1.1 大模型开发的真实痛点：为什么 venv + pip 撑不起工程

1.1 大模型开发的真实痛点：为什么 venv + pip 撑不起工程

很多读者刚听到"用 Docker 装大模型环境"时，第一反应是：我一个 python -m venv、pip install torch 不就完了吗？为什么非要折腾容器？

这一节我们专门拆解这个问题。结论先放在前面：在大模型场景里，虚拟环境（venv/virtualenv）解决的是"Python 依赖"的隔离，但解决不了"系统级 CUDA 栈"和"GPU 硬件资源"的隔离——而这恰恰是大模型开发最致命的两块。

痛点一：依赖不是一维的，而是一个"版本矩阵"

普通 Python 项目的依赖是一个平面列表：flask==2.0、requests==2.28。但大模型项目的依赖是一个三维耦合矩阵：

致命点在于：CUDA 不是 pip 能管得了的东西。PyTorch 的 GPU 版本（cu118/cu121 后缀）本质是把一份 CUDA 运行时静态或动态链接进 wheel 里，它依赖宿主机的 NVIDIA 驱动满足最低版本要求。驱动在系统层、CUDA 在工具链层、Python 包在应用层——三层中只要有任何一层对不上，要么装不上，要么装上了 torch.cuda.is_available() 返回 False，要么更隐蔽：能跑但精度异常、随机种子失效，复现不出论文结果。

venv 只能隔离最上面的"Python 包"那一层，对下面两层无能为力。这也是为什么你明明在虚拟环境里装好了 torch，却在服务器上报 libcudart.so.11.0: cannot open shared object file——这个 .so 文件根本不在 venv 的隔离范围内。

# 一个真实到几乎人人都见过的报错
ImportError: libcudart.so.11.0: cannot open shared object file: No such file or directory
# 你装的是 torch cu118，但宿主机只有 CUDA 12.x 的 libcudart.so.12，
# 系统里找不到 .so.11.0，torch 直接起不来。
​

注意，这种错不是 Python 层面的错误，而是 Linux 动态链接器在加载阶段就失败了。无论你的 requirements.txt 锁得多么精确，只要宿主机 CUDA 链接库版本不匹配，代码连第一行都跑不到。这正是 venv 的盲区：它管得了 site-packages，管不了 /usr/lib/x86_64-linux-gnu/ 下那一堆 .so。

痛点二：GPU 是"独占型"资源，却常被当成"共享型"用

CPU 和内存可以靠操作系统做细粒度的时间片与地址空间隔离；但 GPU 在大模型训练/推理时是近乎独占的：一张卡被某个进程占满显存后，别的进程要么排队、要么 OOM。

在没有隔离措施的裸机共用服务器上，常见惨剧是这样发生的：

1. 同学 A 启动了一个没限制显存占用的训练任务，吃掉了整张卡；
2. 同学 B 的推理服务在同一张卡上 out of memory；
3. 两边都不知道是谁占了卡，只能互相猜、互相 kill；
4. 更糟的是，有人用了 CUDA_VISIBLE_DEVICES 但配错，任务和监控看到的根本不是同一张卡。

venv 对 GPU 资源隔离完全不提供任何能力。进程之间是平等的、共享整台机器的全部 GPU，谁先抢到算谁的。这不是"协作"，这是"抢板凳"。

我们再看一个更隐蔽的例子。假设一台 4 卡机器，你只想在 2 号卡上跑实验：

# 你以为这样就把任务绑到 2 号卡了
CUDA_VISIBLE_DEVICES=2 python train.py
# 但如果启动顺序、环境变量继承出了问题，
# 实际可能落在 0 号卡上，和别人的任务撞车。
# 更危险的是多人各设各的，谁也不知道全局视图。
​

在没有统一调度的情况下，每个人都"以为"自己用的是空闲卡，结果全局上显存被悄悄吃满。这种问题靠记笔记、靠群里喊话是压不住的，必须从机制上把"谁能用什么卡、用多少显存"固化下来。

痛点三：复现性危机——"实验"变成了玄学

大模型研发的命脉是可复现的实验。今天这个超参组合跑出 92% 准确率，明天想对照另一个组合，前提是"除了超参其他全一样"。

但现实是：

