How colocation data centres can offer GPU cloud without the hardware risk
How can a colocation provider offer GPU cloud services?
A colocation provider can enter GPU cloud through two routes, neither of which requires buying GPU hardware.
Route 1: attract GPU hardware owners who need a facility. They co-locate their nodes, connect them to hosted·ai, and publish virtual GPU pools to GPU Mesh. The colo earns colocation and power revenue. The hardware owner earns GPU cloud revenue.
Route 2: the colo installs its own GPU hardware, deploys hosted·ai, creates virtual GPU pools, and sells GPU cloud to its tenants and new customers. GPU Mesh is not a hardware procurement channel in either case. It is a software-defined capacity sharing network where suppliers publish virtual pools and buyers subscribe to them. The hardware stays in the colo. What the network distributes is access to compute time on that hardware.
What GPU Mesh actually is
GPU Mesh is built into the hosted·ai platform. Suppliers, companies with GPU hardware, use hosted·ai to create virtual GPU pools from their physical nodes with configurable overcommit, then publish those pools to the Mesh. Buyers, service providers who need GPU compute, subscribe to those pools and re-sell access to their own end customers. The hardware never moves. The colo is where the hardware lives, not a party that sources capacity from the network.
This distinction matters. A colo that hosts GPU hardware tenants is already part of the GPU Mesh supply chain whether it knows it or not. When a neocloud co-locates GPU nodes and connects them to hosted·ai, that colo's facility becomes the physical substrate for a GPU Mesh supplier. The colo does not need to do anything differently to participate. It needs to attract those tenants.
Why colos are well-positioned
AI infrastructure needs power density, low-latency network connectivity, InfiniBand-capable facilities, and physical security. Colocation providers have built and certified exactly that. What most have not had is a clear commercial path from those assets to GPU cloud revenue.
Enterprise AI procurement teams are now actively evaluating GPU cloud outside hyperscalers. Colos that can credibly support GPU workloads, whether by hosting GPU hardware tenants or by running their own hosted·ai deployment, are in those conversations. Those that cannot are watching the revenue go to neoclouds already sitting in their racks.
Route 1: colo as GPU hardware host
The colo attracts GPU hardware owners who need a verified, well-connected, InfiniBand-capable facility. Neoclouds, infrastructure investors, energy companies with GPU nodes: all need somewhere to put hardware. The colo provides the rack space, power, cooling, and connectivity. The hardware owner installs their nodes, connects them to hosted·ai, and either publishes virtual GPU pools to GPU Mesh or sells directly to their own customers.
The colo earns colocation, power, and connectivity revenue. It does not operate the GPU cloud, manage GPU pools, or deal with GPU end customers. This is the lower-risk entry point. It requires no operational change and no software deployment. The colo's existing colocation business model is unchanged; GPU cloud revenue is what the tenant generates from the hardware the colo hosts.
GPU rack revenue in AI-grade facilities is typically higher than standard IT colocation because GPU hardware is power-dense and operators pay a premium for certified InfiniBand-connected space.
Route 2: colo as GPU cloud operator
The colo installs GPU hardware in its own facility, deploys hosted·ai, and operates a GPU cloud product directly. Using hosted·ai, the colo creates virtual GPU pools with overcommit ratios from 2x to 5x, configures a white-label customer portal under its own brand, sets pricing, and sells GPU compute to its existing tenant base and new customers.
The colo can also publish its GPU pools to GPU Mesh. Other service providers subscribe to those pools and re-sell the capacity to their own customers. The colo earns wholesale revenue from that consumption without additional sales effort. The pools are visible and managed through the same hosted·ai admin panel as direct customer sales.
Route 2 captures both colocation margin and GPU cloud margin. It is the higher-revenue option and carries more operational complexity and GPU CAPEX. The practical path is to start small: one GPU pool, a limited initial customer set, validate the economics, then expand.
Combining both routes
Colos can run both simultaneously. Host external GPU hardware from tenants in Route 1 mode, and run a separate owned-hardware GPU cloud in Route 2 mode, with all pools managed through one hosted·ai admin panel. The tenant's pools and the colo's own pools are separate in the admin but visible in the same interface.
Economics
Route 1: standard colocation pricing per rack or per kW, with a premium for GPU-grade power and InfiniBand connectivity. GPU cloud revenue belongs to the hardware owner.
Route 2: economics depend on hardware cost, overcommit ratio, and utilisation. GPU overcommit at 5x on a pool of H100 nodes with inference-heavy customers produces gross margins of 50% or more. The hosted·ai scheduler manages overcommit safely so customers get the performance they paid for while the operator maximises revenue per physical GPU. Publishing pools to GPU Mesh adds passive wholesale revenue on top of direct customer revenue.
Route 2 CAPEX risk: a rack of H100 nodes costs $2 to $3 million. If demand does not come, that capital is at risk. The hedge is a phased build: start with a small pool, validate demand with real customers, expand from evidence. GPU Mesh provides external demand from other service providers immediately, supplementing the colo's own sales while the direct customer base grows.
Getting started
The starting point is deciding which route fits the existing business. Route 1 needs no software deployment and no hardware investment. Route 2 needs a hosted·ai deployment and a minimum GPU hardware commitment.
The hosted·ai team can walk through the commercial model and the technical deployment for a specific colo configuration.