Stable Diffusion 3.5 Large auf dem Prüfstand: So lässt sich die Befolgung von Prompts messen

Welche Frage dieser Benchmark beantwortet

Bei einer Evaluation der Prompt-Befolgung geht es darum, ob ein generiertes Bild die in einer Anweisung verlangten Elemente enthält und ob diese mit den angegebenen Merkmalen und Beziehungen dargestellt werden. Allein beantwortet eine solche Prüfung nicht, ob das Ergebnis schön, originell oder für jeden denkbaren Einsatz geeignet ist. Ebenso wenig erlaubt sie ein allgemeines Urteil, welches Modell „besser“ ist: Sie beschreibt das Verhalten eines Modells bei einer bestimmten Aufgabenauswahl, mit einer konkreten Konfiguration und nach einer festgelegten Bewertungsmethode.

Für Stable Diffusion 3.5 Large könnte die praktische Frage lauten: Wie häufig erfüllen die erzeugten Bilder überprüfbare Vorgaben, etwa drei Objekte zu enthalten, eines links von einem anderen zu platzieren oder ein bestimmtes Wort zu zeigen? Der vorgeschlagene Vergleich mit Stable Diffusion 3.5 Medium ist als neue Prüfung zu verstehen. Die hier verfügbaren Quellen enthalten weder verifizierte quantitative Ergebnisse noch ein vollständiges Protokoll, auf dessen Grundlage sich bereits eine Rangfolge aufstellen ließe.

Eine Modellseite, eine Softwareanleitung oder eine visuelle Demonstration kann dabei helfen, eine Implementierung zu identifizieren oder in Betrieb zu nehmen. Sie ersetzt jedoch keine kontrollierte Evaluation. Dieser Artikel erläutert daher, wie sich Evidenz erheben und berichten lässt. Er schreibt weder Large noch Medium einen Punktwert für die Prompt-Befolgung zu.

Was verifiziert ist – und was weiterhin offenbleibt

Stability AI kündigt die Verfügbarkeit von Stable Diffusion 3.5 Large und Inferenzcode an. Die im Stability-AI-Namensraum auf Hugging Face gehostete Modellkarte identifiziert Large als Text-zu-Bild-Modell und beschreibt es als Multimodal Diffusion Transformer. Diese Angaben helfen, Modell und Herkunft einzuordnen. Die verfügbaren Auszüge enthalten jedoch keine Messwerte zur Befolgung von Anweisungen.

Die Dokumentation von Amazon Bedrock beschreibt ein Angebot für SD 3.5 Large mit acht Milliarden Parametern und einer Ausgabe von einem Megapixel. Diese Angabe bezieht sich auf die Dokumentation und Konfiguration dieser Plattform; sie darf nicht automatisch auf jede Implementierung übertragen und nicht als Qualitätsnachweis interpretiert werden. Ein vLLM-Rezept nennt innerhalb der Modellfamilie eine Medium-Variante mit 2,5 Milliarden Parametern und Large mit 8,1 Milliarden Parametern. Auch die Kenntnis dieser Größen belegt nicht, welche Variante Prompts besser befolgt.

Das Repository von Stability AI bezeichnet sich als Referenzimplementierung mit Schwerpunkt auf Inferenz. Vorhandener Code erleichtert die Untersuchung eines Ausführungswegs, legt aber nicht von selbst die geeigneten Parameter für einen Vergleich fest. Informelle Tests, die auf Reddit geteilt werden, sind ebenfalls nur anekdotische Erfahrungsberichte: Sie können Anregungen für weitere Untersuchungen liefern, ersetzen aber keinen Testsatz mit vorab festgelegten Kriterien.

Die methodische Schlussfolgerung ist begrenzt, aber wichtig: Auf Grundlage der hier vorgelegten Evidenz lässt sich weder sagen, welches Modell bei der Prompt-Befolgung besser abschneidet, noch wie groß der Unterschied zwischen Large und Medium ist oder welche Konfiguration vergleichbare Ergebnisse erzeugt hat. Dass solche Daten in diesem Quellenbestand fehlen, beweist nicht, dass es anderswo keine veröffentlichten Evaluationen gibt. Es bedeutet, dass hier keine Ergebnisse behauptet werden sollten, die nicht überprüft wurden.

