LLM推理账单怎么降：2026年先查这20处浪费

上周复盘一个 Agent 项目的账单，API 调用费占总成本 67%。再往里拆，重复 Prompt、过长上下文和没有用上的中间推理，合计吃掉了 30% 的 Token。

账单高，先别急着换更便宜的模型。很多钱漏在调用链路里：简单任务交给了大模型，固定上下文被反复计费，GPU 等请求，Agent 陷入循环后还在继续烧 Token。

我们随后把整条推理链路重新拆了一遍。下面这 20 项来自 2025 年底到 2026 年中的生产验证，顺序按当时的优化优先级排列。除产品计价和政策额度外，文中的比例都取自这批项目的账单或压测，适合用来排查，不宜直接当作所有业务的成本承诺。

先把贵模型留给难题

• 先试 INT4、FP8，再决定要不要保留 FP16。 在我们评估的开源模型里，FP8 和 INT4 已很常见。Llama 4-Maverick 的 INT4 版本在 MMLU 上下降 0.8%，显存占用减少约 60%，单卡吞吐提升 2 倍，最终推理成本降低 40%-60%。如果团队还在用 FP16 跑 10B 以上模型，这通常是最先值得动的一处。TensorRT-LLM 的部署细节可参考《10B模型如何在单卡RTX 6000上实现毫秒级响应：量化实战》。

• 垂直微调时，把 GRPO 和原来的 SFT 路线放在一张账上算。 在这次对比中，GRPO 方案取消了 Critic 网络，单卡 RTX 4090 可以运行 3B 模型的强化学习微调。调教后的 3B-7B 模型在特定任务上接近 70B 通用模型表现，训练成本比原 SFT 路线低 70%-85%。相关过程见《用GRPO算法调教3B小模型：不走SFT弯路的企业专属微调方案》。

• 给请求分级，70B 只接复杂推理。 我们把路由分成三档：意图识别且输入少于 60 字的请求走 3B，中等复杂度走 7B-14B，复杂推理再交给 70B。约 45% 的日常请求可以由 3B-7B 模型完成，混合路由后，整体 API 成本下降 50%-65%。

• 分类、提取和格式转换，不要默认输出思维链。 这类确定性任务没有必要习惯性要求模型“一步步思考”。关闭不必要的 CoT 输出后，Token 输出量减少 30%-50%。保留结果字段和必要的校验信息即可。

框架换对，GPU 才不会空转

• 自建场景优先评估 vLLM 或 SGLang。 PagedAttention 和连续批处理是两项直接影响吞吐的能力。同等 GPU 下，纯计算口径的每 Token 成本比 OpenAI API 低约 60%-70%；其中一组在扣除自建运维后仍省 20%-30%，项目整体记录区间为 20%-40%。流量较小的业务要先把运维成本算进去，别只比较 GPU 租金。

• 把 KV Cache 量化到 INT8。 在这批部署里，KV 缓存通常占推理显存的 30%-50%。我们使用的框架版本已经支持 KV Cache INT8，质量几乎没有变化，缓存显存占用约减半，同一张卡因此可以承接更多并发。

• 长文本生成再考虑 Speculative Decoding。 做法是让小模型先生成候选 Token，再由大模型并行验证。前提是已经有可用的蒸馏草稿模型。项目里的长文本生成速度提升 20%-40%，折算后的成本下降 15%-25%。

• 高并发别再用静态批处理硬扛。 请求长度和到达时间不一致时，静态批处理很容易让 GPU 等待。vLLM 和 SGLang 的 Continuous Batching 会在请求到达时动态分组，这次压测中 GPU 利用率提升 30%-50%，单位时间吞吐量随之增加。

• 流式响应不直接降低单价，但能少掉重试。 用户更早看到首批结果后，中途放弃和超时重发都会减少。我们观察到开启流式响应后，用户中途放弃率下降约 18%，重试产生的 Token 减少 15%-25%。

重复内容别再按原价重算

• 固定系统提示词优先接入 Prompt Caching。 Anthropic 和 OpenAI 都在 API 层提供了 Prompt 缓存。按当时采用的价格口径，Anthropic Prompt Cache 为每百万 Token 0.15 美元，正常调用则为每百万 Token 3-15 美元。系统提示词和长上下文重复率较高时，缓存部分的费用可下降 80%-95%。

• FAQ 和知识检索先过 Redis。 高频问题没有必要每次都调用 LLM。我们为客服系统的缓存设置了 1-24 小时 TTL，最终约 40% 的查询命中缓存层，对应的 LLM 调用成本下降约 40%。TTL 要跟内容更新频率一起调整，避免把过期答案长期留在前台。

