Quelles fonctionnalités permettent l’isolation de chaque utilisateur sur un serveur d’IA domestique partagé ?

L’isolation par utilisateur nécessite une autorisation liée à l’identité à chaque frontière de données et d’outils, ainsi que des contrôles de ressources qui empêchent un membre du foyer de monopoliser le serveur partagé.

Un seul GPU domestique peut servir plusieurs membres d’une famille sans charger un modèle distinct pour chacun, mais l’inférence partagée n’équivaut pas à un accès partagé. La passerelle doit conserver l’identité de l’auteur de chaque requête, filtrer la récupération et la mémoire en fonction de cette identité, ne déléguer que des identifiants aux droits limités et appliquer des files d’attente ou des quotas par utilisateur avant que les tâches n’atteignent les services communs de modèles et de stockage.

L’identité doit être préservée sur l’ensemble du parcours de la requête

L’authentification établit qui utilise l’interface, mais l’isolation dépend de la transmission de cette identité lors de la récupération, de l’assemblage des invites, des appels d’outils, de la journalisation et des tâches en arrière-plan. La remplacer par un compte de service partagé détruit le contexte nécessaire aux décisions d’autorisation en aval.

Une architecture détaillée d’isolation de l’identité des locataires sépare l’identité des locataires, l’isolation des données, le chiffrement, les limites de débit et les quotas de ressources. Les mêmes frontières s’appliquent à l’échelle d’un foyer, où chaque utilisateur dispose de fichiers privés et de privilèges d’automatisation différents.

Les jetons de délégation à courte durée de vie doivent identifier à la fois l’utilisateur et l’action de l’agent. Les services les valident indépendamment au lieu de faire confiance à un texte d’identité présent dans l’invite, que le LLM peut mal interpréter ou qu’un document injecté peut manipuler.

Les données, la mémoire et les identifiants nécessitent des espaces de noms distincts

Chaque document, fragment, élément de mémoire, conversation et identifiant d’outil doit comporter une règle de propriété ou de groupe autorisé. La récupération applique ces filtres avant que les résultats potentiels n’entrent dans le contexte du modèle, et les caches incluent la portée d’autorisation afin qu’un résultat privé ne puisse pas être réutilisé pour un autre utilisateur.

Une conception de contrôle d’accès au moment de la requête pour les représentations vectorielles préserve le contexte des contrôles d’accès aux fichiers avec le contenu indexé. Elle montre pourquoi la similarité sémantique doit rester subordonnée aux autorisations d’origine plutôt que devenir un nouveau moyen de les contourner.

Les identifiants nécessitent l’espace de noms le plus restreint. L’assistant d’un enfant peut lire un calendrier partagé, mais pas les e-mails d’un parent ; un flux multimédia peut écrire dans un dossier, mais pas dans tous les partages NAS. Le modèle voit les descriptions des outils, tandis que la passerelle d’exécution conserve et fournit les secrets réels.

L’isolation du calcul contrôle les voisins bruyants, pas l’accès aux données

Les limites de concurrence par utilisateur, les budgets de jetons, les pondérations des files d’attente et l’annulation empêchent une longue génération de monopoliser les créneaux du GPU. Le processeur, la mémoire vive, le stockage temporaire et la sortie réseau doivent également être limités, car les charges d’outils peuvent épuiser le serveur en dehors du modèle.

Une conception de service fondée sur des quotas de jetons par client explique l’étiquetage des requêtes, l’application des quotas, le contrôle des voisins bruyants et la planification partagée des GPU. Ces mécanismes améliorent l’équité, mais ne remplacent pas l’autorisation des documents et des identifiants. Cette distinction reste visible lors des tests ultérieurs au sein du foyer.

La faille consiste à supposer qu’une session de discussion distincte équivaut à une isolation. Les caches vectoriels partagés, les caches de préfixes, les fichiers temporaires, les journaux ou les identifiants de service trop larges peuvent tout de même faire circuler des données entre utilisateurs. Testez chaque composant partagé avec des clés tenant compte de l’identité et des refus d’accès, pas uniquement la base de données visible de l’application.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Effectuez un test d’isolation entre utilisateurs

Créez deux comptes avec un document partagé, un document privé pour chacun, des mémoires distinctes, des autorisations d’outils différentes et des quotas de calcul inégaux. Envoyez depuis les deux identités des requêtes sémantiquement identiques, des tentatives directes de deviner des chemins, des requêtes visant à réchauffer le cache, de longues invites concurrentes et des tâches en arrière-plan.

Comparez la frontière d’autorisation avec l’isolation fondée sur les capacités, qui considère la portée des capacités comme un élément de la sécurité des agents plutôt que comme un simple comportement des invites. Consignez les lectures réussies, les tentatives refusées, le délai d’attente dans la file, les clés de cache, l’identité de l’identifiant délégué et les événements d’audit.

Le test n’est réussi que lorsque les éléments partagés sont visibles pour les deux utilisateurs, que les éléments privés n’entrent jamais dans l’autre contexte et qu’une charge de travail ne peut pas affamer l’autre au-delà de la politique déclarée. Toute récupération interutilisateur dans le cache contenant du contexte privé constitue un défaut bloquant.