KRÖTZSCHKI-Blog · Ohne Bullshit
Newsletter

Suchergebnisse für: „Benchmark“

  • Nano Banana 2.1: Was Googles Modellkarte über Stärken und Grenzen verrät

    Nano Banana 2.1: Was Googles Modellkarte über Stärken und Grenzen verrät

    Was steht in der Model Card von Nano Banana 2.1? Google DeepMind hat am 6. Oktober 2026 ein Dokument veröffentlicht, das Eigenschaften, Messwerte und bekannte Schwächen des Bildmodells bündelt. Wichtig für die Einordnung: Die Modellkarte stammt vom Hersteller selbst, und auch die Benchmarks darin hat Google selbst erhoben, überwiegend mit menschlichen Vergleichsbewertungen. Trotzdem ist eine Model Card kein Werbeprospekt. Sie ähnelt eher einem Prüfprotokoll bei der Hauptuntersuchung eines Fahrzeugs, das der Hersteller allerdings selbst ausfüllt: Beschrieben werden nicht die Fahrt, sondern Messwerte, vorgesehene Einsatzbereiche und dokumentierte Mängel.

    Diese Analogie erklärt, warum eine Modellkarte so nüchtern klingt. Ein Prüfprotokoll sagt nichts darüber, ob ein Fahrzeug dir gefällt. Es sagt, was gemessen wurde, unter welchen Bedingungen und was gar nicht geprüft wurde. Genauso ist die Model Card von Nano Banana 2.1 aufgebaut: erst die Beschreibung, dann die Verweise auf das Basismodell, danach Benchmarks, Grenzen und Sicherheit.

    Was die Model Card über das multimodale Modell festhält

    Nano Banana 2.1 gehört zur Gemini-3-Familie, einer Reihe nativ multimodaler Reasoning-Modelle. Laut Model Card versteht das Modell Eingaben aus unterschiedlichen Quellen, konkret Text und Bilder, und erzeugt in der Antwort sowohl Bild- als auch Textausgabe. Als Eingabe nennt das Dokument Textstrings wie Prompts oder Dokumente sowie Bilder, bei einem Kontextfenster von bis zu einer Million Token. Auf der Ausgabeseite stehen Bilder mit einem Budget von 4K Token und Text mit bis zu 64K Token.

    Nano Banana 2.1 erzeugt Bild und Text also in derselben Antwort. Wie das intern umgesetzt ist, beschreibt die Modellkarte nicht selbst; für die Architektur verweist sie auf das Basismodell. Für die Praxis ist vor allem der Einsatzzweck interessant, den Google nennt: Das Modell soll Geminis Weltwissen nutzen, um präzise Ergebnisse von komplexen Infografiken bis zu historisch stimmigen Szenen zu liefern. Verfügbar ist es laut Modellkarte in der Gemini-App, in Google AI Studio, über die Gemini API, im AI Mode der Google-Suche sowie in Google Ads, Google Flow und Google Stitch.

    Warum fast alle Angaben auf Gemini 3.6 Flash verweisen

    Der Abschnitt zu den Model Dependencies sagt es klar: Nano Banana 2.1 basiert auf Gemini 3.6 Flash. Dasselbe gilt für Architektur, Trainingsdatensatz, Datenverarbeitung, Hardware und Software. In allen diesen Punkten verweist die Model Card auf die Gemini 3.6 Flash Modellkarte, statt eigene Angaben zu wiederholen. Das wirkt wie ein bewusstes Vorgehen: Dokumentiert wird im Wesentlichen, was das neue Modell vom Basismodell unterscheidet.

    Für Leser hat das eine praktische Folge. Wer verstehen will, woher die Trainingsdaten stammen, wie sie aufbereitet wurden oder auf welcher Hardware trainiert und betrieben wird, muss zwei Dokumente lesen. Die Modellkarte von Nano Banana 2.1 beschreibt im Wesentlichen das Delta, also die Bildausgabe, die Editierfähigkeiten und die zugehörigen Messungen. Der Rest steht im Prüfprotokoll des Grundmodells, und dessen Einschränkungen gelten weiter.

    Wie Text-zu-Bild und Bildbearbeitung gemessen werden

    Die Evaluation teilt sich in zwei Bereiche: Capability Sets und Regression Sets. Für die Capability Sets nutzt Google öffentliche Benchmarks und interne Tests. Zu den Capability Sets gehören auf der Seite der Bildgenerierung allgemeine Text-zu-Bild-Aufgaben, Textrendering über mehrere Sprachen hinweg, Factuality mit Weltwissen und Bildungsinhalten, Tool-Nutzung und visuelles Design. Auf der Bearbeitungsseite stehen allgemeine Bildbearbeitung, Stilisierung, Figurenkonsistenz, Objekt- und Umgebungseingriffe, Bearbeitung auf Basis von Kritzeleien (Ink), Multi-Image-Aufgaben wie die Neukontextualisierung mehrerer Produkte sowie Multi-Turn-Szenarien mit statischen und dynamischen Dialogen.

    Die Regression Sets sind der Gegencheck. Sie bestehen aus häufigen Anwendungsfällen, die bereits auf Gemini 2.5 Flash Image und Gemini 3 Pro Image beobachtet wurden, und sollen sicherstellen, dass Nano Banana 2.1 keine spürbaren Rückschritte zeigt. Methodisch arbeitet Google mit zwei Verfahren: einem Side-by-Side-Humaneval, das über Präferenzurteile zu Elo-Werten führt, und einem einseitigen AutoRater für Factuality. Elo-Werte sind relative Größen. Sie beschreiben nicht, wie gut ein Bild in absoluten Maßstäben ist, sondern wie es im direkten Vergleich abschneidet.

    Was die Benchmarks von Nano Banana 2.1 zeigen

    In Googles eigenen Tests mit Stand Oktober 2026 liegt das neue Modell klar vorn. Bei der allgemeinen Präferenz für Text-zu-Bild erreicht Nano Banana 2.1 im Thinking-Modus 1050 Punkte (±14), ohne Thinking 1015 (±13). Die Vergleichsmodelle liegen darunter: Gemini 3.1 Flash Image („Nano Banana 2“, Thinking) kommt auf 990 (±7), Gemini 3 Pro Image („Nano Banana Pro“) auf 935 (±8). Beim Infografik-Design liegen die Werte bei 1048, 1001, 961 und 912, also dieselbe Reihenfolge. Auffällig ist die Factuality der Infografiken: 0,521 im Thinking-Modus gegenüber 0,328 ohne Thinking, 0,179 bei „Nano Banana 2“ und 0,265 bei „Nano Banana Pro“.

    Bei der Bildbearbeitung setzt sich das Muster fort. Den größten Vorsprung zeigt die Konsistenz mehrerer Figuren. Allgemeine Bearbeitung liegt bei 1026 (±12) gegenüber 938 und 939 bei den Vergleichsmodellen. Figurenkonsistenz mit einer Figur erreicht 1028 (±14), mit mehreren Figuren sogar 1106 (±14) gegenüber 978 und 1011. Masken- und Kritzeleibearbeitung kommt auf 1049 (±15), Produktkonsistenz auf 1024 (±18), Stilisierung auf 1062 (±20) und Bearbeitung mit mehreren Referenzbildern auf 1066 (±22).

    Drei Einschränkungen sind beim Lesen dieser Zahlen zu beachten. Erstens liegt der Thinking-Modus fast überall vorn, teils um dreißig bis vierzig Elo-Punkte; bei der Konsistenz einzelner Figuren und bei der Masken- und Kritzeleibearbeitung ist der Unterschied dagegen kleiner als die Fehlerbalken. Zweitens überschneiden sich die Konfidenzintervalle der älteren Vergleichsmodelle in mehreren Kategorien, während die Abstände zum neuen Modell meist klar außerhalb liegen. Drittens hat Google die Tests selbst durchgeführt und die Vergleichsmodelle selbst ausgewählt; Modelle anderer Anbieter fehlen, eine unabhängige Überprüfung gibt es nicht. Die Rangfolge innerhalb der Google-Modelle wirkt damit plausibel, mehr sagen die Zahlen nicht.

    Wo das Modell an Grenzen stößt

    Die Model Card benennt die Schwächen offen. Kleine Texte werden weiterhin schlecht gerendert und erscheinen im 1K-Modus oft unscharf; das gilt auch für lange Absätze und seitenfüllende Layouts. Die Konsistenz von Figuren ist zwischen Eingabebild und Ausgabebild nicht immer perfekt. Bei masken- oder kritzelbasierter Bearbeitung folgt das Modell Anweisungen nur teilweise, und Tinte bleibt mitunter stehen, obwohl sie entfernt werden sollte.

    Hinzu kommen seltene, aber dokumentierte Effekte: Manchmal übernimmt ein bearbeitetes Bild die Körperhaltung und den strukturellen Aufbau des Ausgangsmotivs. Die räumliche Verortung, also links und rechts, geht gelegentlich durcheinander. Bei Weltwissen, 3D-Schlussfolgerungen und Factuality bleibt das Modell begrenzt, und wie jedes Grundmodell kann es halluzinieren. Gelegentliche Langsamkeit und Timeouts werden ebenfalls erwähnt.

    Ein Punkt betrifft die zeitliche Einordnung. Der Knowledge Cutoff von Gemini 3.6 Flash liegt im März 2026, in manchen Domänen aber bereits im Januar 2025, analog zur Gemini-3-Modellfamilie. Wer Nano Banana 2.1 für aktuelle Inhalte nutzt, sollte also nicht davon ausgehen, dass der Wissensstand überall gleich frisch ist. Für ein Modell, das Fakten in Infografiken abbilden soll, ist das eine Einschränkung mit direkter Wirkung auf die Ausgabe.

    Sicherheit, Frontier Safety und die praktische Einordnung

    Beim Human Red Teaming prüfen spezialisierte Teams außerhalb der Modellentwicklung das Verhalten des Modells; ihre Erkenntnisse fließen zurück ins Entwicklungsteam. Nach Googles Angaben erfüllt Nano Banana 2.1 bei der Kindersicherheit die geforderten Startschwellen, die von Expertenteams zum Schutz von Kindern im Netz entwickelt wurden. Im allgemeinen Vergleich zeigt das Modell ähnliche oder bessere Sicherheitsleistungen als Gemini 3 Flash, und das Red Teaming fand bei einem Vergleich mit Gemini 3.1 Pro keine schwerwiegenden Bedenken.

    Beim Frontier Safety Assessment stützt sich Google auf Evaluationen von Gemini 3.1 Pro und Gemini 3.7 Flash. Diese erreichten keine Tracked oder Critical Capability Levels, und da Nano Banana 2.1 nach Googles eigener Bewertung keine wesentlich neuen Fähigkeiten mitbringt, hält das Unternehmen es für unwahrscheinlich, dass das Bildmodell diese Schwellen erreicht. Außerdem arbeite Google laufend an der Widerstandsfähigkeit gegen Jailbreaks und habe die Schutzmaßnahmen im Frontier-Safety-Bereich zuletzt verstärkt. Dieser Teil des Dokuments zeigt sich kaum in Bildern, setzt aber den Rahmen für den produktiven Einsatz.

    Die Model Card von Nano Banana 2.1 ist ein Fortschrittsbericht des Herstellers mit klarem Umfang. Als Stärken nennt Google Bildbearbeitung mit professioneller Präzision und schnellen Iterationen, klaren Text für Poster und komplexe Diagramme, Weltwissen mit langem Kontext und mehrsprachiges Textrendering. Ein Versprechen auf Perfektion ist sie nicht. Wenn du das Modell für eine Pipeline planst, lies die dokumentierten Grenzen als Arbeitsanweisung: kleine Schrift vermeiden, Figurenkonsistenz prüfen, maskenbasierte Eingriffe nachkontrollieren, Wissensstichtage beachten. Ein Prüfprotokoll hilft nur, wenn man es vor der Fahrt liest.

    Quelle: deepmind.google

  • Der Goldrausch um KI-Entscheidungsmodelle: Jev, DecideBench und die Alternativen

    Der Goldrausch um KI-Entscheidungsmodelle: Jev, DecideBench und die Alternativen

    Welches KI-Modell trifft Entscheidungen, statt nur Text zu schreiben? Seit ein paar Wochen gibt es dafür eine eigene Produktkategorie. Wer so ein Modell in die eigene Software einbauen will, steht vor einer unübersichtlichen Auswahl. Es hilft, von den Modellnamen wegzukommen und auf die Kriterien zu schauen. Denn sie entscheiden, ob ein Entscheidungsmodell in der Produktion trägt oder nach zwei Wochen wieder ausgetauscht wird.

    Ein Vergleich hilft: Ein allgemeines Sprachmodell ist wie ein Kommentator, der ein Spiel Stunde um Stunde beschreibt. Ein Entscheidungsmodell ist der Schiedsrichter, der in Sekundenbruchteilen pfeift. Er erzählt nichts. Er liefert ein Urteil, oft mit einer Zahl, die angibt, wie sicher er sich ist. Genau darin liegt der Unterschied.

    Warum in wenigen Wochen ein ganzer Markt entstand

    Am 15. September ging Jev live, das Modell des Startups TypeSafe. Statt einer Antwort liefert es eine Auswahl, einen Score oder ein Ja beziehungsweise Nein mit angehängter Konfidenzzahl. TypeSafe sammelte in derselben Woche 40 Millionen Dollar Seed-Kapital bei einer Bewertung von 200 Millionen ein und arbeitete eine Warteliste von 140.000 Personen in 36 Stunden ab. Innerhalb eines Tages hatten 13 Prozent der zahlenden Kunden von Vercels AI Gateway Jev bereits in einen Workflow eingebaut, und binnen drei Tagen lieferten Cloudflare, LangChain und Langfuse eigene Integrationen. Swapnil Talekar, auf dessen Substack-Beitrag dieser Text zurückgeht, schreibt dazu, um eine solche Adoptionskurve planten die meisten Firmen ein ganzes Launch-Quartal. Talekar hatte erst eine Woche zuvor über Jev geschrieben und schob den Folgebeitrag nach, weil sich die Kategorie schneller entwickelte, als er darüber bloggen konnte.

    Zwei Wochen später gab es bereits Konkurrenz. Amazon brachte bis zum 1. Oktober mit Strands Decider 2B ein offenes Modell auf Basis von Qwen3.5-2B heraus, OpenAI kündigte in derselben Woche eine eigene Decisions API auf Grundlage von GPT-6 Luna an, die anders als Jev auch Bilder verarbeiten kann. Cloudflares Clef wurde als Modell mit offenen Gewichten gebaut, das sich als direkter Ersatz für Jevs API einsetzen lässt. Es landete am ersten Tag bei 465 Punkten auf Hacker News und schlug Jev in mehreren der Benchmarks, die Jev selbst veröffentlicht. Fastino legte mit GLiDE und GLiNER2.5-Decide zwei weitere Modelle nach. Auf GitHub sammelt der Tag jev-alternative bereits ein halbes Dutzend Open-Source-Klone mit Namen wie OpenJev, JevK5, von und Laya. TypeSafes eigener CEO zeigte sich unbeeindruckt und nannte den Ansturm der Konkurrenz „ML people wanting to implement a cool architecture“. Jev hat inzwischen sogar einen Wikipedia-Eintrag. Talekar folgert daraus, dass jede Empfehlung für ein bestimmtes Modell beim Erscheinen schon veraltet ist, und konzentriert sich deshalb auf Kriterien statt auf Modellnamen.

    Was DecideBench über die Qualität verrät

    Herstellerangaben sind in diesem Markt mit Vorsicht zu lesen. Fastino wählte für seinen Vergleich von GLiDE und GLiNER2.5-Decide mit Jev sowohl die Tests als auch die Modelle, gegen die getestet wurde, und TypeSafe räumte ein, dass die eigenen veröffentlichten Verbesserungen eher Best-Case-Szenarien abbilden. Umso wichtiger ist ein unabhängiger Maßstab, und den gibt es: DecideBench, ein Benchmark des Entwicklers Cho Yin Yong. Er umfasst 400 Entscheidungen mit Mehrfachauswahl aus acht Aufgabenfamilien, darunter Support-Triage, Inhaltsmoderation, Prüfung von Behauptungen und Agent-Routing.

    Auf diesem Benchmark schlägt sich Jev gut: 98 Prozent Genauigkeit bei 32 Dollar pro einer Million Aufgaben, damit ist es das günstigste Modell im Test, das die 95-Prozent-Marke überschreitet. Die allgemeinen LLMs, die bei der reinen Trefferquote besser abschneiden, kosten im Betrieb sechs- bis vierzehnmal so viel. Interessanter findet Talekar, was weiter unten in der Tabelle steht: Die kleinen, encoder-basierten Modelle, Laya eingeschlossen, kommen auf lediglich 35 bis 59 Prozent, obwohl sie die schnellsten und billigsten Optionen sind. Der Test brachte außerdem Imajev-4B hervor, ein offenes, selbst hostbares Modell, das anders als Jev Bilder annimmt und 95 Prozent erreichte. Damit gilt es im Test als bestes offenes Entscheidungsmodell. Etwa zur gleichen Zeit tauchte mit JevBench ein zweiter unabhängiger Benchmark auf.

    Sechs Fragen, die vor der Auswahl stehen

    Klär zuerst, wo das Modell laufen soll. Jev und die Decisions API von OpenAI sind gehostet, während Clef, Decider 2B, GLiNER2.5-Decide, Imajev-4B und die übrigen Klone selbst oder am Rand des Netzwerks betrieben werden können. Sind die Daten zu sensibel, um sie an Frontier-Labore zu schicken, ist Selbst-Hosten laut Talekar eine gute Option. Genauso wichtig sind die Eingabedaten. Jev verarbeitet Text, Strings, JSON und Listen von Strings, während die Decisions API und Imajev-4B zusätzlich Bilder annehmen. Sobald irgendwo in der Pipeline ein Screenshot, ein gescanntes Formular oder das Foto eines beschädigten Produkts bewertet werden muss, entscheidet diese eine Frage die Modellwahl.

    Dann die Geschwindigkeit. Jev wirbt mit 70 bis 500 Millisekunden, GLiNER2.5-Decide nennt 38 Millisekunden auf einer GPU, Laya rund 33 Millisekunden pro Frage. Für die Zuordnung eines Support-Tickets in die richtige Warteschlange ist der Unterschied zwischen 70 und 500 Millisekunden kaum spürbar. In einer Echtzeit-Spielschleife oder einem Handelssystem dagegen zählt jede Millisekunde. Dort ist die Latenz der Entscheidung alles, und der Kompromiss zwischen Tempo und Genauigkeit gewinnt an Gewicht.

    Dann ist da die Kalibrierung. Ein Modell nützt nur, wenn es auf den eigenen Daten ähnlich zuverlässig arbeitet wie in der Werbung. Die Prüfung ist einfach: Du ziehst eine Stichprobe vergangener Entscheidungen, die das Modell getroffen hätte, mindestens einige hundert, sortierst sie nach der angegebenen Konfidenz in Bänder von zehn Prozentpunkten und vergleichst je Band die angegebene Konfidenz mit der tatsächlichen Trefferquote. Sagt das Modell 90 Prozent und das Band liefert in Wahrheit 65, solltest du dich nach einer Alternative umsehen. Zuletzt die Kosten: Jev kostet 0,042 Dollar pro einer Million Eingabe-Tokens bei kostenloser Ausgabe. Das klingt harmlos, bis du es mit dem täglichen Entscheidungsvolumen multiplizierst. Bei großen Mengen kann Selbst-Hosten günstiger sein, aber du tauschst den Tokenpreis nur gegen eigene Rechenleistung und Wartung ein. Automatisch billiger ist keins von beidem.

    Bleiben die Wechselkosten. Cloudflare hat Clef bewusst als direkten Ersatz für Jevs API gebaut, damit Kunden beide vergleichen und tauschen können. Für die meisten anderen Modelle gilt das nicht, ihre Schnittstellen sind zueinander inkompatibel, und ein Wechsel bedeutet echte Arbeit. Wer heute auf ein Entscheidungsmodell setzt, bindet sich also nicht nur an ein Modell, sondern auch an die Mühe, es später wieder loszuwerden.

    Zwei Beispiele aus der Praxis

    Zuerst die Support-Triage, bei der täglich ein paar tausend Tickets in Abrechnung, Technik und Abwanderungsrisiko einsortiert werden. Die Einsätze sind hier niedrig, eine falsch zugeordnete Anfrage kostet einen Menschen ein bis zwei Minuten Weiterleitung. Deshalb zählen Kosten pro Aufgabe und Latenz mehr als die letzten Genauigkeitspunkte. Jev liegt mit 32 Dollar pro einer Million Aufgaben bei 98 Prozent Genauigkeit auf DecideBench damit als Standard nahe, während Strands Decider 2B interessant wird, wenn man ohnehin tief in AWS steckt und dieselbe Arbeit selbst hosten möchte. Die Kalibrierung fällt hier aus demselben Grund weniger ins Gewicht. Das ist der Fall, für den Entscheidungsmodelle gebaut wurden.

    Anders, wenn ein Agent entscheiden soll, welchen Werkzeugaufruf er als Nächstes macht, und das mitten in einer laufenden Spielschleife oder einem Handelssystem, in dem ein paar hundert Millisekunden Tausende Dollar kosten können. Hier zählen Genauigkeitsunterschiede im einstelligen Bereich kaum, die Latenz dafür umso mehr. GLiNER2.5-Decide mit 38 Millisekunden auf der GPU oder Laya mit rund 33 Millisekunden wirken allein wegen des Tempos attraktiv. Genau an dieser Stelle musst du jedoch die 35 bis 59 Prozent Genauigkeit der Encoder-Modelle gegenrechnen. Eine Routing-Entscheidung, die in einem Drittel der Fälle falsch liegt, ist wenig wert, auch wenn sie schnell ist; sie liegt dann eben schnell falsch. Bei einem sehr engen Latenzbudget empfiehlt es sich, Jevs 70-Millisekunden-Angabe am eigenen System zu prüfen und nur bei Bedarf auf ein weniger genaues Modell auszuweichen.

    Konsolidierung oder dauerhafte Aufspaltung

    Talekar wagt eine Prognose: Entweder konsolidiert sich die Kategorie stark um jenes Modell, auf dem das meiste Werkzeug aufbaut, worauf Jevs Drei-Tage-Vorsprung bei Cloudflare, LangChain und Langfuse hindeutet. Oder sie teilt sich dauerhaft nach Anwendungsfall auf, mit billigen offenen Modellen für Massen-Triage und gehosteten APIs für alles, was eine Erklärung braucht. Er selbst setzt auf eine Mischung aus beidem. Die Kriterien bleiben nach seiner Einschätzung so oder so gültig, auch wenn ständig neue Modelle erscheinen.

    Unsere Einordnung für die Kostenplanung: Ein Entscheidungsmodell gegen ein allgemeines LLM durchzurechnen, lohnt sich, denn auf DecideBench kosten die allgemeinen Modelle sechs- bis vierzehnmal so viel wie Jev, liegen bei der reinen Trefferquote aber nur knapp darüber. Die Wahl des Anbieters ist dagegen eher eine Wette auf ein Ökosystem als auf ein einzelnes Modell. Wer sich an offene Gewichte bindet, gewinnt Unabhängigkeit und verliert Bequemlichkeit. Wer auf eine gehostete API setzt, gewinnt Tempo beim Einstieg und verliert Kontrolle über Daten und Wechselkosten. Beide Wege sind vertretbar, solange man sie bewusst geht.

    Quelle: swapniltalekar.substack.com

  • Mistral Large 4: Was Mistral für sein offenes Modell mit einer Billion Parametern verspricht

    Mistral Large 4: Was Mistral für sein offenes Modell mit einer Billion Parametern verspricht

    Mistral nennt für sein neuestes Modell eine Billion Parameter, von denen bei jeder Anfrage 49 Milliarden aktiv sind. Mistral Large 4 macht der französische Anbieter seit dem 6. Oktober als öffentliche Vorschau zugänglich. Alle folgenden Angaben stammen aus Mistrals eigener Ankündigung im Firmenblog; Benchmarks und Vergleiche sind also überwiegend Herstellerangaben. Technisch handelt es sich laut Produktbeschreibung um ein Mixture-of-Experts-Modell: Es besteht aus vielen spezialisierten Teilnetzen, von denen pro Anfrage nur ein Bruchteil anspringt. Solche Architekturen sollen Rechenkosten und Antwortzeiten senken, weil nie das ganze Modell rechnen muss.

    Wichtiger noch als die Architektur sind die offenen Gewichte. Mistral will sie bis Ende des Monats veröffentlichen, zusammen mit Details zur Architektur, weiteren Benchmarks und der Methodik des Nachtrainings. Bis dahin läuft laut Unternehmen ein Red-Teaming in realen Umgebungen, mit Sicherheitsfirmen, geprüften Partnern und staatlichen Stellen, die dieselbe Modellversion mit reduzierter Moderation und erweiterten Cyber-Fähigkeiten bekommen. Wer selbst bestimmen will, was seine Systeme tun, kann mit offenen Gewichten selbst hosten und muss nicht auf einen Anbieter warten.

    Eine Billion Parameter, von denen 49 Milliarden pro Anfrage arbeiten

    Nativ multimodal heißt: Text und Bild kommen nicht über nachträglich angeflanschte Zusatzmodule zusammen, sondern stecken von Beginn des Trainings an gemeinsam im Modell. Laut Mistral wurde es von Grund auf auf 3.800 NVIDIA-Grace-Blackwell-Beschleunigern in eigenen Rechenzentren in Europa trainiert, und die öffentliche Vorschau läuft auf derselben Infrastruktur. Ein großer Teil der Trainingsdaten war mehrsprachig, über 160 Sprachen, darunter jede Amtssprache der Europäischen Union. Inoffiziell heißt das Modell ML4, ganz offiziell, so die Ankündigung mit Augenzwinkern, le Chonk.

    Mistral nennt Mistral Large 4 das größte und leistungsfähigste eigene Modell und einen Meilenstein der offenen Gewichte. Nach eigenen Angaben hält es mit den stärksten Open-Source-Modellen weltweit mit und übertrifft alle Open-Weight-Modelle aus den USA oder Europa deutlich. Bei Unternehmensaufgaben in Cybersecurity, Finanzwesen und Recht soll es unter den offenen Modellen vorn liegen. Solche Sätze kommen vom Hersteller selbst. Was sie wert sind, zeigt sich erst an konkreten Zahlen.

    Öffentliche Vorschau, offene Gewichte und die Frage der Souveränität

    Die Preview-API steht ab sofort in Mistral Studio bereit, die Gewichte folgen Ende des Monats. Das Modell wird in mehreren Regionen weltweit verfügbar sein, darunter eine europäische Bereitstellung, die Mistral nach eigener Darstellung durchgängig selbst betreibt, unabhängig von anderen digitalen Dienstleistern und unter europäischem Recht. Wer ein Modell selbst hostet, entscheidet über Protokolle, Aufbewahrungsfristen und Zugriffsrechte und muss nicht damit rechnen, dass eine Funktion mitten im Betrieb abgeschaltet oder umgestellt wird.

    Offene Gewichte sind allerdings nicht dasselbe wie Open Source im klassischen Sinn. Veröffentlicht werden die trainierten Parameter, also das Ergebnis des Lernprozesses, nicht die Trainingsdaten und in der Regel auch nicht der vollständige Trainingscode. Du kannst ein Modell damit inspizieren, lokal betreiben und weiterentwickeln, aber seine Herkunft nicht vollständig nachvollziehen. Wer das für die Compliance prüft, sollte den Unterschied kennen. Wie Mistral das bei Large 4 handhabt, ist noch offen; die Ankündigung äußert sich weder zur Lizenz noch zu den Trainingsdaten. Sie nennt nur, dass das Modell in enger Zusammenarbeit mit Unternehmen aus Finanzwesen, Fertigung, Logistik, Pharma und öffentlichem Sektor trainiert wurde und dieselbe Trainings-, Anpassungs- und Reinforcement-Learning-Umgebung nutzt, die Kunden über Mistral Forge buchen können.

    Cybersecurity: Der Test, bei dem geschlossene Modelle verweigern

    Nach Mistrals Darstellung liegt das Modell im Artificial Analysis Cyber Index, einer unabhängigen Bewertung, wie gut KI-Modelle Sicherheitslücken in realer Software finden und beheben, unter den fünf besten Modellen weltweit und führt die Open-Weight-Modelle außerhalb Chinas deutlich an. In einem Test des Index, bei dem ein Modell eine echte Schwachstelle in Open-Source-Software reproduzieren und anschließend patchen muss, erreicht es 82 Prozent, laut Mistral den höchsten Wert aller Modelle. In Cybench, einer Sammlung von 40 Aufgaben aus Sicherheitswettbewerben, löst es 93 Prozent. Mistral spricht von einem der höchsten Werte, die für ein Open-Weight-Modell gemeldet wurden.

    Die zweite Hälfte des Arguments ist die Ablehnung. Mehrere führende geschlossene Modelle, darunter Claude Opus 5.5 und GPT-6 Astra, erzielen im selben Test Werte nahe null, weil sie die Aufgabe verweigern. Mistral führt das auf die Sicherheitsfilter der geschlossenen Modelle zurück. Software zu verteidigen beginne oft damit, zu beweisen, dass ein Fehler real ist, und genau diese Arbeit könnten solche Filter blockieren. Daraus formuliert Mistral eine unbequeme These: Wenn Angreifer dieselben Modelle mit Jailbreaks für offensive Zwecke nutzen, brauchen Verteidiger Systeme mit vergleichbaren Fähigkeiten, die nicht an denselben Verweigerungen hängen. Ob diese Abwägung aufgeht, lässt sich mit Benchmarks allein nicht beantworten. Die Version mit reduzierter Moderation gibt Mistral vorerst nur geprüften Partnern.

    Das Modell soll auch jenseits dessen nützlich sein, worauf es explizit trainiert wurde. In internen Tests habe es bei der Analyse von Schadsoftware, der Priorisierung von Schwachstellen und dem Schreiben von Erkennungsregeln geholfen. Für Sicherheitsteams, die nachvollziehbare Abläufe brauchen, soll es auf privater Cloud oder im eigenen Rechenzentrum laufen. Gleichzeitig meldet Mistral, dass Mistral Large 4 im Lakera B3 AI Security Benchmark 93,3 Prozent der Angriffe abwehrt und beim KORA-Benchmark 1,691 erreicht, bei einem Maximum von 2. Auf Cyber-Prompts aus JailbreakBench, StrongREJECT und AgentHarm liegt die durchschnittliche Verweigerungsrate sogar höher als bei allen offenen Vergleichsmodellen.

    Code, Agenten und der Blick auf Bilder

    Im Software-Engineering erreicht Mistral Large 4 nach Herstellerangaben 61,7 Prozent auf DeepSWE v1.1, 59,4 Prozent auf SWE-Atlas-QnA und 28,3 Prozent auf Terminal-Bench 4. Der kombinierte Coding-Agent-Index liegt bei 49,8 Prozent und damit vor DeepSeek V4 Pro 0813 und Qwen3.8 Max. In einer verblindeten Bewertung mit Surge AI, bei der professionelle Annotatoren die Ausgaben auf einer Skala von 1 bis 5 beurteilten, landete die Vorschauversion mit 3,74 auf Platz zwei von fünf Modellen, hinter Claude Opus 5 mit 4,22 und vor Kimi K3, GLM-5.3 und GLM-5.2. Die Bewertung hat Mistral selbst durchführen lassen; sie misst Codequalität bei verdeckten Modellnamen, bleibt aber eine Momentaufnahme mit fünf Modellen.

    Bei Agenten, also Systemen, die selbstständig Informationen sammeln, Werkzeuge bedienen und Ergebnisse abliefern, nennt Mistral 59,9 Prozent auf AutomationBench, einer Sammlung von 657 Geschäftsabläufen rund um Gmail, Google Sheets, Slack und Salesforce. Auf AA-Briefcase, das lange Wissensarbeit bewertet, kommt das Modell auf 1.393 Elo und liegt damit vor DeepSeek V4 Pro. Bei AutomationBench sieht Mistral sein Modell außerdem vor Kimi K3 und MiMo-V2.6-Pro. Ob ein Modell über lange Abläufe verlässlich bleibt, zeigt sich allerdings erst im eigenen Einsatz; Benchmarks liefern dafür nur einen Anhaltspunkt.

    Am deutlichsten hebt Mistral den Sprung bei Bildern hervor. Das Modell liest komplexe Dokumente, Diagramme und natürliche Aufnahmen und verbindet visuelles Verankern mit agentischen Fähigkeiten: von der Auswertung gigapixelgroßer Satellitenbilder für Katastropheneinsätze bis zur Analyse technischer Zeichnungen, bei der so lange hineingezoomt wird, bis die Antwort sitzt. Beim visuellen Verankern, also dem präzisen Zuordnen von Bildbereichen zu Aussagen, übertrifft Mistral Large 4 nach eigenen Messungen sogar GPT-6-Astra im Dense-200-Test mit 42 zu 41 Prozent. Ein Prozentpunkt in einem einzelnen, von Mistral ausgewählten Test reicht allerdings nicht, um daraus einen generellen Gleichstand mit geschlossenen Spitzenmodellen abzuleiten.

    Wissen, Recht, Finanzen und das Training am laufenden Modell

    Bei wissenschaftlichen Aufgaben bezeichnet Mistral sein Modell als führend unter den offenen Gewichten, gemessen am SciCode-Verified-Test. In der Praxis soll es eine vollständige Hartree-Fock-Simulation in einem Durchgang erzeugen, also eine mehrstufige quantenchemische Rechnung, die aus einer ganzen Kette fortgeschrittener Einzelroutinen besteht. In eigenen Vergleichen argumentiere es präziser und strukturierter als GLM-5.3 und halte lange, anwendungsnahe Mathematikaufgaben durch. Für Wissensarbeit nennt der Anbieter außerdem FinWorkBench für Tabellenarbeit in Finanz und Buchhaltung sowie Harveys Legal-Agent-Benchmark, wo das Modell alle offenen Konkurrenten übertreffen soll. Externe Prüfungen durch vals.ai auf repräsentativen Rechts- und Finanzaufgaben sehen es nach Angaben von Mistral in beiden Fällen vor GPT-6-Astra.

    Ein Abschnitt der Ankündigung handelt vom Training selbst. Mistral schreibt, dass Basismodelle sich schnell verbessern und die Nachbearbeitung Schritt halten muss: Ein Rezept, das für das gestrige Modell passte, lässt beim heutigen Leistung liegen, weil Aufgaben, die früher an die Grenze gingen, inzwischen trivial sind. Deshalb setzt das Unternehmen auf Reinforcement Learning, also auf Training anhand der Ergebnisse eigener Lösungsversuche, bei dem Schwierigkeit und Breite der Aufgaben mitwachsen. Eine gemeinsame, kombinierbare Schnittstelle erlaubt es, in einem Trainingslauf Aufgaben von kurzen Dialogen über wissenschaftliches Problemlösen bis zu Sicherheitsausrichtung und langfristiger Werkzeugnutzung zu mischen. Diese Umgebungen teilen sich Code-Sandboxes, Websuche und externe Schnittstellen. Bei der derzeitigen Größe von rund dreitausend GPUs erzeuge ein einzelner Trainingslauf etwa 33 Milliarden Tokens pro Tag, davon rund 16 Milliarden trainierbare.

    Was das praktisch heißt

    Für Teams, die heute über den Einsatz entscheiden, sind drei Punkte wichtig. Erstens lässt sich die Preview-API sofort testen, und wer eigene Aufgaben mitbringt, erfährt mehr über das Modell als aus jeder Benchmark-Tabelle. Zweitens lohnt es sich, auf die Gewichte und die zugehörige Lizenz zu warten, denn erst dann zeigt sich, ob Self-Hosting unter eigenen Regeln praktisch und wirtschaftlich trägt. Drittens sind viele der genannten Zahlen Herstellerangaben, teils aus internen Tests, und sollten auch so behandelt werden.

    Für die Vorschau-API nennt Mistral 1,36 US-Dollar pro Million Eingabe-Tokens und 4,18 US-Dollar pro Million Ausgabe-Tokens. Das Modell soll zudem die Basis für eine neue Generation spezialisierter Mistral-Modelle werden. Finanziert wird der Ausbau laut Ankündigung aus einer Series-D-Runde über 3 Milliarden Euro, nach Mistrals Angaben die größte Eigenkapitalrunde, die ein europäisches Technologieunternehmen je eingesammelt hat. Der Reinforcement-Learning-Lauf hinter der Vorschau sei noch nicht abgeschlossen und zeige keine Sättigung; Mistral erwartet in den kommenden Wochen und Monaten deutliche Verbesserungen. Das ist eine Ankündigung, kein Messwert.

    Unsere Einordnung: Ein offenes Modell mit einer Billion Parametern, trainiert auf europäischer Infrastruktur und unter europäischem Recht betreibbar, macht aus dem Schlagwort KI-Souveränität eine Frage der Infrastruktur. Ob ein Unternehmen im Ernstfall eigene Regeln anwenden darf, dürfte künftig weniger von Grundsatzpapieren abhängen als davon, wo die Gewichte liegen und wer den Strom dafür liefert.

    Quelle: mistral.ai

  • Agent Loops mit kleinen Modellen: Warum die Prüfung wichtiger ist als das Modell

    Agent Loops mit kleinen Modellen: Warum die Prüfung wichtiger ist als das Modell

    Wie bringt ein kleines Modell eine große Aufgabe zu Ende? Alice Moore beschreibt im Firmenblog von Builder.io zwei Experimente, die das Team an seinem eigenen Open-Source-Framework Agent-Native gemacht hat. Der Text ist also ein Erfahrungsbericht des Herstellers über das eigene Produkt. Ein Agent Loop hält einen Coding Agent bei der Arbeit: ein Versuch nach dem anderen, so lange, bis irgendeine Instanz sagt, dass die Aufgabe erledigt ist. Die Schleife ist der einfache Teil.

    Die Arbeit steckt in diesem „irgendetwas“. Gemeint ist eine Prüfung, die der Agent selbst ausführen kann und die ihm nach jedem Versuch sagt, ob er näher am Ziel ist. Wer schon einmal einen Ralph Loop oder den Befehl /goal ausprobiert hat, kennt die eine Hälfte des Prinzips: Der Agent hört einfach nicht auf. Die andere Hälfte nennt Geoffrey Huntley Back Pressure – Tests, Builds, Typprüfungen und alles andere, was einen schlechten Versuch zurückweisen kann. Beide Projekte hatten keine Testsuite. Das Team musste sich den Gegendruck selbst bauen.

    Als roter Faden hilft eine einfache Vorstellung: der Agent als Lehrling in einer Werkstatt, der ein Maßband in die Hand bekommt. Die Schleife ist die Wiederholung, das Maßband die Prüfung. Erst wenn der Lehrling selbst messen kann, darf er ohne ständige Aufsicht arbeiten.

    Was ein Agent Loop leistet und wo die Arbeit steckt

    Ein Agent Loop ist unspektakulär: Der Coding Agent macht eine Änderung, führt die Prüfung aus, liest deren Ausgabe und versucht es erneut. Der Wert liegt nicht in der Schleife, sondern in der Qualität des Signals, das sie abbricht. Ohne dieses Signal dreht sich der Loop entweder ewig, oder er hält nach dem ersten halbwegs plausiblen Ergebnis an.

    In der Werkstatt-Analogie ist das Maßband wichtiger als die Arme, die es halten. Ein KI-Agent ohne Testsuite steht vor genau diesem Problem: Er kann beliebig oft arbeiten, aber er erfährt nie, ob seine Arbeit besser geworden ist. Ein großer Teil der Konstruktionsarbeit ist deshalb keine Modellfrage, sondern eine Messfrage.

    Moore beschreibt zwei Aufgaben, die sich als Lehrstücke eignen, weil bei keiner von beiden eine fertige Testsammlung existierte. Beide enden mit derselben Erkenntnis: Die Verbesserung zwischen den Runden kam fast immer von einer besseren Prüfung, nicht von einem größeren Modell.

    Der Pixel-Diff als Maßband für Figma-Importe

    Die erste Aufgabe betraf die Importfunktionen von Agent-Native, dem kostenlosen Open-Source-Framework von Builder.io mit zugehörigen Apps. Nutzer wollten Figma-Dateien in Agent-Native Design und Präsentationen in Agent-Native Slides bringen. Die Ergebnisse waren zunächst schlecht: Diagramme zerfielen in lose Einzelformen, Icons verschwanden, eine Folie kam als schwarzes Rechteck heraus. Eine einzige Folie wich in 88 Prozent ihrer Pixel vom Original ab.

    Die erste Schleife war die naheliegende: hinschauen, beschreiben, was falsch ist, den Agenten um eine Korrektur bitten, wieder hinschauen. Das funktioniert, aber nur so schnell, wie ein Mensch Folien anschauen kann. Der Agent wusste außerdem nur, was ihm jemand ins Chatfenster getippt hatte. Das Team war der Prüfer und tippte immer wieder Sätze wie „still wrong, the heading moved again“ in den Chat.

    Der entscheidende Schritt war die Einsicht, dass jedes importierte File bereits eine richtige Antwort mitbringt: das Original. Statt visuell zu urteilen, rendert man Original und Konvertierung und vergleicht sie mit einem Pixel-Diff. Ein Pixel-Diff vergleicht zwei Bilder und markiert jedes Pixel, das sich unterscheidet. Werkzeuge wie pixelmatch oder ImageMagicks compare erledigen das ohne großen Aufwand.

    Die Prüfung lieferte dem Agenten zwei Dinge: eine Zahl und ein Bild, in dem alle Abweichungen rot markiert waren. Die Zahl sagte ihm, ob eine Änderung geholfen hatte. Die rote Markierung sagte ihm, wo er als Nächstes hinschauen sollte. Über ein Wochenende brachte ein kleineres OpenAI-Modell die Abweichung der Problemfolie von 88 Prozent auf 2 Prozent.

    Warum das Prüfwerkzeug selbst geprüft werden muss

    Ein Agent, der gegen eine Zahl arbeitet, glaubt dieser Zahl. Das ist praktisch, solange die Zahl stimmt, und gefährlich, sobald sie es nicht tut. Genau hier lag die Fehlerquelle: Nicht geladene Schriften ließen einen Export 17 Prozent abweichen, während der tatsächliche Unterschied bei 0,19 Prozent lag. Insgesamt fand das Team vier solcher Fehler in der Prüfung selbst.

    Aus diesen Läufen stammt ein Satz, der die ganze Disziplin zusammenfasst: Eine Treue-Zahl ist eine Behauptung über den Konverter, also muss das Prüfgerüst mindestens so vertrauenswürdig sein wie das, was es bewertet. Ein Maßband, das falsch geeicht ist, macht jeden Lehrling schlechter, nicht besser.

    Zweitens musste definiert werden, was nicht zählt. Unterschiede in der Schriftdarstellung waren nicht lohnend, also wurden sie ausdrücklich ignoriert. Drittens brauchte die Prüfung echte Beispiele. Ein paar aufgeräumte Musterdateien hätten dem Agenten ein bequemes Durchrutschen erlaubt, deshalb sammelte das Team eine breite Auswahl an Community-Dateien: .fig-Dateien, die Figma-API, PowerPoint, PDF und Google Slides. Jede Änderung wurde gegen das gesamte Korpus bewertet.

    Das zahlte sich aus: Die Notizen verzeichnen zwei Korrekturen, die laut Team „made the frame better and the corpus worse“, also eine einzelne Folie verbesserten und das Gesamtergebnis verschlechterten. Beide wurden zurückgenommen. Mit einer belastbaren Prüfung brauchte die Schleife nur noch ein Modell, das nicht aufgab. Es musste nicht das beste sein.

    Verwendet wurde Luna, eines der kleineren Modelle von OpenAI, auf der höchsten Einstellung über einen ChatGPT-Pro-Plan. Die grobe Schätzung des Teams: Ergebnisse nahe am Opus-Niveau für ein Zehntel bis ein Zwanzigstel des Preises, und auf diesem Tarif läuft das Modell tagelang ohne Limit. Abweichungen von 20, 40, teils 50 Prozent sanken auf einstellige Werte, oft auf Bruchteile eines Prozents. Import- und Exportprobleme waren nach Angaben von Builder.io zuvor die häufigste Rückmeldung gewesen, mit Dutzenden Berichten pro Tag. Nach dem Loop seien sie ausgeblieben, und Randfälle, die Nutzer später fanden, ließen sich leicht beheben.

    Ein zweiter Loop: statische Seite aus Screenshots nachbauen

    Um den Teil vor dem Modell sichtbar zu machen, baute das Team einen zweiten Loop von Grund auf – an einer Aufgabe, die sich nachstellen lässt. Der Auftrag: den Kopfbereich eines Blogposts als statische HTML- und CSS-Seite nachbauen, ausschließlich anhand von Screenshots. Der Agent bekam Screenshots in drei Breiten, die Schriften, die Bilder und den Seitentext. Die Prüfung rendert die entstehende Seite in einem Headless-Browser und vergleicht sie mit den Screenshots.

    Die Arbeit wurde bewusst geteilt: Ein starkes Modell baut die Prüfung, ein kleines läuft gegen sie. Als starkes Modell diente Claude. Der Prompt, den das Team mit Claude durchging, lautete sinngemäß, ein kleineres Modell solle an dieser Aufgabe arbeiten, bis sie fertig ist. Bevor jemand mit dem Reparieren anfängt, wird die Schleife gebaut, in der es laufen wird. „Fertig“ wird in eine Prüfung übersetzt, die eine Punktzahl oder ein Bestanden/Durchgefallen liefert. Es werden vielfältige, echte Beispiele gesammelt und einige als Holdout zurückgelegt. Die Prüfung muss wiederholbar sein und nachweislich ein bekannt gutes von einem bekannt schlechten Ergebnis unterscheiden. Außerdem werden die Unterschiede aufgelistet, die nicht zählen sollen, dazu ein Budget und Abbruchbedingungen. Das Ganze wird als Brief geschrieben, dem das kleinere Modell ohne Rückfragen folgen kann.

    Claude baute daraufhin die Prüfung, einen einseitigen Brief und einen Satz von Testseiten. Die Prüfung fiel durch ihren eigenen Test – zweimal. Die erste Version zählte abweichende Pixel als Anteil des gesamten Screenshots. Da die Seite einen dunklen Hintergrund hat, stimmen die meisten Pixel überein, selbst wenn nichts auf der Seite steht; eine leere Seite kam auf 3 bis 5 Prozent. Nach der Umstellung auf den sichtbaren Inhalt sprang die leere Seite auf 57 Prozent und mehr.

    Die zweite Version war zu streng. In der schmalsten Breite ergab eine Verschiebung der ganzen Seite um ein einziges Pixel eine Abweichung von 31 Prozent. Ein solcher Versatz fällt niemandem auf, also lernte die Prüfung, ihn zu verzeihen. Danach passten die Werte zum sichtbaren Eindruck: Original zweimal gerendert ergibt 0 Prozent, alles um ein Pixel verschoben ebenfalls 0 Prozent, eine um drei Pixel versetzte Überschrift 9 Prozent, ein fehlendes Hero-Bild 13 bis 34 Prozent, eine falsche Schrift 41 bis 48 Prozent, eine leere Seite 57 bis 76 Prozent.

    Die Bestehensgrenze lag bei 2 Prozent des sichtbaren Inhalts, in jeder Breite. Das entspricht ungefähr einem Button, der vier Pixel daneben sitzt. Zusätzlich behielt das Team Beispiele zurück: Luna arbeitete mit 390, 768 und 1280 Pixeln Breite, die Breiten 1024 und 1440 blieben unter Verschluss. Damit ließ sich prüfen, ob das Modell die Seite gelöst hatte oder nur die Screenshots gelernt.

    Vier Runden mit einem kleinen Modell

    Der Prompt für Luna war eng gefasst: dem Brief folgen, immer nur eine Änderung auf einmal, danach die Prüfung ausführen und deren Ausgabe lesen. Die Prüfung, die Beispiele und die Toleranzen durften nicht bearbeitet werden. Wer glaubt, eine davon sei falsch, soll anhalten und den Grund erklären. Weiterlaufen, bis die Prüfung in allen Beispielen besteht, das Budget aufgebraucht ist oder es nicht weitergeht. Danach den Holdout-Satz ausführen und die Ergebnisse melden. Über vier Runden hinweg hat Luna die Prüfung nie angefasst – obwohl ein Agent, der eine Zahl senken will, es oft einfacher findet, die Messung zu ändern als den Code.

    In Runde eins bekam Luna auf hoher Einstellung ein Budget von 90 Minuten. Der erste Versuch lag bei 41,5 Prozent, nach 34 Minuten hing das Modell bei 16,7 Prozent fest. Die Seite sah dabei fast identisch mit dem Original aus. Der naheliegende Reflex wäre gewesen, dem Modell die Schuld zu geben und ein größeres zu nehmen; geholfen hätte das nicht. Die Prüfung war falsch: Die Toleranz verzieh nur ganze Pixel, halbe Pixel zählten voll. Nach der Korrektur fiel Lunas Seite auf etwa 2 Prozent. Bei 1024 Pixeln Breite, einer Breite, die es nie gesehen hatte, schaltete sie allerdings zu früh auf das volle Menü um und verlor den linken Rand.

    In Runde zwei kam eine Zeile in den Brief: Die Seite muss in jeder Zwischenbreite halten. Luna bestand die drei geprüften Breiten in neun Minuten, und der Holdout fiel genau so durch wie zuvor. Das Modell hatte den Satz gelesen, aber keine Möglichkeit, ihn zu überprüfen – also reparierte es, was die Prüfung sehen konnte. Alles, was zählt, muss in der Prüfung stehen, nicht im Brief.

    In Runde drei wanderten 1024 und 1440 in die Prüfung; drei neue Breiten wurden zurückgelegt. Luna bestand alle fünf geprüften Breiten in fünf Minuten und fiel bei allen drei neuen durch. Das war der schnellste Durchlauf und das schlechteste Ergebnis. Ein schnelles Bestehen ist ein Grund, genauer hinzuschauen. Der Grund steckte im CSS: Der Menübutton wurde nur zwischen 1024 und 1100 Pixeln angezeigt, gerade genug für die eine sichtbare Breite. Außerdem war der Buchstabenabstand eines Absatzes um 0,03 Pixel verschoben, damit der Text bei 390 richtig umbrach.

    In Runde vier orientierte sich das Team an Cheng Lou, der Pretext gegen den Browser selbst prüfte, indem er Claude Code und Codex die Ground Truth des Browsers zeigt und sie bei jeder signifikanten Containerbreite dagegen messen und iterieren lässt, über Wochen. Die Prüfung bekam 28 Breiten, fünf weitere blieben zurück. Luna brauchte 59 Minuten und 55 Prüfläufe, um alle 28 zu bestehen; drei der fünf zurückgelegten Breiten bestanden ebenfalls. Das Ergebnis ist eine Seite, die fast überall richtig aussieht. Das Stylesheet ist eine andere Geschichte: 21 Media Queries, viele davon decken nur 25 bis 50 Pixel ab. Ein Mensch würde ein paar fluide Regeln schreiben. Die Prüfung maß Pixel, und Pixel hat Luna geliefert. Wäre die Qualität des Codes wichtig, und bei echter Arbeit wäre sie das, bräuchte sie laut Moore eine eigene Prüfung.

    Runde Was geändert wurde Lunas Zeit Prüfläufe Geprüfte Breiten Zurückgelegte Breiten
    1 Erster Lauf 34 min 63 bei 16,7 % hängengeblieben 0 von 2 bestanden
    2 Halbe-Pixel-Toleranz korrigiert 9 min 15 3 von 3 bestanden 0 von 2 bestanden
    3 5 Breiten geprüft, 3 neue zurückgelegt 5 min 6 5 von 5 bestanden 0 von 3 bestanden
    4 28 Breiten geprüft, 5 neue zurückgelegt 59 min 55 28 von 28 bestanden 3 von 5 bestanden

    Was das für eigene Agent-Loop-Projekte bedeutet

    Beide Läufe führen zu denselben praktischen Hinweisen. Suche zuerst die richtige Antwort, die bereits existiert: die Ausgabe einer alten Implementierung, das Verhalten des Browsers selbst, Beispiele aus einer Spezifikation, aufgezeichneter Produktionsverkehr oder ein Benchmark, den man schlagen will. Ohne eine solche Referenz bleibt jede Prüfung Geschmackssache, und Geschmackssache kann kein Agent selbst messen.

    Über alle vier Runden verbrachte Luna weniger als zwei Stunden mit der eigentlichen Kleinarbeit. Jeder Sprung zwischen den Runden kam laut Moore von einer Änderung an der Prüfung, nicht vom Modell. Daraus leitet sie weitere Regeln ab. Teste die Prüfung, bevor du ihr traust: Dasselbe zweimal gerendert muss null ergeben, bekannt schlechte Ergebnisse müssen schlecht abschneiden, akzeptable gut. Schreib auf, was nicht zählt, sonst verbringt der Agent Stunden mit Rauschen. Nutze echte Beispiele, bewerte jede Änderung gegen den ganzen Satz und halte einige zurück, um zu sehen, ob der Agent das Problem gelöst oder nur die Beispiele gelernt hat.

    Alles, was zählt, gehört in die Prüfung, denn der Agent tut, was die Zahl belohnt. Die Prüfung selbst bleibt außer Reichweite: Der Agent soll wissen, dass sie feststeht, und anhalten und erklären, wenn er sie für falsch hält. Das Bauen übernimmt ein starkes Modell, die Kleinarbeit ein kleines. Vor der Punktzahl kommt der Blick auf das Ergebnis, denn ein Stillstand kann an der Prüfung liegen und ein schnelles Bestehen an einer Abkürzung. Und schließlich sollte die Prüfung bleiben: Die finalen Werte werden als Obergrenzen in einen Test übernommen, damit eine spätere Verschlechterung auffällt.

    Visuell muss die Prüfung nicht sein. P90-Antwortzeiten, Fehlerraten, überprüfbares Nutzerverhalten, automatisierbare Browser-Abläufe oder schlichte Unit-Tests liefern einem Agenten ebenfalls eine Zahl oder ein Bestanden/Durchgefallen, gegen das er arbeiten kann, ohne nachzufragen. Moore schließt mit der Frage, welche Sache man bisher von Hand prüft und was nötig wäre, um sie zu messen. Der Beitrag endet mit einem Hinweis auf die eigenen Produkte: Wer sehen will, wo der Loop gelandet ist, kann eine Figma-Datei in Agent-Native Design oder eine Präsentation in Agent-Native Slides importieren. Unabhängig geprüft sind die genannten Ergebnisse nicht; es handelt sich um Angaben des Herstellers.

    Quelle: builder.io

  • KI-Souveränität: Warum gemietete KI-Fähigkeit keine Souveränität ist

    KI-Souveränität: Warum gemietete KI-Fähigkeit keine Souveränität ist

    Australien braucht keinen nationalen Chatbot, an dem seitlich eine australische Flagge klebt. So beginnt ein Beitrag der australischen Beraterin für Daten- und KI-Governance Kate Carruthers über die Frage, was KI-Souveränität bedeuten soll. Er trifft, weil er eine bequeme Gleichsetzung auflöst: die von Zugang und Kontrolle. Carruthers argumentiert, ein Land werde nicht souverän, indem es einen langfristigen Vertrag über den Zugang zu einem amerikanischen Frontier-Modell unterschreibt und das Ergebnis nationale Fähigkeit nennt. Wer den Preis ändern, die Regeln anpassen, den Dienst zurückziehen oder die Nutzung vorschreiben kann, hält die Fäden in der Hand. Gemietete Fähigkeit ist keine Souveränität.

    Man kann sich das wie eine gut ausgestattete Mietwohnung vorstellen. Du wohnst darin, nutzt sie täglich, sie funktioniert zuverlässig, und trotzdem entscheidest du nicht über die Nebenkosten, die Hausordnung oder die Frage, ob der Vermieter die Wohnung in zwei Jahren selbst braucht. So geht es vielen Organisationen, die heute auf proprietäre Modelle setzen. Sie nutzen eine hervorragende Infrastruktur, aber besitzen weder die Wände noch den Schlüssel zum Keller. Die Schlussfolgerung ist nüchtern: Es geht nicht um Autarkie, sondern darum, so viel Handlungsfähigkeit, Einsicht und Auswahl zu behalten, dass Institutionen nicht in die Falle geraten, wenn sich kommerzielle, rechtliche oder geopolitische Bedingungen verschieben.

    Zugang ist nicht Kontrolle

    Der erste Denkfehler in dieser Debatte, so Carruthers, ist die Verwechslung von Zugang mit Kontrolle. Die führenden US-Frontier-Modelle sind außerordentlich leistungsfähig und für Recherche, Analyse, Programmierung, Textarbeit, Übersetzung und Kundensupport nützlich; australische Organisationen sollten sie nutzen, wo es sinnvoll ist. Nur sind das Dienste, die anderswo gesteuert werden. Wer ein proprietäres Frontier-Modell einsetzt, kontrolliert in der Regel weder die Gewichte noch die Trainingsentscheidungen, die Policy-Einstellungen, die Verarbeitungsumgebung, den Update-Zyklus oder die kommerziellen Bedingungen. Oft ist nicht einmal klar, wo die Daten verarbeitet werden, und eine Prüfung nach den Maßstäben einer rechenschaftspflichtigen öffentlichen Entscheidung ist häufig nicht möglich. Ändert der Anbieter die Regeln, bleibt dem Kunden wenig Spielraum.

    Das macht Frontier-Modelle nicht schlecht. Es macht sie zu KI-Infrastruktur mit Bedingungen, und Infrastruktur hat immer politische Folgen. Diese Lektion haben wir bei Cloud-Plattformen gelernt, bei Software-Ökosystemen und bei sozialen Netzwerken. Bei KI lernen wir sie erneut, mit dem Unterschied, dass die Systeme diesmal sehr viel tiefer in Verwaltung, Gesundheitswesen, Bildung, Forschung und kritische Infrastruktur eingebettet sein dürften. Je folgenreicher die Nutzung, desto wichtiger wird die Governance-Frage. Wer darf die Regeln ändern, wer entscheidet über das Erlaubte, wer kann den Dienst zurückziehen, wer darf das System inspizieren, wer kann es abschalten? Fällt die Antwort auf ein Unternehmen in einer anderen Jurisdiktion mit eigenen kommerziellen Interessen, ist das mehr als ein Beschaffungsdetail, nämlich der Kern des Problems.

    Die Annahme der Monopole beginnt zu bröckeln

    Lange galt die Arbeitsannahme, die USA blieben entscheidend vorn und die besten Systeme blieben hinter proprietären Schnittstellen verschlossen. Diese Annahme beginnt zu bröckeln, auch weil chinesische Open-Weight-Modelle aufgeholt haben. Der Stanford AI Index 2026, auf den sich Carruthers beruft, fand einen Abstand zwischen den führenden US- und chinesischen Modellen im niedrigen einstelligen Prozentbereich. Stand März 2026 lag Claude Opus 4.6 mit 39 Arena-Punkten beziehungsweise 2,7 Prozent vor Dola-Seed-2.0 Preview. Die USA behalten enorme Vorteile bei Kapital, Rechenleistung, Frontier-Labors und Infrastruktur, und daran wird sich so schnell nichts ändern. Ein kleiner und schwankender Leistungsabstand ist strategisch trotzdem etwas anderes als überwältigende und dauerhafte Dominanz.

    Die naheliegende Reaktion wäre falsch: US-Abhängigkeit gegen chinesische Abhängigkeit zu tauschen. Das ist keine Souveränität, sondern Anbieter-Diversifizierung mit geopolitischem Beigeschmack,. Entscheidend ist etwas anderes: Die Modelllandschaft wird pluraler. Es gibt mehr leistungsfähige Systeme, von mehr Anbietern, unter unterschiedlichen Lizenz- und Betriebsmodellen, darunter Open-Weight-Modelle, die sich mitunter inspizieren, benchmarken, anpassen und in einer selbst kontrollierten Umgebung betreiben lassen. Mehr Modelle machen ein Land noch nicht souverän. Sie nehmen ihm aber eine Ausrede, abhängig zu bleiben.

    Open-Weight-Modelle sind ein Hebel, kein Zauberstab

    Um offene Gewichte rankt sich viel magisches Denken. Man hört, die Gewichte seien verfügbar, und schließt daraus, die Fähigkeit sei damit automatisch lokal, zugänglich und souverän. So einfach ist es nicht. Open-Weight-Modelle sind trotzdem wichtig, weil sie das Feld möglicher Handlungen vergrößern. Die Stanford-Analyse von 2026 fand, dass sich der Abstand zwischen den besten offenen und geschlossenen Modellen deutlich verringert hat, und sie nennt Alibaba unter den führenden Anbietern in einem enger zusammengerückten Frontier-Feld. Für leistungsfähige Institutionen bedeutet das, mehr tun zu können, als Zugang über eine fremde Oberfläche zu mieten: prüfen, testen, anpassen und in einigen Fällen unter eigenen Governance-Regeln betreiben.

    Herunterladbare Gewichte sind jedoch nicht dasselbe wie nutzbare Fähigkeit. Ein großes Modell braucht weiterhin Rechenleistung in Form von Rechenzentren, Fachleute, sichere Infrastruktur, Evaluation, Monitoring und Geld. Es hängt möglicherweise weiterhin von ausländischen Chips, ausländischer Cloud-Kapazität, ausländischen Software-Frameworks und ausländischen Forschungsökosystemen ab. Offene Gewichte garantieren keine Souveränität, aber sie sind ein Hebel. Und Hebel verschaffen Institutionen Spielraum zum Verhandeln, Bestreiten und Weggehen. Carruthers vertritt seit Langem die Position, offene Institutionen seien wichtig, weil sie die Fähigkeit bewahren, sich der Konzentration von Macht zu widersetzen, statt sie nur zu akzeptieren.

    Kleinere KI-Modelle sind oft die strategische Wahl

    Die Souveränitätsdebatte wird durch Frontier-Theater verzerrt. Die meisten Organisationen brauchen kein Modell, das alles kann, sondern ein System, das eine bestimmte Aufgabe zuverlässig, sicher und zu finanzierbaren Kosten erledigt. Eine Kommune, die Bauanträge klassifiziert, braucht kein Modell mit Billionen Parametern. Ein Gesundheitsdienst, der Personal Fragen aus internen Richtlinien beantwortet, braucht es in der Regel ebenfalls nicht. Eine Aufsichtsbehörde, die ihre eigenen Leitlinien durchsucht, sollte sensible Unterlagen nicht standardmäßig in ein undurchsichtiges externes System schicken. Für viele dieser Aufgaben ist ein kleineres KI-Modell in einer kontrollierten Umgebung die bessere Wahl, nicht weil klein automatisch sicher wäre, sondern weil kleinere Systeme leichter zu betreiben, zu testen, zu begrenzen, zu überwachen und zu ersetzen sind.

    Damit sind sie leichter zu regieren. Kleinere und spezialisierte Modelle lassen sich näher an sensiblen Daten hosten, an geltendes Recht, institutionelle Sprache und definierte Arbeitsabläufe anpassen und gegen ein schmaleres, besser verstandenes Risikoset prüfen. Sie laufen mit geringeren Kosten, geringerem Energiebedarf und niedrigerer Latenz, sind ausfallsicherer und lassen sich austauschen, ohne die ganze Organisation um einen Anbieter herum neu zu bauen. Das Designprinzip ist einfach: Nutze das kleinste Modell, das die Aufgabe sicher, zuverlässig und wirtschaftlich erfüllt, und begründe jede Skalierung nach oben. Das ist kein Argument gegen Frontier-Modelle, denn manche Arbeit wird sie brauchen. Aber „nimm das größte verfügbare Modell“ ist keine Strategie, sondern eine Gewohnheit aus einer Zeit, in der Fähigkeit knapp, konzentriert und laut vermarktet war.

    Keine Autarkie, aber verwaltete Interdependenz

    Eine Fantasie lässt sich sofort beiseiteschieben: Australien, und mit ihm jedes mittelgroße Land, wird keine KI-Autarkie erreichen. Niemand wird jeden fortgeschrittenen Chip im Inland fertigen, jedes große Grundlagenmodell von Grund auf trainieren, jede Cloud-Schicht besitzen und sich von globalen Forschungs- und Softwareökosystemen abkoppeln. Der Versuch wäre ruinös teuer, technologisch brüchig und strategisch töricht, weil er eine Abhängigkeit durch eine kleinere, fragilere lokale Monokultur ersetzen würde. Autarkie abzulehnen heißt aber nicht, Hilflosigkeit zu akzeptieren. Die realistische Alternative ist verwaltete Interdependenz.

    Das bedeutet, genau zu verstehen, wo im KI-Stack die Macht sitzt, und bewusst zu entscheiden, welche Abhängigkeiten tragbar und welche gefährlich sind. Woher kommen die Chips, wo wird das Modell gehostet, wer kontrolliert die Updates, was erlaubt die Lizenz, welche Cloud-Dienste sind unverzichtbar, welche Fähigkeiten sind so knapp, dass sie zum strategischen Engpass werden? Dazu gehört, Optionen zu haben, bevor man sie braucht. Keine Institution sollte erst während eines Ausfalls, eines Vertragsstreits, eines Exportkontrollschocks oder eines geopolitischen Bruchs entdecken, dass ein externer Anbieter still zum Betriebssystem einer essenziellen öffentlichen Funktion geworden ist. Das ist keine Resilienz, sondern Wunschdenken mit angehängter Rechnung.

    Souveränität zeigt sich unter Druck – und in der Fähigkeit, zu gehen

    Echte KI-Souveränität ist keine Aussage darüber, wo ein Modell trainiert wurde oder wo ein Server steht. Sie ist ein Test für den Ernstfall. Lässt sich das System inspizieren? Kann man Leistung, Sicherheit, Datenschutz und Robustheit unabhängig prüfen? Lassen sich Daten verschieben und Workloads auf ein anderes Modell umziehen? Läuft der Betrieb weiter, wenn der Anbieter die Bedingungen ändert? Merkt man, wenn sich das Modell verändert hat? Erfüllt man die eigenen rechtlichen und rechenschaftspflichtigen Pflichten? Und kann man es abschalten? Fällt eine dieser Antworten negativ aus, hat man keine Souveränität, sondern eine Abhängigkeit, die noch nicht getestet wurde.

    Das gilt besonders für Verwaltung, regulierte Sektoren und kritische Infrastruktur. Wer essentielle Funktionen um Systeme herum baut, die sich nicht unabhängig bewerten, nicht sinnvoll auditieren und nicht glaubwürdig ersetzen lassen, geht ein hohes Risiko ein. Ein proprietäres Modell kann im Einzelfall die richtige Wahl sein, denn am Kauf einer Dienstleistung ist nichts grundsätzlich falsch. Die Entscheidung sollte nur bewusst fallen, dem Risiko angemessen sein und durch vertragliche, technische und operative Absicherungen flankiert werden. Es geht nicht darum, Abhängigkeit zu beseitigen, sondern darum, dass Abhängigkeit nicht zu Gehorsam wird.

    Carruthers plädiert deshalb für einen Portfolio-Ansatz statt für einen nationalen Champion. Routinearbeit, Datenschutz oder niedrige Latenz sprechen für ein kleines, lokal gehostetes Modell. Regulierte Entscheidungsunterstützung braucht domänenangepasste Modelle mit definierter Evaluation, Protokollierung und menschlicher Aufsicht. Komplexe Forschung, multimodale Analyse oder agentische Aufgaben können ein großes Open-Weight-Modell rechtfertigen, wenn Infrastruktur und Governance passen. Außergewöhnliche Allzweckfähigkeit bleibt dem proprietären Frontier-Modell vorbehalten, selektiv eingesetzt und mit Sicherheits-, Vertrags- und Ausstiegskontrollen. National bedeutsame Anwendungen schließlich brauchen Forschung, Evaluation, Betriebsexpertise und sichere Infrastruktur über den gesamten Stack hinweg.

    Die wichtigste politische Aufgabe ist damit nicht ein weiteres Strategiepapier mit wohlklingenden Formeln über vertrauenswürdige KI. Sie besteht darin, die Fähigkeit zur Wahl aufzubauen. Dazu gehören im Inland gehostete Inferenz und sichere Rechenkapazität für sensible Workloads, Beschaffungskompetenz in der öffentlichen Verwaltung, unabhängige Evaluation von Sicherheit, Zuverlässigkeit, Datenschutz, Verzerrung und kultureller Angemessenheit, Fachwissen zu Feintuning und Betrieb, offene Standards und interoperable Architekturen gegen Vendor-Lock-in, indigene Daten-Governance und echte Mitbestimmung über kulturell sensible Daten sowie verbindliche Anforderungen an Portabilität, Kontinuität und getestete Ausstiegspläne in Hochrisiko-Beschaffungen. Auch die technische und rechtliche Möglichkeit, KI-Systeme bei Bedarf sicher anzuhalten, gehört dazu. Das ist keine glamouröse Arbeit, und ein nationaler Chatbot, den man auf einer Pressekonferenz enthüllen kann, wird dabei nicht herauskommen.

    Vieles davon gilt auch außerhalb Australiens. In Europa und Deutschland diskutieren wir über digitale Souveränität meist als Frage der Herkunft: wo steht das Rechenzentrum, wo sitzt der Anbieter, welches Label trägt das Modell. Der Beitrag dreht die Frage um. Entscheidend ist nicht die Flagge auf dem System, sondern die Fähigkeit, es zu prüfen, zu begrenzen, zu ersetzen und notfalls abzuschalten. Kleinere Modelle ersetzen nicht alles, sind aber ein praktischer Hebel, weil sie Abhängigkeit sichtbar und verhandelbar machen. Souveränität entsteht nicht durch eine Ankündigung, sondern durch die unspektakuläre Arbeit an Ausstiegsplänen, Evaluationsverfahren und Rechenkapazität, die man selbst kontrolliert. Das verlangt weniger Reden über Modelle und mehr Arbeit an Verträgen, Tests und Alternativen.

    Quelle: katecarruthers.com

Weitere Beiträge