Bij het bouwen van bedrijfskritische toepassingen op basis van grote taalmodellen (Large Language Models) vertrouwen organisaties in toenemende mate op externe API-diensten. Veel ontwikkelaars en IT-architecten gaan er stilzwijgend van uit dat een Service Level Agreement (SLA) van een LLM-provider dezelfde garanties biedt als een traditionele IaaS- of SaaS-dienst. In de praktijk blijkt deze aanname echter vaak tot teleurstellingen te leiden. De fysieke en logische karakteristieken van generatieve AI-infrastructuur verschillen fundamenteel van klassieke REST-API's.
In dit artikel analyseren we wat een SLA bij een LLM-provider feitelijk belooft, welke vormen van uitval of prestatieverlies buiten de officiële afspraken vallen en waarom openbare statuspagina's zelden het volledige beeld tonen. Daarnaast bekijken we hoe financiële compensatieregelingen werken, hoe je zelf de werkelijke bruikbaarheid van een model meet, en hoe je door een doordachte architectuur je afhankelijkheid van één enkele aanbieder minimaliseert.
Wat een LLM-SLA Wel en Niet Belooft
Een Service Level Agreement is een juridisch en operationeel kader waarin een dienstverlener afspraken vastlegt over prestaties en beschikbaarheid. Bij traditionele cloudservices garandeert een SLA meestal dat het HTTP-endpoint binnen een afgesproken percentage van de tijd correct reageert met een succesvolle statuscode. Wanneer we naar LLM-providers kijken, reikt het juridische vangnet echter minder ver dan de operationele behoefte van een bedrijf.
De meeste SLA's garanderen uitsluitend netwerkbereikbaarheid van het API-gateway-endpoint. Zodra de gateway bereikbaar is en een geldig HTTP-antwoord retourneert, telt dit volgens de contractuele definitie als beschikbaarheid. Dit betekent dat vele vormen van functionele onbruikbaarheid formeel niet als downtime worden geregistreerd.
Systeemdegradatie versus Totale Uitval
In het domein van generatieve AI is de grens tussen beschikbaarheid en onbruikbaarheid fluïde. Een LLM-endpoint kan een HTTP 200-statuscode teruggeven, terwijl de interne verwerkingstijd verdubbelt of vertienvoudigt. Extreme verhogingen van de responstijd (latency) en vertragingen in het genereren van de eerste token (Time To First Token) vallen vrijwel nooit onder de contractuele definitie van een storing.
Voor een realtime conversatie-interface of geautomatiseerde workflow betekent een vertraging van tien seconden in feite hetzelfde als een time-out. Toch registreert de provider dit als een geslaagde aanroep. Pas wanneer je zelf meet en strakke limieten stelt, kun je dit onderscheid scherp in kaart brengen. Bekijk voor meer details onze richtlijnen voor timeouts en cancellation.
Capaciteitslimieten en Rate Limiting (HTTP 429 & 503)
Een veelvoorkomend fenomeen bij LLM-diensten is het optreden van capaciteitstekorten op de inferentie-clusters. Dit uit zich in HTTP 429 (Too Many Requests) of HTTP 503 (Service Unavailable) meldingen. Hoewel de applicatie op dat moment geen verzoeken kan verwerken, sluiten de meeste providers foutmeldingen door capaciteitsbeperkingen uit van de SLA-berekening. De provider argumenteert dat de gateway functioneert, maar dat de specifieke capaciteit tijdelijk verzadigd is.
Preview-, Beta- en Experimentele Modellen
Providers brengen in hoog tempo nieuwe modelversies uit, vaak gelabeld als preview, beta of experimenteel. In vrijwel alle SLA-documenten worden deze specifieke endpoints expliciet uitgesloten van elke vorm van beschikbaarheidsgarantie. Indien een bedrijf een kritisch proces koppelt aan een preview-model, draagt de afnemer het volledige risico van onverwachte uitval of abrupte wijzigingen.
Deprecatie en Wijzigingen in Modelversies
Een unieke uitdaging bij LLM's is de levenscyclus van modelversies. Wanneer een provider een model retireert of vervangt, verandert vaak ook de outputkarakteristiek. Formeel valt het beëindigen van een modelversie buiten de SLA, mits de provider de aankondigingstermijn in acht neemt. Meer informatie over de impact hiervan vindt u op ons overzicht van modelversies en deprecatie.
Uptime van het Endpoint versus Bruikbaarheid van het Model
Het scheiden van netwerkbeschikbaarheid en functionele bruikbaarheid is essentieel voor het beoordelen van LLM-prestaties. Een endpoint kan perfect bereikbaar zijn, terwijl het model inhoudelijk of technisch onbruikbaar is.
De onderstaande tabel geeft een overzicht van situaties waarin de status van de API en de daadwerkelijke bruikbaarheid van elkaar afwijken:
| Scenario | API Status (SLA Perspectief) | Werking Applicatie | Telt als Downtime in SLA? |
|---|---|---|---|
| HTTP 500 Server Error | Niet beschikbaar | Volledige storing | Ja |
| Extreme Latency (TTFT > 30s) | Beschikbaar (200 OK) | Onbruikbaar (Time-out) | Nee (uitgesloten) |
| HTTP 429 Rate Limit ex-quota | Beschikbaar | Geweigerd verzoek | Nee |
| Model levert ongeldige JSON | Beschikbaar (200 OK) | Functionele fout | Nee |
Wat Statuspagina's Laten Zien en Waarom Je Zelf Moet Meten
Vrijwel elke grote AI-aanbieder onderhoudt een openbare statuspagina. Hoewel deze pagina's nuttig zijn voor een globaal inzicht bij grote netwerkstoringen, zijn ze ongeschikt als instrument voor nauwkeurige kwaliteitsbewaking.
Statuspagina's worden in de regel gevoed door geaggregeerde meetpunten of handmatige invoer door het incidententeam van de provider. Kleine, regionale of account-specifieke storingen worden hierop zelden zichtbaar. [Aanname: statuspagina's tonen hoofdzakelijk pas storingen wanneer een significant percentage van het globale verkeer gedurende langere tijd uitvalt.] Bovendien meten deze pagina's vaak alleen eenvoudige health-check-requests, die niet representatief zijn voor complexe prompts.
Om een realistisch beeld te krijgen van de prestaties, is eigen monitoring noodzakelijk. Door het opzetten van synthetische probes en het meten van latency en foutpercentages in je eigen productieomgeving, bouw je een objectief dossier op. Praktische richtlijnen voor het inrichten van deze metingen vindt u via de pagina over snelheid meten.
De Werking en Beperkingen van Service Credits
Wanneer een provider er niet in slaagt om de gegarandeerde uptime te behalen, treedt de compensatieregeling van de SLA in werking. Deze compensatie bestaat in vrijwel alle gevallen uit Service Credits — kortingen op toekomstige facturen.
Het is belangrijk om te begrijpen dat Service Credits een zeer beperkte dekking bieden. De hoogte van de credit is gekoppeld aan de maandelijkse uitgaven bij de betreffende provider voor dat specifieke endpoint. Indien een bedrijf een bescheiden maandbedrag uitgeeft en het endpoint valt urenlang uit, bedraagt de credit vaak niet meer dan een klein percentage van die specifieke maandfactuur.
De werkelijke bedrijfsschade — zoals gederfde omzet, reputatieschade of stilvallende bedrijfsprocessen — wordt door de provider expliciet uitgesloten in de algemene voorwaarden. Een SLA is daarmee een instrument voor risicospreiding op factuurniveau, geen verzekering tegen bedrijfsschade. Voor juridische verdieping over deze afspraken verwijzen we naar onze analyse van AI-contracten en SLA.
Het Vormgeven van Je Eigen SLA en Foutbudget
Aangezien de SLA van de provider ontoereikend is voor het waarborgen van de totale applicatiekwaliteit, moet je als engineer een eigen normering opstellen. Dit begint met het bepalen van een foutbudget (Error Budget) en het exact definiëren van wat jouw systeem als een geldige response beschouwt.
Stel voor jouw toepassing vast welke responstijden accepteerbaar zijn. Een doeltreffende definitie van een storing omvat niet alleen harde netwerkfouten (HTTP 5xx), maar ook latency-overschrijdingen, capaciteitsweigeringen en inhoudelijke invaliditeit. Bereken de beschikbaarheid niet uitsluitend op maandbasis, maar hanteer kortere en voortschrijdende meetvensters van bijvoorbeeld 24 uur. Zie hiervoor ook de handleiding over observability en logging.
Architectuurpatronen ter Beperking van SLA-Afhankelijkheid
De meest effectieve manier om te gaan met de onzekerheden van provider-SLA's is het ontwerpen van een veerkrachtige software-architectuur. Vertrouw nooit op de veronderstelling dat een enkele provider 100% beschikbaar is.
Korte netwerkonderbrekingen of tijdelijke piekbelastingen kunnen vaak worden opgevangen door een doordacht herhalingsmechanisme met exponential backoff. Voor kritische processen is bovendien een multi-provider strategie aan te bevelen. Zodra de primaire provider fouten retourneert of de afgesproken latency-drempel overschrijdt, schakelt de applicatie automatisch om naar een secundaire provider.
Checklist: Vragen aan je LLM-Provider
Wanneer je onderhandelt over zakelijke afspraken of een geschikt abonnement kiest bij een LLM-aanbieder, stel dan de volgende vragen om de werkelijke waarde van het contract te toetsen:
- Wat is de precieze contractuele definitie van downtime in het SLA, en zijn latency-stijgingen hierin opgenomen?
- Zijn HTTP 429 (Rate Limit) en HTTP 503 (Capacity Exceeded) fouten uitgesloten van de uptime-berekening?
- Geldt de gegarandeerde uptime voor alle aangeboden modellen, of uitsluitend voor specifiek aangewezen Stable/GA-modellen?
- Wat is de minimale aankondigingstermijn voor het deprecieren of aanpassen van een specifieke modelversie?
- Hoe hoog is de maximale uitkering van Service Credits bij langdurige uitval, en hoe dient een claim te worden onderbouwd?
- Biedt de provider gegarandeerde throughput met specifieke latency-afspraken, en wat zijn daarvan de meerkosten?
