We rented Nvidia B200 GPUs through a single API call, 33 times, and measured what happened. Every job in this run was a B200. Here are the results.
What we ran
Kilawatt Cloud is an orchestration layer that routes GPU jobs across multiple suppliers. In this run we sent 38 B200 requests to the API. The router launched 33 of them: 30 five-minute jobs and 3 one-hour jobs. Across those 33 jobs we launched 39 cards.
The headline numbers
31 of 33 launched jobs came up ready (94%). The two that did not were refunded automatically.
37 of 39 cards came up ready.
25 of the 31 ready jobs were ready in under 60 seconds.
By supplier
RunPod: 13 launched, 13 ready. Median time to ready was 8 seconds. The slowest was 14 seconds.
Vast.ai: 20 launched, 18 ready. Median time to ready was 44 seconds. The slowest was 316 seconds.
The one-hour test
The RunPod one-hour job ran the full hour. We checked its health 87 times and all 87 checks passed. It logged 0 XID errors, 0 uncorrectable ECC errors, and a peak GPU temperature of 34C.
Both Vast.ai one-hour jobs stopped about 15 to 16 minutes in. That was at the supplier account level, not a hardware fault. We are not counting them as host failures.
What did not launch
Five requests for four cards at once could not be placed. RunPod had no machine available, and the Vast.ai quote for four cards failed our pricing check. Nothing was charged for those requests, and the router skipped them instead of forcing a bad launch.
What this does and does not show
This is a small run on one GPU type. It measures how fast and how reliably the router gets a B200 to ready. It does not yet measure what happens when a host dies mid-job. That is the next test we are building: checkpoint-aware jobs that resume on a second supplier. We will publish the timings we measure, whatever they are.
Read the full report
The full report, with charts and the job-by-job breakdown, is on our Super Intelligence page:
kilawattcloud.dev/super-intelligence
Open the latest entry, "Nvidia B200 Chips, Rented by API: 31 of 33 Jobs Came Up Ready", to read or download the PDF. We publish each test run there, including the ones that do not go perfectly.
Questions about the method or the raw numbers are welcome in the comments.
Top comments (2)
The counts reconcile (13 + 20 = 33 launched, 13 + 18 = 31 ready), so the question is what the denominator hides.
Do the 6 extra cards (39 across 33 jobs) all sit in the multi-card jobs, and were the 2 not-ready cards the same 2 failed jobs?
Thank you, this is a fair read, and your reconciliation is right.
Denominator. The headline counted launched jobs. Counting every request, it is 31 of 38, about 82%. The 5 requests that could not be placed were four-card requests with no capacity, and nothing was charged. We should have shown that next to the headline.
Ready versus completed. Agreed. Both one-hour Vast.ai jobs stopped at about 15 to 16 minutes, while the one-hour RunPod job ran the full hour. We believe it was a condition on our test account, not hardware, but we have not proven it, and our platform classified those stops as customer-initiated, which we are reviewing. Future reports will show ready rate and completed-duration rate side by side.
Your two questions. Yes to both. The 6 extra cards were six two-card Vast.ai jobs, all of which came up ready, and the 2 not-ready cards were the same 2 jobs that never came up.
p90. Good suggestion. So far we have published only medians and slowest times. We will add p90 time-to-ready per provider to the next report.
On RunPod versus Vast.ai, agreed: at these sample sizes it is a suggestion, not a ranking.