Red Hat AI 3.5 soll KI-Piloten in steuerbare Produktionsdienste verwandeln

Red Hat AI 3.5 ist weniger ein Update mit einem einzelnen neuen Modell als ein Ausbau für den Betrieb von KI im Unternehmen. Im Mittelpunkt stehen wiederholbare Prüfungen vor dem Roll-out, die Verteilung teurer GPU-Kapazitäten und die Überwachung laufender Inferenzdienste. Red Hat stellte die Version am 9. September 2026 vor; ein Rückblick vom 11. September unterstrich die Schwerpunkte Sicherheit, operative Kontrolle und Transparenz bei der Leistung. 4315

EvalHub: Prüfung vor dem Produktivstart

Die wichtigste Neuerung ist die allgemeine Verfügbarkeit von EvalHub. Das Werkzeug bewertet kundeneigene oder angepasste Modelle, Retrieval-Augmented-Generation-Konfigurationen (RAG) und KI-Agenten. Teams können sicherheitsorientierte Benchmarks durchführen, etwa gegen Prompt Injection und Jailbreaks, und aus den Ergebnissen Compliance-orientierte Zertifizierungen erstellen. 13

Der praktische Nutzen: Ein Modell, das in einem Proof of Concept überzeugend wirkt, ist damit nicht automatisch für geschäftskritische Abläufe geeignet. EvalHub soll eine standardisierte, dokumentierbare Teststufe vor der Bereitstellung schaffen, statt dass jede Anwendungsmannschaft eigene Prüfverfahren entwickeln muss.

Zusätzlich wuchs Red Hats Katalog validierter Modelle um mehr als 20 Einträge, darunter Modelle von Google, NVIDIA und Alibaba Cloud. Für Katalogmodelle stehen unter anderem Ergebnisse des Garak-Benchmarks sowie Hinweise auf Toxizität und eine mögliche Preisgabe personenbezogener Daten zur Verfügung. Das liefert zusätzliche Anhaltspunkte bei der Modellauswahl. 34

Gemeinsame GPUs als steuerbare Ressource

Während Pilotprojekte häufig auf exklusiver Infrastruktur für wenige Nutzer laufen, müssen produktive Dienste konkurrierende Workloads, Prioritäten und Kostenstellen abbilden. Red Hat AI 3.5 ergänzt dafür Fair-Share-Scheduling, prioritätsbewusstes Serving, Admission Control und prioritätsbasiertes Routing von Anfragen in gemeinsam genutzten GPU-Umgebungen. 48

Hinzu kommen Token-Messungen pro Nutzer sowie Dashboards für den Zustand der Inferenz, die GPU-Auslastung und die Modellleistung. Plattformteams sollen dadurch erkennen können, wer Kapazität verbraucht, wo beim Serving Probleme entstehen und wie sich Kosten einzelnen Teams zuordnen lassen. 414

Für NVIDIA-beschleunigte Umgebungen entsteht damit vor allem eine Kubernetes-orientierte Betriebsebene rund um das Model Serving: Workloads prüfen, Zugriff auf gemeinsame GPUs steuern und den laufenden Dienst überwachen. Red Hat AI Inference 3.5 stellt zudem allgemein verfügbare, optimierte Inferenz-Images für NVIDIA CUDA bereit – neben Unterstützung für AMD ROCm, Google TPU, Intel Gaudi und IBM Spyre. 35

RAG und Agenten: nützlich, aber nicht alles ist bereits GA

Auch die Werkzeuge für Retrieval- und agentenbasierte Anwendungen werden erweitert. AutoRAG erhält mehrsprachige Funktionen für nicht englischsprachige und gemischtsprachige Dokumentbestände, darunter Spracherkennung, sprachsensitives Chunking und mehrsprachige Embeddings im Optimierungsprozess. 1

Red Hat beschreibt AutoRAG als Werkzeug zum Bewerten und Optimieren von RAG-Pipelines – mit kontextbezogenem Retrieval, Konversationstests und visuellem Debugging. Entscheidend für Planungen im Unternehmen: AutoRAG ist weiterhin nur als Technology Preview verfügbar, nicht als allgemein verfügbares Produktmerkmal. 13

Ergänzend liefert AI Hub Vorlagen als Ausgangspunkt für Workflows wie Code-Reviews, Dokumentenverarbeitung und Recherche. 43

Verteilte Inferenz auch außerhalb von OpenShift

Red Hat erweitert die Optionen für verteilte Inferenz mit llm-d auf verwalteten Kubernetes-Diensten. Als Zielplattformen nennt die Dokumentation Azure Kubernetes Service (AKS), CoreWeave Kubernetes Service (CKS) und Amazon Elastic Kubernetes Service (EKS). Voraussetzung sind unter anderem Kubernetes 1.33 oder neuer sowie bereitgestellte GPU-Knoten. 37

Der Support-Status ist allerdings nicht auf allen Plattformen gleich: Verteilte Inferenz mit llm-d auf Amazon EKS ist laut Red Hat nur eine Technology Preview, ohne Produktions-SLA und nicht für den Produktiveinsatz empfohlen. Für Azure und CoreWeave beschreibt die Dokumentation dagegen die unterstützten Bereitstellungspfade. 3940

Was sich für Plattformteams konkret ändert

Red Hat bündelt mit Version 3.5 vier Aufgaben, die in KI-Piloten häufig getrennt behandelt werden:

1. Vertrauen vor dem Start: Eigene Modelle, RAG-Pipelines und Agenten auf Sicherheitsrisiken prüfen und nachvollziehbare Ergebnisse erzeugen. 13
2. Steuerung im Betrieb: Gemeinsame GPU-Ressourcen nach Fairness- und Prioritätsregeln zuweisen und Token-Verbrauch messen. 4
3. Transparenz im Tagesgeschäft: Inferenzzustand, Auslastung und Modellleistung über Dashboards überwachen. 14
4. Portabilität der Infrastruktur: Optimierte Inferenz auf mehreren Beschleunigerplattformen ausführen und verteilte Inferenz auf unterstützten Kubernetes-Umgebungen bereitstellen. 3540

Red Hat positioniert diese Funktionen als Grundlage dafür, KI über Hybrid-Cloud-Umgebungen hinweg wie eine gemeinsame Unternehmensressource zu betreiben – statt als Sammlung voneinander getrennter Experimente. 43

Lightwell ist ein separates IBM-Red-Hat-Thema

Im weiteren IBM- und Red-Hat-Umfeld steht auch Lightwell: eine gemeinsame Initiative zur Behandlung verwundbarer Open-Source-Abhängigkeiten von Drittanbietern. Im September kündigte LTM eine Zusammenarbeit mit IBM und Red Hat zu Lightwell für KI-gestützte Schwachstellenbehebung an. Das gehört nicht zu den Funktionen von Red Hat AI 3.5, zeigt aber den übergreifenden Fokus der Unternehmen auf Validierung und die Verringerung operativer Risiken. 2425

Fazit

Red Hat AI 3.5 zielt vor allem auf den Betrieb: KI-Systeme vor der Bereitstellung testen, gemeinsam genutzte Beschleuniger-Infrastruktur steuern und Model Serving in Hybrid-Cloud-Umgebungen beobachten. Die allgemeine Verfügbarkeit von EvalHub ist dabei das Kernstück. GPU-Priorisierung, Token-Messung und Observability adressieren jene Aufgaben nach dem Go-live, die in Pilotprojekten oft offenbleiben. Die zentrale Einschränkung: Der Verfügbarkeitsstatus variiert je nach Funktion – AutoRAG und verteilte Inferenz auf EKS sind weiterhin Technology Previews. 1339