Viele von uns nutzen GPT-3 oder andere LLMs als SaaS-Lösung, die von ihren Anbietern gehostet werden. Aber wie betreibt man ein Modell in der Größe von GPT-3 in der eigenen Cloud?
Es ist nicht einfach, ein eigenes Modell auf die Beine zu stellen, dafür umso spannender. Hier erkläre ich, wie man anfängt und welche Ergebnisse einen erwarten.
BLOOM – ist ein Transformer basiertes Sprachmodell, welches von über 1000 Forschern kreiert wurde (mehr zum BigScience-Projekt). Es wurde mit etwa 1,6 TB vorverarbeiteten und mehrsprachigem Texten trainiert und ist kostenlos. Das größte BLOOM-Modell hat die Größe von 176B in Parametern, was ungefähr der Größe des erfolgreichsten Sprachmodells aller Zeiten entspricht – nämlich dem GPT-3-Modell von OpenAI. Es sind auch kleinere Modelle verfügbar mit 7B, 3B, 1B7, etc.
Warum sollte man ein eigenes Modell aufsetzen, wenn man die kommerziellen Modelle ganz einfach nutzen kann? Es gibt viele Gründe aber das Hauptargument ist die absolute Datensouveränität. Die Daten für das Pre-Training und die von den Nutzern bleiben vollständig in der eigenen Kontrolle und nicht unter der eines KI-Unternehmens. Eine echte SaaS-Lösung für BLOOM gibt es (noch) nicht.
Ok, und wie macht man das?
Modellgröße
Unser BLOOM-Modell benötigt ca. 360 GB Arbeitsspeicher – eine Anforderung, die man mit klassischem Cloud-Hosting nicht durch nur einen Doppelklick erreichen kann und dazu auch noch recht teuer ist.
Glücklicherweise hat Microsoft eine abgespeckte Variante mit INT8-Parameter (ursprünglich FLOAT16) bereitgestellt, die auf der DeepSpeed-Inference-Engine läuft und einen Tensor-Parallelismus verwendet. Die Deep-Speed-Inference führt mehrere Funktionen ein, um Transformer basierte PyTorch-Modelle effizient zu bedienen. Es unterstützt eine Modellparallelität (MP), um große Modelle anzupassen, die sonst nicht in den GPU-Speicher passen würden.
In dem Microsoft Repo sind die Sensoren in 8 Shards aufgeteilt. So wird zum einen die absolute Modellgröße reduziert und zum anderen wird das kleinere Modell aufgeteilt und parallelisiert. So kann es auf 8 GPUs verteilt werden.
Hosting-Setup
Als Host für unser Modell wählten wir AWS, da dieser ein SageMaker-Setup für einen Deep Learning-Container bereitstellt, der das Modell initialisieren kann. Eine Anleitung dazu gibt es hier:
Bitte beachte nur den BLOOM 176B-Teil, der OPT-Teil ist für unsere Zwecke irrelevant.
Bei AWS muss man erstmal das richtige Datenzentrum finden, um das Modell einzurichten. Die erforderliche Kapazität ist nicht überall verfügbar. Wir sind über us-east-1.amazonaws.com nach Virginia an die Ostküste gegangen. Die benötigten Instanzen bezieht man über den Support. Selbst konfigurieren kann man sie nicht. Dafür braucht man 8Nvidia A100 mit je 40GB RAM.
Thomas unser DevOps-Engineer fand heraus, wie man die Umgebung erstellt und hat sie letztendlich eingerichtet. An dieser Stelle möchte ich meinen Respekt an ihn aussprechen, dass er das geschafft hat!
Das Modell booten
Das gehostete Modell kann aus dem Microsoft-Repository auf Huggingface in ein S3 im selben Rechenzentrum geladen werden. Das haben wir gemacht, um das Modell nahe an der Laufzeitumgebung zu haben. Eine andere Möglichkeit wäre es, das von AWS bereitgestellte Modell in einer öffentlichen S3-Umgebung zu verwenden. Die Größe des Modells beträgt 180 GB.
In der Anleitung und im Jupyter Notebook, verfügbar auf Gifthub, findet man die einzelnen notwendigen Schritte zum Erstellen des Modells und zum Einrichten eines Endpunkts auf SageMaker, um ein Modell mit geringer Latenz zum Laufen zu bringen.
Fertig! Das Modell BLOOM 175B ist jetzt am laufen.
Mit unserem Setup kostet es, wenn es läuft, etwa 32$ pro Stunde. Es ist sinnvoll, das Modell für Testrunden hochzufahren und danach wieder herunterzufahren, um Ressourcen zu sparen. Mit dem Skript kann man es in etwa 18 Minuten starten, das Herunterfahren und Freigeben der Ressourcen dauert nur Sekunden.
Verwende das Modell
Mit einem benutzerdefinierten API-Gateway und einer Lambda-Funktion auf dem Sagemaker-Endpunkt, kann ein Nutzer, sich extern mit einem API-Schlüssel verbinden. Das erleichtert die Verwendung und den Aufruf. Hier kommst Du zur Einführung.
Das „Call to the Bloom-Modell“ ist im Prinzip genau dasselbe wie bei anderen Completion Models: Man gibt einen Text, Temperatur, max_new_tokens usw. ein und erhält eine Textantwort.
Als erstes haben wir die Modellschnittstelle mit einem kleineren BLOOM-Modell getestet, danach mit dem 1B7 (mit SageMaker JumpStart) und dann mit dem großen 176B-Modell – es funktionierte.
Na gut, und was ist nun das Ergebnis?
Wir lassen das Modell zwei „hello-world“ und ein „goodbye-world“ machen:
Es funktioniert!
Nett, aber nicht allzu spezifisch. Über die Ergebnisse einiger Fähigkeitstests mit dem BLOOM-Modell werde ich in einem Folgeartikel berichten.
Vielen Dank an: Thomas Bergmann, Leo Sokolov, Nikhil Menon und Kirsten Küppers, für die Hilfe bei dem Setup und dem Artikel.
Alle BLOOM-Bilder wurden mit Openair DALL-E2 erstellt.
Zögert nicht mir Fragen bezüglich des BLOOM-Setups zu stellen.
Lese den ausführlichen Artikel auf medium.com/@maximilianvogel