Ideogram 4 auf DGX Spark: Schöne Bilder, falsche Hardware

Wer DGX-Spark-Klasse-Hardware für lokale Textinferenz betreibt, fragt irgendwann, was dieselbe Hardware mit Bildgenerierung macht. Textmodelle haben wir bereits durchgemessen: Laufzeiten, Frameworks, praktische Grenzen. Jetzt geht es um Bild-KI: Ideogram 4 als FP8-Modell, 2048x2048 Pixel, drei Qualitätsmodi, eigene Benchmarkläufe.

Das Ergebnis ist eindeutig: Ideogram 4 erzeugt auf dieser Hardware schöne Bilder. Der Haken liegt nicht in der Bildqualität. Er liegt in der Laufzeit: Auf DGX Spark und ASUS GX10 ist dieser Workload eher ein Lab-Nachweis als ein Produktionspfad.

Setup: Ideogram 4 FP8 auf DGX-Spark-Hardware

Das Modell ist Ideogram 4 FP8 auf Hugging Face, bereitgestellt über ein lokales Gateway im Tailscale-Netz. Ideogram 4 wurde am 3. Juni 2026 als erstes Open-Weight-Text-zu-Bild-Modell von Ideogram veröffentlicht. Die öffentlichen Gewichte stehen unter dem Ideogram Non-Commercial Model Agreement, während der Inferenzcode im GitHub-Repository Apache-2.0-lizenziert ist. Es ist kein öffentlicher Endpoint und kein geteilter Dienst. Die Inferenzmaschine ist ein ASUS Ascent GX10, also DGX-Spark-Klasse mit NVIDIA GB10 Grace Blackwell Superchip und 128 GB Unified Memory.

Der Benchmark lief am 12.-13. Juni 2026 über Nacht. Zehn ausgewählte Prompts, je drei Qualitätsmodi, fixer Seed 77, Auflösung 2048x2048. Ergebnis: 30 von 30 Jobs abgeschlossen, kein einziger Fehler. Das ist das erste direkt nutzbare Resultat: Das Modell läuft stabil auf dieser Hardware, ohne Absturz, ohne Quantisierungsartefakt, ohne Memory-Overflow.

Die Prompts lagen zunächst als normale Plaintext-Anweisungen vor. Der Runner verpackte diesen Plaintext für jeden Lauf in eine API-JSON-Payload mit Prompttext, Breite, Höhe, Qualitätsmodus und Seed. Das ist nicht Ideograms natives json_prompt-Interface mit typisierten Text-Elementen und Bounding-Boxes. Für die Texttreue-Ergebnisse, vor allem beim Bäckerei-Motiv, ist das eine relevante Einschränkung. Die Antwort des lokalen Gateways lieferte Laufzeit und Bild-URL; danach wurden Originalbild und Messwerte lokal als PNG plus JSONL gespeichert.

Die drei Qualitätsmodi

Ideogram 4 bietet drei Diffusionsmodi, die sich in der Anzahl der Schritte unterscheiden:

• Turbo (12 Schritte): ca. 342-351 Sekunden pro 2048px-Bild
• Default (20 Schritte): ca. 561-576 Sekunden pro 2048px-Bild
• Quality (48 Schritte): ca. 1.329-1.363 Sekunden pro 2048px-Bild

In konkreten Zahlen: Turbo liegt bei knapp sechs Minuten, Default bei rund neun bis zehneinhalb Minuten, Quality bei gut 22 Minuten. Wer 30 Bilder in allen drei Modi erzeugen will, plant die Rechenzeit in Stunden, nicht in Minuten.

Das ist kein Benchmark-Artefakt und kein einzelnes Konfigurationsproblem. DGX Spark ist für Textinferenz mit grossen Modellen konzipiert. Das heisst viel gemeinsam nutzbarer Speicher, grosse Modellgrössen, lange Kontexte. Bildmodelle wie Ideogram 4 profitieren dagegen stark von klassischer CUDA-GPU-Leistung, hoher Speicherbandbreite und einem Stack, der auf Diffusions-Workloads optimiert ist. Wenn Datenhoheit nicht zwingend lokale Ausführung verlangt, liefert eine Cloud-API dasselbe praktische Ergebnis deutlich schneller.

