Kategorie: Erklärer

Wie verdienen persönliche KI-Agenten eigentlich Geld? Tanay Jaipuria, Partner bei der Wagniskapitalgesellschaft Wing, hat das in seinem Newsletter aufgeschrieben. Vier Wege beschreibt er, auf denen ein persönlicher Agent Geld verdienen kann, und zwei davon rechnet er durch.

Man kann sich das wie einen Reiseleiter vorstellen. Er führt durch eine fremde Stadt, kostet den Reisenden nichts und bekommt von den Läden, in die er seine Gruppe bringt, eine Vergütung. Je besser er die Stadt kennt und je genauer er einschätzen kann, was seine Leute suchen, desto wertvoller wird er für beide Seiten. Genau in dieser Doppelrolle steckt die Monetarisierung von KI-Agenten im Handel.

Längst keine Zukunftsfrage mehr, denn personalisierte KI-Agenten machen nicht mehr nur Vorschläge. Noah Shinn, Gründer von Instinct, sagt laut Jaipuria, sein Unternehmen wickele bereits ein annualisiertes Handelsvolumen von über einer Milliarde Dollar ab, die Hälfte davon im Reisebereich. Mark Zuckerberg hat bei Muse Connect gesagt, sein Agent solle möglichst kostenlos bleiben und über eine kleine Gebühr pro Transaktion Geld verdienen.

Vier Wege, auf denen ein persönlicher Agent Geld verdienen kann

Jaipuria unterscheidet vier Modelle. Beim Abo zahlt der Nutzer eine wiederkehrende Gebühr für die Nutzung des Agenten. Bei der Convenience-Gebühr zahlt der Kunde zusätzlich zum Kaufpreis einen Betrag an den Agenten, pauschal oder als Prozentsatz der Transaktion.

Die beiden anderen Modelle drehen das Verhältnis um. Bei Händler- und Partnergebühren zahlt der Verkäufer, ein Aggregator oder ein Zahlungsdienstleister dem Agenten für die geleistete Vermittlung. Bei der Werbung zahlen Händler dafür, dass ihr Angebot überhaupt in Betracht gezogen wird. Jaipuria konzentriert sich auf die letzten beiden Varianten, weil sie sich am interessantesten beziffern lassen: Wie viel kann ein Agent aus Transaktionsgebühren und Werbung tatsächlich ziehen?

Was Plattformen im Handel üblicherweise behalten

Dafür hilft ein Blick auf die Take Rate, also den Anteil des Handelsvolumens, den eine Plattform oder ein Kanal für sich behält. Die Spanne ist weit: von null Prozent, wenn jemand über einen gewöhnlichen Browser einkauft, bis zu rund 30 Prozent beim Kauf über den Apple App Store oder Steam. Irgendwo in dieser Spanne muss sich jeder Agent positionieren, und daraus folgt, wie viel er verlangen kann.

Was die Höhe bestimmt, ist eine Mischung aus mehreren Faktoren. Entscheidend ist erstens, welchen Wert der Vermittler im Ablauf des Kaufs stiftet. Zweitens, wie stark er an der Kundengewinnung beteiligt ist. Drittens, ob die Nachfrage ohne ihn überhaupt entstanden wäre. Viertens, wie viel Arbeit an Lieferung, Vertrauensbildung und Abwicklung nach der Bestellung er übernimmt. Und fünftens, wie gut die Alternativen sind, die ein Händler hätte, wenn er auf diesen Kanal verzichtet.

Je nachdem, was ein Agent aushandelt und um welche Art von Kauf es geht, kann er laut Jaipuria drei Rollen einnehmen: Kaufassistent, Affiliate oder Aggregator. Die Rolle entscheidet über die Höhe der Vergütung.

Vom Kaufassistenten über den Affiliate zum Aggregator

In der einfachsten Rolle als Kaufassistent reduziert der Agent vor allem Reibung. Wer ihn bittet, ein bestimmtes Hotel direkt auf der Seite des Hotels zu buchen, löst keine Vermittlungsleistung aus, und der Händler müsste streng genommen gar nichts zahlen. Denkbar ist laut Jaipuria aber eine Beteiligung an der Zahlungsgebühr, die ein Anbieter wie Stripe verdient; Stripe bietet berechtigten Connect-Plattformen schon heute eine Umsatzbeteiligung an. Jaipuria schätzt solche Anteile auf unter 0,5 Prozent, womöglich in der Größenordnung von 0,2 Prozent.

Weiter geht es mit Affiliate- und Empfehlungsprogrammen, die viele Händler und Aggregatoren bereits betreiben. Hier hilft der Agent bei der Entdeckung und beim Vergleich und leitet den Kauf an einen bestimmten Anbieter weiter. Dafür muss er direkte Beziehungen aufbauen oder sich in eine Vielzahl von Programmen einklinken. Verdient wird an der Provision, die für die Vermittlung fließt.

Als Aggregator übernimmt der Agent mehr Verantwortung und strebt einen größeren Teil der Marge an. Zum Vergleich: Booking behält laut Jaipuria etwa 14 bis 15 Prozent des Handelsvolumens, Affiliate-Provisionen landen bei rund fünf bis sieben Prozent. Diese Differenz ist der Anreiz, selbst für Bestandsverfügbarkeit, korrekte Preise, verlässliche Buchungen und den Support bei Änderungen zu sorgen und als Vertragspartner des Kunden aufzutreten.

Solche Verschiebungen sind dort leichter, wo der Wettbewerber vor allem digital arbeitet. Bei Marktplätzen mit viel physischer Arbeit, etwa Uber oder DoorDash, dürfte der Aufstieg zum Aggregator deutlich mühsamer sein. Und ein Teil des Handels bleibt ohnehin ohne Vertrag: Wer den Agenten bittet, ein konkretes Produkt bei einem konkreten Händler zu kaufen, erwartet, dass er das tut, auch ohne Provision.

Kategorien und Zusatznachfrage entscheiden über die Provision

Die veröffentlichten Affiliate-Sätze zeigen, wie stark das Geschäftsfeld die Marge prägt. Flüge liegen bei nahezu null Prozent, Lebensmitteleinkäufe bei Amazon bei etwa einem Prozent, Hotels über Expedia bei vier Prozent, Erlebnisse über Viator bei acht Prozent. Ein breit aufgestellter Agent verdient also nicht überall gleich viel.

Für Händler zählt vor allem, ob ein Kauf zusätzlich entsteht oder ohnehin passiert wäre. Wenn du heute ein Hotelzimmer über einen Agenten buchst, macht es für den Händler einen Unterschied, ob du vorher zwischen fünf Häusern geschwankt hast oder längst wusstest, wohin du willst. Kann ein Agent nachweisen, dass er den Nutzer zu genau diesem Produkt oder Händler geführt hat, lässt sich die Höhe der Provision eher halten. War es dagegen ein Auftrag zu einem bereits festgelegten Ziel, ist der Spielraum klein.

