Red Hat, filiale d’IBM, croit qu’elle a un rôle à jouer dans le déploiement de systèmes hybrides d’IA. Outre la commercialisation de vLLM, l’éditeur mise sur le projet d’inférence IA distribuée, llm-d.
« Les clients se trouvent à différentes étapes de leur parcours d’adoption de l’IA générative », déclare Tushar Katarki, directeur produit, plateformes de modèles de fondation chez Red Hat.
« Ils développent principalement des chatbots et agents IA en utilisant des modèles frontières comme ceux d’OpenAI, de Google ou d’Anthropic. Cette adoption croissante implique des défis de coût, des complexités d’intégration et des problèmes de flexibilité », ajoute-t-il.
De plus, pour révéler leur plein potentiel, il faut que ces modèles d’IA puissent accéder aux données internes des entreprises. Or, pour des raisons qui leur sont propres ou en respect de réglementations, certaines entreprises ne souhaitent pas les exposer aux API des fournisseurs LLM.
Bien évidemment, sur site, les entreprises n’ont pas les capacités de calcul des fournisseurs cloud. Mais ont-elles vraiment besoin de GPT-4.1 ou de Claude Sonnet 4 ? « En entreprise, les très grands modèles de langage sont souvent surdimensionnés pour les cas d’usage. Nous pensons que les organisations ont besoin de plus petits LLM avec quelques alignements et du contexte », assume le directeur produit. « La taille idéale d’un modèle se trouve autour des 7 à 8 milliards de paramètres ».
« En entreprise, les très grands modèles de langage sont souvent surdimensionnés pour les cas d’usage. Nous pensons que les organisations ont besoin de plus petits LLM avec quelques alignements et du contexte ».
Tushar KatarkiDirecteur produit, plateformes de modèles de fondation, Red Hat
Peu importe la nature du déploiement ou la confiance portée dans le fournisseur d’infrastructure. Personnaliser les réponses d’un grand modèle de langage demeure un exercice difficile. « L’architecture RAG est populaire. Quelques entreprises se lancent dans le fine-tuning. Mais les deux techniques exigent des compétences en data science », estime Tushar Katarki.
Les poupées russes Red Hat AI
En ce sens, Red Hat multiplie les offres consacrées à l’IA. Celles-ci sont chapeautées par la marque ombrelle Red Hat AI. L’éditeur avait d’abord abordé OpenShift AI, légère refonte d’OpenShift. Puis il a évoqué RHEL AI avant de dévoiler Red Hat AI Inference Server.
Ce sont des poupées russes. OpenShift AI intègre des fonctionnalités MLOps et LLMOps – d’entraînement, de déploiement et de suivi de modèles de machine learning et d’IA générative. Elle inclut RHEL AI et Red Hat AI Inference Server. RHEL AI est présentée comme une plateforme par-dessus le système d’exploitation afin de déployer des LLM Granite d’IBM et d’autres modèles « open weight », mais aussi pour les entraîner.
Red Hat AI Inference Server est « en quelque sorte » une distribution commerciale de vLLM, le framework open source d’inférence IA que le fournisseur gère depuis le rachat de Neural Magic.
Selon Jeff DeMoss, Senior Product Manager de Red Hat OpenShift AI, AI Inference Server est le « point de départ » des offres Red Hat AI.
« Red Hat AI Inference Server confère l’accès aux librairies de compresseurs LLM utilisées pour l’optimisation », déclare-t-il. Ils servent à réduire la taille des modèles à l’aide de techniques de quantification (Quantization). Cette approche vise à convertir les poids d’un modèle d’IA dans un type de données de précision inférieure, par exemple de FP16 à FP8. Si le modèle quantifié a tendance à perdre en précision, il est plus léger et plus rapide. Neural Magic aurait réussi à limiter fortement cette perte de qualité.
« Nous avons constaté qu’en utilisant certaines fonctionnalités de compression, nous pouvons conserver 97 à 99 % de la précision du modèle, tout en multipliant par deux à quatre les performances ».
Jeff DeMossSenior Product Manager, Red Hat OpenShift AI
« Nous avons constaté qu’en utilisant certaines fonctionnalités de compression, nous pouvons conserver 97 à 99 % de la précision du modèle, tout en multipliant par deux à quatre les performances », assure Jeff DeMoss.
En outre, Red Hat AI Inference Server inclut un hub de modèles tiers validés. « Red Hat AI Inference Server s’exécute sur RHEL et OpenShift, mais aussi sur des environnements Linux et Kubernetes non Red Hat. Cela nous ouvre donc de nouvelles perspectives techniques et commerciales », poursuit-il.
Red Hat souhaite avant tout que ses clients se tournent vers OpenShift AI, dont les fonctionnalités sont plus complètes. D’autant que l’éditeur vend sa plateforme comme le futur centre de gouvernance des déploiements IA sur site, en cloud privé et en cloud public.
L’enjeu de l’inférence distribuée avec llm-d
C’est le sens de llm-d, une initiative menée par Red Hat en premier lieu avec CoreWeave, Google Cloud, IBM Research et Nvidia. AMD, Cisco, Hugging Face, Intel, Lambda et Mistral AI participent dans une moindre mesure, tandis que les laboratoires Sky Computing de l’université de Berkeley en Californie (l’équipe derrière l’idée de vLLM) et LMCache de l’université de Chicago supportent llm-d.
« Le traitement d’un prompt en entrée et sa compréhension par un LLM s’avèrent gourmands en puissance de calcul et réclament un certain type de GPU. »
Tushar KatarkiDirecteur produit, plateformes de modèles de fondation, Red Hat
Le projet open source vise à favoriser l’inférence distribuée de LLM, tout en la rendant agnostique des puces IA ou des GPU sous-jacents. Pour cela, Red Hat et ses partenaires s’appuient sur Kubernetes et vLLM afin de prendre en compte les particularités des charges de travail d’IA générative. En effet, l’inférence IA se déroule en deux phases distinctes.
« Le traitement d’un prompt en entrée et sa compréhension par un LLM s’avèrent gourmands en puissance de calcul et réclament un certain type de GPU », explique Tushar Katarki. « La phase de génération de la réponse demande beaucoup de mémoire, mais est moins intensive. Cela réclame idéalement un autre type de puce ou de GPU ».
Plus précisément, le traitement du prompt en entrée est parallélisé, tandis que la génération de la réponse est séquentielle, token par token.
« La génération de la réponse demande beaucoup de mémoire, mais est moins intensive. »
Tushar KatarkiDirecteur produit, plateformes de modèles de fondation, Red Hat
Ainsi, llm-d dispose d’un routeur dynamique basé sur l’API Gateway de Kubernetes et un Scheduler (planificateur) spécifique capable de répartir la charge d’IA sur différents clusters en fonction de leur état et de la nature de la requête. Mais ce n’est pas tout.
Séparer le calcul des deux phases de l’inférence
La caractéristique principale de llm-d vise justement à décorréler cette phase de préremplissage (prefill, le traitement du prompt en entrée) du décodage (la génération de la réponse) pur et dur. Cette approche est inspirée des travaux de Google et de DeepSeek. La passerelle API agit donc sur un pool d’inférence où des instances de vLLM sont divisées en deux groupes pour le préremplissage et l’inférence.
Avec la particularité que ces instances distinctes disposent de deux couches KV cache distribuées. Le « Key-Value Cache » est un mécanisme servant à stocker les activations des couches de réseaux de neurones (sous forme de matrices clé-valeur) – les précédentes prédictions de tokens – et à les réutiliser lors des activations suivantes à l’inférence. Autrement dit, c’est le mécanisme qui maintient la mémoire d’un LLM dans une conversation multitour. Techniquement, il s’agit de ne pas recalculer l’ensemble de la discussion à chaque nouveau point d’échange.
Habituellement, la capacité d’une couche de KV cache est liée à la quantité de VRAM disponible dans un serveur GPU. Ici, la première couche, distribuée (est-ouest), sert à transférer le contenu du KV cache entre les instances responsables du préremplissage et du décodage. Ce transfert est effectué en VRAM ou dans un espace de stockage.
Les deux types d’instances communiquent à l’aide de la librairie NIXL (Nvidia Inference Xfer Library), issue du framework d’inférence distribuée Dynamo de Nvidia. Ce dispositif doit abstraire l’accès à différentes catégories de mémoire (VRAM, RAM, CPU) et de stockage (bloc, fichier, objet). Plus tard, une implémentation de la librairie devrait prendre en charge les protocoles d’interconnexion comme RDMA. Il s’agit de ne pas dépendre d’un type de GPU ou de puces IA. Actuellement, vLLM est compatible avec CUDA – la couche logicielle des GPU Nvidia –, les TPU de Google et prend partiellement en charge ROCm d’AMD et XPU d’Intel.
Une deuxième couche (nord-sud) est utilisée pour décharger le KV cache de la VRAM vers la mémoire vive des instances ou leurs SSD (localement). Celle-ci est fonction des capacités de chaque serveur, mais surtout de la librairie LMCache qui exploite le framework NIXL. Selon les porteurs du projet, la combinaison de vLLM et de LMCache permet déjà de réduire fortement le délai de préremplissage au moment de traiter de grand volume de tokens (« Time To First Token »).
« Lorsque vous traitez des interactions multitours, vous pouvez avoir des prompts qui se répètent et qui peuvent donc être stockés afin qu’elles ne soient pas traitées à nouveau », comprend Jeff DeMoss. « Le décodeur peut directement chercher les éléments similaires au prompt en entrée dans une zone du KV Cache. L’idée est que le contenu moins fréquemment utilisé peut être déchargé de la mémoire GPU vers des options de stockage moins coûteuses ».
Du fait qu’il est capable d’exploiter plusieurs algorithmes de calcul de score simultanément, le routeur « peut optimiser les décisions de routage » en fonction du niveau de « désagrégation » du préremplissage et du décodage, des données en cache et l’état du KV cache lui-même. LMCache s’appuie sur une base de données Redis pour stocker les métadonnées liées aux matrices clés-valeurs. Le SGBD in-memory et NOSQL sert également à l’indexation de ce contenu, afin que le planificateur accède à ces informations lors de sa prise de décision. Le tout est supervisé à l’aide de Prometheus.
Quand une requête est envoyée, le scheduler prend sa décision de routage transmise par la gateway API au side-car Envoy d’un pod de décodage. C’est lui qui se charge d’interroger le pod de remplissage désigné par le planificateur (par exemple, pour traiter les requêtes similaires de deux utilisateurs différents), afin d’enclencher le préremplissage ou récupérer la matrice clé-valeur existante en KV Cache. VLLM pousse les données de préremplissage à l’aide de NIXL et de LMCache vers le pod de décodage. Le décodeur fait son œuvre et renvoie la réponse à l’usager.
Malgré la complexité apparente de la solution, llm-d se déploie comme n’importe quel projet associé à Kubernetes, à l’aide d’un Helm Charts, et requiert des dépendances semblables. Si Red Hat prévoit de le distribuer commercialement à travers OpenShift, llm-d est compatible avec un ensemble de distribution K8s, dont Minikube.
Permettre aux entreprises d’internaliser l’approche « Model as a Service »
Selon les responsables de Red Hat, llm-d est un projet voué à propulser l’approche « Model as a Service » au sein des DSI, que ce soit sur site ou dans le cloud. « Les ingénieurs de plateforme pourront fournir aux métiers des modèles spécifiques, en respectant des SLA, des latences faibles à la première réponse et lors des échanges suivants », promet Tushar Katarki. « Ils pourront adapter leur déploiement de LLM par application en fonction du nombre d’utilisateurs et des infrastructures disponibles ».
Les contributeurs de llm-d évoquent, eux, l’optimisation des requêtes RAG, de raisonnement et toute autre demande qui impliquent un déséquilibre entre la quantité de token en entrée et en sortie.
Il y a encore du travail. Il manque un mécanisme d’autoscaling « sensible au trafic, aux différents matériels, aux formes de requêtes [leur longueur et leur type, N.D.L.R.], et à la qualité de service » afin de doter le projet de capacités de haute disponibilité. Nvidia propose de s’appuyer sur le planificateur inclus dans le framework Dynamo et son gestionnaire de KV Cache, Dynamo KV.
Il faudra également s’assurer de la transmission des matrices clés-valeurs entre des instances de décodage et de préremplissage propulsées par différents équipements. Pour l’instant, AMD et Nvidia semblent avoir essayé llm-d sur leurs propres machines.
Pour ce faire, les contributeurs entendent favoriser la mise en place d’un espace de stockage partagé auquel les GPU pourraient accéder directement. Cette technologie sera-t-elle agnostique des fournisseurs de puces ?
Certains clients de Red Hat se sont montrés volontaires pour tester le projet dans une préversion technique prévue au sein d’OpenShift avant la fin de l’année.
Pour approfondir sur IA appliquée, GenAI, IA infusée
