WeChats groß angelegte Trainingspraxis für Empfehlungssysteme basierend auf PyTorch

In diesem Artikel wird das umfangreiche Empfehlungssystemtraining von WeChat auf Basis von PyTorch vorgestellt. Im Gegensatz zu einigen anderen Deep-Learning-Bereichen verwendet das Empfehlungssystem immer noch Tensorflow als Trainingsframework, was von der Mehrheit der Entwickler kritisiert wird. Obwohl es einige Praktiken gibt, die PyTorch für das Empfehlungstraining verwenden, ist der Umfang gering und es gibt keine tatsächliche Geschäftsüberprüfung, was es schwierig macht, frühe Unternehmensanwender zu fördern.

Im Februar 2022 startete das PyTorch-Team die offiziell empfohlene Bibliothek TorchRec. Unser Team begann im Mai, TorchRec im internen Geschäft auszuprobieren und startete eine Reihe von Kooperationen mit dem TorchRec-Team. Während des mehrmonatigen Testeinsatzes haben wir viele Vorteile von TorchRec erfahren und sind auch der Meinung, dass TorchRec bei sehr großen Modellen noch einige Mängel aufweist. Als Reaktion auf diese Mängel haben wir erweiterte Funktionen entwickelt, um die Probleme zu beheben. Im September 2022 wurde die von uns entwickelte dynamische Einbettung mit erweiterten Funktionen offiziell in den Hauptzweig von TorchRec integriert und wird weiterhin kontinuierlich mit dem offiziellen Team optimiert. #🎜🎜 ## 🎜🎜 ## 🎜🎜 ## 🎜🎜 ## 🎜🎜 ## 🎜🎜 ## 🎜🎜 ## 🎜🎜 ## 🎜🎜 ## 🎜🎜 ## 🎜🎜 ## 🎜🎜#1. Was kann TorchRec uns bringen? Wir alle wissen, dass Empfehlungssysteme oft direkt mit dem Cashflow des Unternehmens verknüpft sind und die Kosten für Versuch und Irrtum sehr hoch sind. Daher benötigt jeder ein Framework, das von Unternehmen getestet wurde. Aus diesem Grund wurden einige frühere Empfehlungsframeworks, die auf PyTorch basieren, nicht weit verbreitet verwendet. Als offizielles Empfehlungs-Framework wurde TorchRec im Januar 2022 eingeführt. Meta hatte damit bereits erfolgreich ein 125-Milliarden-Parameter-Modell für das Instagram-Reels-Geschäft trainiert und eingeführt und sich so zu einem geschäftserprobten PyTorch-Framework entwickelt. Mit der Unterstützung eines großen Unternehmens wie Instagram haben wir mehr Vertrauen und können endlich die Vorteile eines auf PyTorch basierenden Empfehlungsframeworks rational berücksichtigen.

TorchRec ist für verschiedene Teammitglieder unterschiedlich . Erstens ermöglicht das von PyTorch empfohlene Framework für die überwiegende Mehrheit der Algorithmeningenieure im Team endlich alle, die benutzerfreundlichere dynamische Grafik- und Debugging-Erfahrung zu genießen, die CV- und NLP-Ingenieure erleben.

Darüber hinaus verfügt PyTorch über eine hervorragende Kompatibilität – ein auf PyTorch1.8 basierendes Modell muss keine Codezeile ändern auf der neuesten Version 1.13 – so können Algorithmeningenieure das Framework endlich mit Zuversicht aktualisieren, um in den Genuss der neuesten Framework-Funktionen und einer besseren Leistung zu kommen. Andererseits bleiben einige empfohlene Frameworks, die auf TensorFlow basieren, häufig bei einer bestimmten Version von TensorFlow hängen. Beispielsweise verwenden viele Teams möglicherweise immer noch interne Frameworks, die auf TensorFlow 1.x basieren. TensorFlow 1.x hat die Wartung im Januar 2021 eingestellt, was bedeutet, dass in den letzten zwei Jahren nicht alle neuen Fehler und neuen Funktionen gut unterstützt werden. Während der Nutzung auftretende Probleme können nur durch das interne Wartungsteam behoben werden, was zusätzliche Kosten verursacht. Rechtzeitige Framework-Upgrades können auch kostenlose Geschwindigkeitsverbesserungen mit sich bringen. Höhere Versionen von PyTorch passen häufig zu höheren Versionen von CUDA sowie zu einigen neuen Funktionen wie CUDA Graph, die die Trainingsgeschwindigkeit weiter erhöhen und die Trainingseffizienz verbessern können.

