提示快取的類型支援的模型、區域和明確的快取限制來自 Anthropic 的模型提示快取來自 OpenAI 的模型提示快取開始使用

提示快取可加快模型推論速度

提示快取是一項選用功能，您可以搭配 Amazon Bedrock 上支援的模型使用，以減少推論回應延遲和輸入字符成本。Amazon Bedrock 支援兩種類型的提示快取：隱含提示快取和明確提示快取。每種類型的支援會因模型和 API 而異。

當工作負載的內容冗長並重複，且經常重複用於多個查詢時，提示快取很有幫助。例如，如果您有一個聊天機器人可供使用者上傳文件並提出相關問題，則每次使用者提供輸入時，模型處理文件可能會很耗時。透過提示快取，您可以快取文件，以便包含文件的未來查詢不需要重新處理該文件。

提示快取的類型

兩種類型的選擇可重複使用提示內容的方式不同：

Type	運作方式	請求組態
隱含提示快取	Amazon Bedrock 和模型會自動嘗試重複使用合格的提示字首。	您的請求不需要快取控制或中斷點。
明確提示快取	您可以透過新增模型特定的快取控制項或中斷點來識別可重複使用的提示字首。	您的請求必須包含模型和 API 支援的快取控制項。

隱含提示快取

隱含提示快取會自動嘗試重複使用合格的提示字首，而無需在您的請求中進行快取控制。在提示開頭保留靜態內容，並在結尾保留動態內容，以增加完全符合字首的可能性。

隱含提示快取是最佳作法。重複相同的提示並不保證快取命中，而且快取命中率可能會有所不同。

明確提示快取

明確提示快取可讓您使用模型特定的快取控制項或快取檢查點來識別可重複使用的提示字首。快取檢查點是標記，可定義您要快取之提示的連續子區段。提示字首在請求之間應保持靜態。在後續請求中變更提示字首會導致快取遺漏。

快取檢查點的字符數量下限和上限，取決於模型。只有在提示字首總數符合字符數量下限時，您才能建立快取檢查點。例如，每個快取檢查點至少Claude Opus 5需要 512 個字符，每個快取檢查點至少Claude Sonnet 5需要 1，024 個字符，每個快取檢查點至少Claude Haiku 4.5需要 4，096 個字符。下限會累積套用至每個檢查點之前的整個提示字首，包括 tools、 system和 messages欄位中適用的內容。快取檢查點之間沒有所需的字符數目下限。對於最低 1，024 權杖的模型，只要每個檢查點之前的總提示字首至少包含 1，024 個權杖，您就可以定義間隔小於 1，024 個權杖的其他檢查點。如果您在提示字首總數達到字符數量下限之前新增快取檢查點，您的推論仍會成功，但您的字首不會快取。

快取具有存留時間 (TTL)，它會在每次快取命中成功時重設。在此期間，會保留快取中的內容。如果 TTL 時段內沒有發生快取命中，則快取會過期。許多模型支援 5 分鐘的 TTL。檢查模型的模型卡，以查看確切的 TTL 條件。

明確提示快取可讓您控制哪些提示內容符合快取資格。它不保證合格的請求會導致快取命中。

快取權杖的帳單

對於隱含提示快取和隱含提示快取，成功從快取讀取的權杖會報告為快取權杖，並以模型的快取讀取速率計費。未從快取讀取的字符會以標準輸入字符費率計費。根據模型，寫入快取的字符可以高於標準輸入字符費率的費率計費。如需更多資訊，請參閱 Amazon Bedrock 定價頁面。

重要

支援提示快取並不保證任何請求的快取命中。檢查模型回應中的快取用量欄位，以判斷權杖是讀取還是寫入快取。

當您使用支援的模型在 Amazon Bedrock 中執行推論時，可以使用提示快取。每個提示快取類型的可用性因模型和 API 而異。提示快取可透過下列 Amazon Bedrock 功能使用：

Converse 和 ConverseStream API: 您可以與支援的模型進行對話。針對明確提示快取，請在提示中指定快取檢查點。
InvokeModel 和 InvokeModelWithResponseStream API: 您可以向支援的模型提交單一提示請求。針對明確提示快取，啟用提示快取並指定快取檢查點。
透過跨區域推論的提示快取: 提示快取可與跨區域推論搭配使用。跨區域推論會自動選取您地理位置內的最佳 AWS 區域，以滿足您的推論請求，從而最大化可用的資源和模型可用性。在需求高的時候，這些最佳化可能會導致快取寫入增加。
Amazon Bedrock 提示管理: 當您建立或修改提示時，可以選擇啟用提示快取。視模型而定，您可以快取系統提示、系統指示和訊息 (使用者和助理)。您也可以選擇停用提示快取。

