Gemini 3.6 Flash oder 3.5 Flash-Lite: Auswahl und API-Migration

Google hat Gemini 3.6 Flash und Gemini 3.5 Flash-Lite am 21. Juli 2026 als stabile, produktionsreife Modelle allgemein verfügbar gemacht. Beide gehören zur Flash-Familie, sind aber für unterschiedliche betriebliche Rollen positioniert: 3.6 Flash für stärkere Code- und agentische Planung, 3.5 Flash-Lite für latenzarme und kosteneffiziente Subagenten in volumenstarken Automationen.

Gleichzeitig erklärt Google die Sampling-Parameter temperature, top_p und top_k für die neuesten Gemini-Modelle als veraltet. Für Unternehmen ist das mehr als ein Release-Hinweis. Modellwahl, Promptverhalten, Tests und Konfiguration sollten gemeinsam geprüft werden, weil ein Wechsel sonst gleichzeitig Leistungs- und Schnittstellenänderungen vermischt.

Was Google bestätigt

Gemini 3.6 Flash ist unter dem Modellnamen gemini-3.6-flash verfügbar. Google nennt bessere Token-Effizienz, stärkere Fähigkeiten bei Code und agentischer Planung sowie einen niedrigeren Preis als bei Gemini 3.5 Flash. Zudem soll das Modell Rückmeldungen zur Ausgabeverbosity adressieren. Konkrete Einsparungen für einen Unternehmensprozess ergeben sich daraus noch nicht.

Gemini 3.5 Flash-Lite wird unter gemini-3.5-flash-lite als niedrig latente und besonders kosteneffektive Subagentenoption für Automationen mit hohem Volumen positioniert. Das ist eine Herstellerpositionierung, keine Garantie für jede Aufgabe. Qualität, Fehlversuche und menschliche Nacharbeit müssen im eigenen Prozess gemessen werden.

Bestätigt ist außerdem die Abkündigung von temperature, top_p und top_k für die neuesten Modelle. Eine Abkündigung bedeutet nicht zwingend, dass jede bestehende Anfrage sofort fehlschlägt. Sie ist aber ein klares Signal, diese Parameter nicht als dauerhaft stabilen Bestandteil neuer Integrationen einzuplanen und das tatsächliche API-Verhalten zu testen.

Entscheidungsmatrix: 3.6 Flash oder 3.5 Flash-Lite?

• Gemini 3.6 Flash prüfen, wenn Aufgaben mehrere Planungsschritte, Codeverständnis, Werkzeugkoordination oder eine ausführlichere fachliche Ableitung erfordern.
• Gemini 3.5 Flash-Lite prüfen, wenn viele klar begrenzte Subaufgaben mit niedriger Latenz bearbeitet werden sollen und Ergebnisse leicht automatisch oder menschlich überprüfbar sind.
• Beide Modelle kombinieren, wenn ein übergeordneter Agent komplex plant und klar definierte Teilaufgaben an kostengünstigere Subagenten delegiert. Berechtigungen und Übergabeformate müssen dabei fest vorgegeben sein.
• Bei einem Modell bleiben, wenn der zusätzliche Routing- und Testaufwand den erwarteten Vorteil übersteigt oder das Aufgabenvolumen zu gering für eine sinnvolle Trennung ist.
• Nicht automatisieren, wenn Fehler irreversible, rechtliche oder sicherheitskritische Folgen haben und keine wirksame Freigabestufe existiert.

Die Zuordnung sollte pro Prozess dokumentiert werden. Ein Modell für Zusammenfassungen kann ungeeignet für Codeänderungen sein, obwohl beide Aufgaben textbasiert wirken. Wichtig sind erwartetes Ergebnis, erlaubte Werkzeuge, Datenklasse, maximale Laufzeit und die Person oder Regel, die den Vorgang abnimmt.

Kosten nicht mit Preis pro Aufruf verwechseln

Google beschreibt 3.6 Flash als günstiger als 3.5 Flash und hebt dessen Token-Effizienz hervor. Für 3.5 Flash-Lite steht die kosteneffektive Verarbeitung hoher Volumina im Vordergrund. Ohne den eigenen Aufgabenmix lässt sich daraus keine belastbare Gesamtersparnis ableiten.

