Kako nametnuti ograničenja potrošnje za LLM na API pristupniku

Ograničenja potrošnje pružatelja usluga korisna su zaštita, ali rijetko se podudaraju s načinom na koji tvrtka zapravo posjeduje potrošnju LLM-a. Financije žele ograničenja prema timu, aplikaciji, okruženju, klijentu, partneru ili tijeku rada. Platformski timovi trebaju ta ograničenja nametnuti prije nego što se zahtjev proširi na OpenAI, Anthropic, Gemini, Azure OpenAI ili drugog davatelja modela. Prava kontrolna točka obično je API pristupnik, gdje se svaki zahtjev može pripisati, procijeniti, prihvatiti, smanjiti, blokirati i uskladiti.

Ovaj vodič opisuje implementaciju sloja pristupnika za AI API kontrolu troškova. Fokusira se na provedbu proračuna u stvarnom vremenu, a ne na retrospektivna izvješća o storniranju ili široke programe optimizacije troškova.

Što kontrole potrošnje davatelja mogu, a što ne mogu

Činjenica: Veliki davatelji izlažu korisne kontrole, ali rade u granicama koje je definirao davatelj. OpenAI dokumentira mjesečna API ograničenja potrošnje na razini organizacije i projekta, zajedno s različitim pogreškama za ograničenja organizacije, ograničenja projekta, dodijeljena ograničenja upotrebe i iscrpljene unaprijed plaćene kredite. Anthropic dokumentira potrošnju radnog prostora i ograničenja stope, a također pruža API-je za dohvaćanje konfiguriranih ograničenja organizacije i radnog prostora za interno upozoravanje. Google Sama upozorenja o proračunu u oblaku ne ograničavaju automatski potrošnju, dok Google također dokumentiraju proračune ograničene potrošnje za prihvatljive usluge kao što su Gemini API i Agent Platform. Azure OpenAI kvota dodjeljuje se po pretplati, regiji, modelu i vrsti implementacije u jedinicama tokena po minuti, a izračuni ograničenja stope mogu uključivati brzu procjenu i maksimalne tokene, ne samo konačne naplaćene tokene.

Preporuka: Ostavite ograničenje potrošnje izvorno davatelja uključenim kao zaštitnu ogradu u krajnjoj nuždi. Nemojte ih tretirati kao glavni mehanizam za provedbu internih proračuna. Pregrubi su za većinu modela vlasništva i obično se aktiviraju nakon što je put zahtjeva već napustio vašu kontrolu.

Predviđanje: Kontrole pružatelja usluga nastavit će se poboljšavati, ali poduzeća će i dalje trebati politiku na razini pristupnika jer se interno vlasništvo nad troškovima mijenja brže od strukture računa pružatelja usluga.

Najprije definirajte model proračunske politike

Počnite s pravilima, a ne s kodom. Gateway ne može nametnuti proračun koji nije precizno opisan.

Zapis o praktičnim pravilima trebao bi uključivati:

• Vlasnik proračuna: tim, odjel, korisnik, partner, aplikacija ili vlasnik tijeka rada.
• Opseg: dimenzije koje odgovaraju zahtjevima, kao što su team_id, app_id, environment, customer_id i workflow_id.
• Interval ponovnog postavljanja: dnevno, tjedno, mjesečno, ugovorno razdoblje ili prilagođeni prozor.
• Mekani prag: točka u kojoj gateway upozorava, vraća na nižu verziju, smanjuje duljinu izlaza ili usmjerava na jeftinije modele.
• Tvrdi prag: točka gdje je nekritičan promet blokiran.
• Dopušteni modeli: modeli koje ovaj opseg može koristiti.
• Rezervni modeli: jeftiniji modeli ili modeli nižeg kapaciteta dopušteni nakon mekog praga.
• Kritičnost: je li radno opterećenje kritično za proizvodnju, okrenuto korisniku, interno, serijski ili eksperimentalno.
• Hitno nadjačavanje: tko može produžiti ograničenje, koliko dugo i s kojim tragom revizije.
• Ciljevi obavijesti: Slack kanal, grupa e-pošte, usluga incidenta, webhook ili financijski red.

Primjer pravila:

{
  "budget_id": "budget_support_prod_monthly",
  "owner_type": "team",
  "owner_id": "customer_support",
  "scope": {
    "team_id": "customer_support",
    "app_id": "support_assistant",
    "environment": "production"
  },
  "currency": "USD",
  "limit": 5000.00,
  "reset_interval": "monthly",
  "soft_threshold_percent": 80,
  "hard_threshold_percent": 100,
  "allowed_models": ["premium-chat", "standard-chat", "economy-chat"],
  "fallback_models": ["standard-chat", "economy-chat"],
  "criticality": "user_facing_production",
  "on_soft_limit": ["notify", "downgrade_model", "reduce_max_output_tokens"],
  "on_hard_limit": ["block_noncritical", "allow_emergency_override"],
  "notification_targets": ["slack:#support-platform", "email:[email protected]"]
}

