Revolut Switches to Self-Hosted GLM to Support 2,000 Engineers, Cutting AI Coding Costs by About 90%

Some people spend $10,000 a month on AI programming, and then the boss looks at the bill: is this money well spent? — This is exactly the awkward situation the British fintech company Revolut once faced.

To get engineers using AI, the company tried Gemini and Claude Code in succession, but some engineers could burn through $1,000 or even $10,000 a month. Yet the money was spent without the expected efficiency gains. So Revolut made a bold decision: it would no longer stake its main AI programming efforts on commercial models, and instead deploy Zhipu's open-source GLM model itself.

The results were striking: in less than a year, AI programming inference costs fell by about 90%, the coding time of the company's roughly 2,000 engineers was cut by 60%, and the delivery cycle from taking on a requirement to merging code was also shortened by about 70%!

Claude is too expensive! Some engineers burn through $10,000 a month

At first, Revolut actually had no intention of training or deploying large models itself.

In early 2025, the company began using Gemini to help engineers look up information and read technical documentation; by early 2026, it introduced Claude Code, hoping to further improve development efficiency. But as usage scaled up, cost quickly became a problem.

David Abitbol, Revolut's head of operations and infrastructure, revealed that some engineers spent as much as $10,000 a month on AI services, but the actual return on investment was not obvious. The company had to set strict token budgets when promoting AI programming tools.

This created a new problem: the more expensive the tokens, the more reluctant engineers were to use them. They would reserve their limited quota for complex code generation tasks; as for debugging bugs, handling Jira tickets, organizing Confluence documents and other work, even if AI could help, they had to consider whether it was worth consuming tokens.

So Revolut began looking for cheaper alternatives, and ultimately set its sights on Zhipu's GLM series models. The company initially adopted GLM-5.1, then upgraded to GLM-5.3, and made the self-hosted model its primary AI programming service.

The cost gap is very clear: according to figures provided by Abitbol, the combined input and output token cost of self-hosted GLM-5.1 is about $0.30 per million tokens, only about one-tenth the cost of commercial services such as OpenAI Codex or Anthropic Claude Code; overall inference spending also fell to about one-tenth of the previous commercial service bill.

With cheaper tokens, engineers' usage habits also changed. Abitbol said that when tokens are no longer so expensive, engineers no longer have to pinch pennies, do not need to save quota for the end of the quarter, and do not have to call on AI only for the hardest tasks — previously engineers thought about how to save tokens, now they think about what other work can be handed to AI.

What really slows down development may not be writing code at all

Revolut also shared a particularly noteworthy detail. They measured two indicators for the company's roughly 2,000 engineers before and after using AI:

Coding time: the time engineers actually spend writing code, measured in hours.

Delivery cycle: the time required from taking on a feature requirement to merging the code and preparing for deployment, measured in days.

Internal data presented by Abitbol shows that after adopting GLM, coding time was shortened by about 60%, and the delivery cycle was also shortened by about 70%. However, he did not simply attribute these gains to the model writing code faster: in his view, what really consumes engineers' time every day goes far beyond coding.

For example, troubleshooting bugs, replying to messages, handling Jira tickets, updating Confluence documents, and following up on various development processes. These tasks do not look complicated, but they chip away at the time engineers actually spend writing code. When the cost of using AI is low enough, engineers can hand these scattered tasks to agents as well, rather than thinking of using AI only when writing code.

This is also why Revolut's delivery cycle was shortened by more than its coding time: writing code faster solves only part of the problems in the development process; letting AI take over the trivial work outside of code is what creates the opportunity to further shorten the entire delivery cycle.

56 Nvidia B200s support 2,000 engineers using AI

Getting nearly 2,000 engineers to use a self-hosted large model at the same time is clearly no easy task.

According to the introduction, the GLM-5.1 chosen by Revolut has about 754 billion total parameters, and about 40 billion parameters are actually activated for each token generated. Even with a mixture-of-experts (MoE) architecture, the model weights and context cache still require a large amount of GPU memory.

