gfx1151Vulkan / Mesa-RADVROCm verworfen

Bildgenerierung und Sprache lokal

Bild, Text-zu-Sprache und Spracherkennung laufen auf dem Ryzen AI Max+ 395 — aber nur auf dem richtigen Pfad. ROCm scheidet für dieses Setup aus; über Vulkan und stable-diffusion.cpp läuft es: 10 Sekunden für ein 1024 × 576-Bild, 13 Minuten für das 32B-Modell. Diese Seite hält die gemessenen Zeiten fest, die Encoder-Zuordnung, das 2-GB-Limit des Treibers und die Stellen, an denen die Ergebnisse nicht brauchbar sind.

Einordnung: Vulkan statt ROCm

Vulkan — der Weg, der läuft

✓Läuft auf gfx1151. stable-diffusion.cpp über Vulkan mit dem Mesa-RADV-Treiber. Das ist der Pfad, auf dem alle Zeiten auf dieser Seite entstanden sind.
✓Build ist reproduzierbar. Mit glslang und spirv-headers-devel kompiliert das Binary in einem Durchgang: rund 103 MB, 28 Threads.

ROCm — bewusst verworfen

✕PyTorch-ROCm unterstützt gfx1151 nicht. Die offiziellen PyTorch-ROCm-Pakete kennen diese GPU nicht. Ohne Support-Patch ist der Weg über PyTorch dicht.
✕ComfyUI mit ROCm hängt die GPU. Kein sauberer Abbruch mit Meldung, sondern ein Hänger. Für einen Betrieb, der laufen muss, ist das keine Option.

Messumgebung

Hardware

Ryzen AI Max+ 395 · Radeon 8060S (gfx1151)

Arbeitsspeicher

117 GB nutzbar (Unified Memory)

Fedora 44

Backend

stable-diffusion.cpp · Vulkan über Mesa-RADV

Build-Pakete

glslang, spirv-headers-devel

Binary

rund 103 MB, Build mit 28 Threads

Bildmodelle im Vergleich

Alle Zeiten mit demselben Backend gemessen: stable-diffusion.cpp über Vulkan. Sortiert von schnell nach langsam. Die Spanne reicht von 10 Sekunden bis rund 13 Minuten — bei identischer Hardware, und Auflösung wie Schrittanzahl stehen mit in der Tabelle, weil man sonst nicht vergleichen kann.

Modell	Quantisierung	Stack	Auflösung	Schritte	CFG	Sampler	Dauer
FLUX.2-klein-4B	Q8_0	8 GB	1024 × 576	4	1,0	—	10 s
SD 1.5	—	2 GB	512 × 512	20	—	—	11 s
FLUX.1-schnell	fp8	17 GB	1024 × 576	4	—	—	36 s
FLUX.1-schnell	fp8	17 GB	1024 × 1024	4	—	—	57 s
FLUX.2-dev 32B	Q5_K_M	39 GB	1024 × 576	20	2,5	euler	794 s ≈ 13 min

Stackgröße ist die Summe, die für den Lauf im Speicher liegen muss — Diffusionsmodell, Text-Encoder und VAE zusammen. Die einzelnen Dateigrößen stehen im nächsten Abschnitt. FLUX.2-klein kommt mit 8 GB aus, FLUX.2-dev mit 39 GB.

Encoder-Zuordnung: Pflicht, kein Vorschlag

Jedes Diffusionsmodell gehört zu genau einem Text-Encoder. Das ist keine Geschmacksfrage und keine Optimierungsstellschraube — der Encoder produziert die Konditionierung, und die passt nur zum zugehörigen Modell.

Bildmodell	Text-Encoder	Encoder-Datei	VAE
FLUX.2-klein-4B	Qwen3-4B	`qwen3-4b-encoder-Q8_0.gguf`	`flux2_vae.safetensors`
FLUX.2-dev 32B	Mistral-Small-3.2-24B	`mistral-encoder-Q4_K_M.gguf`	`flux2_vae.safetensors`

