CoreWeave's Second Trick: Making AI Experimentation Accessible

I’ve been pretty vocal about neoclouds being one-trick ponies. I’ve compared them to Rackspace, which had something today’s neoclouds largely don’t: established enterprise relationships, procurement channels, and decades of operational credibility. Even with those advantages, Rackspace couldn’t maintain its differentiation against the hyperscalers.

My argument is simple. GPU capacity arbitrage isn’t a sustainable business model. When your primary differentiator is access to scarce NVIDIA GPUs, what happens when that capacity is no longer scarce?

I’ve argued that companies like CoreWeave, Lambda, and Crusoe need to find value above renting GPUs. Otherwise, they’re destined to become tomorrow’s Rackspace.

At AI Field Day 9, CoreWeave gave me something to think about.

Disclosure: The Futurum Group’s Tech Field Day subsidized my travel for the event and paid for meals. They have no editorial control over my content.

My labs exposed two problems

If you’ve followed my lab work, you know I’ve invested considerable time and money experimenting with local AI. Two findings have shaped my thinking about fine-tuning and inference economics.

First, fine-tuning is hard. Not because of the compute an individual training run needs, but because of the experimentation surrounding it. Preparing data, training, evaluating, diagnosing problems, adjusting, and repeating. That loop is the cost nobody prices.

I’ve had experiments where the evaluation metrics improved while the actual quality of the model regressed. That’s frustrating when you’ve invested hours into a training run only to discover you’ve made the model worse.

The challenge is closing that feedback loop. How quickly can I identify a problem, experiment with a potential solution, and validate the result?

Second, fine-tuned models challenge the economics of public cloud inference.

For general-purpose inference, the hyperscalers have a compelling economic advantage. But the managed services I’ve evaluated often require dedicated provisioned capacity to serve customized models. Suddenly, I’m paying for infrastructure availability rather than the tokens I consume.

That’s one of the areas where local AI becomes economically attractive.

CoreWeave presented an approach to both problems.

The second trick

CoreWeave spent its AI Field Day session demonstrating Forge, the integrated environment for model development, experimentation, and inference it launched on September 30.

Through acquisitions including Weights & Biases and OpenPipe, CoreWeave has assembled a workflow that connects production observability, training data, fine-tuning, evaluation, and deployment.

None of those individual capabilities is particularly novel. What caught my attention was the attempt to remove the manual work connecting them.

CoreWeave’s ARIA agent analyzes experiments, identifies what drove a change, and recommends the next experiment to run. The proposition is that developers can experiment more often without assembling and operating the entire machine learning pipeline themselves.

CoreWeave is making an argument for democratizing high-frequency AI experimentation.

That’s interesting because it’s precisely the problem I’ve hit in my labs.

I haven’t validated the time savings or effectiveness. Automating experimentation doesn’t guarantee better results. My own work has shown that improving evaluation metrics can produce worse models when you’re measuring the wrong things.

But the approach deserves attention.

The bigger surprise came when CoreWeave discussed serving fine-tuned models.

CoreWeave lets customers keep their low-rank adaptation (LoRA) adapters and potentially serve them against shared base-model infrastructure at commodity token rates. During the presentation, I stopped to confirm I understood the offering, because it’s materially different from my experience with the major cloud providers.

Think about that combination.

I can potentially accelerate experimentation through a managed workflow, keep my customized model adapter, and serve it without provisioning dedicated inference infrastructure.

That challenges both the operational overhead and the inference cost floor I’ve identified in my labs.

I still need to validate the economics, performance, and portability. But CoreWeave has presented an interesting answer to problems I’ve spent months investigating.

But where’s the moat?

Here’s where my skepticism returns.

CoreWeave has assembled a compelling set of capabilities, but what’s preventing AWS, Microsoft, or Google from doing the same thing?

The individual components aren’t revolutionary. The hyperscalers have the infrastructure, developer ecosystems, and enterprise relationships to offer comparable services. I don’t see an architectural barrier preventing them from reproducing CoreWeave’s approach.

There’s also a tension in the portability story. Keeping my LoRA makes CoreWeave more attractive because I can take my customization elsewhere. But if another provider offers a comparable development experience, what’s keeping me on CoreWeave?

My own assessment points at the answer. The experiment history, evaluation datasets, and improvement loop accumulate in Forge, and they don’t move when the GPUs do. That’s real stickiness. But switching friction isn’t a sustainable moat.

The continuous improvement loop CoreWeave highlighted is valuable: run, observe, curate, improve, evaluate, repeat. I suspect it will eventually become table stakes.

CoreWeave needs to move beyond simply automating that loop. There’s a difference between making experimentation easier and helping developers make better decisions about when and how to customize models.

The latter may be considerably harder to replicate.

A second trick isn’t enough

CoreWeave’s row moved in my Layer 2C assessment after the session.

The biggest move is at Layer 2B, the runtime. I used to score CoreWeave Inference as Ceded, meaning the decision sat with CoreWeave. Serverless Inference and customer LoRA adapters now score Delegated. CoreWeave runs the service, but it sits behind an OpenAI-compatible interface and the adapter is my file. I can point both at another provider without rebuilding. That’s the serving story from this session, and it held up against the docs.

The rest of Forge didn’t move. Experiment tracking, the registry, evaluation, and now ARIA all score Ceded. That’s where the history accumulates, and it doesn’t leave with the adapter.

Layer 3 moved from gap to moderate, but that came from Monolith, CoreWeave’s engineering-test application, not from Forge. And Layer 2C, reasoning, held at gap. The improvement loop observes and scores agent behavior. Nothing in it decides what an agent is allowed to do at request time.

That’s not an endorsement of its economics or a validation of its automation. Those are questions for a future lab, sponsored or otherwise.

But I’ve spent enough time fighting these problems to recognize an interesting approach when I see one.

CoreWeave demonstrated that neoclouds don’t have to remain one-trick ponies.

The second trick is making AI experimentation accessible. The third needs to be making that experience difficult to replicate.