RTX PRO 4000 Blackwell(24GB)1枚で、密な27BモデルのQwen3.8を、フル262,144トークンのコンテキストとビジョン付きで動かしました。本番環境で平均50.44 tok/sです。この記事は、その構成にたどり着くまでの測定記録です。
結論から書きます。勝った構成は「個々に最良の部品」の集合ではなく、量子化・ドラフター・CUDAカーネル・メモリ配置・実ワークロードの噛み合わせでした。
ハードウェア
- GPU0: RTX PRO 4000 Blackwell SFF、24GB GDDR7、帯域432GB/s、sm120a。ターゲット本体、埋め込みMTP、256KのKVキャッシュを保持
- GPU1: RTX 2000 Ada、16GB、sm89。F16のマルチモーダルプロジェクター(982MiB)を保持
- Debian 13、CUDA 12.9.86、GCC 14.2
Qwen3.8 27Bは64層のうち、フルアテンションは16層だけです(残り48層はGated DeltaNet)。KVキャッシュが伸びるのは16層のみなので、Q4のK/Vなら256Kでも約4.25GiBで済みます。256Kという数字が見た目ほど無茶ではない理由がこれです。
既製の量子化はどれも一長一短だった
40Kコンテキストで公開GGUFを比較したときの数字です。
| 量子化 | ターゲットのみ | MTP n=3 | 受理率 |
|---|---|---|---|
| Q3_K_M | 17.00 tok/s | 31.34 | 83.98% |
| IQ4_XS (iMatrix) | 20.63 | 34.40 | 64.87% |
| Q4_0 | 22.40 | 44.95 | 80.40% |
| Q4_K_M | 17.57 | 26.15 | 66.86% |
速度ではQ4_0が勝ちましたが、WikiText-2の同一コントロールでPPLは6.3798。IQ4_XSは6.1175でした。速いが粗い。ここで「速さの勝者」をそのまま採用すると、27Bを巨大なオートコンプリートとして使うことになります。
Blackwellにはネイティブなんが載っているので、既製のNVFP4-MEDIUMも試しました。40.46 tok/sで速いのに、PPLは6.4949でQ4_0より悪い。変換レシピが、敏感なテンソルまで一律に低精度化していたのが原因でした。ハードウェアがFP4を持っていることと、どのテンソルにビットを使うべきかは別の話です。
自分のワークロードでキャリブレーションする
そこで自前のハイブリッドを作りました。キャリブレーションコーパスは、実際のエージェントセッション296件から5,472メッセージ。コーディング、ポーランド語と英語の会話、インフラ作業、ツール呼び出し。つまり本番でモデルが実際に見るものです。
llama-imatrixで497個のターゲット重みの重要度を取り、地図として使いました。寛容な大きい行列はネイティブNVFP4のまま。敏感なアテンション・DeltaNet・FFNテンソルはQ5_KやQ6_Kへ。埋め込みはQ6_K、出力ヘッドはQ8_0。
出来上がったのは16,321.38MiB、5.01BPWのハイブリッドで、PPLは6.1197。Q4_1リファレンス(6.1127)との差はこの短いコントロールの誤差以下です。
このモデルは公開しました: https://huggingface.co/cdiamond/Qwen3.8-27B-iMatrix-NVFP4-MTP-GGUF (GGUF本体、F16プロジェクター、SHA-256、テンソルタイプ表、llama.cppパッチ一覧つき)
MTPはn=8に「落とし穴」があった
| n_max | TPS | 受理率 | プロセスVRAM |
|---|---|---|---|
| 3 | 43.11 | 78.73% | 18,352 MiB |
| 4 | 37.79 | 62.22% | 18,502 |
| 7 | 29.10 | 42.95% | 18,950 |
| 8 | 49.31 | 48.33% | 19,100 |
| 9 | 49.02 | 43.95% | 19,250 |
| 12 | 43.31 | 34.34% | 19,700 |
曲線は単調ではありません。8候補がバッチとカーネルの形にはまりました。n=9は速くならないうえ、フル256K構成では162MiBのCUDAグラフ割り当てでOOM。n=8が「アロケータに噛まれる前の最後の速い点」でした。
一番意外だったのはこれです。MTPドラフターに69.2MiB分の精度を足したら、50.44から37.02 tok/sに落ちました。ドラフターの仕事は抽象的に正確なことではなく、この量子化済みターゲットを予測することです。安いNVFP4ドラフターのほうが、NVFP4主体のターゲットと誤差の癖が揃っていて、提案が生き残る確率が高かった。単体の精度より、ドラフターとターゲットの整合が効きます。
llama.cppのビルドはモデルと同じくらい効いた
PRを1本ずつA/Bで測りました(n-gram投機は計測中オフ。プロンプトを繰り返すとキャッシュが学習して見かけ180 tok/sになり、比較を汚染するため)。
| ランタイム | 結果 | 判断 |
|---|---|---|
| クリーンmaster b10454 | 45.422 tok/s | 基準 |
| #26001 + #26048 + #26705 | 45.866 | 採用 (+0.98%) |
| + #27173 (チェーンMTP) | 55.402 | 採用 (+21.97%) |
| #27140 | prefill -1.59% | 却下 |
| #26079 | prefill -1.96% | 却下 |
最終ビルドは6本のPRを監査済みコミットハッシュで固定しています。どれかのPR headが動いたらビルダーは停止します。
「256Kロード成功」はほぼ何も証明しない
261,500トークンを実際に詰めて、キャッシュの端で256トークン生成しました。切り捨てなし、OOMなし、12.61 tok/s。40K付近では同じ構成で約50 tok/sです。ボトルネックは16層のフルアテンションが巨大なKVを読むことで、隠れたCPUフォールバックではありません(GPU使用率99-100%)。
ロードできたことと、端で生成できることは別の主張です。ロングコンテキストの主張には、実際の充填トークン数、充填後VRAM、ホットデコード速度、切り捨ての有無を付けるべきだと思います。
まとめ
- 24GB1枚で27B+ビジョン+実256Kは動く。本番平均50.44 tok/s
- 5.01BPWのiMatrix/NVFP4ハイブリッドはQ4_1品質を維持しつつ、サービングスタックの余地を残した
- MTP n=8は測定で見つけたスイートスポット。n=9以降はCUDA割り当ての崖
- ドラフターの単体精度より、量子化ターゲットとの整合が支配的
- カスタムllama.cppビルドで厳密同一ワークロードが+21.97%
元記事(英語、全テーブルと失敗実験つき): https://piszczek.pl/blog/qwen38-27b-256k-50-tps-24gb-gpu