Token 要花多少钱：如何计算 OpenAI、Claude 与 Gemini API 支出

API 账单往往比页面上的标价更扎心：模型按每一个输入与输出 token计费，不是「一次请求」。下文说明 OpenAI、Claude、Gemini 的计费方式、如何估算月度预算，以及企业通常在哪里多花钱。

• Token - 计费单位：大约 3-4 个字符或一个词的一部分
• 输入量更大；输出每 1M 更贵 - 长上下文比「短而聪明的回答」更伤账单
• 公式 - (input_tokens / 1M) × input_price + (output_tokens / 1M) × output_price
• 2026 年 7 月参考 - GPT-5.6 Luna/Terra/Sol，Claude Sonnet 5 / Opus 4.8 / Fable 5，Gemini 3.5 Flash / 3.1 Pro
• 隐性成本 - system prompt、聊天历史、RAG 分块、重试、tool 调用
• 省钱 - 日常用小模型、caching/batch、裁剪上下文，只在难例上升级到旗舰

Token 是什么，为什么不是「一个词」

Token 是模型分词后的文本片段。它不一定是完整单词：「编程」可能是 2-3 个 token，空格与标点也会计入。体积估算可用：

精确切分取决于提供商的分词器 - 计费请看 API 响应里的 usage，不要靠肉眼估。单次请求上限见上下文窗口。

API 价格如何计算

三家厂商结构相同：

1. 统计 input tokens（system + user + 历史 + 附件/分块）。
2. 统计 output tokens（回答；有时 reasoning/thinking 另计）。
3. 费率按 每百万 tokens（1M），输入输出分开。
4. 单次调用成本：

cost = (input_tokens / 1_000_000) × price_input
     + (output_tokens / 1_000_000) × price_output

重要细节：

• 输出每 1M 几乎总是更贵 - 常为 4-6 倍 - 长回答与「推理」很快推高账单。
• 部分模型在阈值以上使用长上下文加价（OpenAI GPT-5.6 超过 272K；Gemini 3.1 Pro 超过 200K）。
• Batch API 与 prompt caching 可降低重复 system/RAG 上下文的价格 - 需要架构支持。
• ChatGPT / Claude / Gemini Workspace 席位是另一条成本线，勿与按 token 的 API 混淆。平台对比见 ChatGPT vs Claude vs Gemini。

2026 年 7 月费率：计算参考

价格会变 - 上线前请核对官方价目。以下为 2026 年 7 月模型概览 中的工作参考（美元 / 1M tokens，standard）。

OpenAI（GPT-5.6）

Input 超过 272K 时，GPT-5.6 使用长上下文费率（参考：input ×2，output ×1.5）。

Anthropic（Claude）

自 2026-09-01 起，Claude Sonnet 5 参考价：$3.00 / $15.00 每 1M。

Google（Gemini）

Gemini 3.1 Pro 超过 200K tokens - 更高费率（参考：$4.00 / $18.00 每 1M）。

计算示例

示例 1. 客服回复：短对话

单工单：

• input：1 200 tokens（指令 + 问题 + 2 轮历史）；
• output：400 tokens；
• 规模：每月 50 000 工单。

L1 客服几乎从不需要旗舰：检索质量与允许「不知道」比顶级基准更重要。

示例 2. 大量上下文的合同摘要

单文档：

• input：80 000 tokens（PDF + system）；
• output：2 000 tokens；
• 规模：每月 2 000 份文档。

这里的主成本是 input。更省钱的不是「答得更短」，而是在 RAG 相关分块足够时别塞整份 PDF。

示例 3. 带 tools 的智能体：隐藏乘数

智能体的一次「用户请求」常等于 5-20 次模型调用（计划 → tool → 观察 → 再计划）。若每步都带完整 system + 历史：

agent_cost ≈ cost_of_one_call × number_of_steps

