大模型大促全景监控体系：Prometheus 深度采集显存碎片与 Prefill 耗时实战-创锋一号

大模型大促全景监控体系：Prometheus 深度采集显存碎片与 Prefill 耗时实战

在大模型系统高可用保障中，如果运维大屏上只有来自nvidia-smi的“GPU 利用率 85%”和“显存占用 75GB/80GB”，那么这个监控系统对于大促保障而言几乎毫无预警价值。在真实高并发推理场景下，显存占用 75GB 既可能是系统正在高效吞吐，也可能意味着显存已经充满了不可合并的零碎显存块（Memory Fragmentation），导致下一个仅有 100 Token 的请求在尝试申请连续 KV Block 时直接触发 CUDA Out of Memory（OOM）崩溃；而 85% 的 GPU 利用率，既可能是在全力解码生成 Token，也可能意味着系统正在被超长 Prompt 的**预填充阶段（Prefill Phase）**计算死死卡住，导致流式首字延迟飙升至数秒。

为了在大促期间建立起真正具备穿透力的大模型基础设施全景监控大盘，我们必须基于 Prometheus、DCGM Exporter 以及推理引擎自定义指标，深度捕获显存碎片化率（Fragmentation Factor）、KV Cache Block 分配水位以及Prefill 与 Decode 阶段的耗时分离指标。

[大模型深度可观测采集与大促监控大屏架构] │ ┌───────────────────────┼───────────────────────┐ ▼ ▼ ▼ [NVIDIA DCGM Exporter] [vLLM / 推理引擎 Exporter] [网关 OpenTelemetry Span] - GPU 核心 SM 活动率 - KV Cache 空闲 Block 计数 - TTFT (首字耗时直方图) - 显存 ECC 错误与重试 - 显存碎片率 (Frag Factor) - TPOT (每 Token 解码耗时) - PCIe / NVLink 吞吐 - Prefill vs. Decode 耗时 - 客户端长连接断开率 │ │ │ └───────────────────────┼───────────────────────┘ ▼ [Prometheus 高可用时序集群] │ ▼ [Grafana 大促全景大屏: 四大黄金看板] 1. 算力健康度 (XID / ECC / NVLink) 2. 显存动态 (KV Block 消耗与碎片) 3. 阶段延迟 (Prefill P99 vs. Decode P99) 4. 业务容量 (Token/s 与实时排队请求)

显存碎片与推理阶段耗时的核心指标剖析

为了精准把控大模型的运行时健康，必须采集以下三大维度的核心指标：

显存碎片化率与 Block 分配状态：
现代推理引擎（如采用 PagedAttention 机制的 vLLM）将显存划分为固定大小的物理 Block（例如 16 个 Token 为一页）。当动态请求长度差异极大时，未被整除的 Block 尾部空间会形成内部碎片。通过监控vllm:num_free_gpu_blocks与总 Block 数的比值，能够提前 3 分钟预警 OOM 风险。
计算阶段耗时解耦（Prefill vs. Decode）：
- Prefill 阶段：处理用户输入的 Prompt，计算复杂度为 $O(N^2)$，属于计算密集型（Compute-Bound）；
- Decode 阶段：流式逐字生成 Token，计算复杂度为 $O(N)$，但频繁读取显存中的 KV Cache，属于访存密集型（Memory-Bound）。
  必须通过分桶直方图（Histogram）分别统计两者的 P95/P99 延迟，杜绝“平均耗时”掩盖 Prefill 阶段长尾卡顿。

Prometheus 采集配置与自定义 Exporter 实现

我们在推理 Pod 中注入轻量级监控 Exporter，采集底层 PyTorch Caching Allocator 和引擎内部状态：

package exporter import ( "net/http" "github.com/prometheus/client_golang/prometheus" "github.com/prometheus/client_golang/prometheus/promhttp" ) var ( // 显存碎片化指数 (0.0 ~ 1.0) gpuMemoryFragmentation = prometheus.NewGaugeVec( prometheus.GaugeOpts{ Name: "llm_gpu_memory_fragmentation_ratio", Help: "当前 GPU 显存碎片化比例 (未分配连续大块占比)", }, []string{"gpu_id", "model_name", "pod_name"}, ) // Prefill 首字耗时直方图 prefillDurationHistogram = prometheus.NewHistogramVec( prometheus.HistogramOpts{ Name: "llm_prefill_phase_duration_seconds", Help: "Prompt 预填充阶段耗时直方图", Buckets: []float64{0.05, 0.1, 0.25, 0.5, 1.0, 2.0, 5.0, 10.0}, }, []string{"model_name"}, ) // Decode 单 Token 解码耗时直方图 decodeDurationHistogram = prometheus.NewHistogramVec( prometheus.HistogramOpts{ Name: "llm_decode_token_duration_seconds", Help: "单 Token 解码阶段耗时直方图", Buckets: []float64{0.01, 0.02, 0.04, 0.08, 0.15, 0.3}, }, []string{"model_name"}, ) ) func init() { prometheus.MustRegister(gpuMemoryFragmentation) prometheus.MustRegister(prefillDurationHistogram) prometheus.MustRegister(decodeDurationHistogram) } func StartMetricsServer(addr string) { http.Handle("/metrics", promhttp.Handler()) go http.ListenAndServe(addr, nil) }

生产级 Prometheus 关键告警规则

在 Prometheus 中配置如下告警规则，实现大促期间的风险早发现早隔离：

groups: - name: llm-memory-and-latency-alerts rules: # 1. 显存可用 Block 告急告警（KV Cache 剩余低于 10%） - alert: LLMKVCacheDepletionCritical expr: (vllm:num_free_gpu_blocks / (vllm:num_free_gpu_blocks + vllm:num_used_gpu_blocks)) < 0.10 for: 15s labels: severity: critical annotations: summary: "实例 {{ $labels.pod }} KV Cache 可用 Block 低于 10%，极易引发 OOM" # 2. Prefill 阶段长尾严重（长 Prompt 导致严重阻塞） - alert: LLMPrefillPhaseDegraded expr: histogram_quantile(0.95, sum(rate(llm_prefill_phase_duration_seconds_bucket[1m])) by (le, model_name)) > 3.0 for: 30s labels: severity: warning annotations: summary: "模型 {{ $labels.model_name }} Prefill P95 超过 3 秒，建议开启 Chunked Prefill"

大促大屏值守技巧

在大促指挥大屏上，牢记三条观测准则：

盯住空闲 Block 的消耗斜率：如果空闲 Block 在 1 分钟内下降超过 50%，说明正遭遇长文本攻击或异常死循环会话；
结合 DCGM XID 错误码：当显存指标异常且伴随 DCGM 上报 XID 31（GPU 内存页错误）或 XID 45（引擎挂起）时，直接触发节点自动隔离；
关注 Token 生成吞吐与并发请求数的拐点：当并发数增加但总 Token/s 开始下降时，说明系统已进入重度显存换页（Swapping）阶段，必须立即在前置网关执行自适应限流。

企业官网建设流程全解析