Private KI-Infrastruktur: ein vollständiger Architekturüberblick

10

Private KI-Infrastruktur ist das, was Unternehmen am Ende aufbauen, wenn Aufsichtsbehörde, Vorstand oder Egress-Rechnung Training und Inferencing in einer von Dritten im Ausland betriebenen Public Cloud ausschließen. Die Entscheidung ist selten ideologisch. Sie ergibt sich aus der Wirtschaftlichkeit eines Trainingskorpus im Multi-Petabyte-Bereich, aus der Residenzvorgabe in einem Schreiben der Aufsicht oder aus der Audit-Klausel eines Vertrags für kritische Systeme. Sobald das Programm privat laufen muss, lautet die Frage, welche Ebenen des Stacks zuerst zu entwerfen sind und welche Zielkonflikte sich jeweils daraus ergeben. Dieser Leitfaden richtet sich an CIOs, Chief Data und AI Officers sowie Infrastrukturverantwortliche, die sich vor einer Designentscheidung einen Überblick über den gesamten Stack verschaffen wollen. Er geht die vier Ebenen durch – Compute, Speicher, Netzwerk und Betrieb – und zeigt, warum die Datenebene für nahezu jedes KI-Programm im Unternehmen zum begrenzenden Faktor geworden ist.

Was ist private KI-Infrastruktur?

Private KI-Infrastruktur ist der kombinierte Stack aus Compute, Speicher, Netzwerk und Betrieb, mit dem der KI-Lebenszyklus in einer vom Unternehmen kontrollierten Infrastruktur betrieben wird – Training, Fine-Tuning, Inferencing, Retrieval-Augmented Generation, Embeddings, Checkpoints, Evaluierung und Langzeitaufbewahrung. Das entscheidende Merkmal: Daten-, Identitäts- und Betriebsebene werden unter der rechtlichen und betrieblichen Hoheit des Dateneigentümers betrieben statt in einem öffentlichen, gemeinsam genutzten oder im Ausland betriebenen Mandanten. Die Kategorie ist breiter als On-Premises-KI und spezifischer als Private Cloud. Private KI-Infrastruktur kann in einem eigenen Rechenzentrum, einer Colocation-Einrichtung, einer akkreditierten Sovereign-Cloud-Region oder in einer abgeschotteten Umgebung mit Air Gap liegen. Sie gilt weiterhin als privat, wenn Platzierung, Zugriff, Aufbewahrung und Prüfung von der Plattform durchgesetzt werden, die das Unternehmen betreibt – nicht durch einen Vertrag mit einem Hyperscaler. Die Architektur muss Workloads unterstützen, die sich auf I/O-Ebene kaum ähneln. Training erzeugt anhaltende sequenzielle Lesezugriffe mit mehreren Dutzend Gigabyte pro Sekunde. Inferencing erzeugt bei hoher Parallelität zufällige Lesezugriffe mit engen Latenzbudgets. Checkpoints und Embeddings erzeugen Schreibstürme in unvorhersehbaren Abständen. Die Langzeitaufbewahrung erzeugt kaum Datenverkehr, belegt aber den größten Teil der Kapazität. Ein einziger Stack muss all das aufnehmen, ohne auseinanderzufallen.

Die vier Ebenen eines Stacks für private KI-Infrastruktur

Jedes Deployment dieser Art hat dieselben vier Ebenen, auch wenn die Bezeichnungen variieren.

Die vier Ebenen lassen sich nicht isoliert entwerfen. Ein GPU-Cluster wird nur dann ausgelastet, wenn die Speicherebene sein Leseprofil dauerhaft bedienen kann und das Netzwerk die Daten ohne Head-of-Line-Blocking transportiert. Ein perfekt abgestimmtes Paar aus Compute und Speicher fällt trotzdem durch das Audit, wenn die Betriebsebene keine manipulationssicheren Nachweise liefern kann. Die meisten gescheiterten Programme für private KI lassen sich darauf zurückführen, dass eine Ebene im Detail und die anderen drei nach Standard entworfen wurden.

