Lumos：一次真实迭代，能否替代 512 张 H100 上的试错？

0. 链接验证表与证据口径

以下链接均在 2026-09-04 实际访问。实验数字只来自逐页读取的论文 PDF；网页只用于核验版本、会议与资源状态。没有从曲线像素猜数：图 7 的数字直接印在堆叠条上；其余没有标签的柱/曲线只作定性判断。

证据标签：论文原报 表示作者文字或表图标签；本报告复算 只做加总、差值与百分比；论文未报告 绝不以推测填补。HTML、Markdown、纯文本三份正文由同一 Markdown 源生成，内容一致。

1. 候选池、排重与真实随机选择

先查 ml-report-index.md：最近 14 天已经深读 QServe（量化服务）、PARQ（量化训练）以及与生成系统相邻的 LongLive，因此剔除它们及近重复的“再做一篇低比特”。候选来自 MLSys 2025 proceedings、OSDI 2025、arXiv、OpenReview、Hugging Face Daily Papers、Papers with Code 与 Semantic Scholar 的交叉检索；后四者用于发现或核验，不以二手摘要替代原论文。

本地执行 date +%u 得到 5，确认周五；执行 shuf -i 1-24 -n 1 得到 16。因此核心论文是 Lumos。重抽次数：0；正文、附录级讨论、会议终稿和九组带数字的 scale-out 分解足够支撑深读。它发表于当前日期前约 17 个月，仍在“不得超过 24 个月”的硬约束内；候选优先主会系统论文，随机步骤没有按热度挑选。

2. Motivation：最难预测的不是 FLOPs，而是“什么时候真的能跑”

大模型训练配置空间是模型结构与系统策略的笛卡尔积：层数、隐藏维、FFN 维度、micro-batch，再乘 TP、PP、DP、pipeline schedule、collective 与网络拓扑。简单解析模型把每项耗时相加，却无法知道通信与计算重叠了多少；粗粒度 trace simulator 又可能漏掉 host thread、CUDA runtime、不同 stream 之间的因果边。

论文用 GPT-3 175B、TP=8, PP=4, DP=8 的一次迭代给出直观证据。图 1（PDF p.2；网页抽取 p.1 lines 60–65）中，dPRO/实测的四部分依次为：exposed compute 3235/4287 ms、overlapped 1691/885 ms、exposed communication 1417/2261 ms、other 81/178 ms。加总为 6424 vs 7611 ms，即 dPRO 低估总时长 1187 ms（15.60%）；更重要的是，它把真正暴露的 compute 低估 24.54%，却把 overlap 高估 91.07%（本报告复算）。总数错，可以用校准项勉强修；分解错，则会把工程师引向错误瓶颈。

这正是 Lumos 的问题定义：给定一次或少数几次实际 trace，构造足够忠实的执行图 G=(V,E)，使仿真既重放端到端 makespan，也保留 compute、communication、overlap、host/runtime 和时序空洞；然后只改受新配置影响的节点、边与 duration，做成本远低于真机部署的反事实估计。

其核心假设与代价是：

1. 迭代稳定性假设：一次/少数几次 trace 代表长期迭代。论文称因此 profiling overhead 对全训练“negligible”，却没有给 overhead 百分比（§5，PDF p.10；lines 760–767）。
2. 依赖模式可迁移假设：改变层数或 PP 后，旧 trace 的局部依赖模板仍成立（§3.4，PDF p.5；lines 360–383）。它换来廉价变换，但可能漏掉编译器选择、融合、拥塞相变。
3. duration 可外供假设：新 GEMM/collective 的时间由内部 fleet-trace 模型估计；kernel predictor 本身明确不在论文范围内（§5，PDF p.10；lines 783–797）。因此 Lumos 的公开方法只解决“何时可调度”，未完整公开“新任务跑多久”。

3. 故事线：从 profile 到反事实执行图

Lumos 的设计链条很紧：Kineto 负责观察，依赖恢复负责因果，图变换负责提出反事实，离散事件仿真负责把反事实执行出来。

