算力调度平台这个系列写到第二篇环境准备是绕不开的第一道坎。上篇聊了整体架构和资源抽象的思路对平台要解决什么问题、怎么把GPU资源池化和切分已经有了大方向。这篇接着往下推进把最底层的环境底座搭起来Docker和GPU联动。如果你是从这一篇开始看的也不影响环境准备这层是独立的照着做就行。为什么把环境准备单独拎出来写一篇因为算力调度平台后续所有东西——K8s调度、GPU显存隔离、任务编排、镜像分发——都建立在一套能稳定运行的容器加GPU环境上。环境没搭好后面每一步都会遇到莫名其妙的坑。比如容器里跑深度学习任务时提示CUDA不可用或者Docker Desktop一启动就报虚拟化错误又或者宿主机nvidia-smi正常但容器里死活看不到GPU这些问题的根源十有八九都出在环境准备阶段。这篇会把Docker安装、GPU驱动、NVIDIA Container Toolkit、容器内GPU验证这几个环节完整过一遍附带我实际部署中踩过的坑和排查方法尽量让你照着做一遍就能把环境跑通。1. 环境准备这件事先想清楚再动手1.1 算力调度平台为什么非要Docker加GPU这套组合先明确一个问题算力调度平台要调度的是什么表面上是任务和容器本质上调度的是计算资源重点是GPU。深度学习的训练和推理、大模型的微调、科学计算这些场景对GPU的依赖远超CPU。所以一个调度平台要真正落地它的底层必须有能力回答三个问题某个任务能用哪张GPU卡、能用多大显存、任务跑起来容器内部能不能实际访问到GPU的计算能力。Docker在这里扮演的角色是标准化封装和隔离。每个任务打包成一个镜像环境依赖、CUDA版本、Python环境全部固化在镜像里任务发到哪台机器跑起来效果都一样。GPU则通过驱动和运行时暴露给容器让容器内的CUDA应用可以直通宿主机显卡。这套组合的核心价值在于环境隔离做到了资源复用了任务还保持了可迁移性。如果你不是这次做调度平台只是单纯想在自己机器上跑深度学习这套环境准备同样是通用的。本地开发、模型微调、论文复现都需要先过这一关。所以这篇内容不管你是要搭一个大平台还是只想把单机GPU环境搞好都有直接参考价值。1.2 方案选型为什么是Docker而不是裸机或虚拟机聊一下我在环境选型上的思考过程。最朴素的做法是在裸机上装驱动、装CUDA、装Python环境然后直接跑训练脚本。这在单机单卡、没有多人协作的情况下没问题但一旦任务变多、环境需求冲突比如一个任务要CUDA 11.8另一个要CUDA 12.1裸机方案就乱了。你总不能每切换一次任务就重装一遍环境这在工程上是不可接受的。虚拟机方案可以隔离环境但有两个硬伤一是虚拟化层对GPU的透传配置复杂虚拟机和宿主机之间的性能损耗在计算密集型任务里不可忽略二是虚拟机动辄几十GB镜像起停时间以分钟计在调度场景下完全跟不上节奏。Docker正好落在中间进程级隔离启动秒级完成镜像分层复用GPU直通时不引入明显的性能损耗。对于算力调度平台这种需要频繁创建、销毁任务运行环境的场景容器是当前性价比最高的方案。这也是为什么当下主流AI基础设施——K8s、各种训练平台、推理服务框架——几乎全部以容器为底座。选Docker不是跟风是这个场景下的工程理性。1.3 前置检查清单动手前先花十分钟确认这些事无论在Linux还是Windows上做环境准备有几项前置条件必须先确认不然后面报错会报得你怀疑人生。操作系统版本Docker和GPU驱动对系统都有版本要求Ubuntu 22.04 LTS是目前兼容性最稳妥的选择。Windows的话建议Windows 11并打开WSL2功能。内核版本Linux下Docker对内核有最低版本要求64位系统、内核版本建议不低于5.x。太老的内核建议先升级。虚拟化支持Windows上跑Docker Desktop必须开启CPU虚拟化也就是BIOS里的Intel VT-x或AMD-V。这个不开Docker Desktop根本起不来。GPU与驱动版本先确认你的显卡型号和NVIDIA驱动版本支持情况。老显卡可能要装特定版本驱动新显卡太新反而可能遇到驱动还没跟上的问题这在部署时经常遇到。磁盘空间AI相关的镜像和容器动辄几个GB到十几个GB建议单独规划一个容量充足的数据盘。我经历过/var/lib/docker所在分区被打满导致所有容器异常退出的事故所以现在一律先把data-root指到大磁盘上。这些检查项看着琐碎但每一件都在实际排障中救过我的命。花十分钟确认比出问题后再排查两小时划算得多。2. Docker环境安装与基础配置2.1 Linux宿主机安装Docker以Ubuntu为例生产环境我强烈建议直接用Linux裸机或Linux虚拟机作为宿主机。这是算力调度平台真正要跑起来的地方Windows只适合做开发调试。以Ubuntu 22.04为例安装Docker的过程可以固化成一个标准操作sudo apt-get update sudo apt-get install -y ca-certificates curl gnupg lsb-release sudo mkdir -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg echo \ deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin几个容易被坑的点第一不要用系统自带源里的docker.io包版本老旧后续容器运行时兼容性差。第二安装的是docker-ce社区版这是最主流的选择不要用早期的docker-engine。第三docker-compose-plugin顺手装上后面编排多容器任务会用到。安装完成后的标准操作是把当前用户加入docker组避免每次执行docker命令都要sudo。注意这个操作有安全边界docker组内的用户等价于拥有宿主机root权限所以在多人共享的机器上要谨慎不能为了省事无脑把所有人加进去。sudo usermod -aG docker $USER newgrp docker然后启动并设置开机自启sudo systemctl enable docker sudo systemctl start docker2.2 配置daemon.json存储、网络与日志装好Docker只是第一步真正让它在生产环境里稳如老狗靠的是/etc/docker/daemon.json的配置。我常用的一个基础配置长这样{ data-root: /data/docker, log-driver: json-file, log-opts: { max-size: 200m, max-file: 5 }, registry-mirrors: [], exec-opts: [native.cgroupdriversystemd] }>sudo systemctl daemon-reload sudo systemctl restart docker2.3 Windows场景下的Docker Desktop与WSL2开发调试阶段很多同事习惯在Windows上工作。Docker Desktop现在的主流形态是WSL2后端其实就是让Docker跑在一个轻量级虚拟机里。这个模式下有两个前置条件必须满足BIOS开启虚拟化并且Windows里装好WSL2。检查虚拟化是否开启任务管理器性能标签页里能看到虚拟化状态。如果显示已启用继续装WSLwsl --install wsl --set-default-version 2Docker Desktop安装包下载安装后在Settings里把Use the WSL 2 based engine勾上。如果这里启动报错virtualization support wasnt detected先回BIOS确认VT-x/AMD-V是否打开再确认Windows功能里的Virtual Machine Platform和Windows Hypervisor Platform这两个组件是否启用。Windows上用Docker Desktop要注意文件挂载的性能问题。跨文件系统挂载在WSL2里I/O性能较弱编译类、大量小文件读写的任务会明显卡顿。一个折中做法是把代码放到WSL2的Linux文件系统里而不是放在Windows盘符下挂载进容器。2.4 安装后第一件事跑通一个容器环境装好后先用一个最小的容器验证Docker本身是否正常docker run --rm hello-world看到Hello from Docker!就说明Docker守护进程、镜像拉取、容器启停这条链路都通了。接着跑一个交互式容器验证基本的终端和网络能力docker run -it --rm ubuntu:22.04 bash apt-get update这两个小测试的必要性在于把基础链路和网络源的问题提前暴露掉避免后面GPU环境准备时把基础问题和GPU问题混在一起排查。我见过有人在一个网络都没通的Docker环境里折腾GPU排查了半天最后发现是镜像根本拉不动白白浪费了两小时。3. GPU支持打通驱动、运行时与容器3.1 宿主机GPU驱动安装与验证Docker就绪后开始处理GPU。第一步确保宿主机本身能识别GPU。Linux上安装NVIDIA驱动有两类主流方式用apt安装发行版仓库里的驱动包或者用NVIDIA官网的runfile安装脚本。apt方式在Ubuntu上很省事sudo apt-get update sudo ubuntu-drivers devices sudo apt-get install -y nvidia-driver-550ubuntu-drivers devices会列出当前机器推荐的驱动版本照着装就行。装完重启执行nvidia-smi能看到显卡型号、驱动版本、显存信息说明驱动工作正常。这里我提一个反直觉的细节nvidia-smi里的CUDA Version不是系统里安装的CUDA工具包版本而是当前驱动支持的最高CUDA运行时版本。应用实际使用的CUDA版本由容器或应用自身的CUDA库决定只要不超过这个上限即可。很多人把这两者混为一谈导致后面装CUDA时选错版本。踩坑提示Ubuntu从22.04开始默认启用Secure Boot如果BIOS里没关安装NVIDIA驱动后模块可能无法加载。表现是nvidia-smi提示找不到命令或报NVIDIA-SMI has failed because it couldnt communicate with the NVIDIA driver。解决办法有两种Secure Boot关闭后重装驱动或者给DKMS模块做MOK签名。命令行签名流程比较繁琐环境准备阶段我直接建议在测试机上关闭Secure Boot生产环境则要提前规划好签名流程。3.2 安装NVIDIA Container Toolkit宿主机能看到GPU不等于容器里能看到GPU。中间缺的关键组件叫NVIDIA Container Toolkit它负责在Docker容器启动时把GPU设备、驱动库和nvidia-smi工具注入到容器的运行环境里。这里解释一下原理Docker本身不认识GPU硬件。没有Toolkit时即使宿主机的/dev/nvidia0设备节点就在那里容器默认也访问不到。NVIDIA Container Toolkit做的事是在容器创建时通过prestart hook动态向容器配置注入GPU设备和驱动库让容器内的CUDA应用能够和宿主机驱动通信。执行安装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然后配置Docker的运行时sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart dockernvidia-ctk runtime configure这个命令会把NVIDIA Container Runtime注册到Docker的运行时配置里。重启Docker后docker info里应该能看到Runtimes: nvidia这一项。这一步做完Docker才真正具备了把GPU暴露给容器的能力。3.3 容器内nvidia-smi验证验证是最激动人心的一步。拉一个带CUDA的基础镜像从容器里执行nvidia-smidocker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi如果你看到宿主机里那张熟悉的信息表出现在容器内说明GPU打通了。注意一个细节容器内nvidia-smi显示的Driver Version和宿主机的驱动版本通常是一致的。因为容器里的驱动库直接借用宿主机驱动容器内并没有真正的驱动内核模块。这是正常设计不是配置错了。再验证一下容器能否真正执行CUDA计算。用一个带CUDA runtime的镜像在容器内跑一段GPU运算docker run --rm --gpus all nvidia/cuda:12.4.0-runtime-ubuntu22.04 bash -c cat /usr/local/cuda/version.json如果只是想确认设备可用可以写一段小的CUDA样例程序或者直接验证PyTorch。但是要注意整个CUDA镜像体积不小动辄两三个GB。如果只为了验证环境用nvidia/cuda:12.4.0-base-ubuntu22.04就够了。3.4 PyTorch GPU环境实测GPU环境和Docker打通后再上一个大名鼎鼎的PyTorch做最终验证。这一步模拟的是真实的深度学习运行环境。首先拉取官方PyTorch镜像docker run -it --rm --gpus all -v /workspace:/workspace pytorch/pytorch:2.3.0-cuda12.1-cudnn8-runtime bash容器内执行python -c import torch; print(torch.__version__); print(torch.cuda.is_available()); print(torch.cuda.device_count()); print(torch.cuda.get_device_name(0))如果输出True和你的显卡型号算力调度平台的单机GPU环境就算真正落定了。这一步能跑通说明驱动、Container Toolkit、Docker、CUDA运行库之间的所有链路都是通的。这里有一个常见问题在容器内用pip安装PyTorch时默认安装的是CPU版导致运行torch.cuda.is_available()返回False。这是因为PyTorch从2.0版本开始默认pip索引里的包不一定带CUDA支持。解决办法是显式安装带CUDA索引的版本。这一点在多台机器上是很容易踩的坑。4. 环境准备阶段的典型问题与排查实录4.1 容器里看不到GPU八成是Toolkit的问题症状宿主机nvidia-smi正常但容器里执行nvidia-smi提示command not found或者运行带--gpus all命令时报错。排查顺序按概率排列第一确认docker info里有没有显示Runtimes: nvidia没有就说明Container Toolkit没配置好重新执行nvidia-ctk runtime configure并重启Docker。第二确认容器命令里加了--gpus all参数老版本Docker如果没有这个参数在run时也看不到GPU。第三确认驱动和Toolkit版本兼容性。第四检查/dev/nvidia*设备节点是否存在如果设备节点异常多半是驱动模块加载有问题。按这个顺序排查绝大多数情况都能定位。4.2 Docker Desktop启动失败的虚拟化问题Windows场景下Docker Desktop最常见的启动失败报错是virtualization support wasnt detected。这个报错说白了就是WSL2依赖的虚拟化能力没有就绪。排查从三个层面展开BIOS里开启Intel VT-x或AMD-VWindows功能里启用Virtual Machine Platform和Windows Hypervisor Platform如果Hyper-V和第三方的沙盒软件冲突比如旧版VMware、部分安卓模拟器也可能导致虚拟化检测失败这种情况下关闭冲突软件的虚拟化独占功能即可。还有一类特殊情况Windows系统更新补丁导致WSL2内核组件损坏。表现是wsl --status异常。用管理员执行wsl --update可以修复。4.3 驱动版本、CUDA版本与镜像版本的匹配关系三者的关系比很多人想象的宽松。NVIDIA驱动具备向后兼容性新的驱动可以运行旧版的CUDA但旧驱动跑不了新版CUDA。所以宿主机驱动的原则是选新不选旧而应用镜像里的CUDA版本按任务需求来。举个例子宿主机安装Driver 550CUDA 12.1、12.4这些镜像都能跑反过来宿主机驱动是470CUDA 12.4的应用镜像大概率就会报CUDA init失败。所以环境准备阶段我建议直接安装当前官网主流的稳定版驱动给后续应用镜像留足向上兼容的空间。关于CUDA镜像标签的命名需要提一句nvidia/cuda镜像分为base、runtime、devel三个层级。base只包含最基础的CUDA库runtime加了运行时devel才有完整的开发工具链。调度普通推理任务用runtime就够训练任务需要编译算子时选devel。4.4 网络不通、镜像拉取慢的处理思路Docker环境搭建后下一个常见痛点是网络。镜像拉取超时、下载到一半中断单凭这个原因就能让环境准备卡住一整天。首要对策是前面提到的registry-mirrors配置。多填几个备选镜像源。第二个对策是给容器配置HTTP代理环境变量这个适合公司网络需要通过代理访问外网的情况。还有一类隐蔽问题是容器内的DNS解析异常表现是容器内apt-get update失败但宿主机网络正常。这种问题可以在daemon.json里配dns: [8.8.8.8, 114.114.114.114]解决。另外容器网络和宿主机网段冲突也会引发诡异现象。Docker默认bridge网络的网段是172.17.0.0/16如果宿主机所在的内网正好在同一个网段容器访问内网服务就会出现路由异常。处理方式是修改daemon.json里的bip参数把这个网段改掉比如bip: 10.66.0.1/24。4.5 附环境准备快速排查表症状大概率原因快速处理容器内执行nvidia-smi: command not foundContainer Toolkit未安装或未注册运行时安装Toolkit并执行nvidia-ctk runtime configure --runtimedockerDocker Desktop启动提示virtualization support未检测到BIOS未开虚拟化WSL2组件缺失开启VT-x/AMD-Vwsl --update宿主机nvidia-smi失败驱动未加载或Secure Boot阻挡驱动模块重启检查dmesg容器内CUDA应用报版本不匹配驱动版本过老或应用对应CUDA版本过高升级宿主机驱动torch.cuda.is_available()返回False装了CPU版PyTorch用官方镜像或指定cu121/cu124索引重新安装镜像拉取超时或中断镜像源不稳定或网络问题配置registry-mirrors必要时配置代理容器内访问内网服务不通Docker网段和宿主机局域网冲突修改daemon.json的bip参数调整网段日志写满磁盘导致容器异常日志无限增长data-root空间耗尽配置log-opts限制日志大小将data-root迁移到大分区5. 环境准备完成后下一步往哪走环境准备这层踩实之后算力调度平台才算真正有了地基。回顾这篇文章的内容核心其实就三件事Docker正常跑、GPU驱动正常加载、Container Toolkit把GPU暴露给容器。三步走完单机上的容器化GPU环境就具备了。这个过程中有几个我特别想再强调的体会。第一环境准备不要赶进度每一层都要验证通过再往下走。宿主机驱动没验证就直接装Toolkit出问题了根本不知道是驱动还是Toolkit的问题。第二Docker的daemon.json要早规划磁盘、日志、网段这些都是运行时才暴雷的问题与其等生产环境出故障再去救火不如现在就把参数定好。第三日志和监控从一开始就要留好后续做算力调度时每个节点的GPU利用率、显存占用、任务状态都要有数据可查。接下来这个系列要处理的问题会更复杂多节点下怎么统一管理GPU资源任务调度怎么做显存怎么隔离镜像仓库怎么搭建。但这些都是在当前这套Docker加GPU环境上继续叠加。环境稳了后面的事才有讨论的前提。下一篇我会写多机环境下GPU资源的管理和任务调度的初步方案那是算力调度平台真正进入到核心逻辑的部分。恰好我手里还有一台没装驱动的备用机正好用来验证多节点方案到时候实测数据直接写到下篇里。