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

大模型API按Token计费，输入和输出分开定价，输出单价普遍高于输入，这不是厂商随意加价，而是解码阶段的计算结构决定的。只要模型采用自回归生成，输出侧的单位计算成本就高于输入侧；反过来，如果某类接口不经过生成、只做分类或向量化，就不会出现这种价差。理解这个机制，是判断API报价是否合理的前提。 Token是文本切分后的计量单位，不等于汉字数，也不等于英文单词数。中文里一个词可能对应一到两个Token，英文一个单词可能被切成多个Token，同一段文字在不同分词器下算出的Token数并不相同。计费看的是Token数量，不是字符数，这也是为什么同样长度的提示词在不同模型上报价不同。多数API的价格表以每百万Token为单位标价，输入和输出分两行列出，有的还会按缓存命中与否再分档。 输入Token指发送给模型的内容，包括系统提示词、历史对话、检索到的文档片段和用户提问。输出Token指模型生成并返回的内容，包括回答正文和推理过程中产生的可见文本。两者在账单里分列，单价不同，计费口径也不一样。有的平台还会细分缓存写入、缓存读取、批量推理等档位，价格依次递减，看清楚价格表的维度比记住一个单价更重要。 输入Token虽然单价低，但不等于没有成本。模型即使不生成新内容，也要把输入完整编码一遍，建立注意力所需的键值状态，长上下文场景下输入侧的显存占用和计算量同样可观，只是它可以通过并行被摊薄。所以输入侧的成本优化重点是减少冗余上下文，而不是单纯压低单价。 价差的第一层原因是预填充与解码的不对称。输入阶段是预填充，所有Token可以并行送入GPU，运算以大规模矩阵乘法为主，硬件利用率高，单位Token耗时短。输出阶段是解码，模型必须一个Token一个Token地生成，每个新Token都依赖前面所有Token的结果，这个串行过程让GPU很难满载，单位Token的耗时和能耗明显更高。这是输入输出价差最根本的结构性来源。 KV缓存是价差的第二层来源。输入阶段建立的键值缓存会被输出阶段反复读取，每生成一个Token都要读写整个缓存，显存带宽成为主要瓶颈。上下文越长，输出侧这块开销越大，而输入侧的缓存建立过程可以一次性并行完成，边际成本相对可控。所以长上下文场景下，输出单价与输入单价的差距往往更明显。 批处理效率的差异进一步放大了价差。输入可以大批量并行处理，同一批请求的预填充互不等待，吞吐高；输出只能按序列推进，同一批次内不同请求的生成节奏不一致，调度复杂，实际吞吐低于输入。同样的算力投入，能产出的输出Token数少于输入Token数，单价自然更高。这不是运营策略，而是推理引擎的调度特性。 从商业定价逻辑看，输出Token是模型产出的最终结果，用户为价值付费；输入Token更多是上下文成本。厂商把输出单价定得更高，也是在为生成阶段的算力稀缺性定价。不同厂商的输入输出价差倍数并不一样，取决于模型架构、推理引擎的优化程度和商业定位：批处理和缓存优化得越好，输出侧单位成本被摊得越薄，价差可能收窄；注意力实现效率低、显存带宽受限的模型，价差更大。比较不同厂商时，不能只看价差倍数，还要结合自己的使用模式。 中转聚合服务在计费上通常透传上游模型的价格结构，输入和输出分别计价，区别在于提供统一接口、Key管理和多模型路由。不同模型的费率在同一个后台呈现，方便横向比较和切换。至于具体的费率、折扣和套餐，以服务方的官方说明为准。选择中转服务时，要确认它是否完整披露输入输出两栏价格，而不是只给一个笼统的单价。 有几个容易被忽略的计费细节。系统提示词和多轮历史在每次调用时都会计入输入Token，长对话的成本会随轮次累积，而不是只算最新一句。流式输出和非流式输出按实际生成的Token数计费，没有差别。部分平台对缓存命中的输入Token给出折扣，复用重复的提示词前缀可以降低输入侧成本，输出侧一般没有类似机制，因为生成内容难以预先复用。 想控制成本，先分清开销落在输入侧还是输出侧。压缩系统提示词、控制历史轮数、精简检索内容，主要省的是输入；限制最大输出长度、要求模型回答简洁，主要省的是输出。两类优化的杠杆不同，混为一谈容易抓错重点。实际降本时，应该先统计自己的输入输出Token比例，再决定往哪一侧投入优化精力。 判断一个API是否划算，不能只看单一价格，要同时看输入单价、输出单价、是否区分缓存命中，以及自身应用的输入输出比例。输出密集型的应用，比如长文生成和代码生成，对输出单价更敏感；输入密集型的长文档处理、检索问答，则对输入单价更敏感。计费透明是选择中转服务的基本要求，用户应能在后台看到每次调用的输入、输出Token数和对应费用，账单可追溯，价格与折扣以服务方官方说明为准。