AI 服务可观测性体系建设：Token 粒度指标采集与智能告警实践

AI 服务可观测性体系建设Token 粒度指标采集与智能告警实践一、AI 服务黑箱运行的可观测性缺口传统微服务的可观测性体系围绕请求延迟、错误率和吞吐量RED 指标构建但 AI 服务引入了全新的观测维度Token 消耗量、首 Token 延迟、上下文窗口利用率、模型推理耗时占比。这些指标直接关联成本和用户体验却往往被传统监控体系忽略。生产环境中常见的痛点包括Token 账单月末暴增却无法定位到具体业务线、流式响应的首 Token 延迟从 200ms 劣化到 2 秒但告警未触发、某个 Prompt 模板消耗的 Token 量是平均值的 5 倍却无人察觉。这些问题的根源是 AI 服务缺乏 Token 粒度的可观测性需要建立专门的指标体系和告警策略。二、AI 服务可观测性三层指标模型AI 服务的可观测性需要从传统 RED 指标扩展到覆盖成本、质量和性能的三层模型。flowchart TB A[AI 服务可观测性体系] -- B[成本层 - Token 粒度] A -- C[质量层 - 输出评估] A -- D[性能层 - 延迟与吞吐] B -- B1[输入 Token 数] B -- B2[输出 Token 数] B -- B3[Token 单价成本] B -- B4[按业务线/模型/模板聚合] C -- C1[输出空响应率] C -- C2[内容审核拒绝率] C -- C3[用户反馈评分] C -- C4[幻觉检测命中率] D -- D1[首 Token 延迟 - TTFT] D -- D2[Token 生成速率 - TPS] D -- D3[请求排队等待时间] D -- D4[并发连接数 vs 供应商 QPS 上限] B1 -- E[告警策略] B3 -- E C2 -- E D1 -- E D3 -- E E -- F[Token 成本异常 - 日环比超 30%] E -- G[首 Token 延迟 - P99 3s] E -- H[审核拒绝率 - 5%] E -- I[排队超时 - 10s] style A fill:#339af0,color:#fff style E fill:#ff922b,color:#fff三、Token 粒度指标采集与告警实现/** * AI 服务指标采集器 - Token 粒度 * 设计目的在每次大模型调用后采集 Token 消耗和延迟指标按多维度聚合 * 为什么用 Micrometer 的 Counter/Gauge/Timer 而非自定义日志 * Micrometer 与 Prometheus/Grafana 生态无缝集成 * 自动处理指标聚合、采样和导出避免重复造轮子 */ Component Slf4j public class AiMetricsCollector { private final MeterRegistry registry; public AiMetricsCollector(MeterRegistry registry) { this.registry registry; } /** * 记录一次大模型调用的完整指标 * 为什么用 Tags 而非 Label 值做维度 * Tags 是 Micrometer 的维度抽象高基数维度如 requestId * 必须排除否则会导致 Prometheus 时间序列爆炸 */ public void recordLlmCall(LlmCallRecord record) { // Token 消耗指标 - 按业务线、模型、Prompt 模板聚合 Counter.builder(ai.token.input) .tag(business, record.getBusinessLine()) .tag(model, record.getModel()) .tag(template, record.getPromptTemplate()) .register(registry) .increment(record.getInputTokens()); Counter.builder(ai.token.output) .tag(business, record.getBusinessLine()) .tag(model, record.getModel()) .tag(template, record.getPromptTemplate()) .register(registry) .increment(record.getOutputTokens()); // Token 成本指标 - 按模型单价计算 double costUsd calculateCost(record.getModel(), record.getInputTokens(), record.getOutputTokens()); Counter.builder(ai.cost.usd) .tag(business, record.getBusinessLine()) .tag(model, record.getModel()) .register(registry) .increment(costUsd); // 首 Token 延迟 if (record.isStreamMode() record.getFirstTokenLatencyMs() 0) { Timer.builder(ai.latency.first_token) .tag(model, record.getModel()) .tag(business, record.getBusinessLine()) .register(registry) .record(record.getFirstTokenLatencyMs(), TimeUnit.MILLISECONDS); } // 总推理延迟 Timer.builder(ai.latency.total) .tag(model, record.getModel()) .tag(business, record.getBusinessLine()) .tag(stream, String.valueOf(record.isStreamMode())) .register(registry) .record(record.getTotalLatencyMs(), TimeUnit.MILLISECONDS); // 质量指标 if (record.isContentRejected()) { Counter.builder(ai.content.rejected) .tag(business, record.getBusinessLine()) .tag(model, record.getModel()) .register(registry) .increment(); } if (record.isEmptyResponse()) { Counter.builder(ai.response.empty) .tag(business, record.getBusinessLine()) .tag(model, record.getModel()) .register(registry) .increment(); } } /** * 按模型单价计算调用成本 * 为什么将单价配置外部化而非硬编码 * 供应商调价频繁硬编码需要重新部署 * 外部配置可以在不重启服务的情况下更新单价 */ private double calculateCost(String model, int inputTokens, int outputTokens) { ModelPricing pricing ModelPricingRegistry.getPricing(model); if (pricing null) { log.warn(未找到模型 {} 的定价配置使用默认单价, model); pricing ModelPricingRegistry.getDefaultPricing(); } // Token 数除以 1000 得到千 Token 单位 double inputCost (inputTokens / 1000.0) * pricing.getInputPricePer1k(); double outputCost (outputTokens / 1000.0) * pricing.getOutputPricePer1k(); return inputCost outputCost; } }智能告警规则配置# Prometheus 告警规则 - AI 服务专用 groups: - name: ai_service_alerts rules: # Token 成本日环比异常 # 为什么用环比而非绝对值阈值 # 绝对值阈值需要随业务增长持续调整 # 环比异常能自适应业务增长只关注突变 - alert: AiTokenCostSpike expr: | ( sum(increase(ai_cost_usd_total[1d])) / sum(increase(ai_cost_usd_total[1d] offset 1d)) ) 1.3 for: 1h labels: severity: warning annotations: summary: AI Token 成本日环比增长超过 30% description: 当前日成本 {{ $value | printf %.1f }} 倍于昨日同期 # 首 Token 延迟 P99 超标 - alert: AiFirstTokenLatencyHigh expr: | histogram_quantile(0.99, sum(rate(ai_latency_first_token_seconds_bucket[5m])) by (le, model) ) 3 for: 5m labels: severity: critical annotations: summary: 首 Token 延迟 P99 超过 3 秒 description: 模型 {{ $labels.model }} 的首 Token P99 延迟为 {{ $value }}s # 内容审核拒绝率异常 - alert: AiContentRejectionHigh expr: | ( sum(rate(ai_content_rejected_total[10m])) / sum(rate(ai_latency_total_seconds_count[10m])) ) 0.05 for: 10m labels: severity: warning annotations: summary: 内容审核拒绝率超过 5% description: 当前拒绝率 {{ $value | printf %.2f }}可能存在 Prompt 模板问题四、AI 可观测性体系的边界与成本权衡高基数维度的 Prometheus 压力如果将 requestId、userId 等高基数维度作为 Tag每个唯一值都会创建一条时间序列。在日调用量百万级的系统中这会导致 Prometheus 内存暴涨和查询超时。解决方案是只保留低基数维度business/model/template作为 Tag高基数维度通过日志关联在日志中记录 requestId通过 Trace ID 关联指标和日志。Token 计数的精度问题大模型 API 返回的 Token 计数基于其分词器Tokenizer不同模型的分词器对同一文本的 Token 计数可能差异 20% 以上。跨模型对比 Token 消耗时需要考虑分词器差异否则成本分析会产生误导。质量指标的采集延迟内容审核拒绝率可以实时采集但用户反馈评分和幻觉检测需要人工标注或异步评估存在数小时到数天的延迟。告警策略需要区分实时指标和延迟指标避免对延迟指标设置过短的 for 窗口。可观测性本身的资源成本Token 粒度指标采集会增加 1~2ms 的调用延迟和约 5% 的内存开销。在极低延迟场景如实时对话中可以考虑异步采集将指标写入内存队列由后台线程批量上报但会牺牲指标的实时性。五、总结AI 服务的可观测性需要从传统 RED 指标扩展到覆盖成本Token 消耗、质量输出评估和性能延迟与吞吐的三层模型。Token 粒度指标是 AI 可观测性的核心差异化能力通过按业务线、模型、Prompt 模板多维度聚合可以实现成本归因和异常定位。告警策略应优先使用环比异常检测成本突变用 P99 延迟监控性能劣化用比率指标监控质量下降。落地建议先建立 Token 消耗和首 Token 延迟的基线指标再逐步引入质量指标和成本告警维度设计上严格限制高基数 Tag通过日志关联补充细粒度查询能力指标采集优先同步模式保证实时性在延迟敏感场景再考虑异步优化。