Self-hosted LLM cost: what Revolut's bill does and does not prove

On 13 October 2026, David Abitbol of Revolut told the AI Engineer conference in New York that self-hosting Z.ai’s open-weight GLM models for about 2,000 engineers had brought the company’s blended cost to 30 cents per million tokens, and its invoice to one tenth of what it had spent on Anthropic and OpenAI. The figure is Revolut’s own and it is narrow: a coding workload at large scale, frontier tools kept for exceptions, and staff costs unstated. What it does show is that self-hosted LLM cost is set by how a model is operated, not by the weights alone.

This post covers what Revolut said, what the figure does not prove, what decides the cost, when an API is cheaper, licence checks and a dated plan.

What did Revolut say about its self-hosted AI bill?

Abitbol leads AI operations at Revolut, by his own introduction. The conference organiser publishes the recording and a transcript. Every figure is Revolut’s own account, not independently checked.

Topic	What the talk says
Cost	“blended cost of token is 30 cents per million. And so our invoice is one-tenth of what we were spending on Anthropic and OpenAI.”
Model and scale	“to serve 2,000 engineers, we roughly need 56 B200. And that’s to host GLM 5.3.”
Frontier services	“the frontier is the exception”: Codex and Claude Code are still used, as exceptions
Where it runs	“self-hosting open source model on dedicated GPU”; where the GPUs are is not stated
Before	Engineers seen spending “a thousand a month, 10,000 a month”, so Claude Code was launched “with strict budget limits”

The sentence with the 30 cents names no model version. The Register, on 3 November 2026, attributes it to GLM 5.1, the model Revolut started with; the 56-GPU figure is for GLM 5.3. Its headline says Revolut cut out Claude, though the article notes that “GLM hasn’t replaced GPT or Claude entirely”. The talk says Claude Code and Codex stay, for the exceptions.

In advice to CIOs in the audience on Chinese open-weight models, Abitbol said “you’re just getting the weights and putting them on a US-based service”, and that GPU and inference providers have zero data retention by default. Self-hosted, here, means Revolut chose, tuned and ran the model on dedicated GPUs, location unstated.

What the 30 cents does not prove

The organiser’s write-up of the talk is direct: the figures “describe Revolut’s deployment and utilization, not a portable price for any self-hosted model.” Four reasons stand behind that.

• Scale. A GPU costs the same per hour whether it is busy or idle. Revolut sized 56 GPUs for about 2,000 engineers; the talk gives no utilisation figure. A team of 50 on the same hardware would leave it mostly idle.
• Workload. Coding tasks resend similar context again and again, and Abitbol aims for a cache hit rate above 90% on them. Reused context is cheap to serve. A staff assistant over documents has a different shape.
• The blend. The talk does not say what “blended” includes: the mix of input and output tokens, whether the GPUs are rented or bought and over what period, or the cost of the engineers who tuned the stack.
• The baseline. The comparison is with a frontier invoice under budget limits, not with the same open model bought through an API. Engineers now use the model more freely, so the two invoices may not cover the same volume. The talk gives no token counts and does not say whether continuing frontier use is inside the one-tenth.

None of this makes the figure wrong. It makes it Revolut’s.

What decides self-hosted LLM cost?

The useful part is how Revolut got there: “If you just get GPUs and upload weights on a GPU and you start doing some inference, you’re going to get terrible performance,” Abitbol said. Between April and August 2026 Revolut kept the same number of GPUs; the organiser’s reading of the slide gives 76% more requests per second and an 88% cut in time to first token, from 14.26 to 1.68 seconds. His advice was to “resist scaling” until the existing configuration is tuned.

The levers he named are ordinary operations work:

• Context sized to the work. About 256,000 tokens for coding, even where a million can be served, because context competes with concurrent requests for GPU memory.
• Quantisation, parallelism and cache. FP4 on Blackwell-generation GPUs, eight-way tensor parallelism when four leave too little cache, and the cache hit rate checked before further serving techniques.
• Routing. GLM for code, another model for images through a local router, and frontier services for the cases that need them.
• Targets and telemetry. Time to first token under three seconds, about 200 tokens per second, and “a very strong open telemetry” so an incident can be traced.

None of this is specific to GLM. Each setting has to be chosen, measured and revisited when the model or the traffic changes, and that work, more than the weights, decides the cost per token.

Self-hosted LLM vs API cost: when is the API cheaper?

In four cases.

At low or uneven volume. A rented GPU bills every hour. In a worked example published on 20 September 2026, Charafeddine Mouzouni of Cohorte priced two rented H100 GPUs at about $6,117 a month and found $0.30 per million output tokens with the cards saturated around the clock, $4.26 at 30% average load during working hours and $12.77 at 10%, “which is ordinary for an internal tool in its first quarter”. Against a frontier API at $10 per million output tokens, the same example has the two cards paying for themselves at 612 million output tokens a month, “which is very reachable”.

Against the same open weights from a serving provider. A provider runs the identical model on hardware it keeps busy, and in the article’s words sells “the marginal token near marginal cost”. Asked whether self-hosting is cheaper than such an open-weight API, the article answers: “Usually the opposite.”

When people are counted. Someone tunes the serving, applies updates and answers the alert at night. Revolut’s figure does not price that work; a fair comparison does.

When the task needs a frontier model. Revolut keeps frontier tools for that reason.

Self-hosting can win on steady, high volume, as at Revolut. Other reasons, such as data location, an air gap or a model that does not change, are real, and the same article argues that each “should be budgeted under its own name instead of disguised as a saving”.

What to check in an open-weight licence

