llama-modchip v2.4.0: 64GB CPU専用マシンで284B DeepSeek MoEを実行

llama-modchip v2.4.0は、パッチ適用済みのllama.cppフォークであり、64GBのCPU専用マシン上で、GPUを一切使わずに、284.33BパラメータのDeepSeek-V4-Flash混合専門家モデルを、256Kコンテキスト、毎秒約9〜15トークンで完全にRAM内で実行できると主張しています。このプロジェクトの見出しとなる主張は、標準のIQ2_XXS GGUFが76.87 GiB（64GBのLinuxボックスではメモリ不足でクラッシュする）であるモデルが、ディスク上では56.56 GiB、常駐メモリは約57.61〜58.9 GiBに縮小されたというものです。Hacker Newsの議論（387ポイント、172コメント）は、そのエンジニアリングに感銘を受けた人々と、2ビット級のモデルを実行する価値があるかどうかに懐疑的な人々とに大きく分かれました。

llama-modchip v2.4.0が行うと主張していること

llama-modchipは、統一されたCLI（./modchip）と、llama.cppに対するパッチのセットとして配布されています。その宣伝されている3つの柱は、64GB CPUボックス内の284BフロンティアMoE、純粋なCPU上でGPU並みの速度で動作する30B MoE、そしてAPI不要のClaude Code統合です。

プロジェクト自身の概要テーブルは、ハードウェアを推奨モデルにマッピングしています：

マシン	RAM	推奨モデル	主張される速度（GPU 0基）
開発者向けラップトップ / ミニPC	16〜32 GB	Nemotron-3.5-30B-A3B（14.35 GiB）	25.0〜60.4 tok/s
64GBデスクトップ / サーバー	64 GB	DeepSeek-V4-Flash 284B（56.56 GiB）	44.4 tok/s プリフィル、9.1〜14.7 tok/s デコード
ハイブリッドデスクトップ（CPU + 16GB GPU）	32〜64 GB	Nemotron-30B / Qwen3-30B	80.80 tok/s
8チャンネルワークステーション（Threadripper）	128 GB以上	DeepSeek-284B / Nemotron-30B	111.62 tok/s（30B）

これらの数値はすべてプロジェクトによる自己申告であり、READMEおよびベンチマークテーブルに公開されています。

284Bモデルが64GBのRAMにどのように収まるか

中核となるメカニズムは、アグレッシブな量子化とカスタムテンソル形式の組み合わせです。llama-modchipは、ブロック64、BF16スケール、グレイコード化されたテンソルタイプ（1ウェイトあたり3.75ビットのFractal-64）と、1ウェイトあたり4.25ビットのFractal-MXFP4バリアントを導入しています。また、プロジェクトは「Analytical SwiGLU-H2 Second-Order Hessian Compression」ステップと、25%のランク削減で99.82%のコサイン類似度を保持するという「Exact SVD of wo_b * wo_a」削減についても説明しています。

DeepSeek-V4-Flashビルドは、ディスク上で56.56 GiBと報告されており、76.87 GiBのIQ2_XXSベースラインから約20.31 GiBの削減です。フル256Kコンテキストでは、プロジェクトはピークVmRSSが57.61 GiBと報告しており、同じREADMEの別の箇所では58.9 GiBと記載されています。

重要な互換性の注意点：Fractal-64モデルは、カスタムGGMLタイプID（GGML_TYPE_Q2_0 = 40）とカスタムdeepseek4 / Stockfish-PVSカーネルを使用します。READMEには、これらのファイルをパッチ未適用のllama.cpp、Ollama、またはLM Studioで開くと、unknown tensor type 40で失敗すると明記されています。ユーザーは、プロジェクト独自のバイナリまたはパッチ適用済みビルドを実行する必要があります。

投機的デコードレイヤー：Stockfish-PVSとRouteCrack

llama-modchipのデコード速度の向上は、小さなドラフトモデルに大きく依存しています。このプロジェクトには、1.64 MBのStockfish-PVS v2ドラフターとRouteCrackコンポーネント（L2/L3 Zobrist転置テーブルと説明されています）がバンドルされており、Nemotron-30Bモデルでは96.4%、DeepSeek-284Bでは94.5%の受容率が報告されています。

