在建構大語言模型（LLM）應用時，開發者經常會面臨兩個問題：模型反應速度慢，以及推理成本高。 Amazon Bedrock 針對這項痛點推出了「提示快取（Prompt Caching）」功能，協助開發者大幅提升API 呼叫效率，同時大幅節省成本。
什麼是Amazon Bedrock提示快取？
在許多生成式AI 應用中，提示（Prompt）中會重複包含大量相同內容，例如係統指令、歷史對話、上下文說明等。每次呼叫模型時，這些重複的提示部分都需要重新處理，造成計算資源的浪費。
Amazon Bedrock 提示快取的核心在於：將提示中重複的「前綴」部分快取下來，後續呼叫時無需重複推理，從而減少延遲和成本。
與傳統緩存不同，這不僅是文字緩存，而是對大型語言模型內部「神經狀態」的緩存——包括注意力模式、標記關係等深層計算結果。 Amazon Bedrock 會在指定檢查點擷取這些狀態，並安全地儲存在AWS 內部的快取層中，僅對本帳戶有效。
技術架構概覽
Bedrock 的快取系統建構在其推理執行環境上，與模型呼叫的執行路徑高度集成，架構設計類似AWS Lambda。快取系統位於API 和模型執行層之間，能夠攔截請求並動態儲存神經狀態。
快取分為兩類操作：
- 寫入快取：首次遇到的提示前綴會觸發快取寫入，並稍微增加處理開銷。
- 讀取快取：後續重複提示可直接從快取讀取神經狀態，大幅降低處理負載。
此機制特別適合對提示內容重複率高的應用，如文件問答、對話機器人、程式碼產生助理等。
成本優化機制
提示快取的最大優勢之一是成本節省。以Claude 3.5/3.7 Sonnet 為例（輸入成本0.003 美元/千token）：
類型成本/千token描述正常輸入$0.003標準推理調用快取寫入$0.00375成本增加約25%快取讀取$0.0003成本降低高達90%輸出部分$0.015與快取無關，價格相同
假設使用者上傳一個包含3 萬token 的財報文檔，並針對它提出8 個問題：
- 無快取成本：每次問題需重新處理文檔，總計約$0.72；
- 使用快取：首個請求寫入緩存，後續7 次讀取緩存，總成本約$0.1755，節省約75.6%。
如果您的系統每月需處理10,000 份文檔，使用提示快取每月可節省超$5,000 的成本。
適用場景與限制
提示快取並非適用於所有場景。以下是建議啟用快取的典型用例：
- 長提示重複使用：如客服聊天歷史、問答上下文、系統指令等；
- Agent 多輪推理：代理需重複引用環境設定或任務說明；
- 文檔分析工具：針對相同文件反覆提問；
- 代碼助手：每次呼叫需重複載入相同項目上下文。
但在以下場景下，快取收益不明顯，甚至可能增加成本：
- 一次性提示：如每次處理的文檔內容不同；
- 極短提示：低於觸發快取機制的最小閾值；
- 呼叫間隔過長：快取有效期限僅數分鐘，超過時間即失效；
- 提示差異化大：前綴略有不同，可能導致快取未命中。
因此，開發者應結合特定應用的呼叫模式，評估是否啟用提示緩存，並透過API 監控指標如CacheReadInputTokens 和CacheWriteInputTokens 來量化使用效果。
與Amazon Bedrock 其他功能集成
提示快取可無縫整合到Amazon Bedrock 的其他能力：
- 與代理集成：支援建構更複雜的代理任務流程，提升反應速度；
- 長系統提示支持：無需為長指令重複支付高昂計算代價；
- 增強情境穩定性：快取提示前綴幫助建立更穩定的上下文鏈條。
整體來看，提示快取特別適用於需要高頻呼叫相同上下文的LLM 應用場景。借助它，您可以大幅降低成本、縮短回應時間，建立更有效率的AI 服務。
結語
Amazon Bedrock 的提示快取機制不僅是一項技術最佳化，更是企業級AI 應用降本提效的重要工具。它幫助開發者在不犧牲準確性和上下文完整性的前提下，加快模型回應、節省成本，在真實業務中實現更具性價比的LLM 推理體驗。
如果您正在開發基於Bedrock 的AI 應用，不妨評估提示快取帶來的潛力效益。在大模型規模化落地的今天，優化每個token 的使用成本，就是贏得商業競爭的關鍵一步。
