LLMs in großem Maßstab bereitstellen

Die Bereitstellung von Open-Source Large Language Models (LLMs) in großem Maßstab bei gleichzeitiger Gewährleistung von Zuverlässigkeit, geringer Latenz und Kosteneffizienz kann ein anspruchsvolles Unterfangen sein. Ausgehend von unserer umfangreichen Erfahrung beim Aufbau von LLM-Infrastrukturen und deren erfolgreichen Bereitstellung für unsere Kunden habe ich die wichtigsten Herausforderungen zusammengestellt, denen man bei diesem Prozess gewöhnlich begegnet.

Hauptprobleme bei der Bereitstellung von LLMs

Den optimalen Weg zum Hosten einer Modellinstanz finden

Es gibt verschiedene Optionen für Modellserver zum Hosten von LLMs und unterschiedliche Konfigurationsparameter, die eingestellt werden können, um die beste Leistung für Ihren Anwendungsfall zu erzielen. TGI, VLLM und OpenLLM gehören zu den verbreitetsten Frameworks für das Hosten dieser LLMs. Eine detaillierte Analyse finden Sie in diesem Blogbeitrag. Um das richtige Framework für Ihr Hosting auszuwählen, ist es wichtig, die Leistung dieser Frameworks für Ihren Anwendungsfall zu benchmarken und dasjenige auszuwählen, das am besten zu Ihren Anforderungen passt. Zudem verfügen diese Frameworks über eigene abstimmbare Parameter, mit denen Sie die besten Benchmarking-Ergebnisse erzielen können.

Eine Flotte von GPUs finden

GPUs sind teuer und schwer zu bekommen. Es gibt verschiedene GPU-Cloud-Anbieter, die von prominenten Hyperscalern wie AWS, GCP und Azure bis hin zu kleineren Cloud-Anbietern wie Runpod, Fluidstack, Paperspace und Coreweave reichen. Die Preise und Angebote der einzelnen Anbieter variieren stark. Auch die Zuverlässigkeit bleibt bei einigen der neueren GPU-Cloud-Anbieter ein Bedenken.

Zuverlässigkeit aufrechterhalten

Das ist in der Praxis schwerer als es klingt. Aus unserer Erfahrung mit dem Betrieb von LLMs in der Produktion sollten Sie auf seltsame Einzelfall-Bugs in Modellservern vorbereitet sein, die Ihren Prozess einfrieren und alle Anfragen in Zeitüberschreitungen (Timeouts) laufen lassen können. Es ist sehr wichtig, geeignete Prozessmanager sowie Readiness-/Liveness-Probes einzurichten, damit sich die Modellserver nach Fehlern erholen können oder der Datenverkehr nahtlos von einer fehlerhaften auf eine gesunde Instanz umgeleitet werden kann.

Hohen Durchsatz bei geringer Latenz gewährleisten

Beim Benchmarking ist es sehr wichtig, den Kompromiss zwischen Latenz und Durchsatz zu ermitteln. Wenn wir die Anzahl der gleichzeitigen Anfragen an das Modell erhöhen, steigt die Latenz bis zu einem gewissen Punkt leicht an, woraufhin sie sich drastisch verschlechtert. Die richtige Balance zwischen Latenz, Durchsatz und Kosten zu finden, kann zeitaufwendig und fehleranfällig sein. Wir haben einige Blogs, die solche Benchmarks für Llama7B und Llama13B beschreiben.

Benchmarking von Llama-2-70B

Dieser Blogbeitrag erfasst Llama-2-70B-Benchmarks – wo ein Modell glänzt und in welchen Bereichen es Probleme hat. Treffen Sie fundierte Entscheidungen über seinen praktischen Einsatz.

TrueFoundry Blog Truefoundry

‍

Benchmarking von Falcon-40B

Dieser Blogbeitrag erfasst Falcon-40B-Instruct-Benchmarks – wo ein Modell glänzt und in welchen Bereichen es Probleme hat. Treffen Sie fundierte Entscheidungen über seinen praktischen Einsatz.

TrueFoundry Blog Truefoundry