Agentenplattformen wie Muse können mit beiden Seiten arbeiten. Sie nutzen Aggregatoren für das lange Ende des Sortiments und gehen bei anderen Anfragen direkt auf die Händler zu. Jaipuria nennt als Beispiel Expedia auf der einen und Marriott auf der anderen Seite.

In einer Beispielrechnung zeigt Jaipuria, wie sich das entwickeln könnte: 0,2 Prozent Beteiligung an der Zahlungsabwicklung, vier Prozent netto aus Affiliate-Programmen und zwölf Prozent als Aggregator. Startet ein Agent überwiegend mit Zahlungsanteilen und einigen Affiliate-Deals, steigt die durchschnittliche Take Rate über die Zeit von etwa 0,8 auf zwei und später auf vier Prozent. Wichtig ist, dass es sich um Nettowerte handelt, denn der Agent wäre nicht selbst der Zahlungsabwickler.

Werbung als zweiter Hebel und als Vertrauensrisiko

Neben den Gebühren der Händler gibt es den Werbehebel. Hier zahlt ein Händler dafür, dass sein Angebot überhaupt in die Auswahl kommt, wenn jemand nach einem Hotel oder einem Paar Schuhe fragt. Als Orientierung dient das Verhältnis von Werbeerlösen zum Handelsvolumen etablierter Plattformen. Amazon ist in dieser Hinsicht am weitesten entwickelt, doch rund zwei Prozent des Handelsvolumens scheinen laut Jaipuria für viele Plattformtypen erreichbar.

Offen ist allerdings, ob es Werbung in dieser Form überhaupt geben wird und ob sie sich geschmackvoll umsetzen lässt. Ungefragte Kaufvorschläge dürften bei Nutzern schlecht ankommen, schreibt Jaipuria. Und der Agent steht im Dienst des Nutzers. Bezahlt zu werden, um ein Produkt zu wählen, das nicht das beste ist, verschärft den Interessenkonflikt zwischen Beauftragtem und Auftraggeber. Am saubersten wären Angebote, bei denen der Kunde einen Rabatt bekommt und der Agent mitverdient, ohne seine Auswahl zu ändern.

Jaipuria weist darauf hin, dass selbst ohne klassische Anzeigen ein bis zwei Prozent zusätzliche Take Rate im Raum stehen. Diesen Betrag hatten Händler für solche Transaktionen ohnehin eingeplant. Ob er als Anzeige, als Rabatt oder als höhere Vermittlungsgebühr auftaucht, ist eine Frage der Ausgestaltung.

Was das für Agentic Commerce bedeutet

Folgt man Jaipurias Rechnung, könnte ein persönlicher Agent für Nutzer weitgehend kostenlos sein und sich entlang der Wertschöpfungskette finanzieren, aus Provisionen, Zahlungsanteilen und Werbebudgets. Genau das hat Zuckerberg für Muse als Ziel beschrieben. Ob sich dieses Modell gegen Abos durchsetzt, ist offen; Abos bleiben eine der vier Varianten, die Jaipuria nennt.

Für Händler heißt das, genauer hinzuschauen, wofür sie tatsächlich zahlen. Eine Provision für zusätzliche Nachfrage ist eine Investition. Eine Provision für einen Kunden, der ohnehin gekauft hätte, ist verlorene Marge. Wer diese Unterscheidung nicht messen kann, verliert in Verhandlungen mit Agentenplattformen.

Wer an solchen Systemen baut, muss vor allem eine Frage beantworten: Vertraut der Nutzer dem Agenten noch, wenn dieser Provisionen und Werbegelder bekommt? Das ist keine technische Aufgabe, sondern eine Frage der Glaubwürdigkeit. Jaipurias Zahlen sind eine Modellrechnung, keine Prognose. Wie schnell und wie weit die Take Rates tatsächlich steigen, weiß niemand.

Quelle: tanayj.com

Verbreitet ist die Annahme, spekulative Dekodierung sei schnell, weil sie Rechenarbeit spart. Der Forscher Joe Barrow hält in seinem Blog dagegen: Wer nachrechnet, findet das Gegenteil: Für dieselbe Sequenz steigt die Zahl der Floating-Point-Operationen. Das ist kein Widerspruch. Schneller wird das Verfahren nicht, weil weniger gerechnet wird, sondern weil anders gerechnet wird. Um zu verstehen, warum spekulative Dekodierung schnell ist, hilft ein Blick darauf, was die GPU physisch tut, statt auf die Token pro Sekunde. Ein Lieferwagen, der für ein einziges Paket eine komplette Tour fährt, ist ein gutes Bild dafür.

Bei der klassischen LLM-Inferenz passiert genau das. Jeder Token, den das Modell ausgibt, kostet eine vollständige Fahrt durch den Speicher: Alle aktiven Gewichte müssen einmal gelesen werden, egal wie wenig damit anschließend gerechnet wird. Die GPU wartet dabei die meiste Zeit auf Daten, nicht auf Rechenoperationen. Spekulative Dekodierung belädt diesen Lieferwagen voller: dieselbe Strecke, mehr Ladung pro Tour. Darin liegt der Geschwindigkeitsvorteil.

Draft-Modell schlägt vor, großes Modell verifiziert in einem Durchlauf

Ein kleines Draft-Modell erzeugt autoregressiv vier oder fünf Tokens und schiebt sie als Vorschlag nach vorn. Das große Modell bekommt Prompt und Entwurf zusammen und verarbeitet beides in einem einzigen Forward Pass. Für jede Position entsteht eine vollständige Wahrscheinlichkeitsverteilung, nicht bloß ein Ja oder Nein.

Akzeptiert wird der längste zusammenhängende Präfix, der zu diesen Verteilungen passt; das erste abweichende Token wird durch die korrigierte Variante ersetzt. Ein Durchlauf bringt die Sequenz um mehrere Tokens voran statt um einen. Daher die höhere FLOP-Zahl: Der Verifizierer rechnet für jede vorgeschlagene Position mit, und das ist mehr Arbeit als das Erzeugen eines einzelnen Tokens.

Die Verifikation ist kein Vergleich zweier fertiger Tokenlisten. Es ist ein echtes Vorwärtsrechnen des großen Modells, nur parallel über mehrere Positionen. Die Kosten skalieren mit der Spekulationstiefe, der Gewinn hängt an der Annahmequote. Ist sie hoch, ist der Tausch gut. Ist sie niedrig, wird Rechenzeit auf Vorschläge verwendet, die anschließend verworfen werden.

Speichergebunden oder compute bound: zwei Arten von Arbeit auf derselben GPU

Auf einer GPU laufen zwei Dinge gleichzeitig, die man leicht verwechselt. Das eine sind die Tensoroperationen — Matrixmultiplikationen, Skalarprodukte, kurz: Rechnen. Das andere ist Datenverkehr: Werte müssen aus dem globalen Speicher geholt und in lokale Register oder Caches geschrieben werden. Beides kostet Zeit, aber nicht im selben Verhältnis. Je nach Situation wartet die GPU auf das eine oder das andere.

