Qwen4Exp バッチシャードサンプリング：vLLM PR #61018 の内部と、Qwen 4 について述べていること

vLLM のプルリクエスト #61018 で最も多くのことを語る数字は、損失、すなわち 1.5% だ。これは、作者が自身の変更に対して課した上限である — 42 ミリ秒の平均ステップのうち約 0.6～0.8 ミリ秒の短縮で、しかも本人が所有していないマシンで測定され、自分ではまったく実行できないパッチにおける話だ。このプルリクエストは「[Model] Qwen4Exp: バッチシャードサンプリングのサポート（compute_logits_local）」と題され、2026-10-10 にコントリビューターkimseunghyun-krによって開かれ、Qwen4Exp アーキテクチャが、vLLM が8月に投入したサンプリング経路を取れるように、2つのファイルにモデルコードを3行追加する。これはドラフトだ。モデルコードは14行、加えてテストが57行だ。それでも、この3行が何を覆い隠してパッチを当てているかという理由から、注意深く読む価値はある。Qwen4Exp は、Qwen3.8-Flash-Next の中にあるアーキテクチャである。Qwen3.8-Flash-Next は、ベンダーが 2026-08-24 に「Qwen4 の基盤となるアーキテクチャの実験的プレビュー」として公開した1250億パラメータのオープンウェイトモデルだ — そして、そのアーキテクチャのテキスト専用の半分における2経路バグは、まさにローンチ投稿ではなくサービング層を注視して初めて知る種類の詳細である。

位置づけについて曖昧さがないように言っておきます。ここではそれが重要だからです。Qwen 4 自体は未リリースです。ベンダーは2026-09-22のApsaraカンファレンスで、Qwen 4の4つのティア — Qwen 4 Max、Flash、Plus、27B — を挙げましたが、それらのいずれについても、重み、識別子、価格、コンテキスト長、ベンチマークのいずれも公開していません。以下のいずれもリリースではありません。これは、単一のドラフトプルリクエストに関する現時点で分かっていることのまとめであり、その中で数値を伴うものはすべて、検証可能なタイムスタンプか、投稿者が自身のPR本文に入力した数値か、公開モデル設定ファイルから読み取った値のいずれかです。

バッチシャーディングサンプリングとは何か、1段落で。

テンソル並列はモデルの重みを複数の GPU に分割する。語彙射影はスタック内で最も幅の広い単一のテンソルであるため、通常は各ランクが語彙の自分のスライスのみを計算し、その後すべてのランクが all-gather を行うことで、各ランクがバッチ内のすべてのリクエストについて完全な logits を保持することになる。シャード化サンプリングはこの交換を反転させる。ランク間で語彙を複製する代わりに、batch をシャード化する。つまり各ランクはリクエストの 1 スライスをサンプリングし、ランク同士は all-to-all を介して語彙スライスを交換する。vLLM 自身の CLI ドキュメントはこのフラグを簡潔に説明している —「各ランクはバッチの一部をサンプリングし、すべてのランクがその全体をサンプリングするわけではない」— そして制約を述べている: --enable-batch-sharded-sampling はデフォルトで False であり、tensor_parallel_size が 1 より大きいこと、最大シーケンス数が少なくとも tensor_parallel_size であること、そして非負の max_logprobs が必要である。そのドキュメントの最後の行が、このプルリクエストが依拠するフックである: 「モデルは compute_logits_local を実装することでオプトインする。」

この機能自体は新しいものではない。vLLM は 2026-08-24、Qwen3.8-Flash-Next の重みが公開されたのと同じ日に、Giancarlo Delfin による PR #50465「[Model Runner V2] batch-sharded sample」としてこれをマージした。当時の動機はメモリとレイテンシだった。完全なターゲットロジットを実体化すると、バッチサイズ ×（投機的トークン数 + 1）× 語彙サイズのオーダーのコストがかかるため、シャーディングによってその割り当てをテンソル並列度の分だけ削減しつつ、サンプラーの top-k と top-p の処理を並列に実行できるようになる。これは実現に向けた第一歩であり、終着点ではない。PR の本文自体も、シャーディングされたドラフトロジットを今後の課題として挙げている。

なぜ3行が仕事のすべてだったのか

これが実際の欠陥です。そして、コードの外からは見えないので、これは良い欠陥です。vLLM の Qwen4Exp 実装は 2 つのクラスとして提供されています。 Qwen4ExpForConditionalGeneration は視覚言語ラッパーです。言語モデルに組み込まれた Qwen3-VL 視覚タワーであり、そして Qwen4ExpForCausalLM はテキスト専用パスです。ラッパーが継承するのは次です： compute_logits_local から Qwen3_5ForConditionalGeneration、これは呼び出しを次に転送します： language_model.compute_logits_local。しかし、ラッパーが指していた言語モデルクラスはそのメソッドを定義していませんでした。

