Gemini 3.1 Pro oder Gemini 3.7 Flash für die Codepflege: Wie lässt sich messen, ob sich der höhere Preis lohnt?

Die Entscheidung: für eine gelöste Aufgabe bezahlen, nicht für einen Eindruck

Bei der Wahl zwischen Gemini 3.1 Pro und Gemini 3.7 Flash für die Codepflege reicht die Frage, welches Modell „besser“ ist, nicht aus. Für ein Team zählt in der Praxis, welches Modell eine konkrete Aufgabe mit einem korrekten Patch abschließt, wie viel der Weg dorthin kostet und wie lange er dauert. Ein Modell, das schnell antwortet, aber eine Regression verursacht oder mehrere Korrekturrunden erfordert, kann weniger effizient sein als ein Modell mit einem teureren einzelnen Aufruf.

Ein aussagekräftiger Vergleich muss abgeschlossene Arbeit bewerten. Dazu gehört, zu prüfen, ob die Änderung das Problem behebt, relevante Tests besteht und keine Bereiche verändert, die mit dem Auftrag nichts zu tun haben. Auch fehlgeschlagene Versuche, Werkzeuge, Wiederholungen, menschliche Eingriffe und Läufe ohne akzeptablen Patch müssen berücksichtigt werden. Die Kosten pro Aufruf allein sagen nichts darüber aus, was die Pflege eines Repositorys tatsächlich kostet.

Hier liegen keine Ergebnisse eines Vergleichstests vor, der mit denselben Repositorys und einem gemeinsamen Auswertungsrahmen durchgeführt wurde. Es wäre daher nicht seriös zu behaupten, Flash reiche für Routineaufgaben aus, Pro rechtfertige bei komplexen Aufgaben den höheren Preis oder eines der beiden Modelle sei überlegen. Im Folgenden geht es um ein Protokoll, mit dem sich diese Frage beantworten lässt, und um eine Anleitung, Ergebnisse zu interpretieren, ohne Hypothesen als Tatsachen darzustellen.

Welche Modelle verglichen werden – und was vor dem Start zu prüfen ist

Zuerst muss die genaue Identität jedes Systems festgelegt werden. Das konsultierte offizielle Datenblatt führt Gemini 3.1 Pro unter der ID `gemini-3.1-pro-preview` und kennzeichnet es als Preview-Version. Der konsultierte Leitfaden zum Reasoning nennt `gemini-3.7-flash` und `gemini-3.1-pro-preview` unter den Modellen, für die Konfigurationsinformationen aufgeführt werden. In den Testprotokollen dürfen diese Namen nicht durch verkürzte Bezeichnungen ersetzt werden: Die an die API übermittelte Modell-ID ist Teil der experimentellen Konfiguration.

Verfügbarkeit und Status können sich ändern. Vor Beginn der Läufe und erneut beim Abschluss des Tests ist zu prüfen, welche IDs akzeptiert werden, welcher Zugangskanal verwendet wird und ob ein Modell nicht mehr verfügbar ist oder seinen Status geändert hat. Ändert sich ein Modell während des Versuchs, muss der Artikel angeben, welche Läufe zu welcher Version gehören, oder die Zeiträume getrennt ausweisen. Unterschiedliche Versionen dürfen nicht stillschweigend als eine homogene Stichprobe behandelt werden.

Außerdem müssen Anbieter und Zugangskanal, Datum, Generierungsparameter, Kontextlimit, Abbruchregeln und sämtliche Reasoning-Einstellungen festgehalten werden. Die offizielle Dokumentation beschreibt Optionen und Standardwerte. Daraus folgt jedoch nicht, dass zwei Werte mit derselben Bezeichnung denselben Rechenaufwand, dasselbe interne Budget oder dasselbe Verhalten bedeuten. Ein Vergleich mit „äquivalenten“ Stufen ist nur vertretbar, wenn genau festgelegt wird, was äquivalent bedeutet und welche Parameter tatsächlich verwendet wurden.

