Lokale Bildgenerierung auf Apple Silicon: warum fp8 scheitert und MLX der Ausweg ist

Ich wollte KI-Bilder lokal erzeugen. Offline, auf der eigenen Maschine, ohne Cloud-Abo und ohne dass irgendwelche Prompts oder Ergebnisse das Haus verlassen. Dafür habe ich bewusst starke Hardware: ein MacBook Pro mit M5 Max und 128 GB Unified Memory. Genug, um auch große Modelle zu fahren.

Trotzdem bin ich am ersten Abend gegen eine Wand gelaufen, die mit Rechenleistung nichts zu tun hatte. Und genau diese Wand ist eine gute Lektion darüber, wie lokale KI auf dem Mac wirklich funktioniert, und wo die ganzen Anleitungen aus dem Netz an Apple-Hardware vorbeireden.

Die Wand: fp8 läuft auf Apple Silicon nicht

Die gängigen Bildmodelle (FLUX, Stable Diffusion 3.5) lädt man heute fast immer als fp8-Variante herunter. fp8 ist ein 8-Bit-Gleitkomma-Format: es halbiert den Speicherbedarf gegenüber fp16 und läuft auf modernen NVIDIA-Karten in Hardware. Seit 2024 ist das der De-facto-Standard-Download.

Auf dem Mac crasht das beim Generieren mit einer eindeutigen Fehlermeldung:

TypeError: Trying to convert Float8_e4m3fn to the MPS backend
but it does not have support for that dtype.

Das ist kein Konfigurationsfehler, den man wegklickt. Es ist strukturell:

• Metal, Apples Grafik-Schicht, hat keinen nativen 8-Bit-Float-Typ.
• Apple Silicon hat keine fp8-Recheneinheiten (anders als NVIDIA Ada/Hopper).
• Das PyTorch-MPS-Backend, über das die meisten Tools (ComfyUI, Automatic1111) auf die Mac-GPU zugreifen, unterstützt fp8 schlicht nicht.

Betroffen sind beide Hälften des Modells, der Diffusions-Transformer und der Text-Encoder. Beide müssen in fp16/bf16 oder als GGUF-Quant vorliegen, damit überhaupt etwas rechnet.

Warum mehr Hardware das Problem nicht löst

Der erste Reflex ist: dann nehme ich eben das große Modell, ich habe ja 128 GB. Aber das ist der falsche Weg. Das Problem ist nicht "zu wenig Speicher", sondern "die GPU spricht dieses Zahlenformat nicht". 128 GB RAM helfen nicht, wenn die Recheneinheit das Format nicht kennt.

