Was ist Model-Sharding, und warum ist es für die Speichergrenzen von KI-Systemen zu Hause relevant?
Model-Sharding verteilt den erforderlichen Modellzustand auf mehrere Geräte, sodass ein Modell, das den Speicher eines einzelnen Beschleunigers übersteigt, trotzdem geladen und ausgeführt werden kann.
Bei einem KI-Server für zu Hause ist nicht entscheidend, ob ein Checkpoint als mehrere Dateien vorliegt, sondern ob Laufzeitgewichte, Layer, Tensoren oder anderer Zustand tatsächlich auf verschiedene Geräte verteilt werden. Sharding kann einen unmöglichen Speicherbedarf auf einer einzelnen GPU in eine praktikable Bereitstellung auf mehreren Geräten verwandeln. Die Shards müssen jedoch weiterhin Daten austauschen oder Arbeit zwischen den Stufen weitergeben. Dadurch werden Interconnect-Bandbreite, Geräteungleichgewichte und Laufzeitunterstützung zu den nächsten Engpässen.
Laufzeit-Sharding verteilt den Modellzustand auf Geräte
Ein laufendes Modell enthält Tensoren, die verfügbar sein müssen, wenn seine Layer ausgeführt werden. Sharding verändert die Platzierung, sodass verschiedene Geräte unterschiedliche Teile besitzen, anstatt den gesamten Zustand überall zu replizieren.
Ein verteilter Tensor kann die Platzierung geshardeter Tensoren verwenden und verteilte Dimensionen einem Geräteverbund zuweisen, anstatt sie auf jedem Rang identisch zu speichern.
Der unmittelbare Speichervorteil besteht in einer geringeren Belegung pro Gerät. Der systemweite Preis dafür ist, dass kein einzelnes Gerät mehr alle für jede Operation benötigten Daten besitzt. Koordination wird damit zu einem Bestandteil der Inferenz.
Checkpoint-Shards sind nicht dasselbe wie ein geshardetes laufendes Modell
Große Modell-Repositories teilen einen Checkpoint häufig in viele Dateien auf, damit diese schrittweise heruntergeladen und geladen werden können. Diese Verpackungsentscheidung bestimmt jedoch nicht automatisch, wo sich die Tensoren befinden, nachdem die Laufzeit sie geladen hat.
Datei-Sharding und Laufzeitplatzierung bleiben getrennt, da ein Loader geshardete Checkpoints mit einer Verteilung auf mehrere Geräte kombinieren kann.
Ein Heimanwender kann daher Dutzende von `.safetensors`-Shards auf der Festplatte sehen, während die Laufzeit weiterhin versucht, das vollständige Modell auf einer GPU zu platzieren. Umgekehrt kann eine Laufzeit einen Checkpoint beim Laden in ein anderes Layout für mehrere Geräte umverteilen.
Bei der Kapazitätsplanung sollte die tatsächliche Gerätezuordnung und die belegte Speichermenge nach dem Start geprüft werden, anstatt anzunehmen, dass die Anzahl der Repository-Dateien die Inferenztopologie verrät.
Sharding führt zu Kommunikation oder Übergaben zwischen Stufen
Wenn ein Gerät Werte erzeugt, die ein anderer Shard benötigt, müssen Daten über einen Interconnect übertragen oder durch eine kollektive Operation synchronisiert werden. Der genaue Datenverkehr hängt davon ab, ob die Laufzeit Tensoren innerhalb von Layern aufteilt, verschiedene Layerbereiche auf unterschiedliche Geräte verteilt oder den geshardeten Zustand nur bei Bedarf zusammenführt.
Verschiedene Inferenzstrategien für mehrere Geräte wägen unterschiedliche Kommunikationsmuster gegen die Speicherplatzierung ab.
Deshalb können zwei GPUs mit ausreichend gemeinsamem VRAM ein Modell trotzdem langsam bereitstellen. Das Verschieben von Aktivierungen oder die Synchronisierung Teilergebnisse kann zum dominierenden Faktor werden, wenn PCIe oder eine andere Verbindung deutlich langsamer ist als der lokale Speicher des Beschleunigers.
Ungleichartige Geräte können einen Shard zum Engpass machen
Ein heterogener Heimserver kann GPUs mit unterschiedlichen Speichergrößen, Rechenleistungen, Verbindungsbreiten oder Generationen kombinieren. Eine mathematisch gleichmäßige Aufteilung kann dennoch dazu führen, dass das langsamste oder kleinste Gerät das Tempo der gesamten Anfrage bestimmt.
Tools für Layer-Platzierung und Offloading müssen daher die tatsächliche Gerätekapazität berücksichtigen, anstatt von symmetrischer Hardware auszugehen. Explizite verteilte Modellausführung verwendet eine Parallelkonfiguration statt einer automatischen Abstraktion eines gemeinsamen Speichers.
Ein praktisches Layout kann einer größeren GPU mehr Layer zuweisen oder latenzempfindliche Komponenten auf dem schnellsten Pfad belassen. Ziel ist nicht eine gleiche Anzahl an Shards, sondern ein ausgewogener kritischer Pfad, der auf jedes Gerät passt.
Messen Sie pro Gerät den Speicher, die Auslastung, die Übertragungszeit und Leerlaufphasen bei Verwendung desselben Prompts. Ein Shard, der ständig wartet oder Daten auslagert, zeigt, dass die Topologie und nicht der insgesamt kombinierte VRAM die Leistung begrenzt.
Model-Sharding ist zunächst ein Werkzeug für die Speichermachbarkeit
Sharding ist besonders wertvoll, wenn das ungeshardete Modell überhaupt nicht auf ein einzelnes Gerät passt. Sobald das Modell geladen werden kann, verlagert sich die Optimierung auf die Kosten des Interconnects, Batching, die Platzierung des KV-Caches und die Frage, ob ein kleineres oder quantisiertes Modell einfacher wäre.
Eine konkrete Berechnungsstrategie ist die Tensor-parallele Inferenz. Model-Sharding ist das umfassendere Platzierungsproblem, bei dem geklärt wird, welcher benötigte Zustand auf welchem Gerät liegen muss.
Behandeln Sie den gesamten VRAM nicht als einen transparenten gemeinsamen Speicherpool. Sharding kann getrennte Speicher kooperieren lassen, doch jede Laufzeit verfügt weiterhin über Platzierungsregeln und Kommunikationskosten, die bestimmen, ob die resultierende Bereitstellung praktisch nutzbar ist.
FAQ
Ist ein geshardeter Checkpoint dasselbe wie ein geshardetes laufendes Modell?
Nein. Checkpoint-Shards teilen Dateien zur Speicherung oder zum Laden auf. Laufzeit-Sharding bestimmt, welcher Modellzustand während der Inferenz auf welchem Gerät liegt.
Ist Model-Sharding dasselbe wie Tensor-Parallelität?
Nein. Tensor-Parallelität ist eine Möglichkeit, ein geshardetes Modell auszuführen, indem Tensoroperationen aufgeteilt werden. Sharding umfasst außerdem Layer-, Stufen-, Parameter- oder andere Platzierungsstrategien.
Ergeben zwei GPUs mit jeweils 12 GB automatisch einen nutzbaren gemeinsamen Pool von 24 GB?
Nein. Eine Laufzeit muss das Modell ausdrücklich partitionieren. Außerdem verringern Kommunikation, duplizierter Zustand, KV-Cache und Speicherreserven pro Gerät die praktisch nutzbare Gesamtkapazität.
Empfohlene Produkte
Tech- & KI-Zentrum
Mehr zum Lesen
Was ist der Plex-Zustand, und welche Teile müssen erhalten bleiben?
Der persistente Plex-Zustand umfasst die Informationen, die das Servererlebnis über Neustarts und Neuaufbauten hinweg erhalten; Medien und temporäre Transkodierungsdaten erfüllen separate Aufgaben.
Wie handhabt Plex die Authentifizierung bei lokalen und Remote-Sitzungen?
Die Plex-Authentifizierung beginnt mit der Identität des Servers und des Kontos. Anschließend bestimmen lokale oder entfernte Netzwerkpfade die Erreichbarkeit und das Verhalten der sicheren...
Warum kann die Plex-Suche langsamer werden, wenn die Bibliotheksdaten wachsen?
Das Wachstum der Bibliothek allein ist nicht die Diagnose. Prüfe zunächst die Abfragestruktur, Indizes, den Cache-Zustand, die Speicherlatenz und die Schreibaktivität, bevor du die...
