Alle Notizen
31. Mai 202612 Min. Lesedauerai-agentsmodel-routingfoundrybedrockorchestrationengineering

Schicke nicht jeden Schritt durch ein Frontier LLM

Schicke nicht jeden Schritt durch ein Frontier LLM

Die meisten Teams, die 2025 KI-Agents in Produktion gebracht haben, schickten jeden einzelnen Schritt, jeden Tool-Aufruf, jede winzige Klassifikation durch das größte Modell, das sie sich leisten konnten. Das funktionierte, solange es drei Modelle gab und die Preisspanne zwischen ihnen wie ein Rundungsfehler aussah. 2026 sind es zwei Größenordnungen, die kleinen Modelle können tatsächlich denken, und die Monatsrechnung ist das Erste, was dein CFO liest.

Die Position, die ich hier verteidige, ist in Vendor-Decks unmodern und genau die Art, wie unsere Pipelines still umgeschrieben werden. Ein Planner-LLM plus eine Flotte aus 4B- bis 8B-Specialists schlägt ein Frontier-Modell pro Schritt bei Kosten, Latenz und Steuerbarkeit, in jedem Workload oberhalb einer Routing-Accuracy-Schwelle. Das Muster ist kein Microsoft- oder NVIDIA-Talking-Point mehr. Microsoft Foundry, AWS Bedrock, Anthropic, OpenRouter und die akademischen Vorläufer sind innerhalb von 18 Monaten alle darauf konvergiert. Schwer ist nicht mehr die Wahl des Musters. Schwer ist, die Routing-Accuracy-Schwelle zu treffen, an der die Mathematik wirklich aufgeht.

Kernpunkte

  • Specialist-Orchestrierung ist mittlerweile vendor-übergreifend konvergent: Foundry, Bedrock, Anthropic, OpenRouter liefern alle Varianten von Planner-plus-Workers.
  • Ein Planner-LLM, das Tool-Aufrufe an einen 4B-Specialist delegiert, kostet Cent-Beträge, wo ein einzelner Frontier-Call Dollar kostet, solange die Routing-Accuracy hält.
  • Unterhalb von etwa 0,85 Routing-Accuracy verschwinden die Einsparungen; du zahlst das kleine Modell und danach trotzdem das Frontier-Modell.
  • Nemotron Nano 4B, Haiku 4.5, Mistral Small und Phi-4 sind heute eigens für Tool Use trainiert, kein generischer Chat in klein.
  • Der Engpass ist nicht mehr Modellqualität, sondern Eval-Abdeckung des Routers, und die wenigsten Teams haben das budgetiert.

In diesem Artikel

Die Ökonomie, die das Ein-Frontier-pro-Schritt-Muster gebrochen hat

Ein Frontier-Modell auf jedem Schritt ist eine Gewohnheit, keine Architektur. Es ist das, was wir alle verkabelt haben, weil Sonnet billig war, Opus besonders, und die Latenz tolerierbar, solange der Agent nur drei Calls pro Aufgabe machte. Keine dieser Bedingungen gilt in einem 2026-Produktions-Agent. Eine echte Agentenschleife feuert heute 30 bis 80 Modell-Calls pro Aufgabe: Mail lesen, Intent klassifizieren, Tool wählen, JSON-Argument formatieren, Antwort parsen, zusammenfassen, nächsten Schritt entscheiden, wiederholen. Die meisten dieser Calls sind kein Reasoning. Es sind Routing-Entscheidungen, Formatkonvertierungen und kleine Klassifikationen, die ein 8B-Modell auf Augenhöhe erledigt.

