主視覺標題卡寫著「Qwen4Exp QSA DCP」,並附有「未經驗證 — 草稿 PR,未合併」徽章,標題為「Qwen 4 QSA 實現解碼上下文平行處理」,副標為「深入剖析 vLLM PR #59279 的 Qwen3.8-Flash-Next Qwen4Exp 路徑」,三個標籤分別寫著「來源:vllm-project/vllm PR #59279」、「開啟於 2026-09-29」以及「狀態:開放,草稿」,頁尾一行則寫著「由貢獻者回報的數字;未經獨立稽核。」。OrcaRouter 標誌合成於右下角。
Guides & Insights

Qwen 4 QSA 獲得解碼上下文平行化:深入 vLLM 針對 Qwen3.8-Flash-Next 的草稿 PR

作者

Magnus Corvin

發佈日期

最新模型 · 20查看全部模型 →
基準測試:Artificial Analysis · 每日更新
返回全部文章

2026-09-29,vLLM 儲存庫中出現一份草稿拉取請求,標題為「[Model][DCP] 支援 Qwen4Exp QSA」,而就它所描述的模型而言,它帶有整個月來任何人所公布過最具體的服務數據:在四張 GPU 上成對執行 Qwen3.8-Flash-Next,顯示 KV token 容量從 9,759,529 增至 17,603,636,最大併發數從 37.23× 提升至 67.15×,首個 token 耗時從 1,869 毫秒降至 767 毫秒。Qwen3.8-Flash-Next 是開放權重、1,250 億參數的混合專家預覽版,其 Hugging Face 模型卡將其描述為「Qwen4 架構的預覽版」;該拉取請求為該架構所賴以建構的稀疏注意力路徑加入解碼上下文平行處理。Qwen4 本身——廠商在 2026-09-22 雲棲大會上公布的 Qwen4 Max、Flash、Plus 與 27B 等層級——仍未發布,既沒有權重、識別碼,也沒有價格和日期。因此,請如實看待這件事:這不是發布,不是基準測試,而是一項工程產物,告訴你在 Qwen4 家族尚未問世之前,其服務邊界正如何被拓寬。

這是一篇「目前已知」的整理報導,出處來源比平常更為重要。該 pull request 是一份草稿、已開啟且尚未合併——vllm-project/vllm#59279,由 NVIDIA 軟體工程師 Sungsoo Ha 於 2026-09-29 開啟,目前仍處於草稿狀態。以下每個數字都是作者在 PR 說明中報告的自身配對量測結果,取自同一項工作的較早修訂版。這裡沒有任何內容經過獨立審查,也沒有任何內容進入正式發布版本,而作者附加的但書相當重要,因此下方會專門用一個章節說明。

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

解碼情境平行處理——DCP——是一種服務技術,而非模型變更。DCP 不是讓單一 GPU 群組持有整份 KV 快取,而是把該快取分散到各個 rank,因此每個 rank 只讀取自身負責的那一段情境,同時注意力結果會在最後跨 rank 合併。重點在於容量:快取分割之後,部署能在相同硬體上容納遠更多並行的長情境流量,而當每個請求都攜帶 25 萬個 token 時,這正是最會造成限制的瓶頸。

真正的麻煩在於,Qwen Sparse Attention——QSA——並非單純的注意力層。正如 Qwen3.8-Flash-Next 模型卡所載明的那樣,一個輕量級索引器會以 4 的壓縮比將鍵壓縮成微區塊,對它們評分,並保留最佳的 512 個區塊,約 2,048 個 token 位置,而最終的 softmax 與值聚合仍在未壓縮的 K 和 V 上執行。這意味著 QSA 所攜帶的狀態比 KV cache 更多:有主快取,也有索引器所維護的選擇器快取與側快取。vLLM 中的通用 DCP 實作對這一切毫無所知。

根據 #59279 的說明,它的作用是讓 DCP 認識 QSA 專屬的部分:

• 每個 rank 各自讀取主要 KV 快取中屬於自己的部分,而 QSA 的選擇器與側快取則在各 rank 之間保持複製,而非分片。

• 分割讀取後,注意力結果會跨各 rank 合併。

• 選擇器和主要 KV 快取會保存在同一個快取群組中,因此它們不會彼此不一致。

• Synthetic V2 批次會被阻止寫入 QSA 側快取。

