Model­lwahl als Engineering-Entscheidung: Haiku, Sonnet, Opus

Warum „welches Modell ist das beste“ die falsche Frage ist, und wie ihr die richtige beantwortet.

Die Frage kommt in jedem Projekt, meistens in der zweiten Woche: „Welches Modell nehmen wir?“ Und die Antwort, die man online findet, ist immer dieselbe Tabelle mit Benchmark-Werten, aus der man ableiten soll, dass das größte Modell das beste ist.

Das ist ungefähr so hilfreich wie ein CPU-Benchmark für die Frage, welchen Server man mietet. Die richtige Frage lautet nicht, welches Sprachmodell allgemein am stärksten ist, sondern welches für euren Anwendungsfall die Anforderungen erfüllt, und was ihr dafür bezahlt. Die Modellwahl ist damit eine Engineering-Entscheidung, keine Frage des Rankings.

‍

Drei Achsen, zwei davon sind frei wählbar

Jede Modellwahl, die Entscheidung für ein konkretes Sprachmodell, bewegt sich zwischen Qualität, Latenz und Kosten. Die Modellfamilie ist entlang dieser Achsen gestaffelt: Haiku ist schnell und günstig, Opus ist stark und teuer, Sonnet liegt dazwischen. Zwischen dem kleinsten und dem größten Modell liegt in der Regel eine Größenordnung, sowohl beim Preis als auch bei der Antwortzeit.

Entscheidend ist, welche Achse in eurem Fall bindend ist. Eine Autovervollständigung, die in 200 Millisekunden antworten muss, kann kein großes Modell verwenden, egal wie gut die Ergebnisse wären. Eine nächtliche Vertragsanalyse, bei der zehn Sekunden pro Dokument niemanden stören, hat kein Latenzproblem, aber bei 50.000 Dokumenten ein Kostenproblem.

Formuliert die Anforderung deshalb als Budget, bevor ihr messt: „p95 unter zwei Sekunden, maximal X Cent pro Anfrage, mindestens 95 Prozent korrekte Extraktionen.“ Erst dann ist die Messung aussagekräftig.

‍

Warum öffentliche Benchmarks nicht weiterhelfen

Generische Benchmarks messen Fähigkeiten, die mit eurer Aufgabe wenig zu tun haben. Ein Modell, das bei Mathematikaufgaben vorne liegt, ist nicht automatisch besser darin, aus euren Lieferscheinen die richtige Positionsnummer zu ziehen.

Für viele reale Aufgaben wie strukturierte Extraktion, Klassifikation oder Zusammenfassung nach festem Schema liegen kleine und große Modelle deutlich näher beieinander, als die Benchmark-Tabellen vermuten lassen. Der Unterschied zeigt sich erst bei mehrstufigem Denken, langen Kontexten und Aufgaben mit vielen Sonderfällen.

Ihr braucht also einen eigenen Datensatz. Er muss nicht groß sein: 30 bis 50 Fälle aus echten Produktionsdaten sind aussagekräftiger als 500 ausgedachte. Wichtig ist die Zusammensetzung: Nehmt bewusst die Fälle auf, die schiefgehen. Der leere Beleg, das Dokument mit zwei Währungen, die Rechnung mit der handschriftlichen Korrektur.

‍

Das Harness

Der Aufbau ist unspektakulär, und genau das ist der Punkt: Das ist eine Testsuite, kein Forschungsprojekt.

1public sealed record TestCase(string Id, string Input, string Expected);
2
3public sealed record Measurement(
4    string Model,
5    string CaseId,
6    bool Passed,
7    int InputTokens,
8    int OutputTokens,
9    TimeSpan Latency);

‍

1var measurements = new List<Measurement>();
2
3foreach (var model in _options.CandidateModels)
4foreach (var testCase in testCases)
5foreach (var run in Enumerable.Range(0, _options.RunsPerCase))
6{
7    var sw = Stopwatch.StartNew();
8    var response = await _llm.CompleteAsync(model, prompt, testCase.Input, ct);
9    sw.Stop();
10
11    measurements.Add(new Measurement(
12        Model:        model,
13        CaseId:       testCase.Id,
14        Passed:       _grader.Evaluate(testCase, response.Text),
15        InputTokens:  response.Usage.InputTokens,
16        OutputTokens: response.Usage.OutputTokens,
17        Latency:      sw.Elapsed));
18}

‍

Drei Details, die den Unterschied machen:

RunsPerCase ist nicht optional. Modelle antworten nicht deterministisch. Wer jeden Fall einmal laufen lässt, misst Rauschen. Drei bis fünf Durchläufe zeigen, ob ein Modell stabil richtig liegt oder nur manchmal Glück hat. Diese Streuung ist oft das eigentliche Auswahlkriterium.

Messt p95, nicht den Durchschnitt. Der Mittelwert versteckt genau die Ausreißer, über die sich später eure Nutzer beschweren.

Der _grader ist der schwierige Teil. Bei strukturierter Extraktion ist er ein Feldvergleich und damit trivial. Bei Freitext braucht ihr entweder Regelprüfungen oder ein zweites Modell als Bewerter. Das gehört in einen eigenen Artikel und ist der Grund, warum ihr mit Aufgaben anfangen solltet, die sich hart prüfen lassen.

‍

Routing statt Einheitsmodell

Die Messung endet selten mit einem Gewinner. Häufiger stellt sich heraus: Das kleine Modell schafft 85 Prozent der Fälle einwandfrei, und die restlichen 15 Prozent sind erkennbar.

Dann ist Eskalation die günstigere Architektur:

1var draft = await _llm.CompleteAsync(Models.Fast, request, ct);
2
3if (draft.Confidence >= _options.EscalationThreshold)
4    return draft;
5
6_metrics.Escalations.Add(1);
7return await _llm.CompleteAsync(Models.Strong, request, ct);

‍

Die Zeile, auf die es ankommt, ist die Metrik. Die Eskalationsrate entscheidet, ob sich Routing rechnet. Bei 15 Prozent spart ihr erheblich. Bei 60 Prozent zahlt ihr in der Mehrzahl der Fälle zweimal und habt zusätzlich die Latenz beider Aufrufe. Ohne diese Messung ist Routing eine Vermutung.

‍

Beim Wechsel wird der Prompt nachjustiert

Ein häufiger Fehlschluss: Man optimiert den Prompt gegen das große Modell, tauscht dann für die Produktion den Modellnamen und stellt fest, dass die Qualität einbricht.

Kleinere Modelle brauchen explizitere Anweisungen, engere Formatvorgaben und mehr Beispiele. Ein Prompt, der beim großen Modell mit einer Andeutung auskommt, muss beim kleinen ausformuliert werden. Der Modellwechsel ist also kein Konfigurationswechsel, sondern eine Änderung mit eigenem Test.

Trotzdem gehört der Modellname in die Konfiguration, nicht in den Code: IOptions statt Konstante. Dann ist der Wechsel für einen Test wenigstens kein Deployment.

‍

Fazit

Die Standardempfehlung lautet meistens: Fangt mit dem größten Modell an und optimiert später nach unten. Das „Später“ kommt in der Praxis selten.

Die bessere Reihenfolge: Behandelt die Modellwahl als Engineering-Entscheidung. Messt zuerst mit dem kleinsten Modell und geht nur dorthin hoch, wo die Messung es verlangt. Der Aufwand für das Harness liegt bei ein bis zwei Tagen und rechnet sich bei relevantem Volumen bereits im ersten Monat.