Flash-MoE, 48GB MacBook Pro에서 397B Qwen 모델 구동 실험 공개

2026년 3월 22일 Hacker News에서 빠르게 올라온 Flash-MoE 글은, 초대형 MoE 모델을 반드시 서버급 장비에서만 돌려야 한다는 통념에 정면으로 도전하는 사례로 읽힌다. 링크된 GitHub 저장소와 논문은 Qwen3.5-397B-A17B를 Apple M3 Max, 48GB unified memory를 갖춘 MacBook Pro에서 구동하는 순수 C/Metal 추론 스택을 설명한다. 작성자가 제시한 핵심 수치는 4-bit production 설정에서 4.36 tok/s, 그리고 더 공격적인 2-bit 설정에서 5.74 tok/s다. 다만 2-bit 모드는 JSON 출력과 tool calling 품질이 깨져 실사용에는 4-bit 구성이 더 적합하다고 명시한다.

무엇이 기술적으로 흥미로운가

이 프로젝트의 핵심은 209GB 규모의 expert 가중치를 한 번에 메모리에 올리지 않는 데 있다. Flash-MoE는 각 토큰마다 실제로 활성화되는 expert만 SSD에서 병렬 pread()로 읽어오고, 계산은 hand-tuned Metal shader로 처리한다. 문서에 따르면 전체 60개 transformer layer 중 45개는 GatedDeltaNet 기반 linear attention이고, 각 layer에는 512개의 expert가 있지만 매 토큰에서 활성화되는 것은 K=4다. 이 sparse 구조 덕분에 거대한 파라미터 수와 실제 상주 메모리 사용량 사이에 간극을 만들 수 있었다.

• 4-bit expert 구성에서 디스크 상 모델 크기는 209GB이며, 작성자는 production-quality output과 tool calling이 가능하다고 주장한다.
• 2-bit requantization은 디스크 사용량을 120GB 수준으로 줄이지만, 구조화된 출력이 깨져 실제 에이전트 용도에는 부적합하다고 설명한다.
• 논문 초록은 custom cache를 없애고 macOS page cache에 맡긴 것이 오히려 38% 성능 향상을 만들었다고 적는다.

왜 커뮤니티가 반응했나

Hacker News 반응의 핵심은 “거대한 모델을 소비자 장비에서 어디까지 밀어붙일 수 있는가”에 있다. 이 사례는 계산량보다 메모리 대역폭, SSD 읽기 속도, quantization, sparse expert routing이 더 큰 제약이 될 수 있음을 보여준다. 특히 Apple Silicon의 unified memory 구조에서는 SSD DMA와 GPU 계산이 같은 메모리 컨트롤러를 공유하기 때문에, 작성자는 GPU와 I/O를 무리하게 겹치는 것보다 직렬 파이프라인이 더 낫다고 보고한다. 즉, 이 프로젝트는 단순한 데모라기보다 local LLM 시스템 설계에서 어떤 병목이 실제로 중요한지 드러내는 실험에 가깝다.

주의할 점

물론 이것이 범용적인 배포 해법이라는 뜻은 아니다. 구현은 Apple Metal과 특정 Qwen3.5-397B-A17B 구조에 강하게 최적화되어 있고, 2-bit 모드는 정확도 문제가 명확하다. 그래도 초대형 MoE를 laptop class 하드웨어에서 interactive speed로 돌릴 수 있다는 점 자체가 의미 있는 시그널이다. 커뮤니티 관점에서는 “모델 크기”만으로 불가능을 단정하기보다, sparse architecture와 storage-aware inference를 함께 봐야 한다는 메시지가 더 중요하다.

출처

• Hacker News 토론
• Flash-MoE GitHub 저장소
• Flash-MoE 논문