Benchmarken und optimieren Sie die Endpunktbereitstellung in Amazon SageMaker JumpStart | Amazon Web Services

Bei der Bereitstellung eines großen Sprachmodells (LLM) kümmern sich Praktiker des maschinellen Lernens (ML) in der Regel um zwei Messungen der Modellbereitstellungsleistung: Latenz, definiert durch die Zeit, die zum Generieren eines einzelnen Tokens benötigt wird, und Durchsatz, definiert durch die Anzahl der generierten Token pro Sekunde. Obwohl eine einzelne Anfrage an den bereitgestellten Endpunkt einen Durchsatz aufweisen würde, der ungefähr dem Kehrwert der Modelllatenz entspricht, ist dies nicht unbedingt der Fall, wenn mehrere gleichzeitige Anfragen gleichzeitig an den Endpunkt gesendet werden. Aufgrund von Modellbereitstellungstechniken, wie der kontinuierlichen Stapelverarbeitung gleichzeitiger Anforderungen auf der Clientseite, besteht zwischen Latenz und Durchsatz eine komplexe Beziehung, die je nach Modellarchitektur, Bereitstellungskonfigurationen, Instanztyp-Hardware, Anzahl gleichzeitiger Anforderungen und Variationen bei den Eingabenutzlasten erheblich variiert als Anzahl der Input-Tokens und Output-Tokens.

Dieser Beitrag untersucht diese Beziehungen anhand eines umfassenden Benchmarkings der in Amazon SageMaker JumpStart verfügbaren LLMs, einschließlich der Varianten Llama 2, Falcon und Mistral. Mit SageMaker JumpStart können ML-Praktiker aus einer breiten Auswahl öffentlich verfügbarer Basismodelle wählen, die sie dediziert einsetzen können Amazon Sage Maker Instanzen innerhalb einer netzwerkisolierten Umgebung. Wir bieten theoretische Grundlagen dazu, wie sich Beschleunigerspezifikationen auf das LLM-Benchmarking auswirken. Wir demonstrieren auch die Auswirkungen der Bereitstellung mehrerer Instanzen hinter einem einzelnen Endpunkt. Abschließend geben wir praktische Empfehlungen für die Anpassung des SageMaker JumpStart-Bereitstellungsprozesses, um ihn an Ihre Anforderungen an Latenz, Durchsatz, Kosten und Einschränkungen der verfügbaren Instanztypen anzupassen. Alle Benchmarking-Ergebnisse sowie Empfehlungen basieren auf einem vielseitigen Notizbuch die Sie an Ihren Anwendungsfall anpassen können.

Eingesetztes Endpunkt-Benchmarking

Die folgende Abbildung zeigt die Werte für die niedrigsten Latenzen (links) und den höchsten Durchsatz (rechts) für Bereitstellungskonfigurationen für verschiedene Modelltypen und Instanztypen. Wichtig ist, dass jede dieser Modellbereitstellungen Standardkonfigurationen verwendet, die von SageMaker JumpStart bereitgestellt werden, sofern die gewünschte Modell-ID und der gewünschte Instanztyp für die Bereitstellung angegeben sind.

Diese Latenz- und Durchsatzwerte entsprechen Nutzlasten mit 256 Eingabe-Tokens und 256 Ausgabe-Tokens. Die Konfiguration mit der niedrigsten Latenz beschränkt die Modellbereitstellung auf eine einzige gleichzeitige Anfrage, und die Konfiguration mit dem höchsten Durchsatz maximiert die mögliche Anzahl gleichzeitiger Anfragen. Wie wir in unserem Benchmarking sehen können, erhöht die Zunahme gleichzeitiger Anfragen monoton den Durchsatz, während die Verbesserung bei großen gleichzeitigen Anfragen abnimmt. Darüber hinaus werden Modelle auf der unterstützten Instanz vollständig fragmentiert. Da beispielsweise die ml.g5.48xlarge-Instanz über 8 GPUs verfügt, werden alle SageMaker JumpStart-Modelle, die diese Instanz verwenden, mithilfe von Tensorparallelität auf allen acht verfügbaren Beschleunigern geshardt.

Wir können aus dieser Zahl einige Erkenntnisse ziehen. Erstens werden nicht alle Modelle auf allen Instanzen unterstützt; Einige kleinere Modelle, wie z. B. Falcon 7B, unterstützen kein Modell-Sharding, wohingegen größere Modelle höhere Anforderungen an die Rechenressourcen stellen. Zweitens verbessert sich die Leistung mit zunehmendem Sharding in der Regel, bei kleinen Modellen jedoch nicht unbedingt. Dies liegt daran, dass kleine Modelle wie 7B und 13B einen erheblichen Kommunikationsaufwand verursachen, wenn sie auf zu viele Beschleuniger aufgeteilt werden. Wir besprechen dies später ausführlicher. Schließlich weisen ml.p4d.24xlarge-Instanzen aufgrund der verbesserten Speicherbandbreite von A100-GPUs gegenüber A10G-GPUs tendenziell einen deutlich besseren Durchsatz auf. Wie wir später besprechen, hängt die Entscheidung für die Verwendung eines bestimmten Instanztyps von Ihren Bereitstellungsanforderungen ab, einschließlich Latenz, Durchsatz und Kostenbeschränkungen.

