Qwen 4リーク：SGLangのホストステージングPRが、47.7 GiBのPLEテーブルがどのように単一GPUに収まるのかを明らかにする

自分でサービングできるモデルかどうかを決める数字は、Qwen 4の場合、そのパラメータ数ではない。それは47.7 GiB —— Qwen4アーキテクチャに付随し、重みとは別に存在するn-gram埋め込みテーブルのサイズであり、モデルがデコードしている間はどこかに置かれていなければならない。2026年9月18日にSGLangリポジトリで開かれた、タイトルが[Qwen4-Exp] ファイルバックドPLEのためのホストステージングを追加というプルリクエストは、そのテーブルが、マシンがそもそも実行できるようになるために必要なRAM量を左右するのをやめさせる試みだ。Qwen 4はまだ未リリースで、モデルカードも重みもカタログ登録も日付もない。このアーキテクチャを実体化した唯一の出荷済みモデルはQwen3.8-Flash-Next、2026年8月26日に公開されたオープンウェイトのプレビューであり、その設定はmodel_type=qwen4_expを宣言している —— プルリクエストにその名前を与えているのと同じ文字列だ。その本番向けの兄弟であるQwen3.8-Flashは、API呼び出し元が今日実際に使えるバージョンだ。この記事でQwen 4について述べていることはすべて、そのプレビューとエンジンのコードからの推測である。プルリクエストはオープンで未マージなので、すべてを出荷済みの機能ではなくシグナルとして読んでほしい。

その信号が実際に何であるか

プルリクエストsgl-project/sglang#40235は、立ち上げられたものでもなく、マージもされていません。1つのコミットの上に置かれており、投稿者Dev-Jahnによって開かれ、task/ple-host-stagedというブランチをSGLangのメインラインにマージするものです。9人のコードオーナーにレビューが依頼され、その全員が待機中と表示されているため、これがメインに入るまでには少なくとも1件の承認レビューが必要です。3つのCIジョブ — ベースPRテスト、追加PRテスト、AMD ROCm実行 — が、そのオープンなコミットで失敗しています。これは進行中の大規模なエンジン変更ではごく普通の状態であり、また、このPRの面白いところが「マージされるかどうか」ではなくその作者がそれを主張するために何を測定しなければならなかったかにある理由でもあります。説明文には、テストを含めて約1,400行の追加行と、このアーキテクチャを単一のGPUで実行することについて誰かが公表した中で最も具体的な公開データであるベンチマーク表が含まれています。

なぜテーブルがすべてを物語るのか

Per-Layer Embeddings は、この世代の構造上の異例である。通常のモデルが先頭に1つのトークン埋め込みを置くのに対し、Qwen4 の設計では大規模な n-gram テーブル——バイグラムとトライグラムを、トークナイザーの語彙よりはるかに大きい語彙にハッシュ化したもの——を保持し、スタック全体にわたってそこから層ごとの埋め込みルックアップを供給する。Alibaba 自身のプレビュー資料は、n-gram コンポーネントを 125B パラメータの MoE 本体に加えた数百億パラメータ規模と説明している。公開チェックポイントに対するコミュニティの分解調査では、テーブルファイルは 47.7 GiB とされている。これらの数値は独立した再現ではなく、ベンダーおよびコミュニティの情報源に由来しており、プレビューのテーブルと Qwen 4 が出荷するものとの正確な関係は不明である。

疑いようがないのは、エンジニアリング上の帰結だ。すべてのデコードステップで参照しなければならない 47.7 GiB のサイドテーブルは、VRAM の片隅にそっと押し込んでおけるようなものではない。96 GB のカードでは KV キャッシュと直接競合し、より小型のカードではそもそも収まらない。だからこそ、8月下旬にこのプレビューへの day-0 サポートを立ち上げた SGLang は、その後3週間、モデル本体ではなく、この単一のデータ構造について次から次へと pull request を作成してきた。

このPR以前は何が壊れていましたか

SGLang にはすでにテーブルを保持する方法が 2 つありましたが、どちらにも厳しい難点がありました。

• ピン留めはテーブル全体をホストRAM上に常駐させ、そこから読み取ります。確実に動作し、高速で、ホストメモリ要件が絶対的になります — これより小さいバージョンは存在しません。

• File-backedは、以前に別のプルリクエストで追加されたもので、テーブルをスパースファイルに保持し、gather カーネルがそのマッピングを直接読み取れるようにします。したがって、そのうちどれだけが常駐するかはオペレーティングシステムのページキャッシュが決めます。難点はハードウェア側にあります。この直接読み取りの経路では、GPU が cudaDevAttrPageableMemoryAccessUsesHostPageTables を報告することが必要です — これは当該 PR 自身のテキストが「GB10 クラス」と言い換えている機能です。これを持たない GPU では、ファイルバックエンドはきっぱり拒否され、pinned だけが残された選択肢となります。

