Meta veröffentlicht Muse Spark Open mit 816 Milliarden Parametern

Multimodalität mit Text als gemeinsamer Ausgabe

Das Modell nimmt Text, Bilder, Audio und Video entgegen und erzeugt nach der Modellübersicht Text. Ein gemeinsamer Eingabepfad kann beispielsweise Code mit Screenshots, gesprochenen Hinweisen oder einer Bildschirmaufnahme verbinden. Der Veröffentlichungsbeitrag beschreibt diese Kombination als Grundlage für Entwicklungsaufgaben, bei denen ein Agent einen Codebestand bearbeitet und zugleich visuelle oder akustische Informationen auswertet. Das belegt die vorgesehene Nutzung, nicht automatisch eine bestimmte Zuverlässigkeit bei realen Projekten. [1]

Bilder und Videoframes laufen über einen Wahrnehmungsencoder, der Bildinhalte in Tokens für das Sprachmodell überführt. Für Audio ist ein eigener Encoder vorgesehen. Laut Beitrag erzeugt dieser 12,5 Audiotokens pro Sekunde; ein zehnsekündiger Audioclip entspricht damit rechnerisch 125 Tokens. Der Prozessor erwartet für direkt übergebene Audiodaten Mono-Audio mit 24 kHz und kann Audio aus Videos gemeinsam mit den Videoframes verarbeiten. [1]

Für Video setzt die beschriebene Standardverarbeitung auf zwei Bilder pro Sekunde und begrenzt die Zahl der Frames auf 96. Teams können die Bildrate anpassen: Eine höhere Abtastrate kann mehr zeitliche Details erhalten, erhöht laut Beitrag aber Speicherbedarf und Vorverarbeitungs-Latenz. Für Anwendungsfälle wie die Erkennung kurzer Ereignisse in Aufzeichnungen ist dieser Parameter daher eine operative Abwägung und keine rein kosmetische Einstellung. [1]

Millionen-Kontext: nützlich, aber speicherintensiv

Muse Spark Open unterstützt laut Beitrag ein Kontextfenster von bis zu einer Million Tokens. Darin können Text- und Multimodal-Tokens gemeinsam verarbeitet werden. Die Obergrenze erweitert die Möglichkeit, längere Codebasen, Dokumente oder Gesprächsverläufe in einer Anfrage zu berücksichtigen. Sie sagt für sich genommen aber nicht aus, wie schnell, kostengünstig oder zuverlässig ein konkreter Prozess über die gesamte Länge läuft. [1]

Ein wesentlicher technischer Kostenpunkt ist der Key-Value-Cache (KV-Cache), in dem Aufmerksamkeitsinformationen während der Verarbeitung vorgehalten werden. Der Beitrag rechnet in BF16 mit rund 250 Kilobyte zusätzlichem Cache pro Token und etwa 266 Gigabyte bei voller Million-Tokens-Länge. Das ist eine Größenordnung, die bei der Infrastrukturplanung neben den Modellgewichten berücksichtigt werden muss; die veröffentlichten Zahlen sind keine vollständige Kapazitätsplanung für einen produktiven Dienst. [1]

Als Maßnahme zur Begrenzung des Cache-Bedarfs nennt der Beitrag gruppierte Query-Aufmerksamkeit mit 16 Key-Value-Köpfen. Für Unternehmen bedeutet das analytisch: Ein sehr großer Kontext kann Arbeitsschritte über viele Dateien oder Eingaben erleichtern, ersetzt aber keine Tests mit realistischen Kontextlängen und gleichzeitigen Anfragen. Die mögliche Reduktion wiederholter Kontextübergaben ist gegen Speicherbelegung und Antwortzeit abzuwägen. [1]

Betrieb: erhebliche Hardwareanforderungen und mehrere Laufzeitpfade

Der Beitrag beschreibt für die BF16-Ausführung mit Transformers einen verteilten Betrieb über vier Knoten mit jeweils acht H200-GPUs und Tensor-Parallelität über 32 Geräte. Für die NVFP4-Ausführung nennt er in diesem Zusammenhang einen einzelnen B200-Knoten. Daneben führt die SGLang-Referenzkonfiguration NVFP4-Betrieb auf vier GB300-GPUs an. Das sind veröffentlichte Konfigurationen für konkrete Integrationen, keine allgemeingültige Mindestanforderung oder ein vollständiger Leistungsvergleich der Frameworks. [1]

Die dokumentierten Integrationen decken unterschiedliche Funktionsumfänge ab. Transformers stellt laut Beitrag eine multimodale Schnittstelle für Textgenerierung aus verschiedenen Eingaben bereit. Die SGLang-Integration wird für Text, Bild, Audio und Video beschrieben. Die vLLM-Referenzintegration unterstützt demnach NVFP4 sowie Text- und Bildeingaben und setzt Blackwell-GPUs voraus. Wer Video- oder Audioverarbeitung benötigt, sollte daher nicht nur den Checkpoint, sondern auch den konkreten Laufzeitpfad und dessen dokumentierte Modalitätsunterstützung prüfen. [1]

Für llama.cpp beschreibt der Beitrag quantisierte Fassungen und nennt Tests auf einem Mac M3 Ultra mit 512 Gigabyte Arbeitsspeicher. Eine kalibrierte 2-Bit-Quantisierung habe dort 18 Tokens pro Sekunde erreicht und rund 304 Gigabyte für das Modell belegt. Diese Werte stammen aus dem Veröffentlichungsbeitrag; sie sind nicht als unabhängig reproduzierte Benchmarkdaten ausgewiesen und erlauben keine direkte Hochrechnung auf andere Geräte, Eingabelängen oder Lastprofile. [1]