Und eine baldige Lösung von PyTorch-Seite ist unwahrscheinlich. Das zuständige GitHub-Issue (#132624) ist seit August 2024 offen, eingeordnet, aber ohne zugesagten Fahrplan. Selbst wenn fp8-Support käme: mangels passender Hardware würde er emuliert, also intern auf bf16 hochgerechnet. Damit wäre der eigentliche Vorteil von fp8 (weniger Speicher, mehr Speed) auf dem Mac sowieso weg.

Es gibt Community-Hacks (eigene Metal-Kernel), aber keinen offiziellen, verlässlichen Weg. Für ein Werkzeug, das im Geschäftsalltag einfach funktionieren soll, ist das nichts.

Der Umweg, der auch nicht der richtige war

Der naheliegende Workaround: das fp8-Modell gegen eine fp16/bf16-Variante tauschen und in ComfyUI weiterarbeiten. Das funktioniert, FLUX.1-schnell in bf16 läuft. Aber es bleibt ein Gefühl, dass man das NVIDIA-Ökosystem mit Mühe auf den Mac biegt: PyTorch ist hier der Gast, nicht der Hausherr.

Der eigentliche Aha-Moment kam erst danach.

Der Apple-Weg: MLX statt PyTorch

MLX ist Apples eigenes Machine-Learning-Framework, gebaut für Apple Silicon. Es quantisiert nativ in int4 und int8, kennt also das fp8-Problem gar nicht erst, weil es einen anderen, hardwaregerechten Weg geht. Für Bildgenerierung gibt es zwei praktikable Wege:

• Draw Things: eine GUI-App auf MLX-Basis. Der bequemste Einstieg, deutlich schneller als der Umweg über GGUF.
• mflux: ein zustandsloses Kommandozeilen-Werkzeug. Kein Server, kein Hintergrundprozess. Es lädt das Modell pro Aufruf, generiert das Bild, schreibt die Datei, fertig. Genau das, was sich sauber in eigene Skripte und Automatisierungen einbauen lässt.

Die Installation ist ein Einzeiler (uv tool install mflux), der Aufruf ein Kommando mit Prompt, Modell und Ausgabepfad:

mflux-generate-z-image \
  --model Tongyi-MAI/Z-Image-Turbo \
  -q 8 \
  --prompt "ein ruhiges Yoga-Studio im Morgenlicht, fotorealistisch" \
  --steps 8 \
  --height 1024 --width 1024 \
  --output bild.png

Kein fp8, kein MPS-Drama. Das Modell lädt beim ersten Lauf automatisch herunter, danach entsteht jedes Bild in rund 17 Sekunden. Weil mflux ein reines Kommandozeilen-Werkzeug ist, lässt es sich auch von anderen lokalen Werkzeugen ansteuern: Ich rufe es zum Beispiel aus meinem eigenen Bild-Skript heraus auf, und genauso kann ein lokal gehostetes Sprachmodell (etwa über LM Studio) den Aufruf zusammenbauen und ausführen. Damit bleibt die ganze Kette lokal: das Sprachmodell, das den Prompt formuliert, und das Bildmodell, das ihn umsetzt. Kein einziger Cloud-Dienst ist beteiligt.

Welches Modell, und darf ich die Bilder geschäftlich nutzen?

Das ist der Punkt, der für ein Unternehmen wichtiger ist als die letzten zehn Prozent Bildqualität: die Lizenz. Nicht jedes frei herunterladbare Modell darf man kommerziell einsetzen.

Modell	Größe	Lizenz	Einordnung
Z-Image-Turbo	6B	Apache 2.0	Frei kommerziell. Photoreal, ~17s/Bild auf M5 Max. Mein Daily-Default.
FLUX.2-klein-4B	4B	Apache 2.0	Frei kommerziell, am schnellsten (~8s). Etwas weicher.
FLUX.1-schnell	~12B	Apache 2.0	Frei kommerziell, wenige Steps.
Qwen-Image	20B	Apache 2.0	Frei kommerziell. Stark bei Text im Bild, aber ~3 min/Bild.
FLUX.2-klein-9B	9B	Non-Commercial	Optisch top, aber nur privat nutzbar.
FLUX.2-dev	32B	Non-Commercial	Flaggschiff, aber ~35 min/Bild lokal. Ein Cloud-Job, kein Mac-Job.

Die FLUX-dev-Lizenz erlaubt zwar die Bilder kommerziell, formuliert den Modellbetrieb selbst aber als nicht-kommerziell und erzeugt damit eine Grauzone, sobald man damit Assets fürs eigene Geschäft oder für Kunden erzeugt. Für veröffentlichte oder verkaufte Visuals verlasse ich mich nicht auf eine Grauzone. Ich nehme ein sauber Apache-lizenziertes Modell, und das ist aktuell Z-Image-Turbo (von Alibabas Tongyi Lab): kommerziell unbedenklich, photoreal, und mit rund 17 Sekunden pro Bild schnell genug für den Alltag.

Wann lohnt sich lokal, wann nicht

Lokale Bildgenerierung ist kein Selbstzweck. Sie lohnt sich, wenn einer dieser Punkte zählt:

• Datenschutz: Prompts und Ergebnisse bleiben auf der Maschine. Kein Drittanbieter, keine Frage, was mit den Eingaben passiert.
• Laufende Kosten: kein Abo, keine Pro-Bild-Abrechnung. Nach dem Setup kostet jedes weitere Bild nur Strom.
• Integration: ein zustandsloses CLI wie mflux lässt sich direkt in eigene Abläufe einbauen, etwa um automatisch Bilder in der richtigen Größe für verschiedene Kanäle zu erzeugen.

Dagegen spricht:

• Maximale Qualität: das absolute Spitzenmodell (FLUX.2-dev) ist lokal auf dem Mac unbrauchbar langsam. Wer genau das braucht, ist mit einer Cloud-API besser bedient.
• Gelegentliche Nutzung: wer drei Bilder im Monat braucht, für den lohnt das Setup nicht. Da ist ein bezahlter Dienst günstiger als die investierte Zeit.

Die eigentliche Lektion

Auf Apple Silicon ist der Flaschenhals oft nicht das Silizium, sondern das Format und das Framework. Der Standard-Download aus dem Netz (fp8, für NVIDIA gedacht) ist auf dem Mac eine Sackgasse. Der saubere Weg führt über Apples eigenes Werkzeug MLX, nicht über das mühsam angepasste NVIDIA-Ökosystem.

Das ist genau die Art Detail, die einen Abend kostet, wenn man es nicht weiß, und fünf Minuten, wenn man es weiß. Wenn du überlegst, KI lokal und DSGVO-konform in deinem Betrieb einzusetzen, und vorher wissen willst, was wirklich funktioniert und was nur in der Anleitung steht: dann lass uns reden. In einem kostenlosen Mini-Audit schauen wir gemeinsam, wo bei dir der Hebel sitzt: axons.at/audit.