On October 13, 2026, David Abitbol, who leads AI operations at Revolut, gave a 15-minute talk at AI Engineer NYC titled "Shipping like a startup, regulated like a bank". The Register reported it on November 3. The conference's own page carries a reviewed transcript, which is the source for the quotations below. All figures are Revolut's own and describe its deployment.
What Revolut reported
Abitbol described a sample of about 2,000 engineers measured on coding time and lead time, from picking up a feature to having it merged. Early Claude Code use came with strict budget limits because some engineers used large token budgets without a clear return, and scarce tokens meant people saved them for hard tasks. Revolut then self-hosted GLM models. In the transcript, around "April 26th, GLM 5.1" the chart shows "60% improvement in coding time" and "70% improvement in lead time". The conference summary notes that the comparison "does not isolate the model change from other causes".
The serving numbers are specific. "To serve 2,000 engineers, we roughly need 56 B200. And that's to host GLM 5.3." The 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." The targets are a time to first token under three seconds, with complaints starting above five, and about 200 tokens per second for interactive use. GLM is text-only, so image tasks are routed to other models.
Tuning before buying
The most transferable part is the tuning. With the GPU count held constant, the slide reports 76 percent more requests per second and time to first token falling from 14.26 seconds during migration to 1.68 seconds. Abitbol's settings: "long context is a scam ... even though you can serve one million token, 256 is really what you need"; on Blackwell, "you don't want to run anything higher than FP4", which he puts at about a 40 percent saving in GPU footprint compared with FP8; and "even though GLM fits on TP4, you don't have enough KV cache, and so maybe a TP8 works better". He also points to cache hit rate, speculative decoding and separating prefill from decode.
A rough check, which is our own arithmetic: The Register gives GLM 5.1 about 754 billion parameters with 40 billion active. At FP8 that is about 754 GB of weights. NVFP4 stores 4-bit values with an 8-bit scale per 16 values, about 4.5 bits each, or roughly 424 GB, which is 44 percent smaller and consistent with Abitbol's "40% saving". An eight-GPU DGX B200 has 1,440 GB of GPU memory, so at NVFP4 about 1,000 GB per eight-GPU group is left for KV cache and activations, against about 690 GB at FP8. If all 56 GPUs run as TP8 groups, that is seven replicas. We assume GLM 5.3 is similar in size to GLM 5.1, which the talk does not confirm.
What remains uncertain. The 30-cent figure is a blended internal number, and the talk does not break out hardware, staffing or observability costs. The productivity gains come from Revolut's own charts. Whether NVFP4 really has "zero loss in precision" for other workloads is not shown.
Analysis: The 14.26-to-1.68-second improvement on the same hardware is the result most teams can use. At Belgavi's Book Store, Jenya runs a small self-hosted model for drafting CASE replies. Before asking for another GPU, Jenya could measure the context lengths staff actually send, set the served maximum near the 99th percentile instead of the advertised maximum, and compare KV-cache headroom at two tensor-parallel sizes. Those changes cost nothing but a configuration change and a load test.
Sources and evidence
At AI Engineer NYC on October 13, Revolut's AI operations lead said 56 B200 GPUs serve GLM 5.3 to about 2,000 engineers at a blended 30 cents per million tokens, a tenth of its earlier Anthropic and OpenAI spend. Tuning on the same GPUs took time to first token from 14.26 to 1.68 seconds as requests per second rose 76 percent. The settings were a 256K context cap, FP4 weights and TP8 for KV-cache room. All figures are Revolut's own.