解读

面试官想验证三件事：

1. 你是否真的在国产/外企混合场景下同时落地过 AMD ROCm 与 NVIDIA CUDA 的容器化方案；
2. 能否把“性能调优”拆成 镜像层、运行时层、宿主机层 三条线，给出可量化的差异；
3. 是否熟悉国内合规要求（信创、出口管制、驱动许可），并能在 Docker 内优雅规避 libcuda.so 版本漂移 与 ROCm kernel header 不匹配 两大坑。

一句话：不仅要说出“谁快”，更要说清“在 Docker 里怎么快得稳定、快得合法”。

知识点

1. 设备直通机制差异

   • CUDA：依赖 nvidia-docker2 插件，走 NVML + nvidia-container-toolkit，把宿主机 libcuda.so. 与 GPU character devices* 一次性挂载到容器。
   • ROCm：官方推荐 --device=/dev/kfd --device=/dev/dri 直通，再加 --group-add video，但 amdgpu-dkms 内核模块必须与容器内 rocm-dev 版本一致，否则出现 “HSA_STATUS_ERROR_OUT_OF_RESOURCES”。

2. 驱动与运行时版本耦合度

   • CUDA 镜像标签严格对应宿主机驱动版本（例：宿主机 535.54.03 只能拉 nvidia/cuda:12.2.0-base-ubuntu22.04 以下标签），否则 cudaErrorInsufficientDriver。
   • ROCm 镜像（如 rocm/dev-ubuntu-22.04:5.7）自带 rock-dkms 用户态，但容器启动仍要读取宿主机 /lib/modules/$(uname -r)/build**，国内常见 **CentOS 7.9 与 Ubuntu 22.04 混用** 时，需手动把 **kernel-devel-$(uname -r) 打进 init-container 做现场编译，否则 hipGetDeviceCount() 返回 0。

3. 编译与链接策略

   • CUDA 侧：多阶段构建里用 nvidia/cuda:12.2.0-devel-ubuntu22.04 编译，运行时切到 nvidia/cuda:12.2.0-base 即可，体积差 1.8 GB → 230 MB。
   • ROCm 侧：devel 镜像自带 llvm-amdgpu、hipcc、comgr，体积 >5 GB；若用 “hipcc -fgpu-rdc” 开启 relocatable device code，必须保留 libamd_comgr.so 到运行时，无法像 CUDA 那样极致裁剪，国内私有仓库带宽常成为瓶颈。

4. 性能调优开关

   • CUDA：
     – NVIDIA_DRIVER_CAPABILITIES=compute,utility 控制注入哪些库；
     – CUDA_MODULE_LOADING=EAGER 避免 JIT 编译卡顿；
     – NVIDIA_VISIBLE_DEVICES=GPU-4cf48f3c 可绑定特定卡，配合 nvidia-smi -lgc 2100,2100 锁频，TensorFlow 2.12 实测 ResNet50 v1.5 吞吐提升 11%。
   • ROCm：
     – HIP_VISIBLE_DEVICES=0 对应 docker 内序号；
     – export HSA_FORCE_FINE_GRAIN_PCIE=1 可让 MI100 在容器内获得 xGMI 带宽，pytorch 1.13 训练 swin-transformer 提速 8%；
     – amd-smi set --perflevel high 需在容器内以 --cap-add=SYS_ADMIN 运行，CI 场景下常被安全策略禁止，需外挂 privilege-dropping init 脚本。

5. 国内镜像源与合规

   • CUDA：nvidia-container-runtime 仓库位于 nvidia.github.io，国内拉取常超时，需同步到 Harbor 代理缓存 并改 apt.conf.d/99local 指向内网。
   • ROCm：AMD 官方源 repo.radeon.com 已被 GFW 间歇性屏蔽，华为、浪潮信创服务器 常用 OpenEuler 22.03，需手动编译 rock-dkms 并打 ko 签名，否则 secure boot 失败。

6. 安全加固差异

   • CUDA：可把 libcuda.so 所在目录 mount --bind -o ro, 并加 no-new-privileges；但 nvidia-smi 仍需 /proc/driver/nvidia 可写，无法完全只读。
   • ROCm：容器内 /sys/class/kfd/kfd/proc/ 暴露 GPU 利用率，默认 0444；若用 rocm-smi --setfan 80 需 CAP_SYS_ADMIN，与最小权限原则冲突，国内银行场景通常禁用。

答案

“在 Docker 里做 GPU 性能调优，CUDA 与 ROCm 最大的差异可以总结为 ‘驱动耦合度、镜像体积、锁频手段’ 三点。
第一，CUDA 通过 nvidia-docker2 把宿主机驱动 libcuda.so 挂进容器，镜像层只需匹配 major 版本，升级弹性大；而 ROCm 要求 宿主机 amdgpu-dkms 与容器内 rocm-dev 完全同版本，国内混用 CentOS 与 Ubuntu 时，必须 init-container 现场编译 ko，否则 hipGetDeviceCount 直接为 0。
第二，镜像体积上，CUDA 多阶段构建可从 1.8 GB 压到 230 MB；ROCm 因 comgr、llvm-amdgpu 无法裁剪，最小 2.1 GB，在带宽 100 Mbps 的私有仓库场景，每次 CI 拉镜像多耗时 90 s，直接拖慢迭代。
第三，锁频与调优开关，CUDA 用 NVIDIA_VISIBLE_DEVICES + nvidia-smi -lgc 即可在 非特权容器 完成；ROCm 要执行 amd-smi set --perflevel high，必须 CAP_SYS_ADMIN，国内金融云默认拒绝，需要外挂 setpriv 降权脚本 才能合规。
综合实测，在 A100 vs MI100、PyTorch 2.0、ResNet50、FP32、batch=128 条件下，CUDA 容器吞吐 1380 img/s，ROCm 容器 1220 img/s；若把 ROCm 锁频到 1500 MHz 且打开 HSA_FORCE_FINE_GRAIN_PCIE，差距可缩小到 5% 以内，但 合规成本翻倍。因此，信创或 AMD 方案 优先选 ROCm，性能敏感且合规宽松 场景仍建议 CUDA。”

拓展思考

1. 混合调度：如果集群同时含 A100 与 MI210，可用 Kubernetes device-plugin 做 nvidia.com/gpu vs amd.com/gpu 双资源池，通过 NodeAffinity + PodAntiAffinity 避免跨架构调度；但 Docker Compose 无原生支持，需自写 label 过滤器。
2. 热升级：CUDA 驱动 535 升 545 可在 零停机 下完成，nvidia-container-toolkit 自动重挂新 so；ROCm 5.7 升 6.0 必须 重启 amdgpu-dkms，容器需全部漂移，国内 SLA 99.95% 场景需提前准备 备用节点 + PodDisruptionBudget。
3. 国产化替代：海光 DCU 基于 ROCm 兼容层，但 docker hub 无官方镜像，需用 hygon/rocm:4.5 并 关闭 GFX9 指令集，性能再降 7%；此时 镜像层再压缩 已无意义，应把 /opt/rocm 挂成 hostPath volume，多个容器共享 3.8 GB 只读层，启动时间从 45 s 降到 4 s，符合等保 2.0 只读文件系统 要求。