Neben den Algorithmeningenieuren ist auch das Framework-Team ein wichtiger Teil des Empfehlungsteams. Das Framework-Team im Unternehmen führt nach Auswahl des Open-Source-Frameworks eine Sekundärentwicklung basierend auf internen Anforderungen durch. Für sie führt ein empfohlenes Framework für PyTorch zu einer optimierten Entwicklungserfahrung. Viele traditionelle, von TensorFlow empfohlene Frameworks imitieren TF und dienen dazu, eine Erweiterung basierend auf einer C++-Sitzung zu erstellen – diese Designlösung galt damals als sehr fortschrittliche Lösung –, aber dies erfordert eine vollständige Kompilierung des gesamten TensorFlow, nur um eine Codezeile zu ändern ist zeitaufwändig Es ist sehr lang und muss sogar triviale Probleme lösen, wie das Herunterladen externer Abhängigkeiten im Intranet, und die Entwicklungserfahrung ist nicht sehr gut.

Bei der Verwendung von PyTorch werden Sie nicht auf solche Probleme stoßen, da PyTorch die Python-Philosophie als Kern nimmt und hofft, dass jeder sie frei erweitern kann. Wenn wir eine Sekundärentwicklung durchführen, müssen wir sie nur mit einer relativ ausgereiften Python-Bibliothek wie pybind11 kapseln, unsere Bibliothek in eine dynamische Linkbibliothek packen und dann kann sie geladen werden. Auf diese Weise wird die Kompilierungsgeschwindigkeit insgesamt natürlich viel schneller und die Lernkosten werden viel geringer sein.

Wie bereits erwähnt, ist PyTorch ein Framework mit sehr guter Abwärtskompatibilität. Dadurch ist es nicht mehr erforderlich, dass das Wartungsteam mehrere Versionen verwaltet, und jeder kann sich auf bestimmte Probleme konzentrieren Je nach Bedarf wird die Effizienz der Teammitglieder deutlich verbessert.

Die oben genannten Vorteile von TorchRec als PyTorch-Empfehlungsframework. Was uns sehr freut, ist, dass das TorchRec-Team nicht damit aufgehört hat, ein PyTorch-Empfehlungsframework zu erstellen. Sie beobachteten die Eigenschaften bestehender Empfehlungsmodelle und Hardware und fügten dem Framework viele neue Funktionen hinzu, was TorchRec einen klaren Leistungsvorteil gegenüber herkömmlichen Empfehlungs-Frameworks verschaffte. Als nächstes werde ich einige davon zur Einführung auswählen, nämlich die GPU-Einbettung, den hervorragenden GPU-Kernel in TorchRec und die Einbettungsabteilung, die TorchRec basierend auf der Netzwerkkommunikation durchführen kann.

​Das erste ist die GPU-Einbettung. Lassen Sie uns zunächst den GPU-Trainingsprozess des herkömmlichen Empfehlungssystems überprüfen. Wir werden das spezifische Modell auf dem GPU-Worker ablegen und die Einbettung auf dem Remote-PS speichern. Bei jedem Iterationsschritt werden zunächst Parameter vom Remote-PS abgerufen, dann Vorwärts- und Rückwärtsberechnungen des Modells auf der GPU durchgeführt, der Gradient zurück zum PS übertragen und die Parameter auf dem PS aktualisiert.

