一句话结论：大模型推理成本不是靠”换个便宜模型”就能降下来的，它是一套工程治理：稳定提示词前缀换缓存折扣、按难度分级路由模型、控制输出长度、批量与异步化、再加一层预算告警。 OpenAI 官方数据显示缓存输入最高可省 90%，真实客户把缓存命中率从约 85% 提到 90% 以上后，推理成本又降了一档。
一、先搞清钱花在哪
把一次请求的账单拆开看，成本只有三个变量：输入 token（含系统提示、工具定义、历史上下文）、输出 token（含推理 token）、以及模型单价。多数 agent 应用的问题不在单价，而在输入里 80% 是每次都一样的重复内容——系统提示、工具 schema 、项目规范。这部分本可以只付一次。
| 成本项 | 典型占比 | 最有效的手段 |
|---|---|---|
| 重复的固定前缀（系统提示/工具定义） | 高 | 提示词缓存 + 显式缓存断点 |
| 多轮历史上下文 | 高 | 上下文压缩、摘要、只保留结论 |
| 输出长度（含推理） | 中～高 | 限制 max_tokens 、按任务调推理强度 |
| 模型档位选错 | 中 | 分级路由：简单任务用小模型 |
| 重试与冗余调用 | 低～中 | 幂等设计、失败退避、结果缓存 |
优先级口诀：先稳前缀（缓存），再减长度（压缩），最后才换模型。顺序反了，等于用降质换省钱。
二、五条能立刻落地的降本动作
- 把系统提示、工具定义、参考材料放在提示词最前面并保持字节级稳定，变动内容一律放最后；这样最长公共前缀能被缓存命中。
- 用显式缓存断点（cache breakpoint）指定要复用的前缀边界，配合 prompt_cache_key 让同类请求落到同一个推理引擎，命中率更稳。
- 建立模型分级路由：意图识别、格式转换、摘要用便宜的小模型，只有真正复杂的规划与生成才上旗舰模型。
- 按任务难度动态调整推理强度（reasoning effort）：难题调高、常规追问调低，而不是全程最高档。
- 给每次调用打上业务标签（用户/功能/会话），按天聚合 token 与费用，设阈值告警，异常暴涨当天就能发现。
三、缓存：最省钱的一环
OpenAI 在 GPT-6 上重构了提示词缓存：默认命中率更高，共享前缀在 30 分钟窗口内复用即可享折扣，缓存输入 token 最高便宜 90%。同时给了三件套工具——Prompt Caching Dashboard 看命中率趋势与”缓存/未缓存 token”构成，诊断工具给出缓存未命中的具体原因（例如 tools_changed），以及显式断点让你自己决定缓存到哪里结束。
真实客户做到了什么程度
Manus 团队与 OpenAI 工程团队协作，调整缓存断点位置、混合使用显式与自动缓存、用真实请求定位意外未命中，不到一周把缓存命中率从约 85% 提到稳定 90% 以上；另一家客户把 29,000 token 的共享提示词加上断点与 workspace 专用 key 后，未缓存输入减少 28%。 GitHub 也公开表示，近几个月把需要重新处理的 prompt token 占比降低了 50% 以上。
最容易踩的四个”缓存杀手”
- 工具定义变了：顺序、 schema 、增删任一改动都会打断前缀复用。要用 allowed_tools 控制可调用范围，或用 tool_choice=none，而不是临时删掉工具定义。
- 在提示词开头插入动态内容：时间戳、随机数、用户 ID 放在最前面，等于每次都是新前缀。动态内容一律追加到末尾。
- 中途改推理强度或参数：新版模型允许追加 configuration_update 调整而不破坏缓存，直接改请求级参数则会打断。
- 会话 key 分得太散：prompt_cache_key 打散到每个请求，等于主动放弃复用。按”工作区/项目/会话”这类稳定粒度设置。
想系统理解缓存原理，可以看 大模型 Prompt Caching 原理；长上下文场景另见 Anthropic 长上下文怎么用。
四、别让输出吃掉省下的钱
很多团队把输入优化到极致，却放任输出：让模型”顺便解释一下思路”、”输出完整 JSON 再附一段说明”，输出单价比输入贵数倍，一不留神就抵消了缓存收益。实用做法：用结构化输出约束格式、用 max_tokens 设硬上限、把”解释”拆成可选的第二轮请求。
同时注意失败重试的隐性成本：超时重试一次，费用翻倍。给所有调用加幂等键、指数退避和结果缓存，是成本治理里性价比最高的三行代码。
五、最小可运行的监控
// 每次调用后记录，按天聚合即可
logCost({
feature: 'code_review',
model: 'gpt-6-luna',
inputTokens: usage.prompt_tokens,
cachedTokens: usage.prompt_tokens_details.cached_tokens,
outputTokens: usage.completion_tokens,
userId: hash(uid)
});
// 每天算一次命中率，低于阈值就告警
hitRate = cachedTokens / (cachedTokens + inputTokens);
if (hitRate < 0.8) alert('缓存命中率异常：' + hitRate); 只看总花费没用，要看”命中率 + 单任务成本”两个指标。命中率掉 5 个点，账单可能涨 30%。
提示词缓存能省多少钱？
OpenAI 官方口径是最高 90% 的缓存输入 token 折扣，且缓存读取延迟更低。实际幅度取决于你的前缀稳定程度，官方客户案例中命中率从约 85% 提升到 90% 以上，就带来了可观的进一步下降。
为什么我开了缓存但命中率很低？
四个常见原因：工具定义或顺序发生变化、在提示词开头插入了时间戳等动态内容、请求级参数（含推理强度）频繁变动、 prompt_cache_key 粒度过细导致请求分散到不同引擎。
换小模型是不是最直接的省钱办法？
不一定。先做缓存和上下文压缩，通常能拿到 30%～80% 的降幅且不降质；直接换小模型可能牺牲效果。正确顺序是：稳前缀 → 减长度 → 分级路由 → 最后才考虑换档。
怎么判断该不该上多智能体？
多智能体会显著增加 token 开销。只有当任务确实需要并行探索或长流程拆解时才上，并在提示词里明确”什么情况下才启动子智能体”，避免无谓开销。
输出 token 需要单独控制吗？
需要，而且优先级很高。输出单价通常数倍于输入，用结构化输出约束格式、设 max_tokens 上限、把解释拆成二次请求，是最容易见效的三招。
评论 (0)