Die aktuelle Preisspanne sagt alles. Claude Haiku 4.5 listet bei 1 USD Input / 5 USD Output pro Million Tokens; Sonnet 4.6 bei 3 / 15; Opus 4.7 bei 5 / 25, laut BenchLMs Preis-Aufstellung vom April 2026. Llama 3.3 70B auf Groq listet bei 0,59 / 0,79 laut Groq-Preisseite. DeepSeek V3.2 liegt noch eine Größenordnung darunter, laut AI Pricing Guru 2026 Vergleich. Ein Planner, der 80 % der Schritte an ein 1-USD-Modell routet und 20 % für das 25-USD-Modell reserviert, ist keine Kostenoptimierung. Es ist der Unterschied zwischen einem Feature, das du ausliefern kannst, und einem Feature, das deine Finanzleitung im Quartals-Review kippt.

AWS hat dazu Produktionszahlen veröffentlicht. Das Bedrock-Team meldet aus einem ausgelieferten Deployment „average 63.6% cost savings because of a higher percentage (87%) of prompts being routed to Claude 3.5 Haiku while still maintaining the baseline accuracy with the larger / more expensive model (Sonnet 3.5 v2)", laut AWS ML-Blog. Das ist keine Vendor-Broschürenzahl aus einem hypothetischen Agent. Das ist ein 87/13-Split, bei dem der Kunde das kleine Modell bei fast jedem Schritt bezahlt hat und das große nur, wenn der Router sich nicht festlegen wollte.

Anthropics eigene Feldtests berichten eine konservativere, aber aussagekräftigere Zahl: „using Opus as an advisor with Sonnet or Haiku as executors achieves an 11% cost reduction and a 2% improvement on benchmark scores", laut Schreibe zum Advisor-Muster mit Anthropic-Zitat. Kosten runter, Qualität rauf. Das ist die Form einer Architektur, die relativ zu ihrer Wirkung falsch bepreist ist, was genau der Zustand ist, der eine marktweite Migration produziert.

Was ein Specialist 2026 wirklich ist

„Specialist" heißt nicht mehr „kleines, auf deine Domäne feingetuntes Modell". 2024 war das die einzige Bedeutung, weil die offenen kleinen Modelle generischer Chat in klein waren. 2026 gibt es eine Klasse von 4B- bis 8B-Modellen, die von Grund auf für Tool Use, strukturierten Output und Reasoning-Traces trainiert wurden, nicht als verkleinerter Assistent.

NVIDIAs Nemotron Nano 4B ist das sauberste Beispiel. Ein hybrider Mamba-Transformer, trainiert für „agentic reasoning" mit BFCL V4, TerminalBench und SWE-Bench als Headline-Evals laut Nemotron-3-Nano-Paper. Die Tool-Use-Linie geht zurück auf eine dedizierte RL-Linie, beschrieben in Nemotron-Research-Tool-N1: Exploring Tool-Using Language Models with Reinforced Reasoning. Die Model Card zielt auf Jetson Thor, GeForce RTX und DGX Spark als Edge-Plattformen, was dir sagt, wofür NVIDIA es vorsieht. Du betreibst es dort, wo die Daten liegen, nicht dort, wo das Audit-Log liegt.

Anthropic positioniert Haiku 4.5 als Executor-Stufe im Advisor-Muster: Opus plant, Haiku arbeitet. Mistral hat dasselbe mit Mistral Small gemacht. Microsoft hat seine Phi-Familie. Der Punkt ist keine Vendor-Treue. Der Punkt ist, dass die unterste Sprosse der Modellleiter kein generisches Chat-Modell mehr ist, das nützlich tut. Es ist ein Arbeitstier mit einem Tool-Calling-Kopf und einem Reasoning-Trace, für dessen Produktion es tatsächlich belohnt wurde.

Was du am Montag tust: Öffne dein Usage-Dashboard, sortiere die Agentenaufrufe nach Kosten pro Call, identifiziere das Cluster „JSON formatieren", „Intent klassifizieren" oder „diese drei Felder extrahieren", und ersetze diese Calls durch Haiku 4.5 oder ein gehostetes kleines Modell hinter einem dünnen Adapter. Nicht architektieren, einfach die billigsten 30 % der Calls eine Stufe runter ziehen. Die Einsparung zeigt sich im nächsten Abrechnungszyklus und belegt den Rest der Migration vor demjenigen, der den Scheck unterschreibt.

