Claude 输入与输出 Token 成本为何相差 5 倍

为什么输出 token 的成本高于输入 token

在当前目录中的所有 Claude 模型里，输出 token 的成本都是输入 token 的 5 倍。原因在于计算方式不同。读取提示词只需对模型执行一次处理。生成回复则需要每生成 1 个 token 执行一次处理，并且每次处理都必须等待前一次处理完成。

价目表中的每一行都采用相同比例，因此选择哪种模型不会改变账单中输出 token 所占的比例。决定这一比例的是工作负载的结构。一个读取 60,000 个 token、生成 800 个 token 的代理步骤，输出成本几乎可以忽略。一个读取 2,000 个 token、生成 12,000 个 token 的起草任务，输入成本几乎可以忽略。下面将根据 Anthropic 公布的 August 2026 费率，分别计算这两种情况。

Prefill 只运行一次，解码每个 token 运行一次

推理服务器分两个阶段处理请求，两个阶段的成本差异很大。Prefill 读取提示词，解码生成回复。

Prefill 一次处理完整提示词。每个提示词 token 都在同一次前向传播中进入网络，因此注意力和前馈计算会变成少量大型矩阵乘法，每次覆盖数千个 token。模型权重从内存中读取一次，就能服务整个提示词。加速器的矩阵计算单元会持续繁忙，因此 Prefill 受计算能力限制：瓶颈是芯片执行矩阵乘法的速度。

解码无法采用这种方式，因为 token 2 依赖 token 1。模型刚生成的 token 会成为下一步的输入，因此这些步骤无法同时运行。每个输出 token 都需要单独进行一次前向传播，而每次传播都要从高带宽内存中读取完整的模型权重，才能生成一个 token。因此，解码受内存带宽限制：瓶颈是权重移动的速度，而不是矩阵乘法的速度。Prefill 中读取一次权重即可处理完整提示词；解码中相同的权重传输量只能生成一个 token。

服务系统通过批处理来缓解这一问题。多个请求同时进行解码，因此读取一次权重，就能为批次中的每个请求各生成一个 token。这正是解码仍然可行的原因。瓶颈再次转向内存。每个正在处理的请求都会占用一个 KV cache（key/value cache，即截至当前每个 token 的已存储注意力状态）。该缓存会随着生成的 token 数量增加而增长；当它占满加速器后，批次就无法继续扩大。

这些因素无法给出精确数字，因此不应将 5x 理解为经过测量的硬件比例。这是 Anthropic 设定的价格，依据的是上述差异。你可以自行验证的是趋势，整个过程大约需要一分钟。

自行测量输入和输出差值

在任意 Ubuntu 主机上安装这些工具：

sudo apt update && sudo apt install -y curl jq moreutils

现在发送一条简短提示，要求返回较长的答案，并为每一行加上到达时间。

curl -sN https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-5","max_tokens":1000,"stream":true,
       "messages":[{"role":"user","content":"Count from 1 to 300, one number per line."}]}' \
  | ts -s '%.s'

ts -s 会为每一行添加自命令开始以来经过的秒数。输出中有两点值得关注。第一行 content_block_delta 的时间就是首 token 延迟，所有预填充都在这段时间内完成。此后的每一行都是一次小规模解码步骤，时间戳会持续增加，直到 message_stop 到达。

现在反转这种形状。在提示中放入一篇较长的文档，并将答案限制为几个 token。

curl -sN https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d "$(jq -n --rawfile doc ./long-document.txt \
       '{model:"claude-sonnet-5", max_tokens:16, stream:true,
         messages:[{role:"user", content:("Answer in one word. Is this document about networking?\n\n" + $doc)}]}')" \
  | ts -s '%.s'

第一个时间差比使用简短提示时更长，因为预填充需要读取更多文本。它到达后，响应几乎立即结束，因为只剩几个 token 需要解码。输入了数万个 token，但时钟几乎没有变化。输出了几百个 token，而时钟全程都在运行。

每个非流式响应都会以计费所依据的数字结尾。

{
  "usage": {
    "input_tokens": 41283,
    "output_tokens": 6,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 0
  }
}

记录每个请求的全部 4 个字段。output_tokens 包含扩展思考，因此模型在回答前进行思考时，这部分思考会按输出速率计费。要在发送提示前估算费用，POST /v1/messages/count_tokens 接受相同的请求正文，在不运行模型的情况下返回 {"input_tokens": N}，且不收费。API 中免费使用的部分不止这一项；在为第一个项目编制预算前，建议查看 Claude API 中哪些部分不会向您收费。

