從 KV Cache 到 AI 內(nèi)存系統(tǒng)：大模型推理架構(gòu)的演進(jìn)

摘要 這篇文章想回答一個(gè)看似分散、其實(shí)高度統(tǒng)一的問題：為什么這兩年圍繞大模型推理的系統(tǒng)創(chuàng)新，越來越不像是在“優(yōu)化一個(gè)神經(jīng)網(wǎng)絡(luò)”，反而像是在“設(shè)計(jì)一個(gè)內(nèi)存系統(tǒng)”？ 如果把 2023 年以前的大模型工程敘事概括成“拼 FLOPS、拼 Tensor Core、拼訓(xùn)練吞吐”，那么 2024–2026 年的推理敘事，已經(jīng)明顯轉(zhuǎn)向了另一條主線：KV cache、TTFT/TPOT、continuous batching、prefix reuse、prefill/decode disaggregation、hierarchical cache、CXL memory pool。

這不是偶然。Transformer 的自回歸推理天然會(huì)把“歷史”變成一塊不斷增長、必須反復(fù)訪問的狀態(tài)；而 RLHF/RLVR、reasoning、agent workflow、長上下文和多輪交互，又把這塊狀態(tài)推到了系統(tǒng)設(shè)計(jì)的正中央。OpenRLHF 甚至直接指出，在 PPO 風(fēng)格的 RLHF/RLVR 里，inference 階段經(jīng)常占到總運(yùn)行時(shí)間的 90% 以上；同一時(shí)期，Mooncake、LMCache、Strata、KVFlow、Beluga、TraCT 這類系統(tǒng)則在從不同層面把 KV cache 提升為“一等公民”。1

站在今天回看，真正的變化不是“某個(gè) kernel 更快了”，而是推理系統(tǒng)的重心，正在從計(jì)算圖轉(zhuǎn)向內(nèi)存圖。本文會(huì)沿著這條線，把 Mac/Uma、NVIDIA/NVLink、FlashAttention、vLLM、RL rollout、Mooncake、LMCache、CXL，以及 2025–2026 的新論文串成一條完整主線。2

目錄

• ? 1. 大模型推理的本質(zhì)：Prefill vs Decoding

• ? 2. KV Cache：Transformer 推理的真正狀態(tài)變量

• ? 3. 為什么瓶頸會(huì)從 compute 轉(zhuǎn)向 memory

• ? 4. RL / Agent：為什么后訓(xùn)練把問題推向 decoding

• ? 5. 為什么 Mac / UMA 會(huì)重新變重要

• ? 6. 為什么 FlashAttention 救不了 decoding

• ? 7. 推理優(yōu)化的四層結(jié)構(gòu)：kernel、engine、model、hardware

• ? 8. Continuous Batching：從“請(qǐng)求級(jí)”到“token 級(jí)”調(diào)度

• ? 9. 模型結(jié)構(gòu)如何直接決定系統(tǒng)上限：MQA / GQA

• ? 10. KV Cache 其實(shí)是一種高度冗余的外部記憶

• ? 11. 為什么很多線上系統(tǒng)仍然在“重復(fù)計(jì)算歷史”

• ? 12. 第一代 KV-centric 架構(gòu)：DistServe、Mooncake、LMCache

• ? 13. 為什么 Mooncake / LMCache 不是終點(diǎn)

• ? 14. 新一代 Memory-centric 架構(gòu)：Strata、CAKE、R-KV、KVFlow、FastSwitch、CacheBlend

• ? 15. CXL：看起來像終極答案，為什么現(xiàn)實(shí)里還很難

• ? 16. LLM serving 正在變成一個(gè)“操作系統(tǒng)問題”

• ? 17. KV cache 之后是什么：Mamba、RWKV 與“在線壓縮記憶”

• ? 18. 結(jié)語：三條真正的主線

現(xiàn)代主流 LLM，大多沿著 GPT 這條 causal decoder-only Transformer 路線發(fā)展：輸入是“到目前為止的上下文”，輸出是“下一個(gè) token 的概率分布”。這與 BERT 這種 bidirectional encoder 路線的根本區(qū)別在于：GPT 類模型天然支持逐 token 自回歸生成，而 BERT 的預(yù)訓(xùn)練目標(biāo)是 masked language modeling，本質(zhì)上依賴左右文共同參與表示計(jì)算。換句話說，KV cache 只對(duì) causal decoder 天然成立，對(duì) BERT 這種雙向編碼器并不是一等機(jī)制。3

一旦把推理過程按執(zhí)行階段拆開，你會(huì)發(fā)現(xiàn) LLM serving 其實(shí)不是一個(gè)統(tǒng)一的工作負(fù)載，而是兩個(gè)物理性質(zhì)很不一樣的階段疊在一起。

第一階段是 prefill。它讀取整段輸入 prompt，對(duì)所有輸入 token 做一次前向傳播，并為每一層生成后續(xù)要復(fù)用的 K/V 狀態(tài)。這個(gè)階段的并行度高、矩陣乘比例大、GPU Tensor Core 能用得很滿，所以更接近我們熟悉的“訓(xùn)練前向”形態(tài)。Sarathi-Serve 和 DistServe 都明確把 prefill 視為高延遲、但能顯著吃滿 GPU 計(jì)算資源的階段。4

第二階段是 decoding。模型每次只生成一個(gè) token，然后把這個(gè) token 追加到歷史，再生成下一個(gè) token。這個(gè)階段每一步的算子規(guī)模不大，GPU 不容易被純算力吃滿；真正貴的是：你必須把歷史 KV cache 讀回來參加注意力計(jì)算。Sarathi-Serve 直接指出，decode iteration 雖然單次延遲低，但計(jì)算利用率也低，因此系統(tǒng)必須依賴 batching 才能把吞吐做起來。4

這就是理解后面所有系統(tǒng)工作的第一把鑰匙：
prefill 更像 compute-bound，decode 更像 memory-bound。
當(dāng)然，這不是絕對(duì)的，而是 workload-dependent。文檔摘要、RAG、大段代碼分析等長輸入場景，prefill 會(huì)非常重；實(shí)時(shí)聊天、長輸出推理、RL rollout、agent 多輪執(zhí)行，則會(huì)讓 decode 和 KV cache 問題變得更突出。DistServe 在實(shí)際實(shí)驗(yàn)中就專門區(qū)分了 chatbot、programming assistant、document summary 這類不同 workload，并強(qiáng)調(diào) TTFT 與 TPOT 目標(biāo)并不相同。5

所以，后面凡是看到有人說“LLM 推理是算力問題”或“LLM 推理是內(nèi)存問題”，你都應(yīng)該先追問一句：你說的是 prefill 還是 decode？你說的是哪類 workload？

2. KV Cache：Transformer 推理的真正狀態(tài)變量

如果只從算法式子看，自注意力似乎只是
Attention(Q, K, V) = softmax(QK^T)V。
但在推理系統(tǒng)里，這個(gè)式子最重要的副產(chǎn)品不是輸出，而是歷史狀態(tài)如何被保存。

在 causal decoder 中，每來一個(gè)新 token，模型都會(huì)在每一層計(jì)算該 token 對(duì)應(yīng)的 K 和 V，并把它們保存下來；之后生成新 token 時(shí)，當(dāng)前 token 的 Q 只需要去和全部歷史的 K/V交互即可。于是，KV cache 實(shí)際上存的是：每一層、每個(gè)歷史 token 的 Key 和 Value 表示。它不存 Q，因?yàn)?Q 只屬于“當(dāng)前這一拍”；它也不存完整的 attention 矩陣，因?yàn)楹笳唠S當(dāng)前 Q 的變化而變化，而且體量更大。這個(gè)機(jī)制依賴 causal mask：歷史不會(huì)被未來改寫，所以過去 token 的 K/V 可以安全復(fù)用。6

這件事在系統(tǒng)層面的意義非常大。
如果沒有 KV cache，那么第 t 步生成時(shí)，你需要重新對(duì)前 t-1 個(gè) token 做前向計(jì)算，相當(dāng)于重復(fù)計(jì)算整個(gè)歷史；有了 KV cache 之后，你只需要對(duì)新 token做一次增量前向，但仍然要把歷史 K/V 讀出來參加注意力。于是，問題從“反復(fù)重算歷史”變成了“反復(fù)讀取歷史”。Shazeer 在 Multi-Query Attention 論文里對(duì)這一點(diǎn)說得非常直接：incremental decoding 慢，核心是反復(fù)加載巨大的 K/V 張量所帶來的 memory-bandwidth cost。7

也因此，KV cache 不是某個(gè)實(shí)現(xiàn)細(xì)節(jié)，而是 Transformer 自回歸推理的真正狀態(tài)變量。對(duì)于一個(gè)有 L 層、H_kv 個(gè) KV 頭、每頭維度 d、上下文長度 T、batch 為 B 的模型，KV cache 的規(guī)模大致按
O(L * H_kv * d * T * B)
增長。你一旦把 T 拉長，把 B 拉高，或者讓一次請(qǐng)求分裂成多條 trajectory，這塊狀態(tài)就會(huì)迅速膨脹。CAKE、R-KV、FlexiCache 這類 2025 年的論文，本質(zhì)上都是在承認(rèn)并處理這一事實(shí)：KV cache 本身已經(jīng)大到必須被壓縮、分層、淘汰和預(yù)測。8

