LLM 提示詞快取 #4：聊天、RAG 與代理的最佳模型

TL;DR —— 挑選「最佳」LLM 不是單一的基準測試問題，它取決於你要交付的是聊天機器人、RAG/批次 API，還是 AI 代理。每種型態都有不同的提示詞結構、命中率特徵、TTL 適配性與延遲容忍度，這就決定了模型 + 快取策略需要不同的最佳組合。本指南建立在 第 3 部分 中實測的數據之上——同一個閘道、同一個 OpenAI SDK，每次呼叫只切換 model 欄位。

系列：第 4 部分（共 4 部分）· 先前：第 1 部分 —— 快取原理 · 第 2 部分 —— 服務商比較與評測 · 第 3 部分 —— 實戰程式碼教學

0. 通用成本公式

在深入各個使用情境之前，先看看每個選擇都應當最佳化的等式：

per-call cost = (input_uncached × P_in)
              + (input_cached   × P_in × cache_discount)
              + (output × P_out)

per-call TTFT ≈ prefill_time × (1 - hit_rate)
              + decode_time

四個槓桿：

1. 降低單價（P_in / P_out）→ 選更便宜的模型。
2. 提高命中率→ 重構你的提示詞；讓 TTL 對應你的流量節奏。
3. 降低快取折扣係數→ 選快取能力更強的服務商。
4. 選快取預填充最快的服務商→ 延遲對使用體驗很重要。

下面每個使用情境都以不同方式拉動這些槓桿。

使用情境 1：聊天機器人、客戶支援與助理

流量特徵

• 每個請求 = 長系統提示詞（人設 + 知識 + 規則）+ 多輪歷史 + 新的使用者訊息。
• 平均脈絡：4K–20K 權杖。
• 使用者對首個權杖時間極其敏感（>2 秒就感覺卡了）。
• 在一個工作階段內，請求間隔為秒到分鐘級——遠在任何服務商的快取 TTL 之內。

為什麼聊天幾乎能自動快取

聊天是最適合快取的工作負載。在單個工作階段內：

Request 1: [system: 8K] + [history: 0]   + [user: Q1]
Request 2: [system: 8K] + [history: 200] + [user: Q2]
Request 3: [system: 8K] + [history: 400] + [user: Q3]
           ↑──────── prefix is monotonically growing ────────↑

如果訊息間隔保持在 TTL 以內（各服務商都有幾分鐘），系統提示詞部分無需任何努力就能達到 90%+ 的命中率。你不需要保活機制。

模型推薦（實測於 2026-05）

* 針對一個 7,300 權杖的穩定系統提示詞測得，單次循序執行，無並行負載。完整表格見 第 3 部分 §6。

最小生產程式碼

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["SYNTHORAI_KEY"],
    base_url="https://synthorai.io/v1",
)

def chat(history: list, user_msg: str):
    return client.chat.completions.create(
        model="gpt-5.4-mini",
        max_tokens=512,
        messages=[
            {"role": "system", "content": STABLE_SYSTEM_PROMPT},   # front
            *history,                                              # middle
            {"role": "user", "content": user_msg},                 # back
        ],
    )

就這樣。上面列出的每個模型都會自動快取；無需任何標記。開發期間讀取 resp.usage.prompt_tokens_details.cached_tokens 來確認命中。

聊天機器人的陷阱

• ❌ 不要把目前的時間戳記寫進系統提示詞（"Today is 2026-05-25 14:30:25"）。秒級精度會讓每次快取失效。
• ❌ 不要每輪都重新拼接歷史——保持訊息陣列順序逐位元組一致，且只做附加。
• ✅ 把使用者人設資料放在第一則使用者訊息裡，而不是系統提示詞裡——這樣每個使用者的差異就不會污染共用前綴。
• ✅ 對於超過 TTL 變冷的工作階段，在使用者下一則訊息到達前傳送一個 1-權杖的保活探測（見 第 3 部分 §8.2）。

使用情境 2：API 工作負載（RAG、內容生成、批次處理）

流量特徵

• RAG 問答：輸入 = 穩定系統提示詞 + 可變檢索文件 + 可變查詢。
• 內容生成（行銷文案、程式碼、翻譯）：穩定範本，資料變化。
• 批次處理（文件分類、資料清理）：大批量的同一任務。
• 延遲是次要的；每次呼叫的成本占主導。

難題：檢索會打亂你的前綴

RAG 的核心快取問題：檢索到的文件在每次呼叫間變化，從提示詞中段開始破壞前綴。

Request 1: [system: 3K] + [doc_A, doc_B, doc_C] + [user: Q1]
Request 2: [system: 3K] + [doc_B, doc_D, doc_A] + [user: Q2]
           ↑─ hits ─────↑  ↑──── miss ─────────↑

三種解法，複雜度遞增：

解法 A —— 把檢索文件放到後面，而不是前面。

messages = [
    {"role": "system", "content": SYSTEM_PROMPT},          # ~3K, stable
    {"role": "system", "content": INSTRUCTION_TEMPLATE},   # ~500, stable
    {"role": "user",   "content": f"References:\n{retrieved_docs}\n\nQuestion: {q}"},
]

