Muse Spark Open Hardware-Anforderungen: VRAM, GPUs und Nutzer für Metas 816B-Modell

Mit welchen Servern Sie Muse Spark Open lokal betreiben

Muse Spark Open braucht einen Server mit acht GPUs. Der NVFP4-Checkpoint mit 533,0 GB passt auf acht NVIDIA RTX PRO 6000 Blackwell Server Edition und lässt nach unserer Regel für Nutzer je Karte Platz für rund 71 gleichzeitige Gespräche zu je 32.768 Token mit 16-Bit-Cache oder 142 mit FP8-Cache. Acht H200 NVL halten dieselben Gewichte mit fast dem Dreifachen an freiem Speicher, aber nur, wenn die Engine die FP4-Gewichte behält und in 16 Bit rechnet; der BF16-Checkpoint mit 1,64 TB braucht eine DGX B300 oder zwei Server mit je acht H200 NVL.

Metas Model Card schreibt: „the model requires a GPU with at least 700GB of VRAM for NVFP4 and 2TB for BF16“. Keine einzelne GPU hat so viel Speicher, die Angabe meint also den GPU-Speicher eines ganzen Servers. Acht RTX PRO 6000 Server Edition haben 768 GB; nach unserer Regel stehen davon 664,3 GiB, also 713 GB, für Gewichte und Cache bereit, und das erfüllt Metas Angabe. Server mit vier Karten reichen nicht: Vier H200 NVL verfehlen die NVFP4-Gewichte um 3,0 GiB, vier RTX PRO 6000 Server Edition um 164 GiB. Unser Leitfaden zu acht RTX PRO 6000 Server Edition führt Muse Spark Open neben anderen Modellen, die den ganzen Server brauchen; dieser Artikel rechnet es im Detail.

Muse Spark Open auf Hugging Face: Parameter, Checkpoints und Kontext

Meta veröffentlicht das Modell in einer Collection mit zwei Repositories, eines in BF16 und eines in NVFP4. Die safetensors-Dateien beider „Files“-Seiten haben wir am 24. Oktober 2026 summiert.

Model Cards von meta-models/Muse-Spark-Open-816B-A42B und -NVFP4 mit ihren Dateilisten auf Hugging Face, gelesen am 24. Oktober 2026; die Checkpoint-Größen sind unsere Summen der gelisteten safetensors-Dateien (GB = 10⁹ Byte, GiB = 2³⁰ Byte). Das vLLM-Rezept, aktualisiert am 16. Oktober 2026, nennt „~533 GB“ und „~1.64 TB“.

Die Model Card nennt SGLang, vLLM, Hugging Face Transformers, TensorRT-LLM, Unsloth und llama.cpp als unterstützte Engines, legt aber keine Versionen fest und nennt kein GPU-Modell. Die Model Card beschreibt das Modell als Mixture-of-Experts-Transformer mit einem Perception Encoder von 1,8B Parametern; die Summen oben umfassen alle safetensors-Dateien des jeweiligen Repositorys, also das, was der Server laden muss. Das vLLM-Rezept beschreibt den NVFP4-Build als „the primary NVIDIA Blackwell path“, der „fits one 8-GPU node“. Sein Kopf nennt vLLM 0.33.0, und es empfiehlt „Use Docker image for now until the code is in vLLM main repo“; das Modell braucht also unter Umständen eine neuere Engine als die, die Ihre Plattform heute betreibt.

KV-Cache: 46 Sliding-Window-Schichten und 16 volle Schichten

Der Cache entscheidet, wie viele Menschen ein Server trägt. Die Model Card nennt 16 KV-Heads mit Dimension 64 je Schicht. Das vLLM-Rezept ergänzt das Schichtmuster: „Three layers in each cycle look back 2048 tokens; the other (layers 1, 5, …, 61) sees the whole context“, zusammen „46 narrow layers and 16 wide ones“. Die Konfigurationsdatei selbst liegt hinter Metas Zugangsformular; wir rechnen daher mit diesen beiden veröffentlichten Beschreibungen.

