Un serveur d’IA domestique peut-il partager un même modèle entre plusieurs sessions utilisateur ?

Oui. Un seul serveur d’IA domestique peut charger un modèle une fois et servir plusieurs sessions utilisateur. Les serveurs d’inférence modernes sont conçus pour partager les coûteux poids du modèle tout en conservant un état de requête distinct pour chaque conversation. Cela consomme bien moins de mémoire que de charger une seconde copie du même modèle pour chaque membre de la famille.

La principale limite de mise à l’échelle ne vient généralement pas des poids. Elle vient de l’augmentation du cache KV, de la longueur du contexte, de la génération simultanée de tokens et de la mise en file d’attente créée par les utilisateurs actifs. La mise à disposition pour plusieurs utilisateurs est donc autant un problème de planification qu’un problème de taille du modèle.

Qu’est-ce qui est réellement partagé entre les utilisateurs ?

                 Un modèle chargé
                 poids en RAM/VRAM
                         |
       +-----------------+-----------------+
       |                 |                 |
    Session A        Session B        Session C
   Cache KV A        Cache KV B        Cache KV C
   historique A         historique B         historique C

Les poids du transformeur sont en lecture seule pendant l’inférence ordinaire, de nombreuses requêtes peuvent donc utiliser la même copie. Chaque séquence a néanmoins besoin de son propre état de tokens et de son propre cache d’attention.

Comment les serveurs d’inférence gèrent-ils les requêtes simultanées ?

Les différents moteurs d’exécution proposent des contrôles de planification différents, mais le principe reste similaire : accepter plusieurs séquences, regrouper le travail lorsque c’est possible et placer les requêtes excédentaires en file d’attente.

La FAQ d’Ollama documente les contrôles des requêtes parallèles et indique que l’augmentation du contexte parallèle accroît les besoins en mémoire. L’exemple parallèle de llama.cpp montre plusieurs clients simulés utilisant un même serveur de modèle.

Les serveurs à haut débit tels que vLLM utilisent le traitement par lots et une planification tenant compte du cache KV pour maintenir les accélérateurs occupés avec plusieurs séquences entrantes.

Pourquoi la longueur du contexte peut consommer plus de mémoire que ne le suggère un autre utilisateur

Supposons que les poids du modèle tiennent largement dans la VRAM. Quatre utilisateurs ouvrent chacun une très longue conversation. Les poids ne sont pas multipliés par quatre, mais le cache KV peut augmenter considérablement pour chaque séquence active.

budget de VRAM
  |
  +-- poids du modèle      fixes
  +-- cache KV de l’utilisateur A    augmente avec le contexte
  +-- cache KV de l’utilisateur B    augmente avec le contexte
  +-- cache KV de l’utilisateur C    augmente avec le contexte
  +-- surcharge d’exécution

C’est pourquoi « le modèle tient en mémoire » ne suffit pas pour planifier la capacité. Les systèmes multi-utilisateurs doivent définir une longueur de contexte maximale, un nombre maximal de séquences simultanées et une file d’attente limitée.

Le guide existant de ZimaSpace sur la planification des accélérateurs pour l’IA domestique multi-utilisateur approfondit la même limite de ressources.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Chaque utilisateur devrait-il disposer d’un processus de modèle dédié ?

Généralement, non. Des processus distincts dupliquent les poids et réduisent le nombre de modèles pouvant tenir en mémoire. Ils peuvent néanmoins être pertinents lorsque :

• les utilisateurs ont besoin de réglages fins ou de quantifications différents ;
• une isolation forte des processus est plus importante que l’efficacité ;
• une charge de travail utilise un environnement d’exécution personnalisé ;
• vous souhaitez une allocation stricte du GPU par utilisateur ;
• un modèle possède des exigences incompatibles en matière de contexte ou d’échantillonnage.

Pour une famille ou une petite équipe utilisant le même modèle, un seul service d’inférence derrière une application authentifiée est généralement plus simple.

Conservez la mémoire des conversations en dehors du serveur de modèles

Le serveur d’inférence ne doit pas constituer la base de données faisant autorité pour déterminer « qui a dit quoi ». Stockez l’historique des conversations et les préférences des utilisateurs dans la couche applicative, avec un identifiant explicite d’utilisateur/session.

Navigateur / application
    |
    | user_id authentifié
    v
Application de chat
    |
    +-- base de données de l’historique (par utilisateur)
    +-- autorisations RAG
    |
    v
Serveur de modèles partagé

Avant chaque génération, l’application assemble uniquement l’historique et le contexte privé issu de la recherche auxquels l’utilisateur actuel est autorisé à accéder.

Cela est particulièrement important pour un assistant IA privé sur un NAS, lorsque le même serveur peut contenir des documents personnels appartenant à plusieurs membres d’un foyer.