Compute: GPU-Cluster und ihre Grenzen

Die Compute-Ebene wird von GPU-Clustern dominiert, ergänzt um CPU-Head-Nodes und eine kleine Flotte von Management-Hosts. Die wichtigsten Variablen in der Designphase sind GPU-Generation, Verbindungstopologie, Kühlung und Energiebudget sowie der Beschaffungszeitplan. Die GPU-Generation bestimmt die Obergrenze für den Trainingsdurchsatz pro Dollar und für die Inferencing-Latenz pro Token. Die Verbindungstopologie – NVLink innerhalb eines Knotens, InfiniBand oder RoCE zwischen Knoten – bestimmt die praktische Skalierungsgrenze für verteiltes Training. Kühlung und Strom dominieren die Standortwahl: Ein Unternehmen, das einen ernsthaften Trainingscluster aufbaut, entscheidet sich für Flüssigkeitskühlung auf Rack-Ebene, Racks mit 30 bis 60 kW und ein Energiebudget, das vor der Bestellung mit dem Facility-Team abgestimmt sein muss. Die Compute-Ebene macht Schlagzeilen, ist aber auch die Ebene, die am stärksten von den anderen drei abhängt. Ein Cluster mit 512 GPUs, der mangels Daten leerläuft, ist das teuerste Fehlerbild der gesamten Architektur. Mehr dazu erfahren Sie unter Komponenten und Design von KI-Compute-Infrastruktur – dort wird das Thema ausführlicher behandelt.

Speicher: das vereinheitlichende Fundament des Stacks

Speicher ist die Ebene, die jede Phase des KI-Lebenszyklus und jeden Workload gleichzeitig berührt. Die Ingestion holt Rohdaten mit mehreren Gigabyte pro Sekunde herein. Aufbereitungspipelines transformieren, labeln und versionieren sie. Das Training streamt den Trainingskorpus mit anhaltendem Durchsatz. Das Inferencing liest Embeddings und Kontext mit strengen Latenzbudgets. Checkpoints, Modellgewichte, Evaluierungsberichte und Audit-Logs landen alle irgendwo. Die Aufbewahrung läuft noch Jahre, nachdem das Modell, das die Daten erzeugt hat, ausgemustert wurde. Daraus folgt: Speicher kann nicht für einen einzigen Workload entworfen werden. Ein Deployment mit einem Speichersystem für das Training, einem zweiten für das Inferencing, einem dritten für den Data Lake und einem vierten für das Backup hat sich für ein Betriebsmodell mit vier Teams und vier Governance-Regimen entschieden. Die meisten Unternehmen, die sich auf ein einziges Objektspeicher-Fundament mit temperaturübergreifendem Tiering konsolidieren, gewinnen innerhalb des ersten Refresh-Zyklus Personalkapazität und Beschaffungsdisziplin zurück. Drei Eigenschaften unterscheiden KI-tauglichen Speicher von generischem Unternehmensspeicher:

• Anhaltender Durchsatz im großen Maßstab. Spitzenwerte aus Benchmarks sagen nichts über das Verhalten an einem Trainingstag aus. Entscheidend ist der Durchsatz, der über Stunden bei gleichzeitigen Lese-, Schreib- und Metadatenoperationen gehalten wird.
• Temperaturübergreifendes Tiering in einem Namespace. Aktive Trainingsdaten, warme Inferencing-Daten und Langzeitaufbewahrung haben grundverschiedene Kosten- und Leistungsprofile. Richtlinienbasierte Platzierung über NVMe, HDD, Band und Cloud-nahe Medien erspart dem Team den Betrieb von vier Silos.
• Identitätsgebundener Zugriff und Unveränderlichkeit. Trainingskorpora, Modellgewichte und Inferencing-Logs sind hochwertige Angriffsziele. Object Lock, KMS-gestützte Verschlüsselung und manipulationssichere Audits sind keine optionalen Ergänzungen.

