Große Sprachmodelle auf mehrere GPUs verteilen und laden

Große Sprachmodelle (Large Language Models, LLMs) sind ein zentraler Bestandteil anspruchsvoller NLP-Anwendungen wie Chatbots, automatisierter Textgenerierung und maschineller Übersetzung. Ihre hohe Leistungsfähigkeit basiert häufig auf einer enormen Anzahl von Parametern, was gleichzeitig erhebliche Anforderungen an den GPU-Speicher stellt. Werden sehr große Modelle auf nur einer GPU geladen oder trainiert, stößt der verfügbare Speicher schnell an seine Grenzen. Die Verteilung auf mehrere GPUs hilft dabei, diese Einschränkung zu überwinden und die Effizienz zu steigern. Dieser Leitfaden zeigt, wie LLMs auf mehrere GPUs aufgeteilt und geladen werden können, wie sich Speicherengpässe reduzieren lassen und wie die Inferenzleistung verbessert werden kann. Darüber hinaus wird erläutert, wie Datenparallelismus und Modellparallelismus das verteilte Training von LLMs unterstützen.

Voraussetzungen

• Erfahrung mit NLP-Modellarchitekturen wie GPT, BERT und T5 sowie deren Einsatz in Aufgaben der natürlichen Sprachverarbeitung.
• Fähigkeit, Python-Skripte mit gängigen Deep-Learning-Frameworks zu erstellen und auszuführen.
• Grundlegendes Verständnis von CUDA-GPU-Beschleunigung und deren Vorteilen für Deep-Learning-Workloads.
• Kenntnisse über Modelltraining, Evaluierungsprozesse und deren Bedeutung für Vorhersageaufgaben.
• Grundwissen über verteiltes Training, einschließlich Datenparallelismus und Modellparallelismus.

Warum große Sprachmodelle auf mehrere GPUs verteilen?

Moderne Modelle wie PaLM oder Architekturen nach dem Megatron-Prinzip können aus Milliarden von Parametern bestehen. Selbst leistungsstarke GPUs mit 12 GB, 24 GB oder 80 GB VRAM stoßen schnell an ihre Grenzen, wenn Modellgewichte, Aktivierungen und Optimizer-Zustände gleichzeitig im Speicher gehalten werden müssen.

Der Einsatz mehrerer GPUs bietet dabei zwei wesentliche Vorteile:

Skalierbarkeit des Speichers:
Modellparameter können auf mehrere GPUs verteilt werden, wodurch das Risiko von Out-of-Memory-Fehlern deutlich sinkt. Dies ist sowohl beim Training als auch bei der Inferenz sehr großer Modelle von großer Bedeutung.

Leistungssteigerung:
Parallele Berechnungen können Trainings- und Inferenzzeiten erheblich verkürzen. Richtig implementierte Multi-GPU-Konfigurationen steigern den Durchsatz oftmals deutlich.

Die Aufteilung von LLMs auf mehrere GPUs ist daher eine wichtige Methode für anspruchsvolle KI-Workloads – unabhängig davon, ob mehrere GPUs in einem einzelnen System oder über mehrere Server in einer verteilten Umgebung genutzt werden.

Modellparallelismus vs. Datenparallelismus

Für LLM-Workloads gibt es zwei grundlegende Wege, mehrere GPUs einzusetzen – jeweils mit eigenen Vorteilen je nach Anwendung:

Datenparallelismus

Beim Datenparallelismus hält jede GPU eine vollständige Kopie des Modells, verarbeitet jedoch unterschiedliche Teile der Eingabedaten. Während des Trainings berechnet jede GPU Gradienten auf ihrem eigenen Mini-Batch, anschließend werden die Gradienten zwischen den GPUs synchronisiert.

Modellparallelismus

Beim Modellparallelismus wird das Modell selbst über mehrere GPUs verteilt, sodass jede GPU bestimmte Layer oder Parameterbereiche übernimmt. Diese Aufteilung kann in unterschiedlichen Granularitäten erfolgen, zum Beispiel als Tensor-Splits, Layer-Splits oder über Pipeline-Stufen.

