How GPUaaS.com Routes a Buyer Request to the Right Provider

◆ STAGE ONE: QUALIFICATION

What a request has to contain before anyone sees it

A request arrives through the cluster page form, by email, or from a sales call. It does not get routed to a provider until it has been qualified, and qualification is where most of the noise is removed. The first gate is size. GPUaaS.com works at a minimum of one 8-GPU node, so a request for two H100s or a single B200 does not go to the network. It goes to packet.ai, where single-GPU and per-token access is handled on a self-serve basis, and the buyer gets a reply saying so rather than silence.

The second gate is term. A request with no term is not quotable, because the band for the same part moves with the commitment length and a provider cannot price 8,760 hours the way they price 720. If the form says "flexible" or "as needed" the team goes back to the buyer with a direct question: is this a short-term or a long-term commitment, and if short, how short. Month-to-month is possible, but the October demand snapshot showed six-month and longer terms getting filled faster and cheaper than anything shorter, and the team says so at this stage.

The third gate is geography. GPUaaS.com can source capacity in any region except China and Taiwan. A request that needs capacity inside either does not get routed. Everything else does, including requests with hard residency requirements in a single European country, which are harder to fill but entirely in scope.

Only after those three gates does a request get its own record and a named owner on the team. By that point it has a GPU model, a count in multiples of eight, a term, a region or residency constraint, a fabric requirement if the buyer stated one, and a start date. Anything missing is asked for before matching begins, because a half-specified request wastes a provider's time and produces a quote that gets re-done.

◆ WHO IS IN THE POOL

How providers get vetted before they can be matched

A request is only ever routed to a provider who has already been through vetting. There is no cost to apply and no cost to list, but there is a review, and it is not a form you fill in and forget. The team looks at four things. Hardware: what you actually have racked, with spec sheets, not what you have on order. Facility: power density per rack, cooling method, redundancy on power and network, and who operates the site. Support: who answers at 3am, what the replacement window is on a failed GPU, and whether there is a human on the end of the line or a ticket queue. Commercial standing: whether the business can sign a multi-month contract and carry it.

That vetting is why the network stays at 20+ partners rather than two hundred. Buyers come to GPUaaS.com because they do not want to run their own diligence on a provider they found through a listing site, and the only way to make that true is to have done it already. The post on selling capacity without running a cloud business covers what the review looks like from the provider's side.

Once a provider is in the pool, what the team holds on them is a current inventory record: which GPU models, how many nodes, which fabric, which regions, which sites, what their realistic lead time is, and what terms they will consider. A provider with 32 H200 nodes on InfiniBand in North America who will take six-month terms and can hand over in two weeks is matchable against a very specific slice of requests. A provider whose record says "GPUs, various, ask us" is matchable against nothing, and gets asked to update it.

◆ STAGE TWO: THE FIVE MATCHING FIELDS, IN ORDER

Matching order on the GPUaaS.com network, October 2026. Price is not a filter at this stage; it is what the shortlisted providers return.

◆ HOW MATCHING ACTUALLY RUNS

Hardware first, price last

The order in the table is the order the team works in, and price is deliberately not on it. A buyer who asks for 64 contiguous B200 on InfiniBand in Europe with a twelve-month term and a start date in three weeks has already narrowed the pool to a handful of providers before anyone has mentioned a number. Running price first would mean asking twenty providers to quote a spec that fifteen of them cannot fill, and the quotes that came back would be for something other than what was asked.

GPU model is the first cut because it is binary. A provider either has H200 SXM racked or they do not. Interconnect is second because it is the field buyers most often leave blank and the one that moves the quote most after term. If the buyer says "either", the pool stays wide and the quote comes in lower. If they need every node on one fabric, the pool narrows and the quote reflects that. The B200 pricing post shows the gap in band terms.

Region is third rather than first, which surprises people. The October benchmark found regional variation in committed bands to be minimal, so region does not change the price much. What it changes is who can fill the request and how fast. North America has the deepest pool. Europe has the shortest supply of current-generation parts, so a residency-bound European request for B300 may have one or two matchable providers rather than six. APAC sits behind both on lead time. Region is applied after model and fabric so the team can see how thin the pool has become before committing to a hand-over date.

Lead time and term close the shortlist. A provider whose capacity is on order is not matched against a request that starts in three weeks, however good their price would be. A provider whose floor is six months is not matched against a three-month request. What is left, typically between two and five providers, is who gets the request.

◆ STAGE THREE: THE QUOTE WINDOW

What happens in the hours after a provider gets the request

Shortlisted providers receive the qualified spec, not the buyer's identity. They see model, count, fabric, region, term, start date and any stated constraints. They return a per-GPU-hour rate for that term, a confirmed hand-over date, and any conditions. The team collects those, checks them against the current band for the part, and sends the buyer a quote. For H100, H200 and B200 requests that process usually runs within a few hours. For GB300 NVL72, B300 at scale, or anything with single-country residency, it can run to the full 24-hour window, because the pool is thinner and providers need to confirm rack availability rather than read it off a dashboard.

The window matters for providers more than they sometimes realise. A provider who answers in two hours gets their quote in front of the buyer. A provider who answers the next day may find the buyer has already accepted, and in the current market, where most buyers are on a procurement clock, that happens often. Response time is tracked, and providers who consistently answer inside the window are routed first on the next matching request. That is the single most controllable lever a provider has over how much demand reaches them.

What the buyer sees is a quote inside the published band for the part, a named hand-over date, and the terms. What they do not see is which provider it came from, until they accept. At that point the contract is drafted between three parties: the provider, GPUaaS.com and the buyer. Neither the provider nor the buyer signs directly with the other, and the provider's commercial terms with GPUaaS.com are separate from the buyer's. No buyer fees apply, and there is no cost to the provider to have been quoted.

◆ WHY ROUTING FAILS, AND WHAT TO DO

The four reasons a request does not reach you

Providers who are in the pool and not getting requests almost always fall into one of four cases. Their inventory record is stale, so the team cannot match on it. They only hold a part that is not in demand this quarter, and the demand snapshot shows where the requests actually are. They have a term floor above what buyers are asking for. Or they have missed the quote window on recent requests and dropped down the routing order. Every one of those is fixable, and the first step is the same: send the team a current inventory, by model, node count, fabric, region and earliest hand-over.

Buyers whose request has not produced a quote are usually waiting on one of the qualification gates. A missing term is the most common. The second most common is a spec that does not exist in the pool at that size in that region, in which case the team comes back with what does exist and lets the buyer decide whether to widen the region or accept Ethernet. The one-node listing post explains why even small providers matter to that pool.

If you are a provider with racked capacity and a current spec sheet, apply to the network. If you are a buyer with a term and a count in multiples of eight, submit it on the cluster page and expect a reply within a few hours.

◆ FAQ

Frequently asked questions