Wie können Sie diese Konfigurationswerte für die niedrigste Latenz und den höchsten Durchsatz erhalten? Beginnen wir mit der Darstellung der Latenz im Vergleich zum Durchsatz für einen Llama 2 7B-Endpunkt auf einer ml.g5.12xlarge-Instanz für eine Nutzlast mit 256 Eingabe-Tokens und 256 Ausgabe-Tokens, wie in der folgenden Kurve dargestellt. Für jeden bereitgestellten LLM-Endpunkt existiert eine ähnliche Kurve.

Mit zunehmender Parallelität nehmen auch Durchsatz und Latenz monoton zu. Daher tritt der niedrigste Latenzpunkt bei einem Wert für gleichzeitige Anforderungen von 1 auf, und Sie können den Systemdurchsatz kosteneffektiv erhöhen, indem Sie gleichzeitige Anforderungen erhöhen. Es gibt einen deutlichen „Knick“ in dieser Kurve, an dem offensichtlich ist, dass die mit der zusätzlichen Parallelität verbundenen Durchsatzgewinne den damit verbundenen Anstieg der Latenz nicht überwiegen. Die genaue Lage dieses Knies ist anwendungsspezifisch; Einige Praktiker definieren das Knie möglicherweise an dem Punkt, an dem eine vorab festgelegte Latenzanforderung überschritten wird (z. B. 100 ms/Token), während andere möglicherweise Lasttest-Benchmarks und Methoden der Warteschlangentheorie wie die Halblatenzregel verwenden theoretische Beschleunigerspezifikationen.

Wir weisen außerdem darauf hin, dass die maximale Anzahl gleichzeitiger Anfragen begrenzt ist. In der vorherigen Abbildung endet die Zeilenverfolgung mit 192 gleichzeitigen Anforderungen. Die Ursache dieser Einschränkung ist das Zeitlimit für den SageMaker-Aufruf, bei dem SageMaker-Endpunkte eine Aufrufantwort nach 60 Sekunden abbrechen. Diese Einstellung ist kontospezifisch und nicht für einen einzelnen Endpunkt konfigurierbar. Bei LLMs kann die Generierung einer großen Anzahl von Ausgabetokens Sekunden oder sogar Minuten dauern. Daher können große Eingabe- oder Ausgabenutzlasten dazu führen, dass die Aufrufanforderungen fehlschlagen. Wenn außerdem die Anzahl der gleichzeitigen Anfragen sehr groß ist, kommt es bei vielen Anfragen zu langen Wartezeiten, was zu dieser Zeitüberschreitungsgrenze von 60 Sekunden führt. Für den Zweck dieser Studie verwenden wir das Timeout-Limit, um den maximal möglichen Durchsatz für eine Modellbereitstellung zu definieren. Wichtig: Auch wenn ein SageMaker-Endpunkt eine große Anzahl gleichzeitiger Anfragen verarbeiten kann, ohne dass ein Zeitlimit für die Aufrufantwort eingehalten wird, möchten Sie möglicherweise die maximale Anzahl gleichzeitiger Anfragen in Bezug auf das Knie in der Latenz-Durchsatz-Kurve definieren. Dies ist wahrscheinlich der Punkt, an dem Sie beginnen, über eine horizontale Skalierung nachzudenken, bei der ein einzelner Endpunkt mehrere Instanzen mit Modellreplikaten bereitstellt und eingehende Anforderungen zwischen den Replikaten verteilt, um mehr gleichzeitige Anforderungen zu unterstützen.

Um noch einen Schritt weiter zu gehen, enthält die folgende Tabelle Benchmarking-Ergebnisse für verschiedene Konfigurationen für das Llama 2 7B-Modell, einschließlich unterschiedlicher Anzahl von Eingabe- und Ausgabe-Tokens, Instanztypen und Anzahl gleichzeitiger Anforderungen. Beachten Sie, dass in der vorherigen Abbildung nur eine einzelne Zeile dieser Tabelle dargestellt wird.

Wir beobachten einige zusätzliche Muster in diesen Daten. Wenn die Kontextgröße erhöht wird, erhöht sich die Latenz und der Durchsatz verringert sich. Beispielsweise beträgt bei ml.g5.2xlarge mit einer Parallelität von 1 der Durchsatz 30 Token/Sek., wenn die Gesamtanzahl der Token 512 beträgt, im Vergleich zu 20 Token/Sek., wenn die Gesamtanzahl der Token 4,096 beträgt. Dies liegt daran, dass die Verarbeitung der größeren Eingabe mehr Zeit in Anspruch nimmt. Wir können auch sehen, dass sich eine Erhöhung der GPU-Fähigkeit und Sharding auf den maximalen Durchsatz und die maximal unterstützten gleichzeitigen Anforderungen auswirkt. Die Tabelle zeigt, dass Llama 2 7B deutlich unterschiedliche maximale Durchsatzwerte für verschiedene Instanztypen aufweist und diese maximalen Durchsatzwerte bei unterschiedlichen Werten gleichzeitiger Anforderungen auftreten. Diese Merkmale würden einen ML-Anwender dazu veranlassen, die Kosten einer Instanz gegenüber einer anderen zu rechtfertigen. Bei einer geringen Latenzanforderung könnte der Praktiker beispielsweise eine ml.g5.12xlarge-Instanz (4 A10G-GPUs) einer ml.g5.2xlarge-Instanz (1 A10G-GPU) vorziehen. Bei hohen Durchsatzanforderungen wäre die Verwendung einer ml.p4d.24xlarge-Instanz (8 A100-GPUs) mit vollständigem Sharding nur bei hoher Parallelität gerechtfertigt. Beachten Sie jedoch, dass es oft von Vorteil ist, stattdessen mehrere Inferenzkomponenten eines 7B-Modells auf eine einzelne ml.p4d.24xlarge-Instanz zu laden; Eine solche Unterstützung mehrerer Modelle wird später in diesem Beitrag besprochen.