Arten des Modellparallelismus

Modellparallelismus lässt sich in mehrere spezialisierte Verfahren unterteilen.

Tensor-Parallelismus

Tensor-Parallelismus verteilt die Gewichte innerhalb einzelner Layer auf mehrere GPUs – und zwar auf Tensor-Ebene. Bei großen Matrixoperationen kann jede GPU einen Teil der Matrix unabhängig berechnen, was parallele Ausführung ermöglicht.

Pipeline-Parallelismus

Pipeline-Parallelismus verteilt unterschiedliche Layer-Blöcke auf verschiedene GPUs, sodass jede GPU einen eigenen Abschnitt des Modells verarbeitet. Beispielsweise sendet GPU 0 nach dem Abschluss des ersten Micro-Batches im Forward-Pass das Ergebnis sofort an GPU 1. GPU 1 verarbeitet dann die nächste Stufe, während GPU 0 bereits den nächsten Micro-Batch startet. Durch ein kluges Staffeln dieser Micro-Batches können alle GPUs gleichzeitig ausgelastet werden.

Sharded Data Parallelism

Dieses Verfahren kombiniert Datenparallelismus mit Parameter-Sharding (wobei jede GPU nur einen Teil der Parameter speichert), um den Speicherbedarf zu reduzieren und dennoch effizientes Training zu ermöglichen.

GPU-Speicherverwaltung: Die versteckte Herausforderung

In Multi-GPU-Umgebungen ist die GPU-Speicherverwaltung oft der zentrale Engpass für die Performance. Ein naiver Ansatz – das Modell einfach in Teile zu zerlegen und über mehrere GPUs zu schieben – kann Kommunikationskosten zwischen GPUs ignorieren und zusätzlich durch Speicherfragmentierung Probleme verursachen. Für Multi-GPU-Inferenz mit LLMs ist daher eine gezielte Platzierung von Layern, Tensors und Pipeline-Stufen notwendig.

Wichtige Aspekte

• Batch-Größe: Größere Batches verbessern oft die GPU-Auslastung, erhöhen aber ohne sorgfältiges Management das OOM-Risiko. Profiling-Tools und Frameworks – etwa PyTorchs integrierter Profiler oder externe Tools – helfen, Memory-Hotspots zu finden.
• Activation Checkpointing: Checkpointing spart Speicher, indem ausgewählte Forward-Aktivierungen während der Backpropagation neu berechnet werden, statt alles dauerhaft zu speichern.
• Offloading: Manche Frameworks verschieben ungenutzte GPU-Daten in den CPU-Speicher oder auf NVMe. Das kann extrem große Modelle ermöglichen, kann aber auch zusätzliche Latenz und Overhead erzeugen.

Tools und Bibliotheken zum Aufteilen von LLMs auf mehrere GPUs

Zahlreiche Open-Source-Frameworks unterstützen Multi-GPU-Training und Inferenz für große Modelle. Im Folgenden werden einige bekannte Optionen und ihr Beitrag zur GPU-Parallelisierung für LLM-Workloads zusammengefasst.

PyTorch DistributedDataParallel

PyTorch DistributedDataParallel (DDP) zählt zu den am häufigsten genutzten Ansätzen für verteiltes LLM-Training. Es synchronisiert Gradienten direkt über GPUs und Nodes. Jeder Prozess führt dasselbe Modell aus, verarbeitet einen Datenanteil und mittelt die Gradienten nach jedem Trainingsschritt.

Zentrale Vorteile

• Einfache Nutzung: DDP kapselt das Modell und synchronisiert Gradienten automatisch.
• Skalierbarkeit: Es skaliert gut auf großen GPU-Clustern.
• Flexibel: Es funktioniert sowohl für Single-Node-Multi-GPU als auch für Multi-Node-Setups.

HuggingFace Accelerate

