为什么 API 输出 Token 比输入 Token 贵得多？

如果你仔细看过主流大模型 API 的价目表，会发现输出 Token 的定价往往是输入的 2 到 4 倍。以 OpenAI GPT-4o 为例，2024 年的定价是每百万输入 Token 2.5 美元，输出则是每百万 10 美元；Anthropic Claude 3.5 Sonnet 的输入为每百万 3 美元，输出达到每百万 15 美元。这不是云厂商随意定价，而是底层算力结构的直接映射。

要理解这个价差，得先弄清大模型是怎么“读”和“写”的。

解码的算力账：为什么生成更贵

大语言模型本质上是自回归生成器。处理输入时，模型可以一次性把上千个 Token 并行编码，这个阶段叫 Prefill，算力利用率高，耗时通常在毫秒级。但生成输出时，模型必须逐字解码：每产生一个新 Token，都要把它和之前所有的 Token 一起重新喂给模型，再预测下一个。生成 1000 个 Token 的序列，需要连续进行 1000 次前向传播。

更关键的是，解码阶段通常受内存带宽限制，而非纯算力限制。模型参数太大，每次解码都要从显存往计算单元搬运数据。实际部署中，输入 1000 Token 的 Prefill 可能只需 0.1 秒，而输出 1000 Token 的 Decode 阶段可能要 10 到 20 秒，时间差了两个数量级。云厂商按 Token 收费，本质上是在按算力占用时长收费，输出自然更贵。

限制回答长度：最直接的节流阀

很多开发者忽略了 max_tokens 参数。模型默认可能会生成冗长解释，尤其在客服场景里，一次回答轻松突破 500 个 Token。如果你在系统提示里明确要求“请在 150 字以内回答”，并把 max_tokens 设为 200，直接就能把输出成本砍掉 60% 以上。

一位做电商客服的朋友给我算过账：他们之前让模型自由发挥，平均每次回答 420 个 Token；后来强制要求分点回答且不超过三点，平均输出降到 110 个 Token。按 Claude 3.5 Sonnet 的输出单价计算，单月调用成本从 1.2 万元降到了 3500 元左右。

结构化输出：减少废话和重复

非结构化文本最容易产生“正确的废话”。如果你要的是订单号和收货地址，却任由模型写成散文，不仅输出 Token 多，还得在后端做额外解析。

主流 API 如今都支持 JSON Mode。假设让模型从用户评价里提取情感标签，直接要求输出 JSON，模型会精准地吐出 {“sentiment”: “negative”, “keywords”: ["物流慢"]}，可能只需 30 个 Token。而自由文本回答同样的问题，模型可能先复述原话再下结论，轻松超过 150 个 Token。结构化输出的约束更强，也能减少车轱辘话。

摘要前置：把长上下文挡在门外

处理长文档时，一个常见反模式是把全文一次性塞进 Prompt。假设你有一份 10 万字的法律合同，直接扔给模型做问答，不仅输入 Token 爆炸，输出时模型为了照顾全文，也倾向于给出长篇大论的引用。

更经济的做法是先做一次摘要。用更便宜的模型（如 GPT-4o-mini）把 10 万字压缩成 500 字，再把摘要喂给主力模型做推理。输入侧省了钱，输出侧也因上下文变短减少了解码负担。实际测试中，长文档问答任务里，先摘要再问答的方案总成本通常比端到端直接处理低 40% 到 55%。

流式控制：用户体验与成本的平衡

流式输出（SSE）已经是聊天应用的标配，它能让用户立刻看到第一个字。但从成本角度看，流式真正的价值在于“可中断”。

想象一个多轮对话场景：用户连续发送了两条消息，或者点击了“停止生成”。如果前端没有终止请求，模型会在服务端默默把整段话生成完毕。一个 800 Token 的回答，用户可能只看前 100 个 Token 就翻页了，但你得为剩下的 700 个 Token 买单。接入流式 API 时，一定要在用户发出新请求或点击停止时，立刻调用取消逻辑。某内容平台的工程师告诉我，加上主动取消后，他们的无效输出 Token 减少了约 18%，在日均千万级调用下，这是非常可观的节省。

输出 Token 比输入贵，不是云厂商贪心，而是自回归生成的物理限制。对开发者来说，每一个从模型嘴里“挤”出来的字都有明确代价。限制长度、结构化输出、摘要前置和流式控制，这四招并不复杂，但组合起来往往能把账单砍掉三分之一甚至一半。在大模型应用从 Demo 走向量产的今天，控制输出成本不再是可选优化项，而是决定商业模式能否跑通的关键一环。