A capture of the vLLM GitHub pull request #59279, titled '[Model][DCP] Support Qwen4Exp QSA', showing an Open state with a Draft badge, the head branch sungsooha:n4/qsa-dcp-clean-20260929, the description of how decode context parallelism is enabled for Qwen4Exp QSA, and the labels kv-cache-manager, mrv2, speculative-decoding, dflash, nvidia, qwen and ci/build.

最後那對細節才是有意思的部分,如果你在意的是正確性而非吞吐量的話。一個分片式注意力快取若悄悄地和複製式選擇器不一致,這類 bug 表現出來的形式會是在長上下文下緩慢的準確度衰減,而不是崩潰;而這次的變更明確處理了要讓兩者保持同步。作者也聲明使用了 AI 輔助,並將 Codex 列為共同作者——這件事值得直說,因為在這種形式的草稿 PR 中,追問哪些部分由誰撰寫是很合理的問題。

成對的數字,以及它們是如何取得的

這份測試計畫的具體程度足以供人檢核,這正是其結果值得引用的原因。兩個實驗組都在四張 GPU 上服務 Qwen/Qwen3.8-Flash-Next-FP8,張量平行度為 4 並啟用專家平行,設定為 --gpu-memory-utilization 0.90,且開啟前綴快取。兩組之間唯一的差異在於 --decode-context-parallel-size:DCP=1 時予以省略,DCP=2 時設為 2,並在兩組之間重新啟動,使基準測試從冷快取開始。負載為 AgentX 256k 軌跡,128 位使用者,持續 900 秒;準確度則採用 EvalScope 評估 GSM8K,加上已簽入的 MRCR 評估器,每組執行六次,並捨棄重新啟動後的第一次執行結果。

所報告的輸送量差異,DCP=2 對比 DCP=1:

• KV 權杖 — 9,759,529 對比 17,603,636,快取容量增加 1.80 倍。

• 最大並行數 — 37.23× 對比 67.15×,以及 1.80×。

• 每秒請求數 — 1.69 對 2.30,1.36 倍。

• 每秒輸入 token 數 — 128,730 對比 179,702,1.40×。

• 首個權杖時間 — 1,869 毫秒 vs 767 毫秒,降低 2.44 倍。

• 詞元間延遲 — 43.48 毫秒對比 26.27 毫秒,低 1.66 倍。

• 穩態下的前綴快取命中率——67.85% 對 88.98%,提升了 21.1 個百分點。

A two-column comparison scoreboard titled 'Qwen4Exp QSA — DCP = 1 vs DCP = 2'. The DCP = 1 (baseline) column reads KV cache tokens 9,759,529, max concurrency 37.23x, requests/sec 1.69, time to first token 1,869 ms, inter-token latency 43.48 ms, prefix cache hit 67.85%. The DCP = 2 (context parallel) column reads KV cache tokens 17,603,636, max concurrency 67.15x, requests/sec 2.30, time to first token 767 ms, inter-token latency 26.27 ms, prefix cache hit 88.98%. A footer line reads that all figures are contributor-reported in vLLM PR #59279 and unaudited, measured on an earlier revision of the patch. The OrcaRouter logo is composited in the bottom-right corner.

準確率以預熱後各次執行的平均值 ± 樣本標準差表示,基本上持平:MRCR 彙總在 DCP=1 為 0.8630 ± 0.0005,相較於 DCP=2 的 0.8697 ± 0.0153;而 KEEP 為 0.9788 ± 0.0020,相較於 0.9790 ± 0.0016。2-needle 與 4-needle 的 MRCR 樣本在兩組中皆固定為 0.9966 與 0.9906,因此所有各次執行之間的變動都來自 8-needle 樣本——其中一次 DCP=2 彙總執行得分為 0.9970,而另外四次則介於 0.8620 與 0.8632 之間。那是實質的差異,不是你可以隨口稱作雜訊的東西;而且這點在 PR 中如實說明,而非被粉飾帶過。

這些數字未能證明什麼

這個但書就寫在 PR 內容中,而且並不小。成對的 AgentX 與準確度結果,是在一個較早的 QSA DCP 修訂版上測得,使用的是 vLLM nightly,其版本基於提交 3df4ae153eb。PR 中最終的乾淨提交包含了後續的 QSA 本地化核心修正,並已通過聚焦的 B200 驗證——但完整的 AgentX 與準確度評估尚未在那個確切的原始碼上重新執行。換句話說:吞吐量方面的說法和實際交付的 diff 並不是同一個產物,而且作者也這麼說。

