SimAI Architecture

导言

SimAI 不是把上千张 GPU 在软件里逐晶体管复刻一遍，也不是实际训练一个没有数据的模型。它把训练框架、算子耗时、集合通信和网络拆成不同精度的模型，再用事件依赖重建一次迭代的时间线。本文基于 NSDI 2025 论文与固定版本源码，回答五个问题：它是什么、架构如何组织、是不是仿真、精度证据有多强，以及公开版是否支持 Ascend。

先给边界

本文核验的 SimAI 主仓库版本为 f5efb5a。结论是：公开版没有端到端 Ascend/CANN/HCCL 支持，也没有 Ascend 精度数据。论文报告的高精度来自 NVIDIA A100/H100 训练实验；不能因为代码里出现通用单词 NPU，就把结果外推到昇腾。

先给结论

SimAI 是阿里云开源的大规模 AI 集群性能仿真器。它关注的不是模型输出是否正确，而是：给定模型、并行策略、集合通信算法和网络拓扑，一次迭代大约要多久，时间花在计算还是通信，换卡、换网或换并行配置后会怎样。

它确实是仿真，但属于混合建模：

• 训练结构由 AICB 模拟框架调用并生成工作负载，不搬真实激活值，也不计算 loss。
• 计算时间主要来自真机 profiling、算子时间库或同架构外推，不做 GPU 指令级/周期级模拟。
• 集合通信由 NCCL-like 模型拆成点到点流量。
• 网络时间可以用快速的带宽解析模型，也可以交给 ns-3 做包与队列级离散事件仿真。
• 整体时间由事件依赖的关键路径得出，而不是把几个峰值带宽公式简单相加。

问题	核验结论
是仿真吗	是，准确说是“画像/外推 + 行为模拟 + 离散事件”的混合性能仿真
会真正训练模型吗	不会；目标是时间、流量和利用率，不是张量数值、loss 或收敛
解析模式是什么	用有效总线带宽和固定延迟近似通信，快，但看不到交换机排队等细节
Simulation 模式是什么	把通信流交给 ns-3，模拟包、链路与网络事件，更慢但更细
论文精度如何	选定 A100/H100、模型和规模内，端到端偏差小于 3.9%，平均对齐度 98.1%
支持 Ascend 吗	固定版本公开树没有 torch_npu、CANN、HCCL 或 Ascend 设备模型

原创认知插图：真机秒表只负责提供少量标定，工作负载卡片和事件齿轮在普通机器上重建“何时完成”；模拟器估算的是时间，不是在训练模型。

项目与论文

SimAI 仓库把系统拆成多个可替换组件。论文中的名字和当前目录并不完全一致，理解时可以用下面的映射：

论文概念	当前公开实现	责任
SimAI-WG	AICB	生成训练工作负载，记录计算和通信操作
SimAI-CP	AIOB/算子时间与工作负载字段	测量或估算计算核耗时
SimAI-CM	SimCCL/MockNccl	把集合通信算法和拓扑展开成 P2P 流
Execution Engine	astra-sim-alibabacloud	解析工作负载，调度计算、通信和完成事件
Packet Network	ns-3-alibabacloud	对链路、包、队列和网络完成进行离散事件模拟
Inference Simulator	vidur-alibabacloud	论文后新增的多请求推理调度与执行时间模型

论文全名是 SimAI: Unifying Architecture Design and Performance Tuning for Large-Scale Large Language Model Training with Scalability and Precision，发表于 USENIX NSDI 2025。它的中心问题是：传统解析模型太粗，包级仿真又太慢；如何在上千 GPU 规模保持可扩展性，同时保留集合通信和网络拓扑对性能的影响。

论文的主要内容可归纳为四点：