Auch Preise dürfen weder aus einer alten Tabelle übernommen noch aus dem Modellnamen abgeleitet werden. Die zum Ausführungszeitpunkt geltenden Abrechnungskomponenten müssen geprüft und es muss erläutert werden, was einbezogen wird: Eingabe, Ausgabe, Werkzeugaufrufe oder weitere relevante Kosten. Erfolgt der Zugang über eine Zwischenschicht oder zu einem anderen Tarif als der direkte API-Zugang, muss dieser Kanal gemessen und beschrieben werden. Ergebnisse lassen sich nicht automatisch auf einen anderen Zugang übertragen.

Versuchsaufbau: Repositorys, Issues und Akzeptanzkriterien

Der Testsatz muss eingefroren werden, bevor die Modelle ausgeführt werden. Für jede Aufgabe braucht es ein eindeutig bestimmtes Repository und einen Basis-Commit, eine Beschreibung des Problems, eine reproduzierbare Umgebung und vorab festgelegte Akzeptanzkriterien. Werden Aufgaben oder Regeln geändert, nachdem bekannt ist, welches Modell welchen Patch erzeugt hat, steigt das Risiko, die Bewertung nachträglich an die Ergebnisse anzupassen.

Sinnvoll ist eine Auswahl von Issues aus unterschiedlichen Repositorys, gruppiert nach Aufgabenart und Schwierigkeitsgrad: Fehlerdiagnose, eng begrenzte Korrektur, Änderung über mehrere Dateien hinweg und Aufgaben, bei denen die vorhandenen Tests das erwartete Verhalten nicht vollständig abdecken. Die Verteilung sollte veröffentlicht werden. Eine Sammlung, die überwiegend aus kleinen Änderungen besteht, kann ein bestimmtes Arbeitsprofil begünstigen; eine Sammlung mit hauptsächlich weitreichenden Problemen möglicherweise ein anderes. Vielfalt mindert dieses Risiko, beseitigt es aber nicht.

Die Issues sollten echt und für Wartungsarbeiten relevant sein, doch ihre Auswahl erfordert Sorgfalt. Das SWE-bench-Paper beschreibt einen Ansatz mit Aufgaben, die aus realen GitHub-Issues abgeleitet wurden. Die Dokumentation zu Datensätzen und Auswertungsrahmen kann bei der Gestaltung einer Evaluation helfen. Die Verwendung von Benchmark-Aufgaben garantiert jedoch nicht, dass ein bestimmter Test die Arbeit eines Teams gut abbildet. Außerdem hat OpenAI auf Einschränkungen von SWE-bench Verified hingewiesen. Dieser Hinweis muss als veröffentlichte Position von OpenAI gekennzeichnet werden und darf nicht als unabhängiges Audit der hier verglichenen Modelle erscheinen.

Um eine Kontamination zu verringern, muss geprüft werden, ob die Lösung oder ein gleichwertiger Patch bereits im bereitgestellten Kontext, in den Aufgaben-Dateien oder in anderen für das System verfügbaren Materialien enthalten ist. Ebenso wichtig ist eine genaue Beschreibung der Informationen, die jedes Modell erhält: Issue, Verlauf, Anweisungen, Dokumentation und Tests. Es genügt nicht, zu behaupten, beide hätten „denselben Prompt“ erhalten, wenn eines der Modelle zusätzliche Daten oder andere Werkzeuge nutzen konnte.

Die Aufgaben müssen auf sauberen Kopien desselben Basis-Commits ausgeführt werden. Auswertungsrahmen, Abhängigkeiten und Testbefehle müssen identisch bleiben. Eine reproduzierbare Umgebung hilft dabei, den Einfluss des Modells vom Einfluss eines Rechners, einer Abhängigkeitsversion oder einer manuellen Repository-Änderung zu trennen. Scheitert eine Aufgabe an der Infrastruktur und nicht am Patch, muss sie nach einer Regel gekennzeichnet werden, die festgelegt wurde, bevor die Ergebnisse bekannt waren.

„Akzeptierte Aufgabe“ definieren, bevor die Patches vorliegen

