企业将大模型推理服务部署于高性能GPU服务器中是当前的趋势，某团队近期尝试在香港机房的一台新购高配GPU服务器上部署多卡并行的大模型推理服务，模型体积超过30GB，计划使用TensorRT与DeepSpeed结合部署，运行环境基于Docker容器。在部署过程中，却频繁遭遇GPU资源分配失败的问题，导致推理任务无法正常启动。
香港服务器硬件与软件配置
- 服务器型号：Supermicro 4029GP-TRT
- CPU：Intel Xeon Gold 6248R × 2（共48核96线程）
- 内存：1TB DDR4 ECC REG
- GPU：NVIDIA A100 40GB × 4
- 主板拓扑：典型的双路NUMA架构，每个CPU绑定两个GPU
- 操作系统：Ubuntu 20.04 LTS
- NVIDIA Driver：525.105.17
- CUDA版本：11.8
- 容器运行环境：Docker 24.0.2 + NVIDIA Container Toolkit
- 部署工具：PyTorch 2.1 + DeepSpeed 0.11 + TensorRT 8.6
部署脚本在模型加载阶段出现如下错误：
RuntimeError: CUDA error: all CUDA-capable devices are busy or unavailable
CUDA kernel errors might be asynchronously reported at some other API call.
同时，nvidia-smi可以正常识别全部4块GPU，但一旦运行推理服务，部分容器内的GPU进程会在短时间内自动退出。更细致地观察dmesg日志后，发现如下信息：
NVRM: Xid (PCI:0000:7b:00): 31, pid=xxxxx, Ch 0000, intr 10000000. MMU Fault: Unrecoverable page fault
初步排查过程
1. 检查GPU资源状态
首先通过 nvidia-smi topo -m 查看GPU与CPU之间的连接拓扑：
GPU0 GPU1 GPU2 GPU3 CPU Affinity
GPU0 X NV2 SYS SYS 0-23
GPU1 NV2 X SYS SYS 0-23
GPU2 SYS SYS X NV2 24-47
GPU3 SYS SYS NV2 X 24-47
说明 GPU0 与 GPU1 连接至 NUMA节点0（CPU0），GPU2 与 GPU3 连接至 NUMA节点1（CPU1）。
这与主板手册所描述的物理结构一致。
2. 验证驱动与CUDA兼容性
通过以下命令确认驱动与CUDA的兼容性：
nvidia-smi
nvcc --version
确认无明显版本冲突，CUDA 11.8 是官方支持 A100 的兼容版本。驱动版本也高于最低要求（450.x）。
但使用 nvidia-smi mig 检查，确认未启用 MIG 模式。容器环境下也启用了 –gpus all 参数，并确认了/dev/nvidia*设备的正确挂载。
3. 检查 NUMA 绑定情况
使用 numactl –hardware 查看系统内存架构：
available: 2 nodes (0-1)
node 0 cpus: 0-23
node 0 size: 512000 MB
node 1 cpus: 24-47
node 1 size: 512000 MB
确认系统为典型的NUMA架构，存在内存亲和性限制。在使用 DeepSpeed 启动服务时，并未显式指定 NUMA 节点绑定，这可能导致 GPU 与内存之间的跨NUMA访问，引发内存页错误。
深入分析
1. NUMA影响GPU性能与稳定性
NUMA架构下，每个CPU访问本地内存的速度远高于访问另一节点的内存。当模型部署未考虑到GPU-CPU-内存绑定关系时，例如 GPU0尝试访问NUMA节点1的内存，会引发频繁的跨节点通信，导致资源调度不稳定，甚至出现驱动层面MMU Fault错误。
2. 驱动版本存在兼容性Bug
进一步查阅NVIDIA发布说明，确认525系列驱动在NUMA环境中存在A100使用稳定性问题，特别是在多容器调度+跨NUMA部署场景下。官方建议在多NUMA系统中使用较新的 535系列驱动 或 R550长期支持版本。
解决方案
1. 显式绑定NUMA节点与GPU
修改服务启动脚本，加入 numactl 绑定选项，例如将GPU0、GPU1绑定至NUMA节点0：
numactl --cpunodebind=0 --membind=0 \
deepspeed launch.py --num_gpus 2 ...
通过对每个GPU容器进行NUMA感知的部署，大大减少了跨节点内存访问，避免了不必要的page fault。
2. 升级NVIDIA驱动至535系列
将驱动升级至 535.129.03，执行步骤如下：
sudo systemctl stop docker
sudo systemctl stop nvidia-persistenced
sudo bash NVIDIA-Linux-x86_64-535.129.03.run
sudo reboot
升级后重新加载CUDA与容器驱动组件，验证服务稳定性。
3. 在容器中添加IPC命名空间共享与MPS
使用NVIDIA Multi-Process Service（MPS）来优化GPU任务调度。启用方式：
export CUDA_MPS_PIPE_DIRECTORY=/tmp/nvidia-mps
export CUDA_MPS_LOG_DIRECTORY=/tmp/nvidia-log
nvidia-cuda-mps-control -d
并在容器中设置：
--ipc=host --shm-size=2g
确保多模型推理进程可以高效共享GPU资源。
最终效果与验证
升级驱动并进行NUMA绑定部署后：
- 推理服务稳定运行，GPU资源利用率稳定在85%以上；
- dmesg 中未再出现 Xid 31 错误；
- 服务启动耗时缩短约30%，容器不再异常退出；
- 横向部署多实例时，GPU分配可控，避免资源冲突。
NUMA架构是大模型部署中的关键考量因素，尤其在高性能服务器上，CPU、内存、GPU的拓扑布局需要匹配；
- 驱动版本应与硬件架构适配并及时更新，特别是当厂商已公开相关兼容性问题；
- 容器部署需考虑IPC共享、MPS调度等高级特性，以充分释放GPU的并发能力；
- 在部署前建议使用工具如 hwloc, nvidia-smi topo, numactl 进行系统拓扑分析。
我们在处理复杂系统架构与新硬件结合的问题时，不应仅关注表层报错，更应从系统底层资源调度与驱动层次深入剖析，才能有效实现稳定、高效的部署。