DeepSeek-V4-Flashでは、プロジェクトは純粋なCPUデコードが9.06〜10.74 tok/s、PVSドラフターを有効にすると11.5〜14.7 tok/sに上昇すると報告しています。Nemotron-30Bでは、ベースデコードが25.02 tok/s、ドラフター使用時は平均48.39 / ピーク60.40 tok/sと報告しています。

Claude Code統合とウォームKVリストア

このプロジェクトには、Claude Code CLIを（全40ツールを有効にして）ローカルエンジンに配線する./modchip claudeコマンドが含まれています。それが解決するとされる問題は、CPUエージェントが毎ターン遭遇する約45秒のプロンプト再評価です。llama-modchipは、/dev/shm Slot-0 KVウォームリストアでこれに対処しており、Nemotron-30Bでは18.9 ms、DeepSeek-284Bでは13.1〜32.6 msと報告されています。

サポートされているハードウェア

READMEには、AMD Zen 5（VPDPBUSD、VPRORVQ、VBMI、BF16を備えたAVX-512）、Zen 4マルチCCD ThreadripperおよびEPYC（動的L3 CCDトポロジ発見、プロジェクトが-t 64より54%高速と主張する決定的なCCDあたり4コアのストライド）、AMD 3D V-CacheとRadeon Vulkanハイブリッド、Intel/NVIDIA Windowsハイブリッド、Metal経由のApple Silicon、ARM64クラウド（SDOTと256ビットSVEを備えたAWS Graviton3）、FedoraミニPC構成向けのアーキテクチャ固有カーネルがリストされています。

READMEのコミュニティ投稿リーダーボードエントリには、Threadripper PRO 7985WX（Nemotron-30Bで111.62 tok/sウォームデコード）、Apple M4 Pro（47〜48 tok/s）、AWS Graviton3 m7g.2xlarge（44.97 tok/s）、AVX2のみのEPYC 7402P（27.29 tok/s）が含まれています。

中心的な反対意見：2ビット量子化は品質にどのようなコストをもたらすか？

Hacker Newsスレッドで最も実質的な批判は、速度ではなく量子化品質に関するものです。コメンテーターの@armcatは、ビット幅とモデル品質の関係は非線形であり、一般的に最適点は約4ビットであると主張しました：

「アグレッシブな量子化に関して心に留めておくべきことは、（1）量子化は非線形のパフォーマンス挙動を示すことが経験的に証明されており、（2）一般的にサイズ対パフォーマンスのピーク比は4ビットで発生するということです。それ以下では、パフォーマンスの大幅な低下が見られます。」

@armcatは「Reliability Scaling Laws for Quantized Large Language Models」（TUM）を引用し、音声モデルでの2年間の作業で、8ビット未満は大きな品質低下であったと付け加えました（量子化の挙動はモダリティ間で同一ではないと指摘）。

@walrus01はより直接的で、モデルをここまで縮小することは目的を無効にすると主張しました：

「彼らが縮小するために行っていることは何であれ、unsloth Q2XS量子化またはそれと同等のものよりも悪くなるでしょう。そのサイズのモデルは、完全な非量子化KVキャッシュで適切に実行するには約150GBのRAMが必要です... それをやっていると言うためだけにロボトミー化されたモデルを実行することは、実際には特別なことを達成していません。」

@throw10920はこのジャンルを簡潔に表現しました：「'2ビット量子化'は、'このハードウェアにどれだけ大きなモデルを収められるか'の'マウスにおける'です。」@GypsyKing716も同様の指摘をしました：「ロードできるからといって、ロードすべきとは限りません。」

数人のコメンテーターは、量子化レベルがREADMEからまったく明らかではなかったと述べました。@akieは次のように書いています：「どの量子化で？それが私が知りたい唯一のことです。」@boredatoms：「量子化はおそらく最も重要な情報であり、密度の高い言葉のサラダからはまったく明確ではありません。」

2番目の反対意見：実際にプレーンなllama.cppよりも優れているのか？

@aapplebyはRyzen 7945HX（16コアZen 4、96GB DDR5）でプロジェクトをテストし、NemotronではパフォーマンスがCPU上のストックllama.cppとほぼ同じであり、プリフィルを除いては、と報告しました：

「愚かな質問ですが、このAI生成リポジトリは実際に何か_する_のでしょうか？Nemotronで比較すると、CPU上のプレーンなllama.cppとほぼ同じように動作します（プリフィルがはるかに速いことを除いて）。'modchip setup'でDeepSeekをセットアップするオプションが見当たらないので、まだテストしていません。」