Mehr zur Speicherseite des Designs finden Sie unter Schlüsselkomponenten der KI-Dateninfrastruktur (auf Englisch) und Tiered Storage für KI: skalierbare Leistung und Kostenkontrolle.

Netzwerk: East-West, North-South und GPU-Direct-Pfade

Die Netzwerkebene gliedert sich in drei Bereiche. Das East-West-Netzwerk im GPU-Cluster transportiert den Datenverkehr des verteilten Trainings zwischen GPUs. Das North-South-Netzwerk verbindet den Cluster mit der Speicherebene und dem übrigen Unternehmen. Ein separates Managementnetzwerk übernimmt Bereitstellung, Monitoring und Audit. Das East-West-Design wird von InfiniBand oder RoCE mit 200 oder 400 Gbit/s pro Port dominiert, mit nicht blockierenden Fat-Tree- oder Rail-optimierten Topologien für die größten Cluster. Über die Skalierbarkeit des Trainings entscheidet die Varianz der Tail-Latenz, nicht die durchschnittliche Bandbreite. Das North-South-Design entscheidet, ob die Speicherebene den GPU-Cluster ausreichend versorgen kann. GPU-Direct-Pfade – S3 over RDMA, GPUDirect Storage – ermöglichen es dem GPU-Speicher, Daten abzurufen, ohne den Umweg über den CPU-Speicher zu nehmen. Auf der GPU-Direct-Ebene ist mit Flash-basiertem Objektspeicher heute eine Latenz unter 50 Mikrosekunden erreichbar. Einen breiteren Blick auf die Zielkonflikte bietet Hybrid-Cloud-Datenstrategie für KI-Workloads.

Betrieb: die Ebene, die Prüfer tatsächlich lesen

In der Betriebsebene zeigt sich, ob die Architektur einer Prüfung standhält oder unbemerkt Risiken anhäuft. Sie umfasst vier Teilbereiche:

• Bereitstellung und Planung. Kubernetes mit Operatoren wie Kubeflow, Ray oder Slurm-on-Kubernetes koordiniert GPU-Zuteilung, Job-Warteschlangen und Pipeline-Orchestrierung.
• Identität, Zugriff und Richtlinien. SSO, feingranulares IAM auf Objekt- und Mandantenebene, Verschlüsselung mit kundenkontrollierten Schlüsseln und Richtlinien-Engines, die Platzierung, Aufbewahrung und Zugriff auf der Datenebene durchsetzen.
• Observability und Telemetrie. Metriken auf Workload-Ebene, Kapazitäts- und Leistungstrends und zunehmend Stromtelemetrie auf System-, Knoten- und Workload-Ebene. Strom ist zu einer harten Designgrenze geworden, nicht zu einer Fußnote im Finanzbericht.
• Audit und Nachweisführung. Manipulationssichere Logs, unveränderliche Aufbewahrung von Nachweisen und eine kontinuierliche Kontrollüberwachung, die eine behördliche Anfrage ohne dreimonatige forensische Aufarbeitung übersteht.

In der Betriebsebene entscheidet sich auch, ob Teams konsolidieren oder sich zersplittern. Zwei oder drei Speichersysteme plus eine separate Orchestrierungsebene plus eine separate Identitätsebene plus separate Audit-Pipelines sind ein Rezept für Personalbedarf, der linear mit dem Footprint wächst. Die Teams, die vorankommen, konsolidieren auf eine einheitliche Daten- und Betriebsebene.

Warum das Speicherfundament der begrenzende Faktor ist

