Kā ieviest LLM tēriņu ierobežojumus API vārtejā

Pakalpojumu sniedzēju tēriņu ierobežojumi ir noderīgi atbalsta līdzekļi, taču tie reti atbilst uzņēmumam faktiski pieder LLM tēriņi. Finanses vēlas ierobežojumus atkarībā no komandas, lietojumprogrammas, vides, klienta, partnera vai darbplūsmas. Platformas komandām šie ierobežojumi ir jāievieš, pirms tie tiek pieprasīti OpenAI, Anthropic, Gemini, Azure OpenAI vai citam modeļa nodrošinātājam. Pareizais kontroles punkts parasti ir API vārteja, kur katru pieprasījumu var attiecināt, novērtēt, pieņemt, pazemināt, bloķēt un saskaņot.

Šajā rokasgrāmatā ir aprakstīta vārtejas slāņa ieviešana AI API izmaksu kontrolei. Tas koncentrējas uz budžeta izpildi reāllaikā, nevis retrospektīviem atmaksas ziņojumiem vai plašām izmaksu optimizācijas programmām.

Ko pakalpojumu sniedzēja tēriņu kontrole var un ko nevar darīt

Fakts: Lielākie pakalpojumu sniedzēji piedāvā noderīgas vadīklas, taču tie darbojas pakalpojumu sniedzēja noteiktās robežās. OpenAI katru mēnesi dokumentē API tēriņu ierobežojumus organizācijas un projekta līmenī, kā arī izteiktas kļūdas attiecībā uz organizācijas ierobežojumiem, projektu ierobežojumiem, piešķirtajiem lietošanas ierobežojumiem un izlietotajiem priekšapmaksas kredītiem. Anthropic dokumentē darbvietas izdevumu un likmju ierobežojumus, kā arī nodrošina API, lai izgūtu konfigurētas organizācijas un darbvietas ierobežojumus iekšējiem brīdinājumiem. Google Mākoņa budžeta brīdinājumi vien automātiski nenosaka tēriņu ierobežojumu, savukārt Google dokumentē arī ierobežotos tēriņus piemērotiem pakalpojumiem, piemēram, Gemini API un Agent Platform. Azure OpenAI kvota tiek piešķirta katram abonementam, reģionam, modelim un izvietošanas veidam marķieru vienībās minūtē, un ātruma ierobežojuma aprēķinos var iekļaut tūlītēju aprēķinu un maksimālās pilnvaras, ne tikai galīgos apmaksas marķierus.

Ieteikums: Iespējojiet pakalpojumu sniedzēja vietējos tēriņu ierobežojumus kā pēdējās iespējas aizsargmargas. Neuzskatiet tos par galveno iekšējo budžetu izpildes mehānismu. Tie ir pārāk rupji lielākajai daļai īpašumtiesību modeļu, un parasti tie tiek aktivizēti pēc tam, kad pieprasījuma ceļš jau ir atstājis jūsu kontroli.

Prognoze: Pakalpojumu sniedzēju vadīklas turpinās uzlaboties, taču uzņēmumiem joprojām būs nepieciešama vārtejas līmeņa politika, jo iekšējās izmaksu īpašumtiesības mainās ātrāk nekā pakalpojumu sniedzēja kontu struktūras.

Vispirms definējiet budžeta politikas modeli

Sāciet ar politiku, nevis kodu. Vārteja nevar piemērot budžetu, kas nav precīzi aprakstīts.

Praktiskajā politikas ierakstā jāiekļauj:

• Budžeta īpašnieks: komanda, nodaļa, klients, partneris, lietojumprogramma vai darbplūsmas īpašnieks.
• Tvērums: kategorijas, kas atbilst pieprasījumiem, piemēram, team_id, app_id, environment, customer_id un workflow_id.
• Atiestatīšanas intervāls: dienu, nedēļu, mēnesi, līguma periodu vai pielāgotu logu.
• Mīkstais slieksnis: punkts, kurā vārteja brīdina, pazemina, samazina izvades garumu vai novirza uz lētākiem modeļiem.
• Cietais slieksnis: vieta, kur tiek bloķēta nekritiskā satiksme.
• Atļautie modeļi: modeļi, ko var izmantot šī joma.
• Atkāpšanās modeļi: lētāki vai mazākas ietilpības modeļi ir atļauti pēc mīksta sliekšņa.
• Kritiskums: neatkarīgi no tā, vai darba slodze ir svarīga ražošanai, lietotājam, iekšējai, pakešam vai eksperimentālai.
• Avārijas ignorēšana: kurš var pagarināt ierobežojumu, uz cik ilgu laiku un ar kādu audita izsekojamību.
• Paziņojumu mērķi: Slack kanāls, e-pasta grupa, incidentu pakalpojums, tīmekļa aizķere vai finanšu rinda.

Politikas piemērs:

{
  "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]"]
}

Pieprasīt īpašumtiesību metadatus katrā pieprasījumā

Budžeta izpilde ir atkarīga no attiecinājuma. Ja pieprasījumu nevar saistīt ar budžeta apjomu, vārteja nevar pieņemt uzticamu lēmumu par uzņemšanu.

Pieprasīt iekšējiem klientiem nosūtīt stabilus īpašumtiesību metadatus:

{
  "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"
  }
}

Ieteikums: Izlieciet to pa fāzēm. Vispirms reģistrējiet neattiecināto trafiku. Tad brīdini par to. Pēc tam noraidiet neattiecināto produkcijas datplūsmu, kad īpašniekiem ir bijis laiks atjaunināt klientus. Izstrādes datplūsmai ievietojiet to noklusējuma budžetā ar zemu ierobežojumu, nevis samaisiet to ar ražošanas izdevumiem.

Arī pārbaudiet metadatus attiecībā pret savu identitātes sistēmu. Klientam nevajadzētu būt iespējai pieprasīt citas komandas budžetu, mainot team_id. Saistiet API atslēgas, pakalpojumu kontus vai partneru akreditācijas datus ar atļautajiem budžeta apjomiem.

Aptuvenās izmaksas pirms nosūtīšanas

Pirmslidojuma aprēķins ir reāllaika izpildes pamatā. Vārteja nosaka maksimālās iespējamās izmaksas, pirms tā nosūta pieprasījumu pakalpojumu sniedzējam.

Aprēķinam ir nepieciešams:

• Modeļu cenu tabulas ievadei, izvadei, kešatmiņā saglabātajai ievadei, paketei, rīku lietošanai, attēliem, iegulšanām vai citiem apmaksājamiem izmēriem.
• Marķiera vai marķiera aplēses loģika katrai modeļu saimei.
• Uzvednes marķiera skaits vai aprēķins.
• Pieprasītais max_tokens vai maksimālais izvades garums.
• Kešatmiņas pieņēmumi, ja tūlītēja kešatmiņa ietekmē norēķinus.
• Pakalpojumu sniedzējam specifiski norēķinu noteikumi par mēģinājumiem, rīku izsaukumiem, argumentācijas pilnvarām, attēlu ģenerēšanu vai multimodālu ievadi.

Aprēķinātāja izvades piemērs:

{
  "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"
}

Ieteikums: Uztveriet pirmslidojuma izmaksas kā konservatīvu uzņemšanas aprēķinu, nevis grāmatvedības patiesību. Ja lietotājs pieprasa max_tokens: 4000, rezervējiet pret šo augšējo robežu, pat ja atbilde parasti apstājas pie 700 marķieriem. Tas samazina pārtēriņa risku, taču var noraidīt pieprasījumus, kas būtu izpildīti saskaņā ar budžetu. Šis kompromiss ir vēlams stingrai finanšu kontrolei un mazāk pievilcīgs izpētes iekšējiem rīkiem.

