大模型 API 的钱花在哪：输入、输出、缓存与失败调用拆解
先把账拆开：一笔调用到底由哪几块钱组成
很多企业第一次看大模型账单时的反应是一样的：明明业务量不大，钱怎么花得这么快。原因通常不是单价高，而是没人把费用拆开看。我们在帮客户做 API 成本梳理时，习惯把一笔调用的费用分成四块：输入 token、输出 token、缓存、重试与失败调用。前两块是明面上的，后两块是账单上不写、但真金白银流走的。
先说一个前提，也是我们踩过的坑：不同供应商的计费口径并不统一。有的把系统提示词也计入输入，有的对缓存命中单独定价，有的输出按生成 token 计、有的把思考过程也算进去，还有的按「请求次数 + token」双轨收费。所以看到「每百万 token 多少元」就直接横向比价，结论往往是错的。比较之前先统一口径：同样一段提示词、同样长度的输出、同样开启或不开启缓存，各跑一次，把实际扣费拉平到「一次有效业务调用多少钱」，这才有可比性。详细的服务范围与计费方式可以看我们的模型 API 与成本管理页面。
第一块：输入 token，最容易被悄悄放大的部分
输入 token 单价通常比输出低，所以很多人不当回事。但输入的量级往往远超预期，因为它由提示词模板、历史对话、检索到的资料、工具返回结果共同堆出来。一个客服问答场景，如果每轮都带上完整历史对话和前五条知识库片段，输入很容易从 800 token 涨到 6000 token，费用直接翻几倍，而回答质量未必提升。
我们通常做三个动作：去掉模板里没人看的说明性文字；历史对话只保留最近若干轮并做摘要压缩；检索片段按实际需要条数取，而不是固定塞满。这三步不涉及换模型，也不改业务流程，纯靠改提示词结构，很多客户输入侧能降下来一半左右——具体幅度取决于原始提示词有多臃肿，不能一概而论。
输出 token：贵在它不可控
输出单价高，更麻烦的是它由模型自己决定长度。同一句「请总结这段内容」，模型可能回 80 字也可能回 400 字。业务上常见的浪费是：让模型输出整段 JSON、再用代码解析其中两个字段；或者要求「详细说明」却没有字数约束；或者把不需要推理的简单分类任务交给会展开讲道理的模型。
实操上，输出侧最有效的三个约束是：明确字数或条目上限、用结构化输出减少解释性文字、把「思考」和「回答」分开控制。另外提醒一句，结构化输出如果字段设计得过于宽泛，模型会自己补内容，长度反而涨。字段能少就少。
第二块：缓存，省钱的杠杆也是算错账的重灾区
缓存分两类，理解错就会误判收益。一类是提示词缓存（供应商侧，对重复出现的相同前缀按较低价格计费）；另一类是你们自己业务侧的结果缓存（同样的问题直接返回上次答案，压根不调用模型）。后者省得更多，但对时效性敏感的场景要慎用。
提示词缓存的生效前提是「前缀完全一致」。这意味着如果你在系统提示词开头拼接了当前时间、用户名、随机 ID，缓存命中率会掉到零。我们见过一个典型情况：开发为了调试方便，在提示词最前面加了时间戳，上线后忘了删，缓存基本没命中过，账单一直按全价走。
| 费用块 | 由什么决定 | 常见失控原因 | 可下手的地方 |
|---|---|---|---|
| 输入 token | 提示词模板 + 历史对话 + 检索内容 + 工具返回 | 提示词臃肿、历史全量携带、检索条数固定 | 精简模板、历史摘要、按需检索 |
| 输出 token | 模型生成长度 | 无字数约束、输出冗余结构、模型选型过重 | 设上限、结构化输出、任务分级 |
| 缓存 | 前缀一致性与业务结果复用 | 提示词开头有变量、缓存策略未设计 | 固定前缀、结果缓存加过期时间 |
| 重试与失败 | 超时、限流、格式解析失败 | 无退避重试、无兜底、解析规则过严 | 指数退避、失败降级、校验放宽 |
第三块：重试与失败调用，账单上看不见的那部分
失败调用多数是计费的。超时了、限流了、返回格式不符合你的解析规则被判失败然后重试——这些请求在供应商那边已经产生了 token。一次失败重试，等于同样内容再付一遍钱。如果重试逻辑写得粗，比如失败立即重试三次，遇到限流时会连环失败，费用翻三倍而用户只看到一次报错。
可套用的做法是：重试必须带指数退避和次数上限；对限流错误单独处理，不要混在通用重试里；流式输出中途断开要有明确处理策略，而不是直接重发整段；解析失败优先放宽校验规则，而不是立刻重调模型。这几点加到代码里通常不到一天工作量，但对账单的影响比换更便宜的模型更直接。
一个可套用的估算思路
不用一上来就搭复杂的成本系统。拿一个典型业务请求，按下面顺序算一遍就能看出量级：
- 记录单次请求的输入 token、输出 token 实际数值，取 20 次以上的平均值，别拍脑袋估。
- 算日调用量：真实用户数 × 人均请求次数 × 一次业务动作里的模型调用次数（这里常被漏掉，一个动作内部可能调了三次）。
- 加上重试系数。按实测失败率乘，一般先按 1.1 到 1.3 估，稳定后再收紧。
- 分别乘输入、输出单价，注意单位是每百万 token，换算时别差三个数量级。
- 最后加上缓存抵扣，按实际命中率打折，没实测过就先按零算，宁可高估。
算完通常会得到一个和直觉不一样的结论：贵的不一定是模型单价，而是调用结构和重试。AI 工作流自动化里这种结构性浪费尤其常见，因为节点一多，中间结果被反复塞进上下文，没人统管。
三种最常见的浪费，对照自查
一、超长上下文
把整份文档、整张表、整段会议记录丢进提示词，指望模型自己找。上下文窗口变大之后，这种写法更泛滥了。问题是又贵又慢，而且长上下文里关键信息的召回未必更好。更稳的做法是先检索再拼装，这也是企业知识库真正起作用的地方：把资料切分、建索引，每次只给模型需要的几段，而不是整本。
二、重复调用
同一个问题一天被问几十遍，每次都重新调模型；或者同一份内容被多个流程重复处理。有些重复是合理的（需要最新数据），有些不合理（FAQ 类问题）。对不敏感、变化慢的问题加一层结果缓存，命中直接返回，能省下相当一部分。
三、无路由
所有任务都走同一个大模型。分类、抽取、格式转换这类简单任务，用轻量模型就够；复杂推理再走大模型。中间加一层路由判断，按任务类型分派，是我们见过投入产出比最高的优化之一。轻量模型的比例能提到多少，要看你的任务分布，需要实际跑一批样本对比准确率再定，不能一刀切。
比较供应商之前，先做这三件事
一是统一口径，如前面所说，用同一组样本跑出「一次有效业务调用成本」，不要只比标价。二是把重试和失败率纳入对比，稳定性差的供应商在账单上会更贵。三是把迁移成本算进去，换模型意味着重新调提示词、重新测准确率，这部分人力往往被忽略。
如果你们的调用量已经到了每月看到账单会皱眉的程度，又说不清钱具体花在哪，可以先做一次成本盘点：把最近一周的请求日志按上面四块拆一遍，通常能找出两三个立竿见影的改动点。需要有人一起看，可以联系我们，或者直接打 400-873-2750，带上你们的调用量级和场景描述，我们先判断值不值得做优化，不合适也会直说。涉及报价的部分，都以实际方案与报价为准，不做模糊承诺。