Der grüne Teil im Bild ist der auf der GPU ausgeführte Vorgang und der rote Teil wird im Netzwerk oder auf der CPU ausgeführt. Es ist ersichtlich, dass die GPU zwar der teuerste Teil des Systems ist, viele Vorgänge jedoch nicht auf der GPU abgelegt werden. ​

Der herkömmliche Prozess nutzt die GPU nicht vollständig aus. Gleichzeitig wird aus Hardware-Sicht der Speicher einer einzelnen GPU-Karte immer größer, und einige dichte Modelle nutzen die GPU bei weitem nicht vollständig aus. Durch die kontinuierliche Optimierung von NVIDIA haben sich auch NV-Link und GPU-Direkt-RDMA verbessert -Kartenkommunikation immer schneller.

GPU-Einbettung ist eine sehr einfache Lösung. Er teilt die Einbettung direkt auf und platziert sie auf der GPU. Wenn sich beispielsweise 8 Karten auf einem einzelnen Computer befinden, teilen wir die Einbettung direkt in 8 Teile auf und platzieren jeden Teil auf einer Karte. So stellen wir sicher, dass alle Vorgänge auf der Karte verbleiben . . Die Nutzungseffizienz der GPU wird erheblich verbessert und auch die Trainingsgeschwindigkeit wird qualitativ verbessert. Wenn Sie sich Sorgen über unzureichenden Videospeicherplatz auf der GPU machen, unterstützt TorchRec auch UVM, das als Ergänzung zum Videospeicher einen Teil des Speichers im Voraus auf dem Host aufteilen kann, wodurch die Einbettungsgröße erhöht wird, die in a platziert werden kann Einzelmaschine.

Neben der GPU-Einbettung implementiert TorchRec auch einen sehr hervorragenden GPU-Kernel. Diese Kernel nutzen die neuesten Hardwarefunktionen und CUDA-Funktionen voll aus.

Wenn Sie beispielsweise einen Einbettungs-Suchkernel implementieren möchten, das heißt, Sie müssen eine Reihe von Einbettungsvektoren finden, die IDs aus einer großen Einbettung entsprechen, dann wird dies in einer normalen Implementierung jeder GPU-Thread tun Vergeben Sie eine ID und lassen Sie sie jeweils die entsprechende Einbettung finden. Zu diesem Zeitpunkt müssen wir berücksichtigen, dass die unterste Ebene der GPU gemäß Warp geplant ist und die 32 Threads in einem Warp den Videospeicher gemeinsam lesen und schreiben. Dies bedeutet, dass im obigen Prozess beim Lesen der ID zwar kontinuierlich auf den Videospeicher zugegriffen wird, nachfolgende Kopien jedoch in einen zufälligen Lese- und Schreibzustand übergehen. Bei Hardware kann das zufällige Lesen und Schreiben die Speicherbandbreite nicht vollständig nutzen und die Betriebseffizienz ist nicht hoch genug.

TorchRec verwendet Warp-Primitive wie shuffle_sync, um die ID nach dem Lesen der ID in jedem Thread an alle Threads im Warp zu senden, sodass 32 Threads in einem Wrap sie gleichzeitig mit derselben Einbettung verarbeiten können Es kann ein kontinuierliches Lesen und Schreiben des Speichers durchgeführt werden, was die Bandbreitennutzungseffizienz des Videospeichers erheblich verbessert und die Geschwindigkeit des Kernels um ein Vielfaches erhöht.

Diese Tabelle ist ein offizieller Test zur Leistungsverbesserung bei der Einbettungssuche. Hier ist Fused EBC der optimierte Kernel. Es ist ersichtlich, dass TorchRec im Vergleich zum nativen PyTorch eine Dutzendfache Leistungssteigerung aufweist. Basierend auf TorchRec haben wir festgestellt, dass bei relativ kleinen Einbettungen (weniger als 128) möglicherweise die Hälfte oder sogar mehr Threads inaktiv sind. Daher gruppieren wir die Threads im Warp weiter und lassen sie mehrere Einbettungen gleichzeitig verarbeiten.

