Jenseits von Containern und VMs Der Aufstieg der KI-nativen Cloud

Von Dr. Dietmar Müller 10 min Lesedauer

Anbieter zum Thema

Die IT-Infrastruktur steht vor einer neuerlichen Revolution: Vektordatenbanken und dynamische Allokation verändern die Cloud von Grund auf. Welche neuen Layer und Services Cloud-Architekten müssen Architekten jetzt beherrschen? Antworten darauf gibt nicht zuletzt Walter Sun, weltweiter KI-Chef der SAP.

Die neue AI-native Cloud verschiebt das Grundprinzip der Cloud von einer Ressourcen-orientierten Architektur mit virtuellen Maschinen hin zu einer Funktionalitäts-orientierten Welt mit KI-Modell-APIs.(Bild: ©  fotomek - stock.adobe.com)
Die neue AI-native Cloud verschiebt das Grundprinzip der Cloud von einer Ressourcen-orientierten Architektur mit virtuellen Maschinen hin zu einer Funktionalitäts-orientierten Welt mit KI-Modell-APIs.
(Bild: © fotomek - stock.adobe.com)

Alles ist im Fluss... Gerade haben wir es uns in der Cloud-nativen-Ära gemütlich eingerichtet, da ist sie auch schon wieder vorbei. Die Zeit war geprägt durch eine, aus heutiger Sicht, „traditionelle“ Cloud-Infrastruktur, namentlich Infrastructure-as-a-Service (IaaS) und Platform-as-a-Service (PaaS). Beide dienen der Verarbeitung von Workloads der Web 2.0-Ära mit virtuellen Maschinen, entsprechenden Datenbanken, Microservices und Containern.

Letztere waren noch vor weniger als zehn Jahren der angesagteste Modetrend der IT-Szene, heute haben sie sich etabliert und werden auch in der neuen, KI-nativen Welt gebraucht. Sie erfüllen die Anforderungen heutiger generativer künstlicher Intelligenz (KI) und Large Language Models (LLMs) an Latenz, Durchsatz und Ressourceneffizienz.

Doch da ist noch mehr, viel mehr.

GPUs stellen CPUs in den Schatten

Zunächst zeichnet sich eine KI-Native Cloud dadurch aus, dass Graphics Processing Units (GPUs) und Tensor Processing Units (TPUs) nicht mehr optionale Add-ons, sondern die primären Compute-Ressourcen sind. Wie arm machen sich angesichts der neusten Leistungsschritte in diesen Bereichen die früheren Kämpfe zwischen AMD und Intel um das eine oder andere Megahertz (MHz) mehr an Leistung für ihre Central Processing Units (CPUs)!

Eine CPU besteht aus einer Steuereinheit, einer arithmetisch-logischen Einheit und einem Registersatz und inkorporiert in modernen Chips wie „Intel Core i9“ der 10./11. Generation für rund 500 Euro etwas mehr als 10 Milliarden Transistoren. GPUs mit der „Nvidia Blackwell“-Architektur enthalten dagegen 208 Milliarden Transistoren und verfügen über zwei reticle-begrenzte Chips, die über eine Schnittstelle mit 10 Terabyte pro Sekunde zu einer einzigen, einheitlichen GPU verbunden sind.

Eine Tensor-Recheneinheiten ermöglichen Mixed-Precision-Computing. Diese Form der Chip-Architektur ist teuer: Für professionelle Workstations gibt es die „Nvidia RTX Pro“-Serie , zum Beispiel „RTX 6000“ ab rund 8.000 Euro, während die leistungsstärkeren KI-Chips für Rechenzentren wie der „Grace-Blackwell GB200“ für 30.000 bis 70.000 Dollar pro Chip kosten. Für komplette Systeme wie das „DGX B200“ werden sogar über 400.000 Euro fällig.

Bei solchen Preisen ist Leerlauf der größte Feind der Marge. Es besteht eine echte Notwendigkeit, die teuren GPUs möglichst effizient zu nutzen.

