MLPerf™ Leistungssteigerungen im Überfluss mit den neuesten
skalierbaren Intel® Xeon® Prozessoren der 3. Generation

Auf einen Blick

  • Intels neueste MLPerf Inferenz v1.0-Rechenzentrumsübermittlungen bestätigen Intels kontinuierliche Dynamik bei der CPU-Leistung für maschinelles Lernen. Die neuesten skalierbaren Intel® Xeon® Prozessoren der 3. Generation (früher Codename „Ice Lake“) bieten eine größere Leistungssteigerung. Beispielsweise bis zu 46 Prozent (v0,7: [1] v1.0: [2]) mehr als die vorherige Generation auf ResNet50-v1.5 in MLPerf Inference v0.7. Intels MLPerf 1.0-Ergebnisse zeigen auch bis zu einer 2,7-fachen (v0,7: [3] v1.0: [4]) Leistungsverbesserung im Vergleich zur letzten Runde der MLPerf-Einsendungen im Deep Learning-Empfehlungsmodell.

  • Mit integrierter KI-Beschleunigung, Unterstützung für End-to-End-Analysetools und einem breiten Ökosystem von KI-Lösungen, ist der skalierbare Intel Xeon Prozessor der 3. Generation die universelle Inferenz-Engine für das Unternehmen. Intel investiert neben skalierbaren Intel Xeon Prozessoren weiterhin in GPUs und dedizierte Beschleuniger für KI, wodurch Unternehmen umfassende Lösungen erhalten können, um ihre KI-Visionen zu erreichen.

  • Softwareoptimierungen sind von entscheidender Bedeutung, um den vollen Nutzen der Hardware-Fortschritte von Intel zu bieten. In diesem Blog beschreiben einige Softwareentwickler von Intel die Methoden, die sie bei der Optimierung der MLPerf Inferenz 1.0-Einsendungen verwendet haben.

BUILT IN - ARTICLE INTRO SECOND COMPONENT

Autoren

Guokai Ma
Haihao Shen
Bartlomiej Gawrych
Ed Groden
Wei Li
Christine Cheng

KI ist ein dynamisches Feld mit den Geschäftsanforderungen für eine Vielzahl von Hardware-Komponenten, einschließlich CPU, GPU und dedizierten Beschleunigern. Intel investiert in alle drei Bereiche. Dieser Blog konzentriert sich auf CPU-KI. Unternehmen wählen CPUs für KI, weil CPUs Enterprise-Anwendungen sowie KI-Workloads ausführen. KI ist wirklich eine End-to-End-Workload, die mit der Analyse beginnt, wobei Schulung und Inferenz nur ein Teil des Workflows ist. Oft können CPUs eine optimale Kombination aus Leistung und Gesamtbetriebskosten (TCO) für gemischte Workloads bieten, die Analysen und KI umfassen.

Intel hat MLPerf-Ergebnisse an neue skalierbare Intel® Xeon® Prozessoren der 3. Generation übermittelt, die früher den Codenamen „Ice Lake“ hatten. Diese Prozessoren sind die einzigen x86-Rechenzentrums-CPUs mit integrierter KI-Beschleunigung, Unterstützung für End-to-End-Tools der Datenwissenschaften und einem breiten Technologieumfeld innovativer KI-Lösungen. Mit dieser Prozessorreihe macht Intel es einfacher und effizienter, den gesamten Analyse-Workflow durchzuführen, einschließlich dem Schulungs- und Inferenzteil.

Wir übermitteln weiterhin eine breite Palette von MLPerf-Ergebnissen über Datentypen, Frameworks und Nutzungsmodelle, einschließlich Bildverarbeitung, natürlicher Sprachverarbeitung (NLP) und Empfehlungssystemen. Wir machen das, weil wir wissen, wie wichtig es Kunden ist, die Leistungserwartungen von ihren skalierbaren Intel Xeon Prozessoren zu verstehen, um zu entscheiden, ob diese CPUs die Leistung und die Gesamtbetriebskosten für ihre besonderen Anforderungen liefern. Die neuen Xeon Prozessoren der 3. Generation bieten nicht nur mehr Rechen- und Speicherkapazität/Bandbreite als die vorherige Generation, sondern bieten auch einen großen Sprung in die Leistung pro Sockel – beispielsweise bis zu 46 Prozent mehr im Vergleich zur vorherigen Generation bei ResNet50-v1.5 in MLPerf Inference v0.7. Darüber hinaus optimieren wir weiterhin die Deep Learning Software. Wir haben bis zu 2,7-fache (v0,7:[3] v1.0: [4]) Leistungsverbesserung im Vergleich zur letzten Runde der MLPerf-Einsendungen wie zum Beispiel dem Deep Learning Recommendation Model (DLRM) gesehen.