這里還有一個(gè)經(jīng)常被忽略的差別：模型參數(shù) weights 是共享且靜態(tài)的，而 KV cache 是按請(qǐng)求增長且互不共享。前者是“把知識(shí)裝進(jìn)模型里”；后者更像“把每次推理的思考過程存起來”。這會(huì)直接導(dǎo)致一個(gè)系統(tǒng)級(jí)分水嶺：同樣是顯存/內(nèi)存占用，weights 的成本更偏容量，而 KV 的成本更偏容量 + 帶寬 + 延遲。這也是為什么我后面會(huì)說，未來很多場景里，KV cache 的壓縮價(jià)值可能比參數(shù)壓縮更大。9

3. 為什么瓶頸會(huì)從 compute 轉(zhuǎn)向 memory

很多關(guān)于 LLM 推理的爭論，實(shí)際上都輸在“把 workload 混為一談”上。
更精確的說法不是“推理越來越偏向 decode”，而是：

只要工作負(fù)載在走向多輪、長歷史、長輸出、長 CoT、可復(fù)用上下文，系統(tǒng)瓶頸就會(huì)從 prefill 的計(jì)算，逐漸轉(zhuǎn)向 decode 階段對(duì) KV cache 的訪問。

這和“prompt 到底變長還是變短”不是一回事。

先看最容易理解的聊天場景。如果用戶輸入短、系統(tǒng)提示穩(wěn)定，而輸出較長，那么 prefill 只做一次，decode 卻要重復(fù)幾十上百次；這時(shí) decode 的累計(jì)成本很容易壓過 prefill。Sarathi-Serve、DistServe 和 OpenRLHF 都是在這種“prefill 與 decode 特性完全不同”的觀察上做系統(tǒng)設(shè)計(jì)的。4

但這并不意味著所有工作負(fù)載都如此。
在 RAG、長文總結(jié)、代碼倉分析等任務(wù)里，輸入可能有幾千到幾十萬 token，輸出卻很短；這類 workload 的第一個(gè)大問題是 TTFT，因?yàn)槟Ｐ捅仨毾劝验L輸入完整 prefill 完。LinkedIn 那篇關(guān)于 prefix reuse 調(diào)度的理論論文就明確把“l(fā)ong-prompt, short-output”視為一個(gè) prefill-dominant 區(qū)間，并指出在這種場景下，prefix reuse 對(duì) TTFT 非常關(guān)鍵。10

真正有意思的是 agent / reasoning / RL rollout。
這些場景里，邏輯上的“上下文”確實(shí)在變長：模型思考、調(diào)用工具、讀回工具輸出、再繼續(xù)思考，歷史不斷追加。但如果系統(tǒng)能有效復(fù)用 KV cache，那么增長的不是“每輪重新 prefill 的計(jì)算量”，而是“需要繼續(xù)維護(hù)和讀取的歷史狀態(tài)量”。也就是說，長 history 并不自動(dòng)等于更重的 prefill；它可能意味著更大的 KV cache、更高的 decode memory pressure。 OpenRLHF 明確把 long CoT 視為訓(xùn)練效率的關(guān)鍵瓶頸，并把 vLLM 接入 rollout engine 來緩解長推理鏈帶來的推理負(fù)擔(dān)。R-KV 更進(jìn)一步，直接把 reasoning model 的“超長輸出導(dǎo)致 KV cache 爆炸”作為問題出發(fā)點(diǎn)。1

這也是為什么我會(huì)說：
“長 prompt”和“長 history”不是同一件事。

• ? 長 prompt，如果每次都要重新喂進(jìn)去，是 prefill 問題。

• ? 長 history，如果以 KV cache 形式被保留下來，是 decode / memory 問題。

現(xiàn)代 API 和 serving system 的大量創(chuàng)新，恰恰都是圍繞這個(gè)區(qū)別展開的：prompt caching、prefix reuse、PD disaggregation、hierarchical cache，本質(zhì)上都在努力把“重復(fù)計(jì)算的長 prompt”轉(zhuǎn)換成“可復(fù)用的長 history”。11

4. RL / Agent：為什么后訓(xùn)練把問題推向 decoding

如果只看 SFT 時(shí)代，訓(xùn)練的主角還是標(biāo)準(zhǔn)的 forward/backward：數(shù)據(jù)集給定，模型吃進(jìn)去，算損失、回傳梯度。那是典型的“訓(xùn)練是核心、推理只是輔助”的時(shí)代。

但后訓(xùn)練，尤其是 RLHF、RLVR、reasoning-oriented RL、agentic RL，不再是這樣。
今天的一個(gè)典型 PPO/GRPO 風(fēng)格循環(huán)更像：

1. 1. 給 prompt；

2. 2. 模型 rollout 出一條或多條答案/軌跡；

3. 3. 獎(jiǎng)勵(lì)模型、驗(yàn)證器、工具執(zhí)行器或環(huán)境給反饋；

4. 4. 再基于這些 rollout 更新參數(shù)。

在這個(gè) pipeline 里，訓(xùn)練并不是直接對(duì)固定樣本做優(yōu)化，而是先生成樣本，再訓(xùn)練。于是系統(tǒng)重心自然向 rollout 傾斜。OpenRLHF 的論文給了一個(gè)非常重的判斷：在 PPO 風(fēng)格 RLHF/RLVR 中，inference phase often accounts for over 90% of total runtime，因?yàn)槟Ｐ鸵诿總€(gè) inference step 里生成成千上萬個(gè) token。1

RLVR (Reinforcement Learning from Value Reflection) 作為新一代 agentic RL 方法，進(jìn)一步放大了這個(gè)問題：它需要模型在 rollout 過程中不斷反思、修正自己的軌跡，導(dǎo)致軌跡長度通常比普通 RLHF 更長，KV cache 需要保留的狀態(tài)也更大。最近的工程經(jīng)驗(yàn)指出，在 terminal environment 這類復(fù)雜 agent 場景中，rollout 軌跡長度很容易達(dá)到數(shù)千 token，而且每個(gè) policy update 需要采樣多條軌跡，KV cache 的內(nèi)存壓力會(huì)比傳統(tǒng)推理場景高出一個(gè)數(shù)量級(jí)。40

一旦接受這點(diǎn)，很多原本看似奇怪的系統(tǒng)設(shè)計(jì)就變得順理成章了。
ECHO-2 直接提出把 centralized learning 和 distributed rollout inference 分開，讓 rollout 生成從數(shù)據(jù)中心 GPU 集群外溢出去；AgentRL 提出 fully-asynchronous generation-training pipeline，用來支撐多輪、多任務(wù) agent RL；OpenRLHF 則把 rollout engine 和 actor/training engine 顯式拆開，并強(qiáng)調(diào)異步數(shù)據(jù)流對(duì)長 CoT 時(shí)代尤其重要。12

為什么 rollout 會(huì)特別“難”？因?yàn)樗瑫r(shí)具備幾個(gè)糟糕特征：

第一，它是 decode-heavy 的。
不是一次性吞掉一段輸入，而是 token-by-token 往前走。1

第二，它的長度高度不規(guī)則。
同一批 prompt，有的幾步就完成，有的會(huì)展開很長的 chain-of-thought；在 agent setting 里，不同工具調(diào)用還會(huì)導(dǎo)致軌跡長度進(jìn)一步分叉。AgentRL 和 OpenRLHF 都把 asynchronous pipeline 當(dāng)成必要設(shè)計(jì)，而不是錦上添花。13

第三，它天然會(huì)放大 KV cache。
如果一個(gè) prompt 不只采樣 1 條輸出，而是采樣 k 條 trajectory；如果每條 trajectory 還會(huì)持續(xù)增長；如果中間還要保留 verifier、tool use、multi-turn state，那么系統(tǒng)不只是多了 k 次計(jì)算，而是多了 k 份不斷膨脹的歷史狀態(tài)。R-KV 把 reasoning output 的冗長性視為核心問題，正是因?yàn)?reasoning model 的“輸出長度”已經(jīng)直接映射到 KV cache 成本。9

我之前提出的一個(gè)猜想——“后訓(xùn)練需要 Mac，可能是因?yàn)?rollout 時(shí)間比 train 時(shí)間更多”——方向是對(duì)的，但更準(zhǔn)確的說法應(yīng)該是：

不是簡單因?yàn)?rollout 更久，而是因?yàn)?rollout 把問題從 backward-dominated 變成了 decode/KV-dominated.

這也是為什么越來越多 post-training 框架會(huì)把 vLLM、SGLang 這類 serving engine 嵌進(jìn)訓(xùn)練框架：OpenRLHF 明確把 vLLM 當(dāng)作長 CoT RLHF/RLVR 的關(guān)鍵基礎(chǔ)設(shè)施；其論點(diǎn)不是“生成順便用一下推理引擎”，而是“推理本身已經(jīng)是訓(xùn)練效率的核心瓶頸”。1

5. 為什么 Mac / UMA 會(huì)重新變重要