Das führt auf der Hardware-Ebene zu komplexen Multi-Tenant- und Micro-Service-Ansätzen, um Inferenz-Jobs parallel abwickeln zu können: Für die effiziente Nutzung einer GPU, ohne dass sich die Nutzer gegenseitig stören, setzen Anbieter auf Techniken wie Multi-Instance GPU (MIG) von Nvidia.

Die physische GPU wird dabei in bis zu sieben unabhängige Instanzen partitioniert. Jede dieser Instanzen hat ihren eigenen, isolierten Speicher und eigene Rechenressourcen. So können sieben verschiedene Kunden oder sieben verschiedene Applikationen völlig getrennt voneinander auf demselben Chip arbeiten. Das erhöht die Auslastung und senkt die Kosten pro Nutzer massiv.

Was rechnet sich? AI-as-a-Service oder eigene GPU-Cluster?

Unternehmen stehen seit Jahren vor der gleichen Grundsatzentscheidung: Setzen sie auf die Bequemlichkeit von As-a-Service und vorkonfigurierten Angeboten oder investieren sie in eigene Hardware und eine vollständig selbst betriebene Infrastruktur? Diese Frage verschärft sich angesichts der enormen Anschaffungskosten für Architekturen wie Nvidia Blackwell und von Techniken wie MIG noch einmal.

„Während Tech Giganten mit enormer Größe und Ressourcen gelegentlich den Eigenbau bevorzugen, dürfte der Großteil der Unternehmen einen pragmatischen Mittelweg wählen. Denn Kostenstrukturen, Fachkräftemangel und die rasante Weiterentwicklung von Hardware und Algorithmen sprechen klar dafür, KI als Service zu nutzen – flexibel, skalierbar und zukunftssicher“, beantwortet Walter Sun, Senior Vice President und Global Head of Artificial Intelligence bei SAP, diese Frage.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu RZ- und Server-Technik

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung

Er gibt zu bedenken: „Wichtig ist dabei: Wer einen Managed Service nutzt, gibt seine Differenzierungsfähigkeit keineswegs auf. Unternehmen behalten weiterhin die Kontrolle über Daten, Modelle und Geschäftsprozesse. Gleichzeitig profitieren sie von sicheren, unternehmensgerechten KI Services, die den operativen Aufwand erheblich reduzieren.“

Container schippern in die schöne, neue Welt

In der KI-nativen Welt kommen, wie schon in der Cloud-nativen Ära, Microservices zum Einsatz: Die Inferenz wird in kleine, spezialisierte Aufgaben zerlegt, etwa Text-Tokenisierung, Embedding oder Generierung. Diese Aufgaben werden in Container verpackt. Ein System wie Kubernetes verteilt diese winzigen Aufgaben dann auf die gerade freien Lücken im GPU-Cluster.

Der entscheidende technische Trick für die Parallelität ist das so genannte Continuous Batching. Sobald ein Token generiert wurde, darf sofort ein neuer Auftrag beginnen, während die GPU alle anderen Tokens abarbeitet. Für die dynamische Allokation kommen Systeme zum Einsatz, die Ressourcen wie Speicher und Rechenleistung in Echtzeit und hochdynamisch basierend auf dem KI-Workload zuteilen.

Nicht zu vernachlässigen ist auch die Bedeutung von Hochgeschwindigkeits-Interconnects wie „Nvidia NVLink“ für die GPU-zu-GPU-Kommunikation innerhalb eines einzelnen Servers oder Infiniband für die Verbindung mehrerer Server in Clustern innerhalb der Cloud-Rechenzentren, um die Kommunikation zwischen Hunderten von Beschleuniger-Einheiten zu gewährleisten.

Vektoren bilden den Kern der neuen Daten-Architektur

Neben neuen Hardware-Ansätzen spielen auch Vektordatenbanken eine immer wichtigere Rolle. Cloud-Anbieter integrieren sie nicht mehr nur als Drittanbieter-Service, sondern als native, hochverfügbare Komponente direkt neben den traditionellen SQL/NoSQL-Datenbanksystemen. Sie speichern die semantische Bedeutung von Daten und sind essenziell für die Retrieval Augmented Generation (RAG), ein Ansatz für die Verarbeitung natürlicher Sprache (NLP), der große Sprachmodelle (LLMs) mit Information Retrieval Systemen kombiniert.

