Das richtige Modell für die Aufgabe (und das Budget) auswählen

Ein hilfreiches Denkmodell: Erst die Art der Aufgabe, dann das Modell

In der Praxis ordne ich LLM-Workloads anhand von fünf Dimensionen ein, bevor ich mir überhaupt Modellnamen ansehe:

Die Modellauswahl wird deutlich einfacher, sobald Sie nicht mehr fragen: „Welches Modell ist am intelligentesten?“, sondern: „Welches Fehlerrisiko verringere ich mit dieser Ausgabe?“

Zum Beispiel:

• Ein Tool zur Zusammenfassung von Anfragen zum Zurücksetzen von Passwörtern braucht Konsistenz und niedrige Kosten.
• Ein Assistent für Codemigrationen braucht Schlussfolgerungsfähigkeiten und Tool-Nutzung.
• Ein Tool zum Vergleich von Verträgen braucht ein großes Kontextfenster, aber auch eine sorgfältige Zuordnung zu den Quellen.
• Ein kundenorientierter Agent braucht vorhersehbare Latenz mehr als Spitzenwerte in Benchmarks.
• Für eine Batch-Pipeline zur Datenanreicherung kann der Durchsatz pro Dollar wichtiger sein als die Eleganz der Antworten.

Das falsche Modell ist oft nicht technisch falsch. Es ist wirtschaftlich falsch.

Eine praktische Modellhierarchie

Diese Hierarchie verwende ich für die meisten Produktionssysteme.

Modelle der Haiku-Klasse: Der Standard für günstige, schnelle Sprachaufgaben

Modelle der Haiku-Klasse eignen sich hervorragend für den ersten Durchlauf. Ich setze sie für Aufgaben ein, bei denen die Antwort kurz, die Eingabe sauber und das Ausgabeformat klar begrenzt ist.

Gut geeignet für:

• Ticket-Kategorisierung
• Kurze Zusammenfassungen
• Stimmungsklassifizierung
• Vereinheitlichung von E-Mail-Betreffzeilen
• Zuordnung zu FAQ-Einträgen
• Einfache JSON-Extraktion
• Vorfilter für Moderationsaufgaben mit geringem Risiko

Beispielprompt für einen kostengünstigen Klassifikator im ersten Durchlauf:

{
  "model": "claude-haiku-4.5",
  "temperature": 0,
  "max_tokens": 120,
  "response_format": { "type": "json" },
  "messages": [
    {
      "role": "system",
      "content": "Classify the support ticket. Return only valid JSON."
    },
    {
      "role": "user",
      "content": "Subject: Refund not received\nBody: I canceled two weeks ago and still see a charge."
    }
  ]
}

Erwartete Ausgabe:

{
  "category": "billing",
  "urgency": "medium",
  "needs_human": true,
  "reason": "Refund dispute involving payment status"
}

Ein häufiger Fallstrick: Teams verlangen von günstigen Modellen, in einem einzigen Durchlauf sowohl logisch zu schlussfolgern als auch perfekt zu formatieren. Wenn das Modell gelegentlich ungültiges JSON ausgibt, wechseln Sie nicht sofort zu Opus. Grenzen Sie zunächst die Aufgabe stärker ein:

• Setzen Sie temperature: 0
• Verwenden Sie ein JSON-Schema oder einen Tool-Aufruf
• Reduzieren Sie den Umfang der Anweisungen
• Trennen Sie Klassifikation und Erklärung
• Validieren Sie die Ausgabe und versuchen Sie es einmal erneut

Bei vielen Produktionsaufgaben ist ein erneuter Versuch mit einem Modell der Haiku-Klasse immer noch günstiger und schneller, als standardmäßig ein führendes Reasoning-Modell einzusetzen.

Modelle der Sonnet-Klasse: Das Arbeitspferd für echte Produktlogik

Für interaktive Produktfunktionen entscheide ich mich meist für Modelle der Sonnet-Klasse. Sie sind leistungsfähig genug für logisches Schlussfolgern, stabil genug für den Tool-Einsatz und meist schnell genug für nutzerseitige Abläufe.

Gut geeignet für:

• Entwürfe für den Kundensupport
• Agentische Workflows mit Tools
• Code-Erklärungen und kleinere Refactorings
• Mehrstufige Fragen und Antworten zu Dokumenten
• Copilot-Workflows für Vertrieb oder Customer Success
• Strukturierte Extraktion aus unübersichtlichen Eingaben

