Pick the Model First. It Decides Where You Can Train It.

The question I get from architects isn’t whether NVIDIA beats Apple. It’s where to fine-tune and serve the model their application needs. A Mac Studio. A DGX Spark. A GB300 deskside system. Or a managed service that trains the adapter and hands it back.

Most people answer that by comparing hardware. I did too. In August I published a $148,497 quote for a GB300, then spent a follow-up arguing that I should price the constraint, not the box.

I’ve spent the past few days testing an M5 Ultra Mac Studio against the DGX Sparks in my lab. What it taught me is that the hardware comparison comes second. The model comes first, and it decides which venues can run the job at all.

Same box, different model

In Lab 26 I fine-tuned Gemma 4 26B, a mixture-of-experts (MoE) model, on short examples. With the recipe settings matched, the Studio trained the LoRA adapter about six times faster than the Spark. The job needed about 70GB, so memory wasn’t the reason. Both adapters passed the same behavioral checks. In Lab 24, CoreWeave Forge had trained a similar adapter in 31 minutes for $1.51.

On that model, every venue worked. The only questions were speed and cost, which is the comparison most people think they’re making.

Then I changed the model.

Lab 27 is the job my coding-agent work actually needs: dense Gemma 4 31B, a rank-32 LoRA, and agent transcripts that average 8,663 tokens and run to 30,553. Every venue changed its answer.

On the Mac, PyTorch’s Apple GPU backend stopped at its indexing limit, about 11,600 tokens. I rewrote attention to compute in blocks, and then it trained. The Spark trained it the way a CUDA box usually does. It was slow and it wanted an older, pinned software release, but whether it could run the job was never in question. Forge’s published self-serve list for serverless training doesn’t include the dense 31B, and rank is set per model. Its broader catalog advertises post-training support for Gemma 4 31B, and unlisted models go to its support team, which I didn’t contact. So it isn’t a rejection. The self-serve path just wasn’t there.

Once it ran, the Studio trained in 2.69 hours against the Spark’s 10.25. That’s 3.8 times faster. Both adapters landed in the same range on the coding tasks, 11 to 14 of 22, inside the noise.

The speed isn’t the headline. The headline is that the venues ran into different kinds of limits. On NVIDIA, the question was never whether the job would run. It was how long it would take, and how much box you’d need to make it faster. That’s a sizing exercise.

The Mac and the managed service raised a different question: whether it would run at all. The fastest venue on Lab 26 needed part of its software rewritten for Lab 27. The service that did the earlier job in 31 minutes didn’t have the model on its self-serve menu.

A spec sheet wouldn’t have told you any of that.

How I qualify a venue now

Four steps, in this order. The hardware quote doesn’t matter until the last one.

A four-step flow. 1. Select the model based on the application contract: capability, precision, context length, tuning method, evaluation criteria. 2. Qualify the execution venue: does the required model and training configuration actually work? 3. Account for software and engineering costs: framework versions, custom kernels, memory management, portability. 4. Compare validated throughput and total economics: training iteration time, serving concurrency, accepted outcomes, utilization.

The model contract. Write down what the application needs before you look at a venue. In Lab 27 it wasn’t the parameter count that eliminated options. It was context length and tuning method: 30,000-token examples at rank 32.

Qualify the venue. Not “does it support the model family.” Does it run this configuration? Forge supports Gemma 4 31B in a catalog. It didn’t offer my configuration on the self-serve path. Those are different answers, and only one of them gets your job trained. On NVIDIA this step is close to a formality. On Apple silicon and on a managed service, it’s where the job gets decided.

Price the engineering. The attention rewrite. The pinned release. A server cache that kept old conversations until 51GB of them had piled up. And the one that bites hardest if your roadmap chases new open-weight models: in my Studio or Spark lab, eleven weeks after the Spark stack served a model with working speculative decoding, the Mac stack still couldn’t. New models land on NVIDIA first. You pay that lag every time you move to the next one.

Then compare throughput and economics, among the venues that survived. On Lab 27’s coding loop, the Studio served each adapter’s 22 tasks in 1 hour 46 minutes to about 2.5 hours, against 5 hours 17 to 5 hours 41 on the Spark. That’s time to answer, the number I argued in August matters more than the invoice.

Where the GB300 fits

Concurrency is where NVIDIA earns the money, and I’m not going to argue otherwise.

In the Studio or Spark lab, two agent sessions running at once took about half as long per turn on the Spark pair as on the Studio. Add more load and the gap grew. The pair’s total output reached about two and a half times the Studio’s best, though I pushed the pair harder than I tested the Mac.

Read concurrency as people. Four streams means four users, or four agent processes, working at the same time—sixteen means sixteen. That’s the difference between one developer’s desk and a team sharing a box.

Line chart of total output in tokens per second as concurrent streams rise, where a stream is one user or one agent process. Mac Studio: 40.6 at one stream, 58.6 at two, 84.2 at four, the highest tested. Two clustered DGX Sparks: 52.0 at one stream, 132.2 at six, 211.4 at sixteen. Production configurations, unmatched points, so directional.

The GB300 is in another class. It pairs a Blackwell Ultra GPU and 252GB of HBM3e with another 496GB of slower coherent memory. Independent GB300 benchmarks show several models between roughly 2,900 and 6,500 tokens per second on a single station at 64 to 128 concurrent requests.

If the venue’s job is serving many agents at once, the GB300 qualifies and a Mac Studio probably doesn’t. That’s a real reason to spend six figures.

I haven’t trained on a GB300, so I won’t put a number on Lab 27. But I’m not asking whether it can. It’s NVIDIA’s stack. The question is the same one you ask of any NVIDIA box: how much concurrency and memory you need, and whether that’s worth $148,497. That’s sizing, not qualification.

So what?

Don’t start with the quote. Start with the model the application needs, at the precision, context length, and tuning method it needs. Then find out which venues can actually run it, what it costs your engineers to get there, and only then which survivor is fastest and cheapest.

On my bench, for this model, the $12,299 Studio passed and was fastest, at the price of rewritten attention. On a different model it might not pass at all. That’s the point.

The model picks the venue. Not the other way around.