1. 工作负载生成。 截获或模拟 Megatron-LM 等框架的训练结构，把计算时间、通信类型、通信域和字节数写成可回放记录。
2. 计算预测。 优先使用真机核函数画像；缺硬件时再基于计算能力与内存带宽做外推。
3. 通信预测。 不把 AllReduce 当成一个不可分的公式，而是结合 NCCL 算法、协议和拓扑拆成 P2P 流，再模拟网络完成。
4. 可扩展执行。 用无锁多线程事件执行加速大规模仿真；论文报告相对单线程最高 23 倍加速，并比带锁多线程方案再快 15%。

仓库后来继续演进：1.5 加入多请求推理、DeepSeek/Qwen MoE 和 Vidur 调度，1.6 又增加推理显存预算、decode 线性插值与 PD 分离内存预算。这些是论文之后的工程能力，不能直接继承论文的训练精度数字。

架构与对象

论文 Figure 1 给出系统总图：输入模型、框架、xCCL 参数和拓扑后，工作负载生成器构造操作序列；执行引擎一边查询计算模型，一边调用通信与网络模型，最终输出端到端指标。

论文 Figure 1（逻辑证据）：证明作者定义了工作负载、计算、通信、网络和执行引擎之间的模块边界；这张图本身不证明预测精度，也不证明公开版支持 Ascend。

对初学者来说，最容易混淆的是“配置、张量、操作、事件和网络包”。SimAI 真正沿主路径传递的是元数据与时间事件，而不是训练张量的数值：

对象	物理表示	生产者 → 消费者	结束条件
模型与并行配置	参数和拓扑文本	用户 → AICB	工作负载生成完成
层记录	计算时间、通信类型、通信组、字节数	AICB → 执行引擎	对应层事件完成
集合通信请求	类型、rank 组、负载大小	Layer → SimCCL	所有组成流完成
P2P 流	源、目的、字节数、通道/协议元数据	SimCCL → 网络后端	发送与接收完成回调触发
计算/网络事件	时间戳、回调、依赖关系	调度器 → 事件队列	事件出队并执行
结果指标	迭代时间、通信时间、计数器	执行引擎 → 分析者	仿真结束后持久化

原创五视图技术图：用物理、因果、流程、时序/生命周期和数据对象五种视角解释 Analytical 与 ns-3 两条共同主链；右下角单独标出 Ascend 所缺的计算画像和 HCCL 行为层。

不是周期级 GPU 模拟

SimAI 不模拟 SM 中每条指令、cache line 和流水线周期。它把一个计算操作折叠成“经过多少时间后完成”的事件。这样牺牲微架构解释力，换来 1024 GPU 乃至更大规模的仿真速度。

建模方式

工作负载不是训练数据

AICB 的 SimAI workload generator会写入并行配置和逐操作记录。它“跑”的是模型结构和通信语义，不是训练数据。可以把它理解成剧院彩排：演员走位、灯光切换和换景时刻都保留，但不用真的演完整剧情。

下面是与源码对象对应的语义伪代码，不是项目公开 API：

def build_workload(model, parallel, compute_profile):
    records = []
    header = {
        "tensor_parallel": parallel.tp,
        "pipeline_parallel": parallel.pp,
        "expert_parallel": parallel.ep,
        "world_size": parallel.world_size,
    }

    for layer in model.layers:
        compute_key = (
            layer.kind,
            layer.input_shape,
            layer.dtype,
            parallel.tp,
            parallel.ep,
        )
        compute_time = compute_profile.lookup(compute_key)
        records.append({
            "kind": "compute",
            "layer": layer.name,
            "duration_ns": compute_time,
        })

        for collective in layer.collectives(parallel):
            records.append({
                "kind": "communication",
                "layer": layer.name,
                "collective": collective.kind,
                "group": collective.ranks,
                "bytes": collective.payload_bytes,
            })

    write_header(header)
    for record in records:
        write_record(record)
    return len(records)

工作负载文本可以在 CPU 上生成；但 AICB 当前物理回放路径的 初始化和 workload applier明确使用 CUDA/NCCL。这也是 Ascend 不能“改一个设备名就能跑”的第一处证据。

计算时间来自画像