Die vorherigen Beobachtungen wurden für das Modell Llama 2 7B gemacht. Ähnliche Muster gelten jedoch auch für andere Modelle. Eine wichtige Erkenntnis ist, dass die Latenz- und Durchsatzleistungszahlen von der Nutzlast, dem Instanztyp und der Anzahl gleichzeitiger Anfragen abhängen. Daher müssen Sie die ideale Konfiguration für Ihre spezifische Anwendung finden. Um die vorstehenden Zahlen für Ihren Anwendungsfall zu generieren, können Sie die verknüpfte Funktion ausführen Notizbuch, wo Sie diese Lasttestanalyse für Ihr Modell, Ihren Instance-Typ und Ihre Nutzlast konfigurieren können.

Beschleunigerspezifikationen verstehen

Die Auswahl geeigneter Hardware für die LLM-Inferenz hängt stark von spezifischen Anwendungsfällen, Benutzererfahrungszielen und dem gewählten LLM ab. In diesem Abschnitt wird versucht, ein Verständnis des Knies in der Latenz-Durchsatz-Kurve im Hinblick auf übergeordnete Prinzipien auf der Grundlage von Beschleunigerspezifikationen zu schaffen. Diese Grundsätze allein reichen nicht aus, um eine Entscheidung zu treffen: Es sind echte Benchmarks erforderlich. Der Begriff Gerät wird hier verwendet, um alle ML-Hardwarebeschleuniger zu umfassen. Wir gehen davon aus, dass das Knie in der Latenz-Durchsatz-Kurve durch einen von zwei Faktoren bestimmt wird:

• Der Speicher des Beschleunigers zum Zwischenspeichern von KV-Matrizen ist erschöpft, sodass nachfolgende Anforderungen in die Warteschlange gestellt werden
• Der Beschleuniger verfügt weiterhin über freien Speicher für den KV-Cache, verwendet jedoch eine Batch-Größe, die groß genug ist, sodass die Verarbeitungszeit eher von der Latenz des Rechenvorgangs als von der Speicherbandbreite bestimmt wird

Normalerweise bevorzugen wir eine Begrenzung durch den zweiten Faktor, da dies impliziert, dass die Beschleunigerressourcen ausgelastet sind. Im Grunde maximieren Sie die Ressourcen, für die Sie bezahlt haben. Lassen Sie uns diese Behauptung genauer untersuchen.

KV-Caching und Gerätespeicher

Standard-Transformator-Aufmerksamkeitsmechanismen berechnen die Aufmerksamkeit für jeden neuen Token im Vergleich zu allen vorherigen Token. Die meisten modernen ML-Server speichern Aufmerksamkeitsschlüssel und -werte im Gerätespeicher (DRAM), um eine Neuberechnung bei jedem Schritt zu vermeiden. Dies nennt man das KV-Cacheund wächst mit der Stapelgröße und der Sequenzlänge. Es definiert, wie viele Benutzeranfragen parallel bedient werden können, und bestimmt den Knick in der Latenz-Durchsatz-Kurve, wenn das rechengebundene Regime im zweiten Szenario, das zuvor erwähnt wurde, angesichts des verfügbaren DRAM noch nicht erfüllt ist. Die folgende Formel ist eine grobe Näherung für die maximale KV-Cache-Größe.

In dieser Formel ist B die Chargengröße und N die Anzahl der Beschleuniger. Beispielsweise verbraucht das Llama 2 7B-Modell in FP16 (2 Bytes/Parameter), das auf einer A10G-GPU (24 GB DRAM) bereitgestellt wird, etwa 14 GB, sodass 10 GB für den KV-Cache übrig bleiben. Wenn man die vollständige Kontextlänge des Modells (N = 4096) und die verbleibenden Parameter (n_layers=32, n_kv_attention_heads=32 und d_attention_head=128) einbezieht, zeigt dieser Ausdruck, dass wir aufgrund von DRAM-Einschränkungen darauf beschränkt sind, eine Stapelgröße von vier Benutzern parallel zu bedienen . Wenn Sie die entsprechenden Benchmarks in der vorherigen Tabelle beachten, ist dies eine gute Näherung für das beobachtete Knie in dieser Latenz-Durchsatz-Kurve. Methoden wie z gruppierte Abfrageaufmerksamkeit (GQA) kann die KV-Cache-Größe reduzieren, im Fall von GQA wird die Anzahl der KV-Köpfe um denselben Faktor reduziert.

Arithmetische Intensität und Gerätespeicherbandbreite

Das Wachstum der Rechenleistung von ML-Beschleunigern hat ihre Speicherbandbreite übertroffen, was bedeutet, dass sie viel mehr Berechnungen für jedes Datenbyte in der Zeit durchführen können, die für den Zugriff auf dieses Byte benötigt wird.

