BigMoeOnEdge 플래시 스트리밍으로 모바일에서 MoE 실행

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

BigMoeOnEdge는 모바일 RAM 한계보다 큰 MoE 모델을 실행하기 위해 각 토큰이 실제로 라우팅하는 전문가만 플래시에서 스트리밍해 가져오는 접근을 적용했으며, 라우터 훅이 선택된 전문가를 관찰하면 리더가 해당 텐서 슬라이스를 스토리지에서 읽어 연산 전에 포인터를 재결합하는 방식으로 동작한다. 안드로이드 폰 실험에서 단순 mmap은 약 0.1 tok/s로 페이지 캐시 스래싱을 보였지만 전문가 스트리밍은 데모 앱에서 3.8 tok/s, CLI에서는 5 tok/s 이상을 관측해 수십배 성능 차이를 확인했고 gpt-oss-120b 같은 대형 모델도 1~2 tok/s로 로드·생성되는 사례가 보고되었다. 구현은 llama.cpp와 gguf·eval-callback API를 통해 공개 리포지토리로 제공되며 스트리밍 출력이 완전 레지던시 방식과 바이트 단위로 동일함을 테스트로 보장해 정합성을 확보했으나 모바일의 메모리 리클레임 동작과 스토리지 I/O 한계가 처리량을 결정하는 주요 제약으로 남아 있어 추가 측정이 필요하다.

실용적 조언

모바일에서 동일한 실험을 반복할 경우 mmap과 스트리밍 경로 모두에서 바이트 단위 동일성 검증을 수행해 출력 정합성을 보장해야 한다.
데모 앱보다 CLI 경로에서 더 높은 처리량이 관찰되었으므로 초기 성능 실험은 CLI 환경에서도 병행해 측정할 것을 권장한다.
모바일 메모리 리클레임 동작이 결과에 큰 영향을 줄 수 있으므로 다양한 안드로이드 기기와 OS 버전에서 페이지 캐시·리클레임 행태를 측정해 병목 요인을 규명해야 한다.

섹션별 상세

BigMoeOnEdge는 전체 모델을 RAM에 올리지 않고 토큰이 실제로 라우팅되는 전문가만 플래시에서 직접 스트리밍해 실행하는 실험으로, 라우터 훅이 각 층에서 선택된 전문가를 관찰하면 리더가 해당 텐서 슬라이스를 스토리지에서 읽어와 연산 전에 텐서 포인터를 재결합하는 방식으로 동작한다. 이 구조는 토큰별로 접근하는 가중치가 전체의 일부에 불과한 MoE 특성을 활용해 메모리 거주 단위를 '전문가'로 바꾸는 점에서 차이가 있다. 게시물에서는 이 방식으로 나머지 모델은 RAM에 들어오지 않도록 처리해 장비 RAM 한계를 넘겼다고 보고했다.

구체적 성능 측정은 실제 안드로이드 폰에서 수행되었고, 동일 모델 파일을 이용한 비교에서 단순 mmap 접근은 약 0.1 tok/s 수준으로 페이지 캐시 스래싱 때문에 심각한 성능 저하가 발생했으나 전문가 스트리밍은 데모 앱에서 3.8 tok/s, CLI에서는 5 tok/s 이상을 관측했다고 보고되었다. 이 수치들은 I/O 병목과 커널 페이지 관리 방식이 전체 처리량을 결정함을 보여주며, 스트리밍이 절대적인 고성능을 보장하진 않지만 mmap보다 수십배 개선을 이루었다는 근거로 제시되었다. 따라서 스트리밍 기법은 모바일 환경에서 MoE를 실행 가능한 실용적 대안임이 확인되었다.

대형 모델 일반화 가능성은 gpt-oss-120b 사례에서 제시되었고, 이 모델은 디스크 상 약 60GB, RAM 11GB로 약 5.5배 차이가 나는 환경에서도 로드·생성에 성공해 1~2 tok/s를 기록했다. 구현은 llama.cpp를 서브모듈로 사용하고 공개 eval-callback 및 gguf API 경로로 모든 실행이 흐르도록 구성되어 있어 업스트림 변경 시 버전 업만으로 유지보수가 가능하도록 설계되었다. 이 점은 플랫폼 종속성을 줄이고 기존 툴체인과 호환성을 확보한 실무적 장점으로 해석된다.

