巨大なLLMをGPUなしで、しかも64GBのCPUマシンだけで動かす——そんなかなり無茶に見える試みを、GitHub上の llama-modchip は本気でやろうとしています。元記事は単なるデモではなく、DeepSeek-V4-Flash 284Bや30B MoEモデルを、どうやって物理メモリに収め、どの速度で動かし、どんな仕組みで使うのかまで細かく詰めたリポジトリです。GPU前提の常識を崩したい人には面白い一方で、読むほどに「ここまで最適化しないと成立しない世界なのか」とも感じます。今回は、その内容と、そこから見える流れを整理します。
このリポジトリは llama.cpp 系のカーネルパッチ、量子化の変換ツール、実行時ユーティリティをまとめたもので、Sparse Mixture-of-Experts、つまりMoE型のモデルをシステムRAMだけで動かすことを狙っています。対応環境は x86_64 の AVX-512 / AVX2 と、ARM64 の NEON / SVE / Apple Metal です。中心にある主張はかなり明快で、284.33BのDeepSeek-V4-Flashを64GB級のPCに収め、GPUなしで扱えるようにした、という点です。
元記事によれば、標準の UD-IQ1_S ビルドでは DeepSeek-V4-Flash は 76.87 GiB に達し、64GB Linuxマシンの実効的な空きRAMである約62.5 GiBを超えてしまいます。その結果、page cache の激しい入れ替えや OOM kill が起きる。llama-modchip はこれを 56.56 GiB まで圧縮し、256Kコンテキスト用のKV cacheを含めても RAM に収まるようにしています。README には 284.33B total params、13.17B active params、56.56 GiB DeepSeek-V4 GGUF、57.61 GiB Peak VmRSS @ 256K ctx、44.36 tok/s の prefill、25.0〜111.6 tok/s の 30B MoE decode などの数字が並びます。0 GPU で動くことも強調されています。
仕組みとしては、単なる量子化だけではありません。まず、CPU cache と SIMD を意識したパッチで、prefill 時の行列計算を 4段階のタイル処理に置き換え、AVX-512BW のレジスタや L1D、L2、L3 を使い分ける構成にしています。これで 16-core Zen 5 では 25.0 tok/s から 44.36 tok/s へ伸びたと説明されています。さらに、Stockfish-PVS v2 を使った self-speculative drafting と、/dev/shm 上のKV slot snapshots による即時復元も組み合わせ、Claude Code のような40ツールのプロンプトを 13.1〜32.6 ms で復元できるとしています。
README には用途別の表もあり、16〜32GBの開発用ノートPCやミニPCでは Nemotron-3.5-30B-A3B を 25.0〜60.4 tok/s で動かす想定、64GBのデスクトップやサーバーでは DeepSeek-V4-Flash 284B を 44.4 tok/s prefill と 9.1〜14.7 tok/s decode で動かす想定、32〜64GBのハイブリッド環境では CPU＋16GB GPU で 80.80 tok/s、128GB以上のThreadripper環境では 111.62 tok/s といった値が示されています。クイックスタートには ./modchip chat、./modchip web、./modchip bench、./modchip claude などのコマンドも並び、単なる研究資料ではなく、実際に使うための道具として整えられているのが分かります。
このプロジェクトでまず驚くのは、「GPUがないから遅い」という当たり前の前提を、かなり執拗に崩しにいっていることです。私はここに、モデルサイズ競争とは別の、もう一つの競争が見えると思います。つまり、より大きいモデルを作る競争の裏で、「どこまで小さい、安い、ありふれた機械に押し込めるか」という競争です。クラウドGPUは高いし、運用制約もある。そこに対して、64GBのCPUマシンで284Bを動かすのは、派手さはあるがニッチ、と切り捨てるには惜しい発想です。
ただし、ここで示されている数値は、汎用的な「普通の快適さ」とはかなり違います。prefill や decode の速度は確かに出ていますが、それは徹底した最適化と、かなり厳密に選ばれた量子化の成果です。つまり、誰でも同じように使えるわけではない。GGML_TYPE_Q2_0 のような独自 tensor type を使うため、未対応の llama.cpp や Ollama、LM Studio では読めないとも書かれています。私はこの点を、面白さと同時に限界のサインだと見ています。汎用品というより、特定のスタックを理解した人向けの高度な工作に近いからです。
このリポジトリの核心は、モデルを小さくしたことそのものではなく、RAMに「全部乗せ」できるところまで削った点にあります。GPUならVRAMとシステムRAMを分けて考えられますが、CPU-only だと事情が違う。モデル本体、KV cache、OSの余白が同じ場所を奪い合うので、ほんの数GiBの差が性能ではなく生死を分けます。元記事が「zero swap」で動くことを繰り返し強調しているのは、そこが実運用の境目だからでしょう。
私はこの設計に、かなり実務的な割り切りを感じます。モデルを少し圧縮して動けばよい、ではなく、swap に落ちた瞬間に価値が崩れる、という理解です。AI推論は「動くかどうか」より「どの条件で安定して動くか」が大事で、ここではその条件が極端に厳しい。だからこそ、57.61 GiB VmRSS や 62.5 GiB usable Linux RAM といった数字が重要になります。体感の速さより、まず収まるかどうか。順序が逆なんです。
この考え方は、今後のローカルLLMの使われ方にも関係してくると思います。小さなモデルを何個も切り替えるより、ひとつの大きいモデルを、低コストなマシンで安定運用したい需要はあるはずです。とくに社内用途や閉域環境では、GPU調達より既存CPU資産の活用のほうが現実的な場面があります。llama-modchip は、その需要に対してかなり尖った回答を出しているわけです。
もう一つ気になるのは、単に推論を速くするだけでなく、Stockfish-PVS や Claude Code の復元まで持ち込んでいる点です。普通なら「LLMを動かすツール」と「チェスエンジン」「開発用CLI」は別物として扱われます。ところがここでは、推論の補助、状態の再開、ツール呼び出しまでひと続きの体験としてまとめている。私はこれを、モデルそのものではなく「作業の再開性」を価値に置いている設計だと見ます。
13ms台での restore という数字は、単なるベンチマークの華やかさ以上に意味があります。長い文脈を扱うAIエージェントは、止まったあとにいかに素早く元の状態へ戻れるかで実用性が変わるからです。そこが遅いと、結局は再読み込みや再計算で時間を失う。/dev/shm のKVスナップショットは、そのボトルネックをかなり露骨に潰しています。派手なモデル性能より、ワークフローの切れ目を消す方向に寄っているのが面白いところです。
一方で、こうした盛り込み方は、学術的な整理というより「実験室の完成形」に近い印象もあります。どこからが推論エンジンで、どこからがエージェント基盤なのか、境界がかなり曖昧です。そこを雑と見るか、統合的と見るかで評価は分かれるでしょう。私は後者に少し寄ります。いまのAIインフラは、単体のモデル性能より、復元・分割・配置・通信の総合戦になっていて、このリポジトリはその感覚をかなり正直に表しているからです。
llama-modchip を見ていると、ローカルAIは簡単になったというより、分岐したのだと思います。表面的には「自分のPCで巨大モデルが動く」という夢の話ですが、実際にはかなり専門的な知識と、適切なハードウェア、そして特定のビルド環境が要ります。README の情報量も相当で、一般向けというより上級者向けのマニュアルです。それでも公開されている意義は大きい。こういう実装があることで、GPU中心の常識に別の選択肢があると示せるからです。
私は、こうしたCPU-first の試みは今後もっと増えると思います。GPUが足りないから仕方なく、ではなく、既存のCPU資産を活かして運用したい、という現場の要望は確実にあります。ただし、その未来が平易になるとは限りません。むしろ、量子化、カーネル最適化、MoEの扱い、KV cache の置き方まで理解した人が得をする世界になる可能性が高い。llama-modchip は、その未来の先端をかなり極端な形で見せているプロジェクトだと感じます。
