数据中心里的大语言模型开发究竟长什么样

一、这组 trace 回答了什么

这是一篇 workload characterization（工作负载刻画）研究。它不设计理论最优调度算法，而是回答数据中心用于开发大语言模型后的实际问题：队列里有哪些作业，它们申请多少资源、运行多久、为什么等待、硬件忙不忙，失败又如何造成损失。作者分析上海人工智能实验室 Acme 数据中心的 Seren 与 Kalos 两个 LLM 专用集群，材料包括 2023 年 3 月至 8 月连续六个月的调度记录、硬件监控、运行日志和细粒度 profiling。两个集群合计 4,704 张 A100-SXM 80GB GPU，trace 约有 109 万个 CPU/GPU 作业。

Trace 显示出几组同时成立的事实。队列中多数是短小的评测或开发作业，GPU 时间却主要由少数超大预训练作业消耗。粗粒度 GPU utilization 接近满载时，SM、CPU、主存和网络并没有同步饱和。评测作业申请的 GPU 少、运行短，却会因预训练配额预留而等待最久。脚本错误更频繁但通常很早退出；代价更高的是数百张 GPU 已运行很久后出现的基础设施故障。论文据此实现了预训练容错和评测解耦调度两个系统，没有提出统一的 workload 预测模型或所谓“Acme 调度算法”。

因此，读这篇论文要保持三层分离：事实层是 trace 中测到的分布；解释层是作者结合集群政策和运行经验给出的原因；设计层是由事实启发的两个系统机制。后文所有数字都按这三层展开，并明确哪些能外推、哪些只能说明 Acme 在该时段的情况。

二、前置概念：LLM 开发不是一个训练作业

传统集群 trace 常把一个作业抽象成“提交—排队—运行—结束”，并按 GPU 数与持续时间分类。LLM 开发仍有这些事件，却多了一条有反馈环的流水线。研究者先做数据准备和小规模实验，再进行大规模预训练；模型训练期间持续保存 checkpoint、观察 loss，并周期性触发几十个数据集上的离线评测；之后还可能做监督微调等后训练工作。评测反馈又会导致用户调参数、回滚 checkpoint、暂停甚至取消训练。因此，调度器看到的多个 job，可能只是同一个逻辑模型开发任务的不同阶段或一次故障后的重新提交。

论文把工作负载分为 pretraining、evaluation、SFT 和其他几类。预训练通常请求超过 100 张 GPU，生命周期长、同步紧密，故障会使整个并行作业停下；评测通常少于 4 张 GPU，却会对约 60 个数据集并行提交大量 trial；SFT 与其他开发、调试作业又有不同规模。这里的 evaluation 或 inference 主要是离线模型评测，不是面向互联网请求的在线 serving。因而本文不能回答首 token 延迟、逐 token 延迟、请求到达率或 KV cache 命中率。

还要区分三个时间量。提交时刻记为 t_submit，真正得到资源的启动时刻为 t_start，结束时刻为 t_end。排队延迟可写为 q = t_start − t_submit，运行时长为 d = t_end − t_start；论文的作业时长比较排除了排队时间。若作业申请 g 张 GPU，则资源消耗口径是 GPU time = g × d。这不是实际浮点运算量，而是“分配卡数乘占用时间”；即使 GPU 在等待 I/O，这段时间仍计入 GPU time。

三、数据来源：两个集群、六个月、四类证据

观测窗口为 2023 年 3 月至 8 月。Seren 有 286 个节点、2,288 张 A100-SXM 80GB；Kalos 有 302 个节点、2,416 张同型 GPU，总计 588 个节点、4,704 张 GPU。每节点 8 张 GPU、128 个 CPU 线程。Kalos 每节点配 2TB 主存与 5 条 200Gb/s InfiniBand 链路，其中一条用于存储。Acme 使用全 NVMe 共享并行文件系统。Seren 的调度建立在 Slurm 上，Kalos 建立在 Kubernetes 上；为大规模预训练提供资源隔离和配额预留，同时允许 best-effort 作业填充空余资源。

作业数量来自调度器数据库：Seren 有 368K 个 CPU 作业和 664K 个 GPU 作业，Kalos 有 42K 个 CPU 作业和 20K 个 GPU 作业，合计约 1.09M。数量上 Seren 占绝大部分，但这不代表它消耗的 GPU 时间也以相同比例占优；作业数和资源量必须分别统计。论文与旧 trace 的比较对象包括 Philly、Helios 和 PAI，但 Acme 的硬件代际、用户群、模型结构、调度政策与观测年份均不同，所以横向比较是描述差异，不是受控实验。

