Wie verändert das Mixture-of-Experts-Routing die lokale Modellberechnung?

Mixture-of-Experts-Routing verändert die Berechnung lokaler Modelle, indem jedes Token nur durch eine kleine Teilmenge von Experten-Feedforward-Netzwerken geleitet wird, anstatt jeden Experten zu aktivieren.

Dadurch wirkt ein großes MoE-Modell auf einem Heimserver ungewöhnlich: Sein gesamter Checkpoint kann riesig sein, während die für ein einzelnes Token ausgeführte Expertenberechnung einem deutlich kleineren aktiven Modell ähneln kann. Der Vorteil liegt in der sparsamen Arithmetik, nicht in kostenlos verfügbarem Speicher. Die Expertengewichte müssen weiterhin gespeichert werden, und das Routing über mehrere Geräte kann einen Teil der eingesparten Berechnung in Kommunikation umwandeln.

Ein dichter Transformer aktiviert für jedes Token dieselben Feedforward-Parameter

In einer gewöhnlichen dichten Transformer-Schicht durchläuft jedes Token dasselbe Feedforward-Netzwerk. Eine Erhöhung der Anzahl der Feedforward-Parameter vergrößert daher sowohl die Modellgröße als auch den Rechenaufwand für jedes Token.

Der Switch Transformer stellt dem sparsam aktivierte Mixture-of-Experts-Schichten gegenüber, bei denen verschiedene Tokens unterschiedliche Parametersätze auswählen können.

Für lokale Inferenz entsteht dadurch die erste wichtige MoE-Unterscheidung: Die Gesamtzahl der Parameter bestimmt, wie viel Modellzustand gespeichert werden muss, während die aktivierten Parameter maßgeblich den Experten-Rechenaufwand pro Token bestimmen.

Ein Router bewertet jedes Token anhand der verfügbaren Experten

In einer MoE-Schicht untersucht ein kleiner Router die Token-Repräsentation und erzeugt Bewertungen oder Wahrscheinlichkeiten für mögliche Experten. Die Laufzeitumgebung wählt anschließend eine begrenzte Anzahl aus, abhängig von der Architektur meist Top-1 oder Top-k.

Megatron Core von NVIDIA stellt einen Router bereit, der bestimmt, an welche Experten jedes Token gesendet wird. Die Routing-Entscheidung verändert, welche Expertenmatrizen dieses Token verarbeiten.

Zwei Tokens innerhalb desselben Prompts können daher unterschiedliche Expertengewichte aktivieren, obwohl sie die Aufmerksamkeitsschicht und andere dichte Modellteile gemeinsam nutzen.

Sparse Aktivierung reduziert die Expertenberechnung, nicht aber die Speicherung aller Gewichte

Wenn eine Schicht acht Experten enthält, aber jedes Token an zwei von ihnen weiterleitet, werden für dieses Token nur die Berechnungen der ausgewählten Experten ausgeführt. Die übrigen Expertenmatrizen bleiben während dieses Schritts inaktiv.

Die Forschung zu Expert Choice beschreibt MoE als Methode, die die Parameterzahl erhöht und dabei die Berechnung pro Token vergleichsweise begrenzt. Deshalb kann ein MoE-Checkpoint eine sehr große Gesamtzahl an Parametern, aber eine deutlich kleinere Anzahl aktiver Parameter ausweisen.

Ein Heimserver muss weiterhin den vollständigen Satz an Expertengewichten irgendwo verfügbar halten, sofern die Laufzeitumgebung diese nicht streamt oder auslagert. Sparse Berechnung ist nicht dasselbe wie sparse Speicherung.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Die Platzierung der Experten kann Routing in Gerätekommunikation verwandeln

Auf einer einzelnen GPU verändert die Auswahl eines Experten hauptsächlich, welche lokalen Gewichtsblöcke gelesen werden. Über mehrere GPUs hinweg können Experten verteilt sein, sodass eine Token-Repräsentation zu dem Gerät übertragen werden muss, auf dem der ausgewählte Experte liegt, und anschließend in den Hauptablauf der Schicht zurückkehren muss.

Das MoE-Inferenzdesign von DeepSpeed weist Expertengruppen mithilfe von Expertenparallelität über mehrere GPUs zu. Das Routing umfasst dann neben der Matrixmultiplikation auch Kommunikation.

Ein kleiner Heimserver mit mehreren GPUs kann dadurch zum Engpass bei der Verbindung werden, selbst wenn die Berechnung pro Token sparsam ist. PCIe-Topologie und Peer-to-Peer-Unterstützung sind wichtiger, als es die Zahl der aktiven Parameter allein vermuten lässt.

Unausgeglichenes Routing erzeugt überlastete Experten und ungenutzte Kapazität

Reale Prompts verteilen Tokens nicht unbedingt gleichmäßig. Wenn viele Tokens denselben Experten auswählen, wird das entsprechende Gerät oder der entsprechende Kernel zum Engpass, während andere Experten warten.

MoETuner nennt unausgeglichenes Token-Routing und eine unausgeglichene Expertenaktivierung als praktische Engpässe beim Betrieb, da sich auf einigen Geräten mehr geroutete Arbeit und Kommunikation ansammeln kann als auf anderen.

Bei lokaler Inferenz kann sich unausgeglichenes Routing als schwankende Token-Latenz zwischen Prompts zeigen, selbst wenn Kontextlänge und Modellgröße ähnlich sind. Das Modell wählt dynamisch einen anderen Rechenpfad.

Plane die lokale MoE-Kapazität getrennt nach Gesamtgewichten und aktivem Pfad

Eine nützliche Hardware-Schätzung erfasst die Gesamtgröße der Modellgewichte, die Anzahl der pro Token aktiven Experten, die Kosten der dichten Schichten, den KV-Cache, die Quantisierung sowie die Frage, ob sich die Experten auf einem Beschleuniger, mehreren GPUs, im CPU-RAM oder auf dem Speicher befinden.

Die Diskussion von ZimaSpace über die Planung von Speicher und Beschleunigern für lokale KI liefert den übergeordneten Kapazitätskontext für Heimserver. MoE fügt eine zusätzliche Trennung zwischen residenter Kapazität und aktiver Berechnung hinzu.

Führe Benchmark-Prompts aus unterschiedlichen Aufgaben aus, da die Routing-Muster variieren können. Miss Tokens pro Sekunde, Auslastung der einzelnen Geräte, Expertenauslastung, Kommunikationsverkehr und die im Speicher gehaltenen Modellanteile, anstatt anzunehmen, dass die angegebene Zahl aktiver Parameter das gesamte System vorhersagt.

Für besonders große lokale Checkpoints behandelt die Bereitstellungsanalyse großer Modelle von ZimaSpace die angrenzende Kapazitätsfrage. Routing verändert die aktive Berechnung, doch der gesamte Speicherbedarf der Gewichte und ihre Platzierung über mehrere Geräte bestimmen weiterhin, ob das Modell praxistauglich ist.