# Architectuur van Hybrid Cloud/Edge LLM API Integraties | api.llmnet.nl

Deel:[𝕏](https://twitter.com/intent/tweet?url=https%3A//api.llmnet.nl/hybrid-cloud-edge-llm-integraties&text=Versiebeheer%20voor%20Prompts%20in%20een%20Codebase)[LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A//api.llmnet.nl/hybrid-cloud-edge-llm-integraties)[Reddit](https://www.reddit.com/submit?url=https%3A//api.llmnet.nl/hybrid-cloud-edge-llm-integraties&title=Versiebeheer%20voor%20Prompts%20in%20een%20Codebase)[Facebook](https://www.facebook.com/sharer/sharer.php?u=https%3A//api.llmnet.nl/hybrid-cloud-edge-llm-integraties)[Kopieer link](#)

# Architectuur van Hybrid Cloud/Edge LLM API Integraties

Door Ivo Donker - 7 augustus 2026

De opkomst van gedistribueerde LLM-infrastructuren vraagt om een rigoureuze inrichting van verkeersstromen tussen lokale edge-omgevingen en externe cloud-API's. Binnen de moderne API-infrastructuur fungeert de [llm-gateway als centraal knooppunt](/llm-gateway-zelf-hosten) om inkomende verzoeken te distribueren op basis van operationele randvoorwaarden. Dit artikel behandelt de architectuur: wanneer draait een request op een edge-endpoint en wanneer in de cloud, hoe neem je die beslissing op basis van latentie, kosten, privacy en beschikbaarheid, welke patronen bestaan er en wat kost die complexiteit aan observabiliteit en configuratie.

Dit artikel behandelt het zelf hosten van een lokale inference-server niet; zie [de documentatie over lokale modellen achter een API](/lokale-modellen-achter-api) voor de fundamenten van lokale serving. Voor hardware-eisen en dimensionering van dergelijke systemen verwijzen we naar [de hardware-gids voor lokale LLM's](https://gids.llmnet.nl/hardware-voor-lokale-llm) als operationeel naslagwerk. Het bepalen welk specifiek model ingezet moet worden valt buiten de scope van dit architectuurdocument; raadpleeg hiervoor [de gids over kleine modellen op apparaat](https://hub.llmnet.nl/kleine-modellen-op-apparaat) voor de actuele modelselectie op het apparaat.

## De Beslissingsmatrix: Cloud versus Edge

Het routeren van verzoeken vereist een dynamische evaluatie van vier pijlers: netwerklatentie, operationele kosten, data-privacy en servicebeschikbaarheid. Een edge-endpoint bevindt zich fysiek dicht bij de gebruiker of binnen het eigen bedrijfsnetwerk, vaak verbonden via infrastructuren zoals beschreven op [het artikel over lokale LLM's op afstand via Tailscale](https://gids.llmnet.nl/lokale-llm-via-tailscale-op-afstand) om veilige connectiviteit te garanderen. Publieke cloud-API's bieden daarentegen schaalbaarheid en toegang tot omvangrijke fundamentele architecturen, maar introduceren externe netwerkafhankelijkheden.

Latentie-gevoelige toepassingen, zoals real-time autocomplete of interactieve voice-assistenten, vereisen voorspelbare responstijden onder de honderd milliseconden. Lokale inference minimaliseert de netwerktijd, maar de totale verwerkingstijd hangt af van de rekencapaciteit van de lokale hardware. Voor complexe redeneertaken en multimodale analyses schieten lokale modellen vaak tekort, waardoor de cloud de enige haalbare optie is. Privacygevoelige verzoeken met medische of financiële persoonsgegevens moeten daarentegen binnen de landsgrenzen of het lokale netwerk blijven, ongeacht de prestatieverschillen.

## Architectuurpatronen voor Routering en Failover

Om betrouwbaarheid en efficiëntie te waarborgen, worden specifieke patronen toegepast binnen de API-gateway. Strategieën voor het bepalen van de juiste backend en het opvangen van uitval zijn uitgewerkt in [het handboek over model-routing en fallback-mechanismen](/model-routing). Hieronder worden de vier primaire patronen gedetailleerd besproken aan de hand van hun faalmodus, detectie, mitigatie en de kosten van die mitigatie.

### Patroon 1: Latency-Based Routing

Dit patroon stuurt verzoeken naar het endpoint met de laagste geschatte round-trip time (RTT) en verwerkingstijd. Dit voorkomt dat gebruikers op trage netwerken vastlopen op zware cloud-verbindingen of dat lokale nodes overbelast raken door zware belasting.

 
- Faalmodus: Een lokaal edge-endpoint raakt overbelast door een plotselinge piek aan verzoeken, waardoor de wachtrij (queue depth) exponentieel toeneemt en de Time To First Token (TTFT) acceptabele grenzen overschrijdt.
 
- Detectie: De API-gateway meet continu de RTT en de actuele verwerkingstijd per token via actieve health-checks en trailing metingen van actieve streams. Zodra de gemiddelde responsduur over een venster van dertig seconden boven de drempel van tweehonderd milliseconden stijgt, wordt de node aangemerkt als vertraagd.
 
- Mitigatie: De gateway schakelt automatisch over naar een geoptimaliseerd cloud-endpoint met gegarandeerde SLA's, waarbij strikte time-outs worden gehanteerd zoals beschreven in [de richtlijnen voor timeouts en cancellation](/timeouts-en-cancellation).
 
- Kosten: Deze mitigatie verhoogt de operationele kosten doordat duurdere cloud-tokens worden verbruikt en introduceert een vaste netwerklatentie van de externe API-provider.

### Patroon 2: Privacy-First Routing met Cloud-Fallback

Dit patroon classificeert inkomende payloads op gevoeligheid. PII (Personally Identifiable Information) en geclassificeerde bedrijfsdata mogen de lokale perimeter niet verlaten, tenzij de lokale infrastructuur volledig faalt en een expliciete bedrijfsnoodtoestand is afgekondigd.

 
- Faalmodus: Een licaal model crasht tijdens het verwerken van een gevoelige prompt, waardoor het systeem in een deadlock raakt en de API een HTTP 500-fout retourneert aan de client.
 
- Detectie: De gateway registreert het ontbreken van een valide antwoordstroom binnen de gestelde deadline en controleert de heartbeat van de lokale inferentiedaemon.
 
- Mitigatie: Het systeem voert automatisch een strikte sanitering en anonimisering uit op de prompt om alle gevoelige entiteiten te strippen, waarna het geanonimiseerde verzoek alsnog naar de publieke cloud-API wordt gestuurd.
 
- Kosten: De complexiteit van de pipeline neemt toe door de implementatie van deterministische PII-filtering, wat extra CPU-cycli kost en risico's op semantisch verlies van de prompt met zich meebrengt.

### Patroon 3: Warm/Cold Endpoints

Om energiekosten en hardware-slijtage te beperken, draaien zware lokale modellen vaak in een 'cold' of 'standby'-status waarbij geheugen wordt vrijgegeven of GPU-kloks worden verlaagd. Bij binnenkomst van een verzoek moet het model worden geladen.

 
- Faalmodus: Het opwarmen van het lokale model duurt langer dan de ingestelde client-timeout, wat resulteert in voortijdige afbreking van het verzoek door de client.
 
- Detectie: De gateway registreert een client-cancellation of een gateway-timeout tijdens de model-initialisatiefase in de lokale VRAM-allocatie.
 
- Mitigatie: Het verzoek wordt direct doorgestuurd naar een reeds opgewarmd cloud-endpoint, terwijl op de achtergrond het lokale model in de cold-status blijft staan tot de volgende piek.
 
- Kosten: Dit veroorzaakt onnodig dubbel resourcegebruik en tijdelijke piekbelasting op de netwerkbandbreedte, naast extra kosten voor de onverwachte cloud-aanroep.

### Patroon 4: Circuit Breaker en Failover

Wanneer een externe of lokale provider structureel faalt, moet de gateway voorkomen dat blijvende verzoeken naar een onbereikbaar endpoint worden gestuurd om cascading failures te vermijden.

 
- Faalmodus: De externe cloud-provider kampt met een regionale storing, waardoor alle API-aanroepen falen met connectiviteitsfouten of rate-limit exceptions.
 
- Detectie: De circuit breaker telt het aantal opeenvolgende fouten (HTTP 429, 502, 503, 504) binnen een tijdsvenster van zestig seconden. Bij het bereiken van de drempelwaarde van vijf fouten slaat de status om van 'closed' naar 'open'.
 
- Mitigatie: Alle inkomende verzoeken worden direct omgeleid naar het lokale edge-endpoint of een secundaire cloud-provider, waarbij de primaire backend tijdelijk wordt geblokkeerd voor verdere pogingen.
 
- Kosten: Het lokale edge-endpoint kan overbelast raken door de plotselinge toestroom van het totale productieverkeer, wat leidt tot verhoogde latentie voor alle gebruikers.

## Wanneer hybride niet de oplossing is

Een hybride cloud- en edge-architectuur introduceert aanzienlijke operationele complexiteit op het gebied van routering, statusbeheer en synchronisatie. Voor toepassingen met een laag verzoekvolume weegt deze infrastructuur niet op tegen de baten. De operationele overhead van het onderhouden van lokale endpoints en failover-mechanismen leidt in dergelijke scenario's tot disproportioneel hoge beheerkosten per verzoek.

Strikte wet- en regelgeving of sectorspecifieke compliance-kaders kunnen de verwerking van gevoelige data op decentrale edge-hardware expliciet verbieden. Wanneer datasoevereiniteit vereist dat alle gegevens binnen een gecentraliseerde, geauditeerde omgeving blijven, faalt het hybride model doordat de randapparatuur niet aan de beveiligingscertificering voldoet. Het negeren van deze beperking resulteert in directe juridische non-compliance en potentieel datalekrisico.

Complexe workloads die een zeer groot contextvenster vereisen of intensieve redeneertaken bevatten, zijn lokaal op edge-hardware doorgaans niet haalbaar vanwege hardwarelimieten in geheugen en rekenkracht. Het forceren van dergelijke taken op onderbemeten randapparatuur leidt tot onacceptabele responstijden of geheugenoverloop. Omgekeerd geldt dat applicaties met een continu, hoog volume aan eenvoudige taken juist volledig lokaal opereren om de doorlopende cloud-transactiekosten te elimineren; het introduceren van een hybride component voegt hier alleen maar netwerklatentie toe.

### Privacy-first en modelcapaciteit

Lokale edge-endpoints beschikken niet altijd over een model met de juiste capaciteit of het juiste type om een specifieke taak uit te voeren. Wanneer een verzoek een complexiteit of modaliteit vereist die het lokale model overstijgt, mag de gateway de data niet automatisch naar de cloud doorsluizen als dit in strijd is met het privacy-beleid. De architectuur vereist in dat geval een expliciete, gestructureerde afwijzing die direct aan de cliënt wordt geretourneerd.

Een dergelijke afwijzing heeft een negatieve impact op de gebruikerservaring, omdat de client-applicatie faalt in plaats van een fallback-antwoord te ontvangen. Om dit te beheersen, monitort het systeem het aantal afwijzingen nauwgezet via specifieke fouttellers in de gateway. Dit metentype maakt het mogelijk om patronen in modelcapaciteit te analyseren en de lokale modelselectie gericht bij te stellen zonder concessies te doen aan de gestelde privacykaders.

## Provider-Onafhankelijke Pseudocode voor Routering

Het onderstaande codefragment demonstreert een provider-onafhankelijke implementatie van een routeringsalgoritme met ingebouwde timeout-afhandeling, fallback-logica en foutisolatie.

import time
import requests

def route_and_execute_request(prompt, metadata, config):
 start_time = time.time()
 endpoint = select_optimal_backend(metadata, config)
 
 timeout_budget = config.get("max_timeout_ms", 5000) / 1000.0
 elapsed = time.time() - start_time
 remaining_timeout = max(0.1, timeout_budget - elapsed)
 
 try:
 response = execute_inference_call(endpoint, prompt, timeout=remaining_timeout)
 return response
 except (requests.Timeout, ConnectionError) as e:
 log_routing_failure(endpoint, e)
 fallback_endpoint = get_fallback_backend(endpoint, config)
 
 fallback_elapsed = time.time() - start_time
 fallback_remaining = max(0.1, timeout_budget - fallback_elapsed)
 
 try:
 fallback_response = execute_inference_call(fallback_endpoint, prompt, timeout=fallback_remaining)
 return fallback_response
 except Exception as fallback_error:
 log_critical_failure(fallback_endpoint, fallback_error)
 raise RuntimeError("Alle inferentie-backends gefaald binnen het tijdslimiet.") from fallback_error
 except Exception as unexpected_error:
 log_unexpected_error(endpoint, unexpected_error)
 raise unexpected_error

def select_optimal_backend(metadata, config):
 if metadata.get("is_pii_present", False):
 return config["edge_endpoint"]
 if metadata.get("latency_critical", False) and config["edge_latency_ms"] < config["cloud_latency_ms"]:
 return config["edge_endpoint"]
 return config["cloud_endpoint"]

def get_fallback_backend(failed_endpoint, config):
 if failed_endpoint == config["edge_endpoint"]:
 return config["cloud_endpoint"]
 return config["edge_endpoint"]

def execute_inference_call(endpoint, prompt, timeout):
 payload = {"prompt": prompt}
 response = requests.post(endpoint["url"], json=payload, timeout=timeout)
 if response.status_code != 200:
 raise requests.HTTPError(f"API retourneerde statuscode {response.status_code}")
 return response.json()

def log_routing_failure(endpoint, error):
 pass

def log_critical_failure(endpoint, error):
 pass

def log_unexpected_error(endpoint, error):
 pass

## Observability en Configuratiebeheer

Het introduceren van hybride routering verhoogt de operationele complexiteit aanzienlijk. Het meten van de effectiviteit van de gekozen routes vereist gedetailleerde telemetrie op gateway-niveau. Voor het inrichten van deze metingen en het analyseren van fouten per route verwijzen we naar [de technische handleiding voor observability en logging](/observability-en-logging).

## Metrieken voor een hybride route

Het continu bewaken van de prestaties per route is noodzakelijk om de routeringslogica binnen de hybride architectuur optimaal te laten functioneren. Onderstaande tabel toont de kritieke operationele metrieken, de bijbehorende doelen en de illustratieve grenswaarden voor ingrepen.

Metriek | 
Doel | 
Grenswaarde (illustratief) | 

TTFT per route | 
Minimaliseren van de time-to-first-token per endpoint | 
< 200 ms (edge), < 800 ms (cloud) | 

Foutratio per route | 
Detecteren van degradatie of uitval per infrastructuur | 
< 1.0% van het totale aantal verzoeken | 

Kosten per route | 
Bewaken van het budget per verwerkt token | 
Vastgesteld maximum per miljoen tokens | 

Circuit-breaker-status | 
Monitoren van de operationele gezondheid van de fallback | 
Gesloten (open bij > 5 opeenvolgende fouten) | 

Verhouding edge/cloud-verzoeken | 
Optimaliseren van de capaciteitsverdeling | 
Minimaal 70% lokaal verwerkt | 

Elke beslissing van de router — of een request naar de edge of de cloud wordt gestuurd — moet worden gelogd inclusief de deterministische reden (latentie, privacy, kosten of fallback). Zonder deze gedetailleerde tracing is het onmogelijk om prestatieverminderingen te achterhalen in gedistribueerde architecturen. Configuratiebeheer moet bovendien dynamisch worden gevoerd via centralized feature flags of service meshes, zodat drempelwaarden voor RTT en foutpercentages aangepast kunnen worden zonder dat de API-gateway opnieuw gedeployed hoeft te worden.

De complexiteit uit zich direct in de beheerlast: netwerkpartities tussen de cloud en lokale nodes, asynchrone synchronisatie van modelversies en discrepanties in output-formaten tussen verschillende inference-servers vragen om continue monitoring. Door strenge time-outs, circuit breakers en gestructureerde fallbacks toe te passen, blijft de beschikbaarheid van de totale API-infrastructuur gewaarborgd, ongeacht de incidenten aan de backend-zijde.

## Checklist voor een hybride opzet

- Implementeer latency-gebaseerde routering inclusief hysteresis om oscillatie tussen routes te voorkomen.

- Activeer automatische PII-detectie en -maskering vóór eventuele cloud-routing plaatsvindt.

- Configureer een expliciete, gestructureerde afwijzing wanneer de lokale modelcapaciteit ontoereikend is en cloud-routing uitgesloten is.

- Installeer een circuit breaker op de fallback-route om overbelasting van de secundaire infrastructuur te voorkomen.

- Gebruik een token bucket-algoritme om de harde limieten van de cloud-API te bewaken.

- Handhaaf keep-alive-verbindingen om de opstarttijd voor warme endpoints te minimaliseren.

- Verzamel en segmenteer operationele metrieken per individuele route voor nauwkeurige analyse.

- Voer periodieke failover-testen uit onder condities van kunstmatige latentie en netwerkstoringen.

- Definieer helder de functionele afbakening met het artikel over het lokaal zelf hosten van modellen.

© 2026 llmnet.nl · Ivo Donker