Pålitelig LLM API-ruting: tidsavbrudd, gjenforsøk og modelltilbakeslag uten semantiske regresjoner
En praktisk arkitektur for å klassifisere LLM API-feil, håndheve ett latensbudsjett, velge kompatible reservemodeller, beskytte bivirkninger og validere alle aksepterte svar.
En reserveforespørsel er ikke vellykket bare fordi en annen modell returnerte HTTP 200. Erstatningen kan overskride det opprinnelige latensbudsjettet, utelate nødvendige JSON-felt, kalle et annet verktøy eller gi et svar med vesentlig forskjellig semantikk. Pålitelig LLM API-ruting krever derfor mer enn en ordnet liste over modeller: den krever en kontrakt, en feilklassifisering, en policy for begrenset forsøk og validering før aksept.
Den sentrale regelen er enkel: prøv bare på nytt når feilen er sannsynlig midlertidig, og fall tilbake bare når neste rute fortsatt kan tilfredsstille den opprinnelige forespørselskontrakten.
Definer rutekontrakten før du velger modeller
Start med å beskrive hva et vellykket svar må gi. Denne rutekontrakten bør være maskinlesbar og vedlagt hver arbeidsbelastning eller forespørselsklasse.
{
"workload": "invoice_extraction",
"modalities": ["tekst", "bilde"],
"max_input_tokens": 50000,
"requires_tools": usant,
"structured_output": {
"required": sant,
"schema_id": "faktura-v3",
"streng": sant
},
"allowed_model_classes": ["dokumentutvinning"],
"max_cost_usd": 0,08,
"deadline_ms": 8000
}Kontrakten bør dekke nødvendige modaliteter, kontekstkapasitet, verktøystøtte, strukturert produksjonsatferd, akseptable modellklasser, maksimale kostnader og ende-til-ende-fristen. Legg til programspesifikke begrensninger der det er nødvendig, for eksempel tillatte områder, minimum utdatalengde eller en nødvendig årsak til finish.
Anbefaling: oppretthold separate, testede rutegrupper for ren tekst, skjemabegrensede utdata, verktøybruk, visjon og langkontekstforespørsler. En modell som er en akseptabel tekstreserve, er ikke automatisk en akseptabel reserve for verktøykalling eller bildeinndata.
Klassifiser feilen før du gjør noe
Autentiseringsfeil, misformede forespørsler, hastighetsgrenser og serverfeil krever forskjellige svar. Å behandle hver ikke-suksessrespons som omprøvebar sløser kapasitet og kan skjule defekter.
Fakta: mislykkede satsbegrensede forespørsler kan fortsatt telle mot leverandørgrensene. Aggressive umiddelbare gjenforsøk kan derfor gjøre gassen dypere i stedet for å løse den. Forsøk på nytt bruker også ekstra kapasitet under et strømbrudd, og retningslinjer for gjenforsøk på flere applikasjonslag kan multiplisere den resulterende belastningen.
Anbefaling: la ett lags egen modellgenerering prøve på nytt. I en typisk arkitektur er AI API-gatewayen den rette eieren fordi den ser rutehelse, forsøkshistorikk, latens og kostnader. Deaktiver automatiske gjenforsøk i klienter på lavere nivå der det er mulig, eller tell dem eksplisitt i det samme forsøksbudsjettet.
Bruk ett ende-til-ende-forsinkelsesbudsjett
Tidsavbrudd per forsøk er utilstrekkelige. Tre forsøk med fem sekunders tidsavbrudd kan gjøre en tiltenkt operasjon på fem sekunder til en femten sekunders respons, før tilbakekobling og validering er inkludert.
Registrer en absolutt frist når forespørselen kommer inn i gatewayen. Beregn gjenværende tid før hvert forsøk:
resterende = frist - gjeldende_tid
påkrevd = connect_allowance + generation_allowance + validation_allowance
hvis gjenværende < nødvendig:
stop_without_launching_another_temptFor en frist på åtte sekunder kan en rimelig innledende tildeling reservere 300 ms for gatewayarbeid og endelig validering, tillate opptil 4,5 sekunder for den primære ruten, og beholde omtrent 3,2 sekunder for én reserve. Disse verdiene er et eksempel, ikke en målestokk. De må utledes fra målte latensfordelinger for de faktiske leverandørene, modellene, regionene og utdatastørrelsene.
Bruk begrenset eksponentiell backoff med jitter for forbigående forsøk:
forsinkelse = random(0, min(cap, base * 2^retry_index))Tips fra leverandøren, for eksempel en verdi for et nytt forsøk, bør ha forrang når de passer innenfor den gjenværende fristen. Stopp etter et lite antall forsøk. En vanlig policy er ett primært forsøk pluss en reserve, med et valgfritt forsøk på samme rute bare for en tidlig tilkoblingsfeil som ikke kunne ha generert fakturerbar utgang.
Avveining: Sekvensiell fallback forbedrer tilgjengeligheten, men øker haleforsinkelsen. Parallelle eller sikrede forespørsler kan redusere ventetiden under forsinkelser, men de bruker mer kapasitet og kan påløpe kostnader for flere vellykkede generasjoner. Sikring bør begrenses til ventetidskritiske, bivirkningsfrie arbeidsbelastninger med kansellering og kostnadskontroll.
Velg fallbacks etter evne, ikke rangering
En reservetabell bør kode for kompatibilitet i stedet for en global preferanserekkefølge. Filtrer kandidatruter mot kontrakten før du vurderer helse, ventetid eller pris.
kandidater = ruter
.filter(supports_required_modalities)
.filter(context_limit >= estimated_input_size)
.filter(støtter_påkrevde_verktøy)
.filter(støtter_requested_schema_mode)
.filter(modellklasse i tillatte_modellklasser)
.filter(estimated_cost <= resterende_kostnadsbudsjett)
.filter(ikke_temporarily_suppressed)
valgt = rangering(kandidater, helse, ventetid, kostnad)Støtte for strukturert utgang fortjener eksplisitt testing. Selv når to ruter annonserer skjemabegrenset generering, kan de støtte forskjellige JSON Schema-undersett eller tolke edge-tilfeller annerledes. Verktøykompatible modeller kan likeledes variere i verktøyvalg, argumentkonstruksjon og parallelloppføring.
Fakta: Bytte av modellfamilier kan bevare transporttilgjengeligheten samtidig som man endrer stil, resonnementkvalitet, sikkerhetsatferd, tokenisering og verktøyvalg. HTTP-suksess er ikke bevis på semantisk ekvivalens.
Forutsigelse: etter hvert som modellkatalogene utvides, vil retningslinjer for produksjonsruting i økende grad bruke versjonerte funksjonsprofiler og arbeidsbelastningsspesifikke aksepttester i stedet for statiske modelllister. Behandle dette som en designretning, ikke en garanti for leverandørens atferd.
Valider svaret før du godtar det
Kjør hvert svar, inkludert det primære svaret, gjennom samme akseptpipeline. Validering bør skje før resultatet bufres, faktureres internt som vellykket eller sendes til en verktøyutøver.
- Bekreft at transporten er fullført, og at svarkonvolutten kan analyseres.
- Sjekk årsaken til ferdigstillelse og avvis avkorting når fullstendig utdata kreves.
- Valider strukturert utdata mot det opprinnelige skjemaet.
- Bekreft obligatoriske felt, enum-verdier og applikasjonsinvarianter.
- Tillat bare registrerte verktøynavn og valider argumenter mot hvert verktøyskjema.
- Bruk arbeidsbelastningsspesifikke semantiske kontroller der falsk aksept vil være kostbart.
For fakturautvinning kan semantiske kontroller kreve en ikke-negativ totalsum, en støttet valutakode og linjeelementtotaler innenfor en eksplisitt definert toleranse. For klassifisering kreves en etikett fra det tillatte settet. For kodegenerering kan parsing eller kompilering være passende. Disse kontrollene beviser ikke kvalitet, men de forhindrer at forutsigbare kontraktsbrudd blir behandlet som suksesser.
Ikke reparer alle feilaktige svar stille. Deterministisk normalisering, for eksempel fjerning av ufarlig mellomrom rundt, kan være akseptabelt. Å gjette manglende økonomiske felt eller argumenter for omskrivingsverktøy endrer modellens betydning og bør utløse avvisning eller menneskelig vurdering.
Separate generasjonsforsøk fra bivirkninger
LLM-forespørsler bruker vanligvis HTTP POST, som ikke er iboende idempotent. Enda viktigere er det at et modellsvar kan sette i gang en ekstern handling som å belaste en betalingsmetode, sende en melding, opprette en billett eller endre infrastruktur. Å prøve å generere på nytt og spille av handlingen på nytt er separate avgjørelser.
Tildel en operasjons-ID ved applikasjonsgrensen og en forsøks-ID til hvert modellanrop. Vedvarende verktøyutførelsestilstand mot en deterministisk nøkkel, for eksempel:
execution_key = operation_id + tool_name + canonical_arguments_hashFør du kjører et verktøy, sjekk om nøkkelen venter, fullført eller mislyktes. Returner det lagrede resultatet for en fullført kjøring i stedet for å kjøre det på nytt. For operasjoner hvis argumenter kan endres legitimt, krever godkjenning på programnivå eller en ny operasjons-ID.
En tvetydig tidsavbrudd krever spesiell håndtering. Hvis tilkoblingen mislykkes etter at en forespørsel ble overført, kan det hende at gatewayen ikke vet om generering skjedde. En leverandørstøttet idempotensnøkkel kan hjelpe når den er tilgjengelig. Ellers logger du utfallet som ukjent og bruker en arbeidsbelastningsspesifikk replay-policy i stedet for å anta at ingenting har skjedd.
Undtrykk usunne ruter og avslør hvert forsøk
En strømbryter eller midlertidig helseundertrykkelse hindrer hver ny forespørsel fra å gjenoppdage den samme feilende ruten. Åpne kretsen etter en definert feilrate eller terskel for fortløpende feil, og la deretter begrensede prober i halvåpen tilstand. Juster terskler etter rute og feilklasse slik at en feilformet klientforespørsel ikke kan få en sunn modell til å virke utilgjengelig.
Ta opp én hendelse på forespørselsnivå og én hendelse per forsøk. Nyttige felt inkluderer operasjons-ID, forsøks-ID, valgt leverandør og modell, feilklasse, statuskode, ventetid, tokenantall, estimert kostnad, reserveårsak, valideringsresultat, kretstilstand og endelig utfall. Rediger eller hash forespørsler, utdata og verktøyargumenter i henhold til deres følsomhet og oppbevaringskrav.
Nyttige operasjonelle beregninger inkluderer reservefrekvens, forsøk per fullført forespørsel, utmattelsesfrekvens for tidsfrister, valideringsavvisningsfrekvens, tvetydige utfall, kostnad per akseptert svar og latens etter endelig rute. En økende HTTP-suksessrate sammen med en økende valideringsavvisningsrate er en advarsel om at transporttilgjengelighet maskerer kontraktsfeil.
Sjekkliste for produksjonsutrulling
- Definer en versjonert rutekontrakt for hver arbeidsbelastningsklasse.
- Kartlegg leverandørfeil i permanente, forbigående, inkompatible, ugyldige og tvetydige kategorier.
- Velg ett nytt forsøk på eieren og begrense antall forsøk.
- Formidle en absolutt frist gjennom gateway, leverandørklient, validering og verktøykjøring.
- Bygg kapasitetstestede reservegrupper i stedet for én global modellkjede.
- Valider skjemaer, verktøykall, sluttårsaker og domeneinvarianter.
- Dedupliserte bivirkninger med operasjons- og utførelsesnøkler.
- Legg til ruteundertrykkelse med avgrensede halvåpne sonder.
- Latens på loggforsøksnivå, tokens, kostnader, feil og akseptresultater.
- Injiser tidsavbrudd, 429s, utvalgte 5xx-feil, feilutformet JSON, kontekstoverflyt og langsomme suksesser i iscenesettelsen.
Begynn med en primær rute og én kompatibel reserve for én enkelt arbeidsbelastning med lav risiko. Sammenlign akseptert svarkvalitet, ventetid og kostnader før du utvider policyen. Målet er ikke høyest mulig fallback rate. Det er et avgrenset system som enten returnerer et svar som tilfredsstiller den opprinnelige kontrakten eller feiler klart før det forårsaker duplikatarbeid eller semantisk skade.
Relatert lesing
- tidligere API-testnotat
- href="https://model-gate.com/en/blog/article-1-1/">forrige engelskspråklige artikkel