Terra 上 10 步、每步 8K input / 500 output，已不是「几分钱一次聊天」，而是难例上的真金白银。要按智能体 trace 做预算，而不是按 UI 消息。

企业常在哪里多花钱

1. 一切都用旗舰。 用 Sol / Fable 5 做邮件分类与 FAQ - 经典预算漏洞。
2. 每次调用都带厚 system + 完整历史。 无 caching 的重复上下文会放大 input。
3. RAG 不限制分块数量。 「以防万一」的十块比两块相关内容更贵，质量还更差。
4. 重试与 fallback 未计入。 超时 → 重试 → 第二模型 = 一次点击双倍账单。
5. 「以防万一」的长输出。 高 max_tokens + 含糊 prompt = 模型写长文。
6. 席位与 API 混淆。 Team 订阅不会取消产品、机器人与自动化的 token 账单。
7. 忽视长上下文费率。 越过 200K/272K 阈值费率会跳，看板还在显示「平均」价。

如何估算月度预算

财务与 CTO 可用模板：

1. 将流量拆成场景（客服聊天、摘要、智能体、嵌入分别算）。
2. 每个场景用日志中的 input/output 中位数（不是理想演示请求）。
3. 乘以每月请求量 / 智能体步数。
4. 加上 20-40% 缓冲：重试、峰值与实验。
5. 规划换模型：先在小模型试点，再按规则升到大模型。

规划小表：

没有这张表，「选最聪明的模型」是抽奖，不是财务。

如何降本不损质

• 模型路由。 分类与草稿用 Luna / Flash / Sonnet；硬核代码与长 agentic 链用 Sol / Fable 5。
• 上下文工程。 裁剪历史、保持短 system、勿重复同一套指令。见上下文工程。
• 用 RAG 代替「全塞进 prompt」。 输入更少 - 账单更低，也减少噪声导致的幻觉风险。
• Prompt caching 与 batch。 重复指令与夜间批处理通常比 realtime 便宜。
• 硬性输出上限。 用 structured output（JSON）代替长文；明确长度上限。
• 升级而非默认旗舰。 先用便宜模型；置信度低或任务类型难时再用贵模型。
• 可观测性。 按 feature/tenant 记录 usage：否则无从优化。

总结

Token 成本不是「价目表上的模型价」，而是 输入量 × 费率 + 输出量 × 费率 × 调用次数。2026 年合理的业务栈通常是：流量用便宜快模型，工作文档用 mid-tier，旗舰只在点上使用。按真实日志场景计算，纳入智能体链路与重试 - API 就不会再变成月末惊喜。

常见问题

输入 token 与输出 token 在价格上有何不同？

输出几乎总是每 1M 更贵，有时 4-6 倍。但最终账单常被 input 撑大：长文档、聊天历史与 RAG 分块。要看 usage 的两部分，不只是「模型写了多少」。

一条普通用户消息有多少 token？

简短中文问题常见 20-100 tokens。加上 system prompt、政策与 10 轮历史，「一次聊天」在回答前就轻易变成 1 000-5 000+ input。做预算要量完整请求，不是只量客户那一句。

高流量更适合 Gemini Flash、GPT Luna 还是 Claude Sonnet？

大批量分类、FAQ 与短答复往往是 Gemini 3.5 Flash 与 GPT-5.6 Luna 更划算。更看重文风、指令遵循与文本细致、且价格仍适中时选 Claude Sonnet 5。用自家数据集做 A/B 验证，别只看价目表。

「以防万一」是否总该选最贵模型？

不该。 贵模型在难任务上才划算：长代码、agentic 链、严格推理要求。同类请求洪流中溢价是浪费 - 更宜路由 + 按规则升级。

还没有日志时，如何快速估月账单？

取 20-50 条真实 prompt，过一遍 API，记下 usage，平均 input/output，乘以预估请求量，再加 30% 给重试与增长。1-2 周后用生产中位数替换估算 - 误差通常会降好几倍。