• 系统 glibc 版本不同，导致 tokenizers 并行分词行为不一致；
• 两个同学装的 transformers 差一个小版本，默认 attention 实现变了，输出差了 0.3%；
• 有人用 conda，有人用 pip，有人用系统包，环境根本对不齐，对不齐就无从比较。

当环境本身是不可控变量时，整个"实验"的科学性就塌了。你分不清性能提升来自你的算法改进，还是来自某次顺手升级。venv 的 requirements.txt 往往只锁 Python 包、不锁系统库，复现时差之毫厘谬以千里。

举个具体例子：PyTorch 2.x 引入了 torch.compile，但同一份代码在 CUDA 11.8 和 12.1 下编译出的算子内核可能走不同的代码路径，端到端性能差出 10%~20% 并不罕见。如果你的实验基线在 A 机器（cu118）、对照实验在 B 机器（cu121），那你比的根本不是"算法"，而是"编译器后端"。

痛点四：环境漂移与"雪花服务器"

裸机环境会随着时间"漂移"：今天装个 A 库、明天升个驱动、后台自动更新……几个月后这台机器就变成了一朵独一无二的"雪花"——谁都不敢动，动了就崩，而且无法在另一台机器上重建出一模一样的副本。

这带来两个后果：一是服务器宕机后恢复极慢；二是扩容时无新机器可用，因为"那套环境"只存在于这一台机器里。

环境漂移的一个典型推手是操作系统的包管理器。你在一台 Ubuntu 22.04 上 apt install 了一堆编译依赖，半年后另一台同版本系统由于镜像源更新，装出来的底层库版本已经变了。两次安装之间，系统的"真实状态"已经不可同日而语。

痛点五：新人上车的成本鸿沟

把上面四点叠加，新人加入团队的第一周通常这样度过：照着文档装环境 → 报错 → 问老人 → 老人说"我机器上是好的，你缺个系统库" → 装系统库 → 又报另一个错 → 折腾三天，终于能跑，但没人说得清到底哪一步是必须的。

这种"配置靠口口相传、靠玄学"的状态，是团队规模化的天花板。更糟的是，一旦那个"老人"离职，这套环境的知识就彻底失传，团队被迫从头摸索。

一个量化的视角：裸机 vs 容器化的隐性成本

我们可以粗略地把"环境搭建"的成本画成一张对比表，帮团队负责人算笔账：

这张表不是精确测量，而是经验性排序，目的是说明：容器化省下的不是"一次"时间，而是"每一次"重复搭建与环境漂移带来的累计损耗。当团队只有你一个人、只在一台机器上玩模型时，这些痛点确实可以忍；一旦进入多人、多机、长期迭代，它们会从"小麻烦"变成"系统性阻塞"。

为什么 conda 也救不了 CUDA 层

有人会反驳：我用 conda 不就行了？conda 不是能装 cudatoolkit 吗？

这是个常见的误解。conda 确实能管理一部分 CUDA 运行时（它的 cudatoolkit 包提供了部分 .so），但关键限制是：

1. conda 的 cudatoolkit 只是运行时的子集，并不等于完整 CUDA 工具包，编译型算子（比如你从源码编译的自定义 CUDA 扩展）往往仍需要宿主机的完整 CUDA 与驱动；
2. 驱动依然在 conda 之外。NVIDIA 内核驱动是系统级组件，conda 装不了也管不了，最低驱动版本要求照样卡你；
3. conda 环境本身也会漂移，而且它的依赖求解器在某些深度学习栈下极其缓慢、容易解出不一致的环境。

换句话说，conda 把“Python 包 + 部分 CUDA 运行时”的隔离做得比 venv 好一点，但面对“驱动版本 / 完整 CUDA 工具链 / GPU 硬件配额 / 跨机复刻”这四道关，它和 venv 站在同一侧。真正要跨过去，得靠容器把整条栈一起封进一个不可变镜像。

GPU 隔离为什么比 CPU 隔离难得多

理解这一点，才能理解后面容器 GPU 透传的巧妙。

CPU 的虚拟化已经非常成熟：操作系统天然给每个进程独立的虚拟地址空间，虚拟机靠硬件扩展（如 Intel VT-x）做指令级隔离，Kubernetes 靠 cgroups 做 CPU 时间片和核数的硬配额。这一切的基础是：CPU 的计算是无状态的、可切片的时间资源。

