ClusterMAX 3.0 评级回归，低价 GPU 云面临更严峻考验
尽管行业仍通过简单的可用性和成本主张来销售基础设施，ClusterMAX 3.0 评级已对 77 家 GPU 云服务商进行了更全面的测试。SemiAnalysis 在测试托管集群并访谈超过 200 名 neocloud 用户后，于 2026 年 9 月 23 日发布了这项新评估。
核心结论并非某一家服务商拥有最快的 GPU，而是可用计算能力取决于 GPU 周边的一切。网络、存储、调度器、监控、安全性和支持服务，共同决定昂贵的加速器是能产出有效工作，还是只能闲置。
这一差异给主要依靠低租赁价格或稀缺硬件供给竞争的服务商带来了压力。CoreWeave 仍是技术标杆，Nebius 则与其一道进入最高梯队。Google Cloud 也有所提升，但一些知名服务商排名下滑，或已无法接受测试。
ClusterMAX 3.0 评级提高了对 77 家服务商的门槛
ClusterMAX 3.0 将 GPU 云评估转变为运营能力测试，而非加速器名称和宣传价格的对比。
新版覆盖 77 家获得评级的服务商，并将 SemiAnalysis 的整体市场追踪范围扩大至 323 家公司。上一主要版本为 84 家服务商评级，同时追踪 209 家公司。最新评估中，仅有 19 家服务商获得奖章评级。
这些数字需要谨慎解读。获得评级的服务商数量减少，并不必然意味着市场萎缩。SemiAnalysis 还追踪了其他公司，其中一些无法测试、缺乏足够相关性、服务于受限市场，或尚未推出符合条件的托管服务。
该评估聚焦于托管集群。这类环境中，服务商承担的不只是提供物理服务器，还负责重要的运营层工作。这可能包括编排、监控、故障检测、硬件更换、存储、网络管理以及持续的技术支持。
评估范围排除了若干相邻业务。简单的裸金属租赁、基于 token 的推理服务、后训练平台和 agent 沙箱服务，均不会得到同等评估。一家公司可以运营有用的 GPU 基础设施，却未必符合优秀托管集群服务商的资格。
这一边界之所以重要，是因为“GPU 云”一词如今涵盖了截然不同的产品。一家供应商可能交付服务器，并要求客户管理所有软件层；另一家则可能维护调度器、排查故障节点，并保持可替换的备用容量。
SemiAnalysis 通过十个类别评估这些差异，包括安全性、生命周期管理、编排、存储、网络、可靠性、监控、定价、合作伙伴关系和可用性。其公开的评级标准说明了各类别中应具备的能力。
最终等级是相对评价，而非通用认证。服务商的排名取决于其在当前方法论下相对于同行的表现。因此，即便服务没有明显恶化，更高的标准也可能让一家公司排名下降。
ClusterMAX 3.0 在 Bronze 与 Underperforming 之间新增了 Participation Ribbon 类别，共有 15 家服务商进入这一等级。SemiAnalysis 将其用于满足基本要求、但尚未具备推荐托管集群所需运营成熟度的服务。
报告也带来了顶级服务商的显著变化。Nebius 从 Gold 升至 Platinum，与 CoreWeave 并列。Google Cloud 与 Oracle 一同进入 Gold，Azure 则降至 Silver。GMI 从 Bronze 升至 Silver。
其他变动则不那么有利。Crusoe 降至 Bronze，而 Fluidstack 被归入 Unavailable 类别，因为 SemiAnalysis 无法完成充分验证。Lambda、Firmus 和 TensorWave 则维持 Silver。
这些变化确立了报告的主要冲突：服务商可以获得新 GPU、宣布建设大型设施，却仍可能在维持集群生产效率的不显眼系统上落后。
完整的 ClusterMAX 3.0 report 也不仅是一份排名。它将技术测试与客户访谈、合同预期以及针对服务商的运营发现联系起来。
这种结合为买家提供了比基于峰值基准成绩的排行榜更可靠的起点，也为服务商提供了一份公开清单，列出成熟客户日益期待的能力。
可靠性比 GPU 峰值性能更重要
当故障组件仍可被调度、任务反复重启，或支持团队无法快速恢复容量时，再快的集群也会失去优势。
SemiAnalysis 向每家参与服务商申请了 32 块 GPU。首选配置为四个八 GPU 的 HGX 节点，或 NVL72 部署中的八个四 GPU 节点。同时还要求提供高带宽网络和两种形式的存储。
每个环境都需要至少 10 TB 的高性能文件存储，以及至少 10 TB 的 S3 兼容对象存储。服务商还被要求提供监控仪表盘。
测试覆盖 Slurm 和 Kubernetes。Slurm 是广泛用于大型计算任务的调度器，而 Kubernetes 负责管理跨集群的容器化应用。SemiAnalysis 要求每个环境提供五天测试时间，不过服务商可以并行运行这些测试周期。
硬件要求也随之升级。SemiAnalysis 将 Nvidia B200、B300、GB200 和 GB300 系统，以及 AMD MI355X 基础设施视为可接受方案；在本次评估中，H100 系统被视为较旧的一代。
流程从配置审计开始。审计涵盖硬件清单、固件、驱动程序、容器支持、调度器设置、网络、存储、监控和安全性。其公开的集群审计工具会报告通过项、警告项、失败项和跳过项。
随后，性能测试检查 GPU 计算、网络行为、存储、生命周期运维、训练和推理。SemiAnalysis 同时采用微基准测试，以及旨在暴露集群内部交互问题的工作负载。
训练测试包括 Llama 3.1 8B 预训练和混合专家工作负载。混合专家模型会针对每个输入激活选定的组件网络，从而在加速器之间形成高要求的通信模式。
第二种工作负载有助于揭示孤立 GPU 基准测试可能遗漏的网络问题。一台服务器或许能取得很强的矩阵乘法结果，但集群可能在节点间的集合通信中损失大量时间。
推理测试的作用类似。它们考察计算受限、内存受限和通信受限的情况。如果网络无法通过持续的集合通信测试，系统就无法在大规模运行时维持有效的 token 吞吐量。
随后，ClusterMAX 将评估从速度延伸至可靠性。SemiAnalysis 进行八小时老化测试，同时对 GPU 和网络施压。测试跟踪温度、功耗、时钟频率、计算、延迟、带宽、连接性和内核错误。
同步施压十分重要，因为真实工作负载会同时加热多个组件。分别测试 GPU 和网络，可能会遗漏持续全集群负载下由热或电气交互引发的故障。
评估人员还会注入故障。他们可以将合成的 Nvidia 错误消息写入内核日志，或通过 PCIe bridge 触发真实连接故障，随后测量检测和恢复情况。
一项成熟的服务应能识别故障节点、停止向其调度任务，并开始修复。对于传统 HGX 集群，理想响应通常包括使用热备节点替换受影响节点。
机架级 NVL72 系统带来了更棘手的问题。它们的 GPU 共享紧密连接的 NVLink 域，因此运营商并不总能在不影响更大机架的情况下更换一个小单元。服务商需要针对降级系统制定不同的操作流程。
SemiAnalysis 通常希望健康检查能在两分钟内发现不健康节点。这一目标将“可靠性”从营销主张转化为可观察的响应流程。
仅检测故障还不够。监控系统必须识别故障组件、受影响任务、调度器状态，以及每次健康检查的新鲜度。当底层数据已经过期时，绿色仪表盘也会产生误导。
自动修复又增加了一层复杂性。系统可能隔离节点、重置 GPU、重启软件，或启动硬件维修。正确响应取决于错误类型，而草率的自动重启可能破坏原本健康的工作。
Nvidia 记录了涵盖多种不同故障情况的 GPU error codes。错误相互重叠时，恢复工作需要运营判断，而不只是安装监控软件。
这正是峰值速度并非完整采购指标的原因。买家最终获得的是 goodput，即在计入故障、重启和运营延迟后完成的有效工作。
当研究人员反复排查基础设施问题时，较便宜的集群反而可能变得更昂贵。损失的时间包括闲置的 GPU、中断的实验、延迟的模型发布，以及从产品工作中被抽走的工程精力。
低价 GPU 云如今要与总运营成本竞争
ClusterMAX 3.0 将采购问题从每小时价格，转向获得可靠、可用计算能力的成本。
公开租赁价格仍然易于比较，可靠性、支持质量和恢复时间却很难填入采购表。但这些因素往往决定一次大型训练运行的最终成本。
设想一个为模型开发租用多节点集群的团队。一块故障 GPU 可能拖慢同步任务中的每个参与方。一个滞后进程，通常称为 straggler，会迫使系统其余部分等待。
在性能下降的同时，客户仍在消耗容量。工程师可能要花费数小时搜索日志、隔离节点并重新运行测试。低廉的宣传价格几乎无法防范这类浪费。
CoreWeave 仍为 Platinum，因为 SemiAnalysis 发现其集群在关键类别中表现强劲。报告称，其健康检查按预期运行，且大多数测试无需大量干预便达到了预期结果。
该公司还增加了 GPU straggler 检测功能。根据其监控文档，该功能会分析通信遥测数据，以帮助识别拖慢分布式任务的工作进程。
这一功能体现了高端服务的逻辑。真正有价值的产品不只是获得加速器的使用权，而是一套能在用户手动搜寻整个集群之前发现隐蔽问题的系统。
Nebius 现已与 CoreWeave 一同进入 Platinum。SemiAnalysis 将其描述为在各类别中持续表现强劲，并积极参与短期集群市场。对于没有 hyperscaler 级别长期承诺的初创公司而言，这一定位十分重要。
Google Cloud 晋升至 Gold 带来了另一种对比。超大规模云服务商拥有丰富的基础设施经验、更广泛的安全计划和成熟的服务组合。然而，其通用平台并不总能围绕托管式 AI 集群优化每一项工作流。
Oracle 保持 Gold，并因其横向扩展网络设计获得认可。横向扩展网络可将系统连接到单个高度集成服务器或机架之外，使训练任务能够跨更多 GPU 运行。
Azure 降至 Silver，表明企业规模并不会自动在这一方法论下带来最佳的托管集群体验。ClusterMAX 评估的是交付的环境，而非提供商的总工程预算。
结果也挑战了人们对新兴 neocloud 的一个常见假设。专业化有助于它们围绕 AI 工作负载构建服务，但并不保证具备良好的编排能力、可靠的存储、最新的软件或快速的支持服务。
一些提供商对裸金属买家仍然很有吸引力。大型 AI 实验室通常拥有能够管理调度器、监控和恢复工作的内部团队。这些客户可能更偏好直接控制，并接受较少的托管功能。
较小的实验室面临不同的考量。它们可能缺少了解网络拓扑、GPU 错误处理、分布式存储和任务调度的专家。托管服务可以替代它们难以招聘到的专业能力。
智能体编程让这种差异变得更复杂。SemiAnalysis 发现，编程智能体帮助其团队处理缺失的文档和重复性的管理工作。这可能使经验丰富的运营人员更能接受轻度托管的基础设施。
同样的智能体也生成过错误配置。它们有时会选错网络、测试本地存储而非共享存储，或将 GPU 工作调度到 CPU 节点上。
因此，AI 辅助并不会消除运维知识的价值。它会放大那些本就理解预期结果的团队的能力。经验较少的用户则可能收到看似合理、却会悄然使性能测试失效的指令。
对买家而言，实际比较包含四个层面：
计算资源交付
提供商是否交付了承诺的加速器代际和配置？
实测计算性能是否符合合理预期？
集群集成
网络、存储、Slurm 和 Kubernetes 是否能在真实负载下协同工作？
用户是否无需进行大量手动调优即可复现良好结果？
运维恢复
平台能否检测故障硬件并将其从调度中移除？
提供商能否在不需要客户长期介入的情况下恢复可用容量？
商业责任
合同是否明确规定停机时间、验收测试、服务抵扣和退出权利？
当需要进行物理维修时，提供商是否清晰沟通？
这一框架使宣传价格仅成为一个输入因素。真正有意义的分母是已完成的工作，而非预留的 GPU 时间。
安全性是 GPU 云性能的一部分
如果过时的软件、薄弱的隔离或不完善的访问控制会暴露宝贵的模型和数据，那么该集群就不能被视为已具备生产就绪条件。
安全性在 ClusterMAX 3.0 中获得了不同寻常的重视。SemiAnalysis 认为，许多 neocloud 的 AI 基础设施投入已超过其基本防御实践的发展速度。
风险始于集群的复杂性。托管环境结合了操作系统、驱动程序、调度器、容器、存储、高速网络、仪表板和管理工具。每一层都会带来运营者必须维护的凭据、权限和软件。
遭入侵的管理节点所暴露的不止一台机器。它可能提供通往相邻系统、共享存储、模型检查点、专有数据集或客户环境其他位置所用凭据的路径。
高带宽集群网络同样假定组件之间存在高度信任。这种信任支持快速的分布式计算，但隔离不佳可能扩大单个系统遭入侵造成的损害。
因此，安全性以多种方式影响可用性能。一次入侵可能中止工作、触发事件响应、损坏结果，或迫使进行紧急修补。薄弱的控制措施还可能使提供商在任何基准测试开始前就不可接受。
SemiAnalysis 在初步审计中纳入软件和固件版本、访问配置、容器、网络设置和监控。该过程不能替代完整的渗透测试，但可以发现运维预警信号。
评估还审查认证和已记录的控制措施。SOC 2 或 ISO 27001 等认证并不能证明每个集群都安全，但缺少这些认证仍可能表明提供商缺乏基本的组织流程。
买家应在多个边界检查隔离措施，包括客户之间的隔离、租户内的权限、提供商员工的访问，以及围绕存储快照和备份的控制措施。
凭据管理同样值得重视。SSH 密钥、云令牌、服务账户和调度器权限可能会比预期存续更久。薄弱的离职流程会使一次常规的人事变动演变为持续性的暴露风险。
监控也带来其自身的安全权衡。提供商需要详细遥测数据来识别硬件故障和性能异常，但这种采集必须避免暴露敏感任务信息，或授予过度的仪表板访问权限。
随着 AI 智能体获得更多运维访问权限，压力也在增加。能够修改用户、提交任务或排查节点问题的智能体可以节省时间，也可能在宝贵的基础设施上执行错误命令。
SemiAnalysis 报告称，当环境提供明确的成功标准和详细上下文时，智能体最有用。这一观察将文档质量与安全性联系起来：良好的指引可减少临场发挥，并使自动化操作更易于审查。
该报告的批评仍需设定边界。ClusterMAX 并未公开披露每一项安全测试或每家提供商的每个结果。买家不应将其分级体系视为自身威胁模型的替代品。
提供商服务的客户有不同要求。研究原型、受监管的企业工作负载和前沿模型训练任务并不承担完全相同的风险。一个排名无法编码每个组织的风险容忍度。
不过，这一广泛结论很难被忽视。GPU 云承载着集中的算力、宝贵的知识产权，以及日益自主的软件。安全故障可能抹去由更低成本或更高基准性能带来的任何优势。
该排名很有用，但并非普适性结论
ClusterMAX 提供了异常详细的证据，但其结果仍是受范围、访问条件和方法论影响的测试快照。
第一个限制是配置规模。SemiAnalysis 通常请求 32 块 GPU，而大型客户可能运行由更多机器构成的集群。系统扩展时，性能和可靠性问题往往会发生变化。
在四个节点上表现良好的提供商，可能会在数百个节点上遇到不同的拥塞、调度或维修挑战。SemiAnalysis 通过客户访谈补充测试，部分原因正是一次评估无法复现每一种部署情况。
第二个限制是时间。该报告记录的是特定测试窗口内的环境。提供商会更新驱动程序、更换硬件、调整存储系统并重写编排工具。
SemiAnalysis 表示会随市场变化更新其评级。即便如此，买家仍应确认受评配置是否与其获得的区域、硬件代际和软件栈相匹配。
第三个限制是访问条件。一些提供商无法或不愿提供合适的集群。Unavailable 分类可能意味着容量有限、地域限制、延迟发布，或无法验证服务。
该类别并不等同于 Underperforming。前者反映证据缺失，后者反映已观察到的缺陷。采购团队应保留这一区别。
第四个限制涉及提供商的配合。SemiAnalysis 会在测试期间与公司沟通，尤其是在故障注入需要兼容监控时。这有助于产出有效结果，但不同于匿名采购。
提供商知道评估人员正在检查环境，因此有动力提供有利的配置并迅速响应。普通客户需要通过合同和参考资料确认能够获得类似待遇。
第五个限制是商业范围。ClusterMAX 对托管集群进行评级，因此可能低估有意专注于裸金属的供应商。对于拥有强大基础设施团队的企业，这类服务仍可能适用。
相反的问题也存在。复杂的门户或响应迅速的上手流程，可能在持续工作负载开始前就建立信心。长期可靠性仍比精致的初始体验更难验证。
客户访谈增强了该方法论，但也引入了另一层不确定性。公众读者无法独立检查每一次访谈、投诉或权重决策。最终综合判断由 SemiAnalysis 控制。
“行业标准”这一称谓应被理解为发布方的定位，并得到可见行业采用的支持。它不是政府标准，也不是正式认证框架。
尽管如此，这一方法论提升了一个充满复杂比较的市场的透明度。公开的评估概览说明，该过程结合了实操测试、文档审查和用户反馈。
相对评级结构也鼓励持续改进。当同行增加更好的监控、更快的修复能力或更清晰的合同时，提供商不能假定昨日的配置仍具竞争力。
对客户而言，正确做法不是将排名直接照搬到采购决策中，而是把报告当作一份问题清单，要求供应商以证据作答。
提供商能否在客户目标工作负载上复现其性能？能否展示近期恢复数据？合同是否在节点、机架、集群和站点层面衡量停机时间？
当设备位于托管机房时，谁负责物理维修？是否有热备件可用？当网络故障导致间歇性变慢而非完全中断时，会发生什么？
提供商如何在不造成未定义停机时间的情况下处理安全补丁？其支持人员可以获得哪些访问权限？客户能否导出日志和监控数据进行独立审查？
即使买家选择较低等级的提供商，这些问题也揭示了排名的重要性。ClusterMAX 为客户提供了协商保障措施的词汇，而不是让他们接受笼统承诺。
ClusterMAX 3.0 将支持与合同视为技术功能
最具影响力的改变，是将支持义务视为集群架构中可衡量的组成部分。
GPU 云协议通常将技术规格与商业保护分开。合同列出硬件、容量和可用性，而运维细节仍然模糊。
ClusterMAX 3.0 缩小了这一差距。SemiAnalysis 已针对传统 HGX 系统和机架级架构制定标准化服务等级概念，涵盖节点、机架、集群和站点。
该框架对停机时间作出定义，而不是让该术语留待解释。它还描述了客户验收交付前，涵盖 GPU 计算、网络、存储和软件的验收测试。
验收至关重要，因为集群即使已经通电，也未必已具备生产就绪条件。网络配置错误、存储无法访问、驱动程序过时或调度器集成故障，都可能使计费开始后可用工作的启动被延误。
一份可信的协议应明确服务何时达到可验收标准，也应说明供应商未能在该日期前达标时将如何处理。
SemiAnalysis 建议定期审查服务等级表现。这样一来，可靠性就成为持续履行的义务，而非仅在发生重大争议后才被评估的一项承诺。
该框架也承认合理的例外情况。计划内升级、安全补丁和物理维护可能需要停机。合同应对这些例外作出明确界定，而不应让每次中断都被笼统的维护条款掩盖。
支持质量可通过从故障发现到修复的流程进行衡量。供应商必须知道哪个组件发生故障，阻止新的任务流向该组件，并说明修复方案。
设施的所有权会影响这一流程。自行控制数据中心的运营商可以直接管理技术人员、备件和操作流程。使用托管机房的供应商则可能依赖另一家公司的远程协助排班。
两种模式并不存在天然优劣。关键在于，该运营安排能否在承诺的时间窗口内完成恢复。
在 Grace Blackwell 机架系统上，这一区别更加明显。直接液冷、高机架功率、基于 Arm 的主机处理器以及机架级 NVLink，带来了旧式 GPU 部署所没有的额外依赖关系。
单个组件故障可能影响更大规模的容量单元。维修流程必须考虑紧密互连的托盘和机架，而不能将每台八 GPU 服务器都视为可互换的独立单元。
即将到来的 Vera Rubin 一代将进一步提高对电力和网络的要求。SemiAnalysis 预计，这一架构转型的破坏性将低于从 Hopper 迁移至 Grace Blackwell 的过程，但供应商仍将面临运营层面的工作。
因此，对买方而言，支持能力应纳入技术评估。专业的响应团队、经过验证的流程、充足的替换备件和准确的遥测数据，将决定长期实际交付的性能。
同样的原则也适用于定价。不包含有效支持的费率，会将运营风险转移给客户。若能保护工程时间并确保任务完成，更高的费率反而可能提供更高价值。
ClusterMAX 并不会消除谈判。它让谈判中那些隐藏的部分更容易被识别。
GPU 云买家接下来应关注什么
下一个考验在于，随着硬件、工作负载和采购模式同时变化，ClusterMAX 的领先者能否保持优势。
第一个信号是新评级能否被独立复现。客户应将自身的验收测试和长期运行任务与 SemiAnalysis 的发现进行比较。一致的结果将增强该排名在单一评估窗口之外的价值。
第二个信号是供应商在部署 Vera Rubin 期间的表现变化。那些持续维持可靠 Grace Blackwell 系统的公司应当具备先发优势。不过，新的电力、网络和散热需求仍可能暴露容量规划和支持能力上的短板。
关注供应商是否公布清晰的交付时间表和运营目标。营销公告的重要性不及能够稳定运行客户工作负载的集群。延迟、配置变更和有限的区域可用性，将揭示每次部署究竟有多成熟。
第三个信号是 ClusterMAX 向推理端点、强化学习基础设施和智能体沙盒的扩展。这些产品带来的瓶颈与传统训练集群并不相同。
推理服务必须在延迟、吞吐量、模型加载和不可预测的需求之间取得平衡。强化学习系统需要协调生成、沙盒执行、训练以及频繁的模型更新。任何一个阶段的薄弱环节都可能导致 GPU 闲置。
这一扩展可能通过反映 AI 团队如今使用基础设施的方式来增强 ClusterMAX。它也可能使该框架更难解读，因为托管集群和基于 token 的服务解决的是不同问题。
买方还应关注安全披露。关于隔离、补丁、凭据和事件响应的更详细证据，将使供应商之间的比较更具依据。严重事件则会暴露性能测试无法捕捉的缺口。
最后，关注托管服务与裸金属之间的分野。大型实验室正在采购大量容量，同时自行运营更多软件栈。规模较小的团队仍需要供应商承担这类复杂性。
AI 智能体会让部分管理工作变得更容易，但不会消除对可靠系统的需求。该报告自身的测试表明，自动化能够解决常规问题，同时也可能自信地制造新的问题。
ClusterMAX 3.0 评级最终要求买方重新定义产品。他们并非只是单独租用芯片，而是在租用已完成的计算、恢复流程、安全控制以及经验丰富的运营人员支持。
在签署下一份 GPU 云协议之前，应要求供应商在故障情境下展示这些能力层。索取针对工作负载的基准测试、当前安全证据、恢复记录和精确的验收条款。随后比较各方案实际能够交付的已完成工作，而不只是它们各自承诺的容量。
