Launch HN: Expanse (YC P26) – 解锁闲置的GPU算力

<p>嘿，HN，我们是 Ismaeel、Eren、Yafet 和 Nikodem。我们建立了 Expanse（<a href="https://expanse.sh/">https://expanse.sh/</a>），旨在提高运行 K8s 和 SLURM 等调度器/编排器的 HPC/GPU 集群的有效容量。我们通过阅读源代码、作业提交脚本以及工作负载即将运行的硬件信息，在集群看到作业之前预测其实际需求。我们还会标记我们认为即将发生的故障，并展示研究人员可以自行应用的行级优化建议。</p><p>问题：数据中心的实际利用率大约只有30%到40%。用户请求的资源比实际需要的多，这是因为风险不对称：过度请求虽然不好，因为它成本高昂且浪费了本可以被其他人使用的算力，但请求不足会导致作业在运行中途失败，让你损失数天的工作成果。因此，每个人都会过度请求两到三倍的资源。</p><p>我们曾在一个国家级HPC集群上测量了一个月，在12.2万个作业中，59%的计算被浪费了。按照相同硬件的按需云服务价格计算，这意味着该集群一个月内浪费了大约850万美元的计算资源。这种模式在大规模计算行业中也类似，如量化基金、AI实验室和制造业。</p><p>我们四人曾在最大的量化基金和HPC设施中运行HPC和GPU训练工作负载。Ismaeel在EPCC（爱丁堡并行计算中心，英国国家级HPC站点）跟随Adrian Jackson进行研究，期间构建了首个多模态HPC资源预测器：该模型摄入作业源代码、提交脚本、硬件遥测和集群元数据，以估算实际所需计算量。在EPCC自有集群的真实工作负载数据集上，其表现比任何其他基线高出34%，而且在同一预测任务上，性能大约是前沿通用LLM（经过提示）的8倍。这些结果让我们相信，这个问题可以通过软件解决。</p><p>Expanse 会安装在每个节点上，并接入 SLURM（或 K8s 调度器）。它会实时采集集群的硬件遥测数据（DCGM、CUPTI、Cgroups、网络/IO监控），从而为你的硬件性能创建自定义嵌入。我们会扫描即将通过 SLURM/K8s 提交的所有工作负载（嵌入作业的生命周期，因此你无需更改提交方式），然后将这些信息输入我们的深度学习模型，在提交时向研究人员提供准确的资源推荐、故障检测和优化建议。我们会微调特定于集群的模型，随着你运行更多工作负载，这些模型会变得越来越精准。由于作业崩溃的后果不对称，我们的模型被训练为过度配置而非配置不足。我们还提供不确定性估计和p90值，让用户可以选择自己的风险承受能力。</p><p>我们向集群用户提供三种能力：</p><p>(1) 提交时的资源预测。我们预测作业实际所需的GPU显存、利用率、内存、CPU和运行时间，并提供置信区间。基于这些预测，我们还能展示OOM及其他内存相关问题的故障预测，以及提高作业在硬件上利用率的代码行级优化建议。</p><p>(2) 实时可观测性。在作业运行时，我们通过仪表盘展示正在采集的遥测数据，直观呈现硬件状态以及工作负载在代码栈分析中的位置。我们动态分析工作负载，在保持信息丰富的同时实现低个位数的开销。</p><p>(3) 故障诊断。如果工作负载失败，我们会利用收集的所有数据，对堆栈分析和硬件遥测进行关联分析，展示面向解决方案的日志。这些日志只有一两行，不仅告诉你作业失败时发生了什么，还会说明原因以及如何通过代码行级建议进行修复。</p><p>我们的方法有何不同：目前大多数集群的现有技术要么是使用 sacct（SLURM 数据库）中每个用户的历史平均值；要么是手写规则/启发式策略；或者是前沿 LLM 编码代理。对于 sacct 中每个用户的历史平均值，一旦集群中提交了新类型的工作负载或代码级别发生变化，模型就会变得极不准确。对于 LLM 基线，我们向它们提供了所运行工作负载的提交脚本和源代码，并赋予了它们在集群中编码工具的完整能力，但它们的表现相当差。我们将 Expanse 与当时的现有技术（Gemini 3.5 pro、Claude Opus 4.8、GPT 5.5、Codex 5.3）进行基准测试，结果比它们高出 8 倍。</p><p>你可能会想，随着这些模型规模扩大和性能提升，它们可能会在这个任务上击败我们；然而，我们没有看到模型大小或迭代次数与准确率提升之间存在相关性。实际上，Claude Haiku 在很多工作负载上的表现甚至优于 Opus，而之前迭代的模型准确率也保持相同甚至略有提升。即使是专门的代码模型，如 Codex 5.3，表现也很差（准确率与 GPT5.5 相当）。这些模型在真空中推理，缺乏对源代码（理解底层数据流和计算模式）以及硬件遥测和拓扑（理解集群性能模式）等多模态输入的原生支持，因此无法准确预测工作负载所需的资源。此外，Expanse 会持续更新其内部模型，确保随着集群上运行更多工作负载，预测越来越准确，从而能够很好地适应新硬件或工作负载模式的变化。LLM 非常擅长编写代码和超参数搜索，但它们需要 Expanse 来完成自动研究的完整智能体循环。我们的工具非常容易集成到这些智能体中，我们已经使 CLI 工具对 LLM 友好。有关 LLM 评估的更多详情，请查看：<a href="https://x.com/ismaeel_bashir_/status/2059683849404383283" rel="nofollow">https://x.com/ismaeel_bashir_/status/2059683849404383283</a></p><p>我们目前正在以付费试点的方式接入客户。定价按集群确定。我们提供两周的测量窗口，期间我们会安装、采集并向数据中心运营商报告可回收的算力，随后在一个部门进行付费试点部署，收取固定月费，除非范围扩大，否则以相同价格续约。</p><p>如果你运营着 HPC/GPU 集群（SLURM 或 K8s，100+ GPU），我们很乐意交流。我们会在集群的一部分安装一周，发送一份关于可回收算力的书面报告，然后由你决定是否继续。如果你尝试过类似方案但效果不佳，我们非常想听听原因。另外，如果你希望预测的故障模式在本帖中没有提及，请在本帖中留言，我们会回复说明模型是否已能捕获，或者需要添加什么才能实现。</p><p>我从没想过自己会站在 launch HN 的对面 :)。即使你不运营集群，我们也欢迎你的反馈。对我们方法的任何想法、你在集群上运行工作负载的经验，甚至你认为我们错在哪里——我们都乐于倾听。</p><p>Tally Ho!</p>