DeepSeek-V4.1-Flash 喺 vLLM 推理引擎上嘅吞吐量，喺發布後三週內被調高咗 5.3 倍。呢個數字來自 vLLM 官方 blog（2026-10-07），測試基準係 SemiAnalysis AgentX，約束條件係 150 TPS。低並發下速度提升 1.9 倍，TTFT（Time To First Token，首 token 延遲）縮短約 30%。
先講清楚：呢個數字由 vLLM 團隊同 Inferact 合作完成，非獨立第三方驗證。SemiAnalysis AgentX 係第三方評測框架，但優化工作本身由模型方同推理引擎方共同進行，讀者宜自行判斷「自評」同「獨立實測」之間嘅距離。
模型邊個先做咗乜
DeepSeek V4.1 引入 CED（Causal Encoder-Decoder，因果編解碼器）架構：decode 階段每個 token 激活 16B 參數，prefill 階段只激活 8B。模型同埋 KV cache 壓縮策略：Compressed Sparse Attention 2（CSA2）、FP4 KV cache、層間 KV cache 共享，將全局 KV footprint 壓到 890 bytes/token（V4.1 報告）。
vLLM 邊個做咗乜
第一招係 SWA bounded replay（滑動窗口有限重放）。V4.1 維持兩種 KV cache：全局 KV（壓縮、FP4、跨層共享）同滑動窗口 KV（未壓縮、FP8、每層 40 層各保留最後 128 個位置）。SWA KV 嘅代價：prefix caching 要喺每個可能命中邊界都存一份，儲存量大於全局 KV 嘅 10 倍；prefill 時層 21–39 喺每個 prompt token 都要跑，但 decode 時只讀最後 128 個位置。
SWA bounded replay 嘅做法：唔再精確重算，而係只重跑最後 128 個 token 並喺重放起始點截斷窗口。結果唔係 bit-exact，但 DeepSeek 稱品質損失可忽略。vLLM 喺 encoder 同 decoder 兩邊都用呢招：encoder 邊 cache 全局 KV、跳過 SWA KV，喺 prefix hit 時重跑 [H−128, H) 重建窗口；decoder 邊，層 20 喺每個 token 都跑，層 21–39 只喺每個 request 最後 128 個 token 上跑，長 prompt 可跳過近一半模型。
第二招係 CUDA graphs。經過上述裁剪，層 21–39 嘅 GPU 工作量極少，若 eager 執行則 kernel launch 開銷主導、GPU 空轉。因為層 0–20 同層 21–39 嘅輸入 shape 唔同，唔可以攝入同一個 CUDA graph；vLLM 嘅 breakable PIECEWISE graph 喺模型中段分段，天然適合呢個分裂。
第三招係整合 DeepSeek 新發布嘅 kernels：MegaAttention、Mega-mHC、Mega-Gate、DeepSelect，再對剩餘 kernels 做融合同並行化，包括 mHC side streams 同將 all-reduce 同前後運算融合入單一 kernel。
模姐驗嚇貨
5.3 倍吞吐量，聽落似係一個「部署優化」故事，但背後其實係模型架構（CED + KV 壓縮）同推理引擎（SWA replay + CUDA graphs + kernel 融合）両邊同時動手。呢種「模型方同引擎方共同調教」嘅模式，未來開放權重模型部署係咪會成為常態？另，DeepSeek 稱 SWA bounded replay 品質損失「可忽略」，但呢個「可忽略」嘅評估方法與樣本量，值得跟進獨立核實。對部署者而言，TTFT 縮短 30% 同吞吐量 5.3 倍，對 agent 工作流嘅實際成本影響，需要按本身工作負載同 GPU 型號另行估算。
模姐｜深度調教
