The Other Half of the Memory Wall: Serving 35B MoEs from SSD with Trained Routing Prediction

Yu Lin; Yiming Wang; Runyuan Cai; Hanze Liu; Xiaodong Zeng

Paper · arXiv 2609.18063

Die andere Hälfte der Memory Wall: Bereitstellung von 35B-MoEs von der SSD mittels trainierter Routing-Vorhersage

The Other Half of the Memory Wall: Serving 35B MoEs from SSD with Trained Routing Prediction

Yu Lin, Yiming Wang, Runyuan Cai, Hanze Liu, Xiaodong Zeng

Veröffentlicht 2026-09-16cs.AI arXiv PDF

Mit Übersetzung und KI lesen

Zusammenfassung in drei Zeilen

🎯 MoEs der 35B-Klasse benötigen selbst bei int4 ~19,5 GB und übersteigen den RAM von Consumer-Geräten, während naives SSD-Offloading durch Festplattenlatenz blockiert, da das Routing vom Output der vorherigen Schicht abhängt.
🔧 Edge0 streamt MoE-Experten von der SSD mithilfe eines schichtweisen Prerouters, der das Routing ein Token im Voraus prognostiziert („Vorhersage als Routing“), kombiniert mit einem unzusammengeführten parallelen Recovery-LoRA, das auf dem Student-Pfad destilliert wurde.
📈 Stellt ein 35B-MoE mit ~20,4 tok/s bei 2,9 GiB Spitzenspeicher auf einem 24 GB Mac mini M4 Pro bereit, mit nur 3,9 Punkten durchschnittlichem Benchmark-Abstand zum fp16-Teacher.

Abstract

Die Inferenz von Mixture-of-Experts-Modellen (MoE) auf Consumer-Hardware wird durch den Speicherbedarf der Gewichte begrenzt: Ein Modell der 35B-Klasse belegt in 4-Bit 19,5 GB, und Sparsity reduziert lediglich die Rechenlast pro Token, nicht jedoch die vorzuhaltende Datenmenge. Ein naives Offloading auf SSDs hilft für sich allein nicht, da die Experten für Schicht N+1 ausgewählt werden müssen, bevor die Ausgabe von Schicht N vorliegt; die Lesezugriffe können daher nicht früh genug beginnen, um hinter der Berechnung verborgen zu werden. Wir präsentieren Edge0, eine Streaming-MoE-Inferenz-Engine, die diese Lücke mit einem Prerouter schließt: Ein schichtweiser Head sagt das Routing der nächsten Schicht um ein Token voraus. Diese Vorhersage wird direkt als eigentliches Routing übernommen, sodass die bereitgestellte Expertenmenge exakt der gerouteten Menge entspricht und keine Tokens verworfen werden. Ein unzusammengeführtes (unmerged) Recovery-LoRA, das auf dem Student-Pfad trainiert wurde, kompensiert den Qualitätsverlust durch die int4-Quantisierung und das ersetzte Routing. Auf einem einzelnen 24-GB-Rechner stellt Edge0 ein 35B-MoE mit 20 tok/s bei einem maximalen aktiven Speicherbedarf von 3 GiB bereit – im Durchschnitt über fünf öffentliche Benchmarks innerhalb weniger Punkte im Vergleich zum fp16-Teacher. Eine 8B-Variante läuft auf demselben Framework; das Framework, die Checkpoints und die Adapter sind Open Source.

Original-Abstract (Englisch)

Mixture-of-experts (MoE) inference on consumer hardware is bounded by weight memory: a 35B-class model is 19.5GB at 4-bit, and sparsity shrinks the compute per token, not the bytes that must be held. Naive offloading to SSD does not help on its own, because layer N+1's experts must be chosen before layer N's output exists, so the reads cannot start early enough to hide behind compute. We present Edge0, a streaming MoE inference engine that closes the gap with a prerouter: a per-layer head predicts the next layer's routing one token ahead, and the prediction is consumed as the routing itself, so the staged expert set equals the routed set and nothing is dropped. An unmerged recovery LoRA, trained on the student path, pays back the quality lost to int4 quantization and routing replacement. On a single 24GB machine, Edge0 serves a 35B MoE at 20tok/s inside 3GiB of peak active memory, within a few points of its fp16 teacher on average across five public benchmarks. An 8B tier runs on the same framework, and the framework, checkpoints, and adapters are open source.

