Gemini 3.6 Flash und Gemini 3.5 Flash Produktions-Inferenzspuren, verglichen für Geschwindigkeit und Kosten

Comparison

Gemini 3.6 Flash vs Gemini 3.5 Flash: Solltest du Produktionslasten migrieren?

Jacey

Founder

21. Juli 2026

17 Min. Lesezeit

Zuletzt geprüft: 2026-07-21. Verfasst von Jacey, einschließlich der 216 API-Aufrufe, die wir am Launch-Tag durchgeführt haben; die Methode wird dort vollständig beschrieben, wo diese Ergebnisse erscheinen. EvoLink betreibt ein API-Gateway, das an Drittanbieter-Modelle weiterleitet, einschließlich der beiden hier besprochenen Modelle.

Die Kurzfassung

Jetzt migrieren, wenn Output-Tokens deine Rechnung dominieren. Agent-Loops, lange Codegenerierung und rechenintensive Arbeit landen im Bereich von 26% bis 29% günstiger.
Kleiner Gewinn, wenn dein Verkehr input-lastig ist. Eine Dokument-Pipeline mit rund 20 Input-Tokens pro Output-Token spart 7.1%, weil sich der Input-Preis überhaupt nicht geändert hat.
Intelligenz ist unverändert. Unabhängige Messung setzt die beiden Modelle auf 50.1 und 50.2 auf demselben Index. Was sich bewegt hat, ist die Geschwindigkeit: 165 auf 304 Output-Tokens pro Sekunde und 2.7 auf 1.3 Minuten pro Aufgabe.
Zuerst testen, wenn deine Last wissensintensiv ist oder Frontend-UI generiert. Das sind die zwei Stellen, an denen die veröffentlichten Belege in die andere Richtung zeigen.
Das Thinking-Level bewegt deine Rechnung stärker als das Modell. In unseren eigenen Tests senkte der Wechsel vom medium-Default auf minimal die Kosten eines Durchlaufs um 73.6% ohne Genauigkeitsverlust auf unserem Aufgabenset. Setze es bewusst, egal welches Modell du fährst.
Das ist kein Modell-String-Tausch. temperature, top_p und top_k werden jetzt akzeptiert und dann ohne Fehler ignoriert, und thinking_budget existiert nicht mehr.

Die kurze Antwort, nach Last

Der Wert dieses Upgrades hängt fast vollständig von zwei Dingen ab: dem Verhältnis von Input-Tokens zu Output-Tokens in deinem Verkehr und davon, ob Latenz derzeit ein Beschwerdepunkt ist.

Deine Last	Urteil	Warum
Mehrstufige Agents, Tool-Calling-Loops, lange Codegenerierung	Migrieren	Output- und Thinking-Tokens dominieren, und das ist der einzige Teil des Preises, der gefallen ist
Alles, wo Aufgabenlatenz der Beschwerdepunkt ist	Migrieren	Zeit pro Aufgabe in unabhängiger Messung etwa halbiert
Wissensintensives Frage-Antwort	Erst Shadow-Run	Der eine generationenübergreifend direkt vergleichbare Wissenswert ist gesunken
Frontend- und UI-Generierung	Erst Shadow-Run	Google dokumentiert hier zwei spezifische Regressionen, beide mit einer Lösung auf Prompt-Ebene
Dokumentverarbeitung und RAG bei rund 20:1	Keine Eile	Die Ersparnis beträgt 7.1%, was im Rauschen eines normalen Monats liegt

Wenn die Frage, die du eigentlich stellst, lautet, ob du stattdessen Gemini 3.5 Flash-Lite fahren sollst, ist das eine andere Entscheidung mit einer anderen Antwort, und wir behandeln sie in Gemini 3.6 Flash gegen 3.5 Flash-Lite. Flash-Lite ist eine niedrigere Fähigkeitsstufe, keine neuere Version des Modells, das du fährst, also lässt sich keine der Zahlen unten darauf übertragen.

Was sich tatsächlich geändert hat

Gemini 3.6 Flash ist keine neue Modellgeneration. Seine Modellkarte gibt an, dass es auf Gemini 3.5 Flash aufbaut, was es zu einem Post-Training-Update auf derselben Basis macht. Diese eine Tatsache erklärt das meiste, was folgt: Die Fähigkeit bewegte sich seitwärts, während die Dinge, die Post-Training und Serving bewegen können – Geschwindigkeit und Token-Effizienz –, sich stark bewegten.