Rezerves budžets pirms pieprasījuma nosūtīšanas

Bieži sastopams kļūmes režīms ir budžeta pārbaude, pieejamā bilances atrašana un pēc tam daudzu vienlaicīgu pieprasījumu nokārtošana, pirms tiek reģistrēti tēriņi. Labojums ir rezervēšana.

Uzņemšanas secībai jābūt šādai:

1. Autentificējiet zvanītāju.
2. Apstipriniet īpašumtiesību metadatus.
3. Atrisiniet piemērojamo budžeta politiku.
4. Aprēķiniet pieprasījuma izmaksas.
5. Atomiski rezervējiet šīs aptuvenās izmaksas budžeta veikalā.
6. Nosūtiet pieprasījumu pakalpojumu sniedzējam tikai tad, ja rezervācija ir veiksmīga.
7. Atbrīvojiet neizmantoto rezervāciju pēc pabeigšanas.
8. Ierakstīt galīgo aptuveno vai pakalpojumu sniedzēja ziņoto lietojumu.

Rezervācijas veikalam ir jāatbalsta atomu atjauninājumi. Redis var darboties ar Lua skriptiem, PostgreSQL transakcijām vai īpašu virsgrāmatas pakalpojumu. Svarīga īpašība ir tāda, ka diviem pieprasījumiem nevar iztērēt to pašu atlikušo budžetu.

Rezervācijas ieraksta piemērs:

{
  "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"
}

Izmantojiet īsus rezervāciju termiņus, lai atmestie pieprasījumi neierobežotu budžetu uz visiem laikiem. Fona tīrītājam ir jāatbrīvo rezervācijas, kurām beidzies derīguma termiņš un kuras nekad nav sasniegušas termināļa stāvokli.

Atdaliet mīkstos ierobežojumus no stingriem ierobežojumiem

Mīkstajiem un stingriem ierobežojumiem ir jādarbojas atšķirīgi. Mīkstais ierobežojums ir politikas signāls. Stingrs ierobežojums ir lēmums par uzņemšanu.

Mīksto ierobežojumu darbība

Kad tvērums šķērso savu minimālo slieksni, vārteja joprojām var apkalpot datplūsmu, vienlaikus samazinot izdevumu spiedienu. Noderīgas atbildes ietver:

• Nosūtiet brīdinājumus budžeta īpašniekam un finanšu vai platformas kanālam.
• Pievienojiet atbilžu galvenes, kas parāda limita stāvokli un atlikušo budžetu.
• Novirziet nekritiskus pieprasījumus uz lētākiem modeļiem.
• Samaziniet max_tokens detalizētām darbplūsmām.
• Atspējojiet dārgas izvēles funkcijas, piemēram, vairāku paraugu ģenerēšanu.
• Pieprasīt apstiprinājumu jauniem eksperimentiem saskaņā ar šo budžeta apjomu.

Mīksto ierobežojumu atbildes metadatu piemērs:

{
  "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"
}

Stingra ierobežojuma uzvedība

Sasniedzot cieto slieksni, vārtejai ir jābloķē nekritiska trafika ar paredzamu kļūdu līgumu.

{
  "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
  }
}

Neatgrieziet nodrošinātāja formas kļūdas vārtejas budžeta kļūmēm. Iekšējiem klientiem ir jānošķir pakalpojumu sniedzēja tarifu ierobežojumi, pakalpojumu sniedzēja tēriņu ierobežojumi, vārtejas tēriņu ierobežojumi, autentifikācijas kļūmes un politikas atteikumi.

Tieši apstrādājiet straumēšanas pieprasījumus

Straumēšana rada atšķirīgu izpildes problēmu. Pieprasījums tiek pieņemts, pirms vārteja uzzina galīgos izvades marķierus, un ģenerētie marķieri var turpināt uzkrāt izmaksas, kamēr straume ir atvērta.

Darbīgs modelis ir:

