- 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量子化構成が品質と速度のバランスを取り、ツール呼び出し機能を含む本番レベルの出力を生成
- ノートPC環境でも超大規模MoEモデルのリアルタイム推論を可能にした軽量化・最適化の事例
性能結果
- 4-bit専門家（FMAカーネル）構成では4.36 tok/s、品質良好、ディスク使用量は合計209GB
- 4-bit基本構成は3.90 tok/sで、FMA最適化前の段階
- **2-bit専門家（trust the 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個のTransformerレイヤー: 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ユニットが1回の命令で実行- 単純実装と比べて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 の逐次パイプラインがハードウェアに最適な形
1件のコメント
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 にまとめた
オフライン推論用として優れたモデルだ
トークンごとの専門家数を 10 人から 4 人に減らしていて、品質はさらに落ちる
短いプロンプトにはよいが、長いセッションでは役に立たない
JSON 出力で
"name"の代わりに\name\を生成してしまい、ツール呼び出しが不安定になる問題もある長いコンテキストでもうまく動くのか知りたい
それと久しぶりにそのハンドルネームを見てうれしかった — Neovim を作った人だなんて、本当にすごい成功だ
自分も毎日使っている
CoconutBattery で推定できるかもしれない
詳細を見ると、2-bit 量子化と専門家数を 10 人から 4 人に減らすことで 5 tok/s 前後を得たようだ
興味深い概念実証(proof of concept)ではあるが、本来の 397B モデルの品質とはかなり隔たりがある
こうした極端な最適化はモデルの 知能の損失を招く
JSON 出力で
"name"の代わりに\name\を生成する問題もあり、実運用には向かないこうした実験が技術的に可能だと示した点は認めるが、実際に使えるレベルではない
最近はこういう AI が書いた論文 が多すぎてうんざりする
ただ実際には、商用 LLM ですらツール呼び出し精度が低いという話を聞いた
おそらく実装が難しいか、構造的に不可能な部分があるのだろう
r/LocalLLaMA の議論 でも関連する話があった
GitHub ページによると、単純な mmap アクセスはページ単位のオーバーヘッドでボトルネックになる
macOS で huge page を設定したり、
posix_fadviseでプリフェッチしたりすれば改善するのか気になる2-bit 量子化の品質低下は実際かなり深刻な問題だ
実作業では、うまく調整された 30B 4-bit モデル のほうが 70B+ 2-bit より良いという経験がある
専門家数を減らすと、実質的に別のモデルになってしまう
それでもコンシューマー向けハードウェアの限界を試している点は興味深い
「ノートパソコンで動く」というタイトルが毎回 3000ドルの MacBook を意味するのはうんざりする
圧縮技術は印象的だが、一般ユーザーにとって現実的な選択肢ではない
ただ、タイトルを見てどんなノートパソコンでも動くとは期待しない
過剰にシニカルになるより、こういう実験を楽しむほうだ
動画編集などの用途ですでにこうした高性能 MacBook を持っている人も多い
追加の機材なしで既存のノートパソコンで実験できる点が利点だ
速度は約 20 tok/s で、個人にも十分手が届くレベルだと思う
業務用途でも投資する価値があった
“No Python. No frameworks. Just C, Objective-C, and hand-tuned Metal shaders.”
この文を見て、どこからトークンが出てきたのかすぐ察した
“Hand-written Metal kernels” とあるが、もしかして GPT が直接書いた のでは？ 😉
本当に印象的な結果だ
Linux でも SSD の代わりに システムメモリベースのアクセス で似た方法が可能なのか気になる
あるいは重みを ROM の形で保存するアイデアも面白い
ただ、このプロジェクトは Metal を使っているので macOS 専用なだけだ
ただし MoE モデルは依然として 帯域幅の制約 が大きい
ただしデコード段階では GPU より CPU 転送オーバーヘッドのほうが大きく、利得は小さい
GPU は共有部分の高速化にだけ使うのが効率的だ
モデルがシステム RAM やディスクにあふれると 性能が急激に低下する
SSD がボトルネックという説明があったが、著者は 15GB/s を得たと言っていた
しかし自分の理解では最大帯域幅は 8GB/s ほどだった。何か見落としているのだろうか？
ルーターの結果が出ると SSD から専門家を読み込むので、その瞬間に SSD が飽和する
平均 IO は 2970MB/s 程度で、SSD の限界よりかなり低い
一部のテンソルを非同期読み出しで並列化すればさらによくなるかもしれない
自分は Linux で io_uring を試した際、読み出しの約 20% が計算中に並列完了した