Prompts so gestalten, dass Anforderungen überprüfbar sind

Der Testsatz sollte die Befolgung von Anweisungen in beobachtbare Dimensionen aufteilen, statt sich auf einen allgemeinen Gesamteindruck zu stützen. Sinnvolle Kategorien sind das Vorhandensein von Objekten, ihre Anzahl, räumliche Beziehungen, visuelle Attribute und angeforderter Text. Für jeden Prompt muss vor der Bilderzeugung feststehen, welche Anforderung bewertet wird und was als erfüllt gilt. Lässt eine Formulierung mehrere Deutungen zu, sollte sie überarbeitet oder als mehrdeutig gekennzeichnet werden, statt die Auslegung erst nach Betrachtung des Ergebnisses festzulegen.

Die Auswahl sollte sowohl einfache Fälle als auch anspruchsvollere Kombinationen abdecken. Ein Prompt kann beispielsweise zwei Tassen verlangen, ein anderer eine rote Tasse links neben einem blauen Buch und ein weiterer eine Szene mit einem Schild, auf dem ein bestimmtes Wort lesbar sein soll. Das sind Beispiele für die Gestaltung eines Prüfverfahrens, keine Ergebnisse, die einem der Modelle zugeschrieben werden. Die Anweisungen sollten irrelevante Einzelheiten vermeiden, die es erschweren, einen Fehler einer konkreten Anforderung zuzuordnen.

Die Kategorien sollten ausgewogen sein und ihre Zusammensetzung sollte dokumentiert werden. Gibt es viele Prompts zur Objekterkennung, aber nur wenige zu Text, kann ein Gesamtwert sehr unterschiedliche Leistungen verdecken. Ausschlussregeln sollten ebenfalls vorab feststehen: etwa, ob Text nur bewertet wird, wenn er deutlich sichtbar ist, oder ob typografische Abweichungen zulässig sind. Prompts dürfen nicht entfernt werden, nur weil ihre Ergebnisse einer erwarteten Schlussfolgerung entgegenstehen.

Ausführungsbedingungen festlegen

Vor der Generierung sollten die genaue Modell- und Gewichtsidentifikation sowie die Softwareversion, die Implementierung und alle Änderungen an der Pipeline dokumentiert werden. Ebenfalls zu veröffentlichen sind Auflösung, Schrittzahl, Guidance-Parameter, numerische Präzision, Hardware und Beschleunigungsoptionen. Verbirgt eine Plattform einen Teil dieser Angaben, muss dies offengelegt und die Schlussfolgerung entsprechend eingeschränkt werden.

Seed und Anzahl der Generierungen pro Prompt müssen dokumentiert sein. Ein einziges Bild pro Anweisung kann dazu führen, dass eine zufällige Variation das Ergebnis dominiert; mehrere Generierungen machen diese Variabilität sichtbar, verursachen aber höhere Kosten. Das Prüfverfahren sollte vor der Sichtung der Ergebnisse festlegen, wie viele Stichproben erzeugt werden, und dieselbe Regel auf beide Modelle anwenden. Für eine interpretierbare Gegenüberstellung sollte außerdem angegeben werden, ob die Seeds zwischen den Modellen paarweise verwendet wurden und was diese Paarung in den jeweiligen Implementierungen bedeutet.

Es reicht nicht aus, dieselbe Auflösung oder Schrittzahl anzugeben, wenn Large und Medium mit unterschiedlichen Pipelines ausgeführt werden. Der sauberste Vergleich übernimmt alle gemeinsam nutzbaren Parameter und veröffentlicht jede unvermeidbare Abweichung. Erzwingen Speicherbeschränkungen Änderungen an Präzision, Batch-Größe oder anderen Optionen, gehören diese Unterschiede in die Beschreibung. Sie können verhindern, dass das Ergebnis allein dem Modell zugeschrieben wird.