1. Rezervējiet konservatīvu summu, pamatojoties uz uzvednes marķieriem un maksimālās izvades marķieriem.
2. Ja iespējams, izsekojiet ģenerētos marķierus straumes laikā.
3. Pārtraukt ģenerēšanu, ja rezervētā summa ir iztērēta.
4. Norādiet beigu iemeslu, ko klients var apstrādāt.
5. Saskaņojiet faktisko lietojumu pēc tam, kad pakalpojumu sniedzējs ir nosūtījis galīgos lietojuma metadatus vai pēc vārtejas aplēses pabeigšanas.

Straumes pārtraukšanas notikuma piemērs:

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

Kompozīcija: Straumes pārtraukšana aizsargā budžetu, taču tā var radīt nepilnīgu rezultātu. Darbplūsmām, kurām nepieciešamas pilnīgas strukturētas atbildes, dodiet priekšroku pirmslidojuma bloķēšanai vai modeļa pazemināšanai pirms straumēšanas sākuma. Ja klients var lūgt lietotājam vēlāk mēģināt vēlreiz vai turpināt ar lētāku modeli, tērzēšanas stilam var būt pieņemams iemesls, kas ņem vērā budžetu.

Paziņot budžeta stāvokli klientiem

Budžeta izpildi ir vieglāk pieņemt, ja zvanītāji var redzēt notikušo. Pievienojiet atbilžu galvenes vai metadatus iekšējiem klientiem un partneru API.

Noderīgi lauki ietver:

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

Publisko partneru API gadījumā izvairieties no iekšējo komandu nosaukumu vai izmaksu bāzes nopludināšanas, ja tas ir komerciāli sensitīvs. Tā vietā parādiet nomniekam drošas kvotas statusu, piemēram, remaining_quota, limit_state un retry_after.

Saskaņot aprēķinus ar pakalpojumu sniedzēja lietojumu

Pieprasījuma izpildes laikā un grāmatvedības līmeņa izmaksu pārskati ir saistīti, taču tie nav viens un tas pats. Vārtejas aplēse pieņem lēmumu par uzņemšanu nenoteiktības apstākļos. Pakalpojumu sniedzēju norēķinu eksportēšana, lietošanas API un rēķini nodrošina informāciju, kas rūpēsies par finansēm.

Ieteikums: Saskaņojiet vārtejas aprēķinātos tēriņus ar pakalpojumu sniedzēja ziņoto lietojumu vismaz katru dienu. Atšķirības var rasties no marķiera neatbilstības, tūlītējas saglabāšanas kešatmiņā, pakešu atlaidēm, atkārtojumiem, neveiksmīgiem zvaniem, pakalpojumu sniedzējam noteiktas noapaļošanas, attēla vai rīka izmantošanas norēķiniem un aizkavētu rēķinu eksportēšanas.

Saskaņošanas darbam vajadzētu:

1. Importējiet pakalpojumu sniedzēja lietojuma un izmaksu datus.
2. Normalizējiet to vārtejas lietošanas shēmā.
3. Saskaņojiet nodrošinātāja ierakstus ar vārtejas pieprasījumu ID, ja tie ir pieejami.
4. Piešķiriet nesaskaņotos pakalpojumu sniedzēja tēriņus visprecīzākajam zināmajam apjomam.
5. Pielāgojiet budžeta virsgrāmatas pārmērīgai vai nepietiekamai rezervācijai.
6. Izsniedziet novirzes pārskatus pēc pakalpojumu sniedzēja, modeļa, komandas, lietojumprogrammas un vides.

Izmantojiet normalizētos telemetrijas laukus ievades marķieriem, izvades marķieriem, modelim, nodrošinātājam, pieprasījuma ID un statusam. OpenTelemetry GenAI semantiskās konvencijas definē pilnvaru lietošanas atribūtus, kas var palīdzēt standartizēt lietojuma telemetriju starp pakalpojumu sniedzējiem.

