只要你仔细看过主流大模型（如 GPT、Claude、Gemini 或 DeepSeek）的 API 定价表，一定会注意到一个高度一致的行业现象：输出 Token（Output Token）的单价，几乎总是输入 Token（Input Token）的 3 到 5 倍。
比如某款旗舰模型的输入价格是每百万 Token 2.5 美元，而一旦模型开始开口回答，输出价格就会瞬间飙升到每百万 Token 10 到 15 美元。
很多刚接触大模型开发的工程师或产品经理会直觉地认为：“是因为模型‘生成’一个词比‘阅读’一个词需要更多的数学计算量（FLOPs）吗？”
答案恰恰相反。从纯粹的数学运算次数来看，模型处理 1 个输入 Token 和生成 1 个输出 Token 所经历的神经网络层数、参数规模和理论计算量几乎是一模一样的。真正让输出 Token 身价暴涨的，是大模型在推理（Inference）阶段底层的硬件执行效率、显存带宽瓶颈、缓存复用机制以及商业调配逻辑。
一、 硬件底层的撕裂：并行的“高铁批发”与串行的“专车零售”
大模型处理一次完整的对话请求，在底层硬件上并不是一个匀速连贯的过程，而是被严格切分为两个物理特性截然不同的阶段：预填充阶段（Prefill / Prompt Phase）与解码生成阶段（Decode / Token Generation Phase）。
这两个阶段对 GPU 的消耗方式，直接决定了输入与输出的成本鸿沟。
1. 输入阶段（Prefill）：喂饱 GPU 的“批发模式”
当你把一段包含 1,000 个 Token 的提示词（Prompt）发送给大模型时，这 1,000 个词在发送瞬间就已经全部确定了。
此时，GPU 会启动并行计算。它只需要将数十 GB 甚至上百 GB 的模型权重参数从高带宽显存（HBM）搬运到计算核心（SRAM）一次，就可以同时对这 1,000 个 Token 进行矩阵与矩阵的相乘运算（GEMM，General Matrix Multiply）。
这就好比一列拥有 1,000 个座位的高铁，一次性装满 1,000 名乘客发车。虽然启动一次高铁的能耗很高，但分摊到每一位乘客头上的时间成本和硬件折旧几乎微不足道。在 Prefill 阶段，GPU 强大的并行计算单元被彻底喂饱，算力利用率极高，此时的系统处于计算密集型（Compute-Bound）状态——只要 GPU 算得够快，吞吐量就能拉满。
2. 输出阶段（Decode）：卡在显存带宽上的“零售模式”
一旦进入生成回答的阶段，情况就急转直下。目前主流的 Transformer 架构大模型都采用自回归（Autoregressive）机制——模型必须先算出第 1 个词，把它拼回到输入里，才能去预测第 2 个词；算出第 2 个词后，才能去预测第 3 个词。
这种严格的先后依赖关系，彻底堵死了“一次性并行生成所有回答”的可能。
为了吐出一段 1,000 个 Token 的回答，GPU 必须老老实实地循环执行 1,000 次前向传播。最致命的问题在于：每生成 1 个新 Token，GPU 都必须把庞大无比的模型完整权重，重新从显存（HBM）读取并搬运到计算核心（SRAM）一遍！
在这个过程中，实际发生的数学运算仅仅是轻量级的“矩阵与向量相乘（GEMV）”。昂贵且强大的 GPU 算力核心在 90% 以上的时间里都处于“无所事事、干等数据从显存搬过来”的闲置状态。这就好比为了运送 1 名乘客，依然得专门发一趟千人编组的高铁，连发 1,000 趟才能运完 1,000 人。
这种现象在计算机体系结构中被称为“内存墙（Memory Wall）”或访存密集型瓶颈（Memory-Bandwidth-Bound）。输出 Token 之所以贵，本质上是因为你在为 GPU 漫长的显存读取等待时间买单。
| 核心对比维度 | 输入阶段（Prefill / 处理输入 Token） | 输出阶段（Decode / 生成输出 Token） |
|---|---|---|
| 任务本质 | 阅读并理解用户已知的上下文 | 逐字预测并生成未知的后续文本 |
| 硬件执行方式 | 整段文本一次性并行计算 | 逐个 Token 循环串行迭代 |
| 底层矩阵运算 | 矩阵与矩阵相乘（GEMM，高吞吐） | 矩阵与向量相乘（GEMV，低吞吐） |
| 核心物理瓶颈 | 算力瓶颈（Compute-Bound）：受限于浮点运算速度 | 访存瓶颈（Memory-Bandwidth-Bound）：受限于显存带宽 |
| GPU 算力利用率 | 极高（接近满载运转） | 极低（计算单元大量时间在等待数据搬运） |
| 单 Token 耗时成本 | 极低（单次权重加载成本被成百上千个 Token 摊薄） | 极高（每生成 1 个 Token 都要独占一次权重加载周期） |
二、 显存刺客 KV Cache：为什么输出越长，服务器越“喘不上气”？
既然输出阶段每次只能生成一个词，那模型在生成第 500 个词的时候，难道要把前 499 个词的特征重新算一遍吗？
为了避免这种灾难性的重复计算，工程师们引入了 KV Cache（键值缓存）技术——把每一个历史 Token 计算出的注意力中间状态（Key 和 Value 向量）直接保存在显存里，用显存空间换取计算时间。然而，正是这个 KV Cache，进一步拉大了输入与输出的成本差距。
1. 输入的 KV Cache 可以“拼单复用”
在真实的商业应用中，成千上万次 API 请求往往共享着一模一样的“前缀”。比如固定的系统提示词（System Prompt）、预设的数十个工具调用定义（Function Calling）、或者一篇长达数万字的企业知识库文档。
大模型服务商通过上下文缓存（Context Caching / Prefix Caching）技术，可以把这部分输入 Token 生成的 KV Cache 直接驻留在显存甚至高速存储池中。当下一个请求带着相同的前缀进来时，GPU 根本不需要重新计算，直接读取缓存即可。一次计算，万次复用，这也是为什么各大厂商对“缓存命中（Cache Hit）”的输入 Token 往往能给出 1 折甚至 0.5 折的白菜价。
2. 输出的 KV Cache 只能“独占且持续膨胀”
相比之下，模型的输出是实时动态生成的，几乎每次请求的结果都不相同，根本无法跨请求直接复用。
更糟糕的是，在 Decode 生成阶段，每吐出 1 个新的输出 Token，显存里不仅要新写入一份 KV Cache，而且此前所有输入和已生成输出的 KV Cache 都必须死死占住显存不放，直到模型吐出结束符（EOS），整段回答彻底完成，这块显存才能被释放回收。
在 AI 服务器中，高带宽显存（HBM）是最昂贵、最稀缺的战略资源。一个请求生成的输出越长、耗时越久，它霸占大容量显存的时间就越长。这会直接导致单台 GPU 服务器能够同时接待的并发用户数（Batch Size）急剧下降。输出 Token 越长，服务器的并发吞吐能力就越低，服务商自然需要通过高单价来弥补并发损失。
三、 看不见的“思考冰山”与商业定价策略
除了底层硬件的物理限制，近年来大模型架构的演进以及服务商的商业运营逻辑，也在不断强化“输入便宜、输出昂贵”的定价结构。
1. 推理模型的“暗流”：思维链（Reasoning Tokens）
随着具备深度思考能力的推理模型成为主流，模型在给出最终的一句话答案之前，往往会在后台先进行长篇累牍的自我推演、假设验证、逻辑反思和纠错。
这些在后台默默生成的成千上万个“思考 Token（Thinking / Reasoning Tokens）”，哪怕在前端界面上被折叠甚至隐藏，在底层硬件上也实打实地经历了完整的、极其昂贵的串行 Decode 阶段，消耗了同等的显存带宽与计算周期。因此，API 服务商毫无例外地将这些隐藏的思考 Token 全部计入输出 Token 账单中。
2. 防范算力挤兑的“价格调节阀”
如果输入和输出一样便宜，会发生什么？大量开发者可能会放任模型生成冗长、啰嗦、甚至陷入死循环的超长文本。由于输出阶段极其消耗 GPU 独占时间，少数失控的长输出请求就会像大货车堵死高速公路一样，迅速耗尽算力池的并发队列，导致其他所有用户的请求出现严重延迟。
将输入定得很便宜、将输出定得很贵，本质上是一种精妙的流量调控信号：
- 廉价的输入鼓励开发者尽可能提供丰富的背景资料（RAG 检索内容、少样本示例 Few-shot Examples、清晰详尽的指令），这不仅只消耗极少的并行算力，还能大幅提升模型回答的准确率。
- 高昂的输出则倒逼开发者在提示词中约束模型的输出格式（如要求返回精简的 JSON、限制字数），让模型“多看少说、言简意赅”，从而最大化整个算力集群的周转效率。
3. 原材料与高附加值成品的商业逻辑
从商业交付的视角来看，输入 Token 是用户塞给模型的“待加工原材料”（比如一篇杂乱无章的会议录音稿、一段报错的源代码）；而输出 Token 则是模型经过深度加工后交付的“高价值智力成品”（比如提炼好的结构化纪要、修复完毕可直接上线的代码）。为高价值的最终交付物支付更高的溢价，也完全契合软件行业的价值定价法则。
四、 破局视角：单价贵 5 倍，但谁才是账单里的真正吞金兽？
理解了“为什么输出比输入贵”之后，我们在实际做 AI 产品架构和成本核算时，却往往会迎来一个反直觉的反转：虽然输出 Token 的单价高高在上，但在绝大多数企业级应用的月度账单里，真正烧钱的大头往往是输入 Token。
原因很简单——总成本 = 单价 × 数量。在真实生产环境中，输入与输出的 Token 数量级是极度不对称的：
- AI 编程助手（Coding Agent）： 为了让你修改一行代码（输出 50 个 Token），IDE 插件可能需要在后台把你整个项目的十几个关联代码文件、依赖树和报错日志全部作为输入塞给模型（输入 50,000 个 Token）。输入与输出的数量比高达 1000 : 1。
- 企业知识库问答（RAG）： 每次用户提问一句话，系统都会从向量数据库里捞出几十段参考文档拼进 Prompt（输入 15,000 个 Token），而模型最终只需要回答一段三百字的结论（输出 400 个 Token）。
- 多轮对话与智能体（Agent）： 大模型本身是没有记忆的。在第 10 轮对话时，你必须把前 9 轮的所有历史对话记录重新作为输入发给模型，导致输入 Token 像滚雪球一样呈指数级膨胀。
在这些高频场景下，哪怕输出单价是输入的 4 倍，可一旦输入数量达到输出的几十甚至上百倍，输入 Token 依然会占到总账单的 70% 到 90% 以上。
真正成熟的 AI 工程团队在优化成本时，从来不会只盯着单价看，而是采取“双管齐下”的工程策略：一方面通过固定 Prompt 前缀结构、全面接入上下文缓存（Context Caching）以及使用精简的上下文压缩技术，把海量的输入成本打下来；另一方面通过严格限制输出 Schema、采用流式截断（Stop Sequences）以及按任务难度分级路由大小模型，杜绝昂贵的输出算力被无意义的废话浪费。看懂每一颗 Token 在 GPU 里的奇幻漂流，才是掌控大模型时代算力经济学的真正起点。
版权属于：soarli
本文链接：https://blog.soarli.top/archives/1188.html
转载时须注明出处及本声明。