截至 2026 年 8 月 Claude 每百万 token 的收费

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (to 31 Aug)",
    "input_usd": 2,
    "output_usd": 10,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (from 1 Sep)",
    "input_usd": 3,
    "output_usd": 15,
    "output_multiple": 5
  },
  {
    "label": "Opus 5",
    "input_usd": 5,
    "output_usd": 25,
    "output_multiple": 5
  },
  {
    "label": "Fable 5",
    "input_usd": 10,
    "output_usd": 50,
    "output_multiple": 5
  }
]

最后一列是输出量除以输入量，每一行都显示为 5。Haiku 4.5 的输入费用为 $1，输出费用为 $5。Opus 5 的输入费用为 $5，输出费用为 $25。Fable 5 的费用最高，输入为 $10，输出为 $50；在否定这一最高档价格前，建议先阅读Fable 5 这些费率能带来什么。向上选择更高档位时，输入和输出费用会按相同比例增加，因此总费用会变化，但输入与输出的分配比例保持不变。

Sonnet 5 出现两次，因为其优惠费率有期限。到 2026 年 8 月 31 日为止，输入费用为 $2，输出费用为 $10。从 2026 年 9 月 1 日起，适用输入费用 $3 和输出费用 $15 的标准费率，输入和输出两项都高出 50%。下面的所有示例都使用 8 月费率。

费率会变化，不应在本页查询最新费率。claude.com/pricing 才是权威来源。价格变化不会影响计算方法。

价格表不会显示一个需要注意的事项。Anthropic 的文档指出，Claude 4.7 及更高版本的模型使用了新的 tokenizer。与 Sonnet 4.6 及更早版本所用的 tokenizer 相比，它处理相同文本时生成的 token 大约多 30%。如果只比较每百万 token 的价格，较新的模型会显得更便宜，因为同一份文档在该模型中会产生更多 token。应按完成任务的成本进行比较，并使用实际计划采用的模型，统计真实提示词的 token 数量。Claude 的一百万 token 在实际文本中相当于多少介绍了这部分 token 在实际使用中的规模。

何时输出成本会开始主导账单？

当输出价格是输入价格的 5 倍时，盈亏平衡点很容易记住。设输入 token 数为 I，输出 token 数为 O。输入成本为 I，输出成本为 5 乘以 O。当 5 乘以 O 大于 I 时，输出成本超过总支出的一半，此时输入与输出的 token 比例为 5:1。

因此，如果提示词长度超过回复长度的 5 倍，输入成本占比更大。低于这个比例时，输出成本占比更大。

[
  {
    "label": "100:1",
    "input_share_pct": 95.2,
    "output_share_pct": 4.8
  },
  {
    "label": "75:1",
    "input_share_pct": 93.75,
    "output_share_pct": 6.25
  },
  {
    "label": "20:1",
    "input_share_pct": 80,
    "output_share_pct": 20
  },
  {
    "label": "10:1",
    "input_share_pct": 66.7,
    "output_share_pct": 33.3
  },
  {
    "label": "5:1",
    "input_share_pct": 50,
    "output_share_pct": 50
  },
  {
    "label": "1:1",
    "input_share_pct": 16.7,
    "output_share_pct": 83.3
  },
  {
    "label": "1:6",
    "input_share_pct": 3.2,
    "output_share_pct": 96.8
  }
]

在 100:1 时，输出成本占总支出的 4.8%，此时只有压缩提示词值得投入精力。在 5:1 时，两者成本相等。在 1:6 时，输出成本占 96.8%，提示词成本几乎可以忽略。大多数人都会错误估计自己的比例，因此在优化前，先从日志中提取实际数据。

代理工作负载：输入长上下文，输出短答案

执行一个检索代理步骤：输入 60,000 个检索文档和对话历史 token，输出 800 token 的答案。两者比例为 75 比 1。对于任何先读取、再写入的任务，这都很正常。

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.06,
    "output_cost": 0.004,
    "total_cost": 0.064
  },
  {
    "label": "Sonnet 5 (Aug)",
    "input_cost": 0.12,
    "output_cost": 0.008,
    "total_cost": 0.128
  },
  {
    "label": "Opus 5",
    "input_cost": 0.3,
    "output_cost": 0.02,
    "total_cost": 0.32
  },
  {
    "label": "Fable 5",
    "input_cost": 0.6,
    "output_cost": 0.04,
    "total_cost": 0.64
  }
]

