企业官网建设流程全解析

做算力调度平台，环境准备是最容易糊弄、也最容易翻车的一步。我见过太多人把精力花在调度算法和平台架构上，结果节点起来之后GPU容器跑不起来，或者Docker一重启网络全乱。这个系列讲算力调度平台，第二篇就先把环境准备这件事彻底捋清楚，重点围绕Docker和GPU两条主线。这里适合两类人：一是准备自建算力调度平台的运维或研发，二是只想在本地把GPU容器环境跑通、方便复现深度学习任务的开发者。把这篇文章看完，你会明白调度平台为什么依赖Docker做封装，GPU直通到底卡在哪几个环节，以及环境准备阶段哪些坑必须避开。

我这里说的环境准备，不是简单执行几条安装命令，而是要把“宿主机驱动、容器运行时、调度资源模型”这三层关系理清，否则后面平台跑起来，排错成本会成倍增加。下面我先从为什么需要这套环境讲起，再按实际部署顺序一步一步展开。

1. 为什么算力调度平台绕不开Docker和GPU

1.1 环境隔离与调度解耦

算力调度平台要做的事情，本质上就是把物理GPU切分成逻辑资源，分给不同任务。如果没有容器化，单纯靠进程隔离，任务之间的Python版本、CUDA版本、系统依赖会互相打架。Docker在这里的价值是“能用”，而是把环境做成不可变镜像：调度器分发的是镜像，节点只需要保证容器运行时和GPU驱动正常，剩下的依赖全部固化在镜像里。这样上层调度逻辑与底层环境解耦，节点故障恢复也快，换一台节点，拉镜像就能跑。

我最早尝试过裸机方式管理环境，每个节点用Anaconda装环境，再用systemd管理进程。结果模型微调到一半，某个依赖升级影响了另一组任务，排查半天是动态库冲突。后来切到Docker，类似问题基本绝迹。给调度平台做环境准备，本质就是在给“可复现”打地基，这一层不稳，上层全是空中楼阁。

1.2 GPU直通是算力调度的地基

调度平台要调度GPU，容器就必须能看到真实的GPU设备。这里有两个层面的支持：驱动层和运行时层。驱动层由物理机上的NVIDIA驱动提供，运行时层则需要把NVIDIA的库和工具挂进容器。两者缺一不可。只有驱动没有运行时，容器里执行nvidia-smi大概率报错；只有运行时没有驱动，更是空谈。环境准备的重点，就是让Docker在启动容器时，能把宿主机的GPU设备及驱动库正确注入进去。

这个过程并不神秘：本质上就是给容器注入一组设备文件和动态库。但实际配置时，很多人栽在版本匹配上。驱动版本、CUDA版本、NVIDIA容器工具包版本、镜像内CUDA版本，任何一个错位，都可能导致容器内识别不到GPU，或者应用启动时直接报CUDA初始化失败。

1.3 准备环境前必须先搞清楚的三件事

动手之前，先回答三个问题：操作系统是什么、GPU型号是什么、调度平台打算跑在单机还是集群。操作系统决定安装方式；GPU型号决定驱动版本；单机还是集群决定你是只需Docker，还是还要配Kubernetes的GPU插件。这三件事没想清楚，后面很容易反复返工。

以我自己的环境为例：一台双路服务器，4张NVIDIA显卡，系统是Ubuntu 22.04，调度平台先跑在单机Docker上，后续要扩展到K8s。因此环境准备分两条线：先把Docker和GPU容器运行时跑通，再预留K8s的device plugin入口。下面每一步都是基于这个目标来的，你的目标如果不同，对应步骤可以裁剪。

2. 环境检查：动手装Docker之前先做这几步

2.1 操作系统与内核版本核查

Docker对内核版本有底线要求，尤其是老系统。建议至少Linux Kernel 3.10以上，长期运维的节点建议4.18以上，Ubuntu 20.04和22.04默认内核都满足。检查命令很简单：

uname -a cat /etc/os-release

如果发行版太老，比如CentOS 6，新版Docker已经不支持，别想着硬装，会浪费大量时间。我见过有人在老内核上装新版Docker，启动时直接报unsupported kernel，最后只能换系统。对于调度平台这种长期运行的底座，不值得为了迁就旧系统降低Docker版本，否则后续镜像兼容性会很难受。

