大語言模型應用日益複雜，推理成本與延遲越來越重要。一次請求可能包含系統提示、對話歷史、檢索文檔、工具定義和用户輸入，累計數千甚至數百萬 token。如果不加緩存，服務端每次都把相同上下文重新計算一遍，既耗時又浪費算力。實際上，LLM 服務中的緩存不是一個單一功能，而是位於服務堆棧不同層次的四種機制：KV 緩存、前綴緩存、提示詞緩存和語義緩存。
KV 緩存是現代自迴歸模型推理的基礎。模型並不是一次生成完整回覆，而是一個 token 一個 token 地生成；每生成一個新 token，注意力機制都要計算它與此前所有 token 的關係，為已處理 token 生成 Key 和 Value 張量。KV 緩存把這些張量存放在內存（通常為 GPU 顯存）中。prefill 階段處理完提示後緩存 K/V 狀態，後續解碼步驟直接複用並增量追加，避免序列變長後反覆從頭重建注意力狀態。它的侷限是通常只服務於當前請求：該請求結束後，相關 K/V 狀態不會自動成為另一個無關請求的緩存。
前綴緩存把 KV 緩存的複用擴展到不同請求之間。實際場景中，許多用户的請求共享長長的系統提示、公司政策、工具定義，只有末尾的用户問題不同。若新請求與某先前請求有相同的開頭，服務系統直接複用那部分 K/V，無需重新計算。實現上，前綴緩存把提示切成定長的 token 塊，併為每個塊計算基於內容和位置的哈希；新請求通過哈希檢查找到 CACHE HIT，命中塊直接複用，只有 CACHE MISS 的部分送入模型計算。緩存空間有限時，系統通常用 LRU 策略淘汰舊塊。多模態場景中則要注意：文本相同但圖片不同，不能僅憑文本判定可複用。vLLM 等系統已經以塊式 KV 管理、哈希、查找和淘汰機制實現了前綴緩存。
提示詞緩存則把緩存責任交給 API 提供商。對於通過雲 API 使用模型的應用，請求裏的系統提示、文檔、工具定義等常達數萬 token，且幾乎不變。提供商可以在基礎設施層緩存這些重複內容，使後續請求只按緩存的一部分重新處理。多家大模型 API 採用分區定價：例如緩存命中約為不緩存價格的 0.1 倍，寫入緩存約為 1.25 倍或更高（有些還會額外收存儲費，有些則自動緩存且不另計費）。因此，提示詞緩存能同時改善輸入處理成本與延遲。
語義緩存是四種緩存中離模型最遠的一種：它可以完全跳過 LLM。當用户提出的問題與歷史問題語義相近時，系統直接返回之前生成的答案，而不調用模型。通常會用嵌入向量而不是文本哈希來判斷語義相似度。它把響應時間降到最低、避免昂貴推理，但要處理閾值設定、答案新鮮度和多輪語境等問題，適合 FAQ 和知識庫等重複性較高的場景。
綜合來看，四種緩存解決的是不同環節的重複勞動：KV 緩存服務於單次請求的解碼提速；前綴緩存讓共享前綴的請求減少 prefill；提示詞緩存把固定上下文放到服務商緩存層；語義緩存則在請求進入模型之前就用相似答案命中。實際系統中它們並非互斥，而是可以疊加部署。理解它們之間的差別，有助於針對成本、延遲和緩存命中率做出正確取捨。