HuggingFace Accelerate ermöglicht Multi-GPU-Inferenz mit minimalen Codeanpassungen. Modelle lassen sich automatisch sharden, indem device_map="auto" für verteilte Inferenz genutzt wird. Zum Beispiel:

from transformers import AutoModelForCausalLM, AutoTokenizer
import torch
model = AutoModelForCausalLM.from_pretrained(
    "togethercomputer/LLaMA-2-7B-32K",
    torch_dtype=torch.float16,
    device_map="auto" # Automatically distributes across available GPUs
)

Accelerate belegt in der Regel zuerst GPU 0, wechselt dann zu GPU 1 und fährt so fort, bis das Modell vollständig verteilt ist. Das bietet eine einfache, automatische Möglichkeit, ein LLM über mehrere GPUs zu laden, ohne manuell partitionieren zu müssen.

Ollama Multiple GPUs

Ollama ermöglicht das Ausführen von LLMs mit effizienter CPU- und GPU-Inferenz. Mehrere GPUs lassen sich verwenden, indem Umgebungsvariablen gesetzt oder eine Konfigurationsdatei angepasst wird, um festzulegen, wie Modellgewichte aufgeteilt werden. Die offizielle Ollama-Dokumentation beschreibt die Aufteilung der Gewichte über Geräte hinweg.

Umgebungsvariablen zur GPU-Partitionierung

Um die GPU-Nutzung zu konfigurieren, können beispielsweise folgende Variablen exportiert werden:

export OLLAMA_GPU_COUNT=5
export OLLAMA_GPU_MEMORY_LIMIT=16GB

Hier gilt:

• OLLAMA_GPU_COUNT gibt an, wie viele GPUs genutzt werden.
• OLLAMA_GPU_MEMORY_LIMIT definiert das obere Limit für die GPU-Speicherzuweisung.

vLLM

vLLM (Versatile Large Language Model) ist eine neuere Bibliothek für besonders effiziente LLM-Inferenz. Sie bringt eine optimierte Transformer-Runtime mit und führt PagedAttention ein, um den Speicherbedarf des KV-(Key-Value)-Caches bei langen Prompts besser zu handhaben. vLLM unterstützt verteilte Inferenz und Serving.

Wenn ein Modell zu groß für eine einzelne GPU ist, lässt es sich mit vLLM über mehrere GPUs oder sogar mehrere Maschinen bereitstellen. Beim Start einer Serving-Instanz kann die Tensor-Parallel-Größe gesetzt werden, wie im folgenden Beispiel:

from vllm import LLM
# Initialize model with tensor parallelism across 4 GPUs
llm = LLM(model="meta-llama/Llama-2-70b-hf", tensor_parallel_size=4)
# Generate text for multiple prompts in parallel
outputs = llm.generate(["Write a book", "Explain artificial intelligence"])

DeepSpeed

DeepSpeed ist eine Microsoft-Bibliothek, die für das Optimieren von Training sehr großer Modelle entwickelt wurde. Der ZeRO-(Zero Redundancy Optimizer)-Ansatz teilt Trainingszustände über GPUs auf, um redundante Speicherbelegung zu vermeiden.

DeepSpeed-Stufen umfassen:

• ZeRO-1: shardet Optimizer-Zustände,
• ZeRO-2: shardet Optimizer-Zustände und Gradienten,
• ZeRO-3: shardet Optimizer-Zustände, Gradienten und Parameter (die Modellgewichte selbst).

DeepSpeed unterstützt außerdem CPU- und NVMe-Offloading über ZeRO-Offload und ZeRO-Infinity.

ZeRO Stage 3 lässt sich aktivieren und offload_param kann so konfiguriert werden, dass bei Bedarf die CPU genutzt wird. Das folgende Beispiel zeigt einen typischen Ausschnitt aus einer DeepSpeed-Konfigurationsdatei.

