Muse Spark Open: Was die offenen Gewichte technisch bedeuten

Meta hat am 15. Oktober 2026 die Gewichte von Muse Spark Open veröffentlicht: ein multimodales Mixture-of-Experts-Modell mit 816 Milliarden Parametern, davon 42 Milliarden pro Token aktiv, und einem Kontextfenster von einer Million Token [1][2][3]. Meta nennt es „das leistungsfähigste offene US-Modell bisher“. Dieser Beitrag trennt, was sich aus den Primärquellen belegen lässt (Architekturangaben, Speicherbedarf, Lizenzbedingungen), von dem, was Herstellerangabe bleibt (Benchmarks, Sicherheitswerte), und rechnet einige Zahlen selbst nach.

Was Meta veröffentlicht hat

Die Gewichte liegen auf Hugging Face in zwei Fassungen: BF16 und NVFP4, eine 4-Bit-Variante für NVIDIA-Blackwell-Karten [2][3]. Die Modellkarte nennt Meta Superintelligence Labs als Autor, ein Vokabular von 202.048 Einträgen, Training mit Daten aus mehr als 100 Sprachen sowie Eingaben aus Text, Bild, Video und Audio bei reiner Textausgabe [3]. Zusätzlich gibt es laut Meta eine Sicherheits-Nachtrainingsstufe speziell für die offene Version, weil sie ohne die Schutzmechanismen eines gehosteten Dienstes laufen kann [1][3][5].

Verfügbar ist das Modell über API-Anbieter (Baseten, Fireworks AI, Groq, Modal, Nebius, OpenRouter, Together AI) und als Download über Amazon SageMaker AI, Google Cloud Model Garden, Hugging Face und Microsoft Foundry Models [1]. Es läuft laut Meta unter anderem auf SGLang, vLLM, TensorRT-LLM, Transformers, MLX, llama.cpp und Unsloth [1].

Architektur im Detail

Wie bei jedem MoE-Modell gilt: Gerechnet wird mit etwa 42 Milliarden Parametern pro Token, im Speicher liegen aber alle 256 Experten. Man bekommt also die Rechengeschwindigkeit eines mittelgroßen Modells, braucht aber den Speicher eines sehr großen [2]. Das ist der Kern der Hardwarefrage weiter unten.

Ein Detail mit Folgen für lange Kontexte: Mit 16 Key/Value-Köpfen und Kopfdimension 64 über 62 Schichten speichert jedes Token 2 × 16 × 64 × 62 = 126.976 Werte im KV-Cache. In BF16 sind das rund 254 KB je Token und für eine Million Token etwa 266 GB, was der HF-Blog ebenfalls so angibt [2]. Wir haben die Rechnung nachvollzogen und kommen auf 266,3 GB.

Nachgerechnet: Gehen die Parameterzahlen auf?

Wir haben die Herstellerangaben gegeneinander geprüft. Nimmt man den beschriebenen Expertenaufbau wörtlich (256 Experten je Schicht, jeder mit zwei Matrizen 8192 × 4096, 62 Schichten), ergeben sich 62 × 256 × 67,1 Mio. ≈ 1,07 Billionen Parameter allein für die Experten, deutlich mehr als 816 Milliarden. Diese Lesart passt also nicht.

Es geht anders herum: Aus den drei Zahlen, die Meta selbst nennt (816 Mrd. gesamt, 42 Mrd. aktiv, 8 von 256 Experten je Token), lässt sich die Aufteilung ausrechnen. Mit x für die Parameter außerhalb der Experten und e für die Expertenparameter gilt x + e = 816 und x + e × 8/256 = 42. Daraus folgt e ≈ 799 Mrd. und x ≈ 17 Mrd., also ein Expertenanteil von etwa 97,9 Prozent. Das stimmt mit der Angabe „etwa 97 Prozent“ im Hugging-Face-Blog überein [2]. Die drei Zahlen sind also untereinander stimmig.

