Deepseek v4 flash 0731 284Bを2bitまで潰したGGUFが、クラウドの本家と16問すべて同じ判定を出した

80.76 GiB のファイルをミニPCに読ませて、自作ベンチの16問を通しました。中身は総パラメータ284Bのモデルを、エキスパート部分だけ2bit級まで潰したものです。同じ16問を、クラウドで動いている本家のAPIにも投げてあります。

判定は16問すべて一致しました。解けた13問も、解けなかった3問も、問題番号まで同じ。ところが同じレシピで作られたもう1本のGGUFとの間には2問の差が出て、しかもそれは統計的に意味のない差でした。

前回は同じ機械でバックエンドを入れ替えて、条件を揃えないとベンチマークは平気で嘘をつくという話を書きました。そのとき同一環境でも Resolved率が5.0ポイント揺れることを実測しています。今回の12.5ポイント差を読む物差しに、その数字をそのまま使います。

DeepSeek V4 Flash — 284Bのうち13Bしか動かない

DeepSeek-V4-Flash-0731 は2026年7月31日の公開で、モデルカードには「プレビュー版を置き換える公式リリース」とあります。0731 はリリース番号ではなく日付のスナップショット名で、公式APIの `deepseek-v4-flash` はこれに差し替わっています。

アーキテクチャは config.json と GGUF ヘッダで一致を確認しました。総パラメータ284B、アクティブ13B、43層。ルーテッドエキスパートが256個あって、1トークンにつき上位6個だけが動きます。共有エキスパートが1個、コンテキスト長 1,048,576。

「Flash」は速度とコスト重視の小型のほう。4月24日の公式ニュースで、V4-Pro が 1.6T total / 49B active、V4-Flash が 284B total / 13B active と、別サイズのモデルとして並べて発表されています。公式ベンチは Terminal Bench 2.1 が 82.7。ライセンスは MIT です。

地味に効いてくる点がふたつ。投機的デコード用の DSpark が重みに同梱されていること。そして公式が Jinja形式のチャットテンプレートを配布していないことです。モデルカードは代わりに encoding フォルダの Python スクリプトを案内していて、tokenizer_config.json に chat_template キーは存在しません。ツール呼び出しは DSML 形式です。

ファイル名が、そのまま仕様書になっている

今回使った GGUF のファイル名はこれです。

DeepSeek-V4-Flash-IQ2XXS-w2Q2K-AProjQ8-SExpQ8-OutQ8-chat-v2-imatrix-0731.gguf

長いのですが、意味が分かると量子化レシピがそのまま読めます。配布元の README に対応が明記されていました。

IQ2XXS   ffn_gate_exps / ffn_up_exps  → IQ2_XXS
w2Q2K    ffn_down_exps                → Q2_K
SExpQ8   共有エキスパート ffn_*_shexp  → Q8_0
AProjQ8  attn_q_a/q_b/kv/output_a/_b  → Q8_0
OutQ8    output.weight                → Q8_0
         token_embd / router          → F16
         norm 類                      → F32

IQ2_XXS は llama.cpp の I-quant 系で、重要度行列を前提にした非線形のコードブック型です。公式 quantize の README の例では IQ2_XXS から IQ2_M が約2.3〜2.9 bpw。モデル依存の目安であって絶対値ではありません。imatrix は、キャリブレーション用のテキストを流して各重みが出力にどれだけ寄与するかを事前に測り、その重要度で丸め誤差の配分を決める仕組みです。

設計思想も README にありました。ルーテッドエキスパートはパラメータの大半を占めるが、各エキスパートは一部のトークンしか扱わない。だからルーター、射影、共有エキスパートを Q8_0 で保って挙動を維持し、エキスパートを潰してサイズを稼ぐ、と。潰し分ける仕組み自体は llama.cpp の quantize にもあって、`--tensor-type` に正規表現でテンソル名を書けます。ちなみに「MoE を2bit級に落とすと最初に何が壊れるか」を実証した信頼できる出典は、探しても見つけられませんでした。

比較した2本 — 違うのは imatrix の収集規模だけ