In der Praxis ist Sonnet oft die beste Wahl, wenn man sich über das Routing nicht allzu viele Gedanken machen möchte. Wenn Sie nur eine Modellklasse in eine neue Funktion integrieren können, beginnen Sie hier.

Beispiel: ein Support-Agent, der eine Bestellung, eine Richtlinie und frühere Tickets prüfen kann.

SYSTEM = """
You are a support resolution assistant.
Use tools before making claims about orders, refunds, or account state.
If policy is ambiguous, say what is ambiguous and escalate.
Return:
- summary
- recommended_action
- customer_reply
- escalate: true/false
"""

request = {
    "model": "claude-sonnet-4.6",
    "temperature": 0.2,
    "max_tokens": 900,
    "tools": [
        {"name": "get_order", "description": "Fetch order state"},
        {"name": "get_refund_policy", "description": "Fetch current refund rules"},
        {"name": "search_prior_tickets", "description": "Search customer history"}
    ],
    "messages": [
        {"role": "system", "content": SYSTEM},
        {"role": "user", "content": "Customer says they returned item A but were charged again."}
    ]
}

Was beim Einsatz solcher Workflows in der Produktion tatsächlich passiert: Die meisten Fehler liegen nicht daran, dass „das Modell dumm ist“. Es sind Integrationsfehler.

• Das Tool liefert einen veralteten Zustand zurück.
• Das Modell erhält zu viel irrelevanten Kontext.
• Das Richtliniendokument enthält widersprüchliche Aussagen.
• Der Agent darf nach einem fehlgeschlagenen Tool-Aufruf fortfahren.
• Der Prompt verlangt sowohl eine interne Analyse als auch einen kundenfertigen Text, ohne beides voneinander zu trennen.

Ein Modell der Sonnet-Klasse bietet genug Intelligenz, um einige Unzulänglichkeiten auszugleichen. Es macht klar definierte Schnittstellenverträge für Tools jedoch nicht überflüssig.

Modelle der Opus-Klasse: Teuer, aber manchmal günstiger als Fehler

Modelle der Opus-Klasse eignen sich für Aufgaben, bei denen die Kosten einer schlechten Antwort die Inferenzkosten überwiegen.

Ich greife zu Opus, wenn:

• Die Eingabe mehrdeutig ist und viel auf dem Spiel steht
• Viele miteinander zusammenhängende Einschränkungen vorliegen
• Der Nutzer tiefgehendes logisches Schlussfolgern erwartet
• Die Aufgabe Abwägungen zu Code, Richtlinien oder Architektur umfasst
• Ein gescheiterter günstiger Versuch menschliche Arbeitszeit verschwenden würde

Beispiele:

• Prüfung eines Datenbankmigrationsplans
• Analyse des zeitlichen Ablaufs eines Produktionsvorfalls
• Erstellung eines komplexen Vergleichs rechtlicher Richtlinien zur Prüfung durch einen Menschen
• Fehlersuche bei einem Agentenausfall über mehrere Dienste hinweg
• Bewertung, ob eine automatisierte Aktion sicher ist

Ich verwende Opus nicht für jede „wichtige“ Aufgabe. Wichtigkeit und Schwierigkeit sind unterschiedliche Dinge. Eine Million Tickets zum Zurücksetzen von Passwörtern sind für Nutzer wichtig, aber einzeln nicht schwierig. Eine einzige Migration zur Datenlöschung mit subtilen Fallstricken kann sowohl wichtig als auch schwierig sein.

Ein nützliches Muster ist „bei Unsicherheit eskalieren“:

def choose_model(task):
    if task["context_tokens"] > 700_000:
        return "fable-5"

    if task["risk"] == "high" and task["requires_reasoning"]:
        return "claude-opus-4.8"

    if task["requires_tools"] or task["multi_step"]:
        return "claude-sonnet-4.6"

    return "claude-haiku-4.5"

Das ist bewusst einfach gehalten. Der Router sollte so unspektakulär sein, dass Ihr Team ihn auch um 2 Uhr morgens debuggen kann.

Fable 5 und 1M-Kontext: Einsetzen, wenn Retrieval das Problem ist

Modelle mit langem Kontext sind verlockend, weil sie viel Entwicklungsarbeit für Retrieval ersparen. Das 1M-Kontextfenster von Fable 5 verändert, was Sie direkt angehen können: die Prüfung ganzer Dokumente, die Synthese riesiger Transkripte, die Untersuchung großer Repositories und die Analyse von Richtlinien über mehrere Dateien hinweg.

Aber langer Kontext ist keine Magie.

