越來越多的智慧體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既高效能又經濟，掌握這兩種工具之間的協同關係才是關鍵。