Installation und Support von GPUs

GPU-Ressourcen werden in SPARCI als vGPU einer virtuellen Maschine zugewiesen. Diese Zuweisung kann nur durch die SPARCI-Administration erfolgen. Wenn eine GPU einer VM bereits durch einen SPARCI-Admin zugewiesen wurde, müssen auf der VM noch Treiber und entsprechende Toolkits installiert werden.

GPU-VM beantragen und vorbereiten

GPU-Hosts sollen nur für Workloads verwendet werden, die tatsächlich eine GPU benötigen, zum Beispiel Training, Inferenz oder GPU-beschleunigte Datenverarbeitung. Reine CPU-Workloads sollten normalerweise auf CPU-Instanzen laufen, auch wenn einzelne Programme von höherem CPU-Takt profitieren. GPU-Hosts sind knapp und eine VM ohne GPU-Zuweisung kann dort Ressourcen blockieren, die für GPU-Workloads benötigt werden.

Wählen Sie GPU-Offerings nur für VMs aus, für die tatsächlich eine GPU beantragt und durch die Administration zugewiesen werden soll. Ein GPU-Offering ohne korrekt zugewiesene vGPU hilft dem Workload nicht, kann aber GPU-nahe Ressourcen blockieren und die spätere Platzierung erschweren.

Der typische Ablauf für eine GPU-VM ist:

  1. Erstellen Sie eine normale VM in CloudStack mit ausreichend CPU, RAM und Storage für den geplanten Workload.
  2. Fahren Sie die VM herunter, falls die Administration dies für die vGPU-Zuweisung anfordert.
  3. Stellen Sie eine Anfrage an die Cloud-Administration und nennen Sie VM-Name, Forschungsgruppe, geplanten Zweck, Zeitraum und den ungefähren GPU-Speicherbedarf.
  4. Warten Sie auf die Bestätigung, dass eine vGPU zugewiesen wurde und die VM auf einem passenden GPU-Host läuft.
  5. Installieren Sie in der VM den von SPARCI empfohlenen GRID-Treiber und erst danach CUDA oder weitere Toolkits.

GPU-Kapazität ist knapp und wird manuell koordiniert. Wenn eine GPU vorübergehend nicht benötigt wird, kann sie durch die Administration von der VM gelöst und für andere Gruppen freigegeben werden. Geben Sie in diesem Fall an, ab wann Sie die GPU voraussichtlich wieder benötigen. Für die Reaktivierung oder den Wechsel auf eine andere GPU kann ein kontrolliertes Herunterfahren der VM erforderlich sein.

Die verfügbare GPU-Klasse hängt von der aktuellen Belegung ab. Es kann vorkommen, dass eine gewünschte 40-GB-GPU nicht kurzfristig verfügbar ist, aber eine andere GPU-Klasse oder ein kleineres vGPU-Profil angeboten werden kann. Prüfen Sie vor längeren Trainingsläufen den realen VRAM-Bedarf Ihrer Modelle. Ein Workload, der auf einer 40-GB-GPU läuft, kann auf einem 20-GB-Profil mit CUDA-Out-of-Memory abbrechen, auch wenn die GPU rechnerisch schneller ist.

GPU-Zuweisungen sind außerdem an Standort, Host und Netzwerksegment gebunden. GPUs aus einem anderen Rechenzentrum oder einer anderen CloudStack-Instanz können nicht ohne Weiteres an eine bestehende VM in einem anderen Netz gehängt werden. Falls ein Workload auf neue Hardware in einem anderen Rechenzentrum wechseln soll, muss in der Regel eine neue VM dort erstellt und die Daten müssen über Snapshot, Template, Backup oder Kopie migriert werden.

