Zuletzt aktualisiert:

OpenRouter-Benchmark für Silverscale-KI-Jobs · 06.06.2026

Setup: Realer Produktions-Prompt (Nährwert-Schätzung „kleine Portion Pommes mit Ketchup" → JSON mit name/kcal/Makros, ~120 Token in, ~80 Token out), je Modell 3 Läufe via OpenRouter-API (Streaming für TTFT-Messung), vom VPS aus. Referenz: claude -p (CLI, wie unsere Worker heute laufen). Preise live aus der OpenRouter-Models-API. Modellauswahl: deine Liste (Stand Juni 2026) — grok-4.1-fast existiert auf OpenRouter nicht mehr (404), deepseek-v4-pro lieferte im Non-Streaming-Lauf 3× kein parsebares JSON und wurde im TTFT-Lauf durch v4-flash vertreten.

Ergebnisse

Modell TTFT (best) Wall ø $/MTok in→out €/Mt ⁽¹⁾ JSON-Hygiene kcal-Schätzung ⁽²⁾
google/gemma-4-26b-a4b-it 0,25 s 0,98 s 0,06 → 0,33 ~0,70 $ ```json-Fence (Strip nötig) 350 ✓
google/gemini-3.1-flash-lite 0,79 s 1,12 s 0,25 → 1,50 ~3,10 $ rohes JSON 320 ✓
google/gemini-3-flash-preview 0,94 s 1,13 s 0,50 → 3,00 ~6,25 $ rohes JSON ✓ 315 ✓
anthropic/claude-haiku-4.5 (OR) 0,98 s 1,60 s 1,00 → 5,00 ~11,25 $ ```json-Fence 250 (etwas niedrig)
google/gemma-4-31b-it 0,81 s 2,61 s 0,12 → 0,36 ~1,05 $ ```json-Fence 320 ✓
x-ai/grok-4.3 2,53 s 3,21 s 1,25 → 2,50 ~9,40 $ rohes JSON ✓ 350 ✓
deepseek/deepseek-v4-flash 7,13 s 7,19 s 0,10 → 0,20 ~0,75 $ JSON nach Reasoning-Block ⁽³⁾ 350 ✓
qwen/qwen3.7-plus 26,2 s 31,0 s 0,40 → 1,60 ~4,00 $ JSON nach Reasoning 330 ✓
deepseek/deepseek-v4-pro 8,0–8,5 s 0,55 → 2,19 0/3 valides JSON ⁽³⁾
x-ai/grok-4.1-fast 404 auf OpenRouter
CLI claude -p haiku (heute) n/a 4,2–9,8 s Abo 0 $ extra Fence 250–310
CLI claude -p sonnet n/a 7,2–8,0 s Abo 0 $ extra Fence

⁽¹⁾ Hochgerechnet auf 5 000 Jobs/Monat à ~1k in / 250 out; euer reales Volumen liegt eher bei 1–2k Jobs → real unter 1–2 $/Monat für jeden Kandidaten. ⁽²⁾ Plausibel für „kleine Portion Pommes + Ketchup" sind ~300–400 kcal. Alle Kandidaten liegen im Korridor; Haiku schätzt mit 250 am knappsten. ⁽³⁾ DeepSeek/Qwen sind (Hybrid-)Reasoning-Modelle: sie denken erst lange nach. v4-flash liefert im Streaming am Ende sauberes JSON (aber erst nach 7 s), v4-pro sprengte im Non-Streaming-Modus 3× das Format. Für kurze Struktur-Tasks die falsche Modellklasse.

Vergleich zur heutigen CLI-Pipeline

heute:   Job-Queue-Pickup ≤2 s  +  claude -p haiku 4–10 s   ≈ 6–12 s gefühlt
OR:      Job-Queue-Pickup ≤2 s  +  gemini-flash-lite ~1,1 s ≈ 3 s gefühlt

Der CLI-Overhead (Session-Init/Auth der claude-CLI, gemessen ~3 s Floor + variable API-Latenz) ist der dominante Kostenfaktor — nicht das Modell und nicht unsere Queue (die holt seit ADR-27 in ≤2 s ab). Dieselbe Haiku-4.5-Inferenz, die per CLI 4–10 s braucht, antwortet via OpenRouter in 1,0–1,6 s.

Qualitäts-Anmerkungen

Empfehlung

  1. Switch lohnt sich klar: Faktor 4–8 bei der gefühlten KI-Latenz (11 s-Flow → ~3 s), Kosten bei eurem Volumen < 2 $/Monat — das „kostet aber Geld 😢" ist praktisch gegenstandslos.
  2. Arbeitstier: google/gemini-3.1-flash-lite — bester Mix aus TTFT (0,8 s), Wall (1,1 s), rohem JSON, Vision-Fähigkeit (deckt auch den Foto-Flow ab) und Preis (~3 $/Mt bei 5k Jobs, real <1 $).
  3. Sparfuchs-Alternative: google/gemma-4-26b-a4b-it für die simplen Batch-Jobs (Namen, Gruppen, Packungsgrößen) — schnellster TTFT, ¼ des Preises; Fence-Stripping haben wir eh.
  4. Nicht nehmen: DeepSeek/Qwen (Reasoning-Latenz), grok-4.3 (teurer + langsamer als Gemini ohne Qualitätsvorteil hier).
  5. Migrationsskizze (wenn du grünes Licht gibst): ai_jobs.py bekommt einen llm()-Wrapper (OpenRouter-HTTP statt claude -p), Modell je Job-Art konfigurierbar, CLI als Fallback wenn der OR-Call scheitert. Aufwand ~1–2 h, kein Architektur-Umbau (Queue/Endpoints unverändert).

Rohdaten: /tmp/or-bench*.log, /tmp/or-bench-ttft.json · Messung vom 06.06.2026 abends, Einzelmessungen je 3 Läufe, TTFT = Zeit bis zum ersten sichtbaren Content-Token im Stream.