Die vier Ebenen sind gleich wichtig, aber sie begrenzen einander nicht gleich stark. Compute-Generationen wechseln alle 18 bis 24 Monate. Netzwerk-Refresh-Zyklen dauern drei bis fünf Jahre. Betriebswerkzeuge sind Software und werden laufend überarbeitet. Speicher ist die Ebene, die die Daten eines Jahrzehnts hält, mehrere Compute- und Netzwerk-Refreshes übersteht und jedes neue Workload-Muster aufnimmt, sobald es auftaucht. Kann der Speicher nicht mithalten – kann er den Trainingsdurchsatz nicht halten, die Datenresidenz auf der Datenebene nicht durchsetzen, die Unveränderlichkeit im Audit nicht belegen oder Daten nicht in einem Betriebsmodell über Flash, Festplatte, Band und Archiv staffeln –, muss der Rest des Stacks das ausgleichen. Teams fügen Silos hinzu. Der Einkauf fügt Posten hinzu. Das Audit fügt Feststellungen hinzu. Die Kosten einer falsch konzipierten Speicherebene summieren sich über jede andere Ebene der Architektur. Deshalb beginnt ein Design, das den nächsten Refresh-Zyklus übersteht, bei der Datenebene und arbeitet sich nach außen vor, statt bei der Compute-Ebene zu beginnen und Speicher als nachgelagerte Beschaffung zu behandeln.

Wo Scality ADI in den Stack passt

Scality ADI (Autonomous Data Infrastructure) ist in diesem Bild das Speicherfundament – nicht der gesamte Stack, sondern die Ebene, von der Compute, Netzwerk und Betrieb abhängen. Scality ADI ist eine Dateninfrastruktur für Enterprise-KI, Cyber-Resilienz und souveräne Kontrolle, die autonom und nachhaltig die passenden Speichermedien im Maßstab von mehreren Petabyte bis Exabyte zuordnet. Konkret liefert Scality ADI dem Deployment vier Dinge, die die Speicherebene sonst aus getrennten Systemen bereitstellen müsste:

• GPU-Direct-Leistung für Training und Inferencing mit hohem Durchsatz. S3 over RDMA liefert auf der GPU-Direct-Ebene eine Latenz unter 50 Mikrosekunden und auf der Hot-Ebene einen anhaltenden Durchsatz im Multi-TB/s-Bereich. Für die Compute-Ebene ist der Speicher schnell genug, um den Cluster nicht auszubremsen.
• Temperaturübergreifender Lebenszyklus in einem Betriebsmodell. Vier Ebenen – GPU-Direct-Flash, heiß mit QLC und NL-SSD, warm mit HDD, kalt mit Band und Cloud-naher Archivierung – liegen in einem einzigen Namespace und unter einer einzigen Richtlinien-Engine. Training, Fine-Tuning, Inferencing-Cache, Embeddings, Checkpoints und Langzeitaufbewahrung erhalten jeweils die passende Ebene, ohne dass das Team vier Speichersysteme betreiben muss.
• In die Architektur integrierte CORE5-Cyber-Resilienz. Unveränderlichkeit, Ausfallsicherheit durch Erasure Coding, Metadatenschutz, standortübergreifender Schutz und Richtliniendurchsetzung sind Eigenschaften der Plattform statt nachträglich aufgesetzter Dienste. Audit und Wiederherstellung halten der Prüfung stand, der KI-Workloads heute durch Vorstände, Aufsichtsbehörden und Versicherer ausgesetzt sind.
• Souveräne Kontrolle auf der Datenebene. Scality ADI wird als Open-Code-Software mit langen Supportzeiträumen und geregelten Beiträgen ausgeliefert. Sicherheitsteams von Behörden, Akkreditierungsstellen und Red Teams können prüfen, was die Plattform tut, statt sich auf Herstellerbestätigungen zu verlassen. Die Plattform lässt sich On-Premises, in einer souveränen Region, in einer Private Cloud oder in einer Air-Gap-Umgebung in einem einzigen Betriebsmodell bereitstellen.

Scality ADI ist kein schnellerer Objektspeicher. Es ist ein neues Betriebsmodell für Dateninfrastruktur im KI-Zeitalter – eines, das den Rest des Stacks skalieren lässt, ohne die Speicherebene alle zwei Jahre neu aufzusetzen. Für Infrastrukturverantwortliche, die sich vor einer Designentscheidung einen Überblick über die gesamte Architektur für private KI verschaffen, ist die Datenebene der Teil, der mit der nächsten GPU-Generation nicht neu gebaut wird.

So bietet Scality ADI das Speicherfundament für KI-Workloads im Unternehmen

