LLM 应用降本：先查令牌浪费与重复调用

LLM 应用的账单变贵，往往不是因为用户问得太难，而是每次请求都背着重复指令、整段聊天记录和过量检索材料，再经过几轮模型调用。原文的核心主张是：先找到浪费，再用满足质量要求的最少计算完成任务。

这套建议值得读，但别把它当成降本实测报告。作者没有提供真实业务的前后对照，主要给出十类优化方法和一组假设计算。对程序员更有用的是它的排查顺序：先量清成本，再改上下文、模型和工作流，最后用质量评估确认钱省在哪里。

先算清一次任务成功要花多少钱

只看单次 API 请求价格，很容易优化错地方。

用户完成一个任务，可能触发分类、检索、回答、校验和重试。某一步换成便宜模型后，如果错误变多，需要重新生成，单次调用虽然便宜，整个任务反而可能更贵。

真正该盯住的是「每个成功任务的成本」。

作者建议先记录总 API 支出、请求量、平均输入与输出 token、响应延迟、错误率、重试率，以及质量和用户满意度。输入 token 不只有用户的问题，还包括系统指令、历史消息、检索文档等所有送进模型的内容；输出 token 则是模型生成的回答或结构化结果。

这些数据还要按任务类型、模型、功能和用户路径拆开看。大量简单请求加上少数昂贵任务，能得到一个看似正常的平均值，却掩盖真正烧钱的环节。检索、存储、日志和托管也有成本，自建模型同样不能漏算硬件、运维和工程时间。

原文用了一组假设数字说明这个区别：

• 每月处理 10,000 次请求，每次使用 2,000 个输入 token、500 个输出 token。
• 优化后输入减少 30%，每次变成 1,400 个输入 token。
• 月输入量从 20,000,000 降到 14,000,000，少了 6,000,000 个 token。
• 输出没有变化，每月仍是 5,000,000 个 token。

输入量下降 30%，不等于总账单下降 30%。实际节省还取决于模型的输入、输出和缓存计费，以及其他费用。作者明确说，这不是供应商真实报价，也没有附上货币金额。

更关键的前提是：缩短输入之后，任务仍然做对了。原文没有提供验证这个前提的实验结果。

上下文该做减法，但不能只按长度裁剪

输入优化有三个主要位置：系统提示词、会话历史和 RAG，也就是检索增强生成。

系统提示词先删重复内容。例如，同一条语气要求写了四遍，或者塞入很少适用的示例，每次请求都会重复付费。压缩时应保留必要约束，而不是追求提示词越短越好。删掉一个关键例子，可能就让输出格式失控。

会话历史更容易悄悄膨胀。原文举例，用户已经聊了 30 条消息，现在只问订单什么时候到。模型可能只需要订单信息和最近几轮对话，无须重读全部历史。

可选做法包括保留相关近况、摘要较早消息、单独存储允许保存的稳定偏好，或者按需找回之前的信息。摘要也不是无损压缩，关键事实、约束、已作决定和未解决问题都可能丢失，必须专门检查。

RAG 的问题类似。检索系统找到的内容，不应全部进入提示词。原文假设，一个问题用两个章节就能回答，系统却送入了 15 段材料，额外内容既花钱，也可能干扰回答。

优化方向是减少重复段落、过滤无关文档、调整分块大小、使用元数据筛选，并判断模型需要整篇文档还是局部片段。这里不能简单制定一个通用的检索数量：取少了缺证据，取多了有噪声，需要一起评估成本和答案质量。

输出端也要做同样的取舍。工单处理如果只需要分类和优先级，就明确要求相应格式，避免生成几段没人使用的解释。最大输出限制可以控制消耗，但设得过低会截断答案，详细任务仍应得到足够完整的回答。

模型、缓存和工作流，各自省的是哪笔钱

模型路由的思路，是按任务难度选择模型。工单分类、意图识别、字段提取、短文本摘要等任务，可以先评估较小或较便宜的模型；复杂推理、模糊问题和困难的多步任务，再考虑能力更强的模型。

但路由本身也增加复杂度。如果便宜模型频繁判断错误，后续返工、重试和升级处理会吃掉节省。原文给的是适用方向，没有证明哪类模型在具体任务上一定够用。

缓存则必须区分两种机制。

Prompt caching 由供应商按规则复用符合条件的重复输入，适合稳定系统指令、产品文档、政策和格式要求。它可能减少输入成本或延迟，但资格、价格、有效期都因供应商和模型而异，需要记录实际命中情况。

应用层结果缓存，是自己的系统保存旧结果，在请求相同或足够等价、且复用安全时直接返回。公开 FAQ、未变化数据上的文档摘要比较适合；个性化、时效性强或依赖权限的回答则要谨慎。缓存需要合理过期、随源数据变化失效，必要时在键中包含模型、提示词和数据版本。语义相似也不代表可以安全共用答案。

Prompt caching 复用重复输入的处理，结果缓存复用已经生成的答案。

工作流层面，优先检查没有明确收益的重复改写、连续调用、自我评审和无界重试。可靠的确定性规则可以交给普通代码，重试应设置次数限制和退避。困难任务的校验仍可能需要多次调用，不能为了省钱一并删除。

批处理适合独立的反馈分类、文档处理、批量摘要和离线评估。它可能改善吞吐或减少部分开销，但不自动降低 token 费用，折扣取决于供应商计费。实时聊天通常也等不了批次结束。

我的判断

这篇最有价值的地方，是把降本放回完整任务里讨论。单看模型价格、提示词长度或缓存命中率，都无法证明产品更划算。错误答案引发的重试和人工处理，同样要记账。

不过，它更像一份工程排查清单。作者没有给出真实项目、模型配置、质量评分或对照数据，关于路由、摘要、缓存收益的讨论都应视为待验证的建议，不能直接当作实践效果背书。

这些方法还有不同的投入门槛。删除重复指令、限制无界重试通常比较直接；历史摘要会增加处理步骤，语义结果缓存需要判断请求是否等价，模型路由需要持续维护评估。与每次使用同一个模型、固定发送最近几轮消息的简单方案相比，复杂架构必须证明收益足以覆盖维护成本。原文没有提供这部分投入产出数据。

质量评估也不能只看回答是否流畅。作者建议覆盖常见请求、困难问题、模糊输入、边界情况、结构化格式和依赖特定来源的任务，比较准确性、完整性、相关性、指令遵循、格式有效性、无依据断言比例、延迟与成功任务成本。主观任务或高影响决策可能还需要人工审查。

原文列出 13 项实践检查项，但也明确不必全做。对一般团队，我更认同这个取舍：先处理测量中最大的浪费，每次改动都保留质量对照。

能拿来做什么

• 给 Node 服务中的模型调用补上用量、耗时、错误和重试记录，并把同一用户任务的多次调用关联起来，先找出高成本功能和失败任务。
• 检查聊天与知识库功能实际发送的请求，分别找出重复系统指令、无关历史、重复检索片段，再用同一批代表性问题比较修改前后的结果。
• 对只需要分类、优先级或字段的功能明确输出格式，并评估较小模型能否达标；同时统计错误后的重试与升级成本。
• 从公开、稳定、权限明确的内容开始尝试结果缓存，补齐过期和数据变更失效机制；批量分类、摘要及评估任务则单独考察批处理是否划算。