Docker Compose 编排 HPC 算力集群需统一声明 GPU 资源、网络、存储与调度，核心是基于 CUDA/PyTorch 官方镜像构建容器，docker-compose.yml 显式配置 GPU 分配（按数量或 ID），并设计 trainer/ps/tensorboard 等协同服务结构，确保资源隔离与通信高效。
用 Docker Compose 编排高性能计算（HPC）场景下的算力容器集群，核心在于把 GPU 资源、通信网络、存储挂载和任务调度逻辑统一声明化管理。它不是简单启动几个容器，而是构建一个可复现、可伸缩、资源可控的计算单元集合。关键点是：镜像需预装 CUDA/PyTorch/TensorFlow 等运行时，docker-compose.yml 必须显式声明 GPU 访问权限，并合理组织服务依赖与资源隔离。
准备支持 GPU 的基础镜像
高性能计算容器必须能调用宿主机 GPU，因此不能使用普通 CPU 镜像。推荐基于官方 CUDA 镜像构建，例如：
- nvidia/cuda:12.4.0-devel-ubuntu22.04（含编译工具链，适合训练环境）
- nvidia/pytorch:24.05-py3（NVIDIA 官方优化版，预装 PyTorch + CUDA + NCCL）
若需自定义环境（如添加 Horovod、DeepSpeed 或特定数据处理库），应编写 Dockerfile 构建新镜像，并在构建阶段启用 --gpus all 验证 GPU 可见性（非必需但建议）。镜像中务必包含 nvidia-container-toolkit 兼容层，确保运行时能自动挂载驱动设备节点。
在 docker-compose.yml 中声明 GPU 资源分配
Docker Compose v2.20+ 原生支持 deploy.resources.reservations.devices 和简化的 gpus 字段。两种常用方式：
-
按数量分配：适用于通用训练任务，例如让每个 worker 占用 1 张 GPU
deploy:<br> resources:<br> reservations:<br> devices:<br> - driver: nvidia<br> count: 1<br> capabilities: [gpu] -
按 ID 绑定：适用于需要固定设备拓扑（如多卡 NCCL all-reduce）或混合部署（部分服务独占某卡）
gpus: "device=0,1"或gpus: "0,1"（Compose v2.23+ 支持简写）
注意：宿主机必须已安装 NVIDIA 驱动和 nvidia-container-runtime，且 Docker daemon 配置中指定 "default-runtime": "nvidia" 或通过 runtime: nvidia 显式声明。
设计协同工作的服务结构
HPC 场景常见组合包括训练主节点（trainer）、参数服务器（ps）、监控服务（tensorboard/prometheus）和共享存储卷。示例结构：
-
trainer：运行分布式训练脚本，依赖
ps服务，挂载 NFS 或 hostPath 数据卷 -
ps：使用轻量镜像（如
python:3.10-slim+tensorflow-cpu），仅提供参数同步接口 - tensorboard：映射 trainer 的 logs 目录，端口暴露给本地浏览器
-
network：自定义 bridge 网络，启用
driver_opts: {"com.docker.network.driver.mtu": "9000"}提升 RDMA 或 RoCE 通信效率
服务间通过 service 名称 DNS 解析（如 http://ps:8500），无需硬编码 IP；使用 depends_on 控制启动顺序，但健康检查（healthcheck）更可靠地判断就绪状态。
启动与验证集群可用性
执行 docker-compose up -d 后，用以下命令确认 GPU 正确分配：
-
docker-compose ps查看各服务状态 -
docker exec -it <trainer_container> nvidia-smi检查可见 GPU 设备及显存占用 -
docker exec -it <trainer_container> python -c "import torch; print(torch.cuda.device_count())"验证 PyTorch 可识别 GPU 数量 -
docker network inspect <project_name>_default确认容器是否接入同一网络并能互通
若训练脚本报错 “CUDA out of memory” 或 “NCCL timeout”，优先排查是否多个服务被错误调度到同一张 GPU 上——此时应改用 device_ids 精确绑定，或增加 mem_reservation 限制内存抢占。