很多人談 Mac 跑大模型，容易把它誤解成“Apple GPU 能和 NVIDIA 拼訓(xùn)練吞吐”。這基本不是重點(diǎn)。
Mac 重新變重要，核心不是因?yàn)樗诩兯懔ι馅A了，而是因?yàn)樗?strong>內(nèi)存系統(tǒng)組織方式上走了另一條路。

Apple 在官方材料里反復(fù)強(qiáng)調(diào) unified memory architecture：M3 家族的描述是“單一內(nèi)存池，芯片里所有技術(shù)都能訪問同一份數(shù)據(jù)而無需在多個(gè)內(nèi)存池之間拷貝”；M2 Ultra 則明確給出 800GB/s system memory bandwidth，并支持 192GB unified memory；到 2025 年的 M3 Ultra，Apple 進(jìn)一步給到 最高 512GB unified memory 和 超過 800GB/s 的內(nèi)存帶寬；而到了 2026 年 3 月，M5 Max 官方規(guī)格已經(jīng)達(dá)到 614GB/s unified memory bandwidth。Apple 自己甚至把“直接在設(shè)備內(nèi)存里運(yùn)行超大 LLM”當(dāng)成 Mac Studio 的 AI 賣點(diǎn)之一。14

這對(duì) LLM 推理意味著什么？
不是“Mac 的 GPU 比 H100 快”，而是：

1. 1. 模型權(quán)重、KV cache、CPU-side orchestration 可以共享同一大內(nèi)存池；

2. 2. 很多 CPU/GPU 協(xié)作場景不再需要顯式拷貝；

3. 3. 只要容量夠，單機(jī)可以把更大的 working set 放在一個(gè)統(tǒng)一地址空間里。

Apple 對(duì) MLX 的描述也很直接：MLX 利用 Apple silicon 的 unified memory architecture，CPU 和 GPU 之間運(yùn)行操作時(shí)不需要來回搬數(shù)據(jù)。15

這正好擊中 decode-heavy / rollout-heavy 工作負(fù)載的軟肋。
因?yàn)?decode 的難點(diǎn)本來就不是做一個(gè)巨大的 GEMM，而是如何低成本地讀取和維護(hù)一大塊歷史狀態(tài)。如果你的模型、KV cache、tool runtime 和 CPU/GPU orchestration 共享一個(gè)大內(nèi)存池，那么系統(tǒng)層的“摩擦損耗”會(huì)明顯小很多。Apple 的表述一直圍繞高帶寬、低延遲、單池共享，而不是獨(dú)立顯存 + PCIe copy。14

但這并不等于“Mac 全面優(yōu)于 NVIDIA”。
NVIDIA 仍然在 prefill、訓(xùn)練和高并發(fā) serving 上擁有壓倒性生態(tài)與算力優(yōu)勢。H100 級(jí)別產(chǎn)品的 HBM 帶寬已經(jīng)達(dá)到 3TB/s 量級(jí)，而 Grace Hopper GH200 還通過 NVLink-C2C 的 900GB/s coherent interface 提供 CPU+GPU coherent memory model。NVIDIA 自己的官方說法就是：GH200 通過 NVLink-C2C 提供硬件級(jí) memory coherency。16

換句話說，NVIDIA 并不是沒看到 Apple 這條路，而是在沿著另一條更可擴(kuò)展的路徑逼近它：
從傳統(tǒng)的“離散 GPU + PCIe”，到“NVLink 互聯(lián)”，再到“Grace Hopper coherent memory model”，再到今天圍繞 CXL、shared memory pool、PD disaggregation 的一系列論文。Apple 的意義更像是：它讓很多人第一次真正感受到，統(tǒng)一內(nèi)存不是移動(dòng)設(shè)備賣點(diǎn)，而是 LLM 推理的結(jié)構(gòu)性優(yōu)勢。17

所以，如果你問“為什么后訓(xùn)練也有人要 Mac”，我會(huì)給出一個(gè)更謹(jǐn)慎的判斷：

在 cluster-scale post-training 上，NVIDIA 仍然是主角；但在本地實(shí)驗(yàn)、低并發(fā) rollout、長上下文推理、agent 原型、長 CoT 調(diào)試這類 memory-centric 場景里，Mac 的 UMA 確實(shí)切中了關(guān)鍵痛點(diǎn)。

這不是“Mac 比 NVIDIA 更強(qiáng)”，而是“當(dāng) workload 從 FLOPS 轉(zhuǎn)向 working set 時(shí)，內(nèi)存架構(gòu)開始決定體驗(yàn)”。18

6. 為什么 FlashAttention 救不了 decoding

FlashAttention 是過去幾年最重要的 attention kernel 創(chuàng)新之一，但它經(jīng)常被誤用為“attention 已經(jīng)優(yōu)化完了”的證據(jù)。實(shí)際上，F(xiàn)lashAttention 解決的是prefill 的一個(gè)核心痛點(diǎn)，而不是 decode 的根問題。

FlashAttention 的原論文把問題表述得非常明確：標(biāo)準(zhǔn) attention 的關(guān)鍵瓶頸不是理論 FLOPS，而是 HBM 與片上 SRAM 之間的 IO。它通過 tiling 方式避免 materialize 巨大的中間 attention 矩陣，從而顯著減少 HBM 讀寫。這個(gè)優(yōu)化對(duì)長序列 prefill 非常有效，因?yàn)?prefill 階段會(huì)面對(duì)大規(guī)模的 N x N 注意力結(jié)構(gòu)。19

但 decode 完全不是這個(gè)形態(tài)。
在 decoding 的第 t 步，當(dāng)前只有一個(gè)新 token，因此 Q 的序列長度幾乎是 1，而 K/V 的長度是歷史長度 t-1。這時(shí) attention 更像一個(gè) 1 x N 的查詢過程，而不是一個(gè)要顯式構(gòu)造 N x N 中間矩陣的過程。換句話說，decode 的問題不是“中間 attention matrix 太大”，而是“歷史 K/V 必須被完整讀一遍”。Shazeer 的 MQA 論文把 incremental decoding 的瓶頸直接歸因于 repeated loading of large keys and values tensors。19

這就是為什么你會(huì)看到一個(gè)非常反直覺的結(jié)論：

• ? FlashAttention 對(duì) prefill 常常非常關(guān)鍵；

• ? 但對(duì) decode，它更多是在 局部 kernel 效率 上錦上添花，而不是改變瓶頸。

因?yàn)?decode 真正無法繞開的，是 O(N) 的 KV read。你可以減少 kernel overhead，可以更好地融合一些計(jì)算，但只要模型還是標(biāo)準(zhǔn) causal attention，歷史狀態(tài)就必須被訪問。Sarathi-Serve 之所以強(qiáng)調(diào) batching、chunked-prefill 和 stall-free schedule，而不是把希望完全押在 attention kernel 上，背后就是這個(gè)現(xiàn)實(shí)：decode 的系統(tǒng)瓶頸不再是單個(gè)算子本身。4

在 2026 年 3 月 5 日，F(xiàn)lashAttention-4 進(jìn)一步優(yōu)化了異構(gòu)計(jì)算和片上內(nèi)存管理，在長序列 prefill 上繼續(xù)獲得顯著提升，但核心觀察仍然成立：對(duì) incremental decoding 而言，瓶頸的本質(zhì)仍然是對(duì)歷史 KV 的反復(fù)讀取，而非 kernel 內(nèi)的計(jì)算調(diào)度。即使 kernel 效率再優(yōu)化一個(gè)量級(jí)，只要你需要每一步都讀完整歷史，memory 帶寬仍然會(huì)是核心約束。

這也是理解后面所有系統(tǒng)設(shè)計(jì)的第二把鑰匙：
當(dāng)瓶頸是“必須讀歷史”時(shí)，優(yōu)化方向就會(huì)從 kernel 下沉到 memory layout、cache reuse、調(diào)度和體系結(jié)構(gòu)。

7. 推理優(yōu)化的四層結(jié)構(gòu)：kernel、engine、model、hardware

為了不把各種技術(shù)混成一鍋，我更喜歡把 LLM 推理優(yōu)化分成四層：

第一層：kernel 層

典型代表就是 FlashAttention。
它關(guān)心的是：單個(gè) attention / decode kernel 如何更少搬 HBM、更多留在片上 SRAM，如何更高效地執(zhí)行。這層很重要，但它只回答“這一步怎么算更快”。19

第二層：engine 層

典型代表是 Orca、vLLM、SGLang、Sarathi-Serve。
這層關(guān)心的是：請(qǐng)求如何被動(dòng)態(tài)調(diào)度、KV cache 如何被分頁/復(fù)用、prefill 與 decode 如何協(xié)同、如何提高 GPU 利用率與 goodput。Orca 把 request-level scheduling 改成 iteration-level scheduling；vLLM 用 PagedAttention 解決 KV 內(nèi)存碎片；SGLang 用 RadixAttention 做前綴復(fù)用；Sarathi-Serve 通過 chunked-prefill 平衡吞吐與延遲。20

第三層：model 層

