如何估算与控制 token 成本
token 是什么
模型按输入+输出的 token 计费，中文与英文的 token 数不同。
先说个容易被忽略的事实：你在网页上看到的”字数”和账单上扣费的”token 数”根本不是一回事。很多人第一次看账单会懵——明明只发了一句话，怎么扣了 30 多个 token？这是因为模型不是按字符计费，而是按分词器（tokenizer）切出来的”子词单元”计费。主流大模型用的是 BPE（Byte Pair Encoding）或者类似算法，会把常见词组切成一个 token，把生僻词、标点、空格也切成独立的 token。
中英文的切法差别很大，实测数据给你参考：
| 内容类型 | 大致换算比例 | 举例 |
|---|---|---|
| 英文单词 | 约 1 token ≈ 4 个字符 | ”hello” ≈ 1 token |
| 中文汉字 | 约 1 汉字 ≈ 1.5–2 token | ”你好” ≈ 2–3 token |
| 代码（含符号、缩进） | 约 1 token ≈ 3–4 字符 | 一行 20 字符代码 ≈ 5–7 token |
| 标点、换行符 | 通常各占 1 token | 一个换行符也要花钱 |
这就是为什么中文场景下调用同样功能，成本往往比纯英文场景高出不少——同一段意思，中文用的 token 数量比英文多。如果你的产品面向中文用户，估算成本时千万别直接照搬官方文档里给的英文示例数字，那会算少。用 Token 计算器 把你的真实 prompt 粘进去看一眼实际数字，比凭感觉估靠谱得多。
还有个更坑的地方：不同厂商的分词器不是同一套。 同样一段中文客服话术，丢进 GPT 系模型和丢进 DeepSeek、通义千问这类国产模型，切出来的 token 数能差 20%–30%。我见过团队把从某个厂商文档里抄来的”中文大概多 token”的经验值，原封不动套到另一个厂商身上做预算，上线后账单和预估差出一大截，回头查半天才发现是分词器不一样闹的。稳妥做法：换供应商就用对方真实接口跑一次，看返回的 usage.prompt_tokens 字段，别凭经验复用。
输入和输出为什么价格不一样
几乎所有主流模型的定价都是”输出比输入贵”，有的贵 3 倍，有的贵 5 倍（具体倍数以各家官网当前价格为准，各厂商会调整，别死记一个数字）。原因不难理解：输入是模型一次性”读进去”，输出是模型逐个 token 自回归生成，计算量本身就更大，而且很多厂商会把”更贵的推理成本”直接体现在输出定价上。
这个价格结构直接决定了你控制成本该往哪使劲：如果你的场景输出内容偏长（比如生成报告、写文案），优化输出长度带来的边际收益，往往比抠输入 prompt 的几十个 token 更明显。 反过来如果场景是”贴一大段上下文，只要一个简短判断”（比如意图分类、内容审核），那优化的重点就该放在输入端的裁剪上。先看清自己场景的输入输出比例，再决定优化重心，别一上来就眉毛胡子一把抓。
控制成本的方法
- 精简 prompt，去掉冗余上下文；
- 缓存可复用结果；
- 按场景选择合适规格的模型。
这三条原文写得很精炼，但每一条展开都有具体门道，下面拆开讲。
一、精简 prompt：别把”能用”和”精简”搞反了
很多团队的 system prompt 是一版一版叠加出来的——今天加一条规则，明天加一个示例，半年下来变成一篇几千字的”说明书”，每次调用都要把这几千字重新喂给模型一遍。精简不是删内容删到模型不听话，而是找到那些”写了但模型根本没用上”的部分。
具体排查方法：
- 把当前 system prompt 拆成一条条独立的指令/规则/示例；
- 挑 20–30 条真实历史对话，人工核对哪些规则实际影响了输出结果；
- 没被验证起作用的部分，先移除，跑一轮 A/B 观察输出质量是否下降；
- 质量没掉，说明这段确实是冗余，可以永久删掉；质量掉了，说明这条规则虽然不常触发但很关键，加回去。
裁剪对话历史的常见做法是滑动窗口 + 摘要压缩组合： 保留最近 N 轮原文对话（保证短期语境连贯），更早的历史用一次性调用模型压缩成一两句话摘要存起来，后续请求只带”摘要 + 最近几轮原文”，而不是全量历史原文。举个真实数字：一个客服场景聊了 15 轮，全量历史大概 3,500 token，压缩成摘要后只剩 200 token 左右加最近 3 轮的 400 token，输入端直接从 3,500 降到 600，降幅超过 80%。
还有一种更彻底的裁剪思路是用检索代替”整段贴入”，也就是 RAG 的核心逻辑：不要把整份产品手册、整个知识库都塞进 prompt，而是先做向量检索，只把和当前问题最相关的几个片段捞出来拼进去。这一步的收益不只是省 token，还能让模型少被无关信息干扰，回答更聚焦。
二、缓存可复用结果：分清”完全命中”和”前缀命中”
缓存要分两层想，很多人只想到了一层。
第一层是应用层结果缓存：如果用户问的内容和之前某次请求完全一样（或者归一化之后一样，比如去掉多余空格、统一大小写），直接把上次的结果拿出来返回，这次调用直接省掉，成本降为零。适合 FAQ、固定模板、高频重复问题这类场景。
第二层是 API 侧的 Prompt Caching：即使用户这次问的内容和上次不完全一样，只要 prompt 里有一大段固定不变的前缀（比如很长的 system prompt、知识库片段），厂商能识别出这段前缀之前处理过，对这部分给出计费折扣。这层缓存不需要你自己维护缓存服务，但通常有最小前缀长度门槛（比如要求前缀达到一定 token 数才生效，具体门槛以各厂商官方文档为准），而且缓存命中通常有较短的有效期，短时间没有新请求命中就会失效。
两层配合效果：完全命中应用层缓存 → 免费；没命中但前缀一致 → 打折价；完全是新内容 → 正常价。实际项目里，把这两层都搭起来后，重复度高的场景（客服、FAQ 类）综合成本降低 60% 以上是常见的效果，具体降幅取决于你的请求重复率有多高。
三、按场景选择合适规格的模型：别用旗舰模型做流水线活
选模型不是越贵越好，也不是越便宜越好，核心是”匹配任务的复杂度”。给你一个判断依据表，按任务类型对号入座：
| 任务类型 | 特点 | 建议模型规格 | 理由 |
|---|---|---|---|
| 意图分类、路由判断 | 输出简单，逻辑固定 | 小/轻量模型 | 任务简单，旗舰模型是杀鸡用牛刀 |
| 客服问答（有知识库支撑） | 中等复杂度，需要理解上下文 | 中等规格模型 | 平衡效果和成本 |
| 复杂推理、多步规划 | 需要深层逻辑链条 | 旗舰模型 | 便宜模型容易推理断链，返工成本更高 |
| 批量数据标注、摘要生成 | 量大、单条简单 | 轻量模型 + Batch API | 走批处理接口通常有额外折扣 |
| 代码生成、复杂长文写作 | 需要强能力保证质量 | 旗舰模型 | 省下来的模型费用可能不够返工的人工成本 |
一个真实的反面案例：有团队把所有请求都无脑打到旗舰模型，包括最简单的”这是不是垃圾评论”这种二分类任务，一个月账单里有一大半花在了这类最不该花钱的地方。换成一个轻量模型跑分类，效果几乎没差，成本却降了一个量级。分层调度——先用轻量模型做粗筛/路由，只有复杂请求才升级到旗舰模型——是控制成本最立竿见影的一招，也是很多团队最后才想到的一招。
常见报错和怎么排查
控制成本这件事，光会省钱没用，还得知道账单为什么突然涨了、调用为什么突然失败，这几类报错几乎人人都会遇到：
429（Rate Limit / Too Many Requests）： 短时间并发请求数超过了账号或者 Key 的速率限制。别看到 429 就一股脑重试，容易越重试越堵。正确做法是加指数退避重试（比如第一次等 1 秒，失败再等 2 秒、4 秒，叠加一点随机抖动避免多个请求同时重试撞车），并且在应用层做限流排队，别让并发量长期顶着上限跑。
401（Unauthorized）： 大概率是 Key 失效、权限不对，或者调用的接口路径和你申请的服务不匹配。先查 Key 有没有过期或者被限制了调用范围，别急着怀疑是账户欠费——欠费通常会有专门的错误码提示余额不足，而不是笼统的 401。
context 超限（类似 “maximum context length exceeded” 或者 “input is too long”）： 说明输入 + 期望输出的 token 总和超过了模型的上下文窗口上限。常见原因是对话历史越滚越长没做裁剪，或者 RAG 检索召回的片段拼太多。修法就是前面讲的滑动窗口 + 摘要压缩，加一道”发送前先算一遍总 token 数，超限就自动裁剪最早的历史”的兜底逻辑，别等报错了才手忙脚乱去改。
编码问题导致的乱码或者 token 数异常偏高： 常见于处理表情符号、生僻字、或者从 PDF/网页抓取来的文本里混了不可见字符。这类字符往往会被分词器切成好几个 token，甚至触发编码报错。上线前对输入做一遍清洗（统一编码、过滤控制字符）能省不少冤枉钱，也能避免莫名其妙的调用失败。
调用超时： 输出长度设得太大、或者选了推理速度慢的模型规格，容易在高峰期超时。如果业务场景对实时性要求高，优先用流式（streaming）接口——边生成边返回，用户能更快看到内容，你也能在检测到明显跑偏时提前中断调用、省下后面还没生成的 token 费用，这比等一次完整调用跑完了再判断划算得多。
进阶：把估算变成可持续的监控习惯
估算和裁剪只是”上线前”的动作，真正管住成本要靠”上线后”的监控闭环。几乎所有 API 的返回里都带 usage 字段（输入 token 数、输出 token 数），把这些数字落到日志里，每天跑个脚本汇总，看两件事：一是实际均值有没有明显偏离你上线前的估算，偏离超过 30% 就要回头查是不是对话历史或者检索片段又变长了；二是设一个日/月成本告警阈值，接近阈值就发提醒，别等账单出来才后知后觉。
并发场景下还要留意一点：多个请求同时打到 API，如果没有做好速率控制，很容易一波把预算打光还触发限流。给关键业务路径加一层排队或者令牌桶限流，把突发流量削平，既避免 429，也避免因为并发失控导致成本在短时间内失控式增长。
想更系统地摸清楚各家模型的定价结构、看看有没有更便宜又够用的选型，可以去 token成本专题 里翻一翻其他几篇；如果你还在纠结要不要现在就接入、想先弄清楚整体接入路径和后续可能的 token 折扣渠道，也欢迎去 Waitlist 留个联系方式，后续有专属的成本优化方案会第一时间同步。