四类数据源互相补足。第一是 Job Log：包含提交、开始、结束时间，completed、canceled、failed 等最终状态，CPU/GPU/内存请求量、工作目录等字段。第二是 Hardware Monitor Data：Prometheus 提供 CPU、主存和网络指标，NVIDIA DCGM 提供 GPU 指标，IPMI 提供功耗；统一采样间隔为 15 秒。第三是框架 Runtime Log，即 stdout/stderr，用于从错误文本判断失败类型。第四是代表性作业的 Profiling Data，用更细时间尺度解释聚合监控看不见的计算、通信、加载和空闲阶段。没有任何单一来源能独立支持全文结论：作业日志说明“申请了什么”，监控说明“资源是否活跃”，运行日志说明“为何失败”，profiling 说明“时间花在哪里”。

四、Trace schema、派生指标与统计口径

可以把每个作业记录理解为一行主表：作业标识、用户或工作目录、集群、提交/启动/结束时间、最终状态、请求 CPU 数、请求 GPU 数和请求内存。以作业标识、节点和时间区间为键，再连接 15 秒采样的 CPU、host memory、网络、GPU utilization、SM activity、显存和功耗时序；失败分析则把主表连接 stdout/stderr，并对少数代表性训练或评测连接 profiler 时间线。论文并未声称公开 trace 包含所有内部字段，也没有给出关系数据库 DDL；这里的 schema 是对论文明确列出的字段和连接关系的结构化复述，不额外发明列。

核心派生量包括：排队延迟 q、运行时长 d、GPU time g×d、某类别作业数占比、某类别 GPU time 占比，以及硬件指标的经验累积分布。失败表还关心失败次数、失败作业平均 GPU 数、故障前平均运行时间、重启时间、重启时间相对故障前运行时间的比例，以及某故障类别占全部失败 GPU time 的份额。于是“频率高”与“代价高”不再等价。

功耗与碳排放也要看口径。PUE 表示整个数据中心总能耗与 IT 设备能耗之比；Acme 的 PUE 为 1.25，2022 年无碳能源比例约 30.61%，使用的碳排放强度为 0.478 tCO₂e/MWh。Seren 在 2023 年 5 月依据节点级功耗估算消耗约 673MWh，对应有效排放 321.7 tCO₂e。这里报告的是集群月份估计，不是单个模型的生命周期碳核算，也不能把 321.7 直接归因给某次训练。

两个容易混淆的 GPU 指标必须分开。论文中的 GPU utilization 是采样窗口内 GPU 是否有 kernel 活动一类的粗粒度忙碌指标，而 SM activity 更靠近流式多处理器活跃程度。Seren/Kalos 的 GPU utilization 中位数可达 97%/99%，同时 SM activity 中位数约 40%，两者并不矛盾，也不能任选一个称作“实际算力利用率”。显存占用同样只是容量压力，不代表算术吞吐。

五、数据清洗、分类与统计流程如何理解

论文没有给出一段可逐行照抄的 ETL 程序，因此复现时不能假装知道它未披露的去重阈值或缺失值填补方法。能从材料中确定的流程是：先从两个调度后端统一抽取作业时间、状态与请求资源；再以运行区间聚合 15 秒硬件采样；按开发阶段区分 pretraining、evaluation、SFT 与其他；随后分别以“作业数”和“GPU time”加权画分布，避免短小作业在数量上淹没大作业；故障研究则另抽取具备运行日志的任务，解析错误并归入脚本、框架、CUDA/NVLink、网络、节点等类别；最后选代表性作业做细粒度 profiling 来解释宏观分布。

统计上主要使用 CDF、比例、均值/中位数和时间线，而不是因果回归。作业时长 CDF 的每个样本是一项 GPU 作业；GPU time CDF 则按 g×d观察资源集中度；利用率 CDF 来自监控样本或相应聚合口径；profiling 是个案剖面，不应当当成全 trace 的平均。对失败，作者分析 Kalos 的 32,500 个任务日志，其中 96.3% 为 inference/evaluation、2.0% 为 pretraining，并另分析 Seren 的 675 个预训练任务。这一子集构成与全体作业不同，所以表 3 的故障比例不能直接当作所有 109 万个作业的全局故障率。