第一层：低侵入采集。 Kineto 同时记录 PyTorch operator、CUDA runtime event 与 GPU kernel，包括开始时间、duration、stream/thread/correlation ID。论文称只需约 10 行 hook；系统为 Python 约 5200 LoC，从原 trace 到预测 trace 用时数秒至数分钟（§4，PDF p.6；lines 437–445）。这比要求修改 framework/model 的旧工具更易落地，但“需要源码插 hook”仍不是零接入。

第二层：补齐四种依赖。 节点只有 CPU task 与 GPU task 两类，边却覆盖四象限（§3.3，PDF pp.4–5；lines 252–318）：

• CPU→CPU：同 thread 的顺序边，以及由显著 execution gap 推断的跨 thread 阻塞边；
• CPU→GPU：以 correlation ID 连接 cudaLaunchKernel/cudaMemsetAsync 与目标 kernel；
• GPU→CPU：cudaDeviceSync/cudaStreamSync 把完成的 kernel 连回阻塞的 host task；
• GPU→GPU：同 stream 顺序边；跨 stream 则配对 cudaEventRecord 与 cudaStreamWaitEvent。

Lumos 相对 dPRO 的真正技术跃迁不是“图更细”这句口号，而是显式保存跨 stream 的 happens-before。LLM 训练恰恰大量用独立 stream 覆盖 NCCL 与 GEMM；少一条 wait edge 就会让仿真认为二者可同时执行，造成图 1 那种 overlap 虚高。

第三层：图变换。 DP 变化时，本地计算不变，只更新 collective duration；PP 变化时，按 1F1B schedule 重新分层、分 stage、插通信节点并重建相邻依赖；层数变化复制 layer subgraph，hidden/FFN 变化则改 tensor shape 和关键 GEMM/通信 duration（§3.4、§4.3.2，PDF pp.5、9；lines 360–383、717–726）。论文不支持改变 TP，理由是实践中通常固定在单节点内，留作未来工作（PDF p.5；lines 370–373）。

4. 方程级形式化、伪代码与流程

令每个任务 v∈V 具有处理器 p(v)（CPU thread 或 CUDA stream）、持续时间 d(v)、固定前驱 Pred_f(v) 与运行时前驱 Pred_r(v,t)。仿真开始时间可写为：

s(v) = max( A[p(v)],  max_{u∈Pred_f(v)∪Pred_r(v,t)} (s(u)+d(u)) )
f(v) = s(v)+d(v)
A[p(v)] ← f(v)
T_iter = max_v f(v) − min_v s(v)

A[p] 是处理器下一次可用时间。固定边在初始化计入 indegree；运行时边要等 task 被选中时才能解析，例如 cudaStreamSync 必须等待“当时该 stream 最后一个 kernel”，这个对象在仿真前未必可知。论文 Algorithm 1（PDF p.6；lines 384–417）可重写为：

R ← 所有固定入度为 0 的任务；A[p] ← 0
while R 非空:
    v ← pick(R)
    动态发现 v 的 runtime dependencies，并把 v 暂挂到前驱 dependents
    if v 当前入度为 0:
        s(v) ← max(A[p(v)], 已知最早开始时刻)
        A[p(v)] ← s(v)+d(v)
        for c in dependents(v):
            indegree(c) -= 1
            earliest(c) ← max(earliest(c), A[p(v)])
            if indegree(c)=0: R.add(c)
输出带所有 task 起止时刻的新 trace

流程不是线性的“测一下再乘 scaling factor”，而是：

                    ┌─ CPU thread 顺序/阻塞 ─┐
Kineto trace ─解析─┼─ launch / sync 相关边 ─┼─→ G=(V,E)
                    └─ CUDA stream/event 边 ─┘       │
                                                     ├─ 原图重放 → 精度审计
新 DP/PP/层数/宽度 ─→ 图复制/切分/插边/改 duration ─┤
                                                     └─ 事件仿真 → 预测 trace
                                                                   ├─ makespan
                                                                   ├─ 暴露计算/通信
                                                                   └─ overlap/活动时间线

5. 关键机制与工程细节

6. 数据集、平台、基准与指标