注意

只有隨需推論端點才支援提示快取。批次推論 API 不支援此功能。

對於支援明確提示快取的模型，APIs 提供對提示快取的精細控制。您可以在提示中設定個別快取檢查點，並將檢查點新增至模型允許的最大值。如需詳細資訊，請參閱支援的模型、區域和明確的快取限制。

支援的模型、區域和明確的快取限制

提示快取支援因模型和 API 而異。模型卡可識別模型是否支援隱含提示快取、隱含提示快取，或兩者皆支援。提示快取可在支援模型的所有 AWS 區域中使用。若要依區域檢查模型可用性，請參閱依模型的區域可用性。

下表列出支援明確提示快取的模型及其字符最小值、快取檢查點數量上限，以及允許快取檢查點的欄位。

若要查看模型支援的提示快取類型，請參閱模型一目了然，然後選擇您感興趣的模型。

模型名稱	模型 ID	版本類型	每個快取檢查點的字符數量下限	每個請求的快取檢查點數量上限	支援的 TTL	接受提示快取檢查點的欄位
Claude Fable 5.1	anthropic.claude-fable-5-1	全面推出	512	4	5 分鐘、1 小時	`system`、`messages` 和 `tools`
Claude Mythos 5.1	anthropic.claude-mythos-5-1	門控	512	4	5 分鐘、1 小時	`system`、`messages` 和 `tools`
Claude Fable 5	anthropic.claude-fable-5	全面推出	512	4	5 分鐘、1 小時	`system`、`messages` 和 `tools`
Claude Mythos 5	anthropic.claude-mythos-5	門控	512	4	5 分鐘、1 小時	`system`、`messages` 和 `tools`
Claude Mythos Preview	anthropic.claude-mythos-preview	門控	4,096	4	5 分鐘、1 小時	`system`、`messages` 和 `tools`
Claude Opus 5	anthropic.claude-opus-5	全面推出	512	4	5 分鐘、1 小時	`system`、`messages` 和 `tools`
Claude Opus 4.8	anthropic.claude-opus-4-8	全面推出	1,024	4	5 分鐘、1 小時	`system`、`messages` 和 `tools`
Claude Opus 4.7	anthropic.claude-opus-4-7	全面推出	4,096	4	5 分鐘、1 小時	`system`、`messages` 和 `tools`
Claude Opus 4.6	anthropic.claude-opus-4-6-v1	全面推出	4,096	4	5 分鐘、1 小時	`system`、`messages` 和 `tools`
Claude Opus 4.5	anthropic.claude-opus-4-5-20251101-v1：0	全面推出	4,096	4	5 分鐘、1 小時	`system`、`messages` 和 `tools`
Claude Sonnet 5	anthropic.claude-sonnet-5	全面推出	1,024	4	5 分鐘、1 小時	`system`、`messages` 和 `tools`
Claude Sonnet 4.6	anthropic.claude-sonnet-4-6	全面推出	1,024	4	5 分鐘、1 小時	`system`、`messages` 和 `tools`
Claude Sonnet 4.5	anthropic.claude-sonnet-4-5-20250929-v1:0	全面推出	1,024	4	5 分鐘、1 小時	`system`、`messages` 和 `tools`
Claude 3.7 Sonnet	anthropic.claude-3-7-sonnet-20250219-v1:0	全面推出	1,024	4	5 分鐘	`system`、`messages` 和 `tools`
Claude 3.5 Sonnet v2	anthropic.claude-3-5-sonnet-20241022-v2:0	預覽版	1,024	4	5 分鐘	`system`、`messages` 和 `tools`
Claude Haiku 4.5	anthropic.claude-haiku-4-5-20251001-v1:0	全面推出	4,096	4	5 分鐘、1 小時	`system`、`messages` 和 `tools`
GPT-5.6 Sol	openai.gpt-5.6-sol	全面推出	1,024	4	30 分鐘	`prompt_cache_breakpoint` 在 `input_text`、 `input_image`和 `input_file`區塊上（回應 API)
GPT-5.6 特拉	openai.gpt-5.6-terra	全面推出	1,024	4	30 分鐘	`prompt_cache_breakpoint` 在 `input_text`、 `input_image`和 `input_file`區塊上（回應 API)
GPT-5.6 Luna	openai.gpt-5.6-luna	全面推出	1,024	4	30 分鐘	`prompt_cache_breakpoint` 在 `input_text`、 `input_image`和 `input_file`區塊上（回應 API)