Im Kern ist das RAG-Verfahren, dessen sich auch Oracle für die Transformation seiner Datenbanken in die neue Ära bedient, für Cloud-Architekten nichts weniger als ein Paradigmenwechsel: Die KI wird nicht mehr nur als Rechenhirn betrachtet, sondern als ein System, das ein externes Langzeitgedächtnis benötigt.

Denn ein LLM wie „GPT-4“ oder „Llama 3“ ist nach dem Training „eingefroren“. Es weiß nichts über die Verkaufszahlen von letzter Woche oder interne Projektdokumente. Das Modell mittels Fine-Tuning neu zu trainieren ist zu teuer und zu langsam. Man nutzt daher eine Vektordatenbank als „Single Source of Truth“. Das minimiert zudem Halluzinationen drastisch.

In der Pipeline: Vom Text zum mathematischen Vektor

Damit eine künstliche Intelligenz Daten „verstehen“ kann, müssen sie in eine mathematische Sprache übersetzt werden. Dieser Prozess nennt sich Embedding-Pipeline: Riesige PDF-Archive oder Datenbanken werden in kleine, sinnvolle Textstücke zerlegt. Ein spezialisiertes, kleineres KI-Modell verwandelt diese auch Chunks genannten Textpassagen in lange Zahlenreihen: die Vektoren.

Wenn ein Nutzer eine Frage stellt, wandelt die Pipeline sie innerhalb von Millisekunden in einen Vektor um. Die Vektordatenbank durchsucht dann Millionen von Einträgen nach den ähnlichsten Vektoren. Die gefundenen Fakten werden in den Prompt der KI eingebaut.

Damit das ohne spürbare Verzögerung funktioniert, setzen moderne Datenbanken wie „Pinecone“, „Milvus“ und „Weaviate“ auf spezielle Indexierungs-Algorithmen wie Hierarchical Navigable Small World (HNSW). Das ermöglicht eine Suche in Lichtgeschwindigkeit, selbst bei Milliarden von Datensätzen.

Also: Kennzeichnend für die neue Cloud-Ökonomie ist, dass LLMs austauschbar sind; der wahre Wert liegt in der Vektor-Pipeline, die das unternehmenseigene Wissen in Echtzeit für die KI nutzbar macht.

Der Wandel von PaaS zu AIaaS

Cloud-Anbieter bieten heute fertige, fein abgestimmte KI-Modelle, die so genannten Foundation Models, über einfache APIs an. Das hat den Vorteil, dass sich Entwickler weniger um die Infrastruktur kümmern müssen und sich auf das Prompt Engineering und die Integration konzentrieren können.

Neue Cloud-Dienste orchestrieren die komplexen Interaktionen zwischen verschiedenen LLM-Aufrufen, Tools, Datenquellen und KI-Agenten. Dies stellt die nächste Abstraktionsschicht oberhalb von Containern und Functions dar, ein „Agentic Orchestration Layer“:

Die IT bewegt sich damit weg vom „Statischen Code“ mit Functions und Containern hin zum „Dynamischen Intent“ mittels KI-Agenten. Während ein Container einfach läuft, muss ein Agent entscheiden, pausieren, nachfragen und Werkzeuge benutzen.

Die großen Hyperscaler haben ihre Dienste von einfachen API-Schnittstellen zu kompletten „Agenten-Fabriken“ ausgebaut: AWS etwa nutzt bei seinen „Bedrock“- Agents „Action Groups“ und „Knowledge Bases“. Der Dienst übernimmt die komplette Orchestrierung und zerlegt eine Benutzeranfrage in Einzelschritte, entscheidet, welches API-Tool aufgerufen werden muss, und führt die Rückkopplungsschleife automatisch aus.

Der „Vertex AI Agent Builder“ von Google, eine Weiter- beziehungsweise Nebenentwicklung der Entwicklerplattform „Vertex AI“, bietet eine No-Code/Low-Code-Oberfläche, um Agenten mit Tools zu verknüpfen. Und „Microsoft Azure AI Foundry“ setzt stark auf das „Semantic Kernel Framework“. Es erlaubt „Planners“, die dynamisch entscheiden, in welcher Reihenfolge Funktionen aufgerufen werden müssen, um ein Ziel zu erreichen.