这不是下游 ML 数据集评测，而是系统 trace 实验。模型来自 NVIDIA/MLPerf Training 的开源 GPT-3 实现；四种架构见表 1（PDF p.7；lines 467–471）：15B=48层/6144 hidden/12288 FFN/48 heads，44B=48/12288/24576/48，117B=96/12288/24576/96，175B=96/12288/49152/96，head dimension 均 128。

平台是最多 512 张 H100、32 台服务器、每主机 8×400 Gbps、RoCE 数据中心网络；软件为 CUDA 12.4、PyTorch 2.5、Transformer Engine 0.12.0、PyTorch Lightning 1.9.4（§4.1，PDF p.6；lines 456–460）。这套平台足够大，但单一 GPU/网络世代也意味着外推到 A100、Blackwell、InfiniBand 或拥塞共享集群未经验证。

核心指标是迭代时间相对绝对误差：Err=|T_pred−T_real|/T_real×100%。分解为 exposed compute、overlapped、exposed communication、other。论文还称“SM utilization”，但它的定义是每个 1 ms 窗口内“至少一个 CUDA stream 正在执行任务”的时间比例（§4.2.3，PDF p.8；lines 615–622），并非 CUPTI 的 active warps、SM occupancy、tensor-core utilization 或 achieved FLOPS。准确称呼应是 stream-active duty cycle；本报告后文不把它误读成硬件 SM 饱和度。

7. 完整主结果数据矩阵

7.1 重放：Lumos 对 dPRO

换一种更不易误读的说法：平均误差约缩小到 dPRO 的 0.236 倍，而不是“训练快 4.24×”。Lumos 是预测器，论文没有让训练作业本身提速。

7.2 九个反事实 scale-out 配置 × 四项时间分解

下表完整抄录图 7 标注值（PDF p.8；网页 lines 629–675），每格单位 ms；P/A 为 Lumos 预测/真实。总误差按印刷整数重算，可能与作者用未舍入数得到的平均值略异。

逐组解读比“平均 3.3%”更有信息：仅扩 DP 三点误差 0.62%–2.98%；PP 三点 2.88%–6.83%；同时扩展中 2×8×8 达 7.76%。作者另称同时扩 DP+PP 平均误差 4.2%（§4.3.1，PDF p.9；lines 697–700），用图中整数复算三点平均为 4.01%；差 0.19 pp 很可能来自柱上取整，不能据此断言论文矛盾。

值得注意的是，分解分量可有较大偏差而总数仍接近：2×4×8 的 other 预测 55、实测 39，分量相对高 41.03%，却因它只占小部分，总误差仍 2.74%。因此 Lumos 的强证据是 makespan 预测；关于每个细分瓶颈“都很准”的结论需要逐分量误差矩阵，论文没有汇总提供。

7.3 模型架构变化

表 2（PDF p.9；lines 703–709）从 GPT-3 15B 基线构造四个变体：V1 20B（64 层）、V2 30B（96 层）、V3 28B（hidden 9216/FFN 18432）、V4 44B（hidden 12288/FFN 24576），统一 TP=2,PP=2,DP=4。图 8展示 actual 与 predicted 分解“接近”，但柱上未印精确数、正文未报误差均值/最大值；因此本报告不补数字，也不能比较“改深度”和“改宽度”谁更可靠。

8. 逐层消融、超参敏感性与相变

8.1 逐层消融

论文未报告标准组件消融表：没有分别移除 CPU→GPU correlation、GPU→CPU sync、inter-stream event 或 runtime dependencies 后的误差。图 6只给 Actual/Lumos/dPRO 的一条 GPT-3 15B, TP2-PP2-DP4 活动时间线，且没有数值距离指标。因而可以说“完整系统优于 dPRO”，不能把 10.7 pp 平均误差下降定量归因到某一类边。

可以从图 1做机制一致性检查：dPRO overlap 比实测高 806 ms、Lumos 设计恰好补 inter-stream happens-before；这支持因果故事，但不是控制变量消融。最有价值的缺失实验应是同一 Lumos 依次移除四类依赖，报告九配置 makespan、分量 L1 error 与关键路径 edge recall。