そこに生じる隔たりは理論上のものではない。同じコードパスに対して別途提出された報告書は、2 台の RTX 3090 を使うユーザーについて、テーブルのランクごとの取り分が使用可能メモリ 23.56 GiB に対して 23.84 GiB となり、0.28 GiB 不足していた一方、ホスト RAM は 188 GiB も空いていたことを記録している。その構成では、ファイルバックエンドはハードウェアチェックによって拒否され、通常の CPU-offload フラグは PLE offload フラグと組み合わせると例外を送出する。300 メガバイト不足しているのに 180 ギガバイトも余っているというのは、まさにこのプルリクエストが取り除くために存在する問題の形である。

ホストステージングの変更点は何ですか

PR が追加する仕組みは、ファイルとデバイスの間のステージング層です。GPU にホストページを逆参照させる代わりに、CPU 側のコンポーネントがローダーの既存のマッピングを通じて必要な行を読み取り、カーネルにそれらのページを事前に取り込むよう助言します。環境変数 SGLANG_QWEN4_PLE_FILE_PREFETCH は、それなしで測定したい場合にこの助言を無効にします。各 PLE 層には、8,192 行のピン留めされたバッファが 2 つ — FP8 ではそれぞれ約 1.25 MiB — と、1 つのワーカーが割り当てられます。一方のバッファがデバイスへコピーされている間に、行はもう一方のバッファに集められるため、収集と転送は直列化せずにオーバーラップします。N-gram 識別子はデバイス上ではなくホスト上でハッシュ化されます。グラフリプレイは、各リプレイの前に準備呼び出しを受け取り、起動スレッドは前のステップを待機します。

その最後の細部がコストであり、PRはそれを率直に述べている。およそデコードステップごとに0.5～1ミリ秒の追加が固定パスに対して発生する。それ以外はすべて見返りだ。単一のRTX PRO 6000 Blackwell（96 GB）、377 GiBのRAMを搭載したAMD EPYCホスト、CUDA 13.2上で、Qwen3.8-Flash-Nextの公開FP8およびNVFP4チェックポイントを使用して測定した：

• ホストページキャッシュ、FP8 TP4/EP4 — 上限なしでピン留めした場合は71 GB、64 GB上限では49 GB、32 GBでは15 GB、24 GB上限では6 GB

• デコードレイテンシ、同一実行 — 同時実行数1で固定した場合、トークンあたり8.62 ms。一方、3つの上限付きファイル実行では9.16 / 9.20 / 9.12 ms

• 並行度 16 — 16.54 ms（固定時）に対し 17.62 / 17.85 / 17.37 ms（上限あり時）、つまり 893 トークン/秒から 827–840 への低下

• プリフィルスループット — 8k固定時は毎秒620トークン、上限設定時は624 / 630 / 631。32kでは1,347に対し1,358 / 1,359 / 1,361

• NVFP4 TP2 — 固定で69 GB、ファイルバックエンドでは32 GBの上限で24 GB、8.87 ms 対 9.18 ms

• シングルGPU NVFP4 — 64 GBの上限でピン留めは69 GB 対 51 GB、6.44 ms 対 6.73 ms

• それが凌駕する代替手段 — そのGPUでホストメモリ管理を介して同じファイルを読み取った場合、同時実行数1で10.8 ms、同時実行数16で46.5 msとなり、PRはこれをその同時実行数におけるピン留めレイテンシの2.8倍と説明している

精度面は問題なしと報告されている。FP8 TP4 上で、256トークンの8つのプロンプトにわたる決定論的グリーディ出力は、pinned パスと file パスの間でトークン単位で同一だった。また、64 GB 上限では GSM8K が pinned で 97.6%、file で 98.0% だった——その6問分の差を、著者はオフロード経路ではなく実行ごとのばらつきに帰している。これらの数値はすべてプルリクエスト作成者自身によるもので、1台のマシンで1回測定されただけであり、誰も再現していない。

PRが認めるコスト

