I Was Pricing the Box. I Should Have Priced the Bottleneck.
Last Thursday I published a quote. Dell wants $148,497.24 for a Pro Max FCT6263, a GB300 desktop, and I argued the sticker was the least interesting number on it. Then I left the obvious question sitting there.
So, is it worth it?
I’ve been rehearsing a smaller version of that question for months, about a much cheaper box. Whether the second DGX Spark was worth the money. I ran the numbers on it. I compared it against a cloud instance. I talked myself into it and back out of it twice. Every version of that debate was wrong, and the lab I just finished showed me why.
The question was never whether the box is worth its price. The box is cheap. Both boxes are cheap. The question is what the slow box costs me in the thing I actually sell: answers to hard infrastructure questions, produced as labs.
The bottleneck was never the money
Look at my history and one pattern holds. I don’t run out of questions. I run out of GPU time to answer them. The queue of things I want to put in the lab is always longer than the hardware can work through. GPU has been the constraint in my process for a year, and a constraint isn’t a capex line. It’s a throttle on output.
The lab put a number on the shape of it. Across a week-long fine-tuning experiment the metered compute came to $73, plus about 90 hours on hardware I already own. If you remember $58 from Thursday, that’s the same meter mid-run. The lab was still going, and it closed at $73, which is the honest way that number behaves.
And it’s a decoy. Not because it’s too low, but because it’s the wrong unit. That $73 is rented GPU time at Hot Aisle. It’s the only part of the week that generated an invoice, and the 90 hours on my own boxes generated none. Six days went into all of it. The money measures what I rented. The six days measure when I got the answer.
The obvious objection first, because it’s the right one to raise. Nobody sits in a chair watching a progress bar. Training runs unattended. You go do other work.
Correct. And the experiment still isn’t finished.
That’s what a cost model misses, mine included. Slow hardware doesn’t mostly burn attended hours. It occupies the critical path. The run that doesn’t finish tonight is the answer I don’t have tomorrow, and the answer I don’t have tomorrow is the three experiments I can’t start.
Which is the part that still bothers me. I spent 90 GPU-hours building an instrument to measure cost per solved task, and what it measured was that cost per solved task isn’t the number holding me back. Time to solved task is.
The cheap resource was setting the pace
Here’s the trap I walked into. The Spark is cheap to own and it grinds overnight for free, so it feels like the frugal choice. But it’s slow. Slow GPU stretches every experiment across more wall-clock time, and wall-clock time is what sets the pace of the whole research process. A run that eats an overnight on the Spark and an afternoon on a rented MI300X didn’t save me money by staying home. It moved everything downstream of it a day to the right, to save a few dollars of rent.
My labs aren’t independent. Each one produces the next two or three questions. Delay one by three days and you haven’t delayed one experiment. You’ve shifted the entire question tree three days out.
I can rent an MI300X-class accelerator for $3 to $6 an hour. At those prices the rental is a rounding error against the delay it removes. What it buys isn’t cheaper compute. It’s more labs per month, because the thing limiting my output was never dollars. It’s throughput.
Now run it with a team
None of this is peculiar to a one-person lab. My question tree is unusually visible because I publish it, but any team whose next move waits on an answer that hasn’t arrived has the same shape. Which is most of them.
Put four engineers behind a shared training queue and the queue sets your development cycle time. They’ll find other work while it drains, so nobody looks idle and no hour goes unbilled. But the evaluation isn’t done, the architecture decision isn’t made, the next run hasn’t started, and the feature waiting on that answer hasn’t moved.
The finance conversation is always about the accelerator invoice, because that’s the line item with a number next to it. The waiting has no line item. It shows up as roadmap slip, and nobody attributes it to the cluster.
So what does that mean for the $148,497 quote?
It changes the question from “is it worth it” to “will you actually run it.” Here’s the same box priced by duty cycle over a three-year life:
| How hard you run it | GPU-hours over 3 years | Effective cost per hour |
|---|---|---|
| 24/7 | 26,280 | $5.65 |
| 16h/day, every day | 17,520 | $8.48 |
| 8h/day, weekdays | 6,264 | $23.71 |
| 4h/day, weekdays | 3,132 | $47.41 |
Now the part that surprised me when I went looking for the other side of that comparison. You largely can’t rent this tier by the hour.
I checked CoreWeave’s own published pricing rather than an aggregator, because several widely-quoted Blackwell figures don’t survive that check. The previous generation is straightforward: GB200 NVL72 lists at $42.00 an hour for a four-GPU instance, which is $10.50 per GPU-hour, with no long-term commitment. CoreWeave positions on-demand explicitly as burst capacity for people not looking to commit. HGX B200 is $68.80 an hour for eight GPUs, or $8.60 each.
The Blackwell Ultra tier is where it changes. GB300 NVL72 is contact sales for on-demand, contact sales per GPU, and not offered on spot at all. HGX B300 is contact sales on demand too, though it does carry a published spot rate of $35.84 for eight GPUs, about $4.48 per GPU-hour.
The shape matters more than the numbers here. At the frontier tier you can have interruptible capacity at a published price, or you can have guaranteed capacity at a price you have to ask for. What you can’t do is look up what an uninterrupted GB300 hour costs. That’s the trilemma at the top of the market: capable and available, but neither cheap nor self-serve.
And spot is the wrong instrument for the thing this whole post is about. A fine-tune that gets evicted at hour nine of a fifteen-hour run hasn’t saved you anything. It’s spent the expensive resource, your calendar, to save the cheap one.
Two honest caveats before anyone quotes that table at me. The Dell machine is a desktop superchip and the cloud GB300 offerings are rack-scale systems, so these are not the same product wearing different pricing. And my own rental figures earlier in this post are MI300X, a different and less capable class than either. The duty-cycle table prices the box I was quoted. It is not a claim that renting an equivalent is cheaper, because as of today there is no published price for an equivalent to check.
Which is its own answer. If the tier you want has no public rate, the market is telling you the same thing the empty shelf told me: capacity at the frontier is allocated, not purchased.
What the second Spark actually bought
Worth being precise about, because I got this wrong in my own head for months. The second Spark didn’t make anything faster. It bought two things, and I only understood one of them when I placed the order.
The first is concurrency. A 31B dense model grinds on one node while a 26B mixture-of-experts grinds on the other. Two questions answered in the span one used to take.
The second is capacity, and it’s the one that changed what I’m able to ask. Clustered, the pair holds models that neither box can hold alone. DeepSeek V4 Flash needs about 156GB. It doesn’t fit on a single Spark. Split across two it fits, serves at roughly 35 tokens a second, and swept my repair pool twice. 22 of 22 both times, at a seven-minute median per repair. That’s open weights with frontier-scale post-training, clearing the pool for nothing but memory and hours, under my desk.
Concurrency isn’t something only owned hardware can give you. Nothing about the cloud prevents running two experiments side by side. Capacity at that size is a different question, and the honest reason I couldn’t rent it is the subject of the next section.
The part the hourly rate hides
Everything above assumes you can get the GPU. That assumption has been the quietest recurring theme across my labs, and it took me a long time to crack.
Availability is its own constraint. In Lab 017 I went looking for who would actually sell me AMD Instinct-class capacity self-serve, and the answer was mostly nobody. Google Cloud refused accelerator provisioning on that account outright. Hot Aisle turned out to be the only self-serve door I found, at $2.99 an hour for a single MI300X and $5.98 for a pair, provisioned by API in seconds.
That’s the good news. Here’s the rest of it. When I went to provision, the shelf showed a quantity of one. Hot Aisle was sold out of everything except the two commonly-visible on-demand instances. The door exists, and it’s narrow.
The pattern across the labs sorts into three corners, and you only ever get two of them:
| What it costs you | |
|---|---|
| Capable and cheap | Not available. MI300X at $2.99/hr with a shelf depth of one or two. I held the last unit. |
| Capable and available | Not cheap. Managed inference at list, priced per million tokens. |
| Available and cheap | Not capable. The Spark. The L40S. |
Watch that last corner if you’re tempted by whatever is always in stock. Permanent availability is a price signal. What stays rentable is what the market has already judged, and it usually judged on capability.
The wall isn’t always inventory, either. Sometimes it’s policy, and it’s instant. On one Google Cloud project a four-L4 shape at $3.99 an hour would have fit the model I needed to run. The quota request was denied in 2.1 seconds. CPU quota bumps on the same project auto-approved in four to six minutes. That project carries zero GPU quota in every region, and no H100, H200, B200, or GB200 metric exists on it at all. You can’t rent what you’re not allowed to request.
So read the table above with that caveat attached. “Rent the peaks” is sound advice right up until the peak arrives and there’s nothing on the shelf. Owned capacity carries an availability premium that no hourly comparison captures: the box in your rack is never sold out. If your work is bursty and the burst has a deadline, you are not really choosing between $5.65 and $2.99. You’re choosing between capacity you control and capacity you hope is there.
That cuts both ways, and it’s why I keep saying measure the queue first. If your bursts are predictable, reserve. If they’re not, the availability premium may be the strongest argument for owning anything at all.
I wasn’t buying speed. I was buying certainty.
This is the thing that actually decided the Spark purchase, and it took me until now to say it cleanly.
I wasn’t buying speed with the second box. I wasn’t even buying capability. I was buying certainty. I can still burst to an MI300X when I need an answer accelerated, and it is more than capable. But the shelf showed me a quantity of one. I can’t depend on it being there the morning I need it.
The scarce resource here isn’t the person. It’s elapsed development time, and you can’t put a schedule on capacity that might be evicted, might be sold out, or might need a procurement cycle. Spot is a published price for capacity you can’t count on. Committed spend is capacity you can count on, bought before you know whether you’ll need it. Between those two sits every organization deciding whether its ML people are allowed to start something on a Tuesday.
Owned capacity resolves that, and not by being fast. The Sparks are slower. They are also guaranteed. Never sold out, never queued behind an approval, indifferent to whether the experiment turns out to be worth running.
Let me be fair to the rented card, because the honest version of this is better than the flattering one. An L40S has far faster memory than a Spark does. On work that fits, it should finish first, and I’d expect it to. I’m not claiming the box on my bench is quicker.
I’m claiming it’s bigger. A Spark carries 128GB of usable model memory against 48GB on the rental class I keep landing on, and my labs served models on the owned box that an L40S can’t hold at all. That’s the trade, stated plainly: the rented card is faster at the problems it can run, and there are problems it can’t run. A ceiling doesn’t care how fast you approach it.
That memory ceiling is what I can reliably get past by owning the hardware, and it’s a large part of what a GB300 deskside system is actually selling.
So the duty-cycle table is necessary but not sufficient. At 8 hours a day on weekdays that box costs $23.71 an hour and looks like a bad trade against $10.50 published. But you aren’t buying hours. You’re buying the guarantee that the expensive resource is never blocked, never waiting on procurement, and never watching a fifteen-hour run get evicted at hour nine.
Where this sits on the factory floor
I’ve been building an AI Factory Economics framework for CIOs, and this post belongs to one specific floor of it. Layer 0 in that framework, the input supply chain. What the factory consumes before it produces anything.
Thursday’s post asked what a finished unit costs once you count the scrap. Cost per solved task, yield, the models you throw away. That question assumes the line is running.
This one is the question underneath it. Can you buy the input at all?
The framework already names the risk: capacity scarcity, vendor concentration, pricing volatility. What I didn’t have until this year was a way to measure it. Now I do, and it’s deliberately boring. Try to provision. Timestamp what happens. Write down what the shelf said. Do it every week and you have a door ledger, which turns “GPUs are hard to get” from a complaint into a procurement attribute you can put in front of a CFO.
Call it capacity liquidity. Which leaves me with four numbers where I thought I had one, and they don’t substitute for each other. Cost per solved task asks what the answer cost. Time to answer asks how long before it exists. Research throughput asks how many questions you can close in a month. Capacity liquidity asks whether you can get the compute at all.
Thursday’s post measured the first. Everything in this one is about the other three.
How do you justify this against a forklift?
If I’m sitting in a CIO’s chair, that’s the question, and I mean it literally. A forklift is capital equipment on a factory floor. So is this box.
Nobody agonizes over justifying a forklift. You know what it costs, you know how many hours a shift it runs, and you know exactly what happens without it. People carry things by hand and the line moves at walking speed. The justification was never the machine’s hourly rate. It’s the throughput you don’t get without the machine.
Justify the GB300 the same way. The duty-cycle table above is forklift math. $23.71 an hour at eight hours a day on weekdays is either reasonable or ridiculous depending entirely on whether the thing actually runs.
Then the analogy breaks, and it breaks in the direction most people don’t expect. You can always rent a forklift. There’s a yard across town with a dozen of them and a published day rate. That market works, which is why no operations leader builds a strategy around forklift scarcity.
There’s no yard for a GB300. On-demand at that tier is contact sales, spot isn’t offered, and the good-enough substitute is sitting at a shelf depth of one. So the availability premium that stays invisible in every forklift decision is the whole decision here.
A CIO who can answer “how many hours a week will this run” can justify a forklift. This box needs a second answer. Does the line stop when the capacity isn’t there at all?
How I’d decide now
Three questions, in this order, and the hardware quote doesn’t appear until the third.
How long do people wait? Not utilization. Utilization tells you the machine is busy, which the finance team likes. Queue depth tells you people are blocked, which is what costs you. They are not the same number and only one of them is on the invoice.
What is the delay worth? Not the wait multiplied by a salary, which only prices idle people and lets anyone with busy engineers off the hook. Price the delay against whatever the answer unblocks: the decision, the release, the next experiment. That’s harder to defend in a spreadsheet and it’s the honest number, and it’s usually far larger than the hardware being debated.
Can your people count on it? This is the one that separates buying from renting, and it isn’t a cost question.
The split I’d draw is by workload, not by budget. Production inference is predictable, sized in advance, and runs continuously. That belongs on CoreWeave or a hyperscaler floor, where scale and published rates work in your favour. Development is the opposite: bursty, unpredictable, and the whole value is speed to an answer. That’s where deskside capacity earns its price, because the alternative is putting your schedule on a shelf you don’t control.
If there’s no queue at all, you don’t have a hardware problem, and no amount of GB300 will produce one.
So what?
The second-Spark debate optimized the wrong variable. I was pricing an asset when I should have been pricing a constraint. The owned box still earns its place for patient work: big models, overnight grinds, anything unattended where slow and free beats fast and metered. But for the questions in the queue right now, waiting on GPU, slow hardware isn’t thrift. It’s answers arriving later, and every answer that arrives later drags the questions behind it along too.
If you’re holding a quote like mine, the number on it is the least interesting thing about the decision. What matters is how many hours a year it will run, and what isn’t moving while it doesn’t.
The bottleneck is never the cheap resource. Price the constraint, not the box.
Disclosure, carried over from Lab 017 where the Hot Aisle pricing and availability findings come from: Hot Aisle’s CEO credited $100 to the account after it was opened, and that lab spent $29.75 of it. The credit funded the compute, not the answer. Hot Aisle did not commission, review, or see the lab before publication, and self-serve payment was available throughout, so the credit never gated access.