8.2 超参敏感性与相变

论文未报告对 gap 阈值、trace 采样迭代数、1 ms utilization bin、ready-task pick 规则或 kernel predictor 误差的敏感性。尤其是两个潜在相变：

• 当通信 predictor 的误差改变 collective 完成顺序时，critical path 可能离散跳转，端到端误差不再线性随单 kernel 误差增长；
• 当 PP stage 数改变到触发不同 kernel/fusion 或显存策略时，“复制旧 layer 子图”会跨出可迁移区域。

论文只测试从 16 GPU 基线扩至 32/64/128 GPU 的 DP/PP 变体（§4.3.1，PDF p.9；lines 678–700），没有逆向缩容、跨 GPU 型号或拥塞负载。于是能推出在其 H100/RoCE/实现附近存在一个低误差局部邻域，不能推出全配置空间平滑。

8.3 统计显著性

论文未报告重复次数、标准差、置信区间、显著性检验或跨时间段方差。既没有 cluster contention 分布，也没有 profiler run-to-run 变异。因此 3.3% 与 4.2% 是所选配置上的描述统计，不能视为部署前的概率保证。若训练 iteration 本身抖动 3%–5%，单点相对误差与测量噪声可能同阶；论文没有足够数据拆分模型误差与系统噪声。

9. 真正贡献、可复用设计与迁移潜力

真正贡献一：把 host/runtime/stream 同时放进执行因果图。 这是可复用的抽象：优化器不必理解整套 PyTorch，只需在 DAG 上改节点、边或 duration。它也解释了为何简单把 operator time 与 NCCL time 相加会错。

真正贡献二：让预测结果仍是一条 trace。 输出不是孤立的 iteration number，而能继续算暴露通信、重叠和活动时间线。这使性能模型可进入诊断闭环：找关键路径→提出 kernel/parallelism 修改→图上重放→只实现最有潜力者。

真正贡献三：把配置探索从“重新部署”改成“局部图手术”。 DP 只改通信，PP 重排 layer/stage，宽深变化只替换受影响的 key kernels。工程上这比从零建解析模型更快，也比每个候选占用数百 GPU 更便宜。

可迁移到 inference、MoE、异构 accelerator 或 elastic training，但要满足三件事：profiler 能同时给 host/device 事件；新 schedule 的依赖模板可形式化；kernel/network duration 有公开且校准过的供应器。缺任一项，“框架无关”就只是后处理代码无关，而非端到端可用。

10. 相关工作：问题来源与技术来源链

10.1 Daydream：图变换的源头

解决什么：Daydream 用 CUPTI 低层 trace 构建 kernel dependency graph，并以领域知识和图变换原语预测某种优化会怎样改变运行时；USENIX 页面明确将问题定义为“实施前回答优化 X 的收益”。其演示材料报告五类优化、五个 DNN 的平均估计误差约 8%（presentation p.3）。

遗留缺口：需要 framework/model instrumentation，重点是单机/早期 DNN 优化，不覆盖现代分布式 LLM 的 host/runtime 与跨 stream 复杂关系。Lumos 如何回应：沿用 trace→DAG→graph transform→simulate 范式，换成 Kineto 并补四类边。设计如何传递：Daydream 的“修改图而非先修改系统”成为 Lumos what-if 接口的直接思想祖先。

10.2 dPRO：全局分布式图与可比较基线

解决什么：dPRO 把多 worker 的细粒度通信 trace 合并为 global data-flow graph，并搜索 computation/communication/memory 优化；原文报告多数设置预测误差 <5%，优化最高 3.48×（arXiv 摘要；MLSys 2022 PDF p.1）。遗留缺口：它面向 TensorFlow/MXNet 与 AllReduce/PS 时代，Lumos 指出其忽略 concurrent-stream/inter-stream dependencies，导致新 LLM 配置平均误差 14%。

