Edge0: 35B-MoE streamt von SSD auf 24 GB – doch Plattform- und Leistungsangaben widersprechen sich

Edge0 veröffentlicht: 35B-MoE läuft mit SSD-Streaming auf 24 GB

Edge0 ist ein Open-Source-Streaming-MoE-Inferenz-Framework, das große sparse Mixture-of-Experts-Modelle auf Consumer-Hardware lauffähig macht. Der Kernansatz: Expertengewichte werden bei Bedarf von einer SSD gestreamt, statt das gesamte Modell im Arbeitsspeicher zu halten. Nach Angaben des technischen Berichts liefert Edge0 ein 35B-MoE auf einer einzelnen 24-GB-Maschine mit 20 Tokens pro Sekunde innerhalb von 3 GiB Peak-Active-Memory. Der Grund für diesen Ansatz liegt in der Speicherwand: Ein 35B-Modell belegt in 4-Bit-Quantisierung 19,5 GB, und Sparsity reduziert zwar den Rechenaufwand pro Token, nicht aber die zu haltenden Bytes. Naives SSD-Offloading scheitert, weil die Experten der nächsten Schicht gewählt werden müssen, bevor die Ausgabe der aktuellen Schicht vorliegt – die Lesevorgänge können also nicht früh genug starten, um hinter der Berechnung verborgen zu werden. Edge0 schließt diese Lücke mit einem Prerouter, der das Routing der nächsten Schicht einen Token voraus vorhersagt. Die Vorhersage wird als Routing selbst verwendet, sodass die gestagte Expertenmenge gleich der gerouteten Menge ist und nichts verworfen wird.

Die erste Open-Source-Veröffentlichung erfolgte am 8. September 2026 mit den Modellen Edge0-35B-A3B-preview und Edge0-8B-A1B-preview auf Hugging Face und ModelScope. Am 16. September 2026 erschien der technische Bericht auf arXiv unter dem Titel „The Other Half of the Memory Wall: Serving 35B MoEs from SSD with Trained Routing Prediction“. Am 30. September 2026 meldeten die Release-Notes die Veröffentlichung von Inference-Engines für vier Plattformen. Framework, Checkpoints und Adapter sind Open Source; ein 8B-Tier läuft auf demselben Framework. Die Modelle sind als Preview gekennzeichnet und werden als End-to-End-Release ausgeliefert, bei dem Checkpoint, LoRA-Adapter und Prerouter-Kopf als Einheit zusammenarbeiten. Der technische Bericht betont, dass die Sparsity den Rechenaufwand pro Token verringert, nicht aber die Speichermenge, die gehalten werden muss – genau dieses Problem adressiert Edge0.

Drei Bausteine: Prerouter, SSD-Offload, Recover-LoRA

Edge0 kombiniert drei technische Bausteine. Der erste ist SSD-Expert-Offload: Expertengewichte werden bei Bedarf von Storage gestreamt, sodass nur die aktiv gerouteten Gewichte im RAM liegen. Der Peak-Speicher ist damit durch die aktive Expertenmenge begrenzt, nicht durch die Gesamtzahl der Parameter. Das ist der zentrale Hebel, um ein 35B-Modell auf 24 GB lauffähig zu machen. Die Release-Notes beschreiben dies als „Expertengewichte werden nach Bedarf aus dem Speicher gestreamt; der Spitzenspeicher wird durch die aktive Menge begrenzt, nicht durch die Parameteranzahl“. Der zweite Baustein ist der Prerouter: Ein pro-Layer-Kopf sagt das Routing der nächsten Schicht einen Token voraus. Diese Vorhersage wird als Routing verwendet, sodass die gestagte Expertenmenge exakt der gerouteten Menge entspricht und keine Experten verworfen werden. Dadurch überlappen Expertenladevorgänge mit der Vorwärtsberechnung, statt sie zu blockieren. Nach Angaben des Projekts erhöht der Prerouter den Decode-Durchsatz um bis zu 59 Prozent; der Gewinn wächst mit Speicherlatenz, Modellgröße und Routing-Breite K. Der dritte Baustein ist eine unmerged Recover-LoRA, die auf dem Studentenpfad trainiert wurde, um Qualitätsverluste durch int4-Quantisierung und Routing-Ersetzung auszugleichen. Der Adapter bleibt unmerged, sodass eine einzige schreibgeschützte Basis mehrere Adapter bedienen kann. Die Adapter sind als Safetensors-Dateien vereinheitlicht und werden automatisch geladen, sodass `edge0 serve` die trainierte Pipeline out of the box ausführt.

