Bereitstellung von LLMS in großem Maßstab

Die Bereitstellung von Open-Source-Modellen für große Sprachen (LLMs) in großem Maßstab bei gleichzeitiger Gewährleistung von Zuverlässigkeit, niedriger Latenz und Kosteneffektivität kann eine Herausforderung sein. Auf der Grundlage unserer umfassenden Erfahrung beim Aufbau einer LLM-Infrastruktur und deren erfolgreicher Bereitstellung für unsere Kunden habe ich eine Liste der wichtigsten Herausforderungen zusammengestellt, mit denen Einzelpersonen in diesem Prozess häufig konfrontiert sind.

Hauptprobleme bei der Bereitstellung von LLMs

Finden Sie den optimalsten Weg, um eine Instanz des Modells zu hosten

Es gibt mehrere Optionen für Modellserver, um LLM zu hosten, und es gibt verschiedene Konfigurationsparameter, die angepasst werden müssen, um die beste Leistung für Ihren Anwendungsfall zu erzielen. TGI, VLLM, LLM öffnen sind einige der gängigsten Frameworks für das Hosten dieser LLMs. Eine ausführliche Analyse finden Sie hier Blog. Um das richtige Framework für Ihr Hosting auszuwählen, ist es wichtig, die Leistung dieser Frameworks für Ihren Anwendungsfall zu vergleichen und dasjenige auszuwählen, das am besten zu Ihrem Anwendungsfall passt. Außerdem haben diese Frameworks ihre einzigen einstellbaren Parameter, mit denen Sie die besten Benchmarking-Ergebnisse erzielen können.

Suche nach der GPU-Flotte

GPUs sind teuer und schwer zu finden. Es gibt verschiedene GPU-Cloud-Anbieter, die von bekannten Clouds wie AWS, GCP und Azure bis hin zu kleinen Cloud-Anbietern wie Runpod, Fluidstack, Paperspace und Coreweave reichen. Die Preise und Angebote jedes dieser Anbieter sind sehr unterschiedlich. Die Zuverlässigkeit ist auch bei einigen der neueren GPU-Cloud-Anbieter nach wie vor ein Problem.

Aufrechterhaltung der Zuverlässigkeit

Das ist in der Praxis schwieriger als es klingt. Aufgrund unserer Erfahrung mit der Ausführung von LLMs in der Produktion sollten Sie auf seltsame, einmalige Fehler in Modellservern vorbereitet sein, die dazu führen können, dass Ihr Prozess hängen bleibt und alle Anfragen zu einem Timeout führen. Es ist sehr wichtig, dass geeignete Prozessmanager und Bereitschafts-/Verfügbarkeitstests eingerichtet sind, damit sich die Modellserver nach Ausfällen erholen können oder der Datenverkehr nahtlos von einer fehlerhaften zu einer intakten Instanz übergehen kann.

Sicherstellung eines hohen Durchsatzes bei niedriger Latenz

Beim Benchmarking ist es sehr wichtig, den Kompromiss zwischen Latenz und Durchsatz herauszufinden. Wenn wir die Anzahl der gleichzeitigen Anfragen an das Modell erhöhen, steigt die Latenz bis zu einem bestimmten Punkt leicht an. Danach verschlechtert sich die Latenz drastisch. Das richtige Gleichgewicht zwischen Latenz, Durchsatz und Kosten zu finden, kann zeitaufwändig und fehleranfällig sein. Wir haben einige Blogs, in denen solche Benchmarks für skizziert werden Lama 7B und Lama 13B.

Benchmarking Llama-2-70B

This blog captures Llama-2-70B benchmarks - where a model excels and the areas where it struggles. Make informed decisions about its practical deployment.

TrueFoundry Blog Truefoundry

‍

Benchmarking Falcon-40B

This blog captures Falcon-40B-Instruct benchmarks - where a model excels and the areas where it struggles. Make informed decisions about its practical deployment.

TrueFoundry Blog Truefoundry

‍

Stellen Sie eine schnelle Startzeit des Modells sicher

