Cloudflare AI Gateway legger til cache-token-priser til tilpasset kostnadsregnskap

Cloudflare har lagt til cache-lese og cache-write token-hastigheter til AI Gateways egendefinerte kostnadsregnskap, en liten endringsloggpost med store faktureringskonsekvenser for team som videreselger, ruter eller avstemmer modellbruk på tvers av leverandører.

Oppdateringen 9. september betyr at utviklere nå kan sende inn per_cache_cache_token_token_code> og verdier i cf-aig-custom-cost-overskriften. Når en av cache-spesifikke rater er tilstede, sier Cloudflare at AI Gateway aktiverer cache-token-priser og tar hensyn til leverandørforskjeller, slik at den samme cachebruken ikke telles to ganger.

Det høres smalt ut. Det er det ikke. Bufferpriser har blitt en av de vanskeligste delene av unified AI API-fakturering, spesielt ettersom leverandører bruker forskjellige navn, enheter og faktureringsregler for gjenbrukt kontekst. Det kan være enkelt å behandle hvert bufrede token som et normalt inputtoken, men det kan være feil nok til å slette forhandlermarginer eller villede kunder om hvilke arbeidsbelastninger som faktisk er dyre.

Hva endret

AI Gateway tillot allerede tilpassede kostnadsdata å knyttes til forespørsler, noe som ga teamene en måte å representere forhandlede priser eller interne prisbøker kun på i stedet for å tilby repris. Den nye endringen utvider denne mekanismen til cache-spesifikke token-kategorier.

I praksis kan en gateway-operatør nå fortelle Cloudflare ikke bare hva et input- eller output-token koster, men hva en cache-lesing eller cache-skriving koster. Denne forskjellen er viktig fordi leverandørene i økende grad priser hurtigbufring som sitt eget økonomiske lag. En cache-skriving kan koste mer enn en cache-lesing. En cache-lesing kan være dramatisk billigere enn fersk input. Noen leverandører kan eksponere hurtigbufferoppretting og cachehenting annerledes i bruksposter.

Cloudflares merknad om at den håndterer leverandørforskjeller for å unngå dobbelttelling er også viktig. Bufferfelt er ikke alltid rent atskilt fra totaler for input-token. Hvis et faktureringssystem naivt legger til buffertokens på toppen av leverandørrapportert inndatabruk, kan det overbelaste kunder eller øke interne kostnader. Hvis den ignorerer hurtigbufferfelt, kan den undervurdere kostnadene for programmer med lang kontekst som ofte oppretter hurtigbufferoppføringer.

Hvorfor cacheregnskap nå er viktig

Spørrebufring pleide å være en optimaliseringsdetalj. For mange produksjonsarbeidsbelastninger er det nå en del av prisarkitekturen.

Lange systemmeldinger, gjenfinningsutvidet kontekst, kodingsagentlagre, juridiske dokumentpakker og støttekunnskapsbaser drar nytte av gjenbruk av kontekst. Jo mer gjentatt kontekst et system sender, jo mer cache-prising endrer den reelle enhetsøkonomien. To forespørsler med lignende tokenantall kan ha svært forskjellige kostnader hvis en skriver en hurtigbufferoppføring og en annen leser fra den.

Det gjør cachesynlighet til et økonomisk problem, ikke bare et teknisk problem. Et team som kjører interne agenter kan trenge å vite om en ny arbeidsflyt er dyr fordi den genererer for mange nye meldinger, går glipp av hurtigbufferen eller skriver store hurtigbufferblokker for ofte. En forhandler må kanskje vise kundene hvorfor en applikasjons fakturerte bruk er lavere enn forventet, selv om den tilsynelatende forespørselsstørrelsen er stor. En gatewayleverandør kan trenge å bevare hurtigbufferfelt i logger, analyser og reskontroposter slik at månedsavstemming matcher leverandørfakturaer.

Det er også her AI API-kostnadsanalyse blir mer krevende. Samlet forespørselskostnad er ikke lenger nok. Teamene må se input, output, cache-skriving og cache-leseatferd separat, og deretter koble disse kategoriene til API-nøkler, kunder, modeller og ruter.