Hier sind die praktischen Details, entnommen aus Googles Modelldokumentation.

Modell-ID: gemini-3.6-flash. Eine stabile Version, kein Preview-Suffix und kein Datumsstempel, also ist keine Aliasing-Entscheidung zu treffen.
Kontext: 1,048,576 Input-Tokens und 65,536 Output-Tokens, unverändert. Text, Bild, Video, Audio und PDF rein; nur Text raus.
Default-Thinking-Level: medium, wählbar zwischen minimal, low, medium und high.
Preis: Input blieb bei $1.50 pro Million Tokens. Output fiel von $9.00 auf $7.50, eine Senkung um 16.67%. Cache-Lesevorgänge kosten $0.15 pro Million. Siehe Googles Preisseite für die Batch- und Priority-Stufen.

Das sind die Felder, die für die Entscheidung auf dieser Seite zählen. Für die vollständige Fähigkeitsmatrix und einen ersten funktionierenden Request gegen die neue Modell-ID siehe unseren Gemini 3.6 Flash Leitfaden.

Eine Korrektur, die es wert ist, gemacht zu werden, weil sie kursiert: Der Input-Preis ist nicht gestiegen. Sowohl gemini-3.5-flash als auch gemini-3.6-flash berechnen $1.50 pro Million Input-Tokens. Die Behauptung einer versteckten Erhöhung stammt aus dem Vergleich mit einem Preis einer früheren Flash-Generation.

Was mit deiner Rechnung passiert

Zwei getrennte Dinge sollen deine Kosten senken: Der Output-Preis ist 16.67% niedriger, und das Modell soll für dieselbe Aufgabe weniger Output-Tokens verbrauchen. Zusammengenommen sinken die Ausgaben auf der Output-Seite um 30.8%.

Diese Zahl ist echt, und sie ist auch der Grund, warum so viel Berichterstattung über dieses Release die Ersparnis überzeichnet. Der Input-Preis hat sich nicht bewegt. Je input-lastiger dein Verkehr also ist, desto weniger von diesen 30.8% siehst du tatsächlich.

Gemini 3.6 Flash Lastkostenvergleich, der zeigt, warum output-lastige KI-Lasten mehr Ersparnisse erzielen als input-lastige Pipelines

Die Ersparnisse von Gemini 3.6 Flash konzentrieren sich auf die Output-Seite, sodass die Token-Verhältnisse der Last die Auswirkung auf die Produktionskosten bestimmen.

Input:Output-Verhältnis	Typische Last	Auf 3.5 Flash	Auf 3.6 Flash	Änderung
20:1	Dokumentverarbeitung, RAG	$39.00	$36.23	7.1% günstiger
5:1	Allgemeines Frage-Antwort	$16.50	$13.72	16.8% günstiger
1:1	Mehrstufige Agents mit aktiviertem Thinking	$10.50	$7.72	26.4% günstiger
1:3	Rechenintensive Arbeit, lange Codegenerierung	$28.50	$20.17	29.2% günstiger

Lies die Tabelle so: Jede Zeile bepreist eine Last, normalisiert auf 1 Million Output-Tokens auf 3.5 Flash, mit Input-Tokens gemäß dem angegebenen Verhältnis, zu Standard-Tier-Preisen. Sie nimmt 17% weniger Output-Tokens auf dem neueren Modell und identische Input-Tokens an.

Diese 17%-Annahme verdient es, dass ihre Bedingungen genannt werden, denn alles in der Tabelle beruht darauf. Google zitiert die Zahl, statt sie zu messen, und die Quelle ist Artificial Analysis. Die auf derselben Seite veröffentlichten absoluten Token-Zahlen, 59 Millionen gegen 75 Millionen, ergeben 21.3%. Die beiden Zahlen wurden öffentlich nicht in Einklang gebracht. Wir haben durchgehend die konservativere 17% verwendet, also behandle die Tabelle als das untere Ende des Bereichs, nicht als Versprechen.

Thinking-Tokens werden zum Output-Tarif abgerechnet. Deshalb bewegen sich die Agent-Zeilen am stärksten: Bei einem mehrstufigen Agent ist das Thinking-Budget kein Rundungsfehler auf der Rechnung, sondern ein großer Anteil davon.

