上海人工智能实验室的集群运行轨迹：失败也是模型开发的一部分

新华社这张实景照片摄于 2025 年 11 月，画面是安徽的淮海人工智能计算中心。Acme 集群经过匿名处理，论文也没有公布其照片；这幅影像呈现的是另一处设施，让中国模型开发工作负载背后的物理层清晰可见。[6]

模型发布通常会抹去自身的工作历程。公众看到一个检查点、一张 benchmark 成绩表，有时还会看到训练算力估算；队列、中止的作业、一次次评测、检查点写入与午夜的故障恢复，则从视野中消失。上海人工智能实验室在 2024 年 NSDI 大会上的演讲 《数据中心内大语言模型开发的特征分析》（Characterization of Large Language Model Development in the Datacenter），把这段缺失的中间过程带了回来。某个 InternLM 检查点能做什么，只是问题的一端；演讲把目光移向另一端：人们信任这个检查点之前，周围必须持续发生哪些工作。[1][2]

这场十七分钟的演讲，浓缩了实验室一座以 Acme 为匿名代称的数据中心从 2023 年 3 月至 8 月的六个月追踪记录。Seren 和 Kalos 两个集群共有 4,704 张 NVIDIA A100 80GB GPU，支持从 70 亿（7B）到 1230 亿（123B）参数规模的 InternLM 开发。研究人员考察了约 684,000 个 GPU 作业和 410,000 个 CPU 作业，将调度器元数据、硬件监控、运行日志与细粒度性能剖析汇集起来。[2][3] 这为观察中国基础模型所依赖的基础设施打开了一扇格外具体的窗口：眼前是一份运行记录，与产品发布时的宣称相距很远。

观看时，可以留意尺度如何切换。一次预训练会占用数百乃至数千张 GPU，提交到集群的大多数作业却很小。评测在 GPU 总时长里几乎看不见，却能决定开发者能否及时拿到有效反馈，并据此调整下一次运行。简单的用户错误数量很多，频率较低的基础设施故障却会毁掉更多已经积累的工作。演讲真正的论点正是从这些不对称关系中浮现：LLM 开发是一套反馈系统，它的质量取决于系统观测运行、经历失败、完成恢复并再次尝试的速度。[2][3]

大约 2:00 —— 分析对象转向整条开发流水线

开场的流水线幻灯片很容易被略过，却划定了全文最重要的范围。模型开发包括数据准备、预训练、对齐、评测和部署；Acme 研究考察服务上线前的各个阶段，并明确排除了部署工作负载。[1][2] 因此，这些追踪记录无法说明面向用户的延迟、推理批处理、缓存行为或生产需求。它们照见的是工作间，店面留在覆盖范围之外。

这条界线也能避免一种常见的过度解读。这是来自 2023 年 A100 时代、以仅解码器（decoder-only）Transformer 为主的工作负载记录，适用范围有明确的时间与架构边界，无法概括每一座中国 AI 集群。多模态模型、大规模强化学习、混合专家训练、国产加速器和推理密集型服务，都能产生不同的资源使用形态；论文也列出了其中几项限制。[2] 这份追踪记录的价值，在于把一个重要环境呈现得足够清楚，让后来的环境可以与之比较；Acme 只代表这一处环境，无法外推为整个国家的行业图景。

大约 4:00 —— “大模型作业”原来如此短暂

第一个视觉上的意外来自作业持续时间。Acme 两个集群的 GPU 作业持续时间中位数都只有两分钟。此前来自微软、商汤和阿里巴巴的三份深度学习追踪记录，平均作业持续时间是 Acme 的 2.7 至 12.8 倍。[2][3] 更快的硬件和单个作业使用更多 GPU 都产生了影响，工作内容的组成同样重要：其中有大量小型评测和调试尝试，作业未完成率约为 40%。[2]

这组比较只适合观察方向。不同年份、硬件世代、机构和工作负载组成混在其中，无法把它当作一项受控的数据中心质量 benchmark。撇开这层限制，调度方面的启示仍然成立：如果一座集群只按想象中持续数月的训练运行来设计，它就会与实际开发负载错位。集群还要处理密集涌来的短实验、初始化失败、探测任务和评测，同时给各类反馈保留通道，避免最重的作业垄断每一条有效的反馈通道。

大约 5:30 —— 作业数量与 GPU 时长描绘出两个世界

Kalos 把这种失衡呈现得十分鲜明。评测作业占 GPU 作业总数的 92.9%，却只占 GPU 总时长的 0.8%；预训练占 GPU 作业总数的 3.2%，却消耗 94.0% 的 GPU 总时长。[2][3] 在同一个集群里，规模最大的 5% 作业——即申请超过 256 张 GPU 的作业——占据了约 96% 的 GPU 时长。[2]

