De rekening zien voor hij op de mat valt: Enterprise AI-uitgaven voorspellen

Hoe u van de kostendata van uw AI Gateway een toekomstgerichte budgetprognose maakt — met een vroegtijdig waarschuwingssignaal voordat u de limiet overschrijdt — met behulp van twee beproefde tijdreeksmodellen, end-to-end uitgevoerd op TrueFoundry.

De tokenmaxxing-trilogie bepleitte het belang van attributie: u kunt uitgaven die u niet ziet, niet beheren. Het vervolg in de Field Notes over de Meta / Amazon / Uber-achtbaan stelde dat attributie alleen u een regelknop geeft in plaats van een aan/uit-schakelaar. Maar een regelknop laat één vraag onbeantwoord: niet "waar is het geld naartoe gegaan?" — dat is de achteruitkijkspiegel — maar "waar gaat het naartoe?" Toen werd gemeld dat Uber zijn gehele AI-coderingsbudget voor 2026 er in vier maanden doorheen had gejaagd, was het probleem niet dat de uitgaven onzichtbaar waren. Het probleem was dat niemand een geloofwaardige prognose had van wanneer het budget op zou zijn, totdat dat al het geval was.

Bovenstaand artikel gaat over het dichten van die kloof met een forecast. We nemen een fictief maar realistisch bedrijf mee — Meridian, een middelgrote fintech met ongeveer 800 engineers — van "we hebben geattribueerde kostendata" naar "we hebben een wekelijkse, zelf-updatende projectie van tokenuitgaven per team, met een eerlijke onzekerheidsmarge en een melding die afgaat voordat het budget wordt overschreden." We gebruiken twee complementaire tijdreeksmodellen, SARIMAX en Prophet, en we bouwen, deployen en her-trainen het geheel op TrueFoundry — hetzelfde platform dat de gateway-kostentelemetrie levert, en dat ook de ML-infrastructuur biedt om de forecaster te trainen, te serveren en te her-trainen.

Van attributie naar een tijdreeks

Alles hier hangt af van één voorwaarde: schone, geattribueerde kostendata met een timestamp. Dat is precies wat een goed geïnstrumenteerde AI Gateway kan produceren: kosten op request-niveau — automatisch geprijsd op basis van de gepubliceerde tarieven van providers — met de metadata die nodig is om uitgaven te aggregeren per team, route, model, klant of kostencrum. Zoals besproken in de trilogie en het observability-overzicht, genereert elk verzoek via de gateway dat kostencijfer, getagd met model, gebruiker en willekeurige metadata, en exporteert dit naar uw warehouse of observability stack. Aggregeer het naar een wekelijks totaal per kostencentrum en u heeft de enige invoer die een forecaster nodig heeft: een regelmatige, gelabelde tijdreeks van uitgaven.

De forecast is zo goed als de taggingsdiscipline die eronder ligt, dus deze stap is operationeler dan hij lijkt. De gateway zal getrouw alle metadata vastleggen die uw applicaties sturen — wat betekent dat de tijdreeks pas zo schoon is als die instrumentatie. Vóór de training heeft een team stabiele metadatasleutels en consistente team-naar-kostencentrum-mappings nodig, een manier om modelprijzen actueel te houden als providers ze wijzigen, en een expliciet beleid voor de lastige gegevens: late of ontbrekende data, retries, fallbacks en gecachte responsen die weinig tot niets kosten. Het normaliseren van prijzen, ontdubbelen en het uitlijnen van timestamps op één tijdzone is niet aantrekkelijk, maar het is het verschil tussen een forecast en een zelfverzekerd ogend artefact dat is gebouwd op ruis.

Dat gezegd hebbende, is dit nog steeds het deel dat teams zonder gateway helemaal niet kunnen doen. Als uw uitgaven verspreid zijn over ruwe providerfacturen, kunt u een maandelijks totaal op bedrijfsniveau reconstrueren, maar u kunt geen schone wekelijkse reeks per team krijgen met de causale context erbij — en per-team, contextrijke reeksen zijn wat forecasting nuttig maakt in plaats van decoratief. De gateway is niet zomaar een kostencontrolepunt; het is het instrument dat de uitgaven in de eerste plaats voorspelbaar maakt.

Meridian: een fictieve fintech met een echt probleem