{
 "train_batch_size": 8,
 "fp16": { "enabled": true },
 "zero_optimization": {
 "stage": 3,
"offload_param": { "device": "cpu" }
 }
}

DeepSpeed steuert die Verteilung von Parametern und Gradienten gemäß der angegebenen Konfiguration.

Megatron-LM

NVIDIA stellt Megatron-LM über ein GitHub-Repository bereit, um extrem große Transformer-Modelle wie GPT-2, GPT-3 und T5 zu trainieren. Es kombiniert Tensor-Parallelismus und Pipeline-Parallelismus, um sehr hohe Parallelität zu erreichen.

Nutzende können eine Tensor-Parallel-Größe definieren (wie viele GPUs sich die Tensoren pro Layer teilen) und eine Pipeline-Parallel-Größe festlegen (wie das Modell in Stufen segmentiert wird). Megatron-LM enthält zudem fortgeschrittene Techniken, die beim Training von Multi-Milliarden-Parameter-Modellen von Grund auf helfen.

Verteiltes Training über mehrere Maschinen

Wenn LLMs über mehrere Maschinen laufen, wird eine verteilte Umgebung benötigt, in der jede Node mehrere GPUs beiträgt. PyTorchs verteiltes Kommunikations-Backend (NCCL) kann genutzt werden, um Verbindungen zwischen allen Prozessen herzustellen.

• Master-Node-Setup: IP-Adresse und Port der Master-Node bestimmen, die alle anderen Nodes koordiniert.
• Rank und World Size: Jedem Prozess bzw. jeder Node wird ein Rank zugewiesen; die Gesamtzahl der Prozesse entspricht der World Size.
• Start: torch.distributed.launch oder torchrun nutzen, um Prozesse über die beteiligten Maschinen zu starten.
• Netzwerkoptimierung: Eine High-Bandwidth-Verbindung wie InfiniBand nutzen, um Synchronisations-Overhead zu verringern.

Verteiltes LLM-Training mit PyTorch DDP: Ein Minimalbeispiel

PyTorch DistributedDataParallel (DDP) trainiert über mehrere GPUs, indem das Modell auf jeder GPU repliziert wird und Gradienten synchronisiert werden, sodass sich das Verhalten wie Single-Device-Training anfühlt. Im Folgenden steht eine kompakte Abfolge zentraler Schritte für DDP-basiertes verteiltes Training.

1. Die Process Group initialisieren

Damit Prozesse kommunizieren können, muss das verteilte Backend konfiguriert werden. Das folgende Beispiel zeigt die Initialisierung des NCCL-Backends für GPU-Kommunikation:

import torch.distributed as dist
dist.init_process_group(backend="nccl")

Damit entsteht eine Kommunikationsgruppe, die alle Prozesse verbindet. Üblicherweise entspricht ein Prozess genau einer GPU.

2. Device konfigurieren und Modell mit DDP kapseln

Die GPU des aktiven Prozesses wird über die Umgebungsvariable LOCAL_RANK ermittelt, dann wird das Device gesetzt, das Modell dorthin verschoben und anschließend mit DistributedDataParallel umhüllt:

import os
import torch
local_rank = int(os.environ["LOCAL_RANK"])
torch.cuda.set_device(local_rank)
model = MyModel().to(local_rank)
model = torch.nn.parallel.DistributedDataParallel(model, device_ids=[local_rank])

Sobald loss.backward() ausgeführt wird, synchronisiert DDP die Gradienten und mittelt sie über alle Prozesse.

3. DistributedSampler im DataLoader verwenden

Statt shuffle=True zu nutzen, wird DistributedSampler eingesetzt, damit jeder Prozess einen eigenen Datenausschnitt erhält. Zum Beispiel:

from torch.utils.data import DataLoader, DistributedSampler
sampler = DistributedSampler(train_dataset)
train_loader = DataLoader(train_dataset, batch_size=BATCH_SIZE, sampler=sampler)

So wird verhindert, dass mehrere Prozesse auf dieselben Trainingsbeispiele zugreifen.

