6 Machine-Learning-Teams brauchen enorme Speicherkapazitäten. Trainingsdatensätze für große Sprachmodelle umfassen Terabytes. Modell-Checkpoints sammeln sich über die Trainingsiterationen rasch an. Feature Stores halten historische Daten über Monate oder Jahre vor. Lässt die Performance nach und müssen Sie mit Daten von vor neun Monaten nachtrainieren, sollten Sie diese vollständig und unverändert gespeichert haben. Dieses explosive Wachstum führt zu einer überraschenden Kostenlage: Die Speicherkosten für KI übersteigen oft die Rechenkosten. Unternehmen geben Hunderttausende für GPUs aus und stellen fest, dass ihre Speichersysteme sie ebenso stark einschränken. Wer die Gesamtbetriebskosten von Speicher (auf Englisch) kennt, kann ML-Initiativen realistisch budgetieren. Hier kommt die Deduplizierung ins Spiel: Sie verringert den Speicherbedarf, indem sie redundante Daten beseitigt. Der Nutzen der Deduplizierung schwankt jedoch je nach Art der ML-Daten stark. Trainingsdatensätze für Sprachmodelle lassen sich vielleicht im Verhältnis 2:1 deduplizieren, Modell-Checkpoints womöglich 10:1. Manche ML-Workloads lassen sich kaum deduplizieren. Viele Unternehmen stellen fest, dass sie durch strategische Deduplizierung Speicher skalieren und zugleich Kosten senken (auf Englisch) können. Bevor Sie eine Speicherarchitektur entwerfen, sollten Sie die realistische Wirkung der Deduplizierung kennen. Wer sie überschätzt, dimensioniert zu knapp und stößt mitten im Projekt an Grenzen. Wer sie unterschätzt, dimensioniert zu großzügig und verschwendet Kapital. Die falsche Strategie – Inline- oder Post-Process-Deduplizierung – kann Engpässe in Ihrer Trainingspipeline verursachen. Wie Deduplizierung funktioniert und warum sie für ML-Daten wichtig ist Deduplizierung erkennt sich wiederholende Datenblöcke und speichert sie nur einmal. Haben Sie zehn Kopien desselben Datensatzes mit 1 GB, speichert die Deduplizierung ihn einmal und legt neun Verweise an. Teilen sich Tausende Modell-Checkpoints gemeinsame Bibliotheken, werden diese gemeinsamen Bestandteile einmal gespeichert und referenziert. Für Speichersysteme ist das ein starkes Werkzeug. Backup-Systeme, die tägliche Datenbank-Snapshots speichern, erreichen Deduplizierungsraten von 10:1 oder 20:1, weil jeder Snapshot nahezu identisch mit dem des Vortags ist – nur geänderte Blöcke unterscheiden sich. E-Mail-Systeme mit Tausenden Kopien derselben Marketingunterlagen deduplizieren sehr stark. ML-Daten sind jedoch grundlegend anders. Die meisten ML-Datensätze sind von Natur aus einzigartig. Bilddatensätze enthalten Millionen unterschiedlicher Bilder. Finanzielle Zeitreihen enthalten einzigartige Transaktionsfolgen. Wer mit diesen Datensätzen mehrfach trainiert, verbraucht Speicher in Höhe der Datensatzgröße mal Anzahl der Läufe. Deduplizierung kann hier nicht helfen, weil es nichts Redundantes zu beseitigen gibt – es sei denn, Ihre Pipeline speichert Zwischenergebnisse, zwischengespeicherte Daten oder Kopien von Datensätzen. Bei Modell-Checkpoints und Zwischenartefakten spielt die Deduplizierung ihre Stärken aus. Ein Checkpoint eines Sprachmodells bei Iteration 10.000 und 10.001 unterscheidet sich womöglich um weniger als 1 % – die meisten Gewichte und Parameter sind identisch. Die Deduplizierung speichert das Delta und verweist auf die vorherige Iteration, was den Speicherbedarf um 90 % oder mehr senkt. So können Sie die vollständige Checkpoint-Historie vorhalten – unverzichtbar, um Leistungseinbußen zu untersuchen, Fehler rückgängig zu machen oder die Inferenz mit älteren Versionen auszuführen –, ohne die entsprechenden Speicherkosten zu tragen. Deduplizierungsraten nach ML-Workload-Typ Die tatsächlichen Deduplizierungsraten bei ML-Workloads hängen vom Datentyp und den Trainingspraktiken ab. Wer sie kennt, kann den Speicher realistisch dimensionieren. Trainingsdatensätze für große Sprachmodelle lassen sich typischerweise im Verhältnis 1,2:1 bis 1,5:1 deduplizieren. Rohtext ist weitgehend einzigartig – verschiedene Dokumente enthalten kaum überlappende Blöcke. Erzeugt die Vorverarbeitung jedoch Zwischendatensätze (tokenisierte, konvertierte, bereinigte Versionen) und speichern Sie alle für die Reproduzierbarkeit, verbessern sich die Raten auf 2:1 oder 3:1. Manche Unternehmen halten mehrere Datensatzversionen mit unterschiedlicher Bereinigung oder Filterung vor. Hier hilft die Deduplizierung erheblich. Modell-Checkpoints und Trainingsartefakte erreichen deutlich höhere Deduplizierungsraten. Ein typisches Szenario: Sie trainieren ein Sprachmodell und speichern alle 1.000 Iterationen einen Checkpoint. Zwischen Iteration 10.000 und 10.001 sind rund 99 % der Modellgewichte identisch. Die Deduplizierung kann 50:1 oder mehr erreichen – Sie speichern also tausend Checkpoints zu den Kosten von etwa zwanzig. Das verändert die Speicherökonomie grundlegend: Eine vollständige Trainingshistorie wird praktikabel statt unbezahlbar. Feature Stores für ML-Systeme in der Produktion liegen bei der Deduplizierung im Mittelfeld. Feature Stores halten historische Werte über Monate oder Jahre vor. Aufeinanderfolgende Feature-Snapshots lassen sich im Verhältnis 3:1 bis 8:1 deduplizieren – je nachdem, wie häufig Features neu berechnet werden und ob Sie mehrere Versionen vorhalten. Zwischenartefakte des Trainings– temporäre Dateien der Vorverarbeitung, Validierungsergebnisse, Logs – lassen sich im Verhältnis 2:1 bis 4:1 deduplizieren. Diese Dateien entstehen in den Phasen der ML-Pipeline mehrfach und werden selten bereinigt, was sie zu guten Kandidaten für die Deduplizierung macht. Inline-Deduplizierung vs. Post-Process-Deduplizierung Der Zeitpunkt der Deduplizierung – wann das Speichersystem Duplikate erkennt und beseitigt – beeinflusst sowohl den Speicherbedarf als auch die Pipeline-Performance erheblich. Diese Wahl sollte im Mittelpunkt Ihrer Entscheidungen zur Speicherarchitektur stehen. Inline-Deduplizierung erfolgt beim Schreiben der Daten. Schreibt Ihre Trainingspipeline einen Checkpoint, erkennt das Speichersystem sofort vorhandene Blöcke und verweist auf sie, statt Kopien zu speichern. Das bringt sofort maximale Platzersparnis. Die Inline-Deduplizierung hat jedoch ihren Preis: Die Erkennung benötigt Rechenzyklen und erhöht die Schreiblatenz. Bei Checkpoints im Terabyte-Bereich können schon kleine Latenzerhöhungen den Durchsatz stören und das Training verlängern. Post-Process-Deduplizierung erfolgt nach dem Schreiben der Daten. Ihre Pipeline schreibt Checkpoints in voller Größe. Später durchsucht ein Hintergrunddienst den Speicher, erkennt Duplikate und organisiert die Daten neu. Das beeinträchtigt die Schreibleistung kaum – Ihre Pipeline schreibt mit voller Geschwindigkeit. Sie benötigen jedoch genug Kapazität für die volle Datensatzgröße plus den Deduplizierungs-Overhead, bevor der Hintergrundprozess abgeschlossen ist. Ist Ihr Speicher knapp bemessen, kann das problematisch sein. Die meisten Unternehmen, die Deduplizierung für ML-Workloads einsetzen, wählen die Post-Process-Deduplizierung. Sie lassen sie außerhalb der Spitzenzeiten laufen oder wenn der Trainingsdurchsatz weniger kritisch ist. So bleibt die Trainingsleistung erhalten, und die Einsparungen stellen sich innerhalb von Stunden oder Tagen ein. Der Nachteil: Sie brauchen etwas mehr Spitzenkapazität als bei der Inline-Deduplizierung. Deduplizierung im Kontext der ML-Data-Governance Deduplizierung schafft subtile Herausforderungen für die Data Governance, die Sie vor dem Einsatz kennen sollten. Werden zwei Datensätze dedupliziert und löschen Sie später einen davon (weil er nicht mehr benötigt wird oder die Compliance es verlangt), kann das Speichersystem die zugrunde liegenden Daten nicht wirklich löschen – sie werden noch vom anderen Datensatz referenziert. Erst wenn alle Verweise gelöscht sind, verschwinden die Daten tatsächlich. Für ML-Teams ist das oft unsichtbar und führt zu überraschenden Situationen. Eine Data Scientist löscht einen Datensatz mit personenbezogenen Daten, um Datenschutzanforderungen zu erfüllen. Ohne dass sie es weiß, verweisen Modell-Checkpoints, die mit diesem Datensatz trainiert wurden, noch auf die deduplizierten Blöcke und werden unbegrenzt aufbewahrt. Ihr Compliance-Team stellt bei der Prüfung vor einem Datenschutz-Audit fest, dass die personenbezogenen Daten technisch noch existieren. Schlimmer noch: Sie können nicht ohne Weiteres nachvollziehen, welche Datensätze auf die gelöschten Daten verweisen – die Deduplizierungsschicht ist für Governance-Tools meist undurchsichtig. Um das zu verhindern, sollten Sie klare Governance-Richtlinien für deduplizierte Daten festlegen. Dokumentieren Sie, welche Datensätze über die Deduplizierung gemeinsame Blöcke nutzen. Ist ein zur Löschung vorgesehener Datensatz mit anderen dedupliziert, eskalieren Sie vor der Löschung an Ihr Governance-Team. Manche Unternehmen führen einen Mechanismus für „Deduplizierungssperren“ ein, bei dem zur Löschung vorgesehene Daten bis zur Freigabe durch die Governance von der Deduplizierung ausgenommen werden. Hardware und Software für die Deduplizierung: die Abwägung Deduplizierung lässt sich auf mehreren Ebenen umsetzen: im Objektspeichersystem (sofern unterstützt), in der Backup-Software (viele Plattformen bieten das für Checkpoints) oder über separate Appliances. Hardwarebasierte Deduplizierung auf dedizierten Appliances bietet hervorragende Raten und hohe Performance, bringt aber erhebliche Investitionskosten und Vendor-Lock-in mit sich. Diese Systeme werden oft pro Terabyte abgerechnet und sind daher für große ML-Deployments teuer. Softwaredefinierte Deduplizierung auf Standard-Hardware bietet mehr Flexibilität bei geringeren Kosten. Unterstützt Ihr Objektspeichersystem die Deduplizierung nativ (wie manche S3-kompatiblen Systeme), profitieren Sie ohne zusätzliche Infrastruktur. Andernfalls betreiben Sie die Deduplizierung als Softwaredienst auf vorhandenen Rechenressourcen, der den Speicher regelmäßig durchsucht. Das senkt die Investitionskosten, erfordert aber mehr betriebliches Management. Realistische Kapazitätsplanung mit Deduplizierung Rechnen Sie bei der Kapazitätsplanung für ML-Workloads mit Deduplizierung mit vorsichtigen Raten. Erwarten Sie 3:1, planen Sie mit 2:1 und nutzen Sie die zusätzliche Kapazität als Puffer. In der Produktion bleiben die Raten wegen Datenvariationen, Konfigurationsänderungen und grundsätzlich nicht redundanter Daten oft hinter den theoretischen Höchstwerten zurück. Ein Beispielszenario: Ein Trainingssystem soll 500 Modell-Checkpoints für ein großes Sprachmodell vorhalten. Ohne Deduplizierung erfordert das 500 × 100 GB = 50 TB. Mit einer realistischen Deduplizierung von 30:1 benötigen Sie vielleicht 1,5 TB. Planen Sie dennoch 2–3 TB ein, um Zwischenartefakte, Logs und eine unvollkommene Deduplizierung abzudecken. Das verschafft Ihnen Spielraum und verhindert, dass der Speicher zum Engpass wird. Wer versteht, wie Deduplizierung mit Tiered Storage für KI zusammenspielt, kann Hot- und Cold-Storage-Ebenen optimieren und zugleich die Pipeline-Performance erhalten. Überwachen Sie die tatsächlichen Deduplizierungsraten in der Produktion und passen Sie Ihre Kapazitätsplanung entsprechend an. Die meisten modernen Speichersysteme liefern detaillierte Kennzahlen – eingesparter Platz, Raten je Datensatz, Trends im Zeitverlauf. Nutzen Sie diese Daten, um Annahmen zu prüfen und die Planung zu verfeinern. Fazit: Deduplizierung als strategisches Speicherwerkzeug für ML Deduplizierung ist keine Universallösung für die Speicherkosten im ML-Bereich, aber ein wirksames Werkzeug für bestimmte Workloads, insbesondere Modell-Checkpoints und Trainingsartefakte. Wenn Sie realistische Deduplizierungsraten kennen und den richtigen Zeitpunkt wählen (Post-Process für die meisten ML-Workloads), senken Sie den Speicherbedarf erheblich und erhalten zugleich die Data Governance und Reproduzierbarkeit, die moderne ML-Praktiken verlangen. Siehe auch Tiered Storage für KI. Unternehmen, die mit ML-Deployments im großen Maßstab erfolgreich sind, behandeln die Speicherarchitektur als vollwertige Engineering-Aufgabe. Dazu gehört ein durchdachter Einsatz der Deduplizierung dort, wo sie Mehrwert bringt, kombiniert mit einer sorgfältigen Kapazitätsplanung und Governance. Wenn Sie Speicher überdimensionieren, um die Komplexität der Deduplizierung zu umgehen, oder mit Governance-Problemen kämpfen, sollten Sie Ihre Architektur überdenken. Der Nutzen – geringere Investitionskosten und ein einfacherer Betrieb – ist erheblich. Weiterführende Artikel Tiered Storage für KI: Skalierbare Performance und Kostenkontrolle Hot Storage vs. Cold Storage Gesamtbetriebskosten für Datenspeicher (auf Englisch) KI-Datenpipelines: Architektur, Phasen und Best Practices Big-Data-Analytics und Objektspeicher (auf Englisch) Speicher skalieren und Kosten senken (auf Englisch)
