Der meiste LLM-Traffic in Produktion ist nicht schwer. Es ist Klassifikation, Extraktion, kurze Umformulierungen und Routing, die Art von Arbeit, die ein kleines, schnelles Modell korrekt und günstig erledigt. Trotzdem ist das übliche Muster, jeden Aufruf an das größte verfügbare Modell zu verdrahten, weil es "einfach funktioniert", und sich dann zu wundern, warum Rechnung und Latenz beide hoch sind. Auf Amazon Bedrock stehen sowohl Claude Haiku 4.5 als auch Claude Opus 4.5 zur Verfügung, und der Engineering-Gewinn liegt nicht darin, eines auszuwählen, sondern nach Aufgabenklasse zu routen, sodass das günstige Modell die Mehrheit übernimmt und das teure ein Eskalationspfad ist, kein Standard.

Die Umdeutung: Modellwahl ist eine Entscheidung pro Aufgabe, nicht projektweit. Jede Anfrage auf die schwerste Anfrage zu dimensionieren, ist derselbe Fehler wie jede Workload auf dem größten Instance-Typ laufen zu lassen. Right-Sizing heißt, das Modell an die Schwierigkeit des jeweiligen Aufrufs anzupassen, und für einen großen Anteil der Aufrufe ist die richtige Größe klein.

Warum das große Modell der falsche Standard ist

Standardmäßig auf das Frontier-Modell zu setzen, fühlt sich sicher an und ist in zwei Dimensionen teuer. Modelle der Opus-Klasse kosten pro Token ein Vielfaches von Modellen der Haiku-Klasse, sodass eine Workload, die zu 90 Prozent mechanisch ist, Frontier-Preise für Arbeit zahlt, die ein kleines Modell perfekt erledigt. Sie sind auch langsamer, weil fähigere Modelle in der Regel länger zum Antworten brauchen, sodass man ausgerechnet bei den hochvolumigen, einfachen Aufrufen die Latenz aufbläht, bei denen Nutzer Geschwindigkeit am meisten bemerken.

Die versteckten Kosten sind, dass ein großes Modell bei einer einfachen Aufgabe selten ein besseres Ergebnis liefert. Ein Datum aus einer E-Mail zu extrahieren oder ein Ticket in einen von sechs Buckets zu klassifizieren wird nicht besser, wenn man mehr Fähigkeit hineinwirft. Man zahlt mehr und wartet länger auf eine Antwort, die ein kleineres Modell auch richtig hinbekommen hätte.

Nach Aufgabenklasse routen

Das Design, das funktioniert, ist, die Anfrage nach Schwierigkeit zu klassifizieren und sie an das passende Modell zu schicken. Nicht pro Nutzer, nicht pro Feature, pro Aufgabenklasse:

  • Mechanische Arbeit geht an Haiku. Klassifikation, Extraktion, Formatkonvertierung, kurze Zusammenfassungen, Tool-Argument-Konstruktion und Routing-Entscheidungen. Hohes Volumen, geringe Mehrdeutigkeit, und ein kleines Modell ist sowohl günstiger als auch schneller, ohne Qualitätsverlust.
  • Urteilsarbeit geht an Opus. Mehrstufiges Reasoning, mehrdeutige Anweisungen, Long-Context-Synthese und alles, wo eine falsche Antwort teuer ist. Geringeres Volumen, und die Prämie lohnt sich, weil die Fähigkeit das Ergebnis tatsächlich verändert.
  • Der Router selbst ist günstig. Eine Heuristik auf Eingabelänge und Aufgabentyp, oder ein einzelner Aufruf eines kleinen Modells, entscheidet die Klasse. Die Routing-Kosten sind ein Rundungsfehler gegenüber dem, was man spart, indem man nicht alles standardmäßig an die Spitze schickt.

Großes Modell als Eskalationspfad

Das zuverlässigste Muster ist, das Frontier-Modell zur Eskalation zu machen, nicht zur Eingangstür. Zuerst das kleine Modell versuchen. Gelingt es, und bei der mechanischen Mehrheit gelingt es, ist man fertig, zu einem Bruchteil der Kosten und Latenz. Scheitert es an einer Prüfung, niedrige Konfidenz, ein schema-ungültiger Output, ein explizites "ich bin mir nicht sicher", diese eine Anfrage an das größere Modell eskalieren.

result = invoke(HAIKU, task)
if not passes_check(result):
    result = invoke(OPUS, task)   # escalate only the hard cases
return result

Das dreht die Ökonomie um. Statt Opus-Preise auf jeder Anfrage zu zahlen, um den seltenen schweren Fall abzudecken, zahlt man Haiku-Preise beim häufigen Fall und greift nur dann zu Opus, wenn der günstige Versuch sichtbar zu kurz kam. Der Tausch ist ein zusätzlicher Aufruf bei der Minderheit der Anfragen, die ihn braucht, gegen eine große Ersparnis bei der Mehrheit, die es nicht tut.

Messen, bevor man den Split annimmt

Der Punkt, an dem Teams danebenliegen, ist, den Aufgaben-Mix zu raten, statt ihn zu messen. Vor dem Routing echten Traffic samplen und labeln, wie viel davon wirklich mechanisch versus wirklich schwer ist. Die Zahl ist fast immer mechanischer, als das Team erwartet, was genau der Grund ist, warum der Standard auf das große Modell so viel verschwendet. Sie zeigt auch, wo man den Eskalations-Trigger setzen sollte: Erledigt das kleine Modell 92 Prozent des Traffics sauber, sollte die Eskalationsrate nahe 8 Prozent liegen, und eine deutlich höhere Rate bedeutet, dass die Prüfung zu streng oder das Routing schlecht kalibriert ist.

Fazit

Sowohl Haiku als auch Opus sind seit Monaten auf Bedrock verfügbar, und der Punkt ist nicht, zwischen ihnen zu wählen, sondern jedes dort einzusetzen, wo es passt. Nach Aufgabenklasse routen: die mechanische Mehrheit an das kleine, schnelle Modell schicken und das Frontier-Modell für die urteilslastige Minderheit reservieren, idealerweise als Eskalationspfad, ausgelöst durch eine fehlgeschlagene Prüfung statt durch einen Standard. Den tatsächlichen Aufgaben-Mix messen, bevor man den Split justiert. Model Right-Sizing ist dieselbe Disziplin wie Instance Right-Sizing, und das schnellste, günstigste System ist das, das aufhört, Frontier-Preise für Arbeit zu zahlen, die ein kleines Modell korrekt erledigt.

Weiterlesen

Für die Plattformseite von Routing und Kapazität über Modelle hinweg gibt es die Cloud-Field-Notes auf ercan.cloud, und den Hub auf ercanermis.com.