Ein bestandener Test ist nicht automatisch eine akzeptable Lösung. Die vorhandenen Tests decken die zentrale Anforderung möglicherweise nicht ab. Außerdem kann ein Patch sie bestehen, obwohl er Änderungen zu weit fasst oder das Problem durch eine Verhaltensänderung verdeckt. Die Akzeptanz sollte daher relevante automatisierte Tests mit einer strukturierten menschlichen Prüfung verbinden.

Die Bewertungsrubrik sollte mindestens klären, ob der Patch das Issue behebt, nicht betroffene Funktionalität bewahrt, bekannte Regressionen vermeidet, nur notwendige Änderungen vornimmt und wartbar ist. Außerdem muss sie festlegen, wie mit einem Ergebnis umzugehen ist, das plausibel erscheint, obwohl die Tests unzureichend sind. In solchen Fällen können unabhängige Prüfungen ergänzt oder die Aufgabe als unklar eingestuft werden, statt ohne ausreichende Evidenz eine Annahme oder Ablehnung zu erzwingen.

Die Prüferinnen und Prüfer sollten anonymisierte Patches erhalten und dieselbe Rubrik anwenden, ohne das Herkunftsmodell zu kennen. Meinungsverschiedenheiten müssen dokumentiert werden; außerdem braucht es ein Verfahren zur Klärung, etwa eine Zweitprüfung. Auch die menschliche Bewertung ist nicht unfehlbar. Deshalb sollten die Akzeptanzdefinition, Ablehnungskategorien und der Anteil strittiger Entscheidungen veröffentlicht werden.

Zwei getrennte Perspektiven: gleiches Budget und gleiche Frist

Ein Vergleich mit gleichem Budget und ein Vergleich mit gleicher Zeit beantworten unterschiedliche Fragen. Sie dürfen nicht zu einer einzigen Zahl zusammengefasst werden. Beim Budgetvergleich erhält jedes Modell ein Ausgabenlimit pro Aufgabe, einschließlich der für den Test festgelegten Abrechnungskomponenten. Gemessen wird, wie viele Aufgaben es bis zum Erreichen dieses Limits mit einem akzeptablen Patch abschließt. Ein fehlgeschlagener Versuch verbraucht einen Teil des Budgets und muss im Ergebnis enthalten bleiben.

Beim Zeitvergleich erhalten beide Modelle dieselbe maximale Frist. Gemessen wird vom Start der Aufgabe bis zur Abgabe. Die Uhr muss Wartezeiten, Werkzeugaufrufe, Wiederholungen und jede weitere Latenz einschließen, die auch Nutzerinnen und Nutzer erleben. Wird die menschliche Prüfung separat erfasst, muss das klar angegeben werden. Ist sie Teil der Messung, muss sie nach demselben Verfahren erfolgen. Andernfalls werden die reine Antwortzeit des Modells und die Gesamtdauer eines Arbeitsablaufs vermischt.

Damit die Bedingungen fair sind, müssen sie vor der Ausführung feststehen: Höchstausgaben, Frist, Anzahl der Wiederholungen, Schrittlimit, Berechtigungen und Abbruchkriterium. Erreicht ein Modell das Limit, ohne einen akzeptablen Patch zu liefern, ist die Aufgabe unter dieser Bedingung nicht gelöst. Der Lauf darf nicht aus der Analyse entfernt werden. So lässt sich eine konkrete Beschaffungsfrage beantworten: Was erreicht man mit einem festen Geldbetrag oder innerhalb eines bestimmten Zeitfensters?

Was pro Aufgabe und Gruppe gemessen werden sollte

Die zentrale Kennzahl sollte die Akzeptanzrate sein: der Anteil der Läufe, in denen ein Patch die festgelegte Rubrik erfüllt. Damit sie aussagekräftig ist, muss sie zusammen mit der Gesamtzahl der Aufgaben und Versuche angegeben werden, nicht nur als Prozentwert. Dieselbe Rate hat bei wenigen Läufen eine andere Unsicherheit als bei einer großen Stichprobe.