Zahtijevaj metapodatke o vlasništvu na svakom zahtjevu

Izvršenje proračuna ovisi o dodjeli. Ako se zahtjev ne može preslikati na proračunski opseg, pristupnik ne može donijeti pouzdanu odluku o prijemu.

Zahtijevaj interne klijente da pošalju stabilne metapodatke o vlasništvu:

{
  "model": "premium-chat",
  "messages": [...],
  "max_tokens": 1200,
  "metadata": {
    "team_id": "customer_support",
    "app_id": "support_assistant",
    "environment": "production",
    "customer_id": "cust_48291",
    "workflow_id": "ticket_reply_draft"
  }
}

Preporuka: Uvedite ovo u fazama. Prvo zabilježite neatribuirani promet. Zatim upozorite na to. Zatim odbijte neatribuirani proizvodni promet nakon što su vlasnici imali vremena ažurirati klijente. Za razvojni promet, stavite ga u karantenu u zadani proračun s niskim ograničenjem umjesto da ga miješate s potrošnjom za proizvodnju.

Također provjerite metapodatke u odnosu na svoj sustav identiteta. Klijent ne bi trebao moći zatražiti proračun drugog tima promjenom team_id. Povežite API ključeve, račune usluga ili vjerodajnice partnera s dopuštenim opsegom proračuna.

Procjena troškova prije otpreme

Procjena prije provjere srž je provedbe u stvarnom vremenu. Gateway procjenjuje maksimalnu moguću cijenu prije nego što pošalje zahtjev davatelju.

Procjenitelj treba:

• Tablice cijena modela za ulaz, izlaz, predmemorirani unos, seriju, upotrebu alata, slike, ugradnje ili druge naplative dimenzije.
• Tokenizator ili logika procjene tokena po obitelji modela.
• Broj ili procjena brzog tokena.
• Traženi max_tokens ili maksimalna duljina izlaza.
• Pretpostavke predmemoriranja, ako brzo predmemoriranje utječe na naplatu.
• Pravila naplate specifična za davatelja usluga za ponovne pokušaje, pozive alata, obrazovne tokene, generiranje slika ili multimodalni unos.

Primjer izlaza alata za procjenu:

{
  "request_id": "req_7f1b",
  "budget_scope": "team:customer_support/app:support_assistant/env:production",
  "model": "premium-chat",
  "input_tokens_estimated": 1850,
  "max_output_tokens": 1200,
  "estimated_cost": 0.0845,
  "estimate_basis": "prompt_tokens_plus_max_output_tokens",
  "confidence": "conservative"
}

Preporuka: Tretirajte trošak prije leta kao konzervativnu procjenu pristupa, a ne kao računovodstvenu istinu. Ako korisnik traži max_tokens: 4000, rezervirajte prema toj gornjoj granici čak i ako se odgovor obično zaustavlja na 700 tokena. To smanjuje rizik prekomjerne potrošnje, ali može odbiti zahtjeve koji bi bili dovršeni prema proračunu. Taj je kompromis poželjniji za stroge financijske kontrole, a manje privlačan za istraživačke interne alate.

Rezervirajte proračun prije slanja zahtjeva

Uobičajen način neuspjeha je provjera proračuna, pronalaženje raspoloživog salda, a zatim dopuštanje mnogim istodobnim zahtjevima da prođu prije nego što se potrošnja zabilježi. Rješenje je rezervacija.

Redoslijed prijema trebao bi biti:

1. Autentifikacija pozivatelja.
2. Potvrdite metapodatke o vlasništvu.
3. Riješite primjenjiva proračunska pravila.
4. Procjena troškova zahtjeva.
5. Atomski rezervirajte taj procijenjeni trošak iz proračunske trgovine.
6. Pošaljite zahtjev pružatelju samo ako rezervacija uspije.
7. Oslobodi neiskorištenu rezervaciju nakon završetka.
8. Zabilježite konačnu procijenjenu upotrebu ili upotrebu koju je prijavio davatelj.

Pohrana rezervacija mora podržavati atomska ažuriranja. Redis s Lua skriptama, PostgreSQL transakcijama ili namjenskom uslugom glavne knjige može funkcionirati. Važno svojstvo je da dva zahtjeva ne mogu potrošiti isti preostali proračun.

Primjer zapisa rezervacije:

{
  "reservation_id": "res_9d42",
  "request_id": "req_7f1b",
  "budget_id": "budget_support_prod_monthly",
  "estimated_cost": 0.0845,
  "state": "reserved",
  "expires_at": "2026-09-28T12:45:00Z"
}

