你发送给 OpenAI 的每一条提示（prompt），以及模型生成的每一次响应，都会被拆分为一个个 Token。
OpenAI 会分别对输入 Token和输出 Token进行计费，并且不同模型的费率也各不相同。
Token 数量并不是一个固定不变的数字。在生产环境中，随着提示不断演进、对话历史逐渐累积、检索上下文持续扩展，Token 使用量往往会不断增长。
这通常意味着：
一个在测试环境（staging）中看起来成本很低的功能，在用户量没有明显增长的情况下，实际成本却可能增长到原来的 5 倍。
因此，如果你正在构建真正用于生产环境的 AI 功能（而不仅仅是做实验），就必须理解 OpenAI 每 Token 的真实成本机制。
接下来，我们先来看看：OpenAI 的每 Token 成本到底意味着什么。
OpenAI 定价中“每 Token 成本”到底是什么意思？
OpenAI 的“每 Token 成本”指的是其在后台对使用量的计量方式。平台按照 Token 数量进行计费。
在 OpenAI 体系中，Token 是模型处理文本的最小单位，涵盖：
- 你发送给模型的所有内容（输入）
- 模型生成的所有内容（输出）
Token ≠ 单词
Token 并不等同于一个“单词”。OpenAI 采用的是子词级（sub-word）分词机制，这意味着：
- 常见单词可能只占 1 个 Token
- 罕见单词可能会被拆分为多个 Token
- 标点符号和空格也可能计入 Token
- JSON、代码和结构化格式会显著影响 Token 数量
- 表情符号、非英文文本以及特殊字符通常会进一步拉高 Token 计数
举个例子：
- 1,000 个普通英文单词，大约会对应 750–1,300 个 Token
- 但如果这“1,000 个单词”是 JSON、SQL、Python、Markdown、日志文件或检索出来的知识库文本，Token 数量可能会比预期高出 2–5 倍
看起来相似的 API 调用，成本可能完全不同
需要特别注意的是：
由于每个提示的字数和结构不同，即便两个 API 调用看起来非常相似，它们的成本也可能不同，因为 Token 数量并不相同。
还有一个关键点：输出通常更贵
OpenAI 的定价结构通常将输入 Token 和输出 Token 分开计费，而且在很多模型中，输出 Token 的价格更高。
这会形成两种完全不同的成本结构：
- 总结与分类类用例：通常输入多、输出少（input-heavy）
- 写作、聊天机器人、代码生成类用例：通常输出多（output-heavy）
因此，根据不同的调用场景：
- 某些请求可能只处理 200 个 Token
- 另一些请求却可能达到 5,000 个 Token
而这之间的成本差异，往往远超你的直觉预期。
如何换算 OpenAI 的 “每 100 万 Token 多少钱” 定价？
OpenAI 以“每 100 万 token 美元价格”的形式公布定价，并且区分：
- 输入 token（input tokens）
- 缓存输入 token（部分模型支持）
- 输出 token（output tokens）
要把这些价格换算成可实际使用的数字，可以使用两个公式：
每个 token 成本 =（每 100 万 token 的价格）÷ 1,000,000
每 1K token 成本 =（每 100 万 token 的价格）÷ 1,000
例如，如果某个模型的输入价格是 $10 / 100 万 token，那么：
- 每个 token 成本 = $0.00001
- 每 1K token 成本 = $0.01
这一步换算非常关键，因为它能让你把 OpenAI 的官方定价表，转化为：
- 每次 prompt 的成本
- 每个功能调用的成本
- 每个用户行为的成本
- 甚至每个客户生命周期的 AI 成本
在后面的 SaaS 实际案例中，我们会用到这套计算方式。
OpenAI API 按 token 计费
OpenAI 的定价是按以下维度公布的：
- 按模型区分
- 按 token 类型区分
- 按每 100 万 token 计价
并且这些价格会随着新模型发布、升级或退役而变化。
在做采购或预算决策前，请务必前往 OpenAI 官方实时定价页面确认当前价格。
另外需要注意：
OpenAI 已不再提供可用于生产环境的“旧版模型”。当前所有使用都基于 GPT-5 级别模型及更新版本。
此外，计费严格绑定你当前调用的具体模型 ID，而不是某个历史模型家族。也就是说：
- 不再存在“legacy model”单独定价层
- 不存在老版本的特殊优惠价
模型定价完全取决于你实际调用的那个模型 ID。
接下来，我们进入具体内容。
如何读懂 OpenAI 的定价表？
当你打开 OpenAI 的定价页面时，只需要关注三件事：
1.精确的模型 ID
不要只看“模型家族名称”，一定要确认你实际调用的 具体模型 ID。
计费是严格绑定到当前调用的模型版本。
2.分开的三种费率
每个模型通常会列出独立价格：
- Input tokens（输入 token）
- Cached input tokens（缓存输入 token，部分模型支持）
- Output tokens（输出 token）
这三种价格往往不同，而且输出 token 通常更贵。
3.计价单位：美元 / 每 100 万 token
所有价格都以：美元 / 1,000,000 tokens 的形式展示。
只要你拿到这三个数字：
- 模型 ID
- 输入 / 缓存输入 / 输出价格
- 每 100 万 token 的美元价格
你就已经具备计算 每 token 成本 的全部信息了。
接下来，我们就用这些数字，实际算一遍成本。
如何计算 OpenAI 每次调用的 Token 成本（Step-by-Step）
我们先给出一个最干净的公式，然后再叠加那些在真实环境中常被忽略的因素。
在最简单的情况下，OpenAI 的单次请求成本为：
Cost = (input tokens × input rate)
- (cached input tokens × cached input rate，如适用)
- (output tokens × output rate)
其中：
- Input tokens：你发送给模型的全部内容
- Output tokens：模型生成的全部内容
- Rate：每个 token 的美元成本（由 “$ / 100万 token” 换算得出）
这个公式适用于：
- 单轮 prompt
- 多轮聊天
- RAG 工作流
- Tool 调用增强场景
前提是：你正确统计了 token。
Step 1：把 OpenAI 定价换算成可用费率
对于任何 token 类型：
- 每 token 成本 =（每 100 万 token 的价格）÷ 1,000,000
- 每 1K token 成本 =（每 100 万 token 的价格）÷ 1,000
例如，某模型收费：
- $8 / 100万 input tokens
- $24 / 100万 output tokens
那么：
- Input 每 token 成本 = $0.000008
- Output 每 token 成本 = $0.000024
Step 2：识别所有输入 token 的来源
很多团队低估成本，是因为他们只计算“用户输入的文字”。
但在生产环境中，Input tokens 包括：
- System prompt 和指令
- Developer message 与策略规则
- 保留的对话历史
- 检索内容（RAG 文档块、知识库文本）
- Tool 定义或函数 schema
- 格式化开销（JSON、XML、Markdown 等）
一个简单的思维模型：
Input tokens = 用户 prompt + 你附加的一切内容
如果你只计算“可见的用户文本”，你的成本估算一定偏低。
Step 3：估算输出 token
Output tokens 相对更直观，但同样容易被低估。
常见的输出增长因素包括：
- 没有限制 max tokens 的开放式生成
- 长解释和推理过程
- 多步骤 tool 响应
- 默认偏啰嗦的回复风格
如果你不显式限制输出长度，模型通常会生成比预期更多的 token，而且不同请求之间波动较大。
这也是为什么在：
- Chatbot
- 代码生成
- 长文本写作
这些场景中，输出 token 往往是主要成本来源。
Step 4：考虑多轮上下文的叠加
在多轮对话系统中，每一次新请求通常都会包含：
- 原始 system prompt
- 最近 X 条用户消息
- 最近 X 条模型回复
这意味着：同一段对话会随着轮数增加而越来越贵。
举个简单例子：
- 1 input: 400 tokens
- 2 input: 400 + 上一轮 400 + 上一轮 output
- 3 input: 400 + 前两轮上下文
- …
即使你每次输入都很短，总输入 token 也会呈复利式增长。
Step 5：在适用情况下考虑缓存输入（Cached Input）
部分新一代模型支持“缓存输入定价”。
这意味着：
- 如果你的 prompt 有大段内容在不同请求中重复
- 且模型支持 caching
- 那些重复部分可以按更低费率计费
典型适用场景包括：
- 大型固定 system prompt
- 重复使用的指令模板
- 稳定的结构化输入块
但要注意两个关键前提：
- 文本必须完全一致才可缓存
- 仅限支持缓存的模型
如果你的 prompt 每次都有改动，缓存机制对降低成本帮助有限。
到这里，你已经掌握了完整的计算逻辑。
接下来，我们可以用真实 SaaS 场景，把这些公式变成具体的成本模型。
使用 OpenAI 时的 Token 成本示例
基于我们刚才的计算方法，来看两个你在生产环境中很可能已经遇到的典型场景。
示例 1：客服 Chatbot 回复
假设：
Input：
- system prompt：300 tokens
- 用户消息：150 tokens
- 对话历史：550 tokens
总输入 = 1,000 tokens
Output：
- 模型回复：250 tokens
费率：
- 输入：$0.008 / 1K tokens
- 输出：$0.024 / 1K tokens
成本计算
- Input 成本 = (1,000 ÷ 1,000) × 0.008
- Output 成本 = (250 ÷ 1,000) × 0.006
- 单次回复总成本 = $0.014
如果每月 100,000 次回复：总成本 = 100,000 × 1,400
示例 2：多轮对话
假设：
Turn 1
- Input = 500 tokens
- Output = 200 tokens
- 成本 ≈ $0.009
Turn 4（累积上下文后）
- Input = 1,800 tokens
- Output = 220 tokens
- 成本 ≈ $0.021
同一个用户，同一个功能，单轮成本却超过 2 倍。
这正是为什么，在很多场景下，驱动 AI 成本上涨的不是流量增长，而是 token 增长。
Token 预算管理：如何为 Token 使用设置“护栏”
当你理解了 token 是如何增长的，下一步问题就是：
如何防止它吞噬你的利润？
一个在生产系统中非常有效的方法是：
把 token 当成预算资源，而不是无限副产品。
就像你会为延迟、内存、错误率设置上限一样，你也应该为每个 AI 功能设定明确的 token 预算。
什么是 Token 预算？（以及如何设计一个合理的预算）
Token 预算指的是：
单次功能调用允许消耗的最大 token 额度。
通常包含：
- 最大输入 token 数
- 最大输出 token 数
- 单次调用目标成本
例如，一个搜索摘要功能的 token 预算可能是：
- Max input：1,200 tokens
- Max output：250 tokens
- 目标成本：≤ $0.004 / 次
任何超过这个限制的情况，都应被视为：
- Bug
- 回归问题
- 或明确的产品决策
而不是“意外”。
如何设计一个实用的 Token 预算
目前高效团队通常从三个维度设定预算。
1.输入 Token 上限（Input Token Ceiling）
限制单次请求最大输入规模。
常见策略包括：
- 限制 system prompt 长度
- 限制 RAG 检索上下文大小
- 限制对话历史长度
如果超出限制：
-
截断（truncate）
-
摘要（summarize）
-
或拒绝请求（reject）
2.输出 Token 上限（Output Token Ceiling）
限制模型生成的冗长度。
常见控制方式：
- 设置 max output tokens
- 定义响应长度等级（short / medium / long）
- 使用结构化格式约束（JSON schema、固定字段）
这是在以下场景中最有效的控制手段：
-
Chatbot
-
代码生成
-
长文本写作
3.单次调用成本目标（Cost Per Invocation Target）
把 token 使用直接绑定到业务经济模型。
与其说： “这个功能可以用 2,000 tokens”
不如说： “这个功能必须 ≤ $0.005 / 次”
然后反向推导：
- 用哪个模型？
- 可以承受多少上下文？
- 输出允许多长？
- 是否需要缓存？
Token Budget 应该放在哪里？
Token 预算只有在“靠近代码”时才真正有效。
高绩效团队通常会：
- 在代码或配置中定义预算
- 像依赖一样进行版本管理
- 在 CI 中做验证
- 超限时触发告警
例如：
- 拒绝任何 input tokens 超预算的请求
- 在超限时自动截断上下文
这样，token 控制就成为：工程问题，而不是财务事后复盘问题。
一个实用经验法则
在设计或评估一个 AI 功能时，先问：
这个工作负载是“输入驱动型”还是“输出驱动型”？
然后：
- 如果是输入驱动型 → 优化检索规模、上下文窗口、system prompt 长度
- 如果是输出驱动型 → 优化 max output tokens、响应格式、冗余控制
- 如果是均衡型 → 默认更高波动、更高监控需求、更严格护栏
真正决定 AI 成本曲线的，从来不是“调用次数”。
而是：每次调用消耗了多少 token。
常见问题解答（FAQs）
OpenAI 的 “cost per token” 是什么意思？
OpenAI cost per token 指你为模型处理的每一个文本单元支付的费用，包括输入和输出 token。
OpenAI 中的 token 和单词一样吗？
不是。一个 token 可以是单词的一部分、完整单词、标点、代码，甚至是空格。
OpenAI 会对输入和输出 token 收费不同吗？
会。输入 token 和输出 token 有各自的价格，通常输出 token 更贵。
为什么 OpenAI 价格按“每 1M token”计算，而不是按请求计算？
因为 OpenAI 按使用量计费，而不是按请求计费。每个请求包含的 token 数量可能相差很大。
如何计算 OpenAI 的 cost per token？
用每百万 token 的价格除以 1,000,000 即可得到每个 token 的成本。
如何计算 OpenAI 每次 API 调用成本？
公式为：输入 token 数 × 输入费率 + 输出 token 数 × 输出费率。
为什么 OpenAI 成本会随着时间增加，而用户数量没有增长？
因为随着提示扩展、上下文累积以及多轮对话，token 使用量会增加。
生产环境中，什么会导致 token 使用量激增？
常见原因包括：长 system prompt、保留的对话历史、RAG 检索上下文、以及未限制输出长度。
输出 token 通常是最大的成本来源吗？
是的。聊天机器人、文本生成和代码生成通常是输出密集型，因此成本更高。
OpenAI 的 cached input 定价是什么？
Cached input 是针对重复提示文本提供的折扣价格，仅适用于支持该功能的模型。
Cached input 能显著降低 OpenAI 成本吗？
仅在大块提示文本在多次请求中完全相同，并且模型支持缓存时才有效。
为什么 OpenAI 成本难以预测？
因为价格随着 token 使用量而变化，而不是固定流量、基础设施或容量。
什么是 token budget？
Token budget 是为每次功能调用设定的输入和输出 token 的最大数量。
为什么 token budget 要在代码中执行？
因为 token 增长是工程问题，而不是财务问题，不能等到账单结算后才发现。
OpenAI cost per token 和 cost per feature 有什么区别？
Cost per token 衡量使用量；cost per feature 则将使用量转换为实际产品经济价值。
