【LMCache 入門到實戰】系列 #01，共 4 篇
難度：L2-進階　｜　前置知識：對 LLM 推論、Transformer、vLLM 有基本認識即可

一句話說明

LMCache 是一個「把 LLM 算過的中間結果（KV Cache）存起來、下次直接載入」的快取層，讓重複的前綴（system prompt、RAG 文件、多輪對話歷史）不用每次都重新算一遍，藉此降低首 token 延遲（TTFT）並省下 GPU 算力。

這篇是系列開篇，目標不是教你怎麼裝、怎麼調參，而是先讓你看懂它在解決什麼問題——這樣後面幾篇談設定、談效能時，你才知道每個數字是在省什麼。

先搞懂：一次 LLM 推論其實分兩段

當你送一段 prompt 給模型、要它接著往下寫，模型內部其實跑了兩個階段，成本差很多。

你的輸入： "請根據以下文件回答問題：<8000 字的文件> 問題是..."
                    │
        ┌───────────┴───────────┐
        ▼                       ▼
   [1] Prefill 階段          [2] Decode 階段
   把整段輸入一次讀進去        一個一個 token 往外吐
   算出每個 token 的 KV       "根" "據" "文" "件" ...
   → 昂貴、算力密集            → 相對便宜，但要跑很多次
Code language: JavaScript (javascript)

這在幹嘛？兩階段白話翻譯

• Prefill（預填）：模型把你「輸入的每一個 token」都算一遍，產生一份叫做 KV Cache 的中間資料。輸入越長，這步越貴——8000 字的文件，就是 8000 多個 token 全部要算。
• Decode（解碼）：模型開始一個 token、一個 token 往外生成回答。每生一個新 token，只要看前面存好的 KV Cache 就好，不用重算整段輸入。

關鍵直覺：prefill 的成本跟「輸入長度」成正比，而且是一次性的大筆開銷。 你的回答還沒開始吐第一個字之前，GPU 已經在 prefill 這步忙了半天——這段時間就是使用者感受到的「首 token 延遲（TTFT，Time To First Token）」。

KV Cache 到底是什麼？

Transformer 的注意力機制（attention）在算每個 token 時，需要參考前面所有 token 的兩份向量：Key（K） 和 Value（V）。

                你想生成下一個 token 時
                      │
   要回頭看前面每個 token 的 K 和 V ──┐
                                     │
        如果每次都重算 → 超級浪費     │
        所以算一次就「快取」起來 ──────┘
              這份快取 = KV Cache

用一句話翻譯：KV Cache 就是「模型讀過這段文字後的記憶」。 有了它，模型接著生成時不用把整段輸入重讀一遍。

重點來了——這份「記憶」是可以被重複使用的。如果兩個不同的請求，開頭都是同一段文字（例如同一份 system prompt、同一份 RAG 文件），那它們算出來的 KV Cache 前綴其實一模一樣。既然一樣，何必算兩次？

這就是 LMCache 的切入點。

LMCache 想解決的核心問題：重複的 prefill

沒有快取重用時，典型的浪費長這樣：

請求 A： [system prompt 2000 tokens] + [使用者問題]
         └─ prefill 全部 2000+ tokens ─┘   ← 算一次

請求 B： [system prompt 2000 tokens] + [另一個問題]
         └─ prefill 全部 2000+ tokens ─┘   ← 又算一次（一模一樣的前綴！）

請求 C： [system prompt 2000 tokens] + [第三個問題]
         └─ prefill 全部 2000+ tokens ─┘   ← 再算一次...
Code language: CSS (css)

那 2000 個 token 的 system prompt，KV Cache 每次都長得一樣，卻被 GPU 重算了 N 次。有了 LMCache：

請求 A： prefill system prompt → 把 KV Cache 存起來
請求 B： 直接載入存好的 KV Cache（跳過 prefill）→ 只算新問題
請求 C： 直接載入存好的 KV Cache（跳過 prefill）→ 只算新問題

「重算」變成「載入」——這就是 LMCache 一句話能講完的核心價值。載入一份存好的 KV Cache，通常比重新 prefill 快得多，也不吃 GPU 算力。

典型受益場景

不是所有情況都需要 LMCache。它發揮價值的前提是：請求之間有大量重複的前綴。以下四種場景剛好都符合。

一個直覺判斷法：如果你的 prompt 有一大段是「每次都一樣、只有結尾在變」，那 LMCache 就有得省。 反之，如果每個請求從頭到尾都不一樣（例如翻譯一堆互不相關的短句），重用率低，效益就有限。

LMCache 在推論堆疊的哪一層？跟 vLLM 什麼關係？

這是最多人搞混的地方，值得講清楚。

   使用者請求
       │
       ▼
 ┌─────────────────────────┐
 │   vLLM（推論引擎）        │  ← 負責實際跑模型、生成 token
 │                         │
 │  ┌───────────────────┐  │
 │  │ prefix caching     │  │  ← vLLM 內建：同一台機器、
 │  │（引擎內、單機）     │  │     GPU 記憶體內的前綴重用
 │  └───────────────────┘  │
 └───────────┬─────────────┘
             │ 掛上
             ▼
 ┌─────────────────────────┐
 │   LMCache（KV 儲存層）    │  ← 把 KV Cache 存到更大、
 │  GPU→CPU 記憶體→磁碟→遠端 │     更遠的地方，還能跨節點共享
 └─────────────────────────┘