結果：整個 system 部分（穩定的約 3.5K 權杖）都能快取。每次呼叫只有面向使用者的部分未命中。這對大多數生產級 RAG 已經足夠。用 gpt-5.4-mini 在該模式下實測的命中率：系統權杖達 80%+。

解法 B —— 確定性的檢索排序。 按穩定鍵（doc_id 遞增）而非相關性分數對檢索區塊排序。高頻區塊保持在一致的位置，前綴更常相符。會讓排序器損失一點準確率；通常無關緊要。

解法 C —— 透過廠商原生 SDK 使用原生顯式快取標記。 如果你直接用 Anthropic Claude（而非透過本閘道），多個 cache_control 的模式可以把「永不變化」+「很少變化」+「依任務變化」分別快取為不同的中斷點。在你能多帶一個 SDK 時，這對複雜 RAG 極佳。

API 工作負載的 TTL 考量

• 持續流量（7×24 的 RAG 端點）：5 分鐘 TTL 完全夠用——視窗內總有下一個請求。
• 突發 / 排程任務（每天 09:00 的批次處理）：使用長 TTL 服務商（deepseek-v4-flash 是我們測試集中存活最久的），或在執行視窗內每隔 TTL/2 傳送一個 1-權杖保活。模式見 第 3 部分 §8.2。

依任務的模型推薦

† Claude 的多 cache_control 標記對分層 RAG 無可匹敵——使用指向閘道的 anthropic SDK，見 第 3 部分 §2。

RAG 成本估算（10 萬次查詢/天）

3K 系統提示詞 + 5K 檢索文件 + 200-權杖查詢 + 300-權杖輸出。數字由 第 3 部分 §6 中實測的單次呼叫成本按比例換算——單租戶，無並行負載。

僅作數量級參考。真實生產環境有並行呼叫、突發流量，且你的檢索文件長度分佈會主導這筆帳。

RAG / API 的陷阱

• ❌ 不要按動態相關性分數對檢索區塊排序——每個請求都會得到一個獨一無二的前綴。
• ❌ 串流時不要丟棄用量記錄——你的成本歸因會崩潰。傳入 stream_options={"include_usage": True} 並儲存 prompt_tokens_details.cached_tokens 與 usage.cost。
• ✅ 對於批次任務，在快取之上疊加廠商的批次 API（OpenAI Batch、Anthropic Message Batches），可再省約 50%——這是在本閘道之外、直接呼叫服務商完成的。

使用情境 3：AI 代理（多步推理、工具呼叫、長鏈路）

流量特徵

• 一個代理任務 = 多次 LLM 呼叫，與工具結果交錯。
• 超長脈絡（系統 + 工具 + 累積歷史）：到第 10 步通常達 30K–100K 權杖。
• 高度結構化的提示詞：長而穩定的前綴，小而可變的尾部。
• 延遲與成本都重要——每多一秒預填充都會帶來可見的等待，而一個 15 步的代理會把它放大 15 倍。

為什麼代理依賴快取

每一步都在上一步的工具呼叫和結果上附加。沒有快取，每一步都要為數萬權杖重新支付預填充。

Step 1: [system: 5K] + [tools: 3K]
Step 2: [system: 5K] + [tools: 3K] + [call_1: 1K] + [result_1: 2K]
Step 3: [system: 5K] + [tools: 3K] + [call_1: 1K] + [result_1: 2K]
                                   + [call_2: 1K] + [result_2: 5K]
        ↑──── prefix grows monotonically — perfect for caching ────↑

關鍵規則：跨步驟的工具呼叫和結果必須是僅附加且逐位元組一致的。任何重寫或重排都會從該點起破壞快取。最常見的代理 bug 就是「我在重新傳送前清理了工具結果」→ 快取率降到零 → 成本和延遲成倍增加。

TTL 對應 —— 唯一真正重要的使用情境

一個典型的代理任務執行 10–60 秒；在單個任務內，預設 5 分鐘 TTL 沒問題。但等待人工核准的代理（「審查這個計畫並回覆」）可能閒置數分鐘。如果人停頓了 10 分鐘、快取已變冷，你的後續步驟就要為 50K 權杖重新支付預填充。對於這類工作流，要麼：

• 使用更長 TTL 的服務商（deepseek-v4-flash 是我們測試集中存活最久的），或
• 在等待時每隔 TTL/2 傳送一個保活探測（見 第 3 部分 §8.2）。

代理模型推薦

代理要求推理能力——先按品質選，再最佳化成本。

† Claude 的 4 個 cache_control 標記模式仍是代理快取的最強配置（跨 10+ 步的累積前綴折扣）。使用指向閘道的 anthropic SDK——確切的請求主體型態和 TTL 選項見 第 3 部分 §2。

真實成本估算：一個 15 步的代理任務

假設 5K 系統提示詞 + 3K 工具 + 每步附加約 3K，共 15 步。單次呼叫成本取自 第 3 部分 §6，按代理型態縮放：

