Als reactie op de stijgende uitgaven voor The AI / news, is de meest voorkomende reactie om het gebruik te beperken: consumptieplafonds, aantal gebruikersplaatsen en goedkeuringen voor het starten van agents. Deze ongedifferentieerde beperkingen kunnen echter nuttig gebruik afremmen en de verkeerde indicator meten, volgens de analyse.
- Stop met het tellen van tokens en tel wat wordt opgeleverd.
- Algemene verbruiksbeperkingen meten de verkeerde indicator en remmen nuttig werk af.
- Meet de kosten per geaccepteerde merge-aanvraag en let daarbij op kwaliteit.
- Reserveer krachtige modellen voor complexe taken en laat routinewerk aan open-weight modellen over.
De kosten per token (een eenheid tekst die door een taalmodel wordt verwerkt) meten het verbruik, niet de resultaten. Een deel van de uitgaven komt overeen met verspilling, zoals het opnieuw uitvoeren van queries of ongecontroleerde loops, terwijl een ander deel het daadwerkelijke werk van het opleveren van software vertegenwoordigt. Een teller kan deze niet onderscheiden, net zomin als een uitgavenplafond.
De geleverde software meten
Een relevantere indicator zou de kosten per geaccepteerde merge-aanvraag zijn, dat wil zeggen de totale kosten van door The AI / news ondersteunde ontwikkeling gedeeld door het aantal wijzigingen die de review doorstaan en in de code worden geïntegreerd, in het jargon ‘pull requests’ genoemd. Tegelijkertijd moeten correcties en defecten worden bijgehouden, zodat goedkopere wijzigingen geen kwaliteitsverlies maskeren.
Als deze kosten dalen terwijl het gebruik toeneemt, zonder kwaliteitsverlies, zetten ontwikkelaars meer verbruik om in nuttige software. De vraag is dus niet hoeveel tokens worden gebruikt, maar hoeveel afgerond werk de investering oplevert. Om deze balans te verbeteren, worden twee hefbomen naar voren geschoven: kostbare inferentie reserveren voor taken die het nodig hebben, en de kosten van routinewerk verlagen.
Het model aanpassen aan de taak
Agent-gebaseerde ontwikkeling, waarbij een agent autonoom code schrijft en wijzigt, vereist niet op elk moment het krachtigste model. Een topmodel, of een on-premises flagship-model wanneer het bedrijfsbeleid dit vereist, kan worden gereserveerd voor complexe planning en nieuwsoortig redeneren. Eenvoudigere taken, zoals codegeneratie, het maken van tests of herhaalde refactoring, kunnen worden toevertrouwd aan ‘open-weight’ modellen, die het bedrijf zelf direct gebruikt.
Een gateway kan elke aanvraag routeren op basis van complexiteit, gevoeligheid van de gegevens, kosten en latentie. Het eerste model wordt dus alleen gebruikt wanneer de situatie dit rechtvaardigt. Zoals de auteur samenvat: ‘Meter the exception, not the workload’, oftewel: meet de uitzondering, niet de werklast.
Open-weight modellen maken deze verdeling steeds haalbaarder. Volgens de aangehaalde benchmarks voor software-engineering kunnen de beste onder hen op sommige taken de prestaties van topmodellen benaderen. Deze vaststelling garandeert geen gelijkwaardigheid op alle code repositories of alle workflows. Daarom wordt aanbevolen om kandidaten te evalueren op eigen code, eigen tests en eigen acceptatiecriteria voordat ze productiewerk krijgen.
De economie van herhaald gebruik veranderen
Rest nog te bepalen wie de rekenkracht bezit. Met gehuurde inferentie wordt elke aanroep toegevoegd aan de rekening. Met eigen capaciteit is het grootste deel van de kosten al gemaakt, waardoor elke extra aanroep goedkoper wordt naarmate het gebruik toeneemt.