Wartet sie auf Daten, ist der Vorgang speichergebunden. Wartet sie auf die Rechenoperationen, ist er compute bound. Das liegt nicht an der Hardware allein, sondern am Verhältnis von Arbeit zu Datenmenge. Das Roofline-Modell macht das sichtbar: Es trägt die erreichte Rechenleistung gegen die arithmetische Intensität auf, also gegen die Zahl der Operationen pro geladenem Byte. Bis zu einem Knickpunkt begrenzt die Speicherbandbreite, danach die Rechenleistung.

Zurück zum Lieferwagen. Die Straße steht für die Speicherbandbreite und ist die eigentliche Engstelle. Der Laderaum steht für die Rechenwerke. Solange nur ein Paket auf der Ladefläche liegt, entscheidet die Straße über die Lieferzeit, egal wie groß der Laderaum ist. Erst wenn mehr Pakete mitfahren, wird die Fahrt wirtschaftlich — die Strecke bleibt gleich, der Ertrag pro Tour steigt.

Warum ein einzelner Token die GPU unterfordert

Beim Token-für-Token-Dekodieren ist genau das der Fall. Barrow nennt als Beispiel Qwen3.5-27B mit 27 Milliarden aktiven Parametern, die für jeden Token komplett aus dem Speicher gestreamt werden müssen. Gerechnet in 16-Bit-Präzision sind das rund 54 Gigabyte pro Token; bei einigen Terabyte pro Sekunde Speicherbandbreite dauert allein der Transport also Millisekunden. Die zugehörigen Rechenoperationen sind bei dieser Datenmenge erledigt, bevor der Transport abgeschlossen ist. Ein Matrix-Vektor-Produkt mit einem einzelnen Vektor ist rechnerisch anspruchslos.

Die GPU könnte also mehr tun, während sie wartet. Dieses ungenutzte Potenzial ist das Budget, aus dem spekulative Dekodierung schöpft. Würde man statt einer Sequenz zwei gleichzeitig dekodieren, kostete das pro Token praktisch keine zusätzliche Zeit, weil die Gewichte ohnehin geladen werden. Mehr Sequenzen im selben Schritt erhöhen die arithmetische Intensität, bis der Knickpunkt der Roofline erreicht ist.

Spekulative Dekodierung erzeugt keine neue Bandbreite und keine schnellere Hardware. Sie nutzt Rechenleistung, die ohnehin brachliegt, um die teure Speicherfahrt mit mehr Arbeit zu bezahlen. Die Antwort auf die Frage, warum sie schnell ist, ist deshalb keine Frage der Einsparung, sondern der Auslastung.

Breite gegen Tiefe: Batch-Größe und Spekulationstiefe teilen sich dasselbe Budget

Angenommen, ein Forward Pass läuft dann optimal, wenn fünf Tokens darin verarbeitet werden: darunter speichergebunden, darüber compute bound. Bei fünf ist die GPU ausgelastet, ohne in die Rechengrenze zu laufen. Es gibt zwei Wege, diese fünf zu erreichen.

Der erste ist Breite: fünf Sequenzen, jede mit einem Token in derselben Runde. Alle fünf Anfragen kommen ein Stück voran. Der zweite ist Tiefe: eine einzelne Sequenz mit fünf Tokens, wovon vier aus dem Entwurf akzeptiert werden. Der Rechenaufwand ist in beiden Fällen ungefähr gleich. Der Unterschied liegt darin, wem der Fortschritt zugutekommt: fünf Nutzern ein klein wenig oder einem Nutzer sehr viel.

Deshalb wirkt spekulative Dekodierung vor allem bei kleinen Batch-Größen. Solange die Batch-Größe deutlich unter der optimalen Tokenzahl liegt, ist Rechenleistung übrig, und die Spekulation kostet nichts, was nicht schon bezahlt wäre. Bei geringer Last verschenkt das System sonst Kapazität. Spekulative Dekodierung und Batch-Größe sind zwei Seiten desselben Budgets.

Wo die Rechnung kippt: hoher Durchsatz und abgelehnte Tokens

Sobald die Batch-Größe nahe am Optimum liegt oder darüber, wird zusätzliche Spekulationstiefe zu verschwendeter Rechenzeit. Man arbeitet dann gleichzeitig gegen die Speichergrenze und gegen die Rechengrenze, statt Rechenleistung kostenlos abzuschöpfen. Bei fünf Sequenzen mit je vier spekulierten Tokens landet man bei zwanzig Positionen in einem Schritt — deutlich über dem, was die GPU sinnvoll verarbeiten kann.

Dazu kommt die Annahmequote. Jede abgelehnte Position ist bezahlte Arbeit ohne Ertrag. Bei einer hohen Annahmequote fällt das kaum ins Gewicht, bei einer niedrigen frisst es den Vorteil auf. Die Konfiguration dieser Systeme ist deshalb eine Betriebsentscheidung. vLLM stellt dafür den Parameter --speculative-disable-by-batch-size bereit, der spekulative Dekodierung ab einer bestimmten Batch-Größe abschaltet — genau, um nicht in den compute-bound Bereich hinein zu spekulieren.

Wer nur auf die Latenz einer einzelnen Anfrage schaut, gewinnt mit spekulativer Dekodierung. Wer einen Dienst mit hohem Durchsatz betreibt, kann damit Rechenzeit verbrennen, die anderswo fehlt. Beide Sichten sind korrekt, sie beschreiben unterschiedliche Lastprofile.

Dynamische Spekulationstiefe und die praktische Einordnung

Wenn Tiefe und Breite aus demselben Budget kommen, liegt die nächste Frage nahe: Warum sollte man zu jedem Zeitpunkt gleich tief spekulieren? Bei kleiner Batch-Größe ist Rechenleistung übrig, bei großer nicht. Eine feste Tiefe verschenkt in beiden Fällen etwas. Naheliegend ist eine variable Tiefe — tief spekulieren, wenn Platz ist, flach oder gar nicht, wenn die Rechenwerke ausgelastet sind, und das möglichst pro Sequenz statt global.

Genau diese Überlegung steckt laut Barrow hinter Ansätzen wie dSpark, die die Tiefe an die Last anpassen und sie im Idealfall pro Sequenz wählen, statt allen dieselbe aufzuzwingen. Das Budget einer GPU ist eine gemeinsame Ressource, und wer sie ausgibt, sollte wissen, wo gerade welche übrig ist.

Spekulative Dekodierung ist kein allgemeiner Beschleuniger, sondern ein Werkzeug für niedrige Batch-Größen. Sie zahlt sich aus bei Einzelnutzer-Chats, lokaler Inferenz und allem, was auf Latenz optimiert ist. Bei hohem Durchsatz lohnt es sich, sie lastabhängig abzuschalten oder zu begrenzen. Und wer sie einsetzt, sollte neben den FLOPs vor allem die Annahmequote des Draft-Modells im Blick behalten — dort entscheidet sich, ob die zusätzliche Arbeit tatsächlich in akzeptierte Tokens mündet.