Häufig gestellte Fragen

Was ist private KI-Infrastruktur?

Sie ist der kombinierte Stack aus Compute, Speicher, Netzwerk und Betrieb, mit dem der KI-Lebenszyklus in einer vom Unternehmen kontrollierten Infrastruktur betrieben wird. Sie umfasst Training, Fine-Tuning, Inferencing, Retrieval-Augmented Generation, Embeddings, Checkpoints, Evaluierung und Langzeitaufbewahrung. Das entscheidende Merkmal: Platzierung, Zugriff, Aufbewahrung und Prüfung werden von der Plattform durchgesetzt, die das Unternehmen betreibt, nicht durch einen Vertrag mit einem Public-Cloud-Anbieter.

Worin unterscheidet sich das von On-Prem-KI-Infrastruktur?

On-Prem-KI-Infrastruktur beschreibt einen Bereitstellungsort. Das private Modell beschreibt eine Kontrolleigenschaft. Ein On-Prem-Deployment ist ein Weg dorthin, doch dieselbe Architektur kann auch in einer akkreditierten Sovereign-Cloud-Region, einer Colocation-Einrichtung oder einer Air-Gap-Umgebung laufen – solange Daten-, Identitäts- und Betriebsebene unter der rechtlichen und betrieblichen Hoheit des Dateneigentümers betrieben werden.

Welche vier Ebenen hat der Stack?

Compute (GPU-Cluster sowie unterstützende CPU- und Management-Hosts), Speicher (Trainingskorpora, Checkpoints, Embeddings, Aufbewahrung, oft vereinheitlicht über S3-kompatiblen Objektspeicher mit temperaturübergreifendem Tiering), Netzwerk (East-West mit InfiniBand oder RoCE im Cluster, North-South zur Datenebene, GPU-Direct-Pfade für anhaltenden Durchsatz) und Betrieb (Orchestrierung, Identität und Richtlinien, Observability, Audit und Nachweisführung).

Warum ist die Speicherebene in der Architektur für private KI so wichtig?

Speicher überdauert jede andere Ebene. Compute-Generationen wechseln alle 18 bis 24 Monate, Netzwerke alle drei bis fünf Jahre, Betriebswerkzeuge laufend. Speicher hält die Trainingsdaten, Checkpoints, Embeddings und Aufbewahrungsbestände eines Jahrzehnts. Kann er den Trainingsdurchsatz nicht halten, die Datenresidenz nicht durchsetzen, die Unveränderlichkeit nicht belegen oder Daten nicht in einem Modell medienübergreifend staffeln, muss der Rest des Stacks das mit mehr Silos, mehr Personal und mehr Audit-Feststellungen ausgleichen.

Wie fügt sich Scality ADI in die Architektur ein?

Scality ADI ist das Speicherfundament des Stacks. Die Plattform bietet GPU-Direct-Durchsatz über S3 over RDMA, einen temperaturübergreifenden Lebenszyklus über Flash, Festplatte, Band und Cloud-nahes Archiv in einem einzigen Namespace, Cyber-Resilienz nach CORE5 auf der Datenebene sowie Open-Code-Prüfbarkeit für souveräne und regulierte Umgebungen. Sie lässt sich On-Premises, in einer souveränen Region, in einer Private Cloud oder in einer Air-Gap-Umgebung in einem einzigen Betriebsmodell bereitstellen.

Weiterführende Artikel

• Leitfaden zu Bereitstellungsmodellen für private KI im Unternehmen
• Architekturüberblick zur KI-Cloud-Infrastruktur
• Komponenten und Design von KI-Compute-Infrastruktur
• Schlüsselkomponenten der KI-Dateninfrastruktur (auf Englisch)
• Tiered Storage für KI: skalierbare Leistung und Kostenkontrolle
• Hybrid-Cloud-Datenstrategie für KI-Workloads
• Souveräner Cloud-Speicher
• Strategie für die Cloud-Repatriierung
• Agentische KI-Speicherinfrastruktur
• Datensouveränität vs. Public Cloud