Cloudflare AI Gateway håndhæver LLM-budgetter, før requests sendes videre

Af Greg Nowak. Senest opdateret 2026-08-20.

Styring af LLM-omkostninger bliver som regel først drøftet, når fakturaen er kommet. Cloudflare AI Gateway flytter en del af opgaven ind i den løbende request-håndtering: Løsningen kan registrere de estimerede modelomkostninger, evaluere budgetregler og standse trafik med et 429-svar, når en grænse er nået. For virksomheder, der anvender flere AI-funktioner eller udbydere, skaber det et nyttigt kontrolpunkt mellem applikationskoden og modellen.

Funktionen erstatter ikke økonomirapportering, indkøbsregler eller gode produktbeslutninger. Den giver dog driftsteams en praktisk mulighed for at forhindre, at et eksperimentelt workflow, en premiummodel eller en usædvanligt aktiv bruger bruger af et budget uden en fast øvre grænse.

Derfor er forbrugsgrænser ikke det samme som rate limits

En request-grænse besvarer spørgsmålet: »Hvor ofte må denne tjeneste kaldes?« En forbrugsgrænse besvarer spørgsmålet: »Hvor store modelomkostninger må denne trafik samlet medføre?« Forskellen er vigtig, fordi prisen på to requests kan være meget forskellig afhængigt af model, promptlængde og genereret output.

Cloudflare beregner en estimeret omkostning ud fra tokenforbrug og kendte modelpriser. Før en ny request sendes upstream, kontrollerer AI Gateway alle relevante forbrugsregler. Hvis blot én regel allerede har overskredet budgettet, blokeres requesten, indtil det faste eller rullende tidsvindue nulstilles. Forbrugsgrænser fungerer både med Unified Billing og med BYOK-trafik, når Cloudflare kender modellens pris.

Håndhævelsen bygger på det registrerede, akkumulerede forbrug – ikke på en saldo, hvor beløbet reserveres helt præcist. Den gennemførte request medregnes efterfølgende, og Cloudflare beskriver systemet som eventual consistent. En bølge af samtidige requests kan derfor kortvarigt overskride den nominelle grænse.

Den svære del er at placere ansvaret

Nyttige budgetter følger forretningsansvaret. En samlet grænse for hele gatewayen kan beskytte virksomhedens totalbudget, men den kan ikke forklare, om stigningen skyldes automatisering af support, en intern assistent eller en kundevendt funktion.

AI Gateway-regler kan filtrere eller opdele budgetter efter udbyder, model og brugerdefinerede metadata. »Filter« målretter en bestemt værdi, eksempelvis produktionsmiljøet. »Split« opretter en selvstændig budgetpulje for hver værdi, eksempelvis hver bruger eller hvert team. Cloudflare accepterer fem brugerdefinerede metadatafelter pr. request, så vælg et kompakt skema, og anvend det konsekvent. Et praktisk udgangspunkt er team, app, workflow, environment og user_id.

Styringsmål	Foreslået afgrænsning	Typisk reaktion
Beskyt det samlede AI-budget	Én fælles regel for gatewayen	Bloker, og send en alarm
Begræns brugen af premiummodeller	Filtrer efter model	Route til en billigere model
Giv teams separate budgetrammer	Opdel efter `metadata.team`	Bloker, eller kræv godkendelse
Begræns individuelle brugere eller tenants	Opdel efter `metadata.user_id`	Reducer funktionaliteten, sæt i kø, eller bloker

Et budgetdesign med flere lag er som regel mere anvendeligt end én fælles grænse for hele virksomheden.

Test gateway og metadata i samme request-flow

Cloudflares nuværende REST API omfatter /ai/run, OpenAI-kompatible endpoints til chat og Responses samt et Anthropic-kompatibelt Messages-endpoint. Følgende forkortede request vælger en navngivet gateway og tilføjer metadata om ejerskab:

curl -X POST "https://api.cloudflare.com/client/v4/accounts/$CLOUDFLARE_ACCOUNT_ID/ai/v1/chat/completions" \
  -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  -H "cf-aig-gateway-id: production" \
  -H 'cf-aig-metadata: {"team":"support","app":"helpdesk","environment":"prod"}' \
  -H "Content-Type: application/json" \
  -d '{"model":"openai/gpt-4.1","messages":[{"role":"user","content":"Hello"}]}'