分类本身也带有运行环境语义。比如 canceled 只表示最终状态是用户或系统取消，不等于硬件正常；附录指出，大规模预训练可能因 loss spike 调参而被用户暂停，也可能因基础设施问题卡住却没有抛错，直到人工巡检才取消。failed 又常由启动阶段的脚本错误造成。把两者都简单视为“浪费”会丢失原因，把 completed 视为“全程有效计算”也同样过度。因此本文将状态、故障类别和资源损失分别报告。

六、研究问题与证据链

论文依次处理五类问题。第一，LLM 工作负载与旧的任务专用 DL trace 在时长、规模和利用率上有何不同？方法是与 Philly、Helios、PAI 的公开统计并列比较。第二，LLM 开发阶段之间怎样分配作业数和 GPU time？方法是类别分组与请求规模、持续时间、排队时间的条件分布。第三，GPU、CPU、主存、网络与电力是否均衡？方法是 15 秒监控的 CDF、节点功耗拆分和代表性训练 profiling。第四，预训练与评测内部究竟在哪些阶段停顿？方法是 123B 预训练时间线以及 7B HumanEval 评测时间线。第五，失败发生在哪、损失多少、恢复为何慢？方法是运行日志分类与故障前时间、作业规模、恢复时间的联合统计。

分析方法的价值在于三角验证。例如，评测作业排队久由调度日志发现；profiling 又显示评测只在部分阶段需要 GPU；配额政策解释了小作业为何反而缺资源；于是设计层才提出分离 CPU/GPU 阶段。再如，CPU 主存总体富余由监控发现，checkpoint 很慢由训练时间线发现，基础设施故障代价高由日志统计发现；三者共同支持“先写 host memory、后台持久化、自动诊断恢复”的容错方案。任何一条单独证据都不足以推出完整系统。

这也说明论文没有做什么：没有用历史 trace 训练作业时长预测器，没有给出到达过程的概率模型，没有证明某调度策略最优，没有通过随机对照改变配额政策。评测调度只使用各数据集历史运行时长“相对稳定”这一经验先验做排序和均衡；它是部署机制中的估计输入，不是论文主张的通用预测模型。

七、发现一：短作业占数量，超大作业占算力

Seren 与 Kalos 的 GPU 作业运行时长中位数都是 2 分钟，比 Philly、Helios、PAI 的中位数短 1.7～7.2 倍；按平均时长比较，较早的 trace 比 Acme 长 2.7～12.8 倍，其中 2017 年 Philly 的平均值是 2023 年 Acme 的 12.8 倍。这反驳了“LLM 集群里的每个作业都持续数天”的直觉，但不反驳“大模型预训练很长”。总体中位数低，是因为队列混入大量短评测、调试，以及约 40% 很早失败的作业；硬件演进和用户申请更多 GPU 也会缩短相同工作量的墙钟时间。

请求规模和资源消耗呈极强长尾。各比较集群中，请求超过 8 张 GPU 的作业按数量都不足 7%；但在 Kalos，请求至少 256 张 GPU 的大作业贡献超过 96% GPU time。相反，单卡作业在两个 Acme 集群贡献都不足 2% GPU time。举例说，假设队列里有一千个单卡两分钟评测和一个 2,048 卡、十小时训练：前者数量是一千，GPU time 合计却只有 2,000 卡分钟；后者一个作业就是 1,228,800 卡分钟。这个例子只是用公式解释偏斜，不是论文 trace 的新增观测。

按阶段看反转更明显。Kalos 的评测占 92.9% 作业数，却只占 0.8% GPU time；预训练只占 3.2% 作业数，却占 94.0% GPU time。Seren 中预训练占 0.9% 作业数和 69.5% GPU time，评测占 64.9% 作业数。评测通常少于 4 张 GPU，预训练通常超过 100 张。由此得到第一个调度含义：不能用“平均作业”设计容量，也不能只优化吞吐作业数；预训练决定成本，评测决定队列事件和反馈速度。

八、发现二：小评测等得久，最终状态也会骗人