Anforderungen bewerten und verblindete Prüfer einsetzen

Die wichtigste Bewertungseinheit sollte die überprüfbare Anforderung sein. Für jedes Bild können Bewertende markieren, ob das Objekt vorhanden ist, die Anzahl stimmt, das verlangte Attribut dargestellt wird, die räumliche Beziehung erfüllt ist und der Text lesbar ist und mit der Vorgabe übereinstimmt. Eine binäre Skala erleichtert die Auszählung. Eine zusätzliche Kategorie „nicht bewertbar“ kann jedoch für beschädigte Bilder oder tatsächlich mehrdeutige Anweisungen erforderlich sein. Die Regeln für diese Kategorie müssen vor der Sichtung der Ergebnisse festgelegt werden.

Bei der menschlichen Bewertung sollte verborgen bleiben, welches Modell das jeweilige Bild erzeugt hat; außerdem sollte die Reihenfolge der Bilder gemischt werden. Die Bewertenden benötigen gemeinsame Anweisungen, Beispiele für die Anwendung der Rubrik und eine Möglichkeit, Unsicherheiten zu dokumentieren. Empfehlenswert ist der Einsatz mehrerer Personen sowie die Veröffentlichung von Übereinstimmungen und Abweichungen. Häufen sich Meinungsverschiedenheiten, sind die Anforderungen möglicherweise nicht präzise genug definiert. Abweichende Bewertungen dürfen nicht stillschweigend aufgelöst und ein Konsens nicht als absolute Gewissheit dargestellt werden.

Automatische Metriken können unterstützend eingesetzt werden, sind aber kein universeller Ersatz für die Beurteilung sämtlicher Anforderungen. Vor ihrem Einsatz muss erklärt werden, was sie messen, auf welche Fälle sie angewandt werden und wie sie anhand einer von Menschen geprüften Stichprobe überprüft wurden. Ein allgemeines Ähnlichkeitsmaß belegt für sich genommen weder, dass genau drei Objekte vorhanden sind, noch dass eines links von einem anderen liegt oder ein Wort korrekt lesbar ist. Wurde eine Metrik für eine Dimension nicht validiert, muss der Bericht dies kenntlich machen, statt sie als Schiedsrichter zu behandeln.

Large und Medium vergleichen, ohne Ergebnisse falsch zuzuschreiben

Der Vergleich sollte mit denselben Prompts und derselben Rubrik beginnen. Soweit die Implementierungen es zulassen, sind Auflösung, Zahl der Generierungen, Inferenzparameter und Bewertungsbedingungen anzugleichen. Für jede Anforderung sollten die Ergebnisse pro Modell und Kategorie dargestellt werden, zusammen mit der Zahl der Stichproben und einer Beschreibung der Variabilität – nicht nur als allgemeiner Durchschnitt.

Gleiche Werte in einer Parametertabelle garantieren nicht, dass die Ausführungen gleichwertig sind, wenn sich Pipeline, Präzision, Sampling-Optionen oder Software unterscheiden. Jede Abweichung muss daher sichtbar sein. Lässt sich ein wichtiger Unterschied nicht kontrollieren, sollte der Bericht von einem Vergleich zweier vollständiger Konfigurationen sprechen und nicht von einem isolierten Nachweis, dass Modellgröße oder Modellvariante das Ergebnis verursacht hat.

Noch nicht ausgeführte Felder dürfen nicht mit angenommenen Werten ausgefüllt werden. Der Bericht kann das geplante Verfahren veröffentlichen und die Ergebnisse als ausstehend kennzeichnen. Sobald Daten vorliegen, muss jede Schlussfolgerung mit dem Testsatz, der Konfiguration und der Bewertungsrubrik verknüpft sein, auf denen sie beruht. Die vorgeschlagene Evaluation erlaubt keine Vorhersage, ob Large bei der Befolgung von Anweisungen besser abschneiden wird als Medium.

Kontamination, Stichprobenauswahl und Grenzen

