📚 课程目录第1章课程导入

课程导入：学习目标、课程结构、平台搭建的整体流程与关键决策点

一、核心原理：为什么需要自建 AI 训练平台

在接触具体工具之前，我们首先要回答一个根本问题：为什么不能直接在一台服务器上跑训练脚本，而非要搭建一个“平台”？ 这个问题的答案，决定了整门课程的设计逻辑。

单机训练在实验阶段完全可行，但当团队规模扩大、模型迭代次数增加后，会迅速暴露四类矛盾：资源争抢（谁先用 GPU？）、环境冲突（A 需要 PyTorch 1.13，B 需要 2.1）、实验不可复现（跑完就忘，参数丢失）、算力浪费（GPU 空闲时段无人知晓）。AI 训练平台本质上是将“算力、数据、代码、实验记录”四要素统一编排的操作系统，它向下管理异构硬件，向上提供标准化的训练接口。

下图展示了平台搭建完成后，一个训练任务从提交到结束所经过的核心链路，这也是全课程反复出现的总体架构：

从图中可以看到，平台的价值在于解耦：用户不再关心“哪台机器有空”，只需提交任务；调度器负责将任务匹配到最合适的资源；监控系统将 GPU 利用率、Loss 曲线等数据回流给用户，形成闭环。本课程将围绕这条链路，从零开始搭建一个可用的生产级平台。

二、方法流程：平台搭建的五个阶段与关键决策点

搭建 AI 训练平台不是一次性工程，而是分阶段演进的过程。根据大量企业实践，可以归纳为以下五个阶段，每个阶段都有必须做出的关键决策：

阶段	核心任务	关键决策点	常见工具选型
1. 基础设施	服务器、存储、网络就绪	GPU 型号与数量；存储用 NAS 还是对象存储	Docker / containerd
2. 集群编排	将多台机器组成资源池	K8s 原生还是轻量调度；是否启用 GPU 虚拟化	Kubernetes + kubevirt
3. 平台服务	提供用户可用的训练接口	任务调度策略；镜像构建流程	Volcano / KubeFlow
4. 开发体验	让算法工程师高效使用	是否提供 Notebook；实验追踪深度	JupyterHub / MLflow
5. 运维治理	监控、日志、权限、成本	多租户隔离粒度；配额与计费规则	Prometheus / Grafana

这五个阶段并非严格串行，实际落地时往往迭代推进。例如，在阶段 2 尚未完全自动化时，可以先通过脚本临时调度，让算法团队尽早开始训练，再逐步完善平台能力。但有两个决策点必须在初期就明确，否则后期返工成本极高：

GPU 资源池化方式：是采用 Kubernetes 原生调度，还是使用 Slurm 这类传统 HPC 调度器？前者更适合云原生微服务架构，后者在分布式训练通信上更成熟。
存储选型：训练数据是海量小文件（如图片）还是大文件（如视频）？这决定了选择对象存储（如 MinIO）还是分布式文件系统（如 JuiceFS）。

三、案例场景：一个 8 卡 GPU 服务器的起步配置

为了让大家有直观感受，我们看一个最典型的起步场景：某算法团队有 2 台 8×A100（80GB）GPU 服务器，需要搭建平台支撑 10 名工程师同时训练。以下是推荐的初始架构决策：

硬件清单：
- 2 台 GPU 服务器：8×A100 80GB + 512GB 内存 + 4×3.2TB NVMe
- 1 台存储服务器：24×16TB HDD + 2×3.2TB NVMe（用于元数据）
- 1 台管理服务器：32 核 CPU + 128GB 内存（跑 K8s master 和平台服务）

软件栈：
- 操作系统：Ubuntu 22.04 LTS
- 容器运行时：containerd 1.7+
- 集群编排：Kubernetes 1.28（kubeadm 部署）
- GPU 插件：NVIDIA Device Plugin + MIG（每卡切 2 个实例）
- 调度扩展：Volcano（支持队列优先级和公平调度）
- 存储方案：JuiceFS（元数据存 Redis，数据存 HDD 池）
- 训练镜像：PyTorch 2.1 + CUDA 12.2 + cuDNN 8.9

在这个配置下，10 名工程师每人可以申请 1 个 MIG 实例（约 40GB 显存）进行单卡调试；正式训练时，通过 Volcano 队列提交多卡任务，最多可同时运行 2 个 8 卡分布式训练任务。平台上线后，GPU 利用率从原来的 35% 提升到 78%，主要收益来自空闲资源的自动回收和排队机制。

实践建议：起步阶段不要追求大而全。先实现“提交脚本 → 自动分配 GPU → 返回日志”这条最小闭环，让团队用起来，再逐步增加实验追踪、超参搜索等功能。平台的价值是在使用中迭代出来的，而不是一次性设计出来的。

四、误区与复盘：平台搭建中的典型失败模式

在辅导过多个企业团队后，我总结了三个高频踩坑点，希望你在动手前就能避开：

误区一：过度依赖 K8s 原生调度。 默认调度器对 GPU 任务支持很弱，会出现“一个任务占满整卡、其他任务排队”的情况。必须引入 Volcano 或类似组件，才能实现 gang scheduling（gang 调度）和公平共享。曾经有团队用原生调度跑了三个月，GPU 利用率始终低于 50%，换用 Volcano 后一周就提升到 70% 以上。

误区二：忽略镜像管理。 训练镜像动辄 10GB+，如果每次训练都从 Docker Hub 拉取，光等待时间就占任务时长的 15%。正确做法是搭建私有镜像仓库（Harbor），并在每台 GPU 节点上配置镜像缓存预热。另一个常见问题是镜像 tag 混乱，建议强制使用 git commit hash 作为镜像 tag，保证可追溯。

误区三：没有日志持久化。 很多团队在容器内直接打印日志，容器销毁后日志就丢了。当训练中途失败，想排查原因时才发现无迹可寻。必须在平台层统一收集日志到 Elasticsearch 或 Loki，并关联任务 ID，方便事后回溯。

五、课程结构导航与学习路径

本课程共 30 章，按“基础 → 进阶 → 实战 → 治理”四个层次组织，你可以根据自己的基础选择跳跃阅读：

基础篇（第 1-8 章）：环境准备、Docker 镜像制作、K8s 集群部署、GPU 虚拟化。目标是让平台先“跑起来”。
进阶篇（第 9-16 章）：Volcano 调度策略、分布式训练（Horovod / DeepSpeed）、实验追踪、超参搜索。目标是让训练“快起来”。
实战篇（第 17-24 章）：从 LLM 微调到 CV 训练，完整走通两个真实项目，涵盖数据管道、断点续训、多机通信优化。
治理篇（第 25-30 章）：多租户权限、成本核算、监控告警、平台高可用。目标是让平台“稳下去”。

每一章都会包含可直接复用的配置文件和代码片段，建议你准备一台至少 4 卡 GPU 的服务器（或云主机）边学边练。如果只有单卡，也可以将多卡示例改为单卡运行，原理完全一致。

最后需要强调的是，平台搭建的最终衡量标准不是技术多炫酷，而是算法工程师是否愿意每天使用它。因此，本课程在每一章都会从“用户视角”出发，思考这个功能对实际训练体验的改善。当你完成第 30 章的学习后，你将拥有一个具备生产可用性、支持多团队协作、可观测可治理的完整 AI 训练平台。现在，让我们从第一台服务器的环境准备开始。