You Have the GPUs. Now What? The Fastest Path from Capacity to Revenue
For a neocloud, telco, or sovereign cloud, getting GPUs racked and online feels like the finish line. But it is the starting gun.
The moment capacity is live, the commercial clock starts. Depreciation, power, and financing costs accrue whether or not a single customer is consuming the hardware. Every week spent preparing the perfect offering is a week of idle capacity.
That was the premise of "You Have the GPUs – Now What?", an invitation-only Focus Session for neocloud operators led by Cameron Kinard, Enterprise AI Strategist at Rafay, on October 8. His core argument: don't wait to build an extensive AI services catalog before monetizing your GPUs. Launch one sellable service with the right operational foundations, then expand into higher-value offerings as demand develops.
The lessons apply just as directly to telcos and sovereign clouds bringing their own GPU capacity to market.
The catalog trap
Many GPU providers respond to new capacity by planning everything at once: bare metal, VMs, Kubernetes, notebooks, fine-tuning, model serving, inference APIs. The logic is understandable. Hyperscalers offer broad catalogs, and operators want to look competitive on day one.
The problem is sequencing. A broad catalog takes months to build, and most of it is built on guesses about what customers will buy. Revenue waits on engineering, and the hardware ages in the meantime.
Kinard's alternative is to treat the first launch as a focused product decision, not a platform build-out.
Step one: define the first sellable service
The first offering should be the simplest thing a known set of customers will pay for now. For most neoclouds, that is some form of GPU compute: dedicated or shared GPU instances, or GPU-backed Kubernetes clusters for AI teams that already know what they want to run.
A useful test is whether the offering can be described in one sentence, priced on one clear unit, and provisioned without a services engagement. If it needs a custom statement of work for every customer, it is not yet a product.
The goal is not to be small forever. It is to get paying workloads onto the hardware while learning, from real usage, what customers need next.
Step two: get four foundations right
Starting narrow does not mean cutting corners. The session identified four operational foundations that every sellable GPU service needs from day one, because they are expensive to retrofit later.
Self-service delivery. Customers should be able to sign up, provision, and start consuming capacity without filing a ticket. Manual onboarding caps how fast revenue can grow.
Multi-tenancy. Multiple customers need to share infrastructure safely, with isolation between tenants. Without it, every customer becomes a dedicated deployment, and utilization suffers.
Governance. Quotas, policies, and access controls determine who can use what, and how much. They protect both the operator and the customer.
Usage visibility. Operators need accurate, per-tenant metering to bill correctly, spot underused capacity, and see which customers are ready for more. This data also guides what to build next.
Step three: avoid early operational debt
The decisions made in the first few months tend to stick. Kinard cautioned against shortcuts that feel efficient at launch but become costly at scale, such as:
Hand-built, per-customer environments that cannot be reproduced or upgraded consistently
Billing stitched together from spreadsheets instead of metered usage
Tenant isolation handled by convention rather than enforced by the platform
Tooling that works for one offering but cannot support the next
Each of these slows the second and third launches. The fix is to choose an architecture for the first service that can also carry the services that follow.
Step four: expand as demand proves out
Once the first service is live and the foundations are in place, the catalog can grow in response to real demand rather than projections. The session outlined a natural progression up the value stack:
Packaged compute. Pre-configured GPU environments sized and priced for common workloads.
AI platforms. Managed environments for notebooks, training, and fine-tuning that AI teams use directly.
Inference APIs. Model serving exposed as endpoints, so customers consume outcomes rather than infrastructure.
Token-metered AI services. Usage priced per token, the model customers already know from leading AI providers. Sovereign clouds can use this to offer in-country access to national or open models.
Each step moves the operator further from selling raw capacity and closer to selling differentiated services, with better margins and stickier customers. Because the foundations are shared, each new offering builds on the last instead of starting over.
The takeaway
For neoclouds, telcos, and sovereign clouds alike, speed to revenue matters more than breadth at launch. The operators who win will not be those with the longest service menu on day one. They will be those who start selling quickly, on infrastructure built to grow with their customers.
In short: launch one sellable service, build the right foundations under it, and let demand tell you what to offer next.
Cameron Kinard is Enterprise AI Strategist at Rafay, which helps neoclouds, telcos, sovereign clouds, and enterprises turn GPU infrastructure into self-service, token-metered AI services. His session, "You Have the GPUs – Now What? The Fastest Path from Capacity to Revenue," was presented as an invitation-only Focus Session at infra/STRUCTURE 2026 on October 8, 2026.
