Qwen 4 リーク：SGLang が Qwen4Exp Prefill をシャード化し、TTFT を 18% 高速化、GPU あたり 1 GiB を回収

本日2026年10月8日03:47 UTCにSGLangリポジトリでオープンされたプルリクエストは、これまでいかなるQwen 4の発表も生み出せなかったもの、すなわち数字を約束している。そのタイトルはfeat(qwen4-exp): GRとPLEのためのLayerNormシーケンス並列化を有効化であり、オープンウェイトのQwen3.8-Flash-NextチェックポイントをFP8で実行する4基のH20 GPU上で、その作者は、32K入力で17.7～18.4%、235K入力で14.6～14.7%の初回トークン生成時間の短縮、GPUあたり約1ギガバイトのピークメモリの削減、さらに最大22%の入力スループット向上を報告している。Qwen 4自体は——ベンダーが2026年9月22日に杭州で開催されたApsaraカンファレンスで名を挙げながら出荷しなかったファミリーであり——依然として未リリースで、重みも識別子も価格も存在しない。今日Qwen4Expアーキテクチャを具現化している唯一のモデルは、2026年8月26日に公開されたQwen3.8-Flash-Nextであり、そのマネージド版であるQwen3.8-Flashこそ、API呼び出し側が実際に利用できるバージョンだ。したがって、以下に続く内容はまさにそのとおりに受け取ってほしい。あるエンジニアによるペア測定の結果が、オープンでドラフトの、未マージのプルリクエストに添えられているのであり、それはまだ存在しないモデルファミリーのサービング特性についてのものだ。

まず出典確認から。これはリーク記事であり、その区別が実際に効いてくるからだ。シグナルは sgl-project/sglang#43048、2026-10-08 03:47 UTC に GitHub アカウント shiyang814-cpu によって開かれ、最終更新は 03:55 UTC、依然として ドラフト と表示され、承認レビューは記録されておらず、マージもない。これは6つのファイルを変更する — 2つのテストファイル、Qwen4Exp モデルファイル、LayerNorm-SP モジュール、レイヤー境界ファクトリ、引数グループフック — +345 行と −50 行。以下のパフォーマンス数値はすべて PR の説明に由来し、著者自身による対になる OFF/ON 測定であり、誰によっても再現されていない。ブランチ先端のリビジョンに対する3回の CI 実行は失敗とマークされている。ここにあるものはどれも出荷済みの機能ではない。

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

シーケンス並列性はモデルの変更ではなく、新しい機能でもありません。それは、いくつかの層が算術を行う場所を配線し直すものです。その系譜はMegatron方式のシーケンス並列性——arXiv:2205.05198の手法——にまで遡り、SGLangはすでにそれを搭載しています。モジュール自身のdocstringが、再⽤している仕組みを説明しています。すなわち、純粋なテンソル並列性のもとでは、行並列のall_reduceは代数的にはreduceとそれに続くall_gatherになります。これら2つのcollectiveは、置き換える単一のall_reduceとまったく同じバイト数を移動するため、その演算を分割しても通信量は一切増えません。それによって得られるのは、正規化と残差の領域をsequence-shardedなアクティベーション上で実行できる自由度です。つまり、各テンソル並列ランクがトークン行の1/tpを保持する形になり、長いコンテキストのprefillが維持し続けなければならない一時的なアクティベーションメモリを削減します。

このプルリクエストが行うのは、検証済みのアーキテクチャで用いられていたその既存のパスを Qwen4Exp アーキテクチャへ拡張することです。プリフィル中、Gated Residual と Per-Layer Embedding のアクティベーションは、TP グループ全体でトークン次元に沿ってシャーディングされたままになります。アテンションの前、GDN の前、QSA の前、そして Mixture-of-Experts ブロックが実行される前に、トークン行全体が all-gather で戻され、既存の全行テンソル並列計算が共有フォールバックの背後で変更なく実行され、その後 reduce-scatter が部分的な寄与を合算して各ランクのシャードを復元します。デコードは新しいパスに一切触れません。この機能は、すでに存在するオプション — --enable-layernorm-sp — を通じて利用でき、Qwen4Exp 固有のフラグは不要です。また、このフラグを指定しない場合、コードは以前とまったく同じように動作します。

なぜQwen4Expがこれを必要とするアーキテクチャなのか

これがQwen4Expにとって特に重要であり、すべてのモデルに等しく当てはまるわけではない理由は、アーキテクチャ自身の設計にある。Qwen3.8-Flash-NextはGated Residual射影をすべてのトークン行に各デコーダ層で適用する — この構成では、48層にわたって4本の残差ストリームとボトルネックランク320が宣言されている — さらにPer-Layer Embeddingが、その上に2つ目の、複製されたトークン行単位の射影を追加する。テンソル並列では、これらの演算はどちらも各ランク上でまったく同じように複製される。というのも、どちらも自ら分割を強制するTPシャード化された重み行列を持たないからだ。それらのトークン次元をシャーディングすれば、複製された作業を直接取り除くことができる。PRの動機セクションが述べているように、それは既存のテンソル並列レイアウトと、アテンション、GDN/QSA、MoEのリダクションセマンティクスを保ったまま行われる — まさにこの点が、この変更を「巧妙」ではなく「安全」なものにしているのである。

