6 S3-Speicher für KI-Workloads ist keine Beschaffungsentscheidung mehr, sondern eine Selbstverständlichkeit. Trainings-Frameworks erwarten ihn, Vektordatenbanken erwarten ihn, Backup-Ökosysteme erwarten ihn, und die neue Generation agentischer und Retrieval-Pipelines baut auf ihm auf. Die interessante Frage ist nicht, ob S3-kompatibler Speicher für KI genutzt wird, sondern welche Funktionen hinter dem S3-Endpunkt tatsächlich standhalten, wenn produktive KI-Workloads darauf treffen. Dieser Leitfaden erklärt, warum die S3-API zum Standard für KI-Speicher wurde, was KI-Tools tatsächlich von der Speicherebene brauchen und wie Scality ADI (Autonomous Data Infrastructure) S3-Speicher für KI-Workloads über eine Architektur mit vier Ebenen bereitstellt, ohne das Betriebsmodell zu sprengen. Warum die S3-API zum Standard für KI-Speicher wurde Amazon veröffentlichte die S3-API 2006, um unstrukturierte Daten hinter einer einfachen HTTP-Schnittstelle bereitzustellen. Zwanzig Jahre später spricht fast jedes KI-Tool im Unternehmens-Stack sie nativ. Das ist weder Zufall noch Mode. Drei Eigenschaften der S3-API erklären, warum KI-Tools auf sie setzen. Erstens ist der Vertrag klein genug für eine schnelle Integration und umfangreich genug für echte Produktionsanforderungen – PUT, GET, LIST, Multipart-Upload, Object Lock, Lifecycle-Regeln, vorsignierte URLs und ein Metadatenmodell, das die Versionierung übersteht. Zweitens ist die API zustandslos und horizontal skalierbar – passend dazu, wie sich Training und Inferencing auf Tausende von GPU-Prozessen verteilen. Drittens funktioniert sie gleich, ob gegenüber einem Cloud-Bucket, einem On-Premises-Objektspeicher oder einer verwalteten Appliance – ein einmal geschriebenes KI-Tool läuft also gegen jeden kompatiblen Endpunkt. Dieser letzte Punkt macht die S3-API zur Integrationsschicht statt zu einer Funktion. Einem Trainingsskript, das einen Korpus aus S3 liest, ist es egal, welche Plattform am anderen Ende steht. Einem Backup-Produkt, das mit Object Lock nach S3 schreibt, ebenso. Einer RAG-Pipeline, die Chunks und Embeddings aus S3-Buckets abruft, ebenfalls. Der S3-Vertrag ist die gemeinsame Sprache, und der KI-Stack baut darauf auf. Warum KI-Tools auf S3 statt auf File- oder Block-Speicher setzen Die technischen Gründe, warum File- und Block-Speicher bei KI gegen S3 verloren haben, liegen auf der Hand. KI-Workloads überfordern Dateisysteme durch die schiere Zahl der Objekte. Ein bescheidener Trainingskorpus umfasst mehrere Dutzend Millionen Objekte, ein produktiver RAG-Index Hunderte Millionen. Das Durchlaufen von POSIX-Verzeichnissen bricht lange vorher zusammen. Block-Speicher kann einen Datensatz nicht über Tausende von Compute-Knoten teilen, ohne eine Koordinationsschicht, die selbst zum Engpass wird. S3 löst beide Probleme mit einem flachen Namespace, umfangreichen Metadaten und parallelem Zugriff über HTTP. Jedes Objekt ist einzeln adressierbar. Jeder Bucket skaliert horizontal. Gleichzeitige Leser behindern sich nicht gegenseitig, weil keine Sperrsemantik auszuhandeln ist. Für die relevanten KI-Zugriffsmuster – anhaltende parallele Lesezugriffe beim Training, kleine Lesezugriffe mit niedriger Latenz beim Retrieval, große Blöcke für Checkpoints, unveränderliche Schübe für Backups – passt das S3-Modell sauber zum Workload. Die Integration ist die andere Hälfte der Antwort. PyTorch, TensorFlow, JAX, Hugging Face, Ray, MLflow, Weights & Biases, NVIDIA NeMo, LangChain, LlamaIndex, Pinecone, Weaviate, Milvus, Veeam, Commvault, Rubrik, Atempo, Snowflake, Databricks und nahezu jede Lakehouse-Engine bringen native S3-Unterstützung mit. Eine Speicherebene, die den S3-Vertrag einhält, nimmt den gesamten KI-Tool-Stack ohne individuelle Konnektoren auf. Eine Speicherebene, die das nicht tut, muss ersetzt werden, wenn sich die Tools ändern – und die Tools werden sich weiter ändern. Was KI-Workloads tatsächlich von S3-Speicher verlangen Die S3-API ist notwendig, aber nicht hinreichend. Schwieriger ist, was hinter dem Endpunkt liegt. Enterprise-KI bringt fünf unterschiedliche Zugriffsmuster auf dieselbe Speicherebene, und die Plattform muss alle bewältigen, ohne das Team zum Betrieb von fünf getrennten Produkten zu zwingen. Anhaltende Lesezugriffe mit hohem Durchsatz beim Training Trainings-Workloads lesen den Korpus immer wieder. Ein Multi-GPU-Cluster zieht mehrere Gigabyte pro Sekunde und Knoten, verteilt auf Hunderte oder Tausende gleichzeitiger Prozesse. Das Speicher-Fabric muss den anhaltenden Gesamtdurchsatz liefern, nicht nur den Spitzenwert im Benchmark. Sinkt der Durchsatz, laufen GPUs leer – und leerlaufende GPUs sind das teuerste Fehlerbild moderner Infrastruktur. Die Mechanik im Detail beschreiben Speicher für LLM-Trainingsdaten und Speicher für KI-Trainingspipelines. Das Fazit für Speicherarchitekten: Training ist ein Durchsatzproblem, kein Latenzproblem, und die S3-Ebene muss im großen Maßstab mithalten, nicht nur in der Spitze. Kleine Lesezugriffe mit niedriger Latenz beim Retrieval Retrieval-Augmented Generation hat das Profil von KI-Speicher umgekehrt. Eine RAG-Abfrage berührt in Millisekunden einige Hundert bis einige Tausend kleine Objekte. Die Durchsatzwerte sind nach Trainingsmaßstäben bescheiden, doch die Anforderungen an Parallelität und Tail-Latenz sind hoch. Ein Retrieval-Endpunkt, der pro Abfrage eine halbe Sekunde stockt, verliert seinen Gesprächscharakter, und Nutzer merken es sofort. Dieselbe S3-Ebene, die einen Trainingskorpus im Multi-Petabyte-Bereich bedient, muss einen Workload mit kleinen Objekten und hoher Parallelität bedienen, ohne dass einer den anderen beeinträchtigt. Das ist eine andere Art von Skalierung als Benchmark-Durchsatz – und die, die die meisten KI-Deployments unterschätzen. Schreibvorgänge mit großen Blöcken für Checkpoints Modell-Checkpoints kommen in Schüben. Ein Foundation-Modell-Lauf schreibt Hunderte Gigabyte pro Checkpoint, oft in festen Intervallen. Der Schreibpfad muss den Schub aufnehmen, ohne Rückstau auf die GPU-Ebene zu erzeugen. Lesezugriffe sind selten, aber unverzichtbar, wenn sie anfallen – ein Rollback, eine erneute Bereitstellung oder eine behördliche Anfrage kann jederzeit jede Version verlangen. Unveränderliche Aufbewahrung für Backups und Audit-Nachweise Backup- und Audit-Workloads nutzen denselben S3-Endpunkt, wenn die Plattform richtig konzipiert ist. S3 Object Lock bietet eine ransomwareresistente Unveränderlichkeit, mit der das Backup-Ökosystem bereits umzugehen weiß. Veeam, Commvault, Rubrik und Atempo schreiben alle nativ mit Object Lock nach S3. KI-Umgebungen, die Backup- und Primär-Workloads in einem S3-Namespace konsolidieren, zahlen keine Integrationssteuer mehr an der Schnittstelle zwischen beiden. Kostenbewusste Aufbewahrung über Jahre Das letzte Zugriffsmuster ist das langlebigste. Reproduzierbarkeitspflichten, regulatorische Aufbewahrung und Nachweise zur Forschungsherkunft verlängern die Aufbewahrung über die Betriebsdauer des Modells hinaus. Der richtige Ort ist die günstigste Ebene, die das Unternehmen verantwortungsvoll nutzen kann – meist Band oder Cloud-nahe Archivierung –, erreichbar über dieselbe S3-API wie die aktiven Ebenen. Die Lifecycle-Richtlinie, die Daten von heiß nach kalt verschiebt, muss innerhalb der Plattform laufen, nicht als manuelle Übergabe zwischen Anbietern. Was „S3-kompatibel“ für KI wirklich bedeuten sollte S3-Kompatibilität ist am Markt sehr unterschiedlich ausgeprägt. Eine Plattform, die PUT und GET beherrscht, ist nicht dasselbe wie eine Plattform, die Multipart-Uploads in Terabyte-Größe, Object Lock unter behördlicher Prüfung, Lifecycle-Richtlinien über Ebenen im Petabyte-Maßstab und konsistentes Metadatenverhalten bei Ausfällen beherrscht. KI-Workloads finden die Lücken schnell. Der Kompatibilitätstest für Enterprise-KI lautet nicht „spricht sie S3?“, sondern ob die Plattform vier Dinge zusammen liefert: Vollständige S3-Semantik unter Last. Multipart, Range-Reads, Object Lock, Lifecycle, Versionierung und Metadatenoperationen verhalten sich im Petabyte-Maßstab genauso wie im Gigabyte-Maßstab. Leistung im großen Maßstab, nicht nur in der Spitze. Anhaltender Durchsatz und Tail-Latenz halten im Produktivbetrieb des Clusters stand, nicht nur während eines Benchmark-Fensters. Lifecycle über Medienebenen hinweg unter einer API. Heiße, warme, kalte und archivierte Daten liegen alle hinter demselben S3-Endpunkt, mit richtliniengesteuerter Verschiebung zwischen ihnen. Integrierte statt nachgerüstete Cyber-Resilienz. Unveränderlichkeit, Ausfallsicherheit, standortübergreifender Schutz und Audit-Nachweise sind Eigenschaften der Plattform statt Funktionen, die integriert werden müssen. Eine Plattform, die drei der vier liefert, erzeugt irgendwo eine betriebliche Bruchstelle. KI-Umgebungen finden diese Bruchstelle – und zwar unter Last. Zugriffsmuster hinter einem S3-Endpunkt im Vergleich Zugriffsmuster Objektgröße Profil Speicherebene Lesezugriffe beim Training KB to MB Parallel mit hohem Durchsatz GPU-Direct oder Hot RAG-Retrieval KB Kleine Lesezugriffe mit niedriger Latenz Hot Checkpoint-Schreibvorgänge Hunderte MB bis GB Große Schreibvorgänge in Schüben Hot oder Warm Backup-Ingest MB to GB Schreiblastige Schübe, unveränderlich Warm Archivaufbewahrung KB to GB Seltener Zugriff, dauerhaft Cold Genau diese Vielfalt ist der Punkt. Kein einzelnes Leistungsprofil passt zu allen fünf, doch alle sprechen S3. Die Aufgabe der Plattform ist es, alle fünf hinter einem Endpunkt aufzunehmen und jedes per Richtlinie auf das richtige Medium zu leiten. Wie Scality ADI S3-Speicher für KI-Workloads bereitstellt Scality ADI (Autonomous Data Infrastructure) 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. Sie ist auf die oben beschriebenen Anforderungen an KI-Speicher ausgelegt – vollständige S3-Semantik, anhaltende Leistung im großen Maßstab, Lifecycle über Ebenen hinweg und Cyber-Resilienz als Eigenschaft der Plattform. Vier Ebenen hinter einem S3-Endpunkt. Scality ADI stellt vier Medienebenen in einem einzigen S3-kompatiblen Namespace bereit. Eine GPU-Direct-Ebene auf TLC-Flash mit S3 over RDMA liefert eine Latenz unter 50 Mikrosekunden für die anspruchsvollsten Trainings- und Inferencing-Pfade. Eine Hot-Ebene auf QLC oder NL-SSD bietet einen Durchsatz von mehreren Terabyte pro Sekunde für umfangreiche Trainingslesezugriffe und aktives RAG-Retrieval. Eine Warm-Ebene auf NL-SSD, NL-HDD oder HDD übernimmt Arbeitsdaten und aktuelle Backups. Eine Cold-Ebene auf Band und Cloud-naher Archivierung hält die Langzeitaufbewahrung. Dieselbe S3-API adressiert jede Ebene; Richtlinien verschieben die Daten zwischen ihnen. Das übergreifende Designmuster beschreibt der Beitrag zu Tiered Storage für KI. GPU-Direct-Leistung über S3. S3 over RDMA schließt die Lücke zwischen der Wirtschaftlichkeit von S3 und der Auslastung von GPUs. Die GPU-Direct-Ebene hält den Durchsatz im großen Maßstab statt nur in der Benchmark-Spitze – und genau das hält Trainings- und Inferencing-Cluster mit mehreren Knoten produktiv. Die Mechanik erläutert der Beitrag zu GPU-Direct Storage. Vollständige S3-Semantik unter Unternehmenslast. Multipart-Uploads, Object Lock, Lifecycle-Regeln, Versionierung und Metadatenoperationen verhalten sich vom Gigabyte- bis zum Exabyte-Maßstab konsistent. Backup-Ökosysteme – Veeam, Commvault, Rubrik, Atempo – landen ohne separates Gateway im selben Namespace. Die Kompatibilität im Detail beschreibt der Beitrag zur S3-API-Kompatibilität. CORE5-Cyber-Resilienz als Eigenschaft der Plattform. Unveränderlichkeit, Ausfallsicherheit durch Erasure Coding, Metadatenschutz, standortübergreifender Schutz und richtliniengesteuerter Lebenszyklus sind in Scality ADI integriert, statt pro Workload konfiguriert zu werden. Trainingskorpora erben dasselbe Schutzmodell wie Backups. Modellartefakte erben dieselben Audit-Nachweise wie archivierte Datensätze. Durch die Integration mit Backup-Ökosystemen wird die Wiederherstellungsfähigkeit zu einer einzigen Eigenschaft der Plattform statt zu einer Aufgabe pro Anbieter. Autonomer Betrieb innerhalb von Richtlinien. Die Guardian-Agenten von Scality ADI beobachten Zugriffsmuster, liefern Empfehlungen zu Ebenenplatzierung und Lifecycle und führen freigegebene Maßnahmen innerhalb kundendefinierter Richtlinien aus. Die Plattform reagiert auf Änderungen im Workload-Mix – eine neue Fine-Tuning-Kampagne, eine Aktualisierung der RAG-Wissensbasis, ein verschobenes Backup-Fenster – ohne manuelle Koordination durch Administratoren. Keine Blackbox, kein Autopilot: operative Intelligenz mit begrenzter Ausführung und vollständigem Audit-Trail. Stromtelemetrie auf Workload-Ebene. Scality ADI legt den Stromverbrauch pro System, pro Knoten und pro Workload offen. Da Strom im KI-Maßstab zu einer harten Designgrenze wird, macht diese Telemetrie aus Nachhaltigkeitsberichten eine Messung statt einer Modellrechnung und liefert dem Betrieb die Daten für Platzierungsentscheidungen, die der Einkauf vertreten kann. Der Punkt ist nicht, dass Scality ADI ein schnellerer Objektspeicher ist. Der Punkt ist, dass S3-Speicher für KI-Workloads nicht mehr aus fünf getrennten Produkten besteht, die von Integrationsskripten zusammengehalten werden, sondern zu einer Plattform mit einem stimmigen Betriebsmodell wird. Genau diesen Wandel verlangt das KI-Zeitalter. So bietet Scality ADI eine vollständige S3-kompatible Plattform für Enterprise-KI Häufig gestellte Fragen Warum ist die S3-API der Standard für KI-Speicher? Aus drei Gründen. Der API-Vertrag ist einfach genug für eine schnelle Integration und umfangreich genug für Produktionsanforderungen (Multipart, Object Lock, Lifecycle, Versionierung). Das Modell ist zustandslos und horizontal skalierbar – passend dazu, wie sich KI-Workloads auf Tausende von GPU-Prozessen verteilen. Und nahezu jedes KI-Tool – Trainings-Frameworks, Vektordatenbanken, Backup-Ökosysteme, Lakehouse-Engines – bringt native S3-Unterstützung mit, was die API zur Integrationsschicht statt zu einer Funktion macht. Ist S3-Speicher schnell genug für GPU-Direct-KI-Workloads? Ja, wenn die Plattform S3 over RDMA unterstützt. Die GPU-Direct-Ebene von Scality ADI liefert über S3 eine Latenz unter 50 Mikrosekunden, indem sie TLC-Flash-Medien mit RDMA-fähigen Datenpfaden kombiniert. Das Ergebnis ist die Wirtschaftlichkeit von S3 mit dem Zugriffsmuster, das GPUs tatsächlich brauchen – ohne jeden Workload auf ein separates Dateisystem zu zwingen. Kann eine S3-Plattform Trainingsdaten, RAG und Backups gemeinsam bedienen? Ja – und ihre Konsolidierung ist eines der stärksten TCO-Argumente für einheitlichen S3-Speicher für KI-Workloads. Jedes Zugriffsprofil ist anders – anhaltende Lesezugriffe beim Training, kleine Lesezugriffe mit niedriger Latenz bei RAG, unveränderliche Schübe bei Backups –, doch die zugrunde liegende S3-Semantik ist dieselbe. Eine Plattform wie Scality ADI bedient alle drei in einem Namespace, mit Lifecycle-Richtlinien, die Daten ohne Anbieterwechsel durch die Ebenen bewegen. Was bedeutet „S3-kompatibel“ für Enterprise-KI wirklich? Die sinnvolle Definition: Die Plattform liefert vollständige S3-Semantik unter Last – Multipart-Uploads in Terabyte-Größe, Object Lock unter behördlicher Prüfung, Lifecycle-Richtlinien über Ebenen im Petabyte-Maßstab, konsistentes Metadatenverhalten bei Ausfällen – und hält die Leistung im großen Maßstab statt nur in der Benchmark-Spitze. Eine Plattform, die PUT und GET beherrscht, ist nicht dasselbe. Wie bewältigt S3-Speicher den KI-Lebenszyklus vom Training bis zum Archiv? Mit gestaffelten Medien hinter einem S3-Endpunkt. Heiße Daten liegen für Training und RAG auf Flash. Warme Daten liegen für Arbeitsdaten und aktuelle Backups auf HDD. Kalte Daten liegen für die Langzeitaufbewahrung auf Band oder in Cloud-naher Archivierung. Lifecycle-Richtlinien verschieben Daten unter derselben API zwischen den Ebenen, sodass sich die Anwendung mit dem Altern der Daten nicht ändert. Das ist das Betriebsmodell hinter dem Design von Scality ADI mit vier Ebenen. Fazit S3-Speicher für KI-Workloads ist die Annahme, von der heute jedes KI-Tool ausgeht. Die Frage für Unternehmensarchitekten ist nicht, ob sie ihn einführen – diese Entscheidung hat das Tool-Ökosystem bereits getroffen –, sondern was sie von der Plattform hinter dem S3-Endpunkt verlangen. Die fünf oben beschriebenen Zugriffsmuster sind der eigentliche Test. Eine Plattform, die alle fünf bewältigt, ohne neue Silos zu schaffen, verdient den Namen Plattform; eine, die drei davon bewältigt, wird irgendwo betrieblichen Mehraufwand verursachen. Der richtige Test für S3-Speicher für KI-Workloads ist nicht, was er in einem Benchmark zeigen kann. Entscheidend ist, ob derselbe S3-Endpunkt auch in drei Jahren noch sinnvoll ist – wenn sich die Modellarchitekturen geändert haben, die RAG-Wissensbasis sich verdreifacht hat, die Backup-Aufbewahrung länger ist und das Archiv um eine Größenordnung gewachsen ist. Die Plattformen, die über diese Zeitspanne bestehen, sind die, die um das Betriebsmodell herum gebaut sind, nicht um das Datenblatt. Weiterführende Artikel S3-API-Kompatibilität Speicher für LLM-Trainingsdaten Speicher für KI-Trainingspipelines GPU-Direct Storage Tiered Storage für KI: skalierbare Leistung und Kostenkontrolle KI-Datenpipelines Enterprise-Backup (auf Englisch) Scality ADI: KI-Dateninfrastruktur
