ClusterMAX 3.0 Ratings Return, and Cheap GPU Clouds Face a Harder Test

ClusterMAX 3.0 ratings put 77 GPU cloud providers through a broader test, despite an industry still selling infrastructure through simple availability and cost claims. SemiAnalysis published the new assessment on September 23, 2026, after testing managed clusters and interviewing more than 200 neocloud users.

The central finding is not that one provider owns the fastest GPU. It is that usable computing capacity depends on everything surrounding that GPU. Networks, storage, schedulers, monitoring, security, and support determine whether expensive accelerators produce useful work or sit idle.

That distinction places pressure on providers competing primarily through low rental rates or access to scarce hardware. CoreWeave remains a technical benchmark, while Nebius has joined it in the top tier. Google Cloud also improved, but several familiar providers moved down or became unavailable for testing.

ClusterMAX 3.0 Ratings Raise the Bar for 77 Providers

ClusterMAX 3.0 turns GPU cloud evaluation into an operational test, not a comparison of accelerator names and advertised rates.

The new edition covers 77 rated providers and expands SemiAnalysis's broader market view to 323 companies. The previous major release rated 84 providers while tracking 209. Only 19 providers received a medallion rating in the latest assessment.

Those figures require careful interpretation. A smaller rated group does not necessarily mean the market contracted. SemiAnalysis tracks additional companies that remain untestable, lack sufficient relevance, serve restricted markets, or have not launched a qualifying managed service.

The assessment focuses on managed clusters. These are environments where the provider handles important operational layers beyond delivering physical servers. That work can include orchestration, monitoring, failure detection, hardware replacement, storage, network management, and ongoing technical support.

The scope excludes several adjacent businesses. Simple bare-metal rentals, token-based inference services, post-training platforms, and agent sandbox services do not receive equivalent treatment. A company can operate useful GPU infrastructure without qualifying as a strong managed-cluster provider.

This boundary matters because the term “GPU cloud” now covers very different products. One vendor might deliver servers and expect the customer to manage every software layer. Another might maintain the scheduler, investigate failed nodes, and keep replacement capacity available.

SemiAnalysis evaluates those differences through ten categories. They include security, lifecycle management, orchestration, storage, networking, reliability, monitoring, pricing, partnerships, and availability. Its public rating criteria describe the capabilities expected within each category.

The resulting tiers are relative rather than universal certifications. A provider earns its position by comparing favorably with peers under the current methodology. Higher standards can therefore push a company downward even when its service has not visibly deteriorated.

ClusterMAX 3.0 added a Participation Ribbon category between Bronze and Underperforming. Fifteen providers entered that tier. SemiAnalysis uses it for services that meet basic requirements without delivering the operational maturity expected from recommended managed clusters.

The report also produced notable changes near the top. Nebius moved from Gold to Platinum alongside CoreWeave. Google Cloud joined Oracle in Gold, while Azure moved to Silver. GMI rose from Bronze to Silver.

Other movements were less favorable. Crusoe fell to Bronze, while Fluidstack entered the Unavailable category because SemiAnalysis could not complete adequate verification. Lambda, Firmus, and TensorWave remained in Silver.

These changes establish the report's main conflict. Providers can secure new GPUs and announce large facilities, yet still fall behind on the less visible systems that keep clusters productive.

The full ClusterMAX 3.0 report is also more than a ranking. It links technical testing with customer interviews, contract expectations, and provider-specific operational findings.

That combination gives buyers a stronger starting point than a leaderboard based on peak benchmark results. It also gives providers a public checklist of the capabilities that sophisticated customers increasingly expect.

Reliability Matters More Than Peak GPU Performance

A fast cluster loses its advantage when failed components remain schedulable, jobs repeatedly restart, or support cannot restore capacity quickly.

SemiAnalysis requested 32 GPUs from each participating provider. The preferred configuration was four eight-GPU HGX nodes or eight four-GPU nodes within an NVL72 deployment. It also requested high-bandwidth networking and two forms of storage.

Each environment needed at least 10 terabytes of high-performance file storage and at least 10 terabytes of S3-compatible object storage. Providers were also asked to supply a monitoring dashboard.

Testing covered both Slurm and Kubernetes. Slurm is a scheduler widely used for large computing jobs, while Kubernetes manages containerized applications across clusters. SemiAnalysis requested five days with each environment, although providers could run those periods in parallel.

