模型服务监控必须同时盯住延迟、吞吐、错误率三条主线，再辅助资源利用率与饱和度指标，线上推理服务才不会在最忙的时候突然崩掉。 延迟决定单次体验，吞吐决定扛不扛得住流量，错误率决定系统是否健康，这三类指标任何一项失守，模型服务就会从“智能助手”变成“用户流失加速器”，下面把每个维度拆开说透。
模型服务监控指标有哪些？延迟吞吐错误率是三条主线
很多人一上来就盯着GPU利用率,觉得卡没跑满就没事，真实情况是：GPU利用率高不代表用户体验好，利用率低也不代表系统没瓶颈。模型服务监控指标有哪些需要从用户感知出发，而不是从硬件出发。
延迟指标：用户等的是完整故事
延迟在模型服务里不像传统后端一个数字就能说明白,大模型推理延迟拆成三段才有意义：
- 首token延迟（TTFT）：用户发出请求到第一个token出现的时间，这个值直接影响“模型有没有卡住”的心理感受。
- 每输出token延迟（TPOT）：生成过程中每个token之间的平均间隔，它决定文字是“流出来”还是“蹦出来”。
- 总延迟：从请求发出到完整响应结束，转人工、超时重试、客户端断连都跟它直接相关。
监控面板上至少要记录P50、P95、P99三个分位数，平均延迟会掩盖尾延迟，而大模型推理延迟多少算正常往往取决于P95和P99，不是平均值，行业共识认为，尾延迟一旦比中位数高出数倍，就说明队列积压或资源争抢已经出现，用户端会表现为偶发卡顿。
吞吐指标：扛流量的底气
吞吐量通常用QPS（每秒请求数）或TPS（每秒处理token数）表示，模型服务里更建议同时看两个：
- 请求级吞吐：每秒能完成多少次推理请求，压测时直接反映服务容量。
- token级吞吐：每秒生成多少token，不同输出长度的请求混在一起时，token级吞吐更能反映真实计算量。
只看QPS不看TPS,容易被短输出请求“刷高”吞吐假象，比如大量“你好”这种短prompt能把QPS打得很高，但真实生成能力未必强，反过来，长文本摘要场景token级吞吐很低，QPS也不高，但不一定是性能问题。
错误率指标：别只看HTTP 500
模型服务错误率比传统API复杂,常见的错误类别包括：
- HTTP 4xx：参数格式错误、鉴权失败、输入超限，这些多数是调用方问题，但也要监控比例，防止某类客户端bug打爆服务。
- HTTP 5xx：服务端内部错误，比如推理进程崩溃、模型加载失败、OOM。
- 超时错误：请求在队列里等太久，或推理耗时超过设定上限，这类错误最常见也最容易被忽略。
- 模型侧异常：token生成被内容安全策略截断、停止条件未触发、输出为空，这些不会体现在HTTP状态码上，但用户看到的是“答非所问”或“没写完”。
错误率监控需要按错误类别拆分,不能一个总错误率糊过去，总错误率从0.5%涨到1%可能不报警，但如果超时错误占比从10%涨到60%，服务其实已经在排队雪崩边缘。
辅助指标：饱和度与资源
延迟、吞吐、错误率是“果”，资源利用率和饱和度是“因”，辅助指标包括：
- GPU利用率、显存占用、功率
- 请求队列长度、排队时间
- 模型加载/卸载次数、冷启动时长
- 网络带宽、CPU、内存
- 并发连接数、活跃会话数
这些指标的作用是解释三条主线为什么波动,比如延迟突然升高，先看队列长度和GPU利用率，往往能立刻定位是流量突增还是显存碎片。
大模型推理延迟多少算正常？先拆开延迟的四个变量
“大模型推理延迟多少算正常”没有统一答案，但它有清晰的拆解框架，影响推理延迟的主要变量是四个：
模型参数量与架构
参数越大,单次前向计算越重，7B和70B模型在同一张卡上，延迟差距可能达到一个数量级，MoE架构虽然总参数大，但激活参数少，延迟特性跟密集模型不同，监控时要把模型版本和参数量作为标签打在每个指标上，否则版本切换后延迟变化无法归因。
输入输出token长度
输入token多,prefill阶段耗时增加；输出token多，decode阶段耗时线性上升，很多聊天请求输入几百token、输出几十token，延迟大头在prefill；而代码生成、长文总结场景输出可能上千token，总延迟被decode拖长。
硬件与推理框架
同一模型在A100、H100、国产加速卡上的延迟差异非常明显，推理框架也关键：vLLM、TensorRT-LLM、SGLang的调度策略不同，连续批处理、PagedAttention、投机采样都会改变延迟分布，验收模型服务时，应该在同一硬件和框架组合下压测，拿到基线数据。
并发压力与调度策略
延迟和并发不是线性关系,低并发下延迟接近理论最优值，并发一旦超过某个拐点，队列开始堆积，延迟会快速上升。吞吐量和延迟的区别是什么也在这里体现：继续加压可能让吞吐微弱上升，但延迟已经翻倍甚至更多，线上容量规划要找到延迟可接受前提下的最大吞吐点，而不是把吞吐压到极限。
实操上,你可以按下面步骤建立自家模型的延迟基线：
- 固定硬件、模型版本、推理框架版本。
- 准备三组测试集：短prompt（<100 token输入，<50输出）、中prompt（500左右输入，200输出）、长prompt（2000+输入，500+输出）。
- 从低并发开始压测,每次增加并发，记录P50/P95/P99和吞吐。
- 画出“并发-延迟-吞吐”曲线，找到延迟拐点。
- 把拐点设置在容量告警阈值的80%位置，留出突发余量。
吞吐量和延迟的区别是什么？用一张表说清楚
很多团队把吞吐量和延迟混为一谈,监控面板上只看QPS，结果延迟恶化没人发现。
吞吐量和延迟的区别是什么其实很直接：
| 维度 | 延迟 | 吞吐 |
|---|---|---|
| 衡量对象 | 单个请求从到达到完成的耗时 | 单位时间系统完成的请求数或token数 |
| 单位 | 毫秒、秒 | QPS、TPS、token/s |
| 用户体感 | 直接感受到“快不快” | 不直接感受，但决定高峰期是否排队 |
| 优化方向 | 减少单次计算量、加速推理、降低队列等待 | 提升并行度、提高显存利用率、增加实例数 |
| 常见陷阱 | 平均延迟好看但尾延迟爆炸 | 吞吐高但延迟已经不可接受 |
一个常见误区是：用增加并发的方式提高吞吐，却忽略了延迟同步恶化，比如压测时把并发从10拉到50，吞吐从20涨到60，看起来不错，但P99延迟从800ms涨到4秒，这样的“高吞吐”服务上线后，用户端就是典型的“响应慢但服务器没闲”。
正确的监控做法是延迟和吞吐成对观察，Grafana面板里把QPS和P99延迟画在同一张图，两条线出现“剪刀差”时就要警惕：吞吐还在涨，延迟已经起飞，说明队列开始堆积，继续加压只会加速雪崩。
模型服务错误率突然升高怎么排查？五步定位法
线上模型服务错误率突然升高,最忌讳重启服务了事，重启能临时压住问题，但根因还在。模型服务错误率突然升高怎么排查，可以按下面五个步骤走一遍：
第一步：拆错误码，看是哪类错误在涨
先不要看总错误率,把错误拆成超时、5xx、4xx、空输出四类，如果是超时类错误占比飙升，基本可以判断是排队或推理变慢导致；如果是5xx，大概率是推理进程崩溃或资源耗尽；4xx可能是某个调用方参数模板改了；空输出则要查prompt模板和模型自身行为。
第二步：看队列长度和资源饱和度
错误率升高通常伴随队列堆积,登录到监控看请求队列长度、GPU利用率、显存占用，如果GPU利用率已经接近上限，同时显存接近打满，说明流量超过了服务容量，如果GPU利用率不高但队列依然堆积，可能是上游某个同步调用变慢，比如外部知识库检索超时。
第三步：查最近变更记录
模型版本、prompt模板、网关配置、依赖库更新、Kubernetes副本数调整，任何一项变更都可能是诱因，按时间线拉出最近24小时的变更记录，先用回滚排除法，如果是渐进式恶化，变更可能不是直接原因，但会放大问题。
第四步：抓取慢请求trace和日志
从网关或推理框架里捞几个超时请求的完整trace,看时间花在哪个环节：排队、prefill、decode、还是后处理，vLLM和SGLang都有请求级别的日志，能直接看到每阶段的耗时，日志里如果出现大量“queue full”或“OOM”字样，根因基本清楚了。
第五步：验证恢复手段
定位后不要直接全量恢复,先在灰度实例上验证：增加副本数、回滚模型版本、调整max_batch_size、延长超时阈值或优化上游依赖，灰度实例错误率回落后再全量执行，避免二次事故。
国内大模型服务监控工具选型：开源与商业方案怎么挑
监控工具选型直接决定你能多快发现延迟、吞吐、错误率的异常，国内团队在选型时，要考虑部署成本、模型专属指标支持、以及和现有技术栈的匹配度。
开源方案：灵活但需要自己搭
Prometheus + Grafana是事实标准组合，推理框架大多暴露/metrics接口，配合DCGM采集GPU指标，面板模板社区有现成的，缺点是告警规则、高可用、长期存储都要自己维护。
OpenTelemetry适合做全链路trace，尤其是排查慢请求时可以看到请求经过网关、推理服务、上游知识库的完整链路，接入成本中等，但生态兼容性好。
vLLM metrics是模型服务专属指标，如果是vLLM部署，可以直接暴露TTFT、TPOT、队列长度、并发数等指标，比通用HTTP指标精准得多。
商业方案：省事但要算成本
国内云厂商的可观测平台，比如简米云ARMS、酷番云可观测平台、华为云AOM，都提供模型服务监控能力，按数据量或agent数计费，优势是开箱即用，告警模板和AI诊断做得比较全，劣势是大规模长期存储成本可能比自建高，而且某些模型专属指标需要额外配置。
Datadog、Dynatrace等国际厂商在国内使用有一定合规和延迟问题，一般只在跨国团队中采用，国内生产环境更常见的是云厂商方案+Prometheus混合模式：核心指标走Prometheus，日志和trace走商业SaaS。
业内专家指出,选型时不要只看功能列表，要先确认推理框架暴露的指标能不能被采集到，以及告警延迟能不能控制在分钟级，一个连TTFT和TPOT都采不到的监控系统，再漂亮的大盘也是摆设。
模型服务监控指标有哪些是必须报警的
必须报警的指标至少包含：请求级错误率按类别拆分后的阈值、P99延迟超过基线的倍数、请求队列长度、GPU显存占用接近上限、OOM事件、超时错误占比，报警规则要避免“总错误率”单看，否则小类别爆发会被淹没。
大模型推理延迟多少算正常范围
没有统一数字,通常把首token延迟控制在数百毫秒内、P99总延迟控制在用户可接受的一次完整生成时间内，具体基线必须在自家硬件和模型上压测得出，然后围绕基线设置动态告警阈值。
吞吐量和延迟的区别在监控面板上怎么看
把QPS和P99延迟放在同一张图,观察“剪刀差”，吞吐持续上升但延迟同步陡增，说明已经越过容量拐点，应该停止加压或扩容，两者脱钩才是健康状态。
模型服务监控的核心从来不是堆指标,而是把延迟、吞吐、错误率三件事对应到真实用户体验上，三条主线加上资源饱和度辅助定位，足够在大部分线上问题爆发前拦住雪崩。