两个集群中少于 5% 的作业能连续运行超过一天。这里并非所有训练都在一天内完成，而是长逻辑训练会因失败、调参或恢复被切成多次提交。更反直觉的是，资源最小、运行最短的评测类别排队时间最长。原因不是评测天然难放置，而是 Acme 为大规模预训练做配额预留和隔离；评测通常低优先级批量提交，只能使用有限的空余或 best-effort 资源。因此“卡数越多越难排、等待越长”的旧 trace 经验在这里失效。

这项结果的证据边界很重要。观测到的是“工作负载结构 × Acme 配额政策”的联合结果。如果另一集群为评测保留专门分区、允许抢占训练，或不对预训练预留资源，排序可能不同。所以论文支持的设计问题是：怎样同时保障预训练连续性与评测反馈时限；它不支持把“评测总是等待最久”写成普遍定律。

附录的最终状态给出另一种偏斜：最终完成的作业只消耗约 20%～30% GPU 资源；约 40% 作业失败，却只用约 10% GPU 资源，说明很多失败发生在启动早期；约 7% canceled 作业反而占超过 60% GPU 资源，因为其中包含大量长时间预训练。取消可能是达到目标、发现超参数不佳、loss spike 后暂停调参，也可能是基础设施问题让作业无报错卡死后被人工终止。调度器若只优化“失败次数”，会错过 canceled 长作业中的巨大资源损失。

九、发现三：GPU 看起来很忙，整机并不均衡

Seren 与 Kalos 的 GPU utilization 中位数分别为 97% 和 99%，高于 Philly 的 48% 与 PAI 的 4%。Kalos 中一半 GPU 使用超过 75% 的 80GB 显存，即超过 60GB。乍看之下，旧 DL 集群常见的低 GPU 利用问题似乎消失了。然而更细的 DCGM 指标显示，两集群 SM activity 中位数约 40%。GPU 经常有 kernel 活动，不等于每个 SM 在每个周期都做有效矩阵运算；通信、同步、内存访问和 kernel 间隙仍会留下优化空间。

配套资源明显更松。CPU 一般低负载，host memory 使用率低于 50%。附录给出的一个代表性节点只使用 1TB 中的 123GB 活跃物理内存；其中分布式文件系统客户端与数据/元数据缓存占 45.3GB，TensorBoard 占 6.5GB，Prometheus、驱动、Slurm daemon 等剩余系统进程合计约 0.6GB。作者同时提醒，Megatron-LM 若加载完整数据集元数据，dataloader 内存可能显著更大，而异步 checkpoint 所需内存取决于模型与训练配置，所以 123GB 不是所有预训练节点的固定值。

网络也不是持续饱和。Seren 的 InfiniBand NIC 超过 60% 时间处于空闲，活跃时带宽也很少超过峰值 25%。这并不证明网络不重要：同步训练会把通信集中成短促阶段，平均或 CDF 可掩盖关键路径阻塞；MoE 的 all-to-all 更会改变瓶颈。正确含义是资源需求具有阶段性，不能以“GPU utilization 99%”推断 CPU、内存、网络均已充分利用，也不能据此断定简单 GPU sharing 一定安全。密集预训练显存已很高，同卡 packing 的容量和干扰空间可能有限；富余 host memory 反而适合承担 checkpoint 缓冲。

十、发现四：功耗、预训练时间线与并行策略

约 30% GPU 处于空闲状态时仍各消耗约 60W。Seren 与 Kalos 分别有 22.1% 和 12.5% 的 GPU 功耗样本超过 A100 的 400W TDP，少数达到 600W。Seren 的 GPU 服务器平均功耗约是 CPU 服务器的 5 倍；在 GPU 服务器内，GPU 占 65.7%，CPU 占 11.2%，电源转换损耗占 9.6%。这组数字说明功率规划不能只用 400W×GPU 数的静态估算，也说明消除 idle GPU 即使没有增加吞吐，也可能减少显著基线能耗。

作者进一步剖析 123B dense 模型在 2,048 张 GPU 上的预训练。InternEvo V1 使用 3D parallelism，V2 使用 hierarchical ZeRO；V2 的 profiling 时间线空闲区间更少，整体约快 16%。在 1,024 GPU 的附录实验中出现相似模式，说明该现象不只存在于单一 2,048 卡截图。但它仍是 InternEvo、给定模型、拓扑和配置的比较，不能外推成“hierarchical ZeRO 在任意集群固定加速 16%”。