除此之外,通常的紀律依然適用,而且在這裡適用得特別嚴格。這些是來自單一貢獻者、在單一四 GPU 配置上取得的單一設定數據。它們偏向廠商而非中立:框架貢獻者衡量框架變更是正常且有用的事,但這不是獨立稽核,也沒有第三方重現過該次執行。目前沒有任何已發佈的 vLLM 版本包含這項變更,因為該變更尚未合併。而 DCP=2 是針對某個特定形狀的雙向切分——這些差異值並不保證 DCP=4 或 DCP=8 會有什麼表現,PR 中也没有任何地方聲稱如此。

為什麼一篇關於尚未發布架構的 serving PR 仍值得你花時間

顯而易見的反對意見是:標題中的模型並不存在,那又何必在意?因為正在微調的東西並不是 Qwen 4。而是 Qwen3.8-Flash-Next,而那個模型確實存在——阿里巴巴於 2026-08-24 發布了它,是一個 125B 參數的 MoE、啟用 6B,一張 510 億參數的 n-gram 嵌入表,一個用於推測解碼的 4B MTP 頭,48 層以「三個 Gated DeltaNet 區塊後接一個 QSA 區塊」重複十二次的方式排列,512 個專家中有 10 個路由專家和 1 個共享專家處於啟用狀態,以及 262,144 個 token 的原生上下文,而模型卡上說可擴展至 1,000,000。它是 Qwen4 架構以開放權重形式提供的參考實作,而 QSA——這個 pull request 正教導 DCP 對其進行分片的微區塊稀疏注意力——正是它最具特色的一部分。

這些數字所描述的,是當你不再把那個 262K 上下文視為必須由單一 GPU 群組完整承載的東西時,會發生什麼事。KV token 容量與並行度提升 1.80 倍,是把快取一分為二的算術結果,也是這份清單中最不令人意外的結果。更有趣的數字是延遲方面的:在相同提供的負載下,首 token 時間降低 2.44 倍、token 間延遲降低 1.66 倍,再加上穩態前綴快取命中率提升 21 個百分點。這些數字說明,DCP 路徑並非只是以延遲為代價換取容量——在這組配對執行中,它兩者兼得。對任何要服務帶有超長系統提示的 agent 流量的人來說,這正是關鍵的改變形態,因為長上下文下的前綴快取行為,通常就是長上下文吞吐量悄悄崩掉的地方。

而這並非孤立的補丁。同一週出現了一整組 Qwen4Exp 引擎工作:#59214 為 B200 形狀新增 SM100 低延遲解碼 GEMM 計畫,#59010 為 Hopper 上的 QSA 路徑新增 SM90 原生稀疏 prefill 核心,#58977 涵蓋 BF16 INC PLE 嵌入,而 #58961——已於 2026-09-28 實際合併的那一個——修復了 QSA key views 一直使其存活的 profiling KV cache。合起來看,它們是在 Qwen4 系列推出數個月前,於執行環境中公開建構的 Qwen4 架構的服務輪廓。如果你正在為 Qwen 4 規劃,有用的訊號不是推出日期——根本沒有這種日期——而是這些核心與快取佈局已經對你將必須如何服務它所做出的假設。

今天你可以稱之為什麼

如果你想在這個 PR 所關注的架構上測試長脈絡行為,該找的模型是阿里巴巴實際提供的 Flash 層級。Qwen3.8-Flash——建構於 Qwen3.8-Flash-Next 之上的正式生產部署,具備 1,000,000 個 token 的脈絡與 131,072 個 token 的最大輸出,可接受文字、圖像與影片輸入——已經上線,而且它就是真正在今日運行 Qwen4Exp 架構的模型所對應的單一端點,列名為qwen/qwen3.8-flash,每百萬輸入 token 收費 $0.15、每百萬輸出 token 收費 $0.47,快取讀取則為 $0.0184。由於這些是供應商的定價,我們這邊不加價直接轉呈,因此該模型的廠商價格或限制若有變動,會在公告當天就傳達到你這裡。