LLM-Modelle sind riesig groß und reichen von 10s bis 100GB. Es kann viel Zeit in Anspruch nehmen, das Modell herunterzuladen, sobald der Modellserver bereit ist, und es dann von der Festplatte in den Speicher zu laden. Es ist wichtig, dass Sie das Modell auf der Festplatte zwischenspeichern, damit wir das Modell nicht erneut herunterladen, falls der Prozess neu gestartet wird. Um Netzwerkkosten zu sparen, ist es außerdem besser, das Modell einmal herunterzuladen und die Festplatte auf mehrere Replikate aufzuteilen, anstatt dass jedes Replikat das Modell wiederholt über das Internet herunterlädt.

Autoscaling einrichten

Autoscaling ist bei LLM-Hosting aufgrund der hohen Startzeit eines anderen Replikats schwierig. Wenn die Auslastung sehr hoch ist, müssen wir die Infrastruktur in der Regel entsprechend der Spitzenreplikate bereitstellen. Wenn der Spitzenwert jedoch zu bestimmten Tageszeiten erwartet wird, funktioniert zeitbasiertes Autoscaling gut.

Wie bringt man LLMs zur Produktion?

1. Beginnen Sie mit dem Benchmarking des LLM mit verschiedenen Modellservern, GPUs und Parametern, um herauszufinden, wo Sie die beste Leistung erzielen. Idealerweise sollten Sie über Daten aus dem Benchmarking verfügen, die denen in diesem Dokument ähneln Blog für Llama7B.
2. Sie können Modelle auf mehreren GPUs auf Kubernetes oder auf Bare-Metal-Instances einrichten. Wir würden Kubernetes idealerweise empfehlen, da Sie alle Integritätsprüfungen, das Routing und den Failover kostenlos erhalten.
3. Platzieren Sie das Modell auf einem gemeinsam genutzten Volume wie EFS, damit Modelle nicht wiederholt heruntergeladen werden, und stellen Sie das Volume auf allen Pods bereit.
4. Richten Sie die Überwachung und Alarmierung für die Instanzen ein.
5. Idealerweise sollten Sie über eine Ebene verfügen, die die Token-Zählung bei jeder Anfrage für Sie übernehmen kann, da das Muster des eingehenden Datenverkehrs einfacher zu verstehen ist.
6. Beobachten Sie das Verkehrsmuster und passen Sie die Autoscaling-Richtlinie entsprechend an.
7. Sorgen Sie für eine Mischung aus Spot- und On-Demand-Instances, um die Kosten zu senken.

Architektur für das Hosting von LLMs on Scale

Wir haben mit dem oben genannten Ansatz begonnen, sind aber bald auf die unten stehende Architektur migriert, die es uns ermöglicht, LLMs mit sehr niedrigen Kosten und hoher Zuverlässigkeit zu hosten.

Wir erstellen grundsätzlich mehrere GPU-Pools bei verschiedenen Cloud-Anbietern in verschiedenen Regionen und verwenden in der Regel Spot-Instances, wenn es sich um AWS-, GCP- oder Azure-Instanzen handelt, oder um On-Demand-Knoten kleinerer Cloud-Anbieter. Wir platzieren auch eine Warteschlange in der Mitte, die alle Anfragen aufnimmt und die verschiedenen GPU-Pools aus der Warteschlange verarbeiten, und die Antwort an die Warteschlange zurückgibt, von der aus die HTTP-Antwort an den Benutzer zurückgegeben wird. Ein paar Vorteile dieser Architektur:

