Day 26 · 工业工程底座
超大规模基础设施：2.8 万亿参数背后的系统工程奇迹
2.8 万亿（2.8T）参数的模型，按 FP16 计算仅权重本身就重达 5.6 TB！单张 GPU 显存只有 80 GB，怎么把它切开放进超大规模 GPU 集群里？专家之间跨卡通信（All-to-All）怎么做到不卡顿？今天看懂大模型背后的硬核系统工程——专家并行（EP）、通信重叠与内存管理。
学完你能回答
2.8T 模型是怎么被切分到大规模 GPU 集群上的？
学完你能回答
什么是专家并行（EP）与 All-to-All 跨卡通信？
学完你能回答
「通信与计算重叠（Overlap）」是怎么榨干 GPU 性能的？
1起点：这些你早就会了
分布式集群系统工程，就像超大型跨国工厂的流水线分工调度：
| 你已经会的 | AI 世界里对应的东西 |
|---|
| 多条生产线同时开工：每条线造不同订单，最后合并财报 | 数据并行（Data Parallelism, DP）：多卡跑不同批次，同步梯度 |
| 切分大图纸：图纸太大一张桌子放不下，裁成 8 份分别加工 | 张量并行（Tensor Parallelism, TP）：单个矩阵切到同机多卡内 |
| 流水线接力：工段 A 造车架，工段 B 装发动机，工段 C 喷漆 | 流水线并行（Pipeline Parallelism, PP）：按模型深度层数跨机串联 |
| 专科大夫坐诊不同大楼：救护车高速跨楼转运病人 | 专家并行（Expert Parallelism, EP）：896 个专家分派到不同 GPU，All-to-All 分发 token |
| 边装货边开车：司机在路上跑的同时，后舱机器人自动打包下一批货 | 计算与通信重叠（Overlap）：GPU 算矩阵乘法时，异步网卡进行跨机通信 |
2专家并行（Expert Parallelism, EP）与 All-to-All 挑战
在 2.8T MoE 模型中，最关键的并行范式是专家并行（EP）：
专家并行的真实运作
• 假设有 64 张 GPU 卡，896 个专家被均匀分配在这些卡上（每张卡托管 14 个专家）（示意）；
• 当 GPU 0 处理一段文本时，Router 发现其中某个 token 需要去找 GPU 63 上的专家 800，另一个 token 要去找 GPU 12 上的专家 150；
All-to-All 全交换通信大风暴：
所有 64 张 GPU 卡必须在几毫秒之内，
同时把手头的 token 跨网卡高速打包寄给目标 GPU，并接收来自其他 63 张卡寄来的 token！
如果网络带宽不够或发生拥堵，所有 GPU 核心就会彻底锁死等待（Straggler）！
严格来说，token 并不是一个个单独「寄包裹」，而是按固定形状的数据块在高速互联上批量搬运的；而且每张卡实际收到多少 token，取决于 Router 的实时决策，并不像上面平均分的那样整齐——这正是第 4 节 MoonEP 要解决的问题。
图 26.1：专家并行（EP）的通信图谱。通过高速网络协同，让万亿参数巨兽如同运行在一张单机巨卡之上。（图中卡数与专家编号为示意）
3绝技：计算与通信重叠（Overlap）
如果“先等通信全部传完，再开始算矩阵”，GPU 会长时间空等，整个集群的利用率被严重拖垮。《Kimi K3 技术报告》§5.2 的做法是：专家分发与合并的 All-to-All 通信与计算重叠执行（Overlap），以隐藏通信延迟：
双流水线异步重叠（Computation-Communication Overlap）
• 当 GPU 正在算当前层的前向矩阵乘法（GEMM）时；
• 网卡（NIC）在后台异步发起下一层专家的 All-to-All 跨卡传输；
• 结果：通信耗时被“隐藏”在矩阵计算的耗时阴影里，GPU 计算核心的空等被大幅压缩！
4MoonEP：动态冗余专家实现完美均衡
通信再快，如果各张卡分到的活不一样多，集群还是被最慢的卡拖住。传统 EP 里，每张卡（rank）收到多少 token 完全看 Router 脸色：热门专家所在的卡被挤爆，其他卡早早算完干等；而且每个专家每步收到的 token 数一直在变，还会造成显存碎片。《Kimi K3 技术报告》§5.2.1 的解法是 MoonEP——一种借助动态冗余专家实现完美负载均衡的 EP 方案。
类比：外卖高峰的「分身档口」
外卖午高峰，某家爆单餐厅出餐慢，会拖住整个商圈的骑手调度。调度平台的办法是：根据实时订单分布，在附近空闲的共享厨房里临时开几家「分身档口」复制热门菜品，把订单匀过去——让每个骑手这一趟跑的单量完全一样，谁也不等谁。
严格来说，「分身」不是复制整个餐厅：只是把热门专家的计算副本临时放到负载轻的卡上，算完之后，反向传播时这些副本的梯度还要先暂存本地、再归约回原来的卡；而且整个规划由 GPU 规划内核实时完成（报告用整数线性规划离线求精确解做参照，线上内核接近最优、开销可忽略），不是人工调度。
MoonEP 的目标是让每张卡恰好收到同样多的 token（S × K 个，S 为序列长度，K 为每个 token 选择的专家数），所有卡执行完全相同的计算量。关键问题是：要准备多少冗余专家才够？报告证明了一个漂亮的结论——每 rank 至多 E/R 个冗余专家（E 为专家总数，R 为 EP 并行的卡数）就足以保证均衡方案总是存在，且这个上界基本是紧的。于是只要为每张卡预留 E/R 个冗余专家槽位，规划就始终有可行解，训练永不中断。
完美均衡还带来一串附带好处：每张卡收到的 token 数固定，通信缓冲区只需固定大小，token 可以被直接发送到目标位置、消除中间拷贝（零拷贝通信）；所有层的计算形状都静态已知，消除了逐层的主机同步，流水线不再停顿。
注意：MoonEP 与 QB 是两条独立防线
Day 20 讲的 QB（Quantile Balancing，分位数平衡）是在模型路由层面调节负载，让 token 天然分得比较匀；MoonEP 则是在系统执行层面兜底——无论路由怎么倾斜，都能用冗余专家把每张卡的计算量拉平。两者思路不同、互不依赖，是负载均衡上的两条独立防线。
5面试视角
面试视角 · 高频考点
面试官可能会问：「训练和部署一个 2.8T 参数的超大规模 MoE 模型，基础设施面临的最大挑战是什么？如何通过并行策略与通信重叠解决？」
八股答「最大挑战是显存放不下和专家通信慢。用 3D 并行加上专家并行（EP），用 All-to-All 分发 token，通过计算通信重叠（Overlap）隐藏通信时间。」——回答准确，若能补充细粒度算子重叠与完美均衡调度则更显专业实力。
本课答「核心是显存拓扑分布与跨节点通信带宽瓶颈的协同破局：① 挑战本质：2.8T MoE 权重（~5.6TB）必须切分到集群上，但 MoE 的动态路由天然引入了高频的全跨卡 All-to-All 通信，一旦出现专家负载失衡或网络拥塞，整个分布式集群会出现严重的木桶短板（Straggler）；② 并行策略组合：采用 DP + PP + TP + EP 的混合并行，在节点内使用高带宽互联运行 TP，节点间跨网络运行 EP 和 PP；③ 通信与计算重叠（Overlap）：在 GPU 执行当前层计算的同时，异步发起专家分发与合并的 All-to-All 通信，把跨节点通信延迟隐藏在计算耗时之内；④ 完美均衡调度：用 MoonEP 的动态冗余专家把每张卡收到的 token 数拉平，消除木桶短板。」
6映射到原文：K3 报告 §5 基础设施
今天的内容对应报告第 5 章。摘要里的这句话，现在每个词你都能看懂了：
K3 原文（§5 基础设施 · 摘要）
「在 2.8T 规模下，Kimi K3 由多个领域的基础设施进展所支撑：面向 KDA 的算法-系统协同设计、兼具高效内存管理的完美均衡专家并行训练、具备持久 rollout 与沙箱状态的百万 token 智能体强化学习，以及部署层面的创新。」
逐词翻译：
- 「面向 KDA 的算法-系统协同设计」：KDA（Day 19 讲）的线性注意力结构在 GPU 上并不好跑，团队为它专门设计内核与并行方案（§5.1），让算法和硬件互相迁就，而不是各干各的。
- 「完美均衡专家并行训练」：就是今天第 4 节的 MoonEP（§5.2.1）——用动态冗余专家让每张卡收到一样多的 token，谁也不等谁；「高效内存管理」则指激活的重计算、量化与卸载等省显存手段（§5.2.2）。
- 「持久 rollout 与沙箱状态」：智能体 RL 里一条任务横跨数百步工具调用（§5.3），沙箱能被暂停、做检查点并原样恢复，中途打断也能接着跑。
5.6 TB
2.8T 参数按 FP16（2 字节）存放的权重体积（估算）
51,219,741
K3 训练与评测共创建的沙箱数（§5.3.2）
6.5×
AgentENV 沙箱最高内存超配比（§5.3.2）
All-to-All
专家并行中跨卡分发的核心通信原语
7自测题（先自己答，再点开看解析）
Q1 什么是数据并行（DP）和张量并行（TP）的区别？
解析：数据并行（DP）每张卡保存完整的模型副本，分发不同的输入批次；张量并行（TP）将单个算子矩阵（如 W_q 矩阵）切分到同一台机器内的多张 GPU 卡上协同计算。
Q2 专家并行（EP）为什么需要 All-to-All 通信？
解析：因为不同 GPU 托管不同的专家。Router 决定了当前卡的 token 该由哪张卡的专家处理，所有卡必须同时跨网将 token 发送给目标专家卡，并将计算结果接收回来。
Q3 什么是「计算与通信重叠（Overlap）」？它的收益是什么？
解析：在 GPU 核心执行当前层矩阵乘法计算的同时，异步网卡利用独立的通信流在后台传输下一层所需的数据。收益是把通信等待时间隐藏在计算之下，大幅减少 GPU 空等，提升集群算力利用率。
Q4 为什么 MoE 负载均衡对基础设施性能至关重要？
解析：如果负载不均衡，某些热门专家所在的卡会被海量 token 挤爆，而其他卡早早算完干等，导致整个分布式集群的步调被最慢的那张卡强行拖慢（木桶短板效应）。K3 在系统侧的解法正是第 4 节的 MoonEP：用动态冗余专家把每张卡收到的 token 数拉平。
Q5 K3 基础设施在长周期智能体任务中提供了什么支持？
解析：提供了支持百万 token 上下文的持久化沙箱执行环境与高效的 Rollout 状态管理，让模型能进行长达数百步的代码执行、调试与自我纠错。
明天 · Day 27
评测与成绩单：Kimi K3 到底有多强？
GPQA、HLE、BrowseComp 到底在考什么？为什么 K3 能超越绝大多数专有模型，开源完整权重？
进入 Day 27 →