典型代表是 MQA / GQA、以及更激進(jìn)的 Mamba / RWKV 方向。
這層關(guān)心的是：如果 decode 慢是因?yàn)橐x太多 K/V，那能不能讓 K/V 變少，甚至不用 K/V？ MQA 直接共享 K/V；GQA 折中共享；Mamba/RWKV 則試圖把歷史壓成遞歸狀態(tài)。7

第四層：hardware 層

典型代表是 Apple UMA、Grace Hopper coherent memory、CXL memory pool。
這層關(guān)心的是：既然歷史必須讀，那能不能讓“讀”這件事更像訪問本地內(nèi)存，而不是頻繁跨總線搬數(shù)據(jù)？ Apple 走 unified memory；NVIDIA 用 GH200 把 coherent memory 帶進(jìn) CPU+GPU；Beluga、TraCT、CXL-SpecKV 則嘗試把更大的共享內(nèi)存池引入集群級(jí)推理。14

如果只盯著第一層，你會(huì)覺得問題是“attention 還不夠快”。
如果看到第二層，你會(huì)意識(shí)到問題是“GPU 經(jīng)常在等、不夠滿”。
如果看到第三層，你會(huì)發(fā)現(xiàn)“模型本身就在決定系統(tǒng)帶寬壓力”。
如果再看到第四層，你就會(huì)明白：今天很多所謂 AI infra 的創(chuàng)新，本質(zhì)已經(jīng)不是神經(jīng)網(wǎng)絡(luò)論文，而是 memory system 論文。

8. Continuous Batching：從“請(qǐng)求級(jí)”到“token 級(jí)”調(diào)度

LLM serving 的一個(gè)基本矛盾是：decode 每一步的計(jì)算量很小，不 batch 很容易吃不滿 GPU；但一旦 batch，序列長度和完成時(shí)間又高度不一致，傳統(tǒng) static batching 會(huì)制造大量浪費(fèi)。

Orca 是這條線的源頭之一。它提出 iteration-level scheduling：系統(tǒng)不是把一批請(qǐng)求整體跑完再換下一批，而是以“迭代”為單位調(diào)度，每次只讓引擎執(zhí)行單次迭代，然后馬上允許新請(qǐng)求進(jìn)入、已完成請(qǐng)求退出。Orca 論文把這件事的收益說得很清楚：對(duì)于 Transformer-based generative models，這種按 iteration 調(diào)度的方式顯著優(yōu)于傳統(tǒng) request-granularity serving。20

vLLm 把這條思路進(jìn)一步工程化。
其 PagedAttention 論文的出發(fā)點(diǎn)是：KV cache 又大又動(dòng)態(tài)增長，傳統(tǒng)連續(xù)分配方式既浪費(fèi)顯存又難以高吞吐 serving。PagedAttention 把 KV cache 管成類似操作系統(tǒng)分頁的形式，以支撐更靈活的請(qǐng)求裝配和內(nèi)存復(fù)用。21

一旦 KV cache 能被分頁管理，continuous batching 才真正成立。
它的核心不是“一次多攢幾個(gè)請(qǐng)求”，而是：每個(gè) decode step 都重新組 batch。誰結(jié)束了就退出，誰新到就盡快插入；batch 生命周期從“一個(gè)請(qǐng)求的完整生成期”縮短為“一個(gè) token step”。這和靜態(tài) batching 的本質(zhì)區(qū)別，不在于 batch 更大，而在于 batch 的重組粒度更細(xì)。Orca 的迭代級(jí)調(diào)度、vLLM 的 continuous batching、TensorRT-LLM 的 in-flight batching，本質(zhì)都在做這件事。20

為什么它能把 GPU 利用率顯著拉高？
因?yàn)?decode 階段單個(gè)請(qǐng)求的計(jì)算太小，必須把多個(gè)請(qǐng)求的“下一 token”拼在一起算，才能提高張量并行度；而靜態(tài) batching 會(huì)被最長請(qǐng)求拖住，短請(qǐng)求完成后留下的“空座位”無法立刻補(bǔ)入。continuous batching 把等待最長請(qǐng)求的串行模式，改造成了 token-level 的流水線模式。Sarathi-Serve 進(jìn)一步指出，decode batching 對(duì) overall throughput 特別有效，但 prefill 與 decode 混排又會(huì)制造 stall，因此需要 chunked-prefill 來減輕這種互擾。4

當(dāng)然，continuous batching 也不是“batch 越大越好”。
Revisiting SLO and Goodput Metrics in LLM Serving、DistServe、以及一系列后續(xù)工作都提醒我們：在線 serving 的目標(biāo)不是單純最大吞吐，而是滿足 TTFT / TPOT / 尾延遲等 SLO 的 goodput。batch 太大，雖然吞吐可能繼續(xù)升一點(diǎn)，但 TPOT、P99 latency 可能惡化，最終 goodput 反而下降。22

所以，continuous batching 的真正目標(biāo)不是“無限放大 batch”，而是：

在給定的 KV 帶寬、尾延遲和 SLO 約束下，讓 GPU 在每個(gè)時(shí)間片都盡可能做有價(jià)值的 token 計(jì)算。

這已經(jīng)非常像操作系統(tǒng)里的在線調(diào)度問題，而不再像經(jīng)典深度學(xué)習(xí)里的“固定 batch 訓(xùn)練”。

9. 模型結(jié)構(gòu)如何直接決定系統(tǒng)上限：MQA / GQA

如果你理解了 decode 的核心成本是“不斷讀歷史 K/V”，那 MQA / GQA 的意義就會(huì)變得非常清楚。

Shazeer 在 2019 年提出 MQA 時(shí)，問題定義幾乎就是現(xiàn)在整個(gè)行業(yè)的共同語言：incremental decoding 之所以慢，是因?yàn)?repeated loading of large keys and values tensors 帶來了 memory-bandwidth cost。MQA 的解法簡單粗暴：讓所有 query heads 共享同一組 K/V heads。這樣做并不會(huì)減少 query head 數(shù)量，但會(huì)顯著減少 K/V 的尺寸，從而降低 decode 的帶寬壓力。7

GQA 則是這條路線的工程折中。
Google 的 GQA 論文明確指出：MQA 推理很快，但質(zhì)量可能下降；于是他們提出 grouped-query attention，在“每頭獨(dú)立 K/V”和“全頭共享 K/V”之間取一個(gè)中間點(diǎn)。論文結(jié)論也很清楚：uptrained GQA 的質(zhì)量接近 MHA，而速度接近 MQA。23

這件事的重要性，在系統(tǒng)層面遠(yuǎn)超“注意力機(jī)制換了個(gè)變體”。
因?yàn)楫?dāng)你減少 H_kv 的時(shí)候，減少的不只是 KV cache 占用，還減少了每一步 decode 必須讀回來的數(shù)據(jù)量。換句話說：

• ? MHA 把系統(tǒng)拖向 memory wall；

• ? MQA/GQA 在主動(dòng)降低單請(qǐng)求的 memory footprint；

• ? 這會(huì)直接推高可實(shí)現(xiàn)的 optimal batch size，并改善 TTOT/throughput 曲線。

這正是“模型設(shè)計(jì)開始服務(wù)系統(tǒng)效率”的典型例子。它不是單純?yōu)榱藢W(xué)術(shù)上更優(yōu)雅，而是在用結(jié)構(gòu)設(shè)計(jì)換系統(tǒng)帶寬。7

從這個(gè)角度看，很多人把“模型架構(gòu)”和“系統(tǒng)優(yōu)化”分成兩個(gè)世界，其實(shí)已經(jīng)不太成立了。
GQA 并不是一個(gè)脫離部署場景的純模型創(chuàng)新；它是在非常明確地回應(yīng) serving 時(shí)代的物理瓶頸。后面你再看 CAKE、R-KV、FlexiCache 這類方法，會(huì)發(fā)現(xiàn)這條線更進(jìn)一步：不只是讓 K/V 變少，還要讓 K/V 更聰明地存在。8

2024 年底到 2025 年初，這條演化路線又走出了關(guān)鍵幾步：

MLA：DeepSeek V3.1 的低秩壓縮 KV

DeepSeek V3.1 提出的 Multi-Head Latent Attention (MLA)，把 MQA/GQA 的思路推向了新的高度。它不再是簡單共享 K/V 頭，而是對(duì) K/V 做低秩投影壓縮，把原始 K/V 投影到更低維度的 latent space 存儲(chǔ)，需要時(shí)再恢復(fù)。這種方法在保持模型質(zhì)量的同時(shí)，能把 KV cache 體積壓縮 30–50%，顯著降低了 decode 階段的帶寬壓力。MLA 的意義在于：它證明了模型架構(gòu)可以主動(dòng)通過表示壓縮來服務(wù)系統(tǒng)級(jí)的內(nèi)存效率，而不只是被動(dòng)等待系統(tǒng)層面的優(yōu)化。

Lightning Indexer：DeepSeek V3.2 的增量 KV 優(yōu)化

