嘿 HN，我们是 Ismaeel、Eren、Yafet 和 Nikodem。我们创建了 Expanse (https://expanse.sh/) 以提高运行调度程序/编排器（如 Kubernetes 和 SLURM）的 HPC/GPU 集群的有效容量。我们读取源代码、作业提交脚本以及工作负载即将运行的硬件，以预测该作业实际上需要什么，提前在集群看到之前。我们还标记我们认为即将发生的失败，并提供研究人员可以自己应用的逐行优化。问题在于：数据中心的有效利用率大约在 30% 到 40% 之间。用户请求的资源往往超过实际需要，因为不对称风险：过多请求不好，因为成本高并浪费其他人可以使用的容量，而请求不足则会中断您的作业，导致您失去几天的工作。因此，每个人的请求量通常是实际需求的两到三倍。我们测量了一个国家级HPC集群一个月的情况，从 122,000 个作业内，59% 的计算资源被浪费。在同样硬件的按需云费用中，这大约是一个集群一个月浪费的 850 万美元。大规模计算行业（如量化基金、AI 实验室和制造业）也有类似的模式。我们四个曾在最大量化基金和 HPC 设施中运行 HPC 和 GPU 训练工作负载。Ismaeel 曾在 Adrian Jackson 指导下在 EPCC（爱丁堡并行计算中心，英国国家 HPC 站点）做研究，他构建了第一个多模态 HPC 资源预测器：一个模型可以处理作业源代码、提交脚本、硬件遥测和集群元数据，以确定实际需要多少计算。在 EPCC 自身集群的真实工作负载数据集上，它的得分比任何其他基线高 34%，并在相同预测任务上超越了前沿通用 LLM，表现约为其 8 倍。这些结果使我们相信这个问题是可以通过软件解决的。Expanse 安装在每个节点上，连接到 SLURM（或 K8s 调度器）。它获取您集群的实时硬件遥测（DCGM、CUPTI、Cgroups、网络/IO 监控），创建硬件性能的自定义嵌入。我们扫描即将通过 SLURM/K8s 提交的任何工作负载（集成到作业的生命周期中，您不需要改变提交方式），并将这些数据输入我们的深度学习模型，以在提交时为研究人员提供准确的资源建议、故障检测和优化建议。我们微调的特定集群模型随着您运行更多工作负载而变得更加精准。我们的模型训练时优先考虑过度配置而非不足配置，以避免作业崩溃后的不对称后果。我们还提供不确定性估计和 p90 值，以便用户选择他们的风险承受能力。我们为集群用户提供三项功能：(1) 提交时的资源预测。我们预测作业实际需要的 GPU VRAM、利用率、内存、CPU 和墙面时间，并给出置信区间。基于这些预测，我们还提供 OOM 和其他内存相关问题的失败预测，以及逐行代码优化建议，以提高作业在硬件上的利用率。(2) 实时可观测性。作业运行时，我们通过仪表板展示我们收集的遥测数据，直观地显示硬件上的状态以及您的工作负载在代码堆栈分析中的位置。我们动态分析工作负载，实现低单一数字开销，同时保持信息丰富。(3) 故障诊断。如果工作负载失败，我们收集的所有数据和堆栈分析以及硬件遥测进行关联分析，以提供面向解决方案的日志。这些是一两行日志，告诉您作业失败时发生了什么、原因和如何通过逐行代码建议进行修复。我们的方法与众不同：大多数集群的最先进技术要么依赖于来自 sacct（SLURM 会计数据库）的每用户历史平均值；手写规则/启发式；或最前沿的 LLM 编程代理。对于来自 sacct 的每用户历史平均值，一旦提交新的工作负载类型或进行代码级更改，模型便会变得极其不准确。对于 LLM 基线，我们向其提供了正在运行的工作负载的提交脚本和源代码，并赋予其在集群中的全能力，但它的表现相当糟糕。我们基于当时的最先进的技术（Gemini 3.5 pro、Claude Opus 4.8、GPT 5.5、Codex 5.3）对 Expanse 进行了基准测试，并以 8 倍的优势超越了它们。您可能会想，随着这些模型的扩展和改进，它们可能在这个任务上超越我们；然而我们没有看到模型大小或迭代与准确性改进之间的相关性。Claude Haiku 在许多工作负载上实际上表现优于 Opus，模型的早期版本往往有相同甚至稍好的准确性。即使是针对编码的特定模型，如 Codex 5.3 的表现也不尽如人意。