Private Intelligenz

von Günter Baumgart Ralf Frankemölle

Nutanix Enterprise AI ist eine neue KI-Infrastrukturplattform, die es via Inferenz-Services und der Einbeziehung großer Sprachmodelle ermöglicht, KI-Workloads bereitzustellen. Das Produkt ist eine Kubernetes-native Umgebung und erlaubt den lokalen Betrieb von LLMs unabhängig von der Zielplattform – auch unter Einbeziehung von öffentlichen Cloudressourcen. Dieser Workshop zeigt die Inbetriebnahme sowie die Arbeit mit dem Dashboard und der rollenbasierten Zugriffskontrolle.

Über alle Branchen hinweg vertrauen Unternehmen und Organisationen auf KI-Modelle, um Abläufe zu verbessern, Innovationen zu fördern und neue Geschäftsmodelle zu entwickeln. Während dabei Public-Cloud-Angebote nach wie vor selbst für kritische KI-Workloads weiterhin gefragt sind, wächst gerade für sensible Bereiche die Nachfrage nach privater, interner Bereitstellung im besonderen Maße. Die Gründe dafür sind Datenschutz, regulatorische Anforderungen, Sicherheit, Planbarkeit und vollständige Kontrolle über die eigenen Daten.

Die strengen Vorschriften in Europa und somit auch in Deutschland verlangen eine sichere Datenverarbeitung und -speicherung. Schon ein kurzer Blick auf die DSGVO zeigt, wie umfangreich das Ganze sich gestaltet. Öffentliche Cloudplattformen sind in der Regel nationalen Gesetzen unterworfen, die in Notfällen auch den Datenzugriffe durch Behörden erlauben – ein Risiko, das Sie und viele andere Unternehmen möglicherweise vermeiden möchten. Private KI-Implementierungen stellen eine Alternative dar: Sie erlauben es, die Modelle quasi in den eigenen vier Wänden zu betreiben und somit die vollständige Kontrolle über die Daten zu behalten.

Die Vorteile privater KI-Deployments

Abgesehen von regulatorischen Anforderungen sind es häufig auch strategische Überlegungen, die ein Unternehmen dazu bewegen, KI-Workloads lokal auszuführen. Die essenzielle Frage, die Sie sich in diesem Zusammenhang immer stellen müssen lautet: Wem gehören am Ende die Daten und die trainierten Modelle?

Viele KI-Anwendungen der Public Cloud basieren auf proprietären Plattformen. Und gerade hierdurch geraten Sie möglicherweise auch recht schnell in eine gewisse Abhängigkeit von einem bestimmten Anbieter und ehe Sie sich versehen, ist er auch schon da, der Vendor Lock-In. Setzen Sie hingegen auf die private KI, haben Sie immer die vollständige Kontrolle über die eingesetzten Modelle, Trainingsdaten und den gesamten KI-Lebenszyklus. Auch vermeiden Sie so den Trans- fer sensibler Geschäftsgeheimnisse und Kundendaten über externe Netzwerke, das Risiko von Datenlecks und verringern die Gefahr eines ungewollten Zugriffs. Zudem lässt sich die KI-Infrastruktur so gestalten, dass nur autorisierte Personen Zugriff darauf haben.

Daneben spielen technische und wirtschaftliche Faktoren natürlich eine große Rolle. So stellen KI-Modelle mitunter enorme Anforderungen an die Infrastruktur. Die Compute-Leistung, insbesondere beim Training oder der Verarbeitung umfangreicher Datenmengen ist in den meisten Fällen das A und O. In der Public Cloud teilen Sie sich die Rechenleistung mit vielen anderen Unternehmen. Dadurch entstehen möglicherweise Schwankungen, die Sie in der eige- nen Infrastruktur nicht in Kauf nehmen müssen. Hier bleiben Leistung und Verfügbarkeit in der Regel immer konstant und Sie müssen nicht mit sporadisch auftretenden Engpässen rechnen.

Auch was die Kosten angeht, sind Überraschungen kein Thema bei lokaler KI. Clouddienste sind oft nutzungsabhängig und KI-Anwendungen benötigen viele Ressourcen und die monatlichen Kosten können erheblich variieren. Auch in diesem Punkt haben lokale Deployments hinsichtlich der Budgetkontrolle die Nase recht weit vorn.

