Likmes ierobežojumu apzinošas AI API vārtejas: formas RPM, TPM, sērijveidā un īrnieka godīgums pirms 429 s.

429 no LLM pakalpojumu sniedzēja nav tikai signāls, lai mēģinātu mēģināt. Ražošanā bieži vien ir pierādījums, ka jūsu lietojumprogramma jau ir zaudējusi kontroli pār uzņemšanu, īrnieka godīgumu, latentumu vai pakalpojumu sniedzējam specifisku kvotu uzskaiti.

Kopējais labojums — eksponenciāla atkāpšanās — ir nepieciešams, taču nav pilnīgs. Atkāpšanās reaģē pēc tam, kad pakalpojumu sniedzējs noraida trafiku. Likmes ierobežojumu apzinošai AI API vārtejai ir jāveido datplūsma, pirms pieprasījumi tiek atstāti jūsu sistēmā: aprēķiniet pilnvaru spiedienu, rezervējiet kvotu, izolējiet nomniekus, iestatiet pareizo darbu rindā, noraidiet nepareizo darbu un pielāgojieties, kad mainās pakalpojumu sniedzēja ierobežojumi.

Šajā rakstā ir aprakstīts praktisks vārtejas kvotas pārvaldnieks komandām, kas nosūta ražošanas darba slodzi vairākiem LLM nodrošinātājiem, izmantojot vienotu API.

Lasītāja problēma: 429s ir daudzdimensionāli

Daudzas komandas uztver ātruma ierobežojumus tā, it kā tie būtu viens pieprasījumu minūtē skaitlis. Šis pieņēmums ātri tiek pārtraukts, izmantojot LLM API.

Fakti no pašreizējās pakalpojumu sniedzēja dokumentācijas:

• OpenAI dokumenti ar ierobežojumiem var tikt piemēroti īsākiem logiem nekā reklamētais minūtes ierobežojums, tāpēc īsas sērijas var neizdoties pat tad, ja vidējā minūte šķiet droša.
• Azure OpenAI kvota tiek piešķirta pēc abonementa, reģiona, modeļa un izvietošanas veida marķieros minūtē. Piešķirot TPM izvietošanai, tiek noteikti arī piespiedu izsecināšanas RPM ierobežojumi, un RPM un TPM attiecības atšķiras atkarībā no modeļa.
• Azure OpenAI arī atzīmē, ka likmes ierobežojuma pilnvaras aprēķini tiek aprēķināti, kad tiek saņemts pieprasījums, un tie nav vienādi ar galīgo norēķinu pilnvaru skaitu.
• Antropiskie dokumenti nošķir pieprasījumu minūtē, ievades marķieru minūtē un izvades marķieru minūtē ierobežojumus. Pārsniedzot ierobežojumus, tiek atgriezts 429 ar galveni “atkārtoti pēc mēģinājuma”.
• Anthropic brīdina, ka straujš satiksmes pieaugums var sasniegt paātrinājuma ierobežojumus, un iesaka pakāpeniski palielināt ātrumu.
• Lielākajai daļai Claude modeļu Antropiskie dokumenti, kas kešatmiņā nolasa ievades pilnvaras, netiek ņemti vērā ievades marķiera minūtē ierobežojumiem, kas nozīmē, ka tūlītēja kešatmiņa var mainīt faktisko brīvību.
• Google Gemini API likmes ierobežojumi ir saistīti ar projekta lietojuma līmeņiem ar augstākiem līmeņiem atkarībā no norēķinu iestatījumiem, kumulatīviem tēriņiem un laika, kas pagājis pēc maksājuma atskaites punktiem.

Darbības mācība ir skaidra: ar OpenAI saderīga pieprasījuma forma nenozīmē ar OpenAI saderīgu kvotu darbību. Vairāku pakalpojumu sniedzēju vārtejai ir nepieciešams iekšējās kvotas modelis, kas ir bagātāks par “mēģināt vēlreiz, ja 429”.

Izstrādājuma mērķis: padarīt ieejas kontroli par vārtejas pienākumu

Vārtejai, kas apzinās tarifu ierobežojumus, pirms pieprasījuma nosūtīšanas ir jāatbild uz pieciem jautājumiem:

