前綴快取：讓同一份系統提示詞不再反覆付費

你每天往 LLM API 發送數千個請求，每一次都帶著同樣的系統提示詞、同樣的 few-shot 範例。模型並不知道它們一樣——除了前綴快取這條路，每個部分都要重新計算一遍。前綴快取（prefix caching，各家產品裡也叫 context caching）不改變模型，也不改變答案，它只做一件事：把請求開頭那段重複計算的 K/V 中間結果留下來，下一個人接著用。

它到底快取了什麼

不是最終答案。是自迴歸生成時，提示詞每個 token 在每層注意力機制中算出的 key/value 張量。算第一個 token 時，長提示詞的主要開銷就在這裡。前綴快取把這部分結果按 KV block 存住，下一個請求只要開頭位元組級一致，就直接引用，不再重算。

這也解釋了它的硬性前提：匹配從第一個位元組開始，一路比對。系統提示詞裡多一個空格、少一個換行，從那個位置起全部失效。

一條最重要的工程規則：固定在前，變化在後

快取命中率幾乎完全由 prompt 的結構決定：

- 系統提示詞放在最前，且長期不動。改詞可以，但把改動放最後，前面所有穩定內容繼續命中。

- 使用者輸入、檢索文件、當前時間戳記這類每次不同的內容，一律放後面。時間戳記放最末尾，而不是一開始「今天是 2026-08-28」。

- 檢索場景下，把穩定 Few-shot 放在檢索結果前面，同一段被多輪引用也能吃命中。

RAG 系統常見的錯誤是每次把「使用者問題 + 檢索片段」隨機排序後拼進 prompt，前綴從第四個 token 起就全亂了，快取形同虛設。

收益體現在哪三個數字

1. **首 token 延遲（TTFT）**：提示詞階段佔去首次響應的大頭。同樣 4k token 前綴，命中快取時 TTFT 常能縮到未命中的兩三成以下，具體倍數看模型和併發。

2. **輸入成本**：主流雲端廠商對快取命中的輸入 token 按約 10% 計費。系統提示詞 2k token、日發萬級請求，差額是按天累計的真金白銀。

3. **派發效率**：多個同前綴請求會把 KV block 留在同一 GPU 顯存裡，引擎順手把它們排進同批連續批次處理，整體吞吐量上升。

算一筆具體的帳：一個客服機器人，系統提示詞加人格設定共 1,500 token，日均 20,000 次請求，輸入單價每百萬 token 3 元。沒有快取時，這部分提示詞每天花 1,500 × 20,000 ÷ 1,000,000 × 3 = 90 元；快取命中 90% 後，只有 10% 按原價計費，每天 18 元，一年多出約 31,000 元的差額空間。如果你的系統提示詞不足兩百 token，那前綴快取的主要價值就不在成本，而在 TTFT——幾百毫秒的首字延遲對聊天產品的體感影響，比帳單明顯得多。

容易踩的三個坑

- **過期比你想得快**。KV block 閒置若干分鐘就會被回收。流量是「十分鐘五百個請求 + 三小時空窗」這種形態時，你會大量撞上不命中，而不是快取壞了。

- **換模型 = 全量重算**。快取是按模型權重組織的，A/B 切模型那一分鐘，命中歸零，TTFT 會有一陣毛刺，屬正常現象。

- **別只看 usage 總價**。回應裡的 `cached_tokens` 才是真實命中率。週均值掉到三四成，大概率是有人在提示詞開頭加了東西——把它當成一條告警指標掛上。

落地的三步

先把現有 prompt 從前往後過一遍，按「永不變 → 偶爾變 → 每次變」重排，這一步不花一分錢，通常立竿見影。再確認用的是原生支援的快取端點而不是自己手刻 Redis（RAG 語意快取是另一件事，命中的是整條答案，別混用）。最後把 `cached_tokens / prompt_tokens` 比率進監控，低於閾值就有人動了共享前綴。

前綴快取不提升模型能力，它只是讓你為說了八百遍的話，只付一次錢、等一次時間。