Scale-up、Scale-out 与 2026 AI 集群设计：先画数据流，再决定网络域

1. 问题定义：三个 scale 词不是营销同义词

Scale-up 扩大一个紧耦合加速器域：系统希望多张 GPU 像一张更大的逻辑 GPU 一样协作，重点是低延迟、高双向带宽、稳定的内存与同步语义。Scale-out 扩大由多个节点组成的集群：节点通过 NIC、交换机和路由网络协作，容量、故障隔离和可扩展性优先。很多真实服务还存在 scale-across，即跨机房或跨区域调度，请求、模型版本和缓存目录跨较慢链路流动。

三个域不对应固定的物理距离。一个 8-GPU 服务器通常是 scale-up；一个 72-GPU rack-scale 域也可以是 scale-up；一个双层 Clos 中的数百节点通常是 scale-out。交换机的存在本身说明不了边界，应按该域是否承载高频同步、对尾延迟极敏感的模型并行流量来判断。

2. 先列数据流：推理集群不是只有一个“网络负载”

若把这些流量都压进一张“平均利用率”图，结论会失真。TP 的一次 100 微秒停顿可能直接拉高 token 间隔；checkpoint 晚几十秒通常不会影响在线请求。网络层次、QoS 与调度器必须从这类差异出发。

3. 性能模型：带宽不是唯一预算，依赖链才是

一次通信的近似完成时间由启动、序列化、排队、协议和同步共同组成。对于 N 个参与者的 collective，应用看到的是最慢参与者的完成时间，而不是链路平均值。对于 P/D 分离，应用看到的是 prefill、KV 转移和首个 decode step 的串联路径。

α 使小消息对软硬件路径异常敏感；B_effective 受到 packetization、拓扑 hop、collective 算法和并发流量影响；T_queue 解释了为什么平均吞吐充足时 P99 仍然会坏。设计者必须测真实的消息大小分布、并发度与流量混合，而不能用单流带宽峰值替代。

4. Scale-up 域：扩大的是可用内存和同步预算

把多个加速器放在低延迟 fabric 中，首先解决的是单卡放不下模型、KV 或工作区的问题，其次才是峰值 FLOPS。TP、专家并行的一部分通信以及大模型的激活交换会频繁触发同步，因此如果它们跨越太多 NIC/交换机 hop，GPU 会在依赖点空等。

Scale-up 不等于任何形式的“共享内存”。软件仍需明确 tensor shard、owner、同步点和 buffer 生命周期。即便硬件互联很快，错误的 rank 映射、跨域 memory access 或不均衡的 MoE 路由仍能耗尽性能。可把 scale-up 看作一条更宽、更短、约束更多的通信高速路，而不是消除分布式编程的魔法。

5. Scale-out 域：扩大的是 replica、容量和故障隔离

Scale-out 网络连接节点、rack 和 pod，最适合将完整 replica 分布到多个故障域、将 EP 扩到更大集群，或连接 prefill、decode、缓存、存储和控制服务。它的优势是规模和可演进性；代价是路径更长、拥塞更复杂、设备和版本更多。

在线 serving 中，DP replica 通常可跨 rack 扩展，因为逐 token 没有跨 replica 同步。EP 则不同：token 每层都要经 all-to-all，跨节点时要同时检查 per-NIC 流量、专家热点、发送/接收不均衡和交换网络 bisection bandwidth。把“EP 可以 scale-out”误读为“EP 在任意网络上都等价”，会造成稳定的尾延迟问题。

6. 拓扑选择：不要从 GPU 数量倒推一张万能网络图

拓扑设计从通信域和几何结构两步展开。节点内可以使用强互联；节点间常见做法是 GPU-affinitized NIC、rail-optimized 连接、单平面或双平面 Clos。多平面只有在 communicator、路由和网卡绑定一致时才有效，否则流量仍会偏到少数端口。

选择是否无阻塞、是否双平面、是否收敛存储网，必须用预算表达：哪个工作负载允许超售、哪个流量不可被后台任务挤占、发生一条 uplink 故障后还能保留多少 goodput。只有写出这些不变量，拓扑图才是工程设计而不是设备清单。

7. 放置与调度：并行度是运行时控制变量

模型放置需要同时看三张图：模型图决定每层通信，硬件图决定实际链路，流量图决定同时发生什么。固定地把“8 张卡一个组”写进配置，只在静态 batch、固定模型和均匀专家负载下成立。在线负载变化时，scheduler 至少要理解 replica 的 KV locality、TP/EP group 边界、NIC 余量、模型版本和故障域。

