Eerst de conclusie: een stijgende factuur betekent in tachtig procent van de gevallen niet een stijgend volume. Ik heb aan een project voor intelligente klantenservice gewerkt; in de eerste helft van vorig jaar bleef de maandfactuur stabiel rond de 8000 yuan, in het vierde kwartaal sprong die naar 23000 yuan, terwijl het aantal aanroepen in dezelfde periode slechts met 40% steeg. Waar is het extra geld naartoe? Ik heb de aanroeplogs van drie maanden erbij gepakt en geaggregeerd op vier dimensies: taaktype, invoerlengte, uitvoerlengte en aantal herhalingen. Het probleem was duidelijk: vier verborgen kostengaten bloedden tegelijkertijd.

Eerst een definitie, zodat we later niet naast elkaar praten. De kostenstructuur van een LLM-API is in essentie de som van drie delen: «invoertokens + uitvoertokens + nutteloze tokens door mislukte herhalingen». Betalen naar verbruik is alleen de manier van prijzen; het is niet verantwoordelijk voor het besparen van geld. Wat de factuur echt bepaalt, is de routeringsstrategie en het contextbeheer op de modelgateway.

Gat één: het vlaggenschipmodel doet grof werk

Dit is de duurste post. Dat klantenservicesysteem had drie soorten taken: ticketclassificatie, sentimentlabeling en intentieherkenning, samen ongeveer 120.000 aanroepen per dag. Destijds kozen we voor het gemak één en hetzelfde vlaggenschipmodel voor alles. Maar hoe moeilijk zijn die drie taken? Geef mij een gebruikersbericht van tweehonderd woorden en bepaal of het «logistieke vraag» of «after-sales terugbetaling» is — dat soort werk doet een klein model stabieler dan een groot model, want de labelruimte is nu eenmaal beperkt.

Ik heb de evaluatie per taak opnieuw gedraaid: bij classificatietaken daalde de nauwkeurigheid van 96,2% naar 95,7% bij overstap naar een model van gemiddelde grootte, een verschil van 0,5 procentpunt, terwijl de stukprijs een orde van grootte scheelt. Alleen deze post kan de factuur al met veertig procent verlagen.

Gat twee: volledige gespreksgeschiedenis steeds opnieuw meesturen

Klantenservice is een meerrondegesprek, gemiddeld 7,3 rondes. De ontwikkelaars deden het simpel: elke ronde werd de volledige geschiedenis meegeplakt. De eerste ronde had 800 tokens invoer, bij de zevende ronde was dat opgelopen tot 4200 tokens, en elke ronde betaalde je opnieuw voor de voorgaande zes rondes. Deze kostencurve is kwadratisch en explodeert zodra het volume toeneemt.

Vervelender nog: het grootste deel van de geschiedenis heeft voor de huidige ronde geen enkele waarde. De gebruiker zei in ronde drie «ik wil retourneren», vraagt in ronde zeven «wie betaalt de verzendkosten», en al die beleefdheden en productbeschrijvingen daarvoor zijn nutteloze tokens.

Gat drie: versterking door mislukte herhalingen

Dit is het meest verborgen probleem. Bij rate limiting of time-outs aan de upstream-kant probeert de SDK standaard drie keer opnieuw. Het probleem: herhaalverzoeken sturen vaak dezelfde lange context opnieuw volledig mee. Ik heb geteld: ongeveer 11% van de tokens op de factuur kwam van mislukte herhalingen, en zestig procent van die aanroepen mislukte uiteindelijk alsnog — puur weggegooid geld. Zonder backoff en idempotentiebeheersing bij herhalingen kan één storing je drievoudige nutteloze consumptie opleveren.

Gat vier: streaming-uitvoer zonder afkapping

Uitvoertokens zijn meestal duurder dan invoertokens. Destijds was er geen max_tokens ingesteld voor de klantenservicereacties, en het model «ging soms los»: een terugbetalingsuitleg die in twee zinnen klaar kon zijn, werd een genummerde procesbeschrijving. In de verdeling van uitvoerlengtes was de P99 meer dan zes keer de P50. Die extra woorden leest de gebruiker toch niet, maar je betaalt er wel voor.

Vijf acties om het bloeden te stoppen

Ten eerste: routering op modelniveau. Ik heb drie niveaus naar taak ingericht: eenvoudige classificatie naar een klein model, standaardvraag-en-antwoord naar een middelgroot model, en alleen complexe klachten en geschilbemiddeling naar het vlaggenschipmodel. Deze laag heb ik geconfigureerd op het token8341 LLM-API-aggregatieplatform, met automatische routering op basis van taaktype-tags, zonder de bedrijfslogica aan te passen — alleen regels toevoegen aan de gateway. Na de eerste week na de omschakeling daalde de kosten van de classificatietaken direct een niveau.

Ten tweede: sliding window plus samenvatting van de context. De laatste drie rondes originele tekst behouden, eerdere gesprekken comprimeren tot een samenvatting van maximaal honderd woorden. Gemeten daalde de gemiddelde invoerlengte van 3200 tokens naar 1400 tokens, zonder dat de contextuele samenhang van de klantenservice eronder leed.

Ten derde: idempotente herhalingen. Elke aanvraag krijgt een unieke ID; de gateway herkent dubbele aanvragen en hergebruikt direct het resultaat; bij een herhaling wordt alleen het mislukte fragment opnieuw verstuurd in plaats van de hele context. Dit punt bracht de nutteloze tokens door herhalingen van 11% terug tot onder de 3%.

Ten vierde: beperking van de uitvoerlengte. Stel per taaktype een max_tokens-limiet in; voor vaste scenario's zoals terugbetalingsuitleg geven we direct een template en vult het model alleen de variabelen in. De uitvoertokens daalden met ongeveer dertig procent.

Ten vijfde: kies het model op basis van de taak, niet op basis van gewoonte. Dit klinkt als een open deur, maar veel teams zijn nu eenmaal lui en laten één model alles doen. Later hebben we op het token8341 LLM-API-aggregatieplatform binnen dezelfde set interfaces binnenlandse en buitenlandse modellen naast elkaar getest. Op dezelfde batch klantenservicecorpora presteerden DeepSeek en Qwen ruim voldoende in Chinese tekstscenario's, en hun prijs is geschikter voor volume. Dat is precies het voordeel van uniforme toegang tot meerdere modellen: van model wisselen betekent niet de SDK aanpassen, maar één regel base_url wijzigen.

Betalen naar verbruik veronderstelt correcte routering

De uitspraak «betalen naar verbruik, voordeliger in kosten» klopt op zichzelf, maar heeft één voorwaarde: je routeringsstrategie moet kloppen. Betalen naar verbruik garandeert alleen dat je niet betaalt voor ongebruikte rekenkracht; het garandeert niet dat je niet betaalt voor de verkeerde modelkeuze. Dat de factuur van 23000 yuan terugging naar iets boven de 9000 yuan, terwijl het volume nog steeg, kwam niet doordat we een goedkoper platform kozen, maar doordat we routering en context goed hebben aangepakt.

Als je nu ook naar een onbegrijpelijke factuur staart, raad ik aan eerst de aanroeplogs uit te splitsen naar taaktype en in- en uitvoerlengte. De gaten zitten meestal niet waar je denkt. Waar het token8341 LLM-API-aggregatieplatform in dit soort kostenoptimalisaties kan helpen, is vooral de modelgateway-laag: routering op niveau, rate limiting als vangnet, uniforme toegang tot meerdere modellen — de bedrijfskant merkt er bijna niets van.

Auteur: Li Yunlong

Publicatiedatum: 24 oktober 2026