Benchmark: gemini-3.6-flash + gemini-3.5-flash-lite vs. Defaults (03.08.2026)
Frage
Dennis-Bestellung (relayed via Bus, dann live erweitert): lohnt der Umstieg von
den aktuellen Defaults (google/gemini-3.1-flash-lite Standard,
google/gemini-3.5-flash nur cook_suggest) auf google/gemini-3.6-flash bzw.
google/gemini-3.5-flash-lite? Zwei Runden:
1. Nur Latenz, nur 3 Use-Cases (photo/receipt_pdf/portion) — siehe unten, Runde 1.
2. Erweiterung (Dennis-Feedback): "zu stark auf Latenz fokussiert" — Qualität
zählt genauso ("ich bekomme ja was dafür"), 1–3 s Latenz ist akzeptabel, alle
Use-Cases aus ai_jobs.py, 3.5 direkt gegen 3.6, plus Recherche zu
modell-spezifischem Best-Practice-Prompting, bevor geurteilt wird.
Methodik-Korrektur (wichtig — bitte zuerst lesen)
Vor der zweiten Runde recherchiert: alle drei Modelle sind Gemini-3-Reasoning- Modelle mit unterschiedlichen Default-Thinking-Levels (3.1-flash-lite ≈ aus, 3.5-flash-lite ≈ minimal, 3.6-flash ≈ medium) — keines ist ein "klassisches" Nicht-Reasoning-Modell, wie in Runde 1 stillschweigend angenommen. Zwei dokumentierte Stolperfallen von Google/OpenRouter behoben:
reasoning.effortstattreasoning.max_tokens: bei Gemini-3-Modellen mappt OpenRouter einenmax_tokens-Wert nur ungefähr auf ein internes Thinking-Level ("you will not get precise token control") — der in Runde 1 gesetzte Cap{"max_tokens": 512}fürgemini-3.6-flashwar damit unpräzise. Mit dem korrekten, dokumentierten Parameter{"effort": "low"}verschwindet das kaputte-JSON-Problem beireceipt_pdfkomplett (siehe unten) — das war also ein Mess-Fehler meinerseits, kein Modell-Defekt.- Token-Headroom: Google warnt explizit,
max_tokensmüsse klar über dem Reasoning-Budget liegen, sonst wird die eigentliche Antwort abgeschnitten — in Runde 2 pauschal +4000 Tokens Puffer ergänzt. - Überraschung beim Fairness-Versuch:
reasoning.effortexplizit auf allen drei Modellen zu setzen (statt nur beigemini-3.6-flash, das es zwingend braucht) hatgemini-3.1-flash-litemassiv geschadet — beireceipt_pdfz. B. Wall-Zeit 91–147 s statt ~9 s! Dieses Modell ist am schnellsten, wenn man dasreasoning-Feld komplett weglässt (= exakt das, wasai_jobs.pyheute schon tut). Fazit: "explizit + einheitlich" ist NICHT automatisch "fair" — die jeweils modell-eigene Best Practice zählt.
Finale Tabelle unten kombiniert deshalb bewusst: gemini-3.1-flash-lite +
gemini-3.5-flash-lite ohne reasoning-Feld (ihr schneller, produktionsnaher
Default — 1:1 wie or_chat() es heute aufruft), gemini-3.6-flash mit
reasoning.effort="low" + Token-Headroom (sein zwingend nötiges, korrektes
Setup). Quellen: OpenRouter Reasoning Tokens Best
Practices,
Gemini 3 Developer Guide,
Gemini structured output docs.
Offene, nicht umgesetzte Verbesserung (separates Thema): Google empfiehlt
für JSON-Antworten explizit response_schema/responseMimeType statt
Prompt-Instruktion ("Antworte NUR mit JSON") — das nutzt weder dieser Benchmark
noch aktuell ai_jobs.py. Beide sind also gleich gehandicapt (fairer Vergleich),
aber ein struktureller Zuverlässigkeits-Gewinn für ALLE Modelle bliebe auf dem
Tisch, unabhängig von der Modellwahl hier — separates Ticket wert, falls
gewünscht.
Setup
Echte Produktions-Payloads für alle 10 OpenRouter-Use-Cases aus ai_jobs.py
(read-only aus der Live-DB gezogen, keine Schreibvorgänge/Pushes): Median-Bon-PDF
(bon-32.pdf, echter Kaufland-Bon — bon-33.pdf erwies sich als fehlabgelegte
Berufsurkunde, kein Bon, aussortiert), Median-Diary-Foto (diary-538.jpg),
realer portion/estimate-Prompt, echtes HelloFresh-Gericht mit Zutaten+Schritten
(steps), echter Vorrat (ideas, 149 Artikel), echter Dedup-Pool (merge_suggest,
250 Artikel), echte Sammelartikel-Gruppe „toilettenpapier" (member_suggest),
echtes mehrdeutiges Food-Paar „Cherry Strauchtomaten" vs. „Strauchtomaten"
(food_compare), realistischer Cook-Suggest-Kontext (Dennis+Jaqueline, echte
bald-ablaufende Vorratsartikel). Je Modell × Use-Case 3 Streaming-Läufe,
TTFT/Wall/Kosten wie gehabt, plus vollständiger Antworttext für die
Qualitätsbewertung — die habe ich selbst gemacht (kein Fremdmodell als Judge).
Ergebnisse: Latenz + Kosten (finale, korrigierte Zahlen)
| Use-Case | Modell | TTFT (best) | Wall ø | $/Call |
|---|---|---|---|---|
| portion | gemini-3.1-flash-lite (heute) | 0,72 s | 1,35 s | 0,00012 |
| gemini-3.5-flash-lite | 0,70 s | 0,86 s | 0,00022 | |
| gemini-3.6-flash | 2,93 s | 3,79 s | 0,00438 | |
| estimate | gemini-3.1-flash-lite (heute) | 0,47 s | 1,47 s | 0,00027 |
| gemini-3.5-flash-lite | 0,41 s | 0,72 s | 0,00042 | |
| gemini-3.6-flash | 3,77 s | 4,94 s | 0,00667 | |
| photo | gemini-3.1-flash-lite (heute) | 1,35 s | 2,45 s | 0,00053 |
| gemini-3.5-flash-lite | 0,94 s | 1,08 s | 0,00075 | |
| gemini-3.6-flash | 2,25 s | 3,34 s | 0,00524 | |
| steps | gemini-3.1-flash-lite (heute) | 0,59 s | 3,22 s | 0,00118 |
| gemini-3.5-flash-lite | 0,41 s | 2,05 s | 0,00181 | |
| gemini-3.6-flash | 0,57 s | 3,88 s | 0,00714 | |
| ideas | gemini-3.1-flash-lite (heute) | 0,52 s | 3,62 s | 0,00202 |
| gemini-3.5-flash-lite | 0,42 s | 2,96 s | 0,00251 | |
| gemini-3.6-flash | 2,84 s | 10,65 s | 0,01961 | |
| member_suggest | gemini-3.1-flash-lite (heute) | 0,66 s | 0,89 s | 0,00028 |
| gemini-3.5-flash-lite | 0,43 s | 0,48 s | 0,00035 | |
| gemini-3.6-flash | 1,82 s | 2,10 s | 0,00338 | |
| food_compare | gemini-3.1-flash-lite (heute) | 0,43 s | 0,87 s | 0,00013 |
| gemini-3.5-flash-lite | 0,39 s | 0,60 s | 0,00018 | |
| gemini-3.6-flash | 1,09 s | 1,35 s | 0,00121 | |
| merge_suggest | gemini-3.1-flash-lite (heute) | 0,66 s | 3,06 s | 0,00198 |
| gemini-3.5-flash-lite | 0,48 s | 1,66 s | 0,00265 | |
| gemini-3.6-flash | 4,77 s | 7,68 s | 0,01753 | |
| receipt_pdf | gemini-3.1-flash-lite (heute) | 0,86 s | 9,42 s | 0,00583 |
| gemini-3.5-flash-lite | 1,30 s | 11,25 s | 0,01221 | |
| gemini-3.6-flash (korrigiert) | 0,84 s | 26,71 s | 0,05237 | |
| cook_suggest | gemini-3.5-flash (heute) | 10,81 s | 16,59 s | 0,02749 |
| gemini-3.5-flash-lite | 0,40 s | 2,95 s | 0,00237 | |
| gemini-3.6-flash | 8,92 s | 15,76 s | 0,02404 |
Qualitäts-Befunde (der eigentliche Punkt dieser Runde)
Ich bin der Judge — keine der Bewertungen unten kam von einem Fremdmodell, ich habe die vollen JSON-Antworten selbst gelesen und beurteilt.
- receipt_pdf, härtester objektiver Test (57 Positionen, echter Bon):
gemini-3.1-flash-liteUNDgemini-3.5-flash-liteextrahieren in ALLEN 3 Läufen perfekt (Kontrollsumme exakt, 57/57 Positionen).gemini-3.6-flashlieferte in Runde 1 (falscher Reasoning-Parameter) in 2 von 3 Läufen abgeschnittenes, kaputtes JSON — mit dem korrigierteneffort-Parameter jetzt zwar zuverlässig korrekt, aber weiterhin am langsamsten (27 s) und 9–10× teurer als die beiden anderen, ohne jeden Qualitätsvorteil. - merge_suggest (semantische Dubletten-Erkennung), an 250 echten Produkten:
gemini-3.1-flash-litefindet MEHR echte Dubletten als beide Kandidaten (u. a. "Joghurt Erdbeere"/"Joghurt Erdbeeren"/"Fruchtjoghurt Erdbeere" als 3er-Gruppe, "Gemüsemais"↔"Gemüsemais" — identischer Name! —, "Pflaume blau"↔"Dunkle Pflaumen"), diegemini-3.5-flash-liteUNDgemini-3.6-flashBEIDE verpassen. Da Vorschläge ohnehin von dir geprüft werden (kein Auto-Merge), kostet ein Fehlen mehr als eine überflüssige Bestätigung — hier ist mehr Recall besser als weniger. - cook_suggest ("bald-weg"-Zutaten wirklich verwenden) — Korrektur nach
Dennis-Review: das AKTUELLE Setup (
gemini-3.5-flash) verwendet über 3 Läufe alle 5 bald-ablaufenden Artikel, inkl. "Holler Vitamin-Getränk" und "Eistee Erdbeer" — beide Kandidaten lassen genau diese zwei konsequent weg. Von mir ursprünglich als Recall-Nachteil gewertet — falsch bewertet: ein Vitamin-Getränk/Eistee in ein herzhaftes Gericht zu zwingen ist geschmacklich unsinnig (verletzt die eigene GESCHMACK-Regel des Prompts), das Weglassen ist RICHTIGES Verhalten, kein Qualitätsmangel. Damit entfällt der einzige Einwand gegen einen Modellwechsel beicook_suggest→gemini-3.6-flashumgesetzt (Dennis-Entscheidung), mitreasoning.effort="high"(nichtmax_tokens— mappt bei Gemini 3 nur ungefähr auf ein Thinking-Level;effort="high"auf Dennis' Wunsch) +max_tokens=16000(beihighfrisst das Reasoning-Budget sonst die eigentliche Antwort auf — 1 von 2 Testläufen bei 8000 kam abgeschnitten zurück, mit 16000 liefen 3/3 sauber, ~25–63 s, ~0,05–0,10 $/Call). - steps (Zutaten-Zuordnung zu Zubereitungsschritten):
gemini-3.5-flash-liteerfand einmal eine im Text nicht genannte Reis-Menge (150 g) und wich bei der Wasser-Menge vom Originaltext ab (400 statt 300 ml) —gemini-3.1-flash-liteundgemini-3.6-flashbleiben beide näher am tatsächlich genannten Text. Einzelbeobachtung, kein Muster über mehrere Läufe, aber ein Punkt für Stichproben nach einem Wechsel. - portion/estimate/photo/ideas/member_suggest/food_compare: inhaltlich gleichwertig über alle 3 Modelle — keine reproduzierbaren Qualitätsunterschiede gefunden, nur Latenz/Kosten unterscheiden.
- gemini-3.6-flash — durchgängiger Befund über alle 10 Use-Cases: in KEINEM Fall die beste Wahl. Selbst korrekt konfiguriert (Pflicht-Reasoning, richtiger Parameter, genug Headroom) immer langsamer als die Alternativen und 5–50× teurer, ohne einen einzigen beobachteten Qualitätsvorteil.
Datenqualitäts-Fund nebenbei
app/data/receipts-pdf/bon-33.pdf ist keine Kassenbon-PDF, sondern eine
Berufsurkunde ("Erlaubnis zur Führung der Berufsbezeichnung Gesundheits- und
Krankenpflegerin") — vermutlich eine fehlabgelegte Datei. Nicht Teil dieser
Bestellung, aber falls das für einen echten Import-Testlauf gebraucht wurde,
lohnt ein kurzer Check, wie sie dahin kam.
Empfehlung je Use-Case
| Use-Case | Empfehlung | Warum |
|---|---|---|
| portion, estimate, photo | → gemini-3.5-flash-lite | schneller/konsistenter, inhaltlich gleichwertig |
| steps, ideas | → gemini-3.5-flash-lite | schneller, gleichwertig (steps: 1 Ausreißer beobachtet — nach Umstellung kurz stichprobenartig prüfen) |
| member_suggest, food_compare | → gemini-3.5-flash-lite | schneller, identische Urteile in allen Tests |
| merge_suggest | → BEHALTEN: gemini-3.1-flash-lite | bessere Dubletten-Erkennung (Recall); Vorschläge werden eh geprüft, verpasste Dubletten kosten mehr als ein abgelehnter Vorschlag |
| receipt_pdf | → BEHALTEN: gemini-3.1-flash-lite | am echten 57-Positionen-Bon gleich perfekt wie 3.5-flash-lite, aber schneller + billiger |
| cook_suggest | → gemini-3.6-flash | vermeidet geschmacklich unpassende Zutaten (Vitamin-Getränk/Eistee) konsequenter — Dennis-Korrektur: das ist richtiges Verhalten, nicht wenig Recall |
| — | gemini-3.6-flash sonst nirgends | in den anderen 9 Use-Cases nicht die beste Wahl, selbst korrekt konfiguriert |
Umgesetzt (03.08., commit 0967988 + Folgecommit): OR_MODEL in
ai_jobs.py:47 auf google/gemini-3.5-flash-lite, explizite
model="google/gemini-3.1-flash-lite"-Overrides für job_merge_suggest/
job_receipt_pdf, job_cook_suggest auf google/gemini-3.6-flash
(reasoning.effort="high", max_tokens=16000). Insgesamt
~5 Zeilen statt 1 — noch NICHT angewendet, wartet auf dein Go.
Rohdaten: Benchmark-Skripte + full_bench_results*.json im Scratchpad dieser
Session (nicht Teil des Repos) · Messung 03.08.2026.