Prehodi AI API, ki upoštevajo omejitve hitrosti: oblikujte RPM, TPM, burste in poštenost najemnika pred zadetkom 429

429 od ponudnika LLM ni le signal za ponovni poskus. V produkciji je to pogosto dokaz, da je vaša aplikacija že izgubila nadzor nad sprejemom, pravičnostjo najemnikov, zakasnitvijo ali obračunavanjem kvot, specifičnim za ponudnika.

Skupni popravek – eksponentni odmik – je potreben, vendar nepopoln. Backoff se odzove, ko ponudnik zavrne promet. Prehod API-ja AI, ki se zaveda hitrosti, bi moral oblikovati promet, preden zahteve zapustijo vaš sistem: oceniti pritisk žetonov, rezervirati kvoto, izolirati najemnike, postaviti pravo delo v čakalno vrsto, zavrniti napačno delo in se prilagoditi, ko se omejitve ponudnika spremenijo.

Ta članek opisuje praktični regulator kvote prehoda za ekipe, ki pošiljajo produkcijske delovne obremenitve več ponudnikom LLM prek poenotenega API-ja.

Težava z bralnikom: 429 so večdimenzionalni

Številne ekipe obravnavajo omejitve hitrosti, kot da gre za eno število zahtev na minuto. Ta predpostavka se pri API-jih LLM hitro pokvari.

Dejstva iz trenutne dokumentacije ponudnika:

• OpenAI dokumentira, da so lahko omejitve uveljavljene za krajša okna od oglaševane omejitve na minuto, tako da lahko kratki nizi ne uspejo, tudi če je povprečna minuta videti varna.
• Kvota Azure OpenAI je dodeljena glede na naročnino, regijo, model in vrsto uvedbe v žetonih na minuto. Dodeljevanje TPM razmestitvi določa tudi uveljavljene omejitve vrtljajev na minuto sklepanja, razmerja RPM proti TPM pa se razlikujejo glede na model.
• Azure OpenAI prav tako ugotavlja, da so izračuni žetonov za omejitev stopnje ocenjeni, ko je zahteva prejeta, in niso enaki končnim štetjem žetonov za obračun.
• Antropični dokumenti ločujejo omejitve zahtev na minuto, vnosnih žetonov na minuto in izhodnih žetonov na minuto. Preseganje omejitev vrne 429 z glavo za ponovni poskus.
• Anthropic opozarja, da lahko močno povečanje prometa preseže meje pospeška, in priporoča postopno povečevanje.
• Za večino modelov Claude se dokumenti Anthropic, ki predpomnijo vhodne žetone za branje, ne štejejo k omejitvam vnosnih žetonov na minuto, kar pomeni, da lahko takojšnje predpomnjenje spremeni učinkovito zmogljivost.
• Omejitve stopnje API-ja Google Gemini so vezane na ravni uporabe projekta, pri čemer so višje stopnje odvisne od nastavitve obračunavanja, skupne porabe in časa, ki je pretekel po plačilnih mejnikih.

Operativna lekcija je jasna: oblika zahteve, združljiva z OpenAI, ne pomeni vedenja kvote, združljivega z OpenAI. Prehod z več ponudniki potrebuje model notranjih kvot, ki je bogatejši od »poskusi znova, če je 429«.

Cilj načrtovanja: nadzor vstopa naj postane odgovornost prehoda

Prehod, ki pozna omejitev hitrosti, bi moral odgovoriti na pet vprašanj, preden pošlje zahtevo:

1. Kateri ponudnik, model, uvedba, regija, projekt ali delovni prostor bo prejel zahtevo?
2. Koliko zmogljivosti zahteve, vhodnega žetona, izhodnega žetona in sočasnosti lahko porabi?
3. Kateremu najemniku, ekipi, ključu API-ja, stranki ali razredu delovne obremenitve je treba zaračunati skupno zmogljivost?
4. Ali je treba zahtevo sprejeti zdaj, jo na kratko postaviti v čakalno vrsto, znižati, preusmeriti drugam ali zavrniti?
5. Kako je treba rezervacijo uskladiti, potem ko ponudnik vrne dejansko uporabo?

Prehod postane regulator kvote. Ne nadomešča omejitev ponudnika. Zaradi tega so omejitve ponudnika vidne, predvidljive in pravične znotraj vašega sistema.

Izdelajte normaliziran model kvot

Začnite z definiranjem notranjih dimenzij omejevalnika, ki lahko predstavljajo glavne ponudnike, ne da bi jih prisilili v eno zavajajočo vedro.

Priporočene mere omejevalnika

• RPM: zahteve na minuto.
• Vhodni TPM: poziv, sporočilo, orodje in žetoni konteksta na minuto.
• Izhodni TPM: žetoni dokončanja na minuto, rezervirani ločeno za pretakanje in dolge generacije.
• Skupni TPM: uporabno za ponudnike ali uvedbe, ki so izpostavljene kombiniranemu pritisku žetonov.
• Sočasnost: aktivne zahteve, aktivni tokovi ali opravila med letom.
• Trajanje pretakanja: dolgotrajni tokovi lahko zasedejo povezavo in prostor za izhodni žeton, tudi če je RPM nizek.
• Obseg, specifičen za ponudnika: naročnina/regija/uvedba Azure, delovni prostor/razred modela Anthropic, Googlov projekt/stopnja ali organizacija/projekt/skupina modelov OpenAI.

Ne skrivajte razsežnosti ponudnika. Normalizirajte jih v skupno shemo, vendar ohranite dovolj podrobnosti za kasnejšo razlago zavrnitve.