Werfen wir noch einen kurzen Blick auf das Thema "Investition oder Mietmodell". Öffentliche Clouddienste verursachen auf lange Sicht hohe Kosten, während sich eine eigene KI-Infrastruktur oft über die Zeit amortisiert. Sie haben im unternehmenseigenen Rechenzentrum die Wahl, ob Sie Kapazitäten kaufen, flexibel mieten oder eine Kombination aus beiden Modellen nutzen – je nach Bedarf und Unternehmensstrategie. Wenn Sie KI nicht nur testen, sondern langfristig und zuverlässig einsetzen möchten, benötigen Sie in jedem Fall eine Infrastruktur, die sowohl leistungsfähig als auch kalkulierbar sein muss.

Nutanix für lokale KI

All dies zeigt, dass Sie im optimalen Fall eine Plattform benötigen, die KI-Modelle unabhängig vom Standort sicher und flexibel verwalten kann. Nutanix Enterprise AI (kurz NAI) setzt genau hier an. NAI ist eine Kubernetes-native Plattform, die es ermöglicht, KI-Endpunkte auf der Basis unterschiedlicher Modelle bereitzustellen, zu skalieren und zu verwalten. Auch bereits trainierte Modelle lassen sich dergestalt produktiv nutzen. NAI ist nicht an eine spezifische Infrastruktur gebunden und erlaubt, sämtliche Inferenz-Workloads dort auszuführen, wo Sie die benötigen – on premises, in der Public Cloud oder auch in hybriden Cloudinfrastrukturen.

Die Entscheidung für eine private KI-Plattform beinhaltet auch ein geeignetes Betriebsmodell. Soll die KI vollständig laufen, sollen Ressourcen der Public Cloud Ressourcen zum Einsatz kommen oder ist ein hybrider Ansatz der richtige Weg für Sie und Ihr Unternehmen? NAI ermöglicht die Bereitstellung von KI-Modellen in nahezu jeder Umgebung. Ein zentraler Unterschied zu vielen anderen Bestandteilen der Nutanix Cloud Platform ist, dass NAI nicht an die Nutanix Cloud Infrastructure (NCI) gebunden ist, sondern vollständig auf Kubernetes aufbaut. Das bedeutet, dass die Plattform überall dort einsetzbar ist, wo ein Kubernetes-Cluster verfügbar ist – einschließlich der großen Hyperscaler wie AWS, Microsoft Azure oder Google Cloud Platform.

Ein KI-Deployment auf NCI integriert beispielsweise automatisch die Speicherdienste von Nutanix Unified Storage, wie etwa Block-, File- und Objekt-Speicher aus der Nutanix-NCI-Plattform für persistente Volumes. Auch stehen sofort die in NAI benötigten Fileshares via Nutanix-Files zur Verfügung, wenn NAI auf NCI und der Nutanix-Kubernetes-Plattform (NKP) installiert wird. Doch NAI ist nicht auf einen Betrieb in Verbindung mit NKP auf NCI angewiesen. Sie können CNCF-kompatible Kubernetes-Cluster selbst bereitstellen und dann NAI dort aufsetzen. In dieser Variante müssen Sie sich allerdings darüber im Klaren sein, dass Sie auf das vereinfachte Deployment mittels Blueprints aus dem Prism Central Marketplace der Nutanix Cloud Platform verzichten.

Weiter sollten Sie beim lokalen Betrieb unbedingt noch die Kompatibilität beim Betrieb mit GPUs im Auge behalten. NKP verwendet in der Starter-Variante ein Rocky-Linux, das keinen Nvidia-GPU-Operator besitzt. In diesem Fall ist mindestens die Version "NKP Professional" erforderlich. Denn nur dann sind Sie in der Lage, über den integrierten Image-Builder ein eigenes Worker-Node-Image mit GPU-Operator wie beispielsweise Ubuntu zu verwenden. Weitere Informationen zum Thema NKP-Lizenzierung und Funktionsumfang finden Sie unter [1].

NAI mit Ressourcen aus der Public Cloud