The hardware requirement also moved forward. SemiAnalysis considered Nvidia B200, B300, GB200, and GB300 systems acceptable, along with AMD MI355X infrastructure. It treated H100 systems as an older generation for this evaluation.

The process begins with a configuration audit. That audit examines hardware inventory, firmware, drivers, container support, scheduler settings, networking, storage, monitoring, and security. Its public cluster audit tool reports passes, warnings, failures, and skipped checks.

Performance testing then examines GPU compute, network behavior, storage, lifecycle operations, training, and inference. SemiAnalysis uses both microbenchmarks and workloads intended to expose interactions across the cluster.

Training tests include Llama 3.1 8B pretraining and a mixture-of-experts workload. A mixture-of-experts model activates selected component networks for each input, creating demanding communication patterns between accelerators.

That second workload helps reveal network problems that isolated GPU benchmarks can miss. A server can produce strong matrix multiplication results while the cluster loses time during collective communication between nodes.

Inference tests serve a similar purpose. They examine compute-bound, memory-bound, and communication-bound conditions. If a network fails sustained collective tests, the system cannot preserve useful token throughput at scale.

ClusterMAX then moves beyond speed into reliability. SemiAnalysis runs an eight-hour burn-in that stresses the GPUs and network simultaneously. The test tracks temperatures, power, clock rates, computation, latency, bandwidth, connectivity, and kernel errors.

Simultaneous stress is important because real workloads heat multiple components together. Testing the GPU and network separately can miss failures caused by thermal or electrical interactions under sustained cluster-wide load.

The evaluators also inject failures. They can place synthetic Nvidia error messages into the kernel log or trigger a genuine connection failure through the PCIe bridge. They then measure detection and recovery.

A capable service should identify a failed node, stop scheduling work onto it, and begin remediation. For conventional HGX clusters, the ideal response often includes replacing the affected node with a hot spare.

Rack-scale NVL72 systems create a harder problem. Their GPUs share a tightly connected NVLink domain, so operators cannot always replace one small unit without affecting the larger rack. Providers need different operating procedures for degraded systems.

SemiAnalysis generally expects health checks to notice an unhealthy node within two minutes. That target converts “reliability” from a marketing claim into an observable response process.

Failure detection alone is insufficient. Monitoring must identify the failed component, affected jobs, scheduler state, and freshness of each health check. A green dashboard becomes misleading when its underlying data is stale.

Autoremediation adds another layer. The system might isolate a node, reset a GPU, restart software, or initiate hardware repair. The correct response depends on the error, and automatic reboots can destroy healthy work when applied carelessly.

Nvidia documents GPU error codes covering many distinct failure conditions. Overlapping errors make recovery a matter of operational judgment, not merely installing monitoring software.

This is why peak speed is an incomplete purchasing metric. Buyers ultimately receive goodput, meaning the useful work completed after accounting for failures, restarts, and operational delays.

A cheaper cluster can become more expensive when researchers repeatedly diagnose infrastructure problems. The lost time includes idle GPUs, interrupted experiments, delayed model releases, and engineering effort diverted from product work.

Cheap GPU Clouds Now Compete Against Total Operational Cost

ClusterMAX 3.0 shifts the buying question from hourly rates toward the cost of obtaining dependable, usable computation.

Published rental rates remain easy to compare. Reliability, support quality, and recovery time are harder to place on a procurement sheet. Yet these factors often decide the final cost of a large training run.

Consider a team renting a multi-node cluster for model development. A failing GPU can slow every participant in a synchronized job. One lagging process, often called a straggler, forces the rest of the system to wait.

The customer still consumes capacity while performance falls. Engineers may spend hours searching logs, isolating nodes, and rerunning tests. A low advertised rate offers little protection against that waste.

CoreWeave remains Platinum because SemiAnalysis found its clusters strong across the crucial categories. The report says its health checks worked as intended and that most tests reached expected values without extensive intervention.

The company has also added GPU straggler detection. According to its monitoring documentation, the feature analyzes communication telemetry to help identify workers that slow distributed jobs.

That feature illustrates the premium-service argument. The valuable product is not just access to an accelerator. It is a system that finds subtle problems before users conduct a manual search across the fleet.

Nebius now joins CoreWeave in Platinum. SemiAnalysis describes it as consistently strong across categories and active in the market for shorter-term clusters. That positioning matters for startups without hyperscaler-sized commitments.

