1. 项目背景
某社交平台的vLLM推理服务支撑着核心的"AI聊天"功能。某天下午2点，用户投诉"AI回复特别慢"——运维查看Grafana，发现P99延迟从常日800ms飙升到5.2秒。但奇怪的是，CPU、GPU、QPS、错误率四个核心面板全部"正常"——GPU利用率70%，QPS稳定在50，错误率<0.1%。如果只看这四个面板，服务"完全健康"。
深入排查后发现，问题出在排队时间——用户实际等待时间=排队时间+推理时间。由于一个下游服务(向量检索)变慢，vLLM的等待队列从平时的5个积压飙到了80个。但团队的监控面板上没有排队时间的指标——这是一个监控盲区。如果早就有vllm:num_requests_waiting的告警，问题可以在5分钟内被发现，而不是等用户投诉2小时后才被动响应。
更严重的是，CTO问"我们需要加多少GPU才能把P99延迟降回800ms？“——没有容量模型，无法回答。团队只能猜测"再加2张A100试试”——结果加了2张卡后P99只降到3.8秒，因为瓶颈其实在CPU的Tokenizer线程池而非GPU。
痛点：监控不是"把Grafana曲线画得好看"，而是建立SLO驱动的告警体系。容量规划不是"加GPU"，而是建立数学模型预测资源需求。本章将定义LLM服务的SLO、完善告警规则库、建立容量和成本模型，让运维从"凭感觉"走向"凭数据"。
2. 项目设计
（场
