去年线上推理服务出过一次事故：GPU显存缓慢泄漏导致服务在运行三天后OOM崩溃。如果当时有完善的监控，显存泄漏趋势早就能被发现。那次事故之后，我们把推理服务的监控体系补全了；

AI推理服务的监控和传统Web服务不同，需要关注一些特有的维度；

监控维度

推理性能方面，首Token延迟（TTFT）直接影响用户体验——用户感受到的"响应速度"就是TTFT；生成速度（tokens/s）决定了"阅读速度"；端到端延迟是总耗时；

GPU状态方面，GPU计算利用率反映GPU忙不忙；显存使用率接近100%就该预警了；KV Cache使用率是vLLM特有的指标，比显存总量更能反映当前负载；

队列状态方面，等待处理的请求数反映服务是否过载。队列持续增长说明服务能力不够了；

Prometheus配置

scrape_configs:
  - job_name: "vllm-inference"
    scrape_interval: 15s
    static_configs:
      - targets: ["vllm-server:8000"]
    metrics_path: /metrics

vLLM暴露的核心指标：vllm:request_duration_seconds（请求总耗时）、vllm:time_to_first_token_seconds（首Token延迟）、vllm:num_requests_running（运行中请求数）、vllm:gpu_cache_usage_perc（KV Cache使用率）、vllm:avg_generation_throughput_toks_per_s（生成吞吐量）。

告警规则

groups:
- name: vllm-alerts
  rules:
  - alert: HighLatency
    expr: histogram_quantile(0.95, vllm:request_duration_seconds_bucket) > 30
    for: 5m
    labels: {severity: warning}
    annotations:
      summary: "P95推理延迟超过30秒"

  - alert: GPUOOM
    expr: vllm:gpu_cache_usage_perc > 0.95
    for: 2m
    labels: {severity: critical}
    annotations:
      summary: "KV Cache使用率超95%，即将OOM"

  - alert: QueueBacklog
    expr: vllm:num_requests_waiting > 50
    for: 5m
    labels: {severity: warning}
    annotations:
      summary: "请求队列积压超过50"

  - alert: HighErrorRate
    expr: rate(vllm:request_errors_total[5m]) / rate(vllm:request_total[5m]) > 0.05
    for: 5m
    labels: {severity: critical}
    annotations:
      summary: "请求错误率超过5%"

Grafana大盘

建议的面板布局：顶部一行放核心指标卡片（QPS、P50延迟、P95延迟、错误率）；中间一行放GPU相关图表（GPU利用率时序图、显存使用率时序图、KV Cache使用率时序图）；底部放请求详情（按模型维度的请求分布、延迟分布直方图）。

日志采集

用Loki采集推理服务日志。vLLM的日志包含了每次请求的详细信息（模型名、输入长度、输出长度、处理时间），对于排查问题和分析使用模式非常有价值。

自定义指标

除了内置指标，业务层面的指标也很重要。在推理服务中用prometheus_client库添加：

from prometheus_client import Counter, Histogram

token_counter = Counter("llm_tokens_total", "生成的总Token数", ["model", "type"])
latency = Histogram("llm_custom_latency", "自定义延迟追踪", ["model"])

选型建议

模型选型没有标准答案，取决于具体场景。几个关键维度：

  • 效果：在你的任务上的准确率/质量，建议用真实数据跑benchmark；
  • 速度：推理延迟和吞吐量，直接影响用户体验和成本；
  • 成本：API调用费用或自部署的硬件成本；
  • 生态：社区支持、工具链、文档质量；

实际操作中，建议先用API快速验证效果，再决定是否自部署；

量化和压缩

模型太大装不进显存？几个压缩方案：

  • GPTQ：训练后量化，4bit量化后模型大小减少75%，效果损失很小；
  • AWQ：激活感知量化，对重要通道保留高精度，效果比GPTQ略好；
  • GGUF：llama.cpp的量化格式，CPU推理也能用；
  • 蒸馏：用大模型的输出训练小模型，效果接近但参数量小一个数量级；

写在最后

没有监控的服务就是在裸奔。出事故之后再补监控，代价远大于提前建设。Prometheus加Grafana的标准方案已经足够成熟，照着这篇文章搭起来就行，别等出了事故再补课。