{
  "ponudnik": "ponudnik_a",
  "model_profile": "hitri klepet",
  "provider_scope": {
    "projekt": "proizvod",
    "regija": "us-vzhod",
    "deployment": "chat-large-01"
  },
  "omejitve": {
    "rpm": 1200,
    "input_tpm": 800000,
    "output_tpm": 250000,
    "sočasnost": 200
  }
}

Ta notranji objekt je treba konfigurirati eksplicitno, ne pa sklepati samo iz imen modela. Nadzorne plošče ponudnika, ravni računa, regionalne uvedbe in nastavitve delovnega prostora lahko spremenijo učinkovito zmogljivost iste družine modelov.

Ocenite pritisk žetonov pred pošiljanjem

Omejevanje cene na strani ponudnika se pogosto zgodi, preden je znana končna poraba zaračunavanja. Vaš prehod bi moral opraviti enako konzervativno oceno, preden pošlje promet.

Vnosi rezervacij pred letom

• Serializirani poziv in dolžina sporočila.
• Tokenizacija, specifična za model, in režijski stroški za vloge, orodja, slike ali strukturirana izhodna navodila.
• max_completion_tokens ali enakovredna izhodna omejitev.
• Preteklo razmerje dokončanja za to končno točko, najemnika, profil modela in razred zahteve.
• Pričakovani žetoni za branje predpomnilnika, če je hitro predpomnjenje na voljo in ga je mogoče izmeriti.
• Oznaka pretakanja in pričakovano trajanje pretakanja.

Za začetek je pogosto dovolj preprosto pravilo rezervacije:

estimated_input_tokens = tokenize(request_messages) + model_overhead
ocenjeni_izhodni_žetoni = min(
  max_completion_tokens,
  p95_historical_output_tokens_for_route
)
rezervirani_totalni_žetoni = ocenjeni_vhodni_žetoni + ocenjeni_izhodni_žetoni

Za neznane poti uporabite konzervativno privzeto. Za stabilne proizvodne poti nenehno posodabljajte ocene glede na dejansko uporabo.

Rezerviraj, nato uskladi

Rezervacije kvot ne bi smele postati stalne bremenitve. Obravnavajte jih kot zadržke:

1. Citat: ocenite vhodni in izhodni tlak.
2. Rezerviraj: odštej od ustreznih žetonov pred odpremo.
3. Poravnava: zamenjajte oceno s porabo, ki jo poroča ponudnik, ko je na voljo.
4. Vračilo ali bremenitev: po potrebi vrnite neuporabljeno rezervirano kapaciteto ali zaračunajte presežke do naslednjega okna.

To je najpomembnejše za klice z dolgim kontekstom in pretočne klice. Če pred pošiljanjem preverite samo vhodni TPM, se lahko tok uspešno zažene in pozneje naleti na pritisk izhodnega žetona. Z ločeno rezervacijo izhodne višine se zmanjša tveganje za okvaro sredi toka in tveganje zastoja.

Uporabite hierarhične žetone za pravičnost najemnikov

En sam globalni omejevalnik ščiti račun ponudnika, ne ščiti pa najemnikov drug pred drugim. Eno paketno opravilo z dolgim kontekstom lahko porabi TPM v skupni rabi in povzroči neuspešne interaktivne zahteve drugih skupin.

Uporaba hierarhičnih veder žetonov:

organizacija
  └── najemnik
      └── ekipa
          └── api_key
              └── profil_modela
                  └── provider_deployment

Zahteva mora prestati vsako ustrezno vedro. To vam omogoča uveljavljanje več pravilnikov hkrati:

• Organizacija ne sme preseči zmogljivosti ponudnika.
• Najemnik ne more porabiti več od svojega pogodbenega deleža.
• Ključ API ne sme preseči predvidene omejitve okolja ali aplikacije.
• Profil paketnega modela ne more izprazniti profila interaktivnega modela.
• Uvedbe ponudnika ni mogoče preobremeniti, tudi če ima druga uvedba rezervno kvoto.

Poštena delitev v primerjavi z uporabo

Priporočilo: uporabite tehtano pošteno delitev z nadzorovano hitrim izposojanjem.

Stroge omejitve glede na najemnika je enostavno razložiti, vendar lahko zaprejo neizkoriščeno zmogljivost. Burst sposojanje izboljša izkoriščenost tako, da najemniku omogoči začasno uporabo nedejavne kvote iz skupnega bazena. Kompromis je zapletenost: nadzorne plošče morajo pokazati, kaj je bilo zajamčeno, kaj je bilo izposojeno in kdaj je bilo izposojanje preklicano.

Praktično pravilo:

• Dajte vsakemu najemniku zajamčeno izhodišče.
• Dovoli začasno izposojo iz neuporabljene skupne zmogljivosti.
• Povrnitev izposojene zmogljivosti, ko se pojavi promet z višjo prioriteto ali zajamčen promet.
• Nikoli ne dovolite, da izposojeni promet ustvari 429 na ravni ponudnika za zajamčen promet.

Ločite prometne razrede, preden se spopadejo

Vse zahteve si ne zaslužijo enakega obnašanja v čakalni vrsti. Postavite promet v profile modelov z ločenimi čakalnimi vrstami in nabori kvot.

{
  "napaka": {
    "type": "rate_limited",
    "omejevalnik": "izhod_tpm",
    "ponudnik": "ponudnik_a",
    "model_profile": "hitri klepet",
    "provider_model": "model-x",
    "retry_after_ms": 2400,
    "tenant_id": "najemnik_123",
    "api_key_id": "ključ_456",
    "request_class": "interaktiven",
    "estimated_input_tokens": 4200,
    "estimated_output_tokens": 800,
    "gateway_decision": "dopust_potem_ponudnik_zavrnjen",
    "fallback_allowed": napačno,
    "trace_id": "trace_abc"
  }
}