‍

Schnelle Startzeit des Modells sicherstellen

LLM-Modelle sind riesig – ihre Größe reicht von 10 bis zu 100 GB. Es kann sehr lange dauern, das Modell herunterzuladen, sobald der Modellserver bereit ist, und es dann von der Festplatte in den Arbeitsspeicher zu laden. Es ist unerlässlich, das Modell auf der Festplatte zu zwischenzuspeichern (Caching), damit wir das Modell im Falle eines Prozessneustarts nicht erneut herunterladen müssen. Um Netzwerk kosten zu sparen, ist es außerdem besser, das Modell einmal herunterzuladen und den Speicherplatz unter mehreren Replikaten zu teilen, anstatt dass jedes Replikat das Modell wiederholt über das Internet herunterlädt.

Autoscaling einrichten

Autoscaling ist beim LLM-Hosting aufgrund der hohen Startzeit weiterer Replikate knifflig. Wenn die Last sehr sprunghaft ist, müssen wir die Infrastruktur in der Regel entsprechend den Spitzenreplikaten bereitstellen – wenn die Spitze jedoch zu bestimmten Tageszeiten erwartet wird, funktioniert zeitbasiertes Autoscaling gut.

Wie bringt man LLMs in die Produktion?

1. Beginnen Sie mit dem Benchmarking des LLM mit verschiedenen Modellservern, GPUs und Parametern, um zu sehen, wo Sie die beste Leistung erzielen. Idealerweise sollten Sie über Daten aus dem Benchmarking verfügen, die denen in diesem Blog für Llama7B ähneln.
2. Sie können Modelle auf mehreren GPUs auf Kubernetes oder auf Bare-Metal-Instanzen einrichten. Wir würden idealerweise Kubernetes empfehlen, da Sie hier alle Health Checks, das Routing und Failover kostenlos dazubekommen.
3. Legen Sie das Modell auf einem gemeinsamen Volume wie EFS ab, damit Modelle nicht wiederholt heruntergeladen werden, und hängen Sie das Volume an alle Pods an.
4. Richten Sie Monitoring und Alerting für die Instanzen ein.
5. Verfügen Sie idealerweise über eine Schicht, die die Token-Zählung für Sie bei jeder Anfrage übernehmen kann, da sich das Muster des eingehenden Datenverkehrs so leichter verstehen lässt.
6. Beobachten Sie das Traffic-Muster und passen Sie die Autoscaling-Richtlinie entsprechend an.
7. Nutzen Sie eine Mischung aus Spot- und On-Demand-Instanzen, um die Kosten zu senken.

Architektur für das Hosten von LLMs im großen Maßstab

Wir haben mit dem obigen Ansatz begonnen, sind jedoch bald zu der unten stehenden Architektur migriert, die es uns ermöglicht, LLMs mit sehr geringen Kosten und hoher Zuverlässigkeit zu hosten.

Wir erstellen im Wesentlichen mehrere GPU-Pools bei verschiedenen Cloud-Anbietern in unterschiedlichen Regionen. Wir nutzen gewöhnlich Spot-Instanzen, wenn es sich um AWS, GCP oder Azure handelt, oder On-Demand-Knoten von kleineren Cloud-Anbietern. Wir schalten außerdem eine Queue dazwischen, die alle Anfragen aufnimmt. Die verschiedenen GPU-Pools verarbeiten die Anfragen aus der Queue und senden die Antwort zurück an die Queue, von wo aus die HTTP-Antwort an den Benutzer zurückgegeben wird. Einige Vorteile dieser Architektur:

1. Hohe Zuverlässigkeit mit Spot-Instanzen: Da wir die Last über Spot-Instanzen mehrerer Cloud-Anbieter und Regionen verteilen, ist die Wahrscheinlichkeit sehr gering, dass alle Spot-Instanzen gleichzeitig ausfallen. Jeder der Pools kann wachsen, um die Last aufzunehmen, wenn ein Pool ausfällt.
2. Queue sorgt für zusätzliche Zuverlässigkeit bei hoher Last: Ein HTTP-Dienst beginnt bei plötzlichen Lastspitzen mit der Rückgabe von 503-Fehlern. Durch die Queue dazwischen sind wir in der Lage, sprunghafte Arbeitslasten zu tolerieren – es gibt zwar einen leichten Anstieg der Latenz für die Anfragen während der Spitze, aber sie schlagen nicht fehl. Das Hinzufügen der Queue in der Mitte führt zu einer Gesamtlatenz von etwa 10–20 ms, was für den LLM-Inferenz-Anwendungsfall in Ordnung ist, da die Gesamtinferenzlatenz im Bereich von Sekunden liegt.
3. Kostenreduzierung: Dies hilft, die Kosten im Vergleich zum Hosten von LLMs auf On-Demand-Instanzen drastisch zu senken – wir werden unten einen detaillierten Kostenvergleich anstellen.
4. Detaillierte Analysen: Die LLM-Gateway-Schicht hilft uns bei der Berechnung detaillierter Analysen über die eingehenden Anfragen und kann auch die Token-Verteilung unter den Anfragen berechnen. Wir können auch damit beginnen, die Anfragen zu protokollieren, um späteres Finetuning zu ermöglichen.
5. Keine Abhängigkeit von einem einzelnen Cloud-Anbieter: Diese Architektur ermöglicht es uns, einen GPU-Anbieter problemlos gegen einen anderen auszutauschen, wenn wir irgendwo einen besseren Preis finden – und das ohne Ausfallzeiten. Sollte ein Anbieter ausfallen, halten die anderen Pools das System reibungslos am Laufen!
Kostenreduzierung beim Hosten von LLMs

Nehmen wir das Szenario eines LLM-Hostings mit 10 Anfragen pro Sekunde (RPS) in der Spitze und durchschnittlich 7 Anfragen pro Sekunde. Nehmen wir an, wir stellen durch Benchmarking fest, dass eine A100 80GB GPU-Maschine 0,5 RPS verarbeiten kann. Nehmen wir außerdem an, dass der Datenverkehr 12 Stunden am Tag höher ist (ca. 9–10 RPS) und in den restlichen 12 Stunden des Tages niedriger ausfällt (7–8 RPS).

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

12-Stunden-Spitzenfenster: 20 GPUs
12-Stunden-Nebenzeitenfenster: 15 GPUs

Wir vergleichen die Kosten für den Betrieb des LLM mit Sagemaker, dem naiven Hosten auf On-Demand-Maschinen in AWS, GCP und Azure sowie der Nutzung unserer eigenen Architektur mit Autoscaling.

Kosten für das Hosten auf Sagemaker (Region us-east-1):

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

Wir benötigen 2 Maschinen außerhalb der Spitzenzeiten und 3 Maschinen während der Spitzenzeiten.

Monatliche Gesamtkosten: $ 85K

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

Kosten für eine 8x A100 80GB Maschine (p4de.24xlarge) -> $ 40,966 pro Stunde

Wir benötigen 2 Maschinen außerhalb der Spitzenzeiten und 3 Maschinen während der Spitzenzeiten:

Monatliche Gesamtkosten: $ 73K

Kosten für das Hosten auf TrueFoundry

Durch die Nutzung von Spot-Instanzen und anderen GPU-Anbietern können wir den durchschnittlichen GPU-Preis auf 2,50 $ pro Stunde senken. Ausgehend von 15 GPUs außerhalb der Spitzenzeiten und 20 GPUs während der Spitzenzeiten belaufen sich die Gesamtkosten auf:

$ 2,5 * (15*12 + 20*12) * 30 (Tage im Monat) = $ 31K

Wie wir sehen können, sind wir in der Lage, dasselbe LLM zu fast 30 % des Sagemaker-Preises bei hoher Zuverlässigkeit zu hosten. Es erfordert jedoch Aufwand, diese Architektur aufzubauen und zu warten. TrueFoundry kann Ihnen dabei helfen, dies für Sie zu hosten oder es ohne Aufwand in Ihrem eigenen Cloud-Konto einzurichten und gleichzeitig Kosten zu sparen.