Eerst de conclusie: het geld dat een klantenservice-chatbot verbrandt, ligt in tachtig procent van de gevallen niet aan een te hoge modelprijs, maar aan de manier waarop er wordt aangeroepen. Een interne after-sales Q&A-chatbot van ons met een paar duizend dagelijkse actieve gebruikers schoot in de eerste maand na livegang direct naar drie keer het budget. Na onderzoek bleek de modelprijs geen cent veranderd — het waren allemaal verborgen kosten in de aanroepstructuur. Dit artikel beschrijft het retrospectieve proces; wie bezig is met kostenoptimalisatie van grote-model-API's kan het naast de eigen factuur leggen en punt voor punt nalopen.
Hoe een afwijkende factuur eruitziet
Het kenmerk van de afwijking is niet "een hoog totaalbedrag", maar "een vreemde structuur". We trokken de dagelijkse aanroepdetails erbij en zagen drie dingen die niet klopten: op de dagen met het hoogste aanroepvolume liep het gemiddelde aantal tokens per verzoek op; het aandeel hertry's lag tegen de twintig procent; en voor dezelfde gebruikersvraag varieerde het tokenaantal van een paar honderd tot tienduizenden — een enorme variantie. Die drie samen wijzen er vrijwel direct op dat het probleem niet aan de modelkant zit, maar in onze eigen aanroepketen.
Vier verborgen kostenposten, de een nog onopvallender dan de ander
Ten eerste: het topmodel deed grof werk.We kozen in het begin voor het gemak en lieten alle verzoeken uniform via het topmodel lopen. Maar in klantenservice-scenario's is meer dan zeventig procent intentieherkenning en reacties met vaste teksten zoals "waar is mijn bestelling" en "hoe retourneer ik" — dat soort taken kan een klein model prima aan, met een kostenscheelt van een orde van grootte. Het topmodel "hoe laat zijn jullie open" laten beantwoorden is als een vrachtwagen inzetten voor maaltijdbezorging.
Ten tweede: context die ongeremd opzwelt.In meerbeurtsgesprekken stopten we de volledige geschiedenis terug. Als een gebruiker bij de tiende beurt is, neemt alleen de geschiedenis al het grootste deel van de tokens in beslag. Vervelender nog: veel geschiedenis heeft niets met de huidige vraag te maken en loopt puur voor spek en bonen mee. Context is niet "hoe langer hoe slimmer" — voorbij een bepaalde lengte is de nauwkeurigheidswinst beperkt, terwijl de kosten lineair stijgen.
Ten derde: een hertry-storm.We hadden een simpele hertry bij falen ingesteld, maar zonder backoff en circuit breaker. Bij een incidentele upstream-timeout werd dezelfde batch verzoeken steeds opnieuw afgevuurd: één keer falen, één keer hertryen; hertryen faalt weer, weer hertryen. Die aanroepen op de factuur waren allemaal weggegooid geld, en de gebruiker zag nog steeds een foutmelding.
Ten vierde: dubbele facturering van streaming en non-streaming.Deze wordt het makkelijkst over het hoofd gezien. Sommige van onze ketens riepen non-streaming aan om het volledige resultaat voor nabewerking te krijgen; de frontend wilde tegelijk een typemachine-effect en riep streaming nog eens aan. Dezelfde vraag, twee keer betalen. Pas toen we alles uniformeerden naar streaming ontvangen en lokaal samenstellen, verdween deze dubbele kostenpost.
Hoe gelaagde routering in de praktijk werkt
Het idee is niet ingewikkeld: splitsen op taakmoeilijkheid. Intentieherkenning, slot-extractie en vaste teksten gaan naar een lichtgewicht model; alleen complexe gesprekken die echt redeneren, meerstapsbeslissingen en emotionele geruststelling vereisen, gaan naar het topmodel. Daartussen komt een modelgateway die de beoordeling doet: een verzoek komt binnen, gaat eerst door een classifier, krijgt een taaklabel en pas dan wordt bepaald naar welk model het gerouteerd wordt.
Wij gebruiken de logica van automatische modelselectie per taak en hebben een vergelijkingsronde gedraaid op de multi-modelroutering van SiCore TokenWorks. Nadat eenvoudige taken naar het lichtgewicht model waren verplaatst, gingen de totale kosten duidelijk omlaag en was de respons ook sneller. De sleutel hier is niet "welk model gebruiken", maar dat de mappingtabel "welke taak krijgt welk model" continu bijgesteld moet worden. In de beginfase configureerden we op ervaring; na twee weken hebben we op basis van de werkelijke hitrate opnieuw gekalibreerd, wat veel beter werkte dan op gevoel configureren. Het voordeel van uniforme multi-model-toegang kwam hier ook naar voren: een routeringsstrategie wijzigen vereist geen aanpassing van bedrijfscode — een aanpassing in de gatewaylaag volstaat.
Factuurvergelijking voor en na optimalisatie
Geen concrete cijfers, maar verhoudingen. Het totale aanroepvolume bleef gelijk, want het aantal gebruikers bleef gelijk. De totale kosten daalden met ongeveer zestig procent, waarbij het aandeel topmodel-aanroepen van bijna honderd procent naar ongeveer dertig procent ging; de rest werd afgeleid naar lichtgewicht modellen. Hertry-gerelateerde aanroepen gingen van bijna twintig procent naar een enkelcijferig percentage. Het gemiddelde aantal tokens per verzoek daalde met ongeveer veertig procent, vooral door context-trimming. De dubbele facturering van streaming ging direct naar nul. Alles bij elkaar: van drie keer over budget terug naar binnen budget, met nog ruimte over.
Hoe monitoring en alerts in te richten
Het bespaarde geld moet worden vastgehouden — dat lukt via monitoring, niet via zelfdiscipline. We hebben vier alerts ingesteld: een alert wanneer het aantal tokens per verzoek een drempel overschrijdt, tegen context die uit de hand loopt; een alert wanneer de hertry-rate een ingestelde verhouding overschrijdt, tegen hertry-stormen; een alert wanneer het aandeel topmodel-aanroepen abnormaal stijgt, wat betekent dat de routering mogelijk faalt; en een alert wanneer de dagelijkse kostenstijging ten opzichte van de vorige periode een drempel overschrijdt. Deze vier hoeven niet ingewikkeld te zijn — per dag aggregeren en bij overschrijding alarmeren is voldoende. In een token-gebaseerd factureringsmodel accumuleren kosten realtime; wachten tot je aan het eind van de maand de factuur bekijkt om te optimaliseren betekent dat het geld al is uitgegeven.
Samengevat in één zin: de grootste kostenpost van een klantenservice-chatbot zit in de aanroepstructuur, niet in de modelprijs. Doe deze vier dingen goed — gelaagde routering, context-trimming, hertry-beheersing en streaming-uniformiteit — en de factuur gaat vanzelf omlaag. Als uitbreiding: als je scenario ook RAG-retrieval bevat, is het aantal opgehaalde resultaten uit de vectorstore zeker de moeite waard om volgens dezelfde gedachte nog eens na te lopen.