Retries, timeouts en fallbacks: robuuste LLM-integraties bouwen

Large Language Models zijn krachtig, maar de API's die ze ontsluiten zijn onderhevig aan netwerklatentie, rate limits en onverwachte downtime. Zeker wanneer je complexe RAG-pipelines bouwt, kan een enkele falende API-call de hele keten breken. Om productieklare, robuuste applicaties te bouwen, moet je architectuur anticiperen op falen.

Waarom LLM API's falen

Er zijn verschillende redenen waarom een request naar een model provider mislukt:

• Rate limits (429): Je verzendt te veel requests of tokens per minuut.
• Timeouts (504): Het model heeft te lang nodig om de prompt te verwerken (vooral bij zware context windows).
• Server errors (500/503): De provider kampt met capaciteitsproblemen.

Timeouts instellen

Standaard HTTP-clients wachten vaak oneindig. Voor LLM-interacties is dit funest, omdat threads of serverless functies dan blokkeren. Implementeer altijd een harde timeout. Voor generatie-taken is 30 tot 60 seconden vaak voldoende, voor vector-embeddings hooguit 5 seconden.

Retries en Exponentiële Backoff (met Jitter)

Als een request faalt door een tijdelijke fout (zoals een 429 of 503), wil je het opnieuw proberen. Direct opnieuw proberen vergroot echter de belasting op de server. Exponentiële backoff zorgt ervoor dat de wachttijd tussen pogingen toeneemt (bijv. 1s, 2s, 4s, 8s). Voeg hier jitter (willekeurigheid) aan toe om de thundering herd problem te voorkomen.

Fallbacks: Van primaire modellen naar efficiënte alternatieven

Als na meerdere retries je primaire API (bijvoorbeeld een zware Claude Pro instantie) onbereikbaar blijft, moet je systeem naadloos overschakelen. Je kunt een fallback instellen naar een sneller, efficiënter model, zoals DeepSeek via OpenClaw, of zelfs een lokaal gehost model. Dit garandeert uptime, zij het soms met een iets lagere redenatiekwaliteit, wat voor de meeste webapplicaties acceptabel is als noodoplossing.

Alles samenvoegen (Pseudocode)

Hieronder zie je hoe deze concepten samenkomen in een robuuste wrapper-functie voor LLM-calls:

function callLLMWithResilience(prompt, idempotencyKey) {
const maxRetries = 3;
const baseDelayMs = 1000;
const primaryModel = "claude-3-opus";
const fallbackModel = "deepseek-chat";

for (int attempt = 0; attempt <= maxRetries; attempt++) {
try {
// Harde timeout instellen per call
const response = api.complete({
model: primaryModel,
prompt: prompt,
timeout: 30000,
headers: { "Idempotency-Key": idempotencyKey }
});
return response;

} catch (error) {
if (!isTransientError(error)) {
throw error; // Stop direct bij auth of invalid prompt errors
}

if (attempt === maxRetries) {
// Alle retries op primair model gefaald, initieer fallback
console.warn("Primary model failed, falling back to alternative...");
return callFallbackModel(fallbackModel, prompt, idempotencyKey);
}

// Exponentiële backoff met jitter berekenen
const delay = (baseDelayMs * Math.pow(2, attempt)) + randomJitter(0, 500);
sleep(delay);
}
}
}

Door deze patronen consequent toe te passen, voorkom je haperingen in je applicaties en zorg je voor een stabiele gebruikerservaring. Wil je meer weten over de bredere context van schaalbare cloudoplossingen? Bekijk dan onze inzichten op consultancy.llmnet.nl voor geavanceerde architectuurpatronen.