——不是死在进程里就叫活着凌晨两点业务方的电话把你从床上拽起来你们的AI客服疯了用户问天气它回了一段菜谱。你揉着眼睛登上服务器看了眼仪表盘——绿的一片CPU 12%内存 40%GPU利用率 8%。服务在跑进程没崩端口也通。模型死了三个小时你的告警一条没响。这不是故事这是我们组去年Q3复盘报告里白纸黑字写着的真实故障。模型服务到底难在哪你管过MySQL、Redis、Kafka那套监控思路印在脑子里服务不响应看进程进程在但慢看CPU和IOCPU不高看连接数和锁。但模型服务把这些经验全砸碎了——服务活着不等于模型在工作。vLLM、TGI、Ollama这些推理框架只要你启动了HTTP接口就会返回200哪怕模型推理已经彻底卡死或者输出全是乱码。你盯着服务可用率99.9%的曲线觉得一切正常但用户看到的是一个接一句的废话。回答质量变差不等于有错误。模型不会抛异常它只是在努力给出一个答案——这个答案可能离题万里可能逻辑混乱但HTTP状态码是200进程也没报错。传统监控基于状态码和异常日志的方式在这里完全失效。慢得像没事。有些模型退化是渐进式的P99延迟从800毫秒爬到15秒每秒吞吐量从200 token掉到30用户以为在加载你以为是网络抖动。三个真实踩过的坑第一个坑只看服务活着不看回答质量。我们上线第一版监控时用最朴素的方式探测HTTP端口响应200就标记正常。三个月后才发现模型在某些异常输入下会进入复读模式——对任何问题都循环输出同一句话HTTP状态码还是200。业务方反映AI客服疯了我们这边仪表盘一片绿整整两小时后才被二次投诉暴露。第二个坑没盯延迟分位数只看平均值。平均响应时间300毫秒看起来很健康。但P99是8秒P999是47秒——真实用户感受到的不是平均值是那个最慢的请求。某次流量突增导致排队积压平均延迟几乎没变化但P999从20秒跳到了90秒大量用户以为服务挂了。我们事后加了延迟分位数告警才看见这个坑。第三个坑告警淹没在噪音里。这个最要命。上线初期我们设了CPU80%告警、GPU90%告警、显存85%告警听起来很全。结果是白天开发测试流量一冲CPU瞬间破80一晚上告警几百条值班人员两小时后直接设置了消息免打扰——然后真正的故障告警也进免打扰了直到业务方打电话才知道。阈值太松漏报阈值太紧噪音两者之间没有标准答案只有反复调参。务实要盯的四个指标结合业界实践和我们的生产经验以下四个指标是模型服务监控的最小集合值得每个运维认真盯第一可用性不是端口可用是请求成功且回答有效。建议在探测接口里放一个标准Prompt预期答案包含特定关键词或满足格式校验连续3次失败才触发告警。这比HTTP探测贵一点但能抓住服务活着但脑子坏了的情况。第二P99延迟不是平均值。你需要分别盯住P50、P99、P999三个分位点建议告警阈值按分位点梯度设置P505秒预警P9915秒正式告警P99960秒升级。为什么要梯度因为P999触及的用户少但痛感强不能和普通慢请求混为一谈。第三异常回答率。定义你自己的异常连续重复超过N个字符、回答长度低于某个阈值、包含特定乱码pattern、格式校验失败。这个指标没有通用标准你得自己定义模型正常工作时应该长什么样。我们目前用的是有效回答率抽检5%的请求LLM判断回答是否相关低于85%触发告警。第四显存占用和碎片率。显存泄漏在模型服务里是慢性杀手进程不崩溃但每次请求分配一点显存不释放直到OOM被容器kill掉。建议监控显存使用趋势而非单点值如果连续两小时显存只涨不跌哪怕还没OOM也要预警。另外注意显存的显存碎片率vLLM里碎片率超过30%会导致有效显存利用率大幅下降。给运维的真心话模型服务的监控没有银弹没有一套模板拿来就用。你们的模型不同、框架不同、业务对正常的定义也不同。这篇文章里的指标和建议是踩坑踩出来的参考不是标准答案。真正有用的是两件事一是尽快建立你们自己的正常基线这需要在上线后持续观察数据而不是第一天就定好阈值二是让业务方参与告警策略的制定——他们对回答质量的感知往往比你仪表盘上的数字更灵敏。最后一句话别相信服务在跑就等于服务正常。这个行业里沉默的故障比崩溃的故障更常见也更危险。本文基于公开技术资料与行业实践整理不构成具体产品选型或部署方案建议。
