判断在线推理是否需要扩容，单看显卡利用率很容易误判。AI推理实例显卡利用率监控指标应与显存占用、请求等待队列和服务延迟一起观察：利用率低，可能是请求不足，也可能是队列、数据传输或并发配置出了问题。
监控哪些指标，分别回答什么问题
利用率：看计算单元是否持续工作
记录每张卡的利用率，并与同一时间段的请求量、成功处理量对照。利用率长期偏低且请求量也低，通常表示供给有余；利用率偏低但队列增长，则应先检查请求是否卡在预处理、网络传输或调度环节。短时尖峰不等于容量不足，需观察数分钟至数十分钟的趋势。
显存：同时看已用、剩余和变化
采集显存总量、已用量与可用量，按设备或进程拆分更便于定位。已用显存持续上升、可用空间逐渐减少，可能与模型常驻、并发增加或缓存变化有关；若出现分配失败，应结合错误日志和请求规模判断。显存占用高不必然代表计算繁忙，也不能仅凭一个百分比判断需要换卡。
等待队列：观察积压及等待时间
记录待处理请求数、排队时长、请求延迟和超时或失败数量。队列持续增长而处理量没有同步增加，说明到达速度超过了当前处理能力，或请求分配不均。以 NVIDIA Triton Inference Server 为例，可结合其 Prometheus 指标观察推理请求、排队时间及执行时间；具体指标名称和可用性应按服务版本核对。
把指标放进同一张时间线上
AI推理实例显卡利用率监控指标要与业务指标使用一致的时间窗口。建议从 15 秒至 1 分钟的采集间隔起步，再按告警响应要求调整；采样过疏会漏掉短暂拥塞，过密则增加监控存储和查询负担。面向用户的请求延迟可同时查看中位数与较高分位数，例如 P95，避免平均值掩盖少量慢请求。
- 利用率高、队列增加、延迟上升：计算容量可能吃紧，可检查并发上限、批处理配置与实例数。
- 利用率低、队列增加：检查请求路由、预处理耗时、线程或进程阻塞，以及是否有单卡热点。
- 利用率高、队列稳定：若延迟仍满足服务目标，不必仅为降低利用率而扩容。
- 显存接近上限、错误增多：核查模型加载、并发请求和显存分配日志，再评估降低并发或增加显存容量。
从采集到告警的可执行步骤
- 先列出服务目标：最大可接受延迟、超时率和预计请求峰值，并确认统计口径。
- 在主机侧启用显卡遥测采集；NVIDIA 环境可使用 DCGM Exporter 配合 Prometheus，Grafana 用于展示趋势。其他硬件应选用对应厂商支持的遥测工具。
- 从推理服务采集请求量、队列长度、排队时长、执行时长和错误数，并用实例、设备等标签关联数据。
- 制作同一时间轴的看板，至少展示每卡利用率、显存余量、队列长度、P95 延迟和错误率。
- 按服务目标设置告警：例如队列连续多个采样周期增长且 P95 超过目标时通知；显存告警则依据设备余量和历史波动设阈值，不套用所有型号通用的固定百分比。
告警应有持续时间和恢复条件，避免一次采样抖动反复触发。上线后用真实流量回看告警是否早于用户延迟恶化，并根据实际峰值调整阈值。
常见问题
显卡利用率达到 100% 就必须扩容吗？
不一定。若队列和延迟稳定且满足服务目标，可能无需扩容；若队列持续增长、延迟超标，再评估增加实例或调整推理配置。
为什么利用率低，用户仍觉得响应慢？
请求可能耗在排队、网络、预处理或应用层。应对照排队时长、执行时长和端到端延迟，定位耗时所在环节。
AI推理实例显卡利用率监控指标多久采集一次？
可先按 15 秒至 1 分钟采集，再根据流量变化和告警时效调整；设备规模、监控开销及服务目标都会影响选择。