Quelle: jbarrow.ai

OpenAI hat seiner API eine neue Geschwindigkeitsstufe gegeben. Der Ultrafast mode ist laut Dokumentation der schnellste Service-Tier der API, gedacht für latenzkritische Arbeit und ausdrücklich für Fälle, in denen die Geschwindigkeit den höheren Preis rechtfertigt. In der Dokumentation steht er unter den Production best practices im Abschnitt Performance and quality, direkt neben Fast mode, Latency optimization und Predicted Outputs.

Die Seite selbst ist knapp: Sie erklärt, wie man den Modus einschaltet, für welche Modelle er gilt und welche Grenzen gelten. Wie viel schneller er ist, beziffert sie nicht. Dieser Text fasst zusammen, was dort steht, und zeigt, wie du selbst prüfst, ob sich der Aufpreis für deine Anwendung lohnt.

Modelle, Konfiguration und WebSockets

Allgemein verfügbar ist Ultrafast für GPT-6 Astra und GPT-6.1 Sol, für GPT-5.6 Sol gibt es Vorabzugang. Für dieses Modell hatte OpenAI eine Ultrafast-Variante schon im August zusammen mit Cerebras vorgestellt. Eingeschaltet wird der Modus pro Anfrage: model auf gpt-6-astra oder gpt-6.1-sol setzen und service_tier auf ultrafast. Das funktioniert über die normale HTTP-Schnittstelle der Responses API ebenso wie über eine WebSocket-Verbindung.

OpenAI empfiehlt WebSockets ausdrücklich, vor allem für agentische Anwendungen, die in schneller Folge viele Werkzeugaufrufe machen. Ohne dauerhafte Verbindung kann der Netzwerk-Overhead einen Teil des Latenzgewinns wieder auffressen. Das Beispiel in der Dokumentation streamt zwei Antworten über dieselbe Verbindung; die zweite Anfrage schickt nur den neuen Prompt und verweist mit previous_response_id auf die erste. Dieselbe Verbindung soll auch für spätere Runden und Werkzeugergebnisse weiterverwendet werden.

Bezeichnend ist, wo das Thema steht: nicht unter den Modellfähigkeiten, sondern unter den Produktionspraktiken. Es geht nicht darum, was das Modell kann, sondern wie schnell es antwortet. Das ist der Teil, den der Nutzer am Ende spürt, ob im Sprachdialog, in einer Chat-Oberfläche oder in einem Editor.

Rate Limits, Datenresidenz und was die Seite nicht sagt

Ultrafast hat eigene Rate Limits, getrennt von Standard und Fast mode. Für GPT-6.1 Sol liegen die Voreinstellungen je nach Nutzungsstufe bei 1 Million Token pro Minute (Build), 4 Millionen (Launch) und 40 Millionen (Grow). Für GPT-6 Astra sind es 500.000, 1 Million und 5 Millionen Token pro Minute. Vor dem Hochfahren des Verkehrs empfiehlt die Dokumentation, die Limits der eigenen Organisation zu prüfen; wer mehr braucht, soll sich an sein Account-Team bei OpenAI wenden.

Unterschiede gibt es bei der Datenresidenz: Ultrafast mit GPT-6.1 Sol unterstützt Datenresidenz in den USA und der EU sowie globale Verarbeitung, Ultrafast mit GPT-6 Astra nur US-Datenresidenz und globale Verarbeitung. Wer Daten in der EU halten muss, ist damit auf Sol festgelegt. Die Preise für Eingabe, gecachte Eingabe, Cache-Schreibvorgänge und Ausgabe stehen in einer eigenen Ultrafast-Preistabelle.

Was der Modus intern anders macht, erklärt die Seite nicht. Für die eigene Planung hilft trotzdem die Unterscheidung zwischen zwei Größen: der Zeit bis zum ersten Token, im Englischen time to first token, kurz TTFT, und der Geschwindigkeit danach, gemessen in Token pro Sekunde. Wer nur die Gesamtdauer eines Requests betrachtet, mittelt beide zu einer Zahl, die wenig aussagt. Welche der beiden Größen für deine Anwendung zählt, entscheidet mit darüber, ob sich der Aufpreis lohnt.

Für welche Anwendungen sich der ultraschnelle Modus rechnet

Die Dokumentation nennt als Einsatzgebiet latenzkritische Arbeit und hebt agentische Anwendungen mit vielen Werkzeugaufrufen hervor. Gemeint sind Anwendungen, in denen eine Verzögerung von einer Sekunde wie ein Fehler wirkt.

Bei einem Sprachdialog addieren sich mehrere Latenzen: Spracherkennung, Modellaufruf, Sprachausgabe. Wenn der Modellaufruf davon den größten Posten frisst, bringt der ultraschnelle Modus am meisten. Weitere Kandidaten sind Autovervollständigung im Editor, Agenten, die Werkzeuge aufrufen und deren Ergebnis sofort weiterverarbeiten, sowie Oberflächen, die Text während der Generierung einblenden.

Für Batch-Verarbeitung, Tiefenrecherche oder Aufgaben mit langem Reasoning ist der Modus das falsche Werkzeug. Dort ist nicht die Reaktionszeit das Problem, sondern die Qualität des Ergebnisses, und die entsteht durch mehr Rechenzeit, nicht durch weniger. Der Batch-Endpunkt und der Flex-Modus passen für solche Fälle besser.

Fast mode, Predicted Outputs, Prompt Caching: wer was beschleunigt

Die Dokumentation nennt unter Performance and quality mehrere Optimierungen, die unterschiedliche Probleme lösen. Wer sie verwechselt, optimiert an der falschen Stelle und wundert sich über ausbleibende Effekte.

Prompt Caching reduziert den Aufwand für den Eingabetext. Wenn du denselben Systemprompt oder dasselbe Dokument wiederholt mitschickst, muss der vordere Teil nicht neu verarbeitet werden. Predicted Outputs zielt auf den Ausgabeteil und lohnt sich, wenn ein großer Teil der Antwort bereits bekannt ist, etwa beim Umschreiben einer Datei, in der nur wenige Zeilen wechseln. Latency optimization ist der Sammelbegriff für Architekturentscheidungen: kürzere Prompts, weniger Werkzeugschleifen, Streaming statt Warten auf die Gesamtantwort.

Fast mode und Ultrafast mode dagegen sind Service-Tiers, keine Sparmaßnahmen: Sie ändern nicht, wie viel Arbeit ein Request macht, sondern wie schnell er bedient wird, gegen Aufpreis. In der Praxis kombinierst du sie: Caching für den Kontext, den alle Requests teilen, und die schnellere Betriebsart nur für die Pfade, in denen ein Mensch tatsächlich wartet.

