1. 拆解 LLM 成本结构为什么输出 token 比输入贵 4 倍很多人第一次拿到大模型 API 账单的时候都会愣一下明明输入的内容更长怎么输出反而更贵我拿 DeepSeek 的定价举个例子输入 token 每百万大约 1 到 2 块钱输出 token 每百万能到 8 到 16 块差距正好在 4 到 8 倍之间。这不是某一家厂商随便定的背后有一套很硬的工程逻辑。1.1 输入和输出在计算上根本不是一回事要理解这个价差得先搞清楚大模型推理时到底在算什么。输入 token 走的是Prefill 阶段也就是预填充。你丢进去一段 prompt模型把这整段文字一次性并行编码成 KV 缓存GPU 的矩阵运算可以吃满吞吐量非常高。这个过程有点像你往图书馆里一次性搬进去一箱书虽然量大但是可以批量处理单位成本低。输出 token 走的是Decode 阶段也就是逐 token 生成。模型每生成一个 token都要重新做一次前向计算而且必须等上一个 token 算完才能算下一个。这是串行的GPU 利用率天然上不去显存带宽成了瓶颈。打个比方输入像是用货车拉货输出像是用吸管一滴一滴往外挤。同样是一百万 tokenDecode 阶段消耗的算力资源和时间可能是 Prefill 的十几倍甚至更多。所以厂商定价时输出贵 4 倍其实已经算是“良心价”了真实成本差距可能更大。理解这一点很关键因为它直接决定了你优化成本的方向省输出 token 的收益远大于省输入 token。1.2 一个真实的账单拆解案例我拿自己做过的一个知识库问答项目来算账。这个项目每天处理大约 2000 次问答请求每次请求的 prompt 平均 3000 token包含系统提示、检索到的文档片段、对话历史输出平均 400 token。按 DeepSeek 的典型价格粗算项目单价元/百万 token日用量日成本输入2600 万12 元输出880 万6.4 元合计--18.4 元看起来输出只占三分之一对吧但注意输入量是输出的 7.5 倍。如果我把输出长度从 400 压到 200日成本直接降到 15.2 元省了 17%。而如果我把输入从 3000 压到 1500日成本降到 15.4 元省的差不多。但问题是压缩输入往往要牺牲检索质量而压缩输出只需要让模型说话更简洁。从投入产出比来看控制输出长度是性价比最高的优化手段。1.3 为什么“贵 4 倍”这个数字值得记住这个倍数不是让你去跟厂商讨价还价的而是给你一个成本敏感度的锚点。当你做架构决策的时候心里要有一杆秤每多让模型输出 100 个 token相当于多输入了 400 个 token 的钱。所以那些“让模型先思考再回答”“让模型输出 JSON 格式”“让模型解释每一步推理”的设计都是在烧钱。我不是说这些设计不好CoT思维链确实能提升准确率但你要清楚它的代价。我见过一个团队为了“让输出更好看”在系统提示里加了 500 字的格式要求结果每次输出多花 200 token一个月下来多烧了好几百块。这种钱花得冤不冤你自己判断。2. 缓存的第一层真相KV 缓存不是你想的那样省钱聊完输出贵的问题接下来必须说缓存。因为很多人一听“缓存”两个字就觉得是省钱利器恨不得把所有东西都缓存起来。但 LLM 场景下的缓存有好几层每一层的逻辑和收益完全不同搞混了就会做出错误的优化决策。2.1 KV 缓存省的是算力不是 token 账单KV 缓存Key-Value Cache是大模型推理的底层机制。在 Decode 阶段模型每生成一个新 token都需要用到之前所有 token 的 Key 和 Value 矩阵。如果每次都重新算一遍那计算量会爆炸。所以工程上会把已经算过的 KV 存起来下次直接复用。但这里有个关键点KV 缓存省的是 GPU 算力和延迟不是你的 API 账单。你调用云端 API 的时候厂商的推理引擎内部已经在用 KV 缓存了你付的钱是按 token 数量算的不会因为厂商用了 KV 缓存就给你打折。KV 缓存真正能帮你省钱的地方是你自己部署模型的时候。自建推理服务KV 缓存做得好吞吐量能翻好几倍单位 token 的电力成本和机器折旧成本就下来了。提示如果你用的是云端 API不要指望通过“让厂商缓存我的 prompt”来省钱。厂商的 prompt caching 功能比如某些平台提供的上下文缓存是另一回事那个确实能省钱但和 KV 缓存不是同一个概念。2.2 Prompt 缓存真正能砍账单的那把刀Prompt 缓存也叫上下文缓存是云端 API 层面提供的功能。原理很简单如果你多次请求的前缀部分完全一样厂商可以把这部分前缀的 KV 缓存存下来下次你再来请求直接复用只按“缓存命中”的价格收费。这个价格通常比正常输入价格低很多有的平台能低到十分之一。我实测过一个场景系统提示词有 2000 token每次请求都一样。开启 prompt 缓存后这 2000 token 的输入成本从每百万 2 元降到了每百万 0.2 元。一天 2000 次请求光这一项就省了 7 块多。一个月下来两百多块够吃好几顿火锅了。但 prompt 缓存有几个坑要注意前缀必须完全一致。哪怕多一个空格、少一个换行缓存就失效了。所以系统提示词要写得极其稳定不要在里面塞动态内容比如当前时间、用户 ID。缓存有有效期。不同平台的有效期不一样有的几分钟有的几小时。如果你的请求频率很低缓存可能早就过期了省不到钱。不是所有模型都支持。选模型的时候要看清楚有些便宜模型反而不支持缓存综合算下来可能更贵。2.3 语义缓存听起来很美用起来要命语义缓存是第三层也是最容易被滥用的。它的逻辑是如果两个问题的语义相似度超过某个阈值就直接返回缓存答案不调用模型。听起来很省钱对吧但实际用起来坑非常多。我试过在一个客服问答场景里做语义缓存用向量相似度来匹配。结果发现用户问“怎么退款”和“退款流程是什么”相似度 0.95缓存命中没问题。但用户问“退款要多久”和“退款要多久到账”相似度 0.92也命中了可这两个问题的答案其实不一样。前者问的是处理时长后者问的是到账时间。直接返回缓存答案用户就炸了。所以语义缓存的关键不是相似度阈值调多少而是你要缓存什么类型的问题。事实型问题比如“营业时间是什么”适合缓存流程型问题比如“怎么操作”要谨慎观点型问题比如“你觉得哪个好”绝对不能缓存。我的经验是语义缓存只适合那些答案唯一、不随时间变化、不依赖上下文的问题。满足这三个条件的问题在你的总请求量里可能连 20% 都不到。3. 缓存的第二层真相命中率是个虚荣指标做缓存优化的时候很多人盯着命中率看觉得命中率越高越好。但我踩过的坑告诉我命中率是个虚荣指标真正重要的是“有效命中率”。3.1 高命中率不等于省钱什么叫有效命中就是缓存返回的答案用户真的满意没有追问没有点踩没有转人工。如果缓存命中率 80%但其中一半的命中用户都不满意那这个缓存不仅没省钱还浪费了存储和计算资源更糟糕的是损害了用户体验。我见过一个团队为了冲命中率把语义缓存的相似度阈值从 0.9 降到 0.75。命中率从 40% 飙到 75%看起来很美。但用户投诉率翻了三倍因为很多不该命中的问题被命中了。最后不得不把阈值调回去还额外花了两周时间做 bad case 清洗。这就是典型的“指标好看业务遭殃”。3.2 怎么算有效命中率有效命中率的算法很简单有效命中次数除以总请求次数。有效命中的定义是缓存返回答案后用户在接下来的对话中没有表达不满没有追问、没有负面反馈、没有转人工。这个数据需要你在业务层埋点不是缓存系统自己能统计的。指标定义目标值缓存命中率缓存返回次数 / 总请求次数参考值不设目标有效命中率满意命中次数 / 总请求次数越高越好但别超过 30%误命中率不满意命中次数 / 总命中次数必须低于 5%为什么有效命中率别超过 30%因为如果你的业务问题足够多样真正能缓存的问题比例天然就不会太高。超过 30% 要么说明你的业务太单一那恭喜你要么说明你的缓存策略太激进那要小心了。3.3 缓存失效策略比缓存本身更重要另一个容易被忽视的点是缓存失效。LLM 场景下的缓存失效比传统 Web 缓存复杂得多因为答案可能因为模型版本更新、知识库更新、业务规则调整而失效。我的做法是给每个缓存条目打上三个标签模型版本、知识库版本、业务规则版本。任何一个版本变了对应的缓存条目就失效。这样虽然会降低命中率但能保证答案的准确性。宁可多花点钱调模型也不要给用户一个过时的答案。注意不要用 TTL过期时间作为唯一的失效策略。TTL 只能保证缓存最终会失效但不能保证在业务规则变更时立即失效。我见过一个场景退款政策从 7 天改成 15 天但缓存里的答案还是 7 天结果用户按 7 天去申请被拒投诉了一大片。4. 缓存的第三层真相缓存和成本优化的关系是反直觉的前面说了三层缓存现在说一个更反直觉的结论缓存做得越好你可能花在模型上的钱越多。4.1 缓存省下的钱会被“需求膨胀”吃掉经济学里有个概念叫杰文斯悖论当某种资源的使用效率提高时它的总消耗量反而可能增加。缓存就是这样一个东西。你缓存做得好单次请求成本降了业务方就会觉得“反正便宜那就多调几次”。结果总成本不降反升。我亲身经历过一个案例。一个内部知识助手原本每天 500 次调用成本 10 块钱。做了 prompt 缓存和语义缓存后单次成本降了 60%但调用量涨到了 2000 次因为大家都觉得“反正便宜有事没事问一下”。最后日成本变成了 16 块比原来还高。这不是说缓存不该做而是说做缓存的同时要设定调用配额。没有配额的缓存优化就是在给业务方发一张无限额的信用卡。4.2 缓存让“贵模型”变得可用另一个反直觉的点是缓存可以让你用得起更贵的模型。举个例子GPT-4 级别的模型输出价格可能是便宜模型的 20 倍但如果你的场景里 80% 的请求都能被缓存命中那实际成本可能只比便宜模型贵 4 倍。而 4 倍的价差换来的答案质量提升可能是值得的。我现在的策略是用贵模型 激进缓存而不是用便宜模型 不用缓存。因为便宜模型的答案质量不够用户会反复追问反而消耗更多 token。贵模型一次答对缓存命中率也高综合成本可能更低。4.3 缓存的数据一致性成本被严重低估最后说一个很少人提的点缓存的数据一致性成本。在 LLM 场景下缓存的不只是一条数据库记录而是一段自然语言答案。这段答案可能引用了多个数据源涉及多个业务规则。当任何一个数据源或规则变化时你都需要判断缓存是否失效。这个判断逻辑的复杂度往往被严重低估。我见过一个团队缓存系统本身只花了两周开发但缓存失效逻辑改了三个月还没稳定。因为业务规则太复杂了A 规则变了要不要失效 B 缓存C 数据更新了要不要失效 D 缓存这些边界情况根本列不完。我的建议是缓存失效逻辑要尽量简单粗暴。宁可多失效一些也不要漏失效。因为漏失效的代价是用户看到错误答案这个代价远高于多调几次模型的成本。5. 实操一套可落地的 LLM 成本优化方案说了这么多原理和坑现在给一套可以直接抄作业的方案。这套方案是我在多个项目里迭代出来的不一定最优但足够稳。5.1 第一步建立成本监控没有监控就没有优化。你首先要搞清楚钱花在哪了。我建议至少监控这几个维度按模型分每个模型每天消耗多少输入 token、多少输出 token、多少钱。按业务场景分每个场景问答、摘要、翻译、代码生成的 token 消耗和成本。按用户分哪些用户或哪些部门消耗最多有没有异常调用。缓存命中情况prompt 缓存命中率、语义缓存命中率、有效命中率。监控工具可以用现成的也可以自己写。核心是每天看一次报表发现异常及时处理。我见过太多团队等到月底账单出来才发现某个接口被刷了那时候已经晚了。5.2 第二步优化输出长度这是性价比最高的优化手段。具体做法系统提示里明确要求简洁。比如“请用不超过 100 字回答”“不要重复问题”“不要解释推理过程”。设置 max_tokens 上限。根据业务场景设定合理的上限比如问答场景 300 token摘要场景 500 token。用结构化输出替代自然语言。如果下游系统需要解析答案直接让模型输出 JSON比输出一段话再解析更省 token。我实测过光是加一句“请简洁回答”输出长度平均能降 30%。这 30% 直接对应成本下降而且用户体验通常不会变差因为大部分人也不喜欢看长篇大论。5.3 第三步做 prompt 缓存prompt 缓存是确定性最高的省钱手段。做法把系统提示词固定下来不要在里面塞动态内容。把 few-shot 示例固定下来如果要用的话。把检索到的文档片段放在 prompt 末尾这样前缀部分才能被缓存。注意不同平台的 prompt 缓存实现方式不一样。有的自动开启有的需要手动标记缓存断点。用之前一定要看文档别想当然。5.4 第四步谨慎做语义缓存语义缓存不是必须的做之前先问自己三个问题我的业务里有多少问题是答案唯一、不随时间变化、不依赖上下文的我有没有能力做有效命中率的埋点和监控我能不能接受误命中带来的用户体验损失如果三个问题有两个答不上来建议先不做语义缓存把 prompt 缓存和输出优化做好就够了。5.5 第五步定期 review 模型选型模型市场变化很快今天贵的模型明天可能降价今天便宜的模型明天可能出更强版本。我建议每个季度做一次模型选型 review用真实业务数据跑一遍评测看看有没有更优的性价比组合。评测的时候不要只看单次调用成本要看完成一个业务任务的总成本。有的模型单次便宜但需要多轮对话才能完成任务总成本反而更高。6. 常见问题与排查技巧实录最后整理一些我在实际项目里被问得最多的问题以及我的排查思路。6.1 账单突然暴涨怎么排查先看监控报表按模型、场景、用户三个维度拆解。最常见的原因有三个某个接口被异常调用、某个场景的 prompt 变长了、缓存失效导致命中率下降。排查顺序建议从用户维度开始因为异常调用通常集中在少数用户身上。6.2 缓存命中率突然下降怎么排查先检查 prompt 前缀有没有变化。很多时候是开发同学改了一行系统提示或者加了一个动态变量导致缓存全部失效。其次检查缓存有效期如果请求频率变低缓存可能过期了。最后检查模型版本模型升级后缓存通常会全部失效。6.3 怎么判断该用贵模型还是便宜模型我的判断标准是如果便宜模型的答案需要用户追问超过 1 次才能满意就换贵模型。因为一次追问的 token 消耗可能就抵消了便宜模型省下的钱。而且用户体验的损失更难量化但影响更大。6.4 输出 token 能不能压缩到极致不能。输出 token 压得太狠答案质量会下降用户会追问反而消耗更多 token。我的经验是输出长度控制在“刚好把问题说清楚”的程度不要为了省钱牺牲可读性。一般来说问答场景 100 到 300 token摘要场景 200 到 500 token是比较合理的区间。问题排查方向解决手段账单暴涨按用户/场景/模型拆解限流、优化 prompt、修复缓存缓存命中率下降检查前缀变化、有效期、模型版本固定前缀、调整有效期、重建缓存输出太长检查系统提示、max_tokens 设置加简洁要求、设上限、改结构化输出误命中率高检查语义缓存阈值和问题类型提高阈值、限制缓存问题类型6.5 一个容易被忽视的省钱技巧最后分享一个很少人提的技巧把多次小请求合并成一次大请求。比如你要处理 10 条用户评论的情感分析不要调 10 次 API而是把 10 条评论拼成一个 prompt让模型一次性输出 10 个结果。这样输入 token 可能差不多但输出 token 里的格式说明、开场白、结束语只出现一次能省不少钱。我实测过批量处理比逐条处理能省 40% 左右的输出 token。这个技巧的代价是单次请求的延迟变高而且如果其中一条处理失败整批都要重试。所以适合那些对实时性要求不高的场景比如离线分析、批量标注、日报生成。提示批量处理的时候要注意 max_tokens 上限别一次塞太多导致输出被截断。建议先小批量测试找到合适的批量大小。这套方案我在三个项目里跑过综合成本能降 50% 到 70%具体取决于业务场景和优化前的基线。最关键的不是某个单点技巧而是建立“监控-优化-验证”的闭环持续迭代。LLM 成本优化没有一劳永逸的方案模型在变、业务在变、价格在变只有持续关注才能把钱花在刀刃上。