Maak kennis met Meridian — een samengesteld, geen echt bedrijf, maar opgebouwd uit volledig reële patronen. Het heeft ongeveer 800 engineers, een jaar van agressieve interne AI-adoptie en een financieel team dat zojuist een bestuursvraag kreeg die het niet kon beantwoorden: "wat gaat AI ons volgend kwartaal kosten?" Attributie is al opgelost — hun gateway kan tot op de dollar nauwkeurig tonen wat vorige maand kostte en wie dat veroorzaakte. Wat ze niet kunnen, is geloofwaardig vooruitkijken. De spreadsheet van de CFO extrapoleert een rechte lijn; het platformteam weet dat de werkelijkheid grilliger is, omdat uitgaven pieken rond lanceringen, dalen tijdens feestdagen en stapsgewijs stijgen telkens wanneer een team een nieuwe agent in productie neemt.

Dat is de kloof tussen een trendlijn en een forecast. Een lineaire extrapolatie heeft geen gevoel voor seizoensgebondenheid, geen idee welke drijfveren de curve omhoog duwen en — het belangrijkste — geen eerlijke weergave van de eigen onzekerheid. Meridian heeft een model nodig dat het ritme opvangt, rekening kan houden met wat er aan zit te komen (de geplande headcount-toename, de drie roadmap-lanceringen) en een betrouwbaarheidsinterval rapporteert in plaats van één misleidend precies getal.

Twee modellen, twee verschillende taken: SARIMAX en Prophet

Er is niet één beste tijdreeksmodel, en iedereen die u iets anders vertelt, probeert u iets te verkopen. Voor het probleem van Meridian verdienen er twee hun plek — en ze verdienen die om verschillende redenen.

SARIMAX: wanneer u drijfveren heeft en nauwkeurigheid vereist is

SARIMAX staat voor Seasonal AutoRegressive Integrated Moving Average with eXogenous regressors. Ontdoe het van het acroniem en het zijn drie ideeën. De ARIMA-kern modelleert een reeks als een functie van het eigen recente verleden — de uitgaven van vorige week voorspellen die van deze week. Het seizoensgebonden deel voegt een herhalende cyclus toe, en de periode moet overeenkomen met hoe u de data heeft geaggregeerd: voor een wekelijkse reeks betekent seizoensgebondenheid meestal langere ritmes zoals sprint-, kwartaal- of jaarlijkse planningscycli (een seizoensperiode van 52 legt het jaar vast), terwijl werkdag-versus-weekend-effecten alleen bestaan in een dagelijkse reeks en een periode van 7 zouden gebruiken. Het is de moeite waard om hier precies in te zijn, omdat een verkeerd gekozen seizoensperiode een van de meest voorkomende manieren is waarop een forecast ongemerkt misgaat. Het exogene deel — de X, en de reden dat het zo goed bij Meridian past — stelt u in staat externe variabelen in te voeren die de reeks drijven: engineering headcount, het aantal agents in productie, geplande launch flags. Dat is wat een forecast verandert in een wat-als-tool: Meridian kan vragen "hoe zien de uitgaven eruit als we twintig engineers toevoegen en de drie roadmap-lanceringen uitvoeren?" en krijgt een antwoord met een betrouwbaarheidsinterval, geen gok.

In ruwe, illustratieve termen ziet het fitten er zo uit — het gaat om de vorm, niet de syntaxis:

De prijs van die nauwkeurigheid is reëel: SARIMAX vereist dat de reeks ongeveer stationair is (u differentieert deze totdat dat zo is — de "I" in de naam), en de orderparameters vergen afstemming. Dat maakt het de juiste tool voor een klein aantal hoogwaardige kostencentra waar de inspanning zichzelf terugbetaalt en waar u daadwerkelijk beschikt over data van drijfveren — niet voor het voorspellen van tweehonderd teams tegelijk.

Prophet: wanneer u breedte en robuustheid wilt