Jede Schicht speichert Keys und Values von 16 Heads × 64 Werten, in 16 Bit 4.096 Byte je Token. Die 16 vollen Schichten speichern jedes Token, die 46 schmalen höchstens 2.048 Token. Nach unserer Rechnung braucht ein Gespräch daher:

Unsere Schätzung aus den Attention-Angaben der Model Card und dem Schichtmuster im vLLM-Rezept, unter der Annahme, dass die Engine in den schmalen Schichten nur die letzten 2.048 Token hält. Speicherte eine Engine den vollen Kontext in allen 62 Schichten, bräuchte ein Gespräch mit 32K in 16 Bit 7,75 GiB.

Einen FP8-Cache („either the default or --kv-cache-dtype fp8 KV cache“) validiert das Rezept nur für AMDs MXFP4-Variante beim vollen Kontext von 1M; für den NVIDIA-NVFP4-Pfad erwähnt es keinen. --kv-cache-dtype fp8 ist eine allgemeine vLLM-Option, die FP8-Spalte ist daher unsere Schätzung für eine Variante, die einen Testlauf auf Ihrer Hardware braucht. Bei 16 KV-Heads gibt achtfacher Tensor-Parallelismus jeder Karte zwei Heads, und jede Karte hält ein Achtel des Caches jedes Gesprächs. Anders als bei den Latent-Caches der DeepSeek- und Kimi-Modelle wird nichts auf jede Karte kopiert, der Cache-Speicher aller acht Karten addiert sich. Unser Leitfaden zu Hardware für LLMs mit langem Kontext vergleicht diese Cache-Arten.

Freier Speicher und Gespräche je Konfiguration

Unsere Regel für Nutzer je Karte nimmt 90 Prozent des Speichers, den der Treiber meldet, und zieht je Karte 3 GiB ab: 83,0 GiB je RTX PRO 6000 Server Edition und 123,4 GiB je H200 NVL. Was nach den Gewichten übrig bleibt, steht für den Cache bereit.

Unsere Schätzungen nach der Regel für Nutzer je Karte für den NVFP4-Checkpoint mit 496,4 GiB, Gespräche in voller Länge. Zeilen mit H200 NVL setzen voraus, dass die Engine NVFP4 auf Hopper weight-only ausführt. DGX B300: NVIDIA nennt 2,1 TB GPU-Speicher für acht GPUs, rund 270 GB je GPU, vorsichtig als 10⁹ Byte gelesen. Das DSpark-Draft-Modell aus dem vLLM-Rezept ist nicht eingerechnet.

Bei 128K halten acht RTX PRO 6000 Server Edition rund 20 Gespräche mit 16-Bit-Cache und 40 mit FP8-Cache, acht H200 NVL rund 58 und 117. Beim vollen Kontext von 1M ergibt unsere Rechnung rund fünf Gespräche auf acht RTX PRO 6000 Server Edition und 15 auf acht H200 NVL, jeweils mit FP8-Cache. Das sind Anfragen, die im selben Moment laufen, weit weniger als die Zahl der Beschäftigten, die den Dienst nutzen; messen Sie die Spitze in Ihren eigenen Protokollen, bevor Sie zwischen den beiden Servern wählen. Wir bauen Server mit acht RTX PRO 6000 Server Edition oder H200 NVL; senden Sie uns die erwartete Spitze an Gesprächen und die Kontextlänge, und unser Team antwortet mit den Zahlen für beide.

Acht RTX PRO 6000 Server Edition: NVFP4 auf Blackwell

Die RTX PRO 6000 rechnet FP4 auf ihren Blackwell-Tensor-Cores und betreibt den NVFP4-Checkpoint so, wie er veröffentlicht ist. Der vLLM-Befehl für den NVIDIA-NVFP4-Pfad startet das Modell mit --tensor-parallel-size 8, --enable-expert-parallel und --max-model-len 1048576, dazu Metas Reasoning- und Tool-Parser sowie ein DSpark-Draft-Modell für spekulatives Dekodieren. Das Rezept schreibt, NVIDIA „supports every parallelism this recipe offers: TP, TP + PP, TP + expert parallel, data + expert parallel“.