Nach Wartungsarbeiten, Host-Problemen, Stop/Start-Vorgängen, Disk-Änderungen oder Skalierungen kann es notwendig sein, dass die Cloud-Administration eine GPU-VM kontrolliert stoppt und wieder startet. Das ist insbesondere dann relevant, wenn eine VM auf dem Host starten muss, auf dem die zugewiesene vGPU physisch verfügbar ist. Fehlermeldungen wie No suitable host found bei GPU-VMs sind deshalb häufig ein Hinweis auf Host-Platzierung oder reservierte GPU-Ressourcen und sollten an die Cloud-Administration gemeldet werden.

GPU-Zuweisung prüfen

Nach der administrativen Zuweisung erscheint die vGPU innerhalb der VM als PCI-Gerät. Eine erste Prüfung ist daher auch möglich, bevor der NVIDIA-Treiber vollständig funktioniert:

lspci | grep -i nvidia

Wenn hier ein NVIDIA-Gerät sichtbar ist, wurde der VM grundsätzlich eine GPU beziehungsweise vGPU durchgereicht. Für die eigentliche Nutzung durch CUDA, ML-Frameworks oder Container reicht das allein aber nicht aus. Nach der Treiberinstallation muss zusätzlich nvidia-smi funktionieren:

nvidia-smi

Wenn lspci ein NVIDIA-Gerät zeigt, nvidia-smi aber fehlschlägt, liegt das Problem meistens in Treiberinstallation, Kernel-Modulen, vGPU-Lizenzierung oder CUDA-Kompatibilität innerhalb der VM. Wenn bereits lspci keine NVIDIA-Hardware zeigt, sollte die GPU-Zuweisung und Host-Platzierung durch die Cloud-Administration geprüft werden.

Support bei GPU-Problemen

Cloud-Administrator:innen können GPU-Probleme nur aus Sicht der Infrastruktur prüfen. Dazu gehört insbesondere:

  • ob die GPU-Zuweisung in CloudStack korrekt erfolgt ist
  • ob die VM auf einem Host gestartet wurde, auf dem die angeforderte GPU physisch vorhanden ist
  • ob die Treiberversion auf dem physischen Host zur empfohlenen Treiberversion in der VM passt

Fehlkonfigurationen innerhalb der VM können von der Cloud-Administration nicht behoben werden. Dazu fehlen sowohl der Zugang zu den VMs als auch die personellen Kapazitäten, um Betriebssysteme, Treiberinstallationen oder Toolkits innerhalb einzelner Nutzer-VMs zu verwalten und zu debuggen.

Nicht durch die Cloud-Administration abgedeckt sind daher insbesondere:

  • Fehler in der Betriebssystemauswahl oder der VM-Konfiguration
  • fehlerhafte oder unvollständige Treiberinstallationen innerhalb der VM
  • Probleme in CUDA-, Python- oder anderen Software-Stacks der Nutzer:innen
  • allgemeines Debugging von Nutzer-VMs

Die SPARCI-Cloud wird auf eigene Verantwortung genutzt. Wenn Infrastrukturfehler ausgeschlossen werden können, müssen Fehler innerhalb der VM grundsätzlich von den Nutzer:innen selbst behoben werden. Auch enge Deadlines ändern diese Zuständigkeit nicht.

Installation NVIDIA Treiber

Für die Installation ist eine CUDA-fähige Grafikkarte, wie etwa NVIDIA A100 oder H100, erforderlich. Zudem wird der GRID-Treiber benötigt, welcher hier heruntergeladen werden kann.

Installieren Sie nicht blind einen generischen NVIDIA-Treiber aus Ubuntu-Paketquellen oder von der öffentlichen NVIDIA-Downloadseite. Für vGPU-Setups muss die Treiberversion in der VM zur vGPU-Software auf dem physischen Host passen. Verwenden Sie daher den hier verlinkten SPARCI-GRID-Treiber beziehungsweise die von der Cloud-Administration genannte Version.