DeepSeek V3.2 進(jìn)一步推出 Lightning Indexer，針對(duì) MLA 做了增量推理優(yōu)化。它把 KV cache 的索引結(jié)構(gòu)從全局壓縮變成了增量更新，新 incoming token 的 KV 可以直接寫入壓縮緩存而不需要重新壓縮整個(gè)序列，從而在保持壓縮比的同時(shí)不增加延遲開銷。這再次說明：模型結(jié)構(gòu)和內(nèi)存系統(tǒng)設(shè)計(jì)必須協(xié)同進(jìn)化——壓縮帶來了容量好處，但增量更新的工程問題必須一起解決才能落地。

Attention Residuals：Kimi / MiniMax 的分層 KV 保持

Kimi 和 MiniMax 在近期的推理優(yōu)化中都采用了類似 Attention Residuals 的思路：它們不再對(duì)所有層、所有 token 保留完整精度的 KV，而是只在底層保留完整 KV，高層只保留 residuals 或增量信息。這種分層壓縮進(jìn)一步降低了總體 KV 體積，同時(shí)因?yàn)榈讓?attention 更多關(guān)注局部位置，高層更多關(guān)注抽象語義，這種非均勻壓縮對(duì)模型質(zhì)量的影響非常有限。它代表了另一個(gè)方向：利用 attention 機(jī)制本身的層次特性來做非均勻 KV 壓縮。

這些新進(jìn)展繼續(xù)驗(yàn)證著同一個(gè)方向：模型架構(gòu)設(shè)計(jì)正在越來越主動(dòng)地回應(yīng)推理時(shí)的內(nèi)存瓶頸，而不是把所有問題都丟給系統(tǒng)側(cè)解決。模型定義了 KV 的冗余結(jié)構(gòu)，系統(tǒng)才能在這個(gè)結(jié)構(gòu)上做更精細(xì)的管理。

10. KV Cache 其實(shí)是一種高度冗余的外部記憶

如果說 2023 年以前，很多系統(tǒng)還默認(rèn)“KV cache 就是該存的東西，想辦法裝下就好”，那么 2025 年以后，一個(gè)越來越強(qiáng)的共識(shí)是：

KV cache 不是最優(yōu)表示，只是最保守表示。

它保留了 Transformer 為了不丟信息而存下來的全部歷史狀態(tài)，但這些狀態(tài)在時(shí)間、層次、head 和 token 維度上都存在顯著冗余。

R-KV 的問題設(shè)定很有代表性：reasoning models 往往會(huì)生成過長的 chain-of-thought，這會(huì)導(dǎo)致“prohibitively large KV caches during inference”。作者進(jìn)一步指出，傳統(tǒng) KV 壓縮方法在 reasoning model 上容易失敗，因?yàn)?reasoning token 里既有真正關(guān)鍵的推理狀態(tài)，也有大量冗余 token；R-KV 通過 redundancy-aware compression，在只保留 10% KV 的情況下接近滿血效果，甚至在 16% KV 下能超過 full KV baseline。9

CAKE 則從另一個(gè)角度說明“冗余”不是均勻分布的。
它把 KV eviction 建模成一個(gè) layer-aware、time-aware 的資源分配問題：不同層的 attention pattern 不同，不同 token 的重要性還會(huì)隨時(shí)間移動(dòng)。結(jié)果非常激進(jìn)：在 LongBench 和 NeedleBench 上，CAKE 只保留 3.2% KV cache 仍能維持性能，并在長上下文下顯著降低 decode latency。8

FlexiCache 又提供了第三種視角：
attention heads 在時(shí)間上的穩(wěn)定性并不一樣。有些 heads 會(huì)反復(fù)關(guān)注接近的 top-K 頁，有些則頻繁變化。于是系統(tǒng)就沒必要對(duì)所有 heads 一視同仁：穩(wěn)定的 head 可以只在 GPU 上保留 top-K 頁面，其余下沉到 host memory；不穩(wěn)定的 head 則保留更多 GPU-resident pages。24

如果把這三類工作放在一起看，你會(huì)發(fā)現(xiàn)它們共同指向一個(gè)結(jié)論：

1. 1. 很多 token 的貢獻(xiàn)是稀疏的；

2. 2. 很多層和很多 heads 的貢獻(xiàn)并不對(duì)等；

3. 3. 很多歷史狀態(tài)可以被壓縮、淘汰、延遲加載或部分重算。

這時(shí)，KV cache 就越來越像一種“外部記憶系統(tǒng)”而不是“固定中間結(jié)果”。
Transformer 過去的做法，本質(zhì)上是把歷史逐 token 存檔；但一個(gè)更成熟的 memory system 會(huì)問：哪些應(yīng)該保留在熱層？哪些可以降層？哪些其實(shí)只是冗余副本？哪些應(yīng)該預(yù)測性預(yù)?。磕男└纱嗫梢酝簦?

所以我會(huì)說，未來很多推理系統(tǒng)里，KV compression 的戰(zhàn)略價(jià)值可能比參數(shù)量化還高。
參數(shù)壓縮解決的是“模型能不能裝下”；KV 壓縮解決的是“系統(tǒng)能不能真正跑起來、跑得快、跑得穩(wěn)”。R-KV 和 CAKE 的結(jié)果已經(jīng)在很大程度上證明了這一點(diǎn)。8

11. 為什么很多線上系統(tǒng)仍然在“重復(fù)計(jì)算歷史”

到這里，一個(gè)自然問題是：既然 KV cache 這么重要，為什么很多線上系統(tǒng)沒有把它徹底用好？

答案是：因?yàn)橄到y(tǒng)工程的最優(yōu)解，不等于單請(qǐng)求計(jì)算的最優(yōu)解。

在 API 層面，很多云服務(wù)長期采用的是近乎 stateless 的交互模型。
OpenAI 的 Chat Completions 文檔寫得很明白：請(qǐng)求里要提供 messages，也就是“the conversation so far”；這意味著客戶端要把歷史對(duì)話內(nèi)容一起發(fā)回來。后來 Responses API 加入了 previous_response_id、Conversations 等狀態(tài)機(jī)制，可以“store and retrieve conversation state across Response API calls”，并且 Prompt Caching 允許對(duì)完全相同的前綴做自動(dòng)緩存。但從系統(tǒng)角度看，這仍然和“把某個(gè)用戶會(huì)話的完整 KV cache 長期 pin 在某個(gè) GPU 上”不是一回事。25

為什么大家不直接做強(qiáng) stateful KV serving？
因?yàn)槟菚?huì)讓會(huì)話和特定 GPU / 節(jié)點(diǎn)強(qiáng)綁定，惡化負(fù)載均衡、容錯(cuò)和多租戶隔離。只要請(qǐng)求可以落到任意副本，副本就必須能在不知道前情的情況下接住請(qǐng)求；于是最保守的設(shè)計(jì)就是讓客戶端或上層服務(wù)把必要上下文重新發(fā)來。Prompt Caching 是一個(gè)很聰明的折中：OpenAI 官方文檔明確說 cache hits 只可能出現(xiàn)在 exact prefix matches 上，而且現(xiàn)在還能通過 prompt_cache_key 和最長 24 小時(shí)的 extended prompt caching 來提高命中率。它確實(shí)能減少 prefill 成本，但它仍然是“圍繞前綴重用做的工程折中”，而不是通用的跨請(qǐng)求 KV 內(nèi)存系統(tǒng)。11

這就是很多“偽 agent”系統(tǒng)的本質(zhì)。
邏輯上，它們看起來是多輪 agent：用戶問一句、工具跑一輪、模型再思考一輪。
但物理上，很多時(shí)候它們其實(shí)是：每一輪都重新構(gòu)造 prompt，再做一次 full prefill。
當(dāng)上下文越來越長、鏈路越來越多、工具越來越復(fù)雜時(shí)，你看到的不是“狀態(tài)被穩(wěn)態(tài)保留”，而是“歷史被反復(fù)重放”。這會(huì)讓 prefill 成本非常高，也解釋了為什么 prompt caching / prefix reuse / PD disaggregation 會(huì)變得如此重要。11

所以，線上系統(tǒng)的真實(shí)矛盾不是“工程師不知道 KV cache 有用”，而是：

如何在可擴(kuò)展、可容錯(cuò)、可調(diào)度的云架構(gòu)里，盡量恢復(fù) KV cache 的好處。

第一代 KV-centric 系統(tǒng)，就是在解這個(gè)矛盾。

12. 第一代 KV-centric 架構(gòu)：DistServe、Mooncake、LMCache

如果說 vLLM 和 SGLang 主要解決的是“單引擎或單節(jié)點(diǎn)內(nèi)，如何更好地跑”，那么 2024 年開始的一批系統(tǒng)開始把問題升級(jí)為：

跨請(qǐng)求、跨節(jié)點(diǎn)、跨階段，KV cache 應(yīng)該怎么成為系統(tǒng)級(jí)資源？

這條線里，DistServe、Mooncake、LMCache 是三個(gè)非常關(guān)鍵的坐標(biāo)。

DistServe：先把 prefill 和 decode 拆開

