MiniMax H3 auf DGX Spark: Viermal schneller, aber nicht derselbe Output

Vier Videos desselben Fuchses zeigen, was MiniMax H3 auf einem DGX Spark leisten kann. Sie zeigen auch, wie wenig eine einzelne Laufzeit über das beste Ergebnis sagt. Im kontrollierten Sol-Engine-Test blieben Prompt, Seed, 832 × 480 Pixel, 124 Frames und 50 Schritte konstant. Die Baseline brauchte 720,2 Sekunden, NVIDIAs verlustfreie Kernel 482,4 Sekunden und der volle Optimierungsstack 177,8 Sekunden.

Der vierte Clip lief in ComfyUI mit demselben Prompt und Seed, aber doppelt so lang und in 1376 × 768 Pixeln. Er brauchte knapp 45 Minuten und sieht für mich am besten aus. Das ist kein fairer Geschwindigkeitsvergleich: Dauer, Auflösung und Runtime unterscheiden sich. Sol Engine gewinnt beim Tempo, während der langsamste ComfyUI-Lauf in meinen Augen das stärkste Bild liefert.

MiniMax H3 auf DGX Spark: Was die 4,05× messen

NVIDIA nennt für MiniMax H3 auf einem einzelnen GB10-Chip 710,6 Sekunden in der Baseline und 181,3 Sekunden mit allen Optimierungen. Das entspricht dem Faktor 3,92. Mein Lauf mit dem offiziellen Demo-Prompt lag bei 732,1 und 164,2 Sekunden. Lokal ergibt das 4,46-fache Tempo. Beim Fuchs sank die Laufzeit von 720,2 auf 177,8 Sekunden, also um den Faktor 4,05.

Diese Zahl ist kein allgemeiner H3-Benchmark. Sie gilt für den gepinnten NVIDIA-Pfad mit einem FP8-Modellstack: pruned FP8 DiT, Qwen3-VL-32B als FP8-Conditioner, die veröffentlichten Video- und Audio-VAE-Komponenten sowie NVIDIAs Sana-Branch für Sol Engine. Der Lauf verwendete PyTorch 2.11.0 mit CUDA 13.0 und Triton 3.6.0. Ein Warmup und eine gemessene Anfrage pro Stufe verhindern, dass der erste Aufbau der Kernel den Vergleich dominiert.

Der Speicherverbrauch erklärt, weshalb der Spark hier überhaupt interessant ist. Alle drei Fuchs-Arme erreichten rund 73'916 bis 74'601 MiB Peak. Eine typische Consumer-GPU kann diesen Stack nicht einfach laden. Der GB10 kompensiert seine geringere rohe GPU-Leistung mit einem grossen gemeinsamen Speicher. Das ähnelt der Logik hinter lokaler KI auf DGX-Spark-Hardware: Modelle passen, die auf klassischen Einzel-GPUs bereits an der Kapazität scheitern. Die Laufzeit bleibt trotzdem eine eigene Baustelle.

Woher das Tempo kommt und was der Test offenlässt

Die erste Stufe tauscht keine Modelllogik aus. Kernel-only bündelt wiederkehrende, speicherlastige Operationen rund um Normalisierung, Positionskodierung, Aktivierungen und Feed-Forward-Blöcke. Im Fuchs-Test sinkt die reine Denoising-Zeit dadurch von 686,2 auf 452,1 Sekunden. Das decodierte Audiosignal ist bitgleich zur Baseline. Beim Video liegen PSNR bei 40,66 dB und SSIM bei 0,978. Die Dateien sind sehr ähnlich, aber nach H.264-Kodierung nicht byteidentisch.

Fullopt greift tiefer ein. Sol-Attn berechnet nur ausgewählte Aufmerksamkeitsblöcke. FirstBlockCache verwendet die Änderung nach dem ersten Transformer-Block als Näherung: Bleibt sie unter der Schwelle 0,08, kann der restliche Block-Stack übersprungen und ein früheres Residual wiederverwendet werden. Dazu kommt VAE-Tile-Batching. Die Denoising-Zeit fällt auf 156,7 Sekunden. Dieser Gewinn beruht teilweise darauf, weniger oder anders zu rechnen. „Full Optimization“ ist deshalb keine rein verlustfreie Beschleunigung.

