Qwen 4 QSAがデコードコンテキスト並列処理を実現：Qwen3.8-Flash-Nextに向けたvLLMのドラフトPRを読み解く

2026年9月29日、vLLMリポジトリに「[Model][DCP] Support Qwen4Exp QSA」というタイトルのドラフトプルリクエストが現れた。そしてそれが記述するモデルについて、今月誰かが公開した中で最も具体的なサービング数値が示されている。4基のGPU上でのQwen3.8-Flash-Nextのペア実行では、KVトークン容量が9,759,529から17,603,636へ、最大同時実行数が37.23×から67.15×へ、初回トークンまでの時間が1,869 msから767 msへ短縮された。Qwen3.8-Flash-Nextは、Hugging Faceのモデルカードで「Qwen4アーキテクチャのプレビュー」と説明されている、オープンウェイトの1250億パラメータのMixture-of-Expertsプレビューであり、このプルリクエストは、このアーキテクチャが中核に据えているスパースアテンション経路にデコード・コンテキスト並列処理を追加するものだ。Qwen4自体——ベンダーが2026年9月22日のApsaraカンファレンスで名前を挙げたQwen4 Max、Flash、Plus、27Bの各ティア——はまだ未リリースで、重みも識別子も価格も日付もない。したがってこれは、あるがままに読むべきだ。ローンチではなく、ベンチマークでもなく、Qwen4ファミリーが存在する前に、Qwen4のサービング範囲がどのように広げられつつあるかを示すエンジニアリング上の成果物なのである。

これは現時点で分かっていることをまとめた記事であり、情報源の扱いはいつも以上に重要です。このプルリクエストはドラフトであり、オープンで、未マージです — vllm-project/vllm#59279 は、NVIDIA のソフトウェアエンジニアである Sungsoo Ha によって 2026-09-29 に開かれ、今もドラフトのままです。以下の数値はすべて、PR 本文で報告された著者自身のペア測定値であり、同じ作業の以前のリビジョンで取得されたものです。ここにあるものは独立した監査を受けておらず、リリースにも入っていません。また、著者が付している注意書きは、以下で独立したセクションを設けるほど重要なものです。

プルリクエストが実際に変更する内容

デコード・コンテキスト並列——DCP——は、モデルの変更ではなくサービング手法です。1つのGPUグループがKVキャッシュ全体を保持する代わりに、DCPはそのキャッシュをランク間に分割するため、各ランクはコンテキストの自分のスライスだけを読み取り、アテンション結果は最後にランク間で統合されます。要点は容量です。キャッシュが分割されることで、同じハードウェア上で、はるかに多くの同時長コンテキストトラフィックを保持できるデプロイメントが可能になります。これは、すべてのリクエストが25万トークンを運ぶときにまさに効いてくる制約です。

厄介なのは、Qwen Sparse Attention — QSA — が単純なアテンション層ではないという点です。Qwen3.8-Flash-Next のモデルカードが規定しているように、軽量なインデクサーがキーを圧縮率4でマイクロブロックに圧縮してスコアリングし、最良の512ブロック、およそ2,048トークン位置を保持します。一方、最終的な softmax とバリューの集約は、圧縮されていない K と V に対して実行されます。つまり QSA は KV キャッシュよりも多くの状態を抱えることになります。メインキャッシュがあり、さらにインデクサーが維持するセレクターキャッシュとサイドキャッシュがあります。vLLM の汎用 DCP 実装は、そのどれも把握していません。

#59279がその説明に従って行うことは、DCPにQSA固有の部分について教えることです：

• 各ランクはメインKVキャッシュの自分の担当部分を読み取る一方、QSAのセレクタとサイドキャッシュはレプリケートされたままとなり、ランク間でシャーディングされることはない。

• アテンションの結果は、分割読み込み後にランク間で統合されます。

• セレクタとメインのKVキャッシュは1つのキャッシュグループに保持されるため、両者が乖離することはありません。

• 合成V2バッチは、QSAサイドキャッシュへの書き込みが防止されます。

