第四章 · 实战案例：把真实模型塞进沙箱

第四章 · 实战案例：把真实模型塞进沙箱

前两章我们搭好了镜像骨架、讲透了 GPU 透传与隔离的本质。这一章不再停留在 hello-world 级的 demo，而是把工业界真实会遇到、也最容易踩坑的两类负载搬进沙箱：一类是训练 / 微调任务，特点是长时、多卡、重 IO、要留日志和断点；另一类是推理服务，特点是常驻、要稳、要对外暴露、要控资源。这两类负载对沙箱的要求几乎是"两个极端"，对应的 Docker 写法也完全不同。

本章 4.1 拆解训练任务沙箱化，4.2 拆解推理服务沙箱化。读完这两节，你应该能把手上任何一个真实模型项目，干净地装进一个可复现、可迁移、不留"我机器上能跑"后遗症的沙箱。

本章 4.1 拆解训练任务沙箱化，4.2 拆解推理服务沙箱化。读完这两节，你应该能把手上任何一个真实模型项目，干净地装进一个可复现、可迁移、不留「我机器上能跑」后遗症的沙箱。

本章你会带走什么

为了避免你读到一半忘了目标，先给出这一章结束时你应当能独立说出的三句话：

1. 训练沙箱看什么：多卡先解决 IPC 共享内存、数据永远走挂载卷不进镜像、checkpoint 必须外溢且能续跑。
2. 推理沙箱看什么：限定设备不抢卡、只暴露必要端口、框架层设并发上限防 OOM、加健康端点并让容器崩溃自愈。
3. 两者共同的归宿：都该写进 compose 文件固化成团队可复用的「说明书」，而非散落在某台机器上的手敲命令。

如果你读完两节后能用上面三句话复述，说明这一章真的进了你的知识体系，而不是「看过了」。带着这三句话去读 4.1 和 4.2，你会更容易抓住每节的重心。

本章要解决的两类真问题

训练任务和推理服务，在资源模型上是两种完全不同的东西，很多团队一开始用同一套模板去套，结果要么训练把盘写满，要么推理半夜 OOM 被 kill。

• 训练 / 微调：一次性（或周期性）启动，跑几小时到几天，占用多张 GPU；需要把数据集、检查点（checkpoint）、日志持久化到容器之外，失败要能续跑。它对"启动速度"几乎不敏感，但对"数据不丢、多卡能协同、环境完全可复现"极度敏感。
• 推理服务：进程常驻，7×24 对外提供 API；单请求延迟敏感，需要端口映射、健康检查、限流、资源上限。它对"可复现"也敏感，但对"稳定不崩、崩溃秒级重启、资源可控"更敏感。

一个很现实的判断标准：看进程会不会自己退出。训练脚本跑完主循环就 exit 0，容器随之停止；推理服务是 while True 永远不退出。这个差异直接决定了你是该用 docker run 一次性跑，还是该用 docker compose + 重启策略把它当服务养着。

为什么实战案例要单独成章

原理讲得再透，落到真实项目里依然会卡在细节：数据集几十 GB 怎么挂？多卡训练 NCCL 通信为什么在容器里失败？推理暴露端口后外部为什么连不上？这些都不是"原理"能直接回答的，需要的是经过验证的、能直接复用的工程写法。

这一章给出的不是"标准答案"（因为不同框架、不同硬件差异很大），而是一套决策框架和可套用的模板骨架：你照着填空，就能避开 90% 的新手坑。凡涉及具体版本号、默认开关、命令参数，文中会明确标注"以你所用版本官方说明为准"，绝不臆造运行结果。

阅读建议

建议先读 4.1，建立"训练负载"的沙箱心智模型——重点理解多卡协同对网络与设备视图的要求、以及数据卷为什么是训练沙箱的命门；再读 4.2，看服务化如何反过来约束设计——端口、健康检查、资源上限成了主角。两节都假设你已完成第二章的镜像骨架，可以直接复用其中的基础镜像与依赖层，不必从零再来一遍。

为什么训练沙箱和推理沙箱几乎是两个物种：训练追求「一次跑完、产出落盘、能续跑」，所以它的关键词是挂载卷、续跑逻辑、--shm-size；推理追求「永远在线、稳如老狗、被调得动」，所以它的关键词是重启策略、端口映射、资源上限、健康探活。把这两套模板都收进 compose 文件，你就拥有了从「数据进沙箱训练」到「模型出沙箱服务」的完整链路。

本章与其他章的衔接

为了避免你读成孤立的几篇，这里明确第四章在整本书里的位置：

• 它依赖第二章的镜像骨架。无论是训练镜像还是推理镜像，都不是从零装环境，而是复用第二章做好的基础镜像与依赖层。如果你还没读第二章，建议先回去把「镜像分层」「可复现依赖」「数据卷策略」三节读透，否则本章的挂载、--gpus 透传会显得没来由。
• 它是第三章原理的落地。第三章讲透了 NVIDIA Container Runtime 的调用链、显存与算力及设备视图的隔离边界；本章训练部分的「多卡通信为什么在容器里失败」本质上就是第三章调用链在 NCCL 场景的具体表现，推理部分的「资源上限」则直接对应第三章「设备视图隔离边界」的工程化。原理懂了，本章的写法你才会「知其所以然」而不是「背模板」。
• 它为第五章铺路。第五章会把「训练沙箱 + 推理沙箱 + compose 固化」提炼成一套可迁移的标准化工程方法，并讨论它在更大团队、更多框架下的演进。本章给你的具体操作，到第五章会被抽象成原则。

一句话：第二章给你「积木」，第三章给你「积木为什么这样拼」，第四章给你「拼成一个能跑的真实东西」，第五章给你「怎么把这套拼法变成团队标准」。

实战心法：沙箱化的本质是「把隐性知识变成显性文本」

读到这里你也许发现，本章几乎没有「新原理」，全是「把前面原理落到具体场景的写法」。这恰恰是沙箱化最容易被低估的价值：它把团队里那些「只有老手知道」的隐性经验，固化成了可复制的文本。

• 「多卡训练要先加 --shm-size」——以前是口口相传的踩坑教训，现在写进 compose，新人不会再踩。
• 「推理别把权重挂成可写」——以前是某次事故后的复盘，现在变成 :ro 一行配置。
• 「容器一删训练白跑」——以前是某同事加班重训的惨痛回忆，现在变成 checkpoint 外溢与 --resume 的标准动作。

所以当你把训练、推理两套模板都写进仓库的 compose 文件，你交付的不只是「两个能跑的服务」，而是一份「团队不会因为人员流动而丢失的工程资产」。这正是体系化教程想传递的核心理念：工具用法的价值是有限的，把用法沉淀成可复用的资产，价值才是长期的。

下一节，我们从一个最朴素的训练命令开始，一步步把它改造成生产可用的沙箱写法。