Das arithmetische Intensitätoder das Verhältnis von Rechenoperationen zu Speicherzugriffen für eine Operation bestimmt, ob sie durch die Speicherbandbreite oder die Rechenkapazität auf der ausgewählten Hardware begrenzt ist. Beispielsweise kann eine A10G-GPU (g5-Instanztypfamilie) mit 70 TFLOPS FP16 und einer Bandbreite von 600 GB/s etwa 116 Operationen/Byte berechnen. Eine A100-GPU (p4d-Instance-Typfamilie) kann etwa 208 Operationen/Byte berechnen. Wenn die arithmetische Intensität für ein Transformatormodell unter diesem Wert liegt, ist sie speichergebunden; Wenn es darüber liegt, ist es rechengebunden. Der Aufmerksamkeitsmechanismus für Llama 2 7B erfordert 62 Operationen/Byte für Batchgröße 1 (eine Erklärung finden Sie unter Ein Leitfaden zur LLM-Inferenz und -Leistung), was bedeutet, dass es speichergebunden ist. Wenn der Aufmerksamkeitsmechanismus speichergebunden ist, bleiben teure FLOPS ungenutzt.

Es gibt zwei Möglichkeiten, den Beschleuniger besser zu nutzen und die Rechenintensität zu erhöhen: Reduzieren Sie die erforderlichen Speicherzugriffe für die Operation (das ist was BlitzAchtung Schwerpunkte) oder erhöhen Sie die Chargengröße. Allerdings können wir unsere Batch-Größe möglicherweise nicht ausreichend erhöhen, um einen rechengebundenen Modus zu erreichen, wenn unser DRAM zu klein ist, um den entsprechenden KV-Cache aufzunehmen. Eine grobe Näherung der kritischen Batchgröße B*, die rechengebundene von speichergebundenen Regimen für Standard-GPT-Decoder-Inferenz trennt, wird durch den folgenden Ausdruck beschrieben, wobei A_mb die Beschleunigerspeicherbandbreite, A_f die Beschleuniger-FLOPS und N die Zahl ist von Beschleunigern. Diese kritische Batchgröße kann abgeleitet werden, indem man herausfindet, dass die Speicherzugriffszeit gleich der Rechenzeit ist. Beziehen auf dieser Blog-Post um Gleichung 2 und ihre Annahmen genauer zu verstehen.

Dies ist das gleiche Ops/Byte-Verhältnis, das wir zuvor für A10G berechnet haben, sodass die kritische Batch-Größe auf dieser GPU 116 beträgt. Eine Möglichkeit, sich dieser theoretischen, kritischen Batch-Größe zu nähern, besteht darin, das Modell-Sharding zu erhöhen und den Cache auf mehr N Beschleuniger aufzuteilen. Dies erhöht effektiv die KV-Cache-Kapazität sowie die speichergebundene Stapelgröße.

Ein weiterer Vorteil des Modell-Shardings ist die Aufteilung der Modellparameter- und Datenladearbeit auf N Beschleuniger. Bei dieser Art des Shardings handelt es sich um eine Art Modellparallelität, die auch als Modellparallelität bezeichnet wird Tensorparallelität. Naiverweise gibt es insgesamt das N-fache der Speicherbandbreite und der Rechenleistung. Unter der Annahme, dass es keinen Overhead jeglicher Art gibt (Kommunikation, Software usw.), würde dies die Dekodierungslatenz pro Token um N verringern, wenn wir speichergebunden sind, da die Latenz der Tokendekodierung in diesem Regime durch die Zeit begrenzt ist, die zum Laden des Modells benötigt wird Gewichte und Cache. Im wirklichen Leben führt die Erhöhung des Sharding-Grades jedoch zu einer verstärkten Kommunikation zwischen Geräten, um Zwischenaktivierungen auf jeder Modellebene gemeinsam zu nutzen. Diese Kommunikationsgeschwindigkeit wird durch die Bandbreite der Geräteverbindung begrenzt. Es ist schwierig, seine Auswirkungen genau abzuschätzen (Einzelheiten finden Sie unter Modellparallelität), aber dies kann irgendwann keine Vorteile mehr bringen oder die Leistung verschlechtern – dies gilt insbesondere für kleinere Modelle, da kleinere Datenübertragungen zu niedrigeren Übertragungsraten führen.

Um ML-Beschleuniger anhand ihrer Spezifikationen zu vergleichen, empfehlen wir Folgendes. Berechnen Sie zunächst die ungefähre kritische Chargengröße für jeden Beschleunigertyp gemäß der zweiten Gleichung und die KV-Cache-Größe für die kritische Chargengröße gemäß der ersten Gleichung. Sie können dann den verfügbaren DRAM auf dem Beschleuniger verwenden, um die Mindestanzahl an Beschleunigern zu berechnen, die erforderlich sind, um den KV-Cache und die Modellparameter anzupassen. Wenn Sie sich zwischen mehreren Beschleunigern entscheiden, priorisieren Sie die Beschleuniger in der Reihenfolge der niedrigsten Kosten pro GB/s Speicherbandbreite. Vergleichen Sie abschließend diese Konfigurationen und überprüfen Sie, welche Kosten/Tokens für Ihre Obergrenze der gewünschten Latenz am besten geeignet sind.

Wählen Sie eine Endpunktbereitstellungskonfiguration aus