読者にとってそれが何を意味するのか、率直に言っておく価値がある。このPRの興味深い点は、SGLangが速くなっていることではない。Qwen4アーキテクチャが層ごとのコストを抱えており、それがトークン数に応じて増えるのであって、パラメータ数に応じてではない。そしてそれらのコストこそが、長いプリフィルで効いてくる。これは設計上の指紋であり、スペック表が決して言及しない類のものだ。

測定されたデルタ

著者のベンチマークでは、1つの構成を固定してフラグを切り替えている。NVIDIA H20 GPU 4基、Qwen3.8-Flash-Next-FP8、テンソル並列4およびエキスパート並列4、チャンク化プリフィルサイズ8192、FlashInferの線形アテンションのプリフィルおよびデコードバックエンド、OFFとONで同一のサーバー構成、OFF → ON → OFF → ON と交互に行うサービス再起動、ウォームアップリクエスト付きの固定トークン入力である。以下のすべての数値はそのセットアップによるもので、未監査である：

• 32K入力、バッチサイズ1 — TTFTは17.72～18.36%改善、エンドツーエンドレイテンシは約16%、入力スループットは約20%

• 入力235K、バッチサイズ1 — TTFTが14.63～14.71%改善、エンドツーエンドレイテンシは約14%、入力スループットは約17%

• 32K入力、バッチサイズ4 — TTFTが18.74%改善、エンドツーエンドレイテンシ18.14%、入力スループット22.14%

• ピークメモリ — GPUあたり約1.0 GiB削減

• デコード、バッチサイズ1 — 出力トークンあたりの時間は実質的に変わらず

最後の行は2回読むべき行であり、著者はその理由を率直に明かしている。つまり、この最適化はプリフィルでのみ有効になるため、単一ストリームのデコードはそこから何も得られない。バッチ4でのトークンあたりの所要時間の改善は、見られる場合でも、より高速なデコードカーネルではなく、同時実行される長いプリフィルによるスケジューリング遅延の低減を反映したものだ。これがスループットの話だと思っていたなら、そうではない — これは初回トークンまでのレイテンシとメモリの話であり、その2つこそが235Kトークンのリクエストをそもそも処理可能かどうかを決める制約なのだ。

彼らが最初に修正しなければならなかったレイアウトのバグ

プルリクエストで最も情報量が多いのは、高速化の表ではない。PLE の物理行レイアウトに関する節だ。というのも、そこには Qwen4Exp のサービングスタックが依然として間違えている点が示されているからだ。

Per-Layer Embedding は固定された物理的な CUDA グラフバケット上で動作するが、そのバケット内の行のうち実際のトークンを保持できるのは先頭の一部だけである。したがってパディングはシーケンスがシャード化される前に適用しなければならず、後ではいけない。235K トークンのリクエストの最終チャンクにおいて、著者による数値は、TP 4 での 8,192 行の物理バケット内で処理された 5,624 トークンであり、唯一正しいレイアウトは、rank 0 が 2,048 行の有効行を保持し、rank 1 が 2,048 行の有効行を保持し、rank 2 が 1,528 行の有効行に加えて 520 行のパディング行を保持し、rank 3 が 2,048 行のパディング行を保持するものである。5,624 の処理済み行を先にシャード化するという、一見明白な実装は、グローバルに連続した有効範囲の間にパディングを挿入し、結果を破壊してしまう。著者は、実際の 235K の OFF/ON テストでは、このレイアウトが修正された後になってようやく同一の 16 トークンの greedy 出力が得られたと記録している。

それは、大きな含意を持つ小さなディテールだ。SGLang の PLE パスはごく最近追加されたものだったため、この形のトークン順序バグがまだ到達可能だった。そして、それを見つけた人物はシーケンス並列拡張を書いていた。このアーキテクチャに対する Day-zero のサービングサポートは完成しておらず、公開の場でコントリビューターたちによって、レイアウトを一つずつ、活発に構築されている最中だ。

あなたに課されるコスト：制約

一部のデプロイにしか役立たないフラグは、どれに役立つかを把握して初めて有用になる。PR はその要件を明示的に述べており、要件から外れる構成は、黙って機能低下するのではなく引数検証中に失敗する：

• テンソル並列サイズは 1 より大きくなければなりません — 単一 GPU でのデプロイでは何も得られません。シャーディングするランクが存在しないためです

• エキスパート並列サイズはテンソル並列サイズと等しくなければなりません

• パイプライン並列サイズは 1 と等しくなければなりません

• データ並列アテンションは無効にする必要があります

• 投機的デコーディングは無効化する必要があります

