Quels composants permettent à plusieurs modèles locaux de partager un même accélérateur ?

Plusieurs modèles locaux peuvent partager un même accélérateur lorsque la couche de service coordonne la résidence des poids, la mémoire dynamique, le temps d’exécution et l’isolation des requêtes entre les charges de travail.

Un GPU domestique peut alterner entre un modèle conversationnel, un modèle d’embeddings, un encodeur visuel et un système de reconnaissance vocale. Charger en permanence tous les ensembles de poids peut dépasser la VRAM disponible, tandis que les décharger à chaque requête rend la latence avant le premier token imprévisible. Un contrôleur multimodèle a besoin d’une politique de résidence, d’une comptabilisation de la mémoire entre modèles, de la planification, de l’isolation des caches, de la préemption et de l’équité, plutôt que de laisser des processus distincts se disputer aveuglément les ressources.

La politique de résidence détermine quels poids restent chargés

Le contrôleur suit la taille du modèle, le taux d’arrivée, le temps de chargement, l’objectif de latence et l’utilisation récente. Les modèles populaires restent résidents, les modèles peu fréquents occupent la mémoire du processeur ou le stockage, et la demande prévue peut déclencher un préchargement avant que la prochaine requête n’atteigne l’accélérateur.

Le préchargement multimodèle prépare des workers GPU universels pour plusieurs modèles et coordonne le préchargement avec un placement tenant compte de l’éviction. Ses résultats montrent pourquoi éviter un chargement à froid peut améliorer considérablement le délai avant le premier token lorsque la demande est prévisible. Cette distinction reste visible lors des tests domestiques ultérieurs.

Les décisions de résidence doivent inclure la quantification et les variantes d’adaptateurs, car deux points de terminaison apparemment similaires peuvent contenir des poids de base différents. Une limite stricte de mémoire empêche le chargement proactif d’évincer le cache KV des requêtes actives. Le résultat intermédiaire doit rester inspectable avant que l’automatisation ne poursuive le processus.

La coordination de la mémoire entre modèles évite la fragmentation de la capacité

Les poids sont pour la plupart stables, tandis que les activations et les caches KV augmentent avec la taille des lots et la longueur des séquences. Un allocateur partagé peut mapper les pages mémoire à la demande, récupérer les régions inactives et exposer des réservations afin qu’un modèle ne puisse pas consommer l’espace promis à un autre.

La coordination de la mémoire entre modèles introduit une coordination intermodèle de la mémoire, avec un mappage dynamique des pages virtuelles vers les pages physiques et des politiques de partage à l’exécution. Cette conception explique pourquoi le partage ordinaire du GPU au niveau des processus réagit mal à l’évolution rapide de la demande des modèles. Cette limite doit être mesurée séparément dans des conditions d’utilisation réalistes.

Le partage de mémoire n’est pas un partage de données. Les blocs de cache KV, les caches de préfixes, les tampons temporaires et l’état des adaptateurs nécessitent des identifiants de locataire et de modèle ; sinon, une page ou une clé de cache réutilisée peut divulguer le contexte ou fausser les résultats entre les points de terminaison.

La planification et le multiplexage des adaptateurs contrôlent le temps d’exécution

Un ordonnanceur choisit entre le partage spatial, où les modèles occupent simultanément la mémoire, et le partage temporel, où les noyaux s’exécutent à tour de rôle. Le traitement continu par lots améliore le débit, tandis que la préemption et les files d’attente pondérées protègent une requête interactive contre une longue tâche en arrière-plan.

Le multiplexage des adaptateurs permet de servir des milliers d’adaptateurs de faible rang sur des modèles de base partagés, en paginant les poids des adaptateurs et en coordonnant des lots hétérogènes. Il montre comment la spécialisation peut partager davantage d’état que des répliques de modèles complètement séparées. La conséquence pratique apparaît lorsque plusieurs sources se disputent un contexte limité.

La limite critique se situe au niveau des interférences entre noyaux et mémoire. Deux modèles qui tiennent simultanément en mémoire peuvent tout de même ne pas atteindre leurs objectifs de latence lorsqu’ils se disputent les ressources de calcul, la bande passante ou les moteurs de copie. Le partage n’est utile que si la latence p95 et l’équité par modèle restent conformes à la politique, et non lorsque la seule utilisation agrégée semble élevée.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Créez une matrice d’interférences du partage des modèles

Mesurez chaque modèle seul, puis exécutez chaque paire importante ainsi que le mélange prévu de quatre modèles avec des requêtes courtes, longues, en rafale et en arrière-plan. Consignez le temps de chargement à froid, la mémoire résidente, la croissance du cache KV, l’utilisation des noyaux, le débit, la latence p50 et p95 ainsi que les évictions.

Utilisez le principe de la pile routée présenté dans la résidence des modèles routés pour attribuer une priorité et une classe de résidence à chaque point de terminaison. Recommencez avec des adaptateurs, des variantes quantifiées, le traitement continu par lots et la préemption, tout en vérifiant que les caches et les identités des requêtes restent isolés.

Ne conservez une politique de partage que lorsque les modèles interactifs importants atteignent leur objectif de latence dans le pire mélange prévu. Si une paire provoque des remplacements répétés, sérialisez cette paire ou réservez une plage horaire au lieu d’augmenter la concurrence pour obtenir un meilleur graphique d’utilisation.