Résumé Technique : FMplex – Virtualisation de Modèles pour le Service de Modèles Fondations Extensibles

Problématique

Les modèles de fondation (Foundation Models - FM) sont devenus l'épine dorsale de diverses applications en aval dans les domaines du langage, de la vision, des séries temporelles et multimodaux. Cependant, les systèmes de service de modèles existants (par exemple, NVIDIA Triton) sont conçus autour d'un paradigme « une instance par tâche », où chaque tâche personnalisée charge une copie séparée et indépendante du modèle. Cette approche est inefficace pour les FM car :

1. Gaspillage de ressources : Les FM sont composés d'un énorme noyau partagé (souvent de plusieurs gigaoctets) et d'extensions légères spécifiques à la tâche (têtes, adaptateurs). Charger un noyau complet pour chaque tâche réplique la composante la plus lourde, gaspillant ainsi la mémoire de l'accélérateur.
2. Perte d'efficacité : Les instances indépendantes empêchent l'amortissement des coûts de mise en lot (batching) et de chargement entre les tâches.
3. Interférence et isolation : Le simple co-emplacement de tâches sur un GPU partagé sans séparation logique entraîne une interférence entre les tâches, où les pics de charge d'une tâche dégradent les performances des autres.
4. Rigidité du cycle de vie : Les systèmes actuels couplent le cycle de vie de la tâche à l'instance physique du modèle, ce qui rend difficile l'ajout, la suppression ou la modification de tâches sans redéployer l'intégralité du noyau.

L'article soutient que le noyau (backbone) du FM devrait être traité comme un substrat système partagé (analogue à un processeur ou à la mémoire dans la virtualisation de système d'exploitation) plutôt que comme un artefact de déploiement par tâche.

Méthodologie : FMplex

Les auteurs présentent FMplex, un système de service qui introduit la Virtualisation de Modèle de Fondation. Le concept central est le Modèle de Fondation Virtuel (vFM), une instance de FM logiquement privée présentée à chaque tâche, qui est soutenue par une instance physique de FM partagée.

Composants Architecturaux Clés

1. Abstraction du Modèle de Fondation Virtuel (vFM) :

   • Découplage : Le vFM découple la vue logique de la tâche (personnalisation, état, cycle de vie) du noyau physique.
   • Structure : Chaque vFM comprend une File d'attente Virtuelle (pour le routage des requêtes), des Extensions de Tâche (encodeurs, décodeurs et adaptateurs PEFT comme LoRA) et un État/Comptabilité (SLO, priorités, poids).
   • Mécanisme : Lorsqu'une tâche invoque son vFM, FMplex intercepte l'appel, le route à travers la file d'attente virtuelle et l'exécute sur le noyau physique partagé, en appliquant les adaptateurs spécifiques à la tâche si nécessaire.

2. Ordonnanceur Batch-Aware Fair Queueing (BFQ) :

   • Défi : Les ordonnanceurs de partage équitable standard (par exemple, Start-Time Fair Queueing) opèrent sur une base par requête et ne tiennent pas compte des gains d'efficacité de la mise en lot des requêtes, ce qui est crucial pour le débit des FM.
   • Solution : BFQ est un ordonnanceur conservateur de travail qui approxime le partage équitable pondéré tout en optimisant le batching.
   • Fonctionnement : Il attribue des étiquettes de début/fin aux requêtes en fonction des poids des tâches. Il forme de manière itérative des lots jusqu'à une taille maximale ($B_{max}$) ou jusqu'à ce qu'une échéance SLO soit violée.
   • Gestion des adaptateurs : BFQ gère l'incompatibilité des adaptateurs en regroupant d'abord les requêtes sur le noyau commun, puis en traitant séquentiellement les différences d'adaptateurs incompatibles, garantissant l'équité sans sacrifier l'efficacité du batching.
   • Support basé sur les tokens : Pour les FM basés sur les tokens (par exemple, les LLM), BFQ facture le travail au niveau du token en unités de temps de service pour maintenir la cohérence avec les temps d'exécution par requête.