Teilt man 799 Mrd. durch 62 Schichten und 256 Experten, kommt man auf rund 50,3 Mio. Parameter je Expert. Das entspricht genau 8192 × 3072 × 2 oder drei Matrizen der Größe 8192 × 2048 (3 × 8192 × 2048 = 50,33 Mio.), wie sie ein gated Feed-Forward-Netz hätte. Mit diesem Wert ergeben sich 798,9 Mrd. für alle Experten und 25,0 Mrd. für die acht aktiven je Token. Zusammen mit den 17 Mrd. übrigen Parametern sind das 42,0 Mrd. aktiv. Der im HF-Blog genannte Pfad 8192 → 4096 → 8192 liegt dagegen nicht auf dieser Linie. Wir vermuten daher, dass die Beschreibung vereinfacht ist. Das ist eine Hypothese, die die Zahlen stützen, aber keine Bestätigung: Die Konfigurationsdatei (config.json), die es klären würde, war für uns nicht abrufbar (Zugriff nur nach Zustimmung zur Lizenz).

Bleibt eine kleine Differenz: Matrizen für Ein- und Ausgabe (3,3 Mrd.) und Attention (9,4 Mrd.) ergeben 12,7 Mrd., die Rechnung verlangt 17 Mrd. Rund 4 Mrd. erklären wir nicht, möglich wären Router, Gates, Normierungen oder ähnliches. Der Anbieter Baseten nennt zudem einen „komprimierten MoE-Block“, „hybride globale/lokale Attention“ und 42,7 Mrd. aktive Parameter [6], was in den anderen Quellen nicht steht. Wir halten fest: Die Gesamtzahlen sind Herstellerangaben, unsere Rechnung ist eine Plausibilitätsprüfung mit vereinfachten Annahmen.

Hardware: Was läuft wo?

Die Modellkarte nennt für den Betrieb auf eigener Hardware mindestens 700 GB GPU-Speicher für NVFP4 und 2 TB für BF16 [3]. Das passt zu einer Überschlagsrechnung: 816 Mrd. Parameter × 0,5 Byte ≈ 408 GB für die 4-Bit-Gewichte, plus 266 GB KV-Cache bei vollem Kontext, ergibt etwa 674 GB. In BF16 sind es 1,63 TB Gewichte plus der Cache, also rund 1,9 TB. Beide Werte liegen knapp unter den Herstellerangaben, wie man es mit Aktivierungen und Overhead erwartet. Die Rechnung ist grob (Skalierungsfaktoren der Quantisierung und Overhead sind nicht eingerechnet).

• Gewichte (816 Mrd. Parameter)
• KV-Cache, 1 Mio. Token, BF16
• Mindestangabe Modellkarte

Daten als Tabelle

	Gewichte (816 Mrd. Parameter)	KV-Cache, 1 Mio. Token, BF16	Mindestangabe Modellkarte
NVFP4	408 GB	266 GB	700 GB
BF16	1632 GB	266 GB	2000 GB

Quelle: Eigene Rechnung; Angaben der Modellkarte [3]

Eigene Überschlagsrechnung (Gewichte ohne Skalierungsfaktoren) gegen die Mindestangabe der Modellkarte, in Gigabyte.