Messen statt raten: TTFT, Perzentile und die Kostenfrage

Ein Durchschnittswert über alle Requests verdeckt genau das, was Nutzer stört. Miss deshalb den Median und die oberen Perzentile, also p95 und p99, getrennt für jeden Endpunkt und jeden Modus. Ein p95 von zwei Sekunden bei einem Median von 300 Millisekunden bedeutet, dass sich jeder zwanzigste Aufruf träge anfühlt.

Vergleiche mit identischen Prompts, identischer Ausgabelänge und identischer Last. Sonst misst du den Unterschied zwischen zwei Eingaben, nicht den zwischen zwei Betriebsarten. Streaming verändert die Wahrnehmung: Wenn Text sofort erscheint, wirkt derselbe Request kürzer, auch wenn die Gesamtdauer gleich bleibt.

Prüfe außerdem die Randbedingungen. Ultrafast hat eigene Rate Limits, und die schnellste Betriebsart hilft nichts, wenn der Request vorher an einem Limit abprallt. Die Dokumentation lässt sich übrigens skripten: Für den vollständigen Index gibt es llms.txt, und jede Seite existiert als Markdown-Version, wenn du .md an die URL hängst. Damit baust du die Referenz in deinen Entwickler-Workflow ein, statt sie im Browser zu suchen.

Was das für deine Architektur bedeutet

Der ultraschnelle Modus ist keine Wunderwaffe, sondern ein teurerer Service-Tier. Er hebt keine grundlegenden Grenzen auf. Wenn dein Prompt 40.000 Token Kontext mitschleppt oder dein Agent fünf Werkzeugschleifen dreht, bleibt die Wartezeit hoch, egal welche Betriebsart du wählst.

Sinnvoll ist eine Aufteilung: schnelle Pfade für alles, was im Dialog oder direkt in der Eingabe passiert, und großzügigere Zeitbudgets für alles, was im Hintergrund läuft. Wer diese Trennung einmal eingezogen hat, kann beide Seiten unabhängig optimieren, statt an einer einzigen globalen Einstellung zu drehen und dabei entweder Geld zu verbrennen oder Reaktionszeit zu verschenken.

Fang mit der Messung an, nicht mit der Konfiguration. Erhebe TTFT und Durchsatz deiner wichtigsten Endpunkte, schalte dann den Modus für einen einzelnen Pfad zu und vergleiche dieselben Werte erneut. Was sich nicht messbar verbessert, gehört nicht in die Produktion – egal wie überzeugend der Name klingt.

Quelle: developers.openai.com

Was tut ein Hersteller, wenn eine Sicherheitslücke bereits aktiv ausgenutzt wird, der reguläre Update-Prozess aber zu lange braucht? Laut Natalie Silvanovich von Googles Sicherheitsteam Project Zero äußern manche Hersteller genau diese Sorge: dass sie eine Lücke, die Nutzern gerade schadet, wegen der Grenzen ihrer Update-Systeme nicht schnell genug schließen können. In einem Beitrag auf dem Project-Zero-Blog trägt Silvanovich zusammen, mit welchen Notfallmechanismen große Anbieter einzelne Schwachstellen deutlich schneller beheben als über den üblichen Update-Zyklus. Das Team stützt sich dabei auf Gespräche mit Herstellern und auf eigene Sicherheitsanalysen.

Der Beitrag richtet sich an Hersteller, die solche Systeme aufbauen oder verbessern wollen, und soll sie dazu bringen, sich zu überlegen, wie sie eine dringende Lücke schließen würden, bevor sie eine gemeldet bekommen. Zur Einordnung: Project Zero gehört zu Google, und mehrere der genannten Beispiele, etwa Androids Intent Firewall, Google Play Protect, Android Pony Express und Chrome, stammen aus dem eigenen Konzern. Daneben nennt der Text Verfahren von Apple, Meta, Microsoft und Linux. Im Folgenden geht es um die einzelnen Verfahren, ihre Grenzen und die Frage, was davon in einen normalen Patch-Prozess passt.

Warum ein Patch sechs Schritte braucht, nicht einen

Zur Veranschaulichung taugt ein Vergleich, der nicht aus dem Bericht stammt: der Umbau eines bewohnten Hochhauses. Man reißt nicht einfach eine Wand heraus, weil ein Riss sichtbar geworden ist. Erst wird geprüft, wie schlimm der Riss ist und wer zuständig ist. Dann zeichnet jemand den neuen Grundriss, andere prüfen die Statik, die Feuerwehr prüft die Fluchtwege, am Ende wird gearbeitet, und danach kontrolliert noch jemand, dass das Haus wirklich steht. Eine ähnliche Abfolge von Stationen beschreibt Silvanovich für Software.

Der erste Schritt ist die Triage: Eine Meldung kommt an, wird geprüft, priorisiert und einer Person zugewiesen, die den Fehler behebt. Danach folgt die Entwicklung — Code schreiben, Review, Commit; hier entsteht der eigentliche Patch. Der dritte Schritt ist das Testen: nicht nur, ob die Lücke geschlossen ist, sondern ob die Software danach noch tut, was sie soll. Bei manchen Produkten kommt eine Partnerprüfung hinzu, etwa wenn Mobilfunkbetreiber ein Update abnehmen müssen. Dann die Auslieferung an die Nutzer, und in einigen Fällen ein weiterer Schritt wie ein Neustart, bevor die neue Version aktiv wird.

Die Liste ist vereinfacht. In der Praxis wiederholen sich Schritte, weil Tests fehlschlagen, oder es kommen weitere Beteiligte hinzu. Eine Sicherheitslücke schnell zu beheben ist kein einzelner Handgriff, sondern eine Kette — und die langsamste Station bestimmt das Tempo.

Warum Notfall-Patches nicht an der Entwicklung scheitern

Man könnte vermuten, dass im Notfall vor allem die Programmierarbeit zu lange dauert. Der Bericht zeichnet ein anderes Bild. Die Triage geht schnell, wenn klar ist, dass ein ernstes Problem vorliegt, und die Entwicklung lässt sich priorisieren. Verzögerungen entstehen hier nur selten, etwa bei besonders komplexen Lücken oder wenn ein Hersteller selbst nicht weiß, welche Bausteine in seinem Produkt stecken und wer sie intern betreut. Auch Verträge mit Partnern enthalten üblicherweise Ausnahmen für Notfälle.

Der Engpass liegt woanders: beim Testen und bei der Auslieferung. Jede Änderung an Software kann unerwartetes Verhalten erzeugen. Der schlimmste Fall ist ein Gerät, das nach dem Update nicht mehr funktioniert und auch keine weiteren Updates mehr empfangen kann. Es gab auch schon fehlerhafte Updates, die Nutzerdaten beschädigt oder gelöscht haben. Und jeder Funktionsverlust nach einem Sicherheitsupdate senkt die Bereitschaft, künftige Updates überhaupt zu installieren.

