Cornserve: A Distributed Serving System for Any-to-Any Multimodal Models

Le papier présente Cornserve, un système de service distribué open-source conçu pour les modèles multimodaux « any-to-any » qui permet le découplage des composants et une mise à l'échelle indépendante, offrant ainsi une augmentation significative du débit et une réduction de la latence grâce à un modèle d'exécution efficace basé sur Kubernetes.

L'essentiel

Imaginez que vous êtes le directeur d'un restaurant très spécial, appelé Cornserve. Ce restaurant ne sert pas de la nourriture ordinaire, mais des "plats" numériques très complexes appelés modèles "Any-to-Any".

Pour faire simple, ces modèles sont des chefs d'orchestre intelligents capables de comprendre et de créer n'importe quelle combinaison de médias : du texte, des images, de la vidéo, de l'audio, ou tout cela mélangé !

Voici comment Cornserve fonctionne, expliqué comme une histoire de restaurant :

1. Le Problème : Un Menu Trop Complexe

Dans le passé, les restaurants (les systèmes informatiques) étaient spécialisés. Il y avait un restaurant pour les livres (texte), un autre pour les peintures (images), et un troisième pour la musique (audio).

Mais aujourd'hui, les clients veulent des plats hybrides : "Donnez-moi une image, transformez-la en texte, puis lisez ce texte à haute voix en chantant."
C'est là que ça coince. Si vous essayez de faire tout cela dans une seule grande cuisine (un seul ordinateur puissant), c'est un chaos :

• Certains clients commandent juste du texte (rapide).
• D'autres demandent de la vidéo (très lent et gourmand).
• Si tout le monde utilise la même cuisine, le chef qui prépare la vidéo bloque tout le monde, même ceux qui ne voulaient que du texte. C'est comme si un seul cuisinier devait tout faire, et les clients attendent trop longtemps.

2. La Solution de Cornserve : La "Cuisine Modularisée"

Cornserve change la donne en appliquant trois règles simples, comme si le restaurant était réorganisé en une usine de production ultra-efficace.

A. La Carte Flexible (L'Abstraction des Tâches)

Au lieu d'avoir un menu rigide, Cornserve permet aux chefs (les développeurs) d'écrire des recettes en Python (un langage simple) comme s'ils écrivaient une liste de courses.

• Ils disent : "Prends l'ingrédient A, passe-le au chef B, puis au chef C".
• Le système comprend que chaque client a une commande différente. Si un client veut juste du texte, le système saute l'étape "image" et va directement au chef "texte". C'est comme un robot qui lit la commande et envoie les ingrédients uniquement aux chefs concernés.

B. La "Fission" du Modèle (Découper le Chef en Équipes)

C'est l'idée la plus brillante. Au lieu d'avoir un seul "Super-Chef" géant qui fait tout, Cornserve découpe le modèle en plusieurs petits chefs spécialisés :

• Un chef pour les images.
• Un chef pour le texte.
• Un chef pour la voix.
• Un chef pour la vidéo.

Chacun travaille dans sa propre petite cuisine (sur sa propre carte graphique/GPU).

• L'avantage : Si vous avez 100 clients qui veulent juste du texte, vous n'avez pas besoin de 100 chefs de vidéo. Vous pouvez avoir un seul chef de vidéo et 50 chefs de texte. Le système ajuste automatiquement le nombre de chefs en fonction de la demande. C'est comme avoir une équipe de secours qui arrive quand il y a beaucoup de commandes de pizza, mais qui rentre chez elle quand il n'y en a pas.

C. Le Service Express (Le "Sidecar" et la Mémoire Partagée)

Comment ces petits chefs se parlent-ils ? Ils ne s'envoient pas de courriers postaux lents.
Cornserve utilise un système de tuyaux ultra-rapides (appelés Sidecars).

• Quand le chef "Image" finit son travail, il glisse le résultat directement dans un tuyau de mémoire partagée.
• Le chef "Texte" qui attend juste à côté le récupère instantanément.
• C'est comme si les cuisiniers avaient des glissières entre leurs comptoirs : pas de temps perdu à courir ou à attendre. Même si les cuisines sont dans des bâtiments différents (sur différents serveurs), des "tuyaux à haute vitesse" (RDMA) relient tout.

3. Le Résultat : Plus Rapide et Plus Économe

Grâce à cette organisation, Cornserve a prouvé qu'il pouvait :

• Servir jusqu'à 3,8 fois plus de clients en même temps que les anciens systèmes.
• Réduire le temps d'attente (la "latence") jusqu'à 5,8 fois. Imaginez passer de 10 minutes d'attente à 1 minute pour votre plat !
• Économiser de l'énergie : Comme on ne fait tourner que les chefs nécessaires, on ne gaspille pas de ressources.

En Résumé

Cornserve, c'est comme transformer un restaurant où un seul chef fait tout (et s'épuise) en un restaurant gastronomique modulaire où chaque tâche a son expert, où les commandes sont routées intelligemment, et où la communication entre les cuisines est instantanée.