Ein Fenster mit 1M Tokens hilft, wenn die Schwierigkeit darin besteht, dass „die relevante Information irgendwo stehen könnte“. Es garantiert nicht, dass das Modell über alle eine Million Tokens hinweg fehlerfrei schlussfolgert, und es macht irrelevanten Kontext nicht kostenlos. Lange Prompts kosten weiterhin Geld, erhöhen die Latenz und können die Aufmerksamkeit verwässern.

Ich verwende langen Kontext nach dem Vorbild von Fable, wenn:

• Das Korpus zu stark vernetzt ist, um es einfach in Abschnitte aufzuteilen
• Ein übersehenes Detail schwerer wiegt als die Kosten für zusätzlichen Kontext
• Der Nutzer langsamere Antworten akzeptieren kann
• Die Aufgabe davon profitiert, das unverarbeitete umgebende Material zu sehen

Beispielarchitektur für die Prüfung großer Dokumente:

User request
  -> lightweight classifier
  -> retrieve obvious relevant sections
  -> if confidence high: Sonnet answer with citations/quotes from chunks
  -> if confidence low or query is global: Fable 5 over full document set
  -> optional Opus review for high-risk final answer

Dieser hybride Ansatz funktioniert besser, als „immer alles in den Kontext zu stopfen“. In der Praxis sind Modelle mit langem Kontext besonders wertvoll als Ausweichmöglichkeit, wenn die Zuverlässigkeit des Retrievals gering ist.

Modelle mit offenen Gewichten: Kontrolle, Kosten und Durchsatz

Modelle mit offenen Gewichten wie Llama, Qwen, DeepSeek, MiniMax und Kimi sind nicht einfach nur „günstigere Alternativen“. Sie sind Entscheidungen über den Betrieb.

Sie sind sinnvoll, wenn Sie Folgendes benötigen:

• Lokale Bereitstellung oder Bereitstellung in einer VPC
• Planbare Kosten für Batch-Verarbeitung mit hohem Volumen
• Fine-Tuning oder Destillation
• Individuelle Inferenzoptimierungen
• Kontrolle über den Standort der Daten
• Extrem niedrige Grenzkosten nach der Einrichtung

Sie eignen sich besonders gut für eng umrissene, wiederkehrende Aufgaben. Beispielsweise kann eine über vLLM bereitgestellte Qwen- oder Llama-Variante Klassifikation, Extraktion und interne Anreicherung mit hohem Durchsatz bewältigen, wenn Sie Prompt-Länge und Ausgabeformat kontrollieren.

Beispiel für eine lokale Bereitstellung:

vllm serve Qwen/Qwen3-14B \
  --host 0.0.0.0 \
  --port 8000 \
  --tensor-parallel-size 2 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90

Rufen Sie es anschließend über einen OpenAI-kompatiblen Client auf:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="local"
)

result = client.chat.completions.create(
    model="Qwen/Qwen3-14B",
    temperature=0,
    messages=[
        {"role": "system", "content": "Return valid JSON only."},
        {"role": "user", "content": "Classify: user cannot access invoice PDF"}
    ]
)

Der Preis dafür ist die technische Eigenverantwortung. Bei gehosteten führenden Modellen kümmert sich jemand anderes um Kapazität, Patches, die Auswahl der Quantisierung und Leistungsoptimierungen auf Kernel-Ebene. Bei offenen Modellen wird das zu Ihrer Aufgabe.

Modelle mit offenen Gewichten passen hervorragend zu stabilen Workloads. Sie sind weniger geeignet, wenn sich das Produkt wöchentlich ändert und die Prompt-Qualität wichtiger ist als die reinen Bereitstellungskosten.

Routing mit günstigen Modellen zuerst und Eskalation

Ein guter Router ist keine Rangliste. Er ist ein System zur Risikokontrolle.

Hier ist ein Muster, das sich für den Produktionsbetrieb eignet:

1. Versuchen Sie es mit dem günstigsten Modell, das die Aufgabe voraussichtlich bewältigen kann.
2. Validieren Sie die Ausgabe automatisiert.
3. Bitten Sie das Modell um eine kalibrierte Selbstprüfung, die sich ausschließlich auf beobachtbare Kriterien bezieht.
4. Eskalieren Sie, wenn die Validierung fehlschlägt, die Konfidenz gering oder das Risiko hoch ist.
5. Protokollieren Sie den Routing-Pfad und das Ergebnis für spätere Optimierungen.

Beispielrouter:

def run_with_escalation(task, input_text):
    first_model = pick_first_model(task)

    response = call_model(
        model=first_model,
        input=input_text,
        schema=task["schema"],
        temperature=0
    )

    validation = validate(response, task["schema"])

    if not validation.ok:
        return call_model(
            model="claude-sonnet-4.6",
            input=input_text,
            schema=task["schema"],
            temperature=0
        )

    if task["risk"] == "high" and response.get("needs_review"):
        return call_model(
            model="claude-opus-4.8",
            input=input_text,
            schema=task["schema"],
            temperature=0
        )

    return response

Entscheidend ist, dass die Eskalation auf messbaren Signalen beruht und nicht auf einem Bauchgefühl.

Nützliche Eskalationssignale:

• Ungültiges JSON
• Fehlende Pflichtfelder
• Widersprüchliche Antwort
• Tool-Aufruf fehlgeschlagen
• Abgerufene Belege sind schwach
• Der Nutzer verlangt eine irreversible Aktion
• Die Eingabe überschreitet die übliche Länge
• Das Modell kennzeichnet Unsicherheit ausdrücklich
• Der Klassifikator erkennt rechtliche, medizinische, sicherheitsbezogene oder finanzielle Inhalte

Verwenden Sie nicht ausschließlich die „Modellkonfidenz“ als numerischen Wert. Die Konfidenz eines LLM ist keine kalibrierte Wahrscheinlichkeit. Sie ist dennoch nützlich, wenn sie auf konkrete Prüfungen beschränkt wird: „Enthielt die Eingabe genügend Informationen für eine Antwort?“ ist besser als „Wie sicher sind Sie?“

Latenz, Preis und Nutzererlebnis

Das schnellste Modell bietet nicht immer das beste Nutzererlebnis. Das beste Nutzererlebnis führt den Nutzer mit einer akzeptablen Wartezeit zu einem korrekten Ergebnis.

Bei interaktiven Systemen denke ich in Latenzbudgets:

Verbergen Sie langsame Denkprozesse nicht hinter einer Ladeanimation ohne Rückmeldung. Wenn ein Opus- oder Fable-Auftrag 90 Sekunden benötigt, machen Sie daraus eine ausdrückliche Analyseaufgabe:

Analyzing 184 files...
✓ Indexed repository structure
✓ Found 12 migration scripts
✓ Checking rollback safety

Das verändert die Wahrnehmung der Nutzer, weil das System sichtbar arbeitet.

Nutzen Sie außerdem Streaming, wann immer möglich. Streaming verkürzt die Gesamtdauer bis zum Abschluss nicht, verbessert aber die wahrgenommene Latenz bei Chat- und Textentwurfs-Workflows erheblich.

Konkrete Entscheidungen nach Aufgabe

Hier sind konkrete Entscheidungen, die ich heute treffen würde.

Triage von Support-Tickets

Verwenden Sie zuerst Haiku.

• Eingabe: kurzer Tickettext
• Ausgabe: Kategorie, Dringlichkeit, zuständige Warteschlange
• Eskalation an Sonnet bei Streitfällen zur Abrechnung, verärgerten Kunden und unklaren Richtlinien
• Menschliche Prüfung bei Rückerstattungen oberhalb des Schwellenwerts

Das ist ein klassischer Workflow, der mit dem günstigsten Modell beginnt.

Support-Agent mit direktem Kundenkontakt

Verwenden Sie Sonnet.

• Erfordert Tool-Nutzung
• Erfordert Kontrolle über den Ton
• Erfordert die Anwendung von Richtlinien
• Erfordert eine reibungslose Eskalation

Verwenden Sie Haiku nur zur Vorverarbeitung. Verwenden Sie Opus zur übergeordneten Prüfung von Fällen mit hohem Risiko.

Assistent für Code-Reviews

Verwenden Sie Sonnet für gewöhnliche PR-Reviews. Verwenden Sie Opus für Änderungen mit Auswirkungen auf die Architektur, Nebenläufigkeit, Sicherheit, Datenmigrationen und anspruchsvolle Prüfungen auf Korrektheit.

Ein häufiger Fehler ist, standardmäßig das gesamte Repository als Eingabe zu übergeben. Beginnen Sie mit dem Diff, dem Abhängigkeitsgraphen und den unmittelbar zugehörigen Dateien. Eskalieren Sie nur dann an Fable oder ein anderes Modell mit langem Kontext, wenn sich die Änderung über viele Bereiche erstreckt.

Vergleich langer Verträge oder Richtlinien

Verwenden Sie Retrieval zusammen mit Sonnet für eng umrissene Fragen. Verwenden Sie Fable 5, wenn die Frage übergreifend ist, etwa: „Finde alle Widersprüche zwischen diesen Dokumenten.“