在每个模型上，输出都占该调用的 6.25%，因为整个价格表中的比例都是固定的。在 8 月费率下，该调用使用 Opus 5 的成本为 $0.32，使用 Sonnet 5 的成本为 $0.128，使用 Haiku 4.5 的成本为 $0.064。每天在 Opus 5 上执行 200 个此类步骤，成本为每天 $64。

看到这种拆分后，优化重点就很明确了。将答案从 800 token 减少到 400 token，只能节省约 3% 的调用成本。从提示中移除 20,000 个过时上下文 token，则可节省约三分之一。对于读取量较大的代理，严格限制输出长度几乎是在浪费精力。代码代理的 token 实际用在哪里详细说明了这些提示内容的来源。

生成任务：短提示词，长草稿

现在反过来看这种结构。提示词为 2,000 个 token，草稿为 12,000 个 token，比例为 1:6。

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.002,
    "output_cost": 0.06,
    "total_cost": 0.062,
    "batch_total_cost": 0.031
  },
  {
    "label": "Sonnet 5 (Aug)",
    "input_cost": 0.004,
    "output_cost": 0.12,
    "total_cost": 0.124,
    "batch_total_cost": 0.062
  },
  {
    "label": "Opus 5",
    "input_cost": 0.01,
    "output_cost": 0.3,
    "total_cost": 0.31,
    "batch_total_cost": 0.155
  },
  {
    "label": "Fable 5",
    "input_cost": 0.02,
    "output_cost": 0.6,
    "total_cost": 0.62,
    "batch_total_cost": 0.31
  }
]

输出成本占本次费用的 96.8%。Opus 5 每份草稿的成本为 $0.31，而 Haiku 4.5 为 $0.062。这 5 倍的差距几乎完全来自输出部分，而这正是低价模型最能帮您节省成本的地方。

最后一列显示的是通过 Batch API 执行同一任务的成本。该 API 将输入和输出成本都降低 50%。Opus 5 每份草稿的成本降至 $0.155。Batch 会在 24 小时内返回结果，而不是立即返回，因此适合夜间生成报告和批量分类。不适合需要人员等待结果的任务。

在这里，模型路由可以发挥作用；在代理步骤中则通常无法发挥同样的作用。如果任务中较长的部分是机械性的，例如重新格式化文本，或扩展您已经批准的大纲，那么低价模型生成这些 token 的成本只有五分之一。在 Opus、Sonnet 和 Haiku 之间进行选择介绍了实际的质量分界线。

缓存只降低输入成本，而且只降低输入成本

提示缓存会将提示词的前缀存储在服务器上。再次读取这些内容时，按输入费率的一部分计费。截至 2026 年 8 月，相关倍率为：写入 5 分钟缓存时按基础输入费率的 1.25x 计费，写入 1 小时缓存时按 2x 计费，命中缓存并读取时按 0.1x 计费。

输出不包含在其中。不存在缓存输出。模型每次生成的每个 token 都按完整输出费率计费，无论提示词中有多少内容命中缓存。

以 Opus 5 执行相同的代理步骤，其中 60,000 个输入 token 中有 55,000 个来自热缓存。

[
  {
    "label": "No cache",
    "input_cost": 0.3,
    "output_cost": 0.02,
    "total_cost": 0.32
  },
  {
    "label": "55k prefix cache read",
    "input_cost": 0.0525,
    "output_cost": 0.02,
    "total_cost": 0.0725
  }
]

这次调用的费用从 $0.32 降至 $0.0725。输出费用没有变化：之前为 $0.02，之后仍为 $0.02。缓存会降低账单，并改变费用构成。输出曾占该调用费用的 6.25%。现在已超过四分之一，因此下一步值得优化的部分也会改变。

首次调用需要支付写入费用。写入 5 分钟缓存的费用是基础输入费用的 1.25x，因此命中一次后即可回本。写入 1 小时缓存的费用是 2x，因此需要命中两次才能回本。写入和读取倍率，以及缓存何时不再划算详细说明了这部分计算过程。

您可以控制的 4 个杠杆

1. 将 max_tokens 设置为您的 p95 输出长度，而不是模型上限。
2. 将冗长步骤路由到更便宜的模型。
3. 将无人等待的任务批量处理。
4. 删除会增加回复长度的指令。