Google Cloud's rise to Gold presents a different comparison. Hyperscalers bring extensive infrastructure experience, broader security programs, and mature service portfolios. However, their general-purpose platforms do not always optimize every workflow around managed AI clusters.

Oracle retained Gold and received credit for its scale-out network design. Scale-out networking connects systems beyond one tightly integrated server or rack, allowing training jobs to operate across far more GPUs.

Azure moved to Silver, showing that corporate scale does not automatically produce the best managed-cluster experience under this methodology. ClusterMAX evaluates the delivered environment, not the provider's total engineering budget.

The results also challenge a common assumption about newer neoclouds. Specialization can help them build services around AI workloads. It does not guarantee good orchestration, reliable storage, current software, or fast support.

Some providers remain attractive for bare-metal buyers. Large AI laboratories often have internal teams capable of managing schedulers, monitoring, and recovery. Those customers may prefer direct control and accept fewer managed features.

Smaller labs face a different calculation. They may lack specialists who understand network topology, GPU error handling, distributed storage, and job scheduling. A managed service can replace expertise they cannot easily hire.

Agentic coding complicates this divide. SemiAnalysis found that coding agents helped its team work through missing documentation and repetitive administration. This can make lightly managed infrastructure more tolerable for experienced operators.

The same agents also produced incorrect configurations. They sometimes selected the wrong network, tested local storage instead of shared storage, or scheduled GPU work onto CPU nodes.

AI assistance therefore does not erase the value of operational knowledge. It amplifies teams that already understand the desired result. Less experienced users can receive plausible instructions that quietly invalidate performance tests.

For buyers, the practical comparison has four layers:

Compute delivery

• Does the provider supply the promised accelerator generation and configuration?

• Does measured compute performance match reasonable expectations?

Cluster integration

• Do networking, storage, Slurm, and Kubernetes work together under realistic load?

• Can users reproduce good results without extensive manual tuning?

Operational recovery

• Does the platform detect faulty hardware and remove it from scheduling?

• Can the provider restore usable capacity without prolonged customer intervention?

Commercial accountability

• Does the contract define downtime, acceptance testing, service credits, and exit rights?

• Does the provider communicate clearly when physical repair is required?

This framework makes advertised pricing only one input. The meaningful denominator is completed work, not reserved GPU time.

Security Is Part of GPU Cloud Performance

A cluster cannot be considered production-ready when outdated software, weak isolation, or poor access controls expose valuable models and data.

Security receives unusual prominence in ClusterMAX 3.0. SemiAnalysis argues that AI infrastructure spending has outrun basic defensive practices at many neoclouds.

The risk begins with the cluster's complexity. Managed environments combine operating systems, drivers, schedulers, containers, storage, high-speed networks, dashboards, and administrative tools. Every layer creates credentials, permissions, and software that operators must maintain.

A compromised management node can expose more than one machine. It might offer paths to neighboring systems, shared storage, model checkpoints, proprietary datasets, or credentials used elsewhere in the customer's environment.

High-bandwidth cluster networks also assume substantial trust between components. That trust supports fast distributed computing, but poor segmentation can increase the damage caused by one compromised system.

Security therefore affects usable performance in several ways. A breach can halt work, trigger incident response, corrupt results, or force emergency patching. Weak controls can also make a provider unacceptable before any benchmark begins.

SemiAnalysis includes software and firmware versions, access configuration, containers, network settings, and monitoring within its initial audit. The process does not replace a full penetration test, but it catches operational warning signs.

The evaluation also reviews certifications and documented controls. Certifications such as SOC 2 or ISO 27001 do not prove that every cluster is secure. Their absence can still indicate that a provider lacks basic organizational processes.

Buyers should examine isolation at several boundaries. Those include separation between customers, privileges within a tenant, access by provider employees, and controls around storage snapshots and backups.

Credential handling deserves equal attention. SSH keys, cloud tokens, service accounts, and scheduler permissions can remain active longer than intended. Weak offboarding turns a routine staffing change into a persistent exposure.

Monitoring creates its own security tradeoff. Providers need detailed telemetry to identify hardware faults and performance anomalies. That collection must avoid exposing sensitive job information or granting excessive dashboard access.

The pressure grows as AI agents gain more operational access. An agent that can modify users, submit jobs, or troubleshoot nodes can save time. It can also execute a mistaken command across valuable infrastructure.

