# Flash-MoE - 노트북에서 3,970억 파라미터 모델을 실행 > Clean Markdown view of GeekNews topic #27758. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27758](https://news.hada.io/topic?id=27758) - GeekNews Markdown: [https://news.hada.io/topic/27758.md](https://news.hada.io/topic/27758.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-03-23T10:10:50+09:00 - Updated: 2026-03-23T10:10:50+09:00 - Original source: [github.com/danveloper](https://github.com/danveloper/flash-moe) - Points: 5 - Comments: 1 ## Summary 노트북에서도 **397B 파라미터 MoE 모델**을 실시간으로 돌릴 수 있게 만든 초경량 추론 엔진입니다. C와 Metal만으로 작성되어 Python이나 프레임워크 없이 **SSD에서 전문가 가중치를 스트리밍**하며, GPU·SSD·CPU를 병렬로 활용해 4. 4 tok/s 이상을 냅니다. ## Topic Body - 397B 파라미터의 **Mixture-of-Experts 모델**을 **MacBook Pro(48GB RAM)** 에서 초당 4.4토큰 이상으로 실행하는 **C/Metal 기반 추론 엔진** - 전체 209GB 모델을 **SSD에서 스트리밍**하며, **Python이나 프레임워크 없이** C와 Metal 셰이더만으로 구현 - **SSD Expert Streaming**, **FMA 최적화 커널**, **Deferred GPU Compute** 등으로 **GPU·SSD·CPU 병렬 효율**을 극대화 - **4-bit 양자화 구성**이 품질과 속도의 균형을 이루며, **도구 호출 기능**을 포함한 프로덕션 수준 출력 생성 - **노트북 환경에서도 초대형 MoE 모델을 실시간 추론 가능**하게 만든 경량화·최적화 사례 --- ### 성능 결과 - **4-bit 전문가(FMA 커널)** 구성에서 **4.36 tok/s**, 품질 우수, 전체 209GB 디스크 사용 - **4-bit 기본 구성**은 3.90 tok/s로 FMA 최적화 전 단계 - **2-bit 전문가(trust OS)** 구성은 5.74 tok/s로 속도는 빠르지만 JSON 출력 오류로 도구 호출 불가 - **2-bit 피크 단일 토큰**은 7.05 tok/s까지 도달하나 실사용에는 부적합 - **4-bit 양자화**가 실제 운용에 적합한 구성 ### 하드웨어 환경 - **MacBook Pro (Apple M3 Max)**, 16코어 CPU(12P+4E), 40코어 GPU, 16코어 ANE - **48GB 통합 메모리**, 대역폭 약 400GB/s - **SSD**는 1TB Apple Fabric, **17.5GB/s 순차 읽기 속도** - **macOS 26.2 (Darwin 25.2.0)** 환경 ### 모델 아키텍처 - 총 **60개 트랜스포머 레이어**: 45개 **GatedDeltaNet(선형 어텐션)** + 15개 **풀 어텐션** - 각 레이어는 **512명의 전문가**를 가지며, **K=4명**이 토큰당 활성화됨 (공유 전문가 1명 포함) - **히든 차원 4096** - ## 핵심 기술 - ### SSD Expert Streaming - 전문가 가중치(4-bit 기준 209GB)를 **NVMe SSD에서 병렬 pread()** 로 필요 시 로드 - 각 레이어에서 활성화된 **4명의 전문가만 로드**(약 6.75MB씩) - **OS 페이지 캐시**가 자동으로 캐싱을 관리하며, 별도 캐시 불필요 - Apple의 “**LLM in a Flash**” 논문에서 영감을 받은 구조 - ### FMA 최적화 디퀀트 커널 - `(nibble * scale + bias) * x` 연산을 `fma(nibble, scale*x, bias*x)` 형태로 재배열 - `scale*x`와 `bias*x`를 사전 계산하여 **GPU FMA 유닛**이 한 번의 명령으로 수행 - 단순 구현 대비 **12% 속도 향상** - ### Metal Compute Shaders - **4-bit/2-bit 디퀀트 행렬-벡터 곱**, **SwiGLU 활성화**, **RMS 정규화**, **GPU 어텐션(Q@Kᵀ, softmax, scores@V)**, **RoPE**, **MoE 결합+잔차+게이트** 등을 **핸드코드 Metal 커널**로 구현 - ### Deferred GPU Expert Compute - **CMD3(전문가 순전파)** 명령을 비동기 제출하여 GPU가 실행 중일 때 CPU가 다음 레이어 준비 - **결합+정규화+잔차** 연산도 GPU에서 수행되어 다음 레이어로 직접 전달 - ### Accelerate BLAS 활용 - **GatedDeltaNet**의 순환 계산에 `cblas_sscal`, `cblas_sgemv`, `cblas_sger` 사용 - 스칼라 코드 대비 **64% 빠른 성능** - ### Trust the OS - **커스텀 캐시 제거**, OS 페이지 캐시(LRU 기반, 약 35GB)가 전문가 데이터 캐싱 담당 - 자체 Metal LRU, malloc 캐시, LZ4 압축 캐시보다 모두 느림 - **자연스러운 71% 캐시 적중률** 달성 - ## 통합 메모리 제약 - Apple Silicon에서 **SSD DMA와 GPU 연산이 동일 메모리 컨트롤러를 공유** - 병렬 실행 시 GPU 대역폭 포화로 **지연 급증** - **GPU → SSD → GPU** 순차 파이프라인이 **하드웨어 최적 형태** ## Comments ### Comment 53620 - Author: neo - Created: 2026-03-23T10:10:50+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47476422) - 소비자용 장치에서도 **Qwen 3.5 397B**를 실행할 수 있는 다른 방법이 있음 약 **2.5 BPW 양자화(quant)** 버전이 있어 128GB 메모리 장치에서도 충분히 가능함 나는 M1 Ultra에서 약 20 tok/s 속도로, 256k 컨텍스트를 유지하며 잘 돌렸음 [lm-evaluation-harness 결과](https://gist.github.com/simonw/67c754bbc0bc609a6caedee16fef8...)는 mmlu 87.86%, gpqa diamond 82.32%, gsm8k 86.43%, ifeval 75.90% 정도였음 자세한 경험은 [Hugging Face 토론 링크1](https://huggingface.co/ubergarm/Qwen3.5-397B-A17B-GGUF/discu...)과 [링크2](https://huggingface.co/ubergarm/Qwen3.5-397B-A17B-GGUF/discu...)에 정리했음 오프라인 추론용으로 훌륭한 모델임 - 링크의 방법도 이미 **2-bit quantization**을 사용하고 있음 토큰당 전문가 수를 10명에서 4명으로 줄여 품질이 더 떨어짐 짧은 프롬프트에는 괜찮지만 긴 세션에서는 쓸모가 없음 JSON 출력에서 `"name"` 대신 `\name\`을 생성해 **도구 호출이 불안정**해지는 문제도 있음 - 요즘 tok/s는 얼마나 나오는지 궁금함 긴 컨텍스트에서도 잘 작동하는지 알고 싶음 그리고 오랜만에 닉네임을 보니 반갑음 — **Neovim**을 만든 사람이라니, 정말 대단한 성공임 나도 매일 쓰고 있음 - 전력 사용량이 궁금함 [CoconutBattery](https://www.coconut-flavour.com/coconutbattery/)로 추정할 수 있을지도 모름 - 단일 M1 Ultra로만 돌린 것인지 궁금함 - 개인 자동화에 너무 많은 크레딧을 쓰고 있었는데, 이 정보가 큰 도움이 됨 - 세부 내용을 보면 2-bit 양자화와 전문가 수를 10명에서 4명으로 줄여 **5 tok/s** 정도를 얻은 것 같음 흥미로운 개념 증명(proof of concept)이지만, 원래의 397B 모델 품질과는 거리가 큼 이런 극단적인 최적화는 모델의 **지능 손실**을 초래함 JSON 출력에서 `"name"` 대신 `\name\`을 생성하는 문제도 있어서 실사용에는 부적합함 이런 실험이 기술적으로 가능함을 보여주는 시도라는 점은 인정하지만, 실제로 쓸 수 있는 수준은 아님 요즘 이런 **AI 작성 논문**들이 너무 많아 피로감을 느낌 - JSON 출력 문제를 보고, 샘플링을 유효한 JSON 토큰으로만 제한하면 되지 않을까 생각했음 하지만 실제로는 상용 LLM조차 도구 호출 정확도가 낮다는 얘기를 들었음 아마 구현이 어렵거나 구조적으로 불가능한 부분이 있을 것 같음 - [r/LocalLLaMA 토론](https://old.reddit.com/r/LocalLLaMA/comments/1rxmmu5/running...)에서도 관련 논의가 있었음 - GitHub 페이지에 따르면 단순 mmap 접근은 페이지 단위 오버헤드로 병목이 생김 macOS에서 **huge page**를 설정하거나 `posix_fadvise`로 프리패칭을 하면 개선될 수 있을지 궁금함 - 2-bit 양자화의 품질 저하는 실제로 심각한 문제임 실제 작업에서는 잘 튜닝된 **30B 4-bit 모델**이 70B+ 2-bit보다 낫다는 경험이 있음 전문가 수를 줄이면 사실상 다른 모델이 되어버림 그래도 소비자 하드웨어의 한계를 시험해본다는 점은 흥미로움 - “노트북에서 실행”이라는 제목이 매번 **$3000짜리 MacBook**을 의미하는 게 피곤함 압축 기술은 인상적이지만, 일반 사용자에게 현실적인 옵션은 아님 - 나는 꽤 괜찮은 노트북(맥은 아님)을 쓰고 있어서 이런 시도가 흥미로움 하지만 제목을 보고 아무 노트북에서도 돌아갈 거라 기대하지는 않음 지나친 냉소보다는 이런 실험을 즐기는 편임 - 중고 **M1 Max 64GB** 모델은 $2000 이하로도 구할 수 있음 영상 편집 등으로 이미 이런 고성능 맥북을 가진 사람도 많음 별도 장비 없이 기존 노트북으로 실험할 수 있다는 점이 장점임 - 사실 $3000~4000짜리 **Strix Halo** 노트북으로도 가능함 - 제목은 “,on a laptop!”처럼 표현했으면 더 정확했을 것 같음 - 나는 $3000짜리 노트북 두 대(128GB zbook) 클러스터로 전체 모델을 돌렸음 약 20 tok/s 속도였고, 개인에게도 충분히 접근 가능한 수준이라 생각함 업무용으로도 투자 가치가 있었음 - “**No Python. No frameworks. Just C, Objective-C, and hand-tuned Metal shaders.**” 이 문장을 보고 토큰이 어디서 나왔는지 바로 감이 왔음 - “**Hand-written Metal kernels**”이라는데, 혹시 **GPT가 직접 쓴** 건 아닐까? 😉 - 실제로 작성자가 명확히 **AI가 작성한 코드**라고 밝힘 - 정말 인상적인 결과임 Linux에서도 SSD 대신 **시스템 메모리 기반 접근**으로 비슷한 방법이 가능할지 궁금함 혹은 가중치를 ROM 형태로 저장하는 아이디어도 흥미로움 - Linux에서도 동일한 접근이 가능함 다만 이 프로젝트는 Metal을 사용하므로 macOS 전용일 뿐임 - 대부분의 엔진(예: [llama.cpp](https://github.com/ggml-org/llama.cpp/blob/master/tools/cli/...), [vllm](https://docs.vllm.ai/en/stable/configuration/engine_args/#offload), [sglang](https://docs.sglang.io/advanced_features/server_arguments.html))이 이런 기능을 지원함 하지만 MoE 모델은 여전히 **대역폭 제약**이 큼 - 전문가를 시스템 메모리에 로드하는 기능은 이미 대부분의 로컬 AI 프레임워크에서 지원함 다만 디코드 단계는 GPU보다 CPU 전송 오버헤드가 커서 이득이 적음 GPU는 공유 부분 가속에만 쓰는 게 효율적임 - GPU 메모리에 안 맞는 일부 레이어를 CPU로 돌리는 것도 가능하지만 모델이 시스템 RAM이나 디스크로 넘어가면 **성능이 급격히 하락**함 - 이런 접근이 된다면 **3090 두 개와 충분한 RAM**으로도 개인 연구실 수준의 대형 추론이 가능할 것 같음 - SSD가 병목이라는 설명이 있었는데, 저자는 15GB/s를 얻었다고 함 하지만 내가 알기로는 최대 대역폭이 8GB/s 정도였음. 뭘 놓친 걸까? - 이런 구조에서는 IO가 매우 **버스트성**임 라우터 결과가 나오면 SSD에서 전문가를 불러오는데, 그 순간 SSD가 포화됨 평균 IO는 2970MB/s 정도로 SSD 한계보다 훨씬 낮음 일부 텐서를 비동기 읽기로 병렬화하면 더 나을 수도 있음 나는 Linux에서 io_uring으로 실험했을 때 약 20%의 읽기가 연산 중 병렬로 완료됨 - **PCIe 5** 세대에서는 대역폭이 두 배로 늘어나서 최신 SSD가 더 빠름 - **MacBook Pro M5 Pro/Max** 모델의 SSD 속도는 그 정도 수준임