力 力达云
教程聚合APItoken成本国产模型资讯工具关于内测申请
← 返回资讯

输入价与输出价为什么不同？大模型 API 定价结构详解

2026-07-13

大多数开发者在第一次看到 API 价格表时都会注意到一件事：输出 token 的单价明显高于输入 token，通常是 3–5 倍的差距。这不是厂商随意定价，背后有清晰的技术逻辑。

输入与输出的计算量差异

理解这个价差，需要先理解 Transformer 模型的推理机制：

输入阶段（Prefill）： 所有 input token 可以并行处理，GPU 对整段输入一次性计算注意力，效率极高。

输出阶段（Decode/Generation）： 模型逐 token 生成，每生成一个 token 都需要一次完整的前向传播，且必须等待上一个 token 生成完成才能继续——这是串行的、计算密集的过程。

这背后还有一层硬件视角的解释，如果你只记”并行 vs 串行”这半句，遇到要预估显存占用或者排查”长对话越聊越慢”的场景会卡壳。Prefill 阶段 GPU 利用率高，是因为整段输入可以拼成一个大 batch 一次性喂给 GPU，计算是 compute-bound（算力瓶颈），矩阵乘法把 GPU 的算力吃得满满当当。Decode 阶段完全是另一回事：每次只算一个新 token 的注意力和前馈网络，矩阵变成了瘦长的向量运算，GPU 大部分时间其实在等显存把 KV Cache（历史所有 token 的 key/value 张量）搬运到计算单元里，这是 memory-bound（带宽瓶颈）。也就是说，Decode 慢不是因为算得多，而是”算得少但要等得久”——每生成一个 token，都要重新访问一次不断增长的 KV Cache，上下文越长，这个搬运开销就越大，这也是长对话响应会明显变慢的底层原因。理解到这一层你就明白，厂商给输出 token 定高价，本质上是在为这段串行等待时间和显存带宽收费，不是单纯因为”生成”两个字听起来更值钱。

简而言之：生成 1 个输出 token 的计算成本，远高于处理 1 个输入 token。

典型的输入/输出价格倍差

声明：截至 2026-06，以官方为准，具体以各厂商定价页面为准。

价格区间关系常见模式
输出 ÷ 输入通常 3–5 倍
旗舰模型价差可达 4–5 倍
轻量/快速模型价差通常 3–4 倍
推理模型（o系列/R系列）输出（含思考token）可达 10 倍以上

具体各家当前的定价数字，可用 价格对比表 实时查看。

哪种 token 才是成本大头？

这取决于你的业务场景：

业务类型输入占比输出占比成本大头
文档问答 / RAG高（大量上下文）低（简短回答）输入
内容生成（写作/翻译）低高（长文输出）输出
多轮对话客服中（历史累积）中视轮次而定
代码生成中高输出
分类 / 路由中极低（单字/短词）输入

实践启示： 对于输出密集型场景，控制输出长度（如设置 max_tokens、在 prompt 中要求简洁输出）是最直接的省钱手段。

推理模型的特殊情况

以 o 系列、DeepSeek-R1 等推理模型为例，它们在生成最终答案前会产生大量”思考 token”（Chain of Thought 过程），这些思考 token 同样按输出价格计费：

实际输出成本 = (思考 token + 最终答案 token) × 输出单价

因此推理模型的单次调用成本，即使最终给用户看到的答案很短，实际输出 token 消耗也可能是普通模型的数倍到数十倍。

缓存命中对输入定价的影响

部分厂商提供 Prompt Caching 功能，对于重复输入的前缀，命中缓存后的计费通常远低于原始输入价格（约 10%–25%），这实际上是在输入侧提供了折扣通道，但需要主动开启并满足触发条件（如前缀长度要求）。

说白了这个折扣的原理和 KV Cache 是同一件事：既然 Decode 阶段本来就要维护一份 KV Cache 供当前请求使用，那如果两次调用的前缀完全相同（比如同一个 system prompt、同一段几千字的产品文档），厂商就可以把上一次算好的 KV Cache 直接复用，省掉重新做 Prefill 计算的这一步，省下来的算力自然就变成了价格上的折扣。这也解释了为什么 Prompt Caching 对”长且固定的前缀”效果最好——system prompt、知识库背景资料、few-shot 示例这类不常变的内容放在最前面，用户的动态输入放在最后面，才能让缓存命中率最大化；如果你把易变的内容塞在前缀里，哪怕只改了一个字，缓存也会整体失效，白白多花一次 Prefill 的钱。

为什么批量调用能拿到更低价格