Ein Benchmark kann verzerrt sein, wenn die Prompts öffentlich sind, häufig in Demonstrationen verwendet wurden oder Beispielen ähneln, denen das System während seiner Entwicklung begegnet ist. Ohne Zugang zu Informationen über Trainingsdaten lässt sich eine frühere Exposition nicht immer bestätigen oder ausschließen. Das Evaluationsteam kann Risiken senken, indem es eigens für die Prüfung formulierte Prompts bis zur Durchführung zurückhält und den Testsatz erst danach veröffentlicht. Solche Maßnahmen sind jedoch als teilweise Kontrollen zu beschreiben, nicht als Beweis dafür, dass keine Kontamination vorliegt.

Auch die Auswahl und Präsentation nur der überzeugendsten Bilder führt zu Verzerrungen. Um das zu vermeiden, sollten alle im Voraus festgelegten Generierungen erhalten bleiben und Ausschlussregeln vorab definiert werden. Beispielgalerien können Fehler oder Erfolge veranschaulichen, ersetzen aber keine vollständigen Auszählungen. Ein einzelner Seed, eine nachträgliche manuelle Auswahl oder eine Kategorie mit nur wenigen Fällen kann einen irreführenden Eindruck vermitteln.

In jeder Bewertungsrubrik stecken menschliche Entscheidungen: Was gilt als hinreichend erfüllte räumliche Beziehung? Wann ist Text lesbar? Wie viel Detail muss vorhanden sein, damit ein Attribut als erfüllt zählt? Deshalb sind operationale Definitionen, unabhängige Bewertungen und die Berichterstattung über Meinungsverschiedenheiten erforderlich. Ergebnisse aus anderen Testsätzen, Konfigurationen oder Methoden dürfen nicht ohne Weiteres zusammengeführt werden. Unterscheiden sich Aufgaben und Messregeln, beschreibt die Zahl nicht notwendigerweise dasselbe Phänomen.

Checkliste zur Veröffentlichung des Benchmarks

Eine nützliche Evaluation sollte anderen ermöglichen, das Verfahren zu wiederholen und seine Grenzen zu verstehen – selbst wenn sie nicht exakt dieselben Bilder erhalten. Das veröffentlichte Material sollte Prompts, Ein- und Ausschlusskriterien, Seeds, Anzahl der Generierungen, Versionen und Konfigurationen sowie die erzeugten Bilder enthalten. Werden Bilder nicht bereitgestellt, ist klar zu erläutern, warum. Ebenfalls nötig sind die Bewertungsrubrik, Bewertungsformulare, das Verfahren zur Verblindung und aufgeschlüsselte Ergebnisse nach Dimension.

Der Bericht sollte beobachtete Tatsachen, methodische Entscheidungen und Interpretationen auseinanderhalten. Eine Anzahl von Bewertungen ist beispielsweise ein Ergebnis der Durchführung. Die Definition dessen, was als „erfüllte räumliche Beziehung“ gilt, ist eine Entscheidung der Rubrik. Die Behauptung, ein Unterschied gehe auf das Modell zurück, ist eine Interpretation, für die vergleichbare Bedingungen und ausreichende Evidenz erforderlich sind. Diese Trennung hilft Lesenden, eine Empfehlung zum Prüfverfahren nicht mit einem bereits gemessenen Ergebnis zu verwechseln.

Bis eine solche Prüfung veröffentlicht und reproduziert wurde, ist es verantwortungsvoll, Stable Diffusion 3.5 Large und Medium als Varianten zu behandeln, die unter ausdrücklich beschriebenen Bedingungen evaluiert werden müssen – nicht als Gewinner oder Verlierer eines Benchmarks zur Prompt-Befolgung. Der Benchmark-Index kann als redaktioneller Kontext dienen, und die Evaluationsseite zu SD 3.5 Large als Referenz für die Prüfung, sofern ausstehende Ergebnisse nicht als Messwerte dargestellt werden. Die praktische Schlussfolgerung ist einfach: Erst die Methode veröffentlichen, bevor die Bilder interpretiert werden, und die Daten zusammen mit jedem Punktwert zugänglich machen.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.