最後の一対の詳細は、スループットよりも正確さを気にするなら興味深い部分だ。レプリカ化されたセレクタと密かに食い違うシャーディングされたアテンションキャッシュは、クラッシュではなく長いコンテキストでの緩やかな精度低下として現れる類のバグであり、この変更は両者を歩調を合わせることを明示している。著者はまた、AI支援が使われたこと、およびCodexが共著者としてクレジットされていることを述べている。これは率直に言っておく価値がある。この形のドラフトPRでは、誰が何を書いたのかを尋ねるのはもっともなことだからだ。

対になった数値と、その取得方法

テスト計画は検証できるほど具体的であり、だからこそ結果は引用に値する。両方のアームは、4基のGPU上でテンソル並列4とエキスパート並列を有効にしてQwen/Qwen3.8-Flash-Next-FP8を提供し、--gpu-memory-utilization 0.90を指定し、プレフィックスキャッシュを有効にした状態で実行する。両アームの唯一の違いは--decode-context-parallel-sizeである。DCP=1では省略し、DCP=2では2に設定し、ベンチマークがコールドキャッシュから開始されるようにアーム間で再起動する。負荷は128ユーザーで900秒間のAgentX 256kトレースであり、精度はGSM8K用のEvalScopeに加えてチェックイン済みのMRCR評価器で測定し、再起動後の最初の実行を破棄してアームごとに6回実行する。

報告されたスループット差分、DCP=2 対 DCP=1：

• KVトークン — 9,759,529 対 17,603,636、キャッシュ容量が1.80倍に増加。

• 最大同時実行数 — 37.23× 対 67.15×、さらに 1.80×。

• 1秒あたりのリクエスト数 — 1.69 対 2.30、1.36倍。

• 1秒あたりの入力トークン数 — 128,730 対 179,702、1.40倍。

• 初回トークンまでの時間 — 1,869 ms 対 767 ms、2.44分の1。

• トークン間レイテンシ — 43.48 ms 対 26.27 ms、1.66 倍低い。

• 定常状態におけるプレフィックスキャッシュのヒット率 — 67.85% 対 88.98%、21.1 パーセントポイントの向上。

精度は、ウォームアップ後の各実行にわたる平均 ± 標本標準偏差として報告されており、ほぼ横ばいだった。MRCR集計値はDCP=1で0.8630 ± 0.0005、DCP=2で0.8697 ± 0.0153、GSM8Kは0.9788 ± 0.0020 対 0.9790 ± 0.0016だった。2-needleおよび4-needleのMRCRサンプルは両アームとも0.9960と0.9906で固定されていたため、実行間の変動はすべて8-needleサンプルに由来していた。そして、DCP=2の集計実行のうち1回は0.8970を記録し、残りの4回は0.8620から0.8632の間に収まっていた。これは一蹴できるようなノイズではなく実際のばらつきであり、PRでは平滑化されることなく明記されている。

これらの数字が証明しないもの

注意点はPR本文にあり、それは小さなものではありません。ペアになったAgentXと精度の結果は、以前の QSA DCPリビジョンで、コミット3df4ae153ebに基づくvLLMナイトリービルドを使用して測定されました。プルリクエスト内の最終的なクリーンコミットには、その後のQSAローカリゼーションカーネル修正が含まれており、集中的なB200検証に合格しています — しかし、完全なAgentXと精度の評価は、その正確なソース上では繰り返されていません。言い換えれば、スループットの話と出荷されるdiffは同じ成果物ではなく、著者もそう述べています。

それ以外は通常の規律が適用され、ここではそれが厳しく当てはまる。これは単一のコントリビューターが、単一の4基のGPU構成で測定した、単一構成の数値である。これらは中立というよりベンダー寄りだ。フレームワークのコントリビューターがフレームワークの変更を測定するのは普通で有用なことだが、独立した監査ではなく、第三者がこの実行を再現した者はいない。この変更を含むvLLMのリリース版は、今日インストールできるものとして存在しない。変更がまだマージされていないからだ。そしてDCP=2は、ある特定の1つの形状の2分割にすぎない。この差分はDCP=4やDCP=8でどうなるかを約束するものではなく、PRのどこにもそう主張していない。

なぜ未リリースのアーキテクチャに関するサービングPRが、それでも読む価値があるのか