Open weights do not come under one licence. As of 4 November 2026, licence files on Hugging Face differ by version and by size within a family. The revenue conditions apply only to a licensee running a Model as a Service business (or, for Qwen3.8-Max, an AI Work Assistant business). Most organisations using a model internally run neither, but these are the clauses to read.

What to check	Example, as of 4 November 2026
The licence of the exact size	Qwen3.8-27B is Apache 2.0; Qwen3.8-2.4T-A95B carries its own “Qwen3.8-Max License”.
What changed between versions	GLM-5.1 is MIT; GLM-5.3 has its own “GLM-5.3 License”.
Revenue thresholds	For a licensee running a Model as a Service business: above $10 billion of revenue over 12 months, GLM-5.3 requires Z.ai’s security review; above $20 million, Kimi K3.1-Pro requires a separate agreement; above $50 million, Qwen3.8-Max requires a separate licence. Each counts the whole group’s revenue.
Which activities count	“Model as a Service” means giving a third party inference or fine-tuning with “meaningful control over the inputs, parameters, or training data”. Qwen3.8-Max adds products “primarily designed for AI-assisted coding or office productivity”.
How internal use is defined	Kimi K3.1-Pro and Qwen3.8-Max exempt internal use that does not make the software, “its outputs”, or its capabilities available to third parties. If model output reaches your customers, ask counsel how that reads for you. GLM-5.3 has no such exemption: once its condition is met, the review comes before any commercial use.

Write the model, version and licence into the contract with whoever runs it, and reread the licence at every upgrade.

Does the Chinese origin of a model matter?

GLM, Qwen and Kimi are published by Chinese companies. Abitbol’s answer was about the data path: weights run on infrastructure you choose are not an endpoint in China. The organiser adds that his comments on hosting locations “describe his view of Revolut’s circumstances” and “should not be read as a general determination” for other organisations.

On 16 October 2026, China’s Ministry of Commerce and Ministry of Science and Technology proposed adding 23 AI technologies to the catalogue of technologies whose export China prohibits or restricts; comments close on 15 November 2026. In the draft, the core technology of large models, weights included, would be restricted for export if it reaches any of three marks: 10²⁶ floating-point operations of compute, two trillion parameters, or a global top-10 place in a public evaluation. The draft excludes technology already in the public domain through open source or published papers, and the ministry’s questions and answers say the core question is whether restricted technology is transferred from within China to outside it. The catalogue change is a proposal. Already in force, from 16 October 2026 until the revised catalogue applies, is a duty to register exports of the listed technologies before they happen. On its own terms the draft does not reach weights already published, and open-sourcing such technology later would fall under an automatic licence (our summary and translation).

What to do, and by when

All dates are our suggestion.

1. By 30 November 2026: measure what you use now. Export two weeks of token counts from your AI providers or API gateway, by hour and by use (coding, chat, documents), so utilisation is measured, not guessed.
2. By 15 December 2026: price three options, not two. A frontier API, the same open weights through a serving provider, and your own or dedicated GPUs at your measured load, with the people needed to run them.
3. Before committing to GPUs: pilot one steady workload, such as coding assistance or internal search, for four to six weeks on an open-weight model, with hard cases routed to a frontier service where your policy allows.
4. During the pilot: tune before you scale. Set latency targets, size the context to real requests, watch the cache hit rate, and trace prompts and answers with Langfuse so a change of model is judged on your own traffic.
5. Before production: read the licence of the exact model and size, and put the model, version and licence in writing.
6. Before production: write down where the GPUs are and who operates them. For Swiss or EU data, the contract should name a location you chose; our private AI perimeter map lists the flows to check.
7. Every quarter from March 2027: compare again, with measured volume, because prices, models and traffic all move.

Open weights, run properly: control first, cost as the result

Revolut’s talk is a case for open weights, but not the headline one: with open weights, cost becomes something an organisation can engineer. With an API, it is a price list someone else sets.

For a Swiss or EU organisation, three reasons come before the bill:

• Data inside a perimeter you choose. Prompts, documents and logs stay on your servers or in a region the contract names.
• A model that does not change under you. The weights you qualified stay the weights you serve until you approve a change. An API version can be retired on the provider’s schedule.
• A licence you have read. The terms sit in a file you can hand to counsel, version by version.

Open weights do not give you busy GPUs, a tuned serving stack, someone on call or a record of what changed. At small volumes an API is cheaper, and some tasks still need a frontier model. Running open weights properly does not make a small workload cheap. It puts steady workloads on tuned serving, measures cost on real traffic and sends hard cases out on purpose. Cost is then a result you measure, not a promise.

How Pilae fits

Revolut’s own engineers did that work. Pilae operates the same layers for organisations that would rather not build that team: the open-source apps for the model server, the chat interface and tracing, run on your premises or on dedicated machines in Pilae Cloud.

• Models in your perimeter. Private AI runs open-weight models on your own GPU servers, or on dedicated GPUs in Zurich or another Pilae Cloud region you choose, served by vLLM when many people use them at once or Ollama for a pilot or a small team.
• The model list in the contract, each licence checked. The models you run are listed per environment, and changing or adding one is a planned, approved change. Licences differ by family and by size, so we check each one against your use before it goes into the contract.
• Selected users routed to an external API, on purpose. Where your policy allows it, the same interface, Open WebUI or LibreChat, can also route selected users to an external API under your own contract (private AI).
• Updates you approve. The Pilae Agent plans each model and app update, waits for your approval and applies it in your window, with a backup first.

Our plans and prices are on the pricing page; GPU machines are quoted after a scoping call. To find out whether a self-hosted model fits your volume, talk to an engineer: we go through what you use today, the workloads worth moving and where the models would run.

This post is general information, not legal advice. For licence terms, read the licence file published with each model.