La mise en cache des préfixes partagés n’est pas une mémoire de conversation partagée

Certains environnements d’exécution peuvent réutiliser le cache KV ou d’autres calculs pour les préfixes d’invite courants. Une instruction système partagée ou le préfixe répété d’un document peut donc être calculé une fois, puis réutilisé efficacement.

Cette optimisation ne doit pas être confondue avec le fait d’autoriser le contexte privé d’un utilisateur à s’insérer dans l’invite d’un autre. Les systèmes de cache nécessitent une isolation et des sémantiques de hachage correctes ; les autorisations de l’application déterminent toujours quel contenu peut être fourni à une requête.

Utilisez une planification équitable pour qu’un utilisateur ne puisse pas monopoliser le serveur

Une seule requête demandant une sortie très longue peut monopoliser la capacité de décodage pendant que les autres utilisateurs attendent. Ajoutez des contrôles d’admission tels que :

• limite de requêtes simultanées par utilisateur ;
• nombre maximal de jetons en sortie ;
• fenêtre de contexte maximale ;
• nombre maximal global de séquences actives ;
• délai d’expiration de la file d’attente ;
• priorité aux requêtes interactives courtes ;
• file d’attente distincte pour les tâches en arrière-plan.

Le chat interactif et la synthèse de documents pendant la nuit ne devraient pas être soumis à une politique de planification identique.

Que se passe-t-il lorsque le serveur manque de mémoire ?

Un bon service rejette ou met en file d’attente les nouvelles tâches avant que l’accélérateur ne plante. Les contrôles de capacité doivent utiliser le contexte réellement configuré, et pas seulement une moyenne optimiste.

Ne réduisez pas silencieusement la fenêtre de contexte de chaque utilisateur jusqu’à ce que le serveur cesse de planter. Rendez la politique de contexte visible afin que les utilisateurs sachent ce que le système peut conserver.

La confidentialité et l’authentification sont encore plus importantes en mode multi-utilisateur

Lorsqu’un modèle sert un seul administrateur, un point de terminaison accessible uniquement en local peut suffire. Dès que plusieurs personnes l’utilisent, l’application doit authentifier les utilisateurs et autoriser l’accès à leurs sources de données.

Protégez :

• l’historique des conversations ;
• les collections RAG et les ACL des documents ;
• les invites enregistrées ;
• les identifiants d’accès aux outils ;
• les fichiers générés ;
• les journaux et les traces.

Un processus de modèle partagé ne devrait voir que le contexte de la requête en cours et ne devrait pas devenir un moyen pratique de contourner le modèle habituel de gestion des autorisations du NAS.

Combien d’utilisateurs un serveur d’IA domestique peut-il prendre en charge ?

Il n’existe pas de nombre fixe réellement utile. Un serveur peut prendre en charge de nombreux utilisateurs enregistrés si seuls une ou deux personnes sont actives, tandis que deux utilisateurs simultanés avec un contexte long peuvent saturer un petit GPU.

Évaluez trois scénarios :

1. un utilisateur interactif ;
2. la charge simultanée prévue dans votre foyer ;
3. un utilisateur intensif et plusieurs requêtes courtes.

Mesurez le délai avant le premier jeton, le nombre de jetons par seconde et par utilisateur, le temps d’attente dans la file, l’utilisation du cache KV, l’utilisation de la RAM/VRAM et le taux d’échec des requêtes.

FAQ

Les utilisateurs verront-ils les conversations des autres parce que le modèle est partagé ?

Non, si l’application conserve séparément l’historique des conversations et le contexte issu de la récupération. Le partage des poids du modèle n’implique pas le partage de l’historique des conversations.

L’inférence parallèle accélère-t-elle chaque utilisateur ?

Cela peut augmenter le débit total, mais chaque requête individuelle peut recevoir moins de puissance de calcul lorsque plusieurs séquences sont actives. L’objectif est généralement d’améliorer le service global et de réduire le temps d’attente dans la file.

Un seul serveur peut-il aussi héberger plusieurs modèles ?

Oui, si la mémoire le permet. Certains environnements d’exécution chargent et déchargent les modèles selon les besoins, tandis que d’autres sont conçus autour d’un ou de plusieurs processus de diffusion persistants. La planification de plusieurs modèles ajoute un niveau de capacité supplémentaire par rapport à la planification multi-utilisateur.

Verdict final

Un modèle chargé est généralement exactement la ressource qu’un petit service d’IA domestique devrait partager. Gardez les poids du modèle communs, isolez l’historique des sessions et l’état KV, authentifiez chaque utilisateur, limitez le contexte et la concurrence, et planifiez séparément les tâches en arrière-plan et le chat interactif. L’IA multi-utilisateur devient fiable lorsque vous prévoyez l’état propre à chaque session et le comportement de la file d’attente, au lieu de multiplier les processus du modèle.