DistServe 的出發(fā)點(diǎn)是 goodput：
現(xiàn)有 serving 系統(tǒng)把 prefill 與 decode 混在一起跑，會(huì)同時(shí)帶來 prefill-decoding interference 和 resource coupling。前者讓兩個(gè)階段互相拖累；后者讓資源配置無法針對(duì) TTFT 與 TPOT 分別優(yōu)化。于是 DistServe 直接做 prefill/decode disaggregation：把 prefill 分到一批 GPU，把 decode 分到另一批 GPU，再按應(yīng)用的 TTFT/TPOT 目標(biāo)聯(lián)合優(yōu)化資源分配與并行策略。論文報(bào)告在不同模型和 workloads 上，DistServe 能在延遲約束下顯著提升可服務(wù)請(qǐng)求率。5

DistServe 的重要性不在于它是唯一答案，而在于它第一次非常系統(tǒng)地把一個(gè)常識(shí)變成了架構(gòu)原則：
prefill 和 decode 不是同一類資源需求。

Mooncake：把 KV cache 提升為調(diào)度核心

Mooncake 更進(jìn)一步。
它直接把自己定義為 KVCache-centric disaggregated architecture。在 Mooncake 里，prefill 集群和 decode 集群是分離的，同時(shí)系統(tǒng)會(huì)利用 GPU 集群里原本被低估的 CPU、DRAM、SSD、NIC 資源來構(gòu)建一個(gè)分布式 KV cache；核心則是圍繞 KV cache 設(shè)計(jì)的 scheduler，用來在吞吐、SLO 和過載情況下平衡調(diào)度。Mooncake 論文報(bào)告在 Kimi 相關(guān)工作負(fù)載下，真實(shí)場景里可以多處理約 75% 請(qǐng)求。26

Mooncake 的思路非常值得注意：
它已經(jīng)不再把 KV cache 當(dāng)成“模型執(zhí)行之后順手留下來的臨時(shí)副產(chǎn)品”，而是把它當(dāng)成系統(tǒng)調(diào)度的對(duì)象。
這是一個(gè)很大的范式轉(zhuǎn)變。

LMCache：把 KV cache 變成共享層

如果 Mooncake 更偏架構(gòu)與調(diào)度，那么 LMCache 更像是把 KV 抽象成一個(gè)可插拔的 cache layer。
LMCache 論文把自己的定位說得非常清楚：它從 vLLM 和 SGLang 這類現(xiàn)代 LLM engine 里提取并存儲(chǔ) KV cache，然后跨 queries、cross engines共享這些 KV cache，既支持 prefix reuse，也支持 PD disaggregation 下的跨引擎 KV transfer。論文報(bào)告，和 vLLM 結(jié)合時(shí)，吞吐在一些 workload 上可提升到 15x。27

所以如果你非要給三者一個(gè)最簡潔的分工，我會(huì)這樣總結(jié)：

• ? DistServe ：先把 prefill 和 decode 分開，解決兩階段互擾；

• ? Mooncake ：讓 KV cache 成為分布式調(diào)度核心；

• ? LMCache ：把 KV cache 抽象成可存儲(chǔ)、可遷移、可復(fù)用的系統(tǒng)層。

與此同時(shí)，SGLang 的 RadixAttention 提供了另一種非常關(guān)鍵的能力：在復(fù)雜 LM program 中自動(dòng)發(fā)現(xiàn)并復(fù)用共享前綴。SGLang 論文強(qiáng)調(diào)，它的 runtime 可以利用 RadixAttention 實(shí)現(xiàn) KV cache reuse，并在多種任務(wù)上大幅提高吞吐。28

有意思的是，到 2026 年初，Mooncake 和 LMCache 官方文檔已經(jīng)明確展示了二者的集成：Mooncake 可以作為 LMCache 的后端存儲(chǔ)和傳輸引擎，官方甚至直接展示了 LMCache + Mooncake + vLLM 的 PD-disaggregated demo。也就是說，現(xiàn)實(shí)里它們并不是“二選一”的關(guān)系，而是常常疊加使用。29

13. 為什么 Mooncake / LMCache 不是終點(diǎn)

如果 Mooncake / LMCache 已經(jīng)把 KV 提成一等公民，為什么 2025 年以后還會(huì)冒出一大堆“下一代”論文？

因?yàn)楫?dāng)你把 KV 做成系統(tǒng)級(jí)資源之后，新的瓶頸會(huì)立刻暴露出來。

第一，KV 太大，搬不動(dòng)

Mooncake/LMCache 的默認(rèn)設(shè)定仍然是：
KV 值得存、值得搬、值得復(fù)用。
但一旦上下文變長、請(qǐng)求變多、agent 變復(fù)雜，KV cache 的體積會(huì)很快膨脹到 GPU 容量之外。此時(shí)問題就從“有沒有 cache”變成“cache 如何從 CPU/SSD/遠(yuǎn)程內(nèi)存高效回到 GPU”。

Strata 的摘要對(duì)此幾乎是點(diǎn)名式批評(píng)：長上下文下，分層緩存不可避免，但把大塊 cached contexts 重新加載回 GPU 時(shí)會(huì)遇到嚴(yán)重瓶頸——paged layouts 帶來的 fragmented I/O 無法吃滿帶寬，現(xiàn)有 scheduler 又不考慮 cache-loading delay，結(jié)果系統(tǒng)變成 loading-bound 而不是 compute-bound。30

第二，prefix reuse 會(huì)和延遲目標(biāo)沖突

自動(dòng) prefix reuse 并不自動(dòng)等于更好的 online latency。
LinkedIn 那篇關(guān)于 RadixAttention 調(diào)度的 NeurIPS 2025 論文做了一件很重要的事：它把“有 prefix reuse 的在線調(diào)度”形式化之后證明，在 TTFT 約束下，這個(gè)問題是 NP-hard 的。更直觀地說，簡單地貪心追求 longest-prefix-match，可能會(huì)讓某些請(qǐng)求的 TTFT 爆掉。作者因此提出 k-LPM，用來平衡 prefix reuse 與 fairness/waiting time。10

這說明什么？
說明 Mooncake / LMCache 把“緩存能不能用”解決了，但“緩存什么時(shí)候用、優(yōu)先給誰用”還沒有徹底解決。

第三，agent workload 的復(fù)用模式和普通 LRU 不一樣

KVFlow 直接把矛頭指向 agentic workflows：
當(dāng)前系統(tǒng)雖然會(huì)做 prefix caching，但通常采用 LRU 淘汰策略，這會(huì)在 agent 即將下一次被調(diào)用前把其 KV cache 提前丟掉。KVFlow 因而引入 workflow-aware 的 Agent Step Graph、細(xì)粒度 eviction，以及主動(dòng) prefetch。它本質(zhì)上是在說：agent 場景下，緩存管理必須理解工作流結(jié)構(gòu)，而不能只看最近訪問。31

第四，公平性和搶占有上下文切換成本

FastSwitch 又暴露了另一個(gè)問題：
現(xiàn)有 block-based KV cache 分配雖然減少了內(nèi)存浪費(fèi)，但會(huì)導(dǎo)致上下文切換粒度不足、切換開銷高。FastSwitch 因此提出一種 fairness-aware serving system，專門優(yōu)化 preemption/context switching 的效率。換句話說，當(dāng) KV 成為狀態(tài)后，搶占不再是免費(fèi)動(dòng)作。32

第五，精確前綴命中本身就過于苛刻

在 RAG 這類場景里，兩個(gè)請(qǐng)求往往不是“完全相同前綴”，而是“共享大量檢索上下文但并不嚴(yán)格前綴一致”。CacheBlend 就是在這個(gè)問題上往前走了一步：它不再要求嚴(yán)格 prefix match，而是允許復(fù)用已緩存的 KV，再對(duì)少量 token 的 KV 做 selective recompute，從而在 RAG 上顯著改善 TTFT 和吞吐。33

所以，Mooncake / LMCache 之所以“不是最新”，不是因?yàn)樗鼈冞^時(shí)了，而是因?yàn)樗鼈儼褑栴}推進(jìn)到了下一階段。
它們解決的是：讓 KV 進(jìn)入系統(tǒng)視野。
而下一代工作解決的是：當(dāng) KV 已經(jīng)成為系統(tǒng)資源后，如何處理 I/O、調(diào)度、agent reuse、分層緩存、公平性和局部重算。

14. 新一代 Memory-centric 架構(gòu)：Strata、CAKE、R-KV、KVFlow、FastSwitch、CacheBlend

我更愿意把 2025 年之后的工作叫做 memory-centric，而不是簡單的 KV-centric。因?yàn)檫@時(shí)研究重心已經(jīng)不只是“緩存有沒有被復(fù)用”，而是：

如何把 KV cache 管理成一個(gè)真正的分層內(nèi)存系統(tǒng)。

Strata 可以看作 Mooncake/LMCache 之后最系統(tǒng)的一次升級(jí)。
它關(guān)注的不是“怎樣做 prefix reuse”，而是“當(dāng)長上下文 cache 被分層存儲(chǔ)后，如何高效把它重新搬回 GPU”。論文提出 GPU-assisted I/O、GPU/CPU layout decoupling 和 cache-aware scheduling，并報(bào)告在長上下文基準(zhǔn)上相對(duì) vLLM + LMCache 可實(shí)現(xiàn) 最高 5x 更低 TTFT。30