Ressourcen aus der Public Cloud maximieren die Skalierbarkeit, schaffen globale Verfügbarkeit und erlauben, zusätzliche Rechenkapazitäten einzubinden, die lokal wirtschaftlich möglicherweise nicht sinnvoll sind. NAI bietet auch hier Flexibilität und Sie entscheiden, ob sie die Plattform auf den verwalteten Kubernetes-Diensten der Hyperscaler, betreiben oder auf eine selbstadministrierte Variante wie beispielsweise eine K8s-Installation auf AWS EC2 setzen [2].

Eine zusätzliche Betriebsoption in der Cloud ist NKP. Diese kann entweder direkt auf VMs in der öffentlichen Cloud installiert werden oder als zentraler Management-Layer fungieren, um verwaltete Kubernetes-Setups der Hyperscaler als Workload-Cluster zu verwenden. Dadurch erreichen Sie eine konsistente Steuerung über alle Ihre Kubernetes-Umgebungen hinweg, unabhängig davon, wo die Workloads tatsächlich produktiv laufen.

Insbesondere für KI-Modelle, die viel Rechenleistung benötigen, ist es extrem wichtig, dass Sie die passende Compute-Infrastruktur in der Cloud anmieten. Um die Leistung von NAI mit großen Modellen überhaupt sinnvoll nutzen zu können, müssen Sie unbedingt darauf achten, dass die verwendeten Nodes eine GPU-Unterstützung bieten. In Microsoft Azure sind dies unter anderem die NC-A100-v4-Instanzen mit Nvidia A100 Tensor Cores und für hochperformante KI-Workloads die NC-H100-v5-Instanzen mit Nvidia H100. Um Kubernetes-Cluster mit GPU-Ressourcen für NAI zu erstellen, ist es möglich, beide Instanzen in den Azure-Kubernetes-Service einzubinden. Ähnlich sieht es bei Amazon Web Services aus, dessen P4d-Instanzen Sie mit A100 oder P5-Instanzen mit H100-GPUs mit dem Elastic Kubernetes Service (EKS) kombinieren.

Daneben arbeitet NAI auch in einem hybriden Modell. Workloads lassen sich sowohl lokal als auch in der Cloud ausführen. Dadurch können Sie Ihre Infrastruktur bedarfsorientiert skalieren und KI-Ressourcen an den Orten einsetzen, an denen diese benötigt werden.

NAI in Betrieb nehmen

Schauen wir uns nun einmal NAI von der Bereitstellung bis hin zum Betrieb im Detail an. NAI optimiert die Bereitstellung und den Betrieb von Inferenz-Workloads, indem es Kubernetes-native Automatisierung mit leistungsfähigen Managementtools kombiniert. So wird es möglich, verschiedene Modelle zu nutzen, ohne an ein bestimmtes Framework gebunden zu sein. Neben Nvidia Inferencing Microservices (NIM aus dem Nvidia NGC Catalog [3]) unterstützt NAI auch Hugging-Face-Modelle [4]. Ebenso können Sie eigene Modelle auf die Plattform hochladen und Anwendungen in Form eines Inferenz-Endpoint bereitstellen.

Mit dem NGC Catalog von Nvidia steht Ihnen eine Plattform zur Verfügung, die eine Sammlung optimierter Software für KI, Deep Learning, maschinelles Lernen und HPC (High-Performance Computing) bietet. Dazu gehören auch vorgefertigte Modelle, Trainingsskripte, Container, Jupyter-Notebooks und andere Ressourcen, die für Nvidia-GPUs optimiert sind. Und bei Hugging Face handelt es sich sowohl um eine Plattform als auch ein Unternehmen. Hugging Face hat sich auf natürliche Sprachverarbeitung (NLP) und maschinelles Lernen spezialisiert und ist mittlerweile eine Art GitHub für ML und KI. Die Plattform hostet Hunderttausende von Modellen, zigtausende Datensätze und Demos im sogenannten Hugging Face Hub.

Nutanix erlaubt wahlweise ein einfaches Deployment von NAI auf der Nutanix Cloud Platform mittels Prism Central Marketplace oder die manuelle Variante via Helm Charts. Bei der Nutzung alternativer Infrastrukturen wie dem Azure Kubernetes Services ist weiterhin die Installation via Helm Chart zwingend.

