GPT-6 Astra 提示快取指南：如何降低重複上下文成本
了解 GPT-6 Astra 提示快取的運作方式、如何建構可重複使用的前綴、放置快取中斷點、測量命中率，以及避免代價高昂的快取未命中。
大型代理提示詞經常重複相同的系統政策、工具定義、產品文件、範例和對話歷史。重新發送這些內容有時無法避免；但為完全相同的前綴支付完整的輸入成本和延遲則不然。GPT-6 Astra 在 Responses API 中支援提示詞快取，因此重複的前綴可以被重複使用。
快取是一種優化，而非記憶體。它不會讓模型在不同請求之間記住客戶，也不會改變模型所看到的內容。請求仍然需要相關的輸入。差別在於，符合條件的相同前綴可以從快取中以較低的快取輸入費率提供服務。
GPT-6 Astra 快取內容
快取是基於前綴的。當下一個請求的開頭內容與先前匹配時，OpenAI 可以重複使用提示詞開頭的標記。一個有用的心智模型是，一份文件的穩定章節放在前面，而請求特定的附錄則放在最後。
將這些放在靠近前方：
- 穩定的開發者說明；
- 工具架構以穩定順序排列；
- 跨請求使用的長篇參考文件；
- 規範範例與輸出規則。
將這些放在接近結尾的地方：
- 當前使用者訊息；
- 時間戳、請求ID與臨時狀態；
- 每次呼叫時都會變動的檢索段落；
- 非共享的使用者偏好設定。
在接近頂部插入一個時間戳記，可能會使其後的所有內容失效。同樣地，從無序映射生成工具陣列，可能會產生語義相同但字節不同的前綴。請以確定性方式建構提示。
隱式與顯式快取
GPT-5.6 及後續版本會暴露 prompt_cache_options。在隱含模式下，服務會自動識別可重複使用的斷點。這是最簡單的起點，適用於提示詞包含一個大型且穩定的前綴時。
import OpenAI from "openai";
const client = new OpenAI();
const response = await client.responses.create({ model: "gpt-6-astra", prompt_cache_key: "support-agent:v4", prompt_cache_options: { mode: "implicit", ttl: "30m" }, input: [ { role: "developer", content: "穩定的政策與操作說明..." }, { role: "user", content: "為什麼我的發票被重複開立？" } ] });
目前記錄的 TTL 值為 `30m`，30 分鐘是預設值。請勿針對未記錄的持續時間進行設計。OpenAI 也將舊的 `prompt_cache_retention` 欄位標記為已棄用。
明確模式賦予應用程式更多控制權。您可以在值得保留的邊界處加入 `prompt_cache_breakpoint` 內容項目。當提示詞由數個穩定區塊後接變動素材組合而成時，此功能相當實用。每個請求最多可寫入四個中斷點，而服務最多會考量最新的 80 個中斷點。中斷點並非越多越好：每次寫入都有成本，且碎片化的前綴會更難推敲。
## 實用的前綴架構
對於一個生產環境的代理，請使用四層：
### 1. 身份識別與安全性
將持久角色、安全限制和回應合約放在首位。刻意對這個區塊進行版本控制。政策編輯應建立新的快取金鑰，而非靜默混合兩個版本的測量結果。
### 2. 工具定義
工具結構描述通常既龐大又重複。請保持名稱、描述、屬性及順序的穩定。盡可能移除未使用的工具；這能同時降低未快取與已快取的上下文，並減少工具選擇的模糊性。
### 3. 共享知識
添加耐用的手冊、分類法、風格指南或產品文件。如果知識頻繁變動，檔案搜尋可能比將所有內容嵌入每個提示中更好。快取穩定的操作知識；檢索變動中的事實。
### 4. 動態請求狀態
附加使用者輸入、當前記錄、即時搜尋結果及暫存狀態。此放置方式可保護可重複使用的前綴免受常規變更影響。
在創意工作流程中，穩定層可能包含動畫製作規則與工作室風格，而動態尾端則包含當前場景。像 [Elser AI](https://www.elser.ai/) 這樣的平台可將相同原則應用於重複的故事聖經或角色一致性上下文，但這並不意味著快取本身就能創造一致性。
## 衡量節省而非假設節省
檢查 `usage.input_tokens_details.cached_tokens` 和 `cache_write_tokens`。快取token數量高表示前綴部分被重複使用。快取寫入token則揭露了建立或更新條目的成本。
針對 GPT-6 Astra，在驗證日期所公布的模型定價中，快取輸入的價格低於一般輸入，而快取寫入的價格則高於一般輸入。這就產生了一個損益平衡的問題：重複使用的前綴可以節省成本；但只寫入一次且從未重複使用的前綴，則可能花費更多。定價會變動，因此請依據當前的模型頁面進行計算，而非將數字硬編碼到規劃試算表中。
至少追蹤：
- 各提示詞版本的快取命中率；
- 已快取、已寫入及總輸入令牌；
- p50 和 p95 首次令牌生成時間；
- 每完成一項任務的成本，而非僅按請求計費；
- 因版本發佈導致的快取未命中。
僅按模型分組的儀表板會隱藏未命中的原因。請在您自己的遙測中包含快取鍵或提示版本維度，但切勿將個人資料或機密資訊放入快取鍵中。
## 七種常見的快取未命中原因
### 動態內容出現過早
將日期、使用者 ID 和檢索到的資料移到可重複使用的內容之後。
### 工具架構變更順序
在應用程式建置步驟中，確定性地排序工具與結構描述屬性。
### 提示詞「等效」但並非完全相同
空白、範例或序列化方式可能有所不同。請從版本化的成品中生成共享區塊，而非使用臨時字串。
### 前綴太短
最小可快取長度因模型而異。極短的提示可能無法受益。請透過使用數據確認。
### 壓縮變更了前綴
壓縮有助於容納較長的對話，但會產生不同的上下文表示。預期壓縮後重複使用模式會改變，並在里程碑邊界附近進行測量。
### 過多低價值的斷點
斷點應對應有意義且可重複使用的層級。允許的四次寫入是上限，而非目標。
### 快取鍵過於寬泛或過於狹窄
每個不相關的工作流程共用一個金鑰會導致分組薄弱；每個請求使用唯一金鑰則會阻礙重用。建議使用語意化金鑰，例如 `legal-review:v3:us`。
## 安全的上線計畫
從一個高流量工作流程開始，啟用隱含模式。穩定提示詞建構，記錄 Token 細節，並比較兩週的成本與延遲。若提示詞包含多個可重複使用的層級或頻繁的動態結尾，再考慮明確的中斷點。評估品質與節省效果：過度移除上下文並非快取，且可能降低回答品質。
僅快取您已獲准傳送至API的內容。快取無法取代資料分類、租戶隔離、存取控制或保留決策。只要工具能即時擷取機密資訊，就應避免將其置於提示詞中。
## 常見問題
### 提示快取是否會降低輸出令牌的成本？
不，它適用於符合資格的重複輸入。輸出會正常生成，並按輸出費率計費。
### 使用 `previous_response_id` 會讓先前的回覆變得免費嗎？
不。OpenAI 指出，回應鏈中較早的輸入令牌仍會以輸入計費。提示快取可能減少符合資格的重複前綴成本，但對話鏈接與快取是兩種不同的機制。
### 我應該快取檢索到的搜尋結果嗎？
只有在它們穩定且真正被重複使用時。即時結果通常屬於動態尾部。對於受控語料庫，檔案搜尋可以避免在每個提示中嵌入整個集合。
### 我可以依賴快取命中嗎？
將快取視為機會性優化。您的應用程式在未命中時仍必須保持正確。
## 結論
最高價值的 GPT-6 Astra 快取策略是架構性的：穩定的指令與工具優先，易變的狀態最後，確定性序列化，審慎的版本控制，並透過 Token 細節進行衡量。從隱式快取開始，僅在資料支持時才加入顯式中斷點，並最佳化每個成功任務的成本，而非追求單一
