Deel:𝕏LinkedInRedditFacebookKopieer 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 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 voor de fundamenten van lokale serving. Voor hardware-eisen en dimensionering van dergelijke systemen verwijzen we naar de hardware-gids voor lokale LLM's 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 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 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. 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.

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.

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.

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.

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.

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