這類工作很關(guān)鍵，因?yàn)樗选癒V cache 存在哪”從一個(gè) yes/no 問題變成了一個(gè)多級(jí)層次問題：HBM、CPU DRAM、SSD，乃至更遠(yuǎn)的內(nèi)存池，都是緩存層的一部分。

CAKE：Layer-aware eviction

CAKE 的貢獻(xiàn)，是把“刪誰”這件事變得全局且結(jié)構(gòu)化。
它不再把 eviction 看成簡單 LRU，而是結(jié)合 layer-specific preference 與 temporal dynamics 去做 cascading allocation。最值得記住的不是具體算法，而是它的結(jié)果背后的信號(hào)：很多層、很多 token、很多時(shí)刻的 KV 實(shí)際上并不值錢。8

R-KV：Reasoning-specific compression

R-KV 之所以值得單獨(dú)拎出來，是因?yàn)樗苯訉?duì)應(yīng)了當(dāng)下最火的 workload：reasoning。
作者指出 reasoning models 經(jīng)常會(huì)生成 excessively long outputs，而 existing compression approach 又會(huì)在 reasoning failure 上翻車，于是他們專門針對(duì) reasoning 冗余做壓縮。結(jié)果同樣非常有標(biāo)志性：10% KV 接近滿血性能，16% KV 甚至能超過 baseline。9

這說明 reasoning 場景不只是“更長”，還意味著冗余結(jié)構(gòu)有別于普通聊天輸出。

FlexiCache：按 head 穩(wěn)定性做層次管理

FlexiCache 進(jìn)一步把 memory policy 做到了 attention head 層級(jí)：
穩(wěn)定的 heads，只保留 top-K pages 在 GPU；不穩(wěn)定 heads，保留更多熱頁。這代表著另一個(gè)很重要的趨勢：緩存管理正在越來越細(xì)粒度地靠近模型內(nèi)部結(jié)構(gòu)。24

KVFlow：workflow-aware cache for agents

KVFlow 則非常明確地站在 agent workflow 一側(cè)。
它的核心思想很簡單但很有力：agent workload 不是隨機(jī)序列，而是帶有工作流依賴的 Agent Step Graph；因此緩存策略應(yīng)該“知道”哪個(gè) agent 下一步更可能被再次激活。KVFlow 再加上 fully overlapped prefetch，本質(zhì)上已經(jīng)很像 CPU cache 里的“預(yù)測下一步會(huì)用什么”。31

FastSwitch：context switching 也是成本

FastSwitch 說明，當(dāng)你把大量請(qǐng)求都做成可搶占的、可中斷的 KV-stateful 過程時(shí)，context switching 本身會(huì)成為瓶頸。這和操作系統(tǒng)里的進(jìn)程切換越來越像：不是說搶占不能做，而是搶占的粒度、上下文布局、恢復(fù)成本都必須被認(rèn)真設(shè)計(jì)。32

CacheBlend：從 exact prefix reuse 走向 approximate reuse

CacheBlend 值得注意，是因?yàn)樗赋?exact prefix reuse 過于局限。
對(duì)于 RAG 之類場景，共享上下文不一定是“完全一樣的開頭”，但仍然值得復(fù)用一大塊歷史。CacheBlend 用少量 selective recompute 把這種近似重用變成可能，這實(shí)際上把“緩存”和“計(jì)算”做成了連續(xù)體，而不是非此即彼。33

把這些工作放在一起看，你會(huì)發(fā)現(xiàn)新一代架構(gòu)的關(guān)鍵詞已經(jīng)不是簡單的 “cache reuse”，而是：

• ? hierarchical tiers

• ? cache-aware scheduling

• ? workflow-aware eviction

• ? partial recompute

• ? proactive prefetch

• ? fairness-aware switching

這已經(jīng)完全是 memory system 的語言了。

15. CXL：看起來像終極答案，為什么現(xiàn)實(shí)里還很難

CXL 之所以讓人興奮，是因?yàn)樗砻嫔虾芟褚粭l“兼得”的路線：
容量可以擴(kuò)展、內(nèi)存池可以共享、load/store 語義更自然、看起來又比 RDMA 更像真正的內(nèi)存。

Beluga 的摘要就很有代表性：它提出通過 CXL switch 讓 GPU 和 CPU 訪問一個(gè) shared large-scale memory pool，并強(qiáng)調(diào)這種 load/store access semantics 能帶來 near-local memory latency、減少同步與編程復(fù)雜度。論文在 vLLM 上報(bào)告了相對(duì) RDMA baseline 顯著 TTFT 和吞吐改善。34

但如果因此得出“CXL 就是最終解”，那就太樂觀了。

第一，CXL 解決的是容量，不是 HBM 級(jí)帶寬

HBM 的價(jià)值不只是近，而是又近又寬。
CXL 能做出更大的共享內(nèi)存池，但它不會(huì)自動(dòng)給你 HBM 級(jí)吞吐。Beluga 的改進(jìn)之所以成立，是相對(duì) RDMA 等更曲折路徑而言；并不意味著 CXL 可以無成本替代 GPU 本地顯存。34

第二，CXL 不是自動(dòng) coherent 的天堂

TraCT 的摘要非常有教育意義。
它明確指出，為了實(shí)現(xiàn)基于 CXL shared memory 的 rack-scale KV cache，必須處理 synchronization, consistency, and data management on non-coherent CXL memory。換言之，現(xiàn)實(shí)里的 CXL，至少在很多商用品質(zhì)和部署形態(tài)下，并不是“天然全局一致的 UMA”。你還是要自己補(bǔ)軟件協(xié)議。35

第三，數(shù)據(jù)移動(dòng)不見得比重算便宜

只要 KV 足夠大、訪問足夠碎、競爭足夠高，跨層搬運(yùn)本身就會(huì)成為主成本。TraCT 專門把 KV transfer 視為 PD disaggregation 的 fundamental bottleneck；CXL-SpecKV 則不得不引入 speculative prefetch + FPGA compression/decompression，才能把 disaggregated KV-cache 的代價(jià)壓住。35

第四，CXL 方案經(jīng)常不得不引入更多“系統(tǒng)補(bǔ)丁”

Beluga 通過 shared pool + native load/store 降低編程復(fù)雜度；TraCT 通過軟件級(jí)同步機(jī)制處理 non-coherence；CXL-SpecKV 又通過 speculative prefetch 和壓縮去彌補(bǔ)帶寬/延遲問題。你會(huì)發(fā)現(xiàn)，CXL 不是一個(gè)“買來即用”的硬件銀彈，而是一個(gè)要求系統(tǒng)/軟件/硬件協(xié)同設(shè)計(jì)的平臺(tái)。34

所以我會(huì)把 CXL 的真實(shí)定位概括成一句話：

CXL 很重要，但它更像“新增一層內(nèi)存層級(jí)”，而不是“讓所有遠(yuǎn)程內(nèi)存都變成本地 HBM”。

一旦這樣理解，很多現(xiàn)象就不矛盾了：
為什么 CXL 方案總在討論 prefetch、壓縮、shared pool、non-coherence、software sync？
因?yàn)樗鼈冊(cè)诒举|(zhì)上做的是——承認(rèn)遠(yuǎn)程內(nèi)存仍然更慢，然后盡量把這份慢掩蓋掉。

16. LLM serving 正在變成一個(gè)“操作系統(tǒng)問題”

如果把今天的主流 LLM serving 系統(tǒng)和 5 年前的 DNN serving 系統(tǒng)一對(duì)比，最大的變化不是模型更大，而是抽象層變了。

你會(huì)看到一整套越來越像操作系統(tǒng)的概念：

• ? pages / blocks ：PagedAttention 像虛擬內(nèi)存分頁；21

• ? radix tree ：RadixAttention 像基于前綴的共享索引；28

• ? cache hit / miss ：prompt caching、prefix reuse、KVFlow、CacheBlend 都在圍繞命中率做文章；11

• ? eviction policy ：CAKE、KVFlow、FastSwitch 都在研究誰該被驅(qū)逐；8

• ? prefetch ：KVFlow、CXL-SpecKV、Beluga 這類系統(tǒng)都在強(qiáng)調(diào)預(yù)測性加載；31

• ? scheduling under SLO ：DistServe、Revisiting SLO and Goodput、LinkedIn 那篇 k-LPM 理論工作，都把 serving 視為 latency-constrained online scheduling。5

甚至“好不好”的評(píng)價(jià)指標(biāo)都越來越不像傳統(tǒng)訓(xùn)練。
訓(xùn)練時(shí)代，大家比的是 tokens/sec、TFLOPS utilization、samples/sec。
Serving 時(shí)代，越來越關(guān)鍵的是：TTFT、TPOT、P99、SLO attainment、goodput。Revisiting SLO and Goodput Metrics in LLM Serving 明確指出，傳統(tǒng) goodput 指標(biāo)甚至?xí)膭?lì)一些違背用戶體驗(yàn)的行為，因此需要重新定義 serving 指標(biāo)框架。22

這意味著一個(gè)非常根本的變化：
以前我們常說“LLM infra 的核心是分布式訓(xùn)練系統(tǒng)”。
現(xiàn)在更準(zhǔn)確的說法也許是：LLM serving 的核心正在變成一個(gè)面向 KV state 的在線內(nèi)存操作系統(tǒng)。