若要將 1 小時 TTL 選項與支援的模型 (Claude Fable 5、Claude Opus 5、Claude Opus 4.8、Claude Opus 4.7、Claude Opus 4.6、Claude Opus 4.5、Claude Sonnet 5、Claude Sonnet 4.6、和 Claude Haiku 4.5) 搭配使用Claude Sonnet 4.5，請在快取檢查點中指定 ttl 欄位。在 Converse API 中，將 "ttl": "1h"新增至cachePoint物件。在適用於 Claude 模型的 InvokeModel API 中，將 "ttl": "1h"新增至cache_control物件。如果未提供任何ttl值，則會套用預設的 5 分鐘快取行為。1 小時 TTL 適用於長時間執行的工作階段或批次處理案例，而您想要在長時間內維護快取。

Amazon Nova 為所有文字提示提供隱含提示快取，包括 User和 System 訊息。此機制可在提示以重複部分開頭時提供延遲優勢，而不需要明確組態。Amazon Nova在模型卡中顯示為支援明確提示快取的模型也可讓您指定快取檢查點，以進一步控制快取資格。

來自 Anthropic 的模型提示快取

支援 Amazon Bedrock 上提示快取的人類模型支援隱含提示快取和明確提示快取。隱含提示快取會自動嘗試重複使用合格的提示字首，而無需在您的請求中進行快取控制。

對於明確提示快取，Amazon Bedrock 提供簡化的快取管理方法，可降低手動放置快取檢查點的複雜性。您不需要指定確切的快取檢查點位置，而是可以搭配靜態內容結尾的單一中斷點使用自動快取管理。

當您啟用簡化的快取管理時，系統會自動檢查先前內容區塊界限的快取命中，從您指定的中斷點回溯至最多約 20 個內容區塊。這可讓模型從快取中尋找最長的相符字首，而不需要您預測最佳檢查點位置。若要使用此功能，請在靜態內容的結尾放置單一快取檢查點，再放置任何動態或可變內容。系統會自動尋找最佳的快取相符項目。

為了更精細的控制，您仍然可以使用多個快取檢查點 (Claude 模型最多 4 個) 來指定確切的快取界限。如果您要快取以不同頻率變更的區段，或想要更精確地控制快取的內容，您應該使用多個快取檢查點。

重要

自動字首檢查只會從快取檢查點回溯查看大約 20 個內容區塊。如果您的靜態內容超出此範圍，請考慮使用多個快取檢查點或重組您的提示，將最常重複使用的內容放在此範圍內。

在 Anthropic Models 中使用快取管理的最佳實務

如果您有定期使用的提示（即比每 5 分鐘更頻繁使用的系統提示），請繼續使用 5 分鐘快取，因為這會繼續重新整理，無需額外付費。

1 小時快取最適合用於下列案例：

當您的提示可能使用頻率低於 5 分鐘，但比每小時更頻繁時。例如，當客服人員端代理程式需要超過 5 分鐘的時間，或與使用者儲存長聊天對話時，您通常預期該使用者可能不會在接下來的 5 分鐘內回應。
當延遲很重要時，您的追蹤提示可能會傳送超過 5 分鐘。
當您想要改善速率限制用量時，因為快取命中不會從您的速率限制中扣除。

您可以在相同的請求中使用 1 小時和 5 分鐘快取控制，但具有重要的限制：具有較長 TTL 的快取項目必須在較短 TTLs 之前出現（即 1 小時快取項目必須在任何 5 分鐘快取項目之前出現）。

來自 OpenAI 的模型提示快取

Amazon Bedrock 上的 OpenAI 模型支援透過回應 API 的隱含提示快取。GPT-5.6 模型也支援明確提示快取。回應 API 可在 bedrock-runtime和 bedrock-mantle端點上使用。

GPT-5.6 模型

GPT-5.6 Sol (openai.gpt-5.6-sol)、Terra (openai.gpt-5.6-terra) 和 Luna (openai.gpt-5.6-luna) 支援隱含提示快取和明確提示快取。明確提示快取中斷點可讓您精確控制提示的哪些部分符合快取資格。這對於代理工作流程特別有用，其中系統指示、工具定義和參考檔案在許多呼叫之間重複，但只有最新的輸入變更。

關鍵特性：