对计算操作，最可靠的输入是在目标机器上测得的核函数或算子组合时间。论文的 SimAI-CP 还讨论了缺少目标 GPU 时的跨硬件外推：在计算受限区参考 FLOPS，在内存受限区参考带宽，再乘已知硬件的时间。

设：

• T_known 是已知硬件上测得的操作时间。
• P_known、P_new 是已知/目标硬件的有效计算吞吐。
• B_known、B_new 是已知/目标硬件的有效内存带宽。
• T_new 是目标硬件预测时间。

从物理量直觉出发，若工作量不变，计算受限时间应随有效吞吐的倒数变化：

\[ T_{new} \approx T_{known}\frac{P_{known}}{P_{new}} \]

内存受限时同理：

\[ T_{new} \approx T_{known}\frac{B_{known}}{B_{new}} \]

论文公式的印刷/定义歧义

论文正文展示的比例方向与上述量纲直觉相反；当前公开树中也没有找到可核对的 CP-Model 公式实现。因此本文不把印刷式直接当成可执行规范。论文实验本身也显示：直接测量的 SimAI-CP 总计算偏差为 0.5%-3.1%，而外推 CP-Model 约为 13%-15%。跨厂商 Ascend 建模更不应从 A100 峰值参数直接缩放。

通信是两级模型

集合通信首先经过 SimCCL/MockNccl。它根据算法和拓扑把一次 AllReduce、AllGather、AllToAll 等请求拆成多个 P2P 流。随后有两条执行路径：

• Analytical。 使用经标定的有效总线带宽与延迟，快速估计完成时间。概念上可以写成 T_comm = L_fixed + S / B_bus，其中 S 是字节数，B_bus 是有效带宽而非产品峰值，L_fixed 是启动/短消息项。源码中的 Analytical path还包含短消息经验分支，因此它是校准模型，不是纯理论公式。
• Simulation。 将流交给 ns-3 frontend，由离散事件网络模型处理发送、接收、链路和回调。它能观察拥塞和拓扑影响，但运行更慢，也更依赖正确的交换机、队列和链路参数。

完整事件循环可以抽象为：

def run_simulation(workload, topology, mode, compute_model, collective_model):
    queue = EventQueue()
    state = SimulationState(workload)
    queue.push(time=0, event=state.first_ready_operation())

    while not queue.empty():
        now, operation = queue.pop()

        if operation.kind == "compute":
            duration = compute_model.duration(operation)
            queue.push(
                time=now + duration,
                event=state.completion_of(operation),
            )
            continue

        flows = collective_model.expand(
            collective=operation.collective,
            ranks=operation.group,
            payload_bytes=operation.bytes,
            topology=topology,
        )
        completion_events = []
        for flow in flows:
            if mode == "analytical":
                done_at = now + analytical_time(flow, topology)
            elif mode == "ns3":
                done_at = ns3_schedule_and_return_completion(flow, topology, now)
            else:
                raise ValueError("mode must be analytical or ns3")
            completion_events.append(done_at)

        collective_done = max(completion_events, default=now)
        queue.push(
            time=collective_done,
            event=state.completion_of(operation),
        )

        for ready in state.operations_unblocked_by(operation):
            queue.push(time=collective_done, event=ready)

    return state.iteration_finish_time()

这里最重要的不是代码语法，而是完成条件：集合通信只有在其组成流全部完成后才能解除下游依赖；层对象和流对象也必须保留到回调结束。解析模式与 ns-3 模式改变的是网络事件如何计算，不改变上层工作负载语义。

Physical 与推理模式

README 还列出 beta 的 Physical mode。它用 CPU/RDMA 生成 NCCL-like 物理流量，适合在真实网络上压流或验证通信行为；它仍不是在加速卡上执行完整训练计算。

当前推理模块基于 Vidur 的请求级离散事件调度，加入多请求、MoE 模型、PD 分离和显存预算。其思路与训练仿真相通，但对象从“训练层和一次迭代”变成“请求、prefill/decode batch、KV Cache 和调度事件”。因此评估它要用在线吞吐、TTFT、TPOT、显存预算与请求分布，不能拿论文训练 Figure 9 直接背书。