4. Trainingsschleife umsetzen

In jedem Prozess läuft eine normale Trainingsschleife: Batches aus train_loader holen, auf die GPU verschieben, Loss berechnen, loss.backward() ausführen und danach optimizer.step() aufrufen. DDP übernimmt die Gradientensynchronisation im Backward-Pass ohne zusätzlichen Code. Nach Abschluss wird wie folgt aufgeräumt:

dist.destroy_process_group()

Training mit torchrun starten

Um das Training zu starten, wird das Trainingsskript mit torchrun ausgeführt, zum Beispiel: torchrun --nproc_per_node=4 train_ddp.py -nproc_per_node=4:

• Damit wird festgelegt, wie viele Prozesse pro Node (Maschine) gestartet werden.
• Üblicherweise entspricht dieser Wert der Anzahl verfügbarer GPUs auf der Node.
• Mit dieser Konfiguration laufen vier lokale Prozesse (zum Beispiel auf einer Maschine mit 4 GPUs).
• -train_ddp.py:
  • Das Trainingsskript für DDP-basiertes verteiltes Training.

Innerhalb dieses Skripts sollte Folgendes umgesetzt werden:

• Die Process Group initialisieren (torch.distributed.init_process_group).
• Das Modell mit torch.nn.parallel.DistributedDataParallel kapseln.
• Einen DistributedSampler für den Datensatz verwenden.

Durch die initiale Einrichtung erhält jeder Prozess den passenden LOCAL_RANK und synchronisiert sich über die definierte Process Group mit den anderen Prozessen.

Häufige Fehler und Debugging

Dieser Abschnitt fasst typische Probleme beim verteilten Training großer Sprachmodelle über mehrere GPUs zusammen, inklusive wahrscheinlicher Ursachen und möglicher Lösungen.

Wenn Speicherüberläufe, langsame Synchronisation und ineffiziente Parallelität behoben werden, steigen Stabilität und Performance einer Multi-GPU-LLM-Umgebung deutlich.

Besonderheiten bei multimodalen LLMs

Multimodale LLMs – also Modelle, die Text mit Bildern und teils auch Audio oder Video kombinieren – treten immer häufiger auf. Da diese Modelle oft größer sind als reine Textmodelle, werden Multi-GPU-Strategien umso wichtiger.

Wichtige Punkte

• Zusätzliche Modalitäten: Jede Modalität bringt spezialisierte Encoder- oder Decoder-Blöcke mit, was die Parameterzahl erhöht.
• Individuelle Layer: Für Bild-Encoder (wie ViT) und Audio-Encoder (wie Wav2Vec2) können eigene Verteilungsstrategien erforderlich sein.
• Intermodale Fusion: Das Zusammenführen textueller Elemente mit visuellen oder auditiven Komponenten kann neue Pipeline-Stufen einführen.
• Tool-Unterstützung: Das gewählte Framework muss multimodale Ein- und Ausgaben unterstützen und sich in große model-parallele Setups integrieren lassen.

FAQ

Q1: Kann LLM auf mehreren GPUs ausgeführt werden?

Ja. Frameworks wie PyTorch und TensorFlow ermöglichen Training über mehrere GPUs und verteilte Nodes. Daten- und Modellparallelismus machen es möglich, LLMs effizient über mehrere GPUs zu betreiben.

Q2: Wie lässt sich ein Modell auf mehreren GPUs ausführen?

Ein Modell kann in PyTorch mit DistributedDataParallel oder in TensorFlow mit tf.distribute für verteiltes Training gekapselt werden. Alternativ übernehmen Bibliotheken wie Hugging Face Accelerate und DeepSpeed die automatische Verteilung von Parametern und Daten auf mehrere GPUs.

Q3: Kann man mehrere GPUs für maschinelles Lernen verwenden?

Ja. In vielen Deep-Learning-Setups werden mehrere GPUs genutzt, um Training und Inferenz zu beschleunigen. Skalierung gelingt über Datenverteilung oder über das Aufteilen von Modell-Layern.

