Scheid retry van fallback
Een retry stuurt het verzoek opnieuw naar dezelfde route omdat de fout tijdelijk kan zijn. Een fallback wijzigt de provider of het model omdat de oorspronkelijke route niet beschikbaar of ongeschikt is.
Als je beide acties behandelt als één generieke retry-lus, worden incidenten moeilijker te diagnosticeren en kan de kostenpost toenemen zonder dat de slagingskans verbetert.
- Retry: time-out, connection reset, 429 of tijdelijke 5xx-respons.
- Fallback: herhaalde providerfout, modelcapaciteitsprobleem of beleidsbeperking.
- Stop: ongeldig verzoek, niet-ondersteunde parameter of mislukte outputvalidatie.
Bouw een route-tabel die compatibel is met mogelijkheden
Fallback-modellen moeten worden gegroepeerd op capaciteit in plaats van op merk. Een vision-verzoek kan niet terugvallen op een alleen-tekstmodel, en een strikte JSON-workflow mag niet routeren naar een model dat het schema regelmatig schendt.
- Vereiste input- en outputmodaliteiten.
- Minimum context- en outputlengte.
- Ondersteuning voor tool calling en gestructureerde output.
- Maximaal acceptabele prijs en latentie.
Pas één budget op request-niveau toe
Het requestbudget moet elke retry- en fallbackpoging dekken. Controleer voordat je een volgende poging start of de resterende latency- en kostenruimte dit ondersteunt.
const routePolicy = {
maxAttempts: 3,
maxLatencyMs: 18_000,
maxEstimatedCost: 0.12,
retryOn: [408, 429, 500, 502, 503, 504],
fallbackModels: ['primary-model', 'quality-fallback', 'fast-fallback'],
};Meet fallback-kwaliteit, niet alleen beschikbaarheid
Een verzoek dat succesvol wordt afgerond kan nog steeds een productfout zijn. Volg outputvalidatie, de frequentie van gebruikerscorrecties en taakvoltooiing na een fallback-gebeurtenis.
Aanbevolen dashboard: routesucces, fallbackpercentage, p95-latentie, geschatte kosten, validatie-slaagpercentage en kwaliteitsscore per model.