精度到底怎么样

论文在两个各 128 台主机、每台 8 GPU 的集群上验证，规模最高 1024 GPU：

• A100 集群使用主机内 600 GB/s NVLink 和 4 张 ConnectX-6 网卡，每张双 100 Gbps。
• H100 集群使用主机内 900 GB/s NVLink 和 8 张 ConnectX-7 网卡，每张双 200 Gbps。
• 模型覆盖 GPT-3 13B、LLaMA 65B 和 GPT-3 175B，规模为 128、512、1024 GPU 的选定组合。

论文 Figure 9（结果证据）：在图中选定的 A100/H100、模型和 GPU 规模下，SimAI 端到端预测与真机结果接近；它不证明任意模型、任意网络、Ascend 或当前推理模块也有同样误差。

论文报告的关键数字如下：

层级	结果	应如何理解
主机内集合通信	SimAI 平均偏差 A100 3.9%、H100 2.3%	NCCL 行为模型显著优于把集合通信粗化成带宽公式
直接测量的计算模型	总计算偏差 0.5%-3.1%	同类硬件、正确 kernel 画像是高精度基础
跨硬件 CP-Model	偏差约 13%-15%	外推明显弱于直接测量
端到端训练	所测配置均小于 3.9%	是 Figure 9 测试矩阵内的上界，不是全局 SLA
平均对齐度	98.1%	是论文汇总指标，不应简写成“普遍误差 1.9%”

精度不是模拟器常数

模拟器精度取决于 模型 × 并行策略 × kernel 版本 × 集合通信算法 × 拓扑 × 链路参数 × 负载窗口。只要其中一个对象变化，原来的误差数字就需要重新验证。小消息还会受到软件栈、NIC 流水线和同步开销影响；论文也忽略小于 1 KB 的元数据/屏障通信，并在 EP 分析中假设 token 负载均衡。

当前推理模块还有更直接的源码边界：memory_planner.py 的 TODO 明确写到，DeepSeek/Qwen3 的 KV Cache 序列长度当前硬编码为 1，会显著低估单请求 KV 占用，MLA 在 TP 下如何切分也待核验。它不否定训练论文，但说明“v1.6 已支持显存建模”不等于“推理显存预测已经完成同等级验证”。

Ascend 支持审计

当前公开版：不支持

对固定版本做源码审计后，没有发现 Ascend、CANN、HCCL 或 torch_npu 实现。相反，证据明确指向 NVIDIA 栈：

• 公共 GPUType枚举只有 A100、A800、H100、H800、H20 等 NVIDIA 型号。
• AICB 的物理执行路径初始化 torch.cuda 与 NCCL。
• Mock collective 接口直接以 MockNccl命名并建模 NCCL-like 行为。
• 当前推理计算预测依赖 Hopper/Blackwell 侧的 DeepGEMM、FlashMLA 等实现。

代码和论文里出现的 NPU 是 ASTRA-Sim 沿用的通用神经网络加速器术语，类似把 GPU/NPU/TPU 都统称为 accelerator。它不代表 Huawei Ascend 产品适配。

哪些部分可以复用

不是所有代码都要推倒重来。工作负载文本、事件队列、依赖调度、统计输出，以及很大一部分 ns-3 网络执行框架，本质上是 CPU 侧和设备无关的。真正需要重做或校准的是“设备行为注入点”：

1. 计算画像层。 用 Ascend PyTorch 的 torch_npu/CANN 在目标 910B、910C 等 SoC 上测量算子或层时间，键至少包含 SoC、CANN/驱动、dtype、shape、并行度和算子实现。
2. 工作负载层。 让 AICB 能使用 HCCL backend 或导入真实 Ascend trace；同时保留 TP/PP/EP/CP、字节数和同步点语义。
3. 集合通信层。 实现 SimHCCL。官方 HCCL 算法说明包含 Mesh、Ring、Recursive Halving-Doubling、Pairwise、Pipeline 等选择；其 rank 映射、分片、并发流和拓扑条件不能照搬 NCCL。
4. 拓扑层。 表达 HCCS、PCIe、RoCE、Scale-Up/Scale-Out 链路、交换层次、有效带宽和拥塞参数。
5. 验证层。 在同一个模型、batch、精度、并行计划、HCCL 配置、拓扑和统计窗口下，对比真机与仿真，分别报告计算、集合通信和端到端误差。

