NVIDIA's B300 is the GPU everyone is asking about. So on October 2, 2026, we ran a live test to find out what is actually available to rent on demand right now.
An autonomous agent surveyed four suppliers for multi-GPU B300 capacity, then requested, paid for, and received a machine in USDC on Base. No account, no API key, no human intervention. Here is exactly what it found.
The survey
Before paying for anything, the agent read each supplier's live inventory.
| Supplier | B300 availability at time of test |
|---|---|
| RunPod | Up to 2 cards in one machine, limited stock |
| Vast.ai | None in stock |
| Lambda | None in stock |
| Hyperstack | None in stock |
RunPod was the only supplier with any B300 inventory, and its largest machine was two cards. Because no supplier listed a four-card or eight-card B300 machine, we did not attempt requests of that size.
The job
The agent requested the two-GPU B300 machine and paid for it on Base.
| Supplier | Config | GPUs booked | GPUs ready | Time to ready | Paid | Outcome |
|---|---|---|---|---|---|---|
| RunPod | 2x B300 | 2 | 2 | 17 seconds | $2.97 USDC | Delivered |
- Confirmed hardware: the supplier's own machine report confirmed two B300 GPUs.
- Time to ready: the machine reached a healthy state 17 seconds after payment.
- Lifecycle: it ran its ten-minute booking and shut down on schedule. Our platform recorded the shutdown at the ten-minute mark, and RunPod no longer listed the machine afterwards.
- Real money: the payment was a real USDC transaction on Base against the production endpoint. Nothing was simulated.
What this tells you
The number of B300 jobs we could run was limited by market supply, not by the platform. Our platform can request B300 jobs up to eight cards per request, but only one supplier listed any B300 inventory that day, and only up to two cards.
That fits how a new GPU generation usually behaves. Capacity for a newly released generation is largely committed to long-term reservations, so on-demand inventory is scarce. If you need guaranteed B300 volume, on-demand marketplaces are probably not the right channel. Dedicated capacity agreements are, and that is a separate sourcing conversation.
Limits of this test
- One snapshot: inventory was read immediately before the request, and stock is not a reservation. It may look different an hour later.
- One job: a single two-GPU job is a live data point, not a benchmark. It says nothing about larger B300 configurations.
- Platform and supplier records: figures come from Kilawatt Cloud's platform records and the supplier's own machine report.
What's next
We will re-check B300 availability across all four suppliers on a regular cadence, and run more two-GPU B300 jobs as stock allows. As soon as a supplier lists a larger single-machine B300 configuration, we will test it and publish the result the same way, failures included.
Read the full reports
Every live verification run we do is published in full, with the provider, GPU count, result, time and cost for each job. You can read all of them on our Super Intelligence page:
https://kilawattcloud.dev/super-intelligence
If you are building agents that need B300 capacity, or you have seen different availability on your side, we would like to hear about it.
Kilawatt Cloud: https://kilawattcloud.dev
Top comments (3)
Solid write-up. The multi-supplier arbitration approach is exactly what we ended up building internally last year when H100 lead times hit 40+ weeks — except we wrapped it in a lightweight operator that watches capacity APIs and auto-rebalances reservations across clouds based on spot/on-demand pricing deltas and quota headroom.
Couple things that'd make this even more useful for teams actually trying to land these:
Quota vs. real availability gap — Most suppliers show "available" but hit you with regional quota walls at provision time. Did you track how often the x402 response said yes but the actual
CreateClustercall 403'd? That delta burned us weeks on A100s.Pre-warm/hold patterns — Some vendors let you hold capacity for 15-30 min via a soft reservation endpoint (undocumented, but exists on two of the four you tested). Worth probing if B300 inventory exposes that — cuts contention when you're spinning up 64+ node training runs.
Interconnect topology leakage — x402 doesn't surface NVLink domain layout. We've had "available" nodes land in separate switch domains, killing AllReduce bandwidth. Now we bake a topology probe into the selection loop before committing.
Failure domain correlation — Across four suppliers, did you check if outages correlate? Last Q3, two major clouds had simultaneous NVLink firmware rollouts that bricked (site: labagent .tech)
Except you're a Bot, so buzz off.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.