A
成本 / COST
以更低成本讀取相同輸入。
代表性範例：快取命中輸入單價為一般輸入的 10%
FIELD GUIDE · 2026.08
REQUEST / 0042LIVE
01工具定義固定
02系統指示固定
03參考文件固定
CACHE BOUNDARY
04本次問題變更
05最新結果變更
開頭維持不變，只在後方加入新資訊。
快取讀取單價代表性範例 90%↓*
研究中的 TTFT 最大改善31%↓†
核心原則前綴固定，尾端變動
* GPT-5.6、Claude 與 Gemini 官方價格的代表性範例 · † 500 個代理程式工作階段 arXiv 研究的最大值；部分策略沒有改善，甚至更慢
01
原理 / THE MECHANISM
AI 不是記住答案，
而是重複使用相同前綴的計算結果。
提示詞與上下文快取並不是記住答案本身。在模型回答前的預填階段，供應商會重複使用相符前綴的計算結果。快取有效時，只需要讀取新加入的尾端內容。
01預填
讀取完整輸入並建立內部計算結果。
02重複使用快取
略過相同前綴的重複計算。
03解碼
逐一產生回答 token。
重點
快取主要減少輸入預填。輸出 token 成本與生成速度是另外兩回事。
INTERACTIVE LAB 01
親自試著讓快取失效。
變更位置不同，可重複使用的區段也不同。
SIMULATION良好流程: 3/5
01工具定義HIT
02系統指示HIT
03參考文件HIT
04本次問題NEW
05最新結果NEW
前面的 3 個區塊會原樣重複使用。
在典型的前綴快取中，變更位置之後可重複使用的範圍會縮小。
02
效果 / WHY IT MATTERS
成本、速度、吞吐量。一次快取命中會同時改變這三項。
快取條件與效益因供應商及模型而異。下方的 90% 是代表性的輸入價格條件，並不表示整個請求的成本降幅。
90%↓
B
速度 / SPEED
略過冗長預填，更快取得第一個 token。
效果會因前綴長度與基礎架構而異
C
吞吐量 / THROUGHPUT
用相同預算與時間完成更多工作。
Claude API 在多數模型中不將快取讀取 token 計入 ITPM
INTERACTIVE LAB 02
只看命中率，只看見一半。
此簡化模型將快取讀取單價設為一般輸入的 10%。不包含寫入、儲存（TTL）與輸出成本。
RESULT / PER TURN
56K
以全價 token 換算的每輪有效輸入負擔
輸入成本指數28 / 100
約略節省率72%
98% HIT900K × 0.118 = 106.2K
VS
70% HIT50K × 0.37 = 18.5K
即使命中率更高，如果上下文過大，有效負擔仍約重 5.7 倍。
CASE
我們的 Orca 使用紀錄
ORCA HQ · 2026.07.20—07.27 · LOCAL USAGE LOG
我們從自己的使用紀錄中找到了讓快取生效的模式。
我們分析了 Orca 在本機彙整、可直接確認路徑的 207 個 HQ 工作階段。下方 token 數是供應商回應中 usage 欄位的總和；因為沒有帳單紀錄，所以未估算成本。
- 觀測期間紀錄實測
- 8 天 7 月 20–27 日
- Orca 工作階段紀錄實測
- 207 直接確認 HQ 路徑
- 已記錄回應紀錄實測
- 12,554 含 usage 資料
- 使用模型紀錄實測
- 8 Claude、GLM、DeepSeek
WHAT THE LOG SHOWS
快取讀取占全部輸入相關 token 的比例
總計 22.01 億 token 中，21.61 億為 cache read、3,882 萬為 cache write、79.9 萬為新輸入。
紀錄實測cache read ÷ (read + write + fresh input)
快取讀取紀錄實測
21.61億98.20%快取寫入紀錄實測
3,882萬1.76%新輸入紀錄實測
79.9萬0.04%每輪平均17.2 萬 cache-read tokens
重複使用率高，但絕對上下文仍然很大
THREE REAL RUNS
約一小時的集中執行中，數百個回應都記錄到快取讀取。
三次都是使用 Claude Opus 5 的 Orca 基準測試，紀錄總和經過四捨五入。
01 · 營運文件檢視OPSREV3
615輪
- 執行時間
- 57 分鐘
- 快取讀取
- 1.371億
- 快取寫入
- 29.8萬
- 讀取比例
- 99.78%
觀測：讀取量約為寫入量的 460 倍。
02 · 情境檢視SCENAREV
486輪
- 執行時間
- 49 分鐘
- 快取讀取
- 1.102億
- 快取寫入
- 29.2萬
- 讀取比例
- 99.73%
觀測：大多數輸入相關 token 都被重複使用。
03 · 長篇摘要檢視LONGSUM4
425輪
- 執行時間
- 48 分鐘
- 快取讀取
- 1.005億
- 快取寫入
- 26.4萬
- 讀取比例
- 99.74%
觀測：長篇工作也呈現很高的重複使用比例。
我們確認的重點
三次執行都在短時間內，於同一個工作階段連續處理目標相同的工作。
注意：這是高度相關的模式，並未直接分類每次快取寫入的原因。03
實作 / THE PLAYBOOK
固定開頭，只變動尾端。
快取最佳化關乎你如何開始、延續與整理工作階段。
開始前先決定要固定的內容。
- 整理長期規則與參考資料
- 確定模型、MCP 與工具設定
- 每個討論串只處理一項工作
進行中只加入變更內容。
- 將本次問題與最新結果放在後方
- 將大型圖片與紀錄移到外部檔案
- 盡可能連續執行相同工作
上下文變重時果斷整理。
- 壓縮同一項工作的上下文
- 工作改變時建立新討論串
- 同時檢查命中率與絕對 token 數
一般聊天機器人 / PRESCRIPTION
每個主題使用一個討論串，資料只提供一次
- 01
一開始一次整理專案說明與資料。
- 02
同一項工作在同一個討論串繼續。
- 03
長文件只說明變更內容。
CACHE & CONTEXT HABITS
這些習慣會傷害重複使用效果與上下文效率。
- ×在系統指示中放入動態值
- ×頻繁變更工具清單或順序
- ×反覆修改並重新貼上同一份文件
- ×不斷堆疊圖片與原始紀錄
- ×在同一個討論串混合不同工作
WHAT TO MEASURE
同時關注比例與絕對量。
01快取讀取 / 寫入
是否真的發生命中？
02每輪總輸入
工作階段是否過重？
03每項工作成本
取得一個結果要花多少？
04TTFT
第一個 token 是否更快到達？
你自己的工作負載基準與趨勢，比通用的理想命中率更重要。
04
GPT 觀點 / A MODEL'S TAKE
快取最佳化不是提示詞技巧，而是資訊架構設計。
命中率是有用指標，但 100% 不是目標。穩定地重複使用不變的事實，只重新讀取當下需要的新資訊。
OPTIMIZE IN THIS ORDER
- 01移除不必要的上下文
- 02固定穩定資訊
- 03按工作拆分討論串
- 04測量命中率
如果快取與時效性或正確性衝突，應優先選擇正確性。
05
工作階段前 30 秒檢查
YOUR NEXT SESSION
開始前，只要確認六件事。
0 / 6
每完成一項檢查，工作階段就更輕量。
ONE LINE TO REMEMBER
良好的快取使用方式 =
前綴穩定性 × 上下文規模管理 × 工作節奏
這些數值與公式如何計算？
約略節省率 = 命中率 ×（1 − 快取讀取單價 / 一般輸入單價）。讀取單價為 10%、命中率為 80% 時，輸入成本約降低 72%。
快取在所有 AI 中都以相同方式運作嗎？
不一樣。TTL、最小長度、折扣率與 usage 欄位會因供應商及模型而異。
一直使用同一個聊天就一定會命中嗎？
無法保證。結果受供應商政策、TTL 與內部上下文管理影響。
事實查核使用的一手來源
我們對照查核了截至 2026 年 8 月 13 日的官方文件與原始研究，並重新彙整本機 Orca usage 紀錄。