对于 MoE，expert placement 必须随真实 token histogram 检查。对于 P/D，路由器不该只找“当前 GPU utilization 最低”的 decode worker，而应比较 KV 命中、待转 KV 字节、目标 NIC 队列和 decode SLO。对于训练与推理共用集群，网络、存储和功率都应进入借出与回收决策。

8. 数据面与控制面：一次请求跨域的状态机

数据面负责 tensor、token、KV、权重和存储块；控制面负责 membership、拓扑发现、communicator、容量、路由、版本和故障处理。两者不能混为一谈：控制面慢一点可以容忍，数据面一次误路由却会直接拉长 TBT。

请求状态：
ADMITTED → PLACED → PREFILLING → KV_READY
        → KV_TRANSFERRING → KV_COMMITTED → DECODING → FINISHED

每次跨域转移必须携带：
request_id, model_epoch, source, destination,
byte_count, block/version, deadline, completion_state

当节点被驱逐、模型热更新或 transfer 超时，router 必须使旧 epoch 的资源不可见，并以幂等方式重试或释放。没有版本与完成状态的“快速”控制面，最终会将网络偶发错误变成错误回答、重复计费或内存泄漏。

9. 2026 状态：开放 scale-up 从口号进入协议分工

2025–2026 的重要变化是，开放生态开始明确区分端点与网络职责。OCP ESUN 面向交换网络的 framing、无损传输、错误处理与多跳拥塞；OCP SUE-T 关注端点/XPU 侧 transport；UEC 公开规范面向 AI/HPC Ethernet 传输服务；UALink 则代表另一条开放 accelerator scale-up 互联路线。它们解决的层次不同，不能用“谁取代谁”概括。

OCP 在 2026 年发布的 ESUN 1.0 资料强调链路级可靠性、PFC/credit-based flow control、小消息开销与多跳拥塞。UEC 1.0.2 是 2026 年公开版本。它们说明未来规模化 AI fabric 会把可靠性、拥塞和端点语义作为设计对象，而不是仅把传统 Ethernet 端口速率提高。

10. 部署例子：128 卡 MoE 推理池如何分层

假设一个模型使用 TP8、EP16，服务端需要八个并发 replica。可以将每个 8-GPU 节点视为 TP 原子域；两个节点组成一个 EP16 域，并给其 NIC/leaf 预留可计算的 all-to-all 容量；八个 EP 域在更高层通过 DP 扩容。prefill 池和 decode 池可以独立扩缩，但 KV 转移必须是版本化、可限速的 P2P 数据流。

若一个 rack 内发生单条 uplink 故障，设计目标不应是“完全没有退化”，而是让通信库识别降级路径，router 停止向受影响域继续灌入新请求，后台预取让路给 decode，并用 P99、drop、retry、GPU idle 共同验证影响。这样的例子把硬件拓扑、服务路由和运维机制连接在一起。

11. 观测指标：要能把 token 慢归因到一个域

• 应用：TTFT、TBT、request completion、KV transfer deadline miss、路由重试。
• GPU/运行时：collective duration、stream wait、SM occupancy、每 rank token histogram。
• NIC：TX/RX、queue depth、RDMA retry、ECN/CNP、PFC pause、completion latency。
• 交换网络：per-port utilization、buffer watermark、drop/mark、ECMP/rail imbalance。
• 控制面：topology epoch、communicator membership、模型版本、容量与故障域选择。

所有层应共享 request、group 或 transfer trace id。否则 GPU trace、NIC counter 和 switch telemetry 各自都“正常”，但无法解释一次用户可见的尾延迟尖峰。

12. 不变量与失败模式：集群变大后最容易漏掉的部分

常见误判包括：将“总 GPU 利用率高”当作网络健康、将单节点 microbenchmark 当作跨 rack 结论、把 background copy 和 decode traffic 放进同一无优先级队列、以及把一次模型热更新当成纯控制操作而没有处理旧 KV 的生命周期。

13. 落地顺序：从一张拓扑图到可运行的服务

1. 导出实际 GPU、PCIe、NIC、交换机、rack 和故障域图，并自动校验。
2. 为 TP、EP、PP、KV transfer、checkpoint 分别采样消息大小与并发分布。
3. 为每类流量写延迟、带宽、drop 和恢复目标，而不是一个泛化“网络利用率”。
4. 用 trace 驱动的模拟或压测比较 placement、rail 和拥塞策略。
5. 先部署小域并做链路/NIC/rank 故障注入，再扩到多 rack。
6. 把模型、runtime、网络和存储配置绑定到同一可回滚版本。

14. 与 Mainline 和相关文章索引的连接

本页是通信域与集群设计的总图。下游的具体算子、并行、网络和缓存实现，应按以下链接继续读；反向导航由主线索引和相关公众号内容目录统一承载。

15. 来源与版本边界