比べたローカルの2本は、antirez(Redis 作者の Salvatore Sanfilippo)と Rednalreden(Maurice Hagemeijer、別人)のリポジトリのものです。HF API のファイルツリーと GGUF ヘッダを実際に読んだところ、違いはほとんどありませんでした。量子化レシピは同一で、Rednalreden 側の README も「確立された DwarfStar Flash q2-imatrix レシピ」と明言しています。埋め込みチャットテンプレートに至っては md5 が完全一致、バイト単位で同じものでした。

実質的に違うのは imatrix の収集規模だけです。chunks_count が antirez版 202,100 に対し Rednalreden版 117,777。約1.7倍の差。

ファイル名の `chat-v2` は DeepSeek 公式の版番号ではなく、antirez が GGUF に埋め込んだテンプレートの第2版という意味の独自の版番号です。公式がテンプレートを配っていない以上、配布元が独自に書き起こしたものになります。Rednalreden版はファイル名に chat-v2 が無いだけで、中身は同一。リポジトリ名の `dwarfstar` も量子化手法ではなく、antirez の自作推論エンジン ds4 の正式名称です。

そのぶん、正直に書いておくことがあります。antirez の README 冒頭には「これらの量子化は DS4 推論エンジン専用である」、Rednalreden の Caveats には「llama.cpp互換の GGUF ではない」と書かれています。にもかかわらず、今回の測定は llama.cpp b10157 の llama-server で完走しました。GGUF の general.architecture は `deepseek4`。llama.cpp が deepseek4 対応を入れたのか、README が保守的すぎるのかは確認できていません。事実として並べておきます。

結果 — クラウドと2bitローカルが、16問とも同じ判定

測ったのは自作ベンチ `llmbench` の L7 grandmaster、16問を各1試行。バグ報告とソースを渡し、返ってきたパッチを隠しテストで検証して Resolved 判定とコード品質を採点します。ローカル機は GMKtec EVO-X2(Ryzen AI Max+ 395 / Radeon 8060S / 統合メモリ)、llama.cpp の ROCm ビルド。起動は `-ngl 99` / `n_ctx 16384` / `--parallel 1` / `--batch-size 512` / `--ubatch-size 512` / `--threads 8` / `--no-mmap` で固定です。

                       Resolved  Combined  品質平均  tok/s  平均待ち
クラウド 0731           13/16      73.5     80.9     59.2    64.4s
ローカル antirez版      13/16      72.2     77.7     12.6   271.1s
ローカル Rednalreden版  11/16      62.2     81.0     12.0   291.5s

図1が16問の判定マップです。クラウドと antirez版は16問すべてで一致しました。不一致ゼロ。解けなかった t101 / t103 / t105 の3問まで同じ。3実行とも落ちているので、モデル側ではなくタスク側の壁でしょう。

80.76 GiB まで潰した2bit級が、クラウドの本家と16問について同じ答案を返した。図2の左は Combined 平均で 73.5 対 72.2、差は1.3ポイントです。

2問の差は、差ではない

Rednalreden版だけが t064 と t095 を落として 11/16 でした。12.5ポイント差。ここで前回の物差しが効いてきます。

McNemar の完全二項検定(両側)にかけると、クラウド対 antirez版は不一致0問で p = 1.00。クラウド対 Rednalreden版、antirez版対 Rednalreden版は、いずれも不一致2問(片側2勝0敗)で p = 0.50 です。差とは言えません。16問×1試行で12.5ポイントというのは、要するに2問ぶんです。

中身を見るとさらに怪しくなります。t095 の失敗は `generation error: Read timed out (read timeout=600)`、600秒の制限時間切れでした。間違った答えを出したのではなく、時間内に答え終わらなかった。3本とも落ちた t101 も、全実行でタイムアウトです。

品質平均(解けた問題のみ)は Rednalreden 81.0 > クラウド 80.9 > antirez 77.7 と、Resolved率とは逆の順序でした。負けたビルドのほうが、解けた問題については綺麗に解いている。imatrix の収集規模が1.7倍違うことの効果は、この16問からは読み取れません。

本当の問題は、12 tok/s のほう

図3が1問あたりの平均待ち時間です。クラウド 64秒に対し、ローカルは 271秒と292秒。tok/s では 59.2 対 12.6 / 12.0 で、約4.7倍の開きがあります。1問投げて4〜5分待ち、16問で1時間強。能力が本家と並んでいても、この速度だと使い方のほうが変わってしまいます。

