Retrieval-verkeer door de gateway: embeddings-calls routeren, limiteren en budgetteren

Door Ivo Donker — samengesteld met AI-ondersteuning (Claude & Gemini)

In de meeste productieomgevingen die met Large Language Models werken, krijgt de generatieve aanroep alle infrastructurele aandacht. Organisaties richten proxy-lagen in voor load balancing, monitoren token-latenties en bouwen failover-mechanismen rond endpoints zoals Claude, GPT-4 of lokale open-weight modellen. De retrieval-infrastructuur blijft daarbij vaak een architectonische blinde vlek. Embeddings-aanroepen voor vector-zoekopdrachten, document-ingestion en cross-encoder reranking-services worden rechtstreeks vanuit applicatieservers naar externe providers gestuurd, zonder centrale routering, doorvoerbeheersing of budgettering.

Dit leidt in de praktijk tot ernstige operationele problemen. Wanneer een achtergrondtaak miljoenen documentchunks tegelijk vectoriseert, raakt de globale rate limit van de provider binnen enkele seconden uitgeput, waardoor interactieve gebruikerszoekopdrachten direct vastlopen met HTTP 429-foutmeldingen. Daarnaast ontbreekt elk inzicht in de werkelijke kosten per tenant of zoekopdracht. Door retrieval-verkeer structureel door dezelfde centrale gateway te leiden als chat- en completion-verkeer, ontstaat een beheerste, schaalbare en auditeerbare AI-pijplijn. Wie de conceptuele basis van vectorrepresentaties wil bestuderen, kan eerst lezen over hoe semantisch zoeken werkt met een embeddings-API om te zien hoe ruwe tekst wiskundig wordt omgezet in dichte vectoren.

De anatomie van retrieval-verkeer in productie

Retrieval-verkeer is fundamenteel anders van karakter dan generatief LLM-verkeer. Waar generatieve aanroepen worden gekenmerkt door relatief lage frequenties, lange streaming-verbindingen en asymmetrische payload-groottes (een korte prompt leidt tot een lange gegenereerde output), vertoont retrieval-verkeer drie specifieke subpatronen met ieder hun eigen eisen aan doorvoer en latentie:

Verkeerstype	Payload & Batching	Latentietolerantie	Faalimpact
Runtime Query Vectorisatie	Enkelvoudige string (10–100 tokens)	Kritiek (< 80 ms)	Gebruiker ervaart directe vertraging of een mislukte zoekopdracht
Bulk Ingestion & Indexing	Grote arrays (batches van 64–2048 chunks)	Asynchroon / hoog (> minuten)	Indexering raakt vertraagd, geen directe gebruikersimpact
Cross-Encoder Reranking	Query + N kandidaatdocumenten (20–100 paren)	Zeer gevoelig (< 150 ms)	Suboptimale contextselectie of noodzakelijke fallback naar lexicale BM25

Wanneer al deze stromen ongefilterd over dezelfde API-sleutel en hetzelfde endpoint lopen, concurreren bulk-achtergrondprocessen direct met synchrone gebruikersinteracties. Een centrale gateway moet deze stromen kunnen identificeren op basis van headers, payload-structuur of tenant-tokens, en ze langs afzonderlijke routerings- en rate-limiting-paden sturen. De noodzaak voor een robuuste proxy-laag wordt evident zodra teams besluiten om een zelfgehoste LLM-gateway in te richten voor failover en configuratiebeheer, omdat een centrale gateway de enige plek is waar beleidsregels betrouwbaar kunnen worden afgedwongen over alle API-stromen heen.

Architectuur: De gecombineerde gateway-laag

Een gateway die zowel generatieve LLM-calls als retrieval-calls orkestreert, bevindt zich tussen de applicatielaag (RAG-orchestrators, search microservices, ingestion workers) en de upstream providers (zoals OpenAI, Cohere, Voyage AI of lokaal gehoste TEI-instanties op basis van Hugging Face Text Embeddings Inference). De inkomende aanvraag passeert achtereenvolgens authenticatie, payload-validatie, cache-opzoeking, rate-limiting, en provider-dispatch.

Het voornaamste architecturale knelpunt bij retrieval zit in de inspectie van de payload. Een generieke LLM-aanroep bevat meestal een gestructureerde messages-array. Een embeddings-aanroep bevat een input-veld dat kan variëren van een enkele string van 20 karakters tot een JSON-array met duizenden lappen tekst van elk 500 tokens. De gateway moet in staat zijn om het token-aantal van deze arrays snel te schatten zonder dat de JSON-deserialisatie en tokenisatie een CPU-bottleneck vormen voor de totale netwerklatentie.

// Inkomend verzoek naar de centrale gateway
POST /v1/embeddings
Host: gateway.intern
Authorization: Bearer sec_tenant_98234
X-Traffic-Class: interactive-search

{
  "model": "text-embedding-3-small",
  "input": "Hoe configureer ik mutual TLS op een interne proxy?",
  "dimensions": 512
}

// Proxy-reactie na interne verificatie, rate check en upstream routering
HTTP/1.1 200 OK
Content-Type: application/json
X-Gateway-Latency-MS: 28
X-Gateway-Cost-EUR: 0.0000004
X-Tenant-Remaining-Budget-EUR: 142.85

Routeringsstrategieën en de dimensie-valkuil

Bij generatieve modellen is dynamische fallback relatief vergevingsgezind: wanneer Claude 3.5 Sonnet tijdelijk niet beschikbaar is, kan een gateway het verzoek automatisch doorsturen naar GPT-4o of een lokaal open-weight model met een minimale prompt-translatie. Bij embeddings-modellen is deze dynamische flexibiliteit fundamenteel onmogelijk vanwege vectorcompatibiliteit.

Elk embeddings-model projecteert tekst in een unieke wiskundige vectorruimte met een specifiek aantal dimensies (zoals 384, 768, 1024 of 1536 dimensies) en een eigen semantische topologie. Vectoren die zijn gegenereerd door text-embedding-3-small kunnen onder geen beding worden vergeleken met vectoren uit Cohere's embed-multilingual-v3.0 of een lokaal BGE-model. Wie een dynamische fallback instelt naar een ander modeltype, maakt semantische afstandsmetingen via cosinus-overeenkomst in de vector-database volkomen waardeloos, met verhaspelde zoekresultaten tot gevolg.

Routering binnen de gateway voor embeddings kent daarom strikte regels:

Sleutel- en regio-failover: Routeren naar een identiek model in een andere cloud-regio of onder een secundaire API-sleutel bij dezelfde provider. Dit levert 100% vectorcompatibiliteit op zonder functionele breuk.
Zelfgehoste spiegeling: Uitwijken naar een lokaal draaiende Text Embeddings Inference (TEI) container die exact hetzelfde open-source modelbestand laadt (zoals BAAI/bge-m3) wanneer de managed cloud-provider offline gaat.
Matryoshka-dimensiebeheer: Indien een model Matryoshka-embeddings ondersteunt, kan de gateway de dimensions-parameter centraal afdwingen om opslag- en netwerkkosten in de downstream vector-index consistent te houden.

Voor een dieper inzicht in wanneer een gecombineerde RAG-pijplijn vraagt om een extra ranking-laag bovenop de vector-overeenkomst, biedt het overzicht over welk retrieval-model je kiest tussen embeddings en rerankers op hub.llmnet.nl een heldere conceptuele afbakening.

Rate limiting en prioriteitswachtrijen voor embeddings

Omdat bulk-ingestion van documenten honderdduizenden embeddings tegelijk vereist, consumeren indexeringstaken binnen enkele seconden het volledige token-per-minute (TPM) budget van een API-account. Zonder gateway-interventie resulteert dit direct in een blokkade van alle interactieve zoekopdrachten van reguliere gebruikers.

De effectiefste oplossing is de implementatie van een gedifferentieerd token-bucket-algoritme met gescheiden prioriteitswachtrijen. De gateway reserveert een vast percentage van het toegestane TPM-quotum voor interactief verkeer (klasse interactive-search), terwijl achtergrondtaken (klasse batch-ingestion) door een leaky bucket worden geleid die automatisch afknijpt zodra de upstream rate-limiet nadert. Wie het wiskundige mechanisme achter deze doorvoerbeheersing wil implementeren, kan de details nalezen in het artikel over het token bucket algoritme in een LLM-gateway.

Prioriteitsklasse	Gereserveerd Quotum	Max Toegestane Wachttijd	Gedrag bij Quota-uitputting
Interactieve Queries	70% van globale TPM	50 ms	Directe failover naar secundaire regio/sleutel; nooit bufferen
Achtergrond Ingestion	30% van globale TPM + restcapaciteit	300.000 ms	Automatisch pauzeren en geleidelijk leeglopen via wachtrij

Caching-strategieën voor embeddings en reranking

In productietoepassingen herhalen identieke zoekvragen zich regelmatig: helpdesk-applicaties, documentzoekers en interne chatbots ontvangen dagelijks tientallen synonieme of identieke vragen. Caching op de gateway-laag voorkomt onnodige API-aanroepen en reduceert de zoeklatentie van ~60 ms naar minder dan 2 ms.

De gateway kan twee vormen van caching toepassen voor retrieval-verkeer:

Exacte Hash Cache voor Embeddings: De gateway genereert een cryptografische hash (SHA-256) van het genormaliseerde invoerbericht (lowercase, gestripte witruimtes) gecombineerd met de modelnaam en dimensie-parameters. Indien de hash in een lokale Redis- of geheugenopslag aanwezig is, retourneert de gateway direct de opgeslagen vectorarray. Dit kost vrijwel geen rekenkracht en voorkomt dubbele kosten voor identieke queries.
Rerank Cache: Reranking-verzoeken evalueren paren van (Query, Document). Omdat documentteksten statisch zijn, kan de relevantiescore van een specifiek paar gecachet worden. Dit levert aanzienlijke besparingen op, aangezien cross-encoders rekenkundig zwaarder en duurder zijn dan bi-encoders.

Semantische caching van embeddings (waarbij een vector wordt hergebruikt als een eerdere vraag er semantisch op lijkt) is over het algemeen een kostbare denkfout: om de semantische overeenkomst van een inkomende query te bepalen, moet die query immers al gevectoriseerd zijn. Daarmee is de externe API-call reeds uitgevoerd en verdwijnt het kostenvoordeel volledig.

Kostenadministratie en toerekening per tenant

Embeddings lijken per individueel verzoek goedkoop (vaak fracties van een cent per duizend tokens), maar bij continue synchronisatie van bedrijfsdata lopen de volumes op tot honderden miljoenen tokens per maand. Wanneer meerdere klanten of interne afdelingen dezelfde infrastructuur delen, is directe kostentoerekening noodzakelijk om onverwachte facturen en oneerlijke kostenverdelingen te voorkomen.

De gateway fungeert hier als centraal meetstation. Elk inkomend verzoek wordt gelogd met de bijbehorende tenant-ID, het aantal verwerkte tokens, het gebruikte model en de actuele inkoopprijs. Hierdoor kan direct een virtueel saldo worden bijgehouden en kunnen harde budgetlimieten worden afgedwongen. Voor de specifieke opzet van deze administratieve logica verwijzen we naar het artikel over API-kosten per eindgebruiker toerekenen in een SaaS-product, waar de integratie tussen gateway-meters en tenant-saldi stap voor stap wordt uitgewerkt.

# Pseudocode: Gateway metering middleware voor embeddings
def handle_embeddings_request(request):
    tenant_id = extract_tenant(request)
    token_count = fast_estimate_tokens(request.payload["input"])
    unit_price = get_model_price(request.payload["model"])
    estimated_cost = token_count * unit_price

    # 1. Pre-flight budgetcontrole
    if not budget_service.has_sufficient_funds(tenant_id, estimated_cost):
        return http_error(402, "Payment Required: Retrieval quota exceeded")

    # 2. Exacte hash cache controle
    cache_key = generate_cache_key(request.payload)
    if cached_vector := cache.get(cache_key):
        metrics.record_cache_hit(tenant_id)
        return json_response(cached_vector, headers={"X-Cache": "HIT"})

    # 3. Uitvoeren via circuit breaker en rate limiter
    response, latency = upstream_client.post_with_retry(request.payload)

    # 4. Exacte afboeking op tenant-saldo
    actual_tokens = response["usage"]["total_tokens"]
    actual_cost = actual_tokens * unit_price
    budget_service.deduct_funds(tenant_id, actual_cost)
    
    # 5. Resultaat wegschrijven naar cache
    cache.set(cache_key, response["data"], ttl_seconds=86400)
    
    return json_response(response, headers={"X-Cache": "MISS"})

Faalgedrag, circuit breakers en degradatiestrategieën

Wanneer een externe embeddings-provider kampt met verhoogde foutpercentages of extreme netwerklatenties (> 2000 ms), mag dit niet het complete zoeksysteem van de applicatie platleggen. Een gateway moet over een actieve circuit breaker beschikken die faalcondities herkent en direct ingrijpt.

De standaard mitigatiestrategie voor retrieval-verkeer rust op vier opeenvolgende fasen:

Detectie: De gateway registreert het percentage HTTP 5xx- en 429-foutmeldingen over een rollend venster van 30 seconden. Overschrijdt dit de drempelwaarde van 5%, dan springt de circuit breaker naar de status Open.
Snelle weigering (Fast-Fail): Inkomende batch-ingestion taken worden direct gepauzeerd met een gestandaardiseerde statuscode, zodat upstream servers niet verder worden overbelast.
Graceful Degradation voor zoekopdrachten: Voor interactieve zoekopdrachten stuurt de gateway een signaalheader mee naar de backend applicatie (bijvoorbeeld X-Retrieval-Fallback: lexical-only). De applicatie schakelt op basis hiervan direct over naar traditionele full-text zoekmethoden (zoals BM25 of Elasticsearch lexical search), waardoor de eindgebruiker toch relevante resultaten ontvangt zonder dat semantische vectorisatie vereist is.
Half-Open herstel: Na een afkoelperiode van 60 seconden laat de gateway 1% van de interactieve queries door om te verifiëren of de upstream provider is hersteld, alvorens de volledige wachtrij weer vrij te geven.

De achterliggende principes en architecturale patronen voor het beheersen van dergelijke storingen worden uitgebreid behandeld in de gids over graceful degradation ontwerpen bij LLM-uitval.

Meetmethoden, monitoring en SLI/SLO-definitie

Om retrieval-verkeer betrouwbaar in productie te houden, volstaan generieke HTTP-succespercentages niet. Een gateway moet specifieke Service Level Indicators (SLI's) verzamelen die inzicht geven in de daadwerkelijke prestaties van de zoekinfrastructuur:

Query Embedding Latentie (p95 en p99): De tijd die verstrijkt tussen het ontvangen van de zoekstring en het retourneren van de vector. Voor interactieve zoekbalken geldt een gezonde SLO van p95 < 70 ms en p99 < 120 ms.
Cache Hit Ratio per Tenant: Het percentage embeddings-aanroepen dat direct vanuit de lokale hash-cache wordt beantwoord. Een gezonde helpdesk- of chat-app haalt doorgaans een hit ratio tussen de 15% en 35%.
Queue Dwell Time voor Ingestion: De tijdsduur dat een batch documentchunks in de interne wachtrij staat voordat er upstream capaciteit beschikbaar is.
Kosten per Zoekactie: Het geaggregeerde bedrag dat aan embeddings en reranking wordt uitgegeven, gedeeld door het totale aantal uitgevoerde zoekopdrachten.

Door deze metrieken realtime te exporteren naar Prometheus of OpenTelemetry, kunnen afwijkingen zoals sluipende API-prijsstijgingen of verslechterende upstream netwerkverbindingen binnen enkele minuten worden gesignaleerd.

Randgevallen en infrastructurele beperkingen

Bij het routeren van retrieval-verkeer via een centrale proxy doen zich specifieke randgevallen voor die afwijken van standaard API-verwerking:

Geheugenbeslag bij monsterbatches: Wanneer een ingestion worker een array van 2048 documenten in één POST-verzoek stuurt, kan de JSON-payload tientallen megabytes groot zijn. Gateways die payloads volledig in RAM bufferen voor inspectie kunnen bij hoge gelijktijdigheid tegen geheugenlimieten aanlopen (OOM-kills). Een streaming parser die de payload chunkgewijs controleert is hier noodzakelijk.
Modeldeprecatie en herindexering: Wanneer een provider een embeddings-model uitfaseert, moet de volledige vector-database opnieuw worden opgebouwd met het opvolgende model. De gateway moet in staat zijn om tijdens deze migratieperiode twee verschillende modellen parallel te ondersteunen en het verkeer gefaseerd over te zetten per documentcollectie.
Netwerk-overhead van de proxy-hop: Een extra tussenstation introduceert altijd netwerklatentie. In een geoptimaliseerde infrastructuur (geschreven in Go of Rust en draaiend binnen hetzelfde cloud-netwerk of Kubernetes-cluster) bedraagt deze overhead doorgaans slechts 1,5 tot 3,5 milliseconden per call, wat ruimschoots opweegt tegen de operationele voordelen.

Operationele samenvatting en implementatiepad

Het centraliseren van retrieval-verkeer binnen een LLM-gateway transformeert vectorisatie van een kwetsbare nevenactiviteit naar een volwaardig, beheersbaar onderdeel van de AI-architectuur. Door strikte scheiding aan te brengen tussen interactieve zoekopdrachten en zware achtergrond-ingestion, worden plotselinge uitval en onverwachte kostenpieken structureel geëlimineerd.

De aanbevolen implementatievolgorde start bij het omleiden van alle embeddings-endpoints naar de centrale proxy en het inrichten van de exacte hash-cache. Vervolgens worden prioriteitswachtrijen geconfigureerd om het interactieve zoekverkeer te beschermen, waarna per-tenant budgetbewaking en circuit breakers worden geactiveerd. Met deze lagen op hun plek is de retrieval-pijplijn bestand tegen piekbelastingen en klaar voor grootschalige productie-inzet.