Serverless GPU 稳定性验证与故障记录

说明如何用 Prometheus、DCGM Exporter 与 MLPerf 建立 Serverless GPU 稳定性验证链路，并按告警状态、请求延迟和 worker 计费阶段形成可复盘的故障记录。

Serverless GPU 的稳定性验证，应把持续指标、请求延迟、告警状态和 worker 生命周期放在同一条时间线上；故障记录不能只抄一条报错，还要保存配置版本、状态变化与恢复动作。使用算力租赁时，应把 worker 启动、执行和空闲等待分别标记，因为 RunPod 的 Serverless 计费说明将可计费时间按这些阶段说明，并从 worker 启动计到完全停止、向上取整到秒。

Serverless GPU：先固定被测边界

先记录 provider、GPU 型号、模型与运行时版本、部署 revision、请求形态和并发入口。构造持续推理任务时，还要写清请求如何到达、任务在什么条件下结束、用什么指标判断运行正常，避免恢复后无法确认变化发生在哪一层。

按 MLPerf Inference 规则，system under test 是接受性能测量的软硬件资源集合；对 LLM，它分别记录首 token 延迟 TTFT 和每个输出 token 的平均间隔 TPOT。同一规则对不同场景采用不同负载与结果指标：

Server：按 Poisson 分布发送查询，在场景规定的延迟约束下记录可支持的最大 Poisson 吞吐量。
Offline：开始时用一个查询发送全部样本，不设延迟约束，指标是吞吐量。
Single stream：上一请求完成后再发送下一请求，指标是 P90 延迟估计。

选择与实际请求方式对应的场景后，后续运行才具有可重复的比较基础。

稳定性验证：先确认指标链路

按 Prometheus 入门文档，可使用以下命令启动，数据库默认位于 ./data：

./prometheus --config.file=prometheus.yml

入门配置在 global.scrape_interval 中设置采集间隔，并在 scrape_configs 下通过 job_name 和 static_configs.targets 列出目标；job 可以覆盖全局间隔：

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

对于已运行的 DCGM Exporter，NVIDIA 文档说明它默认监听 :9400，通过 /metrics 暴露 GPU 指标，采集间隔默认是 30000 ms。先检查端点：

curl localhost:9400/metrics

再在相应 Prometheus job 的 static_configs.targets 中登记 Exporter 的 HTTP 服务地址。端点可访问只代表采集入口可用，不能单独证明 GPU 或推理服务正常。

稳定性验证：用延迟观察持续运行

Prometheus 查询函数文档给出了按 job 计算 classic histogram P90 的示例：

histogram_quantile(0.9, sum by (job, le) (rate(http_request_duration_seconds_bucket[10m])))

只有服务实际暴露对应 histogram 时才能直接使用该指标名，否则应换成真实 series。classic histogram 聚合时必须保留 le，因此不要从 by (job, le) 中删除它。每次验证还应保存完整 PromQL、查询时间和 job，避免恢复后只留下一个无法复算的延迟数字。

故障记录：关联告警、请求与恢复

按 Prometheus 告警规则，告警条件为真但 for 尚未满足时处于 pending；keep_firing_for 会在条件清除后继续维持 firing。活动告警会出现在合成时间序列 ALERTS 中，并通过 alertstate 区分状态。

每个故障至少记录以下内容：

条件首次为真、进入 pending、进入 firing、条件清除、告警结束和恢复验证的时间。
故障编号、部署 revision、endpoint、Prometheus job、worker 或 request 标识。
对应 P90 查询、原始告警标签、请求错误类别，以及每次操作的执行人和结果。
worker 启动、停止及空闲等待时间，便于与运行记录和账单核对。

保留原始时间戳和查询结果，不要只保存汇总结论；保留期写入内部记录策略即可，本文不替你设定天数。采集失败只能证明观测链路中断，P90 上升与请求报错同时出现也只是关联现象，不能直接写成 GPU 故障根因。

算力租赁：把计费阶段放进时间线

RunPod 的计费规则把 worker 时间分为容器初始化与模型加载所对应的启动阶段、请求执行阶段，以及完成请求后等待缩机的空闲超时阶段。请求完成时间不能直接当作 worker 停止时间。

可按账单或控制台时间戳计算：

单个 worker 计费秒数 = 向上取整（YOUR_STOP_TIME - YOUR_START_TIME）
核对总额 = 各 worker 计费秒数之和

逐个核对启动、模型加载、执行和空闲等待记录。金额不要仅由运行时长猜测，应以 provider 当前账单或报价中的实际行项目为准；其他平台则查阅各自的当前计费文档。

常见出错点

P90 查询没有结果：先确认服务暴露的 metric 类型和名称；使用 classic histogram 时检查 le 是否仍在 by 中。
curl localhost:9400/metrics 无输出：先区分 Exporter、采集入口与目标配置问题，不要直接记录为 GPU 故障。
ALERTS 已活跃但没有进入 firing：检查条件是否满足以及 for 是否已经经过。
账单与运行记录对不上：按启动、执行和空闲阶段分别核对，不要只比较请求开始与结束时间。

本文步骤依据正文所链接的官方文档编写，未包含运行或测量；使用前应对照当前版本复核。