Multi-tenant LLM-applicaties bouwen

Bij het ontwikkelen van Software-as-a-Service (SaaS) oplossingen die gebruikmaken van Large Language Models, kiezen steeds meer organisaties voor een multi-tenant architectuur. Hierbij delen verschillende klanten (tenants) dezelfde applicatie-infrastructuur en dezelfde LLM-endpoints. Dit brengt echter unieke uitdagingen met zich mee op het gebied van beveiliging, kostenbeheersing en performance. Omdat generatieve AI-aanroepen duur, traag en onvoorspelbaar kunnen zijn, volstaat een traditionele multi-tenant database-aanpak niet.

In dit artikel ontleed ik de kerncomponenten die nodig zijn om een robuuste, veilige en financieel houdbare multi-tenant LLM-omgeving op te zetten. We behandelen data-isolatie in prompts en vector-indexen, het toewijzen van quota, usage-metering voor eerlijke kostenberekening en technieken om het gevreesde 'noisy neighbour'-probleem te mitigeren.

1. Data-isolatie: Prompts, Caches en Vector-indexen

Het grootste risico in een multi-tenant LLM-omgeving is dat data van de ene klant (tenant A) lekt naar de contextvensters, caches of embeddings van een andere klant (tenant B). Omdat LLM's instructies slecht kunnen scheiden van data (prompt injection risico's), moet de isolatie op architectonisch niveau worden afgedwongen en niet alleen via system prompts.

Isolatie in prompts en system instructions

Wanneer je gebruikersinvoer combineert met bedrijfsdata (bijvoorbeeld via Retrieval-Augmented Generation), mag de opgehaalde context nooit data van andere tenants bevatten. Dit vereist dat elke query streng wordt gefilterd op basis van de geverifieerde tenant-identiteit die afkomstig is uit de API-gateway of het authenticatietokening (JWT).

Isolatie in vector-indexen

Voor vector-databases zijn er grofweg twee strategieën om multi-tenancy in te richten:

• Nailed Namespaces of aparte collecties: Elke tenant krijgt een eigen fysieke index of collectie binnen de vector-database. Dit biedt maximale veiligheid tegen datalekken via vector-similarity searches, maar schaalbaarheidslimieten kunnen opspelen bij miljoenen actieve tenants.
• Metadata filtering: Alle vectoren worden opgeslagen in één centrale index, maar elke vector krijgt een metadatumtag mee, zoals tenant_id: "xyz". Elke zoekopdracht dwingt een filter af (WHERE tenant_id == "xyz"). Dit is schaalbaarder, maar vereist dat de database-engine feilloos en zonder bugs in de filterlogica werkt.

Isolatie in caches

Het cachen van LLM-antwoorden (of semantische caches) bespaart kosten, maar kan gevaarlijk zijn in een multi-tenant omgeving. Een antwoord dat gegenereerd is op basis van vertrouwelijke interne documenten van tenant A mag absoluut nooit worden geserveerd aan tenant B via een gedeelde cache-sleutel. Zorg ervoor dat de cache-sleutel altijd de tenant_id of een cryptografische hash van de toegangsrechten van de tenant bevat.

2. Quota en Rate Limits per Tenant

Niet elke klant gebruikt de applicatie op dezelfde manier. Sommige tenants betalen voor een basisabonnement en mogen slechts een paar honderd tokens per minuut verbruiken, terwijl enterprise-klanten tienduizenden tokens per minuut nodig hebben. Goede rate limiting voorkomt dat één klant al je API-quota bij de upstream provider (zoals OpenAI, Anthropic of een eigen vLLM-cluster) opsoupeert.

Het instellen van dynamische limieten vereist een gelaagde aanpak. Bekijk voor een breder overzicht van limitering ook onze gids over rate limits en kosten. Een effectief model hanteert een combinatie van:

• Requests Per Minute (RPM): Om te voorkomen dat een script de applicatie overspoelt met verbindingsverzoeken.
• Tokens Per Minute (TPM): Omdat de werkelijke belasting van een LLM-API wordt bepaald door de lengte van de prompt en de gegenereerde output.
• Daily / Monthly Token Quota: Een harde bovengrens om onverwachte kostenpieken te voorkomen.

3. Kosten doorbelasten met Usage-Metering

Omdat LLM's per token worden afgerekend, is het cruciaal om het verbruik per tenant nauwkeurig bij te houden. Dit proces, bekend als usage-metering of cost attribution, vormt de basis voor usage-based billing.

Het administratiemodel voor usage-metering werkt op basis van eenasynchrone Event-Driven architectuur. Zodra een LLM-call voltooid is, logt de middleware de volgende gegevens in een centrale metering-database (bijvoorbeeld TimescaleDB of ClickHouse):

{
  "timestamp": "2026-07-26T14:30:00Z",
  "tenant_id": "tenant_abc_123",
  "model": "gpt-4o",
  "prompt_tokens": 420,
  "completion_tokens": 150,
  "total_tokens": 570,
  "estimated_cost_usd": 0.00425
}

Voor een diepere duik in het bewaken van uitgaven kun je terecht bij onze handleiding over kosten monitoren. Door deze metingen te aggreperen per uur en per dag, kun je als platformeigenaar exact berekenen wat elke tenant kost en hier marges bovenop leggen voor je facturatie.

4. Het Noisy-Neighbour-Probleem Mitigeren

Het 'noisy neighbour'-fenomeen treedt op wanneer één intensieve tenant alle resources (zoals GPU-rekenkracht of netwerkbandbreedte) opslokt, waardoor andere tenants te maken krijgen met trage responstijden of time-outs. Bij traditionele webapplicaties vangen load balancers dit op, maar LLM's hebben te maken met variabele generatiesnelheden (tokens per seconde).

Om dit te voorkomen, kun je de volgende mitigerende maatregelen toepassen:

• Concurrency Limits per Tenant: Beperk het aantal gelijktijdige genererende streams dat één tenant mag openstaan. Als een klant tien grote documenten tegelijk wil samenvatten, worden de latere verzoeken in een wachtrij geplaatst in plaats van dat ze het model verstoppen.
• Fair-sharing Scheduling: Als je gebruikmaakt van self-hosted modellen via engines zoals vLLM of TGI, kun je verzoeken prioriteren of opsplitsen in kleinere batches om te voorkomen dat lange output-reeksen van één gebruiker kleine verzoeken van anderen blokkeren.
• Graceful Degradation en Fallbacks: Als een model overbelast raakt door een specifieke tenant, kun je geautomatiseerde fallbacks inrichten naar een goedkoper of sneller model.

5. Een Concreet Administratiemodel per Tenant

Om alle bovenstaande componenten samen te brengen, is een gestructureerd administratiemodel nodig. Hieronder vind je een overzicht van hoe de configuratie en administratie per tenant er in een relationele database of configuratiestore uit kan zien:

Door dit administratiemodel te koppelen aan je API-gateway (zoals Kong, APISIX of custom middleware), kun je inkomende requests direct valideren voordat ze de dure LLM-infrastructuur bereiken. Dit bespaart onnodige rekentijd en beschermt je bedrijfsmodel.

Conclusie

Het bouwen van een multi-tenant LLM-applicatie vraagt om een zorgvuldige balans tussen flexibiliteit, strenge beveiliging en kostenbeheersing. Door strikte data-isolatie toe te passen in zowel prompts als vector-indexen, nauwkeurig gebruik te meten per token, en harde quota en concurrency-limieten in te stellen, voorkom je dat individuele klanten de prestaties of het budget van je platform ondermijnen. Wil je de prestaties van je applicatie verder optimaliseren? Lees dan meer over het slim inzetten van caching voor LLM-antwoorden om redundante kosten direct te elimineren.