Izvēlieties neveiksmīgi atvērtu vai neveiksmīgi slēgtu darbību apzināti

Budžeta veikals kļūst par daļu no pieprasījuma ceļa. Tās ir galvenās arhitektūras izmaksas par izpildi reāllaikā.

Ja budžeta veikals nav pieejams, vārtejai ir nepieciešama noteikta darbība:

• Neizdevās atvērt: atļauj pieprasījumus un atzīmē tos vēlākai saskaņošanai. Tas aizsargā pieejamību, bet var pārtērēt.
• Neizdevās aizvērt: bloķējiet pieprasījumus, līdz ir pieejams budžeta statuss. Tas aizsargā izdevumus, bet var pārtraukt ražošanas darbplūsmas.
• Ierobežota neveiksme: atļaujiet tikai kritisko produkcijas trafiku, izmantojiet lētākus modeļus, piemērojiet zemus ierobežojumus katram pieprasījumam un bloķējiet eksperimentus vai pakešu darba slodzi.

Ieteikums: Lietojiet atteices ierobežojumu lielākajai daļai biznesa sistēmu. Kritiskās ražošanas darbplūsmas turpinās ar samazinātām izmaksām, savukārt diskrecionārās darba slodzes tiek apturētas, līdz tiek atjaunota vadības plakne.

Ieviešanas kontrolsaraksts

• Definējiet budžeta apjomu un īpašumtiesību metadatus.
• Saistiet API atslēgas vai pakalpojumu kontus ar atļautajiem tvērumiem.
• Izveidojiet politikas ierakstus ar mīkstiem ierobežojumiem, stingriem ierobežojumiem, atļautajiem modeļiem, atkāpšanās gadījumiem, ignorēšanu un paziņojumu mērķiem.
• Izveidojiet pakalpojumu sniedzēju apzinātu izmaksu aprēķinātāju.
• Izmantojiet atombudžeta rezervācijas pirms pakalpojumu sniedzēja nosūtīšanas.
• Pēc pabeigšanas atbrīvojiet neizmantotās rezervācijas.
• Ieviesiet cietā ierobežojuma kļūdas ar stabilu līgumu.
• Pievienojiet straumēšanas pilnvaras izsekošanu un budžeta izpildes iemeslus.
• Atklājiet budžeta stāvokli, izmantojot iekšējās galvenes vai atbilžu metadatus.
• Saglabājiet pakalpojumu sniedzēja tēriņu ierobežojumus iespējotus kā rezerves līdzekļus.
• Katru dienu saskaņojiet vārtejas aprēķinus ar pakalpojumu sniedzēja lietojuma un izmaksu pārskatiem.
• Brīdinājums par novirzēm, neattiecināto trafiku, iztērētiem budžetiem un ignorēšanu.

Rīcāms secinājums

Lai uzticami ieviestu LLM tēriņu ierobežojumus, izlemiet, kur jūsu sistēmā tiek ievadīti pieprasījumi. Pakalpojumu sniedzēju ierobežojumi var apturēt konta līmeņa bojājumus, bet vārtejas politika var ieviest biznesa ierobežojumus, ko vadītāji faktiski pieprasa: komandas, lietotnes, vides, klientu, partneru un darbplūsmas budžetus.

Minimālais dzīvotspējīgais dizains ir vienkāršs: pieprasīt īpašumtiesību metadatus, aplēst izmaksas pirms nosūtīšanas, rezervēt budžetu, lietot mīkstos un stingros sliekšņus, apstrādāt straumēšanu atsevišķi un saskaņot ar pakalpojumu sniedzēja lietojuma datiem. Grūtā daļa nav pirmais bloka lēmums. Sarežģītākā daļa ir padarīt sistēmu pietiekami paredzamu, lai finanses tai uzticētos, un ražošanas komandas varētu turpināt darboties, ja budžets ir zem spiediena.

Saistīta informācija

• vienas komandas LLM izmaksu virsgrāmata