很多人談長上下文，第一反應仍是模型要多大、視窗要多長。但在實際系統裡，更難處理的成本往往不是模型參數，而是提示被讀過之後留下的狀態：它必須被保存、搬運、讀取，還要在每次請求重用。這個狀態就是 KV cache。當上下文拉長，GPU 記憶體被它吃掉，跨卡傳輸和冷啟動也跟著變慢；模型看似能讀更多，產品卻可能因成本與延遲而不敢真的開放。

arXiv 近期的〈Learned Transform Coding of the Prompt KV Cache in Hybrid Language Models〉提出 DCKV，把 KV cache 當成可以學習壓縮與解壓縮的訊號，而不是只能用固定精度儲存的中間產物。在 Qwen3.5-2B 的長 context 測試中，每 token 的記憶體占用可降到 bf16 的 1/55 以上，分數最多下降 1.8 點；再壓到 1/100 以上，最多下降 3.6 點。數字真正重要的地方，不是宣稱「壓得越小越好」，而是它畫出了品質與成本之間的新斜率。

這個斜率會改變系統設計的基本問題。過去工程師常在「完整 cache 但昂貴」和「截斷上下文但失去資訊」之間二選一；有了可調壓縮率，則可以依請求價值、上下文位置與延遲預算分配不同的保真度。客服摘要也許接受更激進的壓縮，程式除錯或法規檢索則保留關鍵片段；熱資料留在 GPU，冷資料以更高壓縮率放到主記憶體或遠端儲存，需要時再搬回來。

但這不是免費的記憶體魔法。壓縮與還原會消耗算力，錯誤也可能集中在少數對答案關鍵的 token；「平均只掉幾分」不能取代對任務分布、最壞情況和多輪累積誤差的測量。真正成熟的產品，應該把 cache 視為有生命週期的資產，為它設計分層儲存、品質監控與可回退路徑，而不是只在模型部署表上填一個上下文長度。

長上下文的競爭，最後可能不是誰把視窗做得最大，而是誰能以可接受的品質，把提示狀態存得更久、搬得更快、用得更便宜。DCKV 的啟示正在這裡：模型能力的邊界，往往由記憶體系統決定；一旦壓縮品質的成本斜率變得漂亮，原本只能展示的長上下文，才有機會變成每天都用得起的功能。