明白な反論はこうだ。タイトルにあるモデルは存在しないのだから、なぜ気にするのか。なぜなら、チューニングされているのはQwen 4ではないからだ。それはQwen3.8-Flash-Nextであり、このモデルは実在する——Alibabaが2026-08-24に公開した、125BパラメータのMoEで、6Bが活性化され、510億パラメータのn-gram埋め込みテーブル、投機的デコーディング用の4B MTPヘッド、3つのGated DeltaNetブロックの12回の繰り返しの後に1つのQSAブロックが続く形で配置された48層、10個がルーティングされ1個が共有されて活性化される512個のエキスパート、そしてカードによれば1,000,000まで拡張可能な262,144トークンのネイティブコンテキストを備えている。これはQwen4アーキテクチャのオープンウェイトによる参照実装であり、QSA——このプルリクエストがDCPにシャーディングを教えているマイクロブロック・スパースアテンション——は、その中で最も特徴的な部分である。

これらの数値が示しているのは、その262Kコンテキストを1つのGPUグループが丸ごと保持しなければならないものとして扱うのをやめたときに何が起きるかだ。KVトークン容量と同時実行数における1.80倍の跳ね上がりは、キャッシュを2つに分割する算術であり、このリストで最も驚きの少ない結果である。より興味深い数値はレイテンシに関するものだ。同一の提供負荷で、初回トークンまでの時間が2.44分の1、トークン間レイテンシが1.66分の1になり、さらに定常状態のプレフィックスキャッシュヒット率が21ポイント改善している。これらが示すのは、DCP経路がレイテンシの犠牲と引き換えに容量を得ているだけではないということだ——このペア実行では、両方を得た。これは、非常に長いシステムプロンプトを伴うエージェントトラフィックを処理している誰にとっても重要な変化の形である。なぜなら、長いコンテキストでのプレフィックスキャッシュの挙動は、通常、長コンテキストのスループットが静かに死ぬ場所だからだ。

そして、これは孤立したパッチではない。同じ週には、Qwen4Expエンジン関連の一連の作業が生まれた。#59214はB200シェイプ向けのSM100低遅延デコードGEMMプランを追加し、#59010はHopper上のQSAパス向けにSM90ネイティブスパースプリフィルカーネルを追加し、#58977はBF16 INC PLE埋め込みをカバーし、#58961——実際にマージされたのはこれで、2026-09-28——は、QSAキービューが生かし続けていたプロファイリングKVキャッシュを修正した。まとめて読むと、これらは、公開の場で、各ランタイムにおいて、ファミリーが出荷される何か月も前から構築されているQwen4アーキテクチャのサービングエンベロープだ。Qwen 4を計画しているなら、有用なシグナルはローンチ日ではない——そんなものは存在しない——カーネルとキャッシュレイアウトが、それをどのようにサービングしなければならなくなるかについてすでに前提としていることだ。

今日電話できる相手

このPRが対象としているアーキテクチャで長文コンテキストの挙動をテストしたいなら、手に取るべきモデルはAlibabaが実際に提供しているFlashティアです。Qwen3.8-Flash — Qwen3.8-Flash-Nextを基に構築された本番デプロイで、1,000,000トークンのコンテキストと131,072トークンの最大出力を持ち、テキスト・画像・動画の入力に対応 — は稼働中であり、それは今日Qwen4Expアーキテクチャを実際に動かしているモデルへの単一のエンドポイントで、qwen/qwen3.8-flashとして、入力100万トークンあたり$0.15、出力100万トークンあたり$0.47、キャッシュ読み取りは$0.0184で掲載されています。これらは当社側でマークアップなしにそのまま渡されるプロバイダーの定価であるため、そのベンダーの価格や制限の変更は、発表されたその日にあなたのところへ届きます。

正直な但し書きが 2 つあります。第一に、Qwen3.8-Flash-Next 自体 — プルリクエストのテストプランにある FP8 ウェイト、つまりこれらの測定値のいずれかをローカルで再現するために必要になるもの — は当社のカタログにはありません。提供されている Flash ティアは QwenCloud のプロダクションラインであり、生のプレビューチェックポイントではありません。PR の正確な構成を実行したいなら、4 台の GPU でセルフホストすることになります。第二に、DCP の変更は未マージのため、今日、どこを呼び出してもそれを動かしているものはありません。提供ティアが与えてくれるのは、あなたのワークロードが DCP の解決する問題にそもそも適した形になっているかどうかを知る手段です。プロンプトが長く、エージェント的で、プレフィックスが多いなら、1.80× の容量とプレフィックスキャッシュの差分が、自分のトレースで注目すべき数値になります。