• 长上下文先截断，再做摘要压缩。 原始内容超过上下文窗口时，全量塞入既贵，也未必有用。一次对比中，128K 上下文经摘要后平均缩减到 16K，精度下降不到 3%，长上下文 Token 消耗减少 60%-80%。

算力怎么买，先看负载曲线

• 闲置 Mac Studio 可以接住内部小模型。 通过 llama.cpp RPC 做分布式推理，两台 M2/M3 Max 合计运行 14B 模型，延迟仍在可接受范围内。对内部工具和低并发任务来说，云调用成本可以接近零。搭建方法见《拒绝被云厂商绑架：两台旧 Mac 本地跑通 14B 大模型实操指南》。

• 突发流量用按需 GPU，稳定负载再谈长期持有。 负载波动大的团队长期租卡，往往会为闲置时间付费。短期任务和流量峰值用 GPU 租赁，稳定负载再评估买断或算力券，项目里的弹性方案比长期租约少了 30%-50% 的闲置成本。采购判断可对照《算力需求升温后，团队用算力券未必比租GPU便宜》。

• 算力券要盯着核销窗口和用途。 按《北京算力券申领指南（2026版）：中小团队如何撬动8000P园区资源》整理的信息，2026 年北京首批算力券补贴最高 500 万元，但核销存在窗口期和用途限制。我们更倾向于把补贴投向高质量数据集和多模态对齐服务，避免单纯堆算力。在符合核销条件的项目里，算力券可覆盖 30%-50% 的基础设施支出。

账单要有刹车，也要能追到模块

• 先给 Agent 装 Token 熔断。 Agent 死循环是异常账单里最危险的一类。LiteLLM、Langfuse 和 Portkey 都可以配置 Token 熔断、动态限额与心跳检测，在消费异常时自动截停。它的价值不在于再省几个点，而是拦住原本可能超过预算 200%-500% 的单次异常消费。配置方式见《别让Agent偷刷你的信用卡：用三款开源工具卡死API异常消费》。

• 把 Token 用量拆到每个模块和每次调用。 用 Langfuse 或自建看板记录 Token 消耗、延迟分布和重试次数，浪费才有机会被定位。我们曾发现一个日志聚合模块占总 Token 量的 22%，原因只是重试逻辑写得太粗。修复这类问题后，项目平均还能再省 10%-20%。

• 每个接口都要设置最大输出 Token。 很多 Prompt 没有配置 max_tokens，模型会一直生成到默认上限。按接口用途设定输出长度后，非必要的输出 Token 减少 20%-35%。分类接口和报告生成接口不该共用同一套上限。

• 选架构时看整条链路的成本。 从 2026 年使用的训练工具和推理框架看，生态仍主要围绕 Transformer 运转。MoR 方案声称可将 KV 缓存内存降低约 50%，Mamba 和 RWKV 也在争夺长序列场景，但框架适配、部署工具和维护成本都要一起计算。长序列任务采用合适架构后，显存成本可能下降 30%-50%。相关判断见《Transformer还没退场，工程账比架构更难改》。

• 每月跑一次成本回归。 模型更新、框架升级和硬件换代都会改变成本结构。我们固定使用同一组 Prompt，对比不同模型、框架和硬件下的实际花费。按月执行后，持续调整带来的年度累计节省为 15%-30%。

时间只够做一轮，先上这三项

如果当前只能安排一次改造，优先级可以很明确：开 Prompt 缓存，评估 vLLM 或 SGLang，再给 Agent 加 Token 熔断。这三项在几个项目里合计让整体推理成本下降约 55%，而且不需要先重做全部业务逻辑。

Agent 系统还要检查编排层。可以把《抛弃复杂Prompt：用最新的多智能体编排工具搭建自动化研报流》里的链路拿来对照，看看复杂 Prompt 和多智能体之间有没有重复上下文、无效往返或失控重试。

还有一个判断顺序，可以从《别急着做自动驾驶：物流重卡在封闭矿区用AI排班省下15%油钱》借来：封闭矿区先用物理 AI 和强化学习改调度排班，就省下了 15% 的油钱，没有急着投入数百万元改装无人驾驶硬件。放回 LLM 场景，同样先处理重复 Prompt、长上下文、GPU 空转和 Agent 死循环。更大的模型、更贵的 GPU 和新架构，等账单证明有必要时再上。