Revolut divise par dix ses coûts de code IA en auto-hébergeant GLM
Début novembre 2026, Revolut a révélé avoir divisé par dix, en moins d’un an, ses coûts d’inférence d’IA de codage en faisant des modèles auto-hébergés GLM son défaut pour environ 2 000 ingénieurs, servis sur 56 GPU NVIDIA B200. C’est la première preuve chiffrée qu’auto-héberger un modèle open-weight devient rentable — mais seulement à une certaine échelle.
3 novembre 2026. The Register révèle que Revolut, la fintech britannique, a divisé par dix ses coûts d’inférence d’IA de codage en moins d’un an, en faisant des modèles auto-hébergés son défaut plutôt que de dépendre de services commerciaux comme Claude. Octobre 2026. David Abitbol, responsable des opérations et de l’infrastructure, en détaille les chiffres à la conférence AI Engineer de New York. 2025–2026. L’entreprise avait d’abord testé Gemini début 2025, puis Claude Code début 2026. Pourquoi c’est important : c’est le premier retour chiffré, à grande échelle, montrant qu’auto-héberger un modèle open-weight pour le codage devient économiquement défendable — mais seulement sous certaines conditions.
Le basculement : le défaut a changé, pas le menu
Ce que Revolut a fait n’est pas d’ajouter un modèle moins cher à côté des autres. L’entreprise a retourné le défaut. Les modèles auto-hébergés traitent désormais le travail d’IA de codage en premier, et les services commerciaux — Anthropic Claude, OpenAI Codex — passent derrière. Ce n’est pas un pilote ni une expérimentation : un défaut décide où part l’essentiel du volume de tokens.
Le déploiement sert environ 2 000 ingénieurs sur 56 GPU NVIDIA B200, soit l’équivalent de sept systèmes DGX B200 à huit GPU. Le modèle retenu est GLM-5.1 de Z.ai, une famille de modèles open-weight développée en Chine, que Revolut a ensuite fait évoluer vers GLM-5.3. Traiter la pile comme quelque chose qu’on met à jour à son propre rythme, sans attendre la feuille de route d’un fournisseur, fait partie du gain.
| Métrique | Chiffre rapporté |
|---|---|
| Réduction du coût d’inférence | ~90 % (≈ 10×) |
| Coût mixte par million de tokens | ~0,30 $ (GLM-5.1 auto-hébergé) |
| Ingénieurs servis | ~2 000 |
| Matériel | 56 GPU NVIDIA B200 |
| Gain de temps de codage | −60 % |
| Gain de lead time | −70 % |
Le point de comparaison importe. Avant le basculement, certains ingénieurs consommaient 1 000 $ à 10 000 $ par mois en API commerciales « pour un ROI pas terrible », selon Abitbol. Le déploiement initial s’était donc fait avec des plafonds de budget stricts — et donc des quotas de tokens. À 0,30 $ par million de tokens en auto-hébergé, le coût tombe à environ un dixième de celui d’OpenAI Codex ou d’Anthropic Claude Code.
L’économie comportementale des tokens bon marché
Le résultat le moins attendu n’est pas le prix, mais ce que le prix change dans les usages. « Quand les tokens sont gratuits, on est libre de faire ça », résume Abitbol : les ingénieurs se sont mis à confier aux modèles le débogage, la résolution de tickets Jira et Confluence — les tâches qu’on ne confiait jamais au modèle quand il fallait économiser ses tokens pour la fin du trimestre ou la tâche la plus difficile.
C’est là que l’auto-hébergement change de nature. Un service au compteur incite à rationner ; une capacité fixe, payée d’avance, incite à utiliser. Les gains de productivité annoncés — 60 % de temps de codage en moins, 70 % de lead time en moins sur un échantillon d’environ 2 000 ingénieurs — doivent se lire avec prudence : la baseline n’est pas précisée, et on ne sait pas si les mêmes ingénieurs auraient obtenu les mêmes gains sur Claude Code ou Codex. Mais ils suggèrent qu’un modèle moins cher n’a pas nui au débit, ce qui est déjà un signal.
La mécanique du « dix fois moins cher »
Le modèle n’est pas petit. GLM 5.1 pèse environ 754 milliards de paramètres au total (40 milliards activés par token généré), ce qui exige ~380 Go de mémoire GPU rien que pour les poids, plus 6 à 26 Go par utilisateur pour le contexte. Servir ça à 2 000 ingénieurs tient en partie au matériel, mais surtout à l’ingénierie.
Abitbol est clair : les plus gros gains ne viennent pas de l’ajout de GPU, mais du réglage des hyperparamètres, du passage à la quantification NVFP4, de la mise en place du prefill/décodage désagrégés et du réglage des longueurs de contexte. Son verdict sur les contextes géants est sans appel : « le contexte long est une arnaque. » Même si on peut servir un million de tokens, « 256 000, c’est ce dont vous avez réellement besoin. »
Résultat : un temps au premier token sous 3 secondes sur des contextes d’environ 256 000 tokens, et une génération autour de 200 tokens par seconde — le « point idéal » pour ses ingénieurs. La cible explicite : « ce qu’on vise, c’est moins de 3 secondes au premier token. Dès qu’on dépasse 5 secondes, ma boîte Slack explose. » Les ingénieurs qui se connectent après 17 h approchent, eux, 800 tokens par seconde : le cluster, payé d’avance, ne se met jamais en veille.
La limite assumée : GLM ne fait pas tout
GLM n’a pas remplacé GPT ni Claude partout. Le modèle est textuel : il ne gère pas la vision, donc pas le travail d’interface. Revolut a donc mis en place un routeur de modèles qui dirige les requêtes vision vers Gemini ou GPT Luna, tout en gardant la génération de code sur GLM. « L’open source est désormais une priorité chez Revolut, nos coûts sont favorables, la facture est plate, il n’y a plus de choc de facturation en fin de mois, et la frontière est l’exception », résume Abitbol.
Sur la question sensible des modèles chinois open-weight, il trace la ligne : le vrai risque, c’est d’accéder à ces modèles via des API hébergées en Chine. Exécutés sur site ou sur des ressources cloud régionales, « il n’y a rien à craindre ». Le corollaire tombe sous le sens : auto-héberger, c’est aussi garder ses prompts et son code dans son propre réseau.
Verdict
Le retour de Revolut est un point de données, pas une loi universelle. Il prouve qu’à l’échelle de 2 000 ingénieurs et avec une équipe d’infrastructure capable de tenir 56 GPU B200 occupés, auto-héberger un modèle open-weight comme GLM peut diviser la facture par dix — sans casser le débit. Mais le « dix fois moins cher » est une comparaison de prix de tokens, pas un coût total de possession : les dépenses de cloud, de personnel, de matériel et d’exploitation peuvent en être exclues.
Si vous dépassez un millier d’utilisateurs intensifs et que vous avez l’équipe pour maintenir un cluster GPU en charge, la voie auto-hébergée se défend : visez un modèle open-weight, activez la quantification NVFP4, mettez en place le prefill/décodage désagrégés, bornez le contexte à ~256 000 tokens, et gardez un routeur de modèles pour la vision. Si vous êtes une équipe de 50 personnes, le calcul ne tient pas : un cluster GPU qui dort la nuit coûte le même prix qu’un cluster à pleine charge, et l’avantage de coût se dissout. Entre les deux, la bonne posture est un hybride — auto-héberger ce qui est textuel et stable, garder un modèle commercial en secours. La règle de fond : l’auto-hébergement d’inférence est un pari sur le taux d’utilisation, pas sur le prix du GPU.
Références
- The Register — British fintech Revolut slashes AI coding costs 10x by cutting out Claude and going self-hosted (3 novembre 2026)
- TechRadar — Revolut cut Claude for self-hosted Z.ai models and slashed inference costs by 90 %
- Cybernews — Revolut Chinese AI model cuts coding costs by 90 %
- selfh.st — Self-Host Weekly (6 novembre 2026)