緩存修復更看鄰近

：從「重算整段」到「只補鄰近」的預算思維轉向 在長上下文模型日益普及的今天，KV 緩存（KV Cache）的修復策略正出現一道關鍵轉折。過去，只要上下文被改動，模型往往必須從頭重算整段前綴，代價高昂；如今的新思路則不再追求全量重來，而是把「編輯後的重算」重新定義成一道預算問題——只在真正受影響的鄰近區間內補算，讓有限資源精準落在必要之處。這項轉變的核心，在於對「重算範圍」的重新劃分。傳統做法視上下文為一條必須整體維護的長鏈，任何一處插入或刪除，都會牽動後續所有位置的緩存失效，於是整段前綴被迫重跑。新的方法則承認一個事實：改動的影響其實具有局部性，距離編輯點越遠的區塊，其緩存往往仍然有效。

既然如此，就沒有必要為了一處小修改而犧牲全部已算好的成果。換句話說，修復的目標從「修得多完整」轉為「修得多近」。系統不再試圖把每一段緩存都還原到完美狀態，而是沿著編輯位置向兩側圈出一個必要鄰域，僅在此範圍內重新計算。這個鄰域的邊界怎麼劃、要往前覆蓋多少、往後延伸多遠，本質上是一道預算分配的題目——在延遲與精度之間，找出最划算的那筆邊際。效果具體體現在兩個數字上。其一是連續窗口的設計，能追回大約 0.94 的邊際，幾乎補平了重算所帶來的落差，意味著局部補算在品質上已相當接近全量重算。其二是速度，整體比全量預填充（full prefill）快上 13 到 21 倍。

當精度幾乎不掉、速度卻提升一個量級，過往「品質與成本二選一」的取捨，也就不再成立。這樣的特性，讓它特別適合 RAG（檢索增強生成）與智能體的長上下文場景。這兩類工作負載的共同特徵，是內容被頻繁插入、裁剪與重組：檢索結果不斷更新，對話記憶持續增減，工具回傳的片段來來去去。在這種反覆編輯的節奏下，快取命中區塊經常被打斷，若每次都退回全量重算，成本將迅速失控。鄰近修復恰好對上了這種節奏。從系統設計的角度看，這也代表緩存管理的重心正在位移。以往工程師關注的是「命中率」這個單一指標，盡可能讓更多前綴被重複利用；但當上下文持續變動，單純追求命中率已不足以描述真實開銷。

真正決定效能的，是每次失效之後，需要補算的區間有多大。命中率再高，若一有改動就得全盤重來，實際延遲依然難看。因此，「鄰近性」成為新的競爭維度。誰能把重算範圍收得越貼近改動處，誰就越能在延遲與精度之間拿到那筆邊際。這不只是一項工程優化，更是一種成本模型的轉換：把不可控的全量開銷，拆解成可估算、可調配的局部預算，讓開發者能依場景需求決定要保守一點還是激進一點。值得注意的是，這種思路並非要否定全量重算的正確性，而是承認多數情況下並不需要它。全量重算像是每次都把整棟房子重建，穩妥卻昂貴；鄰近修復則像是只修補受損的那面牆，前提是能準確判斷損害範圍。

這個判斷本身，就成了技術的關鍵——圈得太大則浪費，圈得太小則失真，連續窗口的設計正是為了在兩者間取得平衡。對 RAG 應用而言，這意味著檢索到的文件可以在變動時被更便宜地重新納入上下文，而不必讓整個提示重新計算。對智能體而言，長達數十輪的對話與工具調用紀錄，也能在每次新增內容後以更低代價延續，而不至於因為上下文膨脹而拖垮回應速度。這些都是過去難以兼顧、如今開始鬆動的瓶頸。歸根結底，緩存修復比拼的已經不是「修得多完整」，而是「修得多近」。當局部補算能在品質上追回 0.94 的邊際、在速度上取得 13 到 21 倍的優勢，過去被視為必然的全量重算，就從預設選項降格為最後手段。

這場轉向的意義，在於它讓長上下文的成本結構變得更可控、更貼近真實使用情境。展望未來，隨著上下文長度持續增長、編輯頻率持續提高，這種以鄰近區間為單位的修復策略，可能成為長上下文系統的標準配置。真正拉開差距的，將不再只是模型本身的規模，而是誰能把重算預算花得最精準——在最靠近改動的地方，用最少的力氣，換回最接近完整的結果。