Playbook for fallback med flere modeller for pålitelige AI API-er

Viktige poenger

Prøv samme rute på nytt bare ved midlertidige feil som timeouts og 429-svar.

Fail over til en modell som oppfyller de samme kravene til kapasitet og utdata-kontrakt.

Sett et maksimalt kostnads- og latensbudsjett for hele forespørselen, ikke for hvert forsøk.

Logg leverandør, modell, feilkategori, antall retries og endelig rute for hver forespørsel.

Skill retry fra fallback

En retry sender forespørselen til samme rute igjen fordi feilen kan være midlertidig. Et fallback skifter leverandør eller modell fordi den opprinnelige ruten er utilgjengelig eller uegnet.

Når begge handlingene behandles som én generell retry-løkke, blir hendelser vanskeligere å feilsøke, og kostnaden kan mangedobles uten at suksessraten forbedres.

Retry: timeout, tilkoblingen ble tilbakestilt, 429 eller midlertidig 5xx-svar.
Fallback: gjentatt leverandørfeil, kapasitetsproblem i modellen eller policybegrensning.
Stopp: ugyldig forespørsel, ikke-støttet parameter eller mislykket validering av utdata.

Bygg en rutetabell som er kompatibel med kapasitet

Fallback-modeller bør grupperes etter kapasitet, ikke etter merke. En forespørsel med bilder kan ikke falle tilbake til en tekstmodell, og en streng JSON-arbeidsflyt bør ikke rutes til en modell som regelmessig bryter skjemaet.

Påkrevde input- og output-modaliteter.
Minimum kontekst og lengde på utdata.
Støtte for tool calling og strukturerte utdata.
Maksimalt akseptabel pris og latens.

Bruk ett budsjett på forespørselsnivå

Forespørselsbudsjettet bør dekke alle retry- og fallback-forsøk. Før et nytt forsøk startes, må du sjekke om gjenværende latens- og kostnadsbudsjett kan støtte det.

const routePolicy = {
  maxAttempts: 3,
  maxLatencyMs: 18_000,
  maxEstimatedCost: 0.12,
  retryOn: [408, 429, 500, 502, 503, 504],
  fallbackModels: ['primary-model', 'quality-fallback', 'fast-fallback'],
};

Mål fallback-kvalitet, ikke bare tilgjengelighet

En forespørsel som returnerer vellykket, kan fortsatt være en produktfeil. Spor utdata-validering, brukerens korreksjonsrate og fullføring av oppgaver etter en fallback-hendelse.

Anbefalt dashboard: rutesuksess, fallback-rate, p95-latens, estimert kostnad, valideringsrate og kvalitetsscore per modell.

Ofte stilte spørsmål

Bør hver mislykkede AI-forespørsel bruke en fallback-modell?

Nei. Ugyldige parametere, ikke-støttede input og mislykkede sikkerhetssjekker bør stoppe umiddelbart. Fallback er passende når en annen kompatibel rute realistisk kan fullføre den samme oppgaven.

Hvor mange fallback-forsøk bør en AI-forespørsel tillate?

De fleste interaktive arbeidsflyter bør holde totalen til to eller tre forsøk. Den riktige grensen avhenger av gjenværende latensbudsjett, oppgaveverdi og estimert kostnad.