Hvem er berørt

Den umiddelbare målgruppen er Cloudflare AI Gateway-brukere som er avhengige av egendefinerte kostnader i stedet for standard offentlige priser. Dette inkluderer bedrifter med forhandlede modellpriser, plattformer som markerer leverandørbruk for kunder, og team som bruker Cloudflare som et delt kontrollplan på tvers av flere modellleverandører.

Forhandlere er spesielt utsatt. Hvis en forhandler belaster kunder ved å bruke en forenklet token-modell mens de betaler leverandører under cache-bevisste priser, kan forskjellen stille seg opp. Underlading av cache-skriving eller overlading av cache-lesninger vises kanskje ikke i én enkelt forespørsel, men det kan ha betydning på tvers av agentsesjoner, batchbehandling eller høyvolums hentingsarbeidsmengder.

Utviklere som bygger OpenAI-kompatible gateway-lag påvirkes selv når de ikke bruker Cloudflare direkte. Endringen reflekterer en bredere retning i markedet: leverandørens faktureringsflater blir mer detaljerte, mens kundene fortsatt forventer en ren faktura og forutsigbare bruksrapporter.Produkter som Model Gate må behandle buffertokenfelter som førsteklasses reskontrodata hvis de ønsker nøyaktig kundebasert rapportering, bruksgrenser og marginanalyse på tvers av flere leverandører.

Praktiske konsekvenser

Gateway-team bør gjennomgå hvordan forespørselsloggene, kostnadskalkulatorene og fakturaene deres representerer bufferaktivitet. Hvis cache-lesing og -skriving er flatet ut til vanlige prompt-tokens, kan analyser se enklere ut enn den underliggende regningen. Hvis leverandørbruksposter inneholder bufferfelt som slettes under inntak, vil senere avstemming være vanskelig.

Prismotorer må også støtte mer enn én pris per retning. Den gamle input-versus-output-delingen er ikke lenger nok for avansert modellregnskap. En troverdig modellbok trenger nå plass til nye input-tokens, output-tokens, cache-skriving, cache-lesing og muligens leverandørspesifikke varianter av disse kategoriene.

Kundevendte dashboards bør avsløre disse forskjellene nøye. De fleste brukere ønsker ikke å lese rå leverandørtelemetri, men de trenger å forstå hvorfor kostnadene endres når en applikasjon begynner å gjenbruke kontekst mer effektivt. Det beste grensesnittet kan være en kostnadsoversikt som viser hurtigbufferbesparelser og kostnader for oppretting av hurtigbuffer uten å tvinge kundene til å lære seg hver leverandørs terminologi.

Det er også operasjonelle implikasjoner for varsler og grenser. En kundebudsjettgrense basert kun på totalt antall tokens kan ikke fange opp en arbeidsbelastning som skriver dyre hurtigbufferoppføringer. Et marginvarsel kun basert på antall forespørseler kan gå glipp av en leverandørprismismatch. For team som selger tilgang gjennom per-kunde-nøkler, bør cache-bevisst regnskap knyttes tilbake til de samme kunde-, prosjekt- eller applikasjonsidentifikatorene som brukes for forbrukskontroller.

Hva forblir åpent

Endreloggen etablerer støtte for cache-lesing og cache-write tilpassede priser, men den løser ikke alle implementeringsspørsmål for gateway-operatører. Teamene må fortsatt teste hvordan deres spesifikke leverandører rapporterer cachebruk, hvordan Cloudflares beregnede kostnader vises i logger og eksporter, og hvordan eksisterende fakturaer skal sammenlignes med de nye tilpassede kostnadsfeltene.

Den større retningen er imidlertid klar. AI gateway-fakturering beveger seg fra en enkel token-måler til en detaljert bruksreskontro. Cache-prising er nå en del av denne hovedboken. Team som bevarer detaljene vil ha renere avstemming og bedre kundeanalyse. Team som kollapser det, vil kanskje ikke legge merke til problemet før leverandørregningen og kundefakturaen deres slutter å fortelle den samme historien.