ByteDance spart mit AWS Inferentia bis zu 60 % an Inferenzkosten und reduziert gleichzeitig die Latenz und erhöht den Durchsatz

Dies ist ein Gast-Blogbeitrag, der gemeinsam mit Minghui Yu und Jianzhe Xiao von Bytedance geschrieben wurde.

ByteDance ist ein Technologieunternehmen, das eine Reihe von Inhaltsplattformen betreibt, um Menschen über Sprachen, Kulturen und Regionen hinweg zu informieren, aufzuklären, zu unterhalten und zu inspirieren. Benutzer vertrauen und genießen unsere Inhaltsplattformen aufgrund der reichhaltigen, intuitiven und sicheren Erfahrungen, die sie bieten. Diese Erfahrungen werden durch unsere Backend-Engine für maschinelles Lernen (ML) ermöglicht, mit ML-Modellen, die für Inhaltsmoderation, Suche, Empfehlung, Werbung und neuartige visuelle Effekte entwickelt wurden.

Das Team von ByteDance AML (Applied Machine Learning) bietet hochleistungsfähige, zuverlässige und skalierbare ML-Systeme und End-to-End-ML-Services für das Geschäft des Unternehmens. Wir haben nach Möglichkeiten gesucht, unsere ML-Inferenzsysteme zu optimieren, um Kosten zu senken, ohne die Antwortzeiten zu verlängern. Beim Start von AWS AWS-Inferenz, einem leistungsstarken ML-Inferenzchip, der speziell von AWS entwickelt wurde, haben wir mit unserem AWS-Kontoteam zusammengearbeitet, um zu testen, ob AWS Inferentia unsere Optimierungsziele erreichen kann. Wir haben mehrere Proofs of Concept durchgeführt, was zu bis zu 60 % geringeren Inferenzkosten im Vergleich zu T4-GPU-basierten EC2 G4dn-Instances und zu einer bis zu 25 % geringeren Inferenzlatenz führte. Um diese Kosteneinsparungen und Leistungsverbesserungen zu realisieren, haben wir uns entschieden, Modelle auf AWS Inferentia-basiert bereitzustellen Amazon Elastic Compute-Cloud (Amazon EC2) Inf1-Instances in Produktion.

Das folgende Diagramm zeigt die Latenzverbesserung für eines unserer Gesichtserkennungsmodelle, das zuvor auf GPUs mit Tensor RT bereitgestellt wurde. Die durchschnittliche Latenz verringerte sich um 20 % (von 50 Millisekunden auf 40 Millisekunden) und die p99-Latenz verringerte sich um 25 % (von 200 Millisekunden auf 150 Millisekunden).

In diesem Beitrag teilen wir mit, wie wir mit AWS Inferentia Inferenzkosten eingespart und gleichzeitig Latenzen reduziert und den Durchsatz erhöht haben.

Auf der Suche nach leistungsstarker, kostengünstiger Rechenleistung

Das ByteDance AML-Team konzentriert sich auf die Erforschung und Implementierung modernster ML-Systeme und der dafür erforderlichen heterogenen Rechenressourcen. Wir erstellen umfangreiche Trainings- und Inferenzsysteme für eine Vielzahl von Empfehlungs-, Natural Language Processing (NLP)- und Computer Vision (CV)-Modellen. Diese Modelle sind sehr komplex und verarbeiten eine riesige Menge an Daten von den vielen Inhaltsplattformen, die ByteDance betreibt. Die Bereitstellung dieser Modelle erfordert erhebliche GPU-Ressourcen, ob in der Cloud oder vor Ort. Daher sind die Rechenkosten für diese Inferenzsysteme ziemlich hoch.

Wir wollten diese Kosten senken, ohne den Durchsatz oder die Latenz zu beeinträchtigen. Wir wollten die Flexibilität und den schnelleren Bereitstellungszyklus der Cloud, der viel kürzer ist als der, der für eine lokale Einrichtung erforderlich ist. Und obwohl wir offen dafür waren, neue Optionen für beschleunigtes ML zu erkunden, wollten wir auch ein nahtloses Entwicklererlebnis.