数字で裏づけがあるのは、まず rocWMMA の Flash Attention です。ROCm ビルドを `-DGGML_HIP_ROCWMMA_FATTN=ON` で作る必要があります。AMD の公式ブログ「Trillion-Parameter LLM on an AMD Ryzen AI Max+ Cluster」に、n_ctx=8192 で生成が 3.46 tok/s から 8.30 tok/s になったという実測が載っています。一次情報です。

本命は投機的デコードでしょう。llama.cpp の Discussion #23659 に、Strix Halo(gfx1151)の ROCm 7.2.3 で Qwen3.5 122B-A10B の生成が 19 tok/s から 26.86 tok/s になったという報告があります。これも llama.cpp リポジトリ内の一次情報。unsloth のドキュメントは一般論として1.4〜2.2倍としていますが、こちらは二次情報寄りに読んでいます。何より V4 Flash は DSpark を重みに同梱しているので、ドラフトモデルを別途探す必要がありません。最大の伸びしろはここだと思っています。

地味な落とし穴が KV キャッシュ量子化です。Discussion #22411 によれば、対称な KV キャッシュ量子化が AMD HIP の高速な fused Flash Attention 経路を有効にする。`-ctk q4_0 -ctv f16` のように K と V を非対称にすると警告なしに低速な経路へ落ちます。ubatch のほうは Issue #18725 (Strix Halo, Vulkan)で、上げすぎると CONCAT のオーバーヘッドが増え、512 で約37秒だった処理が 2048 で約60秒になったと報告されています。推奨は256〜512。今回は既に512でした。

逆に、効かないと分かっているものも。BIOS の VRAM 割り当てや GTT 上限をいじる話をよく見かけますが、ROCm 公式の「AMD Strix Halo system optimization」には「Strix Halo のメモリはマップされているのであって、物理的に分割されているわけではない」と明記されています。容量が載るか載らないかの話であって、速度には効きません。

TDP を上げるのもほぼ無駄でした。Strix Halo Wiki の実測(コミュニティWikiなので二次情報)では、Gemma 3 27B の生成が 55W から 120W までほぼ横ばいで約6 tok/s。伸びるのはプロンプト処理側だけ。生成が帯域律速だからでしょう。`--n-cpu-moe` も、統合メモリ機で効いたという実測は見つかりません。

決着していないものは、していないと書きます。`GGML_HIP_NO_VMM` は Discussion #20856 が「gfx1151 では必須」と言い、別のブログは「OFF にすると96GBの GTT プールにアクセスできた」と逆を言う。ROCm と Vulkan の優劣も、短文脈は Vulkan がやや上、長文脈は ROCm の rocWMMA が優位、と個人ベンチの報告が割れています。バックエンドとバージョンで結果が動く領域なので、一発の測定では何も言えません。

ただ、Framework のコミュニティフォーラムには V4 Flash 284B を単一の Strix Halo 128GB で最大32 tok/s(decode)という書き込みもあります。量子化タイプの記載がなく直接は比べられませんが、12.6 tok/s が上限ではないことは示唆しているでしょう。

その数字、差だと言えますか

手元に残ったのは「2bitでも十分だった」という威勢のいい結論ではありませんでした。16問すべてで一致したという事実と、2問の差を差として扱えなかったという事実、そして4〜5分待つという事実です。

一番危なかったのは、11/16 と 13/16 を並べて「imatrix の収集規模が効いた」と書きかけたところでした。p = 0.50。同一環境でも Resolved率は5.0ポイント揺れると前回自分で測っていたのに、それより大きい12.5ポイントを見た瞬間に意味を読もうとしていた。数字が大きいと、つい差に見えてしまいます。

では何問×何試行なら差と言えるのか。そもそも量子化ビルドの優劣を Resolved率で比べること自体が向いているのか。品質平均が逆順に出た時点で、指標をひとつしか見ないと結論は反転しうる。みなさんの手元の比較表に、試行回数と検定は付いていますか。

Strix Halo で V4 Flash を動かしている方、特に DSpark を使った投機的デコードを llama.cpp 側で走らせられた方がいたら、どのくらい伸びたかコメントで教えてください。12 tok/s のままだと、次の16問を回す気力が持ちません。

#ローカルLLM #DeepSeek #llamacpp #量子化 #GGUF #StrixHalo #ROCm #MoE #ベンチマーク #個人開発 #機械学習