• Rechenzentrum: Der HF-Blog nennt für BF16 vier Knoten mit je 8 H200-GPUs (Tensor-Parallelität 32) und für NVFP4 einen einzelnen B200-Knoten; ein vorgetesteter Inference-Endpoint läuft mit NVFP4 auf 8 × RTX Pro 6000 (98 GB) bei 131.072 Token Kontext oder auf 8 × H200 (141 GB) bei der vollen Million [2].
• Apple-Desktop: Meta nennt zwei Mac Studios mit M5 Ultra (je bis 512 GB, zusammen ein Terabyte einheitlicher Speicher) mit MLX, ohne Geschwindigkeitsangabe [1]. Hugging Face testete eine 3-Bit-Quantisierung (oQ3e, etwa 344 GB) auf einem M3 Ultra mit 512 GB: rund 225 Token pro Sekunde beim Einlesen und 21 Token pro Sekunde beim Erzeugen, gemessen mit einem Prompt von 1.024 Token und 128 erzeugten Token [2]. Das ist ein sehr kurzer Test, er sagt nichts über lange Kontexte.
• Eigene Überschlagsrechnung dazu: Neben 344 GB Gewichten bleiben auf 512 GB höchstens etwa 168 GB. Bei 254 KB je Token im BF16-KV-Cache reichen sie rechnerisch für rund 660.000 Token, bevor Betriebssystem und Aktivierungen etwas abziehen. Die volle Million Token würde dort also nicht in BF16 hineinpassen. Mit einem quantisierten Cache sähe das anders aus; dazu haben wir keine Angaben gefunden.

• KV-Cache (BF16)
• Frei neben 344-GB-Quant auf 512 GB

Daten als Tabelle

Kontextlänge in Token	KV-Cache (BF16)	Frei neben 344-GB-Quant auf 512 GB
64k	16,6 GB	168 GB
128k	33,3 GB	168 GB
256k	66,6 GB	168 GB
512k	133,1 GB	168 GB
1 Mio.	266,3 GB	168 GB

Quelle: Eigene Rechnung nach den Architekturangaben in [2][3]

Eigene Rechnung: 126.976 Werte je Token × 2 Byte, in Gigabyte (dezimal).

Für Geschwindigkeit gilt eine einfache Obergrenze (eigene, stark idealisierte Rechnung): Beim Erzeugen eines Tokens müssen die Gewichte der aktiven Experten einmal aus dem Speicher gelesen werden. Bei 4 Bit sind das 42 Mrd. × 0,5 Byte ≈ 21 GB. Bei den von Meta genannten 1,2 TB/s Speicherbandbreite des M5 Ultra ergibt das höchstens etwa 57 Token pro Sekunde, wenn nur diese Gewichte gelesen werden und nichts anderes bremst (Attention-Cache, Verteilung auf zwei Maschinen, Rechenzeit). Das ist eine Decke, keine Erwartung. Für die gemessenen 21 Token pro Sekunde auf dem M3 Ultra gilt: Die Bandbreite dieses Chips steht in unseren Quellen nicht, ein Vergleich mit der Decke wäre deshalb Spekulation.

Wer kleiner anfangen will: Für lokale Nutzung lohnt der Vergleich in Lokale Modelle: Wann sich der eigene Rechner lohnt. Muse Spark Open ist kein Gerät für den Laptop, sondern für Workstation-Cluster oder gemietete Rechenzeit.

Software-Stack: Was heute läuft

Laut Hugging-Face-Blog gibt es mehrere Wege, das Modell zu betreiben [2]:

• Transformers: Eine eigene Implementierung (MuseSparkForConditionalGeneration) mit Prozessor für Text, Bild, Video und Audio. Für die Verteilung wird Tensor- und Expertenparallelität über eine DistributedConfig gesetzt.
• SGLang: Unterstützt Text, Bild, Audio und Video. Die NVFP4-Referenzkonfiguration läuft auf vier GB300-GPUs.
• vLLM: Die Referenzintegration unterstützt Text und Bild mit der NVFP4-Fassung und verlangt Blackwell-GPUs. Audio und Video fehlen dort laut Blog.
• MLX und llama.cpp: MLX über oMLX und mlx-lm mit 3- und 4-Bit-Quantisierungen; für llama.cpp nennt der Blog ein 2-Bit-Beispiel, das auf einem Mac Ultra rund 18 Token pro Sekunde erreicht. Wegen der starken Quantisierung brauche es mehr Steuerung beim Prompten.
• Inference Endpoints: Ein vorab geprüftes SGLang-Rezept für die NVFP4-Fassung.