Wir haben von unserem AWS-Team erfahren, dass AWS Inferentia-basierte EC2 Inf1-Instances leistungsstarke ML-Inferenz zum niedrigsten Cost-per-Inference in der Cloud liefern. Wir waren neugierig, sie zu erkunden, und fanden sie für unseren Anwendungsfall gut geeignet, da wir umfangreiches maschinelles Lernen mit großen Mengen an Bild-, Objekt-, Sprach- und Textdaten durchführen. Sie passten definitiv gut zu unseren Zielen, da wir angesichts der Komplexität unserer Modelle und der Menge an täglichen Vorhersagen enorme Kosteneinsparungen realisieren konnten. Darüber hinaus verfügt AWS Inferentia über eine große Menge an On-Chip-Speicher, den Sie zum Zwischenspeichern großer Modelle verwenden können, anstatt sie außerhalb des Chips zu speichern. Wir haben erkannt, dass dies einen erheblichen Einfluss auf die Verringerung der Inferenzlatenz haben kann, da die Verarbeitungskerne von AWS Inferentia, genannt NeuronCores, Hochgeschwindigkeitszugriff auf Modelle haben, die im On-Chip-Speicher gespeichert sind und nicht durch den Off-Chip-Speicher begrenzt sind Bandbreite.

Nachdem wir mehrere Optionen geprüft hatten, entschieden wir uns schließlich für EC2 Inf1-Instances aufgrund ihres besseren Leistungs-/Preisverhältnisses im Vergleich zu G4dn-Instances und NVIDIA T4 On-Premises. Wir haben uns mit dem AWS-Team an einem Zyklus kontinuierlicher Iterationen beteiligt, um die Preis- und Leistungsvorteile von Inf1 freizusetzen.

Bereitstellen von Inferenz-Workloads auf AWS Inferentia

Die ersten Schritte mit AWS Inferentia unter Verwendung des AWS Neuron SDK umfassten zwei Phasen: Kompilierung des Modellcodes und Bereitstellung auf Inf1-Instances. Wie es beim Umzug von ML-Modellen in eine neue Infrastruktur üblich ist, gab es einige Herausforderungen, denen wir uns stellen mussten. Wir konnten diese Herausforderungen mit Sorgfalt und der Unterstützung unseres AWS-Teams meistern. In den folgenden Abschnitten teilen wir einige nützliche Tipps und Beobachtungen, die auf unserer Erfahrung mit der Bereitstellung von Inferenz-Workloads auf AWS Inferentia basieren.

Konformeres Modell für OCR

Unser Konformitätsmodell zur optischen Zeichenerkennung (OCR) erkennt und liest Text in Bildern. Wir haben an mehreren Optimierungen gearbeitet, um eine hohe Leistung (QPS) für eine Vielzahl von Stapelgrößen zu erzielen und gleichzeitig die Latenz niedrig zu halten. Einige wichtige Optimierungen sind unten aufgeführt:

• Compiler-Optimierungen – Standardmäßig schneidet Inferentia am besten bei Eingaben mit einer festen Sequenzlänge ab, was eine Herausforderung darstellte, da die Länge von Textdaten nicht festgelegt ist. Um dies zu überwinden, haben wir unser Modell in zwei Teile aufgeteilt: einen Encoder und einen Decoder. Wir haben diese beiden Teilmodelle separat kompiliert und dann über TorchScript zu einem einzigen Modell zusammengeführt. Durch Ausführen des Kontrollflusses der for-Schleife auf CPUs ermöglichte dieser Ansatz die Unterstützung variabler Sequenzlängen auf Inferentia.
• Tiefenfaltungsleistung – Wir sind auf einen DMA-Engpass in der tiefenweisen Faltungsoperation gestoßen, die von unserem Konformermodell stark verwendet wird. Wir haben eng mit dem AWS Neuron-Team zusammengearbeitet, um den Leistungsengpass beim DMA-Zugriff zu identifizieren und zu beheben, wodurch die Leistung dieses Vorgangs und die Gesamtleistung unseres OCR-Modells verbessert wurden.

Wir haben zwei neue Modellvarianten erstellt, um unseren Einsatz auf Inferentia zu optimieren:

• Kombinierter und abgerollter Encoder/Decoder – Anstatt einen unabhängig kompilierten Encoder und Decoder zu verwenden, haben wir den Encoder und einen vollständig entrollten Decoder zu einem einzigen Modell kombiniert und dieses Modell als ein einziges NEFF kompiliert. Das Entrollen des Decoders ermöglicht es, den gesamten Decoder-Steuerungsfluss auf Inferentia auszuführen, ohne CPU-Operationen zu verwenden. Bei diesem Ansatz verwendet jede Iteration des Decoders genau die Menge an Rechenleistung, die für dieses Token erforderlich ist. Dieser Ansatz verbessert die Leistung, da wir die übermäßige Berechnung, die zuvor durch das Auffüllen von Eingaben eingeführt wurde, erheblich reduzieren. Darüber hinaus ist zwischen Decoder-Iterationen keine Datenübertragung von Inferentia zur CPU erforderlich, was die E/A-Zeit drastisch reduziert. Diese Version des Modells unterstützt kein vorzeitiges Stoppen.
• Partitionierter entrollter Decoder – Ähnlich wie beim kombinierten vollständig entrollten Modell entrollt diese Variante des Modells mehrere Iterationen des Decoders und kompiliert sie als eine einzige Ausführung (enthält jedoch nicht den Encoder). Beispielsweise können wir für eine maximale Sequenzlänge von 75 den Decoder in 3 Partitionen aufteilen, die die Token 1–25, 26–50 und 51–75 berechnen. In Bezug auf die E/A ist dies auch erheblich schneller, da wir die Encoderausgabe nicht einmal pro Iteration übertragen müssen. Stattdessen werden die Ausgänge nur einmal pro Decoderpartition übertragen. Diese Version des Modells unterstützt frühes Stoppen, jedoch nur an den Partitionsgrenzen. Die Partitionsgrenzen können für jede spezifische Anwendung abgestimmt werden, um sicherzustellen, dass die Mehrheit der Anforderungen nur eine Partition ausführt.

Um die Leistung weiter zu verbessern, haben wir die folgenden Optimierungen vorgenommen, um die Speichernutzung zu reduzieren oder die Zugriffseffizienz zu verbessern:

• Tensor-Deduplizierung und reduzierte Kopien – Dies ist eine Compiler-Optimierung, die die Größe entrollter Modelle und die Anzahl der Anweisungen/Speicherzugriffe erheblich reduziert, indem Tensoren wiederverwendet werden, um die Platzeffizienz zu verbessern.
• Reduzierte Anleitung – Dies ist eine Compiler-Optimierung, die mit der nicht aufgefüllten Version des Decoders verwendet wird, um die Gesamtzahl der Anweisungen erheblich zu reduzieren.
• Multicore-Deduplizierung – Dies ist eine Laufzeitoptimierung, die eine Alternative zur Tensor-Deduplizierung darstellt. Mit dieser Option werden alle Multicore-Modelle deutlich platzsparender.

ResNet50-Modell zur Bildklassifizierung

ResNet-50 ist ein vortrainiertes Deep-Learning-Modell für die Bildklassifizierung. Es ist ein Convolutional Neural Network (CNN oder ConvNet), das am häufigsten zur Analyse visueller Bilder verwendet wird. Wir haben die folgenden Techniken verwendet, um die Leistung dieses Modells auf Inferentia zu verbessern:

• Modelltransformation – Viele Modelle von ByteDance werden im ONNX-Format exportiert, das Inferentia derzeit nicht nativ unterstützt. Zur Handhabung dieser ONNX-Modelle hat das AWS Neuron-Team Skripte bereitgestellt, um unsere Modelle vom ONNX-Format in PyTorch-Modelle umzuwandeln, die mit Torch-Neuron direkt für Inferentia kompiliert werden können.
• Leistungsoptimierung – Wir haben eng mit der zusammengearbeitet AWS-Neuron Team, um die Scheduling-Heuristik im Compiler abzustimmen, um die Leistung unserer ResNet-50-Modelle zu optimieren.

Multimodales Modell für die Moderation von Inhalten