Der NF4-Vorlauf vom 11. Juni bleibt deshalb nur Kontext, kein Variantenurteil. Er zeigt, dass auch die stärker quantisierte Variante auf dieser Hardware grundsätzlich läuft. Ob NF4 gegenüber FP8 für diesen Workload die bessere Alltagswahl ist, müsste ein eigener Direktvergleich mit identischen Prompts, identischer Auflösung und gleicher Messmethodik zeigen.

Vergleich 1: Oktopus: pure Fotorealismus-Probe

Der erste Testprompt beschreibt ein Unterwasserfoto: ein einzelner gemeiner Oktopus (Octopus vulgaris), rotbraun mit texturierter Haut, über einem Korallenriff, Lichtstrahlen von oben, Tiefblau im Hintergrund. Kein Text, kein Logo, keine Schriftzeichen: die reine Qualitätsfrage.

Bei einem Motiv ohne Textelemente sieht Turbo bereits überzeugend aus. Default verbessert die Detailschärfe und die Lichtbrechung im Wasser spürbar. Quality liefert nochmals mehr Texturtiefe in der Oktopushaut. Ob der Mehraufwand von 16 Minuten Rechenzeit im Vergleich zu Turbo gerechtfertigt ist, hängt vom konkreten Verwendungszweck ab. Für redaktionelle Illustrationen wäre Default in diesem Fall die praktischere Wahl.

Was auffällt: Die Bildkomposition bleibt über alle drei Modi stabil (identischer Seed), die Positionierung des Tiers, der Korallenhintergrund und die Lichtrichtung variieren kaum. Das ist ein nützliches Merkmal für iteratives Arbeiten: Wer mit Turbo eine Komposition findet und dann für die Publikation auf Default upgradet, bekommt kein grundlegend anderes Bild.

Vergleich 2: Bäckerei Nußbaumer: Deutschsprachiger Text als Stresstest

Der zweite Prompt ist gezielt ein Stresstest für Texttreue: Eine 1930er-Jahre-Bäckerei in einem deutschen Dorf, Schaufenster mit Schriftzeichen, die den exakten Text „Bäckerei Nußbaumer“ zeigen sollen, inklusive Umlaut ä und ß.

Das historische Ambiente überzeugt: Fachwerkhäuser, Kopfsteinpflaster, zeitgemässe Kleidung und warmes Mittagslicht sitzen. Die Schaufensterkomposition ist klar, der Laden wirkt lebendig.

Bei der konkreten Schriftzeichengenauigkeit ist das Ergebnis gemischt. Sonderzeichen wie ä und ß sind für Diffusionsmodelle generell schwierig; das Modell zeigt in den getesteten Varianten unterschiedliche Grade der Texttreue. Default liefert hier spannenderweise die beste Lesbarkeit. Für Motive, bei denen exakte Schriftzeichenwiedergabe produktionskritisch ist, bleibt nachträgliche Texteinbindung im Grafikprogramm der sicherere Weg. Für illustrative Zwecke, wo das Ambiente und nicht der genaue Wortlaut zählt, ist das Ergebnis brauchbar.

Wie eingangs erwähnt, kann man bei strikter Anwendung des Ideogram 4 nativen json vermutlich bessere Textergebnisse erzielen!

Vergleich 3: Lufthansa 747: Objekt-, Livery- und Historik-Detail

Der dritte Prompt verlangt historische Präzision. Er beschreibt eine Boeing 747 in Lufthansa-Lackierung aus den frühen 1970er Jahren, einen Landeanflug in Miami, zeitgenössische Flughafeninfrastruktur und den Ausschluss moderner Fahrzeuge oder fremder Logos. Der Prompt dient als Benchmark, nicht als Markenaussage.

Die 747-Silhouette wird von Ideogram 4 gut erkannt: Buckel, Fahrwerk, Flügelgeometrie. Auch die historische Lackierung ist in allen drei Modi erkennbar: weisse Oberseite, dunkelblaues Leitwerk, gelber Kranichkreis. Die Detailschärfe der Livery steigt mit den Modi. Turbo zeigt eine plausible, etwas weiche Lackierung; Default schärft die Streifenführung; Quality liefert das beste Leitwerk-Detail.

