The rise of the Europe GPU cloud startup: sovereignty and scale

What a Europe GPU cloud startup is and why the segment is growing

A Europe GPU cloud startup sells GPUs to engineers who train, fine-tune and serve models. GPUs are its core product, not one item in a broad catalogue. The segment is young, and it is growing with European demand for sovereign infrastructure.

Ask two questions first: who holds your contract, and where do the GPUs run? Their answers remove providers from your list. Billing granularity and portability then decide which plan you buy.

Your GPU jobs may run today in the Frankfurt region of a hyperscaler, one of the large general-purpose US clouds. Should you move them to a European GPU provider, and what do you check before you sign? The question usually arrives when a customer or your legal team asks where data is processed, and by which company.

Demand behind the question is growing. Gartner forecasts that European spending on sovereign cloud infrastructure services will more than triple from 2025 to 2027. The Register reported the forecast on 9 February 2026. By Gartner's projections, Europe reaches over $23.1 billion in 2027 and is likely to overtake North America that year, according to TechRadar.

We are a Europe GPU cloud startup ourselves. Lyceum is a sovereign European AI inference provider for open-source models. Our GPUs run in European data centres, as our press and company facts state. Magnus Grünewald and Maximilian Niroomand founded us in 2025, with offices in Berlin and Zurich. In June 2025, redalpine led our €10.3 million pre-seed round, with participation from 10x Founders.

A European region is not a European contract party

A hyperscaler's European region and a European GPU cloud can sit in the same country and still differ in who you contract with. Data residency means your data sits in a given country or region. Data sovereignty also asks which company controls the data, and which law governs that company.

The table is a checklist, not a legal assessment. Our US vs EU sovereignty comparison covers the legal side.

For a security review, ask each provider for the same four documents and facts. Here is how we answer them on our legal and security page:

• Data handling: prompts and outputs are processed, not stored, and never used for training.
• DPA: the data processing agreement is Annex 1 of our terms. You are the controller, who decides how the data is used, and we are the processor, who handles it for you.
• Certification: our ISO 27001 audit is in progress, and we hold no certificate yet. ISO 27001 is the international standard for information-security management.
• Subprocessors: the list of companies that process data for us is available on request.

Incidents appear on our public status page.

How per-second billing changes the cost of short GPU jobs

Billing granularity is the smallest unit of GPU time a provider charges, and every started unit is paid in full. It matters most for short jobs, such as tests, evaluations and runs that crash early.

Take a hypothetical team whose CI pipeline (the automated tests that run on every code change) starts 40 GPU jobs a day. Each job uses the GPU for 90 seconds. The billed time per day under three rules is:

per second:          40 jobs x 90 s            = 3,600 s = 60 GPU-minutes
per started minute:  40 jobs x 2 min           = 80 GPU-minutes
per started hour:    40 jobs x 1 h             = 40 GPU-hours

In this example, per-minute billing charges 33% more than the GPU time used, and per-hour billing charges 40 times as much. We bill GPU virtual machines per second, with no subscription, so the team pays for the 60 minutes.

The example favours per-second billing, because every job is short. Rounding barely matters for long jobs: an eight-hour run billed per started minute pays for less than one extra minute. Count how many of your runs last under ten minutes before you weigh billing rules. Our per-second billing comparison works through more cases.

Spot machines lower the price rather than the billing unit. On our compute page, a spot machine costs about 50% less than the same GPU on demand, and it can be reclaimed at any time. They suit jobs that save checkpoints (regular snapshots of training state). A reclaimed spot machine then costs you only the steps since the last checkpoint.

How to size a GPU before you rent it

Low GPU use has several causes. A two-month trace of a large GPU cluster shared by many teams found three. Jobs waited for a full set of free GPUs, were limited in which machines they could use, or failed during training. When you rent a GPU, the cause you control most directly is its size. Engineers often rent a bigger GPU to avoid an out-of-memory crash, and the extra memory sits idle.

Our Pythia tool takes that guess out of PyTorch training jobs. You point it at your training script:

lyceum gpu-selection run train.py

Pythia predicts the memory the job needs, estimates its runtime on each GPU option and recommends one. Its documentation lists the limits. It evaluates T4, A100 and H100 GPUs, for one model on one GPU, with PyTorch or PyTorch Lightning.

For serving a model, the sizing tool on our compute page does the same job. You enter a Hugging Face model, the prompt length, the number of requests at once and the precision. Precision is how many bits each model weight uses: 16, 8 or 4. It shows the memory needed and which GPU fits.

The table shows our compute page as read on 21 October 2026. Current rates are on our pricing page, and more fixes are in our guide to low GPU utilisation.

How to run jobs on a European GPU cloud without lock-in

Lock-in means moving away costs more than staying. Keep your training code in a plain Docker container, and a move changes only the command that launches it.

Serverless training on our platform runs your container on the GPU you choose, with no machine for you to manage. You push the image, choose the GPU and submit the job:

lyceum docker run your-team/train -m gpu.h100 -c "python train.py"

The output streams until the run ends. A GPU virtual machine comes with 1, 2, 4 or 8 GPUs and root access, for teams that want their own stack. Reserved GPUs and clusters are capacity held for you for an agreed term, priced per contract. They suit long training runs and jobs that span several machines.

Data is the other half of lock-in. Every account gets an S3-compatible storage bucket that persists across VMs and runs, so a dataset uploaded once is there for the next job. Before you sign with any provider, ask in writing what it charges to move data out (egress), per service. Our egress fees comparison shows what to look for.

How to choose a European GPU cloud in four questions

Choosing a European GPU cloud comes down to four checks, made in this order.

1. Contract party and GPU location. If your users are in the EU, shortlist providers based in Europe with GPUs in European data centres. Ask for the DPA and the subprocessor list.
2. Job length. Count the runs under ten minutes, as in the CI example. Many short runs favour per-second billing. Long steady runs favour a reservation, because the reserved capacity stays yours for the whole term.
3. Exit route. Keep code in containers and data where you can copy it out.
4. GPU size. Predict memory and runtime first, then rent the smallest GPU that fits.

Your provider choice can also cover the models you call. Open-weight models are models whose weights anyone can download and run. Epoch AI reported on 29 May 2026 that the most capable ones trail the best closed models by four months on average. We serve open models such as Kimi, GLM, DeepSeek and Qwen through one OpenAI-compatible API, billed per token.

Choose us when your contract and your GPUs must both stay in Europe, and your prompts must never be stored or used for training. You pay per second with no subscription, Pythia sizes the GPU before you rent it, and your jobs stay in plain Docker containers.

If your answers point to a European provider, start with your own workload. Run Pythia on your training script, then launch a GPU virtual machine of the size it recommends.