そしてもしあなたにとって興味深いのが単一のモデルではなく切り替えの問い——Qwen 4 のラインナップがまだ名前も持たないうちに、どの層の上に構築するか——であるなら、それはサービングの問題ではなくルーティングの問題であり、200以上のモデルに対応する1つのAPIこそが、そのファミリーがついに登場したときに、2つ目の契約やコード変更なしに選択肢を開いておく方法です。

直接答える価値のある質問

#59279 は Qwen 4 がリリース済み、あるいはリリース間近だという意味ですか？

いいえ。そのプルリクエストは、アリババが2026年8月24日に出荷したQwen3.8-Flash-Nextに実装されているQwen4Expアーキテクチャに関するものです。Qwen 4ファミリー — Max、Flash、Plus、27B — は、2026年9月22日にApsaraのステージで名前が発表され、後継ラインが5兆〜10兆パラメータと見込まれる企業ロードマップに位置づけられましたが、依然としてモデルカードも重みもAPI識別子もコンテキストウィンドウも価格も日付もありません。プレビューアーキテクチャに並列化モードを追加するフレームワークPRは、Qwen 4をうまくサービングするための一歩です。それはQwen 4が存在するようになるための一歩ではありません。

デコード時のコンテキスト並列は、テンソル並列とはどう違うのですか？

これらは異なるものを分割し、異なる形で失敗する。テンソル並列は重みと各層の計算を複数のGPUに分割するため、すべてのランクがすべてのトークンに参加するが、シーケンス全体を見ることになる。デコードコンテキスト並列はKVキャッシュ自体を分割するため、各ランクはコンテキストの一部だけを保持して読み取り、部分的なアテンション結果は後でマージされる。TPはモデルを収めるためのものであり、DCPはコンテキストとそれに乗る同時トラフィックを収めるためのものである。この違いこそが、このPRが非自明である理由である。QSAのセレクタとサイドキャッシュは、メインのKVキャッシュのように単純にシャーディングできないため、この変更では一方をシャーディングし、他方をレプリケートし、そのうえで両者が一貫していることを証明する必要がある。

今日、ホスト型API経由でQwen3.8-Flash-Nextを呼び出せば、これらの数値はすでに得られるのでしょうか？

いいえ、そしてその隔たりには3つの部分がある。変更は未マージなので、リリース済みのvLLMビルドはどれもそれを含んでいない。仮にマージされたとしても、プロバイダーがそのビルドを採用し、DCPサイズを1より大きくして実行することを選ぶ必要がある——これはサービング構成であり、デフォルトではない。そして測定された差分は、最終コミットではなくパッチの以前のリビジョンによるもので、著者によればこれまで集中的なB200検証しか行われていない。報告された差分は、このアプローチが1つの構成でもたらすものについての十分に文書化された上限として扱うべきであり、今週レンタルできる任意のエンドポイントの仕様として扱うべきではない。

未解決の問題

注目すべきは、この特定のドラフトがマージされるかどうかではない——おそらく何らかの形でマージされるだろう。それが追加するQSA固有のキャッシュ処理は、好みではなく、実際に欠けている部分だからだ。注目すべきは、最終コミットが中間リビジョンと同じ対になった評価を受けるかどうかである。スループットの主張は一方のビルドに由来し、正確性の主張はもう一方のビルドに由来するサービング変更は、現時点では測定結果ではなく、論拠がしっかりした提案にすぎない。また、8-needle MRCRサンプルにおける精度のばらつきは、出荷済みソースで実行を繰り返すことが、誰かがそれについて公表できる最も有用な一点になるほど大きい。それまでは、方向性は読み取れるが、台帳は閉じられておらず、オープンウェイトで公開されている唯一のQwen4アーキテクチャモデルは、依然として8月のものだけである。