依使用情境選擇最佳 LLM（2026）：聊天、RAG 與 Agent 成本矩陣

TL;DR — 「最佳」LLM 不是看單一 benchmark 就能決定，而是取決於你要做的是聊天機器人、RAG／批次 API，還是 AI Agent。這幾類工作負載的 prompt 結構、命中率特性、TTL 適配度與延遲容忍度都不同，因此各自適合不同的模型與快取策略。本文延續第 3 篇的實測數據：使用相同閘道與 OpenAI SDK，每次呼叫只要替換 model 欄位。

系列文章：第 4 篇，共 5 篇 · 前文：第 1 篇：快取原理 · 第 2 篇：供應商比較與評估 · 第 3 篇：可直接執行的程式碼教學 · 下一篇：第 5 篇：整合 LangChain

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. 提高命中率 → 重整 prompt，讓 TTL 配合流量節奏。
3. 降低快取折扣係數 → 選擇快取優惠幅度更大的供應商。
4. 選擇快取 prefill 最快的供應商 → 延遲會直接影響使用者體驗。

以下每種使用情境，調整這些槓桿的方式都不同。

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

流量特性

• 每個請求 = 很長的 system prompt（角色設定 + 知識 + 規則）+ 多輪對話紀錄 + 新的使用者訊息。
• 平均 context：4K–20K tokens。
• 使用者對 time-to-first-token 非常敏感（超過 2 秒就會覺得系統出問題）。
• 同一個 session 內，請求間隔通常只有幾秒到幾分鐘，遠短於任何供應商的快取 TTL。

為什麼聊天幾乎會自然命中快取

聊天是最適合快取的工作負載。同一個 session 內：

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（各家供應商通常都是幾分鐘），system prompt 部分不需額外處理就能達到 90% 以上的命中率，也不必傳送 keep-alive。

模型建議（2026-05 實測）

* 使用 7,300-token 的固定 system prompt，在無併發負載下進行單次循序測試。完整表格請參閱第 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，確認是否命中。

聊天機器人的常見問題

• ❌ 不要把目前時間寫進 system prompt（"Today is 2026-05-25 14:30:25"）。精確到秒的時間會讓每次快取都失效。
• ❌ 不要每輪重新拼接對話紀錄。message array 的順序必須逐 byte 相同，而且只能附加。
• ✅ 使用者的 persona 資料應放在第一則 user message，而不是 system prompt。這樣不同使用者的內容就不會破壞共用 prefix。
• ✅ session 閒置超過 TTL 後，可在使用者下一則訊息抵達前傳送只產生 1 個 token 的 keep-alive ping（請參閱第 3 篇 §8.2）。

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

流量特性

• RAG 問答：輸入 = 固定 system + 每次不同的檢索文件 + 每次不同的查詢。
• 內容生成（行銷文案、程式碼、翻譯）：固定範本搭配不同資料。
• 批次處理（文件分類、資料清理）：大量執行相同任務。
• 延遲的重要性較低，每次呼叫成本才是主要考量。

最棘手的問題：檢索結果會打亂 prefix

RAG 的核心快取問題是：每次呼叫取得的文件都不同，導致 prompt 中段的 prefix 失效。

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 個固定 token）都能進入快取，只有每次呼叫都不同的 user 部分不會命中。多數正式環境的 RAG 做到這一步就夠了。使用 gpt-5.4-mini 實測時，system tokens 的命中率超過 80%。

解法 B：採用確定性的檢索結果排序。 不要依照相關性分數排序，而是使用固定 key（例如 doc_id 遞增）排列檢索片段。高頻片段的位置會保持一致，prefix 也更容易相符。這會讓 ranker 的準確度略微下降，但通常不影響實際結果。

解法 C：透過供應商原生 SDK 使用明確的快取標記。 如果直接使用 Anthropic Claude，而不是透過此閘道，multi-cache_control 模式可把「永不變動」、「偶爾變動」與「每個任務都不同」的內容設為不同 breakpoint。需要多維護一套 SDK，但很適合複雜的 RAG。