Praktisch wichtig: Die Fähigkeiten hängen am gewählten Stack. Wer Audio oder Video braucht, kommt laut Blog mit der vLLM-Referenz nicht aus. Ausgaben trennen Denkprotokoll (reasoning_content) und Antwort (content), was für Anwendungen relevant ist, die kein rohes Denkprotokoll anzeigen sollen [2]. Die Modellkarte rät ausdrücklich davon ab, das rohe Denkprotokoll Endnutzern zu zeigen [3].

Kernel-Optimierung: Was „3,95-fach schneller“ bedeutet

Meta und die PyTorch Foundation nennen für die mitgelieferten Helion-Kernel Beschleunigungen von 1,03 bis 3,95 Mal gegenüber hardwarespezifisch geschriebenen Kernen (etwa CUDA) auf NVIDIA GB300. Auf AMD MI350 seien dieselben Kernel portierbar gewesen und brächten insgesamt 3 Prozent mehr Durchsatz von Anfang bis Ende [1][5]. Die Kernel betreffen Operationen wie RoPE, RMSNorm und Quantisierung; zusätzlich gibt es in SGLang zusammengeführte „Megakernel“ [5].

Die Zahlen zeigen zwei Dinge. Erstens betrifft ein Kernel-Speedup nur einen Teil der Laufzeit. Eine 3,95-fache Beschleunigung einer Operation, die einen kleinen Anteil der Zeit ausmacht, ändert den Gesamtdurchsatz kaum, wie die 3 Prozent bei AMD zeigen. Zweitens ist die Spanne 1,03 bis 3,95 breit; die Quellen nennen nicht, welcher Kernel welchen Wert erreicht. Wer diese Zahlen für die eigene Planung braucht, sollte also den End-to-End-Durchsatz mit der eigenen Last messen.

Denkaufwand: ein Parameter mit Kostenfolgen

Muse Spark Open denkt immer. Das „Reasoning Effort“ lässt sich auf low, medium, high oder xhigh stellen (intern 16, 64, 256 und 512), ausschalten lässt sich das Denken nicht, und der Standard ist xhigh [2][3]. Die Modellkarte empfiehlt high oder xhigh für komplexe Aufgaben und Coding, und Muse Spark Open läuft laut Karte in allen Benchmarks mit xhigh [3]. Für die Praxis heißt das: Die veröffentlichten Werte gehören zur teuersten Einstellung. Wie viele Token die Benchmarks dabei verbrauchten und was ein Lauf kostet, nennen die gelesenen Quellen nicht. Dass der Tokenverbrauch ein eigenes Messproblem ist, zeigt unsere Analyse zu Long-Horizon-Terminal-Bench 2.0.

Benchmarks: Herstellerangaben, gemischte Bilanz

Die Modellkarte vergleicht Muse Spark Open mit sieben offenen Modellen ähnlicher Größe: Inkling, Nemotron 3 Ultra, Beam, Mistral Large 4, Qwen3.8-2.4T-A95B, GLM 5.3 und Kimi K3 [3]. Alle Werte stammen von Meta. Eine unabhängige Nachprüfung haben wir nicht gefunden, und bei den Coding-Tests steht „Preferred harness“, also der jeweils bevorzugte Agentenaufbau, nicht ein einheitlicher.

Zählt man alle 20 Fähigkeitszeilen der Tabelle (ohne die beiden Sicherheitstests), liegt Muse Spark Open bei 7 vorn: JobBench, MCP-Atlas, HLE-Diamond, AA Omniscience, ZeroBench, SimpleVQA und IntPhys2. Bei den übrigen 13 liegt mindestens ein anderes Modell der Tabelle vorn. In mehreren Zeilen sind nur zwei Vergleichswerte angegeben, und bei einigen fehlt Beam ganz. Beam liegt bei GPQA Diamond (90,5 gegen 89,0) und Terminal-Bench 2.1 (80,1 gegen 76,4) vor Muse Spark Open. Die Zählung ist unsere eigene und setzt voraus, dass die Zahlen der Karte stimmen.