Wie teuer schlecht getestete Updates werden, hängt vom Produkt ab. Eine App, die nach einem Update nicht mehr startet, lässt sich über den Store neu installieren, die Daten liegen meist auf einem Server, der Schaden bleibt überschaubar. Ein unbrauchbar gewordenes Mobilgerät muss dagegen eingeschickt oder ersetzt werden, was den Hersteller echte Summen kostet. Updates werden deshalb häufig langsam ausgerollt, damit sich Probleme zeigen, bevor sie alle Nutzer erreichen. Schnelles und sauberes Patchen stehen in einem Spannungsverhältnis.

Dazu kommen technische Bremsen. Viele Systeme fragen in festen Intervallen nach Updates, wodurch die Verteilung an dieses Intervall gebunden ist. Push-Verfahren sind schneller, brauchen aber mehr Infrastruktur. Auch das Verhalten der Nutzer zählt: Wenn ein Patch eine Bestätigung oder einen Neustart verlangt, bleibt er liegen. Netzgeschwindigkeit und Datenkosten spielen ebenfalls eine Rolle. Chrome und Microsoft haben laut dem Bericht selbst beschrieben, wie schwierig Updates sind, die einen Neustart verlangen: Nutzer schieben ihn hinaus, und er kostet Zeit.

Feature-Flags: der Schalter für den Notfall

Feature-Flags sind Bedingungen im Quellcode, deren Ausgang von Werten abhängt, die ein Server liefert. Normalerweise nutzt man sie für A/B-Tests. Im Notfall lassen sich damit Funktionen abschalten, die eine Schwachstelle erreichbar machen. Ein bekanntes Beispiel ist die FaceTime-Lücke von 2019, bei der Apple die Gruppenfunktion vorübergehend per Flag deaktivierte. Mehrere Hersteller halten Video-Codecs, die ohne Nutzerinteraktion erreichbar sind, auf diese Weise schaltbar und können bei aktiver Ausnutzung auf einen anderen Codec zurückfallen.

Der Vorteil liegt nicht allein in der Geschwindigkeit. Wichtiger ist, dass beide Zustände eines Flags vorab getestet werden können. Ein dringendes Sicherheitsupdate muss damit keinen ungetesteten Code ausliefern. Zusätzlich ist die übertragene Datenmenge winzig, ein Flag-Wechsel erreicht Nutzer also deutlich schneller als ein vollständiges Update. Meta hat beschrieben, wie das Unternehmen zwei Versionen seiner WebRTC-Bibliothek in eine einzige Binärdatei kompiliert und per Flag umschaltet — fällt die neue Version auf, geht es schnell zurück zur alten.

Dasselbe Prinzip lässt sich mit zwei verschiedenen Bibliotheken bauen, die dieselbe Aufgabe erfüllen, etwa zwei H264-Implementierungen. Dann macht man eine Schwachstelle unerreichbar, ohne Funktion zu verlieren. Das erfordert zusätzliche Tests, aber solche, die im Vorfeld möglich sind. Denkbar ist auch eine zweite Variante, die teure Schutzmechanismen aktiviert, um viele mögliche Fehler vorsorglich zu blockieren.

Filter: Regeln vor der Schwachstelle

Filtering bedeutet, ungeprüfte Eingaben gegen einen dynamisch aktualisierbaren Regelsatz laufen zu lassen und genau die Eingaben zu blockieren, die eine Lücke erreichbar machen. Ein Beispiel ist Androids Intent Firewall, die bestimmte Nutzungen eines IPC-Mechanismus über eine aktualisierbare XML-Datei abschalten kann. Damit ließen sich zuletzt Lücken in Wallets Dritter blockieren.

Auf manchen Plattformen laufen ohnehin Endpoint-Schutzprogramme, etwa Microsoft Defender unter Windows oder Google Play Protect unter Android. Regeln, die konkrete Exploits blockieren, lassen sich dorthin sehr schnell ausliefern. Der Vorteil gegenüber Feature-Flags ist die Flexibilität: Für Flags muss man vorher wissen, welche Funktion man abschalten wollen würde. Ist diese Liste unvollständig, steht man im Ernstfall ohne Hebel da. Filter greifen dagegen auch bei Eingaben, an die vorher niemand gedacht hat.

Die Nachteile sind real. Filter müssen selbst geprüft werden, denn ein falsch geschriebener Ausdruck kann notwendige Systemfunktionen stören. Häufiges Filtern kostet Leistung, und die Tests neuer Regeln lassen sich nicht vorab erledigen, solange man die zu blockierende Lücke noch nicht kennt. Endpoint-Schutzprogramme verarbeiten außerdem sehr viel ungeprüfte Eingabe, oft mit hohen Rechten, und sind damit selbst nicht ohne Risiko. Wo sie ohnehin installiert sind, sieht Project Zero in ihnen trotzdem einen möglichen Weg für die Notfallbehebung.

Alternative Kanäle und Hotpatching: schnell, aber mit Nebenwirkungen

Android Pony Express ist ein Beispiel für einen zweiten Auslieferungsweg: Updates für einzelne besonders gefährdete Komponenten laufen schneller als ein komplettes Systemupdate, weil Hersteller sie nicht selbst integrieren müssen. Manche Anwendungen laden einzelne Bibliotheken außerhalb des regulären Update-Zyklus nach und binden sie zur Laufzeit ein. Das umgeht die Grenzen der Verteilung, hat aber eine harte Bedingung: Der Client muss prüfen können, dass die Bibliothek wirklich vom Hersteller stammt. Fehlt diese Prüfung, wird aus dem Notfallkanal eine kritische Schwachstelle.

Hotpatching geht weiter und schiebt kleinere Codeeinheiten direkt in den Speicher eines laufenden Prozesses. Linux unterstützt das mit Livepatch für Kernelfunktionen, Windows mit einem eigenen Verfahren für Sicherheitsupdates ohne Neustart. Der Nutzer merkt nichts, das Update ist sofort wirksam. Die Grenzen liegen in der Art der Änderung: Ändert ein Update die Definition einer Struktur, die mehrere Funktionen gemeinsam nutzen, wird das teilweise nicht unterstützt.

Auch hier gibt es Sicherheitsfragen. Wer Code in laufende Prozesse schreiben kann, braucht zeitweise Speicherseiten, die gleichzeitig beschreibbar und ausführbar sind — ein Zustand, den viele Schutzmechanismen eigentlich verhindern sollen. Noch etwas bleibt bestehen: Hotpatching löst das Auslieferungsproblem, nicht das Testproblem. Ein Patch, der ohne ausreichende Prüfung in den Speicher wandert, bleibt ein Patch ohne ausreichende Prüfung.

Was ein belastbarer Patch-Prozess vorher klären muss

