越來越多的智能體AI系統正在從原型走向生產。大語言模型等領域的進展讓現代自主代理能夠通過多輪LLM調用來規劃、執行動作並反思結果，但從原型轉向生產的過程中，API成本不斷上升，響應延遲有時也高到難以接受。因此，優化底層基礎設施不僅是為了性能，也直接關係到系統能否長期、可持續地運行。
本文的核心是剖析兩種常用於緩解上述問題的技術——提示緩存與微調。理解二者差異後，工程師可以依據應用場景做出更合理的成本與延遲優化決策。
提示緩存的機制是保存模型此前交互所產生的信息，既可以是歷史提示詞對應的原始輸出，也可以是模型內部的注意力狀態，後者通常稱為KV緩存。當代理或用户發送與已緩存內容高度相似的提示時，系統只需提取已有結果，而不是重新執行完整的計算。這樣做的直接收益包括：響應開始生成前的時間，即首Token延遲大幅降低；對於大量重複請求，計算成本也會接近零。文中用一個簡化Python示例説明了這一思路：藉助diskcache庫，先把提示詞哈希後寫入本地緩存，第一次調用未命中時需要按正常延遲和成本調用模型，後續調用只要緩存未過期，就能直接從本地命中並返回，幾乎不產生額外開銷。該代碼並不涉及真實模型，但背後“先查緩存、未命中再計算”的邏輯正是提示緩存的實際寫照。
微調走的是另一條路。它不是每次都在提示中攜帶龐大的指令和上下文，而是讓模型直接更新權重，從而學習特定的用户行為、輸出格式、規則或新領域知識。完全重新訓練全部參數成本很高，因此業界常使用參數高效微調技術，其中LoRA尤其流行。其做法是在原模型旁添加少量低秩適配參數，只更新這部分參數即可達到接近全量微調的效果。舉例來説，使用Hugging Face Transformers和PEFT庫對TinyLlama-1.1B-Chat-v1.0施加LoRA配置後，實際需要訓練的參數僅約112.6萬個，佔全部參數的0.1023%。這説明，即使訓練較大的開源模型，採用LoRA也能把計算成本維持在可接受範圍內。
在實際決策時，需要觀察自己的數據特徵與系統所期望的行為。如果應用中存在龐大的系統提示詞、用於RAG的靜態文檔庫或反覆要求代理遵循的標準操作流程，那麼把它們整體放入緩存前綴能大幅節省Token成本；若應用是客服這類近乎相同的提問反覆出現的場景，緩存也能提供很好的成本與延遲收益。因此，當你要處理大量重複或相對靜態的上下文，並希望明顯降低TTFT和Token計費成本時，提示緩存是更直接的選擇。
反過來，如果代理必須持續產生嚴格一致的輸出，比如標準JSON、SQL或其他專門代碼，微調能避免每次在提示中堆疊大量few-shot示例；如果希望模型具備某種固定“人設”或表達方式，而非靠臨時的額外指令提醒；或者希望通過壓縮每次請求所需的上下文窗口，使重複的LLM調用更加便宜高效，那麼微調顯然更合適。
對於追求穩健整體架構的工程團隊，可以考慮將兩者結合：先用一個小型開放模型做LoRA微調，讓代理學會領域內關鍵的格式和規則；在此基礎上再實施提示緩存，把代理的系統指令和內部scratchpad緩存起來。這樣，代理在“思考-行動-觀察”的循環中每次只需計算最新生成的Token，從而同時獲得微調帶來的行為準確性，以及緩存帶來的低延遲和低費用。
總體上，提示緩存主要降低的是重複上下文帶來的冗餘成本，而微調則從根源上減少了對反覆示範和長篇指令的依賴。要想讓代理AI既高性能又經濟，掌握這兩種工具之間的協同關係才是關鍵。