Leseleitfaden

Problem und Motivation

Mixture-of-Experts-Modelle (MoE) skalieren die Gesamtzahl der Parameter, während die aktiven Parameter pro Token gering gehalten werden (z. B. Aktivierung von ~3B Parametern pro Token bei einem 35B-Modell). Allerdings bleibt die Inferenz auf Consumer-Hardware durch den statischen Gewichtsspeicher begrenzt: Ein 35B-MoE benötigt selbst bei einer int4-Quantisierung rund 19,5 GB. Auf einem 24-GB-System verdrängt dies das Betriebssystem und den KV-Cache nahezu vollständig, was zu starkem Memory Paging und drastisch reduzierter Decode-Geschwindigkeit führt (z. B. 3,9 tok/s für ein resident im Speicher gehaltenes Modell auf einem M4 Pro Mac mini).

Das Auslagern von Expertengewichten auf eine SSD verringert den Speicherbedarf, ein naives Laden bei Bedarf (On-Demand) führt jedoch zu einem harten Serialisierungsengpass: Die Auswahl der Experten für Schicht $N + 1$ hängt von der Ausgabe der Schicht $N$ ab. Die Lesezugriffe auf die SSD können nicht früh genug starten, um sich hinter der Berechnung zu verbergen, wodurch die Ausführung einmal pro Schicht und Token an der Festplattenlatenz ins Stocken gerät.

Kernideen

SSD als Weight Tier: Die MoE-Expertengewichte verbleiben im int4-Format auf der SSD und werden via Memory-Mapping (mmap) in einen kompakten Streaming-Pool eingebunden. Der Spitzenspeicherbedarf wird durch das aktive Working Set bestimmt und nicht durch die Gesamtparametergröße des Modells.
Vorhersage als Routing (Prediction as Routing): Anstatt auf den Abschluss von Schicht $N$ zu warten, sagt ein schichtweiser Prerouter das Routing für Schicht $N + 1$ ein vollständiges Token im Voraus voraus. Entscheidend ist, dass das Modell diese Vorhersage zur Decode-Zeit als das eigentliche Routing übernimmt. Dies verhindert per Konstruktion verworfene Tokens oder Fallback-Ladevorgänge, da die vorbereitete Menge identisch mit der gerouteten Menge ist.
Unzusammengeführtes Recovery-LoRA (Unmerged Recovery LoRA): Die 4-Bit-Quantisierung und das approximierte Routing verursachen Qualitätsverluste. Edge0 trainiert einen Low-Rank-Adapter mittels Destillation auf dem Routing-Pfad des Students. Da das Einfügen (Merge) des LoRA in die int4-Basis und eine anschließende Re-Quantisierung den Großteil des Deltas zunichtemachen würde (nur 18 % Retention auf Logits-Ebene bleiben erhalten), stellt Edge0 den Adapter als paralleles, unzusammengeführtes Delta mit vernachlässigbarem Overhead bereit.

Methode

Architektur des Prerouter-Heads

Jeder Prerouter-Head der Schicht $N$ wird bei Token $t$ auf der Ausgabe der Post-Attention-Layer-Norm ausgeführt und sagt das Routing für Schicht $N + 1$ bei Token $t + 1$ voraus. Die Eingangsmerkmale verknüpfen den Hidden State mit zwei Top- $k$ -One-Hot-Routingvektoren (aktuelles und vorheriges Token):

$dim = d_{model} + 2 E$

Für die 35B-Klasse ergibt sich $2048 + 2 \times 256 = 2560$ . Der Head berechnet:

$head (x) = fc_{2} (erf - gelu (fc_{1} (x))) + ℓ (x)$

wobei $ℓ (x)$ ein linearer Residualpfad ist, der mit den Router-Gewichten der nächsten Schicht initialisiert (warm-started) wird.

Ausführung des unzusammengeführten Adapters

Die bereitgestellte MoE-Schicht behält die quantisierten Basis-Bytes bei und führt parallel das LoRA-Delta aus:

$y = W_{int4} (x) + \frac{α}{r} B A x$

Dreiphasiges Training

