Pipeline-Parallelität bewegt ein Modell über mehrere KI-Beschleuniger zu Hause, indem verschiedene Layergruppen sequenziellen Gerätestufen zugewiesen und Aktivierungen zwischen ihnen weitergegeben werden.
Die Methode ist nützlich, wenn ein tiefes Modell zu groß für einen einzelnen Beschleuniger ist, sich aber in Layergruppen aufteilen lässt, die auf mehrere Geräte passen. Im Gegensatz zur Tensor-Parallelität besitzt jede Stufe vollständige Layer statt Teilstücke derselben Matrix. Der wichtigste Kompromiss besteht in einem geringeren Gewichtsspeicherbedarf pro Gerät gegenüber Aktivierungsübertragungen, einer unausgeglichenen Stufenlast und Leerlaufzeiten innerhalb der Pipeline.
Pipeline-Parallelität teilt ein tiefes Modell in sequenzielle Layerstufen auf
Ein Transformer ist von Natur aus sequenziell aufgebaut: Frühe Layer verarbeiten die Eingabe, bevor spätere Layer ausgeführt werden können. Die Pipeline-Parallelität gruppiert zusammenhängende Abschnitte dieser Tiefe und weist jeden Abschnitt einem anderen Beschleuniger zu.
Die Pipeline-Laufzeit von PyTorch teilt ein Modell in Partitionen auf, die als sequenzielle Stufen auf verschiedenen Geräten ausgeführt werden. Jedes Gerät speichert nur die Parameter für seine zugewiesene Stufe.
Dadurch kann der Modellspeicherbedarf pro Gerät so weit sinken, dass sich ein Modell ausführen lässt, das nicht auf eine einzelne Heim-GPU passen würde.
Aktivierungen werden von einer Stufe zur nächsten weitergeleitet
Nachdem GPU 0 ihre Layer verarbeitet hat, sendet sie die Aktivierung des verborgenen Zustands an GPU 1. Dieses Gerät wendet den nächsten Layer-Satz an und leitet anschließend eine weitere Aktivierung weiter, bis die letzte Stufe Logits oder eine andere Modellausgabe erzeugt.
vLLM-Omni beschreibt die Pipeline-Parallelität als Aufteilung von Transformer-Blöcken in sequenzielle Stufen über mehrere GPUs. Im grundlegenden Vorwärtslauf müssen nur die Aktivierungen an den Grenzen zwischen benachbarten Stufen übertragen werden.
Im Gegensatz zur Tensor-Parallelität berechnen die Geräte nicht gemeinsam eine einzelne Matrix innerhalb desselben Layers. Sie besitzen unterschiedliche Layer.
Eine einzelne Anfrage durchläuft die Stufen weiterhin in der richtigen Reihenfolge
Bei einem einzelnen Token oder Microbatch können spätere Stufen erst beginnen, wenn die benötigte Aktivierung von der vorherigen Stufe eingetroffen ist. Allein die Verteilung von vier Layergruppen auf vier GPUs macht eine sequenzielle Anfrage nicht viermal schneller.
Der Parallelitätsleitfaden von NVIDIA definiert PP als vertikale Aufteilung der Modell-Layer nach ihrer Tiefe. Die serielle Abhängigkeit über die Modelltiefe bleibt bestehen.
Der unmittelbare Vorteil kann daher eher in der Kapazität als in der Latenz liegen. Der Durchsatz steigt, wenn die Laufzeit verschiedene Arbeitsabschnitte über die Stufen hinweg überlappen kann.
Microbatches füllen die Pipeline, sodass mehrere Stufen gleichzeitig arbeiten
Eine Pipeline wird effizient, wenn die Eingabe in Microbatches aufgeteilt wird oder mehrere Inferenzaufgaben gleichzeitig verschiedene Stufen belegen können. Während Stufe 2 einen Microbatch verarbeitet, kann Stufe 1 mit dem nächsten beginnen.
Der Parallelitätsleitfaden von Hugging Face erklärt, dass die Pipeline-Ausführung Microbatches verwendet, um die Leerlaufzeit der Pipeline zu reduzieren. Dasselbe Prinzip der besseren Auslastung gilt immer dann, wenn eine Inferenzlaufzeit unabhängige Arbeitsvorgänge überlappen kann.
Die interaktive Tokengenerierung für einen einzelnen Benutzer bietet weniger natürliche Parallelität, weil jedes neue Token von der Ausgabe des vorherigen Tokens abhängt. Gebündelte Anfragen oder Datenverkehr von mehreren Benutzern können mehr Möglichkeiten schaffen, die Stufen beschäftigt zu halten.
Ungleichmäßige Stufenlaufzeiten erzeugen Blasen und machen die langsamste Stufe zum bestimmenden Faktor
Wenn eine Stufe mehr Layer, langsamere Hardware oder besonders aufwendige Operationen enthält, wartet die nächste Stufe auf Eingaben, während die vorherige Stufe schließlich auf freien Platz wartet. Diese Leerlaufzeiten werden als Pipeline-Blasen bezeichnet.
Die Pipeline-Engine von DeepSpeed legt den Schwerpunkt auf die Aufteilung von Modell-Layern in Pipeline-Stufen. Eine ausgewogene Rechenlast der Stufen ist daher ebenso wichtig wie eine ausgewogene Verteilung der Parameter-Bytes.
In einer gemischten Heim-Beschleunigerumgebung kann eine langsamere GPU bewusst weniger Layer erhalten. Die Speicherkapazität, die Aktivierungsgröße und die unterstützten Geräteübertragungen schränken diese Platzierung jedoch ein.
Pipeline-Parallelität tauscht Gewichtskapazität gegen Aktivierungsübertragung und Ablaufplanung
PP ist attraktiv, wenn das Modell tief ist und sich in Layergruppen aufteilen lässt, die jeweils auf einzelne Geräte passen. Statt der für Tensor-Parallelität typischen häufigen kollektiven Operationen innerhalb eines Layers kommuniziert PP Grenzaktivierungen, bezahlt dafür aber mit seriellen Abhängigkeiten und Pipeline-Blasen.
Der Leitfaden von ZimaSpace zu KI-Konkurrenzsituationen mit mehreren Benutzern zu Hause ist relevant, weil mehr gleichzeitige Arbeit dazu beitragen kann, eine Pipeline zu füllen, während zugleich der Druck auf KV-Cache und Ablaufplanung steigt.
Messen Sie den Speicherbedarf pro Stufe, die Ausführungszeit jeder Stufe, die Übertragungszeit der Aktivierungen, die End-to-End-Latenz, den Durchsatz und den Leerlaufanteil der Geräte. Eine Konfiguration, in der das Modell zwar Platz findet, aber die Hälfte der Beschleuniger ungenutzt bleibt, benötigt möglicherweise eine andere Aufteilung.
Der Leitfaden von ZimaSpace zur lokalen KI-Hardware liefert die grundlegende Kapazitätsübersicht. Pipeline-Parallelität ist eine Möglichkeit, die Speicherschranke eines einzelnen Geräts zu überwinden. Ihr Erfolg hängt jedoch stärker von einer ausgewogenen Verteilung der Stufen ab als allein von der Anzahl der GPUs.
Tech- & KI-Zentrum
Mehr zum Lesen

Können Heimkameras Ereignisse ohne Cloud-Zeitdienste synchronisieren?
Eine mechanismusorientierte Erklärung der Kamera-Zeit ohne Cloud, ihrer Zielkonflikte bei gemeinsam genutzten Ressourcen, drei FAQs zur Abfrageweiterleitung und eines praktischen Verifizierungsprotokolls.

Kann ein lokaler KI-Dienst beschädigte Modellschichten vor der Inferenz erkennen?
Eine mechanismusorientierte Erklärung der Erkennung korrupter Modellebenen, ihrer Zielkonflikte bei gemeinsam genutzten Ressourcen, drei FAQs zur Abfrageverteilung und eines praktischen Verifizierungsprotokolls.

Kann ein RAG-System wiederhergestellt werden, ohne jede Einbettung neu zu generieren?
Eine mechanismusorientierte Erklärung zur RAG-Wiederherstellung ohne erneute Einbettung, zu den Zielkonflikten gemeinsamer Ressourcen, drei FAQs zur Abfrage-Fan-out-Strategie und einem praktischen Verifizierungsprotokoll.

