CrystalLLM：用少量 GPU 重现大规模训练（SOSP 2026）

原题：A Few GPUs, A Whole Lotta Scale: Faithful LLM Training Emulation with CrystalLLM

一句话总结：CrystalLLM 先用少量 GPU 轮流执行全部 rank 来采集、校准目标训练图，再让待调试的 rank 真跑、其余 rank 按图回放并参与真实通信。0.58% 平均迭代时间误差是在最高 2048 张真实 GPU 对照上测得；8192 张只是无同规模真机基线的规模展示（§4–§7）。

问题与动机

训练框架工程师需要复现大集群上的慢节点、通信重叠和内存峰值，却往往无法占用同等规模 GPU 做调试。纯模拟依赖大量随框架版本改变而失效的性能模型；把作业缩到少数 GPU，则改变并行分组、collective 行为和 rank 间依赖（§1–§2）。

关键观察 / 隐含假设

调试通常只需观察部分 rank 的真实行为：并非每个 rank 都要运行原程序，关键是其他 rank 对目标 rank 的依赖和时序足够逼真（§3）。
执行图必须由真实代码路径产生：第一阶段轮流运行每个 rank 并记录通信依赖；一般路径可保存 CUDA context 继续执行，耗时较大；用户也能预先给出通信张量以加速采集，但需要保证会影响分支的张量值合理（§4.2）。
物理链路仍承担真实通信：虚拟 rank 不计算算子，却向真实 rank 发真实的 NCCL 消息；回放能否准时供给张量依赖 PCIe 预取快于网络消费（§3.1、§5.1）。
性能准确性与语义准确性有差别：迭代时长和峰值内存接近实机，并不自动说明任意硬件故障、数值错误或竞争条件都能重现。

核心方法

第一阶段：采集有依赖、无时间的执行图

协调器只调度可用 GPU 数量的 rank；遇到 collective 而参与者不全时，保存该 rank 的通信输入和 GPU 上下文，换入能解除阻塞的 rank。所有参与者到齐后由 CPU 执行 collective，之后恢复各 rank。这样保留真实程序的值相关控制流，而不要求同时持有目标规模的 GPU（§4.2、图 3）。代价也很实在：以 80 GB 上下文为例，128 rank 可能需要约 10 TB 保存空间；几乎满载的上下文一次保存与恢复可超两分钟。对于知道数据语义的用户，论文允许直接提供通信输入/输出：在 Megatron-LM 案例中需要处理 dataloader 状态、合法 token ID、MoE all-to-all 分块这三类会改变控制流或内存占用的值。235B、2048 GPU 目标的纯上下文切换约需 9 小时采集；注入通信张量约需 64 分钟；如果利用 DP 组图同构，只采一个 32-rank 模型副本，可约一分钟完成。这个加速依赖使用者正确提供关键张量，不能一概称为透明自动采集。

第二阶段：分片填时间，跨片校准

第一阶段只知道操作和依赖，不知道真实时长，因为上下文切换污染了时间。论文把 rank 分片，每次让一片真跑，其他 rank 由辅助 GPU 回放来提供通信对端；循环到每个 rank 都至少真跑一次。随后按 send→receive 等跨片依赖平移时间戳，形成全局一致的图（§4.3、图 4）。因此，准确性既依赖真跑测时，也依赖跨片校准正确；网络条件或训练配置变化需重新校准。

混合回放：虚拟计算，真实通信

沙箱 GPU 执行原训练程序；辅助 GPU 上的虚拟 rank 遇到计算节点就等待记录的时间，遇到通信节点就实际通信。张量由磁盘预取至 GPU buffer，空间不够时暂存在 CPU buffer，通信完成后逐出（§5.1）。通信组也不能照目标集群全开：论文在 PyTorch c10d 跳过不触及沙箱 rank 的组，并在 NCCL 初始化时仅实例化与沙箱相邻的虚拟 rank；缺席 rank 的 TCPStore barrier 和拓扑信息由辅助 rank 代理。示例中，2000 个虚拟 rank 所需的活跃 NCCL 组从 8617 缩到 82（§5.2、图 5）。运行时还剪去纯虚拟 rank 间的通信，同时保持沙箱端 collective 的数值语义（§5.3）。这是系统可扩展的核心，不只是把空闲 rank 设成 sleep。