Helm [5] ist sozusagen ein Paketmanager für Kubernetes und ermöglicht, komplexe Kubernetes-Anwendungen in Helm Charts vorzudefinieren und die Bereitstellung dadurch zu vereinfachen. Also anstatt viele YAML-Files für die einzelnen Komponenten von NAI über kubectl auszurollen, können Sie ein Helm Chart verwenden, das alle Konfigurationen beinhaltet und gemeinsam ausrollt. Im ersten Schritt fügen Sie das Helm-Repository hinzu und aktualisieren es. Dies erledigen Sie mit folgendem Kommando:

Anschließend durchsuchen Sie die vorhandenen Helm-Chart-Versionen in Sachen NAI und notieren die gewünschte Version. Diese müssen Sie angeben, wenn Sie die passende Version herunterladen und anschließend installieren:

Haben Sie die passende Version gefunden, laden Sie das Helm Chart herunter und entpacken es (in diesem Beispiel Version 2.1.0):

Im heruntergeladenen Paket befinden sich mehrere "values.yaml"-Dateien für die verschiedenen Deployments wie NKP, EKS und so weiter. Je nach verwendeter Infrastruktur wird auf das passende File verwiesen, bei der Installation auf NKP zeigt "helm upgrade" dementsprechend auf das "nkp-values.yaml"-File. Des Weiteren müssen Sie einige Parameter wie Docker Repository und Credentials angeben. Mit diesen laden Sie dann Container-Images herunter oder geben weitere Kubernetes-Konfigurationen mit wie beispielsweise die Namen der Storage- Klassen für RWO und RWX-Storage – siehe Listing-Kasten.

Nachdem die Installation erfolgreich durchgelaufen ist, sehen Sie im CLI des "nai-systems"-Namespace die erstellten Pods und können dann anschließend via FQDN "ai.nutanix.com" auf die Benutzeroberfläche zugreifen. Nutzen Sie nun die Standard-Credentials (admin, Nutanix.123) zum Anmelden und beginnen Sie mit der Bereitstellung von Inferenz-Endpoints. In einem produktiven Deployment kommen natürlich noch weitere Schritte hinzu. Dazu gehört etwa die Konfiguration von DNS Records und Zertifikaten.

Ein KI-Modell in NAI bereitstellen

Haben Sie sich authentifiziert, erwarten Sie im folgenden Dashboard die unterschiedlichsten Widgets, die Ihnen alle Informationen der Umgebung liefern. So finden Sie hier beispielsweise die Zusammenfassung über die gesamte Infrastruktur und die Übersicht aller vorhandenen Endpunkte.

Das Bereitstellen von Inferenz-Endpunkten erfordert normalerweise eine Fülle von manuell durchzuführenden Einzelschritten. NAI vereinfacht das Ganze dadurch, dass es diesen Workflow zur vollständig automatisiert. So können Sie die Modelle direkt in das System hochladen oder beispielweise über den Hugging-Face-Katalog auswählen und registrieren. Dies standardisiert das Provisioning, das sich dadurch unabhängig vom gewählten Modell deutlich vereinfacht.

Um einen Zugriff auf die Modelle aus den einzelnen Katalogen zu bekommen, konfigurieren Sie zunächst die "Third Party Credentials" in den Settings. Diese nutzt NAI immer dann, wenn Sie vorhaben, über die Import-Models-Funktion ein LLM in das System zu laden. Anschließend wechseln Sie in den Reiter "Models" und wählen "Import Models". Hier können Sie dann zwischen den Optionen "Hugging Face Model Hub", "Nvidia NGC Catalog" und einem manuellen Import auswählen.

Viele Modelle aus den beiden erwähnten Katalogen hat Nutanix verifiziert. Dies bedeutet, dass der Anbieter das Deployment auf NAI getestet hat und für einen Betrieb in Verbindung mit NAI als geeignet ansieht. Dafür müssen die Abhängigkeiten zwischen den Komponenten überprüft und bekannt sein und dürfen letztendlich im Zuge der Prozessautomatisierung eines Deployments nicht zu Fehlfunktionen führen.