Nach Kernel-Updates, Ubuntu-Upgrades oder Änderungen an der vGPU-Hostsoftware kann eine neuere GRID-Treiberversion erforderlich sein. Prüfen Sie nach jeder Treiberinstallation mit nvidia-smi, ob die GPU erkannt wird und ob Treiber- und CUDA-Kompatibilität zum geplanten Workload passen.

Sofern auf der virtuellen Maschine noch CUDA- und NVIDIA-Pakete vorhanden sind, sollten diese System entfernt und die VM neu gestartet werden:

sudo apt-get purge 'cuda-*' -y
sudo apt-get purge 'nvidia-*' -y
sudo apt autoremove
sudo reboot

Ansonsten kann der heruntergeladene Grid-Treiber direkt installiert werden; Bei Ubuntu Maschinen ist die Installation von einigen Ubuntu-Tools jedoch erforderlich:

sudo apt install build-essential
chmod +x NVIDIA-Linux-<Driver Version>-grid.run
sudo  ./NVIDIA-Linux-<Driver Version>-grid.run
sudo reboot

Nach der Neuinstallation kann die erfolgreiche Installation mit dem Befehl nvidia-smi überprüft werden. Es sollten eine Statusmeldung ähnlich der folgenden angezeigt werden:

+-----------------------------------------------------------------------------+
| NVIDIA-SMI 525.105.17   Driver Version: 525.105.17   CUDA Version: 12.0     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                               |                      |               MIG M. |
|===============================+======================+======================|

Im nächsten Schritt muss nun die vGPU lizenziert werden, dazu muss folgender token heruntergeladen und in den nvidia-grid Systemordner verschoben werden:

sudo -i
cd /etc/nvidia/ClientConfigToken
wget -O token.tok "https://cloud.uni-koblenz.de/public.php/dav/files/tRsfqMqgSEL47GT"
systemctl restart nvidia-gridd

Es kann einige Minuten dauern bis die Lizenz vom Nvidia-Lizenzserver abgerufen wurde. Mittels sudo nvidia-smi -q | grep License lässt sich der Status der Lizenzierung abfragen:

    vGPU Software Licensed Product
        License Status                    : Licensed (Expiry: 2023-11-14 10:22:34 GMT)

Zu beachten ist, dass die Lizenz jeden Tag erneuert wird, bis zum endgültigen Ablaufdatum vom 23.11.2026!

vGPU-Lizenzierung und Client-Konfiguration

Die administrative vGPU-Zuweisung in CloudStack und die Nutzbarkeit der vGPU innerhalb der VM sind zwei getrennte Schritte. Die Cloud-Administration kann eine vGPU zuweisen und sicherstellen, dass der Host eine passende vGPU-Lizenzierung unterstützt. Innerhalb der VM muss jedoch der GRID-Treiber installiert sein und der vGPU-Client muss seine Lizenz beziehen können.

Typische Hinweise auf fehlende oder fehlerhafte Gast-Konfiguration sind:

  • lspci zeigt NVIDIA-Hardware, aber nvidia-smi meldet Fehler
  • CUDA-Anwendungen brechen bei der Initialisierung ab
  • sudo nvidia-smi -q | grep License zeigt keinen lizenzierten Zustand
  • nach Kernel- oder Treiberupdates funktioniert die GPU nicht mehr, obwohl sie weiterhin als PCI-Gerät sichtbar ist

Prüfen Sie in diesem Fall die Treiberversion, den Lizenz-Token im Verzeichnis /etc/nvidia/ClientConfigToken, den Dienst nvidia-gridd und die Ausgabe von nvidia-smi. Wenn unklar ist, welche GRID-Version oder welcher Lizenz-Token aktuell verwendet werden soll, fragen Sie die Cloud-Administration. Die Installation und Reparatur innerhalb der VM bleibt Aufgabe der Nutzer:innen.

Installation CUDA

Zur Installation von CUDA sollte die Verwendung von apt-get (bspw. sudo apt-get install nvidia-cuda-dev) vermieden werden, da dies zum Überschreiben des Grid-Treibers führen kann.