Head-Destillation: Die Prerouter-Heads werden darauf trainiert, die tatsächlichen Router-Entscheidungen der nächsten Schicht des Teachers nachzuahmen, während der Rest des Netzwerks eingefroren bleibt.
Student-Pfad-SFT: Recovery-LoRA-Adapter (angebracht an Attention-, Linear-Attention- und Shared-Expert-Projektionen, jedoch nicht an den gestreamten Experten) werden anhand von Teacher-generiertem Text trainiert, wobei das Routing zwingend über den Prerouter erfolgt.
On-Policy-Destillation: Der Student generiert Text unter vorab gerouteter Ausführung, der fp16-Basis-Teacher bewertet die Generierungen, und die LoRA-Parameter werden über reverse Kullback-Leibler-Divergenz mit einem tail-aware Top- $k$ -Wahrscheinlichkeitsziel optimiert.

Ergebnisse

Durchsatz & Speicher (Mac mini M4 Pro, 24 GB):
- edge0-35b ( $K = 4$ ): Erreicht 20,4 tok/s beim Decoding mit nur 2,9 GiB aktivem Spitzenspeicher aus einem 19,5 GB int4-Checkpoint (im Vergleich zu 3,9 tok/s und 18,2 GiB bei vollständiger RAM-Residenz).
- edge0-8b ( $K = 8$ ): Erreicht 28,0 tok/s beim Decoding innerhalb von 1,5 GiB Spitzenspeicher.
Prefetching-Beschleunigung (MacBook M2, 16 GB):
- Im Vergleich zum rein reaktiven On-Demand-Streaming steigert das 1-Token-Prerouter-Prefetching die Decode-Geschwindigkeit um +80 % bis +84 % über verschiedene Routing-Breiten hinweg ( $K = 2$ : 4,8 auf 8,6 tok/s; $K = 4$ : 3,5 auf 6,4 tok/s; $K = 8$ : 1,8 auf 3,3 tok/s).
- Die blockierte Ladezeit im Hauptthread sinkt drastisch (z. B. von 244,0 ms auf 101,9 ms pro Schritt bei $K = 4$ ).
Modellqualität (OpenCompass):
- Über fünf Benchmarks hinweg (AIME 2026, HumanEval, GPQA-Diamond, MMLU-Pro, IFBench) erreicht edge0-35b einen Durchschnittswert von 79,2 gegenüber 83,2 für die fp16 Qwen3.6-Basis (Differenz von 3,9 Punkten).
- edge0-8b erzielt 69,9 gegenüber 72,7 für die Ling 3.0 tiny fp16-Basis (Differenz von 2,8 Punkten).

Grenzen und offene Fragen

Gleichzeitigkeit beim Serving: Edge0 arbeitet FIFO-serialisiert für einzelne Anfragen; Batching verändert das Working Set der Experten und die Caching-Dynamik auf eine Weise, die von den Single-Stream-Profilen nicht abgedeckt wird.
CPU Graph-Building-Overhead: Die Decode-Geschwindigkeit wird durch CPU-seitigen Framework-Overhead begrenzt (~44 ms/Schritt beim Erstellen des MLX-Graphen über 40 Schichten hinweg), was durch SSD-Optimierungen nicht behoben werden kann.
Qualitätseinbußen beim logischen Schließen: Der Leistungsabfall konzentriert sich auf komplexe Reasoning-Benchmarks (z. B. ein Rückgang um 6,1 Punkte bei AIME für 35B und 10,0 Punkte für 8B).
Hardware-Abhängigkeit: Die relativen Durchsatzgewinne des Prerouters hängen von der Festplattenlatenz ab und verringern sich, wenn die Gewicht-Caches warm sind oder extrem schnelle Speichersysteme verwendet werden.

Schlüsselbegriffe