Intelligence Index (AA)-6 P.

JobBench0,4 P.

MCP-Atlas4,7 P.

OSWorld Verified-4,4 P.

Toolathlon Verified-3,7 P.

HLE-Diamond (ohne Werkzeuge)3,9 P.

AA Omniscience5 P.

SciCode-1 P.

HLE (mit Werkzeugen)-1,5 P.

GPQA Diamond-4,5 P.

DeepSWE 1.1-8 P.

SWE-Atlas-QnA-8 P.

Terminal-Bench 2.1-8,6 P.

ZeroBench9 P.

BabyVision-5,5 P.

SimpleVQA1,7 P.

WorldVQA-1,6 P.

IntPhys28 P.

VideoMMEv2-3,9 P.

Daten als Tabelle

	Differenz in Punkten
Intelligence Index (AA)	-6 P.
JobBench	0,4 P.
MCP-Atlas	4,7 P.
OSWorld Verified	-4,4 P.
Toolathlon Verified	-3,7 P.
HLE-Diamond (ohne Werkzeuge)	3,9 P.
AA Omniscience	5 P.
SciCode	-1 P.
HLE (mit Werkzeugen)	-1,5 P.
GPQA Diamond	-4,5 P.
DeepSWE 1.1	-8 P.
SWE-Atlas-QnA	-8 P.
Terminal-Bench 2.1	-8,6 P.
ZeroBench	9 P.
BabyVision	-5,5 P.
SimpleVQA	1,7 P.
WorldVQA	-1,6 P.
IntPhys2	8 P.
VideoMMEv2	-3,9 P.

Quelle: Eigene Rechnung nach Benchmark-Tabelle der Modellkarte [3] (Herstellerangaben)

Muse Spark Open minus bester anderer Wert in Metas Tabelle, in Punkten; positiv heißt vorn. GDPVal-AA (Elo-Skala) fehlt.

Die Differenzen sind nicht über Tests hinweg vergleichbar, weil die Skalen verschieden sind (ein Punkt bei GPQA ist nicht ein Punkt bei Terminal-Bench). Das Bild ist gemischt: Bei MCP-Atlas liegt Muse Spark Open vorn, bei OSWorld Verified und Toolathlon dagegen hinter Kimi K3; ein einheitliches „agentisch stark“ lässt sich daraus nicht ablesen. Am deutlichsten zurück liegt es bei Terminal- und Coding-Aufgaben (Terminal-Bench 2.1, DeepSWE, SWE-Atlas) mit 8 bis fast 9 Punkten. Die Zeile Terminal-Bench 2.1 nutzt wie unser Beitrag zu Long-Horizon-Terminal-Bench 2.0 das Terminus-2-Harness; die Werte lassen sich trotzdem nicht mit denen aus jenem Paper vergleichen, weil Aufgaben und Zeitbudgets verschieden sind.

Was das für die Aussage „leistungsfähigstes offenes US-Modell“ heißt: Die Tabelle erlaubt es nicht, diesen Titel zu prüfen. Sie enthält wenige Vergleichsmodelle mit durchgehenden Werten, und die Herkunftsländer der Modelle sind nicht Teil der Tabelle. Das Profil ist eher: vorn bei MCP-Atlas, bei Wissensfragen (HLE-Diamond, AA Omniscience) und einigen Multimodal-Tests, hinter den Kimi-, GLM- und Qwen-Modellen der Tabelle bei Terminal- und Coding-Tests sowie beim breiten Intelligenz-Index.

Sicherheitsangaben: auffällig, aber nur von Meta