Für die betriebliche Entscheidung ergeben sich damit zwei getrennte Fragen: Welcher Qualitäts- und Quantisierungsstand ist für die Anwendung ausreichend, und welche Hardware kann die vollständigen Gewichte samt Kontext- und Laufzeitbedarf tragen? Die aktive Parameterzahl allein beantwortet die zweite Frage nicht, weil die Expertengewichte und der KV-Cache zusätzlich im Speicher berücksichtigt werden müssen. [1]

Agentische Coding-Aufgaben und Werkzeugaufrufe

Meta beschreibt Muse Spark Open als auf reale Entwicklerabläufe trainiert, darunter Änderungen über mehrere Dateien und längere Debugging-Sitzungen. Das Modell soll Aufgaben schrittweise planen, Werkzeuge aufrufen, Ergebnisse beobachten und bei Bedarf nachsteuern. Die Anleitung zeigt außerdem, wie Entwickler Funktionswerkzeuge angeben und Modellantworten als Werkzeugaufrufe verarbeiten können. Diese Angaben erläutern das Design und die Schnittstelle, liefern aber keine Messwerte für erfolgreiche autonome Softwareänderungen. [1]

Die Vorgängerankündigung ordnet diese Ausrichtung ein: Meta hatte für das im April vorgestellte Muse Spark noch Leistungsabstände bei Coding und lang laufenden agentischen Systemen genannt. Der neue Release setzt inhaltlich genau bei solchen Arbeitsformen an. Ohne unabhängige Benchmarks oder dokumentierte Ergebnisse aus produktiven Einsätzen bleibt offen, wie stark Muse Spark Open diese früher benannten Lücken tatsächlich schließt. [1] [2]

Für Unternehmen ist außerdem relevant, dass Werkzeugaufrufe nicht gleichbedeutend mit sicherer Ausführung sind. Das Modell kann strukturierte Aufrufe erzeugen; die Anwendung muss jedoch weiterhin Berechtigungen, Eingaben, Fehlerbehandlung und Freigaben kontrollieren. Diese Einordnung folgt aus der im Beitrag beschriebenen Tool-Calling-Schnittstelle: Ein Modellaufruf wird erst durch die umgebende Software in eine Aktion übersetzt. [1]

Reasoning lässt sich abstufen, aber nicht abschalten

Die Anleitung sieht vier symbolische Stufen für den Reasoning-Aufwand vor: niedrig, mittel, hoch und sehr hoch. Sie werden laut Beitrag auf interne Werte von 16, 64, 256 beziehungsweise 512 abgebildet. Ein vollständiges Abschalten des Reasonings ist demnach nicht möglich; für einfachere Aufgaben empfiehlt der Beitrag die niedrige Stufe, um weniger Tokens zu verbrauchen. [1]

Das hat Folgen für Kosten- und Latenzmodelle: Teams können den Aufwand an die erwartete Schwierigkeit anpassen, aber nicht auf einen vollständig reasoningfreien Betriebsmodus wechseln. Die tatsächliche Tokenzahl hängt weiterhin von Aufgabe und Ausgabe ab. Ein sinnvoller Einsatz erfordert daher Messungen mit repräsentativen Prompts und eine Prüfung, ob eine höhere Stufe bei den eigenen Aufgaben einen ausreichenden Qualitätsgewinn erzielt. Der Quelltext nennt keine allgemeingültigen Kostensätze oder Leistungswerte für diese Abstufungen. [1]

Leistungsanspruch und offene Fragen für die Evaluation

Der Hugging-Face-Beitrag ordnet Muse Spark Open als besonders leistungsfähiges offenes Gewichtsmodell ein. Zugleich enthält der vorliegende Text keine systematische Benchmarktabelle, keine unabhängigen Ergebnisse und keinen Vergleich, der die Spitzenposition überprüfbar belegt. Die Aussage sollte deshalb als Charakterisierung des Veröffentlichungsbeitrags gelesen werden, nicht als unabhängig bestätigter Leistungsbefund. [1]

Meta hatte für das ursprüngliche Muse Spark im April Benchmarkwerte zu ausgewählten Aufgaben veröffentlicht und dabei eine eigene Methodik angekündigt. Diese Ergebnisse beziehen sich auf das damals vorgestellte Modell und sind kein Ersatz für eine Evaluation von Muse Spark Open. Ebenso wenig belegen sie, wie sich die neue Variante bei Coding, Multimodalität oder Werkzeugnutzung gegenüber anderen aktuell verfügbaren Modellen schlägt. [2] [1]

Für eine B2B-Einführung sollten deshalb unternehmenseigene Tests im Mittelpunkt stehen: relevante Codebasen und Dokumente, tatsächlich genutzte Modalitäten, zulässige Fehlerraten, Kontextgrößen sowie Verhalten bei Werkzeugaufrufen. Das ist eine aus den veröffentlichten Eigenschaften abgeleitete Evaluationspriorität, kein berichtetes Testergebnis. Die technische Offenheit der Gewichte erweitert die Optionen für eigene Bereitstellung und Anpassung; sie nimmt Unternehmen weder die Prüfung von Lizenzbedingungen noch die Verantwortung für sichere Integration und laufende Qualitätskontrolle ab. [1]

Quellen

1. [1] Welcome Muse Spark Open: open-weight frontier multimodal mixture-of-experts model from Meta — https://huggingface.co/blog/meta-muse-spark-open (abgerufen am 2026-10-15)
2. [2] Introducing Muse Spark: Scaling Towards Personal Superintelligence — https://ai.meta.com/blog/introducing-muse-spark-msl (abgerufen am 2026-10-15)