iPhone에서 전문가 스킵 없이 20.5 tok/s로 구동되는 35B MoE
원문 제목 — 35B MoE running at 20.5 tok/s on an iPhone, without skipping experts
📄 전문 번역
OpenBMB가 대형 MoE 모델을 로컬에서 구동하는 방법을 다룬 엔지니어링 기술 문서가 공개되었는데, 그 배후의 시스템 작업이 주목할 만하다. 모델을 축소하거나 전문가를 건너뛰는 대신, 진짜 병목인 플래시 스토리지에서 연산으로 전문가 가중치를 충분히 빠르게 전달하는 문제를 해결했다. OpenBMB의 MiniCPM-V 4.7은 Lookahead Expert Scheduling(LES)이라는 기법을 사용해 실제 라우팅을 변경하거나 전문가를 제외하지 않고 35B-A3B MoE 모델을 로컬에서 구동한다. 핵심 아이디어는 다음 레이어가 필요로 할 전문가를 예측하고, 현재 연산이 진행되는 동안 플래시 스토리지에서 해당 가중치를 미리 불러오며, 준비된 전문가부터 실행하는 것이다.
최적화된 가중치 레이아웃, 혼합 정밀도 양자화, DSpark 추측 디코딩과 결합된 LES는 iPhone 18 Pro Max에서 20.51 tok/s를 달성해 3.38 tok/s 기준선 대비 6.07배 빠르며, 5개 벤치마크에서 0.16점 하락만으로 전문가 가중치를 26.7% 축소했고, 저메모리 구성에서는 약 3GB의 최대 메모리를 사용한다.
전문가 스케줄링과 DSpark 통합을 포함한 구현체는 llama.cpp-omni로 오픈소스로 공개되어 있다. 흥미로운 점은 LES가 모델이 실제 실행하는 전문가를 변경하지 않으면서 메모리 병목을 숨긴다는 것이며, 이 접근법은 다른 MoE 모델에도 적용될 가능성이 있다.
💬 주요 댓글 번역 (5)
🔍 루키 분석
OpenBMB의 MiniCPM-V 4.7은 Lookahead Expert Scheduling(LES) 기법으로 35B-A3B MoE 모델을 iPhone 18 Pro Max에서 전문가 스킵 없이 20.51 tok/s로 구동하며, 이는 3.38 tok/s 기준선 대비 6.07배 빠른 속도다. 전문가 가중치를 26.7% 축소하면서도 5개 벤치마크에서 0.16점 하락에 그쳤고, 저메모리 구성에서 최대 메모리는 약 3GB다. 전문가 스케줄링과 DSpark 통합을 포함한 구현체는 llama.cpp-omni로 오픈소스 공개되어 있다.
— 루키 · glm-5.3-flash:cloud
이 기법은 GPU와 더 큰 모델을 사용하는 데스크톱 추론에도 적합한가?
기본적으로 strata가 하는 일과 같다. 많은(대부분의?) MoE 모델에서 전문가 ID는 레이어 간에 크게 바뀌지 않는다고 한다. 즉, 레이어 X가 전문가 50을 사용했다면 레이어 X+1도 그 전문가를 사용할 가능성이 높다. 그래서 strata는 현재 레이어가 실행되는 동안 다음 레이어를 위해 해당 전문가를 미리 불러온다. 속도는 빨라지지만 특히 더 큰 모델에서는 기적을 기대하지 말라. 여기서 작동하는 이유는 모델 자체도 강하게 양자화되어 있기 때문이다.
지난번에 Strata를 다룰 때는 전문가를 프리페치하지 않고 핫 캐시와 CPU 풀을 사용했다. 어쨌든 놀랍긴 하다. llama.cpp보다 8배 빠른데, 나는 8 tok/s를 얻는 반면 llama.cpp는 겨우 1~2 tok/s이고 내 포크는 24~26 tok/s에 도달한다.
RAM이 충분하면 모든 전문가가 로드되고, 충분하지 않으면 디스크에서 프리페치한다.
그런데 그 프리페치는 히트율이 불안정해서 약하다. 내 포크는 이를 안정적으로 만들었고 훨씬 더 빠르다.