Meta bewertet vier Bereiche: Inhaltssicherheit, agentische Risiken, Privatsphäre und „Preparedness“ (Chemie/Biologie, Cyber, Kontrollverlust) [3]. Genannt werden unter anderem: 99,2 % abgewehrte Jailbreaks im internen Cyber-Test und 94,8 % über drei öffentliche Cyber-Tests aggregiert (Kimi K3 im selben Aufbau 75,5 % und 70,2 %), mehr als 98 % Ablehnung schädlicher Anfragen im BioTIER-Test von SecureBio, 98,1 % Ehrlichkeitsrate im MASK-Benchmark und 0 % Fehlverhalten im Agentic-Misalignment-Test [3].

Muse Spark Open0,5

Inkling86,4

Nemotron 3 Ultra80,7

Qwen3.8-2.4T65,6

GLM 5.362,9

Kimi K366,6

Daten als Tabelle

	StrongREJECT v2
Muse Spark Open	0,5
Inkling	86,4
Nemotron 3 Ultra	80,7
Qwen3.8-2.4T	65,6
GLM 5.3	62,9
Kimi K3	66,6

Quelle: Modellkarte Muse Spark Open [3] (Herstellerangabe, nicht unabhängig geprüft)

StrongREJECT v2 mit adaptiven Angriffen, Herstellerangaben aus der Modellkarte.

Zwei Tabellenzeilen fallen auf. Im adaptiven StrongREJECT-v2-Test (niedriger ist besser) steht für Muse Spark Open 0,5, für die anderen Modelle 62,9 bis 86,4. Im statischen FORTRESS-Test hat Muse Spark Open den niedrigsten ARS-Wert (5,8 gegen 21,6 bis 28,2) und zugleich den höchsten ORS-Wert (17,4 gegen 2,7 bis 13,3) [3]. Die Abkürzungen erklärt der abgerufene Text nicht. Sollte ORS Überablehnung messen, was naheliegt, deutet das auf einen Zielkonflikt zwischen Schutz und Nutzbarkeit hin. Das ist eine Vermutung, keine Aussage der Quelle. So große Abstände wie bei StrongREJECT sind außergewöhnlich und brauchen Gegenprüfung durch Dritte, bevor man sie als Eigenschaft des Modells annimmt. Meta schränkt selbst ein: Die Tests gelten für den veröffentlichten Checkpoint unter den getesteten Bedingungen; Veränderungen wie Feintuning können die Sicherheit verschlechtern [3].

Lizenz: offen, aber mit Bedingungen

Die Gewichte stehen unter der „Muse Model License“. Aus dem abgerufenen Lizenztext (die Bedingung 1 war darin nicht sichtbar) ergibt sich [3]:

• Erlaubt sind Nutzung, Kopie, Änderung (auch Feintuning), Ableitungen, Destillation, Zusammenführung, Veröffentlichung, Weitergabe und Verkauf, vorbehaltlich der Bedingungen.
• Bedingung 2: „Built with Muse Spark Open“ muss in Produkten oder Dokumentation sichtbar genannt werden, auch bei Ableitungen, zu denen Modelle zählen, die mit Hilfe der Ausgaben trainiert wurden.
• Bedingung 3: Wer Modelle als Dienst über eine Schnittstelle anbietet und zusammen mit verbundenen Unternehmen mehr als 20 Millionen US-Dollar Bruttoumsatz in zwölf Monaten erzielt, muss Meta benachrichtigen und eine gesonderte schriftliche Vereinbarung schließen. Ausgenommen sind interne Nutzung, Forschung und eigene Produktfunktionen, die kein „Model as a Service“ sind.
• Meta erhebt keinen Eigentumsanspruch auf Ausgaben des Modells (Bedingung 4). Haftung und Gewährleistung sind ausgeschlossen.
• Eine Nutzungsrichtlinie verbietet unter anderem Gesetzesverstöße, Desinformation und Betrug sowie militärische und nukleare Anwendungen. Das Modell ist nicht für Personen unter 18 vorgesehen [3].

