DeepSeek V4.1 Flash 將全域 KV 快取降至約每 token 890 bytes，讓長上下文需要長期保存的資料進一步縮小。DeepSeek 在 2026 年 9 月 10 日發布的技術報告中，將這個數字列為 V4 Flash 同長度上下文的約 1/4；持久化 KV 快取則在相同工作負載下約為前代的 1/8。兩個比例算的是不同範圍，部署評估不能混用。
模型讓多層共用全域記憶，降低部分記錄的精度，還把不值得長期保存的局部狀態改成需要時重算。對持續讀取程式碼、文件與工具回傳結果的 Agent，這些選擇會影響歷史內容保留多久，以及重用一段提示需要付出多少成本。單看最大上下文長度，已經不足以判斷服務是否划算。
輸入啟動約 8B 參數，生成仍跑完整 40 層
KV 快取是注意力機制保存的 key、value 數值狀態。模型生成新 token 時，可以讀取先前的狀態，省去重算整段歷史的工作；這些狀態並非文字摘要。
一般僅解碼器 Transformer 的各層，通常根據各自的中間表示建立 KV。尚未快取的長輸入因此要經過整個網路。DeepSeek V4.1 Flash 採用因果編碼器—解碼器（Causal Encoder-Decoder，CED），把語言主幹分成前 20 層 Causal Encoder 與後 20 層 Decoder。後半段的全域 KV，直接由前半段的最終輸出投影而成。
輸入處理與生成因此走不同路徑：
Prefill：處理已知輸入、建立快取
輸入 → 前 20 層 Encoder → 由 Encoder 輸出建立 Decoder 全域 KV。
整段提示末尾的 128 token 仍需經過 Decoder，以補齊局部視窗狀態。
Decode：逐步產生新輸出
目前 token → 前 20 層 Encoder → 後 20 層 Decoder → 預測下一個 token。
兩部分都會讀取對應快取，並替新增位置建立狀態。報告所列的啟動參數量，prefill 約為 8B，decode 約為 16B；16B 指完整生成路徑，不能再把它加到 Encoder 的 8B 上。對足夠長的輸入，略過大部分 Decoder 計算可讓 prefill 運算量接近減半，實際耗時仍受硬體、核心實作與批次安排影響。架構與計算口徑見官方技術報告。
這裡的 Encoder 也有明確限制。以「小明把蘋果吃了」為例，雙向編碼器處理「小明」時可以利用後面的「蘋果」與「吃了」；因果編碼器處理這個位置時，只能使用當下與先前資訊。處理到「吃了」，才可利用已出現的前文。
Causal 描述資訊依賴方向，沒有承諾因果推理能力。它也不要求 prefill 逐字串行：已知輸入可透過注意力遮罩並行計算，只要每個位置看不到未來即可。
這條設計路線有前作。Yutao Sun、Li Dong 等人在 2024 年 5 月 8 日提出的 YoCo，讓前段網路產生全域 KV、後段重用，並讓 prefill 提前結束。V4.1 Flash 沿用減少重複快取的方向，另外加入逐層局部注意力與有限回放，不能將兩者視為完全相同的架構。YoCo 原始論文提供了這段研究脈絡。
1. 全域記憶與局部狀態分開保存
V4.1 Flash 將注意力使用的歷史資料分成兩類。全域 KV 負責找回較早的上下文，資料量會隨輸入長度成長；滑動視窗注意力（Sliding Window Attention，SWA）的局部 KV，則保留最近 128 token，各層都有自己的狀態。
局部視窗小，不代表整個服務保存的局部資料一定少。同一段對話可能留下不同續接位置，服務也可能同時保留大量會話。單份視窗大小有上限，許多快取點累積起來仍會占空間。這正是後面調整持久化策略的原因。
全域部分又包含兩種資料：真正供注意力運算讀取的 main KV，以及協助搜尋的 indexer K。評估共享程度時，需要把兩者一起看；只數主 KV，會漏掉檢索本身的保存需求。
2. CSA2 讓 38 層共享四組全域 KV
壓縮稀疏注意力第二版（Compressed Sparse Attention 2，CSA2）將層分成 Full、Reindex 與 Reuse 三種模式。Full 建立新全域 KV 並選出要讀取的位置；Reindex 沿用全域 KV 與 indexer K，以自己的索引查詢重新選位置；Reuse 則連最近一次對應的 Top-K 選擇結果也沿用。
共用記錄省儲存，共用選擇結果省搜尋。每層仍計算自己的注意力查詢 Q，保留自己的局部 SWA KV，也執行其餘網路運算。Reuse 沒有把整層跳過。
| 區段 | 層配置 | 全域 KV 組數 |
|---|---|---|
| Encoder 第 1–2 層 | 僅局部 SWA | 0 |
| Encoder 第 3–20 層 | 3 組，每組 1 層 Full＋5 層 Reuse | 3 |
| Decoder 全部 20 層 | 1 層 Full、4 層 Reindex、15 層 Reuse | 1 |
結果是 38 個具備全域注意力的層，共用四組全域 KV。每組都是隨上下文成長的一套記錄，並非一個向量；也不能用 38／4 推算相較 V4 的節省倍數，因為前代原本就有壓縮，不同區段的序列壓縮率也不同。
CSA2 每次查詢最多選 512 條全域記錄，再搭配局部視窗進行注意力運算。未入選的記錄仍然存在，後續 token 可能需要它們。讀取上限與保存上限必須分清楚。
Decoder 還採用分層檢索。第一個 Full 層先掃描所有因果可見位置，以區塊建立共享候選池，最多 2048 塊，每塊 8 個位置，合計 16384 個候選位置。後續 Reindex 層只在池內選各自的 Top-512，Reuse 層再沿用結果。這項限制也在後訓練中納入。
候選池固定後，後續索引器每次查詢的評分量便有上限。然而，第一遍全域掃描仍隨上下文成長，全域快取也沒有消失。若把這段設計描述成整個模型具備固定成本的長上下文，會抹掉最重要的限制。CSA2 與分層索引見技術報告 §2.3。
3. Encoder 合併位置，Decoder 保留逐 token 記錄
序列壓縮也有分工。Encoder 的三組全域 KV 採用壓縮率 2，亦即每 2 個 token 形成 1 條記錄；Decoder 的壓縮率為 1，保留逐位置的全域記錄。
Decoder 因此主要依靠跨層共享降低空間需求，沒有把所有遠端資訊都先合併成更粗的表示。長程資訊的解析度、每次讀取多少位置、多少層共用同一份資料，可以分別調整。
相較 V4 的 CSA 與 HCA 混合全域分支，V4.1 改用 CSA2。對實作端而言，這也代表不能只替舊引擎改一個壓縮率參數，就假設共享與檢索路徑已經支援。
4. FP4 讓主 KV 縮小，縮放係數仍要占空間
主 KV 的數值格式從 FP8 降至 FP4。報告使用 E2M1，每個數值占 4 bit，每 16 個通道另配一個 8 bit 的 E4M3 縮放係數。只計這兩部分，平均每個數值的保存成本為：
4＋8／16＝4.5 bit
這個算式不能拿來代表所有快取的平均位元數。它未計入其他資料結構，局部 SWA KV 也繼續使用 FP8。報告的全域 KV 總量，還包括前述 indexer K 與各區段的不同設定。
量化同時牽涉品質。DeepSeek 在後訓練加入量化感知訓練（Quantization-Aware Training，QAT），讓模型適應低精度保存的主 KV；讀取時再反量化，交由注意力計算。省下儲存與搬運，不代表注意力矩陣乘法就直接改成 FP4 執行，也不能將 4.5 bit 推算成固定推論加速倍數。
5. 持久化快取降至約 1/8，靠的是放棄長存局部狀態
技術報告指出，前代持久化 KV 快取中，SWA KV 接近一半。全域資料可能在較長時間後仍被重用，局部狀態的價值卻集中在活躍會話的幾分鐘。把兩者保存同樣久，會留下大量很少再用到的局部資料。
V4.1 繼續長期保存全域 KV，Encoder 的 SWA 狀態改放短期記憶體池，依分鐘級期限淘汰；SWA KV 不再進入長期持久化快取。若全域前綴命中，但 Encoder 局部狀態已過期，系統回放已快取前綴末尾的 128 token，近似恢復局部狀態，並處理新增輸入。命中的全域前綴可以重用，不必因重建局部狀態就全部重寫。
按報告描述的舊組成，可用以下算式理解節省來源：
約 1/2 的原有全域部分 × 約 1/4 的全域體積＝約 1/8
這是架構、精度與保存策略共同形成的結果。1/8 的比較條件是相同工作負載，無法直接套用到任意服務的硬碟需求。
Decoder 的處理方式另有差別：每次 prefill 都將整段提示末尾 128 token 跑過後 20 層，建立接下來生成所需的局部狀態。這些狀態供當次生成使用，不放進前綴持久化快取。
最需要保留的限定是「近似」。多層局部注意力會累積依賴範圍；報告以 20 層 Decoder 為例，精確回放的理論長度為 20×128＝2560 token。有限回放只用最後 128 token，截斷更早的局部依賴。報告表示品質影響很小，卻沒有宣稱它與完整計算數學等價，Decoder 也在後訓練中模擬這種回放限制。
對重複利用長提示的產品，應直接測試這個差異。冷啟動、全域與局部都命中、只有全域命中，是不同狀態；平均延遲會把重建成本藏起來。測試集也要保留依賴較早細節的任務，不能只用能從最後一段回答的問題。快取生命週期與回放條件見技術報告 §3.2。
6. CED 省輸入計算，其他設計各有不同節省範圍
把改善全部歸給 CED，會讓部署團隊找錯瓶頸。CED 讓 Decoder 的全域記憶可由 Encoder 輸出建立，降低長輸入計算；CSA2 減少重複保存與部分重複檢索；FP4 降低主 KV 的體積；稀疏選擇與分層檢索限制讀取量及後續搜尋範圍；有限回放則減少局部狀態長存，並控制 Decoder 補算長度。
按每 token 890 bytes 計算，100 萬 token 的全域 KV 約為十進位 0.89 GB。這是一個有用的容量估算，但不包含模型權重、局部快取、工作區與其他執行開銷，不能據此宣稱一般裝置就能完整部署這個模型。
報告另一項結果是上下文從 4K 增至 1M、長度增為 256 倍時，單 token decode 的精度加權 FLOPs 只增加約 25%。其中 BF16、FP8、FP4 分別按 1、0.5、0.25 加權。這張計算量曲線衡量的是整套設計，沒有提供相同幅度的端到端延遲或吞吐保證。
評估部署，先確認引擎實際支援到哪裡
官方模型資料庫提供參考推論程式，但 README 明確定位為方便閱讀的實作，並非正式環境的服務引擎。生成路徑採一般自回歸流程；model.py 的簡短 decode 自我測試以未初始化權重檢查運作串接，不能拿來證明模型回答品質。官方推論 README把這些限制寫得很清楚。
整合時至少要分開驗證協定與執行。官方 deepseek-recipe 提供 Rust 與 Python 的格式轉換和協定工具，但它不負責模型推論，也不替服務執行工具呼叫。能正確產生提示格式，只完成介面的一部分；CSA2、低精度快取與有限回放仍需要推論執行環境支援。deepseek-recipe 官方儲存庫可用來確認這條界線。
成本評估則應回到自己的流量。輸入長、輸出短且常重用前綴的服務，較可能受益於這套設計；若請求幾乎不重用前綴，持久化快取的優勢便不會完整反映在帳單。這是依架構作出的部署判斷，仍需以實測確認。報告未提供可直接套用到每家服務的毛利率改善，應分別量測每次請求的 GPU 時間、快取儲存與資料搬運，再換算單位服務成本。
常見問題
DeepSeek V4.1 Flash 的 890 bytes 包含模型權重嗎？
不包含。890 bytes/token 是全域 KV 快取口徑；100 萬 token 約為十進位 0.89 GB，仍需另外計入權重、局部 SWA 快取、工作區與執行開銷。
Prefill 約 8B、decode 約 16B，代表有兩個獨立模型嗎？
這是同一套 CED 架構在不同階段的啟動參數量。長輸入主要經過前 20 層，生成則經過完整 40 層；Decoder 還須處理提示末尾 128 token 以建立局部狀態。
Top-512 會刪除其他歷史內容嗎？
不會。它限制本次注意力讀取的全域記錄數，未選到的記錄仍可供後續查詢。全域快取總量仍隨上下文長度成長。
有限回放能精確恢復原本的局部狀態嗎？
不能保證數學等價。20 層 Decoder 的理論精確回放長度為 2560 token，實際只回放最後 128 token。模型透過後訓練適應截斷，正式導入仍應測試對任務品質的影響。
權威來源
- DeepSeek V4.1 Flash 技術報告：CED、CSA2、FP4 與快取部署條件
- YoCo 原始論文：前段產生全域快取、後段重用的研究脈絡
- DeepSeek V4.1 Flash 官方模型卡：模型與開放權重資料
- 官方推論 README：參考實作、自我測試與正式服務的界線
- deepseek-recipe：協定轉換工具的能力範圍
Author Insight
我會優先測量局部快取過期後的請求。890 bytes 很醒目，但正式服務要承擔的是使用者離開幾分鐘、回來繼續對話時的品質與等待時間。若只有全域前綴命中的測試依然穩定，再討論要把多少儲存預算轉成更多並行會話，才有依據。光是證明模型能裝進記憶體，還沒回答這個問題。
術語表
| 術語 | 本文用法 |
|---|---|
| Prefill | 處理已知輸入並建立快取 |
| Decode | 逐步產生新 token |
| CED | 因果編碼器—解碼器，前段輸出用於建立後段全域 KV |
| CSA2 | 結合壓縮、稀疏選擇與跨層共享的注意力機制 |
| SWA | 滑動視窗注意力，本模型局部視窗為 128 token |
| 全域 KV | 隨上下文成長、可跨層共享的注意力記錄 |
| 有限回放 | 以受限長度重算局部狀態，結果為近似 |
| 精度加權 FLOPs | 依數值精度給不同權重的運算量，不能直接當作延遲 |
