▲

Flash-MoE - 노트북에서 3,970억 파라미터 모델을 실행

 (github.com/danveloper)
1P by GN⁺ 10시간전 | ★ favorite | 댓글 1개
  • 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 순차 파이프라인이 하드웨어 최적 형태
▲
GN⁺ 10시간전  [-]
Hacker News 의견들

  • 소비자용 장치에서도 Qwen 3.5 397B를 실행할 수 있는 다른 방법이 있음
    약 2.5 BPW 양자화(quant) 버전이 있어 128GB 메모리 장치에서도 충분히 가능함
    나는 M1 Ultra에서 약 20 tok/s 속도로, 256k 컨텍스트를 유지하며 잘 돌렸음
    lm-evaluation-harness 결과는 mmlu 87.86%, gpqa diamond 82.32%, gsm8k 86.43%, ifeval 75.90% 정도였음
    자세한 경험은 Hugging Face 토론 링크1과 링크2에 정리했음
    오프라인 추론용으로 훌륭한 모델임

    • 링크의 방법도 이미 2-bit quantization을 사용하고 있음
      토큰당 전문가 수를 10명에서 4명으로 줄여 품질이 더 떨어짐
      짧은 프롬프트에는 괜찮지만 긴 세션에서는 쓸모가 없음
      JSON 출력에서 "name" 대신 \name\을 생성해 도구 호출이 불안정해지는 문제도 있음
    • 요즘 tok/s는 얼마나 나오는지 궁금함
      긴 컨텍스트에서도 잘 작동하는지 알고 싶음
      그리고 오랜만에 닉네임을 보니 반갑음 — Neovim을 만든 사람이라니, 정말 대단한 성공임
      나도 매일 쓰고 있음
    • 전력 사용량이 궁금함
      CoconutBattery로 추정할 수 있을지도 모름
    • 단일 M1 Ultra로만 돌린 것인지 궁금함
    • 개인 자동화에 너무 많은 크레딧을 쓰고 있었는데, 이 정보가 큰 도움이 됨

  • 세부 내용을 보면 2-bit 양자화와 전문가 수를 10명에서 4명으로 줄여 5 tok/s 정도를 얻은 것 같음
    흥미로운 개념 증명(proof of concept)이지만, 원래의 397B 모델 품질과는 거리가 큼
    이런 극단적인 최적화는 모델의 지능 손실을 초래함
    JSON 출력에서 "name" 대신 \name\을 생성하는 문제도 있어서 실사용에는 부적합함
    이런 실험이 기술적으로 가능함을 보여주는 시도라는 점은 인정하지만, 실제로 쓸 수 있는 수준은 아님
    요즘 이런 AI 작성 논문들이 너무 많아 피로감을 느낌

    • JSON 출력 문제를 보고, 샘플링을 유효한 JSON 토큰으로만 제한하면 되지 않을까 생각했음
      하지만 실제로는 상용 LLM조차 도구 호출 정확도가 낮다는 얘기를 들었음
      아마 구현이 어렵거나 구조적으로 불가능한 부분이 있을 것 같음

  • r/LocalLLaMA 토론에서도 관련 논의가 있었음

  • 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, vllm, sglang)이 이런 기능을 지원함
      하지만 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 속도는 그 정도 수준임
답변달기