最新

Prela 是一种基于塔尔斯基关系代数的嵌入式查询语言。其查询简洁、清晰且快速。它通过浅层嵌入到宿主编程语言中实现：Prela 运算符是宿主中的常规函数。该实现遵循 continuation-passing style，可编译为高效的列式执行。

各位 HN 的朋友们，我们是 Ismaeel、Eren、Yafet 和 Nikodem。我们开发了 Expanse (<a href="https:&#x2F;&#x2F;expanse.sh&#x2F;">https:&#x2F;&#x2F;expanse.sh&#x2F;</a>)，旨在提高您运行 Kubernetes 和 SLURM 等调度器/编排器的 HPC/GPU 集群的有效容量。我们读取源代码、作业提交脚本以及工作负载即将运行的硬件，以便在集群看到作业之前预测其实际需求。我们还会标记我们认为即将发生的故障，并提供研究人员可以自行应用的行级优化建议。 问题所在：数据中心的有效利用率约为 30% 至 40%。用户请求的资源通常比实际需要的要多，这是因为风险不对称：过度请求虽然成本高昂且浪费了其他人可以使用的容量，但请求不足会导致作业在运行过程中夭折，并损失数天的工作。因此，每个人都会过度请求两到三倍的资源。 我们对一个国家级 HPC 集群进行了为期一个月的测量，在 122,000 个作业中，有 59% 的计算资源被浪费了。按照相同硬件的按需云费率计算，这相当于一个月内一个集群浪费了约 850 万美元的计算资源。在大型计算行业，如量化基金、AI 实验室和制造业，也存在类似的模式。 我们四人曾在最大的量化基金和 HPC 设施中运行 HPC 和 GPU 训练工作负载。Ismaeel 在 EPCC（爱丁堡并行计算中心，英国国家 HPC 中心）的 Adrian Jackson 教授指导下进行研究，他构建了第一个多模态 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 基线，我们向其提供了提交脚本和正在运行的工作负载的源代码，并赋予了其在集群中进行编码的全部能力，但其表现相当糟糕。我们将 Expanse 与当时最先进的模型（Gemini 3.5 pro、Claude Opus 4.8、GPT 5.5、Codex 5.3）进行了基准测试，结果显示我们的性能比它们高出 8 倍。 您可能会想，随着这些模型规模的扩大和性能的提升，它们可能会在这一任务上超越我们；然而，我们没有发现模型规模或迭代次数与准确性提高之间存在相关性。Claude Haiku 在许多工作负载上的表现实际上优于 Opus，而早期版本的模型也具有相同的，甚至略好的准确性。即使是像 Codex 5.3 这样的编码专用模型，表现也相当糟糕（准确性与 GPT5.5 相当）。这些模型是在真空中进行推理的，缺乏对模态输入（如源代码，以理解底层数据流和计算模式）以及硬件遥测和拓扑（以理解集群的性能模式）的原生支持，因此它们无法准确预测工作负载所需的资源。此外，Expanse 会持续更新其内部模型，以确保随着更多工作负载在您的集群上运行，我们的预测会越来越准确，这使其非常适合应对新硬件或工作负载模式的变化。LLM 非常擅长编写代码和进行超参数搜索，但它们需要 Expanse 来完成完整的自主循环以实现自动研究。将我们的工具集成到这些代理中非常容易，我们已将 CLI 工具设计为 LLM 友好型。有关我们 LLM 评估的更多详细信息，请访问：<a href="https:&#x2F;&#x2F;x.com&#x2F;ismaeel_bashir_&#x2F;status&#x2F;2059683849404383283" rel="nofollow">https:&#x2F;&#x2F;x.com&#x2F;ismaeel_bashir_&#x2F;status&#x2F;2059683849404383283</a> 我们目前正在为客户提供付费试点项目。定价按集群确定。我们提供为期两周的测量窗口，在此期间我们进行安装、数据摄取，并向数据中心运营商报告可恢复的容量，然后在一个部门进行付费试点部署，收取固定的月费，除非范围扩大，否则将按相同费率续订。 如果您运行 HPC/GPU 集群（SLURM 或 K8s，100+ GPU），我们非常乐意与您交流。我们将在您集群的一部分进行为期一周的安装，发送一份关于可恢复容量的书面报告，然后由您决定是否继续。如果您尝试过类似的方法但效果不佳，我们非常希望了解原因。如果您想预测的某种故障模式在本文中未提及，请在此帖中回复，我们将告知您模型是否已涵盖该情况，或需要进行哪些更改才能添加。 我从未想过自己会成为 HN 发布的一方！即使您不运行集群，我们也仍然希望听到您的声音。对于我们的方法、您在集群上运行工作负载的经验，或者您认为我们有任何错误的地方，我们都非常乐意听取您的意见。 祝好！