Prophet, de open-source forecaster van Meta's onderzoeksgroep, neemt het tegenovergestelde standpunt in. Het ontleedt een reeks in trend, seizoensgebondenheid en feestdageffecten, en is ontworpen voor rommelige zakelijke tijdreeksen — met trend, wekelijkse en jaarlijkse seizoensgebondenheid, feestdagen, automatische detectie van changepoints en praktische tools voor het omgaan met uitschieters en onregelmatigheden — wat een redelijke forecast oplevert met weinig tuning. Dat is niet hetzelfde als "geen datacleaning vereist" (de kanttekeningen hierboven over prijzen, retries en ontbrekende records blijven van kracht), maar het is uit de doos veel vergevingsgezinder dan SARIMAX. Voor Meridian maakt dat het de natuurlijke keuze voor de long tail: draai het over de reeks van elk team om overal snel een robuuste baseline-forecast te krijgen, zonder tweehonderd modellen handmatig af te stellen.

De afweging is het spiegelbeeld van die van SARIMAX. SARIMAX kan modelgebaseerde intervallen bieden die gemakkelijker te auditen zijn wanneer de aannames kloppen; Prophet biedt ook nuttige onzekerheidsintervallen, maar deze worden anders afgeleid en teams moeten beide kalibreren tegen backtests in plaats van ze als een formele garantie te zien. Wat Prophet niet van nature biedt, is de schone causale "wat-als" die exogene regressoren wel bieden — en dat is prima, want dat vraagt u er ook niet van. De pragmatische architectuur waar Meridian op uitkomt, is om beide te draaien: Prophet voor de breedte over alle teams, SARIMAX gelaagd over de drie of vier kostencentra die groot genoeg zijn om modellering op basis van drijfveren te rechtvaardigen. De twee samen dekken meer terrein dan elk afzonderlijk.

Het eerlijke verhaal: een forecast is een marge, geen getal

Vóór het operationele verhaal, de kanttekening die voorkomt dat dit mooie praatjes worden. De belangrijkste uitkomst van een forecast is niet de puntschatting — het is het onzekerheidsinterval. Een model dat zegt "volgend kwartaal kost $ 1,2M" is veel minder nuttig, en veel gevaarlijker, dan een model dat zegt "volgend kwartaal komt uit tussen $ 1,0M en $ 1,5M met 80% betrouwbaarheid, en dit is waarom de marge zo breed is." De marge geeft een financieel team aan of ze kijken naar een afrondingsfout of een reëel risico. En het zou breder moeten worden naarmate de horizon verder weg ligt: elke forecaster die beweert dezelfde precisie te hebben over week 12 als over week 1, verbergt de waarheid. Het onderstaande interactieve model is om precies deze functionaliteit heen gebouwd.

Let op wat het signaal voor vroegtijdige waarschuwing daadwerkelijk is. Het is niet de puntvoorspelling die het budgetplafond overschrijdt — het is het moment waarop de bovenste rand van de marge dit kruist. Dat is de eerste week waarin een overschrijding aannemelijk wordt in plaats van zeker, en het is het juiste moment om te handelen, want vroeg handelen is goedkoop en laat handelen is de botte bijl waar de hele reeks zich tegen heeft uitgesproken. Een goede forecast koopt die voorlooptijd voor u.

Waarom dit thuishoort op TrueFoundry — niet alleen de gateway

Dit is de secundaire draad, bewust in een eigen sectie geplaatst zodat deze de forecasting niet verdringt. Dit is waar de twee helften van TrueFoundry's platform samenkomen, en waar dit ophoudt een generieke data science tutorial te zijn. De meeste artikelen over Prophet of SARIMAX stoppen bij het model. Maar een model in een notebook is geen forecast waar een financieel team op kan vertrouwen — het is een eenmalige actie. Het moeilijke, niet-sexy en echt waardevolle deel is operationeel: het model getraind krijgen op echte infrastructuur, geversioneerd zodat u kunt vergelijken en promoveren, geserveerd achter een API die het dashboard kan aanroepen, en — het stuk dat bijna iedereen vergeet — automatisch her-traind zodat het niet stilzwijgend veroudert als bestedingspatronen veranderen.

TrueFoundry is, onder de gateway, een ML-platform gebouwd op Kubernetes. Het ontwerpdoel, duidelijk vermeld in die architectuurbeschrijving, is dat data uw cloud niet mag verlaten — hetzelfde split-plane model als de gateway, waarbij TrueFoundry's control plane orchestreert terwijl uw compute plane de daadwerkelijke workloads binnen uw eigen account draait. Voor een fintech als Meridian is die eigenschap geen nice-to-have; kostendata getagd per team en project is gevoelig, en het binnen de VPC houden van de training en serving is wat deze aanpak überhaupt haalbaar maakt.