Viele von SageMaker JumpStart vertriebene LLMs verwenden das Textgenerierungsinferenz (TGI) SageMaker-Container zum Modellieren. In der folgenden Tabelle wird erläutert, wie Sie verschiedene Modellbereitstellungsparameter anpassen, um entweder die Modellbereitstellung zu beeinflussen, was sich auf die Latenz-Durchsatz-Kurve auswirkt, oder den Endpunkt vor Anforderungen zu schützen, die den Endpunkt überlasten würden. Dies sind die primären Parameter, mit denen Sie Ihre Endpunktbereitstellung für Ihren Anwendungsfall konfigurieren können. Sofern nicht anders angegeben, verwenden wir die Standardeinstellung Nutzlastparameter für die Textgenerierung machen TGI-Umgebungsvariablen.

Der TGI-Server verwendet kontinuierliches Batching, das gleichzeitige Anforderungen dynamisch zusammenfasst, um einen einzigen Vorwärtsdurchlauf für die Modellinferenz zu teilen. Es gibt zwei Arten von Vorwärtsdurchläufen: Vorfüllen und Dekodieren. Jede neue Anforderung muss einen einzelnen Vorwärtsdurchlauf zum Vorfüllen ausführen, um den KV-Cache für die Eingabesequenz-Tokens zu füllen. Nachdem der KV-Cache gefüllt ist, führt ein Vorwärtsdekodierungsdurchlauf eine einzelne Vorhersage des nächsten Tokens für alle gestapelten Anforderungen durch, die iterativ wiederholt wird, um die Ausgabesequenz zu erzeugen. Wenn neue Anforderungen an den Server gesendet werden, muss der nächste Dekodierungsschritt warten, damit der Vorfüllschritt für die neuen Anforderungen ausgeführt werden kann. Dies muss geschehen, bevor diese neuen Anforderungen in nachfolgende kontinuierlich gestapelte Decodierungsschritte einbezogen werden. Aufgrund von Hardwareeinschränkungen umfasst die kontinuierliche Stapelverarbeitung zur Dekodierung möglicherweise nicht alle Anforderungen. An diesem Punkt gelangen Anforderungen in eine Verarbeitungswarteschlange und die Inferenzlatenz beginnt deutlich zu steigen, wobei der Durchsatz nur geringfügig gesteigert wird.

Es ist möglich, LLM-Latenz-Benchmarking-Analysen in Vorfülllatenz, Dekodierungslatenz und Warteschlangenlatenz zu unterteilen. Die von jeder dieser Komponenten verbrauchte Zeit unterscheidet sich grundlegend: Das Vorfüllen ist eine einmalige Berechnung, die Dekodierung erfolgt einmal für jedes Token in der Ausgabesequenz und die Warteschlangenbildung umfasst Server-Batching-Prozesse. Wenn mehrere gleichzeitige Anforderungen verarbeitet werden, wird es schwierig, die Latenzen von jeder dieser Komponenten zu trennen, da die Latenz, die eine bestimmte Client-Anfrage erfährt, Warteschlangenlatenzen umfasst, die durch die Notwendigkeit verursacht werden, neue gleichzeitige Anforderungen vorab zu füllen, sowie Warteschlangenlatenzen, die durch die Einbeziehung verursacht werden der Anfrage in Batch-Dekodierungsprozessen. Aus diesem Grund konzentriert sich dieser Beitrag auf die End-to-End-Verarbeitungslatenz. Der Knick in der Latenz-Durchsatz-Kurve tritt am Sättigungspunkt auf, an dem die Warteschlangenlatenzen deutlich anzusteigen beginnen. Dieses Phänomen tritt bei jedem Modellinferenzserver auf und wird durch Beschleunigerspezifikationen gesteuert.

Zu den allgemeinen Anforderungen während der Bereitstellung gehören die Einhaltung eines minimal erforderlichen Durchsatzes, einer maximal zulässigen Latenz, maximaler Kosten pro Stunde und maximaler Kosten für die Generierung von 1 Million Token. Sie sollten diese Anforderungen an Nutzlasten knüpfen, die Endbenutzeranfragen darstellen. Ein Entwurf zur Erfüllung dieser Anforderungen sollte viele Faktoren berücksichtigen, einschließlich der spezifischen Modellarchitektur, der Größe des Modells, der Instanztypen und der Instanzanzahl (horizontale Skalierung). In den folgenden Abschnitten konzentrieren wir uns auf die Bereitstellung von Endpunkten, um die Latenz zu minimieren, den Durchsatz zu maximieren und die Kosten zu minimieren. Bei dieser Analyse werden insgesamt 512 Token und 256 Ausgabetoken berücksichtigt.

Latenz minimieren

Latenz ist in vielen Echtzeit-Anwendungsfällen eine wichtige Anforderung. In der folgenden Tabelle sehen wir uns die Mindestlatenz für jedes Modell und jeden Instanztyp an. Durch Einstellen können Sie eine minimale Latenz erreichen MAX_CONCURRENT_REQUESTS = 1.

Um eine minimale Latenz für ein Modell zu erreichen, können Sie den folgenden Code verwenden und gleichzeitig die gewünschte Modell-ID und den gewünschten Instanztyp ersetzen:

from sagemaker.jumpstart.model import JumpStartModel model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.12xlarge", env={ "MAX_CONCURRENT_REQUESTS": "1", "MAX_INPUT_TOKENS": "256", "MAX_TOTAL_TOKENS": "512", },
)
predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True

