摘要： Amazon Bedrock 的 prompt caching 會在首次請求後快取 cachePoint 前的穩定內容，後續命中時輸入 token 單價比標準輸入低 90%。快取寫入成本高 25%，一小時 TTL 更是兩倍，因此效益取決於 TTL 內是否重複命中。功能還受到單一帳戶與 Region 範圍，以及模型最低 token 門檻限制。
問題：重複的 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 前綴
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 皆然。
成本結構：寫入貴一點，讀取便宜很多
在標準的輸入與輸出 token 之外，prompt caching 另外切出了兩種 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 才可能擺在正確的位置上。