隐藏的43%——团队如何浪费近一半的LLM API预算

Source: Dev.to

你打开提供商的仪表盘，只看到一个数字：总账单。它就像一张只写着“$5,000”的电费账单，却没有说明是空调、冰箱还是有人整个月把灯开着。

大多数 AI 初创公司现在都在盲目运营。对多个团队的成本细分分析显示了一个令人震惊的数字：近 43 % 的 LLM API 开支完全被浪费。这并不是因为使用费用，而是因为糟糕的架构导致的费用。

泄漏发生的地方

重试风暴（≈ 34 % 的浪费）

一个代理无法解析 JSON 响应，于是它会重试——有时在循环中重试 5–10 次。你不仅在为失败付费，还在为每次重试时发送的大量上下文窗口付费。

重复调用（≈ 85 % 的应用都有此问题）

多个用户提出完全相同的问题，或内部系统对同一文档运行相同的 RAG 流程。如果没有在提供商层面的缓存，你就会为生成相同的 token 一次又一次地付费。

上下文膨胀

在用户只问“第 2 页的摘要是什么？”时，却发送整篇 50 页的文档历史。RAG 本身很棒，但把所有内容都塞进提示里“以防万一”会消耗大量预算。

错误的模型选择

在简单分类任务上使用 GPT‑4o 或 Claude 3 Opus，而实际上使用更小的模型（如 Haiku 或 GPT‑3.5‑turbo）就能以更低的成本完成任务。

解决方案：LLMeter

看不见的东西是无法修复的。这就是 LLMeter 诞生的原因——一个开源仪表盘，提供按客户和按模型的成本追踪。

• 实时仪表盘： 精确查看哪些租户和模型在消耗费用。
• 预算警报： 设置阈值，在费用失控前收到通知。
• 开源（AGPL‑3.0）： 可自行托管或使用免费层。

在此尝试 LLMeter。

顺便说一句，仅仅设置基本的预算警报并按租户查看费用细分，通常能在第一周让团队的账单下降 20 %。