According to Abitbol's estimates, storing just the model weights alone requires about 380GB of GPU memory, and each user also needs an additional roughly 6GB to 26GB of GPU memory to maintain context, depending on the precision settings. To support scaled inference for GLM-5.3, Revolut ultimately deployed 56 Nvidia B200 GPUs.

However, Abitbol does not believe that performance gains can only come from buying more GPUs.

At the AI Engineer conference held in New York last month, Abitbol presented a set of very interesting data: with the number of GPUs held constant, after inference system optimization, the number of requests processed per second increased by 76%, and the first-token latency dropped from 14.26 seconds during the migration period to 1.68 seconds after stable operation, a decrease of about 88%.

Abitbol shared that during this period the team mainly did the following things:

Adjusting model hyperparameters: optimizing the model's runtime configuration based on real business workloads.

Adopting NVFP4 quantization: using the low-precision computing scheme supported by GPUs with the Blackwell architecture to reduce GPU memory usage and computational overhead.

Splitting Prefill and Decode: separating input context processing from subsequent token generation, and optimizing for different computational stages.

Optimizing cache and context configuration: avoiding reserving too much GPU memory for ultra-long contexts that are not used.

Especially the last point—Abitbol's view is quite direct.

Is a million-token context a gimmick? Revolut thinks 256K is enough

Today, large model vendors are all working to expand context windows, and 1 million tokens or even longer contexts have become selling points in marketing. But Abitbol does not agree with the blind pursuit of ultra-long contexts:

Long context is a scam. Even if you can provide a 1 million token context window, 256K tokens is actually already enough.

Why? Because the longer the context, the larger the KV Cache (key-value cache) the model needs to maintain, and the more GPU memory it occupies. Briefly, KV Cache can be understood as the model's temporary memory area, used to store the Key and Value tensors in the attention mechanism. In this way, when the model continues generating content, it does not need to repeatedly compute information that has already been processed.

But if engineers actually only need a context of tens of thousands of tokens, while the company reserves resources for a million tokens for every request, it will obviously cause waste. Therefore, Revolut pays more attention to how long a context actual tasks need, and whether the cache can be effectively reused.

The team also found that the tensor parallelism configuration is also critical: distributing model weights across 4 GPUs, although it can fit the model, may not leave enough space for the KV Cache; switching to 8-way tensor parallelism can sometimes achieve better overall performance.

After a series of optimizations, Revolut has now brought first-token latency under 3 seconds, while generation speed remains at about 200 tokens per second. Abitbol even joked that if first-token latency exceeded 5 seconds, his Slack inbox would start getting flooded with complaints.

As for generation speed, Abitbol believes that 200 tokens per second is already enough. Engineers are now more accustomed to launching multiple AI tasks at the same time and coming back to check after the tasks are completed, rather than staring at the model outputting word by word—he also shared an interesting point: engineers who log in after 5 p.m. can even see generation speeds approaching 800 tokens per second.

Not letting GLM do everything; visual tasks are still handed to GPT and Gemini

Although GLM-5.3 has become the main AI coding model, Revolut does not intend to completely say goodbye to commercial models such as Claude and GPT—the reason is simple: different models each have their own areas of strength.

For example, when engineers develop UI, they often need AI to read page screenshots, recognize interface layouts, and then modify code based on the visual effect. For these tasks, Gemini and GPT perform more in line with Revolut's expectations. To this end, Revolut introduced a Model Router to automatically assign models according to different tasks:

Tasks such as code generation and text processing are preferentially handed to the self-hosted GLM.

Tasks such as image recognition and visual understanding are handed to commercial models such as Gemini and GPT.

Regarding this approach, Abitbol said: "Open source has now become a priority for Revolut, and from an economic point of view, our approach has great advantages. Now the bill is fixed, and we will not suddenly receive a huge bill at the end of the month. Frontier models have instead become the exception."

However, not every company can copy Revolut's path. The hardware investment of 56 B200s, model deployment, inference optimization, and daily operations and maintenance are not a small expense—and whether the saved API bills can truly cover the GPU and operations costs is the part of this calculation most worth getting clear.

This article comes from the WeChat public account "CSDN", compiled by Zheng Liyuan, and published by 36Kr with authorization.