Mit unseren Verbesserungen wurde der Kernel bei kleinen Einbettungsdimmungen um 10 % bis 30 % verbessert. Diese Optimierung wurde auch in das offizielle Repo übernommen. Es ist zu beachten, dass der Kernel von TorchRec in der FBGEMM-Bibliothek abgelegt ist. Interessierte Freunde können einen Blick darauf werfen.

Abschließend möchte ich den Einbettungsteilungsmechanismus von TorchRec vorstellen. Wie bereits erwähnt, besteht die GPU-Einbettung darin, die Einbettung zu teilen und auf der Karte abzulegen. Daher ist die Frage, wie sie aufgeteilt werden soll, eine Frage, die berücksichtigt werden muss. Traditionell gibt es zwei Aufteilungsideen: zeilenweise und spaltenweise. Zeilenweise bedeutet, dass bei 20.000 Merkmalen die Zahlen 0 bis 10.000 auf Karte 1 und die Zahlen 10.000 bis 20.000 auf Karte 2 platziert werden. Wenn wir also trainieren und die ID Karte 1 entspricht, beginnen wir mit Nimm es von Karte 1, und wenn es Karte 2 entspricht, nimm es von Karte 2. Das Problem bei Row Wise besteht darin, dass die Kommunikation unausgeglichen ist und die Netzwerkhardware nicht vollständig ausgenutzt werden kann, da wir nicht wissen, ob zwischen dem Verkehrsaufkommen der ersten 10.000 Nummern und den letzten 10.000 Nummern eine große Lücke besteht.

Spaltenweise ist im Hinblick auf die Einbettungslänge unterteilt. Die Gesamtlänge der Einbettung beträgt beispielsweise 128. Die ersten 64 Dimensionen und die letzten 64 Dimensionen können an unterschiedlichen Positionen platziert werden. Auf diese Weise wird die Kommunikation ausgewogener, beim Lesen muss jedoch mit allen Karten oder PSs kommuniziert werden .

Der Unterschied im Divisionsmodus führt zu Kompromissen bei der Auswahl. Herkömmliche Empfehlungs-Frameworks legen die Einbettungs-Divisionsmethode im Design fest, während TorchRec mehrere Divisionsmethoden unterstützt – wie z. B. zeilenweise, spaltenweise, sogar tabellenweise, Datenparallelität – und intern solche wie Planner, Estimator, PerfModel und andere Module automatisch bereitstellt Berechnen Sie die Teilungsmethode basierend auf Bandbreite, Videospeicher, Speicher, Modellgröße und anderen Parametern des Nutzungsszenarios. Auf diese Weise kann die Einbettung am effizientesten entsprechend unseren tatsächlichen Hardwarebedingungen aufgeteilt und die Hardware am effizientesten genutzt werden. Die meisten dieser Funktionen sind in Python implementiert. Dadurch können wir es an unsere interne Umgebung anpassen und auf einfache Weise ein Empfehlungssystem erstellen, das für unsere interne Umgebung am besten geeignet ist.

2. Experimentelle Ergebnisse an zig Milliarden Modellen

In unseren Experimenten wird TorchRec im Standardmodus wie DeepFM und DCN eine erstaunliche 10- bis 15-fache Leistungsverbesserung im Vergleich zum vorherigen Benchmark-Empfehlungsrahmen erzielen. Die Erzielung solcher Leistungssteigerungen gibt uns die Zuversicht, TorchRec ins Geschäft zu bringen.

Für das WeChat-Lese-Feineinstellungsmodell, in Hinsichtlich der Ausrichtungsgenauigkeit haben wir festgestellt, dass sich die Leistung bei echten Daten um etwa das Dreifache und bei gefälschten Daten sogar um etwa das Zehnfache verbessert. Der Unterschied besteht darin, dass das Auslesen von Daten für das Training zu einem Engpass geworden ist und wir diesbezüglich noch weitere Optimierungen vornehmen.

03

