Prompt 快取寫入成本：1.25x 溢價何時划算？
Prompt 快取只要在 TTL 內被重新讀取一次，寫入成本就能回本：寫入按輸入費率的 1.25x 計費，讀取則是 0.1x。因此只要命中一次，兩次呼叫的總成本就會從多花 25%，變成省下 32.5%。但在我們 agent 測試套件的五種情境中，同樣的溢價卻在其中一種造成實測 6% 的損失。差異只取決於一個數字，也就是流量的讀寫比。本文說明如何在帳單出爐前量出這個數字。以下結果全部透過 Synthorai 閘道與正式計費指標實測；agent 數據來自 150 個 episode，TTL 與叢集結果則來自獨立的加鹽探測。
TL;DR
- 明確指定的快取寫入按 1.25x（5 分鐘 TTL）或 2x（1 小時）計費；GPT-5.6 的 breakpoint 也呈現相同的 1.25x/0.1x 費率結構；只要重新讀取一次即可回本。
- 在我們的 agent 測試套件中，溢價的淨影響從 +6%（RAG，讀寫比 0.2）到 -83%（批次，15.7）不等。
- 快取命中會免費刷新 Claude 的 TTL：只要流量持續，每段閒置期只需支付一次寫入費，而不是每個 TTL 週期都要付。
- 隱式快取的表現差異很大：GPT-5.5 預熱一次後，後續持續達到 7/8 命中；Gemini 即使集中呼叫，每 12 次也只命中 1 至 3 次。兩者都沒有寫入溢價。
快取寫入實際要花多少錢？
我們比較過的供應商採用三種計價結構，其中兩種會收取寫入費。Claude 的明確快取會針對快取建立收費：預設 5 分鐘 TTL 是輸入費率的 1.25x，1 小時方案則是 2x，讀取為 0.1x；GPT-5.6 改採明確 breakpoint，寫入與讀取倍率同樣是 1.25x 和 0.1x。因此目前業界規模最大的兩種明確快取實作，計價方式已經一致。第三種是隱式快取（Gemini、Kimi，以及 5.6 之前的 OpenAI 模型）：寫入完全不加價，只有供應商剛好命中時，讀取才享有折扣。
明確寫入的損益兩平計算很簡單。假設前綴有 P 個 token，未使用快取時就按正常費率支付 P。啟用快取後，第一次呼叫要付 1.25P；TTL 內每次重新讀取則只付 0.1P，而不是 P。重新讀取一次後，兩次呼叫合計為 1.35P，未使用快取則是 2P，相當於省下 32.5%；之後每次命中都能省下該前綴成本的 90%。真正的風險不是溢價，而是寫入了再也不會讀取的區塊。這個風險完全取決於工作負載的型態。
寫入溢價什麼時候反而虧錢？
當前綴變動的速度高於重複使用的速度時。我們在五種 agent 情境中量測讀取與寫入的 token 比例（模型相同，標記方式也相同），再按 1.25x/0.1x 費率計算快取的淨影響：
| 情境 | 讀寫比 | 相較於未使用快取的淨影響 |
|---|---|---|
| 批次（指令穩定，工作數量多） | 15.7 | 前綴支出 -83% |
| 長對話（歷史持續增長） | 6.8 | -75% |
| Tool loop／工具呼叫 | 5.4 | -72% |
| RAG（擷取文件位於前綴） | 0.2 | +6%：使用快取反而更貴 |
| 整套測試 | 3.5 | -64% |
最需要記住的是 RAG 這一列。每次查詢擷取到的文件不同，因此每次呼叫都會重新寫入前綴，而下一次呼叫又無法重複使用：每讀回一個 token，就寫入了五個 token，1.25x 溢價累積後造成淨損失。這不是設定錯誤，而是這種工作負載根本無法攤提寫入成本。解法是分層，而不是完全不用快取：標記系統 prompt 與工具定義（兩者可跨查詢保持穩定），擷取文件則放在最後一個 breakpoint 之後，不加標記。所有容易變動的內容都適用同樣原則，包括時間戳記、使用者名稱與每次請求專屬的 context。此外，有些設定會在不明顯的情況下讓前綴失效：若每輪之間變更 output_config.effort，prompt 會重新渲染並使快取失效。因此同一個快取 session 內應維持相同的 effort。我們的 LangChain 研究也在 framework 端發現相同問題：有些 builder 讓「全部標記」和「只標記正確內容」一樣容易。
實際上多久要重新支付一次寫入費？
每段閒置期一次，而不是每個 TTL 週期一次，因為命中會免費刷新計時。我們使用 Claude Opus 4.8 與加鹽的 4,981-token 前綴驗證了這點：
| 呼叫 | 時間 | 快取寫入 | 快取讀取 |
|---|---|---|---|
| 1 | t=0 | 4,981 | 0 |
| 2 | +3 分鐘 | 0 | 4,981 |
| 3 | +6 分鐘 | 0 | 4,981 |
| 4 | +9 分鐘 | 0 | 4,981 |
| 5 | 靜置 7 分鐘後 | 4,981 | 0 |
第 4 次呼叫早已超過原始的 5 分鐘 TTL，仍能正常讀取，因為第 2、3 次呼叫都免費延長了有效期；只有靜置 7 分鐘後才需要重新寫入。實務上，只要某條 route 的請求間隔始終短於 TTL，寫入溢價就只會支付一次，5 分鐘方案的效果等同於永久快取。1 小時方案（寫入 2x；我們已透過閘道驗證費用會計入獨立的 ephemeral_1h_input_tokens bucket）適合另一種流量：與其在每次閒置後重付 1.25x，不如一次支付 2x。只要能少一次重新寫入，1 小時方案就比較划算，因此適合閒置間隔介於 5 分鐘到 1 小時的 route。靜置超過 1 小時後，兩種方案都無法跨 run 保留快取。排程工作應依單次 run 內的行為估算：如果 cron 每次只送出一個請求，寫入快取沒有任何收益；如果一次會展開成多個共用前綴的請求，本質上就是批次工作，快取行為也完全相同。
能否靠調整流量型態改善隱式快取？
這完全取決於供應商，因為 best-effort 快取的表現差異非常大。表現較好的一端是 GPT-5.5：它的自動快取很像一套可預期的機制。預熱呼叫一次後，兩秒後就能讀取 entry（我們用兩種 salt 測試，第一次探測都命中）；後續 burst 的八次探測中，有七次從快取讀取 5,170-token prompt 裡的 4,864 個 token，而且完全沒有支付寫入溢價。這是實打實的免費折扣，只要把相同前綴傳送兩次即可。另一端則是 Gemini 3.6 Flash：在同一套 agent 測試中，明確快取供應了 Claude 77-78% 的輸入 token，但 Gemini 的隱式快取只供應了 4%，即使工作負載確實有重複前綴也一樣。
我們試著調整流量型態來改善較差的一端：將相同前綴的呼叫集中處理，讓供應商的快取維持溫熱。對 Gemini 3.6 Flash 連續發出 12 次呼叫，只有一次命中（第 10 次；第 11 次又未命中）；改成每隔 3 分鐘呼叫一次，共八次，則完全沒有命中。為了排除偶發結果，我們透過第二條獨立請求路徑，並在 Gemini 3.5 Flash 上重新執行集中呼叫。兩者各自在 12 次中命中三次和一次，而且從未連續命中太久；唯一有進入快取的區塊，在兩條路徑上讀回的數量都是 4,073 個 token。底層行為一致，命中機率卻不穩定。
未命中的部分原因是資料寫入延遲，而且每家供應商差異很大：GPT-5.5 的 entry 在預熱後兩秒即可讀取，Gemini 則要花數十秒建立。因此緊接著第一次呼叫發出的 burst，速度會快過它的快取建立（我們所有 Gemini 測試中，都沒有任何一組在第 4 次呼叫前命中）。先預熱前綴，等待 45 秒再發出 burst，命中率提升至 8 次中的 3 次，這是流量調整達到的最佳結果；但等待 90 秒後，8 次全部未命中：等我們回來時，entry 已經消失。幾天前，同一模型在更長的暖機掃描中還能維持命中，顯示命中率也會隨時間與負載變動。建立延遲、生命週期短與命中率漂移同時存在時，集中呼叫唯一能確定的改善，就是命中三次總比一次好。（測試時應以有間隔的呼叫與「預熱後等待」組探測隱式快取，並透過預熱後逐步增加等待時間，直接量出建立延遲；連續呼叫量到的是請求速率，不是快取能力。）
因此，可靠的判斷規則應以供應商為單位，而不是以機制分類：先量測供應商的隱式快取比較接近 GPT-5.5（預熱後即可信任），還是 Gemini（每次命中都當成額外折扣）。Kimi K3 介於兩者之間：沒有溢價，最低命中率不高，但不需任何設定，就有57-62% 的輸入由快取供應。還有一個數據很能說明哪一端更好：OpenAI 擁有我們量過最好的隱式快取，卻仍在 GPT-5.6 改採明確 breakpoint，把無法由客戶掌控的隨機折扣，換成可由客戶控制的標記。
哪些工作負載能攤提溢價？
依讀寫比與閒置間隔做決策。這兩項都能在正式採用前，直接從自己的使用紀錄取得：
| 工作負載 | 建議 | 原因 |
|---|---|---|
| 多輪 agent session | 使用快取 | 每輪都會重新讀取歷史；整套測試的整體讀寫比實測為 3.3-3.6 |
| 共用系統 prompt、QPS 穩定 | 使用快取，5 分鐘方案 | 請求間隔 < TTL，代表只需寫入一次，之後命中都會免費刷新 |
| 間歇流量，閒置 5-60 分鐘 | 使用快取，1 小時方案 | 支付一次 2x，優於每段閒置後支付 1.25x |
| 批次工作、指令相同 | 使用快取，並集中執行工作 | 實測讀寫比 15.7、成本 -83%；集中處理可讓有效期維持溫熱 |
| 文件容易變動的 RAG | 分層處理 | 只標記指令／工具；文件放在最後一個 breakpoint 之後 |
| 排程 cron，每個 run 只有一個請求 | 略過 | 每個 run 間隔數小時；每次寫入都會在讀取前過期 |
| 排程 cron，每個 run 有多個請求 | 在 run 內使用快取 | 一個 run 就是一個批次：第一個請求寫入，其餘請求讀取；命中會讓 TTL 在整個 run 期間保持有效 |
| 低於門檻的 prompt | 略過 | 低於各模型的快取最低門檻時，無論如何都不會進入快取 |
最後是計費指標告訴我們的兩條規則。第一，應根據使用明細中的 cache_read 與 cache_creation 判斷快取成效，而不是憑命中感覺是否頻繁；RAG 情境看似適合快取，實測讀寫比卻只有 0.2。第二，只要讀寫比健康，溢價幾乎可以忽略：以整套測試的讀寫比 3.5 為例，即使納入所有已支付的寫入費，前綴支出仍降低 64%。
常見問題
RAG 值得使用 prompt 快取嗎？
擷取文件不值得。在我們的實測中，RAG 每讀回一個 token 就寫入五個 token，使 1.25x 溢價最後造成 6% 的淨損失。應快取穩定的層級，也就是系統 prompt 與工具定義，並把擷取內容放在最後一個 breakpoint 之後；完整快取指南詳細說明了 prompt 分層方式。
應該使用 5 分鐘還是 1 小時的快取 TTL？
看閒置間隔，不是 session 長度。每次命中都會免費刷新 5 分鐘 TTL，因此只要請求間隔短於 5 分鐘，就不必重新寫入，較便宜的方案也能持續有效。只有在閒置間隔介於 5 分鐘到 1 小時時，才值得支付 1 小時方案的 2x 寫入費；只要能避免一次 1.25x 的重新寫入，就能回本。若間隔超過 1 小時，估算成本時應視為完全沒有快取。
隱式快取會收取寫入費嗎？
不會，而且從計價結構來看也無法收取：只有呼叫端主動選用時，寫入溢價才合理。因此溢價只存在於明確快取（Anthropic 的 1.25x/2x 倍率、GPT-5.6 的 breakpoint，以及 Gemini 這類明確 cached-content API 按 token-hour 收取儲存租金的模式）。我們量過的所有隱式實作（Gemini、Kimi、5.6 之前的 OpenAI），以及所有主要公開價目表（DeepSeek、Qwen、Grok），都只將隱式快取列為折扣讀取。差異在於可靠性：GPT-5.5 的隱式快取在八次預熱探測中持續命中七次；Gemini 在我們的 agent 測試中只供應 4% 的輸入，集中呼叫也幾乎沒有改善。能穩定取得且零溢價的折扣最划算；如果折扣隨機出現，價值還不如支付少量溢價，換取自己能控制的快取。
實測期間為 2026-07-25 至 2026-07-29，透過 Synthorai 閘道執行：各情境讀寫比來自 Claude 組的 150 個 agent episode，並逐次呼叫拆分快取明細（Gemini 與 Kimi 占比來自各自的測試套件執行結果）；TTL 刷新與 1 小時 bucket 探測使用 claude-opus-4-8（加鹽的 4,981-token 與 3,742-token 前綴）；隱式快取探測使用 gemini-3.6-flash 與 gemini-3.5-flash（加鹽的約 6,800-token 前綴；包含集中、分散與預熱後等待組），以及 gpt-5.5（加鹽的 5,170-token prompt，預熱後 burst）。淨影響百分比依實測比率，按 1.25x 寫入／0.1x 讀取倍率計算。費率與快取行為可能變動；請以自己的使用紀錄驗證。