设计取舍

真实 rank 需要沙箱 GPU：目标 rank 的框架行为可以复现；当前回放的虚拟 rank 不运行计算，其数据相关异常不能在同一次回放中自然出现。
图采集减少并发硬件需求，却增加准备成本：全自动上下文切换可能以小时计；手动注入数据快得多，但必须知道哪些张量控制后续路径。
只保留与沙箱相邻的通信链路：它大幅降低初始化和内存负担，但验证范围是沙箱可观察到的行为，不能把纯虚拟区域当成真集群。
按目标集群做配置：网络拓扑、设备型号和训练框架版本变化会使原有校准失效。

实验与结果

真机精度：在 512、1024、2048 GPU 的 Qwen3 MoE/Megatron-LM 训练配置上对照，迭代时间平均误差 0.58%、最大 1.98%；GPU 峰值内存误差小于 0.01%，还复现了不均衡 MoE 路由导致的 OOM（§7.2、图 7–8）。这些精度数字不适用于未对照真机的 8192 GPU 案例。
规模和成本：8192 GPU 目标用 32 个物理节点即 256 GPU（<0.4%）回放，端到端仿真低于 80 分钟；图采集约四分钟。减少辅助节点的 1024 GPU 消融需要约 125 分钟，约慢 1.6 倍，说明低 GPU 占用与回放时间需折中（§7.3、图 9）。
初始化消融：512 逻辑 rank 的独立 CUDA context 基线需要约 544.5 GB 主机内存、103.7 GB GPU 内存和 756 秒初始化，在 1024 rank 及以上 OOM；剪枝机制避免这类线性膨胀（§7.3）。
时间稳定性：论文检查了 kernel 时长误差和开始时间，后者最大误差 3.64%；它衡量的是所选配置的时间重建，而不是所有尾部事件或跨作业网络拥塞（§7.2）。

论断—证据表

论断	证据	评测边界	置信度
真实局部执行可重现目标规模时序	512–2048 GPU 对照：平均误差 0.58%，最大 1.98%（§7.2）	Qwen3 MoE/Megatron-LM 与所测拓扑	强（该集合）
沙箱内存峰值仍能保真	峰值 GPU 内存误差 <0.01%；MoE 路由 OOM 可复现（§7.2）	被真实执行的 rank	强（该集合）
少量硬件可承载更大目标配置	8192 目标使用 256 物理 GPU，<80 分钟（§7.3）	没有 8192 真机精度基线	强（可运行规模），未知（精度）

批判性分析

论证链条

论文从“要观察特定 rank”推出执行图切片，再用真实 rank 与虚拟参与者混合执行。迭代时间和内存误差支持性能调优用途；它们对分布式一致性错误或数值漂移的支持有限，因为虚拟 rank 不运行完整训练逻辑。

假设压力测试

若故障只有在许多 rank 共同修改状态时出现，单次仅真跑局部 rank 可能漏掉原因。MoE 路由的数据若变了，注入的通信张量和图都要重新审查；论文明确指出当并行设置或 collective 元数据改变时要重新采图。网络拥塞若由其他作业造成，也不会从单一训练图中自然出现。

实验可信度

与最高 2048 GPU 真实运行对照并报告时间和内存两类误差，比只展示节省 GPU 更有说服力。8192 GPU 是可扩展性实验，不能用其规模和 2048 GPU 的精度数字拼成“8192 GPU 精度 0.58%”。论文的训练程序、硬件、并行策略仍是有限集合；排查 straggler 时还应单独看逐 rank 和尾部迭代误差。

系统性缺陷

仿真平台自身需持续适配训练框架、collective 算法和新 GPU 互连。维护高保真执行图可能成为与训练框架同量级的工程负担，论文尚未量化长期维护成本。

局限与后续工作

在动态 MoE 路由、弹性扩缩和跨作业网络竞争下报告逐 rank 误差与尾部迭代误差。
对真实故障案例建立“能重现/不能重现”分类，而不只用性能误差衡量调试价值。

Awesome System Papers Wiki

探索

CrystalLLM-SOSP26