AWS 說明 Amazon Bedrock 上 OpenAI 模型的提示快取模式

背景

AI 代理（能自主執行任務的軟體）在執行任務時，每次呼叫大型語言模型（LLM，能預測下一個字元的模型）都需要重新發送完整的對話歷史、工具定義與指令，以維持上下文連貫性。由於模型本身沒有跨請求的內部記憶，這導致代理在進行多輪操作（如第 20 輪時需重讀前 19 輪內容）時，使用者需重複支付這些輸入 token 的費用。提示快取（Prompt Caching）技術旨在解決此問題，透過儲存輸入提示的處理狀態，讓後續請求能重複利用已計算好的部分，從而降低輸入價格並提升回應速度。 AWS ML Blog

發生什麼事

AWS 在 2026 年 10 月 26 日發布技術部落格，說明如何在 Amazon Bedrock 上使用 OpenAI 模型時應用提示快取模式。該文章介紹了隱式（Implicit）與顯式（Explicit）兩種快取機制，並展示如何結合兩者以優化代理在靜態指令、動態對話歷史以及子代理（Subagents）場景下的成本。 AWS ML Blog

重點內容

提示快取的運作原理是儲存模型在預填充（Prefill，模型處理輸入並建立工作狀態的階段）階段建立的鍵值向量（Key-Value, KV，模型的工作狀態）狀態。當後續請求的輸入 token 前綴與快取內容完全一致時，服務會載入已儲存的狀態，僅處理新增的內容。Amazon Bedrock 支援兩種模式：隱式快取由服務自動判斷可重複使用的前綴結束點；顯式快取則由開發者透過 prompt_cache_breakpoint 參數明確標記快取邊界。AWS 建議同時使用兩者，以兼顧自動管理對話增長與共享靜態內容。 AWS ML Blog

在靜態內容快取方面，可重複使用的前綴必須達到 1,024 token 才能符合資格。測試顯示，對於約 4,000 token 的工具與指令前綴，首次請求寫入 4,120 token，後續請求則讀取這 4,120 token。為了確保快取命中，開發者必須保證指令與工具列表的序列化方式完全一致，並將變動的資料（如日期、使用者名稱、請求 ID）放置在快取邊界之後。此外，Model Context Protocol (MCP，讓模型與外部工具溝通的標準協定) 伺服器或其他工具傳遞形式需要被索引，以確保一致性。 原文

在對話歷史與工具結果的處理上，隱式模式允許 Amazon Bedrock 重複使用未改變的前綴，並快取新增的內容直至最後一個工具結果。在一個六輪對話的工作負載測試中，GPT-6 Astra 模型在使用隱式快取時，輸入成本比未使用快取時降低約 62%；使用顯式滾動斷點（Rolling breakpoints，隨對話增長而移動的快取標記點）則降低約 61%。隨著對話增長，兩種模式都能重複利用更多的歷史內容。 原文

對使用者的意義

開發者可以透過現有的 Amazon Bedrock 客戶端整合這些快取功能。對於需要頻繁呼叫工具且對話歷史較長的 AI 代理應用，使用快取能降低輸入 token 的費用。開發者可將靜態的工具定義與指令標記為顯式快取，以便在不同會話或啟動輔助代理時重複使用；同時啟用隱式快取以自動處理隨對話增長而變動的歷史記錄。 AWS ML Blog

限制與未定事項

提示快取僅在輸入文字完全一致時生效，任何序列化差異或變動資料位置錯誤都會導致快取失效。可重複使用的前綴必須達到 1,024 token 的門檻。此外，隱式快取的自動斷點位置由服務決定，若需要跨不同任務共享較短的靜態前綴，仍需使用顯式標記。測試數據基於特定工作負載，實際節省比例需依個別代理應用進行測量。 AWS ML Blog

接下來要看的事

• Amazon Bedrock 上其他模型（如 Anthropic Claude 或 Meta Llama）的提示快取支援情況與效能差異。
• 顯式快取與隱式快取在極長上下文（如超過 100k token）下的命中率與成本效益比較。
• AWS 是否提供工具來自動檢測序列化差異以優化快取命中率。