Revolut Self-Hosts GLM on 56 B200s at $0.30 per Million Tokens

A European bank now runs most of its AI coding on open weights, on its own GPUs, and spends about a tenth of what it used to pay the frontier labs. That was the core of David Abitbol’s talk at AI Engineer NYC 2026 on 13 October, Shipping like a startup, regulated like a bank. David leads AI operations at Revolut, which he introduced as a European digital bank with 80 million customers in 45 markets. In twelve minutes he covered why Revolut moved its engineers to self-hosted GLM models, how it serves them on 56 NVIDIA B200 GPUs, and how it keeps coding agents acceptable to a banking regulator.

The cost figure is the one travelling around: a blended $0.30 per million tokens. The rest of the talk is more useful than the headline, because it explains what it took to get there.

The numbers at a glance

All of these are Revolut’s own measurements, from David’s slides and what he said on stage.

Rationed tokens slow down more than the code

David’s first chart followed a sample of about 2,000 engineers on two lines: coding time, in hours, and lead time, in days, from picking up a feature to having it merged and ready to deploy.

Revolut introduced Gemini in January 2025, the first time people could use the company’s private data with AI, and saw lead time improve by about 10% and coding time by about 20%: less Stack Overflow, less reading documentation. Claude Code came next, and David was candid that it did not move the lines much at first. Some engineers were spending a thousand, even ten thousand a month on tokens without a return to match, so Revolut rolled it out with strict budget limits.

Budgets fix the bill, but they also change behaviour: engineers hoard tokens for the hardest task, or for the end of the quarter, and do the rest by hand. Revolut wanted the opposite, tokens people could spend without guilt at a fraction of the cost, and that pointed to open models. Self-hosting started around April 2026 with GLM-5.1 (“We’re a big fan of GLM for coding”), and in the months after, the chart showed coding time about 60% better and lead time about 70% better.

Two caveats before anyone pastes those numbers into a business case. It is Revolut’s internal chart, and a model switch in a year when everything else changed too is not a controlled experiment. And the more interesting result is not the size of the gain but its shape: lead time improved more than coding time. David’s reading is that the bottleneck in engineering is not mainly the code. It is digging through the inbox, Jira and Confluence, and with tokens that don’t need rationing, people hand those chores to the model as well. It sits well next to what Julia Wallin argued at Arch9 in Amsterdam three weeks later: when AI makes writing code cheap, the time moves to the work around it.

56 B200s for 2,000 engineers

Open models are now Revolut’s default, and the frontier is the exception. Engineers still have Codex, Claude Code and Gemini, kept for the tasks that need them. The default runs on GLM-5.3, served on 56 B200 GPUs for roughly 2,000 engineers. That is about 36 engineers per GPU, or the equivalent of seven eight-GPU servers.

The service levels David sizes for are worth copying, because they come from users rather than benchmarks:

• Time to first token under 3 seconds. Above 5 seconds his Slack fills up with complaints, so that is the ceiling.
• About 200 tokens per second is enough. People no longer watch the thinking tokens scroll by; they run several tasks in parallel and come back when they are done. (After 5 p.m., with the GPUs quieter, an engineer can see around 800.)

That second point matters for capacity planning. When users run agents in parallel and walk away, the time to first token is what they feel, and per-stream speed beyond a reasonable floor buys little. You size for concurrency and first-token latency, not for the fastest single stream.

$0.30 per million tokens, and what that number means

The cost line is the one that made the rounds: a blended $0.30 per million tokens for self-hosted GLM, and an AI invoice about one tenth of what Revolut was paying Anthropic and OpenAI. The billing is flat, with no bill shock at the end of the month.

Read it carefully, though. The $0.30 is Revolut’s blended cost at Revolut’s utilisation, with 2,000 engineers keeping 56 GPUs busy through the working day. For self-hosted inference, cost per token is roughly fixed cost divided by tokens served, so the same cluster at half the load costs about twice as much per token. And “a tenth of the invoice” compares total spend before and after, not list prices per token, over a period in which the whole point was to let usage grow. None of that makes the figure less impressive; it makes it Revolut’s, not yours. To see where your own break-even sits, my GPU cost calculator is built for exactly that question.

Tune the GPUs you have before buying more

For anyone running inference, the most useful slide held the GPU count constant. During the migration in April, time to first token was 14.26 seconds, far above the target. By August, on the same 56 B200s, requests per second were up 76% and time to first token was down 88%, to 1.68 seconds.

David’s explanation is simple: if you get GPUs, load the weights and start serving, you get terrible performance, because the workload depends heavily on the parameters you set. His advice was to “resist scaling”: tune the configuration before you add hardware.

The knobs: context, quantisation, parallelism, cache

There is no secret recipe, David said, but he named the parameters that moved his numbers:

• Context length. “Long context is a scam” was his line: the model can serve a million tokens, but 256K is what the work needs. Every token of context you reserve is KV-cache memory that can’t hold another concurrent request, so size the window for the requests you actually get. The GLM-5.2 architecture shows why a 1M window is possible at all; possible isn’t the same as worth reserving.
• Quantisation. On Blackwell-generation GPUs he wouldn’t run anything above FP4. In his numbers, going from FP8 to FP4 saves about 40% of the GPU footprint with no loss in precision. I’d check that claim against your own evals before relying on it, but Blackwell has hardware support for FP4, and that is where the memory comes back.
• Tensor parallelism. GLM fits on four GPUs, but TP4 can leave too little memory for the KV cache, so TP8 may work better, depending on how large the workload is. Fitting the weights is not the same as serving the traffic.
• Cache hits. For coding tasks the cache hit rate should be above 90%, since agents send the same repository context, system prompt and tool definitions again and again. After that come the more esoteric options: speculative decoding, and prefill/decode disaggregation, which separates compute-heavy prompt processing from memory-bound token generation.

If you are starting from zero, the community vLLM Recipes give tested starting configurations per model and GPU, while llm-d’s KV-cache aware routing and NVIDIA Dynamo cover cache-aware routing and disaggregated serving across a fleet. David didn’t say which serving stack Revolut runs, so take those as my pointers, not his.

Around the model: routing and the harness

GLM is a text-only model, which some see as a limitation. David’s trade-off, every time, is to take the smarter coding model and handle images another way. A local router can send image recognition to a multimodal model such as Gemini and keep GLM for the main task; where vision on open weights is needed, he mentioned a GLM vision model that Revolut’s UI designer uses heavily.

The endpoints expose an OpenAI-compatible API, including the Responses API, so engineers keep the harness they like: he named OpenCode and Codex, including the Codex app. That is the quiet enabler of the whole move. If switching the backend means switching the tool, adoption stalls. I covered the gateway side of that pattern in AI Gateway on Kubernetes.

Regulated like a bank

The last part was, in his words, for the CIOs in the room. There is a stigma around Chinese open-weight models, and David’s answer was to separate the model from the data path. Downloading the weights and running them on GPUs you choose is a different thing from sending inference requests to an endpoint in China. In his view, keeping the data in countries covered by data adequacy arrangements, such as the US, the EU, the UK and Israel, is what counts, and in his experience GPU and inference providers offer zero data retention by default. That last point I would still confirm contract by contract.

As an EU-regulated bank, Revolut falls under one of the strictest compliance regimes. What works for them is that coding tasks are not treated as autonomous agents: there is always a human in the loop, and the sandbox is what guarantees it. Claude Code and Codex already have approval modes, so Revolut sets rules for the operations it doesn’t allow; his example was allowing grep but not gradle. That gives the regulator confidence that this is not an autonomous agent needing a different kind of supervision. The same sandbox protects against misuse by people inside the company, and against prompt injection.

The final requirement is strong OpenTelemetry. If there is ever an incident, you need to be able to go deep into the logs, and the same telemetry gives you analytics on how the models are used.

Two notes from my side. These are David’s views of Revolut’s own circumstances, not a compliance template: whether a coding agent counts as autonomous is a question for your own legal and risk teams. And the line he draws matches what Friso Westra described for ABN AMRO Clearing at Arch9: under the EU AI Act, a coding agent that proposes changes is one thing, and the same agent deploying to production is another. Sandbox rules are where that line becomes enforceable.

What I’d take from it

For platform teams in Europe weighing the same move, the talk works as a checklist:

1. Measure lead time, not only coding time. Revolut’s biggest gain came from the work around the code.
2. Price the behaviour, not just the tokens. Token budgets cap the bill, and they also cap how people use AI. A flat-cost platform changes what engineers are willing to delegate.
3. Set service levels from your users. Under 3 seconds to first token and around 200 tokens per second, sized for agents running in parallel.
4. Tune before you scale. Context length, FP4 on Blackwell, TP8 over TP4 when the KV cache is short, a cache hit rate above 90%. Revolut got 88% lower time to first token with 76% more traffic on the same GPUs.
5. Keep the harness and route around the gaps. OpenAI-compatible endpoints, a router for images, frontier models as the exception.
6. Put the controls in the sandbox and the telemetry. Approval rules that limit what an agent can execute, and traces good enough to investigate an incident.

I’d add one more: self-hosting moves the responsibility, not just the cost. Revolut has a team that can run 56 B200s, tune them for months and own the incident response. That team is part of the $0.30.

The talk is about twelve minutes long, in the AI Engineer NYC 2026 livestream on YouTube, and the reading edition on ai.engineer has the slides and the transcript.

Related Articles

• GLM-5.2 744B: Sparse Attention Meets Efficient MoE
• vLLM Recipes: Deploy Any Model on Any GPU
• llm-d at Red Hat Summit 2026: KV-Cache Aware Routing for vLLM
• Pete Cheslock: From RAG to Roll-Your-Own Models in One Year
• LLM Quality vs Cost vs Safety: 2026 Model Trade-Off Guide
• Arch9 2026: The Bottleneck Moved, and the Roads Under AI