Flash-MoE、48GB MacBook Proで397B Qwenを動かす実験を公開

2026年3月22日の Hacker Newsの投稿で注目された Flash-MoE は、「超大規模 MoE はサーバーでなければ動かない」という前提に切り込む実験として読める。リンク先の GitHub リポジトリと論文では、Apple M3 Max と 48GB unified memory を搭載した MacBook Pro 上で Qwen3.5-397B-A17B を動かす pure C/Metal の推論エンジンが説明されている。示された主要な数値は、4-bit の production 構成で 4.36 tok/s、さらに攻めた 2-bit 構成で 5.74 tok/s だ。ただし作者自身が、2-bit は JSON 出力や tool calling の品質を崩すため、実運用向きなのは 4-bit 構成だと明記している。

技術的に何が面白いのか

Flash-MoE のポイントは、209GB 級の expert 重みを一括でメモリに載せないことにある。各トークンで実際に有効化された expert だけを NVMe SSD から並列 pread() で読み出し、計算は hand-tuned な Metal shader に渡す。公開資料によれば、モデルは 60 層の transformer から成り、そのうち 45 層は GatedDeltaNet ベースの linear attention、15 層は full attention だ。各層には 512 個の expert があるが、トークンごとに使うのは K=4 だけで、この sparsity が巨大なパラメータ数と現実的なワーキングセットの間に余地を作っている。

• 4-bit expert 構成ではモデル全体は 209GB だが、論文は同時常駐する重みを約 5.5GB に抑えられるとしている。
• Metal 側には dequantized matrix-vector kernel、fused normalization、activation、MoE combine などが実装されている。
• 要旨では、独自キャッシュを捨てて macOS の page cache に任せた結果、memory compressor の圧力が減り 38% の高速化が出たと述べている。

なぜコミュニティが反応したか

Hacker News での関心は「397B をノートPCで動かした」という見出しだけではない。より重要なのは、ボトルネックの見方を変えた点だ。巨大モデルの可否は単純な parameter count だけで決まるのではなく、SSD の読み出し速度、unified memory の帯域、quantization 誤差、sparse routing の組み合わせで決まる。さらに Apple Silicon では SSD DMA と GPU 計算が同じメモリコントローラを共有するため、無理に重ねるより GPU→SSD→GPU の直列パイプラインの方が良いという結論も、local LLM のシステム設計として興味深い。

注意点

もちろん、これはそのまま汎用デプロイ手法になるわけではない。実装は Metal と Qwen3.5-397B-A17B に強く最適化されており、高速な 2-bit モードには構造化出力の信頼性低下という明確な代償がある。それでも、「巨大 MoE を consumer hardware でどこまで扱えるか」を具体的な数値と設計判断で示した点は大きい。local inference を追う読者にとっては、モデルサイズだけで不可能を決めつけないという示唆の方が重要だろう。

出典

• Hacker News の議論
• Flash-MoE GitHub リポジトリ
• Flash-MoE 論文