Beachten Sie, dass sich die Latenzzahlen je nach Anzahl der Eingabe- und Ausgabe-Tokens ändern. Der Bereitstellungsprozess bleibt jedoch bis auf die Umgebungsvariablen derselbe MAX_INPUT_TOKENS machen MAX_TOTAL_TOKENS. Hier werden diese Umgebungsvariablen festgelegt, um die Latenzanforderungen des Endpunkts zu gewährleisten, da größere Eingabesequenzen möglicherweise gegen die Latenzanforderungen verstoßen. Beachten Sie, dass SageMaker JumpStart bei der Auswahl des Instanztyps bereits die anderen optimalen Umgebungsvariablen bereitstellt; Beispielsweise wird die Verwendung von ml.g5.12xlarge festgelegt SM_NUM_GPUS bis 4 in der Modellumgebung.

Maximieren Sie den Durchsatz

In diesem Abschnitt maximieren wir die Anzahl der generierten Token pro Sekunde. Dies wird normalerweise bei der maximalen Anzahl gültiger gleichzeitiger Anforderungen für das Modell und den Instanztyp erreicht. In der folgenden Tabelle geben wir den Durchsatz an, der beim größten gleichzeitigen Anforderungswert erreicht wurde, bevor bei einer Anforderung ein SageMaker-Aufruf-Timeout auftritt.

Um den maximalen Durchsatz für ein Modell zu erreichen, können Sie den folgenden Code verwenden:

from sagemaker.jumpstart.model import JumpStartModel model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.12xlarge", env={ "MAX_CONCURRENT_REQUESTS": "128", # For your application, identify it from the benchmarking table with the maximum feasible concurrent requests. "MAX_INPUT_TOKENS": "256", "MAX_TOTAL_TOKENS": "512", },
)
predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True

Beachten Sie, dass die maximale Anzahl gleichzeitiger Anforderungen vom Modelltyp, Instanztyp, der maximalen Anzahl von Eingabe-Tokens und der maximalen Anzahl von Ausgabe-Tokens abhängt. Daher sollten Sie diese Parameter vor der Einstellung festlegen MAX_CONCURRENT_REQUESTS.

Beachten Sie auch, dass ein Benutzer, der an einer Minimierung der Latenz interessiert ist, oft im Widerspruch zu einem Benutzer steht, der an einer Maximierung des Durchsatzes interessiert ist. Ersteres ist an Echtzeitantworten interessiert, während letzteres an der Stapelverarbeitung interessiert ist, sodass die Endpunktwarteschlange immer gesättigt ist und dadurch Ausfallzeiten bei der Verarbeitung minimiert werden. Benutzer, die den Durchsatz abhängig von den Latenzanforderungen maximieren möchten, sind oft daran interessiert, im Knie der Latenz-Durchsatz-Kurve zu arbeiten.

Kosten minimieren

Die erste Möglichkeit zur Kostenminimierung besteht darin, die Kosten pro Stunde zu minimieren. Damit können Sie ein ausgewähltes Modell mit den niedrigsten Kosten pro Stunde auf der SageMaker-Instanz bereitstellen. Informationen zur Echtzeit-Preisgestaltung von SageMaker-Instanzen finden Sie unter Amazon SageMaker Preise. Im Allgemeinen ist der Standardinstanztyp für SageMaker JumpStart-LLMs die kostengünstigste Bereitstellungsoption.

Die zweite Möglichkeit zur Kostenminimierung besteht darin, die Kosten für die Generierung von 1 Million Token zu minimieren. Dies ist eine einfache Transformation der Tabelle, die wir zuvor besprochen haben, um den Durchsatz zu maximieren. Dabei können Sie zunächst die Zeit in Stunden berechnen, die zum Generieren von 1 Million Token benötigt wird (1e6 / Durchsatz / 3600). Anschließend können Sie diese Zeit multiplizieren, um 1 Million Token mit dem Stundenpreis der angegebenen SageMaker-Instanz zu generieren.

Beachten Sie, dass Instanzen mit den niedrigsten Kosten pro Stunde nicht mit Instanzen mit den niedrigsten Kosten für die Generierung von 1 Million Token identisch sind. Wenn die Aufrufanforderungen beispielsweise sporadisch sind, könnte eine Instanz mit den niedrigsten Kosten pro Stunde optimal sein, während in den Drosselungsszenarien die niedrigsten Kosten für die Generierung einer Million Token möglicherweise besser geeignet sind.

Kompromiss zwischen Tensorparallelität und Multimodell

In allen vorherigen Analysen haben wir die Bereitstellung eines einzelnen Modellreplikats mit einem Tensor-Parallelitätsgrad in Betracht gezogen, der der Anzahl der GPUs im Bereitstellungsinstanztyp entspricht. Dies ist das Standardverhalten von SageMaker JumpStart. Wie bereits erwähnt, kann das Sharding eines Modells die Modelllatenz und den Durchsatz jedoch nur bis zu einer bestimmten Grenze verbessern, ab der die Anforderungen an die Kommunikation zwischen Geräten die Rechenzeit dominieren. Dies bedeutet, dass es häufig von Vorteil ist, mehrere Modelle mit einem niedrigeren Tensor-Parallelitätsgrad auf einer einzelnen Instanz bereitzustellen, anstatt ein einzelnes Modell mit einem höheren Tensor-Parallelitätsgrad.

Hier stellen wir Llama 2 7B- und 13B-Endpunkte auf ml.p4d.24xlarge-Instanzen mit den Tensorparallelitätsgraden (TP) von 1, 2, 4 und 8 bereit. Aus Gründen der Klarheit des Modellverhaltens lädt jeder dieser Endpunkte nur ein einzelnes Modell.