Zu berichten sind außerdem Regressionen, bestandene relevante Tests, unnötige Änderungen, Wiederholungen, Dienstfehler, menschliche Eingriffe und Aufgaben ohne Patch. Die Ausgaben können pro Versuch und pro akzeptiertem Patch ausgewiesen werden, sofern Formel und Abrechnungskomponenten genannt sind. Wird eine Aufgabe nicht gelöst, dürfen ihre Kosten nicht aus dem Nenner verschwinden: Wer fehlgeschlagene Versuche ausschließt, erhält ein künstlich günstiges Bild der Kosten pro Erfolg.

Die Latenz sollte mindestens in Modellzeit, soweit messbare Warte- oder Warteschlangenzeit, Werkzeugoperationen und Gesamtdauer bis zur Abgabe aufgeschlüsselt werden. Für Teams kann auch die Dauer für Prüfung und manuelle Korrektur relevant sein. Zwei Modelle mit ähnlicher Generierungszeit können unterschiedliche Belastungen verursachen, wenn eines zusätzliche Kontrollen oder Reparaturen erfordert.

Die Ergebnisse sollten nach Aufgabenart und Schwierigkeitsgrad aufgeschlüsselt werden, zusätzlich zu einer allgemeinen Zusammenfassung. Ein aggregierter Wert kann verbergen, dass ein Modell kleine Änderungen besser löst und das andere bei dateiübergreifenden Änderungen weniger Fehler macht. Ein Modell sollte nicht allein deshalb als „besser“ gelten, weil es im Mittel vorn liegt, wenn das Team der lesenden Person mit einem anderen Aufgabenspektrum arbeitet.

Wiederholungen, Dienstfehler und Unsicherheit

Die Ausgabe eines Modells kann zwischen Läufen variieren, selbst wenn Aufgabe und Umgebung gleich bleiben. Ein einziger Lauf pro Issue reicht daher nicht aus, um die Stabilität zu beschreiben. Die Anzahl der Wiederholungen muss vor Beginn festgelegt, im Hinblick auf den Umfang des Tests begründet und für jedes Modell und jede Aufgabe gleich gehalten werden. Verhindern Dienstbedingungen einen vollständigen Lauf, muss zwischen einem Infrastrukturfehler und einem Fehler des Modells unterschieden werden, ohne den Datensatz stillschweigend zu bereinigen.

Zu zeigen sind Streuung und Unsicherheit, nicht nur ein Mittelwert. Veröffentlicht werden können etwa Fallzahlen, geeignete Intervalle und Ergebnisse pro Aufgabe. Die konkrete Wahl des statistischen Verfahrens hängt vom Versuchsaufbau ab und muss beschrieben werden. Ist der Datensatz klein, müssen die Schlussfolgerungen entsprechend begrenzt bleiben: Ein beobachteter Unterschied in diesen Fällen beweist nicht, dass er sich auf andere Sprachen, Repositorys, Teams oder Schwierigkeitsgrade übertragen lässt.

Auch die Empfindlichkeit gegenüber dem Auswertungsrahmen ist wichtig. Änderungen am Prompt, am Werkzeuglimit, am Kontextbudget oder an den Abbruchregeln können das Ergebnis beeinflussen. Ein kontrollierter Test ermittelt den Effekt einer bestimmten Konfiguration; er misst keine universelle, von der Nutzung losgelöste Fähigkeit. Werden zusätzliche Versuche mit anderen Konfigurationen durchgeführt, müssen sie als solche ausgewiesen und dürfen nicht mit dem Hauptergebnis vermischt werden.

Entscheidungsmatrix für Engineering-Teams

Ohne Testergebnisse kann die Matrix Gemini 3.1 Pro oder Gemini 3.7 Flash keinen empirischen Vorteil zuschreiben. Sie kann jedoch dabei helfen, erhobene Daten in eine Entscheidung zu übersetzen, die zur Arbeit des Teams passt. Zu berücksichtigen ist eine Mindestschwelle für die Qualität: Erreicht ein Modell weder die geforderte Akzeptanzrate noch das erforderliche Sicherheitsniveau, gleicht ein niedriger Preis das nicht automatisch aus.