如果你翻过官方定价页会发现，不少厂商对”批处理 / 异步”调用给出接近五折的价格，这不是营销噱头，是 GPU 调度上实打实的收益。同步 API 要求请求进来就要立刻处理、立刻返回，厂商必须常年预留出应对流量峰值的显存和算力，大量时段 GPU 其实是在空等下一个请求。批处理允许你把一批不着急要结果的任务——比如离线打标签、批量生成摘要、跑评测集——一次性提交，厂商可以把这批任务塞进 GPU 空闲的时间窗口，甚至攒够一个更大的 batch 再统一做 Prefill，资源利用率因此明显提升，这部分省下来的成本就让利给了你。代价是拿不到实时结果，通常要等几分钟到 24 小时不等，而且大多数批处理接口不支持流式输出。判断标准很简单：业务对时延不敏感（夜间跑数据清洗、周期性生成报告），批处理基本是白捡的折扣；面向用户的实时对话，同步 API 是唯一选项，别为了省钱牺牲响应速度。

我见过的几个算错成本的坑

只算了当轮的输出，忘了历史对话也要按输入计费。 多轮对话没有”记忆”这回事，每一轮你都要把历史消息重新拼进 prompt 发给模型，这些历史消息全部按输入 token 计费。聊到第十轮，输入里可能已经塞进了前九轮的问答，输入成本会随对话轮次线性增长，而不是保持恒定。如果你的产品是长对话客服又不做上下文裁剪或摘要压缩，账单涨得会比预期快很多。

重试逻辑重复计费。 遇到网络抖动或者 5xx 报错做自动重试，很多人的重试代码是把整个请求（连同完整 prompt）原样重发，这意味着一次失败调用会产生两次甚至三次的输入 token 消耗。稳妥的做法是先判断报错类型：4xx（比如参数错误、超出上下文长度）大概率重试也还是失败，不该无脑重试；只有 5xx 或超时这类瞬时故障才值得重试，且建议设重试上限（比如 2 次）配合指数退避，避免一次网络抖动被放大成两三倍账单。

思考 token 没被计入预算。 前面提到推理模型的思考过程按输出价计费，如果做成本预估时只按”最终答案的字数”估算输出 token，却没有给思考 token 留空间，预估值会严重偏低。推理模型场景建议直接按官方文档给出的 max_tokens 上限做保守预估，而不是按你预期的回答长度去估。

自己动手估一次成本

不用记复杂公式，套这个思路自查就够用：

单次调用成本 = 输入token数 × 输入单价 + 输出token数 × 输出单价

举个纯演示用的例子（价格为假设值，不代表任何厂商实际定价，具体请以 价格对比表 为准）：假设输入单价是每百万 token 2 元，输出单价是每百万 token 8 元，一次调用输入 800 token、输出 300 token，这次调用的成本就是 800/1000000×2 + 300/1000000×8 ≈ 0.0016 + 0.0024 = 0.004 元。单次看着微不足道，但如果产品日均调用 10 万次、维持同样的输入输出比例，一天的成本就是 400 元，一个月大概 1.2 万元。这个演算的意义不在于算准某一次调用花了多少钱，而在于提醒你：调用量一旦上量，输出侧哪怕只增加几十个 token 的平均长度，乘以调用次数放大出来的账单差异会很可观——这也是为什么”控制输出长度”是成本优化里性价比最高的一招，而不是去纠结输入侧的 prompt 要不要精简三五个字。

怎么判断自己是输入贵还是输出贵

多数厂商的用量后台会分别列出当期的输入 token 总数和输出 token 总数，不用靠猜。打开账单页，把两个数字分别乘以对应单价，哪边金额大，哪边就是你该优先优化的方向。如果输入远高于输出，大概率是 RAG 场景背景资料塞太多，该做的是精简召回的上下文块数量或者启用 Prompt Caching；如果输出远高于输入，大概率是没有约束生成长度，该做的是加 max_tokens 上限和”简洁回答”的指令。后台数据比你自己拿计算器估算样本更准，做成本优化之前先看一眼这两个数字，别凭感觉猜。

常见问题

能不能让模型输出更少但质量不变？
可以。在 prompt 中明确要求”简洁回答”、“不超过 X 句话”、“只输出 JSON 不要解释”等指令，大多数情况下可以在质量损失可接受的范围内显著减少输出 token。

输入和输出的 token 用同一个 Tokenizer 切分吗？
是的，同一模型的输入和输出使用相同的 Tokenizer，只是计费单价不同。

流式输出（Streaming）会多收费吗？
不会。流式输出只影响响应的交付方式，token 数量和计费方式与非流式完全相同。

延伸阅读：