1. Kurs pakalpojumu sniedzējs, modelis, izvietošana, reģions, projekts vai darbvieta saņems pieprasījumu?
2. Cik daudz pieprasījuma, ievades pilnvaras, izvades pilnvaras un vienlaicības jaudas tas varētu patērēt?
3. No kura nomnieka, komandas, API atslēgas, klienta vai darba slodzes klases jāiekasē maksa par koplietoto jaudu?
4. Vai pieprasījums ir jāpieņem tagad, īslaicīgi jāievieto rindā, jāsamazina, jānovirza citur vai jānoraida?
5. Kā jāsaskaņo rezervācija pēc tam, kad pakalpojumu sniedzējs atgriež faktisko lietojumu?

Vārteja kļūst par kvotu pārvaldnieku. Tas neaizstāj pakalpojumu sniedzēja ierobežojumus. Tas padara pakalpojumu sniedzēju ierobežojumus redzamus, paredzamus un godīgus jūsu sistēmā.

Izveidojiet normalizētu kvotas modeli

Sāciet ar iekšējo ierobežotāju dimensiju definēšanu, kas var pārstāvēt galvenos pakalpojumu sniedzējus, neliekot tos vienā maldinošā segmentā.

Ieteicamie ierobežotāja izmēri

• IPT: pieprasījumi minūtē.
• Ievades TPM: uzvedne, ziņojums, rīks un konteksta pilnvaras minūtē.
• Izvades TPM: pabeigšanas marķieri minūtē, rezervēti atsevišķi straumēšanai un ilgām paaudzēm.
• Kopējais TPM: noderīga pakalpojumu sniedzējiem vai izvietojumiem, kas pakļauj kombinētu pilnvaru spiedienu.
• Vienlaicīgums: aktīvi pieprasījumi, aktīvas straumes vai uzdevumi lidojuma laikā.
• Straumēšanas ilgums: ilgstošas straumes var aizņemt savienojumu un izvades marķieri pat tad, ja RPM ir zems.
• Pakalpojumu sniedzējam noteiktais tvērums: Azure abonements/reģions/izvietošana, antropiskā darbvieta/modeļa klase, Google projekts/līmenis vai OpenAI organizācija/projekts/modeļu grupa.

Neslēpt pakalpojumu sniedzējam raksturīgās dimensijas. Normalizējiet tos kopējā shēmā, taču saglabājiet pietiekami daudz detaļu, lai vēlāk izskaidrotu noraidījumu.

{
  "provider": "provider_a",
  "model_profile": "ātrā tērzēšana",
  "provider_scope": {
    "projekts": "prod",
    "reģions": "us-austrumi",
    "izvietošana": "chat-large-01"
  },
  "limits": {
    "apgr./min.": 1200,
    "input_tpm": 800000,
    "output_tpm": 250000,
    "vienlaikus": 200
  }
}

Šis iekšējais objekts ir jākonfigurē skaidri, nevis tikai no modeļu nosaukumiem. Pakalpojumu sniedzēja informācijas paneļi, kontu līmeņi, reģionālie izvietojumi un darbvietas iestatījumi var mainīt vienas un tās pašas modeļu saimes faktisko jaudu.

Aprēķiniet marķiera spiedienu pirms nosūtīšanas

Pakalpojumu sniedzēja puses tarifu ierobežošana bieži notiek, pirms ir zināms galīgais norēķinu lietojums. Pirms datplūsmas nosūtīšanas vārtejai ir jāveic tāda paša veida piesardzīgs aprēķins.

Pirmslidojuma rezervācijas ievades

• Serializēta uzvedne un ziņojuma garums.
• Modelim specifiska pilnvarošana un pieskaitāmās izmaksas lomām, rīkiem, attēliem vai strukturētas izvades instrukcijām.
• max_completion_tokens vai līdzvērtīgs izvades ierobežojums.
• Vēsturiskā pabeigšanas attiecība šim galapunktam, nomniekam, modeļa profilam un pieprasījuma klasei.
• Paredzamie kešatmiņas lasīšanas pilnvari, ja tūlītēja kešatmiņa ir pieejama un izmērāma.
• Straumēšanas karodziņš un paredzamais straumes ilgums.

Lai sāktu, bieži pietiek ar vienkāršu rezervēšanas noteikumu:

estimated_input_tokens = tokenize(request_messages) + model_overhead
aptuvenais_izejas_tokens = min(
  max_completion_tokens,
  p95_historical_output_tokens_for_route
)
reserved_total_tokens = aprēķinātie_ievades_tokeni + aprēķinātie_izvades_tokeni

