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 token。
• 用户对首 token 时间极其敏感（>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 token 的稳定系统提示词测得，单次顺序运行，无并发负载。完整表格见 第 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-token 的保活探测（见 第 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 token）都能缓存。每次调用只有面向用户的部分未命中。这对大多数生产级 RAG 已经足够。用 gpt-5.4-mini 在该模式下实测的命中率：系统 token 达 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-token 保活。模式见 第 3 部分 §8.2。

按任务的模型推荐

† Claude 的多 cache_control 标记对分层 RAG 无可匹敌——使用指向网关的 anthropic SDK，见 第 3 部分 §2。

RAG 成本估算（10 万次查询/天）

3K 系统提示词 + 5K 检索文档 + 200-token 查询 + 300-token 输出。数字由 第 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 token。
• 高度结构化的提示词：长而稳定的前缀，小而可变的尾部。
• 延迟和成本都重要——每多一秒预填充都会带来可见的等待，而一个 15 步的智能体会把它放大 15 倍。

为什么智能体依赖缓存

每一步都在上一步的工具调用和结果上追加。没有缓存，每一步都要为数万 token 重新支付预填充。

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 token 重新支付预填充。对于这类工作流，要么：

• 使用更长 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 的提示词布局（系统 token 在前，参考资料在底部），在稳定部分能达到 80%+ 命中率。中文：deepseek-v4-flash。对于经常被查询的超长文档：gemini-2.5-pro（原生处理 1M+ token 上下文）。

智能体应该用 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 · 阿里云百炼。

← 返回博客