最後の制約は、その背後に実際の意思決定が存在する唯一のものだ。トークンあたり約6Bのパラメータを活性化するスパースモデルにとって、投機的デコードはデコードを高速化する数少ないテコのひとつであり、この機能はプリフィルでの利得と引き換えに、そのテコを明示的にオフにする。ワークロードが長いプロンプトで短い出力——ドキュメントやコードベースの分析、動画の要約、一度だけ読む大きなコンテキスト——であれば、このトレードオフは素直に良い。ワークロードが短いプロンプトで長い生成であれば、あなたを助けていたものを手放し、自分には当てはまらない数値を買っていることになる。エキスパート並列＝テンソル並列という要件も、もうひとつ注目すべき点だ。つまり、MoEのシャーディング形状がTPの形状と正確に一致していなければならず、それによって、それ以外なら合理的ないくつかのマルチノード構成が排除されてしまう。

Qwen 4のタイムラインについてこれが示していること

この差分を別の角度から読むと、カレンダーが見えてくる。SGLangのLayerNorm-SPモジュールは、現在のmainブランチにおいて、この機能が検証済みであるアーキテクチャの明示的な許可リストを備えており、本稿執筆時点でその許可リストに含まれるエントリはちょうど1つ、Qwen3ForCausalLMだけである——フラグを渡せば、それ以外のすべてのアーキテクチャは構築時に拒否される。したがって、Qwen4Expをその経路に加えることは、成熟した抽象化への微調整ではない。Qwen4アーキテクチャが、それより何世代も前に生まれていた最適化の上に初めて載せられることになるのだ。

それを公開記録と照らし合わせると、全体像は整合している。ベンダーは2026-09-22に、Qwen 4が訓練中であると発表し、4つのティア名 — Qwen 4 Max、Qwen 4 Flash、Qwen 4 Plus、Qwen 4 27B — を予告したが、いずれにも仕様は添えられていなかった。同じアーキテクチャを共有するオープンウェイトのプレビュー、Qwen3.8-Flash-Nextは、2026-08-26以降ダウンロード可能だ。その後の3週間で起きていることは、「訓練中」と「ローンチ」の間に期待されることまさにそのものだ。つまり、エンジン作者たちがランタイムを調整し、初日サポートが名目上ではなく実際に機能するようにしている。2026-10-08の朝に開かれ、今もドラフトのままの、そのアーキテクチャ上でサービング最適化を機能させるプルリクエストは、Qwen 4が提供可能になるまでどれだけ近いかについて、誰かが口にしたどんな日付よりも良いシグナルだ。また、これは強調しておくが、リリース日では決してない — フラグはデフォルトでオフ、変更は未マージ、そしてそれがベンチマークしているモデルはプレビューであって、Qwen 4ではない。

今日電話できる相手

とはいえ、それらのどれも、今日の午後に実際に利用できるものを変えるわけではありません。Qwen3.8-Flash-Next は実在します。その重みは Hugging Face にあり、セルフホストもできます。ただし、当社のカタログには掲載されていません。そうでないふりをするつもりもありません。当社が提供しているティアは qwen/qwen3.8-flash で、同じ Qwen4-preview アーキテクチャを実行するマネージドの兄弟モデルです。100万トークンのコンテキストウィンドウを持ち、テキスト、画像、動画の入力に対応し、価格は入力100万トークンあたり $0.15、出力100万トークンあたり $0.47、キャッシュ読み取り100万トークンあたり $0.0184 です。これは 0% のマークアップでそのまま適用される定価なので、ベンダーが価格を動かせば、中間業者が価格表を再公開するのを待たずに、請求書の数字も同じ日に動きます。

ここでルーティングレイヤーを気にかけるべき、もう一つのあまり明白ではない理由がある。この記事のすべては、実証されていないプレビューとドラフトパッチについてのものだ——本番の経路をそれに賭けることなく試したい類のものだ。そのためにフェイルオーバーがある。プレビューを、すでに信頼しているモデルと同じキーの背後に置き、あなたのトラフィック上でどう振る舞うかを見守り、プロバイダーがぐらついたりエンドポイントが存在しなかったりしたときには、リクエストを既知の正常な経路へフォールスルーさせるのだ。200以上のモデルに対応する1つのAPI、1組の認証情報、新しいアーキテクチャがあなたの関心に値するかどうかを知るために2つ目の契約に署名する必要はない。

ここから注視すべき点が2つあるが、どちらも予測できない。第一は、このパッチがそもそもマージされるかどうかだ。これはドラフトであり、リポジトリにこれまで一切の履歴がないコントリビューターアカウントによる6ファイルの変更に対して、CIが3回失敗している。加えて、PLEの行レイアウト作業に見られる流動性から、著者がまだ試行錯誤を続けていることがうかがえる。第二は、許可リストが拡大するかどうかだ。もしQwen4Expが検証済みアーキテクチャとしてQwen3ForCausalLMに加われば、これはもはやリークではなくなり、Qwen4ファミリーのモデルが長いコンテキストで提供される既定の方法になる。そのどちらかが実現するまでは、18%を、ランタイムが向かおうとしている先についての約束として扱うべきであり、借りられる数値として扱うべきではない。