Planen Sie für GPU-VMs ausreichend Arbeitsspeicher ein. ML-Frameworks, Dataloader, CUDA-Toolkits und Container benötigen zusätzlich zum VRAM auch normalen RAM. Zu wenig RAM kann Trainingsjobs verlangsamen, zu Swap-Druck führen oder Prozesse abbrechen lassen.

Stattdessen sollten die folgenden Schritte vorgenommen werden:

  1. Mit folgedem Befehl die kompatible CUDA Version identifizieren:
nvidia-smi
  1. Unter https://developer.nvidia.com/ die kompatible run-file für das CUDA-Toolkit herunterladen (die Toolkit-Versionen sind unter https://developer.nvidia.com/cuda-toolkit-archive zu finden).

    Achtung: Die CUDA Version muss mit der zuvor installierten Treiberversion übereinstimmen. Siehe hier zum Finden der korrekten Version. Z.B. für den Treiber 525.x.x muss CUDA 12.0 installiert werden. Weitere Parameter können wie folgt herausgefunden werden:

    • Operating System: Linux
    • Architecture: Über den Befehl lscpu identifizieren
    • Distribution: Über den Befehl lsb_release -a identifizieren
    • Version: Über den Befehl lsb_release -a identifizieren
    • Installer Type: runfile (local)
  2. Die heruntergeladene CUDA run-file ausführbar machen und installieren. Während der Installation sollten der mitgelieferte Treiber unbedingt abgewählt, um zu verhindern, dass der Grid-Treiber überschrieben wird. (Die Option --override ermöglicht die Installation, auch wenn bestimmte Bedingungen wie Compiler-Versionen nicht den Vorgaben entsprechen.) 
chmod 744 cuda_<CUDA Version>.<Driver Version>_linux.run
sudo sh cuda_<CUDA Version>.<Driver Version>_linux.run --override --librarypath=/usr/local/cuda-<CUDA Version>
  1. CUDA zu den Umgebungsvariablen hinzufügen, um die CUDA-Tools und Bibliotheken verwenden zu können. Z.B. in die .profile Datei im Homeverzeichnis:
export PATH="/usr/local/cuda/bin:$PATH"
export LD_LIBRARY_PATH="/usr/local/cuda/lib64:$LD_LIBRARY_PATH"
source .bashrc

Häufige Probleme

  • Die GPU-VM startet nach Stop, Resize oder Disk-Änderung nicht mehr

    • Grund kann sein, dass die VM auf einem bestimmten GPU-Host starten muss, auf dem die zugewiesene vGPU verfügbar oder reserviert ist.
    • Lösung: Melden Sie den Fehler mit VM-Name und Fehlermeldung an die Cloud-Administration. Starten, Host-Platzierung und vGPU-Zuweisung müssen in solchen Fällen häufig administrativ korrigiert werden.

  • Die zuvor funktionierende GPU wird nicht mehr erkannt

    • Grund kann ein Update des Kernels des Servers sein (z.B. durch apt upgrade)
    • Lösung: Erst Treiber und dann CUDA erneut installieren (Lizenz muss nicht neu angefordert werden und auch der bestehende Treiber muss nicht gelöscht werden)

  • CUDA-Out-of-Memory auf kleinerem vGPU-Profil

    • Grund ist, dass der verfügbare GPU-Speicher des zugewiesenen Profils nicht ausreicht. Eine schnellere GPU mit weniger VRAM kann für große Modelle schlechter geeignet sein als eine langsamere GPU mit mehr VRAM.
    • Lösung: Reduzieren Sie Batch Size, Modellgröße oder Speicherverbrauch des Workloads oder fragen Sie rechtzeitig ein größeres vGPU-Profil an. Die Zuweisung hängt von der aktuellen Verfügbarkeit ab.

  • Docker-Container sehen die GPU nicht