Koristite kratke rokove isteka rezervacija tako da napušteni zahtjevi ne blokiraju proračun zauvijek. Pozadinski čistač trebao bi otpustiti istekle rezervacije koje nikad nisu dosegle terminalno stanje.

Odvojite meka ograničenja od tvrdih ograničenja

Meka i čvrsta ograničenja trebala bi se ponašati drugačije. Meko ograničenje je signal politike. Čvrsto ograničenje je odluka o prijemu.

Ponašanje mekog ograničenja

Kada opseg prijeđe svoj meki prag, pristupnik još uvijek može opsluživati promet uz smanjenje pritiska potrošnje. Korisni odgovori uključuju:

• Pošaljite upozorenja vlasniku proračuna i financijama ili kanalu platforme.
• Dodajte zaglavlja odgovora koja prikazuju stanje ograničenja i preostali proračun.
• Usmjerite nekritične zahtjeve na jeftinije modele.
• Smanji max_tokens za opširne tijekove rada.
• Onemogućite skupe dodatne značajke kao što je generiranje više uzoraka.
• Zahtijevajte odobrenje za nove eksperimente unutar tog proračunskog opsega.

Primjer metapodataka odgovora mekog ograničenja:

{
  "budget_scope": "team:customer_support/app:support_assistant/env:production",
  "limit_state": "soft_limit_exceeded",
  "estimated_cost": 0.0310,
  "remaining_budget": 912.44,
  "applied_policy": ["downgrade_model", "reduce_max_output_tokens"],
  "selected_model": "standard-chat"
}

Ponašanje s tvrdim ograničenjima

Na tvrdom pragu, pristupnik bi trebao blokirati nekritičan promet s predvidljivim ugovorom o pogrešci.

{
  "error": {
    "type": "budget_limit_exceeded",
    "code": "llm_budget_hard_limit",
    "message": "The budget for this scope has been exhausted.",
    "budget_scope": "team:customer_support/app:support_assistant/env:production",
    "retry_after": "2026-10-01T00:00:00Z",
    "override_required": true
  }
}

Nemoj vraćati pogreške u obliku davatelja za neuspjehe proračuna pristupnika. Interni klijenti trebaju razlikovati ograničenja stope pružatelja usluga, ograničenja potrošnje pružatelja usluga, ograničenja potrošnje pristupnika, neuspjele provjere autentičnosti i odbijanja pravila.

Izričito rukovanje zahtjevima za strujanje

Streaming stvara drugačiji problem provedbe. Zahtjev je primljen prije nego pristupnik sazna konačne izlazne tokene, a generirani tokeni mogu nastaviti gomilati troškove dok je tok otvoren.

Uzorak koji se može koristiti je:

1. Rezervirajte konzervativni iznos na temelju brzih tokena i maksimalnih izlaznih tokena.
2. Pratite generirane tokene tijekom streama kada je to moguće.
3. Zaustavi generiranje ako je rezervirana količina potrošena.
4. Vrati razlog završetka koji klijent može riješiti.
5. Uskladite stvarnu upotrebu nakon što pružatelj pošalje konačne metapodatke o upotrebi ili nakon što se završi procjena pristupnika.

Primjer događaja prekida streama:

{
  "type": "response.completed",
  "finish_reason": "budget_exhausted",
  "budget_scope": "customer:cust_48291/workflow:ticket_reply_draft",
  "estimated_cost": 0.0845,
  "remaining_budget": 0.00
}

Kompromis: Prekid streama štiti proračun, ali može proizvesti nepotpun izlaz. Za tijekove rada koji zahtijevaju potpune strukturirane odgovore, preferirajte blokiranje prije provjere ili vraćanje modela na stariju verziju prije početka strujanja. Za iskustva u stilu chata, završni razlog s obzirom na proračun može biti prihvatljiv ako klijent može zatražiti od korisnika da pokuša ponovno kasnije ili da nastavi s jeftinijim modelom.

Izložite stanje proračuna klijentima

Proračun je lakše usvojiti kada pozivatelji mogu vidjeti što se dogodilo. Dodajte zaglavlja odgovora ili metapodatke za interne klijente i partnerske API-je.

Korisna polja uključuju:

• budget_scope
• limit_state: normalno, soft_limit_near, soft_limit_exceeded, hard_limit_exceeded
• estimated_cost
• reserved_cost
• final_cost_when_available
• remaining_budget
• applied_policy
• selected_model

Za API-je javnih partnera izbjegavajte otkrivanje imena internih timova ili osnove troškova ako je to komercijalno osjetljivo. Umjesto toga izložite stanje kvote sigurnog stanara, kao što su remaining_quota, limit_state i retry_after.

Uskladite procjene s upotrebom davatelja usluga

Provedba vremena zahtjeva i izvješćivanje o troškovima na razini računovodstva povezani su, ali nisu ista stvar. Procjena pristupnika donosi odluku o prijemu u neizvjesnosti. Izvozi naplate davatelja usluga, API-ji za korištenje i fakture pružaju evidenciju o kojoj će financije brinuti.

