Red Hat a lancé Red Hat AI 3.5, une mise à jour de sa plateforme d’intelligence artificielle conçue pour accompagner les projets depuis leur phase pilote jusqu’aux environnements de production, avec des contrôles renforcés typiques d’une infrastructure à l’échelle de l’entreprise. Cette version intègre une évaluation préalable des modèles et des agents, de nouvelles métriques d’observabilité, des capacités de multiténence sur GPU partagés, ainsi que des outils pour déployer des applications RAG et des agents avec une meilleure maîtrise opérationnelle.
Les points clés de Red Hat AI 3.5 en 20 secondes
- EvalHub introduit l’évaluation de sécurité et la génération de rapports vérifiables.
- Red Hat intègre des métriques d’inférence, de consommation de tokens et d’utilisation des GPU.
- La plateforme renforce la multitenance avec isolation via OpenShift Virtualization.
- AutoRAG et les modèles d’agents préconfigurés visent à accélérer les projets d’entreprise avec des données privées.
- Red Hat AI 3.5 est désormais disponible en version générale.
Cette mise à jour reflète une évolution évidente du marché de l’IA d’entreprise. De nombreuses organisations ont dépassé la phase d’expérimentation avec des modèles et doivent désormais gérer des problématiques moins spectaculaires mais plus complexes : qui utilise chaque GPU, combien coûte chaque charge, comment mettre à jour un modèle sans interrompre le service, quel niveau d’isolation existe entre les équipes, et comment prouver qu’un système a passé certains tests avant sa mise en production.
Red Hat souhaite précisément couvrir cette couche opérationnelle au-dessus d’OpenShift et de sa plateforme d’IA.
EvalHub et Garak pour l’évaluation de sécurité en amont du déploiement
L’une des nouveautés majeures est EvalHub, désormais disponible en version générale avec Red Hat AI 3.5.
Cet outil est conçu pour évaluer les modèles, systèmes RAG et agents avant leur déploiement. Selon Red Hat, il permet d’automatiser les tests de sécurité et de générer des rapports destinés aux processus internes de conformité et d’audit.
L’entreprise intègre également les scores de Garak, un outil d’évaluation des vulnérabilités et du comportement des modèles de langage, dans son catalogue de modèles validés.
Red Hat indique avoir ajouté plus de 20 nouveaux modèles, avec des tests de performance et des métriques liées à la sécurité, à l’exposition d’informations personnelles ou au risque de toxicité.
Parmi les fournisseurs représentés figurent Google, NVIDIA et Alibaba Cloud, avec des modèles tels que Gemma 4, Nemotron 3 et Qwen.
Il est important de préciser ce que cette validation signifie concrètement. Une bonne note lors d’un ensemble de tests ne garantit pas automatiquement qu’un modèle soit sécurisé pour toute application ni qu’il respecte une réglementation précise.
L’intérêt réside dans la disponibilité de preuves reproductibles et comparables qui peuvent s’intégrer dans le processus d’approbation interne d’une organisation.
Red Hat distingue également certains modèles comme étant validés pour tool calling, une capacité particulièrement pertinente pour les agents pouvant exécuter des actions sur des systèmes externes.
| Domaines | Nouvelles fonctionnalités dans Red Hat AI 3.5 |
|---|---|
| Évaluation | EvalHub en disponibilité générale |
| Sécurité des modèles | P scores Garak et tests de risque |
| Agents | Modèles validés pour le tool calling |
| Conformité | Rapports d’évaluation vérifiables |
| Mise à jour | Déploiement contrôlé des nouvelles versions |
La gestion partagée des GPU devient un enjeu plateforme
Red Hat AI 3.5 porte une attention particulière à la gestion des GPU dans des environnements partagés.
Lorsque des projets expérimentaux utilisent quelques GPU dédiés, la répartition des ressources reste simple. La difficulté survient lorsque de nombreux équipes partagent des accélérateurs et que certaines charges requièrent une faible latence, tandis que d’autres peuvent s’exécuter en arrière-plan.
La nouvelle version introduit fair-share GPU scheduling, conçu pour répartir équitablement les ressources entre différents locataires, avec des mécanismes de priorité pour le service d’inférence.
Le système peut appliquer des contrôles d’admission et router les requêtes selon leur priorité, afin d’éviter qu’une charge secondaire monopolise toute la capacité et empêche une application critique de répondre en temps réel.
De plus, Red Hat offre un support officiel pour exécuter sa plateforme d’IA sur des hosted control planes OpenShift déployés via OpenShift Virtualization.
Ce modèle permet à chaque locataire d’avoir sa propre couche de contrôle tandis que le hardware physique sous-jacent est consolidé.
Les charges d’IA peuvent ainsi fonctionner dans des machines virtuelles sur des serveurs avec GPU partagés, offrant un niveau supplémentaire d’isolation entre clients ou unités d’activité.
Ce n’est pas une isolation physique complète, mais cela peut s’avérer utile pour les fournisseurs de services internes, clouds privés ou plateformes enterprise où plusieurs équipes interagissent avec la même infrastructure.
Plus de métriques pour suivre la consommation de tokens et de GPU
L’observabilité est un axe renforcé.
Red Hat AI 3.5 intègre des tableaux de bord permettant de surveiller la santé de l’inférence, la performance des modèles et l’utilisation des GPU.
De plus, il est possible de mesurer la consommation de tokens par utilisateur.
Ces données sont particulièrement utiles pour les départements plateforme et FinOps. Lorsqu’une IA passe de tests limités à des usages pour des centaines ou milliers d’utilisateurs, il devient nécessaire de connaître la consommation par équipe pour répartir les coûts, repérer des charges anormales ou justifier des extensions de capacité.
Red Hat parle de showback, plutôt que de chargeback.
Le premier consiste à informer chaque unité de sa consommation, sans facturation interne, tandis que le second implique de répercuter directement ces coûts sur le département concerné.
La plateforme intègre également un tracé visuel des agents via MLflow, permettant de suivre l’exécution de workflows avec plusieurs étapes, outils et appels aux modèles.
L’observabilité des agents est plus complexe que celle d’une API classique, car une seule requête utilisateur peut entraîner plusieurs appels, recherches, exécutions d’outils et décisions intermédiaires.
AutoRAG pour simplifier l’intégration des modèles aux données d’entreprise
Red Hat étend également ses outils pour les applications RAG, dont le sigle signifie Retrieval-Augmented Generation.
AutoRAG vise à automatiser une partie du processus de connexion entre les référentiels internes et des applications IA.
La version 3.5 supporte désormais les documents multilingues, les tests conversationnels, la récupération contextuelle, ainsi que la compatibilité avec pgvector.
Une interface visuelle est proposée pour concevoir et évaluer le flux avant sa mise en production.
Le but est de réduire le travail manuel nécessaire pour déterminer comment fragmenter les documents, générer les embeddings, choisir la méthode de récupération et évaluer la qualité des réponses.
Red Hat inclut aussi AutoML et une fonction appelée Inference-Time Scaling, qui ajuste dynamiquement la puissance de calcul selon la complexité de la requête.
L’objectif est d’éviter d’allouer les mêmes ressources à une requête simple ou complexe, en adaptant la charge d’inférence à la difficulté perçue.
Il ne s’agit pas nécessairement de connaître à l’avance le coût précis de chaque question, mais d’une gestion qui tente d’optimiser la consommation en fonction de la complexité détectée.
Les agents arrivent avec des modèles et des contrôles d’accès préréglés
Red Hat AI 3.5 propose des modèles préconfigurés pour des agents dédiés à des tâches courantes telles que la revue de code, le traitement documentaire ou la recherche.
Ces modèles font partie de AI Hub et proposent une base avec frameworks, outils et configurations de déploiement.
L’entreprise souhaite que ces agents soient dès leur conception intégrés aux contrôles de sécurité et d’exploitation de la plateforme, plutôt que d’y ajouter ces contrôles après coup.
Une prise en charge générale est également ajoutée pour Responses API et RAG intégré, avec une interface ouverte pour des conversations multi-turnes avec agents.
Red Hat intègre aussi une compatibilité avec NVIDIA NeMo Guardrails pour filtrer ou bloquer certains appels malveillants ou indésirables aux outils.
Ce qui est crucial lorsque l’agent peut modifier des fichiers, interroger des bases de données ou exécuter des actions sur des systèmes d’entreprise.
Un chatbot mal calibré peut générer des informations incorrectes. Un agent ayant accès à des outils peut réaliser une action erronée, avec des conséquences potentielles.
Le périmètre de risque s’étend donc.
Plus d’options pour décharger la mémoire de la GPU
La gestion de la mémoire est aussi améliorée.
Red Hat annonce la disponibilité générale du CPU offloading, qui permet de déplacer partiellement l’information de la mémoire GPU vers la mémoire principale du système.
L’option de storage offloading est aussi en developer preview, permettant de décharger certains flux de données vers le stockage secondaire.
Ce type de technique facilite le traitement de conversations longues ou de modèles volumineux, sans augmenter directement la mémoire HBM.
Le coût de cette approche réside dans les transferts de données.
Déplacer des données entre GPU, RAM et stockage est plus lent que de les conserver continuellement dans la mémoire rapide de la GPU. Le choix dépend donc des charges de travail spécifiques.
Cela s’inscrit dans une tendance plus large d’approche hiérarchisée de la mémoire dans l’inférence : considérer la mémoire comme une hiérarchie à plusieurs niveaux plutôt que de tout faire dépendre de la HBM.
llm-d étend l’inférence distribuée hors d’OpenShift
Une autre avancée est l’expansion de llm-d, la technologie de Red Hat pour l’inférence distribuée.
Red Hat AI 3.5 étend sa compatibilité aux services Kubernetes de tiers.
La société annonce une disponibilité générale pour CoreWeave Kubernetes Service et Microsoft Azure, tandis que Amazon EKS doit arriver en technology preview.
Cela permet d’offrir une couche standardisée de gestion des modèles même si l’infrastructure Kubernetes n’est pas forcément basée sur OpenShift.
Une prise en charge initiale de vLLM Omni est aussi introduite, visant à servir du texte, de l’audio et de l’image à partir d’une couche commune.
Cette fonctionnalité reste en early access et ne doit pas encore être considérée comme prête pour la production.
Red Hat souhaite que l’IA soit gérée comme une infrastructure critique
Les orientations de Red Hat AI 3.5 sont très claires.
L’entreprise consacre moins d’attention à la compétition pour le modèle le plus performant, et davantage à la gestion de la couche entourant le modèle lorsque l’organisation souhaite une utilisation continue.
Évaluations, isolation, gestion des GPU, suivis de tokens, déploiements progressifs, RAG, agents et traçabilité font partie intégrante de cette démarche.
Toutes les fonctionnalités annoncées n’ont pas encore atteint le même degré de maturité. Certaines sont en version générale, d’autres restent en developer preview, technology preview ou early access.
Cette distinction sera cruciale pour toute entreprise envisageant d’adopter Red Hat AI 3.5 en production.
La version est dès maintenant disponible en version générale et fait partie de Red Hat AI Factory with NVIDIA.
Plus qu’une simple mise à jour axée sur de nouveaux modèles, Red Hat AI 3.5 cherche à faire de l’intelligence artificielle une infrastructure que les équipes techniques peuvent gérer avec des contrôles similaires à ceux déployés pour les applications, les clusters et les services critiques.