可以把 Ascend 适配的最小接口写成：

def calibrate_ascend(simulator, ascend_cluster, workload):
    compute_db = profile_with_torch_npu(
        cluster=ascend_cluster,
        operators=workload.operator_shapes(),
        warmup=20,
        repeats=100,
    )
    hccl_model = build_hccl_flow_model(
        algorithms=ascend_cluster.supported_hccl_algorithms,
        rank_table=ascend_cluster.rank_table,
        topology=ascend_cluster.topology,
    )
    simulator.install_compute_profile(compute_db)
    simulator.install_collective_model(hccl_model)

    measured = run_real_workload(ascend_cluster, workload)
    predicted = simulator.run(workload, ascend_cluster.topology)
    return compare_by_scope(
        measured=measured,
        predicted=predicted,
        scopes=["compute", "collective", "iteration"],
    )

不能接受的 Ascend 精度论证

“解析引擎是通用 C++，所以天然支持 Ascend”“把 A100 的 FLOPS/带宽替换成 910B 参数就能达到 3.9%”“代码出现 NPU 字样”都不构成支持证据。没有 HCCL 行为、目标卡计算画像和真机同配置对照，就没有可报告的 Ascend 精度。

如何选择模式

如果只是做早期架构空间搜索，可以先用 Analytical mode 快速筛掉明显差的 TP/PP/EP、链路带宽和拓扑组合；进入候选收敛阶段，再用 ns-3 Simulation mode 检查拥塞、流竞争和拓扑敏感性。最后必须用少量真机测量闭环校准。

一个务实流程是：

1. 固定问题。 明确是在比较硬件、网络、并行策略还是调度器，避免一次改多个变量。
2. 生成工作负载。 先检查每层计算、通信类型、rank 组和字节数是否符合框架语义。
3. 跑解析基线。 用小规模真机点标定 T_compute、B_bus 和短消息项。
4. 跑包级候选。 只对对拥塞敏感的少量候选启用 ns-3。
5. 分层验证。 先核计算，再核集合通信，最后核端到端；不要只看一个总时间“碰巧接近”。
6. 记录适用域。 把版本、硬件、模型、精度、拓扑和统计窗口与误差数字一起保存。

仓库 README 给出了 Analytical 和 Simulation 的 Docker/脚本入口；实际使用时应从固定提交的说明开始，而不是从论文图猜配置。Physical mode 是 beta，推理模块又有独立依赖和参数，两者都应单独验证。

总结

SimAI 的价值不在“用一个公式替代千卡集群”，而在把大模型系统拆成可校准的五类对象：框架工作负载、计算时间、集合通信行为、网络事件和依赖关键路径。解析模式负责速度，ns-3 模式负责网络细节，少量真机 profiling 负责把模型锚定到现实。

论文在所测 NVIDIA 训练配置中给出了很强的结果：端到端偏差小于 3.9%，平均对齐度 98.1%。但这组数字有清晰边界，不能覆盖论文后的推理模块，更不能覆盖尚未实现的 Ascend 后端。

对 Ascend，正确结论不是“完全不能用”，而是：通用事件执行骨架有复用价值，设备相关的计算画像、HCCL 行为和拓扑模型尚缺，精度必须从零校准。 在完成这三层适配和真机对照之前，任何具体 Ascend 误差数字都只是猜测。

参考资料

• SimAI GitHub repository
• SimAI, USENIX NSDI 2025
• AICB GitHub repository
• Ascend PyTorch adaptation
• HCCL communication algorithm guide

评论