Wie viel „denkt“ KI-Übersetzung eigentlich?

Gemini ist ein Geschenk, das immer wieder begeistert. Es ist für die meisten Sprachen von Haus aus das beste Übersetzungs-LLM. Dank seiner Denkfähigkeit lassen sich selbst die schwierigsten Nüsse knacken – ob Idiome, Anime-Referenzen oder Ihre ganz eigene Brand Voice™.

Der Haken ist: Denken braucht Zeit. Und Denken kostet Geld; jeder Token wird abgerechnet. Als Entwickler möchte man beides unter Kontrolle behalten.

Gemini 2.5 hatte es leicht. Gemini 3 macht es einem schwer.

Hier sind unsere Erkenntnisse aus den Transept-Labs

Was sich in Gemini 3 geändert hat

Gemini 2.5 verfügte über das thinkingBudget: eine numerische Obergrenze für Reasoning-Token. Gemini 3 hat dieses Konzept gestrichen. Der Ersatz ist das thinkingLevel: eine kategoriale Einstellung mit vier Werten – minimal, low, medium und high. Die beiden Parameter schließen einander aus; wer beide an ein Gemini-3-Modell sendet, erhält bei aktuellen SDKs einen 400-Fehler.

Das ändert die praktische Bedeutung von „Kostenkontrolle“. Bisher konnte man eine strikte Obergrenze für die Ausgaben festlegen. Jetzt liegt es am Modell, so viel zu verbrauchen, wie es für die Stufe „medium“ gerade für richtig hält.

Wir vermuten, dass die Modelle im Post-Training darauf optimiert wurden, ihre Denktiefe – genau wie wir Menschen – an die Schwierigkeit der Aufgabe anzupassen. Willkürliche Limits würden diese Fähigkeit beeinträchtigen.

Doch wie viele Token verbrauchen low, medium und high eigentlich?

Die Daten

Hier ist ein Auszug aus zwei Wochen unseres echten Übersetzungs-Traffics: rund 1.000 Anfragen über drei Gemini-3-Modelle hinweg. Die Daten zu den Thinking-Token stammen aus usageMetadata.thoughtsTokenCount in den jeweiligen Antworten – der präzisesten Quelle, die überhaupt möglich ist.

Thinking-Token nach Modell

Die 15.725 ist kein Tippfehler. Ein einzelner Übersetzungsaufruf verbrauchte bei einem Flash-Modell auf der Einstellung mittel fünfzehntausend Tokens für das Reasoning.

Normalerweise entstehen solche Token-Explosionen dadurch, dass Gemini seine rohen Thinking-Tokens in die Ausgabe durchsickern lässt. Wie Sie vielleicht wissen, ist das „Denken“ des Modells nicht das, was es tatsächlich denkt, sondern vielmehr aufpolierte Zusammenfassungen; das echte Reasoning eines LLM ähnelt eher einem Bewusstseinsstrom.

Es ist jedoch erwähnenswert, dass Gemini in diesem speziellen Fall in aller Seelenruhe an einer Englisch-Ukrainisch-Übersetzung einer literarischen Passage tüftelte, die eine Zeile wie „reiner Stahl weist Lacke und Farben ab“ enthielt. Es probierte per Brute-Force etwa ein Dutzend Varianten durch und „las“ sie sich quasi laut vor, bis ihm das Ergebnis gefiel.

Ein paar Wochen später ein Update: Die 15,725 waren kein einmaliger Akt der Hingabe von Gemini, sondern ein Muster, das typisch für komplexe Aufgaben ist.

Mit zunehmendem Traffic, besonders bei gemini-3.1-flash-lite, kehrt dieselbe Zahl immer wieder zurück. Ein verdächtig enger Bereich zwischen 15,724 und 15,729, über Dutzende von Aufrufen hinweg – fast ausschließlich Lite-Modelle, die Glossar-Audits abarbeiten. Interessanterweise laufen diese mit „geringem Denkaufwand“ (low thinking effort), was man eigentlich nicht als die teuerste Einstellung vermuten würde.