Concreet wordt de loop gekoppeld aan TrueFoundry-platformmodules die in de architectuurdocumentatie rechtstreeks worden beschreven:

Training als een Job. De fit van het model draait als een TrueFoundry Job — een gecontaineriseerde taak op uw Kubernetes compute plane, met de CPU- of GPU-resources die het nodig heeft, waarbij de geëxporteerde kostendata van de gateway wordt uitgelezen. Geen notebook die blijft draaien op iemands laptop; een reproduceerbare job met bijgehouden inputs.

Versionering in de Model Registry. TrueFoundry biedt een model registry zodat elke getrainde forecaster wordt geversioneerd met de bijbehorende metadata en evaluatiemetrics. Wanneer het model van deze week slechter backtest dan dat van vorige week, kunt u de versies vergelijken en kiezen of u de nieuwe promoveert of de huidige blijft serveren — het verschil tussen een experiment en een betrouwbare dienst.

Serveren als een API. Het gekozen model wordt ingezet als een TrueFoundry Service: een schaalbaar, gemonitord eindpunt dat het financiële dashboard aanroept om de nieuwste projectie en marge op te halen. Autoscaling en health checks komen van het platform, niet uit losse scripts.

Geplande her-training als een Workflow. Dit is de sluitsteen. TrueFoundry integreert een workflow-engine (ArgoWorkflows) voor precies dit soort geplande taken die uit meerdere stappen bestaan. Een wekelijkse workflow haalt de nieuwste kostendata op, controleert het live model op drift, fit opnieuw indien nodig, evalueert en promoveert de nieuwe versie alleen als deze beter is dan de huidige. De forecast blijft actueel zonder dat iemand eraan hoeft te denken een script uit te voeren.

Kosten geattribueerd, vanzelfsprekend. Omdat de forecasting-workloads zelf op TrueFoundry draaien, worden de rekenkosten daarvan ook door het platform geattribueerd — de architectuurbeschrijving meldt gedetailleerde kostenattributie per service via OpenCost. Het systeem dat uw AI-uitgaven voorspelt, rapporteert de eigen kosten op hetzelfde dashboard. Het instrument is gecalibreerd op zichzelf.

Dat end-to-end verhaal — de gateway levert de data, het ML-platform traint, serveert en her-traint het model, onder één toegangsbeheermodel — is iets wat een kale forecasting-bibliotheek u niet kan geven, en het is het deel dat dit een platformbeslissing maakt in plaats van een data science zijproject. Om precies te zijn over de grens: de trainings- en serving-workloads draaien op uw compute plane, dicht bij de data, terwijl TrueFoundry's control plane ze orchestreert; zoals bij elke deployment moeten teams controleren welke metadata, logs, licenties en control-plane records de omgeving verlaten onder hun gekozen model en contract. En om precies te zijn over de taakverdeling: TrueFoundry maakt SARIMAX of Prophet niet speciaal, en het levert uit de doos geen forecast op financieel niveau op. Wat het wel van productiekwaliteit maakt, is de loop om het model heen — geattribueerde kostendata van de gateway, trainingsjobs in het compute plane van de klant, versionering, serving, op workflows gebaseerde her-training en kostenattributie voor de forecasting-workload zelf. De klant bouwt en valideert nog steeds het model; het platform is het fundament waarmee dat model betrouwbaar kan draaien. Het punt is niet dat SARIMAX en Prophet exotisch zijn; dat zijn ze niet. Het punt is dat de afstand van "een model dat werkt in een notebook" naar "een forecast die Financiën elke maandagochtend vertrouwt" precies de afstand is waar een ML-platform voor gebouwd is.

Backtest voordat u waarschuwt

Een forecast die niemand heeft gevalideerd, is gewoon een lijn die er zelfverzekerd uitziet, en het versturen van meldingen op basis van een niet-gevalideerd model is hoe u een financieel team leert om uw waarschuwingen te negeren. Voordat een projectie een beslissing stuur, moet deze vertrouwen verdienen op basis van het verleden. De standaardmethode is evaluatie met een rollende oorsprong (rolling-origin evaluation), soms walk-forward genoemd: train op week 1 tot en met N, voorspel week N+1 tot N+12, vergelijk met wat er werkelijk is gebeurd, schuif het venster naar voren en herhaal. Als u dit over de hele geschiedenis doet, vertelt dit u hoe het model week na week zou hebben gepresteerd, niet alleen bij één toevallige split.

