Ein Architektenhandbuch zum Erstellen einer Referenzarchitektur für einen KI/ML-Datalake

Eine gekürzte Version dieses Beitrags erschien am 19. März 2024 auf The New Stack. In der künstlichen Intelligenz von Unternehmen gibt es zwei Haupttypen von Modellen: diskriminative und generative. Diskriminative Modelle werden verwendet, um Daten zu klassifizieren oder vorherzusagen, während generative Modelle verwendet werden, um neue Daten zu erstellen. Obwohl generative KI in letzter Zeit die Nachrichten dominiert hat, verfolgen Unternehmen immer noch beide Arten von KI. Diskriminative KI bleibt weiterhin eine wichtige Initiative für Unternehmen, die effizienter arbeiten und zusätzliche Einnahmequellen erschließen möchten. Diese verschiedenen Arten von KI haben viel gemeinsam, aber gleichzeitig gibt es erhebliche Unterschiede, die beim Aufbau Ihrer KI-Dateninfrastruktur berücksichtigt werden müssen. Organisationen sollten keine Infrastruktur aufbauen, die ausschließlich der KI und der künstlichen Intelligenz gewidmet ist, während sie Workloads wie Business Intelligence, Datenanalyse und Datenwissenschaft sich selbst überlassen. Es ist möglich, eine vollständige Dateninfrastruktur aufzubauen, die alle Anforderungen der Organisation unterstützt – Business Intelligence, Datenanalyse, Datenwissenschaft, diskriminative KI und generative KI. In einem anderen Beitrag haben wir eine Referenzarchitektur für einen modernen Datalake vorgestellt, der die Anforderungen von Business Intelligence, Datenanalyse, Datenwissenschaft und KI/ML erfüllen kann. Sehen wir uns die moderne Datalake-Referenzarchitektur an und heben wir die Funktionen hervor, die sie zur Unterstützung von KI/ML-Workloads bietet. Der moderne Datalake Beginnen wir mit der Definition eines modernen Datalake, da dieser als Grundlage für unsere Referenzarchitektur dienen wird. Diese Architektur ist nicht „wiederverwertet“, sondern spiegelt grundlegende technische Prinzipien wider, die allgemein anwendbar sind. Ein moderner Datalake ist zur Hälfte Data Warehouse und zur Hälfte Data Lake und verwendet Objektspeicher für alles. Die Verwendung von Objektspeicher für einen Data Lake ist absolut sinnvoll, da Objektspeicher für unstrukturierte Daten gedacht ist, die ein Data Lake speichern soll. Die Verwendung von Objektspeicher für ein Data Warehouse mag jedoch seltsam klingen – aber ein auf diese Weise erstelltes Data Warehouse stellt die nächste Generation von Data Warehouses dar. Dies wird durch die Open Table Format Specifications (OTFs) ermöglicht, die von Netflix, Uber und Databricks entwickelt wurden und die den nahtlosen Einsatz von Objektspeicher in einem Data Warehouse ermöglichen. Die OTFs sind Apache Iceberg, Apache Hudi und Delta Lake. Sie wurden von Netflix, Uber bzw. Databricks entwickelt, weil es auf dem Markt keine Produkte gab, die ihren Datenbedarf decken konnten. Im Wesentlichen definieren sie alle (auf unterschiedliche Weise) ein Data Warehouse, das auf Object Storage (MinIO) aufgebaut werden kann. Object Storage bietet die Kombination aus skalierbarer Kapazität und hoher Leistung, die andere Speicherlösungen nicht bieten können. Da es sich um moderne Spezifikationen handelt, verfügen sie über erweiterte Funktionen, die altmodische Data Warehouses nicht haben – wie Partitionsentwicklung, Schemaentwicklung und Zero-Copy-Branching. Und schließlich können Sie, da das Data Warehouse mit Object Storage aufgebaut ist, denselben Object Store für unstrukturierte Daten wie Bilder, Videodateien, Audiodateien und Dokumente verwenden. Unstrukturierte Daten werden normalerweise in einem sogenannten Data Lake gespeichert. Wenn Sie einen Objektspeicher als Grundlage für Ihren Data Lake und Ihr Data Warehouse verwenden, erhalten Sie eine Lösung, die alle Ihre Daten aufnehmen kann. Strukturierter Speicher befindet sich im OTF-basierten Data Warehouse und unstrukturierter Speicher im Data Lake. Für beides könnte dieselbe Instanz von MinIO verwendet werden. Bei MinIO nennen wir diese Kombination aus einem OTF-basierten Data Warehouse und einem Data Lake den Modern Datalake und sehen ihn als Grundlage für alle Ihre KI/ML-Workloads. Hier werden Daten gesammelt, gespeichert, verarbeitet und transformiert. Das Trainieren von Modellen mit diskriminativer KI (überwachtes, unüberwachtes und bestärkendes Lernen) erfordert häufig eine Speicherlösung, die strukturierte Daten verarbeiten kann, die im Data Warehouse gespeichert werden können. Wenn Sie hingegen Large Language Models (LLMs) trainieren, müssen Sie unstrukturierte Daten oder Dokumente in ihrer Roh- und verarbeiteten Form im Data Lake verwalten. : Quelle Moderne Datalake-Referenzarchitektur Dieser Beitrag konzentriert sich auf die Bereiche der Modern Datalake-Referenzarchitektur für KI/ML, die die verschiedenen KI/ML-Workloads unterstützen. Diese Funktionsbereiche sind unten aufgeführt. Oben sehen Sie eine visuelle Darstellung des Modern Datalake. Die Ebenen, in denen diese Funktionsbereiche zu finden sind, wurden hervorgehoben. Diskriminierende KI Speicher für unstrukturierte Daten Speicher für semistrukturierte Daten Zero Copy Branching im Data Warehouse Generative KI Erstellen eines benutzerdefinierten Korpus mit einer Vektordatenbank Erstellen einer Dokument-Pipeline Retrieval Augmented Generation (RAG) Feinabstimmung großer Sprachmodelle Messen der LLM-Genauigkeit Maschinelles Lernen In diesem Beitrag wird auch der aktuelle Stand der GPUs und ihre Auswirkungen auf Ihre KI-Dateninfrastruktur untersucht. Wir werden uns auch einige Szenarien ansehen, die veranschaulichen, wie Sie Ihre Infrastruktur aufbauen und wie Sie sie nicht aufbauen sollten. Abschließend enthält dieser Beitrag einige Empfehlungen zum Aufbau einer eigenen KI-Dateninfrastruktur. Der aktuelle Stand der GPUs Das Problem der hungrigen GPU Objektspeicher optimieren Die Geschichte zweier Organisationen Ein Plan zum Aufbau Ihrer KI-Dateninfrastruktur Diskriminierende KI Diskriminative KI-Modelle benötigen zum Training Daten aller Art. Modelle zur Bildklassifizierung und Spracherkennung verwenden unstrukturierte Daten in Form von Bildern und Audiodateien. Modelle zur Betrugserkennung und medizinischen Diagnose hingegen treffen Vorhersagen auf der Grundlage strukturierter Daten. Sehen wir uns die im Modern Datalake verfügbaren Optionen zum Speichern und Bearbeiten der von diskriminativer KI benötigten Daten an. Speicher für unstrukturierte Daten Unstrukturierte Daten werden im Data Lake gespeichert, wo sie zum Trainieren und Testen von Modellen verwendet werden können. Trainingssätze, die in den Speicher passen, können vor dem Training geladen werden (bevor Ihre Epochenschleife beginnt). Wenn Ihr Trainingssatz jedoch groß ist und nicht in den Speicher passt, müssen Sie vor dem Training eine Liste von Objekten laden und die tatsächlichen Objekte abrufen, während Sie jeden Stapel in Ihrer Epochenschleife verarbeiten. Dies könnte Ihren Data Lake belasten, wenn Sie Ihren Data Lake nicht mit einem Hochgeschwindigkeitsnetzwerk und Hochgeschwindigkeitsfestplattenlaufwerken erstellen. Wenn Sie Modelle mit Daten trainieren, die nicht in den Speicher passen, sollten Sie erwägen, Ihren Data Lake mit einem 100-GB-Netzwerk und NVMe-Laufwerken zu erstellen. Speicher für semistrukturierte Daten Im Modern Datalake stehen einige Optionen zum Speichern halbstrukturierter Dateien zur Verfügung, beispielsweise Parquet-Dateien, AVRO-Dateien, JSON-Dateien und sogar CSV-Dateien. Am einfachsten ist es, sie in Ihrem Data Lake zu speichern und sie auf dieselbe Weise zu laden wie unstrukturierte Objekte. Wenn die Daten in diesen halbstrukturierten Dateien nicht von anderen Workloads benötigt werden, die der Modern Datalake unterstützt (Business Intelligence, Data Analytics und Data Science), ist dies die beste Option. Eine weitere Möglichkeit besteht darin, diese Dateien in Ihr Data Warehouse zu laden, wo sie von anderen Workloads verwendet werden können. Wenn Daten in Ihr Data Warehouse geladen werden, können Sie mit Ihren Daten. Zero Copy Branching zum Durchführen von Experimenten Zero Copy Branching im Data Warehouse Feature Engineering ist eine Technik zur Verbesserung von Datensätzen, die zum Trainieren eines Modells verwendet werden. Eine sehr raffinierte Funktion, die OTF-basierte Data Warehouses besitzen, ist Zero-Copy-Branching. Dadurch können Daten auf dieselbe Weise verzweigt werden, wie Code in einem Git-Repository verzweigt werden kann. Wie der Name schon sagt, erstellt diese Funktion keine Kopie der Daten, sondern nutzt die Metadatenebene des offenen Tabellenformats, das zur Implementierung des Data Warehouse verwendet wird, um den Anschein einer eindeutigen Kopie der Daten zu erwecken. Datenwissenschaftler können mit einem Zweig experimentieren. Wenn ihre Experimente erfolgreich sind, können sie ihren Zweig wieder in den Hauptzweig integrieren, damit andere Datenwissenschaftler ihn verwenden können. Wenn das Experiment nicht erfolgreich ist, kann der Zweig gelöscht werden. Generative KI Alle Modelle, ob kleine Modelle, die mit Scikit-Learn erstellt wurden, benutzerdefinierte neuronale Netzwerke, die mit PyTorch oder TensorFlow erstellt wurden, oder große Sprachmodelle, die auf der Transformer-Architektur basieren, benötigen Zahlen als Eingaben und erzeugen Zahlen als Ausgabe. Diese einfache Tatsache stellt einige zusätzliche Anforderungen an Ihre KI/ML-Infrastruktur, wenn Sie an generativer KI interessiert sind, bei der Wörter in Zahlen (oder Vektoren, wie wir sehen werden) umgewandelt werden müssen. Eine generative KI-Lösung wird noch komplizierter, wenn Sie private Dokumente verwenden möchten, die das geschützte Wissen Ihres Unternehmens enthalten, um die von den LLMs erzeugten Antworten zu verbessern. Diese Verbesserung könnte in Form von Retrieval Augmented Generation oder LLM Fine-tuning erfolgen. In diesem Abschnitt werden alle diese Techniken (Umwandlung von Wörtern in Zahlen, RAG und Feinabstimmung) und ihre Auswirkungen auf die KI-Infrastruktur besprochen. Beginnen wir mit der Diskussion, wie ein benutzerdefiniertes Corpus erstellt wird und wo es gespeichert werden sollte. Erstellen eines benutzerdefinierten Korpus mit einer Vektordatenbank Wenn Sie es mit Generative AI ernst meinen, sollte Ihr benutzerdefiniertes Korpus Ihre Organisation definieren. Es sollte Dokumente mit Wissen enthalten, das sonst niemand hat, und nur wahre und genaue Informationen enthalten. Darüber hinaus sollte Ihr benutzerdefiniertes Korpus mit einer Vektordatenbank erstellt werden. Eine Vektordatenbank indiziert, speichert und bietet Zugriff auf Ihre Dokumente zusammen mit ihren Vektoreinbettungen, die die numerischen Darstellungen Ihrer Dokumente sind. (Dies löst das oben beschriebene Zahlenproblem.) Vektordatenbanken ermöglichen die semantische Suche. Wie dies funktioniert, erfordert viel mathematisches Wissen und ist kompliziert. Die semantische Suche ist jedoch konzeptionell leicht zu verstehen. Angenommen, Sie möchten alle Dokumente finden, die sich mit „künstlicher Intelligenz“ befassen. Um dies in einer herkömmlichen Datenbank zu tun, müssten Sie nach jeder möglichen Abkürzung, jedem Synonym und jedem verwandten Begriff von „künstlicher Intelligenz“ suchen. Ihre Abfrage würde ungefähr so aussehen: SELECT snippet FROM MyCorpusTable WHERE (text like '%artificial intelligence%' OR text like '%ai%' OR text like '%machine learning%' OR text like '%ml%' OR ... and on and on ... Die manuelle Ähnlichkeitssuche ist nicht nur mühsam und fehleranfällig, sondern die Suche selbst ist auch sehr langsam. Eine Vektordatenbank kann eine Anfrage wie die folgende annehmen und die Abfrage schneller und mit größerer Genauigkeit ausführen. Die Fähigkeit, semantische Abfragen schnell und genau auszuführen, ist wichtig, wenn Sie Retrieval Augmented Generation verwenden möchten. { Get { MyCorpusTable(nearText: {concepts: ["artificial intelligence"]}) {snippet} } } Ein weiterer wichtiger Aspekt für Ihr benutzerdefiniertes Korpus ist die Sicherheit. Beim Zugriff auf Dokumente sollten die Zugriffsbeschränkungen für die Originaldokumente beachtet werden. (Es wäre bedauerlich, wenn ein Praktikant Zugriff auf die Finanzergebnisse des CFO erhalten könnte, die noch nicht an die Wall Street weitergegeben wurden.) Innerhalb Ihrer Vector-Datenbank sollten Sie die Autorisierung so einrichten, dass sie den Zugriffsebenen des Originalinhalts entspricht. Dies können Sie erreichen, indem Sie Ihre Vector-Datenbank in die Identity- und Access-Management-Lösung Ihres Unternehmens integrieren. Vektordatenbanken speichern im Kern unstrukturierte Daten. Daher sollten sie Ihren Data Lake als Speicherlösung verwenden. Erstellen einer Dokument-Pipeline Leider verfügen die meisten Organisationen nicht über ein einziges Repository mit sauberen und genauen Dokumenten. Vielmehr sind die Dokumente in vielen Formaten über die gesamte Organisation verteilt und befinden sich in verschiedenen Teamportalen. Der erste Schritt beim Aufbau eines benutzerdefinierten Korpus besteht daher darin, eine Pipeline zu erstellen, die nur Dokumente, die für die Verwendung mit Generative AI freigegeben wurden, in Ihre Vektordatenbank einfügt. Für große globale Organisationen könnte dies möglicherweise die schwierigste Aufgabe einer Generative AI-Lösung sein. Es ist üblich, dass Teams Dokumentationen im Entwurfsformat in ihren Portalen haben. Es kann auch Dokumente geben, die zufällige Überlegungen darüber darstellen, was sein könnte. Diese Dokumente sollten nicht Teil eines benutzerdefinierten Korpus werden, da sie das Unternehmen nicht genau darstellen. Leider ist das Filtern dieser Dokumente ein manueller Aufwand. Eine Dokumentpipeline sollte die Dokumente auch in Text umwandeln. Glücklicherweise können einige Open-Source-Bibliotheken dies für viele der gängigen Dokumentformate tun. Darüber hinaus muss eine Dokumentpipeline Dokumente in kleine Segmente aufteilen, bevor sie in der Vektordatenbank gespeichert werden. Dies liegt an Beschränkungen der Eingabeaufforderungsgröße, wenn diese Dokumente für Retrieval Augmented Generation verwendet werden, was in einem späteren Abschnitt erläutert wird. Feinabstimmung großer Sprachmodelle Wenn wir ein großes Sprachmodell feinabstimmen, trainieren wir es noch ein wenig mehr mit Informationen aus dem benutzerdefinierten Korpus. Dies könnte eine gute Möglichkeit sein, ein domänenspezifisches LLM zu erhalten. Diese Option erfordert zwar Rechenleistung, um die Feinabstimmung anhand Ihres benutzerdefinierten Korpus durchzuführen, sie ist jedoch nicht so aufwändig wie das Trainieren eines Modells von Grund auf und kann in einem überschaubaren Zeitrahmen abgeschlossen werden. Wenn Ihr Fachgebiet Begriffe enthält, die im alltäglichen Gebrauch nicht vorkommen, kann eine Feinabstimmung die Qualität der Antworten des LLM verbessern. Projekte, die beispielsweise Dokumente aus der medizinischen Forschung, der Umweltforschung und allem, was mit den Naturwissenschaften zu tun hat, verwenden, können von einer Feinabstimmung profitieren. Bei der Feinabstimmung wird die hochspezifische Umgangssprache Ihrer Dokumente in die parametrischen Parameter des Modells integriert. Die Vor- und Nachteile der Feinabstimmung sollten verstanden werden, bevor Sie sich für diesen Ansatz entscheiden. Nachteile Für die Feinabstimmung sind Rechenressourcen erforderlich. Eine Erklärbarkeit ist nicht möglich. Im Zuge der Weiterentwicklung Ihres Korpus müssen Sie regelmäßig mit neuen Daten eine Feinabstimmung vornehmen. Halluzinationen sind ein Problem. Sicherheit auf Dokumentebene ist unmöglich. Vorteile Der LLM verfügt durch Feintuning über Erkenntnisse aus Ihrem individuellen Corpus. Der Inferenzfluss ist weniger kompliziert als RAG. Während Feinabstimmung eine gute Möglichkeit ist, einem LLM die Sprache Ihres Geschäfts beizubringen, verwässert sie die Daten, da die meisten LLMs Milliarden von Parametern enthalten und Ihre Daten auf alle diese Parameter verteilt werden. Der größte Nachteil der Feinabstimmung besteht darin, dass eine Autorisierung auf Dokumentebene nicht möglich ist. Sobald ein Dokument zur Feinabstimmung verwendet wird, werden seine Informationen Teil des Modells. Es ist nicht möglich, diese Informationen basierend auf den Autorisierungsstufen des Benutzers einzuschränken. Sehen wir uns eine Technik an, die Ihre benutzerdefinierten Daten und parametrischen Daten zum Zeitpunkt der Inferenz kombiniert. Retrieval Augmented Generation (RAG) Retrieval Augmented Generation (RAG) ist eine Technik, die mit der gestellten Frage beginnt, eine Vektordatenbank verwendet, um die Fragen mit zusätzlichen Daten zu verbinden, und dann die Frage und die Daten zur Inhaltserstellung an ein LLM weiterleitet. Mit RAG ist keine Schulung erforderlich, da wir das LLM schulen, indem wir ihm relevante Textausschnitte aus unserem Korpus hochwertiger Dokumente senden. Das funktioniert folgendermaßen mit einer Frage-Antwort-Aufgabe: Ein Benutzer stellt eine Frage in der Benutzeroberfläche Ihrer Anwendung. Ihre Anwendung nimmt die Frage – insbesondere die darin enthaltenen Wörter – und durchsucht mithilfe einer Vektordatenbank Ihr Korpus hochwertiger Dokumente nach kontextrelevanten Textausschnitten. Diese Ausschnitte und die ursprüngliche Frage werden an das LLM gesendet. Dieses gesamte Paket – Frage plus Ausschnitte (Kontext) – wird als Eingabeaufforderung bezeichnet. Das LLM verwendet diese Informationen, um Ihre Antwort zu generieren. Dies mag albern erscheinen – wenn Sie die Antwort (die Ausschnitte) bereits kennen, warum sollten Sie sich dann mit dem LLM befassen? Denken Sie daran, dass dies in Echtzeit geschieht und das Ziel darin besteht, Text zu generieren – etwas, das Sie kopieren und in Ihre Recherche einfügen können. Sie benötigen das LLM, um den Text zu erstellen, der die Informationen aus Ihrem benutzerdefinierten Korpus enthält. Dies ist komplizierter als die Feinabstimmung. Allerdings kann eine Benutzerautorisierung implementiert werden, da die Dokumente (oder Dokumentausschnitte) zum Zeitpunkt der Inferenz aus der Vektordatenbank ausgewählt werden. Die Informationen in den Dokumenten werden nie Teil der parametrischen Parameter des Modells. Die Vor- und Nachteile von RAG sind unten aufgeführt. Nachteile Der Inferenzfluss ist komplizierter. Vorteile Der LLM verfügt über direktes Wissen aus Ihrem individuellen Corpus. Erklärbarkeit ist möglich. Eine Feinabstimmung ist nicht erforderlich. Durch die Untersuchung der Ergebnisse der Vektordatenbankabfragen werden Halluzinationen deutlich reduziert und können kontrolliert werden. Eine Autorisierung kann durchgeführt werden. Maschinelles Lernen (MLOps) Um die Bedeutung von MLOps besser zu verstehen, ist es hilfreich, die Modellerstellung mit der herkömmlichen Anwendungsentwicklung zu vergleichen. Die herkömmliche Anwendungsentwicklung, wie die Implementierung eines neuen Microservices, der einer Anwendung eine neue Funktion hinzufügt, beginnt mit der Überprüfung einer Spezifikation. Alle neuen Datenstrukturen oder Änderungen an vorhandenen Datenstrukturen werden zuerst entworfen. Das Design der Daten sollte sich nicht ändern, sobald mit der Codierung begonnen wird. Der Service wird dann implementiert und die Codierung ist die Hauptaktivität in diesem Prozess. Unit-Tests und End-to-End-Tests werden ebenfalls codiert. Diese Tests beweisen, dass der Code fehlerfrei ist und die Spezifikation korrekt implementiert. Sie können automatisch von einer CI/CD-Pipeline ausgeführt werden, bevor die gesamte Anwendung bereitgestellt wird. Das Erstellen und Trainieren eines Modells ist unterschiedlich. Der erste Schritt besteht darin, die Rohdaten und die erforderlichen Vorhersagen zu verstehen. ML-Ingenieure müssen zwar Code schreiben, um ihre neuronalen Netzwerke zu implementieren oder einen Algorithmus einzurichten, aber das Codieren ist nicht die wichtigste Aktivität. Wiederholtes Experimentieren ist die Hauptaktivität. Während des Experimentierens ändern sich das Design der Daten, das Design des Modells und die verwendeten Parameter. Nach jedem Experiment werden Metriken erstellt, die zeigen, wie das Modell während des Trainings abgeschnitten hat. Es werden auch Metriken für die Modellleistung im Vergleich zu einem Validierungssatz und einem Testsatz generiert. Diese Metriken werden verwendet, um die Qualität des Modells nachzuweisen. Sobald ein Modell zur Integration in eine Anwendung bereit ist, muss es verpackt und bereitgestellt werden. MLOps, kurz für Machine Learning Operations, ist eine Reihe von Verfahren und Tools, die diese Unterschiede angehen sollen. Experimentverfolgung und Zusammenarbeit sind die Funktionen, die am häufigsten mit MLOPs in Verbindung gebracht werden, aber die moderneren MLOPs-Tools der Branche können heute noch viel mehr. Sie können beispielsweise eine Laufzeitumgebung für Ihre Experimente bereitstellen und Modelle verpacken und bereitstellen, sobald sie zur Integration in eine Anwendung bereit sind. Nachfolgend finden Sie eine Obermenge der Funktionen, die in MLOps-Tools heute zu finden sind. Diese Liste enthält auch andere zu berücksichtigende Aspekte wie Support und Datenintegration. – MLOps-Techniken und -Funktionen entwickeln sich ständig weiter. Sie möchten ein Tool, das von einem großen Player unterstützt wird und sicherstellt, dass das Tool ständig weiterentwickelt und verbessert wird. Unterstützung durch einen großen Player – Experimente generieren viele strukturierte und unstrukturierte Daten. Idealerweise könnten diese im Data Warehouse und im Data Lake gespeichert werden. Viele MLOps-Tools gab es jedoch schon vor den Open Table Formats, die zum modernen Datalake führten, sodass die meisten eine separate Lösung für ihre strukturierten Daten haben. Moderne Datalake-Integration – Behalten Sie den Überblick über die Datensätze, Modelle, Hyperparameter und Metriken jedes Experiments. Die Experimentverfolgung sollte auch die Wiederholbarkeit erleichtern. Experimentverfolgung – ermöglichen Sie Teammitgliedern, die Ergebnisse aller von allen ML-Ingenieuren durchgeführten Experimente einzusehen. Erleichtern Sie die Zusammenarbeit – Verpacken Sie das Modell so, dass es von anderen Programmierumgebungen aus zugänglich ist. Modellverpackung – Bereitstellung von Modellen in den formalen Umgebungen einer Organisation. Sie benötigen dies nicht, wenn Sie einen Weg gefunden haben, Ihre Modelle in eine vorhandene CI/CD-Pipeline zu integrieren. Modellbereitstellung – Verwalten Sie alle Versionen aller Modelle. Modellregistrierung – Einige Tools bieten Features, mit denen Code so kommentiert werden kann, dass eine Funktion oder ein Modell als containerisierter Dienst zum Ausführen von Experimenten in einem Cluster bereitgestellt werden kann. Serverlose Funktionen – Einige MLOps-Tools zielen darauf ab, vollständige End-to-End-Funktionen bereitzustellen und verfügen über Funktionen, mit denen Sie Pipelines zum Abrufen und Speichern Ihrer Rohdaten erstellen können. Sie benötigen dies nicht, wenn Sie bereits über eine Datenpipeline verfügen. Datenpipeline-Funktionen – Die Möglichkeit, Ihre serverlosen Funktionen in einem gerichteten azyklischen Graphen zu orchestrieren. Ermöglicht auch die Planung und Ausführung von Trainingspipelines. Trainingspipeline-Funktionen Der Einfluss von GPUs auf Ihre KI-Dateninfrastruktur Eine Kette ist so stark wie ihr schwächstes Glied – und Ihre KI/ML-Infrastruktur ist nur so schnell wie Ihre langsamste Komponente. Wenn Sie Machine-Learning-Modelle mit GPUs trainieren, kann Ihr schwächstes Glied Ihre Speicherlösung sein. Das Ergebnis ist das, was wir das „Starving GPU-Problem“ nennen. Das Starving GPU-Problem tritt auf, wenn Ihr Netzwerk oder Ihre Speicherlösung Ihrer Trainingslogik Trainingsdaten nicht schnell genug bereitstellen kann, um Ihre GPUs voll auszulasten. Die Symptome sind ziemlich offensichtlich. Wenn Sie Ihre GPUs überwachen, werden Sie feststellen, dass sie nie annähernd voll ausgelastet sind. Wenn Sie Ihren Trainingscode instrumentiert haben, werden Sie feststellen, dass die gesamte Trainingszeit von IO dominiert wird. Leider gibt es schlechte Nachrichten für diejenigen, die mit diesem Problem kämpfen. GPUs werden immer schneller. Werfen wir einen Blick auf den aktuellen Stand der GPUs und einige Fortschritte, die bei ihnen erzielt werden, um zu verstehen, warum sich dieses Problem in den kommenden Jahren nur noch verschärfen wird. Der aktuelle Stand der GPUs GPUs werden immer schneller. Nicht nur die Rohleistung wird besser, auch Speicher und Bandbreite nehmen zu. Werfen wir einen Blick auf diese drei Merkmale der neuesten GPUs von Nvidia. , Die und das . A100 H100 H200 Grafikkarte LEISTUNG ERINNERUNG SPEICHERBANDBREITE A100 624 TFLOPS 40 GB 1.555 GB/s H100 1.979 TFLOPS 80 GB 3,35 TB/s H200 1.979 TFLOPS 141 GB 4,8 TB/s Hinweis: Die obige Tabelle verwendet die Statistiken, die mit einer PCIe-Sockellösung (Peripheral Component Interconnect Express) für den A100 und der SXM-Sockellösung (Server PCI Express Module) für den H100 und den H200 übereinstimmen. SXM-Statistiken gibt es für den A100 nicht. In Bezug auf die Leistung wird für den Vergleich die Floating Point 16 Tensor Core-Statistik verwendet. Einige vergleichende Beobachtungen zu den oben genannten Statistiken sind erwähnenswert. Erstens haben der H100 und der H200 die gleiche Leistung (1.979 TFLOPS), was 3,17-mal mehr ist als beim A100. Der H100 hat doppelt so viel Speicher wie der A100 und die Speicherbandbreite wurde um einen ähnlichen Betrag erhöht – was Sinn macht, da sich die GPU sonst selbst verhungern würde. Der H200 kann satte 141 GB Speicher verarbeiten und seine Speicherbandbreite hat sich im Vergleich zu den anderen GPUs ebenfalls proportional erhöht. Sehen wir uns jede dieser Statistiken genauer an und besprechen wir, was sie für maschinelles Lernen bedeuten. – Ein Teraflop (TFLOP) sind eine Billion (10^12) Gleitkommaoperationen pro Sekunde. Das ist eine 1 mit 12 Nullen dahinter (1.000.000.000.000). Es ist schwierig, TFLOPs mit dem IO-Bedarf in Gigabyte gleichzusetzen, da die Gleitkommaoperationen, die während des Modelltrainings auftreten, einfache Tensormathematik sowie erste Ableitungen der Verlustfunktion (auch Gradienten genannt) beinhalten. Relative Vergleiche sind jedoch möglich. Wenn wir uns die obigen Statistiken ansehen, sehen wir, dass der H100 und der H200, die beide 1.979 TFLOPS erreichen, dreimal schneller sind – und möglicherweise dreimal schneller Daten verbrauchen, wenn alles andere mithalten kann. Leistung – auch als Video-RAM oder Grafik-RAM bekannt. Der GPU-Speicher ist vom Hauptspeicher (RAM) des Systems getrennt und speziell für die intensiven grafischen Verarbeitungsaufgaben der Grafikkarte konzipiert. Der GPU-Speicher bestimmt die Batchgröße beim Trainieren von Modellen. In der Vergangenheit verringerte sich die Batchgröße, wenn die Trainingslogik von einer CPU auf eine GPU verschoben wurde. Da der GPU-Speicher jedoch in Bezug auf die Kapazität mit dem CPU-Speicher gleichzieht, wird die für das GPU-Training verwendete Batchgröße zunehmen. Wenn Leistung und Speicherkapazität gleichzeitig zunehmen, führt dies zu größeren Anfragen, bei denen jedes Gigabyte an Trainingsdaten schneller verarbeitet wird. GPU-Speicher – Stellen Sie sich die GPU-Speicherbandbreite als „Autobahn“ vor, die den Speicher und die Rechenkerne verbindet. Sie bestimmt, wie viele Daten pro Zeiteinheit übertragen werden können. So wie eine breitere Autobahn mehr Autos in einer bestimmten Zeit passieren lässt, ermöglicht eine höhere Speicherbandbreite die Übertragung von mehr Daten zwischen Speicher und GPU. Wie Sie sehen, haben die Entwickler dieser GPUs die Speicherbandbreite für jede neue Version proportional zum Speicher erhöht; daher wird der interne Datenbus des Chips nicht zum Engpass. Speicherbandbreite Objektspeicher für das Modelltraining optimieren Wenn Sie das Problem „Starving GPU“ haben, sollten Sie ein 100 GB-Netzwerk und NVMe-Laufwerke verwenden. Durch die Verwendung von MinIO mit einer solchen Konfiguration wurden 325 GiB/s bei GETs und 165 GiB/s bei PUTs mit nur 32 Knoten handelsüblicher NVMe-SSDs erreicht. jüngster Benchmark Mit der Entwicklung der Computerwelt und der Wir stellen fest, dass Serverkonfigurationen häufig mit 500 GB oder mehr DRAM ausgestattet sind. Bei größeren Bereitstellungen, selbst solchen mit ultradichten NVMe-Laufwerken, kann sich die Anzahl der Server multipliziert mit dem DRAM auf diesen Servern schnell summieren – oft auf viele TB pro Instanz. Dieser DRAM-Pool kann als verteilter gemeinsam genutzter Speicherpool konfiguriert werden und ist ideal für Workloads, die enorme IOPS und Durchsatzleistung erfordern. Aus diesem Grund haben wir MinIO Cache entwickelt, damit unsere Enterprise- und Enterprise Lite-Kunden ihre Infrastruktur so konfigurieren können, dass sie diesen gemeinsam genutzten Speicherpool nutzen können, um die Leistung für zentrale KI-Workloads – wie GPU-Training – weiter zu verbessern und gleichzeitig die volle Persistenz beizubehalten. Der Preis für DRAM ist stark gesunken Die Geschichte zweier Organisationen Als abschließendes Gedankenexperiment erzählen wir die Geschichte zweier Organisationen, die auf ihrer KI/ML-Reise sehr unterschiedliche Ansätze verfolgen. Organisation Nr. 1 hat eine Kultur der „iterativen Verbesserungen“. Sie glauben, dass alle großen Initiativen in kleinere, überschaubarere Projekte aufgeteilt werden können. Diese kleineren Projekte werden dann so geplant, dass jedes auf den Ergebnissen des vorherigen Projekts aufbaut, um immer komplexere Probleme zu lösen. Sie mögen es auch, wenn diese kleinen Projekte so organisiert sind, dass jedes einzelne einen Mehrwert für das Unternehmen liefert. Sie haben festgestellt, dass Projekte, bei denen es nur um die Verbesserung der Infrastruktur oder die Modernisierung von Software ohne neue Funktionen für das Unternehmen geht, bei den Führungskräften, die die Budgets kontrollieren, nicht sehr beliebt sind. Folglich haben sie gelernt, dass die Anforderung ausgefallener Speichergeräte und Computercluster für einen generativen KI-Proof of Concept nicht der beste Weg ist, um Infrastrukturverbesserungen und neue Softwarefunktionen zu orchestrieren. Vielmehr werden sie klein anfangen mit Infrastrukturprodukten, die mit dem Wachstum skalierbar sind – und sie werden mit einfachen KI-Modellen beginnen, damit sie ihre MLOPs-Tools einrichten und herausfinden können, wie sie mit vorhandenen DevOps-Teams und CI/CD-Pipelines zusammenarbeiten können. Organisation Nr. 2 hat eine „Shiny Objects“-Kultur. Wenn die neueste Idee in die Branche kommt, nimmt sie sich zuerst der bedeutendsten Herausforderung an, um ihre technische Leistungsfähigkeit unter Beweis zu stellen. Sie haben festgestellt, dass diese Projekte sowohl intern als auch extern sehr sichtbar sind. Wenn etwas kaputt geht, können kluge Leute es immer reparieren. Organisation Nr. 1 strukturierte ihr erstes Projekt, indem sie einen Teil ihrer KI-Dateninfrastruktur aufbaute, während sie an einem Empfehlungsmodell für ihre wichtigste E-Commerce-Site arbeitete. Das Empfehlungsmodell war relativ einfach zu trainieren. Es ist ein diskriminatives Modell, das Datensätze verwendet, die bereits in einer Dateifreigabe vorhanden sind. Am Ende dieses Projekts hatte das Team jedoch auch einen kleinen (aber skalierbaren) Modern Datalake aufgebaut, MLOPs-Tools implementiert und einige Best Practices für das Trainieren und Bereitstellen von Modellen eingeführt. Obwohl das Modell nicht kompliziert ist, hat es ihrer Site dennoch viel Effizienz verliehen. Sie nutzten diese positiven Ergebnisse, um Mittel für ihr nächstes Projekt zu erhalten, das eine generative KI-Lösung sein wird. Organisation Nr. 2 erstellte einen Chatbot für ihre E-Commerce-Site, der Kundenfragen zu Produkten beantwortete. Large Language Models sind ziemlich kompliziert – das Team war weder mit Fine-Tuning noch mit Retrieval Augmented Generation vertraut – daher konzentrierten sich alle Entwicklungszyklen für dieses Projekt darauf, schnell eine steile Lernkurve zu bewältigen. Als das Modell fertig war, lieferte es OK-Ergebnisse – nichts Spektakuläres. Leider musste es manuell in die Vorproduktions- und Produktionsumgebungen geladen werden, da keine MLOps-Tools für die Bereitstellung vorhanden waren. Dies führte zu etwas Reibereien mit dem DevOps-Team. Das Modell selbst hatte auch einige Stabilitätsprobleme in der Produktion. Der Cluster, in dem es lief, hatte nicht genug Rechenleistung für eine generative KI-Arbeitslast. Es gab einige Anrufe mit Schweregrad 1, die zu einer Notfallerweiterung des Clusters führten, damit das LLM bei starkem Datenverkehr nicht ausfiel. Nach dem Projekt wurde in einer Retrospektive festgestellt, dass sie ihre Infrastruktur erweitern mussten, wenn sie mit KI erfolgreich sein wollten. Ein Plan zum Aufbau Ihrer KI/ML-Dateninfrastruktur Die obige Kurzgeschichte ist eine einfache Erzählung zweier extremer Umstände. Das Erstellen von KI-Modellen (sowohl diskriminativ als auch generativ) unterscheidet sich erheblich von der herkömmlichen Softwareentwicklung. Dies sollte bei der Warteschlange für KI/ML-Aufgaben berücksichtigt werden. Die folgende Grafik ist eine visuelle Darstellung der im vorherigen Abschnitt erzählten Geschichte. Es handelt sich um einen direkten Vergleich des Ansatzes „AI Data Infrastructure First“ mit dem Ansatz „Model First“. Wie die obige Geschichte gezeigt hat, muss jeder der folgenden Bausteine für den Ansatz „Infrastructure First“ kein eigenständiges Projekt sein. Organisationen sollten nach kreativen Wegen suchen, um KI bereitzustellen, während ihre Infrastruktur aufgebaut wird – dies kann erreicht werden, indem man alle Möglichkeiten der KI versteht, einfach beginnt und dann KI-Projekte mit zunehmender Komplexität auswählt. Abschluss In diesem Beitrag beschreiben wir unsere Erfahrungen bei der Zusammenarbeit mit Unternehmen zum Aufbau einer modernen Datalake-Referenzarchitektur für KI/ML. Er identifiziert die Kernkomponenten, die wichtigsten Bausteine und die Vor- und Nachteile verschiedener KI-Ansätze. Das grundlegende Element ist ein moderner Data Lake, der auf einem Objektspeicher aufbaut. Der Objektspeicher muss in der Lage sein, Leistung in großem Maßstab zu liefern – wobei der Maßstab Hunderte von Petabyte und oft Exabyte beträgt. Wir gehen davon aus, dass der Benutzer durch Befolgen dieser Referenzarchitektur eine flexible, erweiterbare Dateninfrastruktur aufbauen kann, die zwar auf KI und ML ausgerichtet ist, aber bei allen OLAP-Workloads gleichermaßen leistungsfähig ist. Um spezifische Empfehlungen zu den Komponenten zu erhalten, wenden Sie sich bitte an mich unter . keith@min.io