Kein Modus gibt aber den Kranich am Rumpf der Maschine korrekt wieder. Das ist bei einem Logo auf einem Flugzeug in der Szene auch kein realistisches Ziel für ein Diffusionsmodell. Das Bild taugt als Illustrations- und Stimmungsbild, nicht als Identifikations- oder Dokumentationsquelle für Marken-Details.

Was dieser Befund über lokale Bild-KI-Hardware sagt

Das eigentliche Ergebnis dieses Tests ist kein Qualitätsurteil über Ideogram 4. Das Modell liefert starke Bilder. Die Architekturaussage ist nüchterner: Hardware, die für lokale LLM-Inferenz interessant ist, ist nicht automatisch auch die beste Maschine für lokale Bildgenerierung.

Konkret heisst das: Die NF4-Variante ist der 24-GB-Pfad. Auf Karten wie RTX 3090 oder RTX 4090 ist Einzelbild-Inferenz damit realistisch; Batch-Grössen über 1 werden auf 24 GB aber schnell eng. Eine RTX 5090 bringt 32 GB GDDR7 und Blackwell-FP8-Unterstützung mit und ist deshalb die naheliegendere Consumer-Klasse für Experimente. Für FP8 und belastbare Batch-Inferenz ist eher 40- bis 80-GB-GPU-Klasse relevant, etwa A100/H100 oder vergleichbare Workstations.

Für die wenigen Fälle, in denen Datensouveränität wirklich nicht verhandelbar ist, etwa sensible Personenbilder, interne Produktentwürfe oder regulatorisch geschützte Inhalte, kann lokale Ausführung trotz der Laufzeiten das einzig gangbare Modell sein. Dann ist ein Overnight-Batch-Setup eine akzeptable Lösung, aber keine allgemeine Empfehlung.

Was lokal immer gilt und sich nicht durch Hardware-Wahl wegdiskutieren lässt: Prompt-Engineering bleibt Arbeit. Die Texttreue-Grenzen bei Sonderzeichen und Logos sind keine reine lokale Einschränkung; sie betreffen viele aktuelle Diffusionsmodelle auch dann, wenn sie auf schnellerer Hardware laufen.

Für eine ausführlichere Einordnung, wie Benchmarks auf dieser Hardware-Klasse methodisch zu lesen sind, empfiehlt sich unser Artikel zu lokalen LLM-Benchmarks und Messlogik.

Fazit: Schöne Bilder, falsche Hardware

Ideogram 4 kann beeindruckende Bilder erzeugen. Das steht nach diesem Benchmark nicht in Frage. Der harte Befund ist die Laufzeit auf Spark/GX10, nicht die visuelle Qualität des Modells.

Fünfeinhalb bis sechs Minuten pro Bild im Turbo-Modus, knapp zehn Minuten mit Default, gut 22 Minuten mit Quality: Das ist für gelegentliche Lab-Läufe akzeptabel, für regelmässige Bildproduktion aber unattraktiv. Wer lokal arbeiten will, sollte die Hardwarefrage konkret stellen: NF4 passt in die 24-GB-Klasse für Einzelbilder; FP8 und Batch-Workloads gehören eher auf 40 bis 80 GB VRAM oder in eine Cloud-API.

Der Wert dieses Tests liegt nicht darin, einen produktionsreifen Stack gefunden zu haben. Er liegt darin, die Grenze klar zu ziehen: Was für LLM-Inferenz eine überzeugende lokale Lösung ist, muss für Bild-KI noch lange nicht funktionieren. Wer auf Basis des DGX-Spark-Setups lokale Bildgenerierung plant, sollte diese Laufzeiten nicht als temporäres Problem behandeln, das sich mit besserer Konfiguration lösen lässt; sie gehören zu dieser Hardware-Klasse bei diesem Workload.

Kurz: Ideogram 4 ist lokal spannend. Spark/GX10 beweist, dass es läuft. Für schnelle Bildproduktion ist aber eine klassische High-VRAM-CUDA-GPU oder ein Bildgenerierungsdienst der realistischere Weg.