max_tokens 是硬上限。单独将它设置得很高不会产生额外费用，因为计费只针对实际生成的 token，从不针对上限计费。宽松的上限只会取消对异常冗长回复的限制。从日志中提取 output_tokens 分布，将上限设置为略高于第 95 百分位，并在代码中处理 stop_reason: "max_tokens"，例如继续生成回复或重试。检测到的截断，其成本低于支付并丢弃一段 4,000 token 的冗长回复。扩展思考也会计入 output_tokens，因此应根据相同的数据设置这部分预算。

当步骤的昂贵部分是处理量而不是判断时，路由才有效。让强模型负责决策，再将文字生成交给更便宜的模型。先在自己的评估集上测量路由后的版本，因为需要尝试两次的廉价模型，成本可能高于一次昂贵的尝试。

批处理是唯一能降低输出费用的杠杆。双方费用均可享受 50% 折扣，结果在 24 小时内返回，并且任何按计划执行的任务都符合条件。

最后一个杠杆经常被忽略。“务必详尽”和“解释你的推理过程”之类的短语，会增加您今后每次调用的输出长度。应改为直接指定所需格式，例如“最多用三个句子回答”，或“只返回 JSON 对象，不要添加前言”。系统提示每次回复增加 300 个 token，其成本是提示本身增加相同 300 个 token 的 5 倍。控制持续运行的 agent 成本介绍了监控方面的内容；在您花一周调整按 token 计费的支出之前，最好先确定对于您的使用模式，API 还是固定订阅更便宜，因为订阅可能已经覆盖了这些费用。对于主要由一名开发者使用的情况，通常需要确认 Claude Pro 每月 $20 的费用及其使用限制是否足以覆盖工作量。如果您已经在会话中途触及这些限制，应先确定您正在等待哪个使用窗口，因为后续的解决方案可能是使用更小的模型、减少上下文、购买额外使用额度，或将这部分工作转移到按量计费的 API。如果按量计费的 API 最终更适合这类工作，降级到更低级别的套餐或取消订阅不会影响您已经支付的当月套餐，因此切换不会产生退出成本。如果您比较的是 ChatGPT 套餐，而不是按量计费的 API，并列比较两种订阅套餐的价格可以显示哪一种对编码工作更便宜。如果比较对象是团队而不是单个开发者，请注意，Claude Enterprise 将按席位收费与按相同 API 费率计量的 token 结合起来，因此本页介绍的每个杠杆仍适用于账单中按量计费的部分。

FAQ

为什么输出 token 比输入 token 更贵？

生成输出 token 需要更多的加速器时间。处理 prompt 时，模型会在一次前向传播中处理全部内容，因此读取一次模型权重就能覆盖数千个 token，此时硬件瓶颈是矩阵乘法吞吐量。生成回复时，模型一次只生成一个 token，每个 token 都需要单独进行一次前向传播，并再次读取完整的模型权重，因此硬件瓶颈变成了内存带宽。Anthropic 在当前完整产品目录中统一按输入价格的 5 倍收取输出费用，产品范围从 Haiku 4.5 到 Fable 5。

prompt caching 会降低输出 token 的价格吗？

不会。Prompt caching 仅适用于输入。截至 August 2026，缓存读取费用是基础输入价格的 0.1x；缓存写入费用在 5 minute 有效期内是 1.25x，在 1 hour 有效期内是 2x。无论缓存执行了什么操作，每次调用的输出都会按完整价格计费。这就是缓存不仅会改变账单金额，也会改变账单构成的原因：输入侧成本下降后，输出就成了最值得优化的部分。

如果回复很短，较高的 max_tokens 会增加费用吗？

不会。您只需为模型实际生成的 token 付费，因此 max_tokens 是上限，不是预留量。但它仍然很重要，因为它是限制失控回复的唯一硬限制。将其设置为略高于观测到的 output_tokens 的第 95 百分位，然后在代码中处理 stop_reason: "max_tokens"，不要直接发布被静默截断的答案。

如何计算自己的输入与输出 token 比例？

从每个响应的 usage 对象中记录 input_tokens、output_tokens、cache_read_input_tokens 和 cache_creation_input_tokens，然后计算一周内的总量比例。如果输入与输出的比例高于 5:1，成本主要来自 prompt，因此应缓存稳定部分并精简其余内容。如果比例低于 5:1，成本主要来自回复，因此应限制回复长度，并将生成大量输出的步骤迁移到更便宜的模型或 Batch API。