8月17日、Michal Piszczekが「Qwen3.8 27B at 256K: 50 TPS on a 24 GB GPU」と題した記事を公開した。24GB VRAMのGPU上で27Bパラメータのモデルを256Kコンテキスト全体で動作させながら平均50トークン/秒を達成するまでの実験過程を詳述した内容だ。
ローカルでLLMを動かすエンジニアが常に直面する問題がある。「VRAMが足りない」「速度が出ない」「精度を取るか速度を取るか」──この記事はその三つを同時に攻略しようとした記録だ。最大の収穫は数値よりも「精度の高いドラフターを使ったら速度が落ちた」という反直感的な教訓であり、その理由を追うことで最新GPU・量子化・投機的デコーディングの相互作用が浮かび上がる。
目標設定：意図的に無謀なターゲット
Piszczekが設定した要件は以下の通りだ。
- **Qwen3.8 27B**（Alibaba Cloudが開発するQwenシリーズの27Bパラメータモデル。線形再帰型層とフルアテンション層を組み合わせたハイブリッドアーキテクチャを持つ）をフル精度に近い品質で動かす
- 262,144トークン（256K）のコンテキストを使い切る
- マルチモーダル入力（画像）に対応する
- Speculative Decoding（投機的デコーディング）を有効にする
- ハードウェアはNVIDIA RTX PRO 4000 Blackwell SFF（VRAM 24GB、GDDR7、432GB/s帯域）のみ
Speculative Decodingとは、小さなドラフトモデルが次トークンの候補を先読みし、メインモデルがまとめて検証することでスループットを向上させる手法だ。ローカル推論では「メインモデルの推論がメモリ帯域律速になる」ため、バッチ処理を増やせるこの手法が特に効果を発揮する。
Qwen3.8 27Bは64層のうち48層がGated DeltaNet（線形再帰型のアテンション代替層）、残り16層が通常のフルアテンションというハイブリッド構造を持つ。KVキャッシュが膨らむのはフルアテンションの16層だけなので、「256Kは一見無謀だが実際には約4.25GiBで収まる」とPiszczekは説明する。これがロングコンテキストを24GBに収められる設計上の根拠だ。
結果として達成した数字は次の通りだ。
- 本番環境10回計測の平均：50.44 tok/s
- カスタムllama.cppビルド vs. クリーンマスター：55.40 vs. 45.42 tok/s（**+21.97%**）
- MTP（投機的デコーディング）あり vs. なし：59.46 vs. 21.19 tok/s（約2.81倍）
- 256Kキャッシュの末端（261,500トークン充填後）：12.61 tok/s（OOMなし）
最大の発見：「精度の高いドラフターが速度を落とした」
実験で最も反直感的な結果がこれだ。
MTPドラフター（メインモデルの次トークンを先読みするサブモデル）の重みをより高精度な量子化に替えたところ、スループットが50.44から37.02 tok/sに低下した。
| MTPの重み | 追加サイズ | 平均TPS | 受理率 |
|---|---|---|---|
| 本番NVFP4 | baseline | 50.441 | 48.329% |
| iMatrix Q5_K | +50.6 MiB | 48.733 | 46.751% |
| Q5_K + critical Q6_K | +69.2 MiB | 37.024 | 33.065% |
原因はドラフターとターゲットの「量子化誤差の相性」だ。メインモデルはNVFP4（NVIDIA Blackwell世代がハードウェアレベルでネイティブサポートするFP4演算形式）で量子化されており、ドラフターも同じNVFP4にすることで誤差の傾向が揃い、提案トークンの受理率が高まる。ドラフターだけ高精度にすると、「正確すぎる予測」がターゲットのFP4誤差と噛み合わず弾かれやすくなってしまう。
「ドラフターとターゲットは一つの量子化システムを形成する。どちらか一方の単体スコアは的外れだ」
量子化戦略：NVFP4 + iMatrix選択的保護
BlackwellはネイティブFP4演算をサポートするが、「とりあえずNVFP4で量子化する」では品質が出なかった。既製のNVFP4-MEDIUM GGUFはパープレキシティ6.4949と、Q4_0の6.3798より悪化した。アテンション層やDeltaNet層など感度の高い部分まで一律NVFP4にしたのが原因だ。
そこでPiszczekは独自のキャリブレーション手法を採用した。
- 実際の使用データでキャリブレーション：Hermesセッション296件、5,472メッセージを使用（事前に秘密鍵・APIトークン等がないことをスキャンで確認）
- iMatrixで重要テンソルを特定。iMatrixはllama.cppが提供するキャリブレーション手法で、各テンソルへの入力活性化の大きさを測定し、量子化の影響が大きい層を特定できる。大きく許容度の高いテンソルはNVFP4のまま、アテンション・DeltaNet・FFNの一部のみQ5_K/Q6_Kに昇格させた
- 埋め込み層はQ6_K、出力ヘッドはQ8_0
完成したQwen3.8-27B-Hermes-iMatrix-NVFP4-Balanced.ggufは5.01 BPW、約16.3GiB。パープレキシティ6.1197とQ4_1（6.1127）とほぼ同等の精度を保ちながら、速度と必要メモリを両立した。
MTPのn_max：「8」という奇妙な最適解
ドラフトの先読み数（n_max）のスイープでも反直感的な結果が出た。
| n_max | TPS | 受理率 | VRAM |
|---|---|---|---|
| 3 | 43.11 | 78.73% | 18,352 MiB |
| 7 | 29.10 | 42.95% | 18,950 MiB |
| 8 | 49.31 | 48.33% | 19,100 MiB |
| 9 | 49.02 | 43.95% | 19,250 MiB |
| 12 | 43.31 | 34.34% | 19,700 MiB |
n=4〜7と増やすほど遅くなり、n=8で突然跳ね上がる。Piszczekの解釈は「バッチとCUDAカーネルの形状が有利に噛み合った」だ。n=9はn=8より速くなく、しかも256Kキャッシュとの組み合わせでCUDAグラフバッファが162MiB足らず確保できずロードに失敗した。n=8が「アロケーターに弾かれる直前の最後の高速点」として採用された。
llama.cppのカスタムビルドが+22%
モデルと同じくらいランタイムも効いた。クリーンマスター（b10454）に対し、以下のPRを厳選して組み合わせたビルドが45.42→55.40 tok/s（+21.97%）を達成した。
- #27173：MTPチェーン（最大の寄与）
- #26001、#26048：Gated DeltaNet / CUDAディスパッチ
- #26705：Q4/Q5の高速投機的検証
- #24891、#25635：再帰チェックポイントとFlash Attentionスウィズル
Flash Attentionパッチは32Kプリフィルで759→815 tok/s（+7.41%）を記録した。また、PR #27140と#26079は測定でパフォーマンスが下がったため採用を見送った。ビルドはPRのヘッドが変わると自動で止まる仕組みにし、アップストリームの更新で性能が劣化しないよう管理している。
「256Kがロードできる」は何も証明しない
Piszczekが強調するもう一つの教訓がある。「262,144コンテキストでロードできた」というだけではベンチマークとして無意味だという点だ。実際に261,500トークンを充填し、その後256トークン生成するテストを行い、OOMなし・12.06 tok/sを確認して初めて「256Kが使える」と言えると述べている。「262K loaded」という表記は自身の結果表から禁止した。単一コンポーネントの数字を単体で語る文化への静かな異議申し立てでもある。
記事全体を通じて浮かび上がるのは、現代のローカル推論最適化が「コンポーネント単体の性能」ではなく「コンポーネント間のフィット感」によって決まるという視点だ。
「勝利したのはクォント、ドラフター、CUDAカーネル、メモリレイアウト、ワークロードの間のフィット感だ。単体で勝ったコンポーネントは一つもない」
詳細はQwen3.8 27B at 256K: 50 TPS on a 24 GB GPUを参照していただきたい。