Die VAE ist für beide FLUX.2-Modelle dieselbe. Was sich nicht austauschen lässt, ist der Text-Encoder.

Meldung beim Vertauschen

Conditioner model tensor ... q_norm.weight not in model metadata

Vertauscht man die Encoder, kommt genau diese Meldung. Im dokumentierten Fall stand dazu ein vergeblicher 14-GB-Download: der falsche Encoder war geladen, bevor auffiel, dass er nicht passt.

Dateigrößen im Einzelnen. Wer den Stack selbst zusammenstellt, merkt schnell, dass der Encoder kein Anhängsel ist: Bei FLUX.2-dev bringt der Mistral-Encoder mit 14 GB mehr als die Hälfte des Diffusionsmodells auf die Waage.

Datei	Größe	Rolle
`flux-2-klein-4b-Q8_0.gguf`	4,1 GB	Diffusionsmodell
`qwen3-4b-encoder-Q8_0.gguf`	4,0 GB	Text-Encoder
`flux2_vae.safetensors`	238 MB	VAE
`flux2-dev-Q5_K_M.gguf`	25 GB	Diffusionsmodell
`mistral-encoder-Q4_K_M.gguf`	14 GB	Text-Encoder
`flux1-schnell-fp8.safetensors`	17 GB	Diffusionsmodell
`sd15.safetensors`	2,0 GB	Diffusionsmodell

Fallstricke: Limit, Offload, Build

Der wichtigste Punkt zuerst: Die Speichermeldung auf dieser Hardware bedeutet nicht, dass der Speicher voll ist. Sie bedeutet, dass der Treiber einen einzelnen Block nicht größer als 2 GB zulässt.

tückisch

Vulkan-Limit: maxMemoryAllocationSize 2 GB

Läuft weiter — und sagt dabei etwas anderes, als gemeint ist.

Ab 1024x1024 erscheint "Failed to allocate pinned memory" — die Generierung läuft aber weiter.

Was wirklich passiert

Mesa-RADV meldet maxMemoryAllocationSize 2 GB und maxStorageBufferRange 128 MB, bei Heaps von 42,7 / 85,3 / 117,7 GB. Die Grenze gilt für einen einzelnen zusammenhängenden Block, nicht für den Heap. Das ist kein Speichermangel, sondern eine harte Obergrenze des Treibers.

Für die Praxis

Es bricht nichts ab, es wird nur langsamer: die Software weicht auf einen nicht angehefteten Speicherpfad aus. Wer die Meldung als RAM-Problem liest, sucht an der falschen Stelle.

wissenswert

CPU-Offload bringt nur 11 Prozent

Kein Fehler, aber eine Erwartung, die nicht stimmt.

--offload-to-cpu ändert bei der 32B-Variante kaum etwas: 47 Sekunden pro Schritt mit Offload gegen 41 Sekunden ohne.

Was wirklich passiert

Das sind 11 Prozent Unterschied. Bei Unified Memory wird üblicherweise die Speicherbandbreite zum Flaschenhals — hier ist es die Rechenleistung. Der Flaschenhals liegt also dort, wo der Offload gar nicht eingreift.

Für die Praxis

Der Schalter lohnt in diesem Setup nicht. Tempo gewinnt man über Schritte, Auflösung und Modellgröße, nicht über den Speicherpfad.

blockierend

CMake abbruch wegen glslangValidator

Stoppt den Build oder den Start sofort.

Der Build bricht mit "missing components: glslangValidator" ab.

Was wirklich passiert

Für den Vulkan-Backend werden glslang und spirv-headers-devel benötigt. Fehlen sie, kommt der Build nicht über die Konfiguration hinaus.

Für die Praxis

Beide Pakete vor dem ersten Build installieren. Danach läuft es in einem Durchgang: rund 103 MB Binary, 28 Threads.