このプルリクエストを公正に読むなら、それが拒否していることも含まれます。いくつかの実行モードは、黙って劣化させるのではなく構築時に拒否され、各拒否はピン留めされたバックエンドをフォールバックとして明示します。prefill CUDA グラフ、データ並列アテンション、prefill-decode 多重化パス、two-batch オーバーラップ、DLLM デコードグラフ、compact ragged verify グラフはすべて対象外です。同じく重要なのは、新しいフラグも新しいユーザー向けスイッチも追加しないことです。staging path は、以前はまったく使えなかったハードウェア上で file backend が行う処理です。また、精度実行には著者が自ら進んで述べる注意点があります。上限付き実行ではテーブル全体を保持できませんでした。テーブルは 47.7 GiB で、上限は 24 GB まで下がるため、テーブル全体に対して真にフラットで予測不能なアクセスパターンを持つワークロードは測定されていません。

なぜこれが特にQwen 4にとって重要なのか

エンジンの細部を取り除けば、パターンは読み取れる。Alibabaは8月26日、フルファミリーの登場に先立ち、オープンソースコミュニティがランタイム、量子化、推論エンジンを準備するための指示を添えたアーキテクチャプレビューを公開した。SGLangはそれを行い、その後3週間、このアーキテクチャのデプロイを厄介にする唯一のコンポーネントについてプルリクエストを出し続けた。予測として読むなら、それはQwen 4がベンチマークで何をできるかではなく、Qwen 4があなたのハードウェアに何を求めるかについての表明だ。

それはタイムラインに関する疑問も際立たせる。Qwen 4はまだリリースされておらず、それをめぐる9月の憶測は、杭州で9月22～24日に開催されるAlibabaのApsara Conferenceを指している――過去のQwen世代が発表された会場だ。そのいずれも確認されておらず、前回のプレビューサイクルから見えるパターンでは、アーキテクチャのプレビューが完全なファミリーより数週間ではなく数か月先行する。その会議の3日前にプルリクエストが開設されることは示唆的ではあるが、それ以上のものではない。

読者にとってこれが何を意味するかを正直に要約すると、こうなる。Qwen 4 は存在せず、Qwen3.8-Flash-Next は存在する。そして後者は、前者を動かすのにいくらかかるかを教えてくれる。47.7 GiB の表が実効フットプリントで縮小し続けるなら——そして3週間分のプルリクエストは、それに熱心に取り組んでいることを示している——Qwen 4 ファミリーを展開する際のハードルは、プレビューのローンチ週が示唆していたよりも低い。

これで今日実際にできること

このプルリクエストの内容はまだ main では利用できず、対象となっているモデルも API 経由で呼び出せるものではありません。オープンウェイトの Qwen3.8-Flash-Next チェックポイントはセルフホスティングの話です。重みを取得して自分でホスティングするもので、ここで扱っているのはファイルベースの PLE パスです。ここではルーティングされていません。のは本番用バリアント、すなわち Qwen3.8-Flash で、qwen/qwen3.8-flash として利用でき、入力 100万トークンあたり $0.15、出力 100万トークンあたり $0.47、コンテキストは 100万トークンで、テキスト・画像・動画の入力に対応しています。また、より大規模な Qwen3.8-Max は $2.00 と $6.00 です。

今週何をすべきか判断しようとしている読者にとって、役に立つのはその区別です。プレビューは自分で実行する研究であり、served variant は同じアーキテクチャの本番経路で、エンドポイント一つ分の距離にあります。OrcaRouter はプロバイダの定価を0% マークアップでそのまま通すため、そのエンドポイントでのベンダー価格の変更は次の請求サイクルではなく当日に反映され、キー上のすべてのモデルは、ベンダーごとに個別の契約・SDK・認証情報を用意するのではなく、一つの OpenAI 互換ベース URL から到達できます。これほど若いアーキテクチャ——エンジンの作業がまだ毎週着地しており、ロードマップも公開されていない——では、プロバイダ間の自動フェイルオーバーが、単一プロバイダの稼働率に本番経路を賭けることなく served variant に依存するための実用的な方法です。ここまではすべて、今日呼び出せるモデルについての話です。Qwen 4 については何も述べていません。それはそれらの中にはありません。

私たちがまだ知らないこと

Qwen 4が同じ表を同じサイズで提供するのかどうか。そのプルリクエストがそもそもマージされるのかどうか——CI実行は3件失敗しており、レビューはまだ1件もない。1ステップあたり0.5～1ミリ秒のペナルティが、著者の低並行構成の外でも持ちこたえるのかどうか。そして、Alibabaが9月22日のApsaraで何か発言するのかどうか。現在の証拠に基づけば、Qwen 4について最も安全に結論できるのは、それがどんなスコアを出すかではなく、それを適合させるためだけに業界がどれほどの仕組みを築いているかだ——そしてそれは、モデルがどのカタログにも名前を載せる前に知っておく価値のあることでもある。