Unsere vorherigen Analysen zeigten bereits erhebliche Durchsatzvorteile bei ml.p4d.24xlarge-Instanzen, was häufig zu einer besseren Leistung in Bezug auf die Kosten für die Generierung von 1 Million Tokens gegenüber der g5-Instanzfamilie unter Bedingungen hoher gleichzeitiger Anforderungslast führt. Diese Analyse zeigt deutlich, dass Sie den Kompromiss zwischen Modell-Sharding und Modell-Replikation innerhalb einer einzelnen Instanz berücksichtigen sollten; Das heißt, ein vollständig fragmentiertes Modell ist in der Regel nicht die beste Nutzung der ml.p4d.24xlarge-Rechenressourcen für die Modellfamilien 7B und 13B. Tatsächlich erhalten Sie für die 7B-Modellfamilie den besten Durchsatz für eine einzelne Modellreplik mit einem Tensor-Parallelitätsgrad von 4 statt 8.

Von hier aus können Sie extrapolieren, dass die Konfiguration mit dem höchsten Durchsatz für das 7B-Modell einen Tensor-Parallelitätsgrad von 1 mit acht Modellreplikaten umfasst und die Konfiguration mit dem höchsten Durchsatz für das 13B-Modell wahrscheinlich einen Tensor-Parallelitätsgrad von 2 mit vier Modellreplikaten umfasst. Weitere Informationen dazu, wie Sie dies erreichen, finden Sie unter Reduzieren Sie die Kosten für die Modellbereitstellung um durchschnittlich 50 %, indem Sie die neuesten Funktionen von Amazon SageMaker nutzen, das die Verwendung von inferenzkomponentenbasierten Endpunkten demonstriert. Aufgrund von Lastausgleichstechniken, Server-Routing und der gemeinsamen Nutzung von CPU-Ressourcen können Sie möglicherweise keine vollständigen Durchsatzverbesserungen erzielen, die genau der Anzahl der Replikate mal dem Durchsatz für ein einzelnes Replikat entsprechen.

Horizontale Skalierung

Wie bereits erwähnt, unterliegt jede Endpunktbereitstellung einer Beschränkung der Anzahl gleichzeitiger Anforderungen, abhängig von der Anzahl der Eingabe- und Ausgabetokens sowie dem Instanztyp. Wenn dies nicht Ihren Durchsatz- oder gleichzeitigen Anforderungsanforderungen entspricht, können Sie eine Skalierung durchführen, um mehr als eine Instanz hinter dem bereitgestellten Endpunkt zu nutzen. SageMaker führt automatisch einen Lastausgleich von Abfragen zwischen Instanzen durch. Der folgende Code stellt beispielsweise einen Endpunkt bereit, der von drei Instanzen unterstützt wird:

model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.2xlarge",
)
predictor = model.deploy( accept_eula=False, # Change EULA acceptance to True initial_instance_count = 3,
)

Die folgende Tabelle zeigt den Durchsatzgewinn als Faktor der Anzahl der Instanzen für das Modell Llama 2 7B.

Bemerkenswert ist, dass sich das Knie in der Latenz-Durchsatz-Kurve nach rechts verschiebt, da höhere Instanzzahlen eine größere Anzahl gleichzeitiger Anfragen innerhalb des Multi-Instanz-Endpunkts verarbeiten können. In dieser Tabelle gilt der Wert für gleichzeitige Anforderungen für den gesamten Endpunkt und nicht für die Anzahl gleichzeitiger Anforderungen, die jede einzelne Instanz empfängt.

Sie können auch Autoscaling verwenden, eine Funktion zur Überwachung Ihrer Arbeitslasten und zur dynamischen Anpassung der Kapazität, um eine stabile und vorhersehbare Leistung bei möglichst geringen Kosten aufrechtzuerhalten. Dies würde den Rahmen dieses Beitrags sprengen. Weitere Informationen zur automatischen Skalierung finden Sie unter Konfigurieren von Autoscaling-Inferenzendpunkten in Amazon SageMaker.

Rufen Sie den Endpunkt mit gleichzeitigen Anforderungen auf

Nehmen wir an, Sie verfügen über eine große Anzahl von Abfragen, die Sie verwenden möchten, um Antworten aus einem bereitgestellten Modell unter Bedingungen mit hohem Durchsatz zu generieren. Im folgenden Codeblock stellen wir beispielsweise eine Liste mit 1,000 Nutzlasten zusammen, wobei jede Nutzlast die Generierung von 100 Token anfordert. Insgesamt fordern wir die Generierung von 100,000 Token.

payload = { "inputs": "I believe the meaning of life is to ", "parameters": {"max_new_tokens": 100, "details": True},
}
total_requests = 1000
payloads = [payload,] * total_requests

Wenn Sie eine große Anzahl von Anfragen an die SageMaker-Laufzeit-API senden, können Drosselungsfehler auftreten. Um dies zu mildern, können Sie einen benutzerdefinierten SageMaker-Laufzeitclient erstellen, der die Anzahl der Wiederholungsversuche erhöht. Sie können das resultierende SageMaker-Sitzungsobjekt entweder dem bereitstellen JumpStartModel Konstrukteur oder sagemaker.predictor.retrieve_default wenn Sie einen neuen Prädiktor an einen bereits bereitgestellten Endpunkt anhängen möchten. Im folgenden Code verwenden wir dieses Sitzungsobjekt, wenn wir ein Llama 2-Modell mit Standardkonfigurationen von SageMaker JumpStart bereitstellen:

import boto3
from botocore.config import Config
from sagemaker.session import Session
from sagemaker.jumpstart.model import JumpStartModel sagemaker_session = Session( sagemaker_runtime_client=boto3.client( "sagemaker-runtime", config=Config(connect_timeout=10, retries={"mode": "standard", "total_max_attempts": 20}), )
)
model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", sagemaker_session=sagemaker_session
)
predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True

Dieser bereitgestellte Endpunkt hat MAX_CONCURRENT_REQUESTS = 128 standardmäßig. Im folgenden Block verwenden wir die Concurrent-Futures-Bibliothek, um den Endpunkt für alle Nutzlasten mit 128 Arbeitsthreads aufzurufen. Der Endpunkt verarbeitet höchstens 128 gleichzeitige Anfragen, und immer wenn eine Anfrage eine Antwort zurückgibt, sendet der Ausführende sofort eine neue Anfrage an den Endpunkt.

import time
from concurrent import futures concurrent_requests = 128 time_start = time.time()
with futures.ThreadPoolExecutor(max_workers=concurrent_requests) as executor: responses = list(executor.map(predictor.predict, payloads)) total_tokens = sum([response[0]["details"]["generated_tokens"] for response in responses])
token_throughput = total_tokens / (time.time() - time_start)

Dies führt zur Generierung von insgesamt 100,000 Tokens mit einem Durchsatz von 1255 Tokens/Sek. auf einer einzelnen ml.g5.2xlarge-Instanz. Die Bearbeitung dauert etwa 80 Sekunden.

Beachten Sie, dass sich dieser Durchsatzwert erheblich vom maximalen Durchsatz für Llama 2 7B auf ml.g5.2xlarge in den vorherigen Tabellen dieses Beitrags unterscheidet (486 Token/Sek. bei 64 gleichzeitigen Anforderungen). Dies liegt daran, dass die Eingabenutzlast 8 statt 256 Token verwendet, die Ausgabetokenanzahl 100 statt 256 beträgt und die kleineren Tokenanzahlen 128 gleichzeitige Anforderungen ermöglichen. Dies ist eine letzte Erinnerung daran, dass alle Latenz- und Durchsatzzahlen von der Nutzlast abhängig sind! Eine Änderung der Anzahl der Nutzlast-Token wirkt sich auf Batch-Prozesse während der Modellbereitstellung aus, was sich wiederum auf die Vorfüll-, Dekodierungs- und Warteschlangenzeiten für Ihre Anwendung auswirkt.

Zusammenfassung

In diesem Beitrag stellten wir das Benchmarking von SageMaker JumpStart LLMs vor, darunter Llama 2, Mistral und Falcon. Wir haben außerdem einen Leitfaden zur Optimierung von Latenz, Durchsatz und Kosten für Ihre Endpunkt-Bereitstellungskonfiguration vorgestellt. Sie können beginnen, indem Sie Folgendes ausführen zugehöriges Notizbuch um Ihren Anwendungsfall zu vergleichen.

Über die Autoren

 Kyle Ulrich ist angewandter Wissenschaftler im Amazon SageMaker JumpStart-Team. Seine Forschungsinteressen umfassen skalierbare Algorithmen für maschinelles Lernen, Computer Vision, Zeitreihen, Bayes'sche Nichtparametrik und Gaußsche Prozesse. Er promovierte an der Duke University und hat Artikel in NeurIPS, Cell und Neuron veröffentlicht.

Dr. Vivek Madan ist ein angewandter Wissenschaftler im Amazon SageMaker JumpStart-Team. Er promovierte an der University of Illinois at Urbana-Champaign und war Postdoktorand an der Georgia Tech. Er ist ein aktiver Forscher in den Bereichen maschinelles Lernen und Algorithmendesign und hat Artikel auf Konferenzen von EMNLP, ICLR, COLT, FOCS und SODA veröffentlicht.

Dr. Ashish Khetan ist Senior Applied Scientist bei Amazon SageMaker JumpStart und hilft bei der Entwicklung von Algorithmen für maschinelles Lernen. Er promovierte an der University of Illinois Urbana-Champaign. Er ist ein aktiver Forscher im Bereich maschinelles Lernen und statistische Inferenz und hat zahlreiche Artikel auf NeurIPS-, ICML-, ICLR-, JMLR-, ACL- und EMNLP-Konferenzen veröffentlicht.

Joao Moura ist Senior AI/ML Specialist Solutions Architect bei AWS. João hilft AWS-Kunden – von kleinen Start-ups bis hin zu großen Unternehmen – große Modelle effizient zu trainieren und bereitzustellen und allgemeiner ML-Plattformen auf AWS aufzubauen.

• SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
• PlatoData.Network Vertikale generative KI. Motiviere dich selbst. Hier zugreifen.
• PlatoAiStream. Web3-Intelligenz. Wissen verstärkt. Hier zugreifen.
• PlatoESG. Kohlenstoff, CleanTech, Energie, Umwelt, Solar, Abfallwirtschaft. Hier zugreifen.
• PlatoHealth. Informationen zu Biotechnologie und klinischen Studien. Hier zugreifen.
• Quelle: https://aws.amazon.com/blogs/machine-learning/benchmark-and-optimize-endpoint-deployment-in-amazon-sagemaker-jumpstart/