醒目的分布背后还有调度问题。实验室把大部分容量留给预训练，评测只能使用优先级较低的闲置资源。结果颇为反直觉：小型评测作业的排队时间最长。[2] 模型团队即使保证了昂贵训练任务的利用率，整体开发速度依然会慢下来，因为研究人员太晚才知道某个检查点究竟有所改进、发生退步，还是在他们关心的能力上失败。GPU 占用率与有效迭代速度属于两套指标。

大约 8:30 —— 评测显露出推理之外的开销

HumanEval 的性能剖析让这个问题更加清楚。在一次 7B 模型评测中，模型加载和数据处理占总耗时的 29.5%；合成程序的正确性测试又占 19%，这段时间里 GPU 处于空闲状态。真正用于 GPU 推理的时间只有约一半。[2][3] 虽然这项作业被归入模型评测，瓶颈却在存储、CPU 工作与调度器之间不断移动。

研究团队沿着这些分界拆开了处理流程。每个节点只从远程存储获取一次模型，随后经 PCIe 从本地加载；只使用 CPU 的指标计算与 GPU 推理解耦；各次试验则经过分批和排序，让已知工作量在多张 GPU 之间保持均衡。在一项覆盖 63 个数据集的代表性 7B 模型测试中，这套协调程序把总完成时间降至原来的约 1/1.3 和 1/1.8，分别对应单节点与四节点配置。[2] 实验范围很窄，这些数字只描述本次测试；其中仍有一条可复用的设计原则：稀缺加速器完成本环节后立即释放，反馈任务则纳入正式调度，享有明确的资源位置。

10:00 之后 —— 故障次数与故障代价是两回事

故障表对单纯统计事件次数作出了最有价值的修正。文件缺失、类型错误等脚本问题频繁出现，通常发生得早，使用的 GPU 也相对较少。基础设施故障出现次数较少，却往往来得更晚，波及规模大得多的作业。仅 54 次 NVLink 错误，就占归因于已分类故障的 GPU 损失时长约 30%；节点、CUDA、ECC 和网络故障还带来了更多集中的损失。[2]

40% 的作业未完成率涵盖多种原因，单凭这一比例无法推定集群硬件的可靠性；早期的用户错误和框架错误也计入其中。[2] 这些数据更能说明故障会波及多少工作：一项作业在数百张 GPU 上运行数小时后，罕见故障也会抹掉大量累计进度。因此，可靠性工程衡量故障时，资源占用与进度损失都要计入，工单数量只是其中一项。

临近结尾 —— 检查点成为主动运转的基础设施

实验室的恢复设计先把检查点状态移入主机内存；训练随即恢复，后台进程同时把这些状态持久化到存储中。论文报告称，在受测的 7B 和 123B 案例中，检查点开销降至原来的 1/3.6 到 1/58.7；论文也谨慎说明，异步测量没有计入之后的存储持久化时间。[2] 这一限定很重要：这项技术缩短的是训练暂停，后续存储开销依然存在。

诊断同样分为几层。规则处理已知错误特征；压缩日志与 LLM 辅助智能体帮助归类陌生故障；针对性测试隔离可疑节点；能够恢复的作业从完好检查点重新启动。[2] 作者估算，人工干预减少了约 90%，同时明确指出这是一项非严格估算，因为系统仍在变化之中。[2] 这样的运行结果足以启发一种设计；清楚交代限度，也避免把初步估算包装成营销承诺。

这份追踪记录改变了什么

AcmeTrace 的公开代码仓库提供经过匿名处理的作业、故障与硬件数据；除了幻灯片，读者还有底层数据可供检查。[4] 此后，实验室又介绍了范围广得多的研究议程；这份较早的追踪记录仍有价值，恰恰因为它捕捉了一种特定的开发形态，也公开了自身限制。[4][5]

放在 AI-China 报道中，值得追问的问题也随之改变。开放权重、benchmark 分数和加速器供应仍然重要。检查点之间那些不易被看见的时钟同样重要：评测多久排到队首，模型加载重复多少次，CPU 工作占住 GPU 配额多久，状态以什么频率保存。故障节点能否快速隔离，省去漫长的人工排查，也影响着反馈的速度。这些反馈循环运转得如何，最终会反映在模型上。演讲留下的长期启示是，基础设施既铺在模型研究脚下，也参与决定研究者如何认识模型。

cronfeed.work