API 工作負載的 TTL 考量

• 持續流量（全年無休的 RAG endpoint）：5 分鐘 TTL 就夠了，因為下一個請求通常會在期限內到達。
• 突發／cron 流量（每天 09:00 執行的批次工作）：使用長 TTL 的供應商（實測中 deepseek-v4-flash 的存活時間最長），或在執行期間每隔 TTL/2 傳送一次只產生 1 個 token 的 keep-alive。實作方式請參閱第 3 篇 §8.2。

依任務選擇模型

† Claude 的 multi-cache_control 標記最適合分層式 RAG。請使用指向閘道的 anthropic SDK，詳見第 3 篇 §2。

RAG 成本概算（每日 100K 次查詢）

3K system + 5K 檢索文件 + 200-token 查詢 + 300-token 輸出。以下數字依第 3 篇 §6的單次呼叫實測成本換算，測試條件為單一租戶且無併發負載。你可以使用 LLM 成本計算器估算自己的帳單，並透過即時模型價格比較確認目前費率。

這些數字只代表數量級。正式環境有併發呼叫與突發流量，而檢索文件長度的分布會是成本計算的主要變數。

RAG／API 常見問題

• ❌ 不要依照動態相關性分數排列檢索片段，否則每個請求都會產生不同的 prefix。
• ❌ 使用串流時，不要漏掉 usage log，否則無法正確歸屬成本。請傳入 stream_options={"include_usage": True}，並儲存 prompt_tokens_details.cached_tokens 與 usage.cost。
• ✅ 批次任務可在快取之外，再搭配供應商的 Batch API（OpenAI Batch、Anthropic Message Batches），成本還能再降低約 50%。這必須繞過此閘道，直接呼叫供應商。

使用情境 3：AI Agent（多步驟推理、工具使用、長流程）

流量特性

• 一個 Agent 任務包含多次 LLM 呼叫，中間穿插工具執行結果。
• context 非常長（system + tools + 累積歷史紀錄）：到第 10 步時通常會達到 30K–100K tokens。
• prompt 結構高度固定：長而穩定的 prefix，加上少量變動的尾端內容。
• 延遲與成本都很重要。prefill 每多 1 秒，使用者都會明顯感受到等待；15 步 Agent 還會把這個延遲放大 15 倍。

為什麼 Agent 高度依賴快取

每一步都會把前一步的工具呼叫與結果附加到 context。沒有快取時，每一步都得重新支付數萬個 token 的 prefill 成本。

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 ────↑

關鍵規則：每個步驟的工具呼叫與結果都必須只能附加，而且逐 byte 完全相同。只要重寫或重新排序，從該處開始的快取就會全部失效。Agent 最常見的錯誤，就是「先整理工具結果，再傳回模型」→ 快取命中率歸零 → 成本與延遲倍增。

TTL 是否匹配：唯一需要特別注意的使用情境

一般 Agent 任務會在 10–60 秒內完成，單一任務使用預設的 5 分鐘 TTL 沒有問題。但如果 Agent 需要等待人工核准（例如「請檢視這份計畫並回覆」），可能會閒置數分鐘。使用者停頓 10 分鐘、快取過期後，下一步就必須重新支付 50K tokens 的 prefill 成本。這類工作流程可採取以下任一方式：

• 使用 TTL 較長的供應商（實測中 deepseek-v4-flash 的存活時間最長），或
• 等待期間每隔 TTL/2 傳送一次 keep-alive ping（請參閱第 3 篇 §8.2）。

Agent 模型建議

Agent 對推理能力要求較高，應先按品質選擇，再最佳化成本。

† Claude 的 4 個 cache_control 標記模式，仍是 Agent 快取最強的做法，可在 10 步以上的流程中，讓累積 prefix 持續享有折扣。請使用指向閘道的 anthropic SDK。完整 payload 格式與 TTL 選項請參閱第 3 篇 §2。

