# 影片筆記：DeepSeek V4.1：40层模型，读入只跑20层？CED架构与KV Cache优化


<!-- VIDEONOTE_PUBLICATION_WARNINGS_BEGIN -->
## ⚠️ 可先使用，仍有待修正項目

本筆記已完成可閱讀的逐字稿與時間跳轉；下列為待處理問題，建議播放原片確認。

- 待修正：逐字稿全文快速校讀未完成（已保留自動字幕/原始逐字稿並繼續生成筆記。；未完成的全文速讀項目可在精進模式回聽確認。）

<!-- VIDEONOTE_PUBLICATION_WARNINGS_END -->

## 一句話總結

DeepSeek V4.1 Flash 透過引入 CED（因果編碼器-解碼器）架構，在讀入階段僅計算前 20 層，後 20 層直接投影生成 KV 緩存，將計算量減半；同時結合「有界回放」機制與三層存儲架構，將滑動窗口 KV 從硬碟移至短暫記憶體池，使持久化緩存成本降至原來的 1%，在維持性能的前提下大幅降低算力與存儲開銷。

## 核心重點

1.  **計算優化（CED 技術）**：
    *   將 40 層模型分為前 20 層（編碼器）與後 20 層（解碼器）。
    *   讀入上下文（Prefill）時，僅計算前 20 層。
    *   後 20 層的 KV 緩存直接由前 20 層的輸出經投影矩陣投影而來，跳過後 20 層的計算，激活參數從 160 億降至 80 億。
    *   生成階段才使用完整 160 億參數。

2.  **存儲優化（有界回放與三層存儲）**：
    *   **問題**：舊版將滑動窗口 KV 存於硬碟，成本高且利用率低（短時間高頻後不再使用）。
    *   **新架構**：
        *   **顯存**：存放正在使用的「全局 KV」。
        *   **機器記憶體池**：所有機器拿出 10% 記憶體拼成池子，存放「滑動窗口 KV」，有效期僅幾分鐘，過期立即騰出。
        *   **硬碟**：僅存放「全局 KV」，保留 72 小時以上供長期對話。
    *   **未命中處理**：若記憶體池未命中，執行「有界回放」，僅回放末尾 128 個 Token 進行近似計算，而非完整重算。

3.  **成效**：
    *   計算量降低約一半。
    *   持久化緩存降至原來的 1%。
    *   性能基本不受影響，特別適合 Agent 多輪短消息場景。

## 詳細大綱

### 一、 核心問題與目標
*   **背景**：承接上一集關於 DeepSeek V4.1 Flash 降低 KV Cache 存儲開銷的討論。
*   **目標**：減少「脫離計算」（Prefill/讀入階段）與「緩存成本」。
*   **核心手段**：
    1.  重新計算上下文時，只計算前一半層數，後一半直接套用已有結果。
    2.  部分短期緩存不再長期保存，改為需要時重新計算。
*   **預期成果**：
    *   計算量降低約一半。
    *   持久化緩存降至原來的 1%。
    *   性能基本不受影響。

### 二、 為什麼只計算一半層數足夠？（CED 技術解析）
*   **場景痛點**：
    *   Agent 修補 Bug 時，上下文堆積至 50 萬 Token。
    *   每次工具調用返回結果接入上下文，模型需重新讀入（Prefill）。
    *   若緩存未命中，整段 50 萬 Token 需重算 40 層，算力與存儲壓力巨大。
*   **CED (Causal Encoder-Decoder) 設計**：
    *   將 40 層模型分為前後兩半：
        *   **前 20 層（編碼器）**：負責讀入上下文。
        *   **後 20 層（解碼器）**：負責生成。
    *   **關鍵機制**：解碼器所需的 KV 緩存，直接從編碼器的輸出經過「投影矩陣」投影而來。
    *   **優勢**：讀入新內容時，後 20 層無需計算，直接投影得到全局 KV。
*   **與 Yoko 論文的区别**：
    *   Yoko 論文：後半層共用同一份 KV，信息容量少。
    *   V4.1 改進：
        1.  投影矩陣可逐層不同，每層擁有獨立 KV，容量更大。
        2.  滑動窗口部分不投影，每層自行計算，保留局部信息深度。
*   **計算節省**：
    *   讀入階段：僅跑前 20 層，激活參數從 160 億降至 80 億。
    *   生成階段：才使用完整的 160 億參數。