Lumos 如何回应：以 event pair 和 runtime sync 显式恢复跨 stream 因果，在相同论文实验中把平均误差降至 3.3%。设计如何传递：dPRO 的全局图、topological simulation 与 optimization hook 保留；Lumos 主要升级 trace granularity 与 dependency semantics。应注意 dPRO 原论文的 <5% 与 Lumos 复测的 14% 来自不同模型、框架与硬件，不能说旧论文自相矛盾。

10.3 TraceSim：Lumos 的直接原型

解决什么：同一作者链的 TraceSim 已经用 Kineto 同时保存 operator、runtime、kernel，并在 256 H100 的 GPT-3 上报告平均重放准确率 95.6%、scale-up 最高 99.5%（PDF p.1 lines 13–19；p.5 lines 423–432）。遗留缺口：5 页 workshop 稿只给概念验证，对 PP/架构图变换、动态依赖算法与限制展开不足。

Lumos 如何回应：扩到 512 H100、四个 GPT-3 尺寸、显式 Algorithm 1、九组 DP/PP 反事实和架构变体。设计如何传递：Kineto 多层 trace、四类依赖和“生成预测 trace”几乎原样进入 Lumos；所以 Lumos 更像系统化、扩展验证的成熟版本，而非完全不同的方法。

10.4 ASTRA-sim 2.0：通信与硬件空间的互补供应器

解决什么：ASTRA-sim 2.0 以 graph-based training loop 支持任意 parallelism，并建模多维异构 topology、collective、in-network compute 与 disaggregated memory（arXiv v1 pp.1–2）。遗留缺口：它需要 workload 与系统抽象，未从一次 PyTorch 实跑自动恢复完整 host/CUDA happens-before。

Lumos 如何回应：从真实 trace 得到 workload execution graph；反过来，Lumos 对 unseen collective duration 使用内部模型，并明确提出未来可接 ASTRA-sim（§4.3.1/§5，PDF pp.9–10）。设计如何传递：理想组合是 Lumos 供真实因果结构，ASTRA-sim 供新 topology 下的通信 duration；二者不是谁取代谁。

10.5 Calculon：解析搜索的另一条支线

解决什么：Calculon 参数化模型、硬件与 implementation strategy，在内存等约束下快速遍历 LLM 软硬件联合空间；开源 README 示例称单配置约 1 秒、5128 A100 的 execution optimizer 约 1 分钟。遗留缺口：解析模型依赖理想化分解，难原样表达动态 host launch、stream wait 与真实 runtime 空洞。

Lumos 如何回应：用实测 trace 锚定动态行为，牺牲对全新硬件的零样本能力。设计如何传递：Calculon 适合全球粗筛，Lumos 适合已部署栈附近的局部精排；可先用 Calculon 削减搜索空间，再用 Lumos 重放候选。

10.6 非线性技术演进树

硬件/解析模型 ─ Calculon ───────────────┐
                                        ├─ 粗筛新硬件/全局设计空间
网络/collective 仿真 ─ ASTRA-sim 2.0 ──┤
                                        └─ duration supplier ─┐
                                                              │
CUPTI kernel DAG ─ Daydream ─┐                                │
                              ├─ global distributed graph ─ dPRO
                              │                    │           │
                              └─ graph transforms  │           │
                                                   ▼           ▼
                                  Kineto operator+runtime+kernel
                                                   │
                                 TraceSim：跨 stream 依赖原型
                                                   │  扩规模/图变换/动态边
                                                   ▼
                                      Lumos：局部反事实重放
                                                   │
                         ┌─────────────────────────┴──────────────┐
                         ▼                                        ▼
              开源 kernel/网络预测器                         概率化噪声与 OOM/能耗

演进动力与转折：第一转折是从“解释过去的 profiler”到 Daydream 的“预测尚未实施的优化”；第二转折是 dPRO 把单设备图扩成全局分布式图；第三转折是 LLM 通信—计算多 stream 重叠使粗边语义失效，TraceSim/Lumos 转向 operator/runtime/kernel 三层因果；下一转折应是公开的 duration model 与不确定性传播，否则局部精确图仍被私有时延估计锁住。

10.7 跨论文对标

11. 论文自述限制

