Pålidelig LLM API-routing: Timeouts, genforsøg og modeltilbagefald uden semantiske regression
En praktisk arkitektur til klassificering af LLM API-fejl, håndhævelse af ét latensbudget, valg af kompatible fallback-modeller, beskyttelse af bivirkninger og validering af alle accepterede svar.
En fallback-anmodning lykkes ikke, blot fordi en anden model returnerede HTTP 200. Erstatningen kan overskride det oprindelige latensbudget, udelade påkrævede JSON-felter, kalde et andet værktøj eller producere et svar med væsentligt anderledes semantik. Pålidelig LLM API-routing kræver derfor mere end en ordnet liste over modeller: den kræver en kontrakt, en fejlklassificering, en afgrænset forsøgspolitik og validering før accept.
Den centrale regel er enkel: prøv kun igen, når fejlen er plausibelt midlertidig, og fald først tilbage, når den næste rute stadig kan opfylde den oprindelige anmodningskontrakt.
Definer rutekontrakten, før du vælger modeller
Start med at beskrive, hvad et vellykket svar skal give. Denne routingkontrakt skal være maskinlæsbar og knyttet til hver arbejdsbyrde eller anmodningsklasse.
Kontrakten bør dække nødvendige modaliteter, kontekstkapacitet, værktøjsstøtte, struktureret outputadfærd, acceptable modelklasser, maksimale omkostninger og ende-til-ende-deadline. Tilføj applikationsspecifikke begrænsninger, hvor det er nødvendigt, såsom tilladte områder, minimum outputlængde eller en påkrævet finishårsag.
Anbefaling: Oprethold separate, testede rutegrupper for almindelig tekst, skemabegrænset output, brug af værktøj, vision og langkontekstanmodninger. En model, der er et acceptabelt tekstfaldback, er ikke automatisk et acceptabelt fallback for værktøjsopkald eller billedinput.
Klassificer fejlen, før du gør noget
Godkendelsesfejl, forkert udformede anmodninger, hastighedsgrænser og serverfejl kræver forskellige svar. At behandle ethvert ikke-successvar, som kan gentages, spilder kapacitet og kan skjule defekter.
Faktum: mislykkede satsbegrænsede anmodninger kan stadig tælle mod udbydergrænser. Aggressive øjeblikkelige genforsøg kan derfor uddybe droslingen i stedet for at løse den. Genforsøg optager også yderligere kapacitet under et udfald, og genforsøgspolitikker på flere applikationslag kan multiplicere den resulterende belastning.
Anbefaling: Lad ét lags eget modelgenerering forsøge igen. I en typisk arkitektur er AI API-gatewayen den rigtige ejer, fordi den ser rutesundhed, forsøgshistorik, latenstid og omkostninger. Deaktiver automatiske genforsøg i klienter på lavere niveau, hvor det er muligt, eller tæl dem eksplicit i det samme forsøgsbudget.
Brug ét ende-til-ende-ventebudget
Timeouts pr. forsøg er utilstrækkelige. Tre forsøg med fem sekunders timeout kan forvandle en tilsigtet fem sekunders operation til en femten sekunders respons, før backoff og validering er inkluderet.
Optag en absolut deadline, når anmodningen kommer ind i gatewayen. Inden hvert forsøg skal du beregne den resterende tid:
resterende = deadline - nuværende_tid
påkrævet = connect_allowance + generation_allowance + validation_allowance
hvis resterende < påkrævet:
stop_without_launching_ another_temptFor en otte sekunders deadline kan en rimelig indledende allokering reservere 300 ms til gateway-arbejde og endelig validering, tillade op til 4,5 sekunder for den primære rute og beholde cirka 3,2 sekunder for én reserve. Disse værdier er et eksempel, ikke et benchmark. De skal udledes af målte latensfordelinger for de faktiske udbydere, modeller, regioner og outputstørrelser.
Brug afgrænset eksponentiel backoff med jitter til forbigående genforsøg:
forsinkelse = random(0, min(cap, base * 2^retry_index))Tip til udbyderens genforsøg, såsom en værdi for genforsøg efter, bør have forrang, når de passer inden for den resterende deadline. Stop efter et lille antal forsøg. En almindelig politik er ét primært forsøg plus én fallback, med et valgfrit genforsøg på samme rute kun for en tidlig forbindelsesfejl, der ikke kunne have genereret fakturerbart output.
Trade-off: sekventiel fallback forbedrer tilgængeligheden, men øger haleforsinkelsen. Parallelle eller sikrede anmodninger kan reducere ventetiden under opbremsninger, men de bruger mere kapacitet og kan pådrage sig gebyrer for flere succesfulde generationer. Afdækning bør begrænses til latenstidskritiske, bivirkningsfri arbejdsbelastninger med annullering og omkostningskontrol.
Vælg fallbacks efter kapacitet, ikke rang
En reservetabel skal kode for kompatibilitet i stedet for en global præferencerækkefølge. Filtrer kandidatruter mod kontrakten, før du overvejer sundhed, latenstid eller pris.
kandidater = ruter
.filter(understøtter_påkrævede_modaliteter)
.filter(context_limit >= estimeret_input_størrelse)
.filter(understøtter_påkrævede_værktøjer)
.filter(understøtter_anmodet_skematilstand)
.filter(model_klasse i tilladte_modelklasser)
.filter(estimated_cost <= resterende_cost_budget)
.filter(ikke_midlertidigt_undertrykt)
valgt = rang(kandidater, sundhed, latens, omkostninger)Understøttelse af struktureret output fortjener eksplicit test. Selv når to ruter annoncerer for skemabegrænset generering, kan de understøtte forskellige JSON Schema-undersæt eller fortolke edge-tilfælde forskelligt. Værktøjskompatible modeller kan ligeledes afvige i værktøjsvalg, argumentkonstruktion og parallelopkaldsadfærd.
Faktum: Skift af modelfamilier kan bevare transporttilgængeligheden, mens stil, ræsonnementkvalitet, sikkerhedsadfærd, tokenisering og værktøjsvalg ændres. HTTP-succes er ikke bevis på semantisk ækvivalens.
Forudsigelse: efterhånden som modelkataloger udvides, vil produktionsrutingspolitikker i stigende grad bruge versionerede kapacitetsprofiler og arbejdsbelastningsspecifikke accepttests i stedet for statiske modellister. Behandl dette som en designretning, ikke en garanti for udbyderens adfærd.
Valider svaret, før du accepterer det
Kør hvert svar, inklusive det primære svar, gennem den samme acceptpipeline. Validering bør finde sted, før resultatet cachelagres, faktureres internt som vellykket eller videregives til en værktøjsudøver.
- Bekræft, at transporten er fuldført, og svarkonvolutten kan parses.
- Tjek afslutningsårsagen, og afvis trunkering, når komplet output er påkrævet.
- Valider struktureret output i forhold til det originale skema.
- Bekræft påkrævede felter, enum-værdier og applikationsinvarianter.
- Tillad kun registrerede værktøjsnavne og valider argumenter mod hvert værktøjsskema.
- Anvend arbejdsbelastningsspecifikke semantiske kontroller, hvor falsk accept ville være dyrt.
For fakturaudtræk kan semantiske kontroller kræve en ikke-negativ total, en understøttet valutakode og linjeposttotaler inden for en eksplicit defineret tolerance. For klassificering skal du kræve en etiket fra det tilladte sæt. Til kodegenerering kan parsing eller kompilering være passende. Disse kontroller beviser ikke kvalitet, men de forhindrer forudsigelige kontraktbrud i at blive behandlet som succeser.
Reparer ikke alle forkerte svar stille og roligt. Deterministisk normalisering, såsom fjernelse af harmløse omgivende blanktegn, kan være acceptabel. At gætte manglende økonomiske felter eller omskrivningsværktøjsargumenter ændrer modellens betydning og burde udløse afvisning eller menneskelig gennemgang.
Særskilt generationsforsøg fra bivirkninger
LLM-anmodninger bruger almindeligvis HTTP POST, som ikke er iboende idempotent. Endnu vigtigere er det, at et modelsvar kan igangsætte en ekstern handling, såsom opkrævning af en betalingsmetode, afsendelse af en besked, oprettelse af en billet eller ændring af infrastruktur. At forsøge at generere igen og afspille den handling er separate beslutninger.
Tildel et operations-id ved applikationsgrænsen og et forsøgs-id til hvert modelkald. Vedvarende værktøjsudførelsestilstand mod en deterministisk nøgle, såsom:
execution_key = operation_id + tool_name + canonical_arguments_hashFør du udfører et værktøj, skal du kontrollere, om nøglen er afventende, fuldført eller mislykkedes. Returner det gemte resultat for en fuldført udførelse i stedet for at køre det igen. For operationer, hvis argumenter lovligt kan ændre sig, kræves godkendelse på applikationsniveau eller et nyt operations-id.
En tvetydig timeout kræver særlig håndtering. Hvis forbindelsen mislykkes, efter at en anmodning blev overført, ved gatewayen muligvis ikke, om genereringen fandt sted. En udbyder-understøttet idempotensnøgle kan hjælpe, når den er tilgængelig. Ellers skal du logge resultatet som ukendt og anvende en arbejdsbelastningsspecifik genafspilningspolitik i stedet for at antage, at der ikke er sket noget.
Undtryk usunde ruter og afslør hvert eneste forsøg
En strømafbryder eller midlertidig helbredsundertrykkelse forhindrer hver ny anmodning i at genfinde den samme fejlende rute. Åbn kredsløbet efter en defineret fejlrate eller konsekutiv fejltærskel, og indgiv derefter begrænsede prober i en halvåben tilstand. Juster tærskler efter rute og fejlklasse, så en forkert udformet klientanmodning ikke kan få en sund model til at se utilgængelig ud.
Optag én hændelse på anmodningsniveau og én hændelse pr. forsøg. Nyttige felter omfatter operations-id, forsøgs-id, valgt udbyder og model, fejlklasse, statuskode, latens, token-antal, anslåede omkostninger, reserveårsag, valideringsresultat, kredsløbstilstand og endeligt resultat. Rediger eller hash prompter, output og værktøjsargumenter i henhold til deres følsomhed og krav til opbevaring.
Nyttige operationelle metrics omfatter fallback-rate, forsøg pr. gennemført anmodning, deadline-udmattelsesrate, valideringsafvisningsrate, tvetydige resultater, pris pr. accepteret svar og latens ad den endelige rute. En stigende HTTP-succesrate sammen med en stigende valideringsafvisningsrate er en advarsel om, at transporttilgængelighed maskerer kontraktfejl.
Tjekliste for udrulning af produktion
- Definer en versioneret routingkontrakt for hver arbejdsbelastningsklasse.
- Kort udbyderfejl i permanente, forbigående, inkompatible, ugyldige svar og tvetydige kategorier.
- Vælg én genforsøgs ejer og begræns antallet af forsøg.
- Formidle en absolut deadline gennem gateway, udbyderklient, validering og værktøjsudførelse.
- Byg kapacitetstestede reservegrupper i stedet for én global modelkæde.
- Valider skemaer, værktøjskald, afslutningsårsager og domæneinvarianter.
- Deduplikér bivirkninger med betjenings- og udførelsesnøgler.
- Tilføj ruteundertrykkelse med afgrænsede halvåbne sonder.
- Logforsøgsforsinkelse, tokens, omkostninger, fejl og acceptresultater.
- Inject timeouts, 429s, udvalgte 5xx-fejl, forkert udformet JSON, kontekstoverløb og langsomme succeser i iscenesættelse.
Begynd med en primær rute og én kompatibel reserve for en enkelt lavrisiko-arbejdsbyrde. Sammenlign accepteret svarkvalitet, ventetid og omkostninger, før du udvider politikken. Målet er ikke den højest mulige fallback rate. Det er et afgrænset system, der enten returnerer et svar, der opfylder den oprindelige kontrakt eller fejler klart, før det forårsager dobbeltarbejde eller semantisk skade.
Relateret læsning
- tidligere API-testnote
- href="https://model-gate.com/da/blog/article-1-1/">forrige engelsksprogede artikel