LMCache 實用指南：vLLM 推理服務如何複用 KV Cache

Thu, 25 Jun 2026 09:14:41 +0800

LMCache 解決的是一個很實際的問題：大模型推理裡，很多請求前半段 prompt 是重複的，但服務端每次都重新 prefill，GPU 時間就白白浪費了。

如果你的業務裡有長系統提示詞、RAG 模板、多輪對話、Agent 工具說明、固定知識上下文，LMCache 就值得看一眼。它把臨時的 KV Cache 從推理引擎裡抽出來，放到可以複用、可觀測的快取層裡，目標是降低 TTFT，也就是首 token 延遲。

專案地址：

`1`	`https://github.com/LMCache/LMCache`

官方文件：

`1`	`https://docs.lmcache.ai/`

先判斷是否需要

LMCache 更適合 prompt 很長、多個請求共享前綴、RAG 片段重複、多輪對話歷史很長、Agent 工具說明很長，或多個 vLLM 實例需要共享快取的場景。它主要優化 TTFT 和 prefill，不是加速所有 token 的萬能開關。

建議先用 vLLM MP 模式

MP 模式：LMCache 作為獨立服務運行，vLLM 透過 LMCacheMPConnector 連接。
In-process 模式：LMCache 嵌在 vLLM 進程裡，適合快速實驗。

實用角度看，先用 MP 模式更穩，因為快取服務獨立，也更方便管理、觀測和多實例共享。

安裝

1
2
3

uv venv --python 3.12
source .venv/bin/activate
uv pip install lmcache vllm

或：

1
2
3

python -m venv .venv
source .venv/bin/activate
pip install lmcache vllm

生產環境要固定版本，並確認 vLLM、LMCache 和 connector 相容。

啟動 LMCache

`1`	`lmcache server --l1-size-gb 20 --eviction-policy LRU --chunk-size 16`

--chunk-size 16 適合 demo，生產通常用預設值，例如 256。預設 ZMQ 連接埠是 5555，HTTP 管理和指標連接埠是 8080。

啟動 vLLM

`1`	`vllm serve Qwen/Qwen3-8B --port 8000 --kv-transfer-config '{"kv_connector":"LMCacheMPConnector", "kv_role":"kv_both"}'`

vLLM 0.20.0 或更新版本可以顯式指定 LMCache 自帶 connector：

`1`	`vllm serve Qwen/Qwen3-8B --port 8000 --kv-transfer-config '{"kv_connector":"LMCacheMPConnector", "kv_connector_module_path":"lmcache.integration.vllm.lmcache_mp_connector", "kv_role":"kv_both"}'`

測試快取命中

用兩條共享前綴的請求測試。第一次應看到 Stored ... tokens，第二次應看到 Retrieved ... tokens。

curl http://localhost:8000/v1/completions   -H "Content-Type: application/json"   -d '{
    "model": "Qwen/Qwen3-8B",
    "prompt": "Qwen3 is the latest generation of large language models in Qwen series, offering a comprehensive suite of dense and mixture-of-experts",
    "max_tokens": 100,
    "temperature": 0.7
  }'

curl http://localhost:8000/v1/completions   -H "Content-Type: application/json"   -d '{
    "model": "Qwen/Qwen3-8B",
    "prompt": "Qwen3 is the latest generation of large language models in Qwen series, offering a comprehensive suite of dense and mixture-of-experts (MoE) models",
    "max_tokens": 100,
    "temperature": 0.7
  }'

觀察重點

不要只看有沒有 Retrieved，還要看命中 tokens、命中率、從哪個後端取回、取回耗時是否比重新 prefill 更划算，以及 chunk 對齊是否影響命中。

適合的業務

長系統提示詞、固定 RAG 模板、Agent 工具說明、多實例推理服務最容易吃到收益。第一次接入不建議直接上 Redis、S3、NIXL 等複雜後端，先用本地 CPU RAM 證明真實業務 prompt 可複用。

In-process 模式

`1`	`LMCACHE_CHUNK_SIZE=8 vllm serve Qwen/Qwen3-8B --port 8000 --kv-transfer-config '{"kv_connector":"LMCacheConnectorV1", "kv_role":"kv_both"}'`

這種方式簡單，但快取跟著 vLLM 進程走，獨立性不如 MP 模式。

上線前清單

對比開啟和關閉 LMCache 的 TTFT。
單獨記錄 prefill 延遲。
統計 prefix cache hit tokens 和 hit ratio。
觀察 LMCache 記憶體是否穩定。
測試 vLLM 重啟後是否仍能複用。
檢查高併發下的 ZMQ、HTTP 指標和日誌。
用真實業務 prompt 測。

常見坑

LMCache 快取的是 KV Cache，不是最終回答。不要只看 tokens/s，它更直接影響 TTFT 和 prefill。也不要亂調 chunk-size、忽略版本相容或缺少觀測指標。

總結

LMCache 適合長 prompt 重複出現的 LLM 推理服務。已經在用 vLLM 的話，可以先用 MP 模式本機跑通，再用共享前綴請求確認命中，最後拿真實流量對比 TTFT。

LLM推理 on KnightLi的博客