附录还在 Seren 用官方配置对 Mistral 7B MoE 做 1,024 GPU profiling。MoE 的 GPU utilization 明显低于 dense 模型，作者归因于频繁 all-to-all 需要更好的跨节点通信，而该服务器只有单条 IB NIC 难以有效承载。InternEvo 对 MoE 也仍在开发。这个结果恰好限制了主体结论：dense decoder-only 模型的高 GPU utilization 不能直接代表 MoE；硬件网络拓扑和并行结构共同决定利用率。

十一、发现五：一次评测其实是 I/O—GPU—CPU 流水线

作者用 7B 模型执行 HumanEval 的时间线说明，evaluation job 并不是连续 GPU inference。真正推理开始前，模型加载和数据预处理已占总时长 29.5%；GPU 生成代码后，还要执行程序正确性测试，此时 GPU 空闲 42 秒，占总 GPU time 的 19.0%。换言之，只有大约一半时间真正用于 GPU inference。若一个容器从头到尾占卡，远端模型读取、tokenization 和 CPU-only metric 都会把 GPU 锁住。

约 60 个评测数据集还会并发加载同一个 checkpoint。单节点上，单卡 trial 从 1 个增加到 8 个时，受 25Gb/s storage NIC 限制，平均模型加载速度显著下降；把并发规模从 8 扩到 256 张 GPU 后，单 trial 加载速度趋于稳定。二者不矛盾：瓶颈首先发生在每节点共享的存储入口，跨更多节点后每节点仍承受类似局部上限。于是“给评测更多 GPU”未必线性缩短反馈时间，可能先放大共享存储争用。

这个例子把调度单位从 job 改成阶段 DAG：远端 checkpoint 到节点内存是 I/O precursor；节点内存经 PCIe 到 GPU 并生成结果是 GPU 阶段；HumanEval/MBPP 的代码执行和指标计算是 CPU 阶段。只有中间阶段必须占 GPU。只要阶段间结果可持久化，调度器就可以在 CPU metric 运行时释放卡，让下一 trial 推理，从而把异构资源并行起来。

十二、发现六：故障频率不等于故障代价

失败来源跨越用户脚本、框架、GPU/CUDA、NVLink、网络和节点。许多配置或脚本错误在启动初期迅速退出，推低总体时长中位数，却没有消耗太多 GPU time。相反，基础设施错误次数较少，但往往击中已经运行很久、横跨数百张卡的同步预训练；任何一个关键节点出问题都可能令全作业停止。衡量优先级至少要同时看事件次数 n、平均规模 g、故障前时间 t_fail、恢复时间 t_restart 和失败 GPU time 份额，而不能只按错误日志条数排序。

表 3 的具体数字很有代表性：NVLink error 记录 54 次，平均涉及 800 张 GPU，占所列失败 GPU time 的 30.25%；CUDA error 21 次，平均 847 张 GPU，占 15.77%；node failure 只有 16 次，却平均涉及 712 张 GPU，占 14.30%。Network error 的平均重启时间达到 592.1 分钟，相当于平均故障前运行时间的 107.74%。这意味着恢复过程本身可能比被丢弃的工作还久。

一个有用但不是论文正式命名的新算法的解释式是：单次故障暴露的资源量近似为 g × t_fail，若资源在诊断恢复期间仍不可用，还要关注 g × t_restart；按类别聚合则对事件求和。checkpoint 能回收多少训练进度还取决于保存间隔和最后健康 checkpoint。因此，调度与运维应该优先降低“高规模×晚发生×慢恢复”的尾部风险：快速识别坏节点、维护健康资源池、缩短重启，而不是只消灭最常见的早期语法错误。

附录还有一条具体排障经验：PyTorch dataloader 在 num_worker>0 时可能因 fork 的 copy-on-write 与 Python list 设计造成渐进内存泄漏，Dataloader Worker Killed 平均在任务启动 27 小时后出现；团队通过设 num_worker=0 并启用 dataloader 垃圾回收规避。它是特定实现经验，不应扩写成所有 dataloader 的通用定理。

十三、由观测到系统一：容错预训练

