Multi-tenancy is een architectuurpatroon waarbij een enkele LLM-deployment — inclusief het model, inferentie-infrastructuur en ondersteunende diensten — meerdere geïsoleerde klanten (tenants) gelijktijdig bedient. Elke tenant opereert alsof ze een eigen systeem hebben: hun data is gescheiden, hun configuraties zijn onafhankelijk, en hun gebruik wordt individueel gemeten. Ze delen echter de onderliggende rekenresources, wat de kosten per klant drastisch verlaagt (doorgaans 40-60% lager dan dedicated deployments). Multi-tenancy is de standaardarchitectuur voor AI-SaaS-platforms, enterprise AI-functies voor meerdere bedrijfsonderdelen, en elke LLM-dienst op schaal. De primaire engineeringuitdaging is het handhaven van strikte dataisolatie bij het efficiënt delen van resources.
Waarom het belangrijk is
LLM-inferentie is duur — een enkele GPU geschikt voor een 70B-parametermodel kost €2-4 per uur, en de meeste klanten kunnen individueel geen dedicated infrastructuur rechtvaardigen. Multi-tenancy lost dit economische probleem op door vraag te bundelen: wanneer Klant A inactief is, bedient hun GPU-capaciteit de verzoeken van Klant B, wat 70-90% resourcebenutting bereikt versus 20-40% bij single-tenant deployments. Voor AI-platformproviders maakt multi-tenancy concurrerende per-verzoekprijzen mogelijk die LLM-capaciteiten toegankelijk maken voor kleinere organisaties. Voor enterprises bedienen interne multi-tenant platforms marketing, juridisch, HR en engineering vanuit gedeelde infrastructuur zonder dat elke afdeling een eigen GPU-cluster financiert. De kritieke beperking is isolatie: een datalek tussen tenants — waarbij bedrijfseigen informatie van een klant verschijnt in de LLM-respons van een andere klant — is een desastreus beveiligingsincident. Multi-tenancy vereist daarom rigoureuze architecturale beveiligingen op elke laag: aparte embeddingopslagen, tenantgescoopt contextophalen, authenticatie op verzoeksniveau en outputfiltering.
Hoe het werkt
Multi-tenant LLM-architecturen implementeren isolatie op meerdere lagen. Op de verzoeklaag draagt elke API-aanroep een tenant-identifier die wordt geverifieerd tegen een authenticatiesysteem — geen verzoek wordt verwerkt zonder bevestigde tenantcontext. Op de datalaag worden documenten, embeddings, conversatiegeschiedenis en fine-tuningdata van elke tenant opgeslagen in geïsoleerde partities — aparte databases, aparte schema's binnen een gedeelde database of versleutelde tenantspecifieke namespaces. Op de inferentielaag wordt tenantcontext (systeemprompts, RAG-documenten, configuratie) per verzoek geïnjecteerd, zodat het model alleen informatie van de huidige tenant benadert. Op de outputlaag verifiëren monitoringsystemen dat antwoorden geen cross-tenant datalekken bevatten. Resourcemanagement omvat per-tenant rate limits (voorkomt dat één tenant gedeelde GPU's monopoliseert), prioriteitswachtrijen (waarborgt SLA-naleving voor premiumtenants) en gebruiksmetering (tokens, verzoeken en compute per tenant bijhouden voor facturering). Geavanceerde implementaties gebruiken promptcaching per tenant — wanneer systeemprompt en RAG-context van een tenant vaak hergebruikt worden, blijft de KV-cache behouden tussen verzoeken, wat latentie en kosten verlaagt.
Voorbeeld
Een legal-tech startup bouwt een AI-contractanalyseplatform voor 200 advocatenkantoren. Elk kantoor uploadt eigen contracten, precedenten en draaiboeken die strikt geïsoleerd moeten blijven. De single-tenant aanpak zou 200 aparte deployments vereisen à €800 per maand (€160.000 totaal). Hun multi-tenant architectuur bedient alle 200 kantoren vanuit 12 gedeelde GPU-instanties voor €12.000 per maand totaal — een kostenverlaging van 92%. Isolatie wordt afgedwongen op vier lagen: tenantgescoopte vectordatabases (documenten van elk kantoor in een aparte Qdrant-collectie), verzoekauthenticatie (elke API-aanroep gevalideerd tegen tenant-API-keys), systeempromptinjectie (aangepaste analyseregels van elk kantoor per verzoek geladen), en outputmonitoring (een geautomatiseerde classifier controleert dat geen respons documentinhoud van een andere tenant bevat). Tenantbewuste promptcaching slaat veelgebruikte context van elk kantoor op, wat gemiddelde latentie verlaagt van 3,2 seconden naar 1,4 seconden voor herhaalde querypatronen. Wanneer één kantoor een ongebruikelijk grote batchanalyse draait (50.000 contracten), waarborgt de rate limiter dat hun piek de responstijden van andere kantoren niet verslechtert voorbij de 4-seconden SLA. Maandelijkse kosten per kantoor bedragen gemiddeld €60 — een fractie van dedicated infrastructuur, waardoor enterprise AI-contractanalyse toegankelijk wordt voor kantoren van elke omvang.