分布式训练

Kinger2026/7/23大约 5 分钟

历经了最底层的 GPU 架构（第一层）、RDMA 无损网络（第二层）、以及 Weka 高性能存储（第三层）的硬核洗礼后，咱们现在终于站在了 AI 算力基础设施的“紫禁之巅”——分布式训练 (Distributed Training)。

如果你把之前的知识串联起来：模型算法（Transformer）是图纸，GPU（SM/Tensor Core）是机床，存储（Weka）是输送带，网络（RoCEv2/PFC）是车间之间的通道。
那么，分布式训练，就是整个“超级工厂”的最高调度中枢。

当你面对一个像 Qwen 这样拥有千亿参数的大模型时，传统的单机训练会直接撞上两堵叹息之墙：

显存墙 (Memory Wall)： 一个 175B（1750 亿参数）的模型，光是把参数加载进显存（FP16精度）就需要约 350GB。而目前最顶级的单张 H200 显存也才 141GB。单卡连模型都塞不下，更别提还要存放优化器状态和激活值了（实际训练显存需求是参数量的 4-6 倍）。
算力墙 (Compute Wall)： 哪怕你有一张显存无限大的卡，靠单张卡去硬算海量数据的矩阵乘法，可能需要算上几百年。

为了打破这两堵墙，我们需要把模型和数据“切碎”，扔给几百上千张 GPU 一起算。这就是大名鼎鼎的 3D 并行策略 (3D Parallelism)。

为了让你用系统架构师的直觉瞬间看透这三种切分方式，我为你搭建了这个“千亿大模型 3D 分布式并行切片沙盒”。你可以亲自切换策略，看看模型和数据是如何在多张显卡之间流转的，以及为什么它极其依赖咱们之前聊过的底层网络：

在真实的智算中心里，算法团队（比如你们搞智能日志预警平台时如果需要微调开源百亿模型）绝对不会只用一种策略，而是把这三种策略缝合起来使用。

这就是我们在大厂经常听到的黑话：“TP8 + PP8 + DP16”。

这背后其实是一套极其严密的基于网络物理拓扑的排兵布阵：

切分逻辑： 把 Transformer 里面的每一个大矩阵乘法（比如咱们聊过的 Dense GEMM）硬生生切开。几张卡同时算一个矩阵的不同部分。
网络制约： 这种切分要求显卡之间每算一步就要交换一次结果，通信极其频繁。如果你跨机器走网线去同步，延迟会把 GPU 彻底饿死。
物理映射： 所以，TP 的规模永远不能超过单台物理机的显卡数量（通常 TP 最大 = 8）。它必须跑在机器内部极速的 PCIe 总线或 NVLink 上。

切分逻辑： 模型能塞下后，为了加快训练速度，把海量数据（比如几百亿 Token 的语料）切给不同的卡算，最后汇总大家学到的知识（梯度同步/AllReduce）。
物理映射： 同样依赖底层的 RDMA 网络进行高频的梯度广播。

现在你拥有了全局视角，再回头看你之前搭建监控平台时的那些指标，一切就豁然开朗了：

如果你看到 DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTAL (NVLink 带宽) 几乎没动静，说明算法团队配置错了，没有开启张量并行 (TP)。
如果你看到 nvidia-smi GPU 利用率很高，但 SM_ACTIVE 一会儿高一会儿低（呈现锯齿状），这往往是因为流水线并行 (PP) 产生了巨大的气泡 (Bubbles)，GPU 在疯狂等待上一台机器发数据。
如果你看到交换机疯狂报 PFC 暂停帧 甚至丢包，那往往是因为数据并行 (DP) 正在做全局梯度同步 (AllReduce)，瞬间爆发的流量引发了微突发拥塞，直接把 RoCEv2 网络打爆了。

从最初在 Linux 终端敲错 touch 命令去建目录，到后来折腾 Python 环境、Kubeflow，再到如今俯瞰整个智算中心的 GPU 算力、无损网络、并行存储与 3D 并布式调度。你现在的知识体系已经完全闭环，具备了一个高级 AI Infra 架构师的底色。

针对你们那个“分布式智能日志分析预警平台”，目前大模型的训练或者微调推理跑在什么样的算力环境上？你们是有自己物理机房的集群，还是在公有云（比如腾讯云/火山引擎）上使用现成的容器服务呢？