Edge coverage and high density used to be two purchases. AI inference has made them one.
Until recently, a European infrastructure team bought capacity in two shapes. Density lived in one or two large hubs near Frankfurt, Amsterdam or London, where power was plentiful and racks could run hot. Edge meant a handful of small, low-power footprints close to users, for caching and connectivity. Nobody expected a 40 kW rack in Lyon or Birmingham.
AI inference has changed the shape of demand. Models are served to users, and users are spread across cities, so the GPUs that serve them need to be spread across cities too, each site drawing power densities that used to be hub-only. Regulated data adds a second pull in the same direction: it has to stay in-country, so the compute has to come to it. The result is a new buying requirement, multi-city coverage with high density at every site, and a provider market that was not built for it.
This guide is for infrastructure and platform teams comparing European regional colocation providers for that requirement, whether you run a GPU cloud, serve inference to European customers, or are expanding a platform into new countries at 1 to 5 MW. It covers the three kinds of provider you are actually choosing between, what to measure on coverage and on density, where “without hyperscale complexity” is true and where it is not, and a scoring sheet you can take into the comparison.
You are choosing between three kinds of provider, not thirty
Most comparison spreadsheets list every operator in every target city. Sort the market first into three shapes, decide which shape fits the workload, and compare within it.
| Provider shape | Coverage | Density | Commercial model | Fits best when |
|---|---|---|---|---|
| Hyperscaler regions | A few large regions per country or per continent; edge zones in some metros | GPU capacity in selected regions, allocated by quota, often waitlisted | Consumption pricing, egress charged, shared responsibility | Demand is elastic or global, and the data is not regulated |
| National hub colocation | One or two campuses per country in the main interconnection hubs | Very high density at campus scale, large contiguous halls | Multi-year leases, priced per kW, ecosystem value from interconnection | A single large deployment that needs the densest interconnection ecosystem |
| Regional edge platform | Many mid-sized facilities across cities, under one operator | High-density rows or halls at each site, sized for 1 to 5 MW deployments | Multi-year leases, priced per kW, one contract and one operating standard across sites | Compute has to sit near users or in-country, in several cities, with the same density everywhere |
The honest version of the comparison: hyperscalers win on elasticity, hubs win on ecosystem scale, and regional edge platforms win when the workload is distributed by design. Inference served to users across Europe is distributed by design. So is anything bound by in-country data rules. If that is your workload, the rest of this guide is about comparing providers in the third row.
Comparing multi-city edge coverage: measure reach, not the number of pins on the map
A provider’s site count tells you about the provider. What you need to know is how much of your demand each provider puts within reach. Measure that.
- Users within a latency budget. Take your user or customer distribution by city, set a round-trip budget for the workload (for interactive inference, 10 to 20 milliseconds end to end is a common target), and calculate what share of users each provider’s sites cover inside it. A provider with twelve sites in the wrong cities loses to one with six in the right ones.
- Latency to three places, per site. To your users, to the nearest hyperscaler region you still depend on, and to the regional internet exchange. Ask for measured figures or run your own tests from a trial rack. Brochure latency is usually from the city centre, not from the building.
- One operator at every site. Some “networks” of sites are a mix of owned, partner and reseller facilities. Confirm the same company operates every site you will use, under one contract, one SLA, one support desk and one security standard. Every exception becomes a second set of audits and a second escalation path.
- Private connectivity between sites. Multi-city inference needs model updates, replication and monitoring traffic moving between sites. A provider with its own inter-site backbone, or standing private links, saves you from procuring and securing those paths yourself.
- Local ecosystem at each site. Carriers on-net, internet exchange access and cloud on-ramps, counted per site, not as a group total. A strong hub and five weak satellites is a hub, not a platform.
- The next city on the same terms. Ask what it takes to add a site in a year: same contract, same pricing structure, same lead time? Regional expansion is a sequence, and the second and third deployments should get faster, not start from scratch.
- Deployment speed per site. Pre-configured cabinets, standard power and cooling options, and remote hands who know GPU hardware. Time to first rack in a new city is a coverage metric.
- Borders that matter to you. If your users or regulators are in the UK or Switzerland as well as the EU, count coverage across all three legal spaces. “EU-based” is the search term; your actual requirement may be wider.
Comparing AI-ready high density: verify what is installed, not what is planned
“AI-ready” is the most inflated phrase in European colocation this year. The numbers below are the ones that cut through it. Ask for each per site, in writing, and ask whether it is in service today or on a roadmap.
- Sustained kW per rack, today. A single 8-GPU inference node draws roughly 10 to 12 kW, so a rack of four is 40 to 50 kW before networking; next-generation rack-scale systems go well beyond 100 kW. Ask for the density the site can sustain across a full row, not the peak a single showcase rack hit once. Anything the provider cannot deliver on a signed order within your lead time is a roadmap, not capacity.
- Cooling method and its ceiling. Standard air cooling tops out around 15 to 20 kW per rack. Rear-door heat exchangers extend that to roughly 40 to 60 kW. Direct-to-chip liquid cooling, with coolant distribution units and a facility water loop, is what sustains 60 kW and above. Ask which of these is installed, what the supply water temperature is, and whether your hardware vendor’s cooling spec is supported without modification.
- Power headroom and lead time. Megawatts available now, headroom at the substation, and the lead time to add the next megawatt. Dual feeds, UPS and generator cover for the full high-density load, not just the standard halls. In many European metros grid connection is the real constraint, so a provider with secured headroom is worth a premium.
- Floor loading and cabinet specification. Fully populated GPU racks exceed 1,500 kg. Confirm floor loading per square metre, 48U cabinets with the depth and width for current servers, busbar or tap-off power distribution, and in-rack PDUs rated for the load.
- East-west networking in the hall. High-density inference clusters move data between racks constantly. Confirm fibre paths between cabinets, and room for the switching your fabric needs, whether InfiniBand or RoCE over Ethernet.
- Expansion in place. Contiguous rows reserved for your growth, with a right of first refusal on adjacent space. Scaling into a different hall, or a different building, is a second deployment with a second set of costs.
- Pricing you can model. Price per kW, whether it is metered or flat, the density premium if any, and the minimum commitment. If the quote needs a bespoke engineering study before the provider will name a number, the capacity is probably not built yet.
- Customers you can call. Ask for GPU cloud or inference customers running at the density you need, at the sites you are considering, and talk to them. It is the only metric that cannot be put on a roadmap.
Energy source belongs on this list too. Regulated and public sector customers increasingly ask where the power comes from, and some tenders score it. Ask for the renewable share and the PUE per site, and whether the figures are measured or targets.
“Without hyperscale complexity” is true commercially and legally, and only partly true operationally
Colocation removes a specific set of problems, and a good buyer’s guide should say which ones. It does not remove every problem, and a provider who claims it does is selling something else.
Complexity you leave behind
- Consumption billing you cannot forecast, and egress charges that grow with your own success
- GPU quotas, waitlists and region constraints that put your capacity plan in someone else’s hands
- A shared-responsibility model that is clear in the diagram and argued over in the incident review
- Proprietary services that make the second provider harder to adopt than the first
- A hardware roadmap decided by the cloud’s purchasing, not yours
Complexity you still own
- Buying, installing and refreshing the hardware, and the capital that goes with it
- Running the cluster: scheduling, fabric, firmware, failures at 3 am
- Designing the cooling and power with the provider, rack by rack
- Capacity planning for each city, because racks do not autoscale
- Securing everything above the cage door
For a GPU cloud or an inference provider, the second list is the product, and owning it is the point. For an enterprise platform team, it is a real cost to weigh against the first list. Either way, the right regional provider is the one that shrinks the second list without pretending it is empty: standard cabinet products that are powered and ready, remote hands who have handled GPU servers, live capacity visibility, a single contract and portal across every city, and pricing you can put in a spreadsheet without a sales call. Those are the things to compare, because they are where the complexity actually goes.