Die Agenten-Stati

Aber auch abseits der Giganten sind Dienste entstanden, die sich ausschließlich auf das State Management von Agenten konzentrieren: Das „Langgraph“-Framework von Langchain stellt den aktuellen „Goldstandard“ für komplexe Agenten dar. Während normale LLM-Aufrufe „stateless“, also ohne Gedächtnis, agieren, erlaubt Langgraph zyklische Workflows. Die Cloud-Variante übernimmt das Hosting dieser komplexen Zustandsmaschinen; sie ist quasi das „Kubernetes für Agenten“.

„Crewai Enterprise“ ist ein Dienst, der sich auf die Multi-Agenten-Orchestrierung spezialisiert hat. Hier managt die Cloud nicht nur einen Agenten, sondern ein ganzes Team, bestehend beispielsweise aus einem Recherche-Agenten, einem Schreib-Agenten und einem Prüf-Agenten, die untereinander kommunizieren.

Und „Fixie.ai“, ein Pionier im Bereich „Sidekicks“, bot eine Plattform an, die Agenten schnell mit externen Datenquellen und APIs verdrahtet, wobei die Cloud die Authentifizierung und das Session-Management übernimmt. Mittlerweile hat sich der Name und das Unternehmen selbst zu Ultravox weiterentwickelt, weil das Team nun die Latenz und Natürlichkeit von Sprache als größte technologische Hürde für „echte“ KI-Interaktion nehmen will.

Warum Cloud-Architekten jetzt neue Skills benötigen

Der damit beschriebene Übergang vom statischen Code mit Containern und Functions zum „dynamischen Intent“ mit Agenten stellt die Cloud-Architekten vor völlig neue Aufgaben. Statt wie bisher deterministische Abläufe zu bauen, müssen sie nun „Agentic Orchestration Layers“ entwerfen, bei denen das Systemverhalten nicht mehr zu einhundert Prozent vorhersehbar ist.

„Architekten sollten künftig weniger auf strikt vorherbestimmte Abläufe setzen und stattdessen Prozesse entwickeln, die sich an der gewünschten Zielsetzung orientieren“, erläutert Dr. Sun. „In modernen, agentenbasierten KI-Systemen verlaufen viele Schritte nicht vollständig planbar – sie basieren auf Wahrscheinlichkeiten und reagieren flexibel auf neue Informationen. Und das ist keineswegs ein Nachteil: Auch im Geschäftsleben waren Ergebnisse noch nie bis ins Detail vorhersagbar.“

Wer akzeptiert, dass solche Workflows nicht vollständig festgelegt, sondern an vielen Stellen wahrscheinlichkeitsbasiert sind, schaffe Raum für das Wesentliche: klare Ziele, klare Erfolgskriterien und Prozesse, die flexibel bleiben und Ergebnisse statt starrer Vorgaben in den Mittelpunkt stellen. „So entsteht ein Designansatz, der näher an der Realität ist, robuster funktioniert und besser zu dynamischen Märkten passt“, erläutert der weltweite KI-Chef der SAP.

Mit MLOps gegen Alterskrankheiten

Wir sehen: KI-Modelle stellen neue Ansprüche an die Entwickler. Hinzu kommt, dass diese wesentlichen Bausteine der neuen AI-Native Cloud im Gegensatz zu herkömmlicher Software „altern“, sie werden also ungenau, wenn sich die reale Welt verändert.

Ein Monitoring für produktive Systeme ist daher unabdingbar. Diese Disziplin nennt sich Machine Learning Operations (MLOps) und ist das Äquivalent zu DevOps für die Welt der KI.

Folgende Monitoring-Tools gelten als sehr tief in die jeweiligen Cloud-Ökosysteme integriert:

1. AWS: Das Sagemaker-Ökosystem
Amazon bietet mit „Sagemaker“ die wohl umfassendste Suite für den gesamten Lebenszyklus. „Sagemaker Model Monitor“ ist dabei das zentrale Tool für Drift Detection. Es vergleicht die Daten, die im Live-Betrieb ankommen, automatisch mit den Trainingsdaten. Wenn die Abweichung zu groß wird, also ein Data Drift erfolgt ist, oder die Vorhersagen ungenau werden – man spricht von einem Concept Drift -, schlägt es über „Cloudwatch“ Alarm.
„Sagemaker Pipelins fungiert als Workflow-Service. Es startet bei einem Alarm automatisch eine Retraining-Pipeline, die neue Daten aus „S3“ zieht, das Modell neu trainiert und erst nach einer Qualitätsprüfung automatisch nutzt.

2. Google Cloud: Vertex AI
Der Entwicklungsplattform „Vertex AI“ von Google sind wir bereits beim Thema Agentic Orchestration Layer begegnet. Sie hat den Vorteil, dass ihr System von Grund auf als eine Einheit konzipiert wurde. „Vertex AI Model Monitoring“ bietet eine vergleichsweise elegante Integration in „Bigquery“. Entwickler können Schwellenwerte festlegen, und das Tool visualisiert die Verteilungsunterschiede der Daten direkt in der Konsole. Beeindruckend ist, dass es „Skew“, das sind Unterschiede zwischen Trainings- und Live-Daten, fast in Echtzeit erkennt. Vertex AI Pipelines basiert auf „Kubeflow“ und sorgt für die Automatisierung. Es kann komplexe Ketten von Bigquery-Abfragen bis zum Deployment steuern.

3. Microsoft Azure: Azure Machine Learning
Microsoft setzt stark auf die Verbindung von klassischem DevOps und KI. „Azure ML Model Monitoring“ ist entsprechend tief in den „Azure Monitor“ und „Application Insights“ integriert. Das bedeutet, dass IT-Teams KI-Modelle mit den gleichen Werkzeugen überwachen können wie ihre restliche Infrastruktur. „Data Drift Detection“ bezeichnet spezialisierte Datasets in Azure, die automatisch Profile erstellen und Veränderungen melden.

Hier die Unterschiede der integrierten Cloud-Lösungen:

ML-Plattform-Vergleich
Feature AWS SageMaker Google Vertex AI Azure ML
Drift-Analyse Sehr detailliert (Model Monitor) Nahtlos (BigQuery-Anbindung) Stark in IT-Monitoring integriert
Pipeline-Basis Eigene Architektur (Sagemaker) Open Source (Kubeflow/TFX) Azure DevOps / GitHub Actions
Automatisierung Event-basiert via Lambda/EventBridge Nativ über Pipeline-Trigger Fokus auf CI/CD-Integration

4. Herausforderer in Sachen Deep Cloud Integration
Oft nutzen Unternehmen spezialisierte Tools, die sie über den Cloud-Marketplace kaufen, weil diese noch detailliertere Einblicke bieten. Die Tools „Arize AI“ und „Whylabs“ etwa sind auf die Antwort spezialisiert, „warum“ ein Modell driftet.
Sie lassen sich per Knopfdruck mit AWS oder GCP verbinden und bieten oft bessere Dashboards als die Cloud-Anbieter selbst. „Weights & Biases“ (W&B) gilt als Liebling vieler Data Scientists und führt das Tracking von Experimenten durch. Es lässt sich tief in Cloud-Trainings-Cluster integrieren.

Schlussfolgerung

Damit sind die wesentlichen Merkmale der neuen AI-native Cloud genannt. Leicht ist zu erkennen, dass sie mehr ist als nur zusätzliche Hardware. Sie ist eine Verschiebung in der Grundphilosophie der Cloud: von einer Ressourcen-orientierten Architektur mit virtuellen Maschinen hin zu einer Funktionalitätsorientierten Welt mit KI-Modell-APIs. Cloud-Architekten müssen ihr Wissen um die Datenfluss-Optimierung mittels Vektoren und die Ressourcen-Effizienz durch spezialisierte Hardware erweitern, um die nächste Generation von Cloud-Anwendungen erfolgreich zu bauen.

(ID:50782296)