Neoclouds sell a result, not merely a GPU: a distributed job should start, feed data, communicate, survive faults and finish within a predictable budget. Public evidence rarely measures that whole path. One provider reports the share of healthy network links, another publishes storage throughput from fio, another gives mean time between infrastructure failures for a customer cluster, and a fourth document may describe orchestration features without a comparable workload result. Placing those values in one ranking creates precision without comparability.
The 2025 disclosures from CoreWeave, Nebius and Lambda illustrate three useful evidence styles. CoreWeave provides detailed network and storage engineering claims, including a reproducible benchmark configuration[1][2]. Nebius exposes customer-cluster reliability and recovery metrics with explicit caveats[3]. Lambda describes the architecture and operating interfaces for dedicated, multi-cloud GPU clusters but offers fewer directly comparable performance or reliability measurements in that document[4]. This article asks what each disclosure establishes and what a buyer must still verify.
CoreWeave: component telemetry and a disclosed storage test
CoreWeave states that it operates millions of InfiniBand links and gives “99.9975” as the share that, at a given point, can deliver at least 95% goodput[1]. The sentence implies a percentage, but the public page does not print a percent sign or another unit beside 99.9975. The network stack uses NVIDIA Quantum-2 InfiniBand with SHARP and SHIELD, and an eight-NDR node exposes 3.2 Tb/s of accelerator-facing bandwidth. This is fleet telemetry reported by the company. The post also does not define the observation interval, sample distribution, failed-link treatment or whether application collectives achieve the same goodput. It is useful evidence of an operating metric, not an independent end-to-end benchmark.
The storage post gives more method. CoreWeave ran fio with CPU-driven I/O on H200 nodes, separating storage traffic through dual 100 Gb/s BlueField-3 links from the InfiniBand training fabric[2]. A 64-node, 512-GPU test exceeded roughly 500 GiB/s aggregate reads and retained 7.94 GiB/s per node, close to the design target of 1 GiB/s per GPU. The configuration and scripts are disclosed, making the result more reproducible than a bare product claim.
Its limit is equally important. The workload simulates observed training access patterns but does not use GPU Direct Storage, and fio bandwidth does not measure model training goodput, metadata-heavy dataset behavior or checkpoint recovery under concurrent fabric faults. The benchmark proves a storage data path under stated conditions.
Nebius: a customer workload and an explicit caution
Nebius reports an anonymous customer’s 3,000-GPU, 375-node production cluster[3]. Peak mean time between infrastructure failures reached 56.6 hours of wall-clock operation, expressed as 169,800 GPU-hours. The average over the preceding several weeks was 33.0 hours. Across most installations, Nebius reports an average mean time to recovery of 12 minutes.
The units need care. Multiplying 56.6 hours by 3,000 GPUs produces 169,800 GPU-hours; these are two expressions of the same failure interval, not two reliability achievements. The peak and several-week average are also different summaries. The post explicitly says that one environment does not generalize to every cluster. This caveat makes the evidence more useful because it identifies the workload boundary.
Nebius describes the operating mechanisms behind the number: multi-stage acceptance tests, active and passive health checks, workload isolation and migration, automated node replacement, state recovery and end-to-end observability. What is not public is the event-level distribution, failure taxonomy, workload goodput and customer-side checkpoint loss. MTBF and MTTR define important pieces, while effective training time also depends on detection delay and lost work per restart.
Lambda: an operating blueprint rather than a benchmark
Lambda’s December 2025 multi-cloud blueprint describes dedicated bare-metal GPU clusters, low-latency networking, S3-compatible storage, managed or self-managed Kubernetes, standard cloud interconnects and Prometheus-based observability[4]. It also claims no ingress or egress fees for data transfer to and from Lambda. The document is a capability and architecture statement aimed at portability across AWS, Azure, Google Cloud and Oracle Cloud.
It does not publish, in that blueprint, a cluster MTBF distribution comparable to Nebius’s customer case or a multi-node storage curve comparable to CoreWeave’s fio study. That absence should not be converted into a claim that the system performs worse. It changes the status of the evidence. A buyer can confirm interfaces, isolation and commercial terms from the document, while sustained collective goodput, recovery behavior and storage scaling require a benchmark, service-level objective or customer workload record.
Four labels that prevent a false comparison
Every infrastructure number should carry at least four labels. Subject identifies what was measured: link, storage node, job, cluster or fleet. Workload says whether the input was synthetic, trace-derived, customer production or unspecified. Denominator gives scale and duration. Evidence type distinguishes reproducible measurement, operator telemetry, customer report, modeled projection and capability claim.
With those labels, the disclosures stop competing improperly. CoreWeave’s reported 99.9975 link-readiness figure cannot be compared with Nebius’s 56.6-hour peak cluster MTBF; one samples links at a point and the other counts time between job-affecting infrastructure events. The CoreWeave 500 GiB/s result has a 64-node fio denominator, while Lambda’s S3-compatible storage statement establishes an interface, not a throughput level. Each answers a legitimate but narrower question.
What to request before buying cluster-hours
A procurement evaluation should bridge components to completed work. Run the customer’s model or a representative collective at the intended scale, and report p50 and tail goodput over days rather than one clean hour. Inject or observe node, link and storage failures; separate detection, replacement, communication rebuild, checkpoint reload and lost-step time. Publish both physical availability and scheduler availability, since a healthy spare that cannot join the topology does not restore the job.
Storage should be tested concurrently with training communication and checkpoint bursts. Network results should include path diversity, degraded-mode performance and the fraction of time a job remains below its target collective bandwidth. Commercial portability claims should be exercised by moving artifacts and orchestration between clouds, including measured transfer time and every charge not covered by an egress policy.
The fairest conclusion is not that one neocloud wins. CoreWeave reveals component engineering depth, Nebius reveals a customer reliability interval, and Lambda reveals the portability contract of its stack. The gaps are different. A technically serious buyer turns those gaps into a validation plan rather than filling them with a marketing comparison.
Convert the disclosure into a price for completed work
Component evidence becomes commercially useful only when it changes the unit of purchase. A quoted GPU-hour assumes that every rented hour produces equivalent progress. The disclosed network, storage, and reliability data show why that assumption fails. The buyer ultimately pays for accepted training steps, served tokens within an SLO, or a completed checkpoint. A lower hourly price can be more expensive when collective goodput is unstable, failures erase long intervals, or storage extends every checkpoint pause.
The practical metric is risk-adjusted cost per completed unit of work. Its numerator includes rental charges, reserved but unusable capacity, data movement, restart work, and engineering intervention. Its denominator excludes time below the workload’s acceptance threshold. Each provider disclosure can populate one term, but none of the reviewed documents fills the whole equation. That is the analytical reason not to construct a vendor ranking from public numbers: missing variables would dominate the result.
A procurement trial should therefore end with a customer-owned evidence package. It should contain the workload configuration, software versions, topology, percentile goodput, event log, checkpoint and restore distributions, and every exclusion used to compute availability. Repeating the same package after a hardware or software change turns a sales benchmark into an operating baseline. The neocloud market will become easier to compare when providers compete on the completeness of that package, not only on the most favorable number they can disclose.
Contracts should follow the same evidence boundary. A node-availability SLO does not compensate a customer whose distributed job cannot obtain a healthy topology. A network uptime SLO may remain green while collective goodput sits below the training plan. Storage availability can remain green while checkpoint tails erase useful accelerator time. Buyers should request workload-facing service indicators and credits tied to failed job starts, sustained collective thresholds, checkpoint completion, and recovery time. Component indicators remain valuable for diagnosis, but the commercial promise should terminate at completed work.
Comparison over time matters more than a permanent score. Hardware generations, firmware, placement pressure, and customer mix change faster than a procurement cycle. The provider that publishes one strong benchmark may not preserve it under a denser fleet, while an operator with weaker public disclosure may improve rapidly. A buyer should retain the test and rerun it at expansion, renewal, and major software transitions. This makes evidence freshness explicit. A result without a date, version, topology, and load condition is not a durable property of a neocloud; it is an observation whose expiration is unknown.
Sources and attribution
This article is an independent analysis prepared by Silicon & Systems from public operator materials published in 2025. Company-reported figures are identified as such, and unlike metrics are not normalized into a ranking. No source text, tables, logos or figures are reproduced; both figures were created for this article. The source materials are CoreWeave’s network post and storage benchmark, Nebius’s cluster reliability report, and Lambda’s multi-cloud blueprint. Copyright remains with the respective publishers.