3. 故障诊断方法论

GPU推理服务的故障往往不是单点问题，而是从请求入口到GPU计算、再到显存与网络的多层耦合结果。如果一上来就盯着GPU利用率或某条报错日志，很容易陷入“看到什么查什么”的被动局面。更有效的方式是建立一套分层排查思路，用黄金指标定位异常层级，再借助日志与监控体系把问题收敛到具体组件。

一、分层排查：从请求入口到硬件底座

可以把一次推理请求经过的路径拆成五层，每层都有独立的观测对象和典型故障模式：

• 接入层：负载均衡、网关、鉴权、限流。典型问题是连接被拒、超时、429/503、TLS握手失败。
• 服务层：推理框架进程、请求队列、批处理调度、线程池。典型问题是队列积压、批大小抖动、OOM、进程崩溃。
• 运行时层：CUDA上下文、显存分配器、算子库、通信库（NCCL）。典型问题是显存碎片、kernel启动失败、NCCL超时。
• 硬件层：GPU计算单元、显存、PCIe/NVLink、温度与功耗。典型问题是ECC错误、降频、链路降速、XID报错。
• 基础设施层：宿主机CPU、内存、磁盘、网络、驱动与容器运行时。典型问题是CPU争抢、页缓存抖动、网络丢包、驱动版本不匹配。

分层排查的关键是“先定位层，再定位点”。例如P99延迟突然升高，先看接入层错误率是否同步上升；若错误率正常而延迟升高，则重点查服务层队列与运行时层显存；若两者都正常但吞吐下降，则转向硬件层降频或基础设施层网络。每一层只回答一个问题：异常是否由本层引入？

二、黄金指标：延迟、吞吐、错误率、资源利用率

黄金指标不是四个孤立数字，而是一组互相约束的观测面。延迟回答“用户等多久”，吞吐回答“系统能扛多少”，错误率回答“有多少请求失败”，资源利用率回答“瓶颈在哪里”。四者必须放在同一时间窗口内对比，否则容易误判。

以延迟为例，不能只看平均值。应同时采集P50、P95、P99和最大值。P50反映典型体验，P99反映尾部用户，最大值用于发现长尾卡顿。若P50正常而P99飙升，通常是队列排队、批处理等待或个别GPU降频；若P50和P99同步上升，则更可能是整体资源不足或上游依赖变慢。

吞吐通常用QPS或tokens/s衡量。注意区分“请求吞吐”和“token吞吐”：前者受批处理策略影响，后者更贴近GPU实际计算量。错误率要按错误类型拆分，例如4xx（客户端问题）、5xx（服务端问题）、超时、CUDA错误、OOM，不同错误对应不同排查方向。

资源利用率要区分“瞬时值”和“窗口值”。GPU利用率瞬时100%并不一定是瓶颈，可能是正常计算；但如果持续100%且队列增长，说明计算能力不足。显存利用率要同时看已分配、已保留和碎片率，仅看“已用显存”容易忽略碎片导致的OOM。

三、日志与监控体系搭建

日志和监控是分层排查的“证据链”。日志回答“发生了什么”，监控回答“趋势如何”。两者需要统一时间戳、统一请求ID、统一标签体系，否则跨层关联会非常困难。

日志层面，建议至少覆盖四类：接入日志（请求ID、路径、状态码、耗时）、服务日志（批大小、队列长度、推理耗时、显存分配）、运行时日志（CUDA错误、NCCL警告、OOM堆栈）、系统日志（驱动、XID、温度、功耗）。每条日志都应携带请求ID或批次ID，便于从用户请求一路追到GPU kernel。

监控层面，建议采用“指标+事件”双通道。指标用于趋势和告警，事件用于记录状态变化，例如进程重启、GPU掉卡、驱动升级、模型热更新。指标采集频率建议：延迟和吞吐10秒一次，资源利用率5秒一次，硬件错误事件实时上报。

一个可落地的监控体系通常包含三层：采集层（Prometheus、DCGM、Node Exporter、日志采集器）、存储与计算层（时序数据库、日志检索）、展示与告警层（Grafana、告警规则）。对于GPU推理服务，DCGM是采集GPU指标的关键工具，可提供利用率、显存、温度、功耗、ECC错误、NVLink带宽等字段。

四、从指标到根因：一个排查示例

假设某GPU推理服务在晚高峰出现P99延迟从180ms升至620ms，QPS从1200降到900，错误率从0.2%升到1.8%，GPU利用率从72%升到98%。按分层思路：错误率上升说明服务层或接入层有异常；延迟和吞吐同时恶化说明瓶颈在计算或排队；GPU利用率接近饱和说明计算资源不足或存在低效计算。

进一步查看服务日志，发现批大小从平均8降到3，队列长度从12升到85。这说明请求到达速率没有明显变化，但单批处理能力下降。再查运行时日志，发现显存碎片率从12%升到34%，部分请求因显存分配失败被重试。结合DCGM指标，GPU温度从68℃升到83℃，功耗接近上限，出现轻微降频。根因是显存碎片导致批处理效率下降，叠加温度降频，最终表现为延迟和错误率双升。

处理方式：先通过重启推理进程释放碎片，临时恢复服务；再调整显存分配策略，启用更积极的缓存复用；同时检查机房散热和风扇策略，避免持续降频。这个例子说明，黄金指标必须与分层日志结合，才能从“现象”走到“根因”。

五、监控体系落地要点

• 统一标签：所有指标和日志都带上service、instance、gpu_id、model、request_id，便于跨层关联。
• 基线管理：为每个模型和硬件配置建立延迟、吞吐、显存基线，告警阈值基于基线而非固定值。
• 事件记录：进程重启、模型更新、驱动升级、GPU掉卡等事件必须写入监控系统，避免把“变更”误判为“故障”。
• 定期演练：用注入延迟、模拟OOM、限制带宽等方式验证告警和排查路径是否有效。

分层排查提供路径，黄金指标提供信号，日志与监控提供证据。三者结合，才能把GPU推理服务的故障诊断从“凭经验猜”变成“按证据查”。