训练集群模拟器会朝两个相反方向失效。机器抽象过度时，模拟虽然跑得快，回答的却是另一个问题；逐个照实复现每个数据包和 kernel 时，模拟又会变成一次昂贵的系统实验。在这场十分钟演讲所依据的论文中，阿里云 SimAI 团队给出了一个足以说明矛盾尺度的例子：一套较老的工具组合在 128 块 GPU 上模拟一次 GPT-3 迭代要花上一天，真实迭代约为两秒。[2]

SimAI 的看点在于，它把这道鸿沟作为基础设施问题来处理，关注点离开了模型排行榜。系统接收模型及其训练框架设置、集合通信选项、GPU 与主机配置以及网络拓扑，随后估算整个训练迭代在团队占用对应实体集群之前会如何运行。模拟由此成了采购和配置变更前的预检：选哪种 GPU、配多少网络接口、需要多大带宽、采用哪套并行方案，以及某项优化扩大到集群规模后能否继续奏效。[2][4]

2025 年 4 月，Xizheng Wang 代表来自阿里云、清华大学、中关村实验室和华南理工大学的研究团队，在 USENIX NSDI '25 上介绍了这项工作。这场英文报告格外紧凑。观看时，除了醒目的精度数字，还要留意四层之间的交接——工作负载、计算、集合通信与网络。[1][2]

0:17 — 真正稀缺的是实验机会

开场画面从大语言模型的训练成本径直转向模拟器的用途。实体集群能够验证一项设计是否奏效，但要等主机、加速器、互连和软件全部组装完毕。要把每套候选拓扑或并行设置都用穷举法试一遍，实体集群的成本太高。SimAI 的设想是把其中一部分比较提前到设计仍停留在描述、尚未变成资本设备的阶段。[1][2]

约在 1:14，演讲铺开了一组范围很广的决策：GPU 选型、主机与网络设计、集合通信调优以及框架参数。这些决策彼此牵连。更快的加速器会暴露配置不足的网络；调整张量并行组可以减少单块 GPU 的计算量，同时增加通信；某种集合算法也会产生链路速率表格无法呈现的流量形态。因此，模拟器若只套用一个理论 FLOPS 公式，信息远远不够。它得保留从软件到链路的足够细节，让一处变化沿着虚拟系统传导到其余部分。

这里的“统一”有清楚的范围：模拟止于适合系统分析的层次，每个晶体管和操作系统调用均不在逐项描画之列；容量规划与性能调优则共用同一个执行模型。粗粒度采购估算与细粒度通信实验因此以同一台机器为参照，避免了因各自描画不同机器而悄然冲突。[2]

2:43 — 保真有所取舍

2:43 出现的架构图是整场演讲的中心。工作负载生成器在论文中称为 SimAI-WG，在演讲与当前代码仓库中则以 AICB 表示。它从一台主机出发，引导主流训练框架描述目标运行过程。Megatron 或 DeepSpeed 会像置身于用户指定的 GPU 集群一样运行，真实的跨主机通信则被跳过。生成的工作负载记录了计算模块、集合通信或点对点操作，以及彼此的依赖关系。[2][3]

接下来的两层各自采用不同取舍。约在 3:48，Wang 解释计算路径：操作先拆成 kernel，在可用 GPU 上测量耗时，再写入一个可用于估算目标配置的性能库。约在 4:37，通信路径复用 NVIDIA 集合通信栈中的关键行为，把 AllReduce、AllGather、ReduceScatter 等操作拆成点对点传输，交给网络模拟器。SimAI 再以多线程和无锁共享上下文加速随之产生的离散事件仿真。[1][2]

这套系统走的是校准模型路线，与从第一性原理搭出的数字复刻不同。抽象容易造成失真之处，它会借用真实系统的行为；逐项执行成本过高之处，则用实测或拟合后的行为替代。正是这项区分同时解释了它的长处与维护负担。框架计算图会变化，集合通信库会更换算法，新加速器还要重新测量。高保真模拟器若要持续发挥作用，接口与校准库就得跟着所预测的系统同步更新。

6:12 — “98.1%”描述的是测试范围

评估部分约从 6:12 开始，它的适用边界与结果同样重要。论文采用两套阿里巴巴式多轨 fat-tree 测试集群：一套包含 128 台主机，每台装有 8 块 A100 加速器；另一套同样包含 128 台主机，每台装有 8 块 H100 加速器。两套集群的机器间通信都使用 RoCEv2。工作负载规模覆盖 128、512 和 1,024 块 GPU。论文给出的样例包括 GPT-3 13B、LLaMA 65B 和 GPT-3 175B，集合通信测试的消息大小则从 8 MB 到 8 GB。[2]