SemiAnalysis reports that agents were most useful when the environment offered clear success criteria and detailed context. That observation connects documentation quality with security. Good instructions reduce improvisation and make automated actions easier to review.

The report's criticism still needs boundaries. ClusterMAX does not publicly disclose every security test or every provider result. Buyers should not treat its tier system as a substitute for their own threat model.

Providers also serve customers with different requirements. A research prototype, a regulated enterprise workload, and a frontier model training run do not carry identical risks. One ranking cannot encode every organization's tolerance.

However, the broad conclusion is difficult to dismiss. GPU clouds host concentrated computing power, valuable intellectual property, and increasingly autonomous software. Security failures can erase any advantage gained through lower cost or higher benchmark performance.

The Ranking Is Useful, but It Is Not a Universal Verdict

ClusterMAX offers unusually detailed evidence, yet its results remain a tested snapshot shaped by scope, access, and methodology.

The first limitation is configuration size. SemiAnalysis generally requested 32 GPUs, while major customers can operate clusters containing far more machines. Performance and reliability problems often change as systems scale.

A provider that performs well across four nodes may encounter different congestion, scheduler, or repair challenges across hundreds of nodes. SemiAnalysis supplements testing with customer interviews partly because one evaluation cannot reproduce every deployment.

The second limitation is time. The report captures environments during a particular testing window. Providers update drivers, replace hardware, change storage systems, and rewrite orchestration tooling.

SemiAnalysis says its ratings are updated as the market changes. Even so, buyers should confirm whether a reviewed configuration matches the region, hardware generation, and software stack offered to them.

The third limitation is access. Some providers could not or would not supply a suitable cluster. An Unavailable classification can indicate limited capacity, geographic restrictions, a delayed launch, or an inability to verify the service.

That category is not identical to Underperforming. One reflects missing evidence, while the other reflects observed deficiencies. Procurement teams should preserve that distinction.

The fourth limitation concerns provider cooperation. SemiAnalysis communicates with companies during testing, especially when failure injection requires compatible monitoring. This helps produce valid results, but it differs from anonymous purchasing.

Providers know that evaluators are inspecting the environment. They have incentives to supply a favorable configuration and respond quickly. Ordinary customers need contracts and references that confirm similar treatment.

The fifth limitation is commercial scope. ClusterMAX rates managed clusters, so it can undervalue a vendor that intentionally specializes in bare metal. That service may still suit teams with strong infrastructure staff.

The opposite problem also exists. A sophisticated portal or responsive onboarding process can create confidence before sustained workloads begin. Long-term reliability remains harder to verify than a polished initial experience.

Customer interviews strengthen the methodology but introduce another uncertainty. Public readers cannot independently inspect every interview, complaint, or weighting decision. SemiAnalysis controls the final synthesis.

The title “industry standard” should therefore be understood as the publisher's positioning, supported by visible industry use. It is not a government standard or a formal certification framework.

Still, the methodology improves transparency in a market filled with difficult comparisons. The public evaluation overview explains that the process combines hands-on testing, documentation review, and user feedback.

The relative rating structure also encourages continual improvement. A provider cannot assume that yesterday's configuration remains competitive when peers add better monitoring, faster remediation, or clearer contracts.

For customers, the correct response is not to copy the ranking directly into a purchasing decision. It is to use the report as a list of questions that vendors must answer with evidence.

Can the provider reproduce its performance on the customer's intended workload? Can it show recent recovery data? Does the contract measure downtime at the node, rack, cluster, and site levels?

Who controls physical repair when equipment sits in a colocation facility? Are hot spares available? What happens when a network fault produces intermittent slowdowns rather than a complete outage?

How does the provider handle security patches without creating undefined downtime? What access can its support staff obtain? Can the customer export logs and monitoring data for independent review?

These questions reveal why the ranking matters even when a buyer selects a lower-tier provider. ClusterMAX gives customers a vocabulary for negotiating safeguards rather than accepting broad promises.

ClusterMAX 3.0 Makes Support and Contracts Technical Features

The most consequential change is the treatment of support obligations as measurable parts of cluster architecture.

GPU cloud agreements often separate technical specifications from commercial protections. A contract lists hardware, capacity, and availability, while operational details remain vague.

ClusterMAX 3.0 narrows that gap. SemiAnalysis has developed standardized service-level concepts for conventional HGX systems and rack-scale architectures. These address nodes, racks, clusters, and sites.