Das Rezept nennt weder die RTX PRO 6000 noch ihre Compute Capability 12.0, die SM120-Generation. Kernels für Rechenzentrums-Blackwell sind nicht immer für SM120 gebaut, wie unser Artikel zur Software-Unterstützung von Blackwell RTX (SM120) erklärt; testen Sie das Image daher auf dieser Karte, bevor Sie einen Dienst darauf planen. Die Karten sind nur über PCIe verbunden. Tensor-Parallelismus über acht Karten schickt den All-Reduce jeder Schicht über PCIe, und Expert-Parallelismus schickt Token zu den Karten, die ihre Experten halten. Unser Artikel zu Tensor-Parallelismus ohne NVLink auf der RTX PRO 6000 behandelt die Einstellungen, die für diesen Verkehr zählen.

Acht Karten mit 600 W ziehen 4,8 kW; mit zwei Prozessoren und dem Rest des Servers schätzen wir rund 6,3 kW an der Steckdose, ein Wert, den eine Messung am gelieferten System bestätigt oder korrigiert. Das ist mehr, als ein einphasiger Anschluss mit 230 V und 32 A bei 80 Prozent trägt, 5,89 kW; der Server braucht also einen Drehstromplatz, wie unser Leitfaden zu GPU-Servern an 16 A, 32 A und Drehstrom zeigt. Konfiguration und Bestellablauf stehen auf unserer Seite Server mit 8× RTX PRO 6000 Server Edition kaufen.

Acht H200 NVL: mehr Speicher, FP4 nur weight-only

Acht H200 NVL haben 1.128 GB HBM3e und nach unserer Regel 986,9 GiB, nach den NVFP4-Gewichten bleiben 490,5 GiB Cache. Hopper hat keine FP4-Arithmetik. Wie unser Leitfaden zu FP4-Modellen auf H200 NVL und Ada-GPUs erklärt, führt vLLM NVFP4-Checkpoints auf Hopper nur weight-only aus: Die Gewichte behalten im Speicher ihre 4-Bit-Größe, gerechnet wird in 16 Bit. Weder Metas Model Card noch das vLLM-Rezept nennen Hopper für dieses Modell; die Zeilen mit H200 NVL zeigen also nur, dass das Modell in den Speicher passt, und brauchen einen Testlauf.

Der BF16-Checkpoint, den Hopper nativ rechnet, hat 1.531,4 GiB und passt nicht auf acht H200 NVL. Eine FP8-Version veröffentlicht Meta nicht. In einem Server mit acht H200 NVL bilden die Karten außerdem zwei NVLink-Domänen zu je vier, verbunden über PCIe; die passende Aufteilung ist daher TP=4 × PP=2, eine Pipeline-Stufe je Domäne, die das „TP + PP“ des Rezepts abdeckt. Unser Leitfaden zum Server mit 8× H200 NVL erklärt die Domänen und die Befehle.

BF16 und der nächste Schritt: DGX B300 oder zwei Server

Die BF16-Gewichte belegen vor jedem Cache 1.531,4 GiB. Zwei Varianten halten sie. Eine DGX B300 hat acht B300-GPUs mit je rund 270 GB in einer NVLink-Domäne. Vorsichtig als 10⁹ Byte gelesen, sind das nach unserer Regel rund 1.786 GiB; nach den Gewichten bleiben rund 255 GiB, Platz für rund 108 Gespräche zu je 32K mit 16-Bit-Cache oder 216 mit FP8-Cache. In NVFP4, das die B300 nativ rechnet, hält dasselbe System rund 1.290 GiB frei. Die DGX B300 liefern wir projektbezogen; bevor wir ein Angebot erstellen können, fragt die Distribution nach Unternehmen, Projekt und Einsatzzweck, wie unser Leitfaden zum Kauf einer DGX B300 in der EU beschreibt.