NVIDIAs veröffentlichte Stufenmessung weist den Cross-step cache als grössten einzelnen Sprung aus: Auf dem Spark sinkt die Laufzeit nach Kerneloptimierungen und Sol-Attn von 451,2 auf 181,3 Sekunden. Meine Fuchs-Matrix isoliert diesen Anteil nicht. Sol-Attn, FirstBlockCache und VAE-Batching waren im Fullopt-Arm gemeinsam aktiv; weder die Cache-Schwelle noch die beiden veröffentlichten Cache-Presets wurden gegeneinander getestet. Der lokale 4,05×-Wert belegt daher den vollständigen Stack, nicht den Beitrag einer einzelnen Technik.

Der objektive Vergleich bestätigt die Abweichung. Gegenüber der Baseline erreicht Fullopt beim decodierten Video 19,21 dB PSNR und 0,695 SSIM; auch der PCM-Hash des Audios ändert sich. Diese Metriken sagen, dass zwei Resultate materiell verschieden sind. Sie sagen nicht, welches besser aussieht, ob die Bewegung glaubwürdig bleibt oder ob das neue Audio zum Bild passt.

Drei Sol-Clips, eine sichtbare Grenze

Alle drei Videos stammen aus derselben Messstrecke. Sie sind 5,175 Sekunden lang, laufen mit 24 Bildern pro Sekunde und enthalten H.264-Video sowie AAC-Stereo-Audio mit 32 kHz. Für die visuelle Prüfung sollten zuerst alle drei Clips ohne Vorwegnahme des Urteils angesehen werden. Relevant sind Motivtreue, Anatomie und Details, zeitliche Stabilität, Kamerabewegung sowie die Beziehung zwischen Bild und Ton.

A: Baseline
Laufzeit 720,2 Sekunden. Identischer Prompt, Seed und Workload.

B: Kernel-only
Laufzeit 482,4 Sekunden, 1,49× schneller. Identischer Prompt, Seed und Workload.

C: Fullopt
Laufzeit 177,8 Sekunden, 4,05× schneller. Identischer Prompt, Seed und Workload.

Meine Beurteilung ist die Einschätzung einer einzelnen Person, kein objektiver Qualitätsscore. Baseline und Kernel-only wirken für mich gleichwertig. Bei Bewegung, Beleuchtung und Fellzeichnung fällt mir kein belastbarer Unterschied auf. Fullopt liegt leicht dahinter: Der Clip wirkt etwas ruckeliger und weniger flüssig. An einer Stelle bewegt sich der Fuchs unnatürlich; Beleuchtung und Fell erscheinen zudem weniger detailliert. Die eingebetteten Originalclips erlauben eine eigene Bewertung, denn Bewegungsfluss und Detailtreue lassen sich unterschiedlich gewichten.

Der offizielle Pfad lief erst nach einem engen Patch

Der interessanteste Befund entstand vor dem Benchmark. NVIDIAs Baseline lief im gepinnten Checkout durch. Fullopt brach beim Warmup in Schritt 38 mit der Meldung „sink_tokens must be in [0, T]“ ab. FirstBlockCache übersprang Teile des Block-Stacks, während der Sol-Attn-Router Schritt und Block aus einer festen Zahl von Aufrufen ableitete. Ein kurzer Token-Refiner-Aufruf konnte dadurch fälschlich wie eine lange gepackte Videosequenz behandelt werden.

Der lokale Patch ergänzt eine einzige Schutzbedingung: Attention-Aufrufe, deren Sequenz kürzer als das H3-Präfix ist, bleiben auf dem dichten Pfad. Das entspricht NVIDIAs dokumentierter Absicht, die beiden Token-Refiner-Blöcke immer dicht zu berechnen. Der Installer akzeptierte nur den Hash der unveränderten Upstream-Datei, war idempotent und kompilierte die geänderte Python-Datei vor dem nächsten Start.

Dieser Eingriff muss den Performancewert begleiten. Der Test reproduziert NVIDIAs Architektur und Messstrecke, aber keinen unangetasteten Checkout. Sobald eine Anpassung den Inferenzpfad verändert, gehört sie mit Commit, Patch, Hashes und Fehlerprotokoll zum Benchmark-Artefakt. Sonst wirkt die erfolgreiche Zahl sauberer, als die Reproduktion tatsächlich war.