Aktuell stehen Ihnen aus dem Hugging-Face-Katalog 17 Modelle zur Verfügung. Darunter unterschiedliche Varianten der beliebtesten Modelle, wie beispielsweise Mistral, Llama oder Gemma. Sollte es vorkommen, dass ein von Ihnen gewünschtes Modell nicht dabei ist, bleibt Ihnen aber die Variante des manuellen Imports. Die Modelle wurden zwar nicht von Nutanix validiert, Sie können diese aber trotzdem einsetzen. Möglicherweise wurde eine KI mit eigenen Daten trainiert und somit eine eigene Version eines der Foundational-Modelle erstellt. Diese lässt sich via "Custom-Model" hochladen. Sie müssen dann allerdings im Zuge des Deployments zusätzliche Parameter einstellen und können den erleichternden Automatisierungsprozess nicht in vollem Umfang nutzen.

Endpoint aufsetzen und testen

Haben Sie sich für ein Modell entschieden und dieses dann importiert, können Sie mit der Bereitstellung des Inferenz-Endpoints beginnen. Den Provisioning-Workflow stoßen Sie über den Create-Endpoint-Button im Bereich "Endpoints" der Navigationsleiste an. Die Informationen zur Bereitstellung geben Sie im näch-sten Schritt ein: Name des Endpoints, das zu verwendende Modell, welche Grafikkarte genutzt werden soll und die Anzahl der Instanzen.

Den Zugriff auf das Modell via API-Key konfigurieren Sie entweder direkt bei der Erstellung oder erst nachdem die künstliche Intelligenz ausgerollt ist. Wenn Sie jetzt den Deployment-Prozess starten, sehen Sie augenblicklich, dass das System den Status "Processing" in der Endpoint-Übersicht anzeigt. Sobald NAI damit fertig ist, wechselt der Status des neu erstellten Endpoints auf "Active" und steht für Ihre Applikation zur Verfügung. Um den Endpunkt in einer Applikation zu nutzen, müssen Sie jetzt noch den Zugriff konfigurieren – falls nicht schon erledigt. Jetzt lässt sich dieser Key zur Authentifizierung am API-Endpunkt verwenden und die Anwendung ist in der Lage, sofort mit dem LLM zu kommunizieren.

Open WebUI [6] ist eine webbasierte Benutzeroberfläche, die den Zugriff auf lokale und externe LLMs ermöglicht. Die Applikation erlaubt die Interaktion mit einem Inferenz-Endpunkt sowie die Visualisierung des Vorgangs. Ist Ihre Applikation mit dem Endpoint verknüpft, sind Anfragen des LLM über den Prompt von Open WebUI möglich. Alternativ zur UI-Anfrage ist auch ein schneller Test des Modells via curl [7] möglich. Sie können das Tool ebenfalls zur Kommunikation mit dem API-Endpunkt nutzen, um dem provisionierten Modell erste Fragen zu stellen.

NAI bietet zudem selbst die Möglichkeit, eine Frage an den Inference-Service beziehungsweise das Modell zu stellen. Sie können in der NAI-GUI im Formular "Test-Endpoint" einen Request an das Modell senden. Natürlich müssen Sie an dieser Stelle nicht nur testen, sondern Sie haben selbstverständlich auch die Option, so wie von ChatGPT bekannt, richtig zu prompten, um festzustellen, ob das gewählte Modell auch wirklich Ihren Anforderungen genügt.

Ressourcen mit Bordmitteln überwachen

Damit Ihre Inferenz-Workloads auch effizient laufen, stellt Ihnen die NAI umfangreiche Monitoring- und Analysefunktionen bereit. Das System überwacht die genutzten CPU-, Speicher- sowie die GPU-Ressourcen und stellt deren Auslastung in einfachen und übersichtlichen Dashboards transparent dar. Sie erhalten dadurch nicht nur einen ganz granularen Einblick in den aktuellen Verbrauch der Ressourcen, sondern erkennen proaktiv Engpässe oder Überprovisionierung. So visualisiert das Interface beispielsweise auch ein System, das über zwei GPUs verfügt, von denen eine nicht arbeitet und die andere nur geringfügig ausgelastet ist. Gerade diese genaue Ressourcenanalyse ist für ein System, das viele Anwender gleichzeitig nutzen, ein Muss und vereinfacht zudem dem Admin den Alltag erheblich.