明確快取中斷點 — 將 "prompt_cache_breakpoint": {"mode": "explicit"}新增至支援的內容區塊，以標記可重複使用提示字首的確切結尾。
快取模式 — prompt_cache_options.mode設定為控制中斷點行為：
- implicit （預設） — 在最新訊息上放置自動中斷點，並使用您提供的任何明確中斷點。
- explicit — 停用自動中斷點。快取讀取和寫入只會使用明確的中斷點。如果沒有明確的中斷點，請求不會使用提示快取或產生快取寫入費用。
最短字首長度 — 每個中斷點 1，024 個字符。
最短 30 分鐘 TTL — 快取字首會保留至少 30 分鐘以供重複使用，足以涵蓋單一客服人員執行產生的呼叫爆量。TTL 透過設定，prompt_cache_options.ttl並預設為 30m。
快取寫入計費 — 寫入快取的字符會以 1.25 倍的未快取輸入字符費率計費。相較於未快取的輸入字符，快取讀取會以 90% 的折扣計費。
快取權杖不計入速率限制 — 透過提示快取讀取的快取輸入權杖不計入input-tokens-per-minute配額。

了解回應

回應中的用量物件包含兩個快取特定欄位：

cached_tokens — 從快取讀取的輸入字符數量（以快取讀取折扣率計費）。
cache_write_tokens — 寫入快取的輸入字符數量（以 1.25 倍的未快取輸入字符速率計費）。

當 cached_tokens 大於零且 cache_write_tokens 為零時，您的請求會完全符合現有的快取項目 - 不會發生新的寫入，而且您獲得最大成本節省。

在 GPT 5.6 模型中使用快取管理的最佳實務

將中斷點放在穩定內容之後 — 系統指示、工具定義和未在通話之間變更的參考文件應該出現在中斷點之前。中斷點之後的內容可以自由變更，而不會使快取的字首失效。
代理迴圈使用 explicit 模式 — 您希望完全控制快取的內容，並希望避免自動中斷點耗用寫入槽。
監控 cache_write_tokens — 比較快取寫入磁碟區與後續快取讀取，以了解淨成本影響並相應地調整中斷點放置。

GPT-5.5 和舊版模型

對於 GPT-5.6 之前的 OpenAI 模型（例如 openai.gpt-5.5和 openai.gpt-5.4)，隱含提示快取是自動的。您不需要新增任何特殊參數。系統會自動嘗試快取 1，024 個字符或更長的合格提示字首。快取寫入在這些模型上不收取額外費用。

關鍵特性：

隱含提示快取 — 不需要變更程式碼。系統會根據確切的字首比對嘗試自動快取字首。
最短字首長度 — 1，024 個字符。
無快取寫入費用 — 只有快取讀取會以折扣費率計費。
快取權杖不計入速率限制 — 透過提示快取讀取的快取輸入權杖不計入input-tokens-per-minute配額。

在 GPT-5.5 和舊版模型中使用快取管理的最佳實務

將靜態內容（系統提示、工具定義、參考文件）放在提示開頭。
將變數內容（使用者特定輸入）放在結尾。
維持具有相同字首的穩定請求串流，以將快取移出降至最低。

開始使用

以下各節向您簡短介紹如何將提示快取功能用於透過 Amazon Bedrock 與模型互動的每個方法。

Converse API 提供進階且靈活的選項，可在多回合對話中實作提示快取。如需每個模型其提示需求的詳細資訊，請參閱上一節「支援的模型、區域和明確的快取限制」。

範例請求

下列範例顯示在 Converse API 其請求的 messages、system 或 tools 欄位中設定的快取檢查點。您可以針對指定的請求將檢查點放置在這些位置中的任何一個。例如，如果將請求傳送至 Claude 3.5 Sonnet v2 模型，您可以在 messages 中放置兩個快取檢查點、在 system 中放置一個快取檢查點，並在 tools 中放置一個快取檢查點。如需建構和傳送 Converse API 請求的詳細資訊和範例，請參閱使用 Converse API 進行推論。

重要

快取檢查點的處理順序如下：tools→ system → messages。系統會針對所有三個區段組合的累積字符評估最小快取大小，而不是每個區段個別評估。由於區段是鏈結的，因此變更先前區段中的內容會使稍後區段的快取失效（例如，修改 system和 messages快取會tools失效）。為了獲得最佳快取命中率，請在變數內容 (system) 之前放置穩定內容 (tools、messages)，然後在穩定內容之後放置快取檢查點。

如下所示指定所需的 ttl 值，如果未指定 ttl 值，則會套用 5 分鐘快取的預設行為。