Neocloud GPU Providers: CoreWeave, Nebius, Lambda Labs, Crusoe, and How to Choose Your AI Compute Platform

When a team comes to me asking how to choose between CoreWeave and AWS for their next training run, my first question is usually: what do you actually need to accomplish? That question sounds obvious until you realize most teams have not clearly separated what they need from what they think the obvious cloud answer looks like. The neocloud category, providers like CoreWeave, Nebius, Lambda Labs, and Crusoe that exist specifically to serve GPU-intensive AI workloads, has grown fast enough that it now deserves the same structured evaluation you would give any major infrastructure decision.

I have spent twenty years building cloud infrastructure, and I have watched the GPU market do something I have never seen any other infrastructure category do: a small set of specialized providers have genuinely outcompeted the hyperscalers on cost and availability for the specific workload those hyperscalers nominally support. That tells you something important about the structural economics here, and it is worth understanding before you commit your next training budget.

What Actually Defines a Neocloud

The term gets applied loosely, but the core characteristic is GPU specialization at scale. A neocloud is built from the ground up to run GPU clusters for AI training and inference, rather than retrofitting GPU support onto an existing general-purpose cloud. That specialization shows up in several concrete ways.

First, neoclouds negotiate directly with NVIDIA for large GPU allocations, often before general availability. CoreWeave filed to go public in early 2024 and has disclosed multi-year GPU purchase commitments running into the billions. Nebius, spun out of Yandex’s international operations, secured large NVIDIA GPU capacity and struck significant long-term contracts with major AI labs including a multi-year GPU-as-a-service arrangement with Microsoft that industry reporting placed at multi-billion-dollar scale.

Second, the network fabric is built for GPU-to-GPU communication rather than general internet traffic. Training a 70B parameter model requires thousands of GPUs to communicate at memory bandwidth speeds. Neoclouds build their data centers around InfiniBand or high-bandwidth RoCE fabrics rather than standard Ethernet. Understanding how GPU cluster networking actually works matters here: the difference between a 400Gbps InfiniBand fabric and commodity switching shows up directly in your training throughput.

Third, the operational model is different. You are typically getting closer to bare metal than you are with a hyperscaler. The hyperscaler abstraction layers that make EC2 p5 instances convenient to provision also introduce scheduling latency, NUMA boundaries, and network path overhead that compound across a large training cluster.

The Major Players

CoreWeave

CoreWeave is the most visible neocloud because it went public and because it landed a landmark agreement with Meta in April 2026 covering GPU cloud spend through 2032. In their Q2 2026 earnings, CoreWeave reported revenue of $2.575 billion for the quarter, roughly double the same period a year prior. That growth rate reflects genuine demand, not accounting tricks.

What makes CoreWeave technically interesting is the cluster scale they operate at. They run NVLink-connected H100, H200, and B200 clusters at sizes that most hyperscalers will not sell you as a self-service product. If you need a thousand-GPU job to land on interconnected hardware without being scattered across availability zones, CoreWeave’s provisioning model is designed for that. Their pricing model has evolved: in mid-2026 they increased list prices on on-demand GPU instances, and the gap between on-demand and reserved pricing widened significantly, reflecting how much demand they have from long-term committed customers.

The risk with CoreWeave is concentration. Their revenue is highly concentrated in a small number of large customers, and they carry substantial debt from their GPU purchase commitments. For a platform you are building a training pipeline around, that matters. This is not a knock on CoreWeave specifically; it is the nature of a capital-intensive infrastructure business in growth mode.

Nebius

Nebius is the most underrated option in this space, in my view, because its origins (spinning out of Yandex’s international cloud business) cause people to dismiss it before looking carefully at what it actually offers.

Nebius brings a different geographic and technical profile than CoreWeave. Their data centers span Europe and North America, with renewable-powered capacity in Finland and expanding capacity in the US. They have launched support for NVIDIA’s Blackwell architecture (including GB200 NVL72 systems) and run clusters with InfiniBand networking. Their pricing on H100 and H200 capacity is generally lower than CoreWeave’s on-demand rates, according to third-party comparison sites as of Q3 2026, though you should verify current rates directly with both vendors.

The platform offers both managed Kubernetes and Slurm-based cluster environments, which matters if your team has existing HPC tooling. Fault-tolerant distributed training is operationally complex, and Nebius has invested in managed cluster tooling that handles checkpoint coordination and node failure recovery.

The risk with Nebius is the smaller ecosystem around it. They do not have the same breadth of integrations, managed services, or community documentation that CoreWeave has accumulated. If your team runs into an obscure networking issue at 2am, you are more likely to find a StackOverflow answer or a community thread about CoreWeave than about Nebius.

Lambda Labs