Brug et Cloudflare-token med den nødvendige Workers AI-tilladelse, indsæt værdierne for jeres konto og gateway, og afprøv løsningen på ét ikke-kritisk workflow, før I migrerer det hele. Kontrollér, at requests, tokens, fejl, omkostningsestimater og metadata vises under den forventede gateway.

Der er to modeller for credentials, som I bør overveje. Med Unified Billing kan REST API'et kalde understøttede tredjepartsmodeller ved hjælp af Cloudflares fakturering og autentificering. BYOK gemmer udbydernøgler i Cloudflare Secrets Store, så applikationerne ikke skal sende udbyderens credentials med hver request. Autentificering mod gatewayen er stadig påkrævet. BYOK understøtter desuden aliases til flere udbydernøgler, men Unified Billing-endpoints anvender kun aliasset default.

Beslut, hvad der skal ske, når pengene slipper op

Blokering er velegnet til batchjobs, eksperimenter og valgfrie interne værktøjer. I en kunderejse er det ofte for unuanceret. Cloudflare Dynamic Routing kan evaluere betingelser, anvende rate- eller budgetnoder og skifte til en fallback-model. Et fornuftigt fallback kan være at anvende en billigere model, udelade et valgfrit berigelsestrin eller vise applikationens oplevelse uden AI.

Den nuværende dokumentation indeholder et vigtigt implementeringsforbehold: Dynamiske routes kaldes via Cloudflares OpenAI-kompatible /compat/chat/completions-sti og er endnu ikke tilgængelige via de nyere REST API-endpoints. Kompatibilitets-endpointet er deprecated til almindelige chat completions med en enkelt model, men er fortsat nødvendigt til dynamisk routing. Undersøg denne afgrænsning, før I planlægger en fuldstændig migrering af endpoints.

Brug tallene som styringsværktøj – ikke som regnskab

Cloudflare oplyser, at virksomhedens omkostningstal er best-effort-estimater. Udbydere kan ændre priserne, forhandlede priser kan afvige, og visse endpoints kan ikke levere omkostningsmålinger, medmindre svaret indeholder data om model og tokens. Brug udbyderens dashboard eller faktura som den autoritative kilde til faktureringen.

Der gælder desuden et maksimum på 20 forbrugsregler pr. gateway. Undgå at bruge denne kapacitet på snesevis af undtagelser. Begynd med en samlet grænse, en regel for premiummodeller og et mindre antal budgetter baseret på ejerskab. Gennemgå regelmæssigt blokerede requests, fejl, tokenforbrug og cacheeffektivitet, og juster derefter grænserne ud fra den observerede trafik frem for gæt.

En praktisk rækkefølge for udrulningen

Kortlæg modelkald efter applikation, ejer, udbyder, model og miljø.
Vælg Unified Billing, BYOK eller en velovervejet kombination.
Route ét repræsentativt workflow gennem en gateway uden for produktion.
Indfør en metadataaftale med højst fem felter, og verificer den i loggene.
Observer det normale forbrug, før I fastsætter de første faste eller rullende grænser.
Test 429-forløbet og eventuelle fallbacks til billigere modeller.
Dokumentér, hvem der må ændre budgetter, routes og udbydernøgler.

Resultatet bør være mere end endnu et dashboard. Det bør være en driftsmodel, hvor produktejerne forstår deres budgetramme, udviklerne kender fejlforløbet, og økonomiafdelingen kan henføre forbruget til et meningsfuldt workload.

Hvis jeres modelkald er spredt på tværs af scripts, produkter og integrationer udviklet af bureauer, kan Greg hjælpe med at kortlægge trafikken, udforme metadataaftalen og implementere en kontrolleret udrulning af AI Gateway. Tal med Greg om opsætningen af jeres AI-drift.

Relateret indhold på GrN.dk

Har I brug for hjælp til denne type arbejde?

Tal om jeres udrulning af AI Gateway Kontakt Greg.

Kilder

Sidst ændret

2026-08-22