• Modellkosten pro Versuch und pro fachlich akzeptiertem Ergebnis
• Anzahl erzeugter Ein- und Ausgabetokens bei vergleichbarer Aufgabe
• Fehlversuche und notwendige Wiederholungen
• Laufzeit sowie Wartezeit in nachgelagerten Systemen
• Menschliche Prüfung und Nacharbeit
• Integrations-, Monitoring- und Routingaufwand

Ein Flash-Lite-Aufruf ist nur dann wirtschaftlicher, wenn die Erfolgsquote und der Prüfaufwand zur Aufgabe passen. Umgekehrt kann 3.6 Flash trotz höherem Aufwand pro Lauf günstiger sein, wenn komplexe Aufgaben häufiger direkt abgenommen werden. Die richtige Kennzahl sind Gesamtkosten je abgeschlossenem Vorgang.

Sampling-Parameter kontrolliert migrieren

1. Bestand suchen: Erfassen Sie temperature, top_p und top_k in Code, Konfiguration, Prompt-Management, SDK-Wrappern, Tests und Deployment-Variablen.
2. Abhängigkeit verstehen: Dokumentieren Sie, welches Verhalten Teams mit den Parametern steuern wollten und welche Tests diese Annahme heute absichern.
3. Neue Baseline bilden: Führen Sie repräsentative Aufgaben ohne veraltende Parameter aus und vergleichen Sie Qualität, Formatstabilität, Laufzeit und Wiederholbarkeit.
4. Vertrag anpassen: Entfernen oder kapseln Sie die Parameter nur dort, wo der neue Pfad geprüft ist. Unbekannte oder nicht mehr unterstützte Felder dürfen keine stillen Produktionsfehler verursachen.
5. Rollback sichern: Versionieren Sie Modellname, Request-Schema und Prompt. Bei Qualitätsverlust muss der vorherige freigegebene Zustand kontrolliert wiederherstellbar sein.

Besonders wichtig ist die Trennung von Ursachen. Wenn ein Team gleichzeitig das Modell wechselt, Parameter entfernt und Prompts überarbeitet, lässt sich eine Abweichung später kaum zuordnen. Besser ist eine schrittweise Migration mit festen Referenzfällen.

Fünf Schritte für den produktiven Rollout

1. Aufgaben segmentieren: Teilen Sie den Prozess in komplexe Planung, einfache Subaufgaben und nicht automatisierbare Entscheidungen.
2. Baseline messen: Erfassen Sie beim bisherigen Modell Qualität, Kosten, Laufzeit, Fehler und menschliche Nacharbeit.
3. Modelle getrennt testen: Vergleichen Sie 3.6 Flash und 3.5 Flash-Lite mit identischen Aufgaben und Abnahmekriterien.
4. API-Migration isolieren: Prüfen Sie den Request ohne veraltende Sampling-Parameter, bevor Modellrouting und größere Promptänderungen hinzukommen.
5. Gestuft freigeben: Starten Sie mit begrenztem Volumen und menschlicher Kontrolle. Erweitern Sie nur, wenn Qualitäts-, Kosten- und Stabilitätsgrenzen eingehalten werden.

Für den laufenden Betrieb braucht jedes Aufgabenprofil einen Eigentümer, ein Budget und einen Fallback. Neue Modellversionen oder API-Änderungen werden gegen denselben Referenzbestand geprüft. So bleibt die Auswahl nachvollziehbar, auch wenn sich Preise, Modelle oder Standardverhalten verändern.

Die Managemententscheidung

Gemini 3.6 Flash ist der naheliegende Kandidat für anspruchsvollere Code- und Agentenplanung; Gemini 3.5 Flash-Lite für klar begrenzte, volumenstarke Subagentenaufgaben. Die GA-Freigabe senkt das Reiferisiko gegenüber einer Preview, ersetzt aber nicht die eigene Evaluation. Unternehmen sollten Modellwahl und Parameter-Migration getrennt testen und erst nach belastbaren Qualitäts- und Gesamtkostenmessungen produktiv ausrollen.