推理服务看哪些监控指标？新手版入门

一个 AI 推理服务上线只是第一步，跑起来之后健不健康，要靠数字说话。监控指标就是服务的仪表盘：不用逐个翻日志，看几项关键数字就能判断当前是正常、变慢还是快要出事。

盯住四个关键数字

新手先记四个：响应延迟、吞吐量、错误率、资源占用。延迟回答「用户等多久」，吞吐回答「单位时间能处理多少」，错误率回答「多少请求失败」，资源占用回答「机器还剩多少余量」。四个数字各管一摊，合起来就是服务的全貌。

每个数字背后说明什么

数字本身不是终点，要会读背后的信号。延迟突然升高，可能是请求排队变长，也可能是后端调用变慢；错误率抬头，先看是集中在某类请求还是全面出现；资源占用持续逼近上限，说明该扩容了。以一个接入智谱清言做对话的服务为例，如果错误集中出现在长文本请求上，多半是上下文超限，而不一定是机器不够。

读数还要讲究口径：延迟要看分位数而不是平均值，平均值会把少数极端请求藏起来；吞吐要和延迟放在一起看，牺牲延迟换吞吐的做法对交互类服务并不合适。

告警阈值怎么定

阈值定太松，出事了警报不响；定太紧，天天误报让人麻木。实用的做法是从历史数据出发：取正常时段的分位数作基准，阈值设在基准之上留少量余量，再根据误报情况微调。告警要附带处理提示，半夜被叫醒的人应该一眼知道先查什么。

看板怎么搭不迷路

看板并非指标越多越好，而是分层次：顶层放四个关键数字的健康状态，中层放分接口的分位数延迟与错误分布，底层留给排查细节的原始曲线。发现异常往下钻，一层层定位。数字异常但说不清原因时，结合容量规划检查是不是资源到顶；钱花得多但服务没起色，用成本归集对账；计费方式影响余量判断，见预留与按量；低成本承接突发流量可了解竞价实例。无论对接讯飞星火还是自建模型，这套读数方法通用。

新手常问：这些数字去哪里看？两条路：一是推理框架自带的指标接口，主动暴露延迟、队列长度等核心数据；二是平台的监控服务，负责长期存储和画图。自己搭时别重复造轮子，框架给的原始指标加上现成的看板工具，半天就能立起来。真正花时间的反而是梳理口径——同一家团队里，张说的延迟是发出到返回，李说的是模型计算时间，数字对不上，报警阈值也定不准。

还有一个实用习惯：给每次发布和配置变更打时间标记，看曲线时把标记叠加上去。指标突变时一眼就能对上「是不是昨晚那次更新引起的」，排查效率完全不同。数据只有放到事件的时间线上，才能从曲线变成线索。

监控指标速查表

• 四个关键数：延迟、吞吐、错误率、资源占用
• 读数口径：延迟看分位数，别只看平均值
• 阈值来源：历史正常分位数加少量余量
• 看板分层：健康总览、分接口明细、原始曲线

带走一句：看板是给人看的，能在十秒内回答「服务正不正常」的看板才是好看板。

另外提醒一句：指标会骗人，组合起来才不会。单看错误率下降，可能是因为流量本身变小了；单看延迟平稳，可能是因为排队的人已经被挡在门外。任何单项指标下结论之前，先想想有没有别的数字能交叉验证。

关于监控指标，问得最多的三个

• 延迟和吞吐哪个更重要？：交互类服务优先保延迟，离线批任务优先保吞吐，按业务性质定主次。
• 指标要采多密？：健康指标秒级到十秒级足够，细节曲线可以放宽到分钟级，采样太密徒增存储开销。
• 告警太多大家都不看了怎么办？：合并同类告警、提高触发门槛，只留真正需要人动手的，其余进日报。