Die BRKSP94-Session als Muster, nicht als Produkt

Die Microsoft-Build-2026-Session BRKSP94, Orchestrate special agents with NVIDIA Nemotron models on Foundry auf dem MicrosoftDeveloper-YouTube-Channel, lohnt das erneute Ansehen, weil sie das Orchestrator-and-Workers-Muster in produktionsförmiger Infrastruktur zeigt, nicht in einem Forschungs-Notebook. Setup: ein Hermes-Agent-Harness auf Microsoft-Foundry-Hosted-Agents, Nemotron Super für schweres Reasoning, Nemotron Nano für latenzsensitive Tool-Calls, und die Foundry-Managed-Toolbox vermittelt Outlook, GitHub, Teams, MongoDB und Cosmos DB über eine einzige Berechtigungsoberfläche.

Demo-Aufgabe war ein Vier-Personen-Produkt-Launch mit zwei Wochen Deadline. Ein Senior-Lead delegierte eine Feature-Request-Mail an den Agent. Der Agent las den Posteingang, öffnete das richtige Repo, machte die Code-Änderung und öffnete einen PR. Der Lead korrigierte den PR (Reviewer ergänzen, Docstrings ergänzen), und die Korrektur wurde via interner skill_manage-Funktion als wiederverwendbarer Skill persistiert, den andere Teammitglieder dann erbten. Nichts davon ist als Idee neu. Das Microsoft-Research-Paper Magentic-One: A Generalist Multi-Agent System for Solving Complex Tasks hat dasselbe Orchestrator-WebSurfer-FileSurfer-Coder-Muster 18 Monate früher geliefert. Neu ist, dass das Planner-plus-Specialist-Arrangement heute hinter Enterprise-Identität (Entra ID), Enterprise-Audit-Traces und einem einzigen Tool-Gateway lebt. Genau das fehlte 2024 und entschied, ob die Architektur die Demo-Bühne verließ.

Vendor-übergreifend: AWS Bedrock liefert Intelligent Prompt Routing, wo du „configure your own router by selecting any two models from the same model family" kannst, mit „no additional charge for the routing feature itself". Microsoft Foundry liefert Model-Router-Konzepte mit Modell-Subset-Auswahl, sodass du den Choice-Set des Routers deckelst. Anthropics Advisor-Muster ist dieselbe Idee, ausformuliert als System-Prompt-Konvention. Drei Vendor-Akzente, eine architektonische Entscheidung.

💡 Der Vortrag ist ein Zitat. Das Muster ist der Zitatgraph. Wenn drei Hyperscaler und das akademische Paper innerhalb von 18 Monaten dieselbe Form gewählt haben, ist die Frage nicht, ob du adoptierst. Die Frage ist, auf welcher Routing-Accuracy-Schwelle dein Workload sitzt.

Eine minimale Router-Config-Skizze, in Pseudo-Foundry-YAML, damit du sie ohne Kontext lesen kannst. Das ist die Form, kein Copy-Paste; die Feldnamen liegen in den Foundry-Agent-Service-Übersichtsdocs:

router:
  planner:
    model: gpt-4.1
    role: "Decide which worker handles this step. Output JSON {worker, args}."
  workers:
    - name: classify_intent
      model: claude-haiku-4-5
      ceiling_tokens: 200
    - name: format_tool_call
      model: nemotron-nano-4b
      ceiling_tokens: 400
    - name: hard_reasoning
      model: claude-sonnet-4-6
      ceiling_tokens: 4000
  fallback:
    when: router_confidence < 0.85
    model: claude-sonnet-4-6