同樣是估算數字。主導變數是你是否真的逐步保持前綴逐位元組一致。

代理的陷阱

• ❌ 不要每步都重建訊息清單——保持陣列逐位元組一致，只做附加。
• ❌ 不要裁剪或重新格式化工具結果——任何位元組變化都會讓下游快取失效。
• ❌ 不要在並行的代理執行實體間共用快取鍵——它們的步驟順序會發散並相互污染。
• ✅ 監控每個任務的 cache_creation_tokens : cache_read_tokens——到第 10 步，健康的比例是 1:50 或更好。

主決策矩陣

                            ┌─ Chinese-heavy ─→ deepseek-v4-flash + auto cache
                  ┌─ High ─→│
                  │          └─ Global users ──→ gpt-5.4-nano / claude-haiku-4-5
   Chatbot ──────→│
                  │          ┌─ Quality-first ─→ gpt-5.4-mini / claude-sonnet-4-5
                  └─ Mid ──→│
                            └─ Balanced ──────→ gemini-2.5-flash / qwen3-max

                            ┌─ Chinese RAG ───→ deepseek-v4-flash / qwen3-max
                  ┌─ Live ─→│
                  │          └─ English RAG ───→ gpt-5.4-mini / claude-sonnet-4-5†
   API ──────────→│
                  │          ┌─ Translation ───→ gpt-5.4-nano (template caches)
                  └─ Batch →│
                            └─ Doc review ────→ qwen3.5-flash + Batch APIs

                            ┌─ Simple ────────→ deepseek-v4-flash / qwen3-max
                  ┌─ China ─→│
                  │          └─ Complex ───────→ qwen3-max (plan) + deepseek (execute)
   Agent ────────→│
                  │          ┌─ Simple ────────→ gpt-5.4-mini + auto
                  └─ Global →│
                            └─ Complex ───────→ claude-sonnet-4-5† / gpt-5.5-pro

  † Claude with multi-`cache_control` breakpoints via the `anthropic` SDK pointed at the gateway (see Part 3 §2)

依使用情境的 TTL 速查

本閘道做什麼、不做什麼

為誠實地設定預期：

如果你今天就需要右側的任何一項，請在你的應用層或直接對接廠商 SDK 來實作。本閘道是一個輕量代理加一層定價；所有與快取相關的事都發生在上游的模型層。

最終要點

四部分的系列濃縮為四句話：

快取是兩個勝利，而非一個。 成本與延遲都贏。 穩定內容在前，易變內容在後。 前綴紀律是免費的，處處都該做。 讓模型 + 快取行為對應使用情境。 聊天 ≠ RAG ≠ 代理。 在你自己的流量上測量。 單次基準只是起點，不是答案。

從這裡出發最快的路徑：從上面的矩陣裡挑出最接近你的使用情境，套用結構性改動（穩定內容在前的前綴、確定性檢索、逐位元組一致的代理狀態），把 cached_tokens 和 usage.cost 記錄一週，然後重新評估。

常見問題

中文聊天機器人哪個 LLM 最便宜？ 在我們的測試集中，deepseek-v4-flash 和 qwen3.5-flash 在中文文字上比英文調校的模型便宜一個數量級，同時在典型聊天工作負載上品質與 gpt-5.4-mini 相當。

2026 年 RAG 的最佳 LLM 是什麼？ 英文：用 gpt-5.4-mini 搭配解法 A 的提示詞配置（系統權杖在前，參考資料在底部），在穩定部分能達到 80%+ 命中率。中文：deepseek-v4-flash。對於經常被查詢的超長文件：gemini-2.5-pro（原生處理 1M+ 權杖脈絡）。

代理應該用 GPT 還是 Claude？ 兩者都很強；選擇取決於你願意投入多少快取紀律。Claude 的 4 個 cache_control 標記模式（透過指向閘道的 anthropic SDK）對累積型代理前綴格外強大——前綴溫熱後，跨 10+ 步可減少約 90% 的輸入成本。如果你更願意留在 OpenAI 型態的用戶端、接受無標記下約 50% 的快取節省，那麼 gpt-5.4-mini 或 gpt-5.5-pro 是摩擦更低的選擇。

從「樸素」切換到「最佳化」的 LLM 用法，現實中我能省多少？ 在本系列的實測執行中：同一模型可獲得 50–88% 的成本降低和 30–60% 的 TTFT 降低。大部分收益來自把命中率提到 80% 以上，而非換一個不同的模型。

我該從哪裡開始？ 從矩陣裡挑出最接近你的使用情境。套用結構性的提示詞改動。在一週的生產流量上測量 cached_tokens 和 usage.cost。只有到那時再考慮換模型。

來源與驗證：實測數字來自 第 3 部分 §6，https://synthorai.io/v1，時間 2026-05-25，openai SDK 2.38.0。廠商定價頁面：OpenAI · Anthropic · Google Gemini · DeepSeek · 阿里雲百鍊。

← 返回部落格