6 Die meisten Unternehmen bauen On-Prem-KI-Infrastruktur nicht auf, um ein Zeichen zu setzen. Sie tun es, weil der Trainingskorpus zu sensibel ist, um ihn in einen ausländischen Mandanten zu verlagern, weil die Egress-Kosten eines einzigen Retraining-Durchlaufs höher sind als ein Jahr eigener Kapazität oder weil die Aufsichtsbehörde verlangt, dass die Datenebene unter einer einzigen Rechtsordnung betrieben wird. Die Frage lautet dann nicht mehr, ob KI-Workloads im eigenen Haus bleiben, sondern wie Speicher-, Netzwerk- und Betriebsebene zu gestalten sind, damit ein KI-Programm im Multi-Petabyte-Bereich im GPU-Tempo läuft, ohne Datenresidenz, Wiederherstellbarkeit oder Kostendisziplin zu gefährden. Dieser Leitfaden richtet sich an Infrastrukturverantwortliche, Leiter von KI-Infrastruktur und Speicherarchitekten, die ein On-Prem-KI-Programm planen oder ausbauen. Er behandelt die Ebenen, die ein tragfähiges Design braucht, die Vorteile, die die Investition von optional zu offensichtlich machen, und die Rahmenbedingungen, die bestimmen, wo die Grenze zwischen On-Prem und allem anderen verläuft. Was ist On-Prem-KI-Infrastruktur? On-Prem-KI-Infrastruktur umfasst die Compute-, Speicher-, Netzwerk-, Identitäts- und Betriebsebenen, die den KI-Lebenszyklus – Ingestion, Aufbereitung, Training, Fine-Tuning, Inferencing, Retrieval, Checkpoints und Langzeitaufbewahrung – in Einrichtungen betreiben, die das Unternehmen selbst betreibt. Das entscheidende Merkmal: Platzierung, Zugriff, Aufbewahrung und Prüfung regulierter Daten werden von Infrastruktur durchgesetzt, die das Unternehmen kontrolliert, nicht durch einen Vertrag mit einem Public-Cloud-Anbieter. Die Kategorie ist enger als „private KI“ – die auch Sovereign-Cloud- und Air-Gap-Varianten umfassen kann –, aber breiter als ein einzelner GPU-Cluster. Ein tragfähiges On-Prem-KI-Design muss den gesamten Lebenszyklus unterstützen, nicht nur den prestigeträchtigen Trainingslauf. Drei Eigenschaften unterscheiden ein echtes Design von einer umbenannten GPU-Farm: Bandbreite der Workloads. Es muss GPU-Direct-Training, Inferencing mit hoher Parallelität, RAG- und Embedding-Pipelines, Modell-Checkpoints und jahrzehntelange Aufbewahrung über eine einzige Betriebsebene bedienen. Kontrolle auf der Datenebene. Datenresidenz, identitätsgebundener Zugriff, Mandantenisolation und Unveränderlichkeit sind Eigenschaften der Speicherplattform, keine Behauptungen auf Richtlinienfolien. Unabhängige Skalierung. Compute und Speicher müssen in ihrem eigenen Takt skalieren. KI-Workloads wachsen in beiden Dimensionen, aber selten im gleichen Tempo. Fehlt eine dieser Eigenschaften, stößt das Design an seine Grenzen, sobald sich der Workload-Mix zum ersten Mal ändert – und das tut er immer. Die Designebenen Ein tragfähiges On-Prem-KI-Design hat fünf Ebenen. Sie sind nicht unabhängig voneinander – jede schränkt die darüber- und darunterliegenden ein –, lassen sich aber einzeln leichter durchdenken. 1. Compute-Ebene Die Compute-Ebene ist der GPU- und CPU-Rahmen. Für das Training ist das der dichte GPU-Cluster – Beschleuniger der H- oder B-Klasse, verbunden über ein Fabric mit hoher Bandbreite. Für das Inferencing ist es eine Mischung aus GPU- und CPU-Knoten, dimensioniert für Parallelität und Latenz statt für Spitzendurchsatz. Die Trennung ist wichtig, weil Training und Inferencing selten dasselbe Hardwareprofil haben – wer beide auf einen Cluster zwingt, verschwendet auf beiden Seiten Kapazität. Die Compute-Ebene definiert auch das Energiebudget. Moderne Trainingsknoten ziehen so viel Strom, dass die Standortplanung – Racks, Kühlung, PDU-Kapazität – von der ersten Skizze an Teil des Designs ist und keine Fußnote am Ende. 2. Speicherebene In der Speicherebene liegt der größte Teil der betrieblichen Herausforderungen. KI-Workloads haben kein einheitliches Zugriffsmuster. Training liest große Objekte sequenziell mit extremem Durchsatz. Inferencing liest kleine Objekte zufällig bei hoher Parallelität. Embeddings, Retrieval und KV-Cache verhalten sich jeweils wieder anders. Checkpoints schreiben in Schüben. Langzeitaufbewahrung liegt jahrelang kalt. Ein tragfähiges Speicherdesign nutzt gestaffelte Medien in einem einzigen Betriebsmodell: GPU-Direct-Flash für aktive Trainingsdatensätze, Modell-Checkpoints während eines Laufs und KV-Cache für das Inferencing. Latenz im Submillisekundenbereich, auch im großen Maßstab. Heiße Kapazität (QLC, NL-SSD) für Arbeitsdatensätze, aktuelle Inferencing-Logs und Embedding-Indizes – hoher Durchsatz, geringere Kosten pro Terabyte als Premium-Flash. Warme Kapazität (NL-HDD, HDD) für den breiteren Data Lake, historische Trainingskorpora und die jüngere Aufbewahrung. Kalte Archivierung (Band, Cloud-nahe Archivierung) für die Compliance-Aufbewahrung, ausgemusterte Modelle und Kopien für die Notfallwiederherstellung. Entscheidend ist, dass alle vier Ebenen in einem Namespace und unter einer Richtlinien-Engine liegen. Andernfalls betreibt das Team am Ende vier Speichersysteme und schreibt Migrationsskripte zwischen ihnen – genau der Betriebsaufwand, den die Plattform eigentlich beseitigen soll. 3. Netzwerkebene Die Netzwerkebene eines On-Prem-KI-Designs besteht aus zwei Netzwerken, nicht aus einem. Das East-West-Fabric – meist InfiniBand oder Hochgeschwindigkeits-Ethernet – transportiert den Datenverkehr zwischen GPUs sowie zwischen GPU und Speicher mit der Bandbreite, die modernes Training verlangt. Das North-South-Netzwerk übernimmt Ingestion, Replikation an Aufbewahrungsstandorte, Identitätsverkehr und Betriebstelemetrie. Wer beides auf einem Fabric zusammenlegt, spart Verkabelung und verliert Durchsatz. Bei GPU-Direct-Workloads ist der Pfad vom Speicher zur GPU der Engpass. S3 over RDMA, GPUDirect Storage und ähnliche Zero-Copy-Pfade gibt es, um den Umweg über Host-CPU und DRAM aus dem Datenpfad zu entfernen. Wie diese Ebene typischerweise aufgebaut wird, erläutert der Beitrag zu GPU-Direct Storage im Detail. 4. Identitäts-, Zugriffs- und Audit-Ebene KI-Workloads in regulierten Umgebungen verlangen identitätsgebundenen Zugriff auf der Datenebene: Jeder Lese- und Schreibvorgang und jedes Lifecycle-Ereignis ist an eine authentifizierte Identität gebunden und in einer manipulationssicheren Audit-Kette erfasst. Hier zeigt sich der Unterschied zwischen einem generischen On-Prem-Cluster und einem Design für regulierte Umgebungen. Die Audit-Kette muss betriebliche Belastungen überstehen – Trainingsjobs, die das Fabric auslasten, Inferencing-Spitzen, die die Parallelität verzehnfachen, standortübergreifende Replikation, die nach einem Netzwerkereignis aufholt. Audit-Lücken unter Last sind der Grund, warum Akkreditierungsprüfungen scheitern. 5. Betriebsebene Die Betriebsebene ist das, was das Team tatsächlich jeden Tag nutzt: Bereitstellung, Monitoring, Lifecycle-Management, Kapazitätsplanung, Selbstheilung, Upgrades, Erweiterung. Das Designziel: Das Team, das die Umgebung betreibt, wächst nicht linear mit dem Footprint. Dafür braucht es richtliniengesteuerte Automatisierung, workload-bezogene Erkenntnisse und eine Laufzeitumgebung, die Refresh-Zyklen ohne Komplettaustausch bewältigt. Die wichtigsten Vorteile Das wirtschaftliche und betriebliche Argument dafür, KI-Workloads im eigenen Haus zu betreiben, beruht auf vier Vorteilen. Jeder davon ist konkret genug, um ihn zu modellieren – und genau das unterscheidet sie von pauschalen Aussagen wie „die Cloud ist teuer“. Souveränität und nachweisbare Kontrolle Souveränität ist der Vorteil, der den Eigenbetrieb für immer mehr Workloads unverzichtbar macht. Sind Datensätze eingestuft, reguliert oder vertraglichen Residenzregeln unterworfen, lässt sich Kontrolle nur nachweisen, indem die Datenebene innerhalb der eigenen rechtlichen und betrieblichen Grenzen des Unternehmens betrieben wird. Residenzzusagen von Public-Cloud-Anbietern halten dem Test einer Offenlegungsanordnung für Organisationen, die extraterritorialen Regelungen unterliegen, nicht stand. Der Vorteil besteht nicht nur darin, dass „die Daten im Land bleiben“. Platzierung, Zugriff, Aufbewahrung und Prüfung werden im Code durchgesetzt statt in Verträgen zugesichert. Das tiefere rechtliche und architektonische Bild zeichnen Datensouveränität in der Cloud und souveräner Cloud-Speicher ausführlich. Planbare Kosten bei dauerhaftem Betrieb im großen Maßstab Stundenbasierte Public-Cloud-Preise sind für kurze Experimente attraktiv und versagen bei dauerhaften KI-Workloads. Drei Kostenpositionen summieren sich: Premium-Speicher, Egress und Reserved-Instance-Verpflichtungen, die günstiger wirken als On-Demand, aber Kapazität binden, auf der der Workload womöglich nicht bleibt. Sobald die aktiven Trainingsdaten zwei bis drei Petabyte überschreiten – oder der Workload so kontinuierlich läuft, dass reservierte Kapazität die Stundenpreise schlägt –, kippt die Wirtschaftlichkeit. Der Beitrag zur Strategie für die Cloud-Repatriierung beschreibt diesen Wendepunkt ausführlicher. Eigene Infrastruktur ersetzt das variable Kostenmodell durch einen planbaren Investitionsplan. Der Vorteil sind nicht immer niedrigere Gesamtkosten im ersten Jahr, sondern eine Kostenkurve, die sich mit dem Wachstum des Programms nicht in die falsche Richtung biegt. Vorteil durch Data Gravity Daten im Petabyte-Maßstab lassen sich nicht einfach verschieben. Liegt der Trainingskorpus bereits im Unternehmen – Telemetrie aus Industriesystemen, Schadensdaten, Bildarchive, Transaktionshistorie –, läuft die kosteneffiziente KI-Bereitstellung dort, wo die Daten sind, nicht dort, wo sich GPUs am einfachsten mieten lassen. Multi-Petabyte-Datensätze ständig in eine Public Cloud und zurück zu transferieren, ist das Design, das ein gesundes KI-Programm in eine wiederkehrende Egress-Rechnung verwandelt. Der Beitrag zum Data-Gravity-Problem beschreibt diese Dynamik im Detail. Der Vorteil ist eine Frage der Position. Compute direkt neben den Daten, die das Programm ohnehin erzeugt, eliminiert eine ganze Kategorie von Kosten und Risiken, die keine noch so gute Cloud-Architektur vollständig neutralisieren kann. Betriebliche Kontrolle ohne Vendor-Lock-in Der vierte Vorteil ist schwerer zu modellieren, zeigt sich aber jedes Mal, wenn sich das Programm verändern muss. Eine Plattform auf Basis offener Standards – S3-kompatibler Objektspeicher, offene Compute-Hardware, Standard-Identitätsprotokolle – ermöglicht es dem Unternehmen, Hardware zu erneuern, Betriebswerkzeuge auszutauschen und neue Beschleunigergenerationen einzuführen, ohne die Datenebene neu aufzusetzen. KI-Dienste aus der Public Cloud binden die Datenebene an die APIs, Formate und Vertragsbedingungen eines Anbieters. Die Wechselkosten steigen mit jedem Terabyte angesammelter Trainingsdaten. Der Vorteil ist Bewegungsfreiheit in einem langen, schnelllebigen Hardwarezyklus. Rahmenbedingungen, die das Design prägen Fünf Rahmenbedingungen bestimmen, wie das Design in der Praxis aussieht. Workload-Mix. Ein Programm mit 90 % Training und 10 % Inferencing wird anders gestaltet als eines mit 30 % Training, 50 % Inferencing und 20 % RAG. Die Mischung der Speicherebenen und das Netzwerk-Fabric folgen der Form der Workloads. Datenresidenz. Wo die Daten rechtlich liegen müssen, wer darauf zugreifen darf und welches Recht gilt, sind zentrale Designvorgaben. Unternehmen mit mehreren Regionen betreiben oft ein standortübergreifendes Deployment mit regionaler Autonomie unter einer einheitlichen Betriebssicht. Energiebudget. Moderne GPU-Dichte ist ein Problem der Standortplanung, bevor sie ein Beschaffungsproblem ist. Gesamtleistung, Kühlkapazität und PDU-Layout bestimmen, wie viel Beschleunigerkapazität sich in einem Raum einsetzen lässt. Realistische Refresh-Zyklen. GPU-Generationen wechseln alle 12 bis 24 Monate. Speichergenerationen wechseln langsamer. Das Design sollte es dem Team ermöglichen, Compute zu erneuern, ohne den Speicher zu erneuern, und umgekehrt. Disaggregierte Architekturen – siehe verteilter Objektspeicher – sind der übliche Weg dahin. Personalbedarf im Betrieb. Die meisten Unternehmen, die eine solche Plattform aufbauen, können das Personal nicht linear mit dem Footprint aufstocken. Automatisierung, richtliniengesteuerter Lebenszyklus und eine Laufzeitumgebung, die betriebliche Erkenntnisse liefert statt rohe Telemetrie abzuladen, machen den Unterschied zwischen einem Team, das skaliert, und einem, das untergeht. Warum das auf eine autonome Dateninfrastruktur hinausläuft Ein On-Prem-KI-Deployment beansprucht jede Ebene im Maschinentempo und unter Workload-Bedingungen, die sich ohne Vorwarnung ändern. Drei Eigenschaften müssen gleichzeitig erfüllt sein: Leistung im großen Maßstab – schnell genug, um GPUs beim Training und beim Inferencing mit hoher Parallelität nicht auszubremsen, wobei jedes Objekt auf dem für sein Zugriffsmuster passenden Medium liegt. Kontrolle auf der Datenebene – Platzierung, Zugriff, Aufbewahrung und Grenzen für Betreiber werden von der Plattform durchgesetzt, nicht in einem Runbook behauptet. Betriebliche Wirtschaftlichkeit – das Team, das die Plattform betreibt, wächst nicht linear mit der Zahl der Petabytes oder der Vielfalt der Workloads. Klassische Speicherarchitekturen beherrschen eine oder zwei dieser Eigenschaften und scheitern an der dritten. Eine autonomere Dateninfrastruktur – bei der die Speicherschicht die Platzierung durchsetzt, betriebliche Erkenntnisse innerhalb von Richtlinien liefert und jedem Workload ohne manuelle Eingriffe das richtige Medium zuordnet – macht alle drei zusammen möglich. Scality ADI (Autonomous Data Infrastructure) baut genau auf diesem Prinzip auf, mit Sovereign Control als zentraler Säule für On-Prem-KI-Workloads. Wie Scality ADI hier ansetzt 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. Die Plattform lässt sich On-Premises, in einer souveränen Region, in einer Private Cloud oder in einer Air-Gap-Umgebung bereitstellen – und bietet über alle hinweg einen einzigen Namespace. Konkret für die oben beschriebenen Designebenen: Speicherebene. Scality ADI umfasst vier Ebenen – GPU-Direct-Flash mit S3 over RDMA, heiße Ebene mit QLC und NL-SSD, warme Ebene mit HDD sowie kalte Ebene mit Band und Cloud-naher Archivierung – in einem einzigen Betriebsmodell. Training, Fine-Tuning, Inferencing-Cache, Embeddings, Checkpoints und Langzeitaufbewahrung erhalten jeweils die Ebene, die sie brauchen, ohne dass das Team vier getrennte Speichersysteme betreiben muss. Abstimmung von Compute und Netzwerk. Scality ADI läuft auf der disaggregierten RING10-Architektur, die Kapazität, Durchsatz und Operationen unabhängig voneinander skaliert. GPU-Direct-Workloads nutzen S3 over RDMA mit einer Latenz unter 50 Mikrosekunden auf der GPU-Direct-Ebene und einem Durchsatz im Multi-TB/s-Bereich auf der Hot-Ebene. Identität, Zugriff und Audit. CORE5 sorgt mit Cyber-Resilienz – Unveränderlichkeit, Ausfallsicherheit durch Erasure Coding, Metadatenschutz, standortübergreifender Schutz und Richtliniendurchsetzung – dafür, dass Aufbewahrung und Audit einer genauen Prüfung standhalten. Für die sensibelsten Umgebungen wird der Air-Gap-Betrieb unterstützt. Betriebsebene. Guardian stellt mit seinen Agenten workload-orientierte betriebliche Erkenntnisse und Empfehlungen innerhalb kundendefinierter Richtlinien bereit. Das Team entscheidet, worauf reagiert wird; die Plattform führt innerhalb festgelegter Grenzen aus. Der Nutzen zeigt sich in weniger repetitiven Aufgaben und weniger störenden Wartungseinsätzen – nicht in einer Blackbox, die ohne Aufsicht läuft. Scality ADI wird als Open-Code-Software bereitgestellt – als Software-Appliance oder als Managed Service. Offener Code ist in regulierten Umgebungen wichtig: Sicherheitsteams von Behörden, Akkreditierungsstellen und Red Teams können prüfen, was die Plattform tut, statt sich auf Herstellerbestätigungen zu verlassen. Scality bietet Unternehmen und souveränen Organisationen einen Weg zu KI-Leistung im großen Maßstab, ohne auf Kontrolle, Resilienz oder langfristige wirtschaftliche Disziplin zu verzichten. Für Infrastrukturverantwortliche, die ein Programm planen, das den nächsten Refresh-Zyklus überstehen muss, ist eine einheitliche Datenebene der Teil, der nicht alle zwei Jahre neu aufgesetzt werden muss. So liefert Scality ADI On-Prem-KI-Infrastruktur im großen Maßstab Häufig gestellte Fragen Was ist On-Prem-KI-Infrastruktur? On-Prem-KI-Infrastruktur umfasst die Compute-, Speicher-, Netzwerk-, Identitäts- und Betriebsebenen, die den KI-Lebenszyklus in Einrichtungen betreiben, die das Unternehmen selbst betreibt. Sie setzt Platzierung, Zugriff, Aufbewahrung und Prüfung regulierter Daten auf der Datenebene durch, unterstützt Trainings- und Inferencing-Workloads im GPU-Tempo und skaliert Kapazität und Compute unabhängig voneinander, während das Programm wächst. Was sind die wichtigsten Vorteile? Vier Vorteile tragen das Argument: nachweisbare Souveränität und Kontrolle über die Datenebene, planbare Kosten im großen Maßstab, sobald der Workload kontinuierlich läuft oder der Datensatz in den Multi-Petabyte-Bereich wächst, der Vorteil durch Data Gravity, wenn Trainingskorpora bereits im Unternehmen liegen, sowie betriebliche Bewegungsfreiheit über Hardware-Refresh-Zyklen hinweg ohne Vendor-Lock-in. Wann ist On-Prem für KI sinnvoller als die Public Cloud? On-Prem setzt sich typischerweise durch, wenn die aktiven Trainingsdaten zwei bis drei Petabyte übersteigen, wenn Egress-Gebühren zu einer wesentlichen Kostenposition werden, wenn Einstufungs- oder Residenzanforderungen eine gemeinsame Mandantennutzung ausschließen oder wenn der Workload so kontinuierlich läuft, dass reservierte Kapazität die Stundenpreise schlägt. Air-Gap-Varianten kommen für die sensibelsten eingestuften oder regulierten Umgebungen infrage. Worin unterscheidet sich das von einer Private Cloud? Private Cloud bezeichnet ein Nutzungsmodell – mandantenfähig, Self-Service, API-gesteuert –, das On-Prem oder in einer souveränen Region laufen kann. On-Prem bezeichnet hier dagegen, wo der Workload physisch läuft. Beides überschneidet sich: Viele On-Prem-Deployments werden als Private Cloud betrieben, doch On-Prem-Designs eignen sich auch für Single-Tenant-, eingestufte oder Air-Gap-Konfigurationen, die gar nicht wie eine Private Cloud aussehen. Welche Rolle spielt Scality ADI? Scality ADI liefert die Datenebene: einen einzigen Namespace über GPU-Direct-Flash, heiße Kapazität, warme Kapazität und kalte Archivierung, mit richtlinienbasierter Platzierung, S3 over RDMA für GPU-Workloads, CORE5-Cyber-Resilienz für Aufbewahrung und Wiederherstellung sowie betrieblichen Erkenntnissen von Guardian innerhalb kundendefinierter Richtlinien. Die Plattform lässt sich On-Premises oder mit Air Gap bereitstellen, skaliert auf der RING10-Architektur von wenigen Knoten bis in den Exabyte-Bereich und wird als Open-Code-Software ausgeliefert, damit sie in regulierten Umgebungen geprüft werden kann. Weiterführende Artikel Bereitstellungsmodelle für private KI im Unternehmen: ein Praxisleitfaden KI-Bereitstellungsarchitektur: Modelle und Muster (auf Englisch) Die besten On-Premises-Objektspeicher On-Premise vs. Off-Premise Strategie für die Cloud-Repatriierung Das Data-Gravity-Problem GPU-Direct Storage Souveräner Cloud-Speicher Datensouveränität in der Cloud Hybrid-Cloud-Datenstrategie für KI-Workloads Verteilter Objektspeicher
