大模型 API 的 Token 是怎么收费的？为什么输出 Token 单价比输入贵？

大模型 API 的 Token 计费按输入与输出分开计价，一次调用的费用等于输入 token 数乘输入单价，加上输出 token 数乘输出单价，两档单价通常不在同一水平。这个口径只适用于按 token 计量文本进出的对话与补全接口，不适用于按张、按秒、按次计费的图像、语音、视频接口，也不适用于包月包量的套餐形态，具体价差倍数以各平台官方价目为准。 Token 不是字，也不是词，而是模型分词器切出的最小计费单位。同一段内容里，中英文比例、标点、空格、换行、代码符号的切法都不同，token 数因此不同，用字符数乘一个固定系数去估算账单一定会有偏差。做预算之前，应先用目标模型对应的分词器对真实业务语料做抽样统计，再按调用量外推。 一次请求的账单至少由两段构成：提示词侧的输入 token 和模型生成侧的输出 token。开启流式输出时，计费仍按最终生成的总 token 结算，中途断开连接不会退还已经生成的部分。如果接口支持工具调用或结构化输出，函数名、参数和 JSON 结构同样按输出侧 token 计入。 输出更贵的第一个结构性原因，是输入侧可以并行、输出侧只能串行。预填充阶段能够一次性并行处理整段提示词，算力密度高、吞吐大；解码阶段每生成一个 token 都要完整走一遍前向计算，再把新 token 追加进上下文继续算下一个。生成长度越长，串行步数越多，占用的 GPU 时间越长。 解码阶段的瓶颈往往不是算力，而是显存带宽。每一步解码都要把模型权重和 KV Cache 从显存读出，计算量不大但访存量大，计算单元有大量时间在等数据。上下文越长，KV Cache 占用越大，单 token 的解码代价越高，这就解释了为什么长输入叠加长输出的组合最费钱。 缓存命中是输入侧唯一能显著压价的结构性因素。固定系统提示词、长文档、多轮对话历史这类重复前缀如果被平台缓存，命中部分通常按更低的输入单价结算，只有未命中的新内容按标准输入价计费。因此同一份长提示词反复调用，成本曲线并不随调用次数线性增长。 商业定价也在放大价差：输出长度由模型采样决定，调用方事先无法精确控制。输入长度可以预估、可以排队、可以批处理，输出却要保证首 token 延迟，平台必须为长度长尾预留容量和调度余量。这部分容量风险，最终被折算进输出单价里。 通过 API 中转或聚合平台接入时，账单口径由中转方定义，可能和上游并不完全一致。需要问清四件事：输入输出的计费倍率如何设定，缓存命中的折扣是否透传，推理类模型产生的思考 token 计入输入还是输出，请求失败、超时、被限流拒绝时是否计费。这四项口径不同，实际支出可能差出明显一截。 估算月成本，正确做法是先统计业务中真实的输入输出 token 比例，再分别乘对应单价。客服问答通常是长输入短输出，输入侧主导成本；摘要、写作、代码生成这类任务输出占比高，成本更受输出单价牵动。只拿一个笼统的单价横向比价，结论往往是错的。 按 token 计费与限流策略天然绑定。平台一般用每分钟请求数、每分钟 token 数或并发数来限制调用，超限请求被拒通常不产生费用，但会直接影响业务可用性。做成本控制时不能只看单价，还要看是否支持多模型路由、上游故障时能否自动切换，以及 Key 的额度与权限能否按项目隔离，便于对账与止损。 核对账单要落到调用日志上。按 Key 或按项目记录每次请求的输入、输出 token 数，与平台账单逐日比对，才能发现缓存是否真正生效、重试是否被重复计费、流式中断是否按已生成部分结算。缺少这层对账，任何单价优化都只是估算，无法验证。 判断一次调用是否划算，应看单位任务成本而不是单位 token 单价。同一个任务用低单价模型输出两三倍长度的 token，总价可能更高；用单价较高的模型一次答对，反而更省。把评测锚定在任务完成度和总 token 消耗上，比单纯比较输入输出单价更接近真实成本。