1. Hohe Zuverlässigkeit mit Spot-Instances: Da wir die Last auf Spot-Instances von mehreren Cloud-Anbietern und Regionen verteilen, wird die Wahrscheinlichkeit, dass alle Spot-Instances ausfallen, extrem langsam und jeder der Pools kann wachsen, um die Last aufzunehmen, wenn ein Pool ausfällt.
2. Die Warteschlange sorgt für zusätzliche Zuverlässigkeit bei hoher Auslastung: Ein HTTP-Dienst beginnt, 503 Sekunden zurückzugeben, wenn plötzliche Spitzen auftreten. Aufgrund der Warteschlange dazwischen sind wir in der Lage, hohe Workloads zu tolerieren. Während der Spitzen nimmt die Latenz für die Anfragen leicht zu, aber sie schlagen nicht fehl. Das Hinzufügen der Warteschlange in der Mitte erhöht eine Gesamtlatenz von etwa 10-20 ms, was für den LLM-Inferenz-Anwendungsfall in Ordnung ist, da die gesamte Inferenzlatenz in der Größenordnung von Sekunden liegt.
3. Kostenreduzierung: Dies trägt dazu bei, die Kosten im Vergleich zum Hosten von LLMs auf On-Demand-Instances drastisch zu senken. Im Folgenden werden wir die Kosten detailliert vergleichen.
4. Detaillierte Analytik: Die LLM-Gateway-Ebene hilft uns bei der Berechnung der detaillierten Analysen der eingehenden Anfragen und kann auch die Token-Verteilung unter den Anfragen berechnen. Wir können auch mit der Protokollierung der Anfragen beginnen, um die Feinabstimmung später zu ermöglichen.
5. Keine Abhängigkeit von einem Cloud-Anbieter: Diese Architektur ermöglicht es uns, unseren einen GPU-Anbieter problemlos gegen einen anderen auszutauschen, wenn wir irgendwo einen besseren Preis ohne Ausfallzeiten finden. Auch für den Fall, dass ein Anbieter ausfällt, sorgen die anderen Pools dafür, dass das System reibungslos läuft!

Kostenreduzierung für das Hosting von LLMs

Nehmen wir ein Szenario an, in dem ein LLM mit 10 Anfragen pro Sekunde zu Spitzenzeiten und durchschnittlich 7 Anfragen pro Sekunde gehostet wird. Nehmen wir an, wir finden mithilfe von Benchmarking heraus, dass eine A100-GB-GPU-Maschine 0,5 Umdrehungen pro Sekunde erreichen kann. Denken wir auch daran, dass der Traffic 12 Stunden am Tag länger ist (etwa 9-10 RPS) und in den restlichen 12 Stunden am Tag gering ist (7-8 RPS).

Basierend auf den obigen Daten können wir die Anzahl der GPU-Maschinen ermitteln, die im 12-Stunden-Spitzenfenster und außerhalb des 12-Stunden-Zeitfensters benötigt werden:

12-Stunden-Spitzenfenster: 20 GPU
12-Stunden-Fenster außerhalb der Spitzenzeiten: 15 GPU

Wir werden die Kosten für den Betrieb des LLM mit Sagemaker vergleichen, naives Hosten auf On-Demand-Maschinen in AWS, GCP und Azure und die Verwendung unserer eigenen Architektur mit Autoscaling.

Kosten für das Hosting auf Sagemaker (Region US-East-1):

Kosten für 8 A100 80-GB-Maschinen (ml.p4de.24xlarge) -> 47,11$ pro Stunde

Wir benötigen 2 Maschinen außerhalb der Hauptverkehrszeiten und 3 Maschinen in den Hauptverkehrszeiten.

Monatliche Gesamtkosten: 85.000 USD

Kosten für das direkte Hosting auf AWS-Knoten:

Kosten für 8 A100 80-GB-Maschinen (p4de.24xlarge) -> 40.966$ pro Stunde

Wir benötigen 2 Maschinen außerhalb der Spitzenzeiten und 3 Maschinen in den Spitzenzeiten:

Monatliche Gesamtkosten: 73.000 USD

Kosten für das Hosting auf Truefoundry

Mithilfe der Spot-Instances und anderer GPU-Anbieter sind wir in der Lage, den durchschnittlichen GPU-Preis auf 2,5$ pro Stunde zu senken. Gehen wir davon aus, dass 15 GPU außerhalb der Spitzenzeiten und 20 GPU zu Spitzenzeiten verwendet werden, belaufen sich die Gesamtkosten auf:

2,5$ * (15*12 + 20*12) * 30 (Tage pro Monat) = 31.000$

Wie wir sehen können, können wir dasselbe LLM zu fast 30% des Preises des Sagemakers mit hoher Zuverlässigkeit hosten. Es werden jedoch Anstrengungen erforderlich sein, um diese Architektur aufzubauen und zu verwalten. Wahre Gießerei kann Ihnen helfen, es für Sie zu hosten oder es problemlos auf Ihrem eigenen Cloud-Konto zu hosten und gleichzeitig Kosten zu sparen.