Guide De Décision Pour Les Responsables Ingénierie
Votre équipe d'ingénierie doit-elle auto-héberger un modèle de code à poids ouverts ?
Les 2 000 ingénieurs de Revolut disent que ça dépend du volume, pas de l'idéologie.
Cela dépend du nombre d'ingénieurs, des compétences GPU et ops en interne, et des besoins de résidence des données, pas de la seule qualité du modèle.
Lire la réponse complète
Revolut a auto-hébergé un modèle à poids ouverts à environ 2 000 ingénieurs et a réduit sa facture d'API frontier d'environ 90 %, mais garde quand même des outils frontier sous la main pour ses problèmes les plus difficiles. Les équipes plus petites trouveront généralement qu'une API frontier coûte moins cher à exploiter.
Publié le
À retenir
- À environ 2 000 ingénieurs, Revolut a auto-hébergé le GLM de Z.ai sur 56 GPU Nvidia B200 et a réduit son coût moyen par token à environ un dixième de sa facture précédente chez Anthropic et OpenAI.
- Le délai de livraison (jours entre la prise en charge d'une fonctionnalité et sa mise en état d'être fusionnée) s'est amélioré plus que le temps de codage, environ 70 % contre 60 %, ce qui montre que le vrai goulot d'étranglement n'a jamais été le codage pur.
- Le gain a suivi la suppression des budgets de tokens, pas seulement le changement de modèle : une fois les tokens non rationnés, les ingénieurs ont aussi orienté l'IA vers les e-mails, les tickets et la documentation.
- L'auto-hébergement a demandé un vrai travail d'infrastructure, pas seulement de télécharger des poids : ajuster la longueur de contexte, la quantification et le parallélisme a réduit le temps jusqu'au premier token de 88 % avec le même nombre de GPU.
- Revolut garde quand même Claude Code d'Anthropic, Codex d'OpenAI et Gemini de Google sous la main comme exception frontier pour ses problèmes les plus difficiles, pas comme choix par défaut au quotidien.
Le guide complet
Touchez une section pour l'ouvrir.
À propos de ce guide
Ceci est un guide d'achat pour les responsables ingénierie qui se demandent s'ils doivent auto-héberger un modèle de code à poids ouverts, comme le GLM de Z.ai, plutôt que de payer par siège ou par token pour une API frontier. Il s'appuie sur les chiffres publics de Revolut : une banque qui a fait basculer la plupart de ses environ 2 000 ingénieurs hors de la facturation au token, tout en gardant Claude Code d'Anthropic, Codex d'OpenAI et Gemini de Google pour ses problèmes les plus difficiles. La leçon n'est pas quel modèle Revolut a choisi, mais ce qui a changé une fois que les tokens n'étaient plus rationnés.
Auto-Hébergement vs API Frontier Ou Plan Par Siège : Une Liste De Vérification Pour Décider
| Facteur | Penche vers l'auto-hébergement à poids ouverts | Penche vers une API frontier ou un plan par siège |
|---|---|---|
| Taille d'équipe et volume de tokens | Centaines à milliers d'ingénieurs générant un volume de tokens quotidien élevé et stable, comme à l'échelle d'environ 2 000 ingénieurs de Revolut. | Une petite ou moyenne équipe où les frais de GPU et d'ops coûteraient plus que la facture d'API qu'ils remplacent. |
| Compétences GPU et ops en interne | Vous exploitez déjà, ou pouvez recruter pour, une infrastructure GPU : l'ajustement de la pile de service, la quantification et la planification de capacité sont un vrai travail continu. | Aucune équipe d'infrastructure ML dédiée, et aucune envie d'en construire une juste pour servir un modèle de code. |
| Résidence des données et conformité | Le code ou le contexte ne peut pas quitter une infrastructure que vous contrôlez, ou un régulateur attend que vous indiquiez précisément où a lieu l'inférence. | Les conditions standard de traitement des données d'un fournisseur satisfont déjà vos exigences de conformité et de résidence des données. |
| Solution de repli pour les problèmes les plus difficiles | Un budget pour un usage occasionnel d'API frontier reste disponible pour la petite part de tâches qu'un modèle à poids ouverts gère mal. | La majeure partie de votre charge de travail correspond exactement au type de problème difficile et varié pour lequel les modèles frontier sont ajustés, pas du codage routinier. |
| Prévisibilité de facturation vs flexibilité | Vous voulez des coûts d'infrastructure plats et prévisibles plutôt qu'une facture qui bouge avec l'usage et les changements de tarification des modèles. | Vous voulez pouvoir changer de modèle ou de fournisseur rapidement sans réajuster une pile de service, et l'usage est trop irrégulier pour dimensionner des GPU. |
Le Cas SourceCe Que Revolut A Réellement Fait Et Mesuré
David Abitbol, qui dirige les opérations IA chez Revolut, a décrit ce déploiement lors d'une conférence à l'AI Engineer de New York, fin 2026. Revolut suit deux chiffres sur un échantillon d'environ 2 000 ingénieurs : le temps de codage en heures, et le délai de livraison en jours entre la prise en charge d'une fonctionnalité et sa fusion, prête à être déployée.
Un premier déploiement de Gemini de Google avec accès aux données internes a amélioré modestement les deux indicateurs, surtout en remplaçant les recherches dans la documentation. Claude Code d'Anthropic est sorti ensuite sous des budgets de tokens stricts par ingénieur, après que certains ingénieurs ont généré de grosses factures pour un retour peu clair, et Abitbol dit que cela n'a montré que peu d'effet mesurable au début.
Ce qui a changé les chiffres, c'est l'auto-hébergement d'un modèle à poids ouverts, le GLM de Z.ai, à partir d'environ avril 2026, sans aucune limite de tokens. Le temps de codage s'est amélioré d'environ 60 % et le délai de livraison d'environ 70 %. Revolut traite maintenant le modèle auto-hébergé comme le choix par défaut pour le codage quotidien, avec une facturation plate et prévisible, et garde les outils frontier comme exception pour les problèmes les plus difficiles.
À environ 2 000 ingénieurs, servir le modèle a nécessité 56 GPU Nvidia B200, avec pour objectif un temps jusqu'au premier token sous les trois secondes (les plaintes commencent au-delà de cinq). Le coût moyen est ressorti à environ 0,30 $ par million de tokens, environ un dixième de ce que Revolut payait auparavant à Anthropic et OpenAI combinés.
La Vraie LeçonLa Leçon N'est Pas Le Modèle, C'est Le Rationnement
La propre lecture des données par Abitbol est la partie la plus utile : le délai de livraison s'est amélioré plus que le temps de codage, ce qui signifie que le codage n'a jamais été le principal goulot d'étranglement. Une fois que plus personne n'a besoin d'économiser des tokens pour le ticket le plus difficile du trimestre, les ingénieurs se mettent à orienter l'IA vers les e-mails, Jira, Confluence, et le reste du travail qui entoure une fonctionnalité, pas seulement le code lui-même.
Cette leçon vaut quel que soit le modèle utilisé par une équipe. Une équipe sur une API frontier qui budgétise les tokens par ingénieur, ou plafonne l'usage pour contrôler les coûts, recrée exactement le problème de rationnement que Revolut a résolu en supprimant les limites. La solution n'est pas toujours l'auto-hébergement ; parfois c'est un plan tarifaire moins cher ou plus plat sur le même modèle frontier.
Le vrai enseignement pratique pour tout responsable ingénierie est de mesurer le délai de livraison, pas seulement le temps de codage ou les lignes générées, avant de décider si les outils IA rapportent, et de vérifier si les ingénieurs rationnent leur propre usage à cause de la pression sur les coûts ou les quotas.
Cette page se concentre sur la décision de coût d'équipe et de déploiement : faut-il auto-héberger du tout, et comment le déployer une fois la décision prise. Pour la question plus large et indépendante du modèle de ce que signifient réellement les poids ouverts, l'open source et les API fermées, et pourquoi les labos et les gouvernements les traitent différemment, le guide de Nightschool AI Open-Source vs Closed AI Models couvre ce terrain en détail.
Ajuster Avant De Monter En ÉchelleL'Auto-Hébergement A Demandé De L'Ingénierie, Pas Seulement Des Poids
Les chiffres d'infrastructure de Revolut sont un avertissement utile contre l'idée que l'auto-hébergement serait simple une fois qu'on a des GPU. D'avril à août 2026, avec le nombre de GPU resté fixe à 56, la charge est passée d'environ 3 à plus de 7 requêtes par seconde tandis que le temps jusqu'au premier token est tombé d'environ 14 secondes à moins de 2, une amélioration de latence de 88 % sans nouveau matériel.
Abitbol attribue environ 80 % de ce gain à la configuration de service, pas aux GPU : plafonner la longueur de contexte bien en dessous du maximum annoncé du modèle, faire tourner une quantification en précision réduite sur du matériel GPU de génération actuelle, et ajuster la façon dont le cache d'attention du modèle est réparti entre les appareils. Sa phrase résumée pour les équipes qui envisagent cette voie est sans détour : charger des poids sur des GPU et considérer que c'est fait donne des performances exécrables.
Ce travail d'ajustement est un vrai coût opérationnel continu que la plupart des équipes sous-estiment quand elles comparent le prix affiché d'un modèle auto-hébergé à une facture d'API.
Le DéploiementFormez L'Habitude Avant De Toucher À L'Infrastructure
Le gain de Revolut a suivi la suppression des limites de tokens, pas le changement de modèle. Voici les étapes qui ancrent cette habitude dans n'importe quelle équipe, sur n'importe quel modèle.
Fixez d'abord une référence de délai de livraison
Avant de changer d'outil ou de budget, mesurez combien de temps prend réellement une fonctionnalité type, de la prise en charge à la mise en état d'être fusionnée. Sans cette référence, vous ne pouvez pas savoir si un changement ultérieur a aidé.
Supprimez le rationnement silencieux
Vérifiez si les ingénieurs économisent leur usage de l'IA pour le ticket le plus difficile du mois à cause d'un budget ou d'un quota. Si c'est le cas, ce rationnement plafonne vos résultats, quel que soit le modèle derrière.
Entraînez sur chaque ticket, pas seulement les difficiles
L'habitude qui a fait bouger les chiffres de Revolut consistait à orienter l'IA vers les e-mails, les tickets et la documentation, pas seulement les problèmes de codage difficiles. Enseignez cette habitude explicitement ; elle ne se forme pas toute seule simplement parce qu'une limite a été levée.
Remesurez le délai de livraison, pas seulement le temps de codage
Suivez le même indicateur de délai de livraison après le changement. Si le temps de codage s'améliore mais pas le délai de livraison, le goulot d'étranglement est encore ailleurs dans le processus, et plus de tokens ne le réglera pas.
Limites HonnêtesCe Que Le Cas De Revolut Ne Prouve Pas
Les chiffres de Revolut décrivent le déploiement d'une seule banque régulée, à sa propre échelle. Gardez ces limites en tête avant de traiter ceci comme un résultat universel.
Les chiffres d'une entreprise, pas un étalon
Les chiffres de coût et de latence de ce guide décrivent le déploiement, le profil d'usage et les conditions négociées spécifiques de Revolut. Considérez-les comme la preuve de ce qui est possible, pas comme une garantie de prix ou de performance pour votre propre charge de travail.
Les outils frontier sont restés dans le mix
Revolut n'a pas éliminé Claude Code d'Anthropic, Codex d'OpenAI ni Gemini de Google. L'entreprise les a gardés comme exception délibérée pour les problèmes que son modèle auto-hébergé gère moins bien, ce qui est un coût que la plupart des argumentaires d'auto-hébergement passent sous silence.
Les détails de conformité sont propres à l'entreprise
Le raisonnement de Revolut sur où elle fait tourner le modèle et comment cela satisfait son régulateur reflète sa propre situation en tant que banque régulée dans l'UE. Ce n'est pas une conclusion générale selon laquelle n'importe quel modèle, région ou configuration satisfait les obligations d'une autre organisation.
Formez L'Habitude Avant De Toucher À L'Infrastructure
Le gain de Revolut vient de la suppression des limites de tokens, ce qui a permis aux ingénieurs d'utiliser l'IA sur chaque ticket, pas seulement les difficiles. Ce changement d'habitude précède toute décision d'auto-hébergement, et la formation en entreprise de Nightschool AI la construit à l'échelle d'une équipe d'ingénierie entière.
Questions fréquentes
Qu'est-ce qu'un modèle de code à poids ouverts ?
Un modèle dont les poids entraînés sont téléchargeables et peuvent tourner sur une infrastructure que vous contrôlez, contrairement à un modèle fermé auquel vous n'accédez que via l'API d'un fournisseur. Le GLM de Z.ai, le modèle du cas Revolut, en est un exemple ; le faire tourner demande quand même une vraie infrastructure GPU et un ajustement de la pile de service.
Revolut a-t-elle complètement arrêté d'utiliser Claude Code, Codex et Gemini ?
Non. Revolut a fait d'un modèle à poids ouverts auto-hébergé le choix par défaut pour le codage quotidien, mais a gardé Claude Code d'Anthropic, Codex d'OpenAI et Gemini de Google disponibles comme exception pour ses problèmes les plus difficiles, où l'entreprise rapporte que ces outils frontier performent encore bien.
Combien Revolut a-t-elle réellement économisé en auto-hébergeant ?
Son propre coût moyen rapporté était d'environ 0,30 $ par million de tokens, environ un dixième de ce qu'elle payait auparavant à Anthropic et OpenAI combinés, pour servir environ 2 000 ingénieurs sur 56 GPU Nvidia B200. Ce chiffre décrit le déploiement et l'usage de Revolut, pas un prix que chaque équipe devrait attendre.
L'auto-hébergement est-il vraiment moins cher une fois le travail d'ingénierie compté ?
Pas automatiquement. Revolut rapporte qu'environ 80 % de son gain de performance venait de l'ajustement de sa configuration de service, pas de l'achat de plus de GPU, ce qui est un travail d'infrastructure continu. Une équipe plus petite sans cette compétence en interne pourrait dépenser plus pour atteindre une performance comparable qu'elle ne le ferait sur une facture d'API frontier.
Un modèle à poids ouverts auto-hébergé comme GLM est-il un risque de sécurité en raison de son lieu de fabrication ?
Où les poids d'un modèle ont été entraînés et où vous les faites tourner sont deux questions différentes. La position propre de Revolut, en tant que banque régulée, était que télécharger des poids et les faire tourner sur une infrastructure qu'elle contrôle dans des juridictions approuvées constitue un chemin de données différent d'envoyer des requêtes à un point de terminaison hébergé par un tiers ; les organisations soumises à d'autres régulateurs devraient vérifier ce point par rapport à leurs propres exigences de conformité plutôt que de supposer qu'il s'applique à elles.
Que devrait faire une équipe d'ingénierie plus petite au lieu d'auto-héberger ?
Se concentrer sur la leçon plutôt que sur l'infrastructure : vérifier si les ingénieurs rationnent leur usage de l'IA à cause de limites de coût ou de quota, et si oui, regarder un plan plus plat ou moins cher sur le modèle frontier que vous utilisez déjà avant d'envisager l'investissement en GPU et en ops qu'exige l'auto-hébergement.
Que devrions-nous mesurer pour savoir si les outils IA de codage aident réellement ?
Mesurez le délai de livraison, les jours entre la prise en charge d'une fonctionnalité et sa fusion, prête à être déployée, en plus du temps de codage. Les données de Revolut ont montré que le délai de livraison s'améliorait plus que le temps de codage, ce qui est un signe que le travail environnant, pas la frappe au clavier, était le vrai goulot d'étranglement.
Nightschool AI est-elle affiliée à Anthropic, Z.ai ou Revolut ?
Non. Nightschool AI est une plateforme d'apprentissage indépendante et n'est pas affiliée, approuvée ni sponsorisée par Anthropic, Z.ai, Revolut, OpenAI ou Google. Claude, Codex, Gemini et GLM sont des produits de leurs entreprises respectives, nommés ici uniquement pour décrire ce qu'ils sont et comment ils ont été utilisés dans ce cas.
Formez L'Habitude, Puis Décidez De L'Infrastructure
Le modèle et le choix d'hébergement comptent moins que de savoir si votre équipe rationne encore les tokens.