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

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

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

目錄

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

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

• ? 3. 為什么瓶頸會從 compute 轉向 memory

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

• ? 5. 為什么 Mac / UMA 會重新變重要

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

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

• ? 8. Continuous Batching：從“請求級”到“token 級”調度

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

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

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

• ? 12. 第一代 KV-centric 架構：DistServe、Mooncake、LMCache

• ? 13. 為什么 Mooncake / LMCache 不是終點

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

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

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

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

• ? 18. 結語：三條真正的主線

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

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

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

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

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

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

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

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

在 causal decoder 中，每來一個新 token，模型都會在每一層計算該 token 對應的 K 和 V，并把它們保存下來；之后生成新 token 時，當前 token 的 Q 只需要去和全部歷史的 K/V交互即可。于是，KV cache 實際上存的是：每一層、每個歷史 token 的 Key 和 Value 表示。它不存 Q，因為 Q 只屬于“當前這一拍”；它也不存完整的 attention 矩陣，因為后者隨當前 Q 的變化而變化，而且體量更大。這個機制依賴 causal mask：歷史不會被未來改寫，所以過去 token 的 K/V 可以安全復用。6

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

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

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

3. 為什么瓶頸會從 compute 轉向 memory

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

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

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

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

但這并不意味著所有工作負載都如此。
在 RAG、長文總結、代碼倉分析等任務里，輸入可能有幾千到幾十萬 token，輸出卻很短；這類 workload 的第一個大問題是 TTFT，因為模型必須先把長輸入完整 prefill 完。LinkedIn 那篇關于 prefix reuse 調度的理論論文就明確把“l(fā)ong-prompt, short-output”視為一個 prefill-dominant 區(qū)間，并指出在這種場景下，prefix reuse 對 TTFT 非常關鍵。10

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

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

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

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

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

4. RL / Agent：為什么后訓練把問題推向 decoding

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

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

1. 1. 給 prompt；

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

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

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

在這個 pipeline 里，訓練并不是直接對固定樣本做優(yōu)化，而是先生成樣本，再訓練。于是系統(tǒng)重心自然向 rollout 傾斜。OpenRLHF 的論文給了一個非常重的判斷：在 PPO 風格 RLHF/RLVR 中，inference phase often accounts for over 90% of total runtime，因為模型要在每個 inference step 里生成成千上萬個 token。1

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

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

為什么 rollout 會特別“難”？因為它同時具備幾個糟糕特征：

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

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

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

我之前提出的一個猜想——“后訓練需要 Mac，可能是因為 rollout 時間比 train 時間更多”——方向是對的，但更準確的說法應該是：

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

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

5. 為什么 Mac / UMA 會重新變重要

很多人談 Mac 跑大模型，容易把它誤解成“Apple GPU 能和 NVIDIA 拼訓練吞吐”。這基本不是重點。
Mac 重新變重要，核心不是因為它在純算力上贏了，而是因為它在內存系統(tǒng)組織方式上走了另一條路。

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

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

1. 1. 模型權重、KV cache、CPU-side orchestration 可以共享同一大內存池；

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

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

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

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

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

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

所以，如果你問“為什么后訓練也有人要 Mac”，我會給出一個更謹慎的判斷：

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

這不是“Mac 比 NVIDIA 更強”，而是“當 workload 從 FLOPS 轉向 working set 時，內存架構開始決定體驗”。18

6. 為什么 FlashAttention 救不了 decoding

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

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

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

這就是為什么你會看到一個非常反直覺的結論：

• ? FlashAttention 對 prefill 常常非常關鍵；

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

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

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

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

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

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

第一層：kernel 層

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

第二層：engine 層

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

第三層：model 層

典型代表是 MQA / GQA、以及更激進的 Mamba / RWKV 方向。
這層關心的是：如果 decode 慢是因為要讀太多 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。
這層關心的是：既然歷史必須讀，那能不能讓“讀”這件事更像訪問本地內存，而不是頻繁跨總線搬數(shù)據？ Apple 走 unified memory；NVIDIA 用 GH200 把 coherent memory 帶進 CPU+GPU；Beluga、TraCT、CXL-SpecKV 則嘗試把更大的共享內存池引入集群級推理。14

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

8. Continuous Batching：從“請求級”到“token 級”調度

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

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

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

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

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

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

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

在給定的 KV 帶寬、尾延遲和 SLO 約束下，讓 GPU 在每個時間片都盡可能做有價值的 token 計算。

這已經非常像操作系統(tǒng)里的在線調度問題，而不再像經典深度學習里的“固定 batch 訓練”。

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

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

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

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

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

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

• ? MQA/GQA 在主動降低單請求的 memory footprint；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 1. 很多 token 的貢獻是稀疏的；

2. 2. 很多層和很多 heads 的貢獻并不對等；

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

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

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

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

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

答案是：因為系統(tǒng)工程的最優(yōu)解，不等于單請求計算的最優(yōu)解。

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

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

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

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

如何在可擴展、可容錯、可調度的云架構里，盡量恢復 KV cache 的好處。

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

12. 第一代 KV-centric 架構：DistServe、Mooncake、LMCache

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

跨請求、跨節(jié)點、跨階段，KV cache 應該怎么成為系統(tǒng)級資源？

