Deep Recommendation Models (DLRMs) sind zum wichtigsten technischen Szenario für die Anwendung von Deep Learning in Internetunternehmen geworden, z. B. Videoempfehlung, Einkaufssuche, Werbe-Push und andere Verkehrsmonetarisierungsdienste, die das Benutzererlebnis und die Geschäftswerbung erheblich verbessert haben Wert. Allerdings stellen umfangreiche Benutzer- und Geschäftsdaten, häufige iterative Aktualisierungsanforderungen und hohe Schulungskosten große Herausforderungen für die DLRM-Schulung dar.
In DLRM müssen Sie zuerst eine Suche in der eingebetteten Tabelle (EmbeddingBags) durchführen und dann die nachgelagerte Berechnung abschließen. Eingebettete Tabellen machen oft mehr als 99 % des Speicherbedarfs in DLRM aus, aber nur 1 % der Berechnung. Mithilfe des GPU-On-Chip-Hochgeschwindigkeitsspeichers (High Bandwidth Memory) und der leistungsstarken Rechenleistung ist die GPU zur Mainstream-Hardware für das DLRM-Training geworden. Mit der Vertiefung der Forschung zu Empfehlungssystemen haben jedoch die wachsende Größe der Einbettungstabelle und der begrenzte GPU-Speicher einen erheblichen Widerspruch geschaffen. Wie man die GPU zum effizienten Trainieren sehr großer DLRM-Modelle nutzt und gleichzeitig die Einschränkungen der GPU-Speichermauer durchbricht, ist zu einem zentralen Problem im DLRM-Bereich geworden, das gelöst werden muss.
Colossal-AI hat zuvor erfolgreich heterogene Strategien eingesetzt, um die Parameterkapazität von NLP-Modellen, die auf derselben Hardware trainiert wurden, um das Hundertfache zu erhöhen, und hat sie kürzlich mithilfe des Software-Cache erfolgreich auf das Empfehlungssystem ausgeweitet (Cache)-Methode, um die Parameterkapazität des NLP-Modells um das Hundertfache zu erhöhen und eingebettete Tabellen dynamisch im GPU-Speicher zu speichern. Basierend auf dem Software-Cache-Design fügt Colossal-AI außerdem Pipeline-Prefetching hinzu, um den Aufwand für den Software-Cache-Abruf und die Datenverschiebung zu reduzieren, indem Trainingsdaten beobachtet werden, die in Zukunft eingegeben werden. Gleichzeitig wird das gesamte DLRM-Modell auf der GPU synchron aktualisiert und in Kombination mit der weit verbreiteten hybriden parallelen Trainingsmethode auf mehrere GPUs erweitert. Experimente zeigen, dass Colossal-AI nur 1 % der Einbettungsparameter in der GPU beibehalten muss und dennoch eine hervorragende End-to-End-Trainingsgeschwindigkeit aufrechterhalten kann. Im Vergleich zu anderen PyTorch-Lösungen wird der Grafikspeicherbedarf um eine Größenordnung reduziert, und eine einzelne Grafikkarte kann ein Empfehlungsmodell auf Terabyte-Ebene trainieren. Der Kostenvorteil ist erheblich. Zum Trainieren eines DLRM, das eine 91-GB-Embedding-Tasche einnimmt, werden beispielsweise nur 5 GB Videospeicher benötigt als RTX 3050, der nur etwa 2.000 Yuan kostet.
Open-Source-Adresse: https://github.com/hpcaitech/ColossalAI
Die Einbettungstabelle ordnet diskrete ganzzahlige Merkmale in kontinuierliche Gleitkomma-Merkmale zu Vektor, das Folgende Die Abbildung zeigt den Einbettungstabellen-Trainingsprozess in DLRM. Suchen Sie zunächst für jedes Merkmal in der Einbettungstabelle die Zeile, die der Einbettungstabelle entspricht, und verwenden Sie dann Reduktionsoperationen wie Max-, Mittel- und Summenoperationen, um sie in einen Merkmalsvektor umzuwandeln und an das nachfolgende dichte neuronale Netzwerk weiterzuleiten . Es ist ersichtlich, dass der Trainingsprozess für eingebettete Tabellen von DLRM hauptsächlich aus unregelmäßigen Speicherzugriffsvorgängen besteht und daher durch die Hardware-Speicherzugriffsgeschwindigkeit stark eingeschränkt ist.
Die eingebettete Tabelle von DLRM in Industriequalität kann Hunderte von GB oder sogar TB erreichen und damit die maximale Videospeicherkapazität von mehreren zehn GB einer einzelnen GPU bei weitem übertreffen. Es gibt viele Möglichkeiten, die Speicherwand einer einzelnen GPU zu durchbrechen und die Größe der eingebetteten Tabelle von DLRM zu erhöhen. Lassen Sie uns am Beispiel des in der folgenden Abbildung gezeigten Speicherhierarchiediagramms des GPU-Clusters die Vor- und Nachteile mehrerer gängiger Lösungen analysieren.
GPU-Modellparallelität: Die Einbettungstabelle wird aufgeteilt und im Speicher mehrerer GPUs verteilt, und die Zwischenergebnisse werden während des Trainings über das Verbindungsnetzwerk zwischen GPUs synchronisiert. Der Nachteil dieser Methode besteht darin, dass die Segmentierungslast der eingebetteten Tabelle nicht gleichmäßig ist und das Skalierbarkeitsproblem schwer zu lösen ist. Zweitens sind die anfänglichen Hardwarekosten für das Hinzufügen einer GPU hoch und die Rechenleistung der GPU wird während des DLRM-Trainings nicht vollständig genutzt, sondern nur der HBM-Bandbreitenvorteil genutzt, was zu einer geringen GPU-Auslastung führt.
CPU-Teiltraining: Teilen Sie die Einbettungstabelle in zwei Teile auf, ein Teil wird auf der GPU und der andere Teil auf der CPU trainiert. Indem wir den Long-Tail-Effekt der Datenverteilung nutzen, können wir den Anteil der CPU-Berechnungen so klein wie möglich und den Anteil der GPU-Berechnungen so groß wie möglich machen. Mit zunehmender Batch-Größe ist es jedoch schwierig, alle Mini-Batch-Daten auf die CPU oder GPU zu übertragen. Wenn die Daten gleichzeitig auf die CPU oder GPU gelangen, ist diese Methode schwierig zu handhaben. Da DDR-Bandbreite und HBM außerdem eine Datengröße voneinander entfernt sind, wird das gesamte System um mindestens die Hälfte verlangsamt, selbst wenn 10 % der Eingabedaten auf der CPU trainiert werden. Darüber hinaus müssen CPU und GPU Zwischenergebnisse übermitteln, was ebenfalls einen erheblichen Kommunikationsaufwand mit sich bringt und die Trainingsgeschwindigkeit weiter verlangsamt. Daher haben Forscher Methoden wie asynchrone Aktualisierungen entwickelt, um diese Leistungsmängel zu vermeiden. Asynchrone Methoden können jedoch zu Unsicherheiten bei den Trainingsergebnissen führen und sind in der Praxis nicht die erste Wahl von Algorithmenentwicklern.
Software-Cache: Stellt sicher, dass das gesamte Training auf der GPU durchgeführt wird. Die Einbettungstabelle wird in einem heterogenen Bereich aus CPU und GPU gespeichert. Jedes Mal werden die erforderlichen Teile über die Software-Cache-Methode in die GPU ausgelagert . Mit dieser Methode können Speicherressourcen kostengünstig erweitert werden, um den wachsenden Anforderungen eingebetteter Tabellen gerecht zu werden. Darüber hinaus wird im Vergleich zur Verwendung der CPU für die Berechnung der gesamte Trainingsprozess auf diese Weise vollständig auf der GPU abgeschlossen, wodurch die Vorteile der HBM-Bandbreite voll ausgenutzt werden. Allerdings führen Cache-Abfragen und Datenverschiebungen zu zusätzlichen Leistungseinbußen.
Es gibt bereits einige hervorragende Software-Cache-Lösungen zum Einbetten von Tabellen, sie verwenden jedoch häufig angepasste EmbeddingBags-Kernel-Implementierungen wie fbgemm oder verwenden Deep-Learning-Frameworks von Drittanbietern. Colossal-AI nimmt keine Änderungen auf Kernel-Ebene basierend auf dem nativen PyTorch vor und bietet eine Reihe sofort einsatzbereiter Software-Cache-EmbeddingBags-Implementierungen. Es optimiert den DLRM-Trainingsprozess weiter und schlägt eine Prefetch-Pipeline vor Reduzieren Sie den Cache-Overhead weiter.
Speicherhierarchie
Colossal-AI implementiert einen Software-Cache und packt ihn in nn.Module, damit Benutzer ihn in ihren eigenen Modellen verwenden können. . Die Einbettungstabelle von DLRM besteht im Allgemeinen aus EmbeddingBags, die aus mehreren Einbettungen bestehen und sich im CPU-Speicher befinden. Dieser Teil des Speicherplatzes wird als CPU-Gewicht bezeichnet. Ein kleiner Teil der Daten von EmbeddingBags wird im GPU-Speicher gespeichert, einschließlich der für das Training zu verwendenden Daten. Dieser Teil des Speicherplatzes wird als CUDA Cached Weight bezeichnet. Während des DLRM-Trainings müssen Sie zunächst die Zeilen der eingebetteten Tabelle ermitteln, die der Dateneingabe in den Mini-Batch für diese Iteration entsprechen. Wenn sich einige Zeilen nicht in der GPU befinden, müssen sie von der CPU-Gewichtung an den CUDA übertragen werden Zwischengespeichertes Gewicht. Wenn in der GPU nicht genügend Speicherplatz vorhanden ist, verwendet sie den LFU-Algorithmus, um die am wenigsten genutzten Daten basierend auf der historischen Häufigkeit des Zugriffs auf den Cache zu entfernen.
Um den Cache-Abruf zu implementieren, sind einige Hilfsdatenstrukturen erforderlich: Cached_idx_map ist ein eindimensionales Array, das die Entsprechung zwischen den Zeilennummern im CPU-Gewicht und dem CUDA-Cache-Gewicht sowie die Häufigkeit speichert Informationen zu den entsprechenden Zeilen, auf die auf der GPU zugegriffen wird. Das Verhältnis der zwischengespeicherten CUDA-Gewichtsgröße zur CPU-Gewichtsgröße wird „cache_ratio“ genannt und der Standardwert beträgt 1,0 %.
Cache wird vor jeder Iteration ausgeführt, um die Daten in CUDA Weight anzupassen, und zwar in drei Schritten. 🔜 Nummer, die von der CPU zur GPU verschoben werden muss, in der CPU-Gewichtszeilennummer. 🔜 entsprechend der Frequenz zu hoch.
Schritt 3: Daten verschieben:
Verschieben Sie die entsprechenden Zeilen in CUDA Cached Weight zu CPU Weight und dann die entsprechenden Zeilen in CPU Weight zu CUDA Weight.
Das Datenübertragungsmodul ist für die bidirektionale Übertragung von Daten zwischen CUDA Cached Weight und CPU Weight verantwortlich. Im Gegensatz zur ineffizienten zeilenweisen Übertragung wird zuerst der Cache und dann die zentralisierte Übertragung verwendet, um die PCI-e-Bandbreitennutzung zu verbessern. Im Speicher verstreute eingebettete Zeilen werden im lokalen Speicher des Quellgeräts zu zusammenhängenden Datenblöcken zusammengefasst. Die Blöcke werden dann zwischen CPU und GPU übertragen und an die entsprechenden Speicherorte im Zielspeicher verteilt. Das Verschieben von Daten in Blöcken kann die PCI-e-Bandbreitennutzung verbessern, und Merge- und Scatter-Vorgänge erfordern nur On-Chip-Speicherzugriffe für die CPU und GPU, sodass der Overhead nicht sehr groß ist.
Colossal-AI verwendet einen größenbeschränkten Puffer, um Daten zwischen CPU und GPU zu übertragen. Im schlimmsten Fall verfehlen alle Eingabe-IDs den Cache und es muss eine große Anzahl von Elementen übertragen werden. Um zu verhindern, dass der Puffer zu viel Speicher beansprucht, ist die Puffergröße streng begrenzt. Wenn die übertragenen Daten größer als der Puffer sind, wird die Übertragung mehrmals abgeschlossen.
Cached EmbeddingBag Workflow
Die oben genannten Cache-Vorgänge Schritt 1 und Schritt 2 sind beide speicherzugriffsintensiv. Um die Bandbreite von GPU-HBM zu nutzen, werden sie daher auf der GPU ausgeführt und mithilfe von APIs implementiert, die von Deep-Learning-Frameworks gekapselt sind. Dennoch ist der Overhead von Cache-Vorgängen im Vergleich zu Trainingsvorgängen auf der GPU zum Einbetten von Tabellen besonders groß.
Bei einer Trainingsaufgabe, die insgesamt 199 Sekunden dauert, beträgt der Overhead des Cache-Vorgangs beispielsweise 99 Sekunden, was fast 50 % der gesamten Rechenzeit ausmacht. Nach der Analyse wird der Hauptaufwand des Caches hauptsächlich durch Schritt 1 und Schritt 2 verursacht. Die Basisposition in der Abbildung unten zeigt die zeitliche Aufteilung des Cache-Overheads zu diesem Zeitpunkt. Die roten und orangefarbenen Phasen der Cache-Schritte 1 und 2 machen 70 % des gesamten Cache-Overheads aus.
Zeitliche Aufschlüsselung des Cache-Vorgangs
Der Grund für das oben genannte Problem ist, dass die herkömmliche Cache-Strategie etwas „kurzsichtig“ ist und den Cache nur an den aktuellen Stand anpassen kann Da es sich um eine Mini-Batch-Situation handelt, stellt dies ein großes Problem dar. Ein Teil der Zeit wird für Abfragevorgänge verschwendet.
Um den Cache-Overhead zu reduzieren, hat Colossal-AI einen „zukunftsorientierten“ Cache-Mechanismus entwickelt. Anstatt nur Cache-Vorgänge für den ersten Mini-Batch durchzuführen, ruft Colossal-AI mehrere Mini-Batches vorab ab, die später verwendet werden, und führt Cache-Abfragevorgänge auf einheitliche Weise durch.
Wie in der folgenden Abbildung dargestellt, verwendet Colossal-AI Prefetching, um mehrere Mini-Batch-Daten für einheitliche Cache-Vorgänge zusammenzuführen, und verwendet außerdem einen Pipeline-Ansatz, um den Overhead des Datenlesens und -berechnens zu überlappen. Im Beispiel beträgt die Prefetch-Mini-Batch-Nummer 2. Vor Beginn des Trainings werden die Mini-Batch-0,1-Daten von der Festplatte in den GPU-Speicher gelesen, dann wird der Cache-Vorgang gestartet und dann werden die Vorwärts- und Rückwärtspropagierung sowie Parameteraktualisierungen der beiden Mini-Batches durchgeführt. Gleichzeitig kann das anfängliche Datenlesen für Mini-Batch 2 und 3 durchgeführt werden, und dieser Overhead kann sich mit der Berechnung überschneiden.
Im Vergleich zur Baseline-Cache-Ausführungsmethode vergleicht die Abbildung [Zeitaufteilung der Cache-Vorgänge] die Cache-Zeitaufteilung von Prefetch 8 Mini-Batch und Baseline. Die gesamte Trainingszeit sank von 201 Sekunden auf 120 Sekunden, und auch der in der Abbildung dargestellte Anteil der Cache-Phasen-Betriebszeit sank deutlich. Es ist ersichtlich, dass im Vergleich zur unabhängigen Ausführung von Cache-Vorgängen durch jeden Mini-Batch die Zeit für jeden Teil verkürzt wird, insbesondere für die ersten beiden Schritte von Cache-Vorgängen.
Zusammenfassend lässt sich sagen, dass das Vorabrufen der Cache-Pipeline zwei Vorteile mit sich bringt.
a. Verringern Sie den Overhead des Cache-Index
Der offensichtlichste Vorteil des Vorabrufs besteht darin, den Overhead von Schritt 1 und Schritt 2 zu reduzieren, sodass dieser zweistufige Vorgang weniger als 5 % des gesamten Trainingsprozesses ausmacht. Wie in [Zeitaufschlüsselung der Cache-Vorgänge] gezeigt, wird durch das Vorabrufen von 8 Mini-Batch-Daten der Overhead der Cache-Abfrage im Vergleich zur Basislinie ohne Vorabruf erheblich reduziert.
b. Erhöhen Sie die Datenübertragungsbandbreite zwischen CPU und GPU.
Verbessern Sie die Granularität der Datenübertragung, indem Sie mehr Daten konzentrieren und so die Übertragungsbandbreite zwischen CPU und GPU voll ausnutzen. Für das obige Beispiel wird die CUDA->CPU-Bandbreite von 860 MB/s auf 1477 MB/s und die CPU->CUDA-Bandbreite von 1257 MB/s auf 2415 MB/s erhöht, was den Leistungsgewinn fast verdoppelt.
Die Verwendung ist die gleiche wie bei Pytorch EmbeddingBag. Beim Erstellen eines Empfehlungsmodells sind nur die folgenden Codezeilen für die Initialisierung erforderlich, wodurch die Kapazität der Einbettungstabelle erheblich erhöht und eine große Empfehlung auf TB-Ebene erreicht werden kann Modellschulung zu geringen Kosten.
Bashfrom colossalai.nn.parallel.layers.cache_embedding import CachedEmbeddingBag emb_module = CachedEmbeddingBag(num_embeddings=num_embeddings,embedding_dim=embedding_dim,mode="sum"include_last_offset=True,sparse=True,_weight=torch.randn(num_embeddings, embedding_dim),warmup_ratio=0.7,cache_ratio = 0.01,)
Auf den Hardwareplattformen NVIDIA A100 GPU (80 GB) und AMD EPYC 7543 32-Core-Prozessor (512 GB) verwendet Colossal-AI das DLRM-Modell von Meta als Testziel und nutzt dabei die extrem großen Datenmengen Set Cretio 1 TB und Metas dlrm_datasets generieren Datensätze als Testmodelle. Im Experiment wird die PyTorch-Trainingsgeschwindigkeit zum Speichern aller Einbettungstabellen auf der GPU als Basis verwendet.
Cretio 1 TB
Die Einbettungstabelle von Cretio 1 TB hat insgesamt 177944275 Zeilen, wobei Einbettungsdim=128 eingestellt ist, und der Speicherbedarf für die Einbettungstabelle beträgt 91,10 GB. Selbst die hochwertigste NVIDIA A100 80 GB kann die Speicheranforderungen für die Speicherung aller EmbeddingBags in einem einzigen GPU-Speicher nicht erfüllen.
Aber mit Colossal-AI wird das Training immer noch auf einer einzelnen GPU durchgeführt. Bei einem Cache-Verhältnis von 0,05 beträgt der Speicherverbrauch nur 5,01 GB, was sich direkt um das 18-fache reduziert Empfehlungssystem auf Terabyte-Ebene auf einer einzelnen GPU. In Bezug auf die Trainingsgeschwindigkeit zeigt die folgende Abbildung die Verzögerung beim Training von 100 Millionen Proben unter verschiedenen Chargengrößen. Der grüne Prefetch1 ist die Verzögerung ohne Prefetch und der blaue Prefetch8 ist die Verzögerung mit Prefetch (Prefetch Mini-Batch = 8). Es ist ersichtlich, dass die Prefetch-Pipeline-Optimierung eine wichtige Rolle bei der Verbesserung der Gesamtleistung spielt. Der dunkle Teil jeder Spalte in der Abbildung ist der Cache-Overhead. Nach Verwendung des Prefetching wird der Cache-Overhead innerhalb von 15 % der gesamten Trainingszeit kontrolliert.
Multi-GPU-Skalierbarkeit
Verwenden Sie 8192 als globale Stapelgröße, verwenden Sie tabellenweises Sharding als EmbeddingBags auf 8 GPU-Karten, um DLRM parallel zu trainieren, und trainieren Sie 100 Millionen Proben. Stellen Sie zu diesem Zeitpunkt die Prefetch-Größe auf 4 ein, ColossalAI-mem-cr0.05 hat ein Cache-Verhältnis von 0,05 und ColossalAI-mem-cr0.5 = 0,5. Die folgende Abbildung zeigt die Trainingslatenz für verschiedene GPU-Szenarien. Abgesehen davon, dass PyTorch OOM bei Verwendung einer GPU nicht trainiert werden kann, sind die Trainingszeiten von PyTorch und Colossal-AI in anderen Fällen ähnlich. Es ist zu beobachten, dass die Verwendung von 4 und 8 GPUs keine wesentlichen Leistungsverbesserungen mit sich bringt. Dies liegt daran, dass 1. die Synchronisierung der Ergebnisse einen enormen Kommunikationsaufwand erfordert. 2. Tabellenweises Sharding führt zu einem Ungleichgewicht der Sharding-Last. Es zeigt auch, dass die Verwendung mehrerer GPUs zur Erweiterung der Skalierbarkeit des Embedding-Table-Trainings nicht sehr gut ist.
Das Bild unten zeigt die Videospeichernutzung. Die Videospeichernutzung ist auf verschiedenen Karten unterschiedlich. Der maximale Videospeicherwert wird hier angezeigt. Wenn nur eine GPU verwendet wird, kann nur die Software-Cache-Methode von Colossal-AI trainiert werden, und auch der von mehreren Karten parallel belegte Speicher wird um ein Vielfaches deutlich reduziert.
Der synthetische Datensatz dlrm_datasets von Meta Research imitiert das Trainingszugriffsverhalten eingebetteter Tabellen in der Industrie und wird daher häufig als Testreferenz für Software- und Hardwaredesigns im Zusammenhang mit Empfehlungssystemen in der Forschung verwendet. Wählen Sie 500 Millionen Zeilen eingebetteter Tabellenelemente als Unterdatensatz aus und erstellen Sie zum Testen zwei EmbeddingBags mit 256 GB und 128 GB.
PyTorch kann aufgrund unzureichenden Videospeichers nicht auf einer einzelnen A100-Karte trainiert werden. Im Gegensatz dazu wird der Software-Cache von Colossal-AI den GPU-Speicherbedarf erheblich reduzieren, sodass genug Einbettungstabellen mit einer Größe von bis zu 256 GB trainiert werden können, und er kann weiter auf TB-Ebene erweitert werden. Darüber hinaus kann das Pipeline-Prefetching auch Beschleunigungseffekte zeigen. Wenn die Anzahl der Prefetches 32 beträgt, wird die Gesamtzeit im Vergleich zu keinem Prefetching um 60 % reduziert und der Bedarf an GPU-Speicher steigt nicht.
One More Thing
Colossal-AI, ein allgemeines Deep-Learning-System für das Zeitalter großer Modelle, nutzt eine Reihe selbst entwickelter führender Technologien wie effiziente mehrdimensionale automatische Parallelität, heterogen Speicherverwaltung und umfangreiche Optimierungsbibliotheken, adaptive Aufgabenplanung usw., um eine effiziente und schnelle Bereitstellung von Training und Inferenz für große KI-Modelle zu erreichen und die Kosten für die Anwendung großer KI-Modelle zu senken.
Colossal-AI-bezogene Lösungen wurden von namhaften Herstellern in den Bereichen autonomes Fahren, Cloud Computing, Einzelhandel, Medizin, Chips und anderen Branchen erfolgreich implementiert und erhielten viel Lob.
Colossal-AI konzentriert sich auf den Aufbau von Open-Source-Communitys, bietet chinesische Tutorials, eröffnet Benutzer-Communities und Foren, führt effiziente Kommunikation und iterative Aktualisierungen für Benutzer-Feedback durch und fügt kontinuierlich hochmoderne Anwendungen wie PaLM, AlphaFold und OPT hinzu.
Da es von Natur aus Open Source war, belegte Colossal-AI auf GitHub- und Papers With Code-Hotlists viele Male den ersten Platz weltweit und hat zusammen mit vielen Star-Open-Source-Projekten mit Zehntausenden im In- und Ausland Aufmerksamkeit erregt von Sternen!
Open-Source-Adresse des Projekts: https://github.com/hpcaitech/ColossalAI
Das obige ist der detaillierte Inhalt vonEs werden nur 1 % der Einbettungsparameter benötigt, die Hardwarekosten werden um das Zehnfache reduziert und die Open-Source-Lösung mit einer einzelnen GPU trainiert ein großes empfohlenes Modell. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
Was sind Zeichenkonstanten?
Der Computer friert ein. Der Bildschirm bleibt hängen
Die Rolle von index.html
Was bedeutet OEM?
Wie tippe ich die Inschrift auf dem Münzkreis ein?
So aktualisieren Sie den DNS-Cache
So lösen Sie das Problem, dass Tomcat die Seite nicht anzeigen kann
Ajax-Lösung für verstümmelten chinesischen Code
