Datendeduplizierung im Billionenmaßstab: Wie man den größten Engpass beim LLM-Training löst
Das Skalierungsrennen der LLMs – und seine unsichtbaren Kosten
LLMs haben nahezu jeden Bereich der modernen KI verändert und neue Grenzen in der Inhaltserstellung, Softwareentwicklung, im Schlussfolgern und in der autonomen Tool-Nutzung erschlossen. Und ihre Fähigkeiten zeigen keine Anzeichen einer Verlangsamung.
Nehmen wir die jüngsten Ankündigungen: X.ai’s Grok 4 und Moonshot’s Kimi K2 führen stärkere Fähigkeiten im Schlussfolgern, bessere Tool-Nutzung und kohärentere Generierung ein – alles angetrieben durch deutlich größere und vielfältigere Trainingskorpora.
Der Trend ist klar: Die Grenze der Leistungsfähigkeit wird durch Training in beispiellosem Maßstab nach vorne verschoben. Betrachten wir die Daten-Footprints aktueller Modelle:
| Modell | Veröffentlichung | Parameter | Trainingsdaten |
|---|---|---|---|
| Kimi K2 | 2025 | 1T | 15,5 Billionen Token |
| Grok 4 | 2025 | ~175B | 100x mehr als Grok 2, wahrscheinlich Billionenmaßstab |
| GPT-4 | 2023 | 1,8T (geschätzt) | 13 Billionen Token |
| LLaMA 3.1 | 2024 | 405B | 15 Billionen Token |
Kimi K2 beispielsweise hat die Größe seines Datensatzes in nur sechs Monaten verdreifacht – eine Wachstumsrate, die die Expansion des Internets fast überholt. Mit 15,5 Billionen Token ist er um ein Vielfaches größer als der kumulierte Inhalt aller großen Bibliotheken weltweit.
Doch in diesem Wachstum steckt die Annahme, dass mehr Daten immer bessere Leistung bedeuten. In der Praxis nehmen die Grenzerträge durch das bloße Hinzufügen weiterer Token ab und werden zunehmend durch die Datenqualität begrenzt.
Das bringt uns zum ersten – und vielleicht am meisten unterschätzten – Engpass im modernen LLM-Training: Datenduplizierung.
Datendeduplizierung: Warum sie für das LLM-Training wichtig ist
Moderne Pretraining-Datensätze für LLMs stammen hauptsächlich aus groß angelegten Web-Crawls, offenen Repositories, öffentlichen Korpora und domänenspezifischen Dokumenten, die aus dem Web extrahiert wurden. Wenn diese Pipelines wachsen, wird Redundanz nicht nur häufig, sondern systemisch.
Dokumente mit geringfügigen Abweichungen (z. B. Formatierungsänderungen, Fußzeilen, Boilerplate-Header) tauchen in verschiedenen Domains erneut auf. Beliebte Seiten werden gespiegelt, übersetzt oder auf anderen Websites erneut veröffentlicht. Codebasen und Wissensartikel werden über Foren, Wikis und archivierte Snapshots hinweg dupliziert. Selbst strukturierte Quellen wie Wikipedia weisen Wiederholungen in Link-Pfaden und Spiegelungen auf.
Wenn diese duplizierten Inhalte ungeprüft in Trainingssätze einfließen, sind die Folgen erheblich:
Compute-Ineffizienz: Wiederholte Beispiele liefern keine neuen Informationen, verbrauchen aber dieselben Rechenressourcen.
Overfitting-Risiko: LLMs, die wiederholt Formulierungen, Strukturen oder Inhaltsmuster sehen, können sich zu stark auf diese Muster verlassen und dadurch ihre Generalisierungsfähigkeiten verringern.
Wörtliche Memorierung: Hohe Duplizierung erhöht das Risiko, dass Modelle bestimmte Sequenzen memorieren, was Sicherheits-, Datenschutz- und IP-Bedenken aufwirft.
Evaluation Leakage: Wenn Duplikate sowohl in den Trainings- als auch in den Validierungs-/Testsätzen existieren, können Benchmark-Ergebnisse künstlich aufgebläht werden und einen irreführenden Eindruck der Modellqualität vermitteln.
Kurz gesagt: Duplizierung ist nicht nur ein Ärgernis. Sie ist ein existenzielles Problem für großskalige, kostenintensive Trainingsläufe.
Einer unserer Enterprise-Kunden – ein erstklassiger LLM-Anbieter – stieß genau auf dieses Problem. Er musste Dutzende Milliarden Dokumente deduplizieren, bevor sie aufgenommen wurden. Tools für exaktes Hash-Matching übersahen Near-Duplicates. Semantische Modelle waren zu teuer, um sie im großen Maßstab auszuführen. Und traditionelle Data-Cleaning-Stacks konnten ihre Zeit- und Ressourcenbeschränkungen schlicht nicht erfüllen.
Dies ist der Kontext, in dem Deduplizierung zu missionskritischer Infrastruktur geworden ist, nicht zu einem nachträglichen Preprocessing-Schritt.
Ein Überblick über Deduplizierungstechniken
Es gibt drei dominante Strategien für Deduplizierung im großen Maßstab, jeweils mit Kompromissen hinsichtlich Präzision, Kosten und Machbarkeit.
Exakte Übereinstimmung: Verwendet kryptografisches Hashing, um identische Dokumente zu finden. Schnell und präzise, übersieht jedoch Beinahe-Duplikate mit geringfügigen Formatierungsunterschieden.
Semantische Übereinstimmung: Nutzt Vektor-Embedding-Modelle, um konzeptionell ähnliche Inhalte zu finden. Sehr genau, aber im großen Maßstab rechenintensiv.
Approximate Matching: Findet Beinahe-Duplikate mithilfe probabilistischer Algorithmen wie MinHash LSH und Jaccard-Ähnlichkeit. Gleicht Genauigkeit mit Recheneffizienz aus—perfekt für Datensätze mit Billionen von Tokens.
Da Pretraining-Korpora Terabytes oder sogar Petabytes erreichen, sind traditionelle exakte Matching-Methoden, wie paarweise Vergleiche, rechnerisch nicht praktikabel. Semantische Deduplizierung verursacht erheblichen Mehraufwand, indem Embedding-Modelle zur Erzeugung von Vektoren verwendet werden.
Wir brauchen innovativere approximative Methoden—wie MinHash LSH—die Recall und Präzision ausbalancieren und gleichzeitig die Kosten überschaubar halten, wodurch groß angelegte Deduplizierung praktikabel wird.
MinHash LSH: Erkennung von Beinahe-Duplikaten in Datensätzen im Billionen-Maßstab
Im Kontext des groß angelegten LLM-Trainings erfordert effiziente Deduplizierung einen Matching-Algorithmus, der nicht nur genau, sondern auch rechnerisch machbar im Maßstab von zig Milliarden Dokumenten ist. MinHash LSH (Locality Sensitive Hashing) ist genau für diese Art von Szenario konzipiert.
MinHash: Skalierbare Ähnlichkeitsschätzung
MinHash ist eine probabilistische Technik, die entwickelt wurde, um die Jaccard-Ähnlichkeit zwischen Mengen zu schätzen, ohne explizite paarweise Schnittmengen zu berechnen. Im Kontext der Dokument-Deduplizierung fungiert es als verlustbehafteter Komprimierungsmechanismus, der die Ähnlichkeitsstruktur über massive Korpora hinweg bewahrt.
Der Prozess funktioniert wie folgt:
Jedes Dokument wird in eine Menge von Shingles zerlegt, typischerweise Zeichen- oder Wort-n-Gramme fester Länge.
Eine Reihe unabhängiger Hash-Funktionen wird auf diese Mengen angewendet.
Für jede Hash-Funktion wird der minimale resultierende Wert über die Shingle-Menge hinweg beibehalten.
Dies erzeugt für jedes Dokument eine MinHash-Signatur fester Länge. Die entscheidende Eigenschaft ist diese: Für zwei beliebige Dokumente nähert die Wahrscheinlichkeit, dass ein bestimmter Hash-Wert an derselben Position ihrer Signaturen geteilt wird, ihre Jaccard-Ähnlichkeit an.
Dies reduziert die Rechenlast für groß angelegte Ähnlichkeitserkennung drastisch. Anstatt vollständige Dokumente zu vergleichen, vergleichen wir kurze Signaturvektoren. Aber es gibt ein Skalierungsproblem. Selbst mit dieser Optimierung bleibt der Vergleich jedes Dokumentenpaars im Web-Maßstab rechnerisch nicht praktikabel.
Locality Sensitive Hashing: Beschleunigung der Ähnlichkeitssuche
Um MinHash für Korpora im Milliardenmaßstab praktikabel zu machen, wenden wir Locality Sensitive Hashing (LSH) auf die Signaturvektoren an. Die Kernidee von LSH besteht darin, die Wahrscheinlichkeit zu erhöhen, dass ähnliche Dokumente in mindestens einem Hash-Bucket kollidieren, ohne eine exhaustive Vergleichssuche zu erfordern.
So funktioniert es:
Jede MinHash-Signatur wird in mehrere Bänder unterteilt, von denen jedes eine Teilmenge der Signaturdimensionen enthält.
Jedes Band wird unabhängig in einen Bucket gehasht.
Wenn zwei Dokumente mindestens ein Band teilen, das in denselben Bucket gehasht wird, gelten sie als Kandidaten für eine potenzielle Duplizierung.
Diese Banding-Strategie stellt sicher, dass Dokumente mit hoher Ähnlichkeit (d. h. vielen gemeinsamen MinHash-Werten) mit deutlich höherer Wahrscheinlichkeit kollidieren. Durch Anpassen der Anzahl der Bänder und Zeilen pro Band können wir zwischen Recall (der Anzahl korrekt erkannter Duplikate), Präzision (der Anzahl vermiedener False Positives) und Leistung abwägen.
Das Ergebnis ist ein skalierbares, approximatives Deduplizierungssystem, das selbst bei Anwendung auf Korpora mit zig Milliarden Dokumenten handhabbar bleibt.
Integration von MinHash LSH mit Milvus und Zilliz Cloud
Traditionell wird Deduplizierung durch eigenständige Vorverarbeitungspipelines gehandhabt, die von der primären Retrieval- oder Speicherinfrastruktur getrennt sind. Dies führt zu einer Reihe von Ineffizienzen:
Kostspielige Datenübertragung zwischen den Deduplizierungs- und Vektorindexierungskomponenten.
Doppelte Logik für Datennormalisierung und Shingling.
Schwierigkeit, Deduplizierungs- und Retrieval-Pipelines gemeinsam zu skalieren.
Wir sind das Problem anders angegangen. In Anerkennung der Stärke von Milvus als Vektordatenbank mit hohem Durchsatz fragten wir uns: Was wäre, wenn MinHash LSH ein erstklassiges, nativ integriertes Indexierungsprimitiv wäre?
Dies führte zur nativen Integration von MinHash LSH in Milvus 2.6 und Zilliz Cloud (verwaltetes Milvus), wodurch approximative Deduplizierung zu einem Kernbestandteil des Vektorindexierungs- und Retrieval-Workflows wird.
Was diese Integration ermöglicht
End-to-end-Workflow: Von der Aufnahme und MinHash-Signaturgenerierung bis hin zur approximativen Duplikaterkennung und nachgelagerten semantischen Suche – alles innerhalb von Milvus.
Verteilte Skalierung: Aufbauend auf der Cloud-nativen Architektur von Milvus skaliert die LSH-Indexierung horizontal über Terabytes oder sogar Petabytes an Daten.
Einheitliche APIs: Dieselbe API, die für die Suche nach semantischen Embeddings verwendet wird, kann nun auch MinHash-basierte Deduplizierungsabfragen unterstützen, wodurch MLOps-Workflows sauberer und wartbarer werden.
In unserer aktuellen Implementierung:
Benutzer generieren MinHash-Signaturen extern (z. B. mit ihren bevorzugten Shingling- und Hash-Strategien).
Diese Signaturvektoren (typischerweise
uint32-Arrays) werden in Milvus eingefügt.Die LSH-Indexierung grenzt den Kandidatenraum für die approximative Duplikaterkennung mithilfe der oben beschriebenen Banding-Strategie ein.
Dieses Design ermöglicht es Teams, Trainingskorpora in massivem Umfang zu deduplizieren, ohne zusätzliche Speicherschichten oder getrennte Vorverarbeitungslogik einzuführen.
Wir haben außerdem die zugrunde liegende API erweitert, um Workflows wie hybride Einfügung (semantische und MinHash-Vektoren), dynamische Indexerstellung und Batch-Deduplizierungsabfragen zu unterstützen. Diese Fähigkeiten entwickeln sich noch weiter, und wir freuen uns über Feedback von Teams, die dies in der Produktion einsetzen.
Die technischen Herausforderungen bei der Deduplizierung von zig Milliarden Dokumenten mit MinHash LSH
MinHash LSH in der Produktion zum Laufen zu bringen, ist seit Jahren der weiße Wal der Branche.
Die Herausforderung läuft auf zwei brutale Anforderungen hinaus:
Man benötigt tiefgreifende Expertise sowohl in MinHash- als auch in LSH-Algorithmen sowie die technischen Fähigkeiten, sie nahtlos zu integrieren.
Jeder reale Anwendungsfall für MinHash LSH beinhaltet die Deduplizierung von zig Milliarden, Hunderten von Milliarden oder sogar Billionen von Datenpunkten. Dies stellt erdrückende Anforderungen an Leistung und Engineering-Fähigkeiten, die die meisten Teams nicht erfüllen können.
Hier ist ein perfektes Beispiel: Vor etwa einem Jahr kam ein führendes KI-Unternehmen mit einer scheinbar unkomplizierten Anfrage auf uns zu. Sie mussten zig Milliarden von Datenpunkten (in einem 780-dimensionalen int32-Format) deduplizieren, mit der Fähigkeit, Dienste schnell hochzufahren und Daten zügig für Deduplizierung und Einfügung zu verarbeiten.
Wir stießen sofort auf einen Showstopper: Die meisten Vektordatenbanken verwenden standardmäßig float32-Datenformate, aber MinHash-Vektoren sind Sammlungen von uint32-Hashwerten.
Auf den ersten Blick scheint das kein Problem zu sein – float32 kann uint32-Werte in den meisten Fällen darstellen, oder?
Falsch.
Hier ist der Haken: float32 kann vorzeichenlose Ganzzahlen nur im Bereich von 0 bis 16.777.216 darstellen, während uint32 den Bereich von 0 bis 4.294.967.295 abdeckt. Wenn ein Hashwert 16.777.216 überschreitet, beginnt float32, Präzision in den niederwertigsten Bits zu verlieren.
Glücklicherweise löst die Unterstützung für binäre Vektoren von Milvus und Zilliz Cloud dieses Problem auf elegante Weise.
Das mag wie ein kleines technisches Detail erscheinen, verdeutlicht aber einen entscheidenden Punkt: Sie benötigen eine Datenbank, die von Anfang an darauf ausgelegt ist, vielfältige Datenformate, massive Skalierungen und unterschiedliche Enterprise-Anforderungen zu bewältigen. Wenn Sie nicht von Beginn an für Enterprise-Szenarien entwickeln, können selbst winzige Kompatibilitätsprobleme wie dieses später zu Katastrophen für die Kundenerfahrung werden.
Doch die Herausforderung des Datenformats war nur der Anfang – unsere Kunden verlangten auch extreme Performance. Während des Integrationsprozesses brachte es der Kunde unverblümt auf den Punkt: "Ich muss Zilliz Cloud-Services schnell bereitstellen können, die sofort eine hochpräzise Vektordeduplizierung durchführen können. Jeder Import umfasst 30-GB-Dateien mit 780-dimensionalen int32-Signaturdaten, und der gesamte Importprozess muss in weniger als 15 Minuten abgeschlossen sein."
Auf den ersten Blick sieht das nach Mission Impossible aus, aber wir lieferten schnell unsere Antwort: Vergessen Sie 15 Minuten – wir erledigen es in 4.
Dieser Performance-Durchbruch ergab sich aus zwei zentralen Milvus-Optimierungen:
Erstens implementierten wir eine parallele Verarbeitung mehrerer Dateien, die den traditionellen Engpass des seriellen Imports durchbrach. Das System kann nun mehrere Datendateien gleichzeitig verarbeiten, wodurch der Gesamtdurchsatz und die Importgeschwindigkeit drastisch erhöht werden.
Zweitens integrierten wir eine dynamische Ressourcenzuweisung, die Rechenressourcen intelligent auf Grundlage von Aufgabenkomplexität und Datenvolumen plant. Dadurch werden Ressourcenverschwendung und Konflikte vermieden und gleichzeitig die Auslastung maximiert. Zusammen ermöglichen diese Optimierungen Milvus, moderne Hardwarefähigkeiten und die gleichzeitigen Lese-Schreib-Eigenschaften von Cloud-Speicher voll auszuschöpfen und nahezu Echtzeit-Erlebnisse beim Datenimport zu liefern.
Die Lösung der Import-Herausforderung war nur Schritt eins – wie bewältigt man schnelle Bereitstellung und Berechnung in massivem Maßstab?
Trainingsszenarien für große KI-Modelle erzeugen einen perfekten Sturm anspruchsvoller Anforderungen. Sie haben es mit enormen eingehenden Datenmengen, riesigen bestehenden Datenbanken und Spitzenlasten zu tun, die 44.000 Vektorabrufe pro Sekunde erreichen können – eine extreme Parallelität, die die meisten Systeme in die Knie zwingt. Während weiterhin Daten einfließen und Ihre Datenbank exponentiell wächst, steigen die Rechenanforderungen entsprechend an und setzen die Systemleistung unablässig unter Druck.
Die Lösung erfordert ernsthafte verteilte Rechenleistung. Die cloud-native Architektur von Zilliz Cloud wurde speziell entwickelt, um diese Herausforderungen durch intelligente Workload-Verteilung und elastische Skalierung zu bewältigen.
Die Geheimwaffe: Integration der Cardinal Engine
Mit Blick auf die Zukunft ist MinHash LSH erst der Anfang. Wir integrieren diese Fähigkeit in die proprietäre Cardinal Engine von Zilliz Cloud, die die Verarbeitung unstrukturierter Daten insgesamt weiter beschleunigen wird.
Cardinal ist unsere KI-gestützte Vektorsuchmaschine der nächsten Generation, von Grund auf mit modernem C++ und hochmodernen Approximate-Nearest-Neighbor-Search-(ANNS)-Algorithmen entwickelt. Das Ziel ist einfach: mehr Benutzeranfragen mit denselben Hardware-Ressourcen bearbeiten.
Optimierungen auf Algorithmenebene: Cardinal bietet umfassendes Performance-Tuning für Kernalgorithmen wie IVF und Graph-Indexierung und findet dabei die optimale Balance zwischen Geschwindigkeit und Speichereffizienz.
Innovationen auf Engineering-Ebene: Die Engine verfügt über benutzerdefinierte Speicher-Allokatoren und intelligentes Memory Pooling sowie über eine modulare Komponentenarchitektur, die eine flexible Zusammensetzung der Suchpipeline ermöglicht. Jede Pipeline kann für spezifische, geschäftskritische Anwendungsfälle feinabgestimmt werden.
Hardware-spezifische Optimierung: Cardinal umfasst mehrere spezialisierte Compute-Kernels, die jeweils von Hand für bestimmte Hardware-Plattformen und Workload-Muster optimiert wurden.
Diese umfassenden Optimierungen ermöglichen es Cardinal, rund um die Uhr mit maximaler Effizienz zu arbeiten und branchenführende Vector-Search-Performance zu liefern. Da Cardinal Zilliz Cloud antreibt, haben wir 10-fache Leistungsverbesserungen gegenüber Open-Source-Milvus erzielt, kombiniert mit ultraschnellen Abfragegeschwindigkeiten und hohen Recall-Raten. Ganz gleich, ob Sie riesige Datensätze verarbeiten oder Anwendungen entwickeln, die blitzschnelle Antwortzeiten erfordern: Cardinal bietet die Performance-Grundlage für herausragende Nutzererlebnisse und wettbewerbsfähige KI-Anwendungen.
Die Zukunft ist unstrukturiert—und wir sind bereit dafür
Die Deduplizierung von LLM-Trainingsdaten ist nur der Auftakt zu einer viel größeren Transformationsgeschichte. IDC prognostiziert, dass unstrukturierte Daten bis 2027 weltweit auf nahezu 250 ZB anwachsen werden—das entspricht 86,8 % aller existierenden Daten. Zwar ist die Verarbeitung und Speicherung dieser Daten deutlich teurer als bei strukturierten Daten, doch der Wert, der in Texten, Bildern, Audio, Video, Sensorprotokollen, Social-Media-Inhalten, PDFs, Webseiten, Code-Repositories, medizinischer Bildgebung und Satellitenfotos steckt, lässt sich nicht ignorieren.
Dies schafft die prägende Herausforderung unserer Zeit: Wie können wir effizient Wert aus exponentiell wachsenden unstrukturierten Daten extrahieren, ohne das Budget zu sprengen?
Die Deduplizierungsfunktionen, die wir für KI-Training entwickelt haben, sind nur ein Teil dieses größeren Puzzles. Während unstrukturierte Daten weiterhin explosionsartig wachsen, werden dieselben Prinzipien—intelligente Algorithmen, Engineering auf Enterprise-Niveau und cloudnative Performance—zu unverzichtbarer Infrastruktur für jede datengesteuerte Organisation.
Die Zukunft gehört Unternehmen, die das Chaos unstrukturierter Daten in einen strukturierten Wettbewerbsvorteil verwandeln können. Wir bauen diese Zukunft, Algorithmus für Algorithmus. Bereit, sich uns anzuschließen?
Bereit, groß angelegte Deduplizierung für Ihre KI-Trainingspipeline zu erkunden? Erfahren Sie mehr über die MinHash-LSH-Funktionen von Milvus 2.6 in unserer umfassenden Dokumentation, testen Sie Zilliz Cloud (managed Milvus) für Produktions-Workloads, oder treten Sie mit unserem Engineering-Team auf Discord in Kontakt, um Ihren spezifischen Anwendungsfall zu besprechen.
Weiterlesen
Migrating Self-Managed Milvus to Zilliz Cloud for >99% Latency Reduction
Step-by-step guide to migrating 50M vectors from self-managed Milvus to Zilliz Cloud using milvus-backup. Achieve >99% query latency reduction with zero data loss.
Zilliz Cloud Now Available in AWS Asia Pacific (Seoul)
Zilliz Cloud is now available in AWS Seoul — low-latency vector search, in-country data residency, and one-step migration for Korean AI teams. 31 regions across 5 clouds.
Building RAG Pipelines for Real-Time Data with Cloudera and Milvus
explore how Cloudera can be integrated with Milvus to effectively implement some of the key functionalities of RAG pipelines.