つまり、この2つの経路は異なる状態にありました。Qwen3.8-Flash-Next の視覚言語デプロイではシャード化された経路をたどることができましたが、テキスト専用のデプロイではそれができませんでした。ラッパーが委譲していたメソッドが存在しなかったからです。修正策は1つのメソッドであり、モデルファイルの NVIDIA 版と AMD 版で同一です：

• このメソッドはself.logits_processor(self.lm_head, hidden_states, skip_gather=True)を返します — つまりそのランク自身の語彙シャードであり、gather も、どのランクにおける全語彙の実体化も行いません。

• これはPRが「Qwen3.5やMiniMax M3と同じ3行パターン」と呼んでいるものに従っており、ここは少し立ち止まって考える価値がある。同じリポジトリ内の他の2つのモデルファミリーはすでにオプトインしていたからだ。Qwen4Expは単に、そうしていなかっただけである。

テストファイルは、パッチの誠実さを最も簡単に確認できる場所であり、その限界を最も簡単に見て取れる場所でもある。57行で、NVIDIA と AMD の両方のモジュールに対してパラメータ化されており、モデルをダウンロードしない。ヘルパーは次のものを用いてクラスを構築する：object.__new__、次に代入する：nn.Identity を言語モデルヘッドの代わりに使い、呼び出され方を記録しながら入力を 1 加えたものを返す偽の logits processor をインストールする。最初のテストは、4.0 を入力すると 5.0 が出てくること、および記録された呼び出しが skip_gather=True を伴っていたことを検証する。2 番目は言語モデルを条件付き生成クラスでラップし、委譲が正しく行われることを検証する。それは配線の実際のテストであり、それ以外の何物のテストでもない — カーネルは実行されず、ランク境界は越えられず、関与する GPU の数はゼロである。

これらの事実はいずれも、PRの中で埋もれることなく明記されている。テストファイル自身のdocstringは、Qwen4Expを「CPU専用の小さなテストダブル」と呼んでいる。著者の検証セクションには、自身のmacOS環境ではモデルをまったくインポートできなかったと記されている。手元のtransformersビルドにQwen4ExpConfigが同梱されていなかったためだ。CUDAでの実行はまだ保留中だった。エンドツーエンドのベンチマーク——MLPerfエージェントデータセット、同時20セッション、60分のアーム3本——もまだ保留中だった。MTPドラフター自身のlogits経路は未検証としてフラグが立てられている。LoRAは上流のフラグによってすでに拒否されるため、リグレッションではなくスコープ外である。また、このドラフトがAIの支援を受けて書かれたことを開示する一行もあり、コミットのトレーラーにはClaude Opus 5.5が共同著者として記されている。これは、これほどの規模のスタックでは当然視されるべき種類の開示であり、実際にはほとんどそうなっていないものである。

1.5%の推定値、そしてそれが隣り合う測定値

投稿者の見積もりはnsysトレースである。Qwen3.8-Flash-Next-FP8 上で同時16セッション、テンソル並列8、および8枚の A100-SXM4-40GB カードにまたがるエキスパート並列を構成した条件で、42ミリ秒のステップのうち約1.6ミリ秒、それがおよそ3分の1に削減され、エンドツーエンドで1.5〜2%の改善となる。彼が掲げる数字はその算術だ——42 ms のうち 0.6〜0.8 ms。そこに何が付随しているかに注意してほしい。42 ms はトークン間レイテンシの数値であり、したがって 1.7% の削減はトークン生成時間における 1.7% の削減であって、抽象的なスループットの主張ではない。

誠実な比較は、親機能自身のマージ済み数値に対して行うものです。なぜなら、それらはハードウェアを持つ誰かによってエンドツーエンドで測定されたものだからです。PR #50465 で公開された Speed-Bench 2K/2K の実行では、バッチシャーディングサンプリングによって、7 投機トークン・同時実行数 64 の DSpark 付き DeepSeek V4 が毎秒 2.62 から 2.66 リクエストへと押し上げられました。これはスループット 1.53% の向上で、トークン間レイテンシ中央値は 3.09% 低下し、初回トークンまでの時間は 1.45% 増加しました。8 投機トークンの DSpark を用いた MiniMax M3 では、リクエストスループットが 5.38% 上昇し、TPOT 中央値は 8.33% 低下して 15.61 ミリ秒から 14.31 ミリ秒になりました。そして同じ計画は、それが役立たない場合についても記録しています。同時実行数 4 から 16 では実行結果は横ばいかわずかに悪化し、同時実行数 16 のアームはスループットで 0.54%、アクセプタンス長で 1.89% 低下しました。