Dann haben wir es gemessen, und die Tabelle erwies sich als optimistisch. Unser Aufgabenset läuft mit ungefähr 1 Input-Token pro 1.5 abgerechneten Output-Tokens, was zwischen den Zeilen 1:1 und 1:3 liegt, wo die Tabelle eine Ersparnis von 26% bis 29% vorhersagt. Wir haben 13.6% beim medium-Thinking-Level gemessen und 20.1% bei high.

Die gesamte Lücke ist die Token-Effizienz-Annahme. Bei medium berechnete das neuere Modell 1.7% mehr Output-Tokens als sein Vorgänger, nicht 17% weniger, sodass fast die gesamte Ersparnis, die wir erhielten, aus der Preissenkung kam und nicht aus der Token-Effizienz. Bei high trat die Reduktion teilweise auf, mit 6.4% weniger Output-Tokens. Methode und vollständige Zahlen sind im nächsten Abschnitt.

Lies die Tabelle also als die Arithmetik, die die Herstellerbehauptung impliziert, und unsere Zahlen als das, was eine reale Last tatsächlich produziert hat. Wenn deine Arbeit unserer mehr ähnelt als einem Benchmark-Set, plane mit der niedrigeren Zahl.

Gleiche Intelligenz, ungefähr doppelte Geschwindigkeit

Artificial Analysis erhielt Vorabzugang und ist derzeit die einzige unabhängige Quelle mit einer vollständigen Aufschlüsselung. Ihre Zahlen, gemessen beim high-Thinking-Level:

Metrik	3.6 Flash	3.5 Flash
Intelligence Index v4.1	50.1	50.2
Humanity's Last Exam (wissensintensiv)	38.3%	40.2%
GPQA Diamond	92.8%	92.2%
SciCode	52.7%	53.1%
Long-Context-Reasoning (AA-LCR)	69.7%	69.3%
Ausgabegeschwindigkeit	303.6 tok/s	165.4 tok/s
Zeit bis zum ersten Token	11.54 s	20.22 s
Durchschnittliche Zeit pro Frage	1.3 min	2.7 min
Durchschnittliche Kosten pro Frage	$0.50	$0.59

Für jede Zeile gelten zwei Bedingungen. Diese wurden beim high-Thinking-Level gemessen, während der API-Default medium ist, sodass das Fahren der Default-Konfiguration nicht dasselbe Experiment ist. Und die Geschwindigkeits- und Latenzzahlen sind 72-Stunden-Mediane, gemessen an einem Modell, das am selben Tag veröffentlicht wurde, was bedeutet, dass das Stichprobenfenster unter einem Tag liegt und sich voraussichtlich verschieben wird.

Damit gesagt, ist die Form klar, und es ist ein Kompromiss, keine Regression. Die Parität im Intelligence Index von 50.1 gegen 50.2 ist ein Rundungsunterschied. Reasoning- und Long-Context-Werte stiegen leicht. Der eine wissensintensive Wert, der über die beiden Generationen direkt vergleichbar ist, Humanity's Last Exam, sank um 1.9 Punkte. Gleichzeitig stieg die Ausgabegeschwindigkeit um 84% und die Zeit pro Frage halbierte sich ungefähr.

Wenn du von diesem Release also ein intelligenteres Modell wolltest, wurde dieses Upgrade nicht für dich gebaut, und auf gemini-3.5-flash zu bleiben kostet dich auf dieser Achse nichts. Wenn du dieselbe Arbeitsqualität in der halben Zeit zu niedrigeren Stückkosten wolltest, ist genau das ausgeliefert worden.

Der wissensintensive Vorbehalt ist einen zusätzlichen Schritt wert, nicht eine zusätzliche Sorge. Eine Bewegung um 1.9 Punkte bei einem Benchmark ist ein Signal, dein eigenes Evaluationsset zu prüfen, kein Grund, das Release auszulassen.

Das Thinking-Level bewegt die Rechnung stärker als das Modell

Jede oben veröffentlichte Zahl beschreibt das high-Thinking-Level, während der API-Default medium ist. Diese Lücke ist groß genug, um eine Kaufentscheidung zu verändern, also führten wir am Launch-Tag unseren eigenen Test durch.

Gemini 3.6 Flash Thinking-Levels akkumulieren schrittweise mehr Reasoning-Tokens, während die finale Produktionsausgabe kompakt bleibt

Das Thinking-Level kann die abgerechnete Ausgabe stärker verändern als der Modellwechsel selbst, daher sollten Produktionsteams es explizit setzen und evaluieren.