GPU 则完全不同：

• 显存是物理独占的。一张卡的显存被映射成具体地址，CUDA 上下文（context）一旦在某张卡上建立，进程就牢牢占住一部分显存，cgroups 这种 CPU 时代的配额手段对显存几乎无能为力；
• 算力是以“kernel 发射”形式存在的。一次矩阵乘是一个 GPU kernel，它占满整张卡的计算单元，你很难像切 CPU 时间片那样把“半个 SM”分给别人；
• 驱动是唯一入口。所有对 GPU 的访问都必须穿过 NVIDIA 驱动，而驱动默认把整张卡暴露给所有能访问 /dev/nvidia* 设备文件的进程。

这意味着：在裸机上，只要一个进程能打开 /dev/nvidia0，它就能用满整张卡，没有任何原生的“按用户/按进程”的配额。这正是共享服务器上 GPU 大战的根源。要在不虚拟化整张卡的前提下实现“隔离但又能用”，就需要一条精巧的中间路径：让容器看起来独占了一张卡，实际上底层通过驱动和 runtime 做设备与显存视角的裁剪——这正是 NVIDIA Container Toolkit 在做的事，我们会在第三章深入其原理。

这里先记住一个判断：CPU 隔离靠操作系统就够了，GPU 隔离必须靠“驱动 + 容器运行时”的协作。这也是为什么“Docker + CUDA”不是可选项，而是大模型隔离沙箱的事实标准底座。

场景回放：一次典型的“跨机复现失败”

为了让痛点不只是抽象列表，这里复盘一个虚构但极其常见的真实事故链。某团队在 2 号机器上微调出一个 7B 模型，准确率 91.2%，准备在 5 号机器上做对照实验：

1. 把代码和 requirements.txt 拷到 5 号机，创建 venv，pip install -r requirements.txt；
2. 跑起来就报 libcudart.so.11.0 缺失——5 号机的 NVIDIA 驱动较新但 CUDA 软链接指向 12.x；
3. 同学手动软链了一个 .so.12 冒名顶替，import 过了，但训练中途 CUDA illegal instruction 崩掉；
4. 改用 conda 重装 cudatoolkit=11.8，import 正常，但跑出来的准确率只有 90.4%，差了将近 1 个百分点；
5. 全组花两天排查，最后发现 2 号机当时偷偷升级过 transformers 小版本，而 requirements.txt 没锁死，导致注意力实现默认值不同。

这起事故里，没有一个步骤写明了“机器到底装了什么”。环境是被口头约定和临时补救拼起来的，所以一旦跨机，所有隐藏假设全部暴露。如果当初把环境封进一个不可变镜像，第 1 步到第 5 步根本不会发生——因为镜像自带正确的 CUDA 运行时、正确的库版本，且任何人拉到的都是同一份。

这个例子也揭示了一个反直觉的洞见：容器化最大的收益往往不是“省安装时间”，而是“消灭隐藏假设”。当环境变成一份可以被哈希、被版本化、被 diff 的文件时，你和同事、你和服务器、你和三个月后的自己，就拥有了一份共同的事实基准。

小结：venv 没做错什么，只是它管不了大模型最麻烦的那层

把五个痛点归纳一下，会发现有三条 venv 永远解决不了：

• 系统级 CUDA 栈的版本一致性（驱动/CUDA/库的三层耦合）；
• GPU 硬件资源的隔离与配额（显存、算力、卡的分配）；
• 跨机器的一键复刻（环境即代码）。

而这三条，恰恰是"隔离式容器沙箱"的主战场。下一节我们就来看，容器 + GPU 透传到底是在隔离什么、怎样隔离的。

提示：本节提到的 NVIDIA 驱动最低版本与 CUDA 版本的对应关系、PyTorch 各 CUDA 编译版本的适配表，建议以 NVIDIA 官方文档与 PyTorch 官方安装说明为准，避免凭记忆填版本号。实际部署前，请用 nvidia-smi 与 nvcc --version 核对你手头机器的真实版本，再决定使用哪个 CUDA 基础镜像标签。