Neben der Gesamtauslastung des Clusters und der einzelnen GPUs erkennen Sie via GUI auch die Belastung jedes einzelnen Endpunkts. Durch die Auswahl eines Endpunkts sind Sie in der Lage, sich einen detaillierten Überblick zu verschaffen. Achten Sie an dieser Stelle auch auf die "API Requests Summary" – derartige Metriken ermöglichen die Bewertung eines Systems im Hinblick auf Auslastung in erheblichem Maße.

Auch bei der Kapazitätsplanung unterstützen Sie die vom System gesammelten Daten hinsichtlich der Workloads. Durch den transparenten Einblick in die Nutzung von Rechen- und Speicherressourcen sind Sie in der Lage, eine Entscheidung darüber zu treffen, wann Sie zusätzliche Ressourcen benötigen oder wo Einsparungen möglich sind. NAI unterstützt Sie also dabei, zu jedem Zeitpunkt ein optimiertes Sizing Ihrer Workloads vorzunehmen.

Lokale User und Rollen zuweisen

NAI erlaubt es, lokale User nach RBAC (Role Based Access Control) anzulegen und zu verwalten. Sie wählen also die Rolle des neuen Nutzers und hinterlegen anschließend E-Mail-Adresse, Vorname, Nachname, Benutzername und Passwort. Nachdem Sie alle Daten in das Add-User-Formular eingetragen und bestätigt haben, ist der neue Benutzer bereits für das initiale Login freigegeben. Das im Workflow erstellte Passwort ist ein Einmalpasswort, das beim ersten Login geändert werden muss. Meldet sich also der neue User an, muss er ein neues Kennwort vergeben, bevor er sich am System authentifizieren kann. Anschließend ist es dann möglich, sich mit der Rolle des ML/AI-Users als Demo-User einzuloggen.

Nach der Anmeldung muss der User nun dediziert für diesen Account wieder Credentials zum Hugging-Face- und Nvidia-Katalog konfigurieren. Anschließend können dann Modelle aus den Quellen importiert und bereitgestellt werden. Benutzer mit der Rolle "AI/ML-User" sehen die Modelle und Endpunkte von anderen Usern nicht. Lediglich Anwender mit der AI/ML-Admin-Rolle sehen die importierten Modelle und bereitgestellten Endpunkte aller Benutzer.

Die Hugging-Face- und Nvidia-Katalog-Credentials sind für jeden lokalen User dediziert. Das bedeutet, dass sie niemals zwischen den Anwendern geteilt werden. Außerdem sind die Modelle neu zu importieren, wenn diese von einem anderen User verwendet werden sollen. Bei der Installation von NAI wird automatisch der User "admin" angelegt. Dies ist der einzige Anwender, der die Super-Admin-Rolle erhält und somit auch die höchsten Berechtigungen hat.

Die AI/ML-User- und Admin-Rollen unterscheiden sich primär darin, dass die Admins die User verwalten und Ressourcen verschiedener User sehen. AI/ML-User können immer nur die eigenen Ressourcen wie die importierten Modelle oder bereitgestellten Endpunkte sehen und verwalten. Möchten Sie auf die Audit-Events zugreifen, die die NAI-Ereignisse zeigen, benötigen Sie AI/ML-Admin- oder Super-Admin-Berechtigungen.

Fazit

Bei künstlicher Intelligenz geht es im Wesentlichen darum, unterschiedliche Modelle möglichst effizient und schnell bereitzustellen und zu nutzen, ohne dabei auf Datenschutz, Sicherheit und Kontrolle verzichten zu müssen. Während die Dienste der Cloud mit schneller Skalierung glänzen, wächst dennoch die Nachfrage nach privaten und auch hybriden Ansätzen. Auch spielen regulatorische Gründe und die Vermeidung von Abhängigkeiten eine große Rolle.

Nutanix Enterprise AI lässt sich dank seines Kubernetes-nativen Ansatzes in eine Vielzahl von IT-Umgebungen integrieren – on premises, in der Public Cloud oder in einer hybriden Architektur. Gerade diese Kombination aus einfacher Bereitstellung, automatisiertem Inferenz-Management und granularer Zugriffskontrolle macht es möglich, KI-Workloads unabhängig von festen Standorten zu betreiben. Auch die integrierten Möglichkeiten des Monitorings sowohl der Ressourcen als auch der Workloads unter- stützen den IT-Verantwortlichen beim Betrieb derartiger IT-Infrastrukturen.