Das 35B-Modell basiert auf Qwen3.6-35B-A3B mit Routing-Breite K=4, das 8B-Modell auf Ling 3.0 Hybrid mit K=8. Für das 8B-Tier sind 16 Prerouter-Köpfe dokumentiert; die Vorhersage wird ab Layer 7 konsumiert, Layer 1 bis 6 nutzen den ursprünglichen Router. Staged Decode ist ausgeschaltet, der Expert-Cache umfasst 64 Slots, und das Prefill läuft als Full-Layer-E3b-Prefill mit einer Chunk-Größe von 2048. Bei einem 27-Token-Prompt liest das On-Demand-Prefill etwa 0,42 GiB an gerouteten Experten statt des gesamten Layers. Die Framework-Dokumentation beschreibt die Backend-Isolation: Der gesamte MLX-Code liegt unter `edge0/backends/mlx/`, die Kernlogik greift nur über eine Fassade zu, und ein CUDA-Backend ist als Slot reserviert. Die Verwendung ähnelt transformers: `AutoConfig`, `AutoModel` und `AutoEngine` lösen den Adapter automatisch anhand des Modellnamens auf. Diese Details stammen aus der Konfiguration des 8B-Tiers und der Framework-Dokumentation und sind nicht unabhängig verifiziert.

Durchsatz und Speicher: 20 tok/s im Paper, 15 tok/s auf der Modellkarte

Bei Durchsatz und Speichernutzung des 35B-Modells widersprechen sich die Quellen. Der technische Bericht und das Abstract nennen 20 Tokens pro Sekunde innerhalb von 3 GiB Peak-Active-Memory auf einer einzelnen 24-GB-Maschine. Die Hugging-Face-Modellkarte für Edge0-35b-a3b Preview gibt dagegen 15 Tokens pro Sekunde Decode, 140 Tokens pro Sekunde Prefill, 3 GiB aktive Speichernutzung und einen Abstand von 3,9 Punkten zum fp16-Basismodell an. Ein unabhängiger Bericht meldet für den veröffentlichten 35B-Benchmark 2,9 GB Peak-Active-Memory auf einem Mac mini mit M4 Pro und 24 GB Unified Memory; für die iPhone-Demo werden 1 bis 2,5 GB Peak-Speicher genannt. Das README des Repositories gibt für das 35B-Modell etwa 2,9 GB Peak-Active-Memory und für das 8B-Modell etwa 1,0 GB an (bei kurzen Kontexten).

Die Abweichungen könnten auf unterschiedliche Hardware zurückgehen – das Paper nennt eine einzelne 24-GB-Maschine ohne Spezifikation, die Modellkarte bezieht sich möglicherweise auf Apple Silicon, der unabhängige Bericht auf einen Mac mini M4 Pro. Auch die Messbedingungen unterscheiden sich: Das Paper misst möglicherweise den Gesamtdurchsatz über eine Benchmark-Suite, die Modellkarte nennt explizit Decode und Prefill getrennt. Kontextlängen und Adapterversionen sind nicht einheitlich spezifiziert. Die Quellen spezifizieren diese Bedingungen jedoch nicht einheitlich, sodass der Widerspruch nicht aufgelöst ist. Die Modellkarte bezeichnet das Modell als lauffähig in „phone-class memory“ und „fast enough for interactive use“; diese Angaben sind Herstellerangaben und nicht unabhängig belegt. Auch die Angabe, dass lange Prompts mit 140 Tokens pro Sekunde gefüllt werden, stammt aus der Modellkarte und wurde nicht extern verifiziert.

Release-Notes versprechen vier Plattformen, Repository dokumentiert nur macOS

Die Release-Notes auf GitHub melden für den 30. September 2026 die Veröffentlichung von Inference-Engines für iOS, macOS, Android und Windows. Der Quellcode sei in den Unterverzeichnissen ios/, macos/, android/ und windows/ offengelegt; ein einheitliches Inferenz-Framework solle im vierten Quartal 2026 folgen. Das Repository-README und die Framework-Dokumentation geben jedoch an, dass aktuell nur das MLX-Backend für macOS auf Apple Silicon unterstützt wird – getestet auf M1, M2, M3 und M4. Ein CUDA-Backend steht auf der Roadmap, andere Plattformen seien noch nicht unterstützt. Ein unabhängiger Bericht bestätigt, dass das Repository derzeit macOS auf Apple Silicon als unterstützte Plattform listet und kein iOS-Build veröffentlicht ist.