Lambda occupies a distinct position: they are the developer-friendly neocloud. Lambda’s reputation was built on making GPU instances easy to provision without signing enterprise contracts. Their self-serve marketplace, clean API, and straightforward pricing resonated with ML researchers and smaller teams who needed occasional large GPU access without negotiating deals.

Lambda has scaled substantially, added B200 and H200 inventory, and extended their geographic footprint. They remain the strongest option when you need to spin up a multi-hundred-GPU cluster without a procurement relationship, and when your team wants to apply standard DevOps patterns to GPU infrastructure without fighting proprietary provisioning systems.

Where Lambda has gaps compared to CoreWeave and Nebius is in the managed cluster tooling. You get the GPU hardware and the networking; building the distributed training orchestration on top of it is mostly on you. That is fine if your platform team has the skills and capacity. If you are a research team that wants to focus on model work rather than infrastructure plumbing, the operational overhead is real.

Crusoe

Crusoe is the most differentiated neocloud from an infrastructure philosophy standpoint. They began by building data centers powered by natural gas that would otherwise be flared at oil fields, and have since evolved into a broader energy-first AI compute provider. Their current scale includes hundreds of megawatts of operating capacity, and they are building flagship campuses as part of large AI infrastructure initiatives including involvement in the Stargate project in Abilene, Texas.

The energy angle matters for two reasons. First, power cost is a real constraint in GPU cluster economics. A data center that can build near cheap, reliable power sources and commit to long-term energy contracts can undercut providers that pay grid spot prices. Second, sustainability commitments matter to an increasing number of enterprise customers. Crusoe has expanded into renewable-powered European capacity through partnerships with Icelandic data centers, giving them a differentiator in geographies where carbon reporting requirements are tightest.

Crusoe’s self-serve cloud platform is less mature than CoreWeave’s or Lambda’s for teams that want to provision and iterate quickly. Their strength is in large, committed, custom-built cluster deployments where you are working directly with their team on architecture and terms.

Why Not Just Use a Hyperscaler

This is the question I get from every enterprise team that has been running on AWS or GCP for years. The honest answer is: for many teams, the hyperscaler is still the right choice. The question is which specific factors tip the decision.

Hyperscalers win on ecosystem depth. If your AI pipeline reads from S3, writes to Redshift, triggers Lambda functions, and feeds data through Glue, then moving your training jobs to CoreWeave means you are now dealing with cross-cloud data transfer costs, latency, and integration complexity. Understanding GPU cloud infrastructure choices in the broader context of your stack matters here: the workload does not exist in isolation.

Hyperscalers also win on managed services. AWS SageMaker, Vertex AI, and Azure AI Foundry are built on top of the same underlying GPU hardware, but they add managed training infrastructure, experiment tracking, model registries, and MLOps tooling that you would otherwise build yourself. If your team is spending significant engineer time on infrastructure rather than model work, that managed layer has real value.

Where neoclouds win is clear: GPU availability, price on raw compute, and network fabric quality for large training jobs. AWS p5 instances (H100-based) are not always available on demand at the scale a training run needs. When they are available, the on-demand pricing is typically higher than neocloud on-demand pricing, and the spot market for large GPU clusters on hyperscalers is less liquid. For a team running regular large training jobs, moving the training workload to a neocloud while keeping everything else on the hyperscaler is a common and sensible hybrid pattern.

The cost difference on committed capacity is where neoclouds have the most leverage. A one-year or three-year reserved GPU contract on a neocloud often produces a meaningful discount compared to hyperscaler reserved instance pricing for equivalent hardware. Understanding the structure of cloud commitment pricing and how reserved contracts work is important before you sign a multi-year neocloud deal, because the terms vary substantially and the exit provisions matter.

The Vendor Risk Question

The neocloud category is adolescent, and adolescent infrastructure categories carry vendor risk that mature categories do not. Several neoclouds that were active in 2024 no longer exist or have been acquired. The consolidation is not finished.

CoreWeave is now public, which gives you financial transparency but also exposes their debt structure and customer concentration. Nebius is public and majority owned by Arkady Volozh and Yandex founders, which creates a different kind of risk: geopolitical perception risk in some enterprise environments. Lambda and Crusoe are private, which means less financial transparency.

What I tell teams is to think about two specific scenarios before committing. First: what happens if your neocloud doubles their prices in twelve months? CoreWeave raised on-demand prices significantly in 2026 as their committed customer base grew and on-demand availability tightened. If your architecture assumes current pricing, you may find yourself repricing or migrating sooner than expected. Second: what happens if your neocloud has a major outage that lasts longer than your hyperscaler SLA coverage period? Most neoclouds do not offer the same financial SLAs that hyperscalers provide.

The mitigation is not to avoid neoclouds; it is to architect for portability. Running your training on vLLM or SGLang with standard interfaces means your inference pipeline is not locked to a specific provider’s runtime. Using standardized frameworks for distributed training means your training code is not tied to proprietary cluster APIs. The more your platform team has abstracted the GPU hardware layer, the easier a provider migration becomes if you need one.