Bei routinemäßigen und klar abgegrenzten Aufgaben kann ein Team zunächst prüfen, ob Flash diese Schwelle innerhalb des eigenen Budgets und Zeitrahmens erreicht. Das ist eine zu testende Hypothese und keine hier nachgewiesene Eigenschaft. Bei schwierigen Aufgaben, umfangreichen Änderungen oder folgenreichen Eingriffen muss geprüft werden, ob Pro die Akzeptanz erhöht oder den menschlichen Korrekturaufwand ausreichend senkt, um die zusätzlichen Kosten zu rechtfertigen. Dabei darf nicht vorausgesetzt werden, dass der Name „Pro“ dieses Ergebnis garantiert.

In beiden Fällen sollte eine menschliche Prüfung beibehalten werden, wenn es das Änderungsrisiko erfordert. Erzeugen beide Modelle häufig Patches, die nachgebessert werden müssen, oder reichen die verfügbaren Tests nicht aus, um das Verhalten zu verifizieren, kann die vernünftige Schlussfolgerung lauten, dass keines der Modelle die Automatisierungskriterien für diese Aufgabenklasse erfüllt. Eine hybride Entscheidung ist ebenfalls möglich – vorausgesetzt, die Weiterleitung zwischen den Modellen wird gemessen und nicht einfach unterstellt, dass eine Auswahl nach Schwierigkeitsgrad das Ergebnis verbessert.

Materialien zur Reproduktion und Grenzen der Schlussfolgerung

Ein Vergleich, der eine technische Entscheidung unterstützen soll, muss das Protokoll, die einbezogenen Aufgaben, Basis-Commits, Modellkonfigurationen, Limits und die Akzeptanzrubrik veröffentlichen. Soweit Berechtigungen und Lizenzen es zulassen, sollten auch Patches, anonymisierte Protokolle, Testergebnisse und Ablehnungsgründe bereitgestellt werden. Ausschlüsse und fehlgeschlagene Versuche gehören zur Evidenz; sie sind keine Nebensache.

Der Auswertungsrahmen kann sich an reproduzierbaren Evaluationsmethoden orientieren, etwa daran, Patches in isolierten Umgebungen auszuführen und die Anwendung von Änderungen zu kontrollieren. Die Dokumentation des SWE-bench-Auswertungsrahmens beschreibt einen Ansatz mit Docker-Umgebungen, in denen Aufgaben ausgeführt und bewertet werden. Das ist eine methodische Referenz. Die Verwendung dieses Auswertungsrahmens garantiert jedoch nicht, dass der Test den Arbeitsablauf eines Unternehmens abbildet.

Die Ergebnisse stützen nur Schlussfolgerungen zu den dokumentierten Modellen, Versionen, Aufgaben, Konfigurationen und dem angegebenen Datum. Sie erlauben keine automatische Aussage über andere Google-Produkte, andere Versionen oder andere Anbieter. Ebenso ersetzen sie keine Evaluation mit privaten Repositorys und den eigenen Sicherheits- und Prüfregeln. Die Frage „Wann lohnt sich der höhere Preis pro gelöster Aufgabe?“ lässt sich erst beantworten, wenn feststeht, was als gelöste Aufgabe zählt und die vollständigen Kosten im relevanten Kontext gemessen wurden.

Die seriöse redaktionelle Antwort lautet derzeit nicht „Modell A gewinnt“, sondern beschreibt die Bedingungen für eine Entscheidung: Beide Modelle müssen mit eingefrorenen Aufgaben, blinder Akzeptanzprüfung, gemeinsamen Budget- und Zeitlimits sowie einer Veröffentlichung der Unsicherheit verglichen werden. Zeigen die Daten konsistente und für das Team nützliche Unterschiede, lässt sich eine Empfehlung für diesen Anwendungsfall aussprechen. Andernfalls ist es ehrlicher festzuhalten, dass die verfügbare Evidenz keinen Unterschied erkennen lässt.

Weiter entdecken

Korrekturen und Transparenz

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