1. 可行性盲区：反事实配置被假设能正常运行，不预测 OOM；FLOPS utilization、内存、带宽和能耗也在范围外（§5 “Limitations”，PDF p.10；lines 808–816）。所以最短的预测配置可能根本放不下。
2. 新 kernel duration 不在范围内：当前依赖内部 fleet trace 模型；通信可换 ASTRA-sim/解析模型，计算可 microbenchmark，但论文没有整合与误差传播（§5，PDF p.10；lines 783–797）。
3. TP 不可修改：只支持 DP/PP 与模型宽深；作者认为 TP 常固定于节点内（§3.4，PDF p.5；lines 370–373）。这排除了训练配置搜索中的一个关键维度。

12. 独立批判：因为 X，所以 Y

1. [可复现性] 因为论文描述约 5200 LoC，却未提供代码、trace 或内部 kernel predictor；所以外部研究者无法复算 3.3%，也无法判断误差来自图结构还是私有 duration 模型。
2. [指标效度] 因为所谓 SM utilization 只是 1 ms 内任一 stream active 的时间比例（PDF p.8），一个低占用 kernel 也记作“活跃”；所以图 6不能证明 SM/Tensor Core 被高效利用，只能证明活动/空闲时间线相近。
3. [外部效度] 因为全部主实验集中在 H100、RoCE、一个 GPT-3 实现和一套软件版本；所以不能推出对 A100/Blackwell、InfiniBand、MoE 或不同编译器同样是 3.3%。
4. [消融归因] 因为没有逐类删边消融，只比较完整 Lumos 与 dPRO；所以平均 −10.7 pp 不能全部归因于 inter-stream event，也可能包含 profiler、解析和 duration predictor 的共同变化。
5. [统计可靠性] 因为没有多次运行、标准差或区间；所以 2×2×8 的 0.62% 与 2×8×8 的 7.76% 不能与集群自然抖动区分，无法给部署者风险界限。
6. [搜索完整性] 因为不改 TP，PP 只展示 1F1B/规则分层，且假设 layer 均匀；所以它是局部配置估计器，不是完整 3D parallelism 自动规划器。
7. [可行性/目标错位] 因为不建模 OOM、能耗、训练成本与吞吐波动；所以“预测最快”不等于“可运行、最低成本或最节能”，也不能直接支撑采购决策。
8. [分量可信度] 因为 2×4×8 的 other 分量由 39 ms 预测为 55 ms（+41.03%），总误差却只有 2.74%；所以低 makespan error 会掩盖小分量的大相对偏差，瓶颈诊断需单独报告分量误差。

13. 开放挑战：可操作的 head-to-head 实验空白

理论

• 依赖边误差传播：在同一 trace 上比较完整 Lumos、删除 event edge、删除 host sync、随机漏边 1/5/10% 四组；以 critical-path precision/recall、makespan error 与分量 L1 error 作 head-to-head，建立“漏一类边会错多少”的上界。
• 不确定性传播：比较点估计 Lumos 与“每 kernel duration 为分布”的 probabilistic Lumos，在跨天 30 次真机运行上评估 50/90/95% prediction interval coverage，而非只比平均绝对误差。

工程应用

• 公开 duration supplier：固定 Lumos 图，分别接 microbenchmark lookup、Calculon/AMPeD、ASTRA-sim、学习型 kernel predictor，与内部模型做同九配置比较；报告精度、校准成本、模拟时间和需要的真机 GPU-hour。
• 等预算配置搜索：给 Lumos、Calculon、Megatron empirical grid search 同样 24 小时墙钟/同等 H100-hour，在 TP×PP×DP×microbatch 空间寻找最快且不 OOM 的配置；最终统一真机复测 top-5，衡量 best-found throughput 与失败率。
• 跨平台转移：同一模型分别在 H100-RoCE、A100-InfiniBand、B200-NVLink 上采源 trace，并交叉预测另外两平台；与“各平台重新 profile”对比，量化 trace 可迁移性和冷启动成本。

新兴方向

