当前位置：首页 > news >正文

Token 账单的隐形刺客：LLM 推理成本监控体系的设计与实现

news 2026/7/1 8:04:07

Token 账单的隐形刺客：LLM 推理成本监控体系的设计与实现

一、从 API 调用到成本失控：大模型推理费用的隐蔽增长曲线

当企业将大语言模型集成到产品中后，最先感知到压力的往往不是技术团队，而是财务部门。一个典型的场景：对话机器人的日均调用量从 1000 次增长到 50000 次，月度 API 费用从几百美元飙升至数万美元，而业务方对成本增长的感知存在严重滞后——因为 LLM 的计费粒度是 Token 而非调用次数，一次长上下文对话的 Token 消耗可能是一次简单问答的 50 倍。

更棘手的是，成本问题往往在事后才被发现。没有实时监控的情况下，团队可能直到月底账单到达才意识到某个 Prompt 模板因为知识库片段拼接过长，导致每次调用的 Prompt Token 数远超预期。或者某个下游服务的异常重试逻辑，在 LLM 返回超时后反复重试，每次重试都消耗完整的 Prompt Token，成本被放大数倍。

LLM 推理成本监控的核心目标，是将 Token 消耗从"事后账单"变为"实时可见"，从"全局总量"变为"按业务、按模型、按用户的细粒度归因"，从而支持成本预算控制和异常检测。

二、从 Token 计量到成本归因：LLM 推理成本监控的数据模型

LLM 推理成本监控的数据模型需要覆盖三个维度：计量（每次调用消耗了多少 Token）、定价（每个 Token 值多少钱）和归因（这次调用应该算在谁头上）。

flowchart TB subgraph 数据采集层 A[LLM API 调用] --> B[拦截器/中间件] B --> C[提取 Token 用量] C --> D[记录调用元数据] end subgraph 数据模型 D --> E[TokenUsageRecord] E --> F[modelId: 模型标识] E --> G[promptTokens: 输入 Token 数] E --> H[completionTokens: 输出 Token 数] E --> I[totalTokens: 总 Token 数] E --> J[cost: 本次调用成本] E --> K[businessTag: 业务标签] E --> L[userId: 用户标识] E --> M[latencyMs: 延迟] E --> N[timestamp: 时间戳] end subgraph 成本计算引擎 F & G & H --> O[定价表查询] O --> P[模型单价 × Token 数] P --> J end subgraph 监控与告警 E --> Q[实时聚合\n按业务/模型/用户] Q --> R[Grafana 看板] Q --> S{预算阈值检查} S -->|超限| T[告警通知] S -->|正常| U[继续监控] end

Token 计量的关键问题在于：不同模型供应商的 API 响应格式不同。OpenAI 在响应体中直接返回usage.prompt_tokens和usage.completion_tokens，而部分国内模型供应商可能不返回 Token 用量，或返回的数值与实际计费不一致。对于不返回 Token 用量的供应商，需要在客户端侧通过 Tokenizer 预估输入 Token 数，输出 Token 数则通过字符数除以平均 Token 长度估算（中文约 1.5 字符/Token，英文约 4 字符/Token）。

成本归因是监控的核心价值。一次 LLM 调用的成本应该被归因到具体的业务场景（如"智能客服"、"文档摘要"）、具体的用户（如"VIP 用户 A"）和具体的模型（如"gpt-4o"）。只有实现了细粒度的成本归因，才能识别出成本热点并采取针对性的优化措施。

三、生产级成本监控实现：基于 Micrometer 的 Token 用量采集与告警

下面给出一个基于 Spring Boot + Micrometer + Prometheus + Grafana 的 LLM 推理成本监控方案。

Token 用量采集拦截器：