The framework defines downtime rather than leaving the term open to interpretation. It also describes acceptance testing across GPU compute, networking, storage, and software before a customer accepts delivery.

Acceptance matters because a cluster can be powered on without being ready for production. Misconfigured networking, inaccessible storage, outdated drivers, or broken scheduler integration can delay useful work after billing begins.

A credible agreement should state when the service becomes acceptable. It should also describe what happens when the provider misses that date.

SemiAnalysis recommends recurring reviews of service-level performance. That turns reliability into a continuing obligation rather than a promise evaluated only after a major dispute.

The framework also recognizes legitimate exclusions. Planned upgrades, security patches, and physical maintenance can require downtime. The contract should define those exceptions instead of allowing every interruption to disappear into a broad maintenance clause.

Support quality becomes measurable through the path from detection to repair. A provider must know which component failed, prevent new work from reaching it, and communicate the remediation plan.

Ownership of the facility influences that path. An operator controlling its own data center can manage technicians, parts, and procedures directly. A provider using colocation may rely on another company's remote-hands schedule.

Neither model automatically wins. The relevant question is whether the operating arrangement delivers recovery within the promised window.

This distinction becomes sharper with Grace Blackwell rack systems. Direct liquid cooling, high rack power, Arm-based host processors, and rack-scale NVLink add dependencies that older GPU deployments did not share.

A failed component may affect a larger unit of capacity. Repair procedures must account for tightly connected trays and racks rather than treating every eight-GPU server as interchangeable.

The coming Vera Rubin generation will increase power and network requirements again. SemiAnalysis expects the architectural transition to be less disruptive than the move from Hopper to Grace Blackwell, but providers still face operational work.

For buyers, support therefore belongs in technical evaluation. A knowledgeable response team, tested procedures, available replacement parts, and accurate telemetry determine the performance delivered over time.

The same principle applies to pricing. A rate that excludes useful support transfers operational risk to the customer. A higher rate can offer better value when it protects engineering time and preserves job completion.

ClusterMAX does not eliminate negotiation. It makes the hidden parts of that negotiation easier to identify.

What GPU Cloud Buyers Should Watch Next

The next test is whether ClusterMAX's leaders can preserve their advantage as hardware, workloads, and buying models change together.

The first signal is independent reproduction of the new ratings. Customers should compare their own acceptance tests and long-running jobs against SemiAnalysis's findings. Consistent results would strengthen the ranking's value beyond one evaluation window.

The second signal is provider movement during Vera Rubin deployment. Companies that maintained reliable Grace Blackwell systems should have a head start. New power, networking, and cooling demands can still reveal weaknesses in capacity planning and support.

Watch whether providers publish clear delivery schedules and operational targets. Marketing announcements matter less than stable clusters running customer workloads. Delays, configuration changes, and limited regional access will reveal how mature each rollout truly is.

The third signal is ClusterMAX's expansion into inference endpoints, reinforcement-learning infrastructure, and agent sandboxes. These products introduce different bottlenecks from traditional training clusters.

Inference services must balance latency, throughput, model loading, and unpredictable demand. Reinforcement-learning systems coordinate generation, sandbox execution, training, and frequent model updates. A weakness in any stage can leave GPUs idle.

This expansion could strengthen ClusterMAX by reflecting how AI teams now consume infrastructure. It could also make the framework harder to interpret because managed clusters and token-based services solve different problems.

Buyers should also watch security disclosures. More detailed evidence about isolation, patching, credentials, and incident response would make provider comparisons more defensible. Serious incidents would expose gaps that performance testing cannot capture.

Finally, monitor the divide between managed services and bare metal. Large laboratories are buying extensive capacity while operating more of the software stack themselves. Smaller teams still need providers to absorb that complexity.

AI agents will make some administration easier, but they will not remove the need for reliable systems. The report's own tests show that automation can solve routine problems while confidently creating new ones.

The ClusterMAX 3.0 ratings ultimately ask buyers to redefine the product. They are not renting chips in isolation. They are renting completed computation, recovery procedures, security controls, and access to experienced operators.

Before signing the next GPU cloud agreement, ask the provider to demonstrate those layers under failure. Request workload-specific benchmarks, current security evidence, recovery records, and precise acceptance terms. Then compare the completed work each option can deliver, not merely the capacity each one promises.