Der Bericht endet nicht mit einem Werkzeug, sondern mit einer Begründung und einer Aufforderung. Die Begründung: Sprachmodelle erweitern nach Silvanovichs Einschätzung die Fähigkeiten von Angreifern wie Verteidigern, Schwachstellen zu finden und auszunutzen, und mehr Akteure können neuartige Angriffe schneller durchführen. Die Aufforderung: Hersteller sollen planen, wie sie ihre Nutzer im schlimmsten Fall, bei breiter aktiver Ausnutzung, schützen würden, und zwar bevor dieser Fall eintritt. Dafür müssen Notfallmechanismen weder schwergewichtig sein noch jeden denkbaren Fehler beheben können. Feature-Flags, Filter und alternative Update-Wege sollen kurzfristig die wahrscheinlichsten und schwersten Lücken entschärfen und die Geräte dabei halbwegs benutzbar halten. Als ersten Schritt empfiehlt der Beitrag eine Bestandsaufnahme der vorhandenen Update-Mechanismen und schnelle Abhilfe dort, wo Lücken bestehen.

Für die Praxis lässt sich daraus ableiten: Ein Unternehmen braucht mehr als einen Notausgang. Feature-Flags helfen bei Funktionen, die man vorab als Risiko erkannt hat, Filter auch bei Eingaben, an die niemand gedacht hat, alternative Kanäle und Hotpatching bei der Frage, wie ein Fix überhaupt ankommt. Diese Wege ergänzen sich, und keiner davon ersetzt die Tests. Wer nur den schnellsten Weg baut und den langsamsten nicht absichert, verschiebt das Problem.

Der Originaltitel des Beitrags lautet „How to fix a bug in a fix“. Unsere Lesart: Gemeint ist weniger ein zweiter, noch schnellerer Patch als die Vorbereitung darauf, die eigene Kette vom Fehlerbericht bis zur Aktivierung zu kennen, ihre langsamste Station zu identifizieren und für genau diese Station einen vorab geprüften Weg bereitzuhalten. Das Beheben einer Lücke und das Ausliefern der Korrektur sind zwei getrennte Aufgaben, und im Notfall entscheidet meist die zweite über das Tempo. Ob ein Hersteller vorbereitet ist, zeigt sich nicht an der Zahl seiner Patches, sondern daran, ob im Ernstfall ein Weg existiert, der schnell ist und trotzdem trägt.

Quelle: projectzero.google

„Instead of relying on a separate, often larger, teacher, we leverage their self-critiques as privileged information.“ Dieser Satz steht im Abstract von UniEvo-VL, einem Paper, das Fang Wu mit 18 Mitautoren vorgelegt hat, unter anderem von der Stanford University und der Johns Hopkins University. Dahinter steckt eine Verschiebung: Nicht das größere Modell soll den Ton angeben, sondern die Kritik, die ein System an seiner eigenen Arbeit formuliert. Der Gedanke ist einfach – wenn ein Modell Bilder erzeugen und Bilder verstehen kann, kann es auch beurteilen, ob sein eigenes Ergebnis zur Aufgabe passt.

Hier setzt die Arbeit an. Moderne multimodale Modelle bringen Generierung und Verständnis in einem einzigen System zusammen, und nur deshalb können sie aus ihrem eigenen Feedback lernen. Viele Verfahren lernen aus korrigierten Zielbildern oder aus einer einzelnen Belohnungszahl. Das Team geht einen anderen Weg und nutzt die Selbstkritik als privilegierte Information, also als etwas, das dem Modell zur Trainingszeit zur Verfügung steht, zur Laufzeit aber nicht mehr gebraucht wird.

Ein Modell in zwei Rollen: Lehrer und Schüler mit unterschiedlichem Kontext

UniEvo-VL beschreibt ein selbstverbesserndes Framework, in dem dasselbe multimodale Modell zwei Aufgaben übernimmt. Der Schüler sieht nur die schlichte Frage, die sogenannte Vanilla-Frage, ohne jeden Zusatz. Der Lehrer sieht dieselbe Frage plus die Kritik am ersten Versuch. Beide sind derselbe Bildgenerator, der Lehrer ist eine langsam nachgeführte Kopie des Schülers (ein exponentieller gleitender Mittelwert der Gewichte). Allein der Kontext unterscheidet sie. Der Kern: Es braucht kein separat trainiertes, größeres Lehrermodell. Die Kritik selbst schreibt im Experiment allerdings ein eigenes Verständnismodell aus derselben Familie, Qwen-VL; trainiert wird nur der Generator, und zwar über schlanke LoRA-Parameter.

Man kann sich das wie eine Werkstatt mit zwei Räumen vorstellen. Im ersten Raum liegt das fertige Stück auf dem Tisch, ohne Kommentar. Im zweiten Raum liegt dasselbe Stück, daneben ein Korrekturzettel mit den Stellen, die nicht stimmen. In beiden Räumen steht dieselbe Person. Die Frage ist nicht, ob sie es besser kann – mit dem Zettel kann sie es offensichtlich besser. Die Frage ist, ob sie diese Fähigkeit auch ohne Zettel abruft. Genau das ist die Aufgabe des Trainings: die Kompetenz aus dem zweiten Raum in den ersten hinüberzuziehen, ohne dass der Zettel je wieder auftaucht.

Deshalb heißt die Information privilegiert. Im Training ist sie reichlich vorhanden, im Betrieb nicht. Wer Selbstkritik als privilegierte Information nutzt, verlagert Wissen, nicht Daten. Das ist etwas anderes als eine Datenbank mit guten Beispielen, denn das Modell lernt hier aus der Differenz zwischen seinem ersten und seinem korrigierten Versuch.

On-Policy Self-Distillation: gelernt wird auf den eigenen Spuren

Der Trainingsmechanismus heißt On-Policy Self-Distillation, und beide Wörter verdienen Aufmerksamkeit. On-Policy bedeutet, dass der Schüler seine eigenen Spuren erzeugt, statt Beispiele aus einem fremden Datensatz nachzuahmen. Bei der Bildgenerierung sind diese Spuren die Denoising-Pfade: die Kette von Zwischenschritten, die vom reinen Rauschen zum fertigen Bild führt. Das Modell läuft durch seinen eigenen Entstehungsprozess, Schritt für Schritt, und genau dort wird gelernt.

Anschließend minimiert das Training die Divergenz zwischen den Denoising-Verteilungen von Lehrer und Schüler, und zwar an jedem einzelnen Zustand entlang dieser Pfade. Nicht das Endergebnis wird mit einer Note bewertet, sondern die Wahrscheinlichkeitsverteilung an jedem Zwischenschritt wird zur Deckung gebracht. Es ist der Unterschied zwischen „das Bild ist gut“ und „an dieser Stelle hättest du anders abbiegen müssen“. Der Lernreiz liegt in der dichten Rückmeldung, nicht in einer einzelnen Zahl am Ende.