これに対する反論は@sparse-Matrixからで、はるかに弱いハードウェアでプロジェクトが動作したと報告しました：「Ryzen 7 5700U/64GB DDR4でかなりうまく動作します。安定して12〜14 TPS... 意味のある個人作業を行うのに十分な速さで、消費電力は15Wです。」

@robotswantdataは別のパフォーマンス上の懸念を提起しました：「このアプローチのプリフィル（プロンプト処理）ははるかに遅すぎます。」

READMEの可読性の問題

コメントで繰り返し出てきたテーマは、ドキュメント自体についてでした。複数の読者がREADMEをAI生成で解析が難しいと説明しました。@superkickstart：「GitHubのREADMEからAIがスパムした絵文字を掃除してくれる人がいればいいのに。可読性がひどすぎる。」@intoXboxはそれを「かなり不快なReadme.mdで、AIスロップだ」と呼び、「llama.cppをラップしているが、どのプラットフォームの前提があるのかが見えないため、他の読者にとってこれがテストする価値があるかどうかは不明確だ」と指摘しました。@gtirloniは「人間もREADME.mdファイルを読むことを人々は覚えているのでしょうか、それとも私たちはデフォルトでAIスロップにTL;DRを求めているだけなのでしょうか？」と尋ねました。

llama.cppにおけるフォークエコシステムの問題

@SillyUsernameはllama-modchipを、特殊化されたllama.cppフォークのより広いパターン（Bonsai Qwen 3.8 27B、Strata、Pulsarを挙げる）に位置づけ、上流のレビュープロセスがボトルネックであると主張しました：

「上流のLlama.cppがPRをもっと早く受け入れてくれればいいのにと思います。彼らは1日に複数回ビルドしていますが、PRのバックログは前回確認したとき1.7Kで、数人のボランティアでレビューするには非現実的な数です。Qwen 3.8 Bonsai機能を見ていましたが、作成からレビューまで3週間以上かかり、それでも下流で修正したバグのパッチは含まれておらず、プロセスが非常に面倒だったため上流へのプッシュを諦めました。」

議論が示すローカル推論の方向性

数人のコメンテーターは、このプロジェクトを、使用可能なローカル推論のハードウェア下限が下がり続けている証拠と読みました。@kennywinkerは800ドル未満のビルドを説明しました：「スレッドが多いE5ワークステーション、300ドルのRAM、少なくとも100ドルのGPUで、>100tok/s+のプロンプト処理と、Qwen3.8-flash-next:IQ3_Sで約20tok/sの出力ができるものが手に入ります。そこに500ドルのGPUを追加すると、かろうじて使えるレベルから、快適にパフォーマンスが発揮されるレベルになります。」

@antirezはよりハイエンドのデータポイントを提供しました：128GBのユニファイドRAMがあれば、モデルは「速く実行できるだけでなく... コーディングエージェントとして許容できる速さで」、プリフィルは約300 tok/sと述べました。

@nickdothuttonは歴史的な類似点を挙げました：「1980年代のデモシーンの人々の多くは、ハードウェアが希少で高価な国から来ており、それが多くの技術的創造性を駆り立てました。」@aussiegreenieは経済性を「データ主権を備えた有用な作業のための十分な処理能力に対して、1人あたり月額約10ドル」としました。

試す前の実用的な注意点

284B DeepSeekの数値はプロジェクト作者による自己申告であり、スレッド内で独立に再現されていません。
Fractal-64 GGUFファイルはプロジェクトのパッチ適用済みバイナリを必要とします。ストックのllama.cpp、Ollama、LM Studioはunknown tensor type 40で拒否します。
1ウェイトあたり3.75ビットでの品質が未解決の疑問です。READMEはNemotronで「100/100品質ゲート」、DeepSeekプロファイル全体でコサイン類似度0.99126〜1.00000を報告していますが、独立したコメンテーターはこれらのメトリクスが実際の劣化を捉えているかどうかに懐疑的です。
少なくとも1人のテスター（@aappleby）は、Nemotronでプリフィル以外にストックllama.cppと比較して意味のある高速化を見出せませんでしたが、別のテスター（@sparse-Matrix）は古いハードウェアで使用可能なスループットを報告しました。
このプロジェクトはApache 2.0ライセンスであり、paper/ディレクトリにarXivスタイルのプレプリントPDFが含まれています。