Qwen 4 外洩：SGLang 將 Qwen4Exp 預填充分片，讓 TTFT 加快 18%，並在每顆 GPU 上回收 1 GiB。

今早 2026-10-08 03:47 UTC，SGLang 儲存庫中開啟了一份 pull request，承諾了一件迄今任何 Qwen 4 發表都未能帶來的事：一個數字。其標題為 feat(qwen4-exp): enable LayerNorm sequence parallelism for GR and PLE，而在四張 H20 GPU 上以 FP8 執行開放權重的 Qwen3.8-Flash-Next 檢查點時，其作者回報首 token 時間在 32K 輸入下改善 17.7–18.4%，在 235K 輸入下改善 14.6–14.7%，每張 GPU 約回收 1 GB 峰值記憶體，輸入吞吐量最多提升 22%。Qwen 4 本身——亦即廠商在 2026-09-22 於杭州雲棲大會上點名卻未發布的系列——至今仍未推出，沒有權重、沒有識別碼，也沒有價格。今日唯一具體實現 Qwen4Exp 架構的模型是 2026-08-26 發布的 Qwen3.8-Flash-Next，而它的託管版同系列模型 Qwen3.8-Flash 才是 API 呼叫者真正能觸及的版本。因此，請以下述內容的本來面目來看待它：一位工程師的配對量測結果，附在一份公開、草稿、尚未合併的 pull request 上，談的是一個尚不存在的模型系列其服務效能邊界。

先講來源，因為這是一則外洩消息，而這個區分確實有實質作用。這項訊號是 sgl-project/sglang#43048，由 GitHub 帳號 shiyang814-cpu 於 2026-10-08 03:47 UTC 開啟，最後一次更動時間為 03:55 UTC，且仍標記為 草稿，沒有記錄到任何核准審查，也未合併。它變更了六個檔案——兩個測試檔、Qwen4Exp 模型檔、LayerNorm-SP 模組、一個層邊界工廠，以及一個 argument-group 掛鉤——增加 +345 行、刪除 −50 行。以下每一項效能數據都來自 PR 說明，是作者本人配對的 OFF/ON 測量結果，且尚未被任何人重現。分支頂端修訂版上的三次 CI 執行均標記為失敗。這裡沒有任何已正式推出的功能。

拉取請求實際上變更了什麼

序列平行不是模型變更，也不是新能力。它是把少數幾層做算術的位置重新接線。它的血統可追溯至 Megatron 風格的序列平行——也就是 arXiv:2205.05198 的那個技巧——而 SGLang 早已搭載：該模組自己的 docstring 說明了它所重用的機制，即在純張量平行下，一個列平行的 all_reduce 在代數上等同於一個 reduce_scatter 接著一個 all_gather。由於這兩個集合通訊所搬移的位元組與它們所取代的那個單一 all_reduce 完全相同，以這種方式拆分運算完全不會增加額外的通訊量。它換來的是自由，讓正規化與殘差區域能在 sequence-sharded 激活值上執行——每個張量平行 rank 持有 token 列的 1/tp——這削減了長上下文 prefill 所需持續保留的暫態激活記憶體。

這個特定的 pull request 所做的，是將那條既有路徑從當初驗證所用的架構，延伸到 Qwen4Exp 架構。在 prefill 期間，Gated Residual 與 Per-Layer Embedding 的激活值會沿著 token 維度在 TP 群組中維持分片狀態。在 attention 之前、GDN 之前、QSA 之前，以及 Mixture-of-Experts 區塊執行之前，完整的 token 列會全部被 all-gather 回來，既有的全列張量平行運算會在共用回退機制之後原封不動地執行，接著由 reduce-scatter 加總各部分的貢獻，並還原每個 rank 的分片。Decode 完全不會觸及這條新路徑。此功能是透過既有的選項——--enable-layernorm-sp——來啟用，沒有 Qwen4Exp 專屬的旗標；而在沒有這個旗標時，程式的行為與先前完全相同。

為什麼 Qwen4Exp 正是那個需要這項技術的架構

這件事之所以對 Qwen4Exp 特別要緊、而非對每個模型都同等要緊，原因就在架構本身的設計裡。Qwen3.8-Flash-Next 會對所有 token 列於每個解碼器層套用 Gated Residual 投影——該配置宣告了四條殘差串流，以及在 48 層之間瓶頸秩為 320——而 Per-Layer Embedding 還會在其上再疊加第二個被複製、逐 token 列進行的投影。在張量平行之下，這兩項運算在每個 rank 上都會被完全相同地複製，因為它們本身沒有 TP 分片的權重矩陣來迫使切分。將它們的 token 維度分片可直接移除這份被複製的工作，而正如該 PR 的動機一節所述，這是在保留既有張量平行佈局以及注意力、GDN/QSA 與 MoE 的歸約語意之下完成的——這正是讓這項變更安全、而非只是聰明的那個部分。

值得直白地說清楚，這對讀者意味著什麼。這個 PR 有趣的地方，不在於 SGLang 變得更快，而在於 Qwen4 架構帶有逐層成本，而這些成本會隨 token 數量而非參數量而擴展，且這些成本正是在長 prefill 時會咬人的那一種。那是一種設計指紋，也是規格表從不會提及的東西。

測得的差異

作者在基準測試中固定了一組配置並切換該旗標：四張 NVIDIA H20 GPU、Qwen3.8-Flash-Next-FP8、張量平行 4 與專家平行 4、分塊預填充大小 8192、FlashInfer 線性注意力預填充與解碼後端、OFF 與 ON 採用相同的伺服器配置、以 OFF → ON → OFF → ON 交替進行服務重啟，以及固定 token 輸入並搭配暖機請求。下方每一項數據皆來自該設定，且未經稽核：

• 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 — 每個輸出 token 的時間基本上維持不變

最後一行值得讀兩遍，而作者也坦率說明了原因：這項最佳化僅在 prefill 階段啟用，因此單一串流的解碼完全得不到任何好處。batch-4 的每 token 時間改善——若真有出現——反映的是並行長 prefill 所帶來的排程延遲降低，而非任何更快的解碼核心。如果你原本期待這是個吞吐量的故事，那並不是——這是首 token 延遲與記憶體的故事，而這兩項限制正是決定一個 235K token 的請求究竟能否被服務的關鍵。

他們必須先修復的版面配置錯誤

這份 pull request 中最具資訊量的部分並不是加速比較表，而是關於 PLE 實體列佈局的那一節，因為它揭示了 Qwen4Exp 服務堆疊至今仍然弄錯的地方。

Per-Layer Embedding 運作於固定的實體 CUDA graph bucket 上，而該 bucket 中只有前綴的列可能存放真實 token。因此必須套用 padding在序列被分片之前，而不是之後。在一個 235K-token 請求的最後一個 chunk 中，作者的數字是：在 TP 4 下，8,192 列的實體 bucket 內有 5,624 個已處理 token，而唯一正確的佈局是 rank 0 持有 2,048 個有效列、rank 1 持有 2,048 個有效列、rank 2 持有 1,528 個有效列加上 520 個 padding 列，以及 rank 3 持有 2,048 個 padding 列。先將 5,624 個已處理列分片——那個顯而易見的實作——會在全域連續的有效範圍之間插入 padding，並破壞結果。作者記錄，一個真實的 235K OFF/ON 測試僅產生完全相同的 16-token greedy 輸出，在此佈局被修正之後。

這是一個小細節，卻有重大的意涵。SGLang 中的 PLE 路徑是最近才加入的，因此這種形態的 token 排序錯誤仍然可能被觸發，而發現這個錯誤的人當時正在撰寫序列平行擴充功能。針對這個架構的 day-zero serving 支援尚未完成；它正由貢獻者們公開地積極打造，一次一種佈局。

你付出的代價：種種限制

一個只對某些部署有幫助的旗標，只有在你知道是哪些部署時才有用。該 PR 明確陳述其需求，而不符合這些需求的設定會在引數驗證期間失敗，而不是無聲地劣化：

• 張量平行大小必須大於 1——單一 GPU 部署毫無助益，因為沒有可進行分片的 rank

• 專家平行大小必須等於張量平行大小

• 管線平行大小必須等於 1

• 資料平行注意力必須停用

• 推測解碼必須停用

最後一個限制條件背後有一個真正的決定。對於每個 token 啟動約 6B 參數的稀疏模型來說，推測性解碼是少數能加速解碼的手段之一，而這個功能明確地以換取 prefill 優勢為代價，關閉了這個手段。如果你的工作負載是長提示、短輸出——文件與程式碼庫分析、影片摘要、一次性讀取的大型上下文——這個取捨直接就是好的。如果你的工作負載是短提示、長生成，那你等於放棄了原本幫助你的東西，換來一個對你不適用的數字。專家平行等於張量平行這個要求是另一個需要注意的點：這意味著 MoE 分片幾何必須與 TP 幾何完全對齊，這排除了幾種原本合理的多節點佈局。

這對 Qwen 4 的時程說明了什麼

換個方式解讀這個 diff，你會得到一份日曆。SGLang 在 main 分支上的 LayerNorm-SP 模組目前帶有一份明確的允許清單，列出該功能已驗證過的架構；截至本文撰寫時，這份允許清單恰好只包含一個項目，Qwen3ForCausalLM—— 如果你傳入這個旗標，其他所有架構都會在建構時遭到拒絕。因此，將 Qwen4Exp 加入那條路徑，並不是對一個成熟抽象做微調；這是 Qwen4 架構首次被帶到一項比它早好幾個世代的最佳化上。

將此與公開紀錄對照，整體情況便顯得一致。該廠商於 2026-09-22 宣布 Qwen 4 正在訓練中，並預覽了四個層級名稱——Qwen 4 Max、Qwen 4 Flash、Qwen 4 Plus 和 Qwen 4 27B——但並未附加任何規格。共享該架構的開放權重預覽版 Qwen3.8-Flash-Next，自 2026-08-26 起已可下載。自那以來的三週內發生的事情，正是您在「訓練中」與「發布」之間會預期看到的：引擎作者們正在調試執行環境，以使首日支援真正落實，而非僅是名義上的。一個使服務優化能在該架構上運作的拉取請求，於 2026-10-08 上午開啟，且仍處於草稿狀態，這比任何人提出的任何日期更能表明 Qwen 4 距離可服務還有多近。它也斷然不是發布日期——該旗標預設為關閉，變更尚未合併，且其基準測試的模型是預覽版，而非 Qwen 4。

今天你可以稱之為什麼

這些都不會改變今天下午實際上能取得的東西。Qwen3.8-Flash-Next 是真的，它的權重放在 Hugging Face 上，你也可以自行託管——但它不在我們的目錄中，我們也不會佯稱它在。我們實際提供的層級是 qwen/qwen3.8-flash，這是受管理的同類模型，採用相同的 Qwen4-preview 架構，具備 100 萬 token 的上下文視窗，支援文字、圖像與影片輸入，定價為每百萬輸入 token 0.15 美元、每百萬輸出 token 0.47 美元，以及每百萬快取讀取 0.0184 美元。這是按 0% 加成直接轉嫁的定價，所以當供應商調整價格時，你發票上的數字會在同一天跟著變動，而不是等中間商何時重新發布價格表才更新。

這裡還有第二個、較不明顯的理由，值得你關注路由層。本文的一切都圍繞著一個未經實證的預覽版，外加一份草擬中的修補程式——這種東西你會想先測試，而不會拿正式環境的路徑去賭它。這正是容錯移轉的用途：把預覽版放在你已經信任的模型所用的同一把金鑰後面，觀察它在你的流量下表現如何，並在供應商不穩定或端點不存在時，讓請求自動落到已知良好的路由。一個 API 即可使用 200+ 個模型，一組憑證，不必再簽第二份合約，就能知道一個新架構是否值得你關注。

從這裡開始有兩件事值得觀察，而這兩件事我們都無法預測。第一是這個 patch 究竟會不會合併：它是一份草稿，一項來自該儲存庫中毫無先前紀錄的貢獻者帳號、涵蓋六個檔案的變更，卻有三次 CI 執行失敗；而 PLE 資料列版面配置工作的變動不定，顯示作者仍在反覆迭代。第二是允許清單是否會擴大——如果 Qwen4Exp 加入 Qwen3ForCausalLM 的行列，成為已驗證的架構，那麼這就不再是外洩，而會成為 Qwen4 系列模型在長上下文上提供服務的預設方式。直到上述任一情況發生之前，請把 18% 當成關於執行環境未來走向的承諾，而不是你能租用的數字。