Evaluating Against Your Specific Workload

The evaluation framework I use breaks workloads into three categories: training runs, inference serving, and research or experimentation.

Training runs are where neoclouds have the strongest case. A pre-training or large fine-tuning run that needs hundreds of GPUs for days to weeks is the ideal neocloud workload. The economics of on-demand versus reserved GPU time matter a lot here. If your training schedule is predictable, a reserved contract with a neocloud often produces the best price. If your training is bursty and unpredictable, the hyperscaler spot market or neocloud on-demand rates compete more closely.

For training, the critical questions are: what is the minimum cluster size you can run efficiently, how does the provider handle node failures during multi-day jobs, and what does their interconnect look like at your target cluster size. The last question matters more than most teams realize. The InfiniBand vs RoCE distinction affects your all-reduce throughput in ways that compound over a long training run.

Inference serving is more nuanced. Neoclouds can serve inference workloads, but for production inference with variable traffic, you are often better served by a managed serverless GPU platform or by your hyperscaler’s managed endpoints. The operational model of a neocloud assumes you are managing cluster utilization yourself. For inference workloads that benefit from scale-to-zero, that model is less efficient than a purpose-built serverless inference platform.

Research and experimentation is where Lambda’s developer experience and on-demand availability model shines. A researcher who needs a 16-GPU cluster for three days, then nothing for two weeks, then a 64-GPU cluster for a long weekend, is a bad fit for the committed-contract model that CoreWeave optimizes for.

Practical Advice on Pricing

A few things I have learned from doing this evaluation with real teams.

List prices are not your actual cost. Every major neocloud has a list price on their website and a sales team that will offer you a discount for a committed contract. The discount structure varies: CoreWeave, for example, offers significant reductions from on-demand pricing for one-year and multi-year GPU reservations. Lambda and Nebius are similar. If you are spending more than a few hundred thousand dollars per year, you should be talking to a sales team, not booking through the self-serve portal.

Understand what you are actually paying for. GPU-hours are the primary unit, but the actual cost includes networking egress, storage, and the operational time your team spends managing the cluster. A neocloud that requires three engineers to keep a training cluster healthy adds labor cost that does not appear in the GPU-hour line item. When comparing against a hyperscaler with managed training infrastructure, include that operational cost in your comparison.

Build a real-world cost model before you sign anything. The AI FinOps discipline is still immature in most teams, and GPU compute is expensive enough that a wrong assumption in your cost model can produce a surprise invoice that ends conversations about continuing with a neocloud. Run a representative workload, measure the actual resource consumption including storage IOPS and network transfer, and project that forward before committing.

The Hybrid Pattern That Actually Works

The architecture I recommend most often for teams with meaningful AI workloads: run your training on a neocloud under a reserved contract, run your serving infrastructure on your hyperscaler using spot instances or managed endpoints for scale-to-zero benefits, and keep your data platform and orchestration layer on your hyperscaler.

This gives you the cost benefits of neocloud GPU pricing for training, the ecosystem and integration advantages of your hyperscaler for everything else, and a data transfer bill that is acceptable because training data goes in and model checkpoints come out, not the reverse. The hybrid approach also reduces your vendor risk: if the neocloud you chose raises prices or has availability problems, your inference and data infrastructure are unaffected while you migrate your training.

For FinOps teams trying to get AI spending under control, the discipline of separating training compute from inference compute from data processing compute, and pricing each category separately against the right vendor, is how you avoid the trap of paying hyperscaler on-demand pricing for everything simply because it is convenient.

Where This Market Is Going

The neocloud market is growing fast and consolidating at the same time. Microsoft’s reported multi-billion-dollar commitments to neocloud providers across multiple multi-year contracts reflects a strategic bet that these specialized providers will hold a meaningful share of AI compute for years. The hyperscalers have responded by accelerating their own GPU investments, but the neoclouds have a head start in pure GPU-density data center design that takes time to close.

What I expect is that the cost differential for large training runs will persist, because the hyperscalers are serving too many constituencies to optimize purely for GPU density. The neocloud players that survive will be the ones that build enough ecosystem tooling and managed services to reduce the operational burden on customer teams, while maintaining the hardware access and pricing advantages that drove the category in the first place.

For teams making decisions today: the neocloud evaluation is worth doing seriously for any training budget above a few hundred thousand dollars per year. Below that threshold, the operational overhead and pricing negotiations are not worth the savings. Above it, the gap is real enough to matter to your infrastructure cost structure.

Before committing to any neocloud provider, verify current pricing directly with their sales teams. GPU pricing in this market moves faster than any blog post can track, and the reserved versus on-demand spread changes with supply and demand conditions.