ClusterMAX 3.0：行业标准 GPU 云评级系统回归

本帖包含付费订阅者的额外内容。升级以获得完整访问权限。

自从我们上一次重大发布ClusterMAX以来，8个月内，贪婪的投资者几乎已经没钱再存支票了。GPU供应已经降到零。与此同时，我们一直在努力让集群经历折磨。

几周前，我们用一些关于新云安全实践的R级轶事作为预告，引发了一位你可能听说过的新云客户的公益提示。

今天，我们终于在ClusterMAX 3.0中比以往更全面地全面介绍测试内容。这包括计算、网络、存储、编排、用户界面、监控、支持，以及你能想到的所有GPU云检查内容。

我们将解释谁在达成协议，谁的工程师努力工作，以及你应该协商谁的集群，才能配上一瓶阿司匹林。

废话不多说，看看ClusterMAX 3.0的领奖台：

结果（执行摘要）

YouTube总结视频和播客讨论即将推出！

ClusterMAX 3.0 首次亮相，全面回顾了新云行业，涵盖了 77 家供应商。
我们将市场视野扩大到323家，较原文中的209家、169家和124家有所增加。
作为这项研究的一部分，我们已经采访了200多名新云终端用户。
我们更新了我们的涵盖10个类别的详细标准列表，并更新我们对对Slurm、Kubernetes、独立机器、监控仪表盘和健康检查的期望.所有这些内容均在我们的网站上公开。我们鼓励供应商在开发产品时使用这些列表。我们仍然将这些列表视为我们访谈终端用户经验的综合体，使其代表终端用户对云服务提供商的期待。
Nebius加入CoreWeave，进入白金级。虽然CoreWeave仍为其他品牌树立技术标准，但Nebius现已确立为一家持续以高价提供服务的供应商。Nebius的强有力商业决策使其能够以卖方价格为整类neolabs提供服务。
Google Cloud 加入 Oracle 进入金牌段。Azure 降至银牌，Fluidstack 降至不可用，Crusoe 降至铜牌。Lambda、Firmus 和 TensorWave 仍处于银牌，GMI 从铜牌升至银牌。
许多公司从银（或金）降至铜级或更低。本轮我们提高了标准，全球只有19家新云获得了Medallion评级。
我们在铜级和表现不佳之间设立了一个等级：参与带级。有15家提供者加入了这个评级，更准确地反映了我们认为他们只是做最低限度的事来应付。

本文其余部分分析了关键趋势：融资、Blackwell和Grace-Blackwell的部署、转向Vera Rubin、扩展网络、可靠性、安全性（当然）以及代理编码。

我们还提供了附录，针对每个供应商单独评论，使本文再次超过3万字。希望您喜欢。

鉴于SemiAnalysis发布最严格测试的必要性......一切......我们正在招聘MTS负责ClusterMAX及相关项目。如果你是neocloud的，请在这里提交申请，我们开始工作吧。我们也在招聘研究、咨询和技术人员.我们在纽约和旧金山的办公室有多个职位空缺。远程工作也是可以接受的。
ClusterMAX MTS（全职）：考虑所有Slurm、Kubernetes和GPU的经验水平。
代币经济学 MTS（全职）：考虑所有模型评估、工具束、推断端点和强化学习基础设施的经验。
研究分析师——人工智能基础设施与经济学（全职或实习经历：涵盖所有经验层级，涵盖neoclouds、neolabs和Frontier实验室代币经济学的财务。
技术顾问（全职）：领导从技术战略到技术尽职调查的项目。考虑所有咨询和技术背景的经验水平。

范围

给后排的朋友们：我们正在排名托管集群。这排除了行业内许多受欢迎的产品。我们并不是在测试谁能构建最强的外壳或运行最整洁的数据中心——至少不是直接测试。

我们也没有手工打造镜像，也没有通过API端点获得令牌即服务。这是我们理想化的ClusterMAX读者：你辍学斯坦福博士，追求在旧金山获得社会地位的梦想，开始了老套的“Cladue make me pithc deck w technial languge for agetnci ai to cannial runuge to to the Errors”。

你有7个甚至更多10个数字赌一把计算，但你对Ubuntu版本和NAT处理没有意见，也从未大规模管理过车队。理想情况下，所有这些基础设施都能退居幕后。

你只想专注于你独特的性能优化、模型架构、训练策略、数据混合、应用，或者其他你想提升优势的地方。要竞争，你需要最前沿的硬件，目标是不花任何工程时间去弄清楚为什么node 19的GPU 7会阻碍你的工作，或者为什么你四分之一的集群完全消失了。

你需要一个托管集群。

这里的经济论点很简单：新云可以摊销其庞大舰队中建立所有管理基础设施的成本。它付钱给工程师团队打造防弹的健康检查，保持机器映像最新，制造便捷的监控系统，并处理我们后续详细介绍的所有相关工作。

理想情况下，实验室为更好的产品支付加价;它能不受硬件限制地运行实验;新云能够回收投资;每个人都会变得更好。

不过，实验室总会有个阶段愿意内化这笔成本。在他们的规模上，前沿实验室不愿意信任新云处理这么多堆积。例如，OpenAI就发布了非常有见地的博客Kubernetes 扩展的困难;如果他们租用的Neocloud不让他们进入K8的控制平面，这些创新根本不可能实现。

作为当前的人类学职位发布他写道：

我们正在运营一个默认功能停止工作的规模。我们拥有调度器，并扩展它，将拓扑敏感的机器学习工作负载同时部署到数千个加速器上。我们扩展控制平面本身——apiserver、etcd、控制器——这样随着对象数量和节点数量的数量级增长，它依然保持响应。我们构建了每个工作负载依赖的核心集群服务，比如服务发现，以确保它们能承受同样的压力。

可以说，像OpenAI和Anthropic那样的速度和规模，需要同时共同设计整个技术栈，而现成的Slinky实现——即使是好的——也无法满足需求。

前沿实验室在管理基础设施时所表现出的明显用心，正好说明了ClusterMAX的重要性。据我们最后一次查看，OpenAI和Anthropic招聘职位描述中带有“Kubernetes”的薪资范围之和是，27,769,274-42,687,654美元更别提他们给已经拥有庞大团队的薪水了。

如果你不打算看到万亿美元的流动性事件，而你需要基础设施足够好才能有竞争力，那你需要一个新云来帮你承担重任。

至少从纸面上看，较小的新云客户就像大卫与巨人作战。OpenAI和Anthropic各自在物流指数曲线上拥有惊人的增长率，我们的数据中心行业模型目前，2027年所有实验室计算数据的56.3%对他们进行了建模。

正如我们稍后会详细描述的，这里还有一个马修原则，源于融资问题：盈利的前沿实验室更容易锁定产能，而小型实验室则被高额预付金、更低的价格困住，且难以提前多年规划。

这是否意味着托管集群已经死去？cLUsTerMaX iS wAshED？事实上，尽管Anthropic和OpenAI每年占据的份额越来越大，托管集群作为业务仍在指数级增长。

我们帮助无数实验室找到了计算，更多实验室正在寻找，愿意付费，等待更多容量上线。Anthropic和OpenAI是最大的客户，但也有许多价值数亿美元的长尾项目，其总价值巨大。

一个合理的情景是，托管集群在前沿实验室裸机领域取得进展，涉及开源进展。服务开源模型已经比许多人想象的更有利可图;我们最近建模了这样一个你每年通过销售开源代币可以赚取超过1亿美元即使在今天的租金价格下，也留下了大量利润空间。

可以想象，无论是边际采用者更注重成本，还是算法进步缩小了与闭源的差距，开源模型都会提升市场份额。无论动态如何，这都会提升管理集群的相对地位。

几乎任何供给端的分裂都会使实验室稍微减少处理基础设施的意愿，而稍微更愿意依赖新云。

这些集群之上层正在迅速成熟，但它们不在ClusterMAX的范围内。有几个细分领域需要考虑。有推理端点，可以是公开的或私有的，按代币计费。

有后培训服务，针对特定用例定制开源模型。还有沙箱服务，为代理提供基础设施，尤其是在强化学习部署期间，简化和优化容器和CPU管理。

这些都大致属于“GPU服务”类别，界限可能模糊。例如，云可能在出售托管集群后，利用剩余容量启动推理端点，或者提供沙盒基础设施，同时内部消耗，作为销售RLaaS。

我们将在不久的将来发布更多相关内容，但这超出了本报告的范围。

测试方法论

针对ClusterMAX 3.0，我们向每个供应商提出了以下要求：

32个GPU（4个8路HGX节点，或8个4路NVL72节点）
高带宽网络（我们要求800G RoCE或XDR InfiniBand，但很多运营商还没有）
10TB+ 高性能文件存储（支持通过 csi 驱动的 NFS/POSIX 挂载和 RWX StorageClass）
10TB+ 的 S3 兼容对象存储
监控仪表盘（通常基于Grafana）
测试Slurm需要5天，测试K8s需要5天（可以并行、在SonK集群上，或者如果提供商想收回节点并重新配置，可以顺序进行）
Blackwell，而非Hopper（Nvidia的B200、B300、GB200、GB300）或AMD的MI355X，都被认为是可以接受的。H100现在已经超过4年了！

我们通过以下三个阶段测试了集群。当然，我们始终通过联系所有这些供应商的客户并听取他们的反馈来补充测试。

第一阶段：审计

首先，审计涵盖的是非题。集群设置正确吗？软件安装了吗？更新了吗？工具功能正常吗？运行大约需要15分钟。可以在GitHub或通过{uv} pip install clustermax.

审计会在负载前检查配置。它涵盖硬件库存、软件和固件版本、GPU访问、容器、调度器配置、网络、存储、健康监测和安全。我们检查哪些组件适用于测试环境，并在所有检查中显示通过、警告、失败和跳过。

这部分我们已免费发布，并将持续维护。其余部分暂时内部保存。

第二阶段：性能

性能对集群各个组件以及整个集群的性能特性设定了通过/不通过的门槛。这些通过微基准测试和现实世界基准测试来实现。

具体来说，我们测试：

GPU 计算
人脉网络
存储
生命周期
培训
推断

下面我们将更详细地解释，但请记住，我们测试的内容会随着时间演变。

GPU 计算

我们首先检查GPU的实际GEMM性能。GEMM是现代AI工作负载中最关键的操作，我们之前多次解释过，其中分组GEMM对现代MoE模型尤为重要。

我们在cuBLASLt（或hipBLASLt）和DeepGEMM上测试分组GEMM，适用于多种精度类型：BF16、FP16、TF32、FP32、FP8 E4M3、MXFP8和NVFP4，具体取决于集群芯片支持的参数。

我们在Kimi K2.5、K3和DeepSeek V3、V4 Pro型号中，使用一套通用形状来实现不同批次大小的不同gate_up和下投影。

然后我们测试GEMMs、GEMV带宽和MAMF（最大可实现Matmul浮点操作，来自）斯塔斯·贝克曼），该程序在每个GPU上按精度运行一段时间的扫描，使用cuBLASLt（或rocBLAS）。

我们会报告所有GEMM测试的FLOP数。

我们还通过GEMV测试来测试内存和'nv带宽`.GEMV通过细向量测量矩阵-向量乘法，报告GB/s作为低批次解码流行为的代理。NVIDIA的“nvbandwidth”工具内置于DCGM健康检查中，测量h2d（CPU对GPU）、d2d（GPU对GPU）和d2h（GPU对CPU）带宽。

最后，我们还有一个定制的PyTorch脚本，通过实际张量副本测量相同路径，记录固定的h2d、d2h和本地HBM副本的带宽。

最后，我们测试婴儿潮一代的HPL-MxP。HPL-MxP通过低精度分解求解大型密集线性系统，这意味着我们同时处理计算、内存和通信。测试涵盖计算、HBM、MPI广播（通过扩展网络）、NVLink和数值正确性，集中在单一工作负载中。

我们报告了不同芯片类型下各种数字格式的FLOP。

虽然GEMM是现代AI工作负载的核心，但这些微基准测试很少区分供应商——供应商很难搞砸这项功能。重要的是，在长时间烧屏期间检查原始GEMM性能，正如后文所述，芯片的时钟频率可能会下降以避免因冷却不当而过热。

在GEMM突发中，你不太可能发现太多值得注意的测试。我们对每个供应商都进行这些测试，因为它速度快，且集群一旦失败即无法使用，但我们更担心其他测试。

生命周期

为了了解集群在整个生命周期中的易用性，我们使用了一组人为测试。我们首先通过多种方法检测互联网速度，主要用于下载/上传速度，主要来自Cloudflare。

然后测试安装常见软件包如PyTorch和vLLM所需的时间。PIP以及紫外线以及从 Docker Hub 下载容器，ghcr.io，和nvcr.io，并从Hugging Face和ModelScope中提取一个模型。

然后我们重新做PIP以及紫外线 安装在每个可用存储层上使用全新包缓存进行测试：主存储层、共享文件系统、本地 NVMe 临时缓存以及任何额外的挂载（称为/家”, `/数据”, `/抓'，以及其他）。

然后我们从每个位置运行“导入手电筒”，看看需要多长时间。在大多数提供者中，这需要1-2秒，但在一些有LOSF性能问题的文件系统中，可能需要10-20秒。

最后，我们取之前下载的模型，运行VLM 发球命令测试我们达到 /v1/models 的时间。同样，有些供应商能在 10-40 秒内将小型模型从共享存储加载到 GPU 内存，但有些供应商需要超过 2 分钟。

人脉网络

我们对节点间和节点内传输的广泛通信性能进行了基准测试。这包括MPI集体，通过MPI运行NCCL或RCCL测试，测量消息大小从8 B到16 GB的集体带宽和延迟，适用于全对全、全减、全集集及其他集体。

同样的工作负载也被运行到此火炬。分发在PyTorch中。此外，我们特别使用RDMA perftest。ib_write_bw以及ib_read_bw我们测量每个网络轨上的点对点带宽，以及通过PCIe进行主机内存回退，以识别任何问题。

我们会以2倍的速度将世界规模扩大，直到用完整个集群，同时跟踪性能的扩展情况。我们还会在禁用NVLink的情况下进行测试，特别是在GB200或GB300的NVL72集群上，以隔离扩展网络的性能。

在这里的会计时需要谨慎，因为世界规模、算法和工作分配相对于扩展边界的关系会显著影响结果。

存储

我们运行fio、ior、Elbencho，一个用Torch和Torch DCP编写的自定义检查点保存/加载基准测试，以及一个由以下公司共享的自定义数据生成基准测试离异的人工智能.Datagen可能是最有趣的，因为它近似了机器人数据流水线中的真实工作负载：生成视频（MP4）和Parquet传感器数据集的汇总写入吞吐量。

但发现最多问题的测试是传统的fio。我们用1MiB的顺序块进行带缓冲/直接I/O的顺序读写，从c1一直到c32，以及4 KiB缓冲/64 KiB的直接随机块，或者如果节点超过4个，则根据集群能容忍的客户端数量进行扫荡。

如果存储配置有任何错误，这次FIO扫描中几乎总会有显示性能差的设置。我们跟踪吞吐量、IOPS和延迟，当然如果客户端过多测试失败，也会发现元数据不一致。

当然，这很大程度上取决于我们获得的体积大小以及SLO的定义方式。这些结果请持保留态度——上图实际上只显示Azure给了我们PB级的挂载。

这也说明了为什么拥有大量集群数据的重要性。例如，缓冲测试的延迟更高，正如你可能想象的，如果测试运行时间不够长，结果也会非常噪杂。

但延迟会高多少，噪声有多大呢？要区分什么是“足够好”，哪些需要向服务提供商标记，关键是与大型同伴集进行比较。

对于对象存储，我们再次运行该套件，针对一个 S3 桶。我们还运行一个自定义基准测试，测量了连续读写、小对象 PUT 和 GET 速率以及读取延迟（p50、p90、p99）的高对象吞吐量。

在这次测试中，我们保持一切一致性。不过，一如既往，如果发现某个集群在某个工作负载上遇到困难，我们会停留一段时间，进行更多测试以更精确地定位问题。

培训

进入现实世界，我们开始看到网络或存储上的问题在真实测试中如何显现。我们通过 torchtitan 运行两个作业：使用 FSDP 在 C4 数据集上进行 llama 3.1 8B 预训练，以及通过 torchtitan 进行 GPT-OSS MoE 专家并行训练。

前者是 FLOP 绑定的，后者是集体绑定的（除非你用的是 NVL72）。因此，后者能清楚地发现网络出现问题。

推断

我们运行InferenceXAgentX 基准测试在单节点和多节点场景下，使用不同模型寻找计算受限、内存受限和通信受限状态，并启用剖析追踪，将InferenceX结果视为基准性能结果进行比较。

与我们的训练测试类似，这凸显了微基准测试涵盖的各集群组件的重要性。如果集群无法通过NCCL测试，它肯定无法产生大量令牌，而我们的InferenceX测试展示了goodp的损失。

第三阶段：可靠性

仅仅因为我们在基准测试中看到稳定的性能，并不意味着供应商能保证稳定，更不意味着他们会提供良好的支持体验。因此，我们通过多种方式测试可靠性、监控和自动修复。