そのパターンこそが持ち帰るべき点だ。シャード化サンプリングは、サンプリングが重く、バッチが広いとき——高い同時実行性、多数の投機的トークン、実際に機能している top-k と top-p——に効果を発揮し、バッチが小さく all-to-all 通信が純粋なオーバーヘッドになるほど小さいときには少しコストがかかる。あるモデルがオプトインした場合の1.5%という推定値は、それと整合しており、矛盾しない。5.38%と8.33%という数値は、異なる投機的予算を持つ別のモデルに属するものであり、このPRのモデルには独自の構成、独自の248,320トークン語彙、独自の投機的デコーディング経路がある。

そのどれも監査されていない。親PRの数値は、ある1人のコントリビューターが単一ノードで行ったペア実行のものだ。ここでのスモークテストの数値は、著者が持っていないハードウェア上でのトレースであり、著者が16セッションでしか測定していないと述べているパッチのリビジョンから得たものだ。単一のコントリビューターによる単一構成の測定は、方向性に関する有用なシグナルではあるが、キャパシティプランの根拠としては乏しい。この話題がそもそも書く価値があるのは、小数点以下の数字ではなく方向性があるからだ。

周囲のパッチクラスタがQwen4Expについて示していること

1つのドラフトPRだけでは物語にはならない。物語は、これがマージされた週にQwen4Expが持続的なサービングターゲットになったということであり、そのクラスタ内で最小のパッチこそが、このパターンを読み取れるようにするものだ。2026-10-10までの7日間で、vLLMには同じコントリビューターとその他の人々から以下が取り込まれた。Ampere上のスパースアテンション向けFP8メインKVキャッシュパス（8基のA100でKV容量が1.83倍、4基のRTX 3090で1.87倍、同時実行数16でリクエスト数が約2.7倍になる一方、その代償として単一ストリームのデコードTPOTが約6%高くなる）。テンソル並列1およびエキスパート並列におけるW4A4 MoEパディングの修正。未サポートのAITER FP8 MoE演算からフォールバックし、fp16でサービングするAMDパス。alignモードを通してPLEショートコンボリューション状態を引き継ぐ修正。そして、sm_80上でe4m3バイトをレジスタあたり4つずつアンパックするデコードカーネル。そのうちの1つである、H200 M=4のマージ済みQSA LL-GEMMプランの再チューニングは、2026-10-09にmainへマージされた。

そのリストを全体として読めば、それは具体的なことを語っている。Qwen4Expアーキテクチャ——ベンダーがまだリリースしていないもの——は、Ampere、Hopper、ROCm、そしてfp16フォールバック向けに同時に調整が進められている。それは、人々が実際にダウンロードできるモデルに対して初日からのサポートを提供するプロジェクトにおいてだ。理由は謎ではない。Qwen3.8-Flash-Nextは実在し、ダウンロード可能で、広く使われているモデルであり、Qwen 4が採用するアーキテクチャを基に構築されている。Qwen 4の重みがこのような姿で登場するかどうかは不明であり、ベンダーは何も語っていない。しかし、サービング範囲は公の場で広げられており、それは、噂されている10月から11月の期間とは違い、検証可能な情報である。

アーキテクチャの形状の一部もまた、発表ではなく設定を読む人なら誰でも見られる公開情報である。Qwen3.8-Flash-Next の設定には、48層にわたる248,320トークンの語彙、エキスパート中間幅640でトークンあたり10個のルーティングされたエキスパートと1個の共有エキスパートが活性化する512個のエキスパート、隠れサイズ2,560、100万まで拡張可能と説明されている262,144トークンのネイティブコンテキストが記載されている。これはハイブリッドである。層タイプのリストは3つの線形アテンションブロックと1つのフルアテンションブロックを交互に並べ、フルアテンションブロックは、キーを4分の1に圧縮し2,048位置のバジェットを保持する1ヘッドのインデクサーを使うスパースアテンションパスを用いる。層2には層ごとの埋め込みテーブルがあり、2,000万エントリの語彙を持つn-gram埋め込み——これがこのクラスターの他のパッチがホストステージングに忙しい47.7 GiBのテーブルだ——と、投機的デコーディング用の1層MTPヘッドがある。モデルカード自身の要約は「125B、うち6B活性化、加えて51Bのn-gram埋め込みと4BのMTP」である。248,320エントリの語彙があるからこそ、ロジット射影はそもそもシャーディングする価値がある。

これによってあなたにとって変わらないもの

