When a reserved GPU pod beats a neocloud waitlist

A platform lead had two artifacts on the same slide: a neocloud waitlist confirmation and a training window the board had already funded. The waitlist moved a generation. The window did not. They spent a quarter “staying close to allocation” and another quarter collecting versus-spreadsheets. The useful question was never “which cloud is cheaper this week.” It was: is this a cloud-SKU problem, or do we need a reserved pod with a date? This page is that decision guide. Full vendor-versus-vendor writeups stay on the mothership — start with Pacific vs CoreWeave: reserved pods vs neocloud queues.

The waitlist answers a different question

A waitlist is a marketing list with a progress bar. It tells you the vendor hopes to have inventory in a region, on a SKU, at some future allocation. A reserved GPU pod is a physical module: named architecture, a site you can walk, and an acceptance gate someone will witness. If your evaluation still starts with “we are on the list for the next generation,” you are not evaluating reserved capacity. You are evaluating patience. Pacific’s public reserved offer is reserved GPU capacity on pacific.space — read it as the mothership spec, not as a second brochure hosted here.

When the reserved pod is the better evaluation

• The date is real. A board, a customer, or a funded run will not move because a queue slipped.
• The SKU is named — HGX B300 or your exact equivalent — and you will not accept “H100-class at allocation.”
• Single-tenant bare metal and witnessed factory, site, and integration evidence matter more than a cloud control plane.
• You need a place you can point at: your pad, a colo, or a Pacific site — not only a region string.

If three of those four are true, stop collecting waitlist screenshots. You are shopping a reserved module. The commercial conversation is a capacity call, not another Discord role. If CUI or ITAR is also in play, that is a different axis — residency, not a queue — and you should not mix it into this evaluation.

When the neocloud still wins

Be honest when the cloud is the product you actually want. You already run on CoreWeave and need more of that API, those regions, and those instance SKUs. You need elastic burst in their footprint this week, not a reserved module on a pad. Your team is built for cloud instance orchestration and will not operate a site-deployed cluster. Those are real wins for a neocloud. The mothership says so in public: Pacific vs CoreWeave is explicit about when CoreWeave wins. Pacific vs Lambda: procurement-clear reserved clusters is explicit about when Lambda’s familiar cloud invoice is the better fit — workstations, small boxes, time-to-first-GPU in a public region. We will not re-host those tables on trypacific.space.

How to run the evaluation without a bake-off clone

Score the decision, not the brand. Can the vendor reserve inventory to this award, by allocation or serial? Is the operational window a target or a commitment? What evidence do you get at handoff? If the answer is a waitlist, you have your comparison already. If you still need a versus-page after that, stay on the mothership comparison URLs. Do not ask this satellite to become a second pacific.space/comparisons index.

The handoff

If the reserved pod is the evaluation, open reserved GPU capacity. If you still need the vendor-versus-vendor pages, use Pacific vs CoreWeave or Pacific vs Lambda. Then book 30 minutes with Harper. The calendar is the only booking path. This site’s job is to get the decision right before you spend the call.