# 🎜🎜#Die Mängel der ursprünglichen Lösung bei Modellen von 100 Milliarden und mehr

#🎜 🎜 #

Bei den zuvor eingeführten Modellen handelt es sich im Grunde um Modelle im zweistelligen Milliardenbereich oder weniger, also um Modelle, die auf einer einzigen Maschine platziert werden können. Als wir TorchRec auf größere Modelle umstellten, stellten wir einige Probleme mit dem nativen Design von TorchRec fest. Für große Modelle erfordert die reine GPU-Einbettungslösung von TorchRec mehr Karten – vielleicht kann die ursprüngliche Trainingsgeschwindigkeit von 8 Karten alle Daten absorbieren, aber wir müssen 16 Karten verwenden, um die Einbettung vorzunehmen, was eine Verbesserung der GPU-Hardware erschwert Die Auslastungseffizienz ist erneut gesunken.

Und für große Modellszenarien schlägt das Algorithmenteam häufig die Notwendigkeit des dynamischen Hinzufügens und Löschens von Einbettungen vor, beispielsweise das Löschen von IDs auf die seit einer Woche nicht zugegriffen wurde. Die Lösung von TorchRec unterstützt eine solche Funktion nicht. Darüber hinaus sind in sehr großen Modellunternehmen in der Regel viele Teams beteiligt, und die Migration des Grundgerüsts stößt auf großen Widerstand. Was wir brauchen, ist die Unterstützung einer schrittweisen und schrittweisen Migration, und wir können nicht zulassen, dass alle die anstehende Arbeit aufgeben. Das wäre zu kostspielig und riskant.

Basierend auf den oben genannten Anforderungen überlegen wir, wie wir TorchRec modifizieren können Es ist in der Lage, sich an sehr große Modellszenarien anzupassen. Wir glauben, dass es bei Schulungen im extrem großen Maßstab immer noch notwendig ist, Remote-PS-Verbindungen zu unterstützen, da die Remote-CPU-PS sehr ausgereift ist und das dynamische Hinzufügen von Einbettungen problemlos unterstützen kann. Gleichzeitig kann PS für die teamübergreifende Zusammenarbeit verwendet werden, um Training und Inferenz zu isolieren und eine schrittweise Migration zu erreichen.

Dann ist die nächste Frage, wie man PS einführt. Wenn der PS direkt mit der GPU-Einbettung verbunden ist, muss bei jedem Iterationsschritt weiterhin auf den Remote-PS zugegriffen werden, wodurch sich der Anteil des gesamten Netzwerks und der CPU-Operationen erhöht und die GPU-Auslastung erneut reduziert wird. 04 machte einen sehr kleinen Teil der Gesamtdaten aus. Für einen kleinen Teil erwähnte HugeCTR in dem Papier auch ähnliche Schlussfolgerungen: Nur auf einen kleinen Teil der IDs wird häufig zugegriffen. Aus diesem Grund haben wir darüber nachgedacht, die GPU-Einbettung für das normale Training zu verwenden und dann IDs stapelweise an PS zu übertragen, wenn der Anzeigespeicher voll ist.

Nach dieser Idee können nur n IDs in der GPU-Einbettung gespeichert werden und die Gesamtzahl der IDs ist N oder sogar unendlich. Die globale ID kann der Reihe nach auf 0, 1, 2, 3 ... abgebildet werden, und die Zuordnungsbeziehung wird in einer Struktur namens ID-Transformation gespeichert, sodass die GPU-Einbettung die Zuordnungsergebnisse für das normale Training verwenden kann. Wenn die GPU-Einbettung vollständig ist, d. h. wenn der ID-Transformer n Zuordnungspaare enthält, werden IDs stapelweise an PS verdrängt.

Bei diesem Design kann PS selten eingreifen, und GPU-Worker und PS-Kommunikation sind nur beim Entfernen erforderlich.

