2025年3月初，我们在香港的数据中心上线了一套AI推理服务系统，主要服务于海外客户的图像识别需求。系统基于NVIDIA A100 GPU部署，采用NVIDIA Triton Inference Server（容器化部署），并通过Kubernetes进行调度与资源编排。运行初期一切正常，但上线后不久，陆续收到服务中断告警，并伴随GPU利用率骤降、容器频繁重启、服务响应超时等异常现象。
本文记录了从故障现象分析到问题定位与解决的全过程，涵盖技术细节、资源配置、日志分析、代码验证及最终的优化方案，希望对读者在生产环境中处理类似问题提供有价值的参考。
故障现象描述
- 服务不可用告警：Prometheus 监控系统多次触发服务不可用告警，推理服务响应时间陡增，RT超过1.5秒，部分请求超时。
- GPU资源使用异常：NVIDIA DCGM（Data Center GPU Manager）监控数据显示GPU利用率从平均85%骤降至不足10%，同时存在短时峰值闪烁。
- 容器频繁重启：部署在Node-3和Node-5上的推理容器频繁重启，重启次数超过100次/天，重启原因显示为OOMKilled。
- 内核日志异常：dmesg日志显示NVIDIA驱动相关报错，例如：
NVRM: Xid (PCI:0000:41:00): 79, GPU has fallen off the bus.
排查流程与分析
1. 检查资源分配与容器规格
初步怀疑资源分配问题导致服务不稳定，使用以下命令查看Pod的资源请求与限制：
kubectl describe pod triton-inference-xyz -n ai-inference
发现部分Pod资源定义如下：
resources:
requests:
memory: "4Gi"
cpu: "2"
limits:
memory: "6Gi"
cpu: "4"
然而主机配置为：
- CPU: 32-core Intel Xeon
- Memory: 128GiB
- GPU: 2 × NVIDIA A100 40GB
- Driver Version: 535.104.12
- CUDA Version: 12.2
通过 nvidia-smi 和 dcgmi 工具进一步确认，多个容器竞争GPU资源，导致资源饥饿和驱动异常。
2. 容器化驱动兼容性检查
检查容器镜像与主机驱动的兼容性：
docker run --rm --gpus all nvidia/cuda:12.2-base nvidia-smi
输出正常，说明驱动和CUDA库基本兼容。但在分析 /var/log/syslog 和 /var/log/kern.log 日志时发现如下报错：
nvidia 0000:41:00.0: Refused to change power state, currently in D3
参考NVIDIA官方文档，初步怀疑为驱动版本与操作系统内核之间存在冲突。此节点运行的内核版本为 5.15.0-91-generic，而NVIDIA驱动535系列在此内核下存在兼容性问题（NVIDIA官方社区已有相关Issue）。
3. 容器调度与NUMA绑定问题
部署环境为Kubernetes集群，使用Topology Manager未启用，容器未绑定特定NUMA节点，GPU频繁在NUMA间调度，加剧了竞争。
使用如下命令检查GPU拓扑和NUMA映射：
nvidia-smi topo -m
输出显示GPU与CPU不在同一NUMA节点上。加之容器启动参数未启用 –gpus device=0 明确指定使用哪个GPU，推理任务调度存在随机性。
4. 容器日志及模型加载分析
查看Triton容器内部日志：
kubectl logs triton-inference-xyz -n ai-inference
日志中频繁报出：
[core] failed to allocate device memory for model resnet50_optimized: out of memory
进一步分析发现，多个模型在启动阶段尝试同时加载至GPU显存，而部分模型（如resnet50 + yolov7）合计占用显存超出40GB，导致加载失败并触发OOM。
四、本次故障问题汇总
本次故障为多因素耦合所致，主要原因包括：
- 容器间GPU资源竞争严重，缺乏显式GPU绑定，导致推理服务不稳定。
- 驱动版本与内核存在兼容性隐患，触发NVRM错误，GPU掉线。
- 容器模型加载顺序未控制，并发加载过多大型模型，引发OOM。
- Kubernetes未配置Topology Aware调度策略，NUMA调度不合理。
五、解决方案与优化措施
1. 显式绑定GPU资源
更新Deployment配置，指定容器使用GPU：
resources:
limits:
nvidia.com/gpu: 1
并确保使用 device=0 绑定特定GPU：
--gpus device=0
2. 降级驱动版本与重建镜像
将驱动版本从535降级至525.147.05（在官方兼容列表中表现稳定），同时重建Triton容器镜像，确保CUDA和cuDNN版本匹配：
FROM nvcr.io/nvidia/tritonserver:23.08-py3
RUN apt-get update && apt-get install -y cuda-cudart-12-1
3. 控制模型加载策略
修改模型配置，按需加载，使用异步加载策略并预加载核心模型：
model_control_mode: "explicit"
load_model: ["resnet50"]
通过API动态加载/卸载模型，降低显存占用。
4. 启用Topology Manager
在kubelet中开启NUMA感知调度：
--topology-manager-policy=best-effort
--cpu-manager-policy=static
并为推理服务分配相邻的CPU core与GPU，减少跨NUMA通信。
AI推理服务的稳定性，不仅依赖于算法模型的性能，更深层次地受制于底层硬件资源调度、驱动版本兼容性及容器管理策略。通过本次香港节点的故障排查，我们认识到在部署GPU推理服务时，必须对资源配比、驱动版本、容器策略、NUMA调度等多个环节进行系统化管控。希望本文的实录对同类问题的排查与优化提供切实可行的借鉴。
