譯者 | 核子可樂
審校 | 重樓
是不是總感覺ChatGPT響應緩慢？
大家可能沒有留意，大模型應用程序的提示詞重復率高達70%，問天氣、問翻譯和問節日安排的內容大量出現，且每次都要消耗算力進行處理。這樣的情況在分布式集群的各節點上被無數次放大，白白燒掉寶貴的能源和金錢。
為此，Anthropic日前詳細介紹了如何利用提示詞緩存技術將推理成本降低90%。其實不少開源大模型運行時（包括vLLM、TRT-LLM和SGLang等）都擁有自動前綴緩存（也稱上下文緩存）功能，負責將相同前綴請求中的輸入提示詞自動緩存起來。
前綴緩存的工作原理
為了更好地理解前綴緩存，我們先來聊聊大模型推理的工作原理。
推理過程在宏觀上分為兩個步驟：
- 通過正向傳遞處理給定的輸入標記序列，即預填充階段。
- 解碼階段，從首個token連續生成至最后一個token，且當前token依賴于上一token。
圖一
由于此過程的自回歸屬性（即新token依賴于前一token），因此有效的內存管理非常重要。多數大模型會采取為中間狀態保留KV緩存的做法。與簡單提示詞或語義緩存的不同之處在于，其不會將全文輸入和輸出保存在數據庫內，因為這樣就只有完全匹配（或者幾乎完全相同的查詢）才能立即命中緩存并收到響應。
在預填充階段，在大模型處理token時會計算“注意力”，即每個token與其他token的關系。計算過程會為每個token生成鍵-值矩陣。如果不經任何KV緩存，那么模型每次回顧此前token時都需要重新計算這些矩陣。KV緩存在設計上只支持一次生成，即只會在生成一條輸出的過程中捕捉中間狀態。
如果有兩條具有相同前綴的請求，該怎么處理？
KV緩存的基本思路啟發并衍生出了前綴緩存，確保在生成包含相同前綴的提示詞時給出不同的響應。簡單類比一下，假設已經計算過2 * 6的結果，那么對于2 * 6 * 3 * 5 這個新問題，可以直接復用之前的答案，避免在序列中重復計算。
這對應用程序有何幫助？
我們可以使用以下最佳實踐來充分發揮前綴緩存的優勢：
為提示詞結構設計策略
可以將系統提示詞、基礎指令或者共享上下文等常量元素放在提示詞的開頭（圖二），從而為多條查詢建立可復用基礎。其他動態或特殊內容則可放在末尾。
圖二
對請求進行重新分組
將共享通用結構/前綴的請求捆綁在一起（圖三）。例如，在處理以常見問候語或稱呼開頭的多條客戶查詢時，可以嘗試將它們分為一組，盡可能提高計算過程的緩存和復用率。
圖三
監控緩存利用率
另外，需要注意跟蹤緩存利用率。
包括命中率與未命中率：
- 找出哪些前綴比其他一般前綴更重要
- 識別緩存未命中的模式
依托這些見解，就能優化提示詞結構以獲得最佳性能。
簡單示例
以下示例為當多條查詢共享相同的上下文時，前綴緩存如何優化大模型推理。我們使用一份簡單的員工數據庫表，并對其中內容進行不同查詢。
Python
import time
from vllm import LLM, SamplingParams
# A small table containing employee information
LONG_PROMPT = """You are a helpful assistant that recognizes content in markdown tables. Here is the table:
| ID | Name | Department | Salary | Location | Email |
|----|---------------|------------|---------|-------------|---------------------|
| 1 | Alice Smith | Engineering| 85000 | New York | alice@company.com |
| 2 | Bob Johnson | Marketing | 65000 | Chicago | bob@company.com |
| 3 | Carol White | Sales | 75000 | Boston | carol@company.com |
| 4 | David Brown | Engineering| 90000 | Seattle | david@company.com |
| 5 | Eve Wilson | Marketing | 70000 | Austin | eve@company.com |
"""
def get_generation_time(llm, sampling_params, prompts):
start_time = time.time()
output = llm.generate(prompts, sampling_params=sampling_params)
end_time = time.time()
print(f"Output: {output[0].outputs[0].text}")
print(f"Generation time: {end_time - start_time:.2f} seconds")
# Initialize LLM with prefix caching enabled
llm = LLM(
model='lmsys/longchat-13b-16k',
enable_prefix_caching=True
)
sampling_params = SamplingParams(temperature=0, max_tokens=50)
# First query - will compute and cache the table
get_generation_time(
llm,
sampling_params,
LONG_PROMPT + "Question: What is Alice Smith's salary? Your answer: Alice Smith's salary is "
)
# Second query - will reuse the cached table computation
get_generation_time(
llm,
sampling_params,
LONG_PROMPT + "Question: What is Eve Wilson's salary? Your answer: Eve Wilson's salary is "
)運行以上代碼，即可查詢不同查詢間的實際時間差異。第二條查詢明顯更快，因為其復用了緩存中的表上下文。具體時間將根據硬件和設置而有所浮動。
總結
前綴緩存是一項強大的大模型應用優化技術。實施上述最佳實踐將幫助開發人員顯著降低推理成本，且不致影響響應質量。參考示例也表明其操作難度極低，推薦大家馬上在自己的應用程序中試一試。
原文標題：90% Cost Reduction With Prefix Caching for LLMs，作者：Mahak Shah
