Ga naar de hoofdinhoud
BVDNET
Arnhem · websites & automatiseringBVDNET
Industrie & Business

Multi-tenancy in AI

Bij multi-tenancy bedient één AI-dienst veel klanten op gedeelde servers en modellen, terwijl gegevens, instellingen en verbruik per klant gescheiden blijven.

Ook bekend als: multitenancy, multi-tenant architecture, tenant isolation

Multi-tenancy betekent dat één softwaresysteem veel klanten tegelijk bedient, elk met eigen gegevens en instellingen, zoals huurders die een gebouw delen maar elk een afgesloten appartement hebben. Een bedrijf dat een AI-chatbot aan veel webshops verhuurt, kan ze allemaal op dezelfde servers en hetzelfde model laten draaien. Dat houdt de prijs laag, zolang geen enkele winkel de gegevens van een andere kan zien.

Wat is een tenant?

De architectuurgids voor multitenant-oplossingen van Microsoft omschrijft een tenant als een klant, en onderscheidt tenants van gebruikers: alle gebruikers van één bedrijf vormen samen één tenant. Voorbeelden zijn boekhoudsoftware en andere SaaS-producten, en een platform dat meerdere bedrijfsonderdelen van één bedrijf delen. In een multitenant-architectuur bedient één exemplaar van de software alle tenants en geeft het elk een eigen deel, met eigen gegevens, configuratie en gebruikersbeheer (Wikipedia). Het alternatief is een apart exemplaar per tenant.

Hoe ziet dat eruit bij AI?

De richtlijnen voor Azure OpenAI van Microsoft vergelijken vier opzetten, van een aparte modelinstantie per tenant (sterke scheiding van gegevens) tot één gedeelde modeldeployment voor alle tenants (het eenvoudigst, met de minste scheiding). Daartussen zit een gedeelde instantie met een aparte modeldeployment per tenant, waarmee je per tenant een quotum, een contentfilter, een modelversie of een gefinetuned model kunt instellen. De richtlijnen voegen een paar regels toe:

  • Een gedeelde deployment kan last hebben van luidruchtige buren (noisy neighbours): zwaar gebruik door één tenant verhoogt de wachttijd voor anderen.
  • Wie klanten voor een gedeelde deployment laat betalen, moet in de applicatie per tenant de gebruikte tokens tellen.
  • Azure OpenAI dwingt geen toegangsrechten per modeldeployment af, dus de applicatie moet controleren welke tenant welke deployment mag gebruiken.
  • Documenten voor RAG horen in een aparte index per tenant, of elke zoekvraag krijgt een tenantfilter. Pinecone raadt in zijn vectordatabase bijvoorbeeld één namespace per klant aan.
  • De code van de applicatie controleert de tenant-ID; vertrouw er niet op dat het taalmodel tenantinformatie doorgeeft.

Ook aangepaste modellen kunnen hardware delen. Een LoRA-adapter past een basismodel aan met een kleine set extra gewichten, dus één kopie van het basismodel kan veel adapters bedienen. S-LoRA (2023) bedient duizenden adapters op één gpu, en Punica (2023) meldt 12 keer de doorvoer van bestaande systemen, met 2 milliseconden extra vertraging per token.

Waar gaat het mis?

Gedeelde onderdelen kunnen klanten door elkaar halen. In maart 2023 liet een bug in een opensourcebibliotheek die ChatGPT voor zijn cache gebruikte, sommige gebruikers titels uit de chatgeschiedenis van een andere actieve gebruiker zien. Volgens OpenAI kan dezelfde bug betaalgegevens van 1,2% van de ChatGPT Plus-abonnees die in een periode van negen uur actief waren, zichtbaar hebben gemaakt voor anderen: naam, e-mailadres, betaaladres, type creditcard, de laatste vier cijfers en de vervaldatum. OpenAI voegde daarna controles toe die nagaan of gegevens uit de cache bij de vragende gebruiker horen.

Gedeelde caches kunnen ook via de tijd lekken. Prompt caching maakt een herhaalde prompt sneller, dus als klanten één cache delen, kunnen responstijden verraden wat anderen vroegen. Gu e.a. (2025) vonden caches die over alle gebruikers werden gedeeld bij zeven API-aanbieders, waaronder de embedding-API van OpenAI. Nadat ze dat in oktober 2024 hadden gemeld, pasten minstens vijf aanbieders iets aan, bijvoorbeeld door caches niet langer tussen organisaties te delen. In september 2026 staat in de documentatie van Anthropic dat verschillende organisaties nooit een cache delen.

Voorbeeld

Stel: een softwarebedrijf biedt een supportchatbot aan veel webshops aan. De helpartikelen van elke winkel gaan in een eigen namespace in de vectordatabase. Elk verzoek draagt de ID van de winkel uit de login mee, en de code, niet het model, kiest de namespace waarin gezocht wordt. De tokens van elk verzoek worden per winkel opgeslagen voor de maandfactuur, en elke winkel heeft een quotum, zodat een uitverkoop bij de ene winkel de chatbots van de andere niet vertraagt.