1. 先搞清楚账单为什么这么吓人很多人第一次拿到大模型 API 的月度账单时第一反应是“我是不是被多扣了”。我当初也一样明明感觉输入的文字量远大于输出结果账单上输出那一栏的费用几乎是输入的四倍。这不是错觉也不是计费系统出 bug而是当前主流大模型服务商普遍采用的一套定价逻辑在起作用。这篇文章我想聊的就是这件事LLM 成本精算。核心围绕三个问题展开——为什么输出比输入贵这么多、缓存到底能省多少钱、以及围绕 token 的成本优化到底该怎么做。适合正在用 DeepSeek、Claude 或其他大模型 API 做产品、做知识库、做自动化流程的开发者也适合那些刚开始接触 LLM 计费、看到账单一脸懵的朋友。我会把计费的底层逻辑、缓存的三层真相、以及我自己踩过的坑都摊开讲尽量让你看完就能动手算自己的账。先说结论输入 token 和输出 token 的定价差异本质上是计算量和商业策略共同决定的。理解这一点你才能理解后面所有的成本优化手段为什么有效、在什么场景下无效。1.1 输入和输出到底差在哪从模型运行的角度看输入 token 和输出 token 走的计算路径完全不同。输入部分是一次性的前向计算模型把你的 prompt 编码成向量经过若干层注意力机制处理这个过程是并行的GPU 可以一次性把整段输入吃进去。而输出部分是自回归生成每生成一个 token都要重新跑一次前向计算而且必须等上一个 token 生成完才能生成下一个。也就是说输出 100 个 token模型实际上跑了 100 次前向计算。这个差异直接体现在 GPU 时间上。输入 1000 个 token 和输出 1000 个 token后者占用的计算资源可能是前者的几十倍。服务商把这个成本差异转嫁到定价上就形成了“输出贵、输入便宜”的格局。目前市面上主流模型的输出单价通常是输入的 3 到 5 倍4 倍是一个很常见的比例。1.2 为什么是 4 倍而不是 10 倍你可能会问既然输出计算量这么大为什么不是贵 10 倍甚至更多这里有两个原因。一是商业竞争服务商需要让整体价格看起来可接受如果输出定价过高用户会转向更便宜的方案。二是输入侧其实也有成本尤其是长上下文场景输入 token 的注意力计算是 O(n²) 的复杂度上下文越长输入侧的成本增长越快。所以最终定价是两边成本的一个平衡点4 倍左右是市场博弈出来的结果。理解了这个比例你就能明白一个反直觉的事实在长上下文场景下输入未必真的便宜。如果你每次请求都塞进去几万字的上下文输入侧的成本会迅速逼近甚至超过输出侧。这也是为什么缓存机制在长上下文场景下价值巨大。2. 缓存的三层真相别被表面数字骗了缓存是 LLM 成本优化里被提得最多、但也被误解最多的概念。很多人以为开了缓存就能省钱结果发现账单没怎么变。问题出在大家对缓存的理解停留在表面。我把缓存拆成三层来讲每一层的真相都不太一样。2.1 第一层真相缓存省的是输入不是输出这是最基础也最容易被忽略的一点。缓存机制作用于输入 token对输出 token 完全没有影响。它的原理是如果你连续多次请求的前缀部分完全相同服务商可以把这部分前缀的计算结果缓存下来后续请求直接复用不再重复计算从而按更低的单价计费。举个例子你有一个系统提示词长度 2000 token每次对话都带着它。如果没有缓存这 2000 token 每次都按全价输入计费。如果开了缓存第一次请求按全价后续请求中这 2000 token 按缓存命中价计费通常只有原价的 10% 到 25%。听起来很美好但注意这只影响输入侧。你的输出该多少还是多少。所以如果你的应用输出量很大、输入量很小缓存对你的帮助非常有限。反过来如果你的应用是长系统提示词加短输出缓存就是救命稻草。2.2 第二层真相缓存命中是有条件的缓存不是自动生效的它有一系列前提条件。首先是前缀必须完全一致包括标点、空格、换行。差一个字符缓存就失效。其次是缓存有有效期不同服务商的过期时间不同短的可能几分钟长的可能几小时。如果你的请求间隔超过了有效期缓存就没了。还有一个容易被忽略的点缓存是按前缀逐层匹配的。假设你的 prompt 结构是“系统提示词 历史对话 当前问题”系统提示词部分可以命中缓存但如果历史对话每次都不同那么从历史对话开始的部分就无法命中。这意味着你的缓存收益取决于前缀的稳定程度。我见过一个典型的错误用法有人把用户 ID、时间戳这类每次都变的信息放在 prompt 最前面结果整个前缀每次都不同缓存命中率几乎为零。正确的做法是把稳定不变的内容放前面变化的内容放后面。2.3 第三层真相缓存的经济账要算总账缓存本身不是免费的。部分服务商对缓存写入收取额外费用虽然通常比正常输入便宜但也不是零。所以你需要算一笔总账缓存写入成本 缓存命中成本对比不使用缓存的全价输入成本看是否真的划算。这里有个简单的判断方法。假设你的前缀长度是 L缓存写入单价是 a命中单价是 b正常输入单价是 c命中次数是 n。那么使用缓存的总成本是 L×a L×b×n不使用缓存是 L×c×(n1)。当 n 足够大时缓存方案胜出。但如果 n 很小比如只有一两次缓存写入的额外成本可能让总账反而更贵。提示缓存最适合的场景是高频、前缀稳定、请求密集的应用。低频、前缀多变的场景缓存收益有限甚至为负。3. 把成本算清楚一套可复用的精算方法光讲原理不够得能落地算账。我整理了一套自己常用的成本精算方法从 token 估算到最终账单预测一步步来。3.1 token 估算别靠感觉靠工具很多人估算 token 靠“大概多少个字”这在实际计费里误差很大。中文和英文的 token 比例不同标点、代码、特殊符号的 token 消耗也不一样。我的建议是直接用对应服务商提供的 tokenizer 工具来算或者用开源的 tiktoken 类库做近似估算。一个经验值供参考中文大约 1 个汉字对应 1 到 2 个 token英文大约 1 个单词对应 1 到 1.5 个 token代码的 token 密度更高。但这些只是粗略估计正式做预算时一定要用真实 tokenizer 跑一遍你的典型请求。3.2 单价对照不同模型的成本差异不同模型的定价差异很大下面这张表是我整理的常见模型输入输出单价对比单位每百万 token价格为示意实际以官方为准模型类型输入单价输出单价输出/输入比轻量模型低低约 3 倍标准模型中中高约 4 倍旗舰模型高很高约 4 到 5 倍缓存命中极低不适用约为输入 10% 到 25%从这张表能看出两个规律一是输出输入比稳定在 3 到 5 倍之间二是缓存命中价确实低得诱人但前提是你能命中。3.3 一个完整的成本计算示例假设你做一个客服机器人系统提示词 1500 token每次对话历史平均 1000 token用户问题 100 token模型输出 300 token。每天 10000 次请求。标准模型输入单价按每百万 token 10 元输出按每百万 token 40 元缓存命中按每百万 token 2 元。不使用缓存时每次请求输入 2600 token输出 300 token。每天输入成本是 2600×10000÷1000000×10 260 元输出成本是 300×10000÷1000000×40 120 元合计 380 元。使用缓存后假设系统提示词 1500 token 稳定命中对话历史 1000 token 因为每次都变无法命中。那么每次请求的输入成本是 1500×2÷1000000 1100×10÷1000000 0.003 0.011 0.014 元每天 140 元。输出成本不变120 元。合计 260 元。省了 120 元约 31%。这个数字说明缓存确实有用但前提是你的稳定前缀足够长。如果系统提示词只有 200 token缓存收益就微乎其微了。4. 成本优化的实操手段与避坑经验算清楚账之后接下来就是怎么优化。我按投入产出比从高到低排列你可以根据自己的场景选择。4.1 优化 prompt 结构提高缓存命中率这是性价比最高的一招。核心原则是稳定内容前置变化内容后置。把系统提示词、固定指令、知识库静态部分放在最前面把用户输入、时间戳、会话 ID 放在最后。这样缓存能覆盖尽可能长的前缀。我自己的做法是把系统提示词拆成两层一层是完全不变的通用指令一层是可能随场景变化的角色设定。通用指令放最前面角色设定放后面。这样即使角色变了通用指令部分的缓存依然有效。4.2 控制输出长度这是省钱的关键既然输出贵 4 倍那么控制输出长度就是最直接的省钱手段。具体做法包括在 prompt 里明确要求简洁回答、设置 max_tokens 上限、用结构化输出减少冗余文字。我试过在 prompt 里加一句“请用不超过 100 字回答”输出 token 平均下降了 40%而且用户满意度没有明显变化。因为很多模型的默认行为是“话多”你不限制它它就会啰嗦。注意max_tokens 设置过小会导致回答被截断影响体验。建议根据实际场景测试一个合理的下限而不是一刀切设成很小的值。4.3 模型分级不是所有请求都值得用旗舰模型很多团队所有请求都走同一个模型这是很大的浪费。简单的分类、提取、格式化任务用轻量模型就够了成本可能只有旗舰模型的十分之一。只有复杂的推理、创作、分析任务才需要旗舰模型。我的做法是做一个路由层根据请求的复杂度打分简单请求走轻量模型复杂请求走旗舰模型。实测下来整体成本能降 50% 以上而用户体验几乎无感。4.4 常见问题速查表问题现象可能原因排查方向缓存命中率低前缀不稳定检查 prompt 是否有变化内容前置账单远超预期输出 token 过多检查 max_tokens 和 prompt 约束缓存写入成本高请求频率低评估缓存是否划算低频场景可关闭成本忽高忽低请求量波动按天统计找出峰值原因模型响应变慢上下文过长精简历史对话控制上下文长度4.5 几个我踩过的坑第一个坑是以为缓存会自动开启。实际上很多服务商需要你在请求里显式声明使用缓存不声明就不生效。我当初白白多花了一个月的钱。第二个坑是把动态内容放在 prompt 开头。有一次我在系统提示词里加了当前日期结果每天缓存全部失效。后来把日期移到用户消息里缓存命中率立刻上去了。第三个坑是忽略输出侧的优化。有段时间我只盯着输入缓存结果输出成本占了总成本的 70%。后来加了输出长度约束总成本直接降了三分之一。5. 不同场景下的成本策略成本优化没有万能药不同场景的重点完全不同。我按几种典型场景分别说说。5.1 知识库问答场景这类场景的特点是系统提示词长、知识库内容多、输出相对短。缓存是核心手段。把知识库的静态部分放在 prompt 最前面确保稳定命中。同时可以考虑把知识库做成分层结构高频访问的部分常驻缓存低频部分按需加载。5.2 内容生成场景这类场景输出量大输出成本占主导。优化重点是控制输出长度和质量。可以用“先大纲后展开”的两段式生成大纲用轻量模型展开用旗舰模型。也可以设置输出模板减少模型的自由发挥空间。5.3 对话交互场景对话场景的难点是历史对话不断增长输入成本会累积。我的做法是只保留最近 N 轮对话更早的对话做摘要压缩。摘要用轻量模型生成成本很低但能大幅减少输入 token。5.4 批量处理场景批量任务的特点是请求量大、单次成本低。这时候缓存的价值取决于任务的前缀是否统一。如果所有任务共享同一个系统提示词缓存收益会非常可观。另外批量任务可以考虑错峰执行部分服务商在低峰期有折扣。6. 监控与持续优化成本优化不是一次性的工作需要持续监控和调整。我建议至少建立三个监控指标每日 token 消耗量、缓存命中率、单次请求平均成本。这三个指标能帮你快速发现异常。监控工具方面可以用服务商自带的用量面板也可以自己搭一个简单的统计脚本把每次请求的 token 数和成本记下来按天聚合。我用的是一个几十行的脚本把日志里的 token 信息提取出来生成日报。成本不高但能让你对钱花在哪一目了然。还有一个经验是定期复盘。每个月看一次账单结构看看输入输出比例有没有变化缓存命中率有没有下降模型路由策略是否还合理。业务在变成本结构也会变定期复盘能避免“温水煮青蛙”。最后分享一个小技巧如果你同时用多个模型服务商可以做一个简单的成本对比表定期更新各家的单价和缓存政策。有时候换个服务商或者调整模型组合成本能降不少而迁移成本可能比你想的低。这个方向后续还可以往更细的方向扩展比如按用户维度分摊成本、按功能模块统计消耗、做成本预警机制等。核心思路都是一样的把账算清楚把优化做扎实别让成本成为业务增长的隐形天花板。