Nezināmiem maršrutiem izmantojiet konservatīvu noklusējuma iestatījumu. Lai nodrošinātu stabilus ražošanas maršrutus, aprēķinus pastāvīgi atjauniniet no faktiskā lietojuma.

Rezervēt, pēc tam saskaņot

Kvotu rezervācijām nevajadzētu kļūt par pastāvīgām maksām. Izturieties pret tiem kā aizturētiem:

1. Citāts: novērtējiet ieejas un izejas spiedienu.
2. Rezerve: pirms nosūtīšanas atņemiet no attiecīgajām marķieru grupām.
3. Nokārtot: aizstājiet aprēķinu ar pakalpojumu sniedzēja ziņotu lietojumu, ja tas ir pieejams.
4. Atmaksa vai debets: atgrieziet neizmantoto rezervēto jaudu vai iekasējiet pārsniegumu nākamajā logā, ja nepieciešams.

Tas ir vissvarīgākais gariem konteksta un straumēšanas zvaniem. Ja pirms nosūtīšanas pārbaudāt tikai ievades TPM, straume var veiksmīgi sākt un pēc tam vēlāk saskarties ar izvades marķiera spiedienu. Izvades telpas rezervēšana atsevišķi samazina vidējas straumes atteices un apstāšanās risku.

Nomnieka godīguma nodrošināšanai izmantojiet hierarhisku marķieru kopas

Viens globālais ierobežotājs aizsargā pakalpojumu sniedzēja kontu, bet neaizsargā īrniekus vienu no otra. Viens gara konteksta pakešdarbs var patērēt koplietotu TPM un izraisīt citu komandu interaktīvo pieprasījumu neveiksmi.

Izmantojiet hierarhiskas pilnvaru grupas:

organizācija
  └── īrnieks
      └── komanda
          └── api_key
              └── modeļa_profils
                  └── nodrošinātāja_izvietošana

Pieprasījumam ir jānokārto katrs attiecīgais segments. Tas ļauj vienlaikus ieviest vairākas politikas:

• Organizācija nedrīkst pārsniegt nodrošinātāja kapacitāti.
• Īrnieks nevar patērēt vairāk par savu līgumā noteikto daļu.
• API atslēga nedrīkst pārsniegt tai paredzēto vides vai lietojumprogrammas ierobežojumu.
• Pakešmodeļa profils nevar izskaust interaktīvu modeļa profilu.
• Pakalpojumu sniedzēja izvietošanu nevar pārslogot pat tad, ja citai izvietošanai ir rezerves kvota.

Godīga sadale salīdzinājumā ar izmantošanu

Ieteikums: izmantojiet svērtu godīgu dalīšanu ar kontrolētu sērijveida aizņemšanos.

Stingrus ierobežojumus katram īrniekam ir viegli izskaidrot, taču tie var zaudēt neizmantotu jaudu. Sērijveida aizņemšanās uzlabo izmantošanu, ļaujot īrniekam īslaicīgi izmantot dīkstāves kvotu no koplietotā pūla. Kompromiss ir sarežģītība: informācijas paneļos ir jāparāda, kas tika garantēts, kas tika aizņemts un kad aizņēmums tika atsaukts.

Praktisks noteikums:

• Piešķiriet katram nomniekam garantētu bāzes līniju.
• Atļaut sērijveida aizņemšanos no neizmantotās koplietotās jaudas.
• Atgūstiet aizņemto jaudu, kad parādās augstākas prioritātes vai garantēta satiksme.
• Nekad neļaujiet aizņemtai datplūsmai radīt nodrošinātāja līmeņa 429s garantētai datplūsmai.

Atdaliet satiksmes klases, pirms tās cīnās

Ne visi pieprasījumi ir pelnījuši vienādu rindas darbību. Ievietojiet trafiku modeļu profilos ar atsevišķām rindām un kvotu kopumiem.

{
  "kļūda": {
    "type": "rate_limited",
    "limiter": "output_tpm",
    "provider": "provider_a",
    "model_profile": "ātrā tērzēšana",
    "provider_model": "model-x",
    "retry_after_ms": 2400,
    "īrnieka_id": "īrnieks_123",
    "api_key_id": "key_456",
    "request_class": "interaktīvs",
    "estimated_input_tokens": 4200,
    "estimated_output_tokens": 800,
    "gateway_decision": "admitted_then_provider_rejected",
    "fallback_allowed": nepatiess,
    "trace_id": "trace_abc"
  }
}