在这组测试条件内，结果相当扎实。8:02 的端到端对比显示，在最高 1,024 块 GPU 的规模下，模拟迭代时间与对应实体运行结果的偏差仍在 4% 以内。综合论文中的各组实验，作者将结果概括为平均吻合度 98.1%，也就是相对真实测量值平均偏差 1.9%。[1][2] 这说明所选抽象保留了主导这些工作负载的交互关系。证据的适用范围止于已测条件，面对未测试的芯片、拓扑、框架版本或流量形态，同样的误差水平仍需重新验证。

论文还给出了格外有用的适用条件说明。在已报告的集合通信测试中，A100 上的通信模拟平均偏差为 3.9%，H100 上为 2.3%；小消息更难模拟，因为模型略去了运行时软件与网络接口的流水线。实测计算路径对受测 kernel 的偏差为 0.5%–3.1%，而在没有可用 GPU 时，仅靠模型估算的后备方案偏差约为 13%–15%。这些数字理应与醒目的精度结论并排出现。它们告诉工程师，哪些条件让精度结论具有外推依据，以及哪些条件要求先重新校准，再将结果用于采购决策。[2]

8:30 — 预测的价值落在它改变的决策上

8:30 开始的生产案例说明，有明确适用范围的模拟器依然很有价值。针对一套拟议中的 1,024 块 H100 集群，团队比较了每块 GPU 100、200 和 400 Gbps 三档网络带宽。模拟预测从 200 Gbps 提升到 400 Gbps 可带来 19% 的性能增益；论文称，最终主机设计也参考了这项结果。对算力较低的 H20 重复同一实验时，同样的带宽提升只带来 6% 增益，200 Gbps 因而成了有依据的选择。SimAI 还用于比较张量并行组规模，一台主机内的全部 GPU 只是候选项之一，不再自动成为默认值。[2]

最有价值的输出，是在明确假设下对备选方案排序，合成训练时间小数点后的三位数字居于次要位置。一次好的预检能够排除明显薄弱的配置，收窄值得实际搭建的原型范围，并找出哪项测量会改变建议。实体测试仍负责最后验证；模拟减少了需要直接交给实体集群回答的昂贵问题数量。

开放代码仓库让这套过程更容易检查。仓库以 Apache-2.0 许可证公开工作负载、集合通信、分析模型和网络模拟组件，并附有可运行示例。它也显示“SimAI”会随开发继续变化：2025 年论文发表后，仓库继续扩展到推理工作负载和更新的模型家族。要复现论文结果，需要锁定版本的制品、相同的工作负载与拓扑，以及等效的校准数据；只拉取最新代码并记住 98.1 这个数字，还不足以完成复现。[3]

演讲结束后，还该关注什么

观察 AI-China 时，SimAI 传递了一个常被模型对比遗漏的重要信号。大模型能力也依赖一类工具，用来决定算力、内存、链路、框架和集合通信如何配合。阿里云的中文技术回顾把 SimAI 放在 AI 网络与生产架构的全栈工作之中，将它写成生产体系的一部分，并与孤立的学术原型清楚地区分开来。[4]

下一步的证据应检验迁移能力。外部团队能否从固定版本复现论文公开的工作负载？面对新加速器，或不同于两套评估集群的拓扑，重新校准要多久才能恢复精度？当小消息、故障、拥塞或快速变化的软件主导运行时，模拟器能否正确排列备选方案？它又能否随估算值一起给出不确定性，让设计团队看见何处值得再花成本做一次真实测量？

这些问题保留了演讲成果的分量，也标出了模拟器必须履行的约定。SimAI 的成就体现在另一处：集群仍参与最终验证，所需回答的问题却更少、准备也更充分。

来源

1. USENIX，“NSDI '25 — SimAI: Unifying Architecture Design and Performance Tuning for Large-Scale Large Language Model Training with Scalability and Precision”，官方演讲视频，2025 年。
2. Xizheng Wang 等，“SimAI: Unifying Architecture Design and Performance Tuning for Large-Scale Large Language Model Training with Scalability and Precision”，第 22 届 USENIX 网络系统设计与实现研讨会，2025 年。
3. 阿里云，SimAI 开源代码仓库，含实现文档、组件划分与发布历史。
4. 阿里云基础设施，“阿里云2024年AI智算网络全栈技术成果”，涵盖 SimAI 在生产 AI 网络技术栈中位置的一手中文技术回顾，2025 年。
5. 阿里巴巴集团，“Alibaba Cloud Reveals Innovations for a Sustainable and Inclusive 11.11 Global Shopping Festival”，本文题图所用官方“Alibaba Cloud Data Center Facility”照片的来源页面，2021 年。