Q4: Ist es in Ordnung, zwei GPUs gleichzeitig zu verwenden?

Ja, zwei oder mehr GPUs zu nutzen ist üblich und kann die Performance verbessern. Wenn es richtig konfiguriert ist, kann ein Zwei-GPU-System die Trainings- oder Inferenzzeit deutlich reduzieren – auch ohne Cluster.

Q5: Wie lässt sich ein LLM parallelisieren?

Ein LLM lässt sich über Datenparallelismus, Modellparallelismus oder einen Hybridansatz parallelisieren. Bibliotheken wie DeepSpeed, Megatron-LM und Hugging Face Accelerate vereinfachen diesen Prozess.

Q6: Kann man mehrere LLM haben?

Ja, mehrere LLM-Instanzen sind möglich, sofern ausreichend Rechenleistung vorhanden ist. Wenn mehrere große Modelle dieselben GPUs nutzen, kann es zu Ressourcenkonflikten und Out-of-Memory-Fehlern kommen.

Q7: Kann ich mehrere Deep-Learning-Modelle auf derselben GPU ausführen?

Es ist möglich, jedoch ist die Performance meist besser, wenn Modelle auf mehrere GPUs verteilt werden. Mehrere Modelle auf einer GPU erhöhen das Risiko von Speicherengpässen und können die Verarbeitung verlangsamen.

Q8: Was ist ein Doppel-LLM?

„Double LLM“ beschreibt eine Architektur, in der zwei große Sprachmodelle gemeinsam arbeiten, um Aufgabenleistung, Genauigkeit oder Effizienz zu verbessern. Dabei können die Modelle unterschiedliche Verantwortlichkeiten übernehmen, um ihre Stärken zu kombinieren.

Q9: Kann ich mein eigenes LLM trainieren?

Ja. Mit ausreichend Daten, passenden Rechenressourcen (wie GPUs) und einer stabilen Trainingspipeline können Entwickler große Sprachmodelle auch von Grund auf trainieren, etwa mit Open-Source-Projekten wie Megatron-LM oder DeepSpeed.

Q10: Was ist der Unterschied zwischen einem Single- und einem multimodalen LLM?

Ein Single-Modal-LLM verarbeitet nur eine Eingabeart. Multimodale LLMs können verschiedene Datentypen verarbeiten, zum Beispiel Text kombiniert mit Bildern oder Audio.

Q11: Was ist Modellparallelität und wie lässt sie sich auf große Sprachmodelle anwenden?

Modellparallelismus teilt die Parameter eines einzelnen Modells über mehrere GPUs auf, wobei jede GPU einen Teil des Netzwerks verwaltet. Das ist für sehr große LLMs entscheidend, weil das Modell so in begrenzten GPU-Speicher passt und parallele Verarbeitung unterstützt wird.

Fazit

Für Forscher und Entwickler, die heute moderne NLP- und multimodale KI-Systeme bauen, ist das Verteilen großer Sprachmodelle über mehrere GPUs zu einer Notwendigkeit geworden.

Dieser Artikel hat praxisnahe Ansätze gezeigt, um die Rechen- und Speichergrenzen aktueller LLMs zu adressieren. Dazu gehören Daten- und Modellparallelismus sowie Tools wie DeepSpeed, Hugging Face Accelerate und Megatron-LM.

Mit einer passenden Strategie können Multi-GPU-Setups skalierbares Training und schnellere Inferenz ermöglichen. Mit der Weiterentwicklung von Modellen hin zu mehr Datentypen wird der Erfolg zunehmend von effizientem GPU-Speichermanagement und optimierten verteilten Trainingsmethoden abhängen. Wer Parallelismusarchitekturen versteht, Open-Source-Tools sinnvoll nutzt und typische Performance-Probleme früh berücksichtigt, kann das Potenzial großer und multimodaler LLMs besser ausschöpfen.