64GBのCPUだけで284BのDeepSeek-V4-Flashが動く、GPUは不要
Llama-modchip: 284B DeepSeek on 64GB RAM, no GPU
llama-modchipは、SwiGLU-H2圧縮やFractal-64量子化などの独自手法でDeepSeek-V4-Flash 284Bを56.56GiBまで縮小し、64GBのCPU環境で256Kコンテキストの推論を可能にした。プリフィルは44.4 tok/s、デコードは9.1〜14.7 tok/s。30B MoEでは最大111 tok/sを達成し、Claude Codeの復元も13msで行える。
64GBのLinuxでOOMクラッシュする76.87GiBのDeepSeek-V4-Flashを、ディスク上56.56GiB、256Kコンテキスト全体でVmRSS 57.61〜58.9GiBまで縮小した。
HNでの議論
204- kennywinker
機能するローカルAIシステムの下限はどんどん下がり続けているのに、RAMとGPUの価格は上がり続けている。スレッド数の多いE5ワークステーションに、300ドルのRAMと少なくとも100ドルのGPUを載せれば、プロンプト処理は100tok/s超、出力はQwen3.8-flash-next:IQ3_Sで約20tok/sというものが手に入る。そこに500ドルのGPUを放り込めば、ぎりぎり使えるレベルから快適に動くレベルに変わる。800ドル未満で、1年前のSOTAと互角に渡り合えるものが手に入るわけだ。
Claudeのサブスクをどうやって正当化するのか、僕には分からない。自分の仕事を自動化しようとしている連中から、生計を立てるための道具をレンタルしたいのか？
- aappleby
馬鹿げた質問かもしれないけど、このAI生成のリポジトリって実際に何か_動く_の？
Nemotronで比較してみたところ、CPU上では昔ながらのllama.cppとほぼ同じように動く（ただしprefillはかなり速いようだ）。「modchip setup」でDeepSeekをセットアップするオプションが見当たらないので、そちらはまだ試していない。
追記：これはRyzen 7945hx 16コア Zen 4 + 96GB DDR5での話。
- armcat
過激な量子化で心に留めておくべきことは、経験的に証明されている[1]ように、(1)量子化の性能は非線形な挙動を示し、(2)一般にサイズ対性能比のピークは4bitで起こるということ。それより低くすると性能が大幅に低下するのが分かる。
また、ここ2年ほど音声モデルをいじっているが、自分にとっては8bitを下回ると品質が大きく落ちる。つまりLLMとその他の特化型モダリティモデルでは、量子化は1対1ではないということだ。
[1] "Reliability Scaling Laws for Quantized Large Language Models"、TUM、https://arxiv.org/pdf/2607.10855
- sparse-Matrix
自分のRyzen 7 5700U/64GB DDR4ではかなりいい感じに動く。
安定して12〜14 TPS。
決して爆速ではないけれど、消費電力15Wで意味のある個人作業をこなすには十分速い。
- antirez
これを俯瞰するために、128GBのユニファイドRAMがあれば高速に動くことまで考慮してほしい：https://x.com/antirez/status/2119392658661749175
つまり、コーディングエージェントとして許容できる速さだ。返信の後半を見るとprefillが約300 t/sだが、より大きなprefillならさらに速くなる。
- boredatoms
量子化がおそらく最も重要な情報なのに、あの濃密な言葉のサラダからはまったく分からない。
- akie
どの量子化？そこだけが知りたい。
編集：2bitだと思う。だとしたら出力の品質が気になる。あまり良くないんじゃないかな。
- SillyUsername
興味深い。llama.cppのフォークの中には、重みのストリーミングや特殊な量子化、処理前の展開などがうまくいっているものが結構ある。
- Bonsai Qwen 3.8 27B
- Strata
- Pulsar
- これ…
ただ、上流のLlama.cppがPRをもっと早く受け入れてくれればいいのにと思う。彼らは1日に何度もビルドしているが、PRのバックログは最後に確認したとき1.7Kで、数人のボランティアでレビューするには馬鹿げたほど非現実的な数だ。
Qwen 3.8 Bonsaiの機能を見ていたが、作成からレビューまで3週間以上かかっていて、しかも下流で修正したバグのパッチは含まれていない。プロセスが面倒すぎて上流へのプッシュを単に諦めたのだ。
その結果、モデルサポートが遅れたり欠けたり、BonsaiのHadamard Foldingのように半分しか動かない実装になったりして、新しいモデルがこうした最適化の恩恵を受けられなくなっている。
自分のプロジェクトをフォークのリファレンスにしたいのであれば、こうした特化を奨励するのは構わないのかもしれないが、それは意図したことではないだろう。
少なくともllamaswapを使って推論エンジンとモデルをその場でやりくりし、3つか4つ別々にインストールする必要があるという事実を抽象化できる。