Der Aufbau: neun Aufgaben in drei Gruppen – strukturierte Extraktion aus Rechnungen, Logs und Produkt-HTML; mehrstufiges Tool-Calling über drei bis fünf Schritte gegen simulierte Tools; und Code-Lokalisierung und -Reparatur, wo eine Bug-Beschreibung zu einem lauffähigen Patch werden muss. Die Eingaben liegen zwischen 1,000 und 4,000 Tokens, das deckt also keine Long-Context-Arbeit ab. Jede Aufgabe lief dreimal gegen jede von acht Modell- und Thinking-Level-Konfigurationen, insgesamt 216 Aufrufe, seriell über OpenRouter gesendet, mit dem Provider fest auf Google AI Studio gesetzt. Answer-Tokens und Thinking-Tokens wurden getrennt erfasst, und alles ist zur Standard-Tier-Liste von Google bepreist, nicht zur eigenen Abrechnung des Gateways. Es wurden keine Sampling-Parameter gesetzt, da sie nichts mehr bewirken.

Konfiguration	Answer-Tokens	Thinking-Tokens	Thinking-Anteil	Kosten pro Durchlauf	Korrekt
3.6 Flash `minimal`	1,162	0	0%	$0.0158	9/9
3.6 Flash `low`	1,056	1,095	51%	$0.0232	9/9
3.6 Flash `medium` (Default)	1,080	5,944	85%	$0.0598	9/9
3.6 Flash `high`	1,092	6,679	86%	$0.0653	9/9
3.5 Flash `medium`	1,078	5,827	84%	$0.0692	9/9
3.5 Flash `high`	1,113	7,185	87%	$0.0818	9/9

Drei Dinge stechen hervor.

Thinking-Tokens sind die Rechnung. Bei medium und high sind sie 84% bis 87% von allem, wofür du auf der Output-Seite bezahlst. Die Antwortlänge bewegt sich über die gesamte Tabelle kaum. Welches Modell du wählst, ändert deine Kosten weit weniger als welches Level du wählst.

minimal heißt nicht „weniger denken", es heißt „nicht denken". Thinking-Tokens kamen mit exakt null zurück, ein Durchlauf kostete 73.6% weniger als der medium-Default, und die Punktzahl war dieselbe, neun von neun. Wenn du auf medium bist, weil du nie ein Level gewählt hast, ist das der größte Kostenhebel, der dir zur Verfügung steht, und er funktioniert auf dem Modell, das du bereits fährst.

high kostete hier nur 9.3% mehr als medium, weil das zusätzliche Budget ungenutzt blieb: Thinking stieg von 5,944 Tokens auf 6,679. Das ist eine Tatsache über diese Aufgaben, nicht über das Modell. Bei schwererer Arbeit weitet sich diese Lücke.

Wo unsere Zahlen mit dem anderen unabhängigen Lauf nicht übereinstimmen

aibenchy führte nach dem Release 22 kurze Benchmark-Fragen aus und fand das neuere Modell bei medium 29.4% teurer und bei high 9.7% günstiger. Wir fanden es auf beiden Levels günstiger, um 13.6% und 20.1%. Die high-Ergebnisse stimmen in der Richtung überein. Die medium-Ergebnisse weisen in entgegengesetzte Richtungen, und der Grund ist in einer Zahl sichtbar: Sie maßen 66.2% mehr Thinking auf dem neueren Modell bei medium, wir maßen 2.0% mehr.

Wir werden ihr Ergebnis nicht als falsch bezeichnen. Zwei Aufgabensets produzierten entgegengesetzte Antworten auf dieselbe Frage, und das ist die Erkenntnis, die es sich mitzunehmen lohnt: Ob dieses Modell dir Tokens spart, hängt davon ab, womit du es fährst, nicht vom Modell allein. Googles eigenes „17% weniger Output-Tokens" nennt weder ein Thinking-Level noch ein Aufgabenset, weshalb es sich auf manchen Lasten reproduziert und auf anderen nicht.

Was unser Test dir nicht sagen kann. Neun Aufgaben waren nicht schwer genug, um die Levels bei der Qualität zu trennen. Jede Konfiguration erzielte neun von neun. Diese Zahlen stützen also eine kostenbasierte Empfehlung, welches Level zu fahren ist, und sie lokalisieren nicht den Punkt, an dem die Qualität zu sinken beginnt. Wiederholungsläufe variierten ebenfalls: Thinking-Tokens bewegten sich zwischen identischen Läufen derselben Aufgabe um 6% bis 51%, weshalb die obigen Zahlen Durchschnitte aus drei Läufen sind. Eine schwerere Runde, die darauf abzielt, den Qualitätsknick zu finden, läuft separat, und wir werden diese Seite damit aktualisieren.