第一个部署方向由三条证据直接导出：基础设施故障损失大；checkpoint 本身可能形成长停顿；host memory 通常富余。系统因此由 checkpointing、diagnosis、recovery 三部分组成。异步 checkpoint 先把训练状态写入本机富余 host memory，让训练主线程尽快继续；独立后台线程再把 TB 级状态持久化到远端存储。这里缩短的是训练关键路径上的保存等待，不是让持久化数据凭空消失。若节点在后台写完前整体失效，保护能力仍受已完成持久化范围约束。

诊断流程面对的是数百 MB 日志。Log Agent 持续生成正则过滤规则，先压缩重复和无关内容；Failure Agent 对压缩日志做已有规则匹配与向量检索。规则无法覆盖时，系统调用 GPT-4 判断根因和可恢复性，并将人工确认的新模式写回规则库。作者还使用 self-consistency，让模型多次推理，再由另一个 LLM 对结果投票，减少日志过滤或判断错误。这里的 LLM 是诊断工作流组件，不意味着系统能形式化保证根因正确；高风险隔离仍需检测工具和规则验证。

恢复按故障类型采取不同动作。对 NVLink error，工具执行两轮 NCCL allgather：先把节点两两分组定位可疑组，再把可疑节点与正常节点重组测试，从而找出并隔离坏节点。对 loss spike，则回退到更早的健康 checkpoint，并跳过可疑数据 batch。系统自动从合适 checkpoint 重启训练。这是一套由规则、LLM 诊断、主动检测和故障专用处理器组成的恢复流程，没有用单一算法处理所有错误。

在 30 分钟 checkpoint interval 下，7B 与 123B 模型的异步 checkpoint 将 checkpoint 时间及其开销降低 3.6～58.7 倍。该测量不包含后台最终持久化时间，所以应解读为关键路径加速。诊断系统使人工干预约减少 90%，但作者明确说这不是严格评测，因为组件仍在持续改进。两个限定不能省略，否则会把工程观测包装成过强结论。

十四、由观测到系统二：评测解耦调度

第二个系统把批量 evaluation 拆成可分别调度的 trial 阶段。首先，trial coordinator 按节点提交 precursor job，只从远端存储加载一次模型到节点共享内存；同节点多个 GPU trial 再通过 PCIe 读取本地副本，避免约 60 个数据集重复冲击 storage NIC。其次，GPU 生成结束便释放 GPU，把程序测试等 metric computation 作为 CPU 作业运行。这样 I/O、GPU inference 与 CPU metric 可以在不同 trial 之间流水重叠。

调度侧利用一个受观测支持的先验：每个评测数据集的近似运行时长较稳定。数据集可合并到同一 trial 来摊薄模型加载，也可拆开大数据集并分离 metric。coordinator 按预计时长排序，再 round-robin 分配以平衡各 GPU 工作量；CPU metric 较长的 trial 优先启动，使其后处理能与后续 GPU 推理重叠。这是启发式的分解、排序和轮转，不是带最优性证明的通用调度算法。

代表性实验使用一个 7B 模型与 63 个数据集。单节点时 makespan 缩短 1.3 倍，四节点时缩短 1.8 倍。实验说明阶段解耦和局部模型共享能缩短这一配置的反馈周期，但规模只有一到四个节点、一个模型和一组数据集；它没有证明在任意存储网络、任意 metric 或大规模在线推理上保持相同倍数。

十五、预测、调度与容量规划的含义

对预测而言，trace 提示至少要做类别条件化。混合全体作业去拟合一个时长分布，会被大量两分钟评测和少量超长预训练同时扭曲；模型至少应知道开发阶段、请求 GPU 数、最终状态语义和是否为重启。逻辑训练跨多次 job，预测“单次 job 时长”也未必等于预测“模型达到下一反馈点的时间”。评测数据集历史 runtime 相对稳定，可用于 trial balancing；预训练则还需把故障风险、checkpoint interval 与恢复时延纳入完成时间。论文没有训练这些预测器，这些是数据对后续研究提出的变量需求。

对调度而言，资源数与优先级不能替代阶段语义。预训练主导 GPU time，需要连续大规模 gang 资源与低故障域风险；评测主导作业数和研究反馈，适合拆分为 I/O/GPU/CPU DAG，并可设反馈时限；CPU 与 host memory 不应机械地随 GPU 等比例绑死。频繁抢占大训练可能引入昂贵 checkpoint 与恢复，而简单同卡 packing 又受高显存占用和干扰约束。更合理的方向是联合资源预留、有限的评测快速通道、节点健康度、checkpoint 状态和阶段依赖。