Wenn die Ausgabe eine tatsächliche rechtliche oder Compliance-Entscheidung beeinflusst, verwenden Sie das Modell zur Vorbereitung der Analyse, nicht zum Treffen der Entscheidung.

Datenanreicherung in großem Umfang

Verwenden Sie ein Modell mit offenen Gewichten, wenn das Volumen hoch ist und die Aufgabe stabil bleibt.

Beispiel:

• Unternehmensnamen normalisieren
• Branchen-Tags extrahieren
• Eingehende Leads klassifizieren
• Kurze interne Zusammenfassungen erstellen

Führen Sie nächtliche Stapelverarbeitungen aus, validieren Sie Stichproben und eskalieren Sie Grenzfälle an ein gehostetes Modell.

Rechercheassistent für große Archive

Verwenden Sie Gemini 3, GPT-5.5, Opus oder Fable, je nach Kontextlänge und Anforderungen an das Schlussfolgern. Ich würde hier nicht mit dem günstigsten Modell beginnen, es sei denn, die Anfrage ist offensichtlich einfach. Recherchefehler bleiben oft unbemerkt: Das Modell liefert eine plausible Antwort, übersieht dabei aber das entscheidende Dokument.

Budgetplanung ohne Selbsttäuschung

Am leichtesten überschreiten Sie Ihr Budget, wenn Sie die Kosten pro Aufruf optimieren und dabei Wiederholungsversuche, menschliche Korrekturen und fehlgeschlagene Workflows ignorieren.

Erfassen Sie diese Kennzahlen nach Aufgabentyp und Modell:

• Eingabetokens
• Ausgabe-Token
• Latenz p50/p95
• Rate fehlgeschlagener Validierungen
• Eskalationsrate
• Rate menschlicher Übersteuerungen
• Rate der Wiederholungsversuche durch Nutzer
• Kosten pro erfolgreich abgeschlossener Aufgabe, nicht Kosten pro Aufruf

Der letzte Punkt ist entscheidend. Ein günstiges Modell, das drei Wiederholungsversuche erfordert und trotzdem eine manuelle Prüfung auslöst, kann teurer sein als Sonnet. Ein Opus-Aufruf, der eine fehlerhafte Migration verhindert, kann die günstigste Entscheidung der Woche sein.

Wenn Sie ein Multi-Modell-Gateway verwenden, beispielsweise den API-Zugang von AI Prime Tech zu den Modellfamilien Claude, GPT und Gemini, liegt der Hauptvorteil nicht nur in der freien Anbieterwahl. Es vereinfacht auch Routing und Messung über Modellklassen hinweg. Der schwierige Teil bleibt jedoch die Gestaltung Ihrer Aufgaben.

Praktische Empfehlungen

• Beginnen Sie mit der Art der Aufgabe: Transformation, Extraktion, Schlussfolgern, Synthese über lange Kontexte oder Datenanreicherung in Stapelverarbeitung.
• Verwenden Sie Modelle der Haiku-Klasse für günstige, schnelle und klar begrenzte Aufgaben mit mechanischer Validierung.
• Verwenden Sie Modelle der Sonnet-Klasse als Standard für Produktfunktionen, die Schlussfolgern, Tools oder Qualität im direkten Nutzerkontakt erfordern.
• Verwenden Sie Modelle der Opus-Klasse, wenn Fehler teuer sind, große Unklarheit besteht oder tiefgehendes Schlussfolgern wichtig ist.
• Verwenden Sie lange Kontexte nach dem Vorbild von Fable 5, wenn Unsicherheit beim Retrieval das Hauptproblem ist, nicht als Standardstrategie, um sämtliche Inhalte in einen Prompt zu packen.
• Verwenden Sie Modelle mit offenen Gewichten, wenn stabile Arbeitslasten, Datenschutz, Durchsatz oder Kontrolle über die Bereitstellung einen eigenen Inferenzbetrieb rechtfertigen.
• Implementieren Sie ein Routing, das mit dem günstigsten Modell beginnt und ausdrückliche Eskalationssignale verwendet: ungültige Ausgabe, schwache Belege, fehlgeschlagene Tools, Aktionen mit hohem Risiko und Unsicherheit.
• Messen Sie die Kosten pro erfolgreich abgeschlossener Aufgabe, nicht pro Token oder Aufruf.
• Halten Sie Router so einfach, dass sie sich auch unter Druck debuggen lassen.
• Betrachten Sie die Modellwahl als technische Stellschraube, nicht als einmalige Anbieterentscheidung.