實際成本估算：15 步 Agent 任務

假設包含 5K system + 3K tools，每一步約增加 3K，共 15 步。以下是依第 3 篇 §6的單次呼叫成本，換算成 Agent 工作負載後的結果：

這些同樣只是概算。最主要的變數，是你能否讓每一步的 prefix 逐 byte 完全相同。

Agent 常見問題

• ❌ 不要在每一步重建 messages list。array 必須逐 byte 相同，只能附加。
• ❌ 不要裁切或重新格式化工具結果。任何 byte 變更都會讓後續快取失效。
• ❌ 不要讓併發執行的 Agent instance 共用 cache key。各 instance 的步驟順序會分岔並互相污染。
• ✅ 監控每個任務的 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。此閘道只是薄型 proxy 加上計價層；所有快取行為都發生在上游模型層。

最後結論

整個系列可濃縮成四句話：

快取帶來兩種收益，而不是一種。 成本與延遲都會降低。 固定內容放前面，變動內容放最後。 維持 prefix 穩定不用多花錢，所有情境都該這樣做。 依使用情境搭配模型與快取行為。 聊天 ≠ RAG ≠ Agent。 用自己的流量實測。 單次 benchmark 只是起點，不是答案。

最快的做法是：從上方矩陣找出最接近你的使用情境，調整結構（固定內容優先的 prefix、確定性的檢索排序、逐 byte 相同的 Agent state），記錄一週的 cached_tokens 與 usage.cost，再重新評估。

FAQ

中文聊天機器人用哪個 LLM 最便宜？ 在我們的測試模型中，deepseek-v4-flash 與 qwen3.5-flash 處理中文內容的成本，比針對英文調校的模型低一個數量級；面對一般聊天工作負載時，品質則與 gpt-5.4-mini 相當。

2026 年最適合 RAG 的 LLM 是哪個？ 英文情境可選 gpt-5.4-mini，搭配解法 A 的 prompt 配置（system tokens 放前面、參考資料放最後），固定部分的命中率可超過 80%。中文情境選 deepseek-v4-flash。如果要頻繁查詢超長文件，選 gemini-2.5-pro，原生支援 1M+ token context。

Agent 應該用 GPT 還是 Claude？ 兩者都很強，差別在於你願意投入多少心力維持快取。透過 anthropic SDK 呼叫閘道時，Claude 的 4 個 cache_control 標記模式特別適合不斷累積的 Agent prefix。prefix 熱起來後，10 步以上流程的輸入成本可降低約 90%。如果你想繼續使用 OpenAI 形式的 client，不想加任何標記，並接受約 50% 的快取節省幅度，gpt-5.4-mini 或 gpt-5.5-pro 導入起來更省事。

從「未最佳化」改成「最佳化」的 LLM 使用方式，實際能省多少？ 以本系列的實測結果來看，同一個模型可達到 50–88% 的成本降幅與 30–60% 的 TTFT 降幅。大部分收益來自把命中率提高到 80% 以上，而不是更換模型。

該從哪裡開始？ 從矩陣中找出最接近你的使用情境，調整 prompt 結構，接著用一週的正式環境流量測量 cached_tokens 與 usage.cost。完成這些步驟後，再考慮是否更換模型。

如何比較不同供應商的 LLM API 價格？ Synthorai 的模型頁面提供即時價格比較，可依供應商篩選，並按每百萬 token 的輸入或輸出價格排序；價格會與閘道的實際牌價同步。上方矩陣協助你依使用情境選擇模型類型，模型頁面則會告訴你目前的實際價格。

來源與驗證：實測數據取自第 3 篇 §6，於 2026-05-25 使用 https://synthorai.io/v1 與 openai SDK 2.38.0 測得。供應商價格頁面：OpenAI · Anthropic · Google Gemini · DeepSeek · Alibaba Bailian。

← 返回部落格