https://www.knightli.com/tags/%E6%88%90%E6%9C%AC%E5%88%86%E6%9E%90/ Recent content in 成本分析 on KnightLi的博客 Hugo -- gohugo.io zh-cn Sat, 25 Apr 2026 08:44:32 +0800 https://www.knightli.com/2026/04/25/llm-token-pricing-principles/ Sat, 25 Apr 2026 08:44:32 +0800 https://www.knightli.com/2026/04/25/llm-token-pricing-principles/ <p>大模型 API 的计费方式里，最容易让人困惑的一点，就是为什么几乎所有平台最后都会落到 <code>token</code> 这个单位上：<strong>大模型为什么按 token 收费，而且不同 token 还会有不同价格。</strong></p> <p>很多人刚接触模型 API 时，最容易困惑的不是模型能力，而是账单。明明只问了几个问题，为什么费用会涨得这么快？为什么输入便宜、输出更贵？为什么上下文一长，成本就开始明显失控？</p> <p>如果把这件事讲简单一点，可以先记住一句话：<strong>模型收费，买的不是“一次回答”，而是整段推理过程中消耗的计算与带宽资源。</strong></p> <h2 id="1-什么是-token">1. 什么是 token </h2><p>在大模型计费里，<code>token</code> 不是“字数”也不是“单词数”，而是模型处理文本时使用的切分单位。</p> <p>它可能是：</p> <ul> <li>一个汉字</li> <li>一个英文单词的一部分</li> <li>一个标点符号</li> <li>一小段常见词组合</li> </ul> <p>所以 API 平台通常不会按“每句话”或“每次请求”收费，而是按模型实际读入和生成的 token 数量收费。<br> 这比按请求次数计费更合理，因为同样是一次请求，可能只输入 20 个字，也可能塞进去 20 万 token 的上下文，两者消耗完全不是一个量级。</p> <h2 id="2-为什么输入和输出要分开定价">2. 为什么输入和输出要分开定价 </h2><p>现在大多数模型 API，都会把价格拆成两部分：</p> <ul> <li>输入 token 价格</li> <li>输出 token 价格</li> </ul> <p>而且常见情况是：<strong>输出 token 比输入 token 更贵。</strong></p> <p>原因并不难理解。</p> <p>模型处理输入时，本质上是在“读”和“编码”已有内容；但生成输出时，它需要一步一步预测下一个 token，再继续预测下一个 token。这个过程不只是读取，而是持续进行推理和采样，所以通常更耗算力。</p> <p>你可以把它粗略理解成：</p> <ul> <li>输入：像把材料递给模型</li> <li>输出：像让模型现场写答案</li> </ul> <p>“现场写”的计算成本，通常比“把材料读一遍”更高，所以输出价格更贵是很常见的设计。</p> <h2 id="3-为什么上下文越长费用越容易失控">3. 为什么上下文越长，费用越容易失控 </h2><p>很多人以为自己只是在“多贴一点背景资料”，但从模型账单的角度看，这件事的影响往往比想象中大。</p> <p>原因在于：<strong>模型每次调用时，通常都要重新处理当前请求里带进去的整段上下文。</strong></p> <p>也就是说，如果你当前请求里包含：</p> <ul> <li>系统提示词</li> <li>历史对话</li> <li>工具返回结果</li> <li>长文档片段</li> <li>代码文件内容</li> </ul> <p>这些内容都会一起进入输入 token 计费。</p> <p>所以真正让账单变大的，往往不是最后那一句提问，而是它前面拖着的一大串上下文。<br> 当对话轮数增加、工具调用变多、历史消息不断回灌时，token 成本就会被一轮轮放大。</p> <h2 id="4-工具调用为什么特别容易涨-token">4. 工具调用为什么特别容易涨 token </h2><p>在 Agent、代码助手、工作流自动化这类场景里，token 消耗通常比普通聊天高得多。</p> <p>问题不只是“模型回答了一段话”，而是整个流程里会不断出现这些内容：</p> <ul> <li>读文件</li> <li>看日志</li> <li>调接口</li> <li>返回 JSON</li> <li>执行工具结果再回填给模型</li> </ul> <p>每一次工具调用的结果，只要被重新塞回下一轮上下文，就会继续变成新的输入 token。</p> <p>这就是为什么很多开发者会发现：<br> <strong>不是模型本身单价特别离谱，而是工作流把 token 账单一层层叠上去了。</strong></p> <p>例如一个编码 Agent 连续做下面这些事：</p> <ol> <li>读取项目结构</li> <li>打开几个源码文件</li> <li>跑一次测试</li> <li>把报错日志喂回模型</li> <li>再读取更多相关文件</li> </ol> <p>每一步都可能让后续请求背着更长的上下文继续跑。这样即使单价不变，总账单也会很快增长。</p> <h2 id="5-为什么同样是模型价格会差很多">5. 为什么同样是模型，价格会差很多 </h2><p>不同模型的 token 价格差异，背后通常不只是“厂商想卖贵一点”，而是和几个因素直接相关：</p> <ul> <li>模型规模</li> <li>推理效率</li> <li>上下文长度</li> <li>部署成本</li> <li>目标市场</li> </ul> <p>模型越大、激活参数越多、推理链路越复杂，单次生成一个 token 的成本通常就越高。<br> 如果模型还支持超长上下文、复杂推理、工具调用优化，那它的基础设施压力也会进一步增加。</p> <p>所以定价本质上是在覆盖几类成本：</p> <ul> <li>GPU / 加速卡资源</li> <li>显存占用</li> <li>推理延迟</li> <li>网络与服务稳定性</li> <li>峰值并发能力</li> </ul> <p>便宜模型不一定差，贵模型也不一定适合所有场景。很多时候价格差，反映的是“这类能力大概值多少基础设施成本”。</p> <h2 id="6-为什么缓存输入会更便宜">6. 为什么缓存输入会更便宜 </h2><p>不少模型平台现在会提供：</p> <ul> <li>cached input</li> <li>prompt caching</li> <li>prefix caching</li> </ul> <p>这类能力的共同思路是：如果一大段输入已经算过，不要每次都从头按原价重算。</p> <p>比如一个固定 system prompt、固定工具说明、固定长文档前缀，如果每轮都完全重复发送，平台就有机会把其中一部分计算缓存下来。这样同样是输入 token，缓存命中的部分就可以按更低价格计费。</p> <p>这也解释了为什么很多 API 价格页会出现三档甚至更多价格：</p> <ul> <li>普通输入</li> <li>缓存输入</li> <li>输出</li> </ul> <p>它们反映的不是文字内容不同，而是底层计算是否可以复用。</p> <h2 id="7-便宜-token为什么不等于总成本更低">7. “便宜 token”为什么不等于“总成本更低” </h2><p>很多人看到某个模型“每百万 token 超便宜”，第一反应是总成本一定更低。实际上不一定。</p> <p>因为总账单大致等于：</p> <p><strong>token 单价 × 实际消耗量</strong></p> <p>而实际消耗量又会被很多因素放大：</p> <ul> <li>提示词写得太长</li> <li>历史消息不清理</li> <li>工具结果回填过多</li> <li>输出太啰嗦</li> <li>一个任务反复重试</li> </ul> <p>所以真正决定账单的，通常不是单价一个变量，而是：</p> <ul> <li>模型单价</li> <li>每轮输入长度</li> <li>每轮输出长度</li> <li>调用次数</li> <li>工作流设计</li> </ul> <p>这也是为什么“低单价模型”在某些 Agent 任务里，最后总费用仍然可能不低。因为它可能需要更多轮交互、更多补充上下文、更多失败重试。</p> <h2 id="8-开发者该怎么估算-token-成本">8. 开发者该怎么估算 token 成本 </h2><p>如果你想在项目里更稳地控制预算，可以先用一个很朴素的估算方式：</p> <ol> <li>统计平均每次请求的输入 token</li> <li>统计平均每次请求的输出 token</li> <li>估算一个任务会调用多少轮</li> <li>再乘上对应模型单价</li> </ol> <p>举个思路上的例子：</p> <ul> <li>每轮输入 <code>8k tokens</code></li> <li>每轮输出 <code>1k tokens</code></li> <li>一个任务跑 <code>10</code> 轮</li> </ul> <p>那它真正消耗的就不是“一次问答”，而是：</p> <ul> <li>输入约 <code>80k tokens</code></li> <li>输出约 <code>10k tokens</code></li> </ul> <p>如果中途还有日志、工具结果、文件内容不断追加，总量还会继续上升。</p> <p>所以做预算时，最好不要只看单轮，而要看<strong>一个完整任务闭环</strong>到底会吃掉多少 token。</p> <h2 id="9-怎么实际控制账单">9. 怎么实际控制账单 </h2><p>如果你已经在用 API 或 Agent，下面这些做法通常最有效：</p> <ul> <li>缩短 system prompt，避免重复废话</li> <li>定期裁剪历史消息</li> <li>工具返回结果只保留必要字段</li> <li>长文档先检索，再喂局部片段</li> <li>控制输出长度，避免模型无上限展开</li> <li>对高价值任务用贵模型，低价值任务用便宜模型</li> </ul> <p>很多时候，省钱最有效的方式不是一味换更便宜的模型，而是先把工作流里无意义的 token 消耗砍掉。</p> <h2 id="10-这件事真正该怎么理解">10. 这件事真正该怎么理解 </h2><p>大模型 token 定价，说到底是在给“模型读了多少、想了多少、写了多少”计费。</p> <p>它不是传统软件那种按账号、按次数、按包月就能完全描述的资源模型，因为模型调用本身就是一个动态计算过程。你塞进去的上下文、拉起的工具、要求的输出长度，都会直接影响成本。</p> <p>所以理解 token 定价，最重要的不是背价格表，而是先建立一个直觉：</p> <ul> <li>长上下文会涨输入成本</li> <li>长输出会涨生成成本</li> <li>工具链会放大总 token</li> <li>缓存和工作流设计会明显影响账单</li> </ul> <p>只要把这几个点想清楚，大多数模型 API 的价格结构其实都不难理解。</p>