Dieser Blog zeigt die Software-Entwicklung hinter den Kulissen zur Bewältigung verschiedener Optimierungsmöglichkeiten. Wir konzentrieren uns auf Anwendungsfälle ohne maschinelles Sehen, wie NLP und Empfehlungsdienste. Die Optimierungstechniken, die wir beschreiben, begünstigen die Modellklassen im Allgemeinen neben den spezifischen angegebenen Modellen. Die Implementierungsdetails finden Sie in unseren neuesten MLPerf Inferenz v1.0-Einsendungen.

Highlights der Software-Optimierung in MLPerf v1.0-Einsendungen

Wir verwenden Intel® Deep Learning Boost (Intel® DL Boost) Technik, einschließlich Vector Neural Network Instructions (VNNI), in unseren INT8-basierten Einsendungen zu ResNet50-v1.5, SSD-ResNet34, 3D-UNET und BERT. Wir verwenden bfloat16 (Brain Floating Point) in unserem Recurrent Neural Network Transducer (RNN-T) und DLRM-Einsendungen. Das Intel® Low Precision Optimization Tool (Intel® LPOT) unterstützt jetzt eine Inferenz mit geringer Präzision auf Intel® Prozessoren.

Neben der Inferenz mit geringer Präzision verwendeten wir vier Arten von Optimierungstechniken zur Inferenz im Bereich ohne maschinelles Sehen: 1. Reduzierung der Rechenleistung durch Einführung der Dichte; 2. Reduzierung des Speicherzugangs mit operativer Fusion; 3. Optimierung des Netzwerkgraphen durch Reduzierung primitiver Kreationen; und 4. Verbesserung der Hardware-Auslastung durch Lastausgleich mit den Eingabegrößen und Einführung höherer Parallelität. Dies ist keine vollständige Liste, da Software-Optimierungen für Inferenz ein breiter Bereich mit viel spannender Forschung und Innovationen in der Industrie und Wissenschaft ist.

    1. Dichte gezeigt auf DLRM in Open Division

Dichte ist eine vielversprechende Technik, um den Rechen- und Speicherbedarf in der Optimierung des Deep Learning zu reduzieren. In unserer offenen Einsendung [5] haben wir die Optimierung der strukturierten Dichte untersucht, indem wir das Training für Dichte verwenden. Wir haben den Erfolg der FP32-Dichteoptimierung auf DLRM gezeigt.

