Beslissingsgids voor engineeringleiders
Moet uw engineeringteam een open-weight codeermodel zelf hosten?
Revolut's 2.000 engineers zeggen dat het afhangt van volume, niet van ideologie.
Het hangt af van het aantal engineers, de eigen GPU- en ops-kennis, en de eisen rond dataresidentie, niet alleen van modelkwaliteit. Revolut hostte zelf een open-weight model bij ongeveer 2.000 engineers en verlaagde de frontier-API-rekening met ongeveer 90%, maar houdt frontier-tools nog altijd achter de hand voor de moeilijkste problemen. Kleinere teams zullen een frontier-API meestal goedkoper vinden om te draaien.
Gepubliceerd
Belangrijkste punten
- Bij ongeveer 2.000 engineers hostte Revolut Z.ai's GLM zelf op 56 Nvidia B200-GPU's en verlaagde zo de gemengde tokenkosten tot ongeveer een tiende van de eerdere rekening bij Anthropic en OpenAI.
- De doorlooptijd (dagen van het oppakken van een feature tot merge-klaar) verbeterde meer dan de codeertijd, ongeveer 70% versus 60%, wat erop wijst dat de echte bottleneck nooit puur het coderen was.
- De winst liep gelijk met het wegvallen van tokenbudgetten, niet alleen met de modelwissel: zodra tokens niet meer schaars waren, zetten engineers AI ook in op e-mail, tickets en documentatie.
- Zelf hosten vereiste echt infrastructuurwerk, niet alleen het downloaden van gewichten: het afstemmen van contextlengte, kwantisering en parallellisatie verlaagde de tijd tot het eerste token met 88%, bij hetzelfde aantal GPU's.
- Revolut houdt Anthropic's Claude Code, OpenAI's Codex en Google's Gemini nog altijd achter de hand als frontier-uitzondering voor de moeilijkste problemen, niet als dagelijkse standaard.
De volledige gids
Tik op een onderdeel om het te openen.
Over deze gids
Dit is een kopersgids voor engineeringleiders die overwegen om een open-weight codeermodel, zoals Z.ai's GLM, zelf te hosten in plaats van per seat of per token te betalen voor een frontier-API. De gids is gebouwd rond Revolut's openbare cijfers: een bank die het grootste deel van haar ongeveer 2.000 engineers losmaakte van betaling per token, terwijl Anthropic's Claude Code, OpenAI's Codex en Google's Gemini bewaard bleven voor de moeilijkste problemen. De les gaat niet over welk model Revolut koos, maar over wat er veranderde toen tokens niet langer gerantsoeneerd werden.
Zelf hosten versus een frontier-API of seatplan: een beslissingscheck
| Factor | Pleit voor zelfgehost open-weight | Pleit voor frontier-API of seatplan |
|---|---|---|
| Teamgrootte en tokenvolume | Honderden tot duizenden engineers die een constant, hoog dagelijks tokenvolume genereren, zoals bij Revolut's schaal van ongeveer 2.000 engineers. | Een klein of middelgroot team waarbij GPU- en ops-overhead meer zou kosten dan de API-rekening die het vervangt. |
| Eigen GPU- en ops-kennis | U draait al GPU-infrastructuur of kunt daarvoor aannemen: het afstemmen van de serveerstack, kwantisering en capaciteitsplanning zijn reëel, doorlopend werk. | Geen toegewijd ML-infrastructuurteam, en geen zin om daar één voor op te bouwen alleen om een codeermodel te bedienen. |
| Dataresidentie en compliance | Code of context mag infrastructuur die u controleert niet verlaten, of een toezichthouder verwacht dat u precies aangeeft waar inference plaatsvindt. | De standaard data-afhandelingsvoorwaarden van een leverancier voldoen al aan uw compliance- en dataresidentie-eisen. |
| Terugvaloptie voor de moeilijkste problemen | Er blijft budget beschikbaar voor incidenteel frontier-API-gebruik, voor het kleine deel taken waar een open-weight model minder goed in is. | Het grootste deel van uw workload is precies het soort moeilijk, gevarieerd probleem waarvoor frontier-modellen zijn afgestemd, niet routinematig coderen. |
| Voorspelbaarheid versus flexibiliteit van facturering | U wilt vaste, voorspelbare infrastructuurkosten in plaats van een rekening die meebeweegt met gebruik en prijswijzigingen van modellen. | U wilt snel kunnen wisselen van model of leverancier zonder een serveerstack opnieuw af te stemmen, en het gebruik is te ongelijk om GPU's op te dimensioneren. |
De bronzaakWat Revolut daadwerkelijk deed en meette
David Abitbol, die AI-operations leidt bij Revolut, beschreef de uitrol in een talk op de AI Engineer-conferentie in New York, eind 2026. Revolut volgt twee cijfers bij een steekproef van ongeveer 2.000 engineers: codeertijd in uren, en doorlooptijd in dagen vanaf het oppakken van een feature tot het punt waarop die gemerged en deploy-klaar is.
Een vroege uitrol van Google's Gemini met toegang tot interne data verbeterde beide metrics licht, vooral door het vervangen van documentatie-opzoekingen. Anthropic's Claude Code volgde daarna onder strikte tokenbudgetten per engineer, nadat sommige engineers hoge kosten hadden gemaakt met weinig duidelijk rendement, en volgens Abitbol was het effect in eerste instantie nauwelijks meetbaar.
Wat de cijfers deed veranderen was het zelf hosten van een open-weight model, Z.ai's GLM, vanaf ongeveer april 2026, zonder enige tokenlimiet. De codeertijd verbeterde met ongeveer 60% en de doorlooptijd met ongeveer 70%. Revolut behandelt het zelfgehoste model nu als standaard voor dagelijkse codeertaken, met vaste en voorspelbare facturering, en houdt frontier-tools achter de hand als uitzondering voor de moeilijkste problemen.
Bij ongeveer 2.000 engineers vroeg het bedienen van het model 56 Nvidia B200-GPU's, met als doel een tijd tot het eerste token onder de drie seconden (klachten beginnen voorbij de vijf seconden). De gemengde kosten kwamen uit op ongeveer $0,30 per miljoen tokens, ongeveer een tiende van wat Revolut eerder gecombineerd aan Anthropic en OpenAI betaalde.
De echte lesDe les is niet het model, maar de rantsoenering
Abitbols eigen interpretatie van de data is het nuttigste deel: de doorlooptijd verbeterde meer dan de codeertijd, wat betekent dat coderen nooit de voornaamste bottleneck was. Zodra niemand meer tokens hoeft te sparen voor het moeilijkste ticket van het kwartaal, beginnen engineers AI ook in te zetten op e-mail, Jira, Confluence en al het werk rond een feature, niet alleen op de code zelf.
Die les geldt los van welk model een team gebruikt. Een team dat op een frontier-API tokens per engineer budgetteert, of het gebruik beperkt om kosten te beheersen, herschept precies het rantsoeneringsprobleem dat Revolut oploste door limieten weg te nemen. De oplossing is niet altijd zelf hosten; soms is het een goedkoper of vlakker prijsplan bij hetzelfde frontier-model.
De praktische les voor elke engineeringleider is om doorlooptijd te meten, niet alleen codeertijd of gegenereerde regels, voordat wordt besloten of AI-tooling zich terugbetaalt, en om te letten op engineers die hun eigen gebruik rantsoeneren vanwege kosten- of quotadruk.
Deze pagina richt zich op de teamkosten- en uitrolbeslissing: of zelf hosten de moeite waard is, en hoe de uitrol te plannen eenmaal die keuze is gemaakt. Voor de bredere, modelonafhankelijke vraag wat open weights, open source en gesloten API's precies betekenen, en waarom labs en overheden daar verschillend tegenaan kijken, behandelt Nightschool AI's gids Open-Source vs Gesloten AI-modellen dat onderwerp volledig.
Afstemmen voor opschalenZelf hosten vroeg engineering, niet alleen gewichten
Revolut's infrastructuurcijfers zijn een nuttige waarschuwing tegen de aanname dat zelf hosten simpel is zodra je GPU's hebt. Van april tot augustus 2026, met het aantal GPU's constant op 56, steeg de belasting van ongeveer 3 naar meer dan 7 verzoeken per seconde, terwijl de tijd tot het eerste token daalde van ongeveer 14 seconden tot onder de 2, een latentieverbetering van 88% zonder nieuwe hardware.
Abitbol schrijft ongeveer 80% van die winst toe aan de serveerconfiguratie, niet aan de GPU's: het beperken van de contextlengte ver onder het geadverteerde maximum van het model, het draaien van kwantisering met lagere precisie op huidige GPU-hardware, en het afstemmen van hoe de attention-cache van het model over devices wordt verdeeld. Zijn samenvatting voor teams die dit pad overwegen is kort en bot: gewichten op GPU's laden en het daarbij laten, levert slechte prestaties op.
Dat afstemmingswerk is een reële, doorlopende ops-kost die de meeste teams onderschatten wanneer ze het prijskaartje van een zelfgehost model vergelijken met een API-rekening.
De uitrolTrain de gewoonte voordat u aan infrastructuur raakt
Revolut's winst liep gelijk met het wegnemen van tokenlimieten, niet met het wisselen van model. Dit zijn de stappen die die gewoonte laten beklijven, bij elk team, met elk model.
Bepaal eerst een doorlooptijd-baseline
Meet, voordat u tooling of budget wijzigt, hoe lang een typische feature daadwerkelijk duurt van oppakken tot merge-klaar. Zonder deze baseline kunt u niet vaststellen of een latere verandering iets opleverde.
Haal stille rantsoenering weg
Controleer of engineers AI-gebruik sparen voor het moeilijkste ticket van de maand vanwege een budget of quotum. Als dat zo is, begrenst die rantsoenering uw resultaten, ongeacht welk model erachter zit.
Train op elk ticket, niet alleen de moeilijke
De gewoonte die Revolut's cijfers deed bewegen was AI inzetten op e-mail, tickets en documentatie, niet alleen op lastige codeerproblemen. Leer die gewoonte expliciet aan; ze ontstaat niet vanzelf alleen omdat een limiet is weggehaald.
Meet opnieuw de doorlooptijd, niet alleen de codeertijd
Volg na de verandering dezelfde doorlooptijd-metric opnieuw. Verbetert de codeertijd wel maar de doorlooptijd niet, dan zit de bottleneck nog elders in het proces, en lossen meer tokens dat niet op.
Eerlijke grenzenWat Revolut's case niet bewijst
Revolut's cijfers beschrijven de uitrol van één gereguleerde bank, op haar eigen schaal. Houd deze grenzen in gedachten voordat u dit als een universeel resultaat behandelt.
De cijfers van één bedrijf, geen benchmark
De kosten- en latentiecijfers in deze gids beschrijven Revolut's specifieke uitrol, gebruikspatroon en onderhandelde voorwaarden. Behandel ze als bewijs van wat mogelijk is, niet als een prijs- of prestatiegarantie voor uw eigen workload.
Frontier-tools bleven in de mix
Revolut schafte Anthropic's Claude Code, OpenAI's Codex of Google's Gemini niet af. Het hield ze bewust achter als uitzondering voor problemen waar het zelfgehoste model minder goed in is, een kostenpost die de meeste pitches voor zelf hosten weglaten.
Compliance-details zijn bedrijfsspecifiek
Revolut's redenering over waar het het model draait en hoe dat voldoet aan de eisen van de toezichthouder weerspiegelt de eigen omstandigheden als EU-gereguleerde bank. Het is geen algemene vaststelling dat welk model, regio of opzet dan ook voldoet aan de verplichtingen van een andere organisatie.
Leer de gewoonte aan voordat u aan infrastructuur raakt
Revolut's winst kwam uit het wegnemen van tokenlimieten, zodat engineers AI gebruikten op elk ticket, niet alleen de moeilijke. Die gewoonteverandering komt vóór elke beslissing over zelf hosten, en Nightschool AI's bedrijfstraining bouwt die op bij een heel engineeringteam.
Veelgestelde vragen
Wat is een open-weight codeermodel?
Een model waarvan de getrainde gewichten downloadbaar zijn en op infrastructuur die u controleert kunnen draaien, in tegenstelling tot een gesloten model dat u alleen via de API van een leverancier kunt bereiken. Z.ai's GLM, het model in Revolut's case, is daarvan een voorbeeld; het draaien ervan vraagt nog altijd reële GPU-infrastructuur en afstemming van de serveerstack.
Is Revolut volledig gestopt met Claude Code, Codex en Gemini?
Nee. Revolut maakte een zelfgehost open-weight model de standaard voor dagelijkse codeertaken, maar hield Anthropic's Claude Code, OpenAI's Codex en Google's Gemini beschikbaar als uitzondering voor de moeilijkste problemen, waar die frontier-tools volgens eigen rapportage nog goed presteren.
Hoeveel heeft Revolut daadwerkelijk bespaard door zelf te hosten?
De eigen gerapporteerde gemengde kosten bedroegen ongeveer $0,30 per miljoen tokens, ongeveer een tiende van wat eerder gecombineerd aan Anthropic en OpenAI werd betaald, bij het bedienen van ongeveer 2.000 engineers op 56 Nvidia B200-GPU's. Dat cijfer beschrijft Revolut's eigen uitrol en gebruik, geen prijs die elk team zou mogen verwachten.
Is zelf hosten echt goedkoper als het engineeringwerk wordt meegerekend?
Niet automatisch. Revolut rapporteert dat ongeveer 80% van de prestatiewinst kwam uit het afstemmen van de serveerconfiguratie, niet uit het kopen van meer GPU's, wat doorlopend infrastructuurwerk is. Een kleiner team zonder die kennis in huis kan meer uitgeven aan het bereiken van vergelijkbare prestaties dan het aan een frontier-API-rekening zou betalen.
Is een zelfgehost open-weight model zoals GLM een veiligheidsrisico vanwege waar het is gemaakt?
Waar de gewichten van een model zijn getraind en waar u ze draait zijn twee verschillende vragen. Revolut's eigen positie, als gereguleerde bank, was dat het downloaden van gewichten en het draaien ervan op infrastructuur die het zelf controleert in goedgekeurde rechtsgebieden een ander datapad is dan verzoeken sturen naar het gehoste endpoint van een derde partij; organisaties met andere toezichthouders moeten dit tegen hun eigen compliance-eisen toetsen in plaats van aan te nemen dat het ook voor hen geldt.
Wat moet een kleiner engineeringteam doen in plaats van zelf hosten?
Richt u op de les, niet de infrastructuur: ga na of engineers AI-gebruik rantsoeneren vanwege kosten- of quotalimieten, en als dat zo is, bekijk eerst een vlakker of goedkoper plan bij het frontier-model dat u al gebruikt, voordat u de GPU- en ops-investering overweegt die zelf hosten vraagt.
Wat moeten we meten om te weten of AI-codeertools daadwerkelijk helpen?
Meet de doorlooptijd, de dagen van het oppakken van een feature tot het punt waarop die gemerged en deploy-klaar is, naast de codeertijd. Revolut's data toonden dat de doorlooptijd meer verbeterde dan de codeertijd, een teken dat het omringende werk, niet het typen, de echte bottleneck was.
Is Nightschool AI gelieerd aan Anthropic, Z.ai of Revolut?
Nee. Nightschool AI is een onafhankelijk leerplatform en is niet gelieerd aan, onderschreven door of gesponsord door Anthropic, Z.ai, Revolut, OpenAI of Google. Claude, Codex, Gemini en GLM zijn producten van hun respectievelijke bedrijven, hier alleen genoemd om te beschrijven wat ze zijn en hoe ze in deze case werden gebruikt.
Bouw eerst de gewoonte, besluit dan over infrastructuur
Het model en de hostingkeuze doen er minder toe dan of uw team nog altijd tokens rantsoeneert.