Revolut’s David Abitbol on self-hosting AI coding models at scale

I’m David Abitbol, and I lead AI operations at Revolut. I want to share how we use dedicated GPUs to serve open-weight models for engineering, and what we learned about speed, cost and operating in a regulated bank. These are measurements from our setup, not universal guarantees.

Revolut is a European digital bank. At the time of this talk, I describe it as serving 80 million customers across 45 markets. Our emphasis on shipping products makes engineering culture and delivery speed important to the company.

A chart of engineering work covers a sample of roughly 2,000 engineers. It tracks lead time from picking up a feature until it is merged and ready to deploy, as well as coding time. These trends show what happened during adoption; the talk does not establish a controlled causal comparison.

The timeline starts with Gemini in January 2025, followed by experimentation with Claude Code and a broader Claude/Codex rollout with spending limits in January 2026. I report initial improvements with Gemini, but we were skeptical about the return from expensive frontier-model usage and imposed strict budgets.

We wanted engineers to use tokens freely without worrying about the end-of-month bill. Around April 2026 we began self-hosting GLM models. I report substantial reductions in coding and lead time; the accompanying slide summarizes a 60% lead-time improvement, while my spoken account gives 60% for coding and 70% for lead time.

The larger lesson for me is that coding itself is not the only bottleneck. Engineers also spend time finding information and working through tools such as Jira and Confluence. With fewer concerns about token budgets, they can use AI across more of that workflow instead of reserving it only for the hardest tasks.

Open models became our default because a relatively predictable bill makes usage easier to plan. We still use frontier models where they work best. Our setup serves approximately 2,000 engineers with GLM 5.3 on 56 B200 GPUs, and the slide credits Together for the deployment.

The user-facing metric I watch is time to first token. We aim for less than three seconds; in my experience, once it exceeds five seconds, complaints in Slack rise. Around 200 output tokens per second is sufficient for our interactive use, especially as engineers increasingly run tasks in parallel.

I report a blended cost of about $0.30 per million input and output tokens in our setup, with cache treated separately on the slide. I say the invoice is around one tenth of our earlier spending on Anthropic and OpenAI. The comparison is specific to our workload and billing, not a general price quote.

Simply placing model weights on GPUs can yield poor performance without tuning. In our data, the same 56 GPUs ultimately handled higher request volume with lower time to first token. The chart compares a migration point with a stable setup: 76% more requests per second and an 88% reduction in that latency measure.

There is no secret recipe: context length, quantization, tensor parallelism and cache behavior all matter. I argue that one million tokens of context is often not worth its cache cost for our workload, and discuss FP4 and cache-hit rates. These choices should be tested against the actual workload and quality requirements.

Our text model does not handle images, so we can route vision work to another model while keeping the main coding task on the text model. The endpoints expose compatible APIs and can be used with different coding harnesses or applications. The division lets teams choose the right tool for each input.

For a regulated bank, I describe controls around human oversight, sandbox permissions, data privacy and telemetry. Hosting model weights on infrastructure in an approved location changes where inference occurs, but location alone does not establish compliance or eliminate security risks.

Our approach uses permission boundaries and human approval for actions we do not want an agent to perform freely. I also mention insider misuse and prompt injection as risks, and emphasize logs for investigating incidents and auditing use. My comments about regulation and data retention describe our approach and should not be read as a blanket legal determination.