Accueil › Glossaire › Multi-Tenant AI

Multi-Tenant AI

L’architecture multi-tenant IA (multi-locataires) permet de servir plusieurs clients (tenants) depuis une infrastructure partagée tout en garantissant l’isolation des données, la séparation des coûts et des performances prévisibles pour chaque locataire, y compris pour les workloads de LLM et d’agents IA.

Qu’est-ce que le multi-tenancy en IA

Le multi-tenancy est le modèle économique fondamental du SaaS : une seule instance de l’application sert tous les clients. Chaque client (tenant) travaille avec ses propres données, ses propres configurations, et ses propres limites, mais partage l’infrastructure sous-jacente (serveurs, bases de données, modèles IA). L’avantage : des économies d’échelle massives. L’inconvénient : la complexité de garantir que le tenant A ne voit jamais les données du tenant B, et que l’activité du tenant A ne dégrade pas les performances du tenant B.

Avec l’IA, la complexité monte d’un cran. Les workloads LLM sont gourmands en GPU, variables en durée (un prompt de 100 tokens vs 100 000 tokens), et manipulent des données confidentielles (documents clients, historiques de conversation). Un système multi-tenant IA doit isoler non seulement les données relationnelles classiques, mais aussi les index vectoriels (pour le RAG), les modèles fine-tunés par tenant, les historiques de prompts, et les budgets de tokens.

Les trois modèles d’isolation

Tout système multi-tenant repose sur un choix fondamental d’isolation. Trois modèles existent, chacun avec des compromis différents entre coût, sécurité et complexité opérationnelle.

Modèle Pool (partagé)

Tous les tenants partagent la même base de données, le même index vectoriel, et les mêmes ressources compute. L’isolation se fait par filtrage logique : chaque table contient une colonne tenant_id, et chaque requête filtre sur cet identifiant.

Pour les données relationnelles : Row-Level Security (RLS) dans PostgreSQL ou MySQL garantit que chaque requête SQL ne retourne que les lignes du tenant courant, même si le développeur oublie un WHERE tenant_id = ....

-- PostgreSQL : activer RLS sur la table documents
ALTER TABLE documents ENABLE ROW LEVEL SECURITY;
ALTER TABLE documents FORCE ROW LEVEL SECURITY;

-- Politique : chaque tenant ne voit que ses propres documents
CREATE POLICY tenant_isolation ON documents
    USING (tenant_id = current_setting('app.current_tenant')::uuid);

-- À chaque requête, le middleware injecte le contexte tenant
SET LOCAL app.current_tenant = 'tenant-abc-123';

Pour les index vectoriels (RAG) : l’index partagé contient les embeddings de tous les tenants, avec un champ tenant_id dans les métadonnées. Chaque requête de recherche vectorielle filtre sur ce champ. Pinecone, Qdrant, Weaviate et Milvus supportent tous ce pattern de filtrage par métadonnées.

# Recherche vectorielle avec filtre tenant (Qdrant)
results = qdrant_client.search(
    collection_name="documents",
    query_vector=query_embedding,
    query_filter=Filter(
        must=[
            FieldCondition(
                key="tenant_id",
                match=MatchValue(value="tenant-abc-123")
            )
        ]
    ),
    limit=5
)

Avantages : coût minimal (une seule base, un seul index, un seul cluster), opérations simples, scaling horizontal facile.

Risques : une erreur de filtrage expose les données de tous les tenants. La RLS doit être activée ET forcée (avec FORCE ROW LEVEL SECURITY), sinon un superuser contourne les politiques. Un seul path de code sans injection du contexte tenant suffit à créer une fuite de données.

Modèle Silo (dédié)

Chaque tenant dispose de ses propres ressources dédiées : sa base de données, son index vectoriel, et potentiellement son propre cluster ou namespace Kubernetes. L’isolation est maximale.

Avantages : isolation la plus forte (aucun risque de fuite cross-tenant), backup/restore par tenant, possibilité de personnaliser l’infrastructure par tenant (région, version du modèle, SLA dédié).

