Ein Mini-PC mit AMD-Grafik erzeugt bei mir seit gestern Abend Videos mit Ton, fünf Sekunden in gut vier Minuten. Der Aufbau hat einen Abend gedauert und genau einmal richtig geklemmt, an einer Stelle, die in keiner Anleitung vorkommt.
Der Anlass und die offene Frage
Ausgangspunkt war ein Tutorial zu MiniMax-H3, einem Videomodell mit offenen Gewichten, das seit kurzem direkt in ComfyUI unterstützt wird. Es kann Text zu Video, Bild zu Video und erzeugt die Tonspur gleich mit. Alle Anleitungen dazu rechnen mit NVIDIA: CUDA, SageAttention als Beschleuniger, fp8-Quantisierung für die RTX-50-Reihe.
Mein Beelink hat aber eine Radeon 8060S, die integrierte Grafik eines Ryzen AI Max+ 395. Die Architektur heißt RDNA 3.5, und damit stand eine unangenehme Frage im Raum. Im ComfyUI-Repository liegt ein offener Fehlerbericht, nach dem MiniMax-H3 auf RDNA3 nur Rauschen und Mosaik ausgibt, bei jeder getesteten Quantisierung. Auf RDNA4 läuft es. RDNA 3.5 liegt genau dazwischen und taucht in keinem Bericht auf.
Deshalb erst die billige Prüfung: PyTorch mit ROCm 7.2 installieren und nachrechnen lassen, ob die Karte überhaupt korrekt arbeitet. Ein kleines Skript vergleicht Matrixmultiplikation, Faltung und Attention gegen die CPU-Referenz. Alle Abweichungen lagen im Rundungsbereich, und ein Bildmodell lieferte danach ein sauberes Bild in 0,9 Sekunden. Nebenbei die erste Falle: Der allererste Lauf dauerte 112 Sekunden. Das ist die einmalige Kernel-Kompilierung, nicht die Rechenleistung. Wer daran misst, hält die Hardware für unbrauchbar.
Der Absturz kam nicht vom Modell
Dann 69 GB Modelldateien geladen, ComfyUI gestartet, Auftrag abgeschickt. Nach zwei Minuten war der Server weg, der Client bekam nur noch ein zurückgesetztes Netzwerkpaket. Im Kernel-Log stand:
Out of memory: Killed process 407775 (python) anon-rss:62911320kB
amdgpu_hmm_range_get_pages ... svm_range_validate_and_map
62,9 GB, also der komplette Arbeitsspeicher. Der Rechner hat 128 GB verbaut, aber 64 GB davon sind fest als Grafikspeicher abgezweigt, es bleiben 62 GB fürs System. ComfyUI zieht die Gewichte erst dorthin, bevor sie auf die GPU wandern. Text-Encoder und Diffusionsmodell zusammen passen da nicht hinein.
Der Engpass war also der Arbeitsspeicher, während ich die ganze Zeit auf den Grafikspeicher geschaut hatte. Behoben mit einem einzigen Startflag: --lowvram lässt den Text-Encoder auf der CPU liegen und schiebt nur das eigentliche Modell in den Grafikspeicher. Seitdem läuft es stabil.
Was die beiden Stellschrauben kosten
Alle Läufe bei gleichem Prompt, gemessen inklusive Modell-Laden:
| Auflösung | Länge | Schritte | Sekunden je Schritt | Gesamt |
|---|---|---|---|---|
| 640×384 | 1,6 s | 20 | 4,8 | 3,5 min |
| 640×384 | 5,2 s | 20 | 26,3 | 11,9 min |
| 640×384 | 5,2 s | 8 mit Turbo-LoRA | 25,3 | 4,3 min |
| 848×480 | 5,2 s | 8 mit Turbo-LoRA | 77,5 | 15,3 min |
| 848×480 | 10,1 s | 8 mit Turbo-LoRA | 399,7 | 66 min |
Die ersten drei Zeilen legten eine einfache Regel nahe: Länge kostet linear, knapp fünffache Bildzahl bei fünfeinhalbfacher Rechenzeit, während Auflösung überproportional zuschlägt. Ich hatte daraus für den letzten Lauf 25 Minuten geschätzt.
Es wurden 66. Die Verdopplung der Länge kostete bei dieser Auflösung nicht das Doppelte, sondern das 5,2-fache. Der Grund stand während des Laufs im Systemmonitor: 47 von 62 GB belegt, nichts mehr frei. Ablesen ließ es sich an den Schritten selbst, die immer länger brauchten, 227 Sekunden, dann 322, dann 372, dann 402. Ein Rechner, der gleichmäßig rechnet, hält seine Schrittzeit; steigt sie, schichtet er Speicher um.
Die Regel lautet also genauer: Länge ist billig, solange der Arbeitsspeicher reicht. Danach wird sie sehr teuer. Für diese Hardware heißt das fünf Sekunden bei 848×480 oder zehn Sekunden bei 640×384. Beides zusammen lohnt nicht.
Wofür sich die Wartezeit lohnt, zeigt der letzte Lauf aus der Tabelle. Der Prompt beschreibt eine Frau, die nachts durch eine regennasse Gasse auf die Kamera zugeht, dazu Neonlicht, Pfützen und Passanten im Hintergrund:
Und so sehen die 66 Minuten aus der letzten Tabellenzeile aus, eine Straßenbahnfahrt durch eine nächtliche Regenstadt:
Das Turbo-LoRA bringt Faktor 2,8, ohne dass ich einen Qualitätsverlust sehe. Dabei ein Detail, über das der Autor des Tutorials selbst gestolpert ist: Die Datei heißt „4step", aber gedacht sind acht Schritte, dazu Sampler Euler und Beta-Scheduler. Mit vier Schritten wird das Ergebnis matschig, und man sucht den Fehler dann an der falschen Stelle.
Den Aufbau habe ich weitgehend von Claude Code machen lassen, was zum Thema passt, weil das Tutorial genau das empfiehlt. Nützlich war das vor allem beim Workflow selbst: Statt die Verkabelung aus einem Video abzuschreiben, ließ sich die mitgelieferte ComfyUI-Vorlage auslesen und in einen API-Aufruf übersetzen.
Für Bastelzwecke reicht die integrierte Grafik damit aus. Fünf Sekunden in kleiner Auflösung sind eine Kaffeepause, und alles bleibt im Haus, ohne Konto und ohne Zeitguthaben. Die 1344×768 aus dem Tutorial lägen bei dieser Länge allerdings bei rund einer Stunde, und das ist dann eher etwas für über Nacht als zum Ausprobieren.
Kommentare
Noch keine Kommentare. Schreib den ersten.
Melde dich an, um zu kommentieren.