Die Konsequenz reicht über H3 hinaus. Inferenz-Frameworks werden zunehmend zu Optimierungsbaukästen aus Fusionskerneln, Sparse Attention, Caches und modellabhängigen Routern. Ein einzelner Modellname beschreibt den produktiven Stack immer schlechter. Wie beim Vergleich lokaler Inferenz-Frameworks muss deshalb die Runtime-Version zum Ergebnis gehören. In den nächsten 12 bis 24 Monaten dürfte die praktische Vergleichseinheit häufiger „Modell plus Optimierungslinie plus Hardware“ lauten.

MiniMax H3 in ComfyUI: das beste Bild braucht Geduld

MiniMax H3 lief auf demselben DGX Spark auch über ComfyUI. Der T2V-High-Fuchs verwendet denselben Prompt und Seed, dauert aber 10,125 Sekunden und hat mit 1376 × 768 Pixeln rund 2,65-mal so viele Bildpunkte wie die Sol-Clips. Seine Generierung dauerte knapp 45 Minuten. Für mich ist er qualitativ der beste der vier Clips: Fell, Licht und Gesamteindruck wirken am überzeugendsten. Die höhere Auflösung verschafft ihm dabei einen offensichtlichen Vorteil, weshalb diese Bewertung keine Aussage über die reine Güte der Runtime erlaubt.

Das veröffentlichte GB10-Rezept von NVIDIA ist für 832 × 480 Pixel, 124 Frames und 50 Schritte validiert. Genau diesen 480p-Pfad habe ich reproduziert. Daraus folgt keine allgemeine 480p-Sperre von Sol Engine: NVIDIA verwendet auf einer RTX 5090 selbst 1344 × 768 Pixel, allerdings mit einer anderen, hardwarespezifischen Konfiguration. Belegt ist nur die praktische Grenze dieses Tests. ComfyUI erzeugte auf dem Spark 1376 × 768 Pixel; für den Sol-GB10-Pfad liegt hier kein validierter 768p-Lauf vor.

Auch bei den Eingabemodi ist der veröffentlichte GB10-Pfad enger. Der Launcher ist derzeit für Text-to-Video-and-Audio verdrahtet und nimmt weder Start- oder Endbilder noch Referenzmedien entgegen. MiniMax H3 unterstützt Image-to-Video und Reference-to-Video grundsätzlich, diese Modi sind in diesem Launcher aber nicht exponiert und wurden hier nicht getestet.

Der grosse Zeitunterschied hat damit eine technische Ursache. Der ComfyUI-Lauf nutzte keine der getesteten Sol-Engine-Stufen: keine Kernelfusionen, keine Sparse Attention und keinen Cross-step cache. Gleichzeitig verarbeitete er 243 Frames bei 1376 × 768 Pixeln statt 124 Frames bei 832 × 480 Pixeln. Das sind rund 5,2-mal so viele Pixel-Frames. Die Last dichter Attention wächst mit der Sequenzlänge überlinear; H3 verarbeitet dabei Video- und Audio-Tokens gemeinsam. ComfyUI rechnete zwar nur 20 statt 50 Denoising-Schritte, doch dieser gegenläufige Unterschied macht eine einfache Hochrechnung erst recht unbrauchbar.

Damit bedienen die beiden Wege unterschiedliche Prioritäten. ComfyUI bietet den flexibleren kreativen Workflow und in diesem Vergleich das für mich beste Resultat, bezahlt dafür aber mit deutlich mehr Arbeit pro Clip und ohne die Sol-spezifische Beschleunigung. Die drei Sol-Videos messen dagegen sauber den Einfluss der gewählten Stufen bei 480p. Die knapp 45 Minuten bedeuten deshalb nicht, dass ComfyUI bei identischer Last rund 15-mal langsamer wäre als Fullopt. Ich plane, die Optimierungen der Sol Engine zeitnah auf einen ComfyUI-Workflow zu übertragen und dann auch die Grenzen bei 768p zu testen.

D: ComfyUI T2V High
10,125 Sekunden bei 1376 × 768 Pixeln; Generierungszeit knapp 45 Minuten. Illustrativer Praxisvergleich, kein vierter Sol-Benchmarkarm.

Für schnelle Vorschauen bleibt Fullopt attraktiv. Für einen kontrollierten 480p-Export würde ich Kernel-only wählen: 1,49-faches Tempo, identisches decodiertes Audio und für mich dieselbe sichtbare Qualität wie die Baseline. Wenn das bestmögliche Ergebnis dieser vier Clips zählt, gewinnt ComfyUI High. Knapp 45 Minuten pro Versuch machen daraus allerdings eine teure Geduldsprobe, sobald mehrere Varianten nötig werden.