Wir haben ein 16 x 1-Dichtemuster vorgeschlagen, um die Intel® Advanced Vector Extensions (Intel AVX-512-Architektur zu nutzen. Für diesen Blog nennen wir dieses Dichtemuster eine kachelbasierte Dichte. Kachelbasierte Dichte besteht aus Blöcken ungleich Null in einigen regelmäßigen Mustern. Abbildung 1 zeigt ein Beispiel mit den Kacheln an 16 aufeinanderfolgenden Elementen ungleich Null in roten Kästchen, während der Rest der Kacheln Null sind. 

Abbildung 1. Kachelbasierte Dichte (16 x 1-Dichtemuster) nach dem Training mit Dichte im FP32

Mit Training für Dichte und größenbasiertes Zurückschneiden, haben wir ein spärliches Modell für DLRM mit einem geometrischen Mittel (Geomittel) von 80 Prozent generiert. Das Modell hat ein Dichteverhältnis von bis zu 99 Prozent für Allgemeine Matrixmultiplikationen (GEMMs). Wir entwickelten den spärlichen GEMM-Kernal und verifizierten sowohl Genauigkeit als auch Leistung mit der MLPerf-Testsoftware. Mit spärlichen GEMMs konnten wir eine 1,4-fache Inferenz-Beschleunigung [6] auf skalierbaren Intel Xeon Prozessoren der 3. Generation im Vergleich zur gleichen Software mit den ursprünglichen dichten GEMMs erzielen, wobei der Genauigkeitsverlust innerhalb von 1 Prozent erhalten blieb, wie in Tabelle 1 gezeigt wird.

Benchmark Genauigkeitsverlust: Dichte in Sparse konvertieren Leistungsverbesserung Sparse/Dichte
DLRM-99 0,93 % 1,4x

Tabelle 1: Vergleich von Sparse und Dichte DLRM-Modellen [6]

    2. Op-Fusion gezeigt auf BERT

Das BERT-Modell wird weithin verwendet für NLP-Vorschulung. Das Modell selbst hat viele wiederholte FullyConnected + Activation-Untergraphiken, wodurch die Optimierung dieser wiederholten Untergraphiken eine erhebliche Steigerung der allgmeinen Inferenz-Leistung bietet. Abbildung 2 zeigt das BERT-Muster der FullyConnected + GeLU Aktivierungsfunktion, die wir verschmelzen. 

Abbildung 2. Operator Fusion auf BERT-Untergraphik vor (links) und nach (rechts) Fusion. (R = Lesen, W = Schreiben)

Beim Vergleich von vor und nach der Fusion im gestrichelten Kästchen in Abbildung 2 für einen Untergraph, können wir die Anzahl der Speicherzugriffe im gestrichelten roten Kästchen für Aktivierungen von 4 auf 2 reduzieren. Die Tensorausgabe von FullyConnected kann direkt in Aktivierung gehen, ohne auf den Speicher zu gehen, während die Ausgabe von der Aktivierung dann im Speicher gespeichert wird. Die Fusion reduziert auch die Quantisierungsschritte von 2 auf 1 in Abbildung 2. Dies führt zu zwei Lese- und Schreibvorgängen weniger im Speicher. Die linke Zeile hat 10 Lese- und Schreibvorgänge in den fünf Blöcken, während wir sechs Lese- und Schreibvorgänge in den drei Blöcken auf der rechten Seite haben. In diesem Beispiel reduzieren wir Speicherlese- und schreibvorgänge um 40 Prozent [7] im Untergraph mit Bediener-Fusionen. 

    3. Reduzierung der primitiven Kreationsgemeinkosten für BERT und RNN-T

Modelle ohne maschinelles Sehen haben in der Regel variable Eingabegrößen. Beispielsweise haben Textsätze eine variable Anzahl von Tokens oder Wörtern und Audiospracheingaben sind von unterschiedlicher Dauer. Jede Abfrage zu einem Empfehlungsmodell kann verschiedene Zahlen von Benutzer-Item-Paaren enthalten. Die Einzelheiten finden Sie in Tabelle 2.

MLPerf v1.0 Modelle ohne maschinelles Sehen Daten in jedem Eingabebeispiel
BERT Bis zu 384 Tokens (Wörter)
RNN-T Bis zu 15 Sekunden Sprachaudio
DLRM 100, 200, 300, 400, 500, 600 oder 700 Benutzer-Item-Paare

Tabelle 2: Variable Dateneingabegrößen in jeder Inferenz-Abfrage

Deep-Learning-Frameworks erstellen verschiedene Kernel für verschiedene Eingabe-Tensor-Formen, um diese Variabilität in den Eingabegrößen unterzubringen und die Inferenzgeschwindigkeit zu optimieren. Daher halten wir die Kernel persistent, da es Input-Tensoren mit wiederholten Formen in einem typischen Einsatzszenario des Rechenzentrums gibt. Wir verbinden verschiedene Eingabeformen mit verschiedenen CPU-Recheninstanzen [8], damit wir die Kernel-Wiederverwendung innerhalb der Instanz selbst maximieren und die Gemeinkosten der unnötigen Kernel-Kreation reduzieren. 

Im BERT-Fusionsbeispiel in Abbildung 2 eliminieren wir auch einige der Bibliothek- und Framework-Gemeinkosten zwischen Betreibern – beispielsweise die Gemeinkosten der primitiven Kreation in oneDNN.   

    4a. Lastausgleich über Recheninstanzen

Bei skalierbaren Intel Xeon Prozessoren ist es eine gängige Praxis, mehrere Instanzen der Modell-Inferenz auf dem gleichen Prozessor zu erstellen. Jede Instanz ist an eine Untergruppe von Kernen auf diesem Prozessor gebunden, die dazu beiträgt, die Rechenauslastung und den Durchsatz des gesamten Systems zu erhöhen. Diese Bindung minimiert auch die Interferenz zwischen Recheninstanzen, oder zwischen Inferenz-Recheninstanzen und Workloads für nicht maschinelles Lernen, die gemeinsam demselben System zugeordnet werden. 

    4b. Lastausgleich über die Eingabegrößen

Verschiedene Eingabegrößen erstellen Inferenz-Arbeit verschiedener Größen. Wir haben eine Vielzahl von Lastausgleichsverfahren verwendet, um die optimale Hardware-Auslastung zu gewährleisten. 

  1. Dynamisches Batching. Wir haben die Batchgröße für BERT optimiert, die eine variable Eingabelänge hat, indem wir eine einmalige Profilierung von Eingabeformen und einen einmaligen Kalibrierungsschritt durchführen. Mit dieser Profilierung können wir die optimale Batchgröße für eine bestimmte Eingabeform wählen. 
     
  2. Ständiges Batching. Im DLRM haben wir einen Bucketing-Ansatz implementiert, um zu gewährleisten, dass die Gesamtzahl der Benutzer-Item-Paare über Batches konstant ist. Dieser Bucketing-Ansatz hilft auch sicherzustellen, dass die Inferenzgeschwindigkeit pro Batch so konsistent wie möglich ist und die Aktivierungsform im optimalen Bereich ist.

    Insbesondere gruppieren wir, im DLRM-Offline-Szenario, die Proben in verschiedene Buckets und jeder Bucket enthält Proben mit einer anderen Eingabeform. Dann wählen wir Proben aus verschiedenen Buckets aus, um ein Batch mit deiner Gesamtzahl von 420.000 Benutzer-Item-Paaren zu bilden, was ein gängiges Vielfaches der in Tabelle 2 aufgeführten Eingabegrößen ist. Im DLRM-Server-Szenario sammeln wir die Proben in einem Batch bis die Gesamtzahl der Benutzer-Item-Paare X – 600 erreicht, wo X die Ziel-Batchgröße ist, um das Latenzziel zu erfüllen. 
     
  3. Kombinieren von Inferenz-Threads im Bereich Prozesstechnik mit mehreren Inferenzprozessen. DLRM-Modelle haben eine große Anzahl von Gewichten – in der Reihenfolge von 100 G. Wenn wir mehrere Inferenzprozesse auf dem gleichen Prozessor starten, beschränkt sich die Anzahl der Prozesse durch die Speicherkapazität, da jeder Prozess eine Kopie des Modellgewichts behält. Um diese Einschränkung zu vermeiden, starten wir mehrere Inferenz-Threads innerhalb des gleichen Prozesses, damit die Threads dieselbe Kopie von Modellgewichten innerhalb des Prozesses teilen. In unseren Experimenten mit der gleichen Hardware-Plattform fanden wir heraus, dass die Anzahl der gleichzeitigen Inferenz-Instanzen sich mit der Kombination mehrerer Threads und mehrere Prozessoren sich verdoppelt, im Vergleich zu nur mehreren Prozessoren. 
     

    4c. Batch RNN-T-Greedy-Decoder

Die Referenz-RNN-T-Implementierung hat einen sequentiellen Decoder. Die codierte Audiosequenz wird über den Greedy-Decoder Token für Token decodiert. Um die Recheneffizienz zu verbessern, führen wir einen Batch-Greedy-Decoder ein und vektorieren die meisten Decoder-Schritte mit PyTorch-Tensor-Operationen ein. 

Im Vergleich zu seiner sequentiellen Version nimmt ein Batch-Greedy-Decoder einen Vektor der 'Funktions-Front' (wie in Abbildung 4 gezeigt) aus der Encoder-Ausgabe. Sie verwendet jeden Vektor als Eingabe zum gemeinsamen Netzwerk. Im Beispiel in Abbildung 4 haben wir mehrere Szenarien zu jedem Zeitschritt. In diesem Beispiel können wir den gleichen Vektor dekodieren [f00, f10]. Wir können den zweiten Wert vorantreiben, wenn wir das _blank_id Token in der zweiten Reihe [f00, f11] erhalten. Oder wir können den ersten Wert vorantreiben, wenn wir das _blank_id Token in der ersten Reihe [f01, f11] erhalten.   

Abbildung 3: Sequential Greedy Decoder mit 'ft0' und 'ft1', der in Sequenz decodiert wird

Abbildung 4: Batch Greedy Decoder mit zwei Dateneingaben (türkis und gelb), die zusammen decodiert sind. Die orangefarbenen, grünen und blauen Ovale sind die drei Funktions-Fronts in diesem Beispiel.

In unseren Experimenten verbessert der gierige Decoder des Batches RNN-T-Offline-Durchsatz um das 3,3-fache im Vergleich zum sequentiellen gierigen Decoder. Die Konvertierung zur BF16-Präzision bringt eine weitere 2,1-fache Verbesserung. Die Gesamtverbesserung im Startmodell mit dem sequentiellen Decoder beträgt 6,9-mal [9], wie in Abbildung 5 gezeigt.

Abbildung 5: RNN-T Offline Throughput Improvement Breakdown [9]

Intel Submission Results für MLPerf v1.0-Inferenz 

Intel hat Daten für alle Benchmarks im Rechenzentrum eingereicht und die führende CPU-Leistung in der gesamten Benchmark-Suite des Rechenzentrums gezeigt. Siehe die vollständigen Ergebnisse von Intel-Einsendungen auf der MLPerf-Ergebnisseite mit dem Link hier. 

Wir liefern weiterhin mehr Rechen- und Speicherbandbreite mit unseren neuen skalierbaren Intel Xeon Prozessoren der 3. Generation. Wir sahen bis zu 46 Prozent (v0,7:[1] v1.0: [2]) höhere Leistung pro Sockel im Vergleich zu unserer MLPerf v0.7 Einsendung mit skalierbaren Intel Xeon Prozessoren der 2. Generation (Codename: Cascade Lake).

Abbildung 6: ResNet50-v1.5 Leistungsverbesserung von MLPerf v0.7[1] bis v1.0[2].

Mit Softwareoptimierungen verbesserten sich DLRM-Benchmarks in MLPerf v1.0 um bis zu 2,7-mal im Vergleich zu unserer v0.7 Einsendung auf derselben CPU-Plattform (v0,7:[3] v1.0: [4]). (Siehe Abbildung 7.)

Abbildung 7: DLRM-Leistungsverbesserung von MLPerf v0.7[3] bis v1.0[4].

Blick nach vorn

Viele Techniken, einschließlich BF16-Präzisions-Inferenz und Quantisierung von Aufmerksamkeitsbedienern in BERT wurden auf Frameworks wie PyTorch und MXNet hochgeladen. Diese Arbeit ermöglicht Benutzern, heute die Leistungssteigerung ohne zusätzliche Code-Änderungen zu genießen. Weitere Informationen zur Code-Implementierung finden Sie unter dem Link MLCommons™ Inference v1.0 Results GitHub, um alle implementierten Softwareoptimierungen zu sehen. 

Wir haben spannendere KI-orientierte Technologien in der Pipeline. Zukünftige skalierbare Intel Xeon Prozessoren, Codename Sapphire Rapids, umfassen Intel® Advanced Matrix Extensions (Intel® AMX). Wir entwickeln auch eine GPU mit allgemeinem Zweck, die für HPC-/KI-Beschleunigung basierend auf der Intel® Iris® Xᵉ Architektur, Codename Ponte Vecchio optimiert ist. Wir entwickeln weiterhin die Software und Hardware zur Optimierung der KI-Leistung bei Intel® Produkten, die es Unternehmen ermöglichen, das Versprechen von KI zu liefern. 

Hinweise und Haftungsausschlüsse

Die Leistung variiert je nach Verwendung, Konfiguration und anderen Faktoren. Weitere Informationen siehe www.intel.com/PerformanceIndex. 
Die Leistungswerte basieren auf Tests, die mit den in den Konfigurationen angegebenen Daten durchgeführt wurden und spiegeln möglicherweise nicht alle öffentlich verfügbaren Updates wider. Weitere Konfigurationsdetails siehe Backup. Kein Produkt und keine Komponente bieten absolute Sicherheit.
Ihre Kosten und Ergebnisse können variieren.
Für die Funktion bestimmter Technik von Intel kann entsprechend konfigurierte Hardware, Software oder die Aktivierung von Diensten erforderlich sein.
© Intel Corporation. Intel, das Intel Logo und andere Intel Markenbezeichnungen sind Marken der Intel Corporation oder ihrer Tochtergesellschaften. Andere Marken oder Produktnamen sind Eigentum der jeweiligen Inhaber. 


Referenzen:

1.      MLPerf v0.7 Inference Datacenter Closed ResNet, Eintrag 0.7-101. https://mlcommons.org/en/inference-datacenter-07/

2.      MLPerf v1.0 Inference Datacenter Closed ResNet, Eintrag 1.0-53. https://mlcommons.org/en/inference-datacenter-10/

3.      MLPerf v0.7 Inference Datacenter Closed DLRM-99.9, Eintrag 0.7-126. https://mlcommons.org/en/inference-datacenter-07/

4.      MLPerf v1.0 Inference Datacenter Closed DLRM-99.9, Eintrag 1.0-20. https://mlcommons.org/en/inference-datacenter-10/

5.      MLPerf v1.0 Inference Open DLRM-99, Eintrag Inf-1.0-67. https://mlcommons.org/en/inference-datacenter-10/

6.      Baseline FP32 DLRM dichte Modellquelle: https://github.com/mlcommons/inference/tree/master/recommendation/dlrm/pytorch Optimized.FP32 DLRM finden Sie unter https://github.com/mlcommons/submissions_inference_1_0/master/open/Intel/dlrm-99 (Link aktiv ab 21.4). Sowohl das dichte Modell als auch das spärliche DLRM-Modell werden auf der gleichen Hardware mit dem Server-Szenario getestet: 1 Knoten, 2x Intel Xeon Platinum 8380 Prozessor auf Coyote Pass mit 1 TB (16 Slots/64 GB/3200) gesamter DDR4-Speicher, Ucode 0x8d05a260, HT on, Turbo on, Ubuntu 20.04.2 LTS, 5.4.0-66-generisch. Siehe die zusätzlichen Hardware- und Framework-Informationen in v1.0 Inference Open DLRM-99, Eintrag Inf-1.0-67. https://mlcommons.org/en/inference-datacenter-10/. Getestet von Intel am 18.03.2021.

7.      BERT-Large quantifiziert: 1 Knoten, 2x Intel Xeon Platinum 8380 Prozessor auf Coyote Pass mit 1 TB (16 Slots/64 GB/3200) gesamter DDR4-Speicher, UCode 0x8d05a260, HT on, Turbo on, Ubuntu 20.04.2 LTS, 5.4.0-66-generisch. Baseline Modellquelle:https://github.com/mlcommons/inference/tree/master/language/bert. Die Schritte zur Wiedergabe des optimierten Modells finden Sie unter https://github.com/mlcommons/submissions_inference_1_0/tree/master/closed/Intel/code/bert-99/mxnet. Test von Intel am 16.3.2021.

8.      Eine CPU-Inferenz-Instanz kann ein Prozess oder ein Thread sein. Jede Inferenz-Instanz dient einer Inferenz-Anfrage.

9.      Die relativen Leistungsprofilexperimente werden mit 1 Knoten, 4x Intel Xeon Platinum 8380H Prozessor auf Cedar Island mit 1,6 TB (24 Slots/64 GB/3200) gesamter DDR4-Speicher, Ucode 0x700001e, HT on, Turbo on, Ubuntu 20.04.2 LTS, 5.4.0-66-generisch, PyTorch v1.5.0-rc3, BS 384 durchgeführt. Wir haben die optimierte Version mit „BF16-Encoder und BF16-Batch-Greedy-Decoder“ an MLPerf mit einem anderen 1-Knoten, 8-mal Intel Xeon Platinum 8380H Prozessor mit mehr Informationen unter dem Eintrag MLPerf v1.0 Inference Closed RNN-T, Eingabe Inf-1.0-20. https://mlcommons.org/en/inference-datacenter-10/ übermittelt. Getestet von Intel am 18.03.2021.