Das Framework ist so konzipiert, dass Backends isoliert sind: Der gesamte MLX-Code liegt unter `edge0/backends/mlx/`, die Kernlogik greift nur über eine Fassade zu, und ein CUDA-Backend ist als Slot reserviert. Die Release-Notes sprechen von „einer Rezeptur, die auf allen Plattformen funktioniert“ und von „der besten Inferenzerfahrung über Architekturen und Plattformen hinweg“. Möglicherweise wurden plattformspezifische Engines in Unterverzeichnissen veröffentlicht, während das Python-Framework nur MLX unterstützt; oder die Release-Notes beziehen sich auf separate native Engines, die nicht im Haupt-Repository dokumentiert sind. Der Widerspruch ist nicht aufgelöst. Die Ankündigung, die vier Plattform-Engines böten „die beste Inferenzerfahrung über Architekturen und Plattformen hinweg“, ist eine Herstellerangabe ohne unabhängige Vergleichstests. Auch die Roadmap für ein einheitliches Framework im vierten Quartal 2026 ist eine Projektankündigung, deren Umsetzung noch aussteht.

iPhone-Demo ohne iOS-Build: Reproduzierbarkeit offen

Samuel Zeng zeigte in einem Beitrag eine iPhone-Demo: Ein 35B-Modell läuft auf einem iPhone mit 1 bis 2,5 GB Peak-Speicher, ohne Cloud, ohne Remote-Server und ohne Desktop-GPU. Die Demo generiert Spiellogik, strukturierte 3D-Szenen und interaktive Web-Erlebnisse auf dem Gerät. Ein unabhängiger Bericht stellt jedoch klar, dass dieses iPhone-Ergebnis eine Demonstration bleibt und nicht die reproduzierbare Baseline der Veröffentlichung ist. Das Repository listet derzeit macOS auf Apple Silicon als unterstützte Plattform; das MLX-Backend wurde auf M1 bis M4 getestet. Der veröffentlichte 35B-Benchmark meldet 2,9 GB Peak-Active-Memory auf einem Mac mini mit M4 Pro und 24 GB Unified Memory. Ein iOS-Build oder ein iPhone-Benchmark-Verfahren ist im Repository nicht veröffentlicht. Damit bleibt offen, ob die iPhone-Demo mit einer nicht veröffentlichten iOS-Engine durchgeführt wurde und ob die genannten Speicherwerte auf anderen Geräten reproduzierbar sind. Der unabhängige Bericht erwähnt zudem, dass Samuel Zeng zuvor bei Alibaba an maschineller Übersetzung gearbeitet hat und einen Master-Abschluss der University of Macau besitzt – diese Hintergrundinformationen ändern jedoch nichts an der fehlenden Reproduzierbarkeit der Demo.

Was Edge0 für lokale MoE-Inferenz bedeutet – und was ungeklärt bleibt

Edge0 senkt die Hürde für große MoE-Modelle auf Consumer-Hardware erheblich: Statt ein 35B-Modell vollständig im Speicher zu halten, streamt das Framework nur die aktiv gerouteten Experten von der SSD. Das ermöglicht On-Device-Inferenz ohne Cloud und begrenzt den Peak-Speicher auf die aktive Expertenmenge. Gleichzeitig bleiben zentrale Fragen offen. Die Plattform-Unterstützung ist widersprüchlich: Release-Notes nennen vier Engines, das Repository dokumentiert nur macOS. Die Durchsatzangaben schwanken zwischen 20 und 15 Tokens pro Sekunde, ohne einheitliche Messbedingungen. Die iPhone-Demo ist nicht reproduzierbar, weil kein iOS-Build und kein Benchmark-Verfahren veröffentlicht sind. Herstellerangaben wie „production-proven recipe“ und „beste Inferenzerfahrung“ sind nicht unabhängig belegt. Für eine belastbare Einordnung fehlen unabhängige Produktions-Deployments, Vergleichstests auf den angekündigten Plattformen und reproduzierbare Messungen auf Telefon-Hardware.