Backend- en algoritme-collega's, jullie zijn dit contra-intuïtieve fenomeen waarschijnlijk ook tegengekomen: het online verkeer groeit nauwelijks, maar aan het eind van de maand is de factuur in één klap verdubbeld. Het team dat ik leidde bouwde twee jaar geleden een slim klantenservice-systeem voor een online-onderwijsbedrijf. Twee maanden na de lancering steeg het aantal aanroepen slechts van 120.000 naar 168.000 per dag, een stijging van 40%, maar de maandelijkse API-factuur schoot van 8000 yuan naar 23000 yuan, een stijging van 187%. Het geldverschil daartussen kwam niet door een prijsstijging per eenheid, maar door vier verborgen kostenblackholes die stilletjes het budget opaten.
Laten we het probleem eerst helder definiëren: kostenontsporing bij grote-model-API's is in essentie een disbalans tussen het aantal aanroepen en de effectieve output. Je betaalt voor tokens, maar de tokens die daadwerkelijk bedrijfswaarde opleveren zijn misschien slechts dertig procent. Laten we het laag voor laag ontleden.
Blackhole één: herhaalstormen, nutteloze aanroepen verdubbelen direct
Onze eerste aanroepcode was heel simpel: bij netwerkschommelingen of time-outs vingen we de fout op en riepen we gewoon opnieuw aan, zonder backoff, zonder idempotentie. In de tweede week na de lancering kregen we te maken met een upstream rate limit: de QPS werd plotseling van 20 naar 5 gedrukt, en de client herhaalde hetzelfde gebruikersverzoek binnen 3 seconden 7 keer. Die ene nacht liep het aandeel nutteloze aanroepen op tot 41%. Dat deel van de factuur leverde geen cent bedrijfswaarde op.
De oplossing bestaat uit twee lagen. Exponentiële backoff: bij de eerste fout 500ms wachten, bij de tweede 1s, bij de derde 2s, maximaal 3 keer opnieuw proberen, en daarna degraderen naar een fallback-antwoord. Idempotentiesleutel: elk verzoek krijgt een request_id, zowel server als client doen deduplicatie, en dezelfde id mag binnen 60 seconden slechts één echte aanroep doen. Na de aanpassing daalde het aandeel nutteloze aanroepen door herhalingen van 41% naar minder dan 6%. Dit onderdeel bespaart ongeveer 4200 yuan per maand.
Blackhole twee: lange context niet ingekort, gespreksgeschiedenis herhaaldelijk opnieuw meegestuurd
Gesprekken in klantenservice-scenario's lopen vaak op tot meer dan tien rondes. In het begin deden we het voor het gemak: bij elke aanroep plakten we de volledige geschiedenis erin. Het gemiddelde aantal input-tokens per gespreksronde steeg van 800 in ronde 3 naar 3400 in ronde 12. Erger nog: wanneer de gebruiker vroeg "wat was dat terugbetalingsbeleid ook alweer", had het model eigenlijk alleen de laatste 3 rondes plus een samenvatting nodig, maar wij stopten alle 12 rondes erin.
Dit losten we op met een schuivend venster plus samenvattingscompressie: de laatste 4 rondes bleven als originele tekst behouden, eerdere gesprekken werden met één lichte modelaanroep gecomprimeerd tot een samenvatting van maximaal 150 woorden, en die samenvatting werd als onderdeel van de system-context meegestuurd. Zo daalde het aantal input-tokens in ronde 12 van 3400 naar ongeveer 1100, een daling van 67%. Er zit hier een valkuil: de samenvatting zelf kost ook tokens, dus de drempel voor het activeren van de samenvatting moet goed staan. Uit onze metingen bleek dat compressie pas na meer dan 6 rondes te activeren de laagste totale kosten oplevert.
Blackhole drie: het topmodel deed het werk van het lichte model
Dit is het meest verborgen punt. Alle verzoeken in het systeem gingen naar hetzelfde topmodel, inclusief beleefdheidsfrasen zoals "hallo", "ja hoor" en "even geduld". Ik trok één keer de aanroeplogs erbij en categoriseerde ze, en ontdekte dat 62% van de verzoeken intentieherkenning en eenvoudige vraag-en-antwoord betrof, waarvoor helemaal geen topmodel nodig was. Met het topmodel draaien kostte 8 tot 12 keer zoveel per aanroep als met het lichte model.
De oplossing is routering in lagen per taak. We voegden een laag regels toe in de model-gateway: intentieclassificatie, beleefdheidsfrasen en FAQ-treffers gaan naar het lichte model; alleen complexe taken zoals terugbetalingsberekeningen, cursusaanbevelingen en escalatie van klachten worden naar het topmodel gerouteerd. Hier gebruikten we in ons project token8341 voor uniforme toegang tot meerdere modellen: met één Key kun je de toonaangevende modellen zoals GPT-4o, Claude, DeepSeek en Qwen aanroepen, automatisch het optimale model per taak kiezen, zonder zelf meerdere SDK's en authenticatie te onderhouden. Na de gelaagde routering daalde het aandeel aanroepen naar het topmodel van 100% naar 34%, en de totale kosten daalden met 52%.
Trouwens, over de modelkeuze voor grote-model-API's: directe verbinding met de officiële aanbieder en aggregatieplatforms verschillen inderdaad in kostenstructuur. Bij directe officiële verbinding is de eenheidsprijs transparant, maar volumekortingen zijn moeilijk te onderhandelen; aggregatieplatforms werken met bulkinkoop plus groene-energie-kostenverlaging, waardoor de kosten per gebruik gunstiger uitvallen. We hebben de maandelijkse uitgaven voor dezelfde batch taken vergeleken: de aggregatieoplossing lag een stuk lager dan directe officiële inkoop. De exacte cijfers kan ik vanwege commerciële gevoeligheid niet uiteenzetten.
Blackhole vier: dubbele facturering na onderbreking van streaming output
Streaming output (SSE) is heel gebruikelijk in klantenservice-scenario's; gebruikers vinden het fijn om tekst teken voor teken te zien verschijnen. Maar zodra het netwerk wegvalt en de client opnieuw verbindt, genereert de server de al geproduceerde inhoud opnieuw als er geen hervatting vanaf het breekpunt is ingebouwd. We hebben gemeten dat de onderbrekingsgraad van streaming ongeveer 3,7% is, en dat bij elke onderbreking gemiddeld 1200 tokens opnieuw worden gegenereerd. Op maandbasis nam deze dubbele facturering 9% van de factuur voor zijn rekening.
De oplossing is compensatie bij streamonderbreking: de server registreert per streaming-verzoek de offset van de al gegenereerde tokens; wanneer de client opnieuw verbindt, stuurt hij de offset mee, en de server gaat verder vanaf het breekpunt in plaats van vanaf het begin. In combinatie met de idempotentiesleutel gaat dubbele facturering direct naar nul. Dit onderdeel bespaart ongeveer 2000 yuan per maand.
Checklist voor kostenmonitoring
Na deze vier blackholes te hebben doorgelicht, heb ik een lijst opgesteld met indicatoren om dagelijks in de gaten te houden; je kunt ze naast je eigen systeem leggen:
1.Aandeel nutteloze aanroepen: boven de 10% moet je herhalingen en idempotentie onderzoeken;
2.Verhouding tussen gemiddelde input-tokens en gemiddelde output-tokens: boven 3:1 in klantenservice-scenario's betekent dat de context niet is ingekort;
3.Aandeel aanroepen naar het topmodel: boven de 40% moet je gelaagde routering overwegen;
4.Onderbrekingsgraad van streaming: boven de 2% moet je hervatting vanaf het breekpunt implementeren;
5.Kosten per effectief gesprek: berekend volgens bedrijfsmaatstaven, niet volgens API-maatstaven;
6.Trefferpercentage van taakroutering in de model-gateway: onder de 60% betekent dat de regels niet goed zijn afgesteld.
Kostenontsporing is nooit een eenheidsprijsprobleem, het is een engineeringprobleem. Dicht deze vier blackholes en bij hetzelfde verkeersvolume komt de factuur weer in een redelijk bereik terecht.
Auteur: Zhou Mingzhe
Publicatiedatum: 23 oktober 2026