Was du am Montag tust: Füge in deinen bestehenden LangGraph- oder Bedrock-Agent einen einzelnen Klassifikator-Knoten vor dem Modell-Call ein. Lass ihn {worker, confidence} ausgeben. Fällt die Confidence unter 0,85, falle auf das Frontier-Modell durch und logge den Fallback. Nach einer Woche Logs hast du eine echte Verteilung, mit der du argumentieren kannst.

Wo diese These verliert

Hier meine Lesart. Diesen Absatz lassen die Vendor-Decks weg. Die ganze Architektur steht und fällt damit, dass der Router recht hat. Liegt der Router falsch, zahlst du das kleine Modell, bekommst eine schlechte Antwort, versuchst es auf dem Frontier-Modell erneut und zahlst beides. Die Mathematik kippt. Das Paper Evaluating Small Language Models for Front-Door Routing grenzt das direkt ein: „the accuracy prerequisite (>= 0.85) is not yet met for small language models, bounding the gap at 6 to 8 percentage points". Bis dein Router die 0,85-Schwelle konsistent trifft, kostet Specialist-Orchestrierung mehr, als bei jedem Schritt Sonnet aufzurufen, weil jeder Routing-Fehler ein doppelt abgerechneter Retry plus die Latenz zweier Round-Trips ist.

Drei ehrliche Failure-Modes, die genannt gehören. Erstens, Long-Context-Aufgaben: Wenn der Prompt 40k Tokens Kontext umfasst und die Antwort auf einer Synthese beruht, die das 4B-Modell nicht halten kann, gibt der Planner auf, und du bist sowieso wieder beim Frontier-Modell. Specialist-Orchestrierung verliert hier still gegen den Monolithen. Zweitens, Eval-Explosion: Der Router selbst wird zu einer neuen Komponente, die du evaluieren, versionieren und regressionstesten musst. Die meisten Teams haben kein Router-Eval-Set, sie haben ein Modell-Eval-Set. Beide sind nicht dasselbe, und im Spalt driftet die Produktions-Accuracy stillschweigend. Drittens, Debugging: Wenn eine Multi-Worker-Kette eine schlechte Antwort produziert, musst du den Fehler über drei oder vier Modellgrenzen mit unterschiedlichen Temperaturen und Prompts lokalisieren. Die Observability-Traces, die Foundry und Bedrock liefern, helfen wirklich, aber die kognitive Last für den Engineer steigt, nicht sinkt.

Sitzt dein Workload unter der 0,85-Schwelle, ist meine ehrliche Lesart: Bleib beim Monolithen, bis dein Router-Eval-Set real ist. Specialist-Orchestrierung auf einem schlechten Router ist schlechter als gar keine Orchestrierung. Genau deshalb argumentiert der Schwesterpost Modelle altern, Eval-Suiten kumulieren, dass das Eval-Set das Asset ist; das Router-Eval-Set ist eine neue Zeile in diesem Hauptbuch. Das Router-Eval ist die Kostenposition, die die meisten Kostenspar-Posts vergessen abzuziehen.

Das KMU-Rollout-Muster für eine 90-Personen-Firma

Specialist-Orchestrierung ist eine mittelstandstaugliche Architektur, nicht nur eine für Hyperscaler. Stell dir den Daten- und KI-Lead einer 90-Personen-Logistikfirma in Hamburg vor, die Microsoft 365 im Büro betreibt, einen kleinen Azure-Tenant für Analytics und ein einziges KI-Feature-Projekt auf der Roadmap: einen Inbox-Triage-Agent, der eingehende Versandbenachrichtigungen klassifiziert und entweder automatisch bestätigt, für den Disponenten flaggt oder an einen Menschen eskaliert. Heute läuft der Agent komplett auf Sonnet 4.6, weil das Team ein Tutorial kopiert hat. Ausgaben rund 800 EUR pro Monat bei einem Workload von 4000 Mails pro Woche. Für einen Pilot okay. Für eine Roadmap, die dieses Jahr zwei weitere Agents liefern will, schlecht.