2.2 虚拟化与容器运行时的检查

Windows端常见的问题是Docker Desktop提示virtualization support没开启，需要在BIOS里打开VT-x或AMD-V，并确认Windows功能里的“虚拟机平台”和“WSL2”两项已启用。Linux端则要检查是否已经装了其他容器运行时，比如containerd或podman，避免端口和socket冲突。

检查当前Docker状态可以用：

systemctl status docker 2>/dev/null || echo "docker not installed" ls /var/run/docker.sock 2>/dev/null || echo "no docker socket"

如果发现系统之前装过旧版Docker，建议先清理，不要覆盖安装。覆盖安装最典型的坑是：新二进制覆盖了，但旧配置还留在/etc/docker/daemon.json里，导致镜像源或存储驱动不符合预期。我踩过一次，明明改了daemon.json，Docker就是不生效，最后发现是旧进程没完全停干净。

2.3 GPU设备与驱动识别

检查NVIDIA驱动是否安装、能否看到GPU，命令是：

nvidia-smi

如果命令不存在，先装驱动。如果命令存在但报错，比如GPU is lost或者设备管理器错误代码43，先别急着装Docker，先把驱动问题解决。驱动装好后，记录下驱动版本和CUDA版本，例如Driver 535.154.05，CUDA 12.2。这个信息在后面配置容器工具包和挑选镜像时非常关键。

注意，nvidia-smi显示的CUDA版本是驱动所支持的最高版本，并不代表容器内必须用这个版本来跑程序。容器里可以向下兼容使用更低版本的CUDA镜像，比如驱动支持12.2，容器里跑CUDA 11.8的应用也没问题。但如果镜像的CUDA版本高于驱动支持版本，就会在初始化CUDA上下文时报错。

3. Docker安装与镜像源配置（实操向）

3.1 在Linux服务器上安装Docker Engine

如果用官方源安装，在Ubuntu上按顺序执行以下命令：

sudo apt-get update sudo apt-get install -y ca-certificates curl sudo install -m 0755 -d /etc/apt/keyrings sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") 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-buildx-plugin docker-compose-plugin

装完后启动并设置开机自启：

sudo systemctl enable --now docker sudo docker run hello-world

这里提醒一句，不要把docker-compose-plugin漏掉，后续编排调度平台组件经常用到。如果你所在环境无法访问download.docker.com，就换用发行版自带包源安装，但版本可能偏老。我个人建议能装官方源就装官方源，版本新，修复也多。

3.2 Windows环境用Docker Desktop还是Docker Engine

Windows上最常见的方案是Docker Desktop，它自带WSL2后端和GUI。但如果你要做的算力调度平台面向的是Linux服务器集群，Windows本机更适合做开发测试，不建议作为生产节点。Docker Desktop设置WSL2后，GPU支持相对简单，只要在WSL里安装对应版本的NVIDIA驱动，Windows驱动可以直接透传给WSL2，然后在Docker Desktop设置里勾选“Use the WSL 2 based engine”，后期跑带GPU的容器基本能开箱即用。

如果你更想在Windows上用纯Docker Engine方式，可以选择在WSL2发行版里安装Docker Engine，而不是用Docker Desktop。这样少了GUI，但和Linux服务器行为一致，排错时也更可控。我个人更推荐后者做调度平台的开发模拟，因为我后面写脚本也好、验证调度逻辑也好，都直接在WSL2的终端里操作，跟生产环境对得上。

3.3 镜像源与存储驱动配置

Docker安装完成后，至少要检查两个配置：镜像源和存储驱动。配置文件在/etc/docker/daemon.json，典型配置如下：

{ "registry-mirrors": ["https://docker.m.daocloud.io"], "data-root": "/data/docker", "exec-opts": ["native.cgroupdriver=systemd"], "storage-driver": "overlay2" }

每次修改daemon.json之后，要执行systemctl daemon-reload && systemctl restart docker。data-root建议放到独立数据盘，避免系统盘被镜像撑满。调度平台一到高峰期，镜像层缓存能占几十GB，放系统盘很容易把根分区写满，届时Docker会拒绝任何写操作，平台任务全部卡住。