Edge0: Eine Streaming-MoE-Inferenz-Engine, die Modelle von der SSD bereitstellt, indem Lesezugriffe durch Routing-Vorhersage mit Berechnungen überlappt werden und Qualitätsverluste durch ein unzusammengeführtes Recovery-LoRA kompensiert werden.
prerouter: Ein leichtgewichtiger, schichtweiser neuronaler Head, der die Routing-Entscheidungen der Schicht N+1 ein Token im Voraus anhand des Hidden State von Schicht N und des bisherigen Routing-Verlaufs vorhersagt.
prediction-as-routing: Das Entwurfsprinzip, bei dem die vom Prerouter vorhergesagte Expertenmenge zur Decode-Zeit direkt als tatsächliches Schicht-Routing verwendet wird, wodurch verworfene Tokens oder Latenzstrafen zur Laufzeit entfallen.
recovery LoRA: Ein Low-Rank-Adapter, der mittels Destillation auf dem vorab gerouteten Student-Pfad trainiert und als unzusammengeführter paralleler Zweig ausgeführt wird, um int4-Quantisierungs- und Routing-Approximationsfehler auszugleichen.
staged decode: Ein Modus zur Expertenausführung mittels Double-Buffering mit festen Slots, bei dem Expertenindizes über eine Slot-Tabelle auf der GPU zugeordnet werden, um Speicherallokationen pro Schritt zu vermeiden.
incremental sticky-slot stack (incr_stack): Ein Mechanismus, der persistente, gestapelte Expertentensoren direkt an Ort und Stelle aktualisiert und pro Schritt nur die geänderten Expert-Slots überschreibt, anstatt alle Tensoren neu zusammenzusetzen.
unmerged delta: Die Ausführung eines LoRA-Adapters parallel zu den quantisierten Basisgewichten, anstatt diesen direkt mit den Gewichten zu verschmelzen, um den Verlust feingranularer Anpassungen bei der Re-Quantisierung zu verhindern.
memory wall: Die Diskrepanz zwischen Prozessordurchsatz und DRAM-Bandbreite/-Kapazität, die sich beim lokalen Bereitstellen von LLMs auf den dynamischen KV-Cache-Zustand und die statische Speicherung der Modellgewichte aufteilt.

Fragen

Warum nutzt Edge0 die Vorhersage direkt als Routing, anstatt sie als unverbindlichen Hinweis (Hint) zu behandeln?

Werden Vorhersagen nur als Hinweise behandelt, sind bei Fehlvorhersagen Fallbacks zur Laufzeit oder das Verwerfen von Tokens erforderlich. Wird die Vorhersage direkt als Routing übernommen, entspricht die bereitgestellte Expertenmenge stets der gerouteten Menge. Dadurch werden die Kosten der Approximation in das Offline-Training verlagert, wo die Destillation die Qualität wiederherstellt.

Warum wird das Recovery-LoRA unzusammengeführt (unmerged) bereitgestellt, statt in die 4-Bit-Gewichte integriert zu werden?

LoRA-Gewichtsdeltas haben einen RMS-Wert von etwa 10^-3, was kleiner ist als die Schrittweite einer 4-Bit-Quantisierung. Ein Zusammenführen und anschließendes Re-Quantisieren löscht den Großteil der Adapterwirkung aus, sodass auf Logits-Ebene nur 18 % Retention erhalten bleiben. Ein paralleles, unzusammengeführtes Delta behält hingegen 100 % der Genauigkeit.

Warum sagt Edge0 ein Token im Voraus voraus, anstatt innerhalb desselben Tokens zu agieren?

Eine Vorhersage innerhalb desselben Tokens erfordert schichtweise GPU-Pipeline-Flushes, die 30 bis 100 ms pro Schritt dauern – länger als die Ladezeit, die verborgen werden soll. Der Vorsprung von einem vollen Token erlaubt es, alle vorbereiteten Schichten in einem einzigen Batch-Flush vorherzusagen, wodurch die Rechenzeit eines gesamten Decode-Schritts zur Verfügung steht, um die SSD-I/O zu überdecken.

Wie kann Edge0 auf einem 24-GB-Rechner schneller decodieren als eine vollständig im Speicher gehaltene Baseline?

Ein vollständig residentes 19,5-GB-Modell belegt 18,2 GiB RAM, wodurch kaum Speicher für das Betriebssystem und den KV-Cache verbleibt. Dies führt zu massivem OS-Memory-Paging und senkt die Decode-Rate auf 3,9 tok/s. Edge0 streamt Experten von der SSD bei nur ~2,9 GiB aktivem Spitzenspeicher, umgeht den Speicherdruck des Betriebssystems vollständig und erreicht 20,4 tok/s.

Die Übersicht auf dieser Seite wurde von einer KI aus dem Paper erstellt und kann Fehler enthalten. Details stehen im Paper.

Mit Übersetzung und KI lesen