問題：重複的 context 正在吃掉你的預算
在 Amazon Bedrock 上，如果你把同一份 10,000 token 的合約文件傳給模型 50 次，每次搭配不同的使用者問題，你總共要為 500,000 個輸入 token 付全額費用——即使模型每次都重新處理幾乎相同的內容。AWS Machine Learning Blog 在 2026 年 9 月 15 日的文章中點出這個常見的浪費模式。
傳統的省錢方法各有取捨：縮短 prompt 可能降低 context 品質；縮小 context window 會限制模型推理完整資訊的能力；應用層的 response caching 只對完全相同的查詢有效，當同一份 context 配上不同問題時就幫不上忙。
解法：在基礎設施層快取 prompt 前綴
Amazon Bedrock 的 prompt caching 直接在基礎設施層處理這個問題。你在請求中放置一個 cachePoint 標記，Bedrock 會檢查標記之前的內容是否與現有快取條目相符。如果命中（cache hit），模型可以跳過重新處理這些 token，直接從快取狀態開始生成；如果未命中（cache miss），模型處理完整內容並將結果寫入快取，供未來請求使用。
這個機制帶來兩個直接好處：快取讀取的輸入 token 成本比標準輸入低 90%，而且 time-to-first-token（TTFT）會縮短，因為模型不用從頭處理整個前綴。
四個關鍵參數決定快取行為
實際使用時，有四個概念需要掌握：
- 快取範圍：快取條目限定在個別 AWS 帳戶和 AWS Region 內。
- Token 門檻：每個 cache checkpoint 必須達到最低 token 數才會啟動。例如 Anthropic Claude Sonnet 4.5 和 Sonnet 4.6 要求每個 checkpoint 至少 1,024 token，Opus 模型則要求至少 4,096 token。
- TTL：快取條目根據請求中指定的 TTL 過期。預設是 5 分鐘，部分模型支援最長 1 小時。
- 模型無關的語法：Converse API 的
cachePoint語法在支援的模型系列中完全相同，包括 Anthropic Claude 和 Amazon Nova。
成本結構：寫入貴一點，讀取便宜很多
Prompt caching 在標準輸入和輸出 token 之外，新增了兩種 token 類別：
| Token 類型 | 說明 | 與標準輸入相比的成本 |
|---|---|---|
cacheWriteInputTokens |
寫入快取的 token（第一次請求） | 高 25% |
cacheReadInputTokens |
從快取讀取的 token（後續請求） | 低 90% |
cacheWriteInputTokens（1 小時 TTL） |
以 1 小時 TTL 寫入快取的 token | 高 100%（2 倍） |
對於重複 context 的工作負載，輸入 token 成本大約可省下 75%。舉例來說，如果你把一份 10,000 token 的文件配上 10 個不同問題，第一次請求會產生快取寫入成本，其餘九次請求每次都以低 90% 的成本從快取讀取，這樣對該文件 context 的輸入 token 成本淨省約 75%。前提是所有後續請求都在 TTL 時間窗內發生；如果請求在過期後才來，就會觸發新的快取寫入，降低淨省幅度。
實作模式：從基本到進階
AWS 的文章用 Converse API 示範了六種情境，從簡單到複雜：
- 訊息內容快取：快取長文件以進行多問題分析。
- 系統提示快取：跨對話快取 persona 定義和指令。
- 工具定義快取：為 agentic 工作流快取 tool schema。
- 混合 TTL 快取：為不同內容層級指定不同的快取生命週期。
- 租戶隔離：在多租戶應用中實作每個租戶的快取分離。
- LangChain 整合：在 LangChain 框架中使用 prompt caching。
最基本的模式是把 cachePoint 放在靜態文件和動態問題之間：
content = [
{"text": "<static document content>"},
{"cachePoint": {"type": "default"}}, # 快取以上所有內容
{"text": "<user question>"} # 動態，每次請求不同
]這個模式特別適合 RAG 應用、程式碼助理參考大型 codebase，或任何需要反覆查詢同一份參考資料的場景。
何時該用、何時該避開
Prompt caching 不是萬靈丹。如果你的請求每次都帶不同的 context，快取命中率會很低，你反而要為第一次寫入多付 25% 的成本。跨 Region 的 inference profile 也可能偶爾增加快取寫入頻率，因為請求會自動路由到不同 Region。
但如果你正在建構多輪對話、agent 工作流，或任何會重複使用同一份 system prompt、工具定義或知識庫文件的產品，這個功能值得認真評估。它讓你在不犧牲 prompt 品質或 context 完整性的前提下，直接降低基礎設施成本。
在設計這類快取策略時，可以參考我們先前討論過的流程編排執行模型——先想清楚哪些內容是靜態的、哪些是動態的，才能把 cachePoint 放在對的位置。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。