/** * LLM 调用拦截器 * 在每次 LLM 调用前后采集 Token 用量、延迟和成本数据 * 通过 Micrometer 指标暴露给 Prometheus */ @Component public class LlmCostMonitorInterceptor implements HandlerInterceptor { private final MeterRegistry meterRegistry; private final LlmPricingTable pricingTable; // 指标定义 private final Counter promptTokenCounter; private final Counter completionTokenCounter; private final Counter costCounter; private final Timer latencyTimer; public LlmCostMonitorInterceptor(MeterRegistry meterRegistry, LlmPricingTable pricingTable) { this.meterRegistry = meterRegistry; this.pricingTable = pricingTable; // 预定义指标，带业务标签维度 this.promptTokenCounter = Counter.builder("llm.tokens.prompt") .description("LLM Prompt Token 消耗量") .register(meterRegistry); this.completionTokenCounter = Counter.builder("llm.tokens.completion") .description("LLM Completion Token 消耗量") .register(meterRegistry); this.costCounter = Counter.builder("llm.cost.total") .description("LLM 调用总成本（美元）") .register(meterRegistry); this.latencyTimer = Timer.builder("llm.latency") .description("LLM 调用延迟") .register(meterRegistry); } /** * 记录一次 LLM 调用的 Token 用量和成本 * * @param modelId 模型标识（如 gpt-4o） * @param businessTag 业务标签（如 customer-support） * @param userId 用户标识 * @param usage Token 用量 * @param latencyMs 调用延迟 */ public void recordUsage(String modelId, String businessTag, String userId, TokenUsage usage, long latencyMs) { // 计算本次调用成本 BigDecimal cost = pricingTable.calculateCost( modelId, usage.getPromptTokens(), usage.getCompletionTokens()); // 记录带标签的指标，支持按维度聚合 Counter.builder("llm.tokens.prompt") .tag("model", modelId) .tag("business", businessTag) .tag("user", userId) .register(meterRegistry) .increment(usage.getPromptTokens()); Counter.builder("llm.tokens.completion") .tag("model", modelId) .tag("business", businessTag) .tag("user", userId) .register(meterRegistry) .increment(usage.getCompletionTokens()); Counter.builder("llm.cost.total") .tag("model", modelId) .tag("business", businessTag) .tag("user", userId) .register(meterRegistry) .increment(cost.doubleValue()); Timer.builder("llm.latency") .tag("model", modelId) .tag("business", businessTag) .register(meterRegistry) .record(latencyMs, TimeUnit.MILLISECONDS); // 成本超限检查 checkBudgetAlert(businessTag, cost); } /** * 预算告警检查 * 当业务标签的累计成本超过阈值时触发告警 */ private void checkBudgetAlert(String businessTag, BigDecimal incrementalCost) { // 通过 Micrometer 的累计值判断是否超预算 // 实际生产中应使用独立的预算追踪服务 double dailyCost = getDailyCost(businessTag); double budgetLimit = getBudgetLimit(businessTag); if (dailyCost > budgetLimit * 0.8 && dailyCost - incrementalCost.doubleValue() <= budgetLimit * 0.8) { // 首次超过 80% 预算时告警 log.warn("业务 [{}] 日成本已达预算的 80%, 当前: ${}, 预算: ${}", businessTag, dailyCost, budgetLimit); } if (dailyCost > budgetLimit) { log.error("业务 [{}] 日成本已超出预算! 当前: ${}, 预算: ${}", businessTag, dailyCost, budgetLimit); // 触发降级：可配置为自动切换到更便宜的模型或拒绝请求 } } private double getDailyCost(String businessTag) { // 从 Prometheus 查询当日累计成本 // 简化实现，生产环境应使用 Prometheus HTTP API 查询 return 0.0; } private double getBudgetLimit(String businessTag) { // 从配置中心获取业务预算限额 return 100.0; // 默认 $100/天 } }

模型定价表——成本计算的核心：

/** * LLM 模型定价表 * 维护各模型的 Token 单价，支持动态更新 * 定价数据来源：各模型供应商官网公开价格 */ @Component public class LlmPricingTable { private final ConcurrentHashMap<String, ModelPricing> pricingMap = new ConcurrentHashMap<>(); @PostConstruct public void init() { // 初始化模型定价（美元/千 Token） pricingMap.put("gpt-4o", new ModelPricing(0.005, 0.015)); pricingMap.put("gpt-4o-mini", new ModelPricing(0.00015, 0.0006)); pricingMap.put("gpt-3.5-turbo", new ModelPricing(0.0005, 0.0015)); pricingMap.put("claude-3.5-sonnet", new ModelPricing(0.003, 0.015)); } /** * 计算一次调用的成本 * * @param modelId 模型标识 * @param promptTokens 输入 Token 数 * @param completionTokens 输出 Token 数 * @return 成本（美元） */ public BigDecimal calculateCost(String modelId, long promptTokens, long completionTokens) { ModelPricing pricing = pricingMap.get(modelId); if (pricing == null) { log.warn("未找到模型定价: {}, 使用默认定价", modelId); pricing = new ModelPricing(0.001, 0.002); } BigDecimal promptCost = BigDecimal.valueOf(promptTokens) .multiply(BigDecimal.valueOf(pricing.promptPricePer1k)) .divide(BigDecimal.valueOf(1000), 6, RoundingMode.HALF_UP); BigDecimal completionCost = BigDecimal.valueOf(completionTokens) .multiply(BigDecimal.valueOf(pricing.completionPricePer1k)) .divide(BigDecimal.valueOf(1000), 6, RoundingMode.HALF_UP); return promptCost.add(completionCost); } /** * 动态更新模型定价（供应商调价时使用） */ public void updatePricing(String modelId, double promptPrice, double completionPrice) { pricingMap.put(modelId, new ModelPricing(promptPrice, completionPrice)); log.info("更新模型定价: modelId={}, prompt={}/1k, completion={}/1k", modelId, promptPrice, completionPrice); } record ModelPricing(double promptPricePer1k, double completionPricePer1k) {} }

Grafana 看板核心查询：

# 按业务分组的日成本趋势 sum by (business) (increase(llm_cost_total_total[1d])) # 单次调用平均成本 sum(increase(llm_cost_total_total[1h])) / sum(increase(llm_calls_total[1h])) # Prompt Token 与 Completion Token 比例（识别输入过长的异常） sum by (business) (increase(llm_tokens_prompt_total[1h])) / sum by (business) (increase(llm_tokens_completion_total[1h])) # P99 延迟趋势（延迟与成本的相关性分析） histogram_quantile(0.99, sum by (le) (rate(llm_latency_seconds_bucket[5m])))

四、估算误差与定价波动：成本监控的架构权衡

LLM 推理成本监控并非精确的财务系统，其固有的不确定性需要被正视。

第一，Token 计量的估算误差。对于不返回 Token 用量的模型供应商，客户端侧的 Token 估算存在 5%~15% 的误差。中文场景下，不同 Tokenizer（如 GPT-4 的 cl100k_base 与国产模型的自定义 Tokenizer）对同一文本的 Token 计数差异可达 20% 以上。如果成本监控的目的是精确计费，这种误差是不可接受的；但如果目的是趋势分析和异常检测，5%~15% 的误差在可接受范围内。

第二，模型定价的动态波动。模型供应商可能随时调整定价（如 OpenAI 在 2024 年多次下调 GPT-4 系列价格），而成本监控系统中的定价表可能滞后于实际调价。如果定价表未及时更新，监控数据将与实际账单产生偏差。解决方案是将定价表外部化到配置中心（如 Nacos），支持热更新，并建立定价变更的自动化同步机制。

第三，高基数标签的存储压力。Micrometer 的标签维度会直接影响 Prometheus 的存储开销。如果userId标签的基数达到百万级，Prometheus 的时序数据量将急剧膨胀。生产环境中，应对高基数标签进行采样或分桶处理（如将用户 ID 哈希到 100 个桶中），而非直接使用原始值作为标签。

适用边界：本方案适用于需要实时感知 LLM 调用成本趋势、识别成本异常和支持预算控制的场景。不适用于精确到分厘的财务计费——精确计费应基于供应商的官方账单数据，而非客户端侧的估算。