정확성 검증과 재현성 확보를 위해 스트리밍 출력은 완전히 레지던시 방식(fully-resident)으로 실행한 결과와 바이트 단위로 동일함을 테스트로 보장하고 있으며, 코드와 방법론 노트는 Apache-2.0 라이선스로 공개되어 있다. 작성자는 모바일의 메모리 리클레임 동작에 대한 추가 측정과 교정 제안을 요청해, 현재 결과가 초기 측정에 기반한 것임과 추가 검증의 여지가 있음을 명시했다. 따라서 결과는 구현 가능한 접근법으로서 신뢰할 수 있는 정합성 검증을 동반하지만, 모바일 환경 특유의 메모리 관리 영향은 더 많은 측정이 필요하다.

이미지 분석

Screenshot
이미지에는 BigMoeOnEdge 인터페이스가 보이며 상단에 선택된 모델 명과 프롬프트 입력창, 중앙에 'Loading model...' 상태가 나타나 토큰 처리 중 모델 로드 단계임을 확인할 수 있다. 하단에는 현재 토큰 처리율이 0.00 tok/s로 표시되고 compute·flash wait·cache mgmt 지연 바가 있어 앱이 실시간으로 성능 계측 데이터를 노출하고 있음을 보여준다.
앱 화면 스크린샷으로 BigMoeOnEdge UI에서 모델 선택, 프롬프트 입력, 로딩 상태와 토큰 처리율 관련 메트릭이 표시되어 있다.

용어 해설

혼합 전문가(MoE)(Mixture of Experts (MoE)): — Mixture of Experts는 각 토큰마다 전체 네트워크가 아니라 일부 '전문가' 서브네트워크만 활성화되는 아키텍처로, 토큰별로 선택된 전문가에 대해서만 계산과 가중치 접근이 이루어지기 때문에 전체 모델의 모든 가중치를 메모리에 상주시킬 필요가 없다. 라우터가 각 층에서 선택한 전문가를 결정하면 해당 전문가의 텐서 슬라이스만 로드해 연산 전 포인터를 재결합하는 방식으로 동작한다. 이 방식을 통해 큰 모델을 제한된 RAM 환경에서 부분적으로 실행할 수 있다.
메모리 맵 파일 I/O(mmap): — mmap은 디스크 파일을 프로세스 주소 공간에 매핑해 파일 I/O를 가상 메모리 접근으로 처리하는 기법으로, 커널은 페이지 캐시를 통해 매핑된 페이지를 관리한다. 대규모 모델을 mmap으로 그대로 실행하면 페이지 캐시 스래싱이 발생해 실질적인 처리량이 극도로 저하될 수 있다. 게시물에서는 단순 mmap이 안드로이드 환경에서 약 0.1 tok/s 수준으로 성능 병목을 일으킨다고 보고되었다.
GGUF 파일/API(GGUF): — GGUF는 모델 가중치와 메타데이터를 담는 포맷 및 로드 API로, 게시물에서는 gguf API를 통해 스트리밍·평가 콜백 경로로 모든 실행이 흐르도록 구성해 llama.cpp 상위 모듈로 통합했다. 이 구조는 업스트림 업그레이드를 단순 버전 변경으로 유연하게 처리할 수 있게 하며, 파일 단위 접근으로 필요한 텐서 슬라이스만 불러오는 스트리밍 구현과 결합되었다. 공개 API를 이용해 스트리밍된 출력의 정합성을 검증하는 방식이 사용되었다.
라우터 훅(Router hook): — 라우터 훅은 각 토큰 처리 시 어떤 전문가(expert)가 선택되었는지를 관찰하고 그 정보를 외부로 제공하는 콜백 지점으로, 선택된 전문가 목록을 기반으로 필요한 텐서 슬라이스를 스토리지에서 읽어오는 판독기(reader)를 트리거한다. 이 훅은 토큰별 라우팅 결정과 실제 데이터 로드 시점을 연결해 메모리 거주 단위를 '전문가 단위'로 전환하게 한다. 게시물에서는 이 훅을 통해 필요한 슬라이스만 플래시에서 직접 스트리밍하는 것이 핵심으로 제시되었다.

언급된 도구

llama.cpp중립

로컬 CPU 환경에서 LLM 추론을 수행하는 런타임으로, 게시물에서는 서브모듈로 사용해 스트리밍 실행 경로와 통합했다.

GGUF중립

모델 가중치와 메타데이터 로드·호출을 위한 파일/API 포맷으로 스트리밍 구현의 입출력 경로에 사용되었다.

언급된 리소스

GitHubBigMoeOnEdge repository