GPT-6 Astra 提示詞快取：請求為何未命中快取

初步排查提示詞快取未命中

不要因為後面某次呼叫看起來更快，就把問題標為“已修復”。網路狀況、排隊、輸出長度和工具執行同樣會影響總耗時。

修改提示詞前先讀用量記錄

儲存一份安全的診斷記錄，標明請求模板、模型、工具集版本和對話歷史版本。不要把金鑰或私密使用者內容寫入沒有訪問限制的日誌。雜湊或受控比較可以識別變化，而不必暴露每一個值。

同時檢查 usage.input_tokens_details.cached_tokens、cache_write_tokens 和總 input_tokens。已快取 token 表示複用的輸入；快取寫入 token 則對應另一項計費組成。第一次請求的快取 token 為零，本身不代表缺陷：在判斷未命中之前，應與後續符合複用條件的請求比較。絕不要只憑響應很快就推斷快取已複用。

然後比較某個已知請求與緊接著那個預期能夠受益的請求，找出第一處意外差異。不要一開始就把所有指令重新排列，因為那隻會建立一個新實驗，卻無法解釋原先為何失敗。

常見的應用層排查物件包括靠近開頭且不斷變化的時間戳、每次以不同順序組裝的工具列表、被重寫的摘要，以及修改過的指令塊。這些只是需要檢查的專案，不代表它們都曾在你的賬戶中造成快取未命中。

相同的問題不等於相同的字首

官方提示詞快取指南說明，該機制會為匹配的提示詞字首複用中間鍵值狀態。它不是答案快取：後續請求仍有新輸入需要處理，也仍需要生成響應。

這解釋了為什麼兩個不同問題可能從共同的開頭受益，而兩個幾乎一樣的問題卻可能無法複用你預期的部分。變化內容之前放了什麼，才是關鍵。

診斷時，可以把請求視為由應用組裝、有版本記錄的文件。指令、工具和歷史記錄都屬於這份文件。只看最後一條使用者訊息，會遺漏大量相關證據。

開展受控的字首實驗

受控調查應從一個基準請求和一個範圍明確的變體開始。保持任務、輸出要求和工具可用性穩定。在解釋用量之前，先記錄預期字首是否相同。

接著測試一個可能引起變化的因素。如果穩定部分中的某個動態欄位並非必需，應先確認移動它不會改變任務含義，再進行調整。不要僅為了改善快取指標就移除相關上下文。

使用足夠的案例重複檢查，區分可復現的規律與孤立的觀察。在實際執行實驗之前，應將更改描述為擬議的修復。

這種方法也便於回滾。如果輸出質量下降，你可以定位到具體的請求佈局改動，而不用理清多項同時實施的最佳化。

使用包含三次請求的記錄表：A 建立基準，B 用新條目重複相同的穩定內容，C 只修改一個可疑欄位。分別記錄請求版本、時間間隔、快取 token 數和輸出驗收情況。這是實驗設計，不是 API 輸出示例；下表沒有編造命中率。

假設某個團隊依據固定的風格指南和 schema 評估擬議的道具描述。指南和 schema 保持穩定，而每個道具的資料會變化。這是適合研究上下文複用的場景。

再假設應用每次呼叫都會在指南前插入新的執行標識。團隊應在歸因於模型之前，先檢查最終請求如何組裝。同時還應確認，任何重組都讓道具資料與指令保持明確分離。

為了編寫道具描述簡報，可以瀏覽 RPG 遊戲，記錄自己的觀察，看看物品欄標籤如何表達用途和約束。這些筆記可以幫助制定風格指南；不要複製遊戲文案，也不要把連結中的遊戲說成 Astra 快取的應用示例。

推理設定的變化需要單獨檢查

推理文件說明了 GPT-6 Astra 的一種配置更新機制，可在響應之間改變推理投入，同時保留原始提示詞字首。其支援條件包括標準單代理模式。

不要假定在請求的任意位置重寫配置都會產生相同效果。應遵循所用整合對應的文件機制，並檢查實際行為。

當對話在複雜分析與常規追加工作之間切換時，這一點尤其重要。目標不是永遠凍結所有設定，而是有意識地調整，同時避免意外重建無關上下文。

區分快取節省與任務總成本

GPT-6 Astra 模型頁面分別列出輸入、快取輸入和輸出的價格。實施時必須核對當時的價格；本文有意不承諾固定比例的費用降低。

有用的評估應著眼於最終合格的任務結果，而不只是某個打折的組成部分。如果某項最佳化導致輸出變長、重試增加或響應格式損壞，那麼即便部分輸入得到複用，最終工作流也可能更差。

應並列報告快取行為和任務質量。至少同時儲存驗收結果、總耗時和報告用量。只顯示命中率上升的儀表板，可能掩蓋使用者體驗的下降。

風格指南評估也需要面向玩家的質量檢查：透過驗收的標籤是否幫助使用者理解操作？可以瀏覽 Elseland AI 上的瀏覽器遊戲作為互動參考，再編寫自己的測試案例。該遊戲集是遊玩的地方，不是快取效能或所用模型來源的證據。

先保證正確性，再最佳化複用

有利於快取的請求，不一定就是好的請求。如果工具定義因應用變化而需要更新，應保證其準確性；如果使用者修正了要求，應保留這項修正。複用過時上下文並不是有價值的最佳化。

調整請求佈局前，應設定驗收門檻：必需欄位必須保留，輸出必須符合當前任務，過時指令不得覆蓋最新要求。

只有當觀察到的效率提升經得起驗收檢查時，才保留請求佈局改動。如果快取指標改善了，但輸出仍在遵循過時指令，就應回滾。目標是在減少重複輸入處理的同時得到正確結果，而不是不惜代價追求高命中率。