Qwen3.8-27Bを256Kコンテキストで24GB RTX PRO 4000 SFF (432 GB/s)上で: MTP使用時50トークン/秒

AIインフラストラクチャ Qwen3.8 27Bを256Kコンテキストで: 24GB GPU上で50 TPS 2026年8月17日・17分読書・Michał Piszczek #Qwen3.8 #MTP #NVFP4 #llama.cpp #local LLM #GPU inference Qwen3.8のMTPドラフターに、さらに69.2 MiBの精度を追加しました。スループットは50.44から37.02トークン/秒に低下しました。この結果は、実験全体を要約しています。最良のローカル推論セットアップは、個別に「最良」の部品から作られることはめったにありません。 私は、27Bの密なモデル、その完全な262,144トークンのコンテキスト、マルチモーダル入力、最大限の有用な品質、そして24GBのVRAMを持つNVIDIA RTX PRO 4000 Blackwell SFF上でのスペキュラティブデコーディングを望んでいました。また、モデルロード後に印刷するエージェントの実際の作業にも耐える必要がありました。 この実験は、以前に私が書いた仮説に従いました。慎重な運用は、より大きなモデルへの移行と同じくらい重要かもしれないということです。完成したシステムは、現在の10回の実行プロダクションシリーズで平均50.44トークン/秒を達成しました。 厳密なランタイムA/Bテストでは、カスタムllama.cppビルドはクリーンなマスタービルドの45.42トークン/秒に対して55.40トークン/秒を達成し、21.97%のゲインとなりました。ターゲットのみのグリッドデコーディングと比較して、組み込みMTPは21.19から59.46トークン/秒、つまり2.81倍のスループットを移動させます。実際に占有された256Kキャッシュの遠端でも、メモリ不足エラーなしで12.61トークン/秒を生成します。 これらの数値は異なるゲートから得られたものであり、別々に保つべきです。それらを一つの英雄的なスピードアップに組み合わせると、より良いヘッドラインとより悪いベンチマークになるでしょう。勝利したセットアップは、量子化、ドラフター、CUDAカーネル、メモリレイアウト、ワークロードの間の適合性から生まれました。どのコンポーネントも単独では勝利しませんでした。 ターゲットは意図的に非現実的でした Qwen3.8 27Bは64層の密なモデルです。その繰り返しパターンは、3つのGated DeltaNet層と1つのフルアテンション層で構成されており、48のリカレント層と16の従来のレイヤーアテンション層があります。ネイティブで262,144トークンのコンテキスト、1層のMTPヘッド、そして独立した27層のビジョンエンコーダーを備えています。 ハードウェアは有用な方法で偏っています。GPU0: RTX PRO 4000 Blackwell SFF、24GB GDDR7（ECC付き）、192ビットメモリインターフェース、432 GB/sピークメモリ帯域幅、24,467 MiB報告容量、sm120a。ターゲット、組み込みMTP、リカレント状態、グラフ、そして256K KVキャッシュを保持します。GPU1: RTX 2000 Ada、15,996 MiB、sm89。F16マルチモーダルプロジェクターとその他の補助サービスを保持します。 ランタイム: Debian 13、CUDA 12.9.86、GCC 14.2、デュアルアーキテクチャCUDAビルド。 16のフルアテンション層のみが、シーケンス長とともに従来のKVキャッシュを成長させます。これにより、256Kが最初に思われるほど不条理ではなくなります。Q4 KとVを使用すると、そのキャッシュはアロケータオーバーヘッドを除いて約4.25 GiBかかります。DeltaNetは代わりにリカレント状態とチェックポイントを追加します。4つのチェックポイントが有用な最小値でした。デフォルトの32は、私が他の場所で必要としたメモリを消費しました。 NVIDIAは432 GB/sのピーク帯域幅を引用しています。これはハードウェアの天井であり、llama.cppからのアプリケーションメトリックではありませんが、ここでは重要です。自己回帰デコードは、量子化された重みを繰り返しストリーミングし、16のアテンション層は、コンテキストが満たされるにつれてますます高価なKV読み取りを追加します。これが、同じプロファイルがプロダクションタスクで約50トークン/秒、261.5Kトークンキャッシュの遠端で12.61トークン/秒になる理由です。 当初の計画は単純でした。容量を推定し、量子化を選択し、ベンチマークを実行する。マシンはすぐに、容量推定は単なる入場券にすぎないことを教えてくれました。本当のテストはロード後に始まります。 最初の勝者はQ4_0でしたが、それは間違った勝者でした。 私は40Kコンテキストで公開GGUFから始めました。Q4_0は驚くほど強力でした。ターゲットのみのデコーディングは22.40トークン/秒に達し、n_max=3のMTPは44.95に達しました。ファイルサイズと量子化ラベルが実際に実行されるCUDAカーネルを記述していないため、より小さいQ3_K_Mや名目上よりスマートなQ4_K_Mバリアントを上回りました。 | Quant | Target | Only MTP n=3 | Acceptance | |------------|--------|--------------|------------| | Q3_K_M | 17.00 tok/s | 31.34 tok/s | 83.98% | | IQ4_XS, iMatrix | 20.63 tok/s | 34.40 tok/s | 64.87% | | Q4_0 | 22.40 tok/s | 44.95 tok/s | 80.40% | | Q4_K_M | 17.57 tok/s | 26.15 tok/s | 66.86% | 次に品質テストが簡単な答えを台無しにしました。短く同一のWikiText-2コントロールで、IQ4_XSは6.1175のパープレキシティを記録し、Q4_0は6.3798を記録しました。Q4_0は速度表をリードしました。しかし、Hermesにはメインモデルが必要であり、その品質のトレードオフは数百ミリ秒のために高すぎると感じました。私は27Bモデルを大きすぎるオートコンプリートとして使用していたでしょう。 反対の極端も失敗しました。Q4_1は6.1127 PPLに達し、IQ4_XSをわずかに上回りましたが、そのメモリフットプリントにより、256KとF16ビジョンが窮屈になりました。有用な点は、高速で鈍い量子化と、システム全体に十分な余地を残す正確なファイルの中間にありました。 256Kのロードはほとんど何も証明しませんでした 初期の容量テストは良好に見えました。Q4_0、MTP、Q4 KV、4つのリカレントチェックポイント、F16プロジェクターはすべて262,144コンテキストで割り当てられました。それでも、私が気にかけていた質問には答えられませんでした。スロットを261,500の入力トークンで満たし、さらに256トークンを生成し、ホットキャッシュを再利用しました。切り抜きなし。OOMなし。 最初のQ4_0プロファイルは、キャッシュの終盤で12.06トークン/秒でデコードされましたが、40K付近では44.95でした。GPU使用率は99～100%でしたが、サーバーはCPUコアを約1つ使用しました。ボトルネックは、巨大な占有KVキャッシュを読み取る16のフルアテンション層であり、秘密のCPUフォールバックではありませんでした。 これにより、それ以降のすべての実行でベンチマーク方法が変更されました。「262Kロード済み」は結果テーブルから禁止されました。長コンテキストの主張には、実際のトークンフィル、フィル後のVRAM、ホットデコード、切り抜き状態、および出力ハッシュを含める必要がありました。 既製のNVFP4量子化が品質ゲートを通過しませんでした BlackwellはネイティブFP4ハードウェアを備えているため、既製のNVFP4-MEDIUM GGUFは明白なルートのように見えました。そのバルクターゲットマトリックスはNVFP4を使用し、Q8出力ヘッド、Q6埋め込み、IQ4_XS MTPレイヤーを備えていました。40.46トークン/秒に達し、256Kとビジョンプロファイルを約1,055 MiBの空き容量で完全に収容しました。PPLは6.4949でした。Q4_0よりも悪い。 変換レシピが問題でした。ソースFP8チェックポイントからのアテンションとDeltaNetの重みは、無差別にNVFP4に拡張および再量子化され、大きな、許容範囲の広いマトリックスとともに処理されました。ネイティブ演算はファイルを高速化しましたが、無差別に低い精度はモデルの敏感な部分を損傷しました。ハードウェアフォーマットのサポートは、どこにビットを費やすべきかを教えてくれません。 その失敗により、カスタム量子化の設計が得られました。バルクにはNVFP4を使用し、その後、私たちのワークロードが重要だと判断したテンソルのみを保護します。 私は実際に使用する方法でモデルをキャリブレーションしました キャリブレーションコーパスは、296のHermesセッションからの5,472メッセージから始まりました。私はその資料を一般的なコーパスの前に配置したため、処理された153,600トークンは、コーディング、ポーランド語と英語の会話、インフラストラクチャ作業、ツール呼び出し、そして私のエージェントが実際に目にする厄介な混合を表していました。 キャリブレーションの前に秘密のスキャンが実行されました。PEMキー、プロバイダー トークン、GitHub トークン、Slack トークン、または電子メール アドレスは存在しませんでした。 llama-imatrixは497のターゲット重みに対して重要度データを収集しました。NVFP4はブロック量子化中にiMatrixを直接消費しないため、マトリックスをマップとして使用しました。大きな許容範囲のテンソルはネイティブNVFP4のまま、選択されたアテンション、DeltaNet、FFNテンソルはQ5_KまたはQ6_Kに移動しました。埋め込みはQ6_Kになり、出力ヘッドはQ8_0のままになりました。 最初の5.14 BPWハイブリッドは、6.0967 PPLで品質の勝者でした。また、34.19トークン/秒と遅く、256Kと希望するプロジェクターをGPU上に保持するには大きすぎました。良い実験でした。悪いプロダクションモデル。 2番目のビルドはよりタイトでした。 サイズ: 16,321.38 MiB、5.01 BPW。 バルク マトリックス: ネイティブ NVFP4。 敏感なターゲット テンソル: Hermes iMatrix ランキングを使用した選択された Q5_K および Q6_K。 埋め込みと出力: Q6_K および Q8_0。 組み込み MTP: ネイティブ NVFP4。 PPL: 6.1197、参考の Q4_1 の 6.1127 に対して。 0.11% のギャップは、この短いコントロールのエラーをはるかに下回っています。 これが Qwen3.8-27B-Hermes-iMatrix-NVFP4-Balanced.gguf となりました。これは、参照の Q4_1 の測定された品質を維持し、より高速に実行され、実際のサービングスタックのための十分なスペースを残しました。 MTPにはn=8にトラップドアがありました 初期のスウィープはn_max=3を示唆しました。値4から7は、拒否されたドラフト作業が蓄積するにつれて遅くなりました。その後、n=8で49.31トークン/秒にジャンプしました。 | MTP n_max | TPS | Acceptance | Combined process VRAM | |-----------|-------|------------|-----------------------| | 3 | 43.11 | 78.73% | 18,352 MiB | | 4 | 37.79 | 62.22% | 18,502 MiB | | 7 | 29.10 | 42.95% | 18,950 MiB | | 8 | 49.31 | 80.73% | 19,000 MiB |