• MoE 动态路由：在 expert imbalance 可控的 MoE 上比较单迭代静态 Lumos 与保留 token-routing 分布的 stochastic simulator；逐级增加偏斜，测 p50/p95 iteration time 与 straggler attribution。
• 编译器相变：改变 hidden size 使 Triton/cuBLAS 在不同 kernel/fusion 间切换，比较“复制旧图+改 duration”与“重新编译+重新 profile”；寻找图拓扑发生变化的阈值。
• 训练—能耗联合目标：在相同吞吐候选上接 NVML 功耗 trace，比较只最小化 makespan 与 Pareto 搜索（时间、峰值显存、kWh）；验证 3.3% 时间误差是否足以保持 Pareto 排序。

14. 近期工作雷达（非核心证据）

1. vTrain（2023/2024）：面向 LLM 训练的成本与 compute-optimal 仿真，适合和 Lumos 比“从抽象 workload 开始”与“从真 trace 开始”的冷启动代价。
2. Proteus（EuroSys 2024）：以 strategy tree 表达复杂并行策略，补足 Lumos 不改 TP 的缺口；应在同一 Megatron 配置空间做等预算搜索。
3. ReaLLM（ASAP 2025）：把芯片级 kernel library 与系统 trace-driven inference 连接，报告 4×H100 平均 latency error 9.1%；范围是推理而非训练。
4. PRISM（2025）：把系统变异作为概率分布而非固定 duration，正面回应 Lumos 无置信区间的问题；公开实现仍以作者承诺为准。
5. Simulating LLM training workloads for heterogeneous compute（2025）：引入非均匀 workload partition，适合验证 Lumos 的均匀 layer/stage 假设在异构集群何时失效。
6. TileSight（2026）：从 tile-first principles 建模 GPU，代表“低层解析+高层系统”重新汇合；与 Lumos 的关键互补仍是新 kernel duration。
7. Charon（MLSys 2026）：统一训练与推理、以编译式逐层 lowering 构造细粒度仿真；作者报告总体误差低于 5.35%、大规模训练低于 3.74%，是 Lumos 最直接的新近 head-to-head 对手。
8. MLCommons Chakra（MLSys 2026 Industry Track）：把 compute、memory、communication、控制/数据依赖和资源约束做成开放 execution-trace 交换格式；它可能解除 Lumos trace 与其他模拟器之间的私有格式锁定。

15. 结论：值得看什么，不该相信什么

Lumos 最值得复用的是“从真实 happens-before 出发做局部反事实”：它证明现代 LLM 训练的性能误差，常不是 FLOPs 方程不够精，而是 host、runtime、CUDA stream 和 synchronization 的因果边没有被保留下来。平均重放误差从 14.0% 降至 3.3%（−10.7 pp，−76.43%）是强结果；九个 scale-out 点又显示，局部误差从 0.62% 到 7.76%，不是无条件的 3.3% 保证。

真正的落地判断应更克制：在作者的 H100/RoCE/PyTorch/GPT-3 邻域内，Lumos 是很有潜力的配置“沙盘”；但没有公开实现、内部 kernel predictor、TP 变换、OOM/内存/能耗模型和统计区间之前，它还不是可独立复现的全栈容量规划器。最佳后续路线不是再堆一层更复杂 DAG，而是把 Lumos 图、ASTRA-sim 通信、公开 kernel predictor 和概率误差传播拼成可验证闭环。

核验脚注：本报告已读取 Lumos 13 页 arXiv v1/MLSys 终稿、TraceSim 5 页论文，并访问相关工作的会议、arXiv、代码/项目入口。候选池原始表保存为 2026-09-04_efficiency_candidates.tsv；随机结果为 16，无重抽。论文未报告的消融、标准差、显著性、精确图 8 数值与 profiling overhead 均明确保留为空白。ml-report-index.md 已追加本次条目。HTML 已通过 Warm Editorial 结构验证器（0 warnings）及 DOM/响应式静态检查；运行环境有 Playwright 包但没有 /usr/bin/chromium 或 /opt/pw-browsers 浏览器可执行文件，按要求未运行 playwright install，故浅色、深色与移动端的浏览器截图检查本次无法执行，不作已完成声明。