TensorCast, une nouvelle infrastructure pour gérer les tenseurs des modèles d’IA

TensorCast est une couche distribuée et programmable de type Tensor-as-a-Service (TaaS). Son objectif : gérer le cycle de vie des tenseurs — leur identité, leur emplacement, leurs déplacements, leurs transformations, leur partage et leur matérialisation — indépendamment du moteur de calcul qui les produit ou les consomme. 1

L’enjeu est essentiellement architectural. Dans les infrastructures de grands modèles de langage, les poids du modèle, le KV Cache — la mémoire conservée pour accélérer les échanges au fil d’une conversation — et les états intermédiaires sont souvent pris en charge par des composants distincts. TensorCast cherche à leur fournir un même point de contrôle, afin de faciliter les optimisations qui traversent à la fois le moteur d’inférence, le réseau et le stockage. 1

Pourquoi TensorCast a été conçu

Les systèmes d’IA modernes ne manipulent plus seulement des fichiers de poids statiques. Ils doivent aussi gérer des tenseurs distribués et très dynamiques : blocs de KV Cache, activations, paramètres mis à jour ou autres états intermédiaires. Jusqu’à présent, ces opérations étaient généralement intégrées séparément aux moteurs d’inférence, aux ordonnanceurs, aux couches réseau et aux systèmes de stockage. 1

Cette organisation en silos complique la combinaison de plusieurs politiques. Une modification destinée à améliorer la réutilisation des poids ou la migration d’un cache peut nécessiter des changements coordonnés dans plusieurs briques logicielles. TensorCast considère donc la gestion du cycle de vie des tenseurs comme une couche d’infrastructure manquante : l’application décrit ce qui doit arriver à un état, tandis que le runtime choisit comment le placer, le déplacer, le transformer ou le matérialiser sur le cluster. 1

L’approche se distingue d’un stockage d’objets classique, qui traite généralement les données comme des blocs opaques, et des frameworks centrés sur le calcul, qui planifient surtout des tâches plutôt que le cycle de vie des états tensoriels. 1

Les principes techniques de TensorCast

• Des tenseurs comme objets de première classe. Chaque tenseur possède une identité, un propriétaire, un emplacement et des règles de cycle de vie explicites. Un moteur peut ainsi désigner un poids, un bloc de KV Cache ou un état intermédiaire sans devoir connaître le nœud, le GPU ou le support de stockage où il se trouve. 1
• Des primitives combinables. Les développeurs peuvent assembler des opérations de déplacement, de transformation, de prélecture, de réplication ou de matérialisation pour créer une politique adaptée à un workload donné, sans réécrire l’infrastructure bas niveau à chaque optimisation. 1
• Une séparation entre politique et mécanisme. La politique s’exprime au moyen des API TensorCast ; le runtime prend ensuite en charge l’exécution distribuée et les transferts, sans imposer de modifier le moteur d’exécution sous-jacent. 1
• Une séparation entre plan de contrôle et plan de données. Le Global Store (GS) conserve les métadonnées du cluster — état des nœuds et des Workers, emplacement des tenseurs, propriété et informations d’ordonnancement. Les Workers, eux, réalisent les transferts de données. Le GS coordonne donc les opérations sans devenir un goulot d’étranglement pour les charges utiles. 1
• Deux stratégies pour les métadonnées. Les objets peu nombreux et relativement stables, comme les poids d’un modèle, peuvent être suivis de manière centralisée par le GS. Les états nombreux et dynamiques, comme le KV Cache, sont répartis entre plusieurs Workers ; un Worker de référence pour chaque fragment assure la propriété et la cohérence grâce à des baux et des jetons de clôture (« fencing tokens »). 1
• Une matérialisation limitant les copies. Les répliques locales peuvent exposer la mémoire GPU via CUDA IPC ou la mémoire CPU au moyen de descripteurs memfd locaux. Pour les sources distantes, TensorCast prend en charge les écritures directes par RDMA, ce qui permet d’éviter des copies inutiles lorsque le matériel et le chemin de partage le permettent. 6

Le cas du déplacement du KV Cache

Dans une architecture classique de service d’inférence, déplacer une session de conversation multi-tour avec son KV Cache peut nécessiter de modifier simultanément le routeur de requêtes, l’implémentation du cache dans le moteur d’inférence et le backend réseau ou de stockage.

Avec TensorCast, une politique peut simplement identifier les objets tensoriels associés à la session, demander leur placement ou leur matérialisation sur le Worker de destination, puis orienter les requêtes suivantes vers celui-ci. Le runtime s’occupe de la recherche des données, du transfert et de leur rattachement à la mémoire cible. 1

La migration n’est évidemment pas gratuite : les données doivent toujours être transférées. L’intérêt est plutôt de définir cette logique une seule fois au niveau de la gestion du cycle de vie, au lieu de la dupliquer dans plusieurs composants étroitement couplés. Cette abstraction peut aussi faciliter des stratégies combinées : routage selon la localité du cache, réutilisation des poids ou regroupement d’états associés. 1

Des résultats prometteurs, mais encore à confirmer

Les auteurs ont intégré TensorCast à vLLM et SGLang, deux moteurs largement utilisés pour servir des grands modèles, puis évalué la matérialisation et la synchronisation des poids, la gestion du KV Cache ainsi que le routage programmable des requêtes. 1

Selon leurs résultats, les performances liées au KV Cache sont comparables à celles de Mooncake, un système spécialisé dans ce domaine, tout en conservant la possibilité d’écrire des politiques qui couvrent plusieurs composants de l’infrastructure. 1

Pour lancer une instance de Qwen3-235B-A22B, un modèle totalisant 235 milliards de paramètres dont 22 milliards activés, l’article rapporte un démarrage jusqu’à 228,6 fois plus rapide que celui obtenu avec des systèmes de fichiers distribués courants. 12

Dans des scénarios d’agents à forte concurrence et comportant plusieurs tours de dialogue, une politique programmable TensorCast aurait également réduit jusqu’à 93,2 % le délai médian avant la production du premier token — le TTFT (« time-to-first-token »). 1

Ces chiffres suggèrent un intérêt pour des infrastructures d’IA plus élastiques et capables de conserver leur état : démarrage rapide d’instances, routage tenant compte du cache, migration de sessions et réutilisation des tenseurs pourraient être traités comme des politiques système programmables plutôt que comme des optimisations propres à chaque framework.

Il faut toutefois garder une réserve méthodologique. Ces performances sont celles rapportées par les auteurs dans un préprint de recherche ; elles devront encore être reproduites indépendamment et validées dans des environnements de production à grande échelle. 1