cgroupdriver=systemd这个配置尤其重要。如果未来要接Kubernetes，kubelet默认用systemd作为cgroup驱动，Docker这里不保持一致，节点加入集群时会报驱动不一致错误。即使现在只跑单机Docker，也建议把这个参数写上，省得以后集群化改造时再动配置重启Docker。

4. GPU容器运行时：让容器能调用显卡

4.1 NVIDIA Container Toolkit安装

要让Docker调用GPU，光有驱动还不够，还需要NVIDIA Container Toolkit。官方名称是NVIDIA Container Toolkit，旧称nvidia-docker2。安装方法在Ubuntu上大致如下：

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的运行时识别到NVIDIA：

sudo nvidia-ctk runtime configure --runtime=docker sudo systemctl restart docker

这条命令会自动修改/etc/docker/daemon.json，加入nvidia运行时配置。装完之后马上跑docker info，看输出里是否出现nvidia字样，没有就说明配置没生效。Google搜到的很多老教程还是nvidia-docker2时代的方法，新版本已经统一为nvidia-container-toolkit，不要装错。

4.2 Docker默认运行时切换与配置

nvidia-ctk runtime configure命令除了帮你加nvidia运行时，还支持把它设为默认运行时。配置文件里会出现类似这样的一段：

{ "runtimes": { "nvidia": { "args": [], "path": "nvidia-container-runtime" } } }

如果没有设置default-runtime，那么跑GPU容器时必须显式加--gpus all参数。如果设置了default-runtime为nvidia，那么所有容器默认都能访问GPU，但也意味着安全面扩大：每个普通容器都看得到GPU设备。在算力调度平台上，我建议不要全量默认，而是让调度器在启动任务时按需指定--gpus，这样隔离性更好，也不会出现一个调试容器把GPU占用掉的情况。

4.3 验证GPU容器是否生效

装完之后跑一张测试镜像：

docker run --rm --gpus all nvidia/cuda:12.2.0-base-ubuntu22.04 nvidia-smi

如果能正常输出GPU列表，说明设备映射和库注入都成功。如果报错docker: Error response from daemon: could not select device driver "" with capabilities: [[gpu]]，说明容器工具包没有正确配置，大概率是没执行nvidia-ctk runtime configure，或者执行完后没有重启Docker。

另外要注意，镜像TAG里的CUDA版本不一定非得和宿主机驱动版本一致，但不要高于驱动支持的最高版本。这个放在实操环节尤其容易踩：有人拉了一个CUDA 12.3的镜像，结果宿主驱动只支持12.1，应用启动后直接段错误或者CUDA error。选镜像之前先看一眼nvidia-smi，再决定拉哪个TAG，能省很多时间。

5. 算力调度场景下的进阶配置

5.1 nvidia-smi与CUDA版本匹配

在调度平台上，每个任务可能会用不同CUDA版本的镜像。宿主机驱动是全局的，只需要大于等于任务的CUDA版本即可。一个实用建议：宿主机驱动尽量更新，这样既能兼容老CUDA镜像，也能跑新CUDA镜像。驱动版本与CUDA版本对照关系可以参考NVIDIA官方文档，安装驱动时别选latest随便装，至少确认它支持你们业务里最常用的CUDA版本。

另一个常被忽略的点：nvidia-smi看到的GPU显存是物理显卡的总显存，但容器默认不会限制显存，一个任务可以直接耗尽整张卡显存。调度平台的设计上需要在框架层做显存配额，Docker本身没有原生的显存限制，除开较新的MIG硬件特性。所以环境准备阶段要提前确定：到底打算用多少张卡、多少显存作为最小分配单元。这个决定会直接影响调度器的资源模型。

5.2 为调度平台预留的资源上限

Docker可以对CPU和内存做限制，但对显存的控制比较有限。通常做法是：平台管理组件单独放在非GPU节点，或者使用非常小的GPU比例；GPU节点专注于算力任务。同时建议在docker run时设置--cpus和--memory，避免一个失控任务打爆宿主机。示例：

docker run -itd --name task-01 --gpus '"device=0,1"' --cpus=16 --memory=64g nvidia/cuda:12.2.0-base-ubuntu22.04 sleep infinity

