（來源：量子位 作者：金磊）
拿Agent做Coding，想必大家都已經很熟悉了。
不過，如果我們把目光從聊天窗口移到背后的數據中心，事情就沒那么簡單了。
一個Coding Agent改跨十幾個文件的bug，需要反復讀代碼、查資料、跑測試。前幾輪交互可能還很順暢，但任務繼續跑下去，系統要處理的歷史信息也會越積越多。
當成千上萬個Agent同時這樣干活，運營方就可能遇到一個頭疼的問題：服務器還在跑，能接住的并發卻越來越吃緊，有些請求連吐出第一個Token都要等上好一會兒。
難道只能繼續加GPU？
非也非也。
模型還是那個模型，服務器也還是那個服務器，問題的根兒啊，其實是出在了記憶。
因為大模型每生成一個新的Token，都還要繼續用到前文的信息。為了不用每次從頭計算，系統會把前面已經算好的中間結果保存起來；會話越聊越長，這份記憶自然也就越堆越厚。
一旦顯存裝不下，部分緩存被清走，等Agent下一輪又需要這些歷史信息時，就可能重新做一遍Prefill。前面明明已經算過的東西，又得花GPU時間再算一次。
尤其是到了Agent時代，AI很少干一問一答的事兒，更多是那種反復需要思考、規劃和行動的任務，期間會不斷積累會話歷史、檢索證據、工具結果和中間狀態等等。
于是乎，一個過去藏在大模型推理內部、普通用戶幾乎感知不到的東西，就這樣被推到了臺面兒上——KV Cache。
它的特點，說起來就一個字：大。但運營方又不能為了省空間，任由已經算過的內容反復占用GPU重算。所以，長上下文推理要算的這筆賬，也就從算力延伸到了存儲、搬運和復用。
而這件事的破局之道，并不是你以為的GPU，而是——CPU。
AI的記憶怎么就越來越貴了？
我們先把KV Cache這件事說清楚。
對于采用因果自注意力的Transformer模型來說，前面處理過的Token，會在注意力層中留下對應的Key和Value。模型生成后續Token時，還能繼續使用這些結果。推理系統把它們緩存起來，就有了KV Cache。
你可以把它理解成模型讀書時做的筆記。后面再遇到需要聯系上文的地方，模型可以調用筆記，省去對已有Token的重復計算。
所以，我們這里說的記憶，指的是推理過程中留下的中間狀態，模型的權重并沒有因此發生變化。
這份筆記確實能省計算，但它也是實實在在要占地方的。而且，Agent讀的東西越多，服務器要替它保存的筆記往往就越厚。
那么這個增長到底有多明顯呢？
我們拿Qwen3-8B算一筆賬。按照它的公開模型配置，在KV Cache采用BF16或FP16、每個數值占2字節的條件下，每個Token對應的KV數據是147456字節，也就是約147KB。這還沒有計入緩存管理等額外開銷。
為什么一個Token會帶出這么大一份緩存？因為系統保存的并不是這個Token的文字本身，而是它在多層注意力計算中對應的Key和Value。按這個模型的結構，計算式就是：2份K/V × 36層 × 8個KV頭 × 每頭128維 × 2字節。
接下來，我們只借用這個每Token開銷，做一次百萬上下文的容量推演：如果需要緩存100萬個Token，對應的KV數據就約為147GB。注意，這里的1M是測算假設，不代表Qwen3-8B實際支持百萬上下文；它的官方說明是原生32768 Token，采用YaRN可擴展到131072 Token。
單個請求已經如此，如果把請求規模也放大呢？假設一個服務有300萬日活用戶，每人每天發出10個請求，而且每個請求都按前面的1M上下文計算，一天就是3000萬個請求。
先不考慮壓縮和共享復用，按每個請求約147GB全量累加，對應的日累計KV數據規模就是：300萬 × 10 × 147GB ≈ 4410PB。如果日活再增加到3億，相同假設下，這個數字還會放大100倍，達到約441000PB，也就是441EB。
不過，這里得分清兩件事：一天的請求累計涉及多少KV數據，和數據中心同時需要存下多少KV數據，不是一回事。上面是每次請求都獨立、全量計數的規模推演，不能直接當作存儲采購清單。
實際要配多大的緩存池，運營方還得看高峰時有多少請求同時運行、緩存要留多久、哪些前綴能夠共享，以及壓縮和淘汰策略。已經復用的同一份緩存，也不該因為被請求多次就重復占一份容量。
當然，不同模型的“筆記本”也不一樣。模型層數、KV頭數量、緩存精度等都會影響大小，不能只看參數量。上面的數字不是某個服務的真實用量，卻能說明運營方為什么要格外關注這份“記憶”：上下文長度和請求規模，會一起把緩存的賬越算越大。
而GPU的顯存，還要放模型權重和運行時的其他數據。大家共用這么多空間，KV Cache占得越多，系統留給其他請求的余地就可能越小。
這時候，推理系統就得做取舍了：減少同時處理的請求，把部分緩存卸載到其他存儲層，或者清理暫時不用的緩存。
再拿前面的Coding Agent來說。它可能正在等工具跑測試，系統趁這個空當，把它的一部分歷史緩存清掉了。等測試結果返回，Agent準備接著干活，卻發現需要用的緩存已經不在了。
如果其他存儲層也沒保存這份數據，模型就得重新處理相應的歷史輸入、重建緩存。這個處理輸入的階段叫Prefill，輸入越長，通常就越費時。用戶等待首個Token的時間，也就是TTFT，便可能跟著增加。
算過一遍的內容，過一會兒又得再算。對運營方來說，消耗掉的不只是電和時間，還有這批GPU原本可以用來處理新任務、生成新Token的機會。
這也解釋了，為什么KV Cache再大，運營方仍然要認真考慮怎么把它用好。
從成本角度看，GPU應該盡量把資源花在必要的新輸入處理和新Token生成上，少為已經處理過、又可以復用的歷史內容重復做Prefill。KV Cache保留下來的，正是這部分已有計算的成果。
當然，這不意味著所有緩存都得永久保存。真正要算的是：保留和取回一份緩存，能不能比下次重算更劃算？誰能把這筆賬算好，誰就更有機會用同一套設備服務更多請求。
GPU生成Token，CPU開始接管記憶
聊到這里，你可能已經想到了，顯存放不下，難道不能先存到別處，等要用的時候再拿回來？
可以，這也正是“以存代算”的思路。
在服務器里，GPU顯存之外還有CPU側的DDR內存、本地SSD，以及遠端存儲。它們的容量、速度和成本各不相同，正好可以用來存放不同活躍程度的緩存。
例如眼下正在生成回答，需要頻繁訪問的數據，就留在GPU的高帶寬顯存HBM里；短時間內可能繼續用到的緩存，可以先放進CPU側的DDR內存；至于更久沒有訪問、但還值得保留的歷史緩存，則可以繼續下沉到SSD或遠端存儲。
再聚焦到Coding Agent的任務里，就是它寫代碼時，相關緩存盡量留在GPU側；任務暫停后，系統可以把緩存轉存到內存；如果這段會話很久沒繼續，再考慮把數據移到更下一層。用戶回來后，系統根據緩存命中情況，把需要的部分取回來。
對運營方來說，這樣安排的直接好處是：顯存不用一直替所有歷史會話占著位置，騰出的空間可以交給正在運行的請求。
不過，把東西搬出去只是第一步。哪些數據可以搬、應該放在哪里、什么時候得提前取回來，總得有個地方統一管理。
CPU就在這里發揮作用。
推理服務運行在主機側的管理邏輯，需要跟蹤會話狀態、剩余容量和緩存訪問情況。CPU連接的大容量內存和存儲，也為顯存之外的緩存池提供了基礎。系統可以結合這些信息，決定一份KV Cache接下來該留在哪一層。
這類機制其實已經出現在一些推理框架里了。例如，vLLM的KV Offloading支持將緩存塊卸載到CPU內存，還可以配置次級存儲層。在它描述的多層方案里，次級存儲與GPU之間的數據傳輸，會經過CPU側的緩存層。
但這里還有個問題，那就是數據是存下來了，搬回來會不會更慢？
畢竟，DDR、SSD和遠端存儲的訪問條件各不相同。假如取回緩存比重新計算還費時，用戶還是得等，甚至可能等得更久。所以，系統需要根據訪問頻率和傳輸開銷安排緩存，不能一股腦地把數據全塞到硬盤里。
要減少搬運量，另一個辦法就是壓縮。數據變小了，同樣的空間能存得更多，傳輸時要搬的字節也更少。
可壓縮也不是白來的，壓縮和解壓都要花時間，如果全讓通用CPU核心來干，又可能擠占請求調度等工作需要的資源。
更麻煩的是，KV Cache本身就是大體量數據，壓縮和解壓的速度如果跟不上GPU側的數據吞吐，壓縮環節反而會成為新的瓶頸。單純依靠通用CPU核心做軟件壓縮，很難同時兼顧高吞吐和CPU資源占用。
這也是QAT的意義所在。它把壓縮、解壓交給專用硬件處理，在提升吞吐的同時釋放通用CPU核心。相比只依賴CPU Core的軟件方案，這種內置專用壓縮加速能力，也構成了英特爾在KV Cache分層卸載上的一個差異化優勢。
于是問題就不只是能不能壓，還變成了能不能壓得足夠快。
對此，CPU老巨頭英特爾給出了一套面向數據中心的KV Cache優化思路。
記憶存得下，還要用得上
圍繞KV Cache，英特爾布局了KV Shrink、KV Fuse、KV Cascade和KV Infinity四個技術方向。
名字雖然看著多，但我們用一張表格，根據它們各自要解決的問題來分類，就一目了然了：
其中，KV Shrink已經有較具體的實現和測試披露，我們先來重點看看它。
KV Shrink可以把前面講的分層管理與硬件壓縮結合起來，并提供冷熱調度API，讓業務系統按自己的策略決定緩存什么時候下沉、什么時候回載。內存吃緊時，系統還可以把較冷的數據繼續轉存到SSD等下一層介質。
而負責分擔壓縮工作的，是英特爾的QAT（QuickAssist Technology）。
它能夠把壓縮、解壓等任務交給專用加速單元，減少對通用CPU核心的占用。英特爾從第四代至強可擴展處理器的相關型號開始集成QAT硬件。
這么一來，CPU側的管理邏輯繼續負責調度，專用硬件接過壓縮任務，系統便有機會在控制額外開銷的同時，縮小緩存體積。
英特爾還做了一個更細的調整：重新排列KV Cache的存儲格式，讓壓縮算法更容易壓縮這些數據。
重排后，壓縮所節省的空間從原先的10%以上增加到20%以上，空間降幅約為20%至30%。這條路徑采用無損壓縮，解壓后能夠恢復原始KV數據，不會因壓縮而丟失數據。
雖然20%-30%這個數字乍一看似乎沒那么夸張，但把緩存池的規模放大，差別就出來了。
例如，一個數據中心需要保留500TB的KV Cache，如果能壓縮掉30%，對應的就是約150TB空間。這里算的是實際緩存池的容量，和前面按請求累加的日累計數據量不同。至于運營方最終能省下多少費用，還得結合存儲介質、保留時間和業務負載來算，不能直接給總成本也打個七折。
空間這塊算是有收益了，那速度又怎么樣呢？
在英特爾給出的一組測試中，使用雙路至強金牌6554S處理器、兩張英偉達L20 GPU和Qwen3-32B模型，在80%緩存命中率下，相較未開啟分層卸載的原生vLLM基線，KV Shrink在測試覆蓋的輸入長度和并發組合中，TTFT最高獲得約5倍加速。
除此之外，QAT硬件壓縮方案的整體性能約為CPU軟件壓縮方案的兩倍。在相同分層卸載機制下，相較不啟用壓縮，開啟QAT壓縮帶來的額外TTFT開銷低于10%。
從這兩項對照測試來看，壓縮確實會多一道工序，但在這組測試里，專用硬件把額外開銷控制在了較小范圍內，讓系統能夠用一定的時間代價換取存儲空間。
再來看一組面向Coding Agent服務的測試。
英特爾與道客聯合實驗室采用另一套配置進行測試：雙路至強金牌6554S、八張H800和Qwen3-32B FP8模型，緩存命中率同樣為80%。相較測試中的LMCache方案，KV Shrink在單路負載下的平均TTFT由129.81毫秒降至114.13毫秒，降幅約12.1%；八路并發時，降幅約為4.6%。
你會發現，換一套設備、換一個比較對象，加速幅度也變了。所以數據中心運營方真正部署時，還是要把自己的上下文長度、并發量和緩存命中率帶進去測試。業務里重復訪問歷史內容的機會越少，緩存復用能幫上的忙通常也越有限。
除了把一段會話存好，運營方承載的企業服務還可能遇到另一類需求：幾份文檔以前都處理過，現在想把它們組合起來用，能不能少算一點？
這就是KV Fuse關注的問題。但模型處理文檔時會受到前文和位置等因素影響，幾份獨立生成的KV Cache通常不能直接拼接。KV Fuse嘗試通過緩存融合和部分重計算，保留其中能夠復用的工作。
如果問題出在“給模型看的東西太多”，KV Cascade則嘗試先請輔助模型做篩選或處理，把相關內容交給主模型。例如，一大堆文檔里只有部分信息和當前問題有關，就可以先縮小主模型需要處理的范圍。
而KV Infinity面向持續增長的長任務，通過按需加載和預取，嘗試緩解緩存必須全部常駐HBM的壓力，讓系統能夠利用顯存之外的資源。具體能擴展到什么程度，仍然要看訪問方式和傳輸效率。
這些方向背后，英特爾想要做的事就已經比較清楚了：
讓CPU協助管理推理中產生的大量計算結果，再通過內存、存儲和專用加速單元，把保存和使用這些結果的成本降下來。
對于具備相應QAT硬件的至強服務器，這提供了一條利用已有平臺能力的優化路徑。當然，實際接入還要檢查內存、存儲和軟件等條件。
最后，再回到數據中心的那筆賬。單個用戶看到的，也許只是Coding Agent有沒有及時回答；運營方要考慮的，則是成千上萬個請求涌進來之后，系統還能不能以可接受的成本持續提供服務。
KV Cache越大，全部留在顯存里就越難；可如果把還有復用價值的緩存一清了之，GPU又得為同一段歷史反復開工。運營方需要在保存、搬運和重算之間找到合適的平衡。
英特爾押注KV Cache，爭取的正是這個位置：通過CPU側的管理、分層存儲和硬件壓縮，讓已有計算結果能以更低的代價被保留和再次使用。
GPU仍然負責模型計算，CPU和存儲系統則協助減少那些本可以避免的重復工作。至于方案值不值得部署，最終還得看真實負載下的響應時間、吞吐量，以及把服務器、內存、存儲和能耗都算進去的總成本。
畢竟，運營方買下昂貴的GPU，是希望它多干點新活兒。已經算過、又能復用的內容，就盡量別再付一次計算的賬。
最后，若是小伙伴們想要了解更多關于英特爾CPU的最新進展，歡迎鎖定9月22日-9月23日的英特爾技術創新與產業生態大會（關注【英特爾商用】報名參加）！
星空人工智能技術網 倡導尊重與保護知識產權。如發現本站文章存在版權等問題，煩請30天內提供版權疑問、身份證明、版權證明、聯系方式等發郵件至1851688011@qq.com我們將及時溝通與處理。！：首頁 > 星空人工智能產業 > AI大模型 » 把記憶交給CPU，大模型會變快