Der umsetzbare Teil ist einfach: Egal welches Modell du fährst, setze das Thinking-Level explizit und bepreise das Level, das du tatsächlich fährst, nicht das Level, zu dem die Benchmarks veröffentlicht wurden.

Zwei Dinge, die das neue Modell laut Google schlechter macht

Google veröffentlicht in seinem Launch-Post zwei spezifische Schwächen, und beide konzentrieren sich an derselben Stelle.

Es exploriert, bevor es editiert. Das Modell neigt mehr als 3.5 Flash dazu, einen Diagnosedurchlauf zu machen, bevor es Code ändert. Bei komplexen Aufgaben erhöht das die Genauigkeit. Bei einfachen Frontend-Aufgaben produziert es zusätzliche Explorationsschritte, die du nicht brauchtest und nicht bezahlen wolltest.

Menschliche Bewerter bevorzugten die visuelle Ausgabe des älteren Modells. Speziell bei visuellem Layout und Styling favorisierten die Bewerter das frühere Modell. Googles angegebene Abhilfe ist, deine Designregeln in den Prompt zu schreiben, statt das Styling den Defaults des Modells zu überlassen.

Die Modellkarte listet außerdem Halluzination und gelegentlich langsame Antworten oder Timeouts unter den bekannten Einschränkungen.

Nichts davon spricht gegen das Upgrade. Es spricht dafür, die Entscheidung nach Oberfläche aufzuteilen. Wenn du eine Agent-Ebene und eine UI-Generierungs-Ebene hast, sind das unterschiedliche Lasten mit unterschiedlichen Belegen, und es gibt keine Regel, die besagt, dass sie dieselbe Modell-ID fahren müssen.

Wechseln ist keine Modell-String-Änderung

Das ist der Teil, der Teams erwischt, und der Grund, warum eine „ändere einfach den Modellnamen"-Empfehlung vom selben Tag jetzt falsch ist. Ab diesem Release, und ausdrücklich für alle Modelle danach, hat sich das Verhalten mehrerer Parameter geändert. Die vollständige Liste steht in Googles API-Changelog; die, die die Produktion leise kaputtmachen, sind diese.

temperature, top_p und top_k werden ignoriert, und es wird kein Fehler ausgelöst. Googles Dokumentation besagt, dass eine künftige Modellgeneration HTTP 400 zurückgeben wird, aber heute werden die Werte einfach verworfen. Wenn du dich auf temperature=0 verlässt, um eine Extraktions- oder Klassifizierungspipeline deterministisch zu halten, verschwindet diese Garantie ohne Log-Zeile, ohne Exception und ohne Alarm. Der Ersatzansatz ist, die Regel in die System Instruction zu schreiben.

Es gibt eine Version zweiter Ordnung davon, die es zu prüfen lohnt. OpenRouters Modell-Metadaten listen temperature, top_p und seed weiterhin unter den unterstützten Parametern, sodass ein Gateway deinen Wert akzeptiert und weiterleitet, und das Modell ignoriert ihn. Wer heute die Temperatur abstimmt, um die Ausgabequalität zu verbessern, stimmt eine Leeroperation ab.

thinking_budget wird durch thinking_level ersetzt. Das alte numerische Budget wird zu einem String-Enum. Beide in einem Request zu senden, gibt eine 400 zurück.

Drei kleinere. candidate_count wird auf Gemini 3.x nicht unterstützt. Ein Request, dessen letzte Nachricht die model-Rolle trägt, gibt jetzt 400 zurück, was das Response-Prefilling entfernt. Und jede FunctionResponse muss jetzt sowohl call_id als auch name tragen.

Für die zeilenweise Version, einschließlich Googles eigenem automatisiertem Migrations-Tooling und dem Abschaltplan für die Modelle, die dies ersetzt, siehe unseren Gemini 3.6 Flash Migrationsleitfaden. Eine Warnung, falls du selbst danach suchst: Leitfäden, die für frühere Gemini-Upgrades geschrieben wurden, einschließlich unserem eigenen zum Umzug von Gemini 3 Flash Preview auf Gemini 3.5 Flash, beschreiben Sampling-Parameter weiterhin als funktionierend, weil sie es auf diesem Modellpaar taten. Die obigen Deprecations beginnen mit dieser Generation.