如果你的平台允许任务共享一张卡，可以只指定device=0，再通过镜像内的训练框架限制显存占比。但要注意，多个容器共享一张卡时，显存分配完全看任务自身行为，一旦有一个任务显存泄漏，整张卡可能OOM，进而影响其他任务。所以环境准备阶段就要把“单卡独占”还是“单卡共享”的策略定下来，并在调度器里实现对应的分配逻辑。

5.3 K8s环境里的GPU扩展点

如果你的算力平台从单机Docker走向K8s，一定要关注device plugin机制。NVIDIA官方提供了GPU device plugin，作为DaemonSet部署到每个GPU节点，这样K8s调度器才能感知GPU资源并做分配。同时需要为每个节点打标签，比如nvidia.com/gpu.present=true，并且通过Extended Resource方式暴露nvidia.com/gpu。这些字段在环境准备阶段就要想好，因为节点是否安装了NVIDIA Container Toolkit，决定device plugin能不能探测到GPU。

如果你不是立刻上K8s，至少保持daemon.json里的cgroupdriver=systemd一致，避免将来整改。真正的算力平台到了多节点以后，一定离不开K8s的调度能力，所以环境准备不是只给Docker用的，而是给“容器加资源调度”设计好底子。现在多花十分钟把配置写对，之后集群化会顺利很多。

6. 常见问题与排查技巧实录

6.1 Docker Desktop启动失败：虚拟化未开启

Windows端最常见的报错是Docker Desktop failed to start because virtualisation support isn't detected。处理分三步：第一步，BIOS里启用VT-x或AMD-V；第二步，Windows功能开启“虚拟机平台”和“适用于Linux的Windows子系统”；第三步，以管理员身份运行bcdedit /set hypervisorlaunchtype auto，然后重启。多数情况下重启就能解决。如果还不行，检查是否和其他虚拟机软件冲突，比如老版本VirtualBox可能干扰Hyper-V。

6.2 Linux容器里执行nvidia-smi提示not found

原因通常是宿主机驱动正常，但容器里缺少NVIDIA工具库。在正确配置NVIDIA Container Toolkit后，运行时会把宿主机的库注入容器，不应该出现not found。解决思路：先跑官方镜像而不是自打包镜像，排除镜像问题；再检查daemon.json里runtimes配置；最后手动执行nvidia-ctk runtime configure --runtime=docker并重启Docker。

6.3 GPU错误代码43

Windows上经常出现设备管理器里NVIDIA显卡错误代码43，本质是驱动或硬件层面的问题，不是Docker的锅。先用DDU卸载干净驱动，再安装厂家认证版本；如果使用WSL2，确保Windows驱动版本支持WSL2。出现43代码时，先修好宿主机GPU，不要试图用容器绕过宿主机故障，否则后面训练任务会莫名其妙失败。

6.4 Docker拉取镜像慢或超时

拉取镜像失败大多是网络问题。配置registry-mirrors后一般会改善，但注意不是所有镜像源都稳定，建议一个不够就配两三个。实际操作中，我还遇到过镜像源配置了，但docker pull默认还是走官方仓库，排查后发现Docker服务没有加载新的daemon.json，重启一次就好。镜像源要避免使用容易被干扰的服务，尽量选择多个备用源。

6.5 权限问题：docker run需要sudo

把当前用户加入docker组：

sudo usermod -aG docker $USER newgrp docker

加入后重新登录，一般就不用sudo了。不过要注意，docker组等同于root权限，不要随便把不信任的用户加进去。算力调度平台管理节点尤其要小心，给一个普通开发开docker权限，等于把主机的root权限也给他了。权限边界要在环境准备阶段就划清楚，别等出了问题再补救。

环境准备这件事，看起来只是装个软件，其实是在给整个调度系统划边界。我在实际部署中最大的体会是：先把驱动版本、CUDA版本、容器运行时版本这三者的匹配关系画成一张表，贴到机房的墙上；每次出问题先看表，能省下大半排查时间。另外，所有配置改动前都先备份daemon.json，别嫌麻烦。算力调度平台能不能稳定运行，往往不是调度算法多高明，而是环境底子有没有打扎实。