Die zweite Variante sind zwei Server mit je acht H200 NVL, nach unserer Regel 1.973,8 GiB, über das Netzwerk verbunden, mit Pipeline-Parallelismus zwischen den Servern. Nach den BF16-Gewichten bleiben rund 442 GiB, grob 187 Gespräche zu je 32K mit 16-Bit-Cache. Unser Vergleich 1T-Modelle für 100 Nutzer auf einer DGX B300 oder zwei H200-NVL-Servern rechnet diese Aufteilung für mehrere große Modelle durch. Für die meisten Unternehmen ist der NVFP4-Checkpoint auf Blackwell die praktische Wahl; BF16 ist dort wichtig, wo eine Fine-Tuning-Pipeline oder eine Evaluierung von den Originalgewichten ausgehen muss.

Muse Model License: Namensnennung, Model-as-a-Service und Zugang

Muse Spark Open steht unter der Muse Model License, die Meta auf den 15. Oktober 2026 datiert. Sie gewährt das Recht „to deal in the Software without restriction“, einschließlich Änderung, Fine-Tuning, Destillation und Verkauf, sofern „The above copyright notice and this license and the Usage Policy shall be included in all copies“. Lizenznehmer müssen „prominently display "Built with Muse Spark Open"“, in der Benutzeroberfläche jedes Produkts oder Dienstes oder in dessen Dokumentation, Website oder Einstellungen.

Die kommerzielle Bedingung steht in Abschnitt 3. Ein Lizenznehmer, der Model as a Service anbietet, also „a third party with access to artificial intelligence models as a product or service, via API or a similar interface“ bereitstellt, muss Meta benachrichtigen und „enter into a separate written agreement with Meta“, sobald „the aggregate gross revenue of the Licensee and its affiliates exceeds twenty (20) million US dollars“ in einem Zeitraum von 12 Monaten. Der Abschnitt gilt nicht für „internal use, research, or any commercial activity that is not Model as a Service“ und nicht für die Nutzung des Modells „as a component to power features of the Licensee's own product or service“. Für Lizenznehmer in Europa ist „Meta“ die Meta Platforms Ireland Limited. Eine Klausel, die die EU ausschließt oder die Nutzung dort einschränkt, haben wir nicht gefunden. Die Usage Policy hält fest, dass das Modell nicht für Personen unter 18 Jahren gedacht ist, und listet verbotene Nutzungen.

Die Repositories sind zugangsbeschränkt: Metas Formular fragt nach vollständigem Namen, Geburtsdatum und Name der Organisation und lässt sich nach dem Absenden nicht mehr ändern; lassen Sie es daher von der Person ausfüllen, die für Ihr Unternehmen zeichnet. Ob Lizenz und Policy zu Ihrer Nutzung passen, entscheidet Ihre Rechtsabteilung. Ein Modell, das aus heruntergeladenen Gewichten auf Ihren eigenen Servern läuft, sendet keine Prompts oder Ausgaben an Meta.

Was wir liefern

Sie können dieses System bei uns kaufen: Unser Team legt die Konfiguration nach Ihrer Last und Ihrem Budget aus und antwortet innerhalb eines Werktages. Für Muse Spark Open bauen wir Server mit acht RTX PRO 6000 Server Edition oder H200 NVL, zwei AMD-EPYC-Prozessoren, DDR5-ECC-Speicher mit mindestens dem Doppelten des GPU-Speichers und NVMe-Speicher für den Checkpoint mit 533 GB, vor der Lieferung montiert und getestet, mit EU-Vertrag und EU-Rechnung sowie Herstellergarantie auf jede Komponente. Die DGX B300 bieten wir projektbezogen an. Die Einrichtung von Modell, Retrieval und Serving-Plattform gehört zu unserem Service Private AI/ML. Nennen Sie uns, ob Sie Bilder, Video oder Audio als Eingabe brauchen, und wir rechnen die Last des Encoders in die Auslegung ein.

FAQ