Red Hat Summit : Red Hat AI 3.4 va désormais au-delà du serveur d’inférence

La marque de fabrique : savoir distribuer les requêtes sur une batterie de GPU

La console de la boîte à outils Red Hat AI ressemble en première approche à ces produits d’inférence désormais disponibles en Open source pour le grand public, comme LM Studio. On sélectionne depuis une interface graphique un LLM parmi un catalogue pour qu’il devienne interrogeable depuis le chatbot situé ailleurs dans la même interface graphique. Plus précisément, le chatbot est plutôt ici OpenCode, un clone Open source de Claude Code.

Comme ailleurs, on retrouve dans le catalogue des dizaines de modèles déclinés en dizaines de variantes selon l’encodage pour tel GPU, tel processeur, ou le taux de quantisation pour faire tenir le bon nombre de paramètres avec la bonne précision dans une certaine quantité mémoire. Red Hat assure qu’il aurait lui-même réencodé ces LLM et que Red Hat AI ne liste à l’écran que les versions compatibles avec les puces présentes dans le serveur hôte. Ou dans le cluster de serveurs que gère Red Hat AI.  

Car, chose unique à Red Hat à ce stade, un switch LLM-d dans l’interface permet de distribuer les requêtes sur plusieurs GPU, s’ils existent dans la machine hôte et dans celles avec lesquelles elle est connectée en réseau. Il s’agit plus exactement de répartir les requêtes entrantes de plusieurs clients qui utilisent simultanément le même LLM vers les différentes ressources GPU disponibles dans un cluster.

En pratique, LLM-d utilise Kubernetes pour démultiplier et distribuer le container qui exécute le LLM.

Clés API et IA prédictive pour se différencier des autres appliances d’inférence

Vient ensuite la première nouveauté de cette version 3.4 : avant de pouvoir utiliser le LLM, l’utilisateur va devoir se créer une clé API unique pour lui et ce LLM. Comme en cloud public payant, sauf que l’on est ici sur des machines privées. Le bouton pour le faire s’appelle MaaS, pour Model-as-a-Service.

Selon Erwan Granger, le directeur de l’unité chez Red Hat qui accompagne les clients dans l’adoption de l’IA (à droite sur la photo en haut de cet article), cette nouvelle fonction MaaS est censée permettre à une entreprise de suivre la consommation de chacun de ses salariés sur l’IA. « L’administrateur de la solution voit la consommation de tout le monde et peut imposer des quotas pour ne pas qu’une personne accapare toute la puissance de calcul », se contente-t-il de dire.

À l’étape suivante, on comprend mieux pourquoi Red Hat se refuse à dire que sa solution est une appliance clés en main pour les utilisateurs finaux. Red Hat AI ne se contente pas d’offrir les outils classiques de l’IA générative (RAG...). Il propose aussi ceux de l’IA prédictive. À savoir un moteur de Machine learning à qui on fait avaler pendant toute une nuit des documents de test pour qu’il comprenne comment évolue normalement un processus et qu’il soit ensuite capable de prédire comment les processus suivants évolueront.

D’ordinaire, l’entraînement des modèles prédictifs est une tâche dévolue aux datascientists. Ils sont les spécialistes pour essayer à tâtons des paramètres qui amélioreront l’entraînement et les prédictions. La seconde nouveauté de Red Hat AI 3.4 est qu’il intègre une fonction AutoML qui se charge toute seule de tester des plages de paramètres (fournies via un fichier CSV) sur une collection de modèles. Au bout de la nuit que le datascientist aura passée à plutôt dormir, le système lui dit quel modèle avec quels paramètres prédit mieux le déroulement des processus soumis.

Automatiser les tâches qui doivent solliciter l’attention des équipes techniques

Il existe exactement la même chose pour le RAG, avec une fonction baptisée désormais AutoRAG. « Le processus typique pour le RAG consiste à mettre tous vos documents dans une base de données vectorielle. Mais entre alors en jeu tout un tas de paramétrages, comme la taille des chunks, le modèle d’embeddings, si l’on préfère que la réponse s’en tienne aux documents fournis (Faithfulness) ou qu’elle s’attache plutôt à être sémantiquement juste par rapport à la question (Correctness) », explique Erwan Granger.

Et de montrer que l’interface se lance dans une batterie de tests, pour à la fin livrer des scores à plusieurs configurations. On choisit celle qui a le meilleur score et l’interface paramètre toute seule son processus, ou plus exactement le pipeline qui mènera le LLM à donner les réponses les plus satisfaisantes.

La troisième nouveauté de Red Hat AI 3.4 concerne les agents, ou plutôt la passerelle par laquelle doit passer un agent, ici OpenCode, et qui à présent monitore toutes ses requêtes. « Le point intéressant est que cette passerelle est indépendante du framework utilisé – MCP, A2A ou autre. Elle trace toutes les requêtes d’un agent et pour chaque action crée une boucle qui va vérifier si l’agent peut la faire. Sachant que l’utilisateur indique juste un but à atteindre à son agent, mais qu’il ne maîtrise pas comment il y parvient. Cette passerelle apporte cette maîtrise », dit Erwan Granger, en conclusion de sa démonstration.