Ein Modell, das elfmal bei derselben Zahl landet, ist an ein Limit gestoßen und hat nicht etwa eine Formulierung gewählt. Die Einstellung low thinking stößt bei etwa 15,7k Tokens an ihre Sättigungsgrenze. Da kleine Modelle wie die lite-Variante weniger effizient denken, treiben komplexe Aufgaben sie dazu, Unmengen an Tokens zu verbrauchen; bei größeren Modellen passiert das nie, da dort jedes Token mit höherer Wahrscheinlichkeit ein sinnvoller Schritt hin zur Antwort ist.

Diese Sättigung hat zudem ihren Preis. Bei Gemini 3 werden Thinking-Tokens auf maxOutputTokens angerechnet. Ein Aufruf, der 15,7k für das Denken verbraucht, lässt fast keinen Platz mehr für die Antwort; das gesamte Denken wird jedoch zum Output-Tarif abgerechnet. Bei einem Budget von 16k blieb das Audit bei kleinen Dokumenten in etwa der Hälfte der Fälle leer (finishReason=MAX_TOKENS), was uns zu Nachforschungen veranlasste.

Das Budget zu erhöhen, bekämpft nur das Symptom, nicht die Ursache. Wir haben das Audit-Budget bei low auf 32k hochgeschraubt, was nach einem gesättigten Denkvorgang noch ca. 16k für die Ausgabe lässt – die leeren Antworten hörten auf. Das Denken selbst schrumpfte jedoch nicht. Man kann es bei Gemini 3 nicht deckeln, also werden weiterhin rund 15,7k Tokens verfeuert; das größere Budget schafft lediglich den nötigen Platz für die Antwort.

Die einzige echte Abhilfe gegen dieses 16k-Thinkingmaxxing war die Reduzierung des Aufgabenumfangs.

minimal ist die einzige Stufe, die mit einer Obergrenze von ca. 2k Tokens wie eine echte Deckelung fungiert. Sie ist allerdings nur für Lite-Modelle verfügbar.

Thinking-Tokens nach Aufgabentyp (Flash vs. Pro, beide auf medium)

Bei reinen Übersetzungen denkt Pro fast halb so viel wie Flash. Nur bei Rewrite-Aufgaben übertrifft es Flash an Denkleistung. Der Denkaufwand richtet sich nach der Schwierigkeit der Aufgabe, nicht nach der Marketing-Klasse des Modells.

Pro erzielt in Übersetzungs-Benchmarks wohl gerade deshalb bessere Ergebnisse, weil es bei Bedarf zu einer höheren Denktiefe fähig ist.

Praktische Erkenntnisse

• Legen Sie kein thinkingBudget für Gemini-3-Modelle fest. Es wird entweder ignoriert oder führt zu einem Fehler.
• medium ist nach oben hin offen. Planen Sie realistisch ca. 4.000 P90-Thinking-Tokens pro Aufruf ein, nicht 2.000.
• Wenn Sie ein striktes Kostenlimit benötigen, nutzen Sie nach Möglichkeit minimal. Es ist nicht sinnvoll, die Ausgabe abzubrechen: Die Kosten fallen in jedem Fall an.
• Werten Sie bei jeder Antwort usageMetadata.thoughtsTokenCount aus, falls Sie pro Aufruf abrechnen. Die Zahl steht zwar nicht im Response-Body, erscheint aber auf der Rechnung.
• Pro auf der Stufe medium denkt bei einfachen Aufgaben wahrscheinlich weniger als im Median, bei schwierigen hingegen mehr. Lite & Flash weisen diese Varianz nicht auf.

Damit ist Pro das beste Modell für das Korrekturlesen und die Verfeinerung über den LLM-Standard hinaus, da hier seine Kreativität aktiviert wird. Reine Rohübersetzungen sind bei Flash besser aufgehoben.

Das kostet allerdings Zeit und Geld. Bei Transept haben wir Wege gefunden, die Pro-Kosten zu senken, indem wir eine intelligente Korrekturlogik einsetzen, die Pro nur für die schwierigsten Stellen zuschaltet. Wir nutzen Pro auch für die Planung und Entscheidungsfindung und delegieren die Ausführung an kleinere Modelle und Fine-tunes.

Auf diese Weise funktioniert alles.