C'est la première fois qu'un système aussi flexible existe pour gérer ces modèles "tout-en-un" qui peuvent voir, entendre, lire et parler en même temps. C'est une révolution pour rendre l'intelligence artificielle plus rapide et plus accessible à tout le monde.

Résumé technique

1. Problématique

Les modèles Any-to-Any (de n'importe quel type vers n'importe quel type) représentent une nouvelle classe de modèles multimodaux capables d'accepter des combinaisons variées de données (texte, image, vidéo, audio) en entrée et d'en générer en sortie. Cependant, leur mise en production (serving) pose des défis majeurs que les systèmes actuels ne parviennent pas à résoudre efficacement :

• Hétérogénéité des chemins de calcul : Selon la combinaison des modalités d'entrée et de sortie demandées par l'utilisateur, le graphe de calcul du modèle change. Une requête peut activer un encodeur d'image et un LLM, tandis qu'une autre peut activer un encodeur vidéo, un LLM et un générateur audio.
• Hétérogénéité des caractéristiques de mise à l'échelle : Les différents composants d'un même modèle (ex: encodeurs, LLM, générateurs) ont des besoins en ressources et des performances de calcul très différents. Par exemple, sur une même GPU A100, la génération de texte peut être 4 fois plus rapide que la génération audio.
• Limites des solutions existantes : Les systèmes actuels comme vLLM (axé sur le texte) ou xDiT (axé sur la diffusion d'images/vidéos) sont des solutions ponctuelles. Ils ne gèrent pas la complexité des graphes de calcul arbitraires ni le "fission" (découpage) dynamique des modèles multimodaux complexes.

2. Méthodologie et Architecture

Cornserve est un système de serving distribué conçu spécifiquement pour gérer ces modèles génériques. Il repose sur une architecture Kubernetes avec environ 23 000 lignes de code Python.

A. Abstraction des Tâches et Fission de Modèle

Cornserve introduit une abstraction logicielle flexible en trois niveaux :

1. Unités de tâche (Unit Tasks) : Représentent des composants atomiques (ex: EncoderTask, LLMTask, GeneratorTask).
2. Tâches composites : Permettent aux développeurs d'exprimer la logique du modèle en Python pur, en composant des unités de tâche.
3. Applications (Apps) : Le module d'entrée qui orchestre les tâches.

La Fission de Modèle (Model Fission) permet de découper le modèle à n'importe quelle frontière de composant. Chaque composant peut être déployé sur des GPU dédiés avec des exécuteurs spécialisés (ex: Eric pour les encodeurs multimodaux, une version forkée de vLLM pour les LLM, Geri pour les générateurs). Cela permet une mise à l'échelle indépendante : on peut avoir plusieurs répliques d'un générateur audio lent pour équilibrer la charge avec un LLM rapide.

B. Exécution Enregistrement-Rejeu (Record-and-Replay)

C'est le cœur du moteur d'exécution distribué. Pour gérer les chemins de calcul dynamiques et complexes (boucles, branches conditionnelles) sans connaître le graphe à l'avance :

1. Phase d'enregistrement (Record) : La tâche composite est invoquée avec la requête, mais les sous-tâches retournent des résultats factices (placeholders). Le système enregistre l'ordre des appels et les dépendances de données. Ce processus est instantané car aucun calcul réel n'est effectué.
2. Phase de rejeu (Replay) : Le graphe sous-jacent reconstruit est envoyé au Task Dispatcher, qui distribue les appels aux exécuteurs appropriés. Les tâches sont invoquées à nouveau, cette fois-ci avec les vrais résultats, produisant la réponse finale.

C. Transfert de Données et Partage de Ressources

• Sidecar : Un processus par GPU qui gère le transfert des tenseurs intermédiaires (embeddings, états cachés) entre les composants.
  • Intra-nœud : Utilisation de la mémoire partagée Linux (/dev/shm) pour éviter de saturer le NVLink/NVSwitch.
  • Inter-nœuds : Utilisation de RDMA via la bibliothèque UCX.
• Partage de composants : Si plusieurs applications utilisent le même composant (ex: un encodeur de vision commun), Cornserve partage automatiquement le déploiement de l'exécuteur pour économiser les GPU.

3. Résultats Expérimentaux

Les évaluations ont été menées sur des nœuds équipés de GPU NVIDIA A100-80GB, en comparant Cornserve à un déploiement monolithique (tout le modèle sur un seul exécuteur). Les modèles testés incluent Qwen 2.5 Omni et Qwen 3 Omni.

• Débit (Throughput) :

  • Cornserve améliore le débit de Qwen 2.5 Omni jusqu'à 3,81 fois par rapport au déploiement monolithique (sur 16 GPU).
  • Pour Qwen 3 Omni, le déploiement monolithique échoue par manque de mémoire GPU (OOM), tandis que Cornserve réussit grâce à la fission du modèle.
  • L'augmentation de 8 à 16 GPU a permis une amélioration de débit de 2,68 fois (supérieure au scaling linéaire de 2x) grâce à un meilleur équilibrage de charge entre les composants hétérogènes.

• Latence :

  • Réduction significative de la latence pour Qwen 2.5 Omni sur 16 GPU :
    • P50 : amélioration de 3,24x.
    • P95 : amélioration de 5,3x.
    • P99 (latence de queue) : amélioration de 5,79x.
  • Ces gains proviennent de la suppression des interférences entre composants (plus d'attente bloquante) et de l'activation du "continuous batching" pour les générateurs audio.

• Surcharge (Overhead) :

  • Le transfert via le Sidecar (RDMA ou mémoire partagée) ajoute une latence négligeable (5-27 ms pour des tenseurs de 8 à 32 Mo), ne constituant pas le goulot d'étranglement principal.

4. Contributions Clés

1. Premier système distribué générique : Cornserve est le premier système capable de servir n'importe quel modèle Any-to-Any, indépendamment de la complexité de son graphe de calcul.
2. Abstraction flexible : Une interface Python simple permettant aux développeurs de définir des graphes de calcul arbitraires et des fissions de modèles sans modifier le cœur du système.
3. Mécanisme Record-and-Replay : Une approche innovante pour gérer l'exécution de graphes dynamiques et conditionnels dans un environnement distribué.
4. Optimisation des ressources : Capacité à partager les composants communs et à mettre à l'échelle indépendamment les parties hétérogènes du modèle.

5. Signification et Impact

Cornserve comble un vide critique dans l'infrastructure d'IA générative. Alors que les modèles multimodaux deviennent de plus en plus complexes et hétérogènes, les solutions de serving actuelles sont trop rigides.

• Pour les développeurs : Cornserve offre un moyen simple de déployer des modèles complexes sans se soucier de l'orchestration manuelle des GPU.
• Pour l'industrie : Il permet une utilisation beaucoup plus efficace du matériel coûteux (GPU) en évitant le gaspillage dû à l'inadéquation entre les besoins des composants et la capacité des serveurs.
• Pour la recherche : En fournissant une plateforme robuste, Cornserve ouvre la voie au développement de modèles multimodaux encore plus puissants et efficaces, qui seraient autrement impossibles à servir à grande échelle.

Le système est open-source et disponible sur GitHub, avec une démo vidéo sur YouTube, facilitant son adoption par la communauté.