MoE auf dem Smartphone laufen lassen? Meta stellt MobileMoE vor, das iPhone 16 Pro beschleunigt um das 3,8-fache
In den letzten Jahren werden Mixture of Experts (MoE)-Modelle bereits weitgehend in großen Cloud-Modellen eingesetzt. Auf Mobiltelefonen hingegen basieren Large Language Models (LLM) immer noch hauptsächlich auf dichten Architekturen. In der Vergangenheit waren die Einschränkungen von Mobilgeräten in Bezug auf Speicher, Rechenleistung und Latenz strenger. Es fehlte bisher an einer systematischen Untersuchung von Edge-MoE-Modellen im Bereich von weniger als einer Milliarde aktiver Parameter. Mit der zunehmenden DRAM-Kapazität von Mobilgeräten besteht nun die Möglichkeit, MoE auch auf Smartphones zu implementieren.
Das von dem Meta-Team vorgeschlagene MobileMoE hat erstmalig eine effiziente MoE-Inferenz auf kommerziellen Smartphones realisiert. Die Ergebnisse zeigen, dass MobileMoE-S/M in 14 Grundtests bei ähnlichem Speicherverbrauch mit nur einem halben bis einem viertel des Rechenaufwands der dichten Baseline die gleiche oder sogar eine höhere durchschnittliche Genauigkeit erzielt. In praktischen Tests hat MobileMoE-S auf der GPU/MLX-Backend des iPhone 16 Pro die höchste Beschleunigung gezeigt, im Eingabestadium um bis zu 3,8 Mal schneller.
Link zur Studie: https://arxiv.org/abs/2605.27358
Das Forschungsteam hat auch eine Skalierungsregel für Edge-MoE-Modelle entwickelt, um die am besten geeignete Modellarchitektur für die Implementierung auf Mobiltelefonen zu bestimmen. MobileMoE hat eine neue Pareto-Frontier für Edge-Large Language Models geschaffen und bessere Ergebnisse bei der Abwägung zwischen Genauigkeit und Rechenaufwand erzielt.
Abbildung | MobileMoE hat eine neue Pareto-Frontier für Edge-Large Language Models geschaffen.
Wie wurde MobileMoE entwickelt?
MobileMoE kann so verstanden werden: Es ist eine Art MoE-Sprachemodell, das für die Edge-Implementierung entwickelt wurde. Insgesamt basiert es immer noch auf einem decoder-only Transformer, aber die ursprünglichen dichten Feedforward-Schichten wurden durch MoE-Schichten ersetzt. Der Router wählt für jedes Token die wenigen Experten mit den höchsten Bewertungen aus, um an der Berechnung teilzunehmen. Außerdem gibt es einen gemeinsamen Experten, der immer an der Berechnung beteiligt ist. Der gesamte Trainingsablauf besteht aus vier Schritten: Prä-Training, Mittelstufe-Training, überwachtes Feintuning und quantisierungsbewusstes Training.
Prä-Training: Das Forschungsteam hat bei einer Kontextlänge von 2048 mit etwa 6T Token an Open-Lizenz-Daten vorgesiebt. Die Daten bestehen hauptsächlich aus Webinhalten und decken auch Bereiche wie Mathematik, Code, Wissen und Wissenschaft ab.
Mittelstufe-Training: Das Forschungsteam hat die Kontextlänge auf 8192 erweitert und den Anteil an hochwertigen Daten wie Wissen, Code, Mathematik und Wissenschaft weiter erhöht. Die Gesamtgröße beträgt etwa 500B Token.
Überwachtes Feintuning (SFT): Das Forschungsteam hat MobileMoE-Base auf über 80 Millionen Open-Lizenz-Befehlsfeintuning-Daten feingestimmt.
Quantisierungsbewusstes Training: Das Forschungsteam hat die linearen Schichten und die Embeddings auf INT4 quantisiert, die Aktivierungen dynamisch auf INT8 und den Router mit FP32-Präzision beibehalten.
Abbildung | Vierstufiges Training von MobileMoE.
Experimentelle Ergebnisse
Ergebnisse der Ablationsstudie
Das Forschungsteam hat zunächst drei Architekturvariablen verglichen: Anzahl der Experten E, Expertengranularität g und die Einbeziehung eines gemeinsamen Experten.
Abbildung | Skalierung der Anzahl der Experten E.
Bei einem festen Speicherbudget beginnt der Verlust von MoE, wenn der Speicher über etwa 0,25 GB liegt, unter dem des entsprechenden dichten Modells. Mit zunehmender Anzahl der Experten E sinkt der Verlust weiter, aber ab E = 8 nimmt der Grenznutzen deutlich ab. Die Experimente zur Expertengranularität g zeigen, dass eine feinere Expertenkonfiguration insgesamt besser ist. Insbesondere g = 8 bietet ein gutes Gleichgewicht zwischen Effektivität und Trainingsaufwand. Wenn g von 8 auf 16 erhöht wird, verbessert sich der Verlust um weniger als 0,01, aber die Trainingsdauer erhöht sich um etwa 50 %. Bei gleichem Rechenbudget sinkt der Modellverlust weiter, wenn ein gemeinsamer Experte hinzugefügt wird.
Basierend auf den Ergebnissen der Ablationsstudie hat das Forschungsteam schließlich die Konfiguration E = 8, g = 8 mit einem gemeinsamen Experten gewählt, d. h. 60 feingranulare Router-Experten, Top-4-Routing und 1 gemeinsamer Experte. Diese Architektur wird für die drei Versionen MobileMoE-S/M/L verwendet.
Abbildung | Skalierung des MoE-Modells unter optimalen Rechenbedingungen.
Abbildung | TrainingsEffizienz der MoE-Architektur.
14 Grundtests: Schaffung einer neuen Edge-Pareto-Frontier
Das Forschungsteam hat MobileMoE in fünf Kategorien von 14 Grundtests, einschließlich Allgemeinwissens-Inferenz, Wissen, Wissenschaft, Lesen und Inferenz, zusammen mit Modellen wie Gemma 3, SmolLM2, Qwen3.5, OLMo 2 und OLMoE-1B-7B unter einheitlichen Bedingungen neu evaluiert.
Abbildung | Prä-Trainingsverlauf von MobileMoE.
Die Vergleichsergebnisse des Base-Modells zeigen, dass der Durchschnittswert von MobileMoE-M höher ist als der von Qwen3.5 2B, und der von MobileMoE-L höher als der von OLMoE-1B-7B, wobei das erforderliche Modellvolumen kleiner ist. Das Forschungsteam hat auch erwähnt, dass der Durchschnittswert der Base-Version von MobileMoE-L bereits höher ist als der der Instruct-Version von OLMoE-1B-7B. In Bezug auf das Trainingsvolumen verwendet MobileMoE etwa 6T Prä-Trainingstoken, weniger als Llama 3.2 1B mit 9T und SmolLM2 1.7B mit 11T. Bei der Gesamtvergleichung der Befehlsfeintuning-Modelle ist die durchschnittliche Genauigkeit von MobileMoE-M bereits nahe an der von OLMoE-1B-7B, aber die aktiven Parameter und die Gesamtparameter sind um etwa 60 % weniger.
Abbildung | Vergleich der MobileMoE-Base-Modelle.
Erweiterte Tests: Stärkeres Leistungsvermögen in Code- und Mathematikaufgaben
In den erweiterten Tests nach dem Befehlsfeintuning hat MobileMoE in Code- und Mathematikaufgaben eine bessere Leistung gezeigt. Am Beispiel von MobileMoE-L ist der Durchschnittswert in beiden Code- und Mathematiktests höher als der von Qwen3.5 2B und OLMoE-1B-7B. Das Forschungsteam hat jedoch auch erwähnt, dass Qwen3.5 2B immer noch stärker in den Fähigkeiten des Befehlsfolgens und des Wissensinferenz ist.
Abbildung | Vergleich der Instruct-Modelle in erweiterten Benchmarks.
Quantisierung und Edge-Implementierung: Noch immer konkurrenzfähig nach INT4, deutliche Beschleunigung auf Mobiltelefonen
Nach der Quantisierung hat sich der Gesamt-Durchschnittswert von MobileMoE-S/M/L im Vergleich zu ihren jeweiligen BF16-Versionen um etwa 2 bis 3 Punkte verringert. Dennoch ist die Leistung der INT4-Version von MobileMoE-L immer noch höher als die der BF16-Version von OLMoE-1B-7B Instruct.
Das Forschungsteam hat MobileMoE auch auf einem Samsung Galaxy S25 und einem iPhone 16 Pro getestet. Die Ergebnisse zeigen, dass MobileMoE-S im Vergleich zu MobileLLM-Pro bei vergleichbaren INT4-Gewichtsspeicherbedingungen im Eingabestadium um 1,8 - 3,8 Mal schneller und im Token-Generierungsstadium um 2,2 - 3,4 Mal schneller ist.
In Bezug auf den Speicherverbrauch beträgt der Spitzen-RSS von MobileMoE-S auf einem Samsung Galaxy S25 unter 8K-Kontext und realen Prompts 1,49 GB, was weniger ist als der von MobileLLM-Pro mit 1,91 GB.
Abbildung | Edge-Laufzeitverzögerung.
Limitierungen und zukünftige Richtungen
Der Befehlsfeintuning MobileMoE liegt derzeit in höheren Befehlsfolgungs- sowie Wissens- und Inferenzfähigkeiten hinter Qwen3.5 2B zurück. Das Forschungsteam glaubt, dass diese Lücke möglicherweise mit umfassenderem Post-Training zusammenhängt. Um diese Lücke in Zukunft zu schließen, muss auf der Trainingsseite Distillation, Post-Training für Inferenz und Multimodal-Expansion verstärkt werden.
Darüber hinaus hat das Forschungsteam darauf hingewiesen, dass der Speicherverbrauch von MoE auf Mobiltelefonen sich je nach Eingabeinhalt ändert. Im Vergleich zu einer festen Vorlageneingabe führt eine reale Eingabe normalerweise zu einem höheren Speicherverbrauch. Wenn nur auf Vorlageneingaben basierende Tests durchgeführt werden, könnte der Speicherdruck in realen Implementierungsszenarien unterschätzt werden. Um in Zukunft die reale Speicherleistung von Edge-MoE genauer zu bewerten, sind weiterhin mehr reale Testdaten erforderlich.
Das Forschungsteam hat bereits systematische Tests auf echten Geräten auf CPU- und GPU-Backends durchgeführt, aber die NPU-Route muss noch erforscht werden. Gleichzeitig ist der Laufzeit-Speicherverbrauch von MoE empfindlich gegenüber der Eingabe. In Zukunft sind dynamisches Routing, Experten-Pruning, gemischte Präzisionsquantisierung und die Implementierung auf mobilen NPUs Richtungen, um die Edge-Effizienz weiter zu verbessern.
Weitere technische Details finden Sie in der Originalstudie.