Waarom de rekening explodeerde

Toen het team voor het eerst generatieve AI toevoegde, stuurden ze elke gebruikersaanvraag naar het nieuwste en meest krachtige model. Naarmate het verkeer groeide, stegen de kosten per aanvraag in hetzelfde tempo, en de spreadsheet van de CFO liet zien dat de uitgaven sneller groeiden dan het aantal gebruikers. De gebruikelijke snelle oplossing — "gebruik gewoon een goedkoper model" — werkt niet in productie, omdat verschillende queries verschillende niveaus van redeneren vereisen. De echte hefboom is hoe de aanvraag wordt verzonden, niet welk model er altijd wordt gebruikt.

Het bouwen van een routinglaag die geld bespaart

De engineer behandelde de inference service als elk ander productiecomponent: definieer tiers, stel SLA's in en handhaaf latency-budgetten. De resulterende architectuur heeft vier bewegende delen die samen zorgen voor de reductie van 95%.

Gelaagde routing

Een dunne front-end classificeert elke inkomende aanvraag op basis van moeilijkheidsgraad. Ongeveer 95% van de queries komt terecht in een "goedkope" tier die een bescheiden model gebruikt; alleen de moeilijkste 5% wordt geëscaleerd naar een premium model. De classificatie kan op regels gebaseerd zijn (bijv. lengte, aanwezigheid van domeinspecifieke trefwoorden) of geleerd worden van historische escalatiedata. Door standaard voor de goedkope tier te kiezen, daalden de maandelijkse kosten van de chatbot van $420 naar $28.

Model right-sizing

Het afstemmen van de modelcapaciteit op de complexiteit van de taak levert de grootste besparingen op:

  • Eenvoudige chat – gebruik een lichtgewicht model in plaats van het vlaggenschipmodel (97,5% besparing).
  • Classificatie – vervang een mid-size model door een goedkoper alternatief (98,3% besparing).
  • Samenvatting – vervang het topmodel door een model uit het middensegment (97,2% besparing).

De exacte modelnamen zijn niet cruciaal; het principe is om het meest krachtige model in reserve te houden voor de weinige queries die het echt nodig hebben.

Slimme caching

Elke cache-hit elimineert een netwerkoproep en een API-kostenpost. Een gedistribueerde Redis-cache slaat zowel succesvolle antwoorden als "negatieve" antwoorden op ("Ik weet het niet"). Wanneer dezelfde onbeantwoordbare vraag opnieuw verschijnt, geeft het systeem het gecachte "Ik weet het niet" terug in plaats van het model een tweede keer aan te roepen. Bij duizenden aanvragen bespaart dit alleen al een aanzienlijk deel van de rekening.

Promptcompressie

Lange prompts drijven het tokenverbruik op, wat zich direct vertaalt in kosten. Het team draait een goedkope summarizer aan de clientzijde of in een pre-processing stap, waardoor een context van 2.000 tokens wordt verkleind tot ongeveer 400 tokens voordat deze het dure model bereikt. De reductie in tokens vermenigvuldigt zich over alle aanvragen, wat enorme besparingen oplevert zonder de ervaring van de eindgebruiker te veranderen.

Strategische batching

Batching groepeert meerdere onafhankelijke aanvragen in één enkele API-aanroep. De vuistregel is simpel: als een gebruiker op een antwoord wacht, batch dan niet; als de aanvraag op de achtergrond draait (nachtelijke rapporten, geplande taken), batch dan alles. Alleen al de batch-taken 's nachts verlagen de uitgaven met nog eens 10-20%.

Het monitoren van de optimalisatielus

Je kunt niet verbeteren wat je niet meet. De engineer stelde vier wekelijkse metrieken in:

  1. Kosten per aanvraag, onderverdeeld per tier.
  2. Cache-hit rate voor elk routingpad.
  3. Escalatiesnelheid van goedkope naar premium tiers.
  4. Uitgaven per klantsegment.

Deze cijfers maken drift zichtbaar — bijvoorbeeld kan een stijgende escalatiesnelheid aangeven dat de classificatielogica te agressief is of dat de kwaliteit van het goedkope model is verslechterd. Het team werkt elke week aan drempelwaarden, modeltoewijzingen en cache-policies, waardoor kostenbeheersing een gewoonte wordt in plaats van een crisisrespons.

Kernpunt

Een gedisciplineerde routinglaag die aanvragen classificeert, modellen optimaliseert, agressief cachet, prompts comprimeert en achtergrondwerk batcht, kan de AI-API-uitgaven met wel 95% verlagen terwijl de betrouwbaarheid hoog blijft. Behandel de inference stack als een productie-service: definieer tiers, meet de resultaten en werk wekelijks bij.