Preporuka: Uskladite procijenjenu potrošnju pristupnika s upotrebom koju je prijavio davatelj barem dnevno. Razlike mogu proizaći iz neusklađenosti tokenizatora, brzog predmemoriranja, skupnih popusta, ponovnih pokušaja, neuspjelih poziva, zaokruživanja specifičnog za pružatelja usluga, naplate pomoću slika ili alata i izvoza odgođene naplate.

Posao usklađivanja trebao bi:

1. Uvoz podataka o korištenju i troškovima pružatelja usluga.
2. Normalizirajte ga u shemu korištenja pristupnika.
3. Uparite zapise pružatelja usluga s ID-ovima zahtjeva pristupnika ako su dostupni.
4. Dodijelite neusklađenu potrošnju pružatelja najspecifičnijem poznatom opsegu.
5. Prilagodite proračunske knjige za prevelike ili premale rezervacije.
6. Emitira izvješća o varijanci prema dobavljaču, modelu, timu, aplikaciji i okruženju.

Koristite normalizirana telemetrijska polja za ulazne tokene, izlazne tokene, model, pružatelja usluga, ID zahtjeva i status. OpenTelemetry GenAI semantičke konvencije definiraju atribute upotrebe tokena koji mogu pomoći u standardizaciji telemetrije upotrebe među pružateljima usluga.

Namjerno odaberite ponašanje pri otvaranju ili zatvaranju kod pogreške

Proračunska trgovina postaje dio putanje zahtjeva. To je glavni arhitektonski trošak provedbe u stvarnom vremenu.

Ako je proračunska trgovina nedostupna, pristupnik treba definirano ponašanje:

• Neuspješno otvaranje: dopustite zahtjeve i označite ih za kasnije usklađivanje. Time se štiti dostupnost, ali može doći do prekomjerne potrošnje.
• Neuspješno zatvoreno: blokiraj zahtjeve dok stanje proračuna ne bude dostupno. To štiti potrošnju, ali može prekinuti proizvodne tijekove rada.
• Fail constrained: dopustite samo kritični proizvodni promet, koristite jeftinije modele, primijenite niska ograničenja po zahtjevu i blokirajte eksperimente ili skupna radna opterećenja.

Preporuka: Koristite fail constrained za većinu poslovnih sustava. Kritični radni procesi proizvodnje nastavljaju se uz smanjenu izloženost troškovima, dok diskrecijska radna opterećenja pauziraju dok se kontrolna razina ne oporavi.

Kontrolni popis za implementaciju

• Definirajte opseg proračuna i metapodatke o vlasništvu.
• Poveži API ključeve ili račune usluga za dopuštene opsege.
• Stvorite zapise pravila s mekim ograničenjima, čvrstim ograničenjima, dopuštenim modelima, zamjenama, nadjačavanjima i ciljevima obavijesti.
• Izradite procjenitelj troškova svjestan pružatelja usluga.
• Koristite atomske proračunske rezervacije prije slanja pružatelja usluga.
• Oslobodi neiskorištene rezervacije nakon završetka.
• Implementirajte pogreške tvrdog ograničenja sa stabilnim ugovorom.
• Dodajte praćenje tokena za strujanje i razloge završetka s obzirom na proračun.
• Izložite stanje proračuna putem internih zaglavlja ili metapodataka odgovora.
• Neka ograničenja potrošnje davatelja budu omogućena kao zaštitne mjere.
• Uskladite procjene pristupnika s dnevnim izvješćima o upotrebi i troškovima pružatelja usluga.
• Upozorenje o odstupanju, neatribuiranom prometu, iscrpljenim proračunima i korištenju nadjačavanja.

Zaključak koji se može poduzeti

Da biste pouzdano proveli ograničenja potrošnje LLM-a, stavite odluku tamo gdje zahtjevi ulaze u vaš sustav. Ograničenja pružatelja usluga mogu zaustaviti štetu na razini računa, ali pravila pristupnika mogu nametnuti poslovna ograničenja koja čelnici zapravo traže: proračune tima, aplikacije, okruženja, korisnika, partnera i tijeka rada.

Minimalni održivi dizajn je jednostavan: zahtijevajte metapodatke o vlasništvu, procijenite troškove prije slanja, rezervirajte proračun atomski, primijenite meke i tvrde pragove, upravljajte strujanjem odvojeno i uskladite s podacima o korištenju pružatelja usluga. Teži dio nije odluka prvog bloka. Teži dio je učiniti sustav dovoljno predvidljivim da mu financije vjeruju i da produkcijski timovi mogu nastaviti s radom kada je proračun pod pritiskom.

Povezano čitanje

• knjiga troškova LLM-a po timu