Who Buys GPU Capacity Through GPUaaS.com, and What They Expect

◆ THE FOUR BUYER PROFILES AT A GLANCE

Profiles drawn from requests through the GPUaaS.com network, 2026, reported as typical ranges and direction only. Individual requests vary widely.

◆ PROFILE ONE

The AI product company: inference, cost per token, and a start date this week

This is the most frequent request type. A company with a model in production, serving customers, whose inference bill on a hyperscaler or neocloud has grown past the point where committed capacity makes sense. They know their throughput, they know their cost per million tokens, and they arrive with a target number. The request is usually 8 to 64 GPUs on a six to twelve month term, with B300 or B200 for large models and H200 or RTX PRO 6000 where the model fits in less memory. Ethernet is almost always acceptable because inference does not all-reduce.

What they check: can the provider provision this week, what is the uptime commitment, and what happens when a GPU fails at 2am. They care about support hours more than most providers expect, because an inference outage is a customer-facing outage. They care less about InfiniBand and more about network egress to their users.

For a provider this buyer is the fastest to close and the easiest to keep. They renew if the service held up, and their capacity needs grow with their customer base. The inference majority post covers why this profile now outnumbers training buyers.

◆ PROFILE TWO

The enterprise AI team: a project with a start date, an end date and a procurement department

An enterprise team buys capacity for something specific: fine-tuning a model on internal data, a training run for a product launch, a proof of concept the board has funded. The request has a defined scope, which is why it has a defined term, usually three to twelve months, and a defined size, usually 16 to 128 GPUs. Training asks specify H100 SXM or Blackwell with InfiniBand; fine-tuning and evaluation are more flexible.

What they check is everything, in writing, because procurement will ask. SLA with uptime figures, support hours and escalation path, replacement policy, security posture, data handling, insurance, and whether the provider has done this before. The vendor evaluation checklist is the buyer-side version of their questions and a provider who has read it quotes faster.

This buyer is slower to sign and more demanding on documentation, and in exchange they sign larger contracts and rarely churn mid-term. A provider without written SLA and support policies loses them before the quote is read.

◆ PROFILE THREE

The research lab: grant cycles, price first, and loyal once signed

Universities, research institutes and the research arms of larger organisations buy on a different clock. The budget arrives with a grant, has a spend-by date, and is fixed, which makes this buyer the most price-sensitive on the platform and the most flexible on everything else. They ask for 8 to 32 GPUs, frequently H100 or A100 because the band is lower, sometimes H200 for memory. Region rarely matters unless the grant specifies it. Term aligns to the grant, so three, six or twelve months.

What they check is the price, then whether the capacity can be paused or extended as the project moves, then whether students can get SSH access without a ticket. They are slow to sign because institutional procurement is slow, and once signed they are the least likely to leave, because switching costs them time they do not have.

For a provider with previous-generation hardware, this is the buyer. An A100 or H100 PCIe fleet that struggles to attract an AI product company is exactly what a lab with a fixed grant is looking for.

◆ PROFILE FOUR

The sovereign or regulated program: jurisdiction first, everything else second

Government programs, regulated financial and healthcare organisations, and national AI initiatives specify where the data sits before they specify the GPU. The request names a country, sometimes a region within it, and sometimes the legal jurisdiction of the operator. Only then does it name H200, B300 or GB300 NVL72, in sizes from 32 GPUs to whole racks, on terms of twelve months and longer.

What they check is residency documentation: where the facility is, who owns the operator, what law applies to the data, and whether that can be evidenced. The October demand snapshot found this to be the hardest request type to fill, particularly in Europe since the EU AI Act reached full applicability, and the one where a provider with the right paperwork has the least competition.

This buyer is the slowest to sign and the largest when it does. A regional operator in Germany, the Gulf, India or Japan with documented jurisdiction is competing for these requests against very few others.

◆ WHAT TO LIST

Match the fleet to the profile that will ask for it

A provider with Blackwell nodes on Ethernet in a US facility is listing for AI product companies and should document uptime, support hours and provisioning speed. A provider with H100 SXM on InfiniBand is listing for enterprise training teams and should have the SLA, security and escalation paperwork ready before the first request. A provider with A100 or H100 PCIe is listing for research labs and should price at the bottom of the band and be flexible on pause and extension. A provider in a named jurisdiction with documented residency is listing for sovereign programs and should say the country and the governing law on the listing itself.

Most providers fit more than one, and a listing can serve all of them. What changes is which documentation gets written first. The supply anchor post covers what buyers check and the one node post covers how to list.

For the AI product company profile specifically, the same hardware can also be offered through packet.ai as token-metered inference, which reaches the companies that are not yet ready to commit to a cluster but will be within a year.

◆ FAQ

Frequently asked questions