Adskil retry fra fallback
En retry sender anmodningen til den samme rute igen, fordi fejlen kan være midlertidig. En fallback skifter provider eller model, fordi den oprindelige rute er utilgængelig eller uegnet.
Når begge handlinger behandles som én generisk retry-løkke, bliver hændelser sværere at diagnosticere, og omkostningerne kan vokse uden at forbedre succesraten.
- Retry: timeout, connection reset, 429 eller midlertidigt 5xx-svar.
- Fallback: gentagen provider-fejl, modelkapacitetsproblem eller policy-begrænsning.
- Stop: ugyldig anmodning, ikke-understøttet parameter eller fejlet output-validering.
Byg en kapabilitetskompatibel routetabel
Fallback-modeller bør grupperes efter kapabilitet frem for brand. En vision-anmodning kan ikke falde tilbage til en rent tekstbaseret model, og en strikt JSON-workflow bør ikke routes til en model, der jævnligt bryder skemaet.
- Påkrævede input- og output-modaliteter.
- Minimum kontekst- og outputlængde.
- Understøttelse af tool calling og struktureret output.
- Maksimal acceptabel pris og latenstid.
Anvend ét budget på anmodningsniveau
Anmodningsbudgettet bør dække alle retry- og fallback-forsøg. Før et nyt forsøg starter, skal du kontrollere, om det resterende laten- og omkostningsbudget kan bære 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 kun tilgængelighed
En anmodning, der returnerer succesfuldt, kan stadig være et produktmæssigt fejlresultat. Spor outputvalidering, brugerens korrektionsrate og fuldførelse af opgaven efter et fallback-event.
Anbefalet dashboard: route-success, fallback-rate, p95-latenstid, estimeret omkostning, validerings-godkendelsesrate og kvalitets-score pr. model.