Das erklärt auch, warum der Ansatz überhaupt funktionieren kann. Ein skalares Belohnungssignal sagt dem Modell, dass etwas besser war, aber nicht wo. Eine Verteilungsangleichung über den gesamten Pfad sagt ihm sehr genau, an welchen Stellen es abweicht. Die Verbesserung der Bildgenerierung durch Selbst-Distillation kommt also nicht aus mehr Rechenzeit allein, sondern aus der Auflösung des Signals.

Die Zahlen: GenEval und Soft-TIFA im Vergleich

Die Experimente bauen auf dem offenen Modell Qwen-Image-2512 auf, das mit Qwen-Image 3.0 verwandt ist. Mit dem hauseigenen Kritiker Qwen-VL steigt der Wert auf GenEval von 0,747 auf 0,808. Die zweite Zahl aus dem Abstract, ein Anstieg von 32,97 auf 35,53 bei GenEval2 Soft-TIFA, stammt dagegen aus dem Lauf mit einem externen Kritiker, GPT-5.6-Luna. Mit dem eigenen Kritiker sinkt GenEval2 im Volltext leicht, von 32,58 auf 32,37; erst wenn die überarbeiteten Prompts zusätzlich geprüft werden, steigt der Wert auf 35,07. Beide Benchmarks prüfen im Kern, wie zuverlässig ein erzeugtes Bild zur Textvorgabe passt – ob Objekte, Farben, Anzahlen und Anordnungen stimmen.

Bemerkenswert ist, dass die Verbesserung ohne korrigierte Zielbilder und ohne Belohnungssignal entsteht. Zusätzlich berichtet das Team, dass die Empfindlichkeit des Modells für zusätzliche Reflexionsinformation erhalten bleibt: Auch das trainierte Modell profitiert noch von einem weiteren Korrekturdurchgang. Es verliert also nicht die Fähigkeit, auf Kritik zu reagieren, während es lernt, ohne sie auszukommen.

Wer selbst mit Bildmodellen arbeitet, sollte die Zahlen dennoch nüchtern lesen. Die Gewinne konzentrieren sich auf Prompts, an denen das Basismodell anfangs scheitert. Bei Prompts, die es schon vorher gut löste, sinken die Werte um 1 bis 4 Punkte auf einer Skala bis 100. Teuer ist das Verfahren auch: Nur 10 bis 21 Prozent der Versuche liefern ein brauchbares Trainingspaar, also fünf bis zehn Anläufe pro Paar, trainiert wurde auf vier H200-GPUs.

Warum ein starker Kritiker die Obergrenze hebt

Ein Ergebnis des Papers verdient besondere Beachtung. Das Team hat zusätzlich mit einem leistungsfähigeren externen Kritiker trainiert, GPT-5.6-Luna. Damit erreicht das Modell auf GenEval 0,882 statt 0,808 und auf GenEval2 den Bestwert von 35,53. Die Autoren folgern, dass Modelle mit starken Beurteilungsfähigkeiten eine höhere Obergrenze der Selbstverbesserung erwarten können. Die Qualität der Kritik bestimmt also, wie weit das Verfahren trägt.

Das ist einleuchtend und ein wenig unbequem. Wenn das Modell nur so weit kommt, wie es sich selbst durchschaut, dann ist Selbstverbesserung zunächst einmal durch die eigene Urteilskraft begrenzt. Ein besseres Urteilsvermögen verschiebt diese Grenze nach oben. Damit ist der Anspruch „ohne externen Lehrer“ an dieser Stelle qualifiziert: ohne externen Lehrer im Training ja, aber nicht ohne gutes Urteilen. Die Formulierung im Abstract spricht davon, dass ein höheres Niveau zu erwarten sei – nicht, dass es bewiesen wäre.

Für die Praxis heißt das: Wer dieses Verfahren nutzen will, sollte zuerst in die Kritikfähigkeit investieren. Der Kritiker ist der eigentliche Engpass, nicht der Generator.

Text-Rendering: wo die Verbesserung nicht gleichmäßig greift

Das Team berichtet außerdem von gemischten Ergebnissen beim Rendern von Text im Bild. Nur die Variante mit geprüften Prompts verbessert sich hier, von 0,771 auf 0,790. Mit dem ungeprüften eigenen Kritiker fällt der Wert unter das Ausgangsniveau, mit GPT-5.6-Luna steigt er nur leicht. Die Selbstverbesserung ist also nicht über alle Aufgaben hinweg gleich verteilt.

Ein Modell erbt die blinden Flecken seines Kritikers. Wenn die Kritik beim Text-Rendering nicht sauber unterscheidet, ob Buchstaben korrekt gesetzt oder nur plausibel aussehen, dann kann die Verteilungsangleichung diese Unterscheidung auch nicht herstellen. Die Selbstverbesserung verstärkt, was die Kritik schon erkennt – und eben auch, was sie übersieht.

Statt eine gleichmäßige Kurve nach oben zu behaupten, benennt das Paper diese Ungleichverteilung. Wer solche Verfahren einsetzt, sollte deshalb nicht von einer pauschalen Qualitätssteigerung ausgehen, sondern von einer aufgabenspezifischen.

Was das konkret bedeutet

UniEvo-VL ist kein Durchbruch, der die Bildgenerierung neu ordnet, sondern ein Rezept mit einer klaren Idee: Selbstkritik wird zur privilegierten Information, und ein einziges Modell spielt Lehrer und Schüler in unterschiedlichen Kontexten. Der Bezug zu Test-Time Compute ist dabei der interessanteste Punkt. Die Kritik entsteht beim Erzeugen, kostet dort Rechenzeit und wird anschließend in dauerhaftes Können übersetzt. Der Aufwand fällt im Training an, danach erzeugt das Modell bessere Bilder ohne zusätzlichen Korrekturdurchgang.

Für die Praxis ergeben sich zwei Konsequenzen. Erstens: Der Engpass verschiebt sich vom Generator zum Kritiker – wer in Beurteilungsfähigkeit investiert, gewinnt mehr als jemand, der nur größere Generatoren baut. Zweitens: Erwartungen gehören aufgabenspezifisch formuliert. Prompt-Treue lässt sich so verbessern, Text-Rendering nicht automatisch mit, und leichte Aufgaben können sogar leicht schlechter werden. Und die Verbesserung ist, wie das Paper selbst schreibt, nicht zwingend gleichmäßig.

Offen bleibt, wie weit das Verfahren skaliert, ob die Selbstkritik mit steigender Modellqualität informativ bleibt oder sich selbst bestätigt, und wo genau die Obergrenze liegt, wenn kein stärkerer externer Kritiker mehr zur Verfügung steht. Wer heute multimodale Modelle einsetzt, muss darauf nicht warten. Die relevante Frage ist ohnehin nicht, ob es einen größeren Lehrer gibt, sondern ob im eigenen System ein verlässlicher Kritiker arbeitet. Die Details stehen im vollständigen Paper, nicht im Abstract.

Quelle: arxiv.org