Houd enkele metrics bij, want elke metric beantwoordt een andere vraag. MAPE of WAPE — fout als percentage — is de leesbare metric voor een financieel publiek ("we zitten er meestal binnen 8% naast"). RMSE straft grote missers harder af, dus het brengt de incidentele slechte week aan het licht die een percentueel gemiddelde glad zou strijken. En de metric die de meesten vergeten: intervaldekking — bevat de 80%-marge daadwerkelijk ongeveer 80% van de tijd de werkelijke waarde? Een model waarvan de 80%-marge de werkelijkheid slechts de helft van de tijd opvangt, liegt over de eigen betrouwbaarheid, en dat is erger dan een bredere, eerlijke marge. De regel 'alleen promoveren indien beter' uit de geplande her-training moet tegen deze metrics worden geschreven: een nieuw wekelijks model vervangt het huidige alleen als het dit verslaat op de afgesproken foutmetric zonder dat de dekking verslechtert.

Hoe dit er voor Meridian uitziet, end-to-end

Alles bij elkaar genomen: Meridian's gateway genereert al maanden geattribueerde kosten, dus ze hebben een schone wekelijkse reeks per team. Een TrueFoundry training Job fit Prophet over alle teams voor een baseline, en SARIMAX op de vier grootste kostencentra met headcount en agent-count als regressoren. Beide modellen komen in de registry met hun backtestfouten geregistreerd. Het betere model per kostencentrum wordt geserveerd achter een forecast-API. Het financiële dashboard toont nu voor elk team een geprojecteerde uitgavencurve met een 80%-marge en een vlag — groen, oranje of waarschijnlijke overschrijding — gebaseerd op waar de bovenste marge zich bevindt ten opzichte van het budget van dat team. Een wekelijkse workflow houdt dit alles vers.

De bestuursvraag — "wat gaat AI ons volgend kwartaal kosten?" — heeft nu een eerlijk antwoord: een bereik, met de drijfveren benoemd, en een melding die afgaat in het tijdsbestek voordat een team de limiet overschrijdt, in plaats van achteraf. Meridian heeft de kosten niet geëlimineerd. Het heeft de kosten inzichtelijk gemaakt voor de toekomst, wat het enige is dat een budget verandert van een muur waar u tegenaan loopt in een plan bijsturen. Dat is de regelknop, vooruitgericht.

Wat dit niet is

Dit is geen bewering dat forecasting de noodzaak van menselijk oordeel wegneemt, of dat een model kostengovernance op de automatische piloot kan draaien. Een forecast is beslissingsondersteuning: het vergroot het tijdsbestek waarin een mens kan handelen, en het maakt de actie goedkoper door voorlooptijd te geven. Het beslist niet of een uitgaventraject acceptabel is — dat is een zakelijke afweging over de vraag of het werk dat de tokens opleveren de moeite waard is, wat dezelfde input-versus-outputvraag is waar de trilogie om draaide. Een forecast die het budget overschrijdt, kan betekenen "snijd in verspilling" of "verhoog het budget omdat dit team resultaten levert" — het model kan u niet vertellen welke van de twee het is, en elke leverancier die anders beweert, belooft te veel.

Dit is evenmin een bewering dat SARIMAX en Prophet de enige of beste modellen zijn — gradient-boosted trees, state-space-modellen en deep forecasters hebben allemaal hun plaats, en voor sommige reeksen is een eenvoudige seasonal-naive baseline oprecht moeilijk te verslaan. De twee die we hebben gekozen zijn goed begrepen, goed ondersteund en een verstandige standaardkoppeling; ze zijn een sterk startpunt, geen definitief antwoord. En de interactieve grafiek hierboven is een educatieve mock-up die wordt aangestuurd door schuifregelaars, geen TrueFoundry-modeloutput — een echte forecast leidt zijn groei, seizoensgebondenheid en interval af uit uw historie, niet uit een knop die u versleept. De eerlijke bewoording is dezelfde als die deze serie de hele tijd heeft gehanteerd: het platform geeft u de instrumenten; uw team leest ze nog steeds af en neemt de beslissing.

