2026-07-04 · 5 分钟阅读

请求前 vs 事后 LLM 计费

每个 LLM 产品最终都会面临同一个架构问题：在 API 调用前检查预算，还是事后对账用量？答案取决于你的定价模式和客户花钱的速度。

事后计费：先计量，后结账

事后模式摄入 Token 事件，在批量窗口（30 秒、60 秒或更长）内汇总，再异步更新余额。这是大多数分析管道的默认做法，适用于月底发票的后付费 SaaS。

弱点出现在预付费钱包和 Agent 循环上。等汇总反映支出时，可能已有数十次 LLM 调用完成。你始终在用过时的数据做拦截。

请求前检查颠倒顺序：每次 LLM 调用前执行 GET /budget/{id}/check。传入估算成本；系统根据当前余额减去进行中预留返回 allowed: true 或 false。

调用后仍需摄入实际 Token 数量以准确扣减。请求前拦截不是计量的替代品 — 它是热路径上的闸门，窗口后扣减保持账本准确。

仅在延迟拦截可接受时使用事后模式：后付费计费、宽松信用额度或低频人工使用。

在客户预付费 Token、Agent 循环可链式发起数十次调用、或单次未检查请求可能大幅超支时使用请求前拦截。

许多生产栈两者兼用：FluxMeter 做实时拦截，Lago 或 Stripe 做发票和客户面向的计费。

流式响应带来进行中的支出，简单的前后检查都无法处理。FluxMeter 使用预留 → 流式 → 摄入 → 对账，使有效余额计入尚未结束的 Token。

没有预留机制，客户可并发启动十个流式响应，在任一流结束前就超额消费。