DeepSeek-V4.1-Flash 深度分析：百萬 Token Agent 的快取成本真降了嗎？（2026）

2026 年 9 月 17 日，DeepSeek-AI 在 arXiv 發布技術報告〈DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression〉。DeepSeek-V4.1-Flash 的重點不是再把「百萬 token」寫進規格表，而是直攻長上下文 Agent 最不顯眼、也最容易把服務成本撐爆的地方：prefill、HBM 裡的 KV cache，以及跨工作階段保存到主機記憶體或 SSD 的持久化快取。

這份報告值得看的，不只是模型分數，而是它如何把架構、低精度快取與部署策略綁在一起。以下先還原設計，再檢查數字的邊界，最後回答一個更實際的問題：百萬 token Agent 的帳單，究竟真的變小了，還是只是換了計費位置？

核心主張：長上下文真正卡住的是搬運與保存

DeepSeek-V4.1-Flash 是多模態 MoE 模型，語言骨幹有 552B 參數，另配置 196B Engram 參數。這兩個數字不能混成「整個模型只有 552B」；前者是 backbone，後者是以稀疏方式查找的條件記憶。模型把 40 層拆成 20 層 causal encoder 與 20 層 decoder，官方規格支援最高約 100 萬 token 上下文。8B／16B「啟用參數」也不等於權重常駐量或實際 FLOPs；552B backbone、Engram、分片、RDMA 與通訊成本仍然存在。

“prefill remains computationally expensive”

中文：prefill 仍然需要昂貴的計算。

DeepSeek-V4.1-Flash 技術報告

這句話點出 Agent 與一般聊天的差別。Agent 會反覆帶入程式碼、工具輸出、文件與歷史軌跡；每次重新處理長 prompt，都要付 prefill 計算，並為後續生成保留 KV cache。上下文視窗可以容納多少，只是容量上限；真正決定一套服務能同時撐多少工作階段的，往往是每個工作階段佔多少 HBM、快取能否命中，以及舊狀態要不要從 SSD 搬回來。

三張帳單：Prefill、全域 KV、持久化快取

DeepSeek 報告提出三組相互配合的數字。第一，模型在 prefill 階段每個 token 啟用 8B 參數，decode 階段則啟用 16B；這是架構規格，不是整個模型的總參數量。第二，作者稱 global KV cache 壓到每 token 890 bytes，約為 V4-Flash 的四分之一。第三，藉由不再長期保存 SWA KV、需要時只重播有限範圍，持久化 KV cache 據稱約降到 V4-Flash 的八分之一。

按 890 bytes 直接換算，100 萬 token 的 global KV 約是 890 MB；100 個同樣長度、同時完整駐留的工作階段，單是 global KV 便約 89 GB。這只是用論文數字做的容量算術，不是 AlphaLab 的吞吐量實測，也不包含 SWA、模型權重、執行時緩衝區、碎片與複本。它真正說明的是：每 token 少幾 KB，乘上長上下文與大量並行工作階段後，就會成為基礎設施級差異。

它怎麼做：不是一招，而是四層共同設計

這些元件並非全從零開始：論文明說 CED 受到 YOCO 啟發，跨層重用 KV 或索引也延續 IndexCache、YOIO、HySparse 等研究方向。V4.1-Flash 更值得注意的創新，是把這些方向與低精度快取、訓練適配、kernel 和持久化策略一起做成可部署系統，而不是替每個元件宣稱首創。

1. CED：讓大部分輸入少走一半昂貴路徑

Causal Encoder-Decoder（CED）先由 encoder 處理輸入，再用最後的 encoder hidden states 建立 decoder 的 global KV。直覺上，它不讓每個 prompt token 都完整走過同一套 decoder 計算。這就是 prefill 啟用 8B、decode 啟用 16B 的來源，也是 DeepSeek-V4.1-Flash 對「輸入很長、輸出相對短」Agent 工作負載的主要押注。

2. CSA2：跨層共用 KV，也共用搜尋結果

Compressed Sparse Attention 2（CSA2）把層分成 Full、Reindex、Reuse。Hierarchical Sparse Indexer 只放在 decoder；其中第一個 Full-mode CSA2 layer 掃描可見的 main KV 並建立候選池。論文的例子是挑 2,048 個區塊、每區塊 8 個位置，形成 16,384 個候選位置。後續 Reindex 層只在池內挑 Top-512，Reuse 層連索引都不重算。代價是搜尋從「每層各自完整判斷」改成「後層相信前層縮過的範圍」；省下計算與快取，也把選錯候選的風險集中到較早的索引器。

3. FP4：壓的是 main/global KV，不是所有快取

報告把 main KV cache 量化成 FP4 E2M1，並以每 16 個 channel 一個 E4M3 scale 配合訓練；但 sliding-window attention（SWA）的 KV 仍是 FP8。把它簡化成「整套 KV cache 都用 FP4」會誤導讀者。更準確的說法是：DeepSeek 用 FP4 壓全域、長期最吃容量的部分，再保留局部視窗的精度與運作方式。

4. Bounded Replay：少存一份狀態，命中時補算一小段

上一代部署會把 global KV 與 SWA KV 都放進持久化快取；V4.1-Flash 改成長期保留 global KV。Encoder SWA KV 不再寫入 persistent cache，但仍存放於每台機器約配置 10% host DRAM 的分散式記憶體池，TTL 只有數分鐘；當 global KV hit、SWA 卻 miss 時，系統才重播最近一個 SWA window。Decoder SWA KV 則從不快取，因此每次 prefill 都重播 prompt 最後一個 window。這不是把成本消失，而是用短期 DRAM 與固定範圍重算，交換 SSD／主機記憶體容量和資料搬運。

數字很漂亮，但證據還缺兩塊