3. Task-API et Pile de Service :

   • Task-API : Une interface de programmation permettant aux utilisateurs de construire des pipelines de tâches en attachant des encodeurs, des décodeurs et des adaptateurs à un vFM. Elle supporte à la fois l'inférence et l'ajustement fin (fine-tuning) en utilisant le même objet de pipeline.
   • FMplex-Controller : Un contrôleur au niveau du cluster qui gère le plan de déploiement. Il utilise une heuristique "Max-Share" pour lier les tâches à des noyaux physiques existants chaque fois que possible, minimisant ainsi l'instanciation de nouveaux noyaux.
   • Adaptation Élastique : Lorsque la charge change, le système peut re-lier le vFM d'une tâche à un autre noyau physique existant, en déplaçant uniquement l'état léger de la tâche (files d'attente, adaptateurs) plutôt que de recharger le noyau lourd.

Contributions Clés

1. Virtualisation de FM pour le Partage de Déploiement : L'introduction de l'abstraction vFM, qui permet à plusieurs tâches indépendamment personnalisées de partager une seule instance physique de FM tout en maintenant une isolation logique et des cycles de vie indépendants.
2. Pile de Service Basée sur le Partage : Un système de bout en bout intégrant la Task-API pour la construction extensible de tâches et le FMplex-Controller pour le déploiement de cluster conscient du partage.
3. Implémentation Prototype : Un prototype fonctionnel supportant plusieurs modalités (séries temporelles, vision, LLM, VLM) et environnements d'exécution (PyTorch, vLLM), démontrant la flexibilité à travers des FM hétérogènes.
4. Évaluation Complète : Une évaluation rigoureuse sur 7 noyaux FM (16 variantes) et 92 tâches en aval.

Résultats Expérimentaux

L'évaluation a été menée sur un cluster AWS de 16 nœuds (GPU NVIDIA T4) en utilisant des traces synthétiques et réelles (Azure Functions).

• Réduction de la Latence :

  • Comparé au Partitionnement Spatial (isolation des tâches sur des partitions de GPU), FMplex a réduit la latence jusqu'à 80 %.
  • Comparé au Co-emplacement Best-Effort (plusieurs instances complètes sur un seul GPU sans isolation), FMplex a réduit la latence jusqu'à 33,3 %.
  • À l'échelle du cluster, FMplex a réduit la latence moyenne de 15 % et la latence P99 de 26 % par rapport au co-emplacement best-effort.

• Efficacité des Ressources et Scalabilité :

  • Mémoire : FMplex réduit considérablement l'utilisation de la mémoire GPU. Par exemple, le co-emplacement de 10 tâches de séries temporelles sur un noyau partagé n'a nécessité que 1,17× la mémoire d'une seule tâche, contre 10× pour un déploiement indépendant.
  • Débit : FMplex a maintenu jusqu'à 6× plus de tâches à faible charge (où la mémoire est le goulot d'étranglement) et 8 à 12 % de tâches supplémentaires à charge modérée/élevée (où le calcul est le goulot d'étranglement) par rapport au co-emplacement best-effort.
  • Équité : Sous des poids de service asymétriques (par exemple, 3:1), FMplex a maintenu des scores d'équité de 0,97–0,98 tout en soutenant 84 RPS. En revanche, le partage équitable non-batché a atteint une équité similaire à seulement 37 RPS, et le partage non géré a fait chuter l'équité à 0,66.

• Surcoût d'Adaptation :

  • FMplex a démontré une adaptation rapide aux augmentations de charge. Le re-liaison d'une tâche à un noyau existant a pris 0,5 seconde, alors que le chargement d'une nouvelle instance de noyau (requis par les systèmes sans partage) a pris environ 58 secondes, provoquant un pic de latence de deux ordres de grandeur.

• Surcoût (Overhead) :

  • Le surcoût de planification introduit par FMplex (gestion des files d'attente et calcul des étiquettes) est minime, avec une moyenne de 0,35 ms par requête, ce qui est négligeable par rapport aux temps d'exécution du noyau.

Signification et Revendications

L'article affirme que FMplex répond au décalage fondamental entre l'architecture des Modèles de Fondation (noyaux lourds partagés, extensions légères) et les systèmes de service actuels (déploiement par instance). En traitant le noyau du FM comme un substrat de virtualisation, FMplex permet :

• Partage de Déploiement : L'amortissement des coûts massifs de mémoire et de calcul du noyau sur plusieurs tâches.
• Isolation des Tâches : Fournir des garanties de performance par tâche et une isolation sans la pénalité de ressources d'une réplication complète du modèle.
• Flexibilité Opérationnelle : Permettre l'ajout, la suppression ou la modification de tâches de manière dynamique sans redéployer l'infrastructure sous-jacente.

Les auteurs positionnent FMplex non pas seulement comme une optimisation pour des modèles spécifiques, mais comme une couche système généralisable qui étend les principes classiques de la virtualisation au domaine du service de Modèles de Fondation, permettant une infrastructure d'IA plus efficace et évolutive.