FAQ

Heb ik zowel SARIMAX als Prophet nodig, of kan ik er één kiezen?

U kunt absoluut met één beginnen, en voor de meeste teams is Prophet de snelste eerste stap — het biedt een robuuste baseline over elke kostenplaats met minimale tuning. Voeg SARIMAX later toe, en alleen op die enkele hoogwaardige kostenplaatsen waar u echte drivergegevens hebt (personeelsbestand, aantal agenten, launch-kalender) en de nauwere intervallen en wat-als-mogelijkheden wilt die exogene regressoren bieden. De koppeling is de volwassen staat, geen vereiste vooraf.

Waarom niet gewoon een trendlijn extrapoleren in een spreadsheet?

Een rechte lijn heeft geen seizoensinvloeden, geen bewustzijn van drivers en — fataal — geen onzekerheidsband. Het zal er zelfverzekerd naast zitten rond launches en feestdagen, en het geeft een financieel team geen manier om een kleine schommeling te onderscheiden van een echt risico. De gehele waarde van een forecast is het eerlijke interval en het vroegtijdige waarschuwingssignaal; een trendlijn heeft geen van beide.

Verlaten de kostengegevens onze omgeving om dit te doen?

De training- en serving-workloads kunnen in uw eigen compute plane draaien, dicht bij de data, waarbij de control plane van TrueFoundry de trainingsdata orchestreert in plaats van verwerkt. Dat is de eigenschap die de aanpak bruikbaar maakt voor gereguleerde workloads — maar teams moeten exact controleren welke metadata, logs, licenties en control-plane-records de omgeving verlaten onder hun gekozen deploymentmodel en contract, in plaats van "er verlaat niets" als vanzelfsprekend te beschouwen.

Hoe vaak moet het model opnieuw worden getraind?

Dat hangt af van hoe snel uw uitgavenpatronen verschuiven, maar wekelijks is een verstandige standaard voor token cost, die meebeweegt met sprintcycli en launches. Het meetslaggevende is dat her-training wordt geautomatiseerd als een geplande workflow met een driftcheck en een promote-only-if-better-poort, zodat de forecast gelijke tred houdt zonder handmatige inspanning en zonder stilzwijgend te verslechteren.

Is dit overkill voor een kleine AI-rekening?

Als uw maandelijkse AI-uitgaven klein en stabiel zijn, is een forecast de moeite niet waard — attributie en een budgetwaarschuwing zijn voldoende. Forecasting bewijst zijn nut wanneer de uitgaven groot, groeiend en wisselvallig genoeg zijn dat het verschil tussen "we overschrijden in week 5" en "we overschrijden in week 11" verandert wat u deze maand doet. Meridian is voorbij die drempel; een startup van tien personen is dat waarschijnlijk nog niet.

Referenties

De tokenmaxxing-trilogie (het attributie-argument waarop dit voortbouwt):

Deel 1 — The Cost-Governance Gap. Deel 2 — The Architecture of Governed AI Usage. Deel 3 — Building the AI Leverage Control Room.

Veldnotities (het whipsaw-effect en het argument van de knop in plaats van de schakelaar):

When AI Cost Control Becomes a Switch — and Why It Should Be a Gateway (de ommekeer bij Meta / Amazon / Uber, met citaten uit primaire bronnen).

TrueFoundry-platform (de productbasis hieronder):

ML-platformarchitectuur — Machine Learning on Kubernetes (training, registry, serving, workflows, split-plane deployment, OpenCost-attributie). AI Gateway — productpagina. Observability en kostenregistratie — observability in de AI Gateway. Platformdocumentatie — docs.truefoundry.com/introduction.

De modellen (externe, open documentatie):

SARIMAX is gedocumenteerd in statsmodels; Prophet is gedocumenteerd op facebook.github.io/prophet.

Geschreven door het TrueFoundry-team. Dit is een educatief artikel; Meridian is een fictief samenvoegsel en de interactieve grafiek is een illustratieve mock-up, geen productoutput of een benchmark. Forecasting is beslissingsondersteuning, geen garantie — valideer elk model aan de hand van uw eigen data en beschouw de intervallen, niet de puntschattingen, als het signaal.

‍

‍

‍

‍