正確さが重要だ。これほど密度の高いパッチ群は、まるでローンチのように読めてしまうからだ。上記はいずれもまだマージされていない。そのうちの一つ——Ampere FP8 KV cache の作業——は、vLLM の CI に A100 がないため、CI 上で明示的に検証されていない。今日インストールできるリリース済みの vLLM バージョンで、Qwen4Exp の sharded-sampling opt-in を備えたものは存在しない。これらの変更のいずれかの下での Qwen3.8-Flash-Next のサービング挙動についての独立したベンチマークは存在しない。上記で引用した数値はすべて PR 本文に由来しており、したがって投稿者による報告であり、第三者がその実行を再現していないという意味で未監査である。そして、この記事のきっかけとなった PR の見出し数値は 1.5% であり、これはサービングスタックにおける実際の改善ではあるが、モデル選択を変える理由にはならない。

判断を変えうるのは、完全かつ監査済みのサービング実行であり、それはまだ存在しない。Qwen3.8-Flash-Next について実際に存在するペーシング測定値は、これらのパッチの完全に外側にある。このモデルは Artificial Analysis で Intelligence Index 40 と評価されており、同程度の規模のオープンウェイトモデルの中央値18をはるかに上回っている。そしてその数値は、ここで論じたすべてとは独立している。

今日呼び出せるもの、そしてルーティングの観点

ここまで読んできて、モデルを自前で計装するのではなくホスト型モデルを使いたいという人にとって、話が実用的になるところです。Qwen3.8-Flash-Next は OrcaRouter のカタログにはありません。当社がルーティングする 205 モデルの一つではなく、ここにはそのホスト型エンドポイントも存在しません。しかし、これがプレビューしている本番版の兄弟モデルはこちらです：qwen/qwen3.8-flash。これは Qwen3.8-Flash の正式リリースであり、ベンダー自身のモデルカードによればプレビューよりも多くの機能を備え、デフォルトで 100 万トークンのコンテキストや組み込みツールを含みます。入力トークン 100 万あたり $0.15、出力トークン 100 万あたり $0.47 で利用でき、プロバイダの定価のまま提供され、マークアップは一切加えられていません。同じファミリー内で規模を比較すると、qwen/qwen3.8-27b は $0.33 と $2.40、そして qwen/qwen3.8-max は $2.00 と $6.00 — すべて 1 つのキーで利用できます。

未公開のアーキテクチャを扱う記事では、これがいつも以上に重要になる理由が2つある。1つ目はスイッチングコストだ。Qwen 4 が存在する前に、スパースアテンションモデルが自分のトラフィックでどう感じられるかを測りたいなら、比較すべき相手は定価の qwen/qwen3.8-flash だ。そしてルーター経由で行えば、計測しているモデルとフォールバック先になり得るモデルが同じエンドポイント、同じSDK、同じキーの裏側にあり、2つ目の契約に署名する必要もない。2つ目は、このパッチ群におけるあらゆるサービング変更がセルフホスト型 vLLM を対象としていることだ。8台の A100 を動かしていなければ、1.83倍の KV 容量や 1.5% のサンプリング改善は、読んで知るものであって、手に入るものではない。ルーティングされたエンドポイントは、これをビルドステップなしで実現した形だ。プロバイダーが劣化したときの自動フェイルオーバー、そして測定に使える自前のハードウェアがある場合に、ホスト型の呼び出しとセルフホスト型の呼び出しを単一のエンドポイントに並べて配置できるルーティング DSL を備えている。

絶対にすべきでない唯一のことは、この記事をQwen 4を待つ理由として読むことだ。日付はない。価格もない。実物のウェイト数もない — 上の数字は製品ではなくプレビュービルドについてのものだ。存在するのは、今のところプレビュー形式でしかダウンロードできないアーキテクチャのために、公開の場で準備が進められているサービングスタックだ。

短いバージョン

あるモデルファイルのテキスト専用パスと視覚言語パスの間のギャップを埋める3行は、それ自体ではニュースにはならない。それは、誰かにレビューする時間さえあればマージコミットの中に埋もれてしまう類のパッチであり、より大きな変更に取り込まれるか、あっさりクローズされてもおかしくない——PR上で引用されているvLLMボット自身のエージェントガイドラインは、AI支援を受けたコントリビューターに対し、有意な利点が乏しければ自身の作業をクローズするよう指示しており、1.5%という数字はまさにその問いを招く。これが注目に値するのは、それが記録しているもの、すなわち、2000万エントリのn-gramテーブル、トークンあたり10エキスパートが稼働する512エキスパートのMoE、線形アテンションと圧縮スパースアテンションのハイブリッド、投機的ヘッド——それらすべてが、それを載せる製品が存在する前に、NVIDIAとAMD、AmpereからHopperにわたってチューニングされているという事実だ。Qwen4のサービングの想定範囲に関心があるなら、その実際の仕様が現在生きているのはPRの本文の中だ。今日モデルを呼び出したいなら、実際にそこにあるのはQwen3.8-Flashだ。

200以上のモデルに対応する1つのAPI、自動フェイルオーバー、ルーティングDSL。OrcaRouterのモデルカタログを見る