這個(gè)“操作系統(tǒng)”要解決的事情包括：

1. 1. 如何把狀態(tài)拆成頁；

2. 2. 如何在多層存儲(chǔ)中放置；

3. 3. 如何決定誰駐留 GPU；

4. 4. 如何預(yù)測誰下一步會(huì)用；

5. 5. 如何平衡公平、吞吐和尾延遲；

6. 6. 如何在必要時(shí)壓縮、重算、搶占和遷移；

7. 7. 如何讓 prefix sharing 和多租戶服務(wù)共存。

從這個(gè)角度看，Mooncake/LMCache 只是“把文件系統(tǒng)建起來”的第一步；Strata、KVFlow、FastSwitch、Beluga、TraCT，則在往“完整內(nèi)存管理器”方向走。

17. KV cache 之后是什么：Mamba、RWKV 與“在線壓縮記憶”

如果把問題繼續(xù)追到底，一個(gè)更激進(jìn)的問題會(huì)冒出來：

既然大家已經(jīng)承認(rèn) KV cache 很大、很貴、很冗余，那為什么不干脆不要 KV cache？

這就是 Mamba、RWKV 這類方向的吸引力。

Mamba 的核心主張很明確：Transformer 在長序列上存在根本性的計(jì)算效率問題，因此它用 selective state spaces 去構(gòu)建一種linear-time sequence model。論文強(qiáng)調(diào) Mamba 是 fully recurrent 的，并報(bào)告在語言建模上獲得很強(qiáng)性能，同時(shí)推理吞吐優(yōu)于同規(guī)模 Transformer。36

RWKV 的表述也很直接：它想結(jié)合 Transformer 可并行訓(xùn)練的優(yōu)點(diǎn)與 RNN 高效推理的優(yōu)點(diǎn)，實(shí)現(xiàn)線性擴(kuò)展的推理過程。37

如果用一句更系統(tǒng)的話來說，Transformer 的 KV cache 是一種“把歷史逐 token 存檔”的外部記憶；而 Mamba/RWKV 這類模型更像在嘗試一種“在線壓縮記憶”：不是把每一段歷史都原樣保留，而是把歷史不斷壓縮進(jìn)一個(gè)遞歸狀態(tài)里。

這條路線的誘惑非常大，因?yàn)樗鼜母由媳苊饬恕懊坎奖仨氉x完整歷史 K/V”的問題。
但現(xiàn)實(shí)也很清楚：截至 2026 年，Transformer 仍然是工業(yè)部署的主流，圍繞 KV cache 的系統(tǒng)創(chuàng)新還在高速推進(jìn)。這說明產(chǎn)業(yè)界的短中期共識(shí)不是“馬上替換 Transformer”，而是“先把 KV-based world 優(yōu)化到極致”。36

所以，KV cache 之后的未來，大概率不是一個(gè)瞬間翻篇的故事，而是兩條線并行：

• ? 一條線繼續(xù)把 Transformer serving 做成真正成熟的 memory system；

• ? 另一條線探索如何用 state-space / recurrent / hybrid 架構(gòu)，把“歷史存儲(chǔ)成本”在模型層面降下來。

這兩條線并不沖突。相反，今天圍繞 KV cache 做出的所有系統(tǒng)認(rèn)知，都會(huì)成為理解下一代序列架構(gòu)的基礎(chǔ)。

18. 結(jié)語：三條真正的主線

如果要把整篇文章濃縮成三條主線，我會(huì)這樣總結(jié)。

第一條：從 Compute 到 Memory

Transformer 訓(xùn)練時(shí)代，焦點(diǎn)是 FLOPS；
Transformer 推理時(shí)代，焦點(diǎn)越來越是 working set、帶寬、延遲、狀態(tài)復(fù)用。
FlashAttention 重要，但它不是終局；真正的終局問題是：歷史信息該如何被存儲(chǔ)、訪問、遷移和壓縮。19

第二條：從 Stateless 到 Stateful

云上 API 為了可擴(kuò)展、可容錯(cuò)和多租戶，天然偏向 stateless；
但 agent、多輪對(duì)話、長 CoT、RL rollout，又天然需要 stateful。
于是過去兩年最重要的 serving 創(chuàng)新，幾乎都在試圖調(diào)和這對(duì)矛盾：prompt caching、prefix reuse、RadixAttention、LMCache、Mooncake、DistServe、KVFlow、Beluga、TraCT。它們的共同目標(biāo)都是：在不犧牲云架構(gòu)彈性的前提下，盡量恢復(fù)狀態(tài)復(fù)用的收益。11

第三條：從 Model 到 System，再到 Memory OS

過去我們常把“模型創(chuàng)新”和“系統(tǒng)優(yōu)化”分開看。
但今天，GQA 這種結(jié)構(gòu)設(shè)計(jì)直接影響帶寬；R-KV 這種壓縮方法直接影響 serving 成本；KVFlow/FastSwitch/Strata 這種系統(tǒng)工作又在深度利用模型內(nèi)部的時(shí)間穩(wěn)定性、前綴結(jié)構(gòu)和層間差異。到這個(gè)階段，模型、引擎、調(diào)度、內(nèi)存層級(jí)其實(shí)已經(jīng)被綁在一起。23

所以，這篇文章真正想表達(dá)的不是“Mac 好還是 NVIDIA 好”，也不是“Mooncake 和 LMCache 過沒過時(shí)”。
我更想強(qiáng)調(diào)的是：

大模型推理的下一階段，越來越不是一個(gè)“神經(jīng)網(wǎng)絡(luò)算子優(yōu)化”問題，而是一個(gè)“如何把歷史變成可管理內(nèi)存”的系統(tǒng)問題。

一旦你接受這一點(diǎn)，很多過去看似碎片化的現(xiàn)象就會(huì)統(tǒng)一起來：

• ? 為什么 RL rollout 讓 inference 比 training 更貴；

• ? 為什么 Mac 的統(tǒng)一內(nèi)存會(huì)重新有意義；

• ? 為什么 FlashAttention 不夠；

• ? 為什么 vLLM、SGLang、Mooncake、LMCache、Strata、Beluga、TraCT 會(huì)同時(shí)出現(xiàn)；

• ? 為什么 CXL 讓人興奮又讓人頭疼；

• ? 為什么 KV cache compression 可能比參數(shù)壓縮更重要；

• ? 為什么未來的 LLM serving，看起來越來越像一個(gè)操作系統(tǒng)。

而這，也許才是過去兩年 AI infra 最值得被認(rèn)真理解的變化。

參考閱讀（按主題分組） 基礎(chǔ)機(jī)制

1. 6. Attention Is All You Need — Transformer 與 masked decoder。6

2. 7. BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding — 雙向 encoder 路線。3

3. 8. Language Models are Unsupervised Multitask Learners — GPT 路線的代表性早期文本。38

1. 19. FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness 。19

2. 20. Efficient Memory Management for Large Language Model Serving with PagedAttention （vLLM）。21

3. 21. Orca: A Distributed Serving System for Transformer-Based Generative Models 。20

4. 22. Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve 。4

5. 23. SGLang: Efficient Execution of Structured Language Model Programs 。28

1. 7. Fast Transformer Decoding: One Write-Head is All You Need （MQA）。7

2. 8. GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints 。23

3. 9. CAKE: Cascading and Adaptive KV Cache Eviction with Layer Preferences 。8

4. 10. R-KV: Redundancy-aware KV Cache Compression for Training-Free Reasoning Models Acceleration 。9

5. 11. FlexiCache: Leveraging Temporal Stability of Attention Heads for Efficient KV Cache Management 。24

1. 5. DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving 。5

2. 6. Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving 。26

3. 7. LMCache: An Efficient KV Cache Layer for Enterprise-Scale LLM Inference 。27

4. 8. Strata: Hierarchical Context Caching for Long Context Language Model Serving 。30

5. 9. KVFlow: Efficient Prefix Caching for Accelerating LLM-Based Multi-Agent Workflows 。31

6. 10. FastSwitch: Optimizing Context Switching Efficiency in Fairness-aware Serving Systems 。32

7. 11. CacheBlend: Fast Large Language Model Serving for RAG with Cached Knowledge Fusion 。33

8. 12. LLM Query Scheduling with Prefix Reuse and Latency Constraints 。10

9. 13. Revisiting SLO and Goodput Metrics in LLM Serving 。22

1. 1. OpenRLHF: An Easy-to-use, Scalable and High-performance RLHF Framework 。1

2. 2. ECHO-2: A Large-Scale Distributed Rollout Framework for Cost-Efficient RL Post-Training 。12

3. 3. AgentRL / Agent Lightning 這類 agentic RL 基礎(chǔ)設(shè)施工作。13

1. 14. Apple 官方關(guān)于 unified memory、M2 Ultra、M3 Ultra、M5 Pro/Max、MLX 的材料。14

2. 15. NVIDIA Grace Hopper / GH200 官方 coherent memory 材料。39

3. 16. Beluga , TraCT , CXL-SpecKV — CXL/shared memory 方向。34