In the broader narrative of the AI boom, a new category of infrastructure provider has emerged, colloquially termed the “neocloud.” The economic logic of the neocloud is, at first glance, simple arbitrage: the hyperscalers (AWS, Azure, Google Cloud) are supply-constrained and expensive, creating an opening for smaller, agile players to buy GPUs, place them in leased data centers, and rent them out to desperate AI startups. The bear case for this entire category is that it is fundamentally a financial engineering play—a “GPU REIT” (Real Estate Investment Trust)—rather than a software business. The model relies on asset-backed debt and long-term leases, selling a commodity (compute) that will eventually face price compression as supply normalizes.

However, to lump CoreWeave in with the generic neocloud cohort is to misunderstand the specific problem that large-scale AI training actually presents. While the company’s balance sheet shares the asset-heavy, leveraged characteristics of a landlord, its operational reality is increasingly distinct. Most neoclouds are infrastructure brokers with a thin DevOps veneer; they sell access to chips. CoreWeave, by contrast, is attempting to build a verticalized AI hyperscaler. The differentiation is not that they have GPUs; it is how much useful work—specifically Model Flop Utilization (MFU)—they can extract from those GPUs.

The standard neocloud pattern is one of minimum viable product. The provider acquires hardware—often a generation behind the bleeding edge—leases a powered shell, and exposes instances via a thin control plane. The customer receives a bare-metal box or a basic Kubernetes instance, and the provider’s responsibility ends at the hardware level. This is a commoditized business model where the only levers are price and availability. CoreWeave began here, but has spent the last several years moving simultaneously down into the physical fabric and up into the software stack. The result is a platform where the product is not the chip, but the cluster.

This shift begins at the rack level. While generic providers treat GPUs as inventory units (SKUs), CoreWeave treats the rack—specifically the NVIDIA NVL72 GB200 systems—as the atomic unit of the product. This distinction is critical because modern Large Language Model (LLM) training is a bandwidth problem as much as a compute problem. CoreWeave designs its clusters with high-bandwidth InfiniBand fabrics and SHARP in-network compute, optimizing the physical topology so that large jobs reside within tightly coupled GPU “islands” connected via NVLink. This stands in stark contrast to providers that utilize standard Ethernet or mixed fabrics which, while sufficient on a spec sheet, crumble under the latency demands of collective operations like all-reduce and all-gather. This is an operator mindset: designing cooling, power, and topology for specific workloads rather than simply filling a room with capacity.

The second layer of differentiation is the control plane, where CoreWeave addresses the fundamental tension of cloud infrastructure: the trade-off between the raw performance of bare metal and the manageability of virtualization. Traditional virtualization introduces a “hypervisor tax” that degrades performance, which is unacceptable for training runs costing tens of millions of dollars. However, bare metal is notoriously difficult to secure and manage in a multi-tenant environment. CoreWeave resolves this by offloading the entire cloud operating system—networking, storage, encryption, and security policies—onto NVIDIA BlueField Data Processing Units (DPUs).

By moving the control plane to the DPU, CoreWeave allows the tenant to access the host GPU without an intermediary layer, while still maintaining Virtual Private Cloud (VPC) isolation and security. This is a subtle but profound architectural shift. While other neoclouds force customers to choose between chaotic DIY bare metal or performance-draining VMs, CoreWeave utilizes hardware integration to offer the benefits of a managed cloud with the throughput of bare metal. This directly impacts the customer’s bottom line by lowering the effective cost per token. (This, + Nimbus, IMO, is one of their most interesting technical differentiators) 

Moving up the stack, CoreWeave has recognized that in the era of Generative AI, the scheduler is the computer. Standard Kubernetes is ill-suited for the unique demands of AI workloads; consequently, CoreWeave has built a GPU-native orchestration stack centered on CKS (CoreWeave Kubernetes Service) and SUNK (Slurm on Kubernetes). This is not merely a scheduling tool, but a topology-aware system that pins large training jobs to specific GPU islands to minimize communication overhead. Combined with “Tensorizer” for rapid model loading and checkpointing, the system is engineered to maximize “goodput”—the amount of time the hardware spends actually training the model versus waiting for data or recovering from failures.

This operational focus extends to what CoreWeave calls “Mission Control.” In the realm of LLM training, hardware failure is not a possibility; it is a statistical certainty. A single failing Network Interface Card (NIC) can stall a training run across thousands of GPUs. Most neoclouds provide logs and leave the remediation to the customer’s MLOps team. CoreWeave, however, treats operations as a product, utilizing automated remediation to quarantine bad nodes and rebalance workloads without human intervention. This is the sort of reliability engineering usually reserved for internal teams at Google or Meta, and its availability as a service is a significant value-add for enterprises that need predictable training timelines.

Ultimately, CoreWeave is betting that the future of AI infrastructure is not about renting commodities, but about selling outcomes. To be sure, the company faces significant risks: it is capitalizing an asset-heavy model with high leverage, and its revenue is concentrated among a handful of hyperscaler-adjacent giants. In this sense, the “GPU REIT” comparison remains financially relevant. However, strictly defining CoreWeave by its capital structure ignores its strategic position. Most neoclouds compete on inventory, a game that becomes impossible once supply constraints ease. CoreWeave is competing on delivered performance and operational integration. If they can sustain the claim that their cloud solves the hardest training problems faster and more reliably than the alternatives, they will have successfully transitioned from a landlord to a specialized AI platform, occupying a defensible niche between the commodity providers and the integrated hyperscalers.  All of this to say, Coreweave has some key differentiators but their long-term success depends on them getting enterprises, who are likely current or future tenants of the big three hyperscalers, to choose Corweave over AWS, GCP, and Azure.  If we were to make the case Coreweave has a chance to do it, this is how we would make the case.

The Case Against the Hyperscalers for AI native workloads. 

Join the newsletter and stay up to date