Wie teilt Tensor-Parallelismus die lokale KI-Inferenz auf mehrere GPUs auf?

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Tensor-Parallelismus teilt die lokale KI-Inferenz auf, indem große Gewichtstensoren innerhalb jeder Transformatorschicht auf mehrere GPUs verteilt und ihre Teilergebnisse zusammengeführt werden.

Das unterscheidet sich davon, jeder GPU eine eigene Anfrage zuzuweisen oder verschiedene Schichten unterschiedlichen Geräten zuzuordnen. Jede Tensor-Parallel-GPU arbeitet an derselben Schicht mit, häufig bei jedem generierten Token. Dadurch kann ein Modell auf mehrere GPUs im Heimnetz verteilt werden, zugleich wird jedoch die Kommunikation zwischen den GPUs zu einem Teil des kritischen Inferenzpfads.

Tensor-Parallelismus teilt eine Schicht, statt das gesamte Modell zu kopieren

Beim Datenparallelismus erhält jede GPU eine Modellkopie, während Anfragen oder Batches aufgeteilt werden. Tensor-Parallelismus macht bei einem einzelnen Modell das Gegenteil: Große Parametertensoren innerhalb einzelner Schichten werden auf mehrere Geräte verteilt.

NVIDIA NeMo definiert TP als das Verteilen des Parametertensors einer einzelnen Schicht auf mehrere GPUs. Jede GPU enthält nur einen Teil der betroffenen Matrix.

Das ist nützlich, wenn ein Modell oder sogar eine einzelne große Schicht nicht problemlos auf eine einzelne Heim-GPU passt.

Spalten- und Zeilenaufteilung verteilen die Arbeit der Matrixmultiplikation

Transformatorschichten enthalten große lineare Projektionen. Bei einer spaltenweisen Aufteilung werden verschiedene Ausgabespalten unterschiedlichen GPUs zugewiesen, während bei einer zeilenweisen Aufteilung verschiedene Eingabezeilen oder Merkmalsbereiche verteilt werden.

Das Tensor-Parallel-Tutorial von PyTorch wendet zeilenweise und spaltenweise Parallelisierungsstile auf Transformatorschichten an. Jeder Rang berechnet ein Teilprodukt der Matrix anhand seines lokalen Gewichtsteils.

Das Modell stellt weiterhin eine einzige logische Schicht dar. Die Aufteilung verändert, wo die mathematischen Teiloperationen stattfinden und wie die Teilergebnisse zusammengeführt werden.

Kollektive Kommunikation rekonstruiert die logische Ausgabe der Schicht

Da jede GPU nur einen Teil des Tensors sieht, benötigen einige Operationen vor der nächsten Berechnung ein All-Reduce, All-Gather, Reduce-Scatter oder vergleichbare kollektive Kommunikationsverfahren, damit die erforderliche Darstellung vorliegt.

Open MPI definiert AllReduce als das Zusammenführen von Werten über mehrere Prozesse und das anschließende Verteilen des Ergebnisses an alle Beteiligten. Tensor-Parallel-Laufzeitumgebungen verwenden diese Art kollektiver Kommunikation zusammen mit All-Gather und Reduce-Scatter, um die Ergebnisse aufgeteilter Schichten zu rekonstruieren oder neu zu verteilen.

Auf einer Heim-Workstation kann die Qualität der Verbindung zwischen den GPUs darüber entscheiden, ob die Aufteilung Zeit spart oder lediglich die Kapazität erhöht.

Schnelle Verbindungen sind wichtig, weil die Kommunikation bei jeder Schicht stattfindet

Tensor-Parallelismus kann für jeden Transformer-Block und jedes generierte Token mehrere kollektive Kommunikationsvorgänge erfordern. Systeme, die ausschließlich PCIe verwenden, bieten deutlich weniger Peer-Bandbreite als hochwertige Accelerator-Fabrics, die für große verteilte Rechenaufgaben entwickelt wurden.

AMD RCCL dokumentiert Peer-to-Peer-Transport für über PCIe verbundene GPUs. Die konkrete Bibliothek für kollektive Kommunikation hängt zwar von der Plattform ab, die Einschränkung durch die Topologie bleibt jedoch bestehen.

Zwei GPUs mit ausreichend gemeinsamem VRAM können ein größeres Modell erfolgreich ausführen und dennoch einen geringeren Token-Durchsatz als erwartet liefern, weil jede Schicht auf die Synchronisierung warten muss.

Unterschiedliche GPUs können dazu führen, dass der langsamste Teil die Geschwindigkeit vorgibt

Eine Tensor-parallele Schicht wird erst fortgesetzt, wenn die erforderlichen Teilergebnisse eingetroffen sind. Verfügt eine GPU über einen geringeren Rechendurchsatz, eine niedrigere Speicherbandbreite oder eine langsamere Verbindung, kann die schnellere GPU Zeit mit Warten verbringen.

Die automatische Tensor-Parallel-Inferenzfunktion von DeepSpeed ist auf Modellaufteilung über eine Inferenz-Prozessgruppe ausgelegt. Die praktische Effizienz setzt voraus, dass die beteiligten Geräte ähnlich viel Arbeit leisten können.

Eine gemischte GPU-Sammlung im Heimnetz kann weiterhin nützlich sein, um ein Modell unterzubringen. Gleich große Teilstücke sind jedoch nicht automatisch optimal, wenn sich die Hardware deutlich unterscheidet.

Wähle Tensor-Parallelismus für breite Schichten und knappen Speicher auf einer einzelnen GPU

Der größte Vorteil zeigt sich bei Modellen, deren große verborgene Dimensionen und Schichtentensoren auf mehrere GPUs verteilt werden müssen, insbesondere wenn die Geräte über eine schnelle lokale Verbindung verfügen. Für die Bereitstellung mehrerer unabhängiger kleiner Anfragen ist dies nicht automatisch die beste Methode.

Der Artikel von ZimaSpace zur Speicherplanung für lokale KI-Beschleuniger liefert die Kapazitätsgrundlage. Tensor-Parallelismus verändert diese Grundlage, indem die Schichten eines einzelnen Modells auf mehrere Geräte verteilt werden.

Miss nach Möglichkeit zunächst eine einzelne GPU und anschließend zwei oder mehr GPUs mit demselben Modell, Prompt, Kontext und Batch. Erfasse den Speicherverbrauch pro GPU, Tokens pro Sekunde, Latenz, die Zeit für kollektive Kommunikation und die Auslastung der Verbindung.

Der Artikel von ZimaSpace zum Druck auf lokale KI-Systeme durch mehrere Benutzer bietet den Vergleich aus Sicht der Bereitstellung: TP verteilt ein Modell über mehrere Geräte, während die Parallelität von Anfragen bestimmt, wie viele unabhängige Kontexte um dieses verteilte Modell konkurrieren.

Tech- & KI-Zentrum

Mehr zum Lesen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.