Ob diese Lizenz nach der Open-Source-Definition als Open Source gilt, haben wir nicht geprüft. Meta selbst spricht von „Open Weights“ und von „limitierten kommerziellen Bedingungen“ [1]. Für Unternehmen mit Dienstangebot ist vor allem Bedingung 3 relevant. Wir sind keine Rechtsberatung: Für den kommerziellen Einsatz sollte der Originaltext von jemandem gelesen werden, der ihn bewerten darf.

Training und Feintuning

Die Modellkarte nennt als Trainingsdaten Text, Bilder, Audio und Video aus öffentlichen Quellen, Internet-Crawls, zugekauften Daten, Metas Produkten sowie synthetischen und von Vendor-Netzwerken aufbereiteten Daten [3]. Dateninhalte werden nicht aufgelistet.

Zum Feintuning zeigt der HF-Blog ein Beispiel: 500 Schritte in rund zwei Stunden auf 64 H100-GPUs bei etwa 8.000 Token pro Sekunde, wobei die mittlere Token-Genauigkeit von 72 % auf 84 % stieg und der Loss von 1,26 auf 0,57 fiel [2]. Das sind Trainingskennzahlen auf dem Datensatz des Beispiels. Sie belegen einen funktionierenden Lauf, nicht bessere Antworten in der Praxis.

Einordnung: Was belegt ist, was offen bleibt

Belegt (durch Herstellerdokumente)

• Gewichte sind in BF16 und NVFP4 verfügbar; 816 Mrd. Parameter, 42 Mrd. aktiv, 1 Mio. Token Kontext, Eingabe Text/Bild/Audio/Video.
• Der Speicherbedarf liegt laut Karte bei mindestens 700 GB (NVFP4) bzw. 2 TB (BF16); unsere Überschlagsrechnung stützt das.
• Die Lizenz enthält Namensnennung, eine Umsatzschwelle für Modell-als-Dienst-Angebote und eine Nutzungsrichtlinie.

Offen oder nur Herstellerangabe

• Alle Benchmark- und Sicherheitswerte stammen von Meta. Der Evaluationsbericht, auf den Blog und Modellkarte verweisen, war für uns nicht einsehbar.
• Die Parameterbilanz geht aus den veröffentlichten Beschreibungen nicht sauber auf (siehe oben); die Konfigurationsdatei war nicht abrufbar.
• Tokenverbrauch und Kosten bei xhigh sind in den Quellen nicht angegeben.
• Wir haben das Modell nicht selbst ausgeführt und keine eigenen Tests gemacht.

Prüfplan: Was man unabhängig nachmessen sollte

Aus den offenen Punkten ergibt sich, was eine unabhängige Prüfung klären müsste. Das ist unsere Einordnung, keine Quelle:

1. Parameterbilanz: Die config.json lesen und Expertenbreite, Zahl der MoE-Schichten und Gates mit unserer Hypothese vergleichen.
2. Benchmarks mit einheitlichem Harness: Dieselben Tests mit demselben Agentenaufbau für alle Modelle laufen lassen; Metas Tabelle nutzt bei Coding-Tests den „Preferred harness“.
3. Denkaufwand und Kosten: Den Tokenverbrauch je Aufgabe bei low, medium, high und xhigh messen, nicht nur die Genauigkeit.
4. Quantisierung: NVFP4 und die 3-Bit-Fassung gegen BF16 auf eigenen Aufgaben testen; die Karte spricht selbst von „kleinen Qualitätsunterschieden“ in Randfällen.
5. Sicherheit: Die StrongREJECT- und FORTRESS-Werte mit externen Red-Teams wiederholen, vor allem nach Feintuning.

Methode dieser Analyse

Quellen sind die sechs genannten Seiten, abgerufen am 18. Oktober 2026. Eigene Rechnungen folgen diesen Formeln:

• KV-Cache je Token = 2 (Key und Value) × 16 Köpfe × 64 Dimensionen × 62 Schichten × 2 Byte (BF16) = 253.952 Byte.
• Gewichtsspeicher = 816 Mrd. × 0,5 Byte (4 Bit) bzw. × 2 Byte (BF16), ohne Skalierungsfaktoren der Quantisierung.
• Parameterbilanz: Lösung des Gleichungspaars x + e = 816 und x + e × 8/256 = 42 (in Mrd.).
• Bandbreitengrenze = Speicherbandbreite ÷ (aktive Parameter × Bytes je Parameter).
• Benchmark-Differenz = Wert von Muse Spark Open minus höchster Wert der übrigen Modelle derselben Zeile; Zählung der 7 von 20 über alle Zeilen mit höher-ist-besser-Skala.

Wir haben das Modell nicht ausgeführt, keine Benchmarks wiederholt und keine Lizenzprüfung durchgeführt. Die Diagramme entstehen aus den genannten Zahlen und stehen jeweils mit Datentabelle im Beitrag.

Glossar

• Mixture of Experts (MoE): Architektur, bei der pro Token nur ein Teil der Teilnetze („Experten“) rechnet.
• Aktive Parameter: Die Parameter, die pro Token tatsächlich in die Rechnung eingehen.
• KV-Cache: Zwischenspeicher der Aufmerksamkeitsschicht, der mit der Kontextlänge wächst.
• NVFP4: 4-Bit-Zahlenformat für NVIDIA-Blackwell-GPUs, das den Speicherbedarf der Gewichte etwa auf ein Viertel von BF16 senkt.
• Open Weights: Veröffentlichte Modellgewichte, die nicht zwingend eine offene Lizenz im Sinne von Open Source bedeuten.
• Reasoning Effort: Stellgröße, wie viel das Modell vor der Antwort „nachdenkt“.
• Expertenparallelität: Verteilung der Experten auf mehrere GPUs, sodass jede nur einen Teil hält.
• Tensorparallelität: Aufteilung einzelner Matrizen auf mehrere GPUs.
• Kernel: Kleines GPU-Programm für eine einzelne Operation, etwa eine Normierung.
• Quantisierung: Speichern von Gewichten mit weniger Bits, um Speicher zu sparen, meist mit kleinen Qualitätsverlusten.

Methode

Grundlage sind die sechs genannten Quellen, die wir am 18. Oktober 2026 abgerufen haben. Rechenschritte (KV-Cache, Speicher, Parameterbilanz, Zählung der Benchmark-Zeilen) sind eigene Überschlagsrechnungen und im Text gekennzeichnet. Wir haben das Modell nicht ausgeführt. Der Text entstand mit KI-Unterstützung und wurde von der Redaktion verantwortet.

Grenzen

Alle Benchmark- und Sicherheitswerte sind Herstellerangaben; config.json war nicht abrufbar, die Expertenbreite ist eine Hypothese; Evaluationsbericht nicht eingesehen; Lizenzbedingung 1 im abgerufenen Text nicht sichtbar; keine eigenen Tests.

Quellen

1. Introducing Muse Spark Open, The Most Capable US Open-Weight Model to Date, Meta AI Research (abgerufen 2026-10-18)
2. Welcome Muse Spark Open: open-weight frontier multimodal mixture-of-experts model from Meta, Hugging Face (Pedro Cuenca) (abgerufen 2026-10-18)
3. meta-models/Muse-Spark-Open-816B-A42B: Muse Model License und Model Card, Hugging Face / Meta (abgerufen 2026-10-18)
4. Muse Spark Open (Collection), Hugging Face / meta-models (abgerufen 2026-10-18)
5. Muse Spark Is Now an Open-Weights Model, PyTorch Foundation (abgerufen 2026-10-18)
6. Muse Spark Open, an open-weight model for coding agents, Baseten (abgerufen 2026-10-18)