Die Treibergrenzen im Wortlaut. Das meldet Mesa-RADV auf dieser GPU — diese Werte stehen so in der Geräteabfrage und erklären den Fehlerfall besser als jede Vermutung über freien Speicher.

Begrenzung	Wert	Bedeutung
`maxMemoryAllocationSize`	2 GB	Die relevante Grenze: Sie gilt pro zusammenhängendem Block und ist unabhängig davon, wie viel Speicher frei ist.
`maxStorageBufferRange`	128 MB	Wird vom Treiber ebenfalls als eng gemeldet, ist aber nicht die Grenze aus dem Fehlerfall.
`Heaps`	42,7 / 85,3 / 117,7 GB	Der verfügbare Platz ist groß. Die Fehlermeldung beschreibt gerade nicht diesen Platz.

Leistungsaufnahme und Temperatur unter Volllast

Gemessen bei FLUX.2-dev 32B (Q5_K_M), 1024 × 576, 20 Schritte, CFG 2,5, Sampler euler.

GPU-Auslastung

100 %

Durchgehend belegt, kein Idle-Anteil während der Generierung.

GPU-Temperatur

73 °C

Unter Volllast, über der gesamten Messstrecke stabil.

CPU-Package

74 °C

Die CPU läuft bei der Bildgenerierung mit, bleibt aber in derselben Größenordnung.

Leistungsaufnahme

119 W

Gesamtsystem unter Volllast.

Grenzen: was diese Modelle nicht können

Die Zeiten oben sagen nichts über die Qualität der Ergebnisse. Diese drei Punkte fallen bei jeder Generierung wieder auf und liegen an den Modellen, nicht am Backend und nicht an der Hardware.

Schrift im Bild

Schriftzüge gelingen nicht zuverlässig. Wer Text im Bild braucht, setzt ihn nachträglich.

Geometrische Präzision

Geometrisch präzise Vorgaben werden ignoriert. Ein Modell erkennt Muster wie "steigend", aber keine komplexen Richtungswechsel wie Wendepunkte in einer Kurve.

FLUX.1-schnell

Wurde auf gefilterten Daten trainiert und ist entsprechend eingeschränkt.

Sprache: whisper.cpp und Piper

Sprache ist separat und in deutlich kleinerem Umfang gemessen als die Bildbenchmarks: zwei Messwerte, kein Lastprofil, keine Vergleichsserie über mehrere Modelle.

Aufgabe	Werkzeug	Modell	Messwert
Spracherkennung	whisper.cpp	large-v3-turbo	11 s Audio → rund 1 s Transkript
Sprachausgabe	Piper	thorsten-medium (deutsch)	rund 1,5 s pro Ausgabe

Spracherkennung · whisper.cpp

Das aufzurufende Programm heißt whisper-cli. Das früher übliche main ist nur noch ein Hinweis-Stub.

Sprachausgabe · Piper

Deutsche Stimme, identische Hardware wie bei den Bildmessungen.

whisper-cli, nicht main. Das Programm heißt whisper-cli. Wer den alten Befehl mit main aufruft, bekommt keine Erkennung, sondern nur einen Hinweis-Stub. Das ist kein Absturz — es passiert einfach nichts Nützliches.

Video: Ausblick, nicht vermessen

Genannt werden für diese Hardware regelmäßig Wan 2.1 / 2.2, LTX-2.3, HunyuanVideo 1.5. Grundsätzlich ist Video damit möglich.

Kein Messwert vorhanden

Video ist auf dieser Hardware grundsätzlich möglich. Hier wurde es nicht systematisch vermessen — es gibt dazu keine Zeiten, keine Auflösungs- oder Längenlimits und keinen Vergleich. Wer Video braucht, muss selbst messen.

· Keine Generierungszeiten pro Sekunde Videomaterial
· Keine Auflösungs- oder Längenlimits
· Kein Vergleich der drei Modelle untereinander
· Keine Aussage zu Speicherbedarf oder Stabilität