Der Montagsplan: Sonnet bleibt als Planner und Eskalations-Handler. Den Klassifikationsschritt (Label aus 12 Sendungstypen wählen) und den JSON-Formatierungsschritt (Disponentenzeile schreiben) auf Haiku 4.5 verschieben. Einen Router-Knoten ergänzen, der Sonnet bei Confidence < 0,85 feuert. Das Ganze in einen Logic-Apps-Connector für den bestehenden Outlook-Flow verdrahten, weil das die einzige Infrastruktur ist, die die IT bereits besitzt und akzeptiert. Jede Routing-Entscheidung vier Wochen lang in eine einzelne SQL-Tabelle loggen. Am Monatsende drei Zahlen berechnen: Anteil der Schritte, die zu Haiku gingen, Anteil der Routing-Fallbacks, Gesamtausgaben. Erwartetes Ergebnis auf Basis der oben zitierten Evidenz: 40 bis 60 % Kostenreduktion, keine messbare Genauigkeitseinbuße beim Klassifikationsschritt, und eine Routing-Fallback-Quote, die dem Lead sagt, ob Agent #2 und #3 dasselbe Muster fahren können oder ob der Router zuerst Nacharbeit braucht.

Die Rolle, die mich hier interessiert, ist nicht der KI-Lead. Es ist der Disponent. Wird sein Arbeitstag ruhiger, ohne dass auffällige Fehler bei Kunden landen, hat die Architektur ihren Platz verdient. Landen merkwürdige Routing-Entscheidungen in seiner Queue, zeigt die Fallback-Quote das schon in den Logs, und die Planner-Decke ist der direkte Stellhebel. Der Schwesterpost Copilot Studio Workflows ist das deterministische Rückgrat, das LLM-Agents brauchten liefert den komplementären Punkt: Ein deterministischer Workflow hält die Steuerflusslogik, und im Inneren jedes Blatts wählst du das Modell. Specialist-Orchestrierung passiert im Blatt; das deterministische Rückgrat fängt die Fehler.

Was du am Montag tust

Fünf konkrete Schritte, alle real für ein 20- bis 200-Personen-Team in dieser Woche. Jeder paart eine Wirkungsannahme mit dem Schritt, der sie belegt oder kippt.

  1. Auditiere deine volumenstärksten Agentenschritte. Zieh die letzten 30 Tage Modell-Calls, sortiere nach Call-Anzahl, identifiziere das Cluster „Format", „Klassifizieren" oder „Extrahieren". Das sind die 30 %, die du heute eine Stufe runter ziehen kannst.
  2. Füge einen Router-Knoten ein, kein Router-System. Ein einzelner Haiku-Call, der {worker, confidence} ausgibt, reicht zum Start. Kauf keine Routing-Plattform, bevor du dein eigenes Confidence-Histogramm gelesen hast.
  3. Pinne ein Modell-Subset. Auf Foundry den Model-Router auf ein Zwei-Modell-Subset konfigurieren (Haiku + Sonnet oder Nano + Super). Auf Bedrock Intelligent Routing innerhalb einer Modellfamilie konfigurieren. Subset-Auswahl ist der einzige zuverlässige Kostendeckel.
  4. Bau das Router-Eval-Set zuerst. 200 gelabelte Routing-Entscheidungen abschnüren, bevor du ausrollst. Modell-Eval und Router-Eval sind nicht dasselbe Artefakt. Ohne Router-Eval kannst du die 0,85-Schwelle nicht verteidigen und keine Drift erkennen.
  5. Setze einen Fallback, der eskaliert, nicht verschluckt. Liegt die Router-Confidence < 0,85, ruf das Frontier-Modell auf und logge den Fallback. Calls mit niedriger Confidence still ans kleine Modell durchzureichen ist, wie eine Kostenersparnis in sechs Wochen zur Qualitätsregression wird.

