tok/sは「速度」じゃなかった——DFlashが変えた、24GB GPUでの推論の見方
「tok/sが高い＝速い」という読み方が、speculative decodingを使うと成立しなくなる。
先日、Qiitaに投稿されたエンジニアの実測レポートを読んで、この感覚が改めて鮮明になった。70W制限の24GB GPU 1枚に、dense 30Bモデル・256Kコンテキスト・Vision projector・speculative decodingをすべて詰め込んだ実験だ。数字の話を先に書くと、同じGPU・同じターゲットモデル（Q5_K_M）・同じ量子化で、通常デコードが17.98 tok/s、DFlashを使ったコード生成で80.87 tok/sが出ている。4.5倍近い差だ。
ハードウェアは何も変わっていない。変わったのは、出力の「予測しやすさ」だけである。
実験の構成：1枚のGPUに何を詰め込んだのか
使用機材はNVIDIA RTX PRO 4000 Blackwell SFF、VRAMは24GB、消費電力を70Wに制限した状態での実験だ。その上で以下を同時に動かしている。
- ターゲットモデル：Meta Muse Glimmer 30B（UD-Q5_K_M）
- コンテキスト長：262,144トークン（256K）
- Vision projector：量子化済みMuse mmproj
- DFlash drafter：dflash-kquant、最大ドラフト長15トークン
KV cacheはターゲットQ8、ドラフターF16。バッチサイズ1024/256、スレッド8/8。最終的なVRAM使用量は22,920 / 24,467 MiB（93.68%）。ほぼ限界まで使い切っている。
量子化の選択も実験の重要な部分だ。実験的なNVFP4 hybridは94.36 tok/sという最高スループットを出した。しかしWikiText-2 perplexityが5.6493で、Q5_K_Mの5.5420より悪かった。Q5_K_XLはperplexityを約0.26%改善したが、スループットが約13%落ち、DFlashのacceptanceも悪化した。結果としてQ5_K_Mが採用されている。
「最速の量子化は負けた。perplexityが最も低い量子化も負けた」というレポートの書き出しは、この選択の過程を正確に表している。
数字の整理：何がどれだけ変わるのか
workloadごとのtok/sの差は大きい。
| ワークロード | Decode | Acceptance |
|---|---|---|
| 通常デコード（コード） | 17.98 tok/s | n/a |
| DFlash（コード） | 80.87 tok/s | 36.18% |
| 最良チューニング後 | 84.64 tok/s | 38.67% |
| code + prose + planning + infra（混合） | 38.34 tok/s | 14.41% |
| 262,116トークン入力後のデコード | 21.56 tok/s | workload依存 |
コードはspeculative decodingと相性が良い。構文・インデント・API名・JSONスキーマといった要素が、次のトークン候補を狭めるからだ。一方でarchitecture planningや自由な対話文では、ドラフターとターゲットが最初の1トークンで別の正解を選ぶと、その後のspeculative prefixがすべて失効する。
draft lengthの比較も興味深い。
| 最大ドラフト長 | Acceptance | Decode |
|---|---|---|
| 4 tokens | 47.46% | 34.50 tok/s |
| 8 tokens | 27.00% | 40.54 tok/s |
| 12 tokens | 20.33% | 42.22 tok/s |
| 15 tokens | 17.99% | 47.20 tok/s |
ドラフト4はacceptance rateで勝ち、スループットで負けた。ドラフト15はacceptanceが大幅に低いにもかかわらず36.8%速かった。acceptance rateだけ見ていたら、最悪の選択をしていた可能性がある。
より重要な指標として挙げられているのが**平均受理長τ（average acceptance length）**だ。1回の高コストなtarget passで平均何トークンを確定できたか、という数字で、このコーディングrunではτ=6.39が記録されている。
CPUが静かにGPUにブレーキをかけていた
実装上の改善で見逃せないのが、argmaxのCPU/GPU境界の話だ。
DFlash drafterはGPU上で動いていた。しかしgreedyなdraftトークン選択のargmaxが、CPU pathを通っていた。そのため、最もホットなループにdevice-to-host転送と同期が入り込んでいたことになる。
このargmaxをGPU backend graph内に残すと、mixed benchmarkが36.30から38.34 tok/sへ5.6%改善した。コード生成では、この小さな境界削除がDFlash全体の効果と重なり、target単体17.98 tok/sに対して80.87 tok/sという数字が出ている。
「speculative decoderはcheckboxではなくpipelineである。小さなCPU処理1つが、高速なGPU graph全体のmetronomeになり得る」というレポートの一節は、この実験の核心を突いている。
もうひとつ見落とされがちな要素がサンプリングパラメータだ。Muse Glimmerの推奨値はtemperature 1.0・top-p 0.95・top-k 64だが、llama.cppのデフォルトであるmin-p=0.05が残っていた。これをmin-p=0に修正してdocumentedサンプラー設定に合わせると、84.64 tok/s・acceptance 38.67%へ改善した。調整前は78.29 tok/s・36.18%だったので、8.1%の差がサンプリング設定の見落とし1つで出たことになる。
サンプリングは品質設定であると同時に、speculative performanceの設定でもある——これは実務的に効く知見だ。
ここからは見方の話：この実験が示す構造的な意味
単純な感想を言えば、このレポートは「benchmark報告の作法」についての論文でもある。
speculative decodingが実用段階に入りつつある今、「tok/s」という単一指標だけを比較する記事・発表・製品紹介が増えている。しかし今回の実験が示すように、同じGPU・同じモデルでもworkloadが変われば4倍以上の差が出る。acceptance rateも見方を誤れば判断を逆転させる。τを報告しない数字は半分しか情報を持っていない、と言っても過言ではない。
もう少し構造的に言うと、speculative decodingの「速さ」は、ハードウェアの性能ではなく、モデルと出力の相性によって決まるという話になる。これはインフラの最適化とはやや異なる次元の話だ。「このGPUを使えばこの速度が出る」という約束が成立しなくなる。ワークロードの性質——コードか、対話か、推論か——によって速度が非線形に変わる。
実務的に何が変わるかというと、推論サービスを設計するときの前提が変わるということだ。コード補完に特化したサービスと、open-ended QAを扱うサービスでは、同じspeculative decodingの設定をそのまま使っても性能が全然違う。ワークロードに合わせてdraft lengthやdrafter設定を調整しないと、宣伝スペックと実使用感にギャップが生まれる。
256K文脈の扱いについても実験は丁寧だ。「–ctx-size 262144でサーバーが起動するだけでは不十分」というのは、KV memoryがlazy allocationされることがあり、prefill中にCUDA work bufferが増え、長いcache positionでattentionコストが変わるからだという。今回は262,116トークンを実際に入力してデコードを検証している。prompt processing: 371.24 tok/s、far-cache decode: 21.56 tok/s。「コンテキスト容量」と「コンテキスト性能」は別の主張だという指摘は、製品評価の場面でそのまま使える観点だ。
実務への示唆：次にbenchmark記事を読むときの確認リスト
このレポートが末尾にまとめている「benchmarkで最低限報告すべきもの」は、そのままチェックリストとして使える。
- ターゲットモデルと正確なquant recipe
- ドラフターとdraft length
- code・planning・chat・tool callのワークロード比率
- acceptance rateとτ（average acceptance length）
- すべてのサンプリングパラメータ
- prefillとdecodeを分離した数字
- KV cache position（実際にfillした後のVRAM）
- draft token selectionがGPU内に残るか
- speedと並べたquality指標
「単一のtok/sだけでは、speculative decodingのbenchmarkとして情報不足である」という結論は辛口だが、正しい。何を生成したか、何トークンが1回のtarget passで確定したか、CPU/GPU境界がどこにあるか、カーソルがKV cacheのどこにいたか——ここまで揃ってはじめて比較の土台になる。
今後、speculative decodingを採用するプロダクトやサービスが増えていくにつれて、この種の「見た目の速度」と「実使用での速度」のギャップは広がりやすい。ベンダーの発表資料やGitHubのREADMEに書かれたtok/sを読むとき、ワークロードが何か・acceptance rateが何%か・τがいくつかを確認する習慣が、技術判断の精度を上げる。
まとめにかえて
24GB GPU 1枚でdense 30B・256K・Vision・speculative decodingを動かす、というのはそれ自体が興味深い実験だ。ただ今回のレポートの本当の価値は「何を詰め込めたか」ではなく、「何を測れば意味があるか」を丁寧に示した点にある。
tok/sは指標として消えるわけじゃない。ただ、speculative decodingを前提にした世界では、その数字の後ろに「どんな出力を、どんな条件で生成したときの話か」を問い返す習慣が必要になる。
次にAI推論サービスのbenchmark記事を読むとき、「ワークロードの内訳は何か」「acceptance rateは書いてあるか」という問いを入れてみてほしい。それだけで、記事の情報量が変わって見えてくる。
参考元: DFlashでtok/sの意味が変わる — 24GB GPUでMuse Glimmer 30B・256K・Visionを実測した