### 三、 為什麼重新計算比一直存緩存更划算？（滑動窗口處理）
*   **問題來源**：
    *   解碼器在讀入階段未運行，導致其「滑動窗口 KV」為空。
    *   生成第一個 Token 時，需使用前 128 個 Token 的窗口 KV。
    *   若精確補齊，需回溯至第 20 層對應的 2560 個 Token 前開始重算（因層層疊加視野）。
    *   對 Agent 多輪短消息場景，回溯 2560 個 Token 開銷過大。
*   **解決方案：滑動窗口有界回放 (Bounded Replay)**
    *   **策略**：不回退 2560 個，僅回退末尾 128 個 Token。
    *   **執行**：將這 128 個 Token 的編碼器輸出送進解碼器跑一遍。
    *   **開銷**：128 個 Token × 20 層，相較於 50 萬 Token 可忽略不計。
    *   **視野限制**：窗口僅在 128 個 Token 內查看，更遠處信息由全局分支處理。
*   **有效性驗證**：
    *   參考 *PowerAttention* 研究：遠處信息經層層傳遞已衰減至可忽略，窗口僅負責眼前段。
    *   後訓練階段已模擬此近似行為，實測幾乎不掉點。

### 四、 硬碟緩存成本為何降至 1%？
*   **V4 舊版存儲模式**：
    *   **全局 KV**：整段存儲，若新請求開頭匹配則整段復用。
    *   **滑動窗口 KV**：不整段存，僅存提示詞末尾與回答末尾各 128 個 Token。
    *   **淘汰機制**：最久未使用先刪除。
    *   **問題**：滑動窗口 KV 佔持久化緩存近一半，且訪問模式為「短時間高頻使用後不再使用」，存入保留 72 小時的硬碟中「又貴又沒用」。
*   **V4.1 新存儲架構（三層存儲）**：
    1.  **顯存**：存放正在使用的「全局 KV」（每 Token 890 字節）。
    2.  **機器記憶體池**：
        *   所有機器拿出 10% 記憶體拼成池子（非顯存）。
        *   存放「滑動窗口 KV」。
        *   有效期僅幾分鐘，過期立即騰出服務新繪畫。
        *   處理高周轉負載，服務大多數進行中的繪畫。
    3.  **硬碟**：
        *   僅存放「全局 KV」。
        *   保留 72 小時以上，供多日後用戶回來繼續對話。
*   **未命中處理**：
    *   若記憶體池未命中（滑動窗口已過期），執行「有界回放」。
    *   僅回放末尾 128 個 Token 補齊窗口 KV。
    *   報告稱此近似對回答質量影響極小，將「災難性未命中」轉化為「優雅且便宜的降級」。

### 五、 總結與局限
*   **成本計算邏輯**：
    *   滑動窗口 KV 不存硬碟 → 持久化緩存減少一半。
    *   剩餘全局 KV 為上一代的 1/4（基於上一集共用機制）。
    *   總持久化緩存 = 1/2 × 1/4 = 1/8（約 12.5%，報告稱降至 1% 可能包含其他壓縮或特定定義，但筆記依逐字稿記錄為「降到原来的1%」與「八分之一」的推導）。
*   **場景適配**：
    *   收益最大於「多輪每輪短」的 Agent 繪畫場景。
    *   對於一次性幾十萬 Token 的長文檔，僅節省算力一半，硬碟節省效益有限。
*   **局限性**：
    1.  有界回放是近似值，尤其在緩存與新內容接縫處，尚需壓力測試與真實負載觀察。
    2.  收益與場景綁定，長文檔場景硬碟節省效益低。
    3.  記憶體池比例（10%）、有效期（幾分鐘）、硬碟保留（72小時）均基於 DeepSeek 自家線上負載調優，換其他負載分布需重新測試未命中率與回放开銷。

## 工具 / 模型 / 名詞整理

*   **模型/版本**：DeepSeek V4.1 Flash、DeepSeek V4、DeepSeek
*   **技術/機制名稱**：
    *   KV Cache (KV 緩存)
    *   Prefill (脫離計算/讀入階段)
    *   CED (Causal Encoder-Decoder，因果編碼器-解碼器)
    *   Yoko (2024年論文名稱)
    *   PowerAttention (研究/工作名稱)
    *   滑動窗口 (Sliding Window)
    *   全局分支 / 局部分支
    *   有界回放 (Bounded Replay)
    *   Zero SWA Catching (V4 報告提及的概念)
    *   後訓練 (Post-training)
    *   稀疏注意力 (Sparse Attention)
    *   MLA、MOE、ROPE、GRPO、VLLM、SGLAN (提及的相關技術或工具)
