算力调度平台系列写到第二篇了。上一篇我把整体架构和模块划分做了个梳理当时不少读者留言问的比较集中的问题是环境到底怎么准备Docker 装了但容器里跑不了 GPU 算力nvidia-smi都识别不到还有人在 Windows 上装 Docker Desktop 卡在虚拟化那一步。这些问题如果不提前绕开后面部署调度层时会非常痛苦。这篇文章就专门把环境准备这件事讲透覆盖 Linux 和 Windows 两条主线重点是 GPU 容器化的完整链路。适合三类读者第一类是刚起步、准备折腾算力平台的小团队第二类是自己有 GPU 主机、想用 Docker 统一管理开发环境的个人开发者第三类是已经跳过一些坑、但想系统搞清楚 GPU 容器原理的运维同学。内容偏实操我会把每一步背后的原理和判断依据也讲清楚这样你们遇到变体问题也不慌。1. 为什么算力调度平台必须选 Docker 做底座1.1 算力平台的第一需求不是调度而是环境一致很多人以为算力调度平台的核心是那个调度器其实搭过的都懂真正让你熬夜的永远在两头一头是底层环境的碎片化另一头是上层任务环境的重构。我见过一个很典型的团队节点 A 上装了 CUDA 12.2节点 B 上还是 11.8训练脚本在 A 上跑得挺欢切到 B 上直接就CUDA driver version is insufficient。节点多了之后你根本没法保证每台机器上的驱动、CUDA、cuDNN、Python 依赖都完全一致。开发同学报过来一个环境问题你 ssh 上去排查半小时最后发现是 libcudnn 版本对不上。Docker 解决的就是这个问题。你把 CUDA 版本、PyTorch、依赖库全部打进镜像这个镜像在哪台机器上跑看到的环境就是一模一样的。底层只要保证两件事操作系统能跑 DockerGPU 驱动能被容器访问。剩下的差异都被镜像隔离掉了。这是调度平台能做的第一个前提。1.2 GPU 直通的演进从 nvidia-docker 到--gpus参数早期 Docker 根本不支持 GPU。那时候想在容器里用显卡得靠nvidia-docker这个插件它会把宿主机上的 NVIDIA 驱动库和 GPU 设备文件注入容器再用一个专门的 docker runtime 启动容器。用起来非常别扭要写nvidia-docker run不能用原生的docker run。后来 NVIDIA 推出了 NVIDIA Container ToolkitDocker 官方也把 GPU 支持收进了原生 CLI。现在的用法就一行docker run --rm --gpus all nvidia/cuda:12.2.0-base-ubuntu22.04 nvidia-smi--gpus这个参数背后做的工作不少Docker 会从宿主机设备列表里找到 NVIDIA 的 GPU 设备/dev/nvidia0、/dev/nvidiactl 等然后把 NVIDIA Container Toolkit 生成的一组运行时库挂载进容器保证容器里的程序能调用 GPU 驱动接口。理解这套链路对排错价值很大。容器里跑nvidia-smi时它不是简单读出有个显卡而是要经过设备文件映射 → 驱动库注入 → 用户态库初始化 → 内核驱动通信。哪一环断了表现都不一样。后面我会详细带大家排查。1.3 面向调度平台的镜像设计观做单机实验时镜像随便拉一个就能用。但面向调度平台镜像从一开始就要养成分层清晰、体积可控的习惯。平台侧运维只关心两件与镜像相关的操作拉取和分发。给每个任务都拉一个 10GB 的镜像调度器的启动速度会被拖垮。通常的做法是基础镜像 任务镜像两层。基础镜像只装驱动依赖、CUDA runtime 和通用工具作为平台的公共底座放在每个节点上任务镜像基于基础镜像叠加具体框架PyTorch、TensorFlow、自定义推理服务。这样大部分节点只要拉一次基础镜像任务镜像的差异层通常比较小分发成本显著下降。在环境准备阶段你只需要记住这个理念具体怎么在调度层落地下一篇讲调度器时再展开。2. Docker 环境安装与基础配置Linux / Windows 两条主线2.1 Linux 节点上的 Docker 安装日常够用的三行命令绝大多数算力节点是 Linux。Ubuntu 和 CentOS 系都有官方包源但第三方源的版本经常落后我建议直接用 Docker 官方安装脚本省掉各种依赖问题curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh脚本会帮你装好 Docker Engine、CLI、containerd还会提示是否配置镜像加速。装完先用系统服务把它拉起来sudo systemctl enable docker sudo systemctl start docker sudo docker versiondocker version会输出 Client 和 Server 两段信息。如果你只看到 Client 而 Server 部分报错那说明 Docker daemon 没起来常见原因包括 systemd 没启动、卸载残留配置文件损坏、以及磁盘空间不足。这时候先看服务状态日志sudo systemctl status docker sudo journalctl -u docker --no-pager -n 50日志里的关键行往往是failed to start daemon: ...后面的内容照着处理即可。提示不要在生产节点上装 Docker Desktop它面向本地开发包含一堆图形化组件和虚拟机层白白增加系统负担。服务器场景装 Docker Engine 就对了。2.2 Windows 开发机上的 Docker Desktop虚拟化检查是第一个坎开发人员普遍用 Windows所以平台边上的开发环境通常要装 Docker Desktop。装这个其实是在 Windows 上套一层轻量虚拟机再在这个虚拟机里跑 Docker Engine。它支持两种后端老一点的 Hyper-V以及现在主流的 WSL 2。最常见的失败场景是启动时报Docker Desktop failed to start because virtualisation support wasnt detected。这个提示说得很明白——虚拟化功能没开。第一步先确认 BIOS/UEFI 里 Intel VT-x 或 AMD SVM 有没有启用这个在进系统前设置的而且改了之后要重启才生效。第二步确认 Windows 功能面板里虚拟机平台和适用于 Linux 的 Windows 子系统这两个选项有没有勾上。都确认完在 PowerShell 里执行systeminfo看输出里 Hyper-V 要求那一栏如果四个项目都显示已检测到虚拟化这关就算过了。如果还是启动失败多半是旧版本 Docker Desktop 和 Windows 版本的兼容问题直接卸载重装最新版问题概率会小很多。装好后 WSL 2 后端会在后台维护一个docker-desktop发行版平时不用管它。但我建议把 Docker Desktop 的资源限制调一下默认的配置占内存偏高。在 Settings - Resources - Advanced 里根据开发机的实际内存配 4GB 左右即可不然同时跑 IDE 和 Docker 会很吃力。2.3 国内镜像加速配置不花一分钱但能省一堆时间这个坑几乎所有刚接触 Docker 的人都踩过。拉取镜像默认走 Docker Hub网络一忙就是几 KB/s一个 pytorch 镜像能拉一上午。配置镜像加速属于做得早、受益久的事情。Linux 下修改/etc/docker/daemon.json{ registry-mirrors: [ https://docker.m.daocloud.io, https://dockerproxy.com ] }改完后执行sudo systemctl daemon-reload sudo systemctl restart docker用docker info查看 Registry Mirrors 字段是否生效。注意这里存在一个信息更新问题公共镜像加速地址的可用性和速度是动态变化的。如果你的加速地址失效请去容器服务商的控制台找到镜像加速器入口获取自己专属的加速地址也可以用公共的 DaoCloud / 阿里云加速器地址间切换测试。Windows 桌面版同理Docker Desktop Settings - Docker Engine 里把这段 JSON 写进去Apply Restart 即可。我实际用下来配置加速之后 pytorch 官方镜像基本能跑到满速这是环境准备里性价比最高的一步。3. 让容器认识 GPUNVIDIA Container Toolkit 安装与配置3.1 前置条件检查驱动、CUDA、运行时版本的关系在动手装任何容器工具之前先搞清楚宿主机上的一层依赖关系。Docker 容器里的 CUDA 运行库比如 libcudart、libcublas都封装在镜像里不需要你在宿主机上装 CUDA但是宿主机必须有与容器要求兼容的 NVIDIA 驱动。你可以这样理解容器里的 CUDA 库是应用层宿主机驱动是内核层两者通过 NVIDIA 提供的用户态驱动库和字符设备文件通信。版本匹配有个简单的安全规则容器镜像里声明的 CUDA 版本不得高于宿主机驱动支持的 CUDA 版本。判断方法很简单在宿主机执行nvidia-smi输出右上角有CUDA Version: 12.2这个是当前驱动能支持的最大 CUDA 版本。只要你的容器镜像 CUDA 标签不高于它通常没问题。如果nvidia-smi提示命令找不到说明驱动根本没装。Linux 下装驱动的方式有几种Ubuntu 的ubuntu-drivers自动检测、NVIDIA 官网 .run 包手动装。无论哪种装完务必重启然后用nvidia-smi确认。驱动装不上时最常见的表现是装完一次重启后又被内核更新顶掉这时需要禁用 nouveau 开源驱动。Ubuntu 下可以这样确认lsmod | grep nouveau如果有输出说明 nouveau 还在需要把它加进/etc/modprobe.d/blacklist-nouveau.conf再重新生成 initramfs。具体命令各发行版有差异Debian/Ubuntu 系是sudo update-initramfs -u。3.2 安装 NVIDIA Container Toolkit 的标准流程一旦驱动正常接下来就让 Docker 认识 GPU。NVIDIA 官方给了一套工具链叫 NVIDIA Container Toolkit装它之后 Docker 才能通过--gpus参数把 GPU 设备映射进容器。Ubuntu/Debian 的安装流程如下先添加 NVIDIA 的 apt 仓库curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | \ sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \ sed s#deb https://#deb [signed-by/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g | \ sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list然后更新并安装sudo apt-get update sudo apt-get install -y nvidia-container-toolkit装好后需要把 nvidia runtime 注册进 Docker 配置sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart dockernvidia-ctk runtime configure这条命令会自动修改/etc/docker/daemon.json加上默认 runtime 为 nvidia 的配置。如果一切顺利docker info输出里应该能看到类似Runtimes: nvidia runc Default Runtime: nvidia3.3--gpus参数与nvidia-ctk之间的关系有些读者会问既然默认 runtime 已经是 nvidia为什么docker run还要加--gpus all两者其实是互补关系。runtimenvidia让 Docker 知道这个容器允许访问 GPU并且我可以调用 NVIDIA Container Toolkit 提供的运行时来准备环境。--gpus all则具体告诉 Docker你允许的是哪几个 GPU 设备要挂载哪些设备文件和库。严谨地说在默认 runtime 已经是 nvidia 的机器上你仍然要写--gpus它俩管的不是一个层面。实际操作里我建议不用依赖全局 runtime显式在 docker run 命令里声明更清晰方便同一个节点上同时跑 CPU 容器和 GPU 容器任务docker run --rm --gpus device0,1 nvidia/cuda:12.2.0-base-ubuntu22.04 nvidia-smi这段会只把 0 和 1 号卡映射进容器。调度平台里做 GPU 切分时这种设备级控制非常有用。4. 完整测试链路容器里跑通nvidia-smi和真实计算4.1 最小验证一条命令确认 GPU 可见环境配置完第一个测试命令建议用这个docker run --rm --gpus all nvidia/cuda:12.2.0-base-ubuntu22.04 nvidia-smi成功的标志是容器内nvidia-smi输出的显卡列表和宿主机一致驱动版本一致GPU 利用率、显存占用都是正常数字。如果这段能过说明设备映射和驱动注入都通了。有读者会问为什么测试镜像用nvidia/cuda官方基础镜像而不是自己打包的答案很简单——排查问题要隔离变量。官方镜像里 CUDA runtime 和驱动工具链是齐全的如果连它都跑不出nvidia-smi说明问题百分之百出在宿主机配置链路上不需要怀疑你的应用镜像。4.2 真实计算验证用 PyTorch 容器确认 CUDA 可用nvidia-smi能过不代表你的 AI 框架就能用因为框架还要依赖具体的 CUDA 库和 cuDNN。更接近实战的验证是拉一个 pytorch 官方镜像跑一个真实的张量运算docker run --rm --gpus all \ -v /tmp:/workspace \ pytorch/pytorch:2.3.1-cuda12.1-cudnn8-runtime \ python -c import torch; x torch.tensor([1.0, 2.0], devicecuda); print(x x.T)如果输出tensor(5., devicecuda:0)说明容器内的 PyTorch 已经完整拿到 GPU 能力这才是真正过验。实际调试时我还常在 python 命令里打印torch.cuda.device_count()和torch.cuda.get_device_name(0)确认几号卡、什么型号避免闹出调用了 0 号卡但 0 号卡已经被占了的笑话。4.3 为调度平台预留的节点信息采集环境准备不只是能跑通一个容器还要把节点的资源信息结构化方便调度器后续做决策。我在每个节点上固定跑一个脚本采集三类信息GPU 数量与型号nvidia-smi --query-gpuindex,name,memory.total --formatcsv,noheaderDocker runtime 是否支持 GPUdocker info | grep -i runtime节点空闲显存nvidia-smi --query-gpumemory.free --formatcsv,noheader这些信息在调度平台里就是节点的资源标签。比如gpu-nameNVIDIA-GeForce-RTX-4090、gpu-memory24GB、gpu-driver-version535后续调度器分配任务时全靠它匹配。这一步现在不做等节点一多再回补就很狼狈。5. 环境准备踩坑实录与排查思路5.1permission denied连不上 Docker API不是 Docker 坏了新手在 Linux 上执行docker ps最常见的报错permission denied while trying to connect to the Docker API原因很简单docker 命令默认通过 unix socket/var/run/docker.sock和 daemon 通信这个 socket 只有 root 和 docker 组有权限访问。你的用户不在 docker 组里权限不够。解决办法是把用户加进 docker 组sudo usermod -aG docker $USER newgrp docker注意把用户加入 docker 组等价于赋予其 root 能力因为 docker 可以挂载宿主文件系统、操作设备生产环境要严格限制可加入的用户。小团队内部问题不大但安全审计时你最好知道这个边界。5.2 GPU 驱动装了容器里却看不到卡八成是 Toolkit 漏配这是最典型的兜底坑。宿主机nvidia-smi完全正常但docker run --gpus all nvidia/cuda nvidia-smi报错常见报错有两种could not select device driver with capabilities: [[gpu]]Unknown runtime specified nvidia第一种是什么意思它说明 Docker 压根不认识 nvidia 这个设备能力也就是 NVIDIA Container Toolkit 没装或者装了但没执行nvidia-ctk runtime configure。处理方式就是回到第 3.2 节把 toolkit 的安装和 runtime 配置重走一遍然后确认docker info里有 nvidia runtime。第二种Unknown runtime specified nvidia则更明显——daemon.json 里的默认 runtime 配了nvidia但 Docker 没加载到nvidia-container-runtime这个二进制。这时检查nvidia-container-toolkit包是否完整安装、nvidia-container-runtime是否在 PATH 里必要的时候重装一遍 toolkit。我把排查思路整理成一张对照表方便大家直接对号入座现象可能原因排查/处理动作宿主机 nvidia-smi 正常容器内报 device selector 错误Toolkit 未安装或未配置 runtime安装 nvidia-container-toolkit执行nvidia-ctk runtime configure后重启 DockerUnknown runtime specified nvidiadaemon.json 已配置但容器 runtime 二进制缺失重新安装 toolkit确认/usr/bin/nvidia-container-runtime存在能跑 nvidia-smi 但程序报 CUDA driver version insufficient镜像内 CUDA 版本高于宿主机驱动支持版本换更低 CUDA 版本的镜像或升级宿主机驱动容器内 nvidia-smi 卡数与宿主机不一致--gpus 指定方式不对用--gpus all或显式指定--gpus device05.3 Windows 装机失败与老版本残留问题Windows 上还有一类隐蔽问题之前装过老版本的 Docker Toolbox后来改装 Docker Desktop启动始终报错。原因通常是老版本残留的 Hyper-V 虚拟机或环境变量污染了新版。处理方式是彻底清理卸载 Docker Desktop删除%ProgramData%\DockerDesktop和%USERPROFILE%\.docker禁用再重新启用虚拟机平台功能必要时重启 Windows 后再安装。另外一个高频问题是 Docker Desktop 与 VirtualBox / VMware 这类 Type-2 虚拟化软件冲突。它们都要用 CPU 虚拟化指令在 Windows 上经常打架。如果你日常需要使用虚拟机软件又要用 Docker建议关掉 VirtualBox 的硬件加速或改用 Hyper-V / WSL2 统一虚拟化层。5.4 镜像下载慢之外磁盘空间被镜像占满镜像加速配好后很多人又栽在磁盘上。训练镜像往往几个 GB 起节点上如果默认分区/var/lib/docker空间不足拉镜像会莫名失败日志里写着no space left on device。解决办法不是删镜像而是把 Docker 的数据目录迁移到大容量分区。修改/etc/docker/daemon.json{ data-root: /data/docker }然后重启 docker。迁移时注意原有镜像和容器数据不会自动搬过去需要手动把旧目录内容拷贝到新目录或直接用docker system prune -a清掉重建。生产节点上我建议一开始就规划好独立数据盘不要等爆了再处理。5.5 CUDA 容器版本与驱动版本匹配的黄金准则最后强调一次版本匹配。很多人的容器故障隔三差五出现核心就是镜像里的 CUDA 版本可以向下兼容但前提是宿主机驱动支持这条规则被打破。最稳妥的做法是在团队内约定一个标准版本组合比如宿主机统一装 535 或 545 系列驱动CUDA 容器统一用12.1、12.2或更低版本。这样任何任务镜像拿过来CUDA 版本都不会超过驱动的能力上限环境准备阶段就把版本漂移问题掐死在摇篮里。收尾环境准备到这里就够了把第 2 到第 4 节走通其实你已经具备运行 GPU 容器的全部基础能力。我自己在搭这套环境时最大的体会是Docker 和 GPU 的配置并不难难的是每一步都要理解它为什么这么设计。设备文件、驱动版本、运行时注册这三层概念捋顺了很多报错看都不用看就能猜到大概方向。环境准备好之后下一步可以开始搭建调度层了。下一篇我准备聊聊任务编排和服务发现也就是当节点上 GPU 容器能跑起来之后怎么把它管起来、分出去让多台机器的算力真正成为一个平台。到时候见。