Unser multimodales Deep-Learning-Modell ist eine Kombination aus mehreren separaten Modellen. Die Größe dieses Modells ist relativ groß, was zu Fehlern beim Laden des Modells auf Inferentia führte. Das AWS Neuron-Team hat dieses Problem erfolgreich gelöst, indem es die Gewichtsverteilung verwendet hat, um die Speichernutzung des Geräts zu reduzieren. Das Neuron-Team hat diese Gewichtungs-Deduplizierungsfunktion in der Neuron-libnrt-Bibliothek veröffentlicht und auch die Neuron-Tools für präzisere Metriken verbessert. Die Laufzeitgewichtungs-Deduplizierungsfunktion kann aktiviert werden, indem die folgende Umgebungsvariable festgelegt wird, bevor die Inferenz ausgeführt wird:

NEURON_RT_MULTI_INSTANCE_SHARED_WEIGHTS=1

Das aktualisierte Neuron SDK reduzierte den Gesamtspeicherverbrauch unserer duplizierten Modelle, wodurch wir unser multimodales Modell für Multi-Core-Inferenz einsetzen konnten.

Migrieren weiterer Modelle zu AWS Inferentia

Bei ByteDance setzen wir weiterhin innovative Deep-Learning-Modelle ein, um fast 2 Milliarden monatlich aktiven Benutzern angenehme Benutzererlebnisse zu bieten. Angesichts des enormen Umfangs, in dem wir tätig sind, suchen wir ständig nach Möglichkeiten, Kosten zu sparen und die Leistung zu optimieren. Wir werden weiterhin Modelle zu AWS Inferentia migrieren, um von der hohen Leistung und Kosteneffizienz zu profitieren. Wir möchten auch, dass AWS mehr AWS Inferentia-basierte Instance-Typen einführt, z. B. solche mit mehr vCPUs für Vorverarbeitungsaufgaben. Für die Zukunft hofft ByteDance auf weitere Silizium-Innovationen von AWS, um das beste Preis-Leistungs-Verhältnis für ML-Anwendungen zu bieten.

Wenn Sie mehr darüber erfahren möchten, wie AWS Inferentia Ihnen helfen kann, Kosten zu sparen und gleichzeitig die Leistung Ihrer Inferenzanwendungen zu optimieren, besuchen Sie die Amazon EC2 Inf1-Instanzen Produktseite.

---

Über die Autoren

Minghui Yu ist Senior Machine Learning Team Lead for Inference bei ByteDance. Sein Schwerpunkt liegt auf AI Computing Acceleration and Machine Learning System. Er interessiert sich sehr für heterogenes Rechnen und Computerarchitektur in der Post-Moore-Ära. In seiner Freizeit mag er Basketball und Bogenschießen.

Jianzhe Xiao ist Senior Software Engineer Team Lead im AML-Team bei ByteDance. Seine aktuelle Arbeit konzentriert sich darauf, dem Geschäftsteam dabei zu helfen, den Modellbereitstellungsprozess zu beschleunigen und die Inferenzleistung des Modells zu verbessern. Außerhalb der Arbeit spielt er gerne Klavier.

Tian Shi ist Senior Solutions Architect bei AWS. Seine Schwerpunkte sind Datenanalyse, maschinelles Lernen und Serverless. Seine Leidenschaft ist es, Kunden dabei zu helfen, zuverlässige und skalierbare Lösungen in der Cloud zu entwerfen und zu erstellen. In seiner Freizeit schwimmt und liest er gerne.

Jia Dong ist Customer Solutions Manager bei AWS. Sie lernt gerne etwas über AWS AI/ML-Services und hilft Kunden dabei, ihre Geschäftsergebnisse zu erreichen, indem sie Lösungen für sie entwickelt. Außerhalb der Arbeit genießt Jia Reisen, Yoga und Filme.

Jonathan Lunt ist Softwareentwickler bei Amazon mit Schwerpunkt auf der Entwicklung von ML-Frameworks. Im Laufe seiner Karriere hat er die gesamte Breite der Data-Science-Rollen durchlaufen, darunter Modellentwicklung, Infrastrukturbereitstellung und hardwarespezifische Optimierung.

Josua Hannan ist Machine Learning Engineer bei Amazon. Er arbeitet an der Optimierung von Deep-Learning-Modellen für groß angelegte Computer-Vision- und Natural-Language-Processing-Anwendungen.

Shruti Koparkar ist Senior Product Marketing Manager bei AWS. Sie hilft Kunden bei der Erkundung, Bewertung und Einführung der beschleunigten EC2-Computing-Infrastruktur für ihre Anforderungen an maschinelles Lernen.