LLM账单飙升的四个真凶：别急着换便宜模型

账单涨了，但流量没怎么涨

发票又来了，比上个月更贵。流量只增长了一点，账单却涨了一大截。大多数团队的第一反应是"我们需要换个更便宜的模型"——有时候这没错，但更多时候，钱正从没人注意的地方悄悄漏走，而换模型只是把漏洞挪了个位置。

一位开发者社区作者把这个问题拆成了四个嫌疑人：长提示词、啰嗦输出、重试与Agent循环、模型层级错配。他认为前两个只要你查看单次请求就能发现，而后两个——重试循环和模型错配——只有当你看整个工作流时才会暴露。

rss source: What's Actually Eating Your LLM Bill? Four Suspects to Check First

嫌疑人A：长提示词——每次调用都在为同一段文字付费

输入token的单价通常比输出便宜，问题在于你会在每一次请求里为它们付费。一段6000token的系统提示词，如果从不改变，它在第一次调用时计费6000token，在第一百万次调用时依然计费6000token。

省钱的关键在于把提示词中稳定的部分放在顶部，让供应商的提示词缓存机制生效。OpenAI和Anthropic都在文档中说明了：当提示词前缀完全一致时，缓存读取的输入token会享受折扣。

需要排查的几点：

稳定的系统提示词是否放在最前面，使缓存能够命中？
当答案只需要3个片段时，你的RAG是否检索了20个？
对话历史是被裁剪或摘要压缩了，还是无限增长？

嫌疑人B：啰嗦输出——在价格表最贵的一侧烧钱

在多数供应商的价格表上，输出token的价格是输入token的数倍。一个"贴心地"写了600字、而UI上只显示两句话的模型，正在烧掉你最贵的那类token。

对大多数应用来说，这是最容易发现也最容易修复的问题：

是否为每个使用场景设置了合理的max_tokens？
提示词里有没有明确说清你想要的长度和格式？
对于机器消费的输出，是否直接要求结构化JSON，而不是让它写一大段散文再由你解析？

输出长度本质上是一个产品决策，不是一个模型能力问题。很多团队默认"让它自由发挥"，结果付出的代价是账单上最难解释的那部分。

嫌疑人C：重试与Agent循环——为同样的工作重复付费

这才是真正会藏起来的那一个。一次用户操作可能扇出成：验证失败触发的重新提问、供应商超时触发的重试、Agent调用工具后得到困惑结果再试一次——一共八次。

每一步单独看都很合理。加在一起，总成本是预算的数倍。

排查思路：

按"完成的任务"而非"请求"来计算成本。如果一个"总结工单"任务平均需要四次LLM调用，那么四次才是你真正的单位价格。
对Agent迭代次数和每次请求的重试次数设置硬上限。
确认重试是否幂等且被记录，这样你才能看到它们到底触发了多少次。

链路追踪工具能让这些隐藏成本显形。Langfuse的token与成本追踪功能可以按trace和span归因成本；如果通过LiteLLM代理路由，它也能给出按key、团队或模型维度的支出统计。没有可观测性，重试循环就是一笔看不见的账。

LLM链路追踪（Tracing） 是可观测性在AI应用中的具体形态。传统APM以HTTP请求为最小单位，而一次用户操作在LLM应用里会扇出成多层调用：一次Agent回合可能包含规划、工具调用、结果反思、再规划等若干步，每一步又可能触发内部重试。链路追踪把这些调用组织成树状的trace与span结构，每个span记录模型名、输入输出token数、耗时和状态，从而让"一个任务花了多少钱"变得可查询。Langfuse、LangSmith、Phoenix等工具都提供这类能力。

LiteLLM代理 则位于应用与各模型供应商之间的路由层。它把OpenAI、Anthropic、Bedrock等不同API统一成OpenAI兼容格式，同时集中记录每次调用的用量与成本，并支持按API key、团队、模型设置预算和速率上限。当应用经由它转发时，隐藏的重试、超时后的兜底调用、以及在多个模型间的自动降级都会在同一个账本里显形，这正是把"看不见的账"变成"可归因的支出"的关键。

嫌疑人D：模型层级错配——用大锤敲每一颗钉子

生产中大量调用其实很无聊：分类、字段抽取、工单路由。这些任务很少需要你能访问到的最强模型。

排查方法：

列出所有LLM调用点，给每个打上标签：推理密集还是例行公事。
在例行任务上，用评估集跑一遍小模型。如果质量保持，就切换。
对延迟不敏感的工作，看看批处理接口——OpenAI Batch和Anthropic Message Batches的定价都低于各自的同步API。

OpenAI的延迟优化指南也提到一个相关观点：更少的token、更少的请求、以及在可能时使用更小的模型，既能提升速度也能控制支出。速度与成本在这里并不矛盾。

批处理接口 与同步API的本质区别在于延迟换价格。同步调用要求模型立即返回结果，占用实时算力；批处理则把请求排队，由供应商在数小时窗口内（通常是24小时）择机执行，因此单价普遍打对折甚至更低。OpenAI Batch和Anthropic Message Batches都遵循这个模式，代价是不保证低延迟，适合离线评估、数据标注、批量摘要、日志清洗等对时效不敏感的工作。使用时要留意两点：一是请求需以JSONL等格式打包上传并携带自定义ID便于结果对回；二是失败项会单独返回，需要在业务侧设计补跑逻辑，避免部分失败被静默吞掉。

一个30分钟就能跑的审计

拉出一天的trace或日志。
按任务而非请求来归组成本。
对成本最高的三个任务，记录：输入token、输出token、每任务调用次数、使用的模型。
那张表上最大的数字，就是你对A、B、C还是D的回答。

十次有九次，解决方案不是换供应商，而是一个上限、一个对缓存友好的提示词顺序、或者在例行路径上换用更小的模型。这四个嫌疑人的共同点是：它们都不是模型能力问题，而是工程习惯问题。

常见问题

Prompt缓存能省多少？ 取决于前缀复用率。前缀完全一致时，OpenAI和Anthropic都对缓存读取的输入token提供折扣定价，稳定前缀越长、调用越频繁，节省越明显。

如何判断该换小模型？ 拿你的评估集在候选小模型上跑一遍。例行任务（分类、抽取、路由）通常先受影响最小，质量守住就可以切。

Agent循环的成本怎么控制？ 设置迭代次数硬上限，按完成的任务统计成本，并接入Langfuse或LiteLLM这类追踪工具让重试可见。