7 best GPU clouds for self-hosting large models in Europe in 2026 (and where OVHcloud's B300s actually fit)

Key Points:

• B300 closes the hardware gap for one generation, and only that gap. Once OVHcloud ships NVIDIA Blackwell Ultra B300 on its Public Cloud, it matches what AWS and Google Cloud rent on paper. The capacity gap stays open (fleet size, GPU regions, multi-node interconnect). The software gap is narrowing but still there (managed Kubernetes GPU tooling, inference services, the data services that sit next to the GPU). Those three gaps are the whole decision.
• EU clouds are already a credible home for 1 to 16 GPUs. OVHcloud and Scaleway work today for steady-state inference and fine-tuning under EU data residency and EU jurisdiction. They are still the weaker choice for training runs that need hundreds of interconnected GPUs on demand.
• Egress is where the hyperscalers lose money for you. OVHcloud, Nebius and CoreWeave publish free internet egress. AWS charges $0.09/GB for the first 10 TB out of Frankfurt, which comes to about $891 a month on 10 TB, before you pay for a single GPU-hour.
• The deciding factor is rarely the GPU. It is whether you get quota in the region you need, plus a managed Kubernetes and an inference stack (vLLM, SGLang, Triton, KServe) your team can run without a dedicated GPU platform crew.
• Sovereignty has three layers. Data residency (where the bytes sit), jurisdiction (whose law binds the contracting entity) and operational sovereignty (who can touch the control plane, and where support staff sit). A datacenter in Frankfurt answers only the first.
• Portability is the only durable hedge against GPU scarcity. Keep the application layer on Kubernetes and provider-agnostic so the GPU pool becomes a swappable backend. Qovery runs in your own AWS, GCP, Azure or Scaleway account, or on a Kubernetes cluster you already run at a European GPU provider. Qovery does not sell GPUs and will not get you quota.

I get the same question from European CTOs every few weeks, and the B300 news made it louder: can we finally self-host our models on a European cloud, or is it still a downgrade from AWS and Google Cloud? I run a company that deploys workloads on AWS, GCP, Azure and Scaleway every day, so I have opinions. Below is the ranking I would give a friend, with every price and spec linked to the vendor that published it.

What is OVHcloud actually shipping with NVIDIA Blackwell Ultra B300, and when?

OVHcloud says NVIDIA Blackwell Ultra B300 GPUs are coming to OVHcloud Public Cloud in November 2026, but as of 7 November 2026 its public GPU page, price list and newsroom list no B300 instance, form factor, hosting region or price. So four things are still unknown in public: the price per GPU-hour, per-customer quota, how many units are deployed, and whether multi-node NVLink or InfiniBand fabrics come with it.

Here is what OVHcloud does list today on Public Cloud, all excluding VAT and billed per instance-hour:

• H200: h200-1920, 8x H200 141 GB, $49.56/hour, which is $6.20 per GPU-hour (OVHcloud prices).
• H100: h100-380, 1x H100 80 GB PCIe, $2.99/hour. Two GPUs cost $5.98, four cost $11.97.
• A100 80 GB from $3.07/hour, L40S from $1.80/hour, L4 from $1.00/hour.
• GPU regions: Gravelines (GRA5, GRA7, GRA9, GRA11) in France and Beauharnois (BHS5) in Canada (OVHcloud regions).

OVHcloud is not first to B300 in Europe. Scaleway already lists B300-SXM-8-288G at €60/hour (€7.50 per GPU-hour) in Paris (fr-par-2), and Nebius lists B300 at $9.50 per GPU-hour in its eu-west2 region in France (Nebius regions, Nebius prices). B300 on OVHcloud matters because it brings the generation to the European provider with the widest published catalog and free egress. No European provider gets an exclusive.

What does Blackwell Ultra change on paper?

The number that matters for self-hosting is GPU memory. It decides how many GPUs one model replica needs and how much KV cache is left for concurrent requests, and that drives tokens per second. Blackwell Ultra's headline is 288 GB of HBM3e per GPU, against 141 GB on H200 and 80 GB on H100.

The model in the table is Llama 3.3 70B Instruct. It weighs 141.1 GB in BF16, and the FP8 build from Red Hat AI weighs 72.7 GB.

Sources: NVIDIA Blackwell Ultra technical blog for the per-GPU comparison, NVIDIA H100 and H200 pages, and NVIDIA HGX for system totals (HGX B200 1.4 TB, HGX B300 2.1 TB for 8 GPUs). NVIDIA's product pages quote FP8 with sparsity by default, so the dense figures above are half the headline. The replica counts are my own sizing: weights plus enough room for a useful KV cache, rounded to the tensor-parallel sizes vLLM actually runs.

The measured gap between generations is larger than the spec sheet suggests. In MLPerf Inference v5.0, an 8x B200 system served Llama 2 70B at 98,443 tokens/s against 33,072 tokens/s for 8x H200, about 3x (NVIDIA). In v5.1, GB300 NVL72 delivered 45% more offline throughput per GPU than GB200 on DeepSeek-R1 (NVIDIA).

The three gaps

I use the same three gaps for the rest of this article:

1. Hardware gap: closed for one generation once B300 is live. You rent the same silicon as on AWS.
2. Capacity gap: open. Fleet size, the number of GPU regions, and multi-node interconnect for large jobs.
3. Software gap: narrowing. Managed Kubernetes with GPU tooling, managed inference, and the data services around the GPU.

An announced availability date is not a quota guarantee. OVHcloud has not published a B300 price at the time of writing, so treat any B300 budget you build today as an estimate.

How did we rank the best GPU clouds for self-hosting large models in Europe?

I scored every provider on six criteria, ordered by how often each one kills a real project. The top two are capacity/quota and sovereignty, not raw GPU specs. Every provider below is judged on the same six, with prices taken from the vendors' own pages on 7 November 2026.

1. Hardware availability and real quota. Which GPU generations, how many EU regions, and what a mid-size team can realistically get approved in under 30 days.
2. Sovereignty and compliance. Jurisdiction of the contracting legal entity, EU data residency, SecNumCloud / BSI C5 / ISO 27001 posture, and where the control plane and support staff sit. EUCS doesn't count yet: ENISA's library still lists only the candidate EUCS scheme, so no provider can claim it.
3. Software maturity. Managed Kubernetes with the NVIDIA GPU Operator, driver and CUDA lifecycle, inference endpoints, model catalogs, object storage and networking next to the GPU.
4. Published price per GPU-hour and egress. On-demand versus reserved versus spot, per-GB data transfer out, minimum commitments.
5. Operational burden. What your team has to build to go from a bare GPU node to a production endpoint with autoscaling, observability, canary rollouts and per-model cost attribution.
6. Portability and lock-in. Whether the workload can move providers without rewriting the serving and deployment layer.

Scope. I score self-hosting of open-weight models (Llama, Mistral, Qwen, DeepSeek class). Where a managed per-token API beats self-hosting outright, I say so.

Transparency. Prices are on-demand list rates, excluding VAT, as published on 7 November 2026. I keep each vendor's own currency (EUR for Scaleway and Hetzner, USD for the rest) instead of picking an exchange rate. Where a vendor does not publish a rate, the table says "not published".

Which GPU cloud should you pick in Europe in 2026? The ranked shortlist at a glance

Pick OVHcloud for sovereign steady-state inference, Scaleway for EU sovereignty with a developer-friendly API, Nebius for AI-first capacity in EU datacenters, CoreWeave for the fastest route to a new NVIDIA generation at scale, AWS for large on-demand training and reservable GPU windows, Google Cloud when TPUs are a real alternative to CUDA, and Azure for Microsoft-anchored stacks. Hetzner and other bare-metal hosts sit outside the ranking: the lowest cost per hour, and no platform at all.

My one-line verdict: go sovereign-first when jurisdiction is a contractual requirement, and go hyperscaler or GPU specialist first when you need on-demand multi-node scale.

What does one 8-GPU node cost per month, 24/7?

The unit everyone sells is an 8-GPU node, so here is one running 24/7 for 730 hours, plus 10 TB of outbound traffic. Scaleway has no H200, so its row uses 8x H100 SXM. AWS uses p5en (8x H200) in Stockholm.

The AWS egress line is (10,000 GB - 100 GB free) × $0.09 = $891. On Azure at $0.087/GB the same traffic costs $861. That is hundreds of dollars a month for moving bytes, and it grows with every customer you serve. Savings Plans and committed-use discounts lower the hyperscaler GPU line, but they do not touch egress.

What does a million output tokens cost on each cloud?

I ran the numbers for Llama 3.3 70B in FP8 on two H100s. NVIDIA's TensorRT-LLM performance page measures 4,181 output tokens/s on 2x H100 SXM at 1,000 input and 1,000 output tokens (TensorRT-LLM perf overview). The formula is (GPU-hour rate × GPUs per replica) ÷ (tokens/s × 3,600):

• OVHcloud h100-760: $5.98 ÷ (4,181 × 3,600) × 1,000,000 = $0.40 per million output tokens
• Nebius: ($4.50 × 2) ÷ 15.05M = $0.60
• AWS p5 in Stockholm: ($7.36 × 2) ÷ 15.05M = $0.98

Two caveats keep this honest. That benchmark runs at an "infinite" request rate, and NVIDIA says it is not peak performance, so these figures assume a fully busy GPU. OVHcloud's H100 is PCIe, while the benchmark used SXM, so expect somewhat lower throughput on the cheaper card.

Is OVHcloud Public Cloud a real alternative to AWS and Google Cloud for self-hosting large models?

Yes for steady-state inference and small-to-mid fine-tuning under EU jurisdiction, and even more so once B300 lands. No if you need hundreds of interconnected GPUs on demand, or if your stack depends on a Bedrock- or Vertex-style managed AI catalog sitting next to your GPUs.

Best for: EU-regulated teams in health, public sector and finance that need data residency under EU jurisdiction plus predictable, published GPU pricing.

What is genuinely competitive:

• A French contracting entity, outside the reach of US law that binds US-parented clouds.
• SecNumCloud qualifications across its range. Hosted Private Cloud was qualified in December 2020, and the public-cloud-style SNC Cloud Platform in September 2026 (OVHcloud SecNumCloud). Check which product your GPU workload lands on: the standard Public Cloud GPU instances are a different offer from the qualified platforms.
• One of the cheapest published H100 rates in this article, $2.99/hour, with outbound traffic included.
• Managed Kubernetes Service with GPU instances and a free control plane.
• AI Endpoints when you would rather not self-host: Llama 3.3 70B at €0.67 per million input tokens and €0.67 per million output, in FP8 with a 131K context.

Where the gap stays open:

• Fleet scale against CoreWeave and the hyperscalers.
• GPU regions concentrated in Gravelines.
• Fewer managed data and AI services around the GPU.
• Fewer third-party integrations that assume your cloud is OVHcloud.

Do not pick OVHcloud if you need a 512-GPU interconnected training cluster next month, or your retrieval and feature pipelines already run on managed hyperscaler services.

On risk, be factual. The March 2021 fire at OVHcloud's Strasbourg site is documented in OVHcloud's own statement. The lesson applies to every provider: run inference in at least two failure domains, and keep model weights somewhere other than the GPU region.

A test you can run this week: request quota for the exact GPU count you need in your target region, and time how long approval takes. That one number predicts your migration better than any benchmark.

When are AWS, Google Cloud and Azure still the better pick for GPU workloads in Europe?

The hyperscalers still win when you need very large on-demand training capacity, a real spot market, reservable GPU windows, or when the rest of your data platform already lives there. They lose on per-GB egress and on jurisdictional exposure, whichever EU region the bytes sit in.

AWS

• P5 (H100), P5e/P5en (H200) and P6-B200 instances, EKS with GPU node groups and the GPU Operator, and SageMaker HyperPod for multi-week runs.
• EC2 Capacity Blocks for ML reserve up to 64 instances (512 GPUs) per block, up to six months long, starting up to eight weeks ahead. In the EU they are offered in Stockholm, London, Paris and Spain.
• The Stockholm list prices show the Blackwell premium. p5 costs $58.89/hour and p6-b200 costs $143.24/hour. Per GPU, that is $17.91 for a B200 on AWS against $8.50 on Nebius.
• The AWS European Sovereign Cloud went generally available on 14 January 2026 in Brandenburg, Germany. It is backed by a €7.8 billion investment, run by German-law entities and operated by EU residents.

Google Cloud

• A3 High (H100) runs in europe-west1, europe-west3, europe-west4 and europe-west9. A4 (B200) runs in europe-west4, europe-west1 and europe-north1 (GCP zones).
• GKE runs both the GPU and TPU stacks, with Vertex AI on top.
• TPUs are the real differentiator. TPU v5e costs $1.56 and Trillium $2.97 per chip-hour in europe-west4 (TPU pricing). If your serving stack runs on JAX or vLLM's TPU backend, that changes the economics. Our TPU vs GPU cost per million tokens piece runs those numbers.

Microsoft Azure

• ND H100 v5 at $127.82/hour in Sweden Central, plus ND GB200 v6 for Blackwell.
• AKS with GPU node pools.
• The tightest fit when identity, data and compliance tooling are already Microsoft-anchored.

Where they win: multi-node interconnect at scale, spot and preemptible pricing, reservable capacity windows, and the breadth of managed data services next to the GPU.

Where they lose for EU buyers:

• Per-GB egress on top of the instance price.
• Exposure to non-EU law through a US parent company.
• GPU quota that is also hard to get. NVIDIA reported $89.0 billion of data center revenue for the quarter ended 26 July 2026, up 117% year on year, and every hyperscaler competes for that supply.

Be fair about the sovereign offers. The AWS European Sovereign Cloud, the Microsoft EU Data Boundary (completed 26 February 2025) and Google's sovereign tiers (Data Boundary, the S3NS partner cloud with Thales, and air-gapped Google Distributed Cloud) are real engineering. Ask three questions of each:

• Who holds the encryption keys?
• Who operates the control plane?
• Which legal entity signs your contract?

For the AWS European Sovereign Cloud, AWS says customers contract with Amazon Web Services EMEA SARL.

What about Scaleway, Nebius, CoreWeave and the GPU specialists?

GPU specialists usually beat both the hyperscalers and the generalist EU clouds on published price per GPU-hour and on time-to-capacity for a new NVIDIA generation. They lose on everything that is not a GPU.

• Scaleway. A French company under EU jurisdiction, with H100 PCIe at €2.87/hour, L40S at €1.47, L4 at €0.79, and 8x B300 already listed in Paris. Kapsule preinstalls the NVIDIA GPU Operator on GPU pools, and the API is one of the cleanest in Europe. It is the strongest fit for sovereignty plus developer ergonomics. We wrote up a Kapsule vs EKS comparison if you want the details.
• Nebius. Headquartered in Amsterdam and built around AI workloads. It has H100 and H200 in Finland, H200 and B300 in France, published per-GPU-hour prices and free egress. Its managed Kubernetes ships GPU driver images. It is the closest thing to a European CoreWeave.
• CoreWeave. The largest pure-play GPU fleet, usually first to a new NVIDIA generation, with EU zones in Sweden, Norway, Denmark, Spain and the UK, and free internet egress. It is US-headquartered, so it answers the capacity question and not the jurisdiction question.
• Hetzner and bare-metal hosts. The cheapest cost per hour in this article. A GEX63 with one RTX PRO 6000 Blackwell (96 GB) costs €999/month plus a €999 setup fee. 96 GB holds Llama 3.3 70B in FP8 on one card. You build Kubernetes, the driver lifecycle and the serving layer yourself; our Hetzner GEX63 walkthrough shows what that takes.

When does a per-token API beat self-hosting?

Below a certain sustained utilisation, a per-token API is cheaper and faster than running your own GPUs. Fireworks AI charges $0.90 per million tokens for serverless models above 16B parameters. Together AI lists Llama 3.3 70B at $1.04 per million tokens. OVHcloud AI Endpoints charges €0.67.

The break-even maths against the $0.40 per million output tokens computed above for a fully busy pair of OVHcloud H100s:

• Against Fireworks: $0.40 ÷ $0.90 = 44% sustained utilisation.

Below 44%, you pay for idle GPU time and the API wins. Above it, self-hosting wins, and by more than the arithmetic shows, because the APIs also bill every input token. RAG and agent workloads send long prompts, which pushes them past break-even sooner.

My decision rule: if the binding constraint is GPU-hour cost, go specialist. If it is jurisdiction, go EU-headquartered. If it is "we have no platform team", the GPU vendor is not your real problem.

Is the real blocker the GPU, or the software stack around it?

For most teams self-hosting a large model, GPUs are obtainable somewhere within weeks. What blows the timeline is the platform between a bare GPU node and a production inference endpoint. That work is nearly identical on every provider, which is exactly why it is worth building once.

What you have to build on top of a GPU node:

• The NVIDIA GPU Operator, with pinned driver and CUDA versions.
• GPU node pools with taints and tolerations so CPU workloads don't land on nodes billed by the GPU-hour.
• Model weight distribution and caching.
• A serving engine: vLLM or SGLang (our inference server comparison covers the trade-offs).
• Autoscaling on a metric that is not CPU, such as queue depth or KV cache usage (KEDA queue-depth autoscaling).
• Request queueing and admission control.
• Canary rollouts for new model versions.
• Per-model cost attribution.

Why is GPU autoscaling harder than CPU autoscaling?

A cold start includes loading tens of gigabytes of weights. Run:ai's model streamer benchmark loads a 15 GB Llama 3 8B onto an A10G in 47.99 seconds with standard safetensors from gp3 storage, and in 4.88 seconds with the streamer reading from S3 (Run:ai benchmarks).

Scale those rates linearly to Llama 3.3 70B's 141 GB:

• Standard safetensors: 141 ÷ 15 × 48 s ≈ 7.5 minutes.
• Streamer from S3: ≈ 46 seconds.

Both figures exclude node provisioning and image pulls. Scale-to-zero on a 70B model costs your users minutes, not seconds.

Why does sovereignty die in the platform layer?

Sovereignty usually fails in the platform layer, not the hardware layer. Racking the GPU in Gravelines does nothing if prompts land in a US-hosted logging SaaS, traces go to a US APM vendor, and evaluation datasets sit in a US bucket. For inference, the prompts and outputs are the regulated data, and they flow through your observability stack on every request.

The hidden multiplier

Every additional provider doubles the platform work unless the layer above Kubernetes is identical everywhere. Two clouds means two GPU Operator upgrade cycles, two IAM models and two deploy pipelines, and someone has to be on call for both.

Where Qovery fits, and where it doesn't

This is where an internal developer platform earns its keep. Qovery gives developers self-service deployments on your own AWS, GCP, Azure or Scaleway account, or on a Kubernetes cluster you already run (Qovery clusters).

• On AWS, Qovery can add a dedicated GPU node pool to the EKS cluster it manages (EKS GPU node pool).
• At OVHcloud, Nebius or another European GPU provider, you attach the cluster you run, GPU node pools included, as a self-managed cluster. Qovery deploys on top of it.

The clusters and the cloud bill stay in your name, with any discounts or Savings Plans you negotiated.

The limits, plainly: Qovery does not sell GPUs, does not broker capacity, and will not get you quota.

How do you keep a multi-cloud GPU strategy portable without a dedicated platform team?

The only durable hedge against GPU scarcity is portability. Standardize on Kubernetes, keep deployment configuration provider-agnostic, and treat the GPU pool as a swappable backend behind a stable internal inference API.

• Keep everything above Kubernetes identical. Same container images, same Helm values, same CI/CD on every provider. The GPU node pool is the only provider-specific piece.
• Put inference behind a stable internal API. Swapping OVHcloud for Scaleway, Nebius or AWS should be a routing change, not a rebuild. Our sovereign GPU migration playbook walks through the cutover.
• Give AI teams their own small pools. Per-environment RBAC and preview environments let them test a new model version without touching production GPU capacity.
• Auto-stop non-production. Idle GPU nodes at night and at weekends are usually the largest avoidable line on an AI infrastructure bill. Flexera's 2026 State of the Cloud report puts wasted IaaS/PaaS spend at 29%. One OVHcloud h100-760 staging instance at $5.98/hour costs $4,365 a month if it runs 24/7. Stop it 14 hours a day and you save 14 × 30 × $5.98 = $2,512 a month, on a single two-GPU instance.
• Treat cluster upgrades as GPU events. The current GPU Operator supports Kubernetes 1.33 to 1.37 with specific driver branches (NVIDIA platform support). A Kubernetes upgrade that outruns that matrix takes the whole inference fleet down. Managed upgrades with a tested path matter more with GPUs than without.

What this buys a small team is the ability to ship on Kubernetes in its own cloud accounts without first hiring a dedicated DevOps or MLOps engineer. For more on running across several GPU providers, see where to find GPU capacity in 2026.

How do I deploy and operate this with Qovery from Claude Code or Cursor?

You can drive the whole deployment workflow from your coding agent. Install the Qovery Agent Skills once, then ask in plain language and approve the plan the agent proposes.

Install the skills globally for every compatible agent (Claude Code, Cursor, OpenCode, Gemini CLI, Copilot, Kiro and Goose):

curl -fsSL https://skill.qovery.com/install.sh | bash

Or scope them to the current project:

curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

Add the Qovery MCP Server to Claude Code. It uses OAuth and is read-only by default:

claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

Enable write access only when you explicitly want the agent to change things. You also have to turn on write access in the Qovery Console:

claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

What each piece does:

• The skills handle deployment. They include qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview and qovery-terraform.
• The MCP Server operates what already exists.

Then ask: "Deploy this inference service to my existing Kubernetes cluster with Qovery." The agent shows the plan and asks you to approve before anything is created. The full setup is in the AI agent quickstart and on the Claude Code integration page.

The bigger picture

European capacity is growing, but from a small base. EU-headquartered providers hold about 15% of the European cloud market, against 70% for Amazon, Microsoft and Google, according to Synergy Research Group. The European Commission's InvestAI plan aims to mobilise €200 billion for AI. That includes a €20 billion fund for AI gigafactories with around 100,000 latest-generation AI chips each. Most of that capacity is years away, so the provider you choose this quarter matters more than any roadmap.