Darüber hinaus muss PS in diesem Design nur als KV verwendet werden und muss keine Parameteraktualisierungen unterstützen, sodass das PS-Team keine optimierungsbezogenen Vorgänge implementieren muss sich auf speicherbezogene Arbeiten zu konzentrieren. Wir unterstützen auch Plug-Ins, die beliebige KV-Speicher implementieren, und die Open-Source-Version verfügt über ein integriertes Redis-Plug-In, sodass Redis auch als PS verwendet werden kann.

Hier einige Designdetails zur dynamischen Einbettung. Der einfachste und grundlegendste ID-Transformer, den wir implementiert haben, verwendet tatsächlich eine Hash-Tabelle und verwendet die leistungsstarke ska::flat_hash_map in PyTorch.

Als einziger CPU-Vorgang im Prozess stellt ID Transformer möglicherweise relativ hohe Leistungsanforderungen. Daher haben wir auch eine Hochleistungsversion implementiert, die in L1-Cacheline-Einheiten gespeichert ist, um die Effizienz des Speicherzugriffs weiter zu verbessern .

Darüber hinaus hoffen wir für das Räumungsschema, LRU und LFU effizient zu verschmelzen, ohne den Speicher-Cache-Druck zu erhöhen. Inspiriert durch die LFU-Lösung von Redis haben wir einen probabilistischen Algorithmus entworfen: Nur der Index der ID-Zugriffshäufigkeit wird gespeichert. Bei einem 32-maligen Zugriff werden beispielsweise 5 gespeichert. Wenn bei der Aktualisierung der Häufigkeit erneut auf diese ID zugegriffen wird, wird eine 5-stellige Zufallszahl generiert. Wenn alle 5 Ziffern 0 sind, d. h. ein Ereignis mit einer Wahrscheinlichkeit von 1/32 eingetreten ist, erhöhen wir den Häufigkeitsindex bis 6. Durch einen solchen Wahrscheinlichkeitsalgorithmus können die Häufigkeiten von LRU und LFU in uint32 eingegeben werden, wodurch LRU und LFU integriert werden, ohne den Speicherzugriffsdruck zu erhöhen.

Abschließend stellen wir Ihnen kurz unsere Multi-Card-Lösung vor. Derzeit sammeln wir alle Kartendaten im ID-Transformator der ersten Karte und senden sie dann zurück. Da der von uns implementierte ID Transformer eine sehr hohe Leistung aufweist und mit der GPU-Computing-Pipeline kombiniert werden kann, wird er nicht zu einem spezifischen Leistungsengpass.

Die oben genannten sind einige Designideen für die dynamische Einbettung. In einem unserer internen Billionengeschäfte weist die dynamische Einbettungslösung im Hinblick auf die Ausrichtungsgenauigkeit eine Leistungsverbesserung von etwa dem Dreifachen im Vergleich zu unserem internen Original-GPU-Tensorflow-Framework auf. Im Vergleich zur TF-optimierten Version weist es immer noch einen Leistungsvorteil von mehr als 50 % auf.

Abschließend empfehle ich jedem, Torchrec auszuprobieren. Für relativ kleine Unternehmen, beispielsweise Dutzende Milliarden Unternehmen, wird die direkte Verwendung des nativen TorchRec empfohlen: Plug-and-Play, keine sekundäre Entwicklung erforderlich und die Leistung kann verdoppelt werden. Für sehr große Unternehmen empfehlen wir Ihnen, die dynamische Einbettung von TorchRec bei uns zu integrieren. Einerseits ist es bequem, eine Verbindung zum internen PS herzustellen, andererseits unterstützt es auch die Erweiterung und schrittweise Migration der Einbettung Gleichzeitig können Sie dennoch eine gewisse Leistungsverbesserung erzielen.

Hier sind einige Präzisionsmodelle und bestehende Anwendungsszenarien, die wir abgestimmt haben. Interessierte Freunde können es ausprobieren.

Das obige ist der detaillierte Inhalt vonWeChats groß angelegte Trainingspraxis für Empfehlungssysteme basierend auf PyTorch. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!