關鍵區分：vLLM 內建的 prefix caching vs. LMCache

vLLM 自己就有 prefix caching：它會把最近算過的前綴 KV Cache 留在 GPU 記憶體裡，同一台機器上遇到相同前綴就重用。這很好用，但有兩個天花板：

1. 只在 GPU 記憶體裡：GPU 顯存很貴很有限，存不了多少，一滿就被擠掉（evict）。
2. 只在單一引擎內：換一台機器、換一個 vLLM 實例，快取就用不到了。

LMCache 補的正是這兩塊：它把 KV Cache 往外延伸儲存——從 GPU 記憶體，一路可以放到 CPU 記憶體、本地磁碟、甚至遠端共享儲存。於是快取能存得更多、活得更久，還能跨節點共享（A 機器算過的前綴，B 機器也能直接載入）。

一句話總結兩者關係：不是二選一，而是互補。 vLLM 的 prefix caching 是引擎內的第一層快取，LMCache 是它外面更大、更持久、可跨機共享的第二層 KV 儲存。實務上 LMCache 是「掛」在 vLLM 上一起用的。

效益概觀：到底能省多少？

先建立量級概念，具體數字後面幾篇會實測：

• TTFT 下降：命中快取時，省掉了整段前綴的 prefill。前綴越長、佔比越高，首 token 延遲改善越明顯——長 context 場景下常見數倍的加速。
• GPU 算力節省：被跳過的 prefill 就是省下的浮點運算。重複前綴越多的服務（例如共用 system prompt 的線上客服），整體 GPU 用量下降越顯著。

但務必記住一個前提：這些效益都建立在「快取命中」上。 沒命中（前綴每次都不同），LMCache 不但幫不上忙，載入／查找還可能帶來一點點額外開銷。所以「你的流量到底有多少重複前綴」，才是決定 LMCache 值不值得的真正變數。

🚩 紅旗：看到這些說法要警覺

當 AI 或某篇文章跟你介紹 LMCache 時，以下幾種講法要打問號：

• 🚩 「裝了 LMCache 一定變快」：不對。沒有重複前綴、快取命中率低的時候，效益趨近於零，甚至因為查找開銷小輸。先問「我的請求前綴重複嗎？」
• 🚩 「LMCache 可以取代 vLLM」：搞錯層級了。LMCache 是 KV 儲存層，不自己跑模型；它是掛在 vLLM 這類引擎上用的，不是替代品。
• 🚩 「KV Cache 重用會影響回答正確性」：只要前綴 token 完全相同，載入的 KV Cache 在數學上等價於重算，結果一致。要警覺的是反例——如果前綴其實不完全一樣卻硬命中，那才會出問題（這是設定層面的坑，後面篇章談）。
• 🚩 「快取存越多越好」：存到磁碟或遠端雖然容量大，但載入也要時間。當「載入 KV」比「直接重算 prefill」還慢時，快取反而拖後腿。省不省，要看前綴長度與儲存層級的權衡。

Vibe Coder 驗收檢查點

讀完這篇，你應該能回答下面幾個問題。做不到就回去重讀對應段落，或直接把問題貼給 AI 問。

• ✅ 用一句話說出 prefill 和 decode 差在哪、哪個貴（提示：prefill 一次性、跟輸入長度成正比、決定 TTFT）。
• ✅ 解釋 KV Cache 為什麼可以被跨請求重用（提示：相同前綴 token 算出來的 K/V 一樣）。
• ✅ 講清楚 vLLM prefix caching 和 LMCache 的分工（提示：引擎內單機 vs. 跨層級跨節點的儲存）。
• ✅ 判斷一個場景適不適合用 LMCache（提示：問前綴重複率高不高）。

自我檢測小情境：假設你在做一個「客服機器人」，每個請求都帶著同一段 3000 字的公司政策當 system prompt。這適合 LMCache 嗎？（答案：非常適合，因為那 3000 字的前綴每次都一樣，重用率極高。）

看不懂就這樣問 AI

把不確定的地方直接丟給 AI，這幾句可以複製：

「用最白話解釋，LLM 推論裡的 prefill 和 decode 差在哪？為什麼 prefill 比較貴？我是初學者。」

「vLLM 內建的 prefix caching 和 LMCache 有什麼不同？為什麼說它們是互補而不是二選一？」

「我的服務每個請求 prompt 開頭都一樣、只有結尾問題不同，用 KV Cache 重用能省多少？幫我判斷值不值得。」

小結與下一篇

這篇你建立了三個核心認知：

1. 推論分兩段：prefill 昂貴且決定 TTFT，decode 相對便宜；KV Cache 是 prefill 的產物。
2. LMCache 的價值：把重複前綴的「重算」變成「載入」，核心受益場景是 RAG、多輪對話、共用 system prompt、長文件問答。
3. 它的定位：不是取代 vLLM，而是掛在上面、補足引擎內 prefix caching 「單機、易被擠掉」限制的跨層級／跨節點 KV 儲存層。

下一篇（#02）我們會實際把 LMCache 掛到 vLLM 上跑起來，看它的設定長什麼樣、快取存到哪裡，並用真實請求驗證命中前後的 TTFT 差異。