烧蚀

我们从GPU和网络的8小时烧录开始，通过在张量核上运行大型GEMM和全对全通信，同时监控脚本跟踪温度、功耗、时钟频率、FLOP、网络连接、延迟、带宽，当然还跟踪内核环缓冲区是否有错误。

你会惊讶于仅凭这个简单的测试就引发了多少硬件问题。我们无法强调同时对GPU和网络施加压力的重要性。烧灼需要同时热膨胀和收缩这两个组件，以模拟这些系统在真实工作负载下真实应力下的真实行为。

许多供应商仍然使用脚本，分别烧录GPU和网络。

织物

接下来，我们通过循环处理大消息大小的全对全、全收集和减少散布，测试扩展和扩展网络结构的持续性能。我们报告平均、最小和最大带宽，以及集体错误。

在前端网络上，我们还测试了四个节点上每对有向网络之间的管理网络丢包、RTT和TCP带宽。这项额外测试很少能发现烧屏未发现的错误，但我们喜欢这些数据，并且在某些以太网网络负载下显示了显著的性能差异。

存储

继续，我们通过在每个客户端计数下连续运行7.5分钟的连续混合读写，随后进行7.5分钟的随机混合读写，使用fio（如前所述）测试文件系统的耐久度。

我们增加了分配中的客户端，并报告带宽随时间变化、IOPS、尾延迟和性能下降的情况。有趣的是，我们发现一些供应商在负载下带宽下降率较初始基准测试下降了近40%。

当对象存储可用时，我们还会运行一个15分钟的混合PUT、GET、LIST和DELETE工作负载，测量吞吐量下降、P99 GET到第一个字节漂移时间、限速和错误。

我们在这些测试中看到大约10%的差异。

配器

在 Kubernetes 上，我们通过反复创建/删除 GPU Pod 并检查 API 的 GPU 分配来测试“流失”。我们报告调度和启动延迟，并在Kubectl delete po卡住了。

我们还增加了仅CPU沙盒Pod的批量，测量有多少能达到Ready，需要多长时间，以及为何其余的仍处于待处理状态。

最后，我们通过反复启动一个加载卷、写入并同步文件的 pod 来测试 PVC 生命周期，然后删除。我们等待拆除，并在周期间使用预热周期去除测量运行中的初始图像拉取。

破坏性

最后，我们进入有趣的部分：故意破坏东西。

首先，我们重启集群中的所有节点。你可能会希望这不是破坏性测试，但实际上是。在Kubernetes上，我们会围堵并排空节点，发出重启指令，要求更改启动ID，然后等待它返回集群。

计时器停止时，我们能运行英伟达-SMI在节点上的一个新Pod中。使用Slurm时，我们只需获得分配或SSH然后运行Sudo 重启.Slurm-on-Kubernetes 有点不同，所以我们会尝试从 Kubernetes 层做测试，以确保测试正确。

我们的脚本会为所有操作进行计时。

对于注入失败，我们先使用 DCGM 注入方法。如果效果不佳，我们会在内核日志中写入合成的 NVIDIA XID 或 SXID 消息，观察提供者现有的健康检查和调度器的响应。

我们不动他们的健康代理和排水自动化，因此由他们的工具自行检测错误并处理。大多数健康检查设置为读取内核环缓冲区，但有些不是，因此我们与提供者沟通，确保触发器正常工作并有权限拉取。

作为最后一个可靠的方法，我们重置 GPU 的上游 PCIe 桥，生成真正的 XID 79。

在所有这些情况下，我们都会计时检测故障所需的时间、节点在“DRAIN”状态保持的时间，以及返回集群后执行基本命令所需的时间。在AMD系统中，我们注入UMC RAS错误并以相同方式跟踪所有内容。

这是我们最关键的测试。那些我们经常听到客户抱怨可靠性的供应商，通常没有健康检查、监控仪表盘和自动修复系统。可靠性是许多全球最大客户的#1最重要的标准，正如我们在文章《？

》中详细讨论的那样。

值得注意的是，我们的实际测试只是整体评级的一部分。有许多内容我们无法亲自测试，需要通过其他研究方法来详细理解。主要是大规模性能、长期可靠性、支持体验、价格、GPU可用性和交付时间。

即将推出：代理工作负载与强化学习

我们还有两个测试套件，将在后续工作中详细介绍。

CPU 计算

CPU是现代代理工作负载中关键的性能考量，我们之前也讨论过。我们开发了一个全面的基准测试，通过常用的Linux工具和更多微基准测试，将CPU性能推向这些代理工作负载的极限，项目名为SandboX。

SandboX 运行一系列代表代码执行的 CPU 密集型工作负载，包括环形洗牌生产者-消费者队列、Redpanda（测量本地兼容 Kafka 的代理及其吞吐量）以及动态加载平台。

我们还对Kubernetes集群的沙箱生命周期进行了基准测试，以洞察如何在GPU集群剩余的CPU/内存资源上共址强化沙箱的运作方式。我们报告冷启动延迟、调度吞吐量、每节点密度、容量和基线数据。

强化学习

强化学习运行包含许多环节：滚动轨迹的生成器、沙盒中执行动作的环境，以及接收滚动、更新策略并将更新权重推回推理引擎的训练器。

扩展强化学习意味着要平衡最大化训练器、推理引擎、环境沙盒执行、滚动转移、权重同步等，任何一个都可能阻碍整个强化学习栈。

我们还看到了“培训即服务”（Post-Training-as-a-Service，简称RLaaS）的兴起，客户自带环境，或由前置部署的工程师构建，托管培训提供商搭建基础设施以后培训开放权重模型。

其宣传是定制化同时保护客户知识产权，这显然是Satya现在的标语。

在我们即将发布的PostTrainingX基准测试中，我们对训练器与推理GPU分配、批处理大小、部署并发性和策略陈旧限制进行了扫描，以研究它们对性能和训练稳定性的影响。

我们通过每秒推理GPU的输入/输出令牌数、推断延迟、KV缓存占用率和前缀缓存命中率来跟踪生成器性能。通过权重同步延迟、传输带宽和网络遥测来提升通信效率;通过训练吞吐量、优化步时间、MFU、训练/部署 KL、观察到的策略陈旧、裁剪分数、梯度范数和被拒绝的部署来提升训练器的性能和稳定性。

对于环境，我们测量设置时间、工具执行时间、超时和基础设施故障。GPU 利用率、内存使用和功耗提供了系统层面的上下文，而归档的轨迹、日志和精确环境定义则使结果可重复。

PostTrainingX 的目标是对每个提供商进行基准测试。这包括托管培训平台如 Applied Compute、Azure Foundry、Fireworks、Thinky、Baseten、Trajectory、Engram、AI21 平台等，以及开源框架如 Miles、slime、prime-rl 和 verl。

最终结果应能让客户获得数据，决定是否在开源框架上运行自己的后期培训栈，或交给托管的强化学习提供商。

我们已经开始在包括Miles、prime-rl和verl在内的开源框架上运行，接下来还将扩展到托管服务提供商。敬请关注......

行业趋势

融资

过去几个月，新云领域最热门的话题是融资。每个人都想“跟随资金流向”，这正是我们在人工智能计算、资本与市场模型中所做的，我们已在某年推出。

下面我们将讨论更多热门话题。

债务与债务获取

如今，新云用户意识到，信用良好的客户合同可以帮助他们以低于自身信用评级所能支持的利率获得债务。这意味着没有承诺客户（或称“IG承包商”）的供应商可能需要更昂贵的债务或类似股权的资本来购买GPU，从而推动业务启动或发展。

与此同时，贷款方还需要证明供应商能够按时交付集群并满足客户合同中的SLA。债务提升不仅依赖于租赁终止权，也取决于债务服务的现金以及TCV。

这促使多家保险提供商推出参数化方案，以保护neocloud及其贷款方免受合同终止的影响，通常提供一个月的过渡期，以便在终止时找到新的承托人。

我们非常支持这种结构，并认为这是贷款机构降低交易风险的可靠方法。

交易对手风险与英伟达的资产负债表即服务

在大型新云项目中，GPU贷款方和数据中心贷款方可能在同一项目内面对不同的对手方。例如，在Anthropic TPU新云结构中，博通支持设备融资，而谷歌支持数据中心租金。

由于供应链中的多个贷款可能依赖同一个AI实验室，即使每笔贷款指定不同的新云或数据中心借款人，也可能存在系统性且相关的风险。

正如我们刚才讨论的，施工延迟可能导致取消并影响现金流。

英伟达的后备方案应运而生。由于英伟达通过收入底线、房东担保和计划转让给第三方的租赁来支持GPU需求，他们能够帮助新云和人工智能实验室获得投资级融资，而无需超大规模企业介入。

英伟达在首次销售时获得GPU利润率，但现在还可以获得超过其“AICP底线”的部分收入。因此，他们的财务支持推动了对硬件的需求。资产负债表是护城河。

折旧表

自从我们追查伯里博士后，这个话题稍微平息了一些。也许是因为那些六年合同，或者那些价格不降的烦人四年旧H100！谁能确定呢。

无论哪种情况，我们在建模折旧时，会将设备购买日期与在服役日期分开。6年折旧假设需要供应商特定的支持，而在NVIDIA的AICP项目中，6年收入下限实际上并未确定GPU的使用寿命。

我们的折旧敏感性测试会大幅改变模型利润率，但IRR仍是贷款方的优先考虑，因此我们不会在此分享。当然，财务分析并不能确定买家未来为GPU支付的真实价格。

这取决于供需动态，最终问题是：剩余价值。由于贷款机构无法将贷款还款计划与我们用于折旧的会计假设分开设定，我们陷入了一个没有人愿意承担对4、5或6年历史GB300剩余价值评估的风险的世界。

布莱克韦尔与格蕾丝·布莱克韦尔

现在让我们回到本文剩余部分的技术内容。精彩的内容。

正如我们所讨论的，运行8路H100 HGX服务器与GB300 NVL72机架级系统之间的差异非常巨大。3-4年前开始安装H100的供应商，现在面临以下挑战：

基于ARM的Grace CPU（而非x86 Intel或AMD）
Blackwell 显卡，配备 SM100/SM103（配备 CUDA 13.0+）
强制直接液冷（DLC）
高压功率（每个机架 130kW+，通过三相 408 或 480V 供电）
具有 800G CX-8 NIC 和 51.2T 或 102.4T (800GbE RoCE Spectrum-X) 或 115.2T 交换机 (800Gb XDR InfiniBand) 的横向扩展网络
使用 NVLink 交换机和背板在机架级、72 路上扩展网络
用于前端（或融合前端/存储）网络的 BF-3 或 BF-4 DPU
带有洗牌板/洗牌电缆的多平面网络

所有这些变化都会对配置软件、监控系统、技术人员培训、设施级电气、冷却和机械系统、OEM 支持合同和关系等产生影响。

仅仅因为供应商在霍珀一代取得了成功，并不意味着他们也会在布莱克威尔一代取得成功。

在我们的排名中，我们对向我们提供 Grace Blackwell 的任何提供商都给予了高度评价，坦率地说，当他们在配置、监控和可靠性/热备件方面遇到困难时，给了他们更多的余地。

这意味着，如果客户租用仅通过 RoCE 或 InfiniBand 连接的标准 HGX 节点，我们期望看到可用热备件的自动修复：在一小时内完成端到端更换，并在大约 2 分钟内进行检测。然而，对于 NVL72 系统，将托盘热插拔到不同的放大结构上是没有意义的。

因此，在我们的测试中，只要运行状况检查注意到不健康的节点（仍然在 2 分钟或更短的时间内）并阻止在其上安排工作负载，它就完成了其工作。如上所述，我们为许多实验室和云提供 GB300 NVL72 SLA 的建议，我们看到的最常见的模式可能称为“NVL64+”。这意味着每个节点都有一个 SLA，但如果机架中 18 个节点中的 3 个或更多节点在给定时间发生故障，则整个机架将被视为停机。这是由于简单的 2 的幂：很多作业可以被 64 整除，并且在 64 个 GPU 上运行，而填充 72 个 GPU 的最大配置是世界范围内的_尺寸=8 * 在一个_就业机会=9。

搬到维拉鲁宾

有趣的是，从格蕾丝·布莱克威尔（Grace Blackwell）搬到维拉·鲁宾（Vera Rubin）比从霍珀（Hopper）搬到布莱克威尔（Blackwell）需要的改变要少得多。提供商仍然管理基于 Arm 的 CPU、液冷机架规模架构、72 路 NVLink 纵向扩展网络、多平面横向扩展网络和一些 Bluefield DPU。当 GB200 出现时，所有这些东西都是新的！

主要变化是在横向扩展网络上从 800G CX-8 NIC 迁移到 1.6T CX-9 NIC，并且每个机架的功率从约 130kW 增加到约 200kW，包括。

早期需求比布莱克威尔转型时期更为强劲——部分原因是——并且 我们从许多提供商那里得知，他们有望比预期更早地提供 VR。启动起来出奇的顺利，而且物理设计似乎也成熟了很多。

横向扩展网络

横向扩展网络是提供商仍然拥有的最后一个重大设计决策。 Nvidia 和 OEM/ODM 锁定了大部分 NVL72 机架。在它之外，提供商选择拓扑、布线以及 Kubernetes 或 Slurm 如何将结构交付给工作。我们在每一层都发现了问题。

从物理层开始，800G CX-8 NIC 是多平面的：每个 NIC 将其带宽分配给独立的交换结构（称为平面）。每个 GPU 的总带宽保持在 800G。更多的平面为每个交换机提供了更多的有效端口，并且为每个 NIC 提供了更多的上行链路路径，这需要进行洗牌。每个 NIC 通道都必须落在正确的平面上，因此 shuffle 盒将光纤映射放入接插模块中，同时 shuffle 电缆将其构建到组件中。两者都有效，但在可靠性（需要维修设备的频率）和可维护性（维修或更换设备的容易程度）方面需要权衡。

Oracle 是这种物理设计的先驱，当您获得 GB300 节点时它就会显示出来。我们得到的每个 4x GPU 托盘都有 16 个物理 200G 端口，这意味着每个 GPU 有 4 个平面。 Linux暴露了4个可用的800G RDMA VF（rdma_室颤_Rail0 到 RDMA_室颤_rail3），每个 GPU 一个，每个 GPU 位于其自己的 VRF 中。聚合 PF 失败，没有可用的 GID，因此我们必须依赖他们的 SPCX NCCL 插件，每个连接使用 16 个队列对，以及跨平面的自适应路由。

为什么要费心去做这件事？答案是规模。Oracle 在这个物理设计上构建了 Acceleron。他们的 MRC 拓扑论文展示了每个网卡如何分成 8x100G，这将一个 51.2T 的交换机变成 512 个端口，并且以全带宽支持 131,072 个 GPU，只需 2 层，最多 3 次交换机跳转。

OpenAI 于 2026 年 5 月通过 OCP 发布了 MRC，而 Oracle 在 Stargate Abilene 上运行它。软件层允许 MRC 将一个连接分布到路径和平面上，乱序放置数据，通过选择性确认恢复丢失，并使用 SRv6 源路由绕过失败或拥塞的链路。

这个逻辑层在任何规模下都可能变得复杂。这就是任务出问题的地方。

要分配 RDMA 设备并正确使用它，Kubernetes 必须为每个 Pod 提供正确的设备和接口。换句话说，有很多方式来配置和使用 NVIDIA NetworkOperator。

如果配置错误，会给每个人带来麻烦。

我们的脚本识别以下与网络操作员相关的部署模式（资源名称是我们所检查集群的示例）：

