企业官网建设流程全解析

算力调度平台这个系列写到第二篇，环境准备是绕不开的第一道坎。上篇聊了整体架构和资源抽象的思路，对平台要解决什么问题、怎么把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 docker

2.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.cgroupdriver=systemd"] }

>sudo systemctl daemon-reload sudo systemctl restart docker

2.3 Windows场景下的Docker Desktop与WSL2

开发调试阶段，很多同事习惯在Windows上工作。Docker Desktop现在的主流形态是WSL2后端，其实就是让Docker跑在一个轻量级虚拟机里。这个模式下有两个前置条件必须满足：BIOS开启虚拟化，并且Windows里装好WSL2。

检查虚拟化是否开启，任务管理器性能标签页里能看到虚拟化状态。如果显示已启用，继续装WSL：

wsl --install wsl --set-default-version 2

Docker Desktop安装包下载安装后，在Settings里把Use the WSL 2 based engine勾上。如果这里启动报错virtualization support wasn't 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-550

ubuntu-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 couldn't 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 --runtime=docker sudo systemctl restart docker

nvidia-ctk runtime configure这个命令会把NVIDIA Container Runtime注册到Docker的运行时配置里。重启Docker后，docker info里应该能看到Runtimes: nvidia这一项。这一步做完，Docker才真正具备了把GPU暴露给容器的能力。

3.3 容器内nvidia-smi验证

验证是最激动人心的一步。拉一个带CUDA的基础镜像，从容器里执行nvidia-smi：

docker 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 wasn't detected。这个报错说白了就是WSL2依赖的虚拟化能力没有就绪。

排查从三个层面展开：BIOS里开启Intel VT-x或AMD-V；Windows功能里启用Virtual Machine Platform和Windows Hypervisor Platform；如果Hyper-V和第三方的沙盒软件冲突，比如旧版VMware、部分安卓模拟器，也可能导致虚拟化检测失败，这种情况下关闭冲突软件的虚拟化独占功能即可。

还有一类特殊情况：Windows系统更新补丁导致WSL2内核组件损坏。表现是wsl --status异常。用管理员执行wsl --update可以修复。

4.3 驱动版本、CUDA版本与镜像版本的匹配关系

三者的关系比很多人想象的宽松。NVIDIA驱动具备向后兼容性：新的驱动可以运行旧版的CUDA，但旧驱动跑不了新版CUDA。所以宿主机驱动的原则是选新不选旧，而应用镜像里的CUDA版本按任务需求来。

举个例子：宿主机安装Driver 550，CUDA 12.1、12.4这些镜像都能跑；反过来宿主机驱动是470，CUDA 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 附：环境准备快速排查表

5. 环境准备完成后，下一步往哪走

环境准备这层踩实之后，算力调度平台才算真正有了地基。回顾这篇文章的内容，核心其实就三件事：Docker正常跑、GPU驱动正常加载、Container Toolkit把GPU暴露给容器。三步走完，单机上的容器化GPU环境就具备了。

这个过程中有几个我特别想再强调的体会。第一，环境准备不要赶进度，每一层都要验证通过再往下走。宿主机驱动没验证就直接装Toolkit，出问题了根本不知道是驱动还是Toolkit的问题。第二，Docker的daemon.json要早规划，磁盘、日志、网段这些都是运行时才暴雷的问题，与其等生产环境出故障再去救火，不如现在就把参数定好。第三，日志和监控从一开始就要留好，后续做算力调度时，每个节点的GPU利用率、显存占用、任务状态都要有数据可查。

接下来这个系列要处理的问题会更复杂：多节点下怎么统一管理GPU资源，任务调度怎么做，显存怎么隔离，镜像仓库怎么搭建。但这些都是在当前这套Docker加GPU环境上继续叠加。环境稳了，后面的事才有讨论的前提。下一篇我会写多机环境下GPU资源的管理和任务调度的初步方案，那是算力调度平台真正进入到核心逻辑的部分。恰好我手里还有一台没装驱动的备用机，正好用来验证多节点方案，到时候实测数据直接写到下篇里。