Ein praktischer Hinweis zum Testen der beiden nebeneinander: Weil beide Modell-IDs über einen OpenAI-kompatiblen Endpoint auf EvoLink bereitstehen, kannst du base_url auf ein einziges Gateway richten und den Modell-String wechseln, um sie gegen deine eigenen Prompts zu A/B-testen, ohne zuerst eine zweite Integration aufzubauen. Das ist der günstigste Weg, die obigen Fragen zu Wissensintensität und UI für deinen eigenen Verkehr zu beantworten.

Bevor du den Schalter umlegst

Die veröffentlichten Zahlen engen die Frage ein. Vier Messungen schließen sie.

Logge Answer-Tokens und Thinking-Tokens getrennt. Eine Gesamt-Token-Metrik sagt dir nicht, warum sich deine Rechnung bewegt hat, weil sich nur eine der beiden Komponenten zwischen diesen Modellen anders verhält.
Nagle das Thinking-Level explizit fest. Erbe medium nicht aus Versehen und bepreise das Level, das du tatsächlich fährst, statt des high-Levels, das die veröffentlichten Benchmarks verwendeten. Auf unserem Aufgabenset war das mehr wert als der Modellwechsel: minimal kostete 73.6% weniger als der medium-Default bei gleicher Genauigkeit. Prüfe, ob deine eigene Arbeit es toleriert, bevor du dasselbe annimmst.
Shadow-Run deine echte Prompt-Mischung, nicht ein Benchmark-Set. Das ist am wichtigsten, wenn dein Verkehr wissensintensiv ist, was die eine Achse ist, auf der der vergleichbare Wert gesunken ist.
Greppe, bevor du umstellst. Durchsuche deine Codebasis nach temperature, top_p, top_k, thinking_budget und candidate_count. Die ersten drei schlagen still fehl, was bedeutet, dass deine Tests bestehen und deine Ausgaben driften.

Häufige Fragen

Ist Gemini 3.6 Flash ein umbenanntes Gemini 3.5 Pro? Diese Spekulation kursierte nach dem Launch. Die am höchsten bewertete Community-Antwort wies sie zurück, mit dem Argument, es gebe keinen Hinweis auf ein umbenanntes Pro-Modell und dies sei ein Flash-Upgrade. Die Modellkarte stützt diese Lesart: Sie gibt an, dass das Modell auf Gemini 3.5 Flash aufbaut. Wir halten die Spekulation fest, ohne sie zu befürworten.

Wird gemini-3.5-flash abgeschaltet? Die von Google angekündigten Abschaltdaten sind 2026-10-16 für gemini-2.5-flash und gemini-2.5-flash-lite und 2027-05-07 für gemini-3.1-flash-lite. Für die am 2026-07-21 veröffentlichten Modelle wurde kein Abschaltdatum angekündigt. Es gibt keine angekündigte Frist, die diese Entscheidung erzwingt, du kannst dir also die Zeit zum Messen nehmen.

Ist der Input-Preis gestiegen? Nein. Beide Modelle berechnen $1.50 pro Million Input-Tokens im Standard-Tier. Nur der Output-Preis änderte sich, von $9.00 auf $7.50.

Kann ich temperature=0 weiterhin für deterministische Ausgabe verwenden? Nein, und das ist der Fehlermodus, auf den man achten muss. Der Parameter wird akzeptiert und ohne Fehler ignoriert. Verschiebe die Einschränkung in die System Instruction und verifiziere die Ausgabe statt des Requests.

Ist 3.6 Flash für RAG nennenswert günstiger? Bei rund 20 Input-Tokens pro Output-Token implizieren die veröffentlichten Zahlen eine Ersparnis von 7.1%. Sie ist echt, aber klein, weil sich die Input-Seite deiner Rechnung nicht geändert hat. Behandle das als Obergrenze, nicht als Schätzung: Bei unseren eigenen Aufgaben lag die effektive Ersparnis unter dem, was dieselbe Arithmetik vorhersagte, und unser Test deckte Long-Context-Retrieval überhaupt nicht ab. RAG-Teams sollten dieses Release zuerst als Latenzverbesserung und erst danach als Kostenverbesserung behandeln.

Welche Modell-ID sollte ich verwenden? gemini-3.6-flash. Es gibt eine einzige stabile Version, ohne Preview-Suffix und ohne datumsgestempelte Variante zur Auswahl.