对容量与运维而言，平均 GPU utilization 不是唯一目标。需要同时看 SM activity、显存、关键路径网络、存储入口、idle 功耗与故障域。高利用率训练仍可能被通信短峰限制；评测扩卡仍可能先撞 25Gb/s storage NIC；30% idle GPU 每张约 60W 仍有电力成本。运维优先级应以失败 GPU time 和恢复尾延迟排序，尤其关注 NVLink、CUDA、节点与网络，而非仅看 ticket 数。

十六、证据边界、局限与可执行复现协议

代表性边界。数据来自一个机构、两个专用集群、六个月；Slurm/Kubernetes、配额预留、用户习惯和 InternEvo 都带有本地性。主体是 7B 到 123B 以上的 decoder-only dense Transformer；MoE 只有 Mistral 7B、1,024 GPU 的附录 profiling。无线上 serving，不能推断请求级延迟与缓存行为；多模态、RLHF 和后来的长上下文工作负载没有同等深度数据。旧集群横向比较不是硬件和策略控制实验。

方法边界。15 秒监控会漏掉更短的 kernel、通信峰和瞬态故障；profiling 只覆盖代表性作业；故障日志子集不是全体作业的随机样本；错误分类依赖日志可见性，卡死但不报错可能进入 canceled。99% GPU utilization 与约 40% SM activity定义不同。碳排是 Seren 单月节点功耗估计，不是模型碳足迹。16%、3.6～58.7 倍、1.3/1.8 倍均是指定配置结果；90% 人工干预下降被作者标为非严格评测。

解释数字时的自检规则。看到百分比先问分母：92.9% 是 Kalos 的评测作业数比例，0.8% 才是其 GPU time 比例；看到时长先问是否包含排队，本文作业 duration 不包含；看到利用率先问采样工具和指标定义，GPU utilization、SM activity 与显存占比不可互换；看到倍数先问基线和计时边界，异步 checkpoint 不计后台最终持久化，评测 makespan 则计整批完成。看到失败统计还要问样本集：32,500 个 Kalos 日志任务与 675 个 Seren 预训练任务不是 109 万作业的等比例缩影。遵守这些规则，才能从同一组数字得到论文允许的结论，而不会把相关性写成因果、把局部实验写成普遍保证。

最小复现协议。第一，固定 2023-03 至 2023-08 窗口，分别抽取 Seren/Kalos 的 job 主表，保留提交、启动、结束、状态与资源请求，报告各表记录数和缺失值，不擅自填补。第二，用 q=t_start−t_submit、d=t_end−t_start、GPU time=g×d生成派生列，明确排除排队时间；分别按 job count 和 GPU time 画请求 GPU 数、时长、类别和最终状态分布。第三，按 job—node—time window 连接 Prometheus、DCGM、IPMI 的 15 秒样本，分别报告 GPU utilization、SM activity、显存、CPU、主存、网络与功耗，禁止互换定义。

第四，记录阶段分类规则及无法分类比例；对 pretraining、evaluation、SFT、其他分别报告规模、时长、排队和资源份额。第五，对有 stdout/stderr 的任务单独建立 failure 子集，公开子集构成；每种错误报告次数、平均 GPU 数、故障前时间、重启时间及失败 GPU time 份额，并人工抽样核验规则。第六，选择 123B dense 训练和 7B HumanEval 等代表案例保存细粒度时间线，明确个案不能替代全局分布。第七，复现系统实验时固定 checkpoint interval=30 分钟，分别计关键路径保存与后台持久化；评测固定 7B、63 数据集、一与四节点，报告 makespan 和存储并发。第八，把所有政策、硬件、软件版本和排除规则随结果发布；若无法获得内部字段，只复现公开 AcmeTrace 能支持的指标，并把不可复现项列为缺失，而不是猜测。

最终应把论文的贡献准确表述为：它用多源生产 trace 证明 LLM 数据中心的基本单位是开发阶段与反馈回路，并把资源偏斜、评测阶段空洞和高代价故障转成两个已部署工程方向。它提供的是设计依据与实测边界，不是一个包治所有集群的算法。读到这里，已经具备理解论文主要问题、数据、指标、方法、数字、系统含义和局限所需的完整信息；原文存档仅用于核对图表。