Cost-per-Task statt Benchmark-Score: die 30-Minuten-Methode, die deinen Modellwechsel wirklich entscheidet

Cost-per-Task statt Benchmark-Score: die 30-Minuten-Methode, die deinen Modellwechsel wirklich entscheidet

TL;DR: Benchmark-Tabellen vergleichen Modelle auf fremden Aufgaben. Deine Entscheidungen fallen aber auf deinen Aufgaben. Mit fünf echten Tasks, zwei Messläufen und einer Mini-Tabelle pro Token-Kategorie hast du in 30 Minuten eine eigene Cost-per-Task-Rechnung — und tauschst nur, wenn sie in Euro und Sekunden gewinnt, nicht nur im Punktestand.

Warum die Benchmark-Tabelle allein selten weiterhilft

Public-Scores wie GPQA oder MMLU sind nützlich für die erste Vorauswahl. Für den Wechsel eines laufenden Modells fehlen ihnen drei Dinge: sie kennen deine Prompt-Längen nicht, sie ignorieren die Kontext-Steuer bei langen Sessions, und sie sagen nichts über dein Preis-Leistungs-Verhältnis pro tatsächlichem Task aus.

Ein Modell kann auf dem Papier 3 Punkte vorn liegen und in deinem Stack trotzdem teurer oder langsamer sein — etwa weil es mehr Output-Tokens pro Antwort braucht oder deinen Cache schlechter trifft. Deshalb: eigene Messung, eigene Rechnung.

Die 30-Minuten-Methode in 5 Schritten

1. Fünf echte Tasks auswählen: die letzten fünf produktiven Anfragen aus deinem Workflow, nicht Tutorial-Beispiele.
2. Gleiche Prompts, beide Modelle: jeweils einmal alt, einmal neu, gleiche Parameter (Temperatur, max tokens).
3. Vier Werte pro Lauf notieren: Input-Tokens, Output-Tokens, Sekunden, korrekt ja/nein.
4. Cost-per-Task rechnen: Tokenzahlen durch 1.000.000 mal den jeweiligen Tokenpreis, dann pro Task summieren.
5. Nach 5 Tasks vergleichen: Mediane bilden — nicht Mittelwerte, einzelne Ausreißer verzerren sonst das Bild.

Das Protokoll ist eine einzige Tabelle. Mehr braucht es nicht.

Rechenbeispiel mit echten Preisdaten

Hy-4 Preview (Tencent, 770B total / 49B aktive Parameter, Apache 2.0) kostet im API-Angebot 0,834 USD pro Million Input-Tokens und 2,001 USD pro Million Output-Tokens. Ein typischer Support-Task mit 8.000 Input- und 2.000 Output-Tokens:

Bei 2.000 Tasks pro Monat landen wir bei etwa 22 USD vs. 60 USD. Der Wechsel lohnt sich, wenn die fünf Tasks auch inhaltlich mindestens gleich gut beantwortet wurden — gemessen an deinem eigenen Korpus, nicht am Leaderboard.

Wer lokal misst, rechnet dieselbe Logik mit Hardware-Zeit statt Token-Preisen: Qwen3.8-27B als GGUF braucht rund 11,8 GB Footprint und läuft mit etwa 40 Token/s auf einer RTX 5060 Ti — auch das ist eine Cost-per-Task-Zahl, nur in Sekunden statt Dollar.

Ein kopierbares Protokoll

task_01:
  prompt_hash: a1b2c3
  model_old: {input: 8000, output: 2000, seconds: 6.4, correct: true}
  model_new: {input: 8000, output: 1700, seconds: 4.1, correct: true}
  cost_old: 0.030
  cost_new: 0.010
task_02: ...
# Mediane am Ende bilden, nicht Mittelwerte

Typische Fehler

• Zu kurze Serien: unter fünf Tasks ist die Varianz größer als der Unterschied. Nachmessen statt raten.
• Parameter verchanged: wer beim neuen Modell die Temperatur anfasst, misst das Modell und nicht den Wechsel.
• Kontext-Steuer vergessen: lange Sessions blähen die Input-Tokens. Genau deshalb pro Task zählen, nicht pro Modell pauschal.
• Nur Dollar vergleichen: bei Latenz-kritischen Workflows ist die Sekunden-Spalte das Zünglein an der Waage.

FAQ

Wie viele Tasks brauche ich für eine belastbare Cost-per-Task-Aussage? Fünf Tasks sind die Untergrenze, zehn sind komfortabel. Der Grund: Tokenzahlen streuen je nach Task-Typ stark, und der Median aus fünf Läufen glättet das schon besser als der Mittelwert aus zwei. Wenn sich nach fünf Tasks kein konsistentes Muster zeigt, war die Task-Auswahl zu gemischt — dann in zwei Serien trennen (kurze Klassifikation vs. lange Zusammenfassung).

Was, wenn das neue Modell andere Tokenzahlen für denselben Prompt liefert? Das ist normal und Teil der Messung: notiere Input- und Output-Tokens je Modell getrennt. Die Cost-per-Task-Rechnung trägt das automatisch ab, weil beide Größen in die Summe eingehen. Nur die Sekunden-Zahl solltest du bei gleicher Prompt-Länge vergleichen, sonst mischst du Latenz- und Modell-Effekte.

Funktioniert die Methode auch für lokale Modelle? Ja, dann rechnest du statt Dollar pro Token mit Sekunden pro Task und dem festen Hardware-Fenster. Ein lokaler Lauf auf 11,8-GB-Footprint mit 40 Token/s ist direkt mit der API-Laufzeit vergleichbar, weil beide in derselben Einheit (Sekunden pro Task) enden. Der Vorteil: dein Cache-Verhalten und die Kontext-Steuer werden realitätsnah mitgemessen.

Wie gehe ich mit Caching um — muss ich das abschalten? Nein, im Gegenteil: miss im selben Modus, den du produktiv nutzt. Prompt-Caching ist Teil des Kostenprofils deines Setups. Notiere nur in der Protokoll-Tabelle, ob der Cache warm oder kalt war, damit du Äpfel mit Äpfeln vergleichst. Ein einzelner kalter Start-Lauf pro Modell reicht als Referenz.

Wann lohnt sich das Nachmessen danach noch? Bei jedem Major-Release des neuen Modells und bei Änderung der Preisliste — beides ist selten, also misst du höchstens quartalsweise. Dazwischen reicht die erste Messung, weil sich Tokenpreise und Modellarchitektur nicht ständig bewegen. Nur wenn deine Prompt-Längen im Produktivbetrieb stark wandern, solltest du die Serie nachziehen, denn dann verschiebt sich die Cost-per-Task-Kurve mit.

Quellen

• Tencent Hy-4 Preview (Modell- und Preisdaten): https://www.youtube.com/watch?v=Dmlszfz2LjM
• Deltafin — Layer-Streaming für 2,8T Kimi K3 auf Laptop-NVMe: https://github.com/argonautlabsai/deltafin
• Qwen3.8-27B GGUF Messwerte (Footprint, tok/s): Kontext-Studios-Daily-Intel-Run #175
• Google Gemini API-Pricing (Referenzpreise): https://ai.google.dev/gemini-api/docs/pricing