Ein 60-Zeilen-LangGraph-Stub, der das Muster einfängt, lauffähig gegen das Anthropic-SDK mit zwei Modell-IDs und einem Confidence-Parser:

from langgraph.graph import StateGraph, END
import anthropic

client = anthropic.Anthropic()

def route(state):
    msg = client.messages.create(
        model="claude-haiku-4-5",
        max_tokens=200,
        system="Pick worker in {classify, format, hard}. Output JSON.",
        messages=[{"role": "user", "content": state["input"]}],
    )
    decision = parse_decision(msg.content[0].text)
    state["worker"] = decision["worker"]
    state["confidence"] = decision["confidence"]
    return state

def worker(state):
    model = "claude-sonnet-4-6" if state["confidence"] < 0.85 else "claude-haiku-4-5"
    if state["worker"] == "hard":
        model = "claude-sonnet-4-6"
    msg = client.messages.create(model=model, max_tokens=2000,
        messages=[{"role": "user", "content": state["input"]}])
    state["output"] = msg.content[0].text
    state["model_used"] = model
    return state

g = StateGraph(dict)
g.add_node("route", route)
g.add_node("work", worker)
g.set_entry_point("route")
g.add_edge("route", "work")
g.add_edge("work", END)
agent = g.compile()

Das ist kein fertiges System. Es ist das Kleinste, das die Daten emittiert, die du brauchst, um die Architektur in deinem Kontext zu verteidigen oder zu kippen. Die harte Arbeit ist das gelabelte Router-Eval-Set, das du parallel baust.

Offene Fragen und Kontakt

Ich beobachte weiter drei Dinge und erwarte, diesen Post innerhalb von sechs Monaten zu aktualisieren. Erstens, ob die 0,85-Routing-Accuracy-Schwelle sich bewegt. Der Front-Door-Routing-Benchmark ist eine 2025er-Zahl auf einem spezifischen Eval; ein 2026er-Retraining auf Tool-Call-Traces könnte die Schwelle auf 0,75 drücken und die Mathematik für marginale Workloads ändern. Zweitens, ob die Nemotron-auf-Foundry-Preise pro Token tatsächlich günstiger landen als Haiku bei vergleichbaren Aufgaben. Ich habe noch keine saubere Primärquelle zu den Nemotron-Line-Items auf Foundry gesehen und will die Zahl nicht raten; landet der Preis pro Call über Haiku, behält das Specialist-Muster den Latenzvorteil, verliert aber den Kostenvorteil für Nicht-Edge-Workloads. Drittens, ob die Routing-Eval-Disziplin ein bezahltes Produkt wird oder ein Build-your-own-Artefakt bleibt. Liefert ein Vendor einen echten Router-Eval-Harness, beschleunigt sich die Migration für Mittelstandsteams ohne ML-Engineers im Haus. Wenn nicht, bleiben die Eval-Kosten eine versteckte Steuer auf diese Architektur, und die Einsparungsprognosen in jedem Vendor-Deck brauchen eine Fußnote.

Sitzt du auf einer mittleren vierstelligen Euro-Sonnet-Rechnung pro Monat und entscheidest, ob du auf eine Planner-plus-Workers-Form migrieren sollst, gleich ich gern Notizen ab. Die interessante Variable ist dein Router-Eval-Set, nicht das Modell-Lineup. Teams, die eines haben, fahren Specialist-Orchestrierung in Produktion und liefern die oben zitierten Spar-Zahlen. Teams, die keines haben, warten zu Recht. Willst du durchdenken, auf welcher Seite dieser Linie dein Workload sitzt, schick eine Nachricht über die Kontaktsektion mit einem Absatz zur aktuellen Form deines Agents und deinen aktuellen Monatsausgaben. Ich antworte mit den zwei oder drei Zahlen, die ich zuerst messen würde.