开篇答案
推理平台监控指标体系的搭建，核心不是追求指标数量，而是围绕“推理成本、响应速度、模型质量、资源利用率”四条主线，建立一套能定位问题、指导调优、预测趋势的闭环规则。
很多团队搭建监控体系时，容易陷入“什么都想监控”的误区，最后图表铺满大屏，但线上模型出问题定位要半小时，真正有效的监控体系，应该像给平台装一套“体检系统”，既要有常规体温血压，也要有专项检查,还要能根据历史数据预判风险。
围绕业务目标反推监控指标，而非先看工具能力
搭建监控体系的第一步，不是打开Prometheus或Grafana看能采集什么，而是回到业务场景问自己三个问题：这个推理平台支撑的是什么类型的应用？用户对延迟的容忍度是多少？模型输出的错误会带来多大损失？
一个支撑实时语音识别的平台，和另一个支撑离线批量图像生成的平台，监控重点完全不同，前者更关注P99延迟和并发连接数，后者更关注吞吐量和GPU利用率的平稳度，行业共识认为，监控指标必须从业务目标反推，否则采回来的数据只是“数字摆设”。
区分“关键指标”和“参考指标”
建议把指标分成两层，关键指标用于告警和SLA考核,参考指标用于问题排查和趋势分析。
- 关键指标：请求成功率、平均延迟、P99延迟、GPU显存占用率、推理错误率。
- 参考指标：CPU使用率、网络带宽、队列深度、模型加载耗时、卡顿次数。
这里有个实操技巧：在搭建初期，先只定义5到8个关键指标，跑通“采集-存储-展示-告警”全链路，再逐步增加参考指标，很多团队一上来接几十个指标，结果告警规则没配好，数据采集也有空洞,最后反而无从下手。
四条主线：成本、速度、质量、资源
推理平台与训练平台最大的区别在于“常驻服务”和“持续流量”，训练平台重吞吐，推理平台重稳定，以下四条主线的指标选择,直接决定监控体系是否好用。
推理成本指标：从单次请求计价到集群总开销
推理平台的花费往往不是一次性的，而是按天累计，监控时要同时关注单次推理成本和每日推理总成本，单次推理成本通常用“每千次请求消耗的GPU时数”或“单卡每小时处理的请求数”来衡量。
- 单请求GPU耗时：反映单次推理的算力消耗,异常升高可能意味着模型被篡改或输入异常。
- 集群空闲率：如果许多GPU长期空闲，但请求还在排队,说明调度算法需要优化。
- 成本趋势对比：按周维度对比单位成本变化,可以用于评估是否该切换推理引擎或量化模型。
这里常遇到一个场景：业务方反馈“最近推理费用涨了”，但看请求量没变，这时候如果监控里有“每请求GPU耗时”就能立刻定位，不是模型输入变长,就是推理框架的batch策略失效了。
响应速度指标：关注分布而非平均值
平均延迟很容易掩盖问题，假设平台平均延迟200毫秒，但P99延迟高达2秒，那对用户体验的影响其实很大，监控响应速度时,至少分三个维度看：
- 平均延迟：用于宏观趋势判断。
- P95/P99延迟：代表最差体验的那批用户,是告警的主要依据。
- 排队等待时间：反映请求从进入系统到开始推理的间隔，等待时间过长说明瓶颈不在推理本身,而在前置调度。
行业共识是不要只看平均延迟，P99延迟才是用户体验的“生命线”，设置告警时建议用“P99延迟连续5分钟超过阈值”触发,避免偶发抖动导致的误报。
模型质量指标：非功能监控中容易缺失的一环
推理平台不仅要快，更要准，监控指标体系里必须包含模型输出的质量信号，否则平台运行稳定，但效果变差,业务方往往最后一个知道。
常见的质量监控手段有三类：
- 显式验证：对线上请求做抽样回放，将推理结果与离线基线对比，计算准确率漂移，适用于分类、检测类模型。
- 隐式反馈：对生成式模型，监控输出长度、重复率、语义向量距离等指标,这些信号能间接反映生成质量。
- 输入分布漂移：监控线上输入数据的特征统计分布，与训练集或上线初期的分布进行对比，分布偏差大时,模型效果大概率下滑。
举个例子，一个智能客服平台，如果最近用户提问的文本长度明显变长，且关键词分布和训练集差异很大，那即使延迟和成功率都正常，也需要触发模型重训练提醒，这类场景,单靠基础设施监控无法发现。
资源利用率指标：精细到卡和线程
推理平台的资源监控需要比通用服务更细，通用web服务看CPU和内存即可，推理服务需要额外关注显存、GPU利用率、张量核心活跃度等。
- 显存占用率：长期高于90%有OOM风险，低于30%说明资源浪费,可以动态缩小副本数。
- GPU利用率：指计算单元的整体活跃程度，但注意，高利用率不一定代表高吞吐,还要看是否在等待数据。
- 批处理大小：实时监控当前批次大小，批次过小会增加调度开销，批次过大会提高延迟,需要平衡。
实操中，推荐使用nvml或dcgm-exporter采集GPU细粒度指标，很多推理平台的性能瓶颈其实在“数据复制”和“内核启动”上,单看GPU利用率容易误判。
搭建从零到一的监控架构：选型与路径
如果你是从0开始搭建推理平台监控，不必追求大而全,先走通下面这条路。
第一步：用现成技术栈快速上线基础监控
对于大部分团队，开源组合“Prometheus + Grafana + Alertmanager”仍然是最稳妥的起点，原因有三：文档多、社区活跃、与大部分推理框架有官方集成。
- 部署node_exporter采集主机CPU、内存、磁盘。
- 部署dcgm-exporter采集NVIDIA GPU的利用率、显存、温度、功耗。
- 推理框架侧暴露/metrics端点，例如Triton Inference Server原生支持prometheus指标。
以Triton为例，在server启动参数中追加--metrics-port=8002，然后配置文件里加一行scrape配置即可看到nv_inference_request_duration_us等关键指标,这个操作10分钟以内可以完成。
第二步：建设日志追踪体系，补充指标的盲区
指标本身是聚合后的数字，无法还原单个请求的完整链路，需要接入分布式追踪，比如OpenTelemetry，对于推理平台,重点记录四个阶段的时间戳：
- 请求到达网关的时间点
- 调度器开始分配资源的时间点
- 模型推理开始的时间点
- 推理完成并返回结果的时间点
有了这四个时间点，你可以计算调度耗时、推理耗时、网络耗时，当P99延迟升高时，能立刻判断是前三个的哪一个环节“变慢”了，我见过很多团队为了省事只记录最终总延迟,出了问题根本没法分锅。
第三步：定义告警规则时区分“故障”与“恶化”
告警的价值不在于叫醒运维，而在于提供可执行的线索，一条好的告警信息应该能说明“什么东西，在什么条件下，偏离预期多少”，避免把所有指标都设置固定阈值,可以尝试服务端口的动态基线算法。
对于请求成功率，固定阈值“低于99%告警”在低峰期可能合适，高峰则过于敏感，更好的做法是用过去7天同一时间段的成功率均值作为基线，偏离超过2%才告警，虽然这个动态基线需要一些存储和计算成本,但对减少深夜误报很有帮助。
针对不同场景的指标组合策略
不同业务场景下，监控指标的侧重点和阈值完全不同，下面给出三个典型场景的指标组合,方便直接套用。
在线实时推荐系统
这类系统对延迟极其敏感,但每路请求的数据量小。
- 核心指标：P99延迟（小于150毫秒）、请求成功率、GPU利用率。
- 辅助指标：特征缓存命中率、推理输出归一化置信度。
- 特殊关注：跨可用区调用的网络往返时延,推荐系统常因跨机房导致延迟突增。
大规模离线批量推理任务
比如批量生成商品描述或OCR大批量文档，这类任务不要求实时性,但要求成本可控。
- 核心指标：吞吐量（每分钟处理样本数）、平均单样本成本、队列积压量。
- 辅助指标：GPU算力利用率、批大小、数据读取耗时。
- 特殊关注：数据倾斜问题，即某些分片输入耗时异常长,导致其他GPU等待。
大语言模型对话服务
这类服务最头疼的问题是“没有标准答案”,质量指标难以量化。
- 核心指标：首token延迟、生成token的每秒吞吐（TPS）、显存占用峰值。
- 辅助指标：输出截断率、重复生成比例、请求级拒绝率。
- 特殊关注：上下文长度分布，多数情况下，请求上下文越长,显存和延迟呈超线性增长。
如果你正在对比如何选择推理平台的监控工具，建议优先考虑与现有技术栈匹配度高的方案，比如团队擅长Python和Kubernetes，就选Prometheus+自定义exporter；如果是深度使用AWS SageMaker，可以考虑SageMaker内置的Model Monitor。
从监控到治理：指标如何反哺平台优化
监控只是手段，最终目的是让推理平台更稳、更快、更省，可以建立每周一次“监控复盘”机制,每次只挑一到两个最突出的问题进行分析。
假设当前监控发现某型号GPU的利用率一直在60%左右，而显存已经接近极限，结合推理日志发现，模型为动态输入shape分配了过大的显存buffer，这时候可以将模型导出时固定到一个统一的max_sequence_length，显存占用下降15%，同时可以提升批量大小，让GPU利用率升到85%以上，这个优化动作的收益,可以通过监控曲线清晰地看到。
另一个常见优化路径是基于成本指标的弹性伸缩，监控中如果发现“集群空闲率”在不满足SLA的时段超过40%，可以配置定时缩容副本数，或者将部分流量转移到价格更低的实例上，据行业统计，这类基于监控数据的调度优化，能让推理平台的总成本降低20%至30%,但每个团队的真实收益取决于负载模式。
长期演进：从单点监控到全链路智能分析
成熟推理平台的监控体系，最终会走向“指标+日志+追踪”三合一的数据平台，在此基础上，通过简单的规则引擎或机器学习模型,实现根因分析。
一个现实路径是：
- 先用指标覆盖“系统健康度”。
- 再用日志覆盖“失败原因”。
- 然后用追踪覆盖“延迟分布”。
- 最后将三者数据关联到“业务绩效”,比如用户留存与推理延迟的关联分析。
这个演进周期可能持续一两年，对于刚开始搭建的团队，不需要提前设计太复杂的关联关系，先把前三步做扎实，未来想提升监控智能化水平时,基础数据已经准备好了。
Q&A：推理平台监控指标常见疑惑
如何设置推理平台监控阈值的初始值？
优先从业务SLA反推，如果业务要求95%的请求在300毫秒内完成，那么初始阈值设为“P99延迟300毫秒”就是合理的，如果没有明确SLA，可以先采一周数据，找出指标的自然分布，将“正常值的2到3倍”作为告警阈值,后续根据一两次真实故障的表现再做微调。
监控指标采集频率选择多少合适？
通用主机指标15秒采集一次，GPU细粒度指标5秒采集一次即可，对于P99延迟这类聚合指标，建议在推理框架侧按10秒窗口计算一次，而不是从原始请求日志里实时聚合，采集频率过高会引入额外开销,甚至挤占推理任务的CPU和内存资源。
推理平台监控与训练任务监控有什么关键区别？
训练任务通常有一个明确的起止时间，监控侧重于长时间稳定性和资源占用峰值；推理平台是常驻服务，监控必须关注延迟分布、请求成功率和每日成本，训练任务出现故障可以回滚重启，推理平台出现异常直接面向终端用户,所以对告警实时性和准确性要求更高。