論文呈現的 Agent benchmark 進步明顯：在作者設定的 Max reasoning effort 下，DeepSWE v1.1 為 74.2%，V4-Flash 為 54.4%；Terminal-Bench 2.1 則是 90.6% 對 82.7%。這些是 DeepSeek 報告中的模型結果，不是獨立稽核。表格同時顯示基礎模型在 LongBench-V2 得 45.2，僅略高於 V4-Flash 的 44.7，且低於 V4-Pro 的 51.5；但 LongBench-V2 不是專門把關鍵證據埋在 1M token 中的 needle／retrieval 壓力測試，不能單靠這一列判定百萬 token 檢索能力。合理結論仍是：容量與可靠找回關鍵證據，必須分開驗證。

第一塊缺口是可歸因性。CED、CSA2、FP4、Bounded Replay、Engram 與 DSpark 同時改動；依照文內現有表格，讀者無法把每項機制對品質、延遲與容量的貢獻分離。第二塊是端到端服務數字：論文主要公開 FLOPs 與快取容量；要估算真實部署成本，仍需要在相同硬體、相同併發、相同命中率下比較 time-to-first-token、每秒輸出 token、尾延遲與每工作階段總成本。因此，架構方向可信，不代表「部署成本已降低多少」可以直接從 890 bytes 推導。

“no finite test suite can cover every extreme input and deployment condition”

中文：任何有限測試集，都不可能涵蓋所有極端輸入與部署條件。

DeepSeek-V4.1-Flash 技術報告的限制說明

作者表示內部評估在已測設定中未觀察到系統性能力退化，但這仍是團隊自報；同一段也明確指出兩個尚未充分刻畫的邊界：CSA2 可能選錯位置，Bounded Replay 的近似狀態重建也可能在未測條件下降低能力。這段限制比任何排行榜都重要，因為它把下一輪競爭的題目說清楚了：不只是塞得下，而是能不能在很長、很髒、會跨工作階段恢復的真實上下文裡，穩定找回對的資訊。

AlphaLab 判讀：成本沒有消失，命中率變得更重要

壓縮的真正價值，是提高並行密度

我認同 DeepSeek 的主方向。對長時間 Agent，KV cache 不是附屬資料，而是另一種工作記憶；每 token 的 byte 數會直接影響一張卡能留住多少活躍工作階段、多少 prefix 可以跨請求重用，以及快取被逐出後要付多少重算。V4.1-Flash 最有價值的地方不是「視窗又變長」，而是試圖讓更多長視窗同時活著。

算力之外，命中率與資料生命週期變得更重要

當 global KV 變小、SWA 改成短期保存或固定範圍重播後，應用層的 prompt 穩定性就更重要。系統提示、工具定義與大型文件若能形成穩定 prefix，命中持久化 global KV，節省會被放大；若 Agent harness 每一輪都重排內容、插入動態欄位，或頻繁跨過恢復邊界，再好的壓縮也可能被 miss 與 replay 吃掉。命中率與資料生命週期因此會更大程度影響帳單，但 prefill miss、輸出長度、decode、模型常駐記憶體、I/O、硬體與併發仍共同決定總成本。

這套設計最直接瞄準 input-heavy workload。若任務主要花在長輸出，decode 長度、DSpark 的實際接受率與硬體吞吐仍會主導結果；論文目前公開的核心證據以 FLOPs、容量與模型 benchmark 為主，仍需要同硬體端到端對照才能換算成真實帳單。

長上下文仍不是可靠記憶

CSA2 的候選池把檢索錯誤變成核心風險：某個 global-KV position 若未進入第一個 Full 層建立的 candidate pool，後續 Reindex 層就不能直接重新選到它；不過，資訊仍可能透過前層輸出、殘差流或 SWA 間接傳遞，不能簡化成「後層完全看不到」。DeepSeek-V4.1-Flash 的公開證據主要支持「歷史更容易被保存與搬運」；至於能否從極長歷史穩定找對證據，作者也把稀疏檢索列為後續壓力測試重點。對高風險流程，外部檢索、結構化狀態與可驗證工具輸出仍不能被一個 1M 視窗取代。

MIT 權重降低使用門檻，不等於部署門檻消失

官方 Hugging Face 模型庫以 MIT License 發布權重，讓研究與商業整合的授權路徑更直接。但 552B backbone、196B Engram、低精度 kernel、分離式 encoder／prefill／decode 與持久化快取管理，仍是一整套系統工程。開放權重代表可取得，不代表一般團隊能用單機重現論文的服務效率。

接下來該怎麼驗證這個架構

• 同硬體、同負載比較：固定 prompt／output 長度、批次與併發，公開 TTFT、吞吐、P95/P99 延遲、HBM／工作階段與 SSD 寫入量。
• 把命中率放進報表：分別測全新 prompt、穩定 prefix、短間隔續聊與超過持久化期限後恢復，避免只展示理想 cache hit。
• 壓力測稀疏檢索：在 64K、256K、1M 放置容易混淆的證據，測候選池漏選，而不是只確認輸入可被接受。
• 隔離每個機制：用受控消融拆出 CED、CSA2、FP4 與 Bounded Replay 對成本和品質各自的貢獻。
• 應用團隊先測工作量：不要預設 1M 一定優於 128K；用任務成功率、重試次數與每完成一項任務的總成本選上下文長度。

如果這些端到端數據成立，DeepSeek-V4.1-Flash 的影響會比一次排行榜領先更持久：它會把「上下文能有多長」改寫成「同一套基礎設施能保留多少有用歷史」。若數據不成立，這份報告仍把問題定義得更精確——百萬 token Agent 的瓶頸不只在模型能不能讀，也在系統能否便宜、持續且可靠地保存與找回。