当大模型完成微调、压缩并部署为推理服务后，服务是否稳定、体验是否流畅、成本是否可控，都需要通过量化指标来判断。模型服务监控的核心价值，就是用一套明确的指标体系，让推理服务的运行状态从 “模糊感知” 变成 “精准可控”。
一、推理服务的仪表盘
大模型推理服务的问题（比如响应慢、失败多），往往不会直接 “报错”，而是藏在细节里：
- 用户觉得 “服务变卡了”，可能是首 token 时延从 100ms 涨到了 500ms；
- 业务成本突然上升，可能是调用 tokens 量翻倍增长；
- 部分请求没结果，可能是调用失败率从 0.1% 升到了 5%。
没有量化指标，就只能 “凭感觉运维”；而模型服务监控的指标体系，正是让服务状态 “可视化、可追溯、可优化” 的关键。
二、3类核心指标
模型服务监控的指标可分为「可靠性」「性能」「成本」三类，每一项都对应具体的业务目标：
（一）可靠性指标：保障服务能用
1. 服务调用量
- 定义：统计时间范围内服务被调用的总次数
- 计算方式：请求总数累加
- 业务价值：
- 反映服务的业务热度（调用量越高，业务依赖越强）；
- 是资源扩容 / 缩容的核心依据（调用量突增需及时加实例）。
2. 调用失败率
- 定义：服务调用失败的比例
- 计算方式：
（调用失败次数 ÷ 调用总次数） × 100% - 业务价值：
- 直接体现服务可靠性（失败率＞1% 需警惕）；
- 结合 “调用失败明细”，可定位问题（如请求格式错误、模型加载失败）。
（二）性能指标：保障服务好用
1. 平均首 token 时延
- 定义：流式响应场景下，从请求发起→输出第一个 token 的平均耗时
- 计算方式：
（所有成功请求的首token耗时之和） ÷ 成功请求次数 - 业务价值 ：
- 直接影响用户 “等待感”（首 token 时延＞200ms 会感知卡顿）；
- 若突增，需优化模型推理速度或增加算力资源。
2. 平均响应时间
- 定义：成功请求的整体响应时间平均值（仅统计成功请求）
- 计算方式：
（所有成功请求的总耗时之和） ÷ 成功请求次数 - 业务价值：
- 反映服务的整体性能（响应时间＞1s 需优化）；
- 若持续升高，需排查请求复杂度、资源负载等问题。
3. 整句时延
- 定义：从请求发起→整句输出完成的平均耗时（非流式场景）
- 计算方式：
（所有成功请求的整句耗时之和） ÷ 成功请求次数 - 业务价值：
- 体现非流式场景的完整服务效率；
- 若过高，可能是模型推理慢或输出内容过长。
（三）成本指标：保障服务划算
1. 调用 tokens 量
- 定义：统计时间范围内，所有请求的输入 + 输出 tokens 总数
- 计算方式：输入 tokens 数累加 + 输出 tokens 数累加
- 业务价值：
- tokens 是大模型推理的 “成本单位”，直接关联算力开销；
- 若突增，需排查是否有超长输入 / 输出请求。
2. 平均输入 / 输出 tokens 量
- 定义：单次成功调用的平均输入 / 输出 tokens 数
- 计算方式：
成功请求的输入/输出tokens总数 ÷ 成功请求次数 - 业务价值 ：
- 反映单请求的资源消耗；
- 若平均输出 tokens 过高，可通过 prompt 优化控制输出长度。
三、指标怎么用？从监控到优化的闭环
指标不是 “看个数字”，而是要形成发现问题→定位根因→优化服务的闭环：
1.看趋势：通过折线图观察指标变化（比如调用失败率从 0.5% 涨到 8%）；
2.找异常：定位指标突变的时间点（比如失败率突增发生在 “模型更新后”）；
3.查明细：查看对应时间段的 “调用失败明细”，看具体请求的错误信息；
4.做优化：
- 首 token 时延高→增加推理实例；
- 输出 tokens 多→调整 prompt 约束长度；
- 失败率高→修复模型接口。
模型服务监控的本质，是用 “数据” 替代 “感觉”—— 通过这一套指标体系，既能守住服务的稳定性，也能在用户体验与推理成本之间找到最优解。