*   **其他專有名詞**：
    *   Agent
    *   Token
    *   顯存 (VRAM)
    *   硬碟 (Hard Disk)
    *   記憶體池 (Memory Pool)

## 操作流程整理

1.  **讀入階段 (Prefill)**：
    *   輸入上下文（如 50 萬 Token）。
    *   僅計算前 20 層（編碼器）。
    *   將前 20 層輸出經投影矩陣投影，直接生成後 20 層（解碼器）所需的 KV 緩存。
    *   跳過後 20 層的實際計算，降低激活參數需求。

2.  **生成階段**：
    *   使用完整的 160 億參數模型進行生成。
    *   若為新請求且無緩存命中，執行上述讀入流程。

3.  **緩存管理與未命中處理**：
    *   **全局 KV**：存於顯存（使用中）或硬碟（長期保留 >72小時）。
    *   **滑動窗口 KV**：
        *   優先從機器記憶體池（10% 總記憶體）讀取，有效期僅幾分鐘。
        *   若記憶體池未命中（過期）：
            *   執行「有界回放」：僅回放末尾 128 個 Token 的編碼器輸出。
            *   將這 128 個 Token 送進解碼器跑一遍，補齊窗口 KV。
            *   此操作開銷極小，視為對回答質量影響極小的近似降級。

## 值得注意的限制或風險

1.  **近似計算的準確性**：有界回放僅回放末尾 128 個 Token，屬於近似值。尤其在緩存與新內容接縫處，尚需壓力測試與真實負載觀察以確認是否影響回答質量。
2.  **場景綁定性**：該架構收益最大於「多輪每輪短」的 Agent 場景。對於一次性幾十萬 Token 的長文檔，僅節省算力一半，硬碟節省效益有限。
3.  **參數調優依賴**：記憶體池比例（10%）、有效期（幾分鐘）、硬碟保留（72小時）均基於 DeepSeek 自家線上負載調優。若換其他負載分布，需重新測試未命中率與回放开銷。
4.  **數值一致性疑點**：筆記中記錄報告稱持久化緩存降至 1%，但推導邏輯為 1/2 × 1/4 = 1/8 (12.5%)，兩者存在顯著數值差異，需確認是否包含其他壓縮機制或定義差異。

## 逐字稿辨識疑點

*   **SGLAN / 固鼓鼠**：逐字稿中提到「VLLM SGLAN 固鼓鼠」，聽寫可能為「SGLang」或其他工具名稱，但依規則標為疑點，不自行更正。
*   **獨入**：逐字稿多次使用「獨入」，結合上下文應指「讀入」或「Prefill」，但依規則保留原詞或標註為聽寫疑點。
*   **繪畫**：逐字稿中多次出現「繪畫」（如「正在進行的繪畫」、「多輪短消息的 agent 繪畫」），結合 Agent 與上下文場景，疑為「對話」或「會話」的聽寫錯誤，但依規則標為疑點。
*   **負層**：逐字稿提到「真正做投影的是解碼器那一個負層」，疑為「最後一層」或「特定層」的聽寫錯誤，標為疑點。
*   **1% 與 八分之一**：逐字稿結論提到「持久化缓存降到原来的1%」，但後文推導為「二分之一乘四分之一 八分之一」。若 1/8 等於 12.5%，則與 1% 有顯著數值差異，此處依規則僅記錄原文，不判斷是否為口誤。

## 可延伸追問

1.  CED 架構中，投影矩陣逐層不同的具體訓練方法為何？如何確保投影後的 KV 與直接計算的 KV 足夠接近？
2.  「有界回放」中，僅回放 128 個 Token 的理論依據是什麼？若上下文長度遠超此範圍，衰減效應是否仍成立？
3.  機器記憶體池的 10% 比例是如何確定的？若負載模式改變（如長文本比例增加），該比例是否需要動態調整？
4.  報告中提到的 1% 緩存成本與推導的 1/8 (12.5%) 之間的差異具體來自哪些壓縮技術或定義調整？