這條線里，DistServe、Mooncake、LMCache 是三個非常關鍵的坐標。

DistServe：先把 prefill 和 decode 拆開

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

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

Mooncake：把 KV cache 提升為調度核心

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

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

LMCache：把 KV cache 變成共享層

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

所以如果你非要給三者一個最簡潔的分工，我會這樣總結：

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

• ? Mooncake ：讓 KV cache 成為分布式調度核心；

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

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

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

13. 為什么 Mooncake / LMCache 不是終點

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

因為當你把 KV 做成系統(tǒng)級資源之后，新的瓶頸會立刻暴露出來。

第一，KV 太大，搬不動

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

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

第二，prefix reuse 會和延遲目標沖突

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

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

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

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

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

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

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

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

所以，Mooncake / LMCache 之所以“不是最新”，不是因為它們過時了，而是因為它們把問題推進到了下一階段。
它們解決的是：讓 KV 進入系統(tǒng)視野。
而下一代工作解決的是：當 KV 已經成為系統(tǒng)資源后，如何處理 I/O、調度、agent reuse、分層緩存、公平性和局部重算。

14. 新一代 Memory-centric 架構：Strata、CAKE、R-KV、KVFlow、FastSwitch、CacheBlend

我更愿意把 2025 年之后的工作叫做 memory-centric，而不是簡單的 KV-centric。因為這時研究重心已經不只是“緩存有沒有被復用”，而是：

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

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

這類工作很關鍵，因為它把“KV cache 存在哪”從一個 yes/no 問題變成了一個多級層次問題：HBM、CPU DRAM、SSD，乃至更遠的內存池，都是緩存層的一部分。

CAKE：Layer-aware eviction

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

R-KV：Reasoning-specific compression

R-KV 之所以值得單獨拎出來，是因為它直接對應了當下最火的 workload：reasoning。
作者指出 reasoning models 經常會生成 excessively long outputs，而 existing compression approach 又會在 reasoning failure 上翻車，于是他們專門針對 reasoning 冗余做壓縮。結果同樣非常有標志性：10% KV 接近滿血性能，16% KV 甚至能超過 baseline。9

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

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

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

KVFlow：workflow-aware cache for agents

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

FastSwitch：context switching 也是成本

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

CacheBlend：從 exact prefix reuse 走向 approximate reuse

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

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

• ? hierarchical tiers

• ? cache-aware scheduling

• ? workflow-aware eviction

• ? partial recompute

• ? proactive prefetch

• ? fairness-aware switching

這已經完全是 memory system 的語言了。

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

CXL 之所以讓人興奮，是因為它表面上很像一條“兼得”的路線：
容量可以擴展、內存池可以共享、load/store 語義更自然、看起來又比 RDMA 更像真正的內存。

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

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

第一，CXL 解決的是容量，不是 HBM 級帶寬

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

第二，CXL 不是自動 coherent 的天堂

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

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

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

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

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

所以我會把 CXL 的真實定位概括成一句話：

CXL 很重要，但它更像“新增一層內存層級”，而不是“讓所有遠程內存都變成本地 HBM”。

一旦這樣理解，很多現(xiàn)象就不矛盾了：
為什么 CXL 方案總在討論 prefetch、壓縮、shared pool、non-coherence、software sync？
因為它們在本質上做的是——承認遠程內存仍然更慢，然后盡量把這份慢掩蓋掉。

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

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

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

• ? pages / blocks ：PagedAttention 像虛擬內存分頁；21

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

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

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

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

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

甚至“好不好”的評價指標都越來越不像傳統(tǒng)訓練。
訓練時代，大家比的是 tokens/sec、TFLOPS utilization、samples/sec。
Serving 時代，越來越關鍵的是：TTFT、TPOT、P99、SLO attainment、goodput。Revisiting SLO and Goodput Metrics in LLM Serving 明確指出，傳統(tǒng) goodput 指標甚至會鼓勵一些違背用戶體驗的行為，因此需要重新定義 serving 指標框架。22

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

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

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

2. 2. 如何在多層存儲中放置；

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

4. 4. 如何預測誰下一步會用；

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

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

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

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

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

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

既然大家已經承認 KV cache 很大、很貴、很冗余，那為什么不干脆不要 KV cache？

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

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

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

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

這條路線的誘惑非常大，因為它從根子上避免了“每步必須讀完整歷史 K/V”的問題。
但現(xiàn)實也很清楚：截至 2026 年，Transformer 仍然是工業(yè)部署的主流，圍繞 KV cache 的系統(tǒng)創(chuàng)新還在高速推進。這說明產業(yè)界的短中期共識不是“馬上替換 Transformer”，而是“先把 KV-based world 優(yōu)化到極致”。36

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

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

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

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

18. 結語：三條真正的主線

如果要把整篇文章濃縮成三條主線，我會這樣總結。

第一條：從 Compute 到 Memory

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

第二條：從 Stateless 到 Stateful

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

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

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

所以，這篇文章真正想表達的不是“Mac 好還是 NVIDIA 好”，也不是“Mooncake 和 LMCache 過沒過時”。
我更想強調的是：

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

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

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

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

• ? 為什么 FlashAttention 不夠；

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

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

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

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

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

參考閱讀（按主題分組） 基礎機制

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 基礎設施工作。13

1. 14. Apple 官方關于 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