GitHub
Medium
Start
Die Ausführung großer Sprachmodelle (LLM) kann erhebliche Rechenressourcen erfordern. Wenn man verschiedene Grafikkarten testen möchte, muss man Cloud-Ressourcen mieten.
Die manuelle Verwaltung dieser Ressourcen ist zeitaufwendig, führt zu Fehlern, ist schwer skalierbar und hat viele Nachteile. Zum Beispiel gibt es keinen Überblick darüber, wie viel jeder Mitarbeiter ausgegeben hat, und wer häufig vergisst, virtuelle Maschinen auszuschalten.Als Lead DevOps stellte ich mich der Herausforderung, einen einfachen Weg zur Bereitstellung, Verwaltung und Bereinigung von GPU-Instanzen in RunPod für unser Team zu schaffen. Unsere Hauptaufmerksamkeit galt dem Inferenzprozess mit vLLM auf verschiedenen GPUs.
Um dieses Problem zu lösen, habe ich einen GitLab CI/CD-Pipeline entwickelt, der den gesamten Lebenszyklus von RunPod-Grafikmodulen direkt aus dem GitLab-Interface automatisiert.
Diese Lösung soll die Verwaltung von GPU-Ressourcen vereinfachen, die Arbeitsprozesse effizienter gestalten und den Bereitstellungsprozess transparent machen. In diesem Beitrag erkläre ich Ihnen die Konfiguration und wie sie funktioniert.
Das Problem
Unabhängig davon, ob der RunPod-Account korrekt konfiguriert ist, gibt es Unannehmlichkeiten hinsichtlich der Kontrolle und des Billing nach Mitarbeitern im Team. GPU-Berechnungen sind kostspielig, daher ist eine Kontrolle – besonders automatisierte – in diesem Bereich besonders wichtig.
Muss ich noch erwähnen, dass manuelle Ausführung mehr Zeit und ständige Aufmerksamkeit erfordert?Menschen sind angeboren, Fehler zu begehen, besonders unter den Bedingungen mehrfacher Versuche.
Es gibt noch ein weiteres Problem (das bisher nicht eindeutig gelöst werden konnte) – die automatisierte Verwaltung des GPU-Scope. Denn die parallele Arbeit mit mehreren vLLM ist offensichtlich besser als die sequentielle.
Lösung: GitLab CI/CD-Pipeline
Nach den Untersuchungen habe ich eine Datei erstellt, die ich vorstellen möchte – .gitlab-ci.yml. Sie verwendet einfache cURL-Anfragen, mit denen Pods erstellt und gelöscht werden, sowie vLLM konfiguriert wird.
Wie es funktioniert
Ich habe den Code in Phasen unterteilt:
- deploy
- listing
- destroy
- stop
- start
In Zukunft werden zusätzliche Schritte hinzugefügt:
- Versand von E-Mails
- Versand von Benachrichtigungen in DiscourseDie letzten drei Phasen erfordern, dass ein Listing ausgeführt wird. Da in dieser Phase die Pod-ID bekannt wird, ist es nicht möglich, sie während der Pod-Erstellung zu erhalten, da die Bereitstellung unterschiedliche Zeiten benötigt und die API erst antwortet, wenn die Bereitstellung abgeschlossen ist. Dazu wurde ein separater Schritt „Listing“ erstellt.
Jeder Schritt enthält detaillierte Protokollierung in der GitLab-Pipeline. Dies sollte bei frühen Phasen helfen und ist auch für die Einarbeitung neuer Mitarbeiter geeignet.
Beim Start eines neuen Pipelines können Variablen überschrieben werden (sonst müssen Sie die Variablen über Code-Änderungen hinzufügen).
Installationsanleitung (kurz)
Wichtige Variablen sollten in GitLab im Bereich „Variables“ des CI-Projekts gespeichert werden. Der Code greift darauf zu. Dazu gehören Variablen wie:- RUNPOD_API_KEY: Ihr RunPod-API-Schlüssel
- HG_TOKEN: Ihr Hugging Face-Token
- RUNPOD_SSH_PUBLIC_KEYS: Ihre öffentlichen SSH-Schlüssel zum Zugriff auf den Pod (falls zutreffend, durch \n getrennt, falls mehrere vorhanden sind)
- RUNPOD_SSH_PRIVATE_KEY: Ihr privater SSH-Schlüssel, damit GitLab Runner auf den Pod zugreifen kann
(Nutzen Sie eine Sensitivitätsmaskierung, damit diese Daten nicht im offenen Format in Logs erscheinen)
Warum dieser Ansatz nützlich istDieser Ansatz ist nützlich für:
- Die Trennung von AI-Entwicklern unterschiedlicher Levels nach Rollen – ein CI passt für alle
- Jeder Mitarbeiter hat sein eigenes Pipeline-Raum mit Historie
- Leichte Aufteilung der Kosten des Accounts nach Mitarbeitern
- Leichte Kontrolle von Starts und aktuellen Ständen
- Leichte Speicherung verschiedener Konfigurationen als Branches
- Bequeme und schnelle Bereitstellung beliebig vieler Demo-Stände
- Universeller Ansatz im DevOps – unterstützt jeden Entwickler
- Leichte Übertragbarkeit von Code zwischen Entwicklungsteams
- Wichtigster Punkt: 100 % Kompatibilität mit GitLab Workflow bei der Integration von AI-Elementen in die Projektarchitektur