A capture of the OrcaRouter model page for Qwen3.8 Flash (qwen/qwen3.8-flash), showing the model name and vendor, the Vision, Tools, JSON and Reasoning capability chips, text plus image plus video input, a 1,000,000-token context window, 131,072-token maximum output, a $0.15 per 1M token input rate and a $0.47 per 1M token output rate passed through at provider list price, and an OpenAI-compatible base URL of https://api.orcarouter.ai/v1.

兩點必須坦白說明的但書。第一,Qwen3.8-Flash-Next 本身——也就是 PR 測試計畫中的 FP8 權重,那個你若想在本機重現這裡任何一項量測結果都必須用到的版本——並不在我們的產品目錄中;所提供的 Flash 服務層級是 QwenCloud 的正式生產線,而非原始預覽檢查點。如果你想跑 PR 裡那套確切的配置,你得在四張 GPU 上自行託管。第二,DCP 的變更尚未合併,因此今天你在任何地方能呼叫到的東西,都沒有在跑它。服務層級能給你的,是一個方法,讓你判斷自己的工作負載形狀是否真的契合 DCP 所解決的問題:如果你的提示詞很長、具代理性且前綴佔比高,那麼 1.80 倍的容量與前綴快取差異,就是你在自己的追蹤記錄中該留意的數字。

而如果你感興趣的部分並非單一模型,而是切換的問題——在 Qwen 4 系列仍未定名的情況下,該建構在哪一層級上——那這是路由問題,而非服務問題,而一個 API 串接 200 多個模型正是讓你在該系列終於問世時,無須第二份合約或修改程式碼,就能保有選項的方式。

值得直接回答的問題

#59279 是否意味著 Qwen 4 已經推出,還是即將推出?

不。這個 pull request 談的是 Qwen4Exp 架構,也就是 Alibaba 於 2026-08-24 在 Qwen3.8-Flash-Next 中所實作的版本。Qwen 4 系列——Max、Flash、Plus 與 27B——於 2026-09-22 在 Apsara 的舞台上公布名稱,並被納入公司路線圖,其後續產品線預計達到 5 至 10 兆個參數,而它至今仍沒有模型卡、沒有權重、沒有 API 識別碼、沒有上下文視窗、沒有價格,也沒有日期。一個為預覽架構加入平行模式的框架 PR,是邁向完善服務 Qwen 4 的一步。這不是邁向 Qwen 4 存在的一步。

解碼上下文平行處理與張量平行處理有何不同?

它們切分不同的東西,並以不同方式失效。張量平行處理會把每一層的權重與運算分割到多個 GPU 上,因此每個 rank 都會參與每個 token,但會看到整個序列。解碼上下文平行處理則會分割 KV 快取本身,因此每個 rank 只會持有並讀取上下文的一個切片,而部分的注意力結果會在之後合併。TP 是為了容納模型;DCP 是為了容納上下文,以及搭載於其上的並行流量。這個差異正是為什麼這個 PR 並非易事:QSA 的選擇器與側邊快取無法像主 KV 快取那樣簡單地分片,因此這項變更必須將其中一個分片,並複製其他的,然後證明兩者維持一致。

如果我今天透過託管的 API 呼叫 Qwen3.8-Flash-Next,我是否已經能取得這些數字?

不,而且這個差距有三個部分。這項變更尚未合併,所以沒有任何已發行的 vLLM 版本包含它。即使合併了,供應商也必須採用那個版本,並選擇以 DCP 大小大於 1 來執行——這是服務配置,不是預設值。而且測得的差異來自該修補程式的較早修訂版,而非最終提交;作者表示,最終提交迄今只做過聚焦於 B200 的驗證。請把所報告的差異視為這個方法在單一配置下所能帶來效益的有詳細記錄上限,而不是你這週能租用的任何端點規格。

未解決的問題

真正該留意的,不是這份特定草案是否會被合併——它大概率會以某種形式合併,因為它加入的 QSA 專屬快取處理是真正的缺口,而不是偏好問題。真正該留意的是,最終提交是否會得到與中間修訂版相同的配對評估。一項服務層變更,若其吞吐量數據來自某個建置版本、而正確性數據來自另一個建置版本,那麼就目前而言,它是一份論證充分的提案,而非經過實測的結果;而且 8-needle MRCR 樣本上的準確率離散幅度相當大,因此在實際出貨的原始碼上重跑一次,會是任何人能就它發表的最有用的一件事。在那之前:方向清楚可辨,帳目尚未結清,而開放權重中唯一的 Qwen4 架構模型,仍然是八月的那一個。