大模型 token 计费完全指南：原理、价格与省钱方法总览
调用一次 GPT-4o 到底花了多少钱？很多开发者接到账单才意识到”token 计费”并不是黑盒——只要理解计费逻辑，成本完全可以精确预估并有效压缩。本文从 token 定义出发，把计费原理、价格横向比较和省钱方向一次讲清楚。
什么是 token
Token 是大模型处理文本的基本单位，既不等于字，也不等于词，而是介于两者之间的”子词”切片。
实用换算规则（近似）：
- 英文：约 4 个字符 = 1 token（“hello world” ≈ 2 token）
- 中文：约 1 个汉字 = 1–1.5 token（“你好世界” ≈ 4–6 token）
- 代码：密度更高，注释和字符串往往比逻辑本身消耗更多 token
不同模型使用的 Tokenizer 略有差异，精确计算建议使用 token 计算器 实测。
为什么中文比英文”贵”？ 主流大模型的分词器（BPE 或类似算法）大多是在英文语料上训练出来的，常见英文单词往往能被切成一个完整 token，但汉字在合并表里出现频率低，经常被拆成 2 个甚至更多 token。这不是厂商故意针对中文用户，而是分词字典的构造方式决定的。实际影响是：同样一句话，中文 prompt 消耗的 token 数常常比对应的英文翻译版本高出 30%–50%。如果你的场景是内部工具、日志分析这类不需要中文交互的任务，把 system prompt 改写成英文往往能直接省下一截成本——这是很多人忽略的一个小技巧。
还有一个容易踩的坑：token 数不等于字符数，也不等于”看起来的长度”。一段全是标点、emoji 或者 markdown 表格符号（|、-、*）的文本，token 密度会显著升高，因为这些符号大多各自占一个 token 而不参与语义合并。如果你的应用会把结构化数据（JSON、表格）直接塞进 prompt，实测下来的 token 数往往比预估高 20% 左右，做预算时一定要按真实文本跑一遍计算器，而不是拍脑袋按字数除以 2 估算。
输入 token vs 输出 token
几乎所有主流 API 都采用 “输入 + 输出分开计费” 的模式，且输出单价通常高于输入（约 3–5 倍）。
| 计费维度 | 说明 | 典型单价倍差 |
|---|---|---|
| 输入 token | prompt + 历史对话 + system prompt | 基准 1× |
| 输出 token | 模型生成的回答 | 通常 3–5× |
| 缓存命中（部分厂商） | 重复前缀不重复计算 | 低至 0.1× |
关键启示： 输出 token 比输入贵得多，因此让模型”少说废话”、控制输出长度是最直接的省钱手段。
实操上有两个具体动作比”控制输出长度”这句话更好落地：一是在 system prompt 里明确要求”只输出结果，不要解释过程”，很多默认行为下模型会习惯性铺垫一段”好的，我来帮你分析一下”，这段客套话看似短，量大了也是真金白银；二是给 max_tokens 设置一个贴合业务的硬上限，不要用 API 默认值——默认值往往偏大，一旦模型进入”复述+总结”的啰嗦模式，输出 token 会不受控地涨上去，你的账单也会跟着涨。
关于缓存命中，各家叫法不同但原理接近：OpenAI 和 Anthropic 都提供了 Prompt Caching（前者叫 prompt caching，后者叫 cache control），命中缓存部分的输入 token 只按很低的折扣价计费；国内一些厂商也有类似的”上下文缓存”能力，命名和触发条件（比如缓存最短存活时间、最小 token 长度门槛）各家不一样，用之前建议查一遍官方文档，不要想当然套用别家的经验参数。
各家计费模式横向比较
声明：以下为截至 2026-06 的定性比较，仅供参考，以各厂商官方定价页面为准。
国内厂商 vs 海外厂商
| 维度 | 国内主流（阿里、百度、字节、月之暗面等） | 海外主流（OpenAI、Anthropic、Google） |
|---|---|---|
| 价格水平 | 普遍更低，部分有免费额度 | 较贵，但顶级能力仍领先 |
| 计费粒度 | 大多按 1k token 或百万 token | 同上，单位逐渐向百万 token 迁移 |
| 系统提示缓存 | 部分支持 | OpenAI/Anthropic 均已支持 |
| 批量折扣（Batch API） | 部分厂商提供 | OpenAI Batch API 提供约 50% 折扣 |
模型级别与价格层级
不同能力档次的模型价格差距悬殊，通常可分为：
- 轻量/快速模型：价格最低，适合分类、路由、摘要等简单任务
- 标准对话模型：主力档，平衡能力与成本
- 旗舰/推理模型（如 o3、R1 等）：价格最高，适合复杂推理，谨慎使用
推理模型额外注意：o 系列、R 系列等”推理模型”会在输出前进行大量内部”思考”，思考 token 同样计费，单次调用成本可能是普通模型的数倍到数十倍。
建议使用 价格对比表 实时比对各模型当前报价。
实际成本如何估算
以一个常见的客服 Bot 场景为例：
| 参数 | 假设值 |
|---|---|
| 系统提示 | 500 token（固定） |
| 平均用户问题 | 50 token |
| 平均模型回答 | 200 token |
| 历史对话轮数 | 3 轮 |
每次调用的 token 消耗约：
- 输入：500（system）+ 3×（50+200）（历史）+ 50（当前）= 1,300 token
- 输出：200 token
历史对话是输入 token 的最大”隐形成本”，每多一轮就多带入一轮的内容。
把单次成本换算成月度账单，公式其实很直白：月成本 = 日均调用次数 × 单次总 token 成本 × 30。接着上面的客服 Bot 例子，假设你用的模型输入单价是 1 元/百万 token、输出单价是 4 元/百万 token（具体以 价格对比表 实时查到的为准），单次调用成本 ≈ 1,300÷1,000,000×1 + 200÷1,000,000×4 ≈ 0.0013 + 0.0008 = 0.0021 元。如果日均 5,000 次调用，月成本约 0.0021×5,000×30 ≈ 315 元。这个数字看着不吓人，但一旦历史轮数从 3 轮涨到 8 轮（很多产品会不知不觉把整段会话都塞进去），输入 token 会从 1,300 涨到 2,550 左右，月成本也会跟着接近翻倍——这就是为什么”压缩上下文”排在省钱清单前列的原因，它的杠杆效应比调低输出上限更大。
并发调用下的成本和体验取舍也值得单独说一说。很多团队为了让用户少等，会用流式（streaming）输出，边生成边吐字给前端；流式本身不会额外计费，计费只看最终生成的 token 总数，但它对超时策略和重试逻辑的要求更高——如果连接中途断了，你已经消耗的那部分 token 通常还是要算钱的，等于白花钱又没拿到完整结果。所以在生产环境做流式对接时，建议给客户端加断线重连缓冲，而不是简单粗暴地整段重试，否则一次网络抖动可能让你重复计费。
关于重试策略，遇到限流（429）或偶发超时，切忌立刻原样重试，正确做法是指数退避（exponential backoff）：第一次等待 1 秒重试，失败再等 2 秒、4 秒……并加上随机抖动（jitter）避免多个请求同时撞线。如果不做退避，在高并发场景下重试请求本身会加重限流，形成”越限流越重试、越重试越限流”的雪崩，账单和错误率会一起飙升。
五大省钱方向概览
成本控制不是猜谜，有成熟的工程方法：
- 启用 Prompt Caching：重复系统提示只算一次，命中后成本可低至原价的 10%。详见 Prompt Caching 省钱原理。
- 选对模型：复杂任务用旗舰，简单任务用轻量模型，路由得当可省 60–80%。
- 压缩上下文：只保留必要历史轮次，用摘要代替全文。
- Batch API：非实时任务批量提交，折扣通常在 50% 左右。
- 监控与告警：设置每日用量上限，避免 Bug 导致的失控消耗。
完整的 10 个省钱技巧见 大模型 API 成本优化 10 招。
哪家模型最便宜？
性价比不能只看单价，还要看”完成同一任务”的实际 token 消耗。详见 最便宜的大模型 API 盘点，里面有按场景的横向对比思路。
常见问题
token 超出上下文窗口怎么办？
超出后 API 通常报错，需要手动截断历史或使用分块（chunking）策略。部分模型支持超长上下文但价格更高。
为什么账单比预期高很多？
最常见原因：① 输出 token 被低估；② 历史对话累积过多；③ 系统提示过长且未开缓存；④ 意外的 retry 或死循环调用。建议先查日志里每次调用的实际 token 数。
同一模型不同地区价格一样吗？
不一定。部分厂商对不同地区有差异定价，企业合同价与按量付费价也可能不同。
429 和 401 报错分别是什么情况，怎么排查？
401 Unauthorized 通常是 API Key 本身的问题：密钥填错、密钥已被撤销、或者用了测试环境的 key 打生产环境的接口地址，先检查密钥是否复制完整（前后不要带空格或换行）。429 Too Many Requests 则是限流，具体又分两种：一种是 RPM（每分钟请求数）超限，一种是 TPM（每分钟 token 数）超限，返回体里通常会标明具体是哪一种，排查时别只看状态码，把 response body 打出来看清楚原因，再决定是该降低并发还是该压缩单次 token 消耗。
上下文超限报错长什么样，怎么处理？
常见报错形如”maximum context length is 128000 tokens, however you requested 132450 tokens”，意思很直白：你这次请求（历史 + 当前输入 + 预留的输出空间）总 token 数超过了模型上限。处理思路优先级：① 先看是不是历史对话没做截断，越堆越长；② 用摘要压缩早期轮次而不是整段截断，保留关键信息；③ 实在需要超长上下文，再考虑切换到支持更大窗口的模型，但要接受它单价通常更高这个代价。
延伸阅读：
- 完整成本优化手册：大模型 API 成本优化 10 招
- 各厂商性价比横向：最便宜的大模型 API 盘点
- 缓存省钱详解：Prompt Caching 省钱原理与实践
- 实时价格对比：价格对比表工具
- Token 用量估算：Token 计算器
- 更多成本话题：token 成本专题
- 接入托管服务降低运维负担：加入候补