rdma_shared_device：rdma/rdma_shared_device_* 使用资源支持的 NAD，或主机网络回退
sriov_主机设备：nvidia.com/hostdev或者nvidia.com/rdma_host_dev使用 HostDeviceNetwork NAD，实现直接设备访问和 GPUDirect RDMA
sriov_legacy：通过 NAD 绑定的 VFnvidia.com/以及一个 SriovNetwork NAD，并在需要时加上 RDMA CNI
sriov_ib：例如一种 InfiniBand VFnvidia.com/mlnxics 使用 SriovIBNetwork NAD。分区结构还需要正确的 PKey 和 UFM 配置。
OVS_卸载: nvidia.com/switchdev 带有 OVSNetwork NAD，用于硬件卸载的 Open vSwitch。
拉德玛_一个/rdma_年份：rdma/ib、rdma/roce，或 nvidia.com/rdma_*，每轨一个 NAD 或主机网络后备。
特定于提供商：AWS EFA (vpc.amazonaws.com/efa 和 libfabric）、DOKS（带有 roce-net-fabricN@fabricN 的 rdma/fabricN）和 GKE DRANET（DRA 声明模板和 pod ResourceClaims）。

设备设置及其之上的 NCCL 插件可以改变作业性能。在 Google 的 GB300 上，内置 NCCL 库选择了不可路由的链接本地 GID，并在我们测试时挂起。设置 NCCL_IB_全局ID_INDEX=3 修复了这个问题，Google 的 gIB 插件在 16 节点、16 GiB 全部上达到了 99.5 GB/s，而其他提供商的速度为 95.3 GB/s，即完全性能。

话虽如此，多节点 NVLink 本身就有问题。 NVIDIA DRA 驱动程序中的 ComputeDomain CRD 为每个作业提供了自己的 IMEX 守护进程和通道声明，独立于 RDMA。 Google、GMI 和 Firmus Kubernetes 使用 ComputeDomain，具有不同的 RDMA 路径：Google 的 DRANET、GMI 的主机网络共享设备、Firmus 的每轨 VF。与此同时，Oracle、Azure Slurm、GMI Slurm、Firmus Slurm 和 Nebius Soperator 从主机提供 IMEX，没有租户索赔。尽管有 GPU DRA ResourceSlices，Azure AKS 仍运行多节点 NVLink，没有租户可见的 ComputeDomain，并且通道源和租户隔离边界未记录。

每个 ComputeDomain 必须位于一个 NVLink 域内，因为跨域需要 RDMA。换句话说，这是分层纵向扩展 NVLink + 横向扩展 RDMA 网络上的拓扑感知网络。当我们在没有ComputeDomain意识的情况下错误地启动作业时，当放置跨机架时，它们只是挂在集团设置中。我们将在稍后的附录中留下关于 EFA 不支持 DeepEP 和 MoonEP 供 AWS 提供商审查的抱怨。

可靠性、运行状况检查、自动修复和 SLA

大约在我们开始研究的时候，我们开始将故障注入到我们测试的每个集群中。提供商之间的差异很大。处理失败需要两件事:

确定发生的事情
正确修复

为了识别故障，我们建议监控仪表板。一个好的仪表板会显示失败的组件、受影响的作业、当前调度程序状态以及每次检查上次运行的时间。陈旧的绿色结果并不是健康的证据。当然，监控仪表板依赖于一些遥测技术，因此您必须正确（且安全）地设置 DCGM。

为了修复故障，我们期望自动修复：重新启动并替换为热备用节点。自动修复不会涵盖所有内容。有些故障需要人工干预、RMA 以及提供商必须直接与客户沟通的其他工作。我们涵盖了确切的成本，以产出的形式衡量，单位为。

NVIDIA 最近开源了 NVSentinel，这是一个针对 Kubernetes 的故障检测和修复系统。它读取 DCGM、系统日志和云维护事件，然后可以封锁和耗尽节点、重置 GPU 或重新启动。默认安装仅用于监控。软件是最简单的部分。重要的部分是从每个 XID 到提供者采取的操作的映射。包含的 XID 94 需要重新启动应用程序。未包含的 XID 95 需要 GPU 恢复。显然，如果你天真地为每个 XID 重新启动每个节点，你就会杀死健康的工作，而如果你在严重的 XID 之后让 GPU 可调度，你就会面临工作负载崩溃的风险。

这也是许多客户只想要裸机的原因。他们只是希望提供商关闭支持请求。关闭支持票比听起来更难。给定的票证可以来自 100 多个 XID 中的任何一个，每个 XID 都有不同的含义和分辨率。 SOP 涵盖从更换驱动器或电源，到清洁电缆，到重新安装内存、GPU 或 NIC，一直到对单个组件或整个服务器托盘进行 RMA 的所有内容。

自动修复有很多不同的选择，正确的选择取决于系统。此外，修复对于 GB 来说是一个与 HGX 不同的问题。在 HGX 上，您可以交换具有 8 个 GPU 的热备用节点。在 NVL72 上，您无法将 8 个以上的 GPU 热插拔到 NVLink 域中。出现故障的托盘会导致 4 个 GPU 停机，选项是降级运行机架或更换整个机架。好消息是 GB300 的失败率往往低于 GB200。无论哪种方式，从错误到数据中心中的操作的流程才是重要的。

一些提供商告诉我们，他们会先等待，然后再采取行动，以便让客户有时间将他们的东西从节点上取出。这就是应对。我们正在模拟一次硬故障。该节点已经死亡，没有任何东西可以从它身上下来。（众所周知，如果提供商说他们选择不做某事是因为他们想“为客户提供选择权”，那么这是可以应对的，提供商承认这一点只是时间问题。）

这就是拥有和运营数据中心与租用共置机房的不同之处。运营自有设施的提供商可以控制现场的技术人员、备件和标准操作程序。使用共置机房的提供商则可能依赖房东的远程操作和他们的时间表。

这两者都会影响容量恢复的速度，而这正是服务水平协议必须衡量的内容。

在涉及服务水平协议（SLA）时，我们已经为三类供应商制定了一套标准化的SLA

在这些文件中，我们提供了以下内容：

在两种场景下（HGX 8路系统，即 H100 或 B300，以及 MGX 4路系统，即 GB200 或 VR NVL72）“节点”、“机架”、“集群”和“站点”的技术定义
所有系统的“停机时间”技术定义
三个级别的相关服务级别协议（“铜”、“银”和“金”，与停机时间相关的相应阈值和信用惩罚）
用于衡量停机时间和提供抵扣的双向承诺
建议从停机时间测量中排除的项目，例如软件升级、安全补丁和物理维护
针对提供商绩效与服务水平协议（SLA）的推荐月度审查频率
买方因低于推荐阈值的停机时间而享有的合同终止权利
验收测试的定义，描述了跨 GPU 计算、网络、存储和软件执行的测试类型，以验证集群是否可运行且是否可以接受，并建议联系 SemiAnalysis 进行 ClusterMAX 技术评估
买方因错过约定的验收日期而享有的合同终止权
“不可抗力”条款的定义
… 还有更多

我们鼓励计算买家 (Neolabs)、云提供商 (Neoclouds)、债务/融资合作伙伴和保险提供商使用这些条款作为其合同的基础，并在验收测试和每月 SLA 性能审查期间包含 SemiAnalysis 技术评估。我们使用我们的技术评估 最大浓度 实用程序和全面的专有流程。

请联系我们： clustermax@semianalysis.com 了解更多信息。

安全

自从我们发布“，”以来，我们对反响感到鼓舞。我们的朋友一直在奔跑我们的 CLI 在他们的集群上寻找需要更换哪些满是灰尘的旧包，并且普遍有更大的动力以应有的严肃态度来处理这个问题。

尽管如此，我们认为它值得更多的审查。随着关于人工智能是否会杀死所有人的讨论达到白热化，几乎没有分析它实际上可以逃避控制并造成伤害的具体手段。开放人工智能和人择正在花费数百万美元进行功能获得研究，他们的一些基础设施已被揭露出严重可疑，但它基本上没有受到评论，即 GPU 集群（这些模型的物理主机）通常没有你所希望的免疫系统那样的东西。

无论您对人工智能功能的信念如何，良好的安全实践都至关重要。即使人工智能工具不会使这些集群变得更加脆弱，但事实仍然是，我们正在花费数十亿美元建设并不安全的基础设施。有很多令人不快的场景可以想象，这些场景只涉及一个使用 Vim 且对操作系统有深入了解的人。通读 Hugging Face 报告并统计导致火势蔓延的普通网络安全错误的数量。

还值得强调的是，这在某种程度上是一种结构性风险。当该行业应对严厉监管和不加批判的社会阻力的危险时，法学硕士工厂的违规事件是它最不应该成为头条新闻的事情。出于网络安全的原因，情况确实如此——每个受损的节点都会增加不良行为者探索的邻居数量——以及普通的社会政治节点——无论好坏，批评者都会对新云行业进行大肆渲染。

做一个好邻居，不要被黑客攻击。

能动编码

主动编码已经对托管的 GPU 集群造成了利润压力，因为使用 AI 工具的客户更愿意采用裸机或轻度管理的集群。我们在测试中一直看到这一点的证据。

如果我们需要添加 Linux 用户，但集群上没有脚本，Codex/目标制作 useradd 脚本并添加我整个团队节省了很多繁琐的工作。尤其是在文档不完善的集群上，代理帮助我们梳理了所有可能的配置，使我们能够顺利进行。

相应的 Slack 对话通常是这样的：

“嘿，大家，我们应该怎么使用XYZ？”

“没关系，Codex 告诉我 ABC。”

“是的，没错。我们会把那个加到文档里。”

在具有明确成功标准和良好背景的环境中，代理对我们的帮助最大；否则，他们在 GPU 系统上的方法显得很天真。他们拥有相关知识，但与看似合理但错误的方法相比，这些知识的权重并不高。

例如，Claude 有一个习惯，通过使用循环而不是作业数组来压垮 Slurm 控制器。我们的一位代理认为 NVLink 结构太麻烦而不想配置，改为通过 InfiniBand 启动作业并宣布胜利；另一位在运行存储测试时犯了类似错误，将测试运行在 NVMe 上而不是 NFS 上；还有一位在试图将 GPU 作业调度到 CPU 节点后，将性能差归咎于提供商。

我们通常让代理通宵运行，无论是使用 `/goal fix this part of the cluster so tests can run`，还是 `/goal try to break this part of the cluster with a realistic workload`。

总体来说，这使我们能够倍增输出，但有时验证结果所需的时间比我们自己做还要长。如果你对集群的设置有很好的想法，代理会让你更强大，你甚至可能考虑与一个不那么理想的提供商合作。

如果你不知道自己在做什么，你的 AGI 顾问会高兴地告诉你去射掉自己的脚。在这种半可理解的事情中，代理放大了技能差异，而不是抹平它们。

一个有见地的例子是 CoreWeave 的启动过程，这本身已经是业界最严格的流程之一。现在，除了严格的传统流程外，他们还让大型语言模型（LLM）对其设备群进行统计分析，寻找能够提前发现故障并改进流程的模式。

CoreWeave 还有一个 NodeBot，可以在自动警报的基础上提供轻量级推理，总结情况并建议下一步操作，以简化人工参与者的诊断过程。

例如，团队描述了一个事件，其中一个热界面材料泵出警报本应将节点移出集群进行调查，但同时也要进行PMU停车警报竞争重启节点而非对其进行分流。

尽管存在冲突，NodeBot 仍确定了正确的操作。CoreWeave 有大规模运行 GPU 的经验，了解无数训练数据中缺失的经验法则，并有专家不断闭合反馈循环以改进这些模型的使用;即使如此，我们也不指望 CoreWeave 很快会受到新兴新云和振动编码数据中心自动化的威胁。

尽管——说实话——业内每个人至少在某些工作流程上都在使用 AI，但我们看到的唯一 AI 优先产品是 AWS 提供的一个不错的 MCP 服务器。

除此之外，所有文档名义上都是为人类编写的。服务商能做的最好的事情是提供详尽的文档——理想情况下，比人类能完成的还要详尽——并在集群上留下黄金配方作为攀山的起点。

除了那些尚未以 AI 为先的遗留流程外，还有许多系统因为不适合代理而变得更差。例如，虽然让 AI 管理你的工作对集群利用率有好处，但它不尊重那些为辅助研究而建立的老式系统。

CoreWeave和Nebius拥有许多Slurm层优化——真正的作业账号系统，带有RBAC和对用户和组强制优先级，精心管理的分区、作业数组、日志和指标——当一切都以代理方式运行时，这些优化就被浪费了。

CoreWeave还告诉我们，他们曾见过主节点在远程控制Claude对集群进行草率调控时内存耗尽。值得关注的是，供应商如何改进他们的AI代理服务。

展望未来

正如本文所描述的，我们历来一直在测试集群。但市场显然朝两个相反方向发展。

首先，最大的实验室大规模购买裸机，数量达数百兆瓦，并且拥有管理自身培训集群、编排软件、监控和可靠性的人才。本质上，他们的新云服务提供商（当他们使用时，且不自建）是数据中心技术员，负责结案。

这是一个复杂的业务，不能掉以轻心：有172种独特且有文档记录的NVIDIA GPU故障方式（XIDs）。而且许多失败模式可能重叠，导致出现了极其庞大的不同失败场景，这些场景需要简单的故障排除逻辑、人类经验，以及越来越多的人工智能主动研究相结合，才能从这些故障中恢复。

与此同时，许多初创公司筹集了数亿美元甚至数亿美元，实际上将所有资金都花在计算上。但由于大量研究由强化学习驱动，通过对长期代理的真实生产轨迹进行持续学习，因此离线、吞吐量优化的推理和在线延迟敏感推理的需求都非常强烈。

与此同时，越来越多的客户在寻找购买原生开源代币的最简单方式。

这引出了我们即将发布的下一篇文章，我们将介绍推理端点的结构，并朝着未来ClusterMAX版本中加入推理端点测试方向迈进。我们认为所有新云未来都需要拥有端点业务。

我们还将评估超越推理的强化学习基础设施：沙盒、托管培训、评估等。我们每天都看到大量新供应商进入（或退出）市场。这是人工智能领域的激动人心时刻，而新云正是其核心。

如果您看到本文，仍然渴望了解我们对每个服务商的个人体验，欢迎加入SemiAnalysis！

我们正在积极招聘研究、咨询和技术人员。我们在纽约和旧金山办公室有多个职位空缺。远程工作也是允许的。ClusterMAX工程师：考虑所有使用 Slurm、Kubernetes 和 GPU 的经验水平（全职)代币经济学工程师：考虑所有模型评估、工具束、推理端点和强化学习基础设施的经验层级（全职)研究分析师——人工智能基础设施与经济学：涵盖NeoClouds、NeoLabs和Frontier实验室代币经济学财务的各级经验全职，或者实习经历)技术顾问：领导从技术战略到技术尽职调查的项目。考虑所有咨询经验和技术背景的人士（全职)

感谢阅读，我们期待在ClusterMAX未来版本中与您见面。

附录：提供者评价

白金

CoreWeave

CoreWeave依然是业内最敏锐、最坚固、最主动的新型云技术。

我们的CoreWeave集群在所有关键类别中都表现出色。健康检查功能正常，可靠性极佳，几乎所有测试开箱即用时都达到了预期值。与Nebius一起，CoreWeave成为行业内其他集群的衡量标准——不仅是抽象意义上的“优秀表现者”，更体现在字面意义上，我们会将他们的集群与评分较低的集群进行比较，以精准描述他人的不足。

当其他新云集群需要被催促来刷新他们那陈旧的GPU驱动时，CoreWeave不仅处理了基础工作，还建立了一个重要的独立集群栈，实现了边际性能和可靠性的提升。

他们详细介绍了CoreWeave的设计决策，包括裸机配置、Slurm分支、DPU的使用以及健康检查。此后，CoreWeave的“极客们”新增了一个智能功能，名为“”GPU 落后检测“，并将其集成到他们同类最优秀的仪表盘中。CoreWeave 没有让客户自己翻日志或对车队进行二分搜索来筛选不良排名，而是用手卷算法对 NCCL 遥测数据进行分析，并根据发现推荐修复策略。CoreWeave 团队告诉我们，他们几乎每天都在与客户通话时使用这种方法。有各种软性失败，既不写 XID 也不留下其他明显特征，但却浪费了 GPU 时间，因为工作在一个落后者身上等待。

比起发现有问题的GPU更重要的是不提前调度它们;CoreWeave还配备了系统，确保每个节点在被信任处理客户工作负载前都达到高门槛。当节点在CKS中空闲时，CoreWeave每小时运行20-30分钟的烧屏，验证扩展和扩展结构的健康状况，GEMM数据符合规格，D2H和H2D带宽充足，等等。

这些测试会被客户工作负载抢占;对操作员来说是隐形的，有助于确保不是生产工作负载发现故障。CoreWeave当然不是唯一有活跃健康检查的供应商，但这些检查异常稳健。

这种勤勉也延伸到了CoreWeave启动过程.每周配置约10,000块GPU，CoreWeave相信他们掌握的数据比上帝还多，关于如何证明Blackwell机架的健康状况。

在CoreWeave看来，Nvidia的诊断工具擅长发现许多故障，但其独特且深度的数据集使他们能够推出一套定制的补充测试套件，包括针对NVLink的测试。

这一过程的核心是车队生命周期控制器（FLCC），它”自动化节点配置、测试和监控“并拥有从通电到切换的路径。重要的是，正如其他大规模运营车队的证实，存在大量晦涩的故障模式，这些模式在Nvidia文档中未被充分覆盖。CoreWeave保存这些故障的统计数据，以更好地预测未来故障，并将其响应模式内置于FLCC。这也是为什么大规模运营经验成为我们评级中关键标准的原因之一。新手与像CoreWeave这样拥有严格运行手册、自动化和烧机的供应商之间存在巨大差异。正如上文”代理编码“部分所述，CoreWeave在该系统基础上使用LLM来获取人工工程师无法察觉的洞察。CoreWeave还会在交付前与制造商合作。参与程度因OEM或ODM以及生产阶段而异，但总体目标是逆向供应链中追溯，尽早发现问题：绝不在生产阶段发现你可能在生产阶段发现的问题，也绝不能在L11阶段发现你在工厂车间发现的错误。

他们在Blackwell NVL72的启动和验证经验，以及与Nvidia和Dell的密切合作关系，使CoreWeave成为首个发布该产品的供应商一台VR200 NVL72系统通过L11诊断.CoreWeave 将 VR 描述为“我们带来自己知识产权的一代”。

随着计算物理需求的不断增加，CoreWeave 认为，“建筑的运作方式现在已成为计算机的运作方式的一部分——它们不再是两个独立的事物。”因此，CoreWeave 推出了其定制的 Racky、Valvey 和 RLCC最近的博客文章.尤其有趣的是Valvey，一款可编程的每机架水冷阀组件。

这使CoreWeave能够对每个机架的冷却回路进行细致控制，同时在泄漏或其他紧急情况下，还能触发关闭。尽管在构建自身硬件时开始采用超大规模思维，CoreWeave仍将其方法定位为反超空间：传统基础设施强调冗余并防止故障，而CoreWeave则设计得优雅且能快速恢复，限制故障范围，并允许对不可避免的故障更灵活地响应。

然而，在当前万亿美元的扩建中，CoreWeave 正在应对客户需求的大幅增长以及资本成本的不断上升。当然，也有许多好消息值得一提。

它与 Meta、Microsoft、OpenAI 和 NVIDIA ——其最大客户——的关系看起来很稳固，最近还达成了与Anthropic的多年合作协议.它宣布了引人注目的协议激素替代疗法以及简街今年夏天。

也是积极扩展其在亚太地区的产能，表明它”预计国际市场将成为增长的主要驱动力。然而，它背负着350亿美元的债务，并且已经看到投资者抵制项目启动。

因此，CoreWeave 专注于长期裸金属合约，这些合同易于通过投资级交易对手融资，而非管理型集群，后者利润率更高但市场对投资兴趣较低。

此外，我们上一篇文章提到了近期令人印象深刻的收购阵容，但此后Core Scientific 的合并最终告吹除此之外，没有其他消息公布。

关于反馈，有些有些吹毛求疵：

我们希望他们的托管SUNK认证RBAC能按集群进行
我们希望启用本地 GPUDirect 存储能在用户体验控制台中一键实现
新用户的入门以及他们把 ssh pub key 输入放在 UX 控制台的位置，对很多尝试过的用户来说非常困惑

CoreWeave 开始从裸金属领域多元化，首先通过提供自助式SUNK集群这让他们在有能力时可以选择向按需市场销售。他们还推出了一个托管推理平台，最近披露了1亿美元ARR.我们正在为即将发布的无服务器推理端点文章进行测试，但失望地发现没有支持按令牌付费的公共端点。

目前，可以说 CoreWeave 在推理端点方面还有一些工作要做。

尼比乌斯

Nebius在ClusterMAX 2.0中被评为全球第二佳新云，但仍保持金质评级。这一次，Nebius无疑是行业领导者，在各类产品中表现强劲，并具备显著价格溢价的能力。

Nebius进入白金级。

Nebius与英伟达的合作关系依然稳固，包括3月的20亿美元投资，英伟达披露了7月整体持股率为9.3%.Nebius是首家于2025年12月部署HGX B300的供应商，此后一直如此VR NVL72 中最早的 neoclouds 之一,预计将开始部署今年年底或明年初。

Nebius的建设在美国和欧洲多个地点继续推进，具体为他们最近将2027年年底的合同用电目标提高到5 GW.在购方方面，Nebius已与超大规模企业签订了大型协议元文化以及Microsoft以及较小的反射人工智能以及帕兰提尔使其成为少数拥有数百兆瓦超大规模协议且仍定期争夺更小规模初创合同的新型云公司之一。

他们是所有新云中短期集群市场中最活跃的，服务于众多满意客户。Nebius用俄罗斯口音吓唬潜在客户的时代已经过去。这也反映在其容量采购上：与许多同行不同，Nebius通过广泛的数据中心和软件合作伙伴网络机会主义地抢占了5-20兆瓦的站点。

就集群本身而言，好的集群通常很无聊。在Nebius上，烧屏运行无错误;Slurm具备拓扑感知;我们需要的包通常在集群上且较新;WAN良好;编排层没有触发枪。

Nebius与其他平台在技术上的一个区别是，Nebius构建并开源其偏好的SonK版本，操作员.（当然，CoreWeave 内部构建了 SUNK，但它并非开源。）本轮测试的一个 Gcore 集群使用了 Soperator，之前的 Voltage Park 和 FPT 集群也使用了 Soperator。

Nebius写道：“Soperator 的真正魔力在于我们如何使用'jail' Persistent Volume”： Nebius 在“jail”处提供一个 VirtioFS 卷，然后在“/”处绑定挂载，所以你无需担心缓存指向正确的目录，也不用担心“salloc”节点时带走文件。

你会在我们对其他供应商的介绍中看到，管理 SonK 存储系统时存在一些棘手的问题：Slurm 和 Kubernetes 在持久化理念上不同，实际上你在多个层上，站在一个短暂的 Kubernetes 舱上，营造出裸机的假象并不总是简单。

Nebius 的方法让操作员轻松无忧。

特别是，Nebius 为每个工作节点提供了几种存储层级：'/jail' VirtioFS，'/home' NFS，'/mnt/data/' VirtioFS，'/mnt/local-nvme' ext4，以及 '/mnt/memory' tmpfs，以及一流S3.对于大量输入输出的作业，建议使用“/mnt/data”，而对于共享代码和其他并发访问较低的数据，则用“/home”即可。

当我们首次测试“/mnt/data”时，发现4 KiB的顺序分配写入非常缓慢，而从128+排名创建并发目录时，由于元数据可见性不一致，有时会返回“EEXIST”，导致作业被取消。

根据我们对病态工作负载的反馈，Nebius重新调校了这个文件系统，结果证明它坚固且快速。我们不断调整并验证错误已解决;按客户端计算，它的性能超过了中位数，并且我们进一步验证了它能够扩展以应对跨两个机架的高负载。

Nebius 在健康检查方面投入了大量工作，在我们的测试中表现良好。Nebius 在 GB300 机架上进行合成错误注入后，自动将节点恢复服务;该过程尚未优化速度，从开始到完成需 8 小时 40 分钟，但检测即时，过程最终成功。

此外，我们测试的其他 GB300 机架不会自动重启并返回失败节点，因此该过程是自动驱动的，这对 Nebius 来说是有利的。（正如我们在“Blackwell 和 Grace Blackwell” 部分所描述的，通常根本不会自动修复 GB300 节点，因为没有真正的方法能将节点热插拔到 NVL72 机架，且故障排除通常比 HGX 服务器复杂得多。）Nebius还为我们提供了一套出色的仪表盘，揭示了包括集群健康在内的多个方面。

这一切导致Nebius的每兆瓦收入相比CoreWeave（以及市值）有所增长。鉴于他们以当前价格拥有更多的销售能力，我们预计这一趋势将持续。

据我们所知，Nebius在最近的谈判中表现得非常激进，包括他们将一部分容量作为直接拍卖的案例。总体来说，要求高价和在一年期承诺中达到100%的高额预付款似乎是个不错的生意，尤其是当这些预付款能覆盖当前TCV服务器的全部资本支出时。

有人了解Infinite Project的IRR吗？

在他们最大的裸金属场地，Nebius持续面临建设和许可的延误，包括我们拥有的Béthune和Vineland为我们行业领先的数据中心模型客户提供广泛覆盖.但随着各种芯片的陆续上线，Nebius的业绩让他们处于持续增长的有利位置。

总体而言，我们对Nebius始终印象深刻。虽然我们认为他们在许多技术层面和与NVIDIA及Frontier实验室的关系上仍落后于CoreWeave，但稳健的商业决策已确立了Nebius作为服务NeoLab的默认新云平台。

金牌

谷歌云

在谷歌大脑和DeepMind从前沿奇异撤退的背景下，GCP在交易方面表现得无可比拟。知名合作伙伴包括Palo Alto Networks 以100亿美元成交以及Thinking Machines Lab 为“数十亿美元的交易”，同时扩展其与人工智能安全组织Anthropic的丰厚合作关系。

收购网络安全初创公司Wiz以320亿美元成交以及能源创业Intersinters以47.5亿美元现金谷歌积极扩展其技术能力。它还通过以下方式开拓新的收入来源。

TPU销售稀少我们非常关注这一发展，而不是只通过GCP租赁。不过，它自己的TPUaaS仍在不断发展，这要归功于与黑石集团达成50亿美元的交易目标容量为500兆瓦。

谷歌已有千兆瓦项目在筹备中，我们期待继续追踪其与其他超大规模企业和实验室在电力和许可获取上的持续竞争。

凭借跨越多层技术栈的独特地位，谷歌可能拥有全球最多的工程人才，但它拥有值得注意的是《不完美历史》在支持创新方面。在ClusterMAX 1.0中，我们注意到其平台存在诸多问题，但我们预测GCP会迅速达到黄金或白金等级。

直到ClusterMAX 3.0才实现这一目标，但谷歌终于稳居管理最好的集群提供商之列。

GCP GPU的体验不如我们的白金供应商CoreWeave和Nebius精致。与年轻、更专注的新型云用户相比，控制台感觉更像是车辆管理局。访问需要一个Google Cloud的CLI，但有时不配合，迫使我们有时切换到谷歌控制台的基于浏览器的连接，而该连接同样不可靠。

我们的GB200 GKE集群出现了一个小配置错误，默认StorageClass拒绝连接到“a4x-highgpu-4g”节点，迫使我们用非默认类重新尝试块存储。

撇开吹毛求疵不谈，GKE设置得非常好，我们很喜欢使用它。谷歌的托管Slurm正式正式发布且相当稳定，默认设置良好且健康检查良好。

我们为ClusterMAX 2.0在其托管Slurm产品上所做的许多测试现在都成立了，因为GCP产品管理部门的官僚们允许真实客户使用该产品，而不是贴上“测试版”、“预发布版”或“尚未正式发布”等标签。

（顺便说一句，谷歌之后我们将讨论的许多新云用户应该考虑更频繁地使用这些标签——这里的平衡处于中间水平。）

我们GCP集群与其他集群最大的区别是网络。我们的第一次NCCL测试卡住了，因为自动GID选择了错误的地址，但钉定“NCCL_IB_GID_INDEX=3”完成了运行。

即便如此，我们的NCCL测试也不令人满意：你希望看到随着消息体积单调增长，出现大致的逻辑曲线，但实际上呈现出以下锯齿状形状：

这很可能是NCCL本身的问题，而非我们的GCP配置问题。NCCL的启发式不要总是选对协议和算法对于消息大小和拓扑，并且需要一定的手工调优。

不过，我们已经收集了数GB的网络数据，并且知道预期性能会更好。问题很简单，就是我们没有启用gIB插件。这是Google为提升Google RoCE网络性能而提供的一套NCCL插件。

截至26.07，gIB已内置在NGC PyTorch镜像中，因此谷歌客户默认获得自定义协议栈。安装gIB后，我们得到了更好的图表，16节点全对一时的峰值吞吐量提高了4.4%。

（注意，这些测试都是在关闭多节点NVLink结构以隔离扩展网络性能的情况下进行的，这里指的是RoCE。）

虽然不完美，但整体效果好多了，整体数据也很稳健。此时，很明显面料状况良好，配置也足够好，工程师如果想从系统中榨取更多性能，将有一个坚实的基础。

这是英伟达和谷歌为谷歌ConnectX-7/8 NCCL插件设置自动激活的惊人工作。以前，用户需要调整正确的库加载路径和环境变量，才能正确设置并在GCP Nvidia GPU机器上的ConnectX网卡上优化性能。

我们几个季度前给过反馈，现在已经完全自动化了！

GKE的健康检查效果良好。与其他有NVL72系统经验的供应商一样，谷歌的健康检查介入了，但由运营商自行将病区节点带回车队。特别是在我们的XID注入后，健康检查标记为“GPUUnhealthy=True”和“。cloud.google.com/health-check-status=warning但保持节点可调度。这种配置易于操作，是GCP客户默认偏好的配置，并且可以根据用户喜好配置以响应不同严重程度的错误。

为了持续改进，GCP可以审视Nebius和CoreWeave近期所做的所有生活质量改进。它应发布一款更易导航、简化IAM和RBAC的更好控制台，并确保集群访问无痛，无论是通过标准SSH或“kubectl”，还是让现有CLI变得无懈可击。

尤其是现在gIB已在默认的Nvidia镜像中可用，我们希望GCP运营商能顺利从GCP扩展中获得良好性能。他们还可以继续在中端市场追求neolabs，提升实际操作支持体验，并改善与Nvidia的关系。

GCP持续大量业务流失给小型、能力较差的neocloud，因为这些新云要么缺乏GPU容量，要么拒绝以一定价格位满足市场需求。

我们期待在 GCP 的 VR NVL72 系统上市时进行测试，并看到 GCP 在可用性和性能上的持续提升。

神谕

正如我们在ClusterMAX 2.0中提到的，甲骨文在超大规模企业中处于独特地位，其增长必须来自大型合同。与AWS、谷歌和Azure不同，甲骨文没有任何销售前沿代币的协议，也不像Meta和谷歌那样拥有可依靠的非前沿实验室。

相反，它持续与OpenAI、Meta和Nvidia达成巨额交易，报道称”交付850MW额外数据中心容量从6月到8月，这是一个令人震惊的数字。我们预测其2027年的相对增长将成为超大规模企业中最大的，尽管基数最小。

我们测试了两个Oracle集群，接下来将按顺序描述。第一个是Slurm上的GB300 NVL72集群，设置在多平面网络.这本来是原版Slurm，但由于客户需求，Oracle将Slurm-on-OKE纳入了路线图。

一旦开始分配，我们试图通过控制台进入，但和所有超规模主机一样，它证明是个令人望而却步的地方。

重要的是，Oracle 的控制台不支持 RBAC——控制台上没有连接 SSH 用户——所以我们所有的 SSH 密钥都必须在机器上管理。有一次，当我们试图附加到 'authorized_keys' 时，实习生忘记了一个 '-a' 标志，导致我们之前的所有密钥都被移除了。

这显然是典型的用户错误，但这也说明了为什么我们更喜欢在控制台上设置加固路径。我们更不想信任实习生——尤其是那位，无意冒犯——在一个错误可能把我们锁在集群之外时，在命令行上输入魔法词汇。

幸运的是，Oracle 的工程师立刻发现了错误并帮我们修复了。

我们希望他们能解决这个问题，并添加企业级RBAC。

正如预期，Oracle 的集群从第一天起表现良好。他们为我们提供了 InfiniBand 和 NCCL 测试脚本，这很有帮助，因为原版脚本并不能正确使用所有四条轨道。

烧屏无瑕疵，Oracle 托管的 Lustre 吞吐量强劲。Oracle 的健康检查按预期运行，虽然消耗了我们的合成错误，但是否终止并更换 GB300 节点则由用户自行决定。

Oracle 管理的 Prometheus 和 Grafana 表现不错，虽然不完美。例如，它们没有与最终用户的作业核算体验集成。不过，积极的一面是，健康指标现在集成到了控制台的集群管理器中，使关键状态一目了然。

接下来，我们用MI355X测试了OKE。除了TensorWave之外，这是唯一允许我们试用AMD GPU的供应商。过程很艰难。

正如我们上次抱怨的，起初我们需要SSH到操作员节点来引导Kubernetes。这次团队很快解决了我们的Oracle CLI问题，我们很快能够在本地下载凭证。

不过，这个集群最大的问题无疑是网卡。峰值性能接近线路速率，因此我们检测到的硬件没有问题。问题出在ionic驱动上。我们对所有八个网卡的每轨“ib_write”/“ib_read”扫描速度达到391 Gb/s，完成后节点卡住：当Pod被删除时，性能测试进程从未完成“rdma_cm”拆除，强制“杀机”使网卡的destroy-CQ命令超时，RDMA在“ionic_0”和“ionic_4”的管理队列也随之失效。

更糟的是，两个端口仍显示“活跃”，速度为400 Gb/s，节点保持“就绪”状态。被动检查未检查RDMA控制路径，且八天内未运行任何主动检测。

我们通过grep 'dmesg'发现了问题，因为RCCL持续失败。甲骨文在一个周末迅速诊断并重启：他们自己的“ibwrite”健康检查在该集群上也以同样方式失败。

通话中我们解释了病态工作负载，他们与AMD沟通，向集群推送了不同的驱动和固件，问题解决了。

另外，我们遇到过一块GPU断断续续从PCIe总线中掉线，既未被健康检查发现，也未正确显示在仪表盘中。甲骨文迅速更换了该节点，并响应了我们在仪表盘上的反馈。

这一事件表现参差不齐，但甲骨文的响应速度不错。尤其令人遗憾的是，尽管这些驱动程序已知存在不稳定，但没有任何健康检查被提醒。

不过，甲骨文与AMD的密切关系显然是一大优势。他们能够与相关团队沟通，诊断问题，并迅速实施补丁。在甲骨文这样规模的组织中，这种支持并不保证。

有趣的是，甲骨文也是唯一一家银级及以上评级，以及两家铜级及以上排名的供应商之一，且没有任何安装的适用 CVE 库。这对我们来说更多是预期而非好处，但这清楚地表明他们的自动化在部署和升级集群方面是有效的。

如果我们是新实验室，我们会对与甲骨文合作充满信心地完成这次测试。然而，鉴于甲骨文越来越致力于为前沿实验室（如星际之门中的OpenAI）部署裸机，这一点已无关紧要。

在该行业的成功更多依赖于获取，而非RCCL测试。

不过，自上次测试以来，甲骨文取得了进展，整体体验非常出色。我们期待未来继续关注他们的动态。

银牌

Lambda

Lambda最近因参与一项活动而登上新闻350亿美元的人造交易在Nueces县，350兆瓦，与Hut8和Nvidia共同运营。在此之前，他们是传闻他们正准备2027年首次公开募股（IPO），它们分别升起10亿美元,9.26亿美元，和10亿美元为他们的建造负债。

在他们不断成长的过程中，在ClusterMAX 2.0中评为银级后，我们这次对评估Lambda的集群很感兴趣。

入职流程以一份精美的演示文和PDF，说明集群的预期内容，访问权限也迅速安排好。

;这轮测试，这也是Lambda的重点之一。他们的被动健康检查涵盖了相关条件，最终自动修复了我们在测试中模拟的三个错误。两个合成XID在不到15分钟内自动修复，并连接了仪表盘监控节点健康状况。

我们的测试通过重置PCIe二级总线重置触发了真正的XID 79，使节点进入“未准备好”状态，没有“GpuXid”、没有隔离线，也没有Kubernetes层的监控可见性，但最终在2小时后重新加入了车队。

我们在Kubernetes层的节点重启测试也顺利完成。

编排层有了显著改进，但仍存在一些问题。Slurm配置中每个任务的CPU未设置，因此Slurm默认分配一个逻辑核心，除非启动时要求更多。

无密码须藤Slurm 上没有启用，因为我们使用的是托管 slurm 而非非非托管 Slurm。Lambda 是我们遇到的唯一一个做出这种区分的提供商，但显然他们的一些客户希望对自己的集群有根权限，而另一些则不需要（？）。

我们喜欢在自己的集群上有 root 权限。

还缺少了对计算节点的SSH，但没有分配。如果有人在运行作业，你无法连接到他们的分配，或者作业卡住，调试时会很头疼。这也是我们喜欢集群“yolo模式”的另一个原因。

更重要的是，Slurm 的软件已经过时，包括默认位置的 CUDA Toolkit 12.0/usr/bin/nvcc（该版本太老，与 B300 SM100 架构不兼容），驱动程序过于老旧。

好消息是，Slurm 确实配置了拓扑设置，他们给我们的 NCCL 配方也运行良好。测试期间没有出现真正的错误，所有测试，包括烧录和存储，都显示了良好的性能。

我们对Lambda一键集群的关注，在当今积压数月的容量预订时代显得有些过时。正如开头所述，Lambda越来越多地通过裸机构建来推动其盈利，而非完全托管集群。

无论如何，Lambda的编排持续改进，客户满意，这使他们跻身ClusterMAX 3.0的前列。

Microsoft

由于Microsoft的限制，使用Azure集群可能非常困难官僚。他们的工程师尽其所能，但这并不是一个灵活适应客户需求的组织。微软的客户在品味问题上并不是第一位的。

在测试过程中，我们不允许拥有自己的 Azure 帐户，因此我们必须在一位 Azure 工程师的用户名下使用集群，这使我们无法在控制台上摸索并体验真实的入门体验。我们的 GPU 原本设在弗吉尼亚州，但由于一些模糊的内部法令，我们不允许在那里拥有控制平面。相反，我们的控制飞机在德克萨斯州圣安东尼奥市运行。访问需要设置 VPN，经过一段时间（实际上是 3 周）的来回后才成功。堡垒上禁用了粘贴，因此要运行我们的测试，我们必须手动输入 GitHub 和 HuggingFace 令牌。就像，一次逐字地输入一个字符。不过，我们第一次尝试就做对了，nbd 😮‍💨.

一旦一切最终运行，我们发现一些软件包已经过时，并且糟糕的默认 NCCL 配置使我们无法进行第一次运行。在 AKS 上，“托管 csi-premium-v2”“StorageClass”无法附加，并且“EAGAIN”尝试在 Azure 文件高级版上超过 4 个客户端上运行“fio”。我们的 Slurm 集群没有附加并行系统，这意味着我们从 NFS 加载 DeepSeek-V4 的测试之一超时了。

当我们进行预烧时，我们的 Slurm 机架的 10 个节点出现了真正的故障，导致我们的工作中断。微软发现了这些错误，将其追溯到不健康的主机，并打开了来宾健康报告进行修复。 “scontrol”恢复命令将它们带回来，之后，我们的 Kubernetes 和 Slurm 机架都完成了预烧，没有错误。

在我们通过注入合成 XID 测试 Azure 的运行状况检查后，CycleCloud 立即耗尽了节点，但它没有恢复或替换它。因为我们拥有整个 GB300 机架，所以这令人满意，如上面“Blackwell 和 Grace Blackwell”部分所述。

由于帐户问题，默认情况下我们看不到 Kubernetes dash。相反，Azure 的工程团队为我们设计了一个自定义仪表板设置，而且非常详细，彻底战胜了官僚主义的束缚。我们想为此向我们的朋友徐雪大声喊叫，因为我们非常确定他为我们打造这个项目远远超出了职责范围，但他不承认这一点。他精心策划的仪表板是开源的这里，对于任何构建 Grafana 仪表板以从头开始监控 Nvidia GPU 集群的人来说都是一个很好的资源。

萨蒂亚曾经说过 “我们希望将 Azure 打造成非常适合长尾工作负载的产品，”并且微软“不只是与五个客户签订五份合同作为他们的裸机服务。”然而，很少有风投支持的实验室使用 Azure 进行训练和推理。 “五个客户提供裸机服务”有些言过其实。实际上，有两个：OpenAI 和 MAI。很快就到了三岁，人类多样化。

Azure最有趣的资产是它可以服务OpenAI的模型并保留100%的收入。他们仍然可以完全访问 OpenAI 的所有 IP。然而，Azure 可以单独夸耀与 OpenAI 的大型裸机交易，以及与 Anthropic 的日益有利可图的关系。这是一个非常有利的位置。如果只是为了......

由于 Azure 主要在不同的层面上竞争，拥有庞大的部署和数千亿的资本支出，它管理集群的能力只会使其更加灵活。与谷歌和甲骨文一样，Azure 从不需要帮助建立“ComputeDomain”的承购商那里获得现金流。

但基于测试的质量，这三个机构仍然可以与想要更高接触体验的实验室达成规模更小、利润更高的交易。

不过，这似乎不太可能很快发生。支持和控制台是一个令人头痛的问题，即使 Azure 是唯一一个可以在横向扩展网络上获得 Nvidia 参考架构的超大规模提供商。最重要的是，我们希望验证这些超大规模企业是否行动自如。

公司

Firmus 是 Nvidia 最喜欢的后起之秀之一，也是我们在亚太地区最喜欢的 8 月宣布一轮 20 亿美元融资融资后，以 $10.5B 的价格在澳大利亚、马来西亚和印度尼西亚进行扩张 5.05亿美元融资，估值55亿美元就在4个月前。

Firmus也筹集了100亿美元的债务融资三月份，为其位于墨尔本和塔斯马尼亚的Southgate项目建设。就在上周，它披露了总计900兆瓦的合同容量，并宣布OpenAI作为其在马来西亚扩张的核心租户总的来说，Firmus 今天在部署过程中披露了 18,400 个 GB300 GPU，预计今年晚些时候在塔斯马尼亚将增加到 36,800 个，同时还有多个 GW 和成千上万的 VR 正在筹备中。

我们在测试Firmus的一个开发集群时经历了一个颠簸的起飞，但着陆相对平稳。访问我们的芯片需要使用Microsoft Entra账户、Microsoft SSO，然后下载并配置一个定制的预发布版本vCluster CLI。

我们是新技术的爱好者，但涉及到集群访问时，我们更愿意直接使用SSH。经过几轮反复尝试，在Firmus团队的帮助下，我们终于成功访问了。

……在集群上，但还没有完全启动运行。Kubernetes 和 Slinky 的默认设置都不尽如人意。Slurm 登录没有 `sudo`，没有 `vim` 或 `nano`，HPC-X 已安装但不在 `PATH` 中，也没有 NVCC。

更重要的是，我们原本期望在一块机架上收到 4 个 Slurm 节点，另一块机架上收到 4 个 Kubernetes 节点，但实际上每块机架上都有 2 个。

虽然这不一定是个问题，但 Kubernetes 有 `nvidia.com/gpu.clique` 配置时没有任何东西使用它，而 Slurm 使用了 `topology/flat`。

因此，每个调度器可见的节点跨越了多个机架，而且没有任何措施可以避免多节点作业无谓地跨越机架边界。我们必须推断节点命名法，以确保我们的测试放置得当。

此外，在测试过程中，Kubernetes 控制平面的 `etcd` 可见性闪烁了数次，这导致我们的作业失败，并使 Slurm 和 Kubernetes 层都重新启动。

这最终归因于升级交换机固件的问题，并且在过去 10 天中没有再发生。我们在重启时还丢失了一张 NIC，这在 Firmus 的健康检查中未被发现，因为它们在我们测试的开发集群上没有启用。

Firmus 是我们唯一一个将 GPU HBM 作为 NUMA 节点暴露的 GB300 集群，这是一个有趣的配置，我们将其标记为失败，因为如果主机上的资源溢出，它会让设备 HBM 意外耗尽。

广域网（WAN）表现不稳定，但通常相当差，对 NGC 的保持速率为 0.25 Gb/s。我们遇到的最后一个问题是，其中一个机架的 NVLink 架构性能明显下降，这被解释为 Firmus 在其开发集群上尝试的电源设置所致；修复该问题后，我们的性能数值回到正常范围内。

因此，到测试结束时，我们已经有了满意的 Slinky 和 Kubernetes 层，尽管还不够完善，我们知道如何访问它们，并且我们可以在整个测试套件中获得强大的性能。我们知道托管集群目前并不是 Firmus 的首要任务，但我们相信他们的技术团队可以轻松实现很多目标。随着 Firmus 致力于提供巨大的在线容量，我们期待看到他们继续让 GPU 软件堆栈用户的生活变得更加轻松。

张量波

TensorWave 是 AMD 独有的 neocloud，我们通过 K8s 和 Slinky 测试了其 MI355X 产品。在上一篇文章中，我们强调了 TensorWave 的加入过程的困难，它需要来回才能加入集群，并且仍然存在大量的减速带。这次的改进是显着的。入职很顺利，直接发送给我们的“kubeconfig”工作完美，控制台允许我们轻松添加具有 SSH 访问权限的团队成员，并且 TensorWave 支持团队在整个测试过程中都很细心。

作为仅限 AMD 的云，TensorWave 正在与 AMD 的软件堆栈进行一场艰苦的战斗，其中，仍然远远落后于Nvidia。我们在 RCCL 微基准测试的 TensorWave 集群上看到了这一点，即使使用 TensorWave 的二进制文件和配方，所有收集和所有到所有的大小都挂在 32 KiB 上。其他集体在某些消息大小下表现出不均匀的扩展和较差的吞吐量。 [编辑评论：RCCL？更像瑞克·L！] 总的来说，可以说 AMD 网络堆栈缺乏 Nvidia 工具提供的社区支持。当然，在硬件方面也是如此。比微基准测试更重要的是，我们在实践中看到 GB300 NVL72 系统在整个行业中对实验室的需求最大：它们的性能非常优越，即使考虑到其较高的价格，它们通常也能提供最佳的性价比。 AMD 的机架规模答案 MI455X赫利俄斯，仍然是，并且 TensorWave 肯定还没有提供。因此，TensorWave 在排名中的位置不仅取决于其内部改进，还取决于 AMD 正在努力缩小与 Nvidia 的差距。

正如其宣传的那样，我们的 TensorWave 集群在各方面都表现良好。南北带宽强劲。存储性能非常出色，烧机也顺利完成。当我们推动 Kubernetes 层时，它的可靠性很好，而且 Slinky 层也很容易使用。

健康检查立即识别出我们模拟的错误，将节点置于“drng”状态。

仪表板奇怪地将节点标记为“已分配”，而不是分成自己的类别。然而，不久之后，我们看到了一个漂亮的多汁按钮，单击即可批准用新节点替换我们的“生病”节点。

更换工作大约用时 43m 完成。我们希望自动修复默认发生——我们甚至不必点击一个漂亮的多汁按钮——但在其他方面考虑 TensorWave 的监控和自动修复堪称典范。

总体而言，TensorWave 是领先的 AMD 专有 Neocloud，在 AMD GPU 上提供与 Oracle 和 Microsoft 等超大规模提供商相当（有时甚至更好）的体验。他们并没有停止。 TensorWave 有与费米达成协议得克萨斯州狭长地带的 222 兆瓦发电项目，以及高达 650 兆瓦的扩建权，具体取决于费米 (Fermi) 获得项目融资。它有一个顺风 $350M六月B系列，投后价格为 $1.55B，目前正在与超大规模企业进行大型交易。两者都有开放人工智能和人择宣布与 AMD 建立 MI450 代战略合作伙伴关系，我们预计 TensorWave 将受益，并且 AMD 独占的 neoclouds 可能能够进入金牌级别。我们期待在 TensorWave 的 MI455X Helios 可用时进行测试。

GMI

GMI 是一家总部位于芒廷维尤的新云公司，起源于台湾。拥有一个去年十一月宣布的5亿美元英伟达交易和今年三月多了 120 亿美元在管道中有数百个 GB300 机架，并且有未来 VR 的计划，他们在硬件方面一直保持在前沿。

最近，他们还通过与较小的新型云计算服务商达成交易并将计算资源转售给已有客户群来扩大他们的机群，这提供了一个具有吸引力的现金流模式，因为它不需要前期资本支出。

在将他们评为“顶级铜牌新型云”之后，我们有兴趣测试他们托管集群的进展情况。

入职过程有点坎坷，包括从控制台下载的 Kubeconfig 是空的，以及我们上传但从未同步到集群的 SSH 密钥。经过与团队的一番反复沟通后，我们最终进入了系统。

问题的原因是，我们测试时控制台只是只读状态，因此无法验证其功能。上一次，我们根本无法访问自助控制台，所以我们认为这已经是进步了。

和上次一样，计算性能达到规格要求，烧机测试顺利通过，InfiniBand 网络结构非常稳固。自 ClusterMAX 2.0 以来，一个显著的改进是在 GMI 的存储方面。

GMI 提供了高性能的 RWX NFS 默认 StorageClass，这在 Slurm 层的 `/home` 也可用。我们尝试 GMI 的 S3 时遇到了一些困难，结果发现是他们文档中的一个拼写错误。

但一旦卡拉马佐夫兄弟 Karasev 通过电话修复，我们验证了对象存储的性能也很好。在集群配置方面，最大阻碍是 GMI 期望通过 ComputeDomain CRD 在 Kubernetes 集群上配置 IMEX 域。

这完全可行——许多其他高评提供商也是这样做的——但是 GMI 的 Kueue 无法接受该声明，因此我们的作业一直处于 `Suspended` 状态。为了解决这个问题，我们不得不在一个没有名为 `default` 的 `LocalQueue` 的命名空间中提交作业。

我们建议 GMI 文档中说明 MNNVL 作业需要跳过队列，或者更好的是，让 GMI 设置其 Kueue 以容忍 DRA 资源声明。

GMI 的仪表板，在我们上次测试时还不存在，非常有用，包括来自 DCGM 的硬件信息以及 NVLink 和 InfiniBand 监控。

由于缺乏备用容量，我们无法获得完整的 GMI 健康检查体验，但我们可以测试的表现良好。节点很快在 Kubernetes 层被封锁，然后重新启动并自动取消封锁。 Slurm 层还在注入合成错误后不久将节点带入“DRAIN”。 GMI 在 Slack 中设置了警报，因此我们可以看到他们的系统检测到错误并与支持人员讨论后续步骤，这很方便。

我们的 GMI 经验在各个关键方面都很扎实，我们期待着随着它们的容量快速提升而继续对其进行测试。

青铜

亚马逊网络服务 (AWS)

我们的上一份报告将 AWS 体验总结为“令人头痛”。这一次，我们必须打破一些 亚马逊 Basic Care 布洛芬片，退烧药，缓解身体疼痛、头痛、关节炎疼痛等，棕色 200 片 通过我们的测试。

AWS 的困难在您进入集群之前就开始了，实际上，甚至在您尝试配置集群之前：当您考虑 AWS 的托管产品动物园时，它就开始了。为了弄清楚这一点，我们必须制作维恩图:

(警告讲师: 任何对 AWS GPU 产品的细节不感兴趣的人都应该跳过这个¶。）贤者创客是 AWS 的完全托管平台，旨在最大限度地减少维护。如果您不想处理任何基础设施，它提供无服务器模型定制和数据科学环境抽象出底层计算。下一个级别是 SageMaker HyperPod 线，同时支持泥浆和前员工. HyperPod 系列提供许多便利，例如健康检查,自我修复,仪表盘，以及工作负载级别的特征，例如无检查点训练对于想要保留“ssh”或“kubectl”访问权限的用户来说，开箱即用。如果您希望抽象基础设施，但想自己处理 ML 堆栈，您可以离开 SageMaker 保护伞并选择 EKS 自动模式，它负责节点配置、自动扩展、操作系统修补和节点修复。 EKS 自动模式是“托管 EC2 实例”之上的包装器，但这些不是实际的 EC2 实例，因为它们不会显示在 EC2 控制台中，并且不提供与普通 EC2 实例相同级别的可定制性。在 EKS 自动模式下，用户无权访问控制平面，并且必须允许 AWS 回收其工作人员每 21 天一次以确保安全。最后，为了获得更大的可定制性， EKS + 卡彭特，它允许用户使用开源工具自行管理自动缩放卡彭特.

尽管亚马逊享有盛誉 “顾客至上”，很明显，这个小说长度的 GPU 菜单就是这句格言的一个例子 “您发送您的组织结构图” 而不是真实需求细分的反映。一旦您订购了集群，官僚主义的挫败感就不会结束。这是对组织的批评，而不是对任何团队的批评——AWS 具有以下特点：三世纪罗马帝国。为了提高其在下一轮 ClusterMAX 测试中的地位，我们建议 AWS 选择另一个帝国和/或时间段作为参考。

然而，所有这些产品都有一个共同的特征：它们在您第一次尝试时无法提供。因此，我们制作了另一个澄清维恩图:

这最终给我们带来了 AWS 操作员体验。由于 IAM 权限不足，我们在控制台中配置的一个 SageMaker 集群失败。一些 EKS 集群使用 Terraform 来简化配置，但该路径未经实战测试，并且需要位于正确的子目录中，并且位于正确（运行中）存储库的正确分支的正确提交中，并且确切地知道要转动哪些旋钮，而不会发出无效请求。一个集群在没有 Lustre 的情况下出现，并且不让我们附加任何集群，尽管我们与 AWS 工程师进行了长时间的反复讨论。出于测试目的，我们在新区域配置了一个新集群来收集有关文件系统性能的数据，但如果我们是现实生活中的实验室，这将造成严重后果，至少是暂时的。与我们合作的 AWS 团队始终如一地提供帮助，但很明显，他们没有自由去解决问题，甚至没有深入了解系统如何组合在一起的能力，特别是与我们评判他们的扁平、灵活的 Neocloud 相比。首先，不应该需要六名工程师多次调用来配置 Slurm 集群。

货物交付后，就没有任何障碍阻止我们获得合理的性能。驱动程序、固件和大多数实用程序都是最新的。然而，这只是 AWS 等信誉良好的提供商的最低要求，其他地方也不乏粗糙的地方。

我们测试的 AWS 集群与同类 B200 集群之间的一个基本区别是，AWS 使用 Elastic Fabric Adapter (EFA)，这是其专有的横向扩展结构。在我们的测试中，EFA 峰值吞吐量很高。在四节点 32-GPU 多对多上 NCCL在B200上对EFA进行测试时，我们在16 GiB消息大小下测量到59.44 GB/s的总线带宽，这相当于考虑跨节点流量比例后，约为扩展线速的92%。在其他网络测试中，使用不同的流量模式和启动机制，只要消息大小足够大，吞吐量就处于B200集群的最佳水平。然而，EFA的延迟始终明显高于优化良好的InfiniBand系统。例如，当消息大小减小到64 KiB时，同样的四节点32-GPU全对全NCCL测试在EFA上耗时85.26微秒，而在InfiniBand节点上耗时不到50微秒；EFA与InfiniBand之间的30-40%的差距在以延迟为主的小消息测试中是一致的。虽然这看起来像是挑剔，但扩展延迟是现代系统的关键指标。专家-平行工作负载，经常在节点边界之间发送小的令牌向量。例如，这个 64 KiB 的 NCCL 测试，类似于像 Kimi K3 和 DeepSeek V4 这样的模型的专家路由步骤。我们的发现得到了一个……的证实关于优化EFA的优秀Perplexity技术博客文章，其报告了类似的结果：EFA 展示了令人满意的峰值吞吐量，但在“MoE 派发和合并期间交换的消息大小”上需要支付大约 20 微秒的延迟代价。（注意，这篇 Perplexity 的文章将 EFA 与 ConnectX-7 网卡进行了比较，而我们测试的是 ConnectX-8，但两代的标称吞吐量是相同的。）当 Perplexity 的顶尖工程师为了“启用”你自定义网络栈上的基本功能而写出详细而费力的博客文章时，这不是一个好迹象。

EFA 在上游的 vLLM 和 SGLang 中进行专家并行推理仍然需要额外的设置。AWS 报告了成功的 vLLM 部署，但用户必须安装 EFA 用户空间库，并构建支持 EFA 的相关通信组件。

根据工作负载，这些组件包括 DeepEP、NIXL 或 Mooncake Store。AWS 的 DeepEP 分支通过 NCCL GIN 支持 EFA。深度EP V2使用 NCCL GIN，而其基于 NVSHMEM 的 V1 路径现已作为遗留文件。

上游集成和默认容器打包仍需工作。NCCL EP 是另一条正在开发的路径;链接的 vLLM 集成仍然是选秀公关.总体而言，EFA并非前沿通信图书馆的优先事项，用户必须等待数周甚至数月才能获得支持。

AWS是唯一在这方面与众不同的云。我们测试的其他所有供应商都使用InfiniBand或RoCE。当然，AWS拥有与全球协议的客户有资源确保其EFA的良好调优，但我们仍然觉得遗憾的是，最大供应商的扩展技术栈却异常棘手。

从另一个角度看，存储是另一个基础集群服务，但经常不配合。我们在“ap-south-1a”中配置的B200集群每次存储请求都失败，出现模糊的“容量不足”错误，删除“失败”文件系统则耗时5小时46分55秒。

要测试Lustre的性能，需要在另一个区域的集群，这意味着又要花很长时间——又一个晚上盯着终端观察，试图判断Terraform是否取得了进展。

通过Terraform在AWS上占领存储就像养育一个幼儿：你只能眼睁睁看着，希望它销毁完后会开始创建。而且存储一旦创建，访问并不一定简单。

在Kubernetes层，有一个集群默认没有提供StorageClass，只有提供StorageClass后，由于驱动程序错误，我们的PVC无限期处于“待处理”状态。

这需要我们用正确的配置器定义自己的StorageClass。

开机并接线后，存储效果混合。提供的FSx协议栈在普通缓冲I/O方面表现非常困难在FIO测试中，p99连续读取延迟达到9.2秒，而在相同指标下禁用缓冲时为312毫秒。

缓冲设置下延迟更高是预期的，但这是病态的差异。

AWS的健康检查表现同样参差不齐。我们的EKS自动模式集群捕获了注入的XID，设置了“AcceleratedHardwareReady=False”，并在原始注入仅24分钟后给出了一个新的健康节点。

与此同时，我们的SageMaker HyperPod Slurm集群立即检测到XID，将节点带入“DRAIN”状态，并完成了大部分重新配置过程，直到需要深度健康检查才能重新加入舰队时绊倒了自己。

这次深度健康检查作为Slurm任务提交，直到节点重新加入舰队后才能调度。因此，操作员必须手动推送“scontrol ...State=RESUME”命令，舰队随后恢复了完整健康。

在我们的反馈下，AWS迅速修复了这种循环依赖，并且对单个H100节点的后续测试也顺利通过，无需干预。更好。

我们的EKS Karpenter集群的健康检查更加自我破坏。“dcgm服务器”DaemonSet不允许nvidia.com/gpu:NoSchedule'污染，因此它没有连接到工作节点，导致监控代理报告“连接nv-hostengine错误”，并将“AcceleratedHardwareReady=False”翻转为“Reason=DCGMErrror”。

Karpenter随后标记了“NodeClaim”终止，替换节点因同样原因被标记为不健康，系统开始打转，直到我们手动修改守护进程以容忍GPU污染。

健康检查发现IMEX守护进程未调度时又出现过敏反应。IMEX在节点间配置NVLink结构，但我们有普通B200节点通过EFA通信，IMEX无能为力：这个守护进程未能着陆本应无害。

然而，监控日志发出了精神分裂的消息

忽略非NVLink多节点系统的IMEX健康码，代码=122

向出口商发送条件，

Reason=NvidiaFabricError，

严重度=致命

如果我们没有手动钉住，这同样会回收一个健康的节点NodeRepair=false以防止过度的垃圾收集阻碍我们的工作。最终，在测试接近尾声时，卡彭特在结束日期强制驱逐正在进行的4节点MPIJob。我们在这里详细说明，是因为这些漏洞对全球最大云来说几乎是极其基础的。或许AWS生命周期中唯一无痛的部分是Karpenter的扩展和缩减，几分钟内完成且无错误。然而，GPU容量必须提前大量加密，因此用Karpenter快速自动扩展功能毫无意义。

尽管产品存在诸多问题，AWS的专家和工程师在与他们的互动中依然聪明且响应迅速。他们热衷于展示改进，寻求文档反馈，回头纠正测试中的错误，甚至打造了一个面向未来的系统MCP服务器我们从他们的技能中挖掘出来，打造了自己的代码库。

AWS的问题在于其组织结构。在拥有AWS资源的组织中，许多基本问题被忽视的数量令人震惊。

今年二月，AWS宣布与OpenAI的合作协议将扩大1亿美元;在2Q26，净销售额同比增长37%;其Trainium业务ARR达到250亿美元，同比增长三位数;其人力投资每年增长数百亿美元;基岩。

托管集群不是AWS的优先事项。

Gcore

Gcore 是一家类似卢森堡的新型云，位于被称为“欧洲”的模糊地区，依赖其他供应商提供容量。他们最近没有发布任何炫目的公告，但正在将 Blackwell 加入他们的 Hopper 车队。

在 ClusterMAX 2.0 中，我们在通过 Soperator 测试 Kubernetes 和 SonK 后，给 Gcore 打了银级评级。这次，我们只尝试了 SonK。

我们对 Gcore 能力的了解受限于其容量不足：大多数供应商至少给我们 4 个 B300 节点，至少一周，但 Gcore 受限甚大，只能给出 3 个 H200。

尽管如此，这个集群仍有许多因素让我们保持警惕。

我们在Soperator层的测试需要与Gcore团队多次来回沟通以修正一些粗糙之处，但团队始终提供了帮助。当我们大部分第一次扫描因配置错误导致非root用户无法运行工作负载而失败时，团队迅速响应，确认“kernel.apparmor_restrict_unprivileged_userns=0”将帮助我们解封。

当每个Slurm工作者报告“RealMemory=2048 MiB”时，Gcore团队再次迅速响应，纠正了另一个糟糕的默认设置，显然是错误继承了CPU配置。

这导致我们甚至无法运行“nvidia-smi”，我们很高兴看到问题迅速修复。

由于默认禁用节点间 SSH，调试在 Soperator 层稍显困难，但团队向我们推荐了一个“soperator-createuser”便利脚本，让操作更方便。

团队还在测试时排查了仪表盘的错误。

Kubernetes 层没有默认的 StorageClass，用户必须明确选择 NFS。Slurm 层的存储配置正确，Soperator 默认设置为 '/'，提供与所有节点有线共享的单一共享卷的假象。

该存储在多个工作负载中表现良好。N/S 网络表现良好，E/W 网络最终达到规格，但 RDMA 设备名称非标准且无 topology.conf，配置需额外操作。

我们注入的 XID 很快被捕获并显示在 Grafana 中;有趣的是，节点在 Slurm 层“宕机”，但在 Kubernetes 层上没有变化，尽管它通过 K8s 注入。

我们无法测试自动修复，因为 Gcore 没有多余容量。

我们对 Gcore 的细致入微和他们的 Soperator 产品印象深刻，经过调整后，基本功能已做得恰到好处。我们期待测试 Gcore 的 B300/GB300 管理，包括其对 XDR ConnectX-8 网卡的处理，并见证他们 Soperator 和 Kubernetes 产品的改进。

转基因生物

GMO管理的Slurm集群在两个B300节点上提供了强大的网络和存储性能。其主要弱点是配置文件受限、企业控制有限以及缺乏自动修复。

Slurm 带来了配置好的头节点、分区和 topology.conf。驱动程序和 CUDA/NCCL/HPC-X 模块在各节点上保持最新且一致，Pyxis 也可用。

上线过程很简单，尽管仅支持日语的控制台需要手动操作 ctrl+c、ctrl+v 才能理解。

Grafana访问花了我们五天时间排查。我们最初漏掉了macOS登录钥匙串的指令，后来输入了证书密码，系统密码是必须的。GMO进行了调查并反复跟进。

最后一个错误是我们的，但更清晰的证书说明会节省时间。或者，访问网站时没有不必要的自定义证书。日本安全剧场再次出击。

每节点16条400 Gb/s轨道提供了强劲的NCCL结果，尽管两个节点提供的扩展证据低于我们通常的四节点最低标准。MPI启动需要明确的 NCCL_IB_HCA 设置，GMO 表示已在 nccl.conf 中提供，但最初对我们不起作用。

烧屏显示无网络错误、重试或 ECC 错误，温度和功率正常。

共享的家庭/数据/工作目录开箱即用。FIO 顺序读写、随机读取，以及torch.save是稳固的，构建在经过良好调优的DDN Lustre文件系统之上。

然而，我们那些人为测试，如“导入火炬”和共享存储的vLLM Serve，表现不佳;GMO提出调查，但我们归结为经典的Lustre元数据性能调优问题，便放弃了。

和许多其他Lustre实现一样，GMO存储缺乏快照、自动备份和灾难恢复选项。

集群还缺少工作端的“sudo”和 Docker 功能，并且需要使用斯诺德，他们编写了一个方便脚本，用来显示集群的元数据，因为它们阻止用户运行任何控制指挥他们自己的集群。

安全剧场再次上演。

最后一步，集群上的工作节点的SSH也被屏蔽了。在Slurm作业中，“RmProfilingAdminOnly=1”阻挡了Nsight Compute的GPU计数器，Perf无法满足我们的分析需求。

我们认为，托管集群应允许用户选择yolo模式，可以自行配置工作负载。我们想要，但GMO无法实现。

最后，Grafana暴露了有用的DCGM指标，但缺乏XID检测、估计TFLOPS、SM活跃和SM占用视图，这些都是我们在性能和可靠性监测中享有的。

Slurm工作摘要视图也相当基础。我们的合成XID 79日志注入未产生任何警报或节点耗尽。GMO表示其在Slurm prolog中运行dcgmi健康，确认XID 79未被列入白名单，并同意未来调查。

我们最终确定GMO缺乏任何自动修复系统，或者至少无法验证。

总体而言，GMO缺乏Kubernetes和企业级功能，如RBAC、SSO和客户可访问的审计日志，使其属于专门的本地化运营商，有效服务于日本市场。

我们与他们团队的支持经验很有帮助，但他们遵循了日本标准的营业时间。展望未来，我们预计GMO将继续在日本保持领先地位，但缺乏扩大业务范围的雄心。

绿色

总部位于赫尔辛基的Verda（前称DataCrunch）今年6月披露了1亿美元的ARR和2亿美元的总资金.他们与英伟达保持紧密关系，并持续积极寻求融资。

在技术方面，自我们去年11月测试以来，他们已实现了多项功能，我们对他们的工程团队和路线图持乐观态度。

上一轮测试中，Verda的Slurm正式进入测试阶段，他们没有提供Kubernetes。这次，他们提供了托管的Kubernetes，并将Slurm服务迁移到了Slurm-on-Kubernetes，以简化部署。

我们在Slurm和K8s层上测试了他们的集群;虽然存在不少粗糙之处，但代表了显著进展，是持续开发的坚实起点。我们还发现安全性非常稳固。

购买和入职过程非常顺利，集群在30分钟内顺利配置完成。Grafana仪表盘开箱即用，我们顺利通过SSH连接到集群，没有出问题。

不过，一旦我们进入集群，路上遇到了一些坎坷。我们的 Slurm 测试从一个有趣的“脚枪”开始：当我们通过 SSH 进入时，我们以为自己在 Slinky 层，但实际上我们已经落在了外层虚拟机，封装器通过 'kubectl exec' 运行了 'salloc'、'sinfo' 等类似命令到'LoginSet'。

行为很不寻常——例如所有 Slurm 命令都会升级到“root”，我们的 Python 环境也消失了——经过一晚调试才弄清楚 Slurm 访问是虚幻的，需要不同的 SSH 命令才能正确访问 Slinky 层。

Verda的工程师响应迅速，迅速接到支持电话，合理地解释了这些便利功能的背后原理，并指引了支持的路径。虽然这个功能让我们头疼，但当工程师们主动努力让集群更易用时，这反而是乐观的。

Slinky层虽然可用，但并不完美。Verda运行了一个NCCL测试Prolog，超过了Slurm的10秒“MessageTimeout”，导致每次分配都出现令人担忧但无害的“Prolog挂机”警报。

更重要的是，Verda不支持Pyxis或Enroot，所以我们不得不通过一个庞大的“.sif”文件来维护环境。解决后，我们顺利完成了8小时的烧机，并在微基准测试上取得了令人满意的数据。

与此同时，Kubernetes 层只能通过堡垒进行引导，无法通过控制台下载“kubeconfig”。这是一个相对简单的解决方案，旨在使 Verda 的产品与用户标准工作流程保持一致。

在性能检查中，最大的不足是共享文件系统。总吞吐量数据非常出色，但跨节点文件锁似乎根本没有被执行。我们发现“flock（）”和“fcntl（）”在各节点上都出现了100/100的独他锁违规，而同一节点的控制则拒绝了所有尝试。

这强烈表明问题出在“virtiofs”未能公开锁定行为。我们还发现在多个客户端下载时数据损坏，以及Elbencho上32个客户端的“ENOENT”失败。

这更多是容易解决的问题，尤其考虑到运行Slinky时可靠共享文件系统的重要性。

最后，Verda的健康检查程序尚未完全配置完成。它们是字面意义上的“健康检查”，即评估节点是否健康，但没有任何数据消耗其输出——它们退出“1”——“是的，这个节点死了”——然后继续。

因此，用户必须自带可靠性套件，否则不希望不良节点无声无息地终止他们的工作流程。当然，Verda也没有提供自动修复功能。

Verda始终保持沟通迅速清晰，似乎拥有有自由和动力改进产品的工程师。9月10日，测试结束后，他们向即时集群推送了若干更改这些措施看起来很有意义。

我们期待他们继续打磨Slinky和Kubernetes产品，优化存储系统，并实施强有力的健康检查和自动修复。

月光石

月光石总部位于芝加哥的Neocloud，是ClusterMAX 3.0中新增的。Moonlite由前Crusoe创始团队组成，目前运营Hopper机队，最近交付了首批B300和GB300，未来几个月将继续增加。

据LinkedIn称，Moonlite是我们本轮合作过的公司中员工最少，且以工程为导向。

我们测试了 Moonlite 的 Kubernetes 和 Slinky。交接过程很顺利，有一份很好的入职文档定义了验证的配方，还有一个 Kubeconfig，提供了我们所需的一切。

默认情况下，Slinky 上所有人都共享同一个根用户;当我们要求非 root 用户时，Moonlite 在半小时内写了一个“moonlite-adduser”便利脚本，并当天就把它内置进了登录 pod 镜像。

这不仅体现了 Moonlite 对反馈的响应，也展现了他们的新手。我们很喜欢他们的回复。我们更希望有一个经过实战验证的系统，最好是通过控制台来处理这些基础问题。

硬件方面，我们测试的所有设备开箱即用都运行良好。NCCL测试符合ConnectX-7规格，NFS表现良好，计算基准测试稳定，烧机完成也没有问题。

不过，值得一再强调的是，我们测试的是H100，这些设备现在已经为行业熟悉，因此比我们和其他供应商用的GB300 NVL72更容易做到。尽管如此，我们对Hopper的表现很满意。

系统中我们无法测试的一个组件是 NVMe，它存在但无法访问。没有任何暴露：没有本地路径的“StorageClass”，“hostPath”不可用，Slurm 工作者是只有 VAST “/home” 的 Slinky Pods。

在 Kubernetes 层，默认没有 “StorageClass”，未受资格的 PVC 悬挂为“待处理”。

我们通过PCIe二级总线重置测试了Moonlite的健康和监控系统，Moonlite在11分钟内通知了我们。在我们的许可下，他们封锁了节点，进行了诊断，并在总共57分钟后将其归还给我们的车队，其中包括几分钟等待我们指示的后续行动。

实际上，他们会提前与客户制定策略，以便团队根据具体错误遵循运行手册。Moonlite的典型SLA是在收到Slack和PagerDuty警报时，15分钟内响应。

我们从客户那里听到，到目前为止，这正是他们所做的。

在我们看来，任何能在一小时内恢复到满载舰队的自动修复流程都足够了。但虽然手动流程没问题，但规模化时我们希望实现自动化。我们也希望在发生错误时对集群有更高的可见性。

用户唯一可见的变化是，节点在Kubernetes层保持“准备就绪”状态，但在重置与Moonlite手动干预之间的时间内，显示显示有7个GPU，而不是8个。

Slinky层没有工人的容器运行时间，但其他方面完成了任务，并且在登录舱里有我们要求的大部分内容。Moonlite的Grafana还行，但在调度层缺乏细节，也没有显示最关键的信息，也就是错误状态。

Moonlite尝试做的事情，做得很好。我们期待随着他们的产品成熟，手上出现GB300的老茧，再次测试他们。

一起

在 ClusterMAX 2.0 中，我们写了以下关于 Together 的内容：

Together是一家强大的供应商，拥有强大的集群服务，支持Slurm和kubernetes，但由于可靠性问题，未能获得黄金类别。

本轮，Together的问题——通常但不限于可靠性——是降级为铜牌的理由。

我们的两个节点在计算测试中失败;一个回来了，另一个被无预警送往RMA，我们不确定它去了哪里。测试后期，Together的Slurm“HealthCheckProgram”尝试在45秒超时下对已调度的节点运行“dcgmi diag -r 1”;诊断未成功，超时误读为失败，节点在运行中被耗尽。

Together迅速根据反馈修复了这个问题。另外，我们的一个节点无法访问VASTUS，因为其存储网卡处于“operstate=down”状态，Together解释这是由于他们新轻量级虚拟机栈中NIC初始化出现竞争条件。

没有任何错误可以发现，需要人工干预重新配置一个健康的节点，并将测试队列恢复到4个。虽然我们喜欢“减少集群配置时间”的说法，但显然不希望它影响可靠性。

Together的健康检查在某些情况下确实正常工作，显示了自那以后的进展。当我们在Slurm集群上触发PCIe二级总线重置时，节点在67秒内被耗尽，自动节点替换在35分钟7秒内完成，无需人工干预。

一个合成错误还在Kubernetes层封锁了一个节点，正确地没有触发自动修复，因为我们关闭了“自动修复”。

Together Kubernetes 和 Slinky 层都运行正常，但存在一些挑战。有趣的是，Together 建议避免使用 Slinky 集群的 Kubernetes 层：为了将 Slinky 节点转换为 K8s，我们被指示将其拆除并重新配置为原版 Kubernetes。

因此，Slinky 产品应被视为纯粹的 Slurm。简要总结其痛点：由于默认设置为 '/tmp'，OCI 图像提取失败，我们不得不将提取重定向到 '/scratch';发生这种情况时，Slurm 仍然退出了 '0';NFS 拒绝了任何包含 '：' 的文件名;租户没有读取 'dmesg' 的权限，这阻止了检查 XID 事件;而非登录工作者壳的“PATH”上既没有“nvcc”也没有“mpirun”，因此普通批处理脚本的行为与交互式设置不同，且缺乏所需的工具。

这些都不是致命的，但加起来加上其他较小的错误，意味着我们需要几个开发日才能畅通运行。奇怪的是，Together的公共互联网为大多数服务提供了强劲的吞吐量，但它与Canonical的Ubuntu归档源连接反复失败、连接后卡顿，或传输速度低于20 kB/s。

这再次让我们在尝试搭建集群时陷入困境。

公开的IP检查确认，这个不稳定的B300集群拥有组织“AS53735 IREN”。这个N+0的乔治王子数据中心是业内两个以不可靠性著称的数据中心之一，另一个是Crusoe那个该死的雷克雅未克站点。

我们强烈怀疑其中一个或两个数据中心并非以土地确认仪式正式启用.我们知道有多位Together极其不满的客户，面临链路中断、电力问题、集群访问被切断、未经用户批准的随机升级错误且无法回滚，以及持续周末的断线，最终被归咎于单一ISP（是的，这个站点只有一家ISP——加拿大北部没有冗余）。

也许他们的其他站点更好，但IREN Prince George的TogetherAI站点完全糟糕。

经过一段时间的推卸责任游戏，很明显可靠性问题不能完全归咎于底层供应商。客户支持工程师的非强制错误导致客户与服务提供商之间缺乏信任。

当然，管理型集群并非Together的主打业务，也不是主要收入来源。当七月，宣布推出8亿美元的C系列该帖子充其量只是顺带提及了他们的管理集群业务，反而强调“Together AI是一家以研究为驱动的公司”。

他们的购买者沙特250MW尚未公开，但我们知道Together更倾向于按令牌付费，而非按GPU小时计费。尽管如此，我们仍希望Together能够完成，解决集群可靠性问题，使其Slurm和Kubernetes产品值得骄傲。

克鲁梭

ClusterMAX 2.0中关于Crusoe的部分以谨慎的语气结束：

由于许多顶尖个人贡献工程师离职，Crusoe 面临被降级为 ClusterMAX 银级的风险，这使得其云部门的文化开始变得像大科技公司。组织中层管理人员过多，尤其是在工程领域。这导致发布进展极为缓慢，比如他们的 AutoClusters 功能，让我们对 Crusoe 公有云服务的未来感到担忧。如果 Chase 不想失去所有 10x 工程师，最终也要失去他们的 Neocloud 业务，就必须迅速调整方向。

自从我们发布那段话以来的八个月多里，《漂流记》取得了不少胜利。它的估值从大约开始增长100亿美元到309亿美元，它宣布900兆瓦以及1.0GW德克萨斯州的校区还有更多其他地方，并且依然是创新者。

他们拥有所有数据中心建设商中最大的实际流水线。

其推理端点业务也备受推崇，继从Atero引进一些有潜力的以色列工程师之后。他们还与Jane Street等公司达成了极佳的合作。

有很多人可以让他们忙得不可开交，生意也在忙碌，有些集群很棒，但也有些非常糟糕。

然而，这一轮ClusterMAX测试发现，Crusoe的新型云业务并没有足够迅速地调整方向。问题回到了根本：可靠性和卫生性。

我们强调健康检查期望以及我们的报告，但真正的硬件故障在测试中很少见，因为我们的ClusterMAX分配太小且寿命短。Crusoe打破了这一趋势。

在我们五月用来测试AutoCluster的H100集群中，我们看到了大量涌现的XIDS——单个集群在五天内实际出现的误差比我们其他测试加起来还多。

在整个测试过程中，这种模式不断重复，某些方面表现极差，而其他方面服务却成熟：这场XID风暴伴随着方便的邮件，格式吸引人，礼貌地通知我们错误。

除了对本轮大部分硬件故障负有责任外，Crusoe 还拥有我们测试过的最老 Linux 内核和最老 GPU 驱动。Crusoe 后来修正了这些缺陷，但在测试时，有几个软件版本远低于我们的最低预期：上述 NVIDIA 驱动未能满足我们的CMAX审计安全”以及Docker、ConnectX固件和“runc”。

这些问题反映了安全措施松懈和工程卫生不良。

这些软件版本的批评也不仅仅是学术性的。我们B300集群运行的Linux内核“5.15.0-185-generic”，早于一个名为“的Linux补丁系列”写回：切换 inode 时避免锁机.”我们内核遇到的具体问题可以通过提交的描述很好地解释了E1B849C'，该修正了上游核的错误：
```
可能有多个inode交换机构试图将inode切换到或从同一个WB切换。尤其是当某个cgroup退出时，Cgroup拥有数千个inode，我们需要全部切换。在这种情况下，多个inode_switch_wbs_work_fn（）实例会在同一个WB->list_lock上旋转，而只有一个能前进。这会浪费CPU周期，很快导致软锁报告和系统无法使用。

```

拥有数千个 inode 的“cgroup”何时会退出？一个答案是：当 Slurm 作业被拆除时。在我们的情况下，普通工作负载结束时，NUMA 节点上的每个 CPU 都被困在争夺同一个“list_lock”，导致处理器无法使用。

本地 NFS 客户端恰好在冻结的 NUMA 节点上，无法获得 CPU 时间，该客户端的活体探针超时并报告节点异常。Kubelet 试图通过“SIGTERM”和“StopContainer”操作控制损害，但内核拖得很慢——重新分配脏兮兮的“inodes”——花了两个多小时才响应终止请求。

最终结果是 Crusoe 又发了一封“NotReady”邮件——这封邮件独特地位于旧 CPU 内核的下游。

测试结束时，这个内核不仅老旧且性能不佳，还被正式标记为安全漏洞CVE-2026-64378该项目利用了错误的回写行为，于7月25日发布，严重度为7.8;该内核有独立的7.8版本发布于7月27日。

因此，我们将Linux内核加入了我们暴露于CVE的Crusoe软件收藏中。Crusoe通知我们，他们将升级为6大Linux内核，这是必要的补丁。

当我们在 Crusoe 的 Kubernetes 层上运行 XID 注入时，错误很快被检测到并触发了“节点替换”流程，但由于 Slurm 命名规则不匹配，未能将该节点放入“排水”，该节点未能通过 Crusoe 的 CI 检测。

健康监测系统反复发现错误，尝试但未能将节点标记为不健康。Crusoe 的工程团队迅速诊断错误，数小时内推出了替换节点。然而，我们的替换节点存储网卡故障，立即进入“清除”状态。

该问题在节点虚拟机被手动重置后依然存在。Crusoe的工程团队告知我们，AutoClusters未能在后者事件中进行修复是“已知的漏洞”，他们将在“几周内启动自动修复行动”。

这对基本的可靠性故障反应出人意料地迟缓。

最后，简要提一下，这个集群的广域网是我们测试过的最慢之一，时钟速度在0.47 Gbps到0.78 Gbps之间，具体取决于具体情况。冰岛有一些细长的电缆可以离开岛屿。

所有这些问题汇聚成了一个臭名昭著的不稳定集群，正如我们朋友们在Frontier Labs抱怨失败次数以及Crusoe工程师显然缺乏及时修复兴趣所证实的那样。

需要说明的是，我们曾一度将Crusoe视为全球#2的neocloud，因此是全球#2的GPU租赁场所。我们为此提出了建议。哦，昔日的强者如今已衰落。

不过，虽然Crusoe的机器镜像急需更新，工程师们也无法获得Claude Tags或Codex的批准，但他们内部Slack里确实设置了类似的自动化：

2025年11月的CVE算作“历史包袱”吗？

说正经的，这是优先级的问题，是官僚主义失控的问题。我们不确定该如何看待像上面那样的高级Linux内核工程师职位发布。我们只是请求大家保持信息更新。

你不需要雇佣林纳斯来理解这为何合理。所以，虽然看到克鲁索展示实力，花高价请一个好人很酷，但克鲁索来到这里的并不是人手不足、资金不足或技术技能不足。

我们的抱怨集中在最基本的问题上，而不是弹簧配置或控制台或CLI这无疑会占用更多工程时间，而我们很享受使用它。

我们很享受与Crusoe工程团队合作，并相信他们拥有大量人才来提升自身声誉。坦率地说，过去几个月，情况似乎正在回归正轨。工程师们专注于开发代码，对即将发布的版本充满期待。

Atero的收购价值连城，使Crusoe在推理端点质量方面跃居众多买家的首选。我们很高兴看到这一点。

不过，在托管集群领域，Crusoe的集群极其不可靠。

《漂流记》在本轮铜奖组中排名靠后。

主智者

主智者今年7月完成了一笔1.3亿美元的A轮融资在10亿美元估值披露了1亿美元的“年化收入运行率，涵盖计算、强化学习和后期培训、沙盒、推理、环境和评估。”

我们测试了 Slurm 和 Kubernetes B300 集群，并且大部分都喜欢 Prime Intellect 的编排层，尽管每个层都缺少一些我们希望拥有的软件包。巨大的 Slurm 控制平面非常漂亮且敏捷，由于某种原因拥有 2TB RAM 的机器。充足的交换空间可供运行 萨洛克.

在快速修复标准化 NCCL 引导接口后，我们的网络测试在 ConnectX-8 NIC 上运行了多达 13 个节点，并具有出色的吞吐量。使用 Weka，存储不再是问题 /数据 卷在 4 个节点上表现良好，并且可以稳定扩展。 PrimeIntellect 的托管 Grafana 是我们遇到的更好的之一。然而，我们所在的集群仍在经历老化，因此我们看到了源源不断的错误。测试系统监控和健康检查的简单方法！

首先，我们的 Kubernetes 集群上的一个节点被标记 未准备好，显然是由于现场技术人员对相邻服务器的胡闹； 5 分钟内就返回了。然后，在 PyTorch 网络测试期间，另一个 Kubernetes 节点停止发布 kubelet 状态，并且分布式作业无法完成；节点在重新启动后恢复并完成作业。第二天，2 个 Slurm 节点出现故障，其中一个出现 NVLink 问题，另一个在重新启动后卡住。两者在干预后都立即返回，但后者很快又再次意外重启，导致存储测试失败。 MPI 测试在最后阶段中止，相应的 Slurm 作业仍保留在 正在完成 因为在我们将集群交还之前的短时间内，所有工作人员仍然无法联系到。

所有这些可靠性问题都可以归咎于我们在一个小窗口内进入这个集群，而他们仍在为付费客户进行老化。很公平。但 Prime 缺乏可用的计算资源，无法保留热备件，这表明容量限制日益严重，这是一个更大的问题。 Prime 是其他计算的经销商，依赖其底层提供商来保证客户获得高质量的体验。这带来了高质量的培训/强化学习框架、仪表板和来自优秀工程师团队的疯狂 Slack 参与始终无法掩盖的挑战。

话虽如此，Prime 的健康检查自始至终都表现出色，能够快速干预并限制每个错误的损害。我们认为系统的默认响应是合理的，甚至喜欢 Slack 警报，团队立即跟进了。鉴于 Prime 从许多提供商那里获得了容量，因此他们的软件层的质量对于实验室对他们所获得的产品感到满意非常重要。在我们测试过的市场中，Prime 似乎是最好的。

这给 Prime Intellect 留下了一项简单的任务，而我们无法直接洞察这一任务：提高可靠性，构建计算能力的基本负载，并作为真正的新云提升排名。我们对团队的技术能力毫不怀疑；他们在这个集群上正确地完成了许多困难的事情，并且是这个列表中唯一将真实经验培训模型注入到他们的软件和支持方法中的提供商。无论好坏，他们在其他地方的工作比这里评估的基本管理计算产品更令人印象深刻。

我们在此期间预览了他们托管的培训产品，印象非常深刻。 RL 基础设施显然比简单的托管 Slurm 或 Kubernetes 集群更复杂，因为它构建在相同的基础之上，但具有需要保持同步的三个组件:

训练
推理
沙箱/环境

很快，我们将通过一个暂时称为 PostTrainingX 的项目来评估托管培训基础设施提供商和 RLaaS 公司的招聘情况。如果我们必须对这些排名进行初步削减，那么 Prime 将会争夺白金！

敬请关注。

数字海洋

这标志着我们首次能够获得完整的 DigitalOcean 开发者体验的测试轮次。营销本身作为“首个为推理和代理时代端到端构建的云”，DigitalOcean 将自己与“以裸机为中心的新型云以及缺乏云平台的推理封装”区分开来。

简而言之：DigitalOcean 销售的产品中包括托管集群。

DigitalOcean 的托管集群由 Kubernetes 编排，虽然稳定但略显不成熟。他们的入门文档要求我们自己安装 Multus，然后创建网络附件，安装 MPI 操作器，并创建 MPIJob 清单。

没有理由不提前为客户设置好。一旦配置完成，我们的集群表现良好，达到了计算和 XDR 网络的所有标准基准测试，并且烧机测试顺利完成。

集群开箱即用时也缺少 RWX StorageClass，这增加了另一个基本的设置步骤，而更好的 K8s 提供商会为你处理好。一旦配置了存储，其性能表现很有趣：顺序写在不同客户端数量下大约比顺序读快 6 倍，这与我们在大多数集群上看到的情况相反。

我们预计，通过重新调优，DigitalOcean 的顺序读取性能可以显著提升。

当我们去测试健康检查时，我们的第一次 XID 注入没有被发现：监控系统没有检测到任何异常，节点仍然可用于调度。当我们提醒 DigitalOcean 团队时，他们迅速做出响应，发现了系统中的错误，并要求我们在本周晚些时候重新进行测试。

第二次尝试顺利进行，注入后 50 分钟我们就有了一个新的节点。

当一个新型云被“端到端构建用于推理”时，这意味着它不提供 Slurm。DigitalOcean 团队贴心地为我们提供了一个运行 Slinky 的操作手册，它把基本内容做对了，但在被认为可用于生产环境之前，还需要大量工作。

没有 SSH 访问权限，也没有前面提到的任何 RWX 卷，这意味着没有地方可以存放 `/shared`。任何计划在 DigitalOcean 上运行 Slurm 的人都应该准备自己搭建编排环境。

数字海洋将在整个2027年增加60兆瓦的产能，而且，除了其托管的 K8s 外，它还有一系列有趣的 GPU 服务，例如液滴和裸机 Hopper 和 MI300X 不属于 ClusterMAX 测试范围。但目前我们还没有针对 GB 或 VR 的计划。我们期待团队在下次测试时继续改进其托管 Kubernetes 服务。

超栈

Hyperstack 隶属于母公司 NexGen Cloud，是一家总部位于英国的 Neocloud，在美国、加拿大和挪威宣传 Kubernetes 集群。最近它以 3.54 亿美元的估值筹集了 4500 万美元计划对众多AI新产品进行“全周期开发”。

” 它宣布提供 3400 万美元的债务融资来建设 B200 机队，它还透露计划在今年晚些时候部署 4,500 台 B300，并在 2027 年额外部署 56 MW。

我们测试的托管 Kubernetes 集群标志着自 ClusterMAX 2.0 以来的重大进步，并为其持续增长奠定了坚实的基础。计算和网络测试均符合规格，并且老化持续良好，没有出现硬错误。我们的 Kubernetes 节点重启恢复很快，并且挂载和卸载 PersistentVolume 没有遇到任何问题。 N/S 网络很好，存储也足够好，尽管我们无法在我们的时间线上获得 Hyperstack 通常提供的 Weka 和 VAST。

我们的合成 XID 在不到一秒的时间内就被检测到，带有“NvidiaFatalXid=True”标志。该测试很尴尬，因为 Hyperstack 没有额外的容量，因此我们必须从我们的队列中取出一个节点来模拟备用节点。支持团队通知我们，他们在我们注入后 12m 后检测到了错误，而我们的备件在总共 52m 后重新加入了车队。有趣的是，此时“病态”节点仍未被封锁，直到 1 点 30 分才在 Kubernetes 层注册。这一切都是由 Hyperstack 的 SRE 团队在我们的合成错误触发 Grafana 警报后进行的手动干预推动的。

总的来说，这次测试是成功的，我们感谢 Hyperstack 致力于帮助其顺利进行。然而，正如团队所知，所需的人力支持数量让我们担心其可复制性。 Hyperstack 提供 24/7 支持，并且目标是在发生单节点故障时在 60m 以内进行干预，但最好不要指望另一个工程团队在集群恢复完全健康之前按下正确的按钮。

我们测试期间唯一的彻底错误是两个 Pod，“cilium-envoy”和“csi-hyperstack-node”，因“打开文件太多”而发生崩溃循环。这是一个小麻烦，并没有影响我们的工作流程。

我们期待继续与 Hyperstack 合作，帮助他们发展团队、获得管理大型集群的经验，并继续自动化和强化其基础设施。

参与丝带

乌尔特尔

Vultr 将自己宣传为 “全球最大的私营云基础设施公司，”它们并非如此，以及“世界上最大的私有超大规模云服务提供商，“即使他们是，也不会如此。不过，他们在新云领域仍然是一个相关的参与者，拥有现代的GB300和MI355X，包括声称的50 兆瓦 AMD 站点在俄亥俄州。在，Vultr 的集群交付时带有一些基本错误。不幸的是，几乎一年后情况仍然相同。

Vultr 为我们的测试构建的镜像包含许多具有适用 CVE 的库，包括 CUDA、DCGM、Docker、runc 和 ConnectX 固件。我们的 Slinky 登录 Pod 没有挂载 `/shared`，并且缺少 Pyxis plugstack 配置，因此我们不得不从工作 Pod 进行编排，直到 Vultr 支持团队在活动中期重新配置登录 Pod，解决了这两个问题。

K8s 层可见的存储还有另一个基本问题：默认存储配置与我们的裸金属集群不兼容。默认的 StorageClass `vultr-block-storage` 可以无投诉地配置和绑定，但 Pod 却一直处于 `ContainerCreating` 状态。

然而，附加在工作节点上的 Lustre 层非常出色，在 32 个客户端上的聚合读取速度达到了 91.7 GB/s。Grafana 已配置，但只有部分正确，由于 `DCGM_FI_PROF_NVLINK_*` 字段未配置，NVLink 读取为 0。

众所周知，Vultr 在其扩展网络的可靠性方面一直存在问题，这使得合作伙伴对开始或扩大现有交易感到犹豫。我们建议 Vultr 继续提高其集群的稳健性，并努力创建配置合理且保持最新的所有相关工具和编排的标准镜像。

船

Vessl 是一家新的韩国新型云公司，它自认为是“多云编排器”而非经纪商，长期购买裸机，并在其上提供带有服务级别协议的管理层。他们领取目前正在使用的 5,000 个 GPU 并制定了到 2027 年底实现 100 兆瓦的宏伟目标。旧的 Vessl BizOps 职位发布说期待“速度”。我们必须快速行动、快速学习、不断迭代，“苛求”。”

我们热爱野心；然而，Vessl 集群的不成熟（我们在 Kubernetes 和 Slinky 风格中进行了采样）给了他们很多工作要做。我们的入职培训始于通知固定三个设置以使 RDMA 结构可用。平视总比没有好，但我们更希望获得一个开箱即用的性能良好的集群。

第三个要点是针对一个特别繁琐的配置：默认情况下，由于 Vessl 的 Kubernetes `LimitRange`，每个容器如果使用超过 2GB 的主机内存就会出现硬故障。尽管防御性默认在某些情况下可能有意义，但这是一个糟糕的设置。节点很少被要求一次运行多个作业，因此容器可以期望使用所有主机 DRAM（数百 GB），而 OOM 杀死它们超过 2 GB 是令人窒息的。我们建议Vessl放宽这个限制，使其符合宿主的物理能力，同时也让失败更加优雅。

在管理方面，Vessl 没有提供任何方法来处理 Slinky 层上的用户，除非通过机器上的传统 Linux 工具。我们从控制台添加的 SSH 密钥没有显示在集群上，我们通过 Vessl CLI 添加的密钥也没有显示在集群上；我们后来了解到，这些实用程序独立于 Vessl 的 Blackwell 集群。因此，我们只能使用 Slack 上发给我们的私钥和“kubeconfig”。

集群提供了一个合理的（虽然奇怪）“add-user”方便脚本来创建新的 Linux 用户。

然而，它没有提供像“pip”、“git”甚至“sudo”这样的基本包。

因此，集群花了一些功夫才到达起跑线。但我们的实习生还没有完成担任 Linux 系统管理员的工作。 Vessl 使用临时 OverlayFS 根运行 Slurm 登录节点，因此对 `/etc/passwd` 和 `/usr/bin` 的运行时更改仅存在于容器的可写层中，并且当 Kubernetes 回收 pod 时不会保留。这导致我们的用户在测试中途消失。

另一个 Slinky 错误配置导致部分测试中的 Slurm 层崩溃。我们的工作负载写入了他们没有清理的覆盖层，在根卷中累积了 863 GiB，导致 Kubernetes 标记节点“DiskPressure”并重新启动它。这不仅导致本地工作进程崩溃，还导致 Slurm 控制器守护进程崩溃，导致整个 Slurm 层间歇性无法访问。我们推断“slurmctld”被调度到也运行“slurmd”的节点上。与“slurmctld”共同调度“slurmd-pyxis” Pod 通常是一种不好的做法，其原因可以通过以下轶事充分说明：数据平面不应因控制平面的管理职责而陷入困境，并且控制平面不应位于数据平面的爆炸半径内。 Vessl 通过让 Enroot 写入更大的卷来迅速止血，但据我们所知，根本原因——共同调度的工作人员和控制器——仍然没有得到解决。很明显，Vessl 没有在生产环境中大规模运行 Slinky 的经验。

一个单独的错误导致 Kubernetes 访问不一致。我们的“kubeconfig”的“server”字段中的 URL 并不总是解析为相同的 IP 地址：除了公共 IP 地址之外，Vessl 还错误地将私有“10.x”IP 发布到记录集。有时，我们的“kubectl”命令解析为正确的（公共）IP，我们可以访问，但有时它会解析为错误的IP，我们的请求将挂起，直到重试完成。我们建议 Vessl 从公共记录集中删除“10.x”IP。

我们在 Vessl 集群的 Kubernetes 层上设置的“NetworkPolicy”被接受，但没有强制执行，因为所有租户 Pod 之间的 HTTP 请求都被接受，而不考虑定义的规则。 Vessl 没有配置健康检查程序，应优先考虑此程序以及上述所有平凡的“生活质量”功能。

Vessl 提供的硬件本身在整个测试中表现良好，包括通过 InfiniBand 进行的 NCCL 测试。鉴于 Vessl 拥有如此庞大的船队，宣称即将上线，因此它完全有动力强化其产品，为用户提供优质服务，并使其能够获得更优惠的价格。当我们下次测试时，我们将有兴趣观察 Vessl 的进展。

运行波德

Runpod 是一家 Neocloud，总部位于新泽西州穆尔斯敦，拥有 RTX PRO 6000、H100、H200、B200 和 B300 等设备。今年六月，他们以 10 亿美元的估值筹集了 1 亿美元，在 Twitter 上宣布从 2 月到 6 月，他们的收入翻了一番，达到 2.4 亿美元 ARR.

我们能够测试的集群位于西雅图，而且非常新，甚至还没有配置存储。我们的“即时集群”几乎是即时的，在 2 分钟内旋转完毕。

Runpod 的用户模型很不寻常。在理想情况下，我们通过带有 RBAC 的网络控制台管理权限，可以通过电子邮件添加团队成员，增加或减少权限，创建组，并放入我们的 SSH 密钥以自动同步到集群。

然而，利用其快速的资源配置，Runpod 建议按需创建即时集群。然后工程师以单租户方式操作他们的集群，并在完成后将其归还到资源池。

这意味着预算、监控以及其他相关策略是在集群之上进行管理的，而不是通过传统工具如 Linux 用户管理或 Slurm 账户管理。Runpod 的设计选择是可行的，但显然我们最终并没有按照建议的方式使用集群，而是更愿意回归更熟悉的模式，即创建与我们的 SSH 密钥相关联的 Linux 账户。

我们的第一次烧机测试失败，因为我们的一个节点在两个网卡上的端口1链接下线，怀疑是叶子交换机的问题。没有健康检查来捕捉到这个错误，但有一个 Grafana 仪表板，如果你知道该看哪里，会显示出错误。

根据我们的反馈，Runpod 团队快速改进了仪表板，使 InfiniBand 状态更容易被发现。

在第二次烧机尝试中，网络性能良好，测试顺利完成，没有出现错误。

这个集群是如此新，以至于没有共享的文件系统可供测试。不过在软件方面，我们的初步审计发现有许多需要改进的地方。出于安全原因，CUDA 工具包、GPU 驱动程序和网络接口卡固件都已被弃用，而且 CUDA 工具包还存在额外的风险，因为12.8 不支持 SM103，B300 SM 架构。

这导致我们的一些基准测试第一次尝试就失败了。集群也缺少许多预期的工具，没有容器运行时，许多基本的 HPC 软件包也不存在。Slurm 有时还会将等待中的作业标记为 `InvalidAccount`，这阻止了作业运行，即使设置了 `AccountingStorageEnforce=none` 和 `AllowAccounts=ALL`。

解决方法是不断运行 `scontrol update JobId= Account=me`，直到 Slurm 接受为止。

我们还看到一个节点在镜像提取填满我们 50 GB 的根覆盖层（该覆盖层与 `/var/spool/slurmd` 共享）时被清空，导致 `slurmd` 无法写入。

我们的租户没有 `scontrol update` 的凭据，所以我们的测试只能缺人手继续进行。另外，Linux 拒绝了 `unshare -Ur`，所以我们不得不改用 `udocker` 来运行。

我们的标准 XID 注入路径被阻止，因为我们没有权限写入 `/dev/kmsg`；我们没有机制来发起节点重启；默认情况下没有启用免密码 `sudo`。

这里的主题很清楚：在 Runpod 环境中，用户缺少完成工作所需的许多权限。

我们发现 Runpod 团队格外乐于接受反馈，并且热衷于解释他们的决定。我们喜欢这一点他们大多数的职位发布都是严肃的工程岗位，我们希望他们能继续努力，在易用性和开发者控制之间取得更好的平衡。

比特迪尔

Bitdeer是ClusterMAX 2.1版本中新增的测试内容。作为另一家转向人工智能的加密矿工，Bitdeer的总电容量已达到令人印象深刻的1.75GW根据其最新公告.然而，这主要供给加密货币挖矿设备：我们的半分析数据中心行业模型估计，他们只有少数几个AI中波在线.不过，Bitdeer正积极转向利润率更高的GPU业务，未来几年已有数百兆瓦的设备在筹备中，正在诺克斯维尔、温纳奇、福克斯克里克和罗克代尔，以及挪威和马来西亚的站点（无论是已转换还是已转换）。

Bitdeer希望实现垂直和横向业务增长，他不满足于单纯的合作协议，推出了从代币即服务到托管代理，当然还有托管集群的初兴方案。

我们花了很多时间试图弄清楚Bitdeer在公共控制台给我们点数时到底期望我们测试什么。健康检查未设置，监控仪表盘无法正常工作，许多基础库如PyTorch和Docker未安装，网络设置空无一物，IMEX未配置，控制台也不支持RBAC等普通便利设施。

Bitdeer的监控安装程序下载了错误CPU架构的二进制文件。SSH最终成功了，但奇怪的是需要RSA密钥而非ed25519。Kubernetes查询多次断开连接。

简而言之，该集群的管理非常基础。最多能说的是它配备了GPU驱动、NCCL、CUDA，以及操作系统和内核，且都足够现代化。

一旦有时间设置，性能就很好。GPU在烧屏时达到了预期数值，NVLink也支持预期流量。

参与讨论