Inconvénients : coût élevé (infrastructure dupliquée pour chaque tenant), complexité opérationnelle (déployer une mise à jour sur 500 bases de données vs une seule), scaling plus difficile (onboarder un nouveau tenant = provisionner des ressources dédiées).

Idéal pour : tenants enterprise avec des exigences de compliance fortes (HIPAA, FedRAMP, RGPD avec résidence des données), ou tenants à très haut volume qui justifient des ressources dédiées.

Modèle Bridge (hybride)

Le modèle le plus pragmatique en pratique. Les tenants PME/standard partagent l’infrastructure (modèle Pool). Les tenants enterprise ont des ressources dédiées (modèle Silo). Le routage se fait au niveau de l’API Gateway en fonction du tier du tenant.

# Routage hybride dans l'API Gateway
def route_request(tenant_id: str, request):
    tenant = get_tenant_config(tenant_id)
    
    if tenant.tier == "enterprise":
        # Silo : route vers les ressources dédiées du tenant
        return forward_to(tenant.dedicated_endpoint, request)
    else:
        # Pool : route vers l'infrastructure partagée
        request.headers["X-Tenant-ID"] = tenant_id
        return forward_to(SHARED_ENDPOINT, request)

Ce modèle est le plus courant en production. La majorité des SaaS commencent en Pool pur, puis « graduent » les gros clients vers le Silo quand ils signent un contrat enterprise.

Le problème du noisy neighbor

Le « noisy neighbor » (voisin bruyant) est le problème central de toute architecture multi-tenant. Quand plusieurs tenants partagent les mêmes ressources (CPU, mémoire, GPU, bande passante I/O, connexions base de données), l’activité d’un tenant peut dégrader les performances des autres.

En IA, ce problème est amplifié. Un tenant qui envoie un prompt de 200K tokens consomme une quantité massive de GPU et de mémoire VRAM pendant plusieurs secondes, bloquant ou ralentissant les requêtes des autres tenants qui partagent le même GPU. Un batch de fine-tuning peut saturer la bande passante PCIe pendant des heures.

Solutions au noisy neighbor

Rate limiting par tenant. Chaque tenant a une limite de requêtes par minute et de tokens par minute. Le rate limiting empêche un seul tenant de monopoliser les ressources. C’est la première ligne de défense, indispensable mais insuffisante seule (un tenant peut rester sous la limite tout en saturant les GPU avec des requêtes coûteuses).

Quotas de ressources Kubernetes. Chaque namespace Kubernetes (un par tenant ou un par tier) reçoit des ResourceQuotas qui plafonnent le CPU, la mémoire, et le nombre de GPU disponibles. Un tenant enterprise avec un namespace dédié et 2 GPU alloués ne peut pas déborder sur les GPU des autres tenants.

# ResourceQuota Kubernetes par namespace tenant
apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-quota
  namespace: tenant-acme
spec:
  hard:
    requests.cpu: "16"
    requests.memory: 64Gi
    requests.nvidia.com/gpu: "2"
    limits.cpu: "24"
    limits.memory: 96Gi
    limits.nvidia.com/gpu: "2"

NVIDIA Multi-Instance GPU (MIG). Sur les GPU A100 et H100, la technologie MIG partitionne physiquement un GPU en plusieurs instances isolées (jusqu’à 7 partitions sur un A100). Chaque partition dispose de ses propres Streaming Multiprocessors et de sa propre mémoire. Un tenant reçoit une partition MIG dédiée, éliminant l’interférence au niveau matériel. Des recherches récentes montrent que le MIG dynamique (reconfigurer les partitions en temps réel selon la charge) réduit le taux de violations de SLO d’environ 32 % par rapport à un partitionnement statique.

Serveurs d’inférence dédiés par tenant. Pour les tenants enterprise, déployez un serveur vLLM ou TGI (Text Generation Inference) par tenant dans un namespace Kubernetes dédié, avec des GPU réservés. C’est le Silo appliqué au compute : isolation totale des performances.

Files d’attente pondérées. Si les tenants partagent un même serveur d’inférence, implémentez un système de files d’attente avec priorité. Les tenants premium passent en priorité. Les tenants gratuits attendent. Cela ne résout pas le noisy neighbor au niveau du hardware, mais garantit l’équité au niveau applicatif.

RAG multi-tenant

Le Retrieval-Augmented Generation en multi-tenant est un cas d’architecture critique. Chaque tenant a ses propres documents, ses propres embeddings, et potentiellement sa propre configuration (modèle d’embedding, stratégie de chunking, template de prompt). L’isolation doit être garantie à chaque étape du pipeline.

Pipeline RAG par tenant

Ingestion : les documents uploadés par le tenant sont taggés avec son tenant_id à chaque étape. Le chunking et l’embedding peuvent utiliser des paramètres différents par tenant (chunk size, overlap, modèle d’embedding).

Stockage vectoriel : deux approches selon le modèle d’isolation. En Pool, tous les embeddings sont dans la même collection avec un filtre tenant_id sur chaque requête. En Silo, chaque tenant a sa propre collection ou son propre index.

Retrieval : la requête de recherche vectorielle DOIT inclure le filtre tenant. C’est le point de défaillance le plus critique : un oubli de filtre retourne les documents de tous les tenants dans le contexte envoyé au LLM.

Génération : le prompt est construit avec le contexte récupéré (documents du tenant uniquement), le template de prompt du tenant, et les paramètres LLM du tenant (modèle, température, max tokens). La réponse est enregistrée dans l’historique du tenant.

class MultiTenantRAGPipeline:
    def query(self, tenant_id: str, user_query: str):
        # 1. Récupérer la config du tenant
        config = self.get_tenant_config(tenant_id)
        
        # 2. Embedding de la requête (modèle configurable par tenant)
        query_vector = self.embed(user_query, model=config.embedding_model)
        
        # 3. Recherche vectorielle AVEC FILTRE TENANT (critique)
        if config.isolation == "silo":
            index = self.get_dedicated_index(tenant_id)
            chunks = index.search(query_vector, top_k=config.top_k)
        else:
            chunks = self.shared_index.search(
                query_vector,
                top_k=config.top_k,
                filter={"tenant_id": tenant_id}  # OBLIGATOIRE
            )
        
        # 4. Génération avec le modèle et template du tenant
        prompt = config.prompt_template.format(
            query=user_query,
            context=self.format_chunks(chunks)
        )
        
        response = self.llm.generate(
            prompt,
            model=config.llm_model,
            temperature=config.temperature,
            max_tokens=config.max_tokens
        )
        
        # 5. Logger pour le metering
        self.meter_usage(tenant_id, response.usage)
        
        return response

Déploiement multi-tenant sur Kubernetes

Kubernetes est la plateforme standard pour les déploiements multi-tenant IA en production. Le pattern recommandé combine plusieurs mécanismes natifs :

Namespace par tenant (ou par tier). Chaque namespace reçoit ses propres ResourceQuotas, LimitRanges, NetworkPolicies, et ServiceAccounts. Un tenant ne peut pas accéder aux pods d’un autre namespace.

Istio/Linkerd pour le mTLS. Un service mesh chiffre les communications inter-services et applique des AuthorizationPolicies par namespace. Le trafic du tenant A ne peut pas atteindre les services du tenant B, même si les pods sont sur le même nœud.

vLLM avec isolation par namespace. Chaque tenant enterprise obtient un déploiement vLLM dans son namespace, avec des GPU réservés via les node selectors et les tolerations Kubernetes. Le HorizontalPodAutoscaler scale les replicas en fonction de la taille de la file d’attente vLLM.

Header X-Tenant-ID. Pour les tenants partagés, l’API Gateway injecte le header X-Tenant-ID dans chaque requête. Le serveur d’inférence partagé utilise ce header pour le routage, le metering et le logging. Istio peut appliquer des AuthorizationPolicies qui vérifient ce header.

Metering et attribution des coûts

En multi-tenant IA, le metering par tenant n’est pas optionnel. Chaque requête LLM a un coût direct (tokens input + output, modèle utilisé, tokens cachés ou non), et ce coût doit être attribué au bon tenant pour la facturation, l’analytics, et la rentabilité par client.

LiteLLM propose une architecture multi-tenant native avec suivi des coûts à quatre niveaux : organisation, équipe, utilisateur, clé API. Chaque appel API est tracé avec le contexte complet du tenant. Les budgets sont hiérarchiques : le budget d’une équipe ne peut pas dépasser celui de l’organisation. En version enterprise, les organisations fonctionnent comme des tenants de premier niveau avec leurs propres administrateurs.

Les métriques clés à tracker par tenant : nombre de requêtes, tokens consommés (input/output/cached), coût en dollars, latence P50/P95/P99, taux d’erreur, et modèles utilisés. Ces données alimentent à la fois la facturation et le monitoring de la qualité de service par tenant.

Sécurité multi-tenant pour l’IA

Isolation des données

Chiffrement par tenant. Au-delà du chiffrement at-rest global (AES-256), les architectures les plus sécurisées utilisent des clés de chiffrement par tenant (customer-managed keys / CMK). Si la clé du tenant A est compromise, les données du tenant B restent protégées.

Résidence des données. Certains tenants exigent que leurs données restent dans une région géographique spécifique (RGPD pour l’Europe, lois locales pour certains pays). L’API Gateway route les requêtes vers l’infrastructure dans la bonne région en fonction du tenant.

Audit trail. Chaque accès aux données d’un tenant est loggé avec le timestamp, l’identité de l’appelant, et l’opération. Ces logs sont indispensables pour la compliance (SOC 2, HIPAA, ISO 27001) et pour détecter les accès non autorisés.

Isolation des prompts et réponses

Les prompts des clients contiennent souvent des données confidentielles (données clients, stratégies business, informations personnelles). En multi-tenant, il faut garantir que les prompts et réponses du tenant A ne fuient jamais vers le tenant B, y compris via les caches, les logs, et les datasets d’entraînement.

Concrètement : les caches de prompts sont isolés par tenant (ou le cache key inclut le tenant_id). Les logs de production sont filtrés par tenant pour le support. Les données de conversation ne sont jamais utilisées pour l’entraînement sans consentement explicite. Et le pipeline de prompt caching inclut le tenant_id dans la clé de cache pour éviter qu’un tenant bénéficie du cache d’un autre.

Bonnes pratiques

Commencez par le Pool, graduez vers le Bridge. La plupart des SaaS IA devraient démarrer avec un modèle Pool (base partagée + RLS, index vectoriel partagé + filtre, serveur d’inférence partagé + rate limiting par tenant). Quand les premiers clients enterprise arrivent, ajoutez le tier Silo avec des ressources dédiées. Ne sur-ingénieriez pas au départ.

Injectez le tenant_id au plus tôt, vérifiez-le au plus tard. L’API Gateway injecte le tenant_id dans chaque requête (header ou contexte). Chaque couche du système le propage. La base de données le vérifie via RLS. Le vecteur store le filtre. Le metering le log. Si le tenant_id est absent à n’importe quelle étape, la requête échoue explicitement plutôt que silencieusement.

Testez l’isolation automatiquement. Chaque endpoint de votre API doit avoir un test qui vérifie qu’un tenant A ne peut pas accéder aux données d’un tenant B. Ces tests doivent tourner dans votre CI/CD à chaque déploiement. Un test manquant est une faille en attente.

Stockez la configuration par tenant. Modèle LLM préféré, stratégie de chunking, template de prompt, budget de tokens, plafond de dépense, région de résidence des données. Toute cette configuration doit être récupérable par tenant_id et injectée dans chaque étape du pipeline.

Prévoyez la « graduation » des tenants. Un tenant PME qui grandit deviendra un tenant enterprise qui exige du Silo. Concevez votre système pour que cette migration soit un changement de configuration (tier dans la table tenants), pas une migration de données manuelle.