AI开发计费详解：Token、输入输出与缓存机制

Token 是什么

调用 AI API 时，模型处理文本的基本单位不是字或词，而是 Token（词元）。这是分词器将原始文本切分后的最小单元，不同语言的 token 密度差异很大。

英文中，1 个 token 大致对应 0.75 个单词或 3–4 个字符；中文则更“密集”，1 个汉字通常占 1–2 个 token；结构化内容如 JSON 或代码，token 消耗更高。例如：

• "Hello world" → 2 tokens
• "你好，世界" → 约 5–7 tokens
• {"key": "value"} → 约 6 tokens

你可以用 OpenAI 的在线 Tokenizer 工具直观查看一段文本的 token 数量。理解这一点很重要——因为所有计费都基于 token，而不是你看到的“字数”。

输入与输出的计费差异

每次 API 调用的费用由两部分组成：

总费用 = 输入 Token 数 × 输入单价 + 输出 Token 数 × 输出单价

输入 Token 包括你发给模型的所有内容：系统提示词（system prompt）、历史对话、当前用户消息，以及粘贴进去的代码或文档片段。

输出 Token 则是模型生成并返回给你的全部内容。

为什么输出通常比输入贵 3–6 倍？因为模型处理输入时可以一次性并行计算，而生成输出必须逐个 token 顺序进行——第 N 个 token 必须等第 N-1 个生成后才能开始。这种“自回归”特性导致输出阶段的计算开销远高于输入。

以 2026 年 4 月的价格为例：

• GPT-5.4：输入 $2.50/M，输出 $15.00/M
• Claude Sonnet 4.6：输入 $3.00/M，输出 $15.00/M
• Gemini 2.5 Flash：输入 $0.30/M，输出 $2.50/M

这意味着，如果你让模型写一篇长文，费用主要来自输出部分。控制 max_tokens 参数能有效避免意外超支。

上下文窗口：别让历史对话吃掉你的预算

上下文窗口是模型单次请求能处理的最大 token 总量（输入 + 输出）。超出后，要么报错，要么自动截断最早的内容。

主流模型的窗口大小：

• GPT-4o / GPT-4o mini：128K
• GPT-5.4 / GPT-5.5：270K
• GPT-4.1 系列、Gemini 2.5、Claude 4.6（正式版）：1M

新手常踩的坑是忽略多轮对话中的上下文累积。AI 本身无状态，客户端（如 Cursor、Claude Code）每次都会把完整对话历史打包发送。随着轮次增加，输入 token 持续膨胀，费用和延迟同步上升。

比如第 10 轮对话可能携带上万 token 的历史，即使你只问了一句“再改一下”。解决办法很简单：

• 定期清空会话（用 /clear 或新建对话）
• 把关键规则写进 system prompt 或项目配置文件（如 .cursorrules），而非依赖对话记忆
• 避免在聊天中粘贴整份代码库

Prompt Caching：复用不变内容，省下 90% 费用

假设你的 system prompt 有 5000 token，每天调用 1000 次，光这部分就要消耗 500 万 token——但内容完全没变。Prompt Caching 就是为解决这种浪费而生。

其原理是：模型处理输入分两个阶段——先做 Prefill（构建内部 KV 缓存），再 Decode（生成输出）。缓存机制会保存 Prefill 阶段的结果。下次请求若前缀一致，直接跳过重复计算，大幅节省时间和费用。

各平台缓存策略对比

OpenAI：自动缓存，无需配置。缓存读取按输入价的 10% 计费（省 90%），写入无额外费用。但匹配逻辑不透明，前缀稍有变动就失效。

Anthropic（Claude）：需手动标记 cache_control。支持两种 TTL：

• 5 分钟：写入成本为原价 125%，读取 10%
• 1 小时：写入成本 200%，读取 10%

只要命中两次以上，总成本就低于不缓存。例如：1.25 + 0.10 = 1.35 < 2.00。

Google Gemini：通过 Context Caching 显式管理，按存储时间计费，门槛较高（最小 32K token）。

缓存命中的关键：严格前缀匹配

缓存从第一个 token 开始逐字比对。只有请求 A 和 B 的开头完全一致，才能命中。因此，把最稳定的内容放前面是最佳实践：

1. System prompt（几乎不变）
2. 项目文档/代码上下文（较稳定）
3. Few-shot 示例
4. 历史对话（缓慢变化）
5. 当前用户消息（每次都变）

Claude 的手动标记示例：

{
  "system": [
    {
      "type": "text",
      "text": "你是一个代码审查助手...[长内容]",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [{"role": "user", "content": "审查这段代码"}]
}

加上 cache_control 后，该块及之前内容会被缓存。

中转站：国内访问的代理方案

中转站是部署在国内的 API 代理服务，帮你转发请求到 OpenAI、Claude 等官方接口。主要用途：

• 解决网络访问问题
• 统一多家模型接口（用 OpenAI 格式调 Claude）
• 可能获得更低价格（批量采购折扣）

计费通常有两种模式：

• 后付费：按实际 token 用量结算，价格约为官方 6–8 折
• 预付费：充值额度，按消耗扣除（注意跑路风险）

使用注意事项

安全：你的 API Key 会经过第三方服务器，选择运营时间长、口碑好的平台。

稳定性：中转站自身可能故障，关键业务建议保留直连方案（配合本地代理）。

价格陷阱：确认 token 计算是否透明，是否支持缓存透传——有些中转站会破坏缓存机制，导致你无法享受折扣。

切换非常简单，只需改 base_url：

client = OpenAI(
    api_key="中转站Key",
    base_url="https://proxy.example.com/v1"
)

Cursor、Claude Code 等工具也在设置中支持自定义 base URL。

费用估算与控制策略

快速估算公式

费用 = (未缓存输入 / 1e6) × 输入单价
     + (缓存命中 / 1e6) × 缓存单价
     + (输出 / 1e6) × 输出单价

例如用 Claude Sonnet 4.6 处理：2000 token 输入（1800 命中缓存）、500 token 输出：

• 未缓存输入：200 × $3.00 / 1e6 = $0.0006
• 缓存命中：1800 × $0.30 / 1e6 = $0.00054
• 输出：500 × $15.00 / 1e6 = $0.0075
• 总计 ≈ $0.0086（约 0.06 元）

降本核心策略

策略	效果	难度
用小模型处理简单任务	节省 80–95%	低
启用 Prompt Caching	节省 50–90%	中
压缩 system prompt	减少固定开销	低
控制输出长度	避免超长回复	低
清空对话历史	防止上下文膨胀	低
批量请求（Batch API）	节省约 50%	中

设置费用告警

• OpenAI：在 platform.openai.com/usage 设置用量上限和邮件提醒
• Anthropic：Console 中配置月度预算
• 中转站：开启余额不足通知

常见问题解答

Q：为什么 Claude Code 越用越慢、越用越贵？
A：对话历史不断累积，每次请求携带的 token 越来越多。定期 /clear 或把关键信息写进 CLAUDE.md。

Q：中转站的 token 计算和官方一致吗？
A：大多数按官方数量计算，但可能有倍率（如 0.8×）。务必确认是否支持缓存透传。

Q：Prompt Caching 需要手动开启吗？
A：OpenAI 自动生效；Claude 需手动加 cache_control；工具如 Cursor 通常已内置处理。

Q：上下文窗口越大越好？
A：不一定。更大窗口意味着更高费用，且模型在超长上下文中对中间内容的注意力会下降（“Lost in the Middle”问题）。按需选择即可。

Q：Claude 的 1M 上下文是正式功能吗？
A：是的，Claude 4.6 的 1M 上下文已于 2026 年 3 月 13 日正式 GA，不再收附加费。

Q：token 超出上下文窗口会怎样？
A：API 返回错误（如 context_length_exceeded），不会自动截断——除非你的客户端做了处理。

总结

• Token 是计费基础，中文约 1–2 token/字
• 输出比输入贵 3–6 倍，因生成过程无法并行
• 上下文窗口 包含输入+输出总和，多轮对话易超限
• Prompt Caching 可省 90% 费用：OpenAI 自动，Claude 需手动标记
• 中转站 解决访问问题，但需警惕安全与价格陷阱

合理利用这些机制，能显著降低 AI 开发成本，避免账单 surprises。