Microsoft Foundry Model Router und Model Catalog: Deep Dive

Die Auswahl eines Modells war früher eine einmalige Entscheidung: Sie wählten GPT-4o, fügten es in die Konfiguration ein und machten weiter. Im Jahr 2026 verfügt der Model Catalog in Microsoft Foundry über Hunderte von Modellen in OpenAI, Anthropic, xAI, DeepSeek, Meta und Mistral – und die ehrliche Antwort auf „Welches Modell?“ ist normalerweise „es hängt vom Prompt ab“. Genau dieses Problem löst der Model Router. In diesem Blogbeitrag erkläre ich, wie der Foundry Model Router unter der Haube funktioniert, wie der Katalog heute aussieht, welche Einsatzarten es gibt und wie ich mich zwischen Router und festem Modell entscheide. Ich habe bereits eine allgemeine Stellungnahme zu KI-Modelle im Jahr 2026: Was ich eigentlich auswählen würde geschrieben – dieser Beitrag ist der Foundry-spezifische Deep Dive.

Was ist der Model Router?

Der Model Router ist ein bereitstellbares Modell in Foundry (Herausgeber Microsoft), das Prompts selbst nicht beantwortet. Es handelt sich um ein kleines, speziell entwickeltes Routing-Modell: Es analysiert jede eingehende Anfrage in Echtzeit – Komplexität, Begründungsbedarf, Aufgabentyp, Tool-Definitionen, Konversationsverlauf – und leitet die Anfrage an das am besten geeignete zugrunde liegende LLM weiter. Die Routing-Entscheidung fügt nur einen vernachlässigbaren Bruchteil der gesamten Inferenzzeit hinzu und der Router speichert Ihre Prompts nicht.

Ihre Anwendung sieht nur eine Bereitstellung:

# you call one deployment - the router picks the model per request
response = client.chat.completions.create(
    model="model-router",   # your router deployment name
    messages=[{"role": "user", "content": "Summarize this incident report."}])

print(response.model)  # tells you which model actually answered, e.g. gpt-5-mini

Das Feld model in der Antwort gibt immer an, welches Modell geantwortet hat. Melden Sie es an – es ist Ihr wichtigstes Signal, wenn Sie mit dem Router arbeiten.

Mit Stand Mitte 2026 umfasst der Routing-Pool rund 28 Modelle. Der Kern ist die OpenAI-Reihe – die GPT-5-Familie von Nano bis Full, die Chat-Varianten und die Argumentationsmodelle der O-Serie. Darüber hinaus können Nicht-OpenAI-Modelle dem Pool beitreten: DeepSeek, Llama, Grok, gpt-oss und sogar Claude. Ein Statusdetail, das leicht falsch verstanden werden kann: Router-Unterstützung für jedes Nicht-OpenAI-Modell ist noch in der Vorschau – das GA-Versprechen deckt die OpenAI-Modelle ab.

Hinweis: Claude-Modelle sind die einzigen, die Sie zuerst separat vom Katalog bereitstellen müssen; Der Router ruft dann Ihr Claude-Bereitstellungen auf, wenn er sie auswählt. Alles andere im Pool funktioniert ohne eine dedizierte Bereitstellung. Und achten Sie auf die SKU: Ihr Claude-Bereitstellungstyp muss mit der Router-Bereitstellung übereinstimmen, sonst erhalten Sie einen InvalidResourceProperties-Fehler.

Welche Version verwende ich eigentlich?

Der Router verwendet Versionen mit Datumsstempel und der Lebenszyklus ist ungewöhnlich: Die GA-Version 2025-11-18 wird an Ort und Stelle aktualisiert. Neue zugrunde liegende Modelle und Funktionen werden im Laufe der Zeit ohne neue Versionsnummer hinzugefügt, während die älteren Versionen (2025-08-07, 2025-05-19) eingefroren werden. „Welche Modelle kann mein Router verwenden?“ ist also selbst bei einer angehefteten Version ein bewegliches Ziel – die Veröffentlichungsverlaufsseite ist das zu beobachtende Änderungsprotokoll.

Es gibt auch eine Option zur automatischen Aktualisierung zum Zeitpunkt der Bereitstellung. Praktisch, aber seien Sie sich bewusst, was es bedeutet: Wenn eine neue Router-Version auf den Markt kommt, ändern sich auch die zugrunde liegenden Modelle – und damit möglicherweise auch Ihr Qualitätsprofil und Ihre Kosten. Für die Produktion pinne ich die Version und steuere den Modellsatz explizit über einen Teilsatz (nächster Abschnitt).

Wie steuere ich das Routing?

Drei Knöpfe sind wichtig, alle auf die Bereitstellung eingestellt:

1. Routing-Modus – der Kompromiss zwischen Kosten und Qualität

• Ausgewogen (Standard): berücksichtigt alle Modelle innerhalb eines kleinen Qualitätsbands (ungefähr 1 bis 2 Prozent des besten Modells für diesen Prompt) und wählt das kostengünstigste Modell aus.
• Kosten: erweitert das Qualitätsband auf etwa 5 bis 6 Prozent und optimiert den Preis stärker. Für hochvolumige, budgetkritische Arbeitslasten.
• Qualität: immer das hochwertigste Modell, Kosten außer Acht gelassen.

2. Modellteilmenge – das Compliance-Gate

Sie können das Routing auf eine explizite Einschlussliste von Modellen beschränken. Dies löst drei echte Probleme. Erstens, Governance: Neu hinzugefügte Basismodelle werden nicht einbezogen, bis Sie sie explizit hinzufügen, sodass der Router nicht stillschweigend mit der Verwendung eines Modells beginnen kann, das Ihr Datenschutzbeauftragter nie gesehen hat. Zweitens, Kontext: Das effektive Kontextfenster einer Router-Bereitstellung ist das kleinste Fenster im Pool – mit einer Teilmenge erhöhen Sie diese Untergrenze. Drittens: Wenn Ihre Organisation Modellbereitstellungen mit Azure Policy regelt, gilt dieselbe integrierte Richtlinie für die Teilmenge des Routers und wird über Portal, REST, CLI und ARM durchgesetzt.

3. Automatisches Failover

Der Router verfügt über ein integriertes Failover: Wenn beim ausgewählten Modell ein vorübergehendes Problem auftritt, wird die Anfrage transparent an das nächstgeeignete Modell umgeleitet. Bei einer Standardbereitstellung ist dies standardmäßig aktiviert, es ist keine Konfiguration erforderlich. Sie erhalten Multi-Modell-Ausfallsicherheit, ohne eine einzige Wiederholungszeile schreiben zu müssen.

Hinweis: Subset und Failover sind gekoppelt. Ihr Modell-Subset ist Ihr Fallback-Set – Failover verlässt es nie, was genau das ist, was Sie für die Compliance wünschen. Das bedeutet aber auch: Eine Teilmenge mit nur einem Modell hat überhaupt kein Failover. Fügen Sie immer mindestens zwei Modelle in eine Teilmenge ein.

Was kostet der Router?

Die Abrechnung ist die Summe der Token-Preise der zugrunde liegenden Modelle – Sie zahlen gpt-5-nano-Preise, wenn der Router gpt-5-nano ausgewählt hat – zuzüglich eines Router-Aufschlags, der auf Eingabe-Tokens berechnet wird (der genaue Preis finden Sie auf der Azure-Preisseite). Ob der Router Geld spart, hängt ganz von Ihrem Traffic-Mix ab: Wenn die meisten Prompts einfach sind und Sie Grenzpreise dafür zahlen würden, sind die Einsparungen dramatisch. Wenn Ihr Traffic gleichmäßig hoch ist, ist ein festes Modell ohne Aufschlag günstiger. Messen Sie es – Microsoft liefert für genau diesen Vergleich sogar ein auto Evaluation-Toolkit aus.

Noch zwei kostenrelevante Details. Prompt-Caching wird an zugrunde liegende Modelle weitergeleitet, die es unterstützen, aber ein Cache-Treffer erfordert aufeinanderfolgende Anfragen an das gleiche zugrunde liegende Modell – mit dynamischem Routing, das nicht garantiert ist, also planen Sie nicht mit zwischengespeicherten Preisen. Und der Router verfügt über ein eigenes Kontingent, das mit der Abonnementstufe Ihres Abonnements skaliert: von 1.000 Anfragen und 1 Million Token pro Minute auf Stufe 1 bis zu 15.000 Anfragen und 15 Millionen Token pro Minute auf Stufe 6 für Global Standard (Datenzonengrenzen sind niedriger).

Was steht eigentlich im Model Catalog?

Der Katalog besteht aus zwei Kategorien, und der Unterschied ist vertraglicher und nicht technischer Natur:

• Direkt von Azure verkaufte Modelle: von Azure gehostet und betrieben, Abrechnung über Ihr Azure-Abonnement, abgedeckt durch Azure SLAs. Dazu gehören alle Azure OpenAI-Modelle sowie ausgewählte Modelle von xAI (Grok), DeepSeek, Meta, Mistral, Cohere, Black Forest Labs und Microsofts eigener Phi-Familie.
• Modelle von Partnern und Community: werden zu den Bedingungen des Anbieters über Azure Marketplace angeboten. Anthropic lebt hier – mit einer Wendung: Claude-Modelle gibt es in zwei Hosting-Varianten: „Hosted on Azure“ (läuft durchgängig auf der Azure-Infrastruktur) und „Hosted on Anthropic Infrastructure“. Claude wird auch anders abgerechnet, und zwar über Claude-Verbrauchseinheiten über einen einzigen Marketplace-Zähler.

Hinweis: Claude in Foundry wird nicht über die OpenAI-kompatible API aufgerufen, sondern über die native Anthropic Messages API auf Ihrem Foundry-Endpunkt (/anthropic/v1/messages). Planen Sie das in Ihren Kundencode ein – das Payload-Format ist anders.

Für den Vergleich von Modellen vor dem Commit verfügt das Portal über Modell-Bestenlisten (noch Vorschau): Qualitätsindex, Sicherheit, Leistung und – seit der Überarbeitung – gemessene Kosten pro Benchmark-Lauf in Dollar statt theoretischer Token-Preis-Berechnungen. Ich verwende sie, um eine Auswahlliste zu erstellen, und bewerte die Auswahlliste dann anhand meiner eigenen Daten. Bestenlisten-Rangdurchschnitte; Ihre Arbeitsbelastung ist nicht durchschnittlich.

Welchen Bereitstellungstyp wähle ich?

Jeder Model Deployment benötigt einen Typ, und diese Auswahl entscheidet über Kosten, Latenz und Datenpfad:

Geben Sie	ein Verwenden Sie wann	Kosten, die Sie zahlen
Globaler Standard	Standard, höchstes Kontingent	In einer beliebigen Azure-Region verarbeitete Daten
Datenzone	EU- oder US-Verarbeitungsgrenze erforderlich	Etwas höherer Preis, geringere Quote
Bereitgestellt (PTU)	Vorhersehbares SLA mit hohem Volumen und Latenz	Reservierte Kapazität, bezahlt auch im Leerlauf
Charge	Offline-Massenaufträge, 24-Stunden-Bearbeitung OK	50 Prozent Rabatt, nicht interaktiv

Für EU-Kunden ist oft die Datenzonenoption der entscheidende Faktor: Die Verarbeitung erfolgt innerhalb der EU-Datengrenze (Regionen in Frankreich, Deutschland, Italien, Niederlande, Norwegen, Polen, Spanien, Schweden, Schweiz).

Hinweis: In dieser Tabelle geht es um normale Modellbereitstellungen. Der Model Router selbst unterstützt nur zwei dieser Typen: Global Standard und Data Zone Standard und wird derzeit nur in East US 2 und Sweden Central eingesetzt. Sie können den Router nicht als Provisioned (PTU) oder Batch bereitstellen. Wenn Sie PTU-Kapazität oder Batch-Preise benötigen, stellen Sie dieses Modell direkt bereit. Das Gute daran: Ein Datenzonen-Router berücksichtigt bei seinen Routing-Entscheidungen die Datenzonengrenze, sodass er nur an Modelle innerhalb der Grenze weiterleitet.

Die Funktion, die Standard und Provisioned zusammenhält, ist Spillover (GA): Wenn Ihre PTU-Bereitstellung eine 429 zurückgibt, weil die Kapazität voll ist, werden Anforderungen automatisch an eine gepaarte Standardbereitstellung in derselben Ressource weitergeleitet. PTU deckt die Grundlast zu Fixkosten ab, Spillover fängt die Spitzen zu Token-Preisen ab. Aktivieren Sie es pro Bereitstellung über die Eigenschaft spilloverDeploymentName und beobachten Sie die Aufteilung IsSpillover in Azure Monitor, um die richtige Größe Ihrer PTUs zu ermitteln.

Wie wähle ich Models für Agenten aus?

Ein Agent in Foundry Agent Service ist die Konfiguration: Anweisungen plus Modell plus Tools. Der Agent erbt Kontingent- und Ratenlimits von dem von ihm verwendeten Model Deployment. Zwei Muster funktionieren für mich gut:

1. Router als Basismodell des Agenten. In einem mehrstufigen Agent unterscheiden sich die Schritte stark in der Schwierigkeit – die Absichtsklassifizierung ist trivial, die Ursachenanalyse jedoch nicht. Mit der Oberfräse als Basismodell erhält jeder Schritt automatisch ein passendes Modell. Vorsichtsmaßnahme aus den Dokumenten: Wenn der Agent in seinen Abläufen den Agentendienst Tools verwendet, werden für das Routing nur OpenAI-Modelle verwendet.
2. Das Hybridmuster. Router für den allgemeinen Datenverkehr sowie eine festgelegte dedizierte Bereitstellung für Arbeitslasten, bei denen Compliance oder Reproduzierbarkeit eine feste Modellversion erfordern. Das empfiehlt Microsoft selbst und es entspricht meiner Erfahrung: Fräser für die Breite, Stifte für die Kronjuwelen.

Wie kann ich sehen, was der Router tut?

Der Router ist nur so vertrauenswürdig wie Ihr Einblick in ihn. Drei Dinge, die ich am ersten Tag eingerichtet habe:

1. Protokollieren Sie das Feld model jeder Antwort. Nach zwei Wochen haben Sie die Routing-Verteilung – das nützlichste Diagramm für die Pin-oder-Route-Entscheidung.
2. Kostenanalyse im Azure-Portal, gefiltert nach Router-Bereitstellung: Die Kosten werden nach zugrunde liegendem Modell aufgeteilt, sodass Sie genau sehen, wohin das Geld fließt.
3. A/B des Routers gegen Ihr altes Festnetzmodell mit Ihrem eigenen Evaluation-Set, bevor Sie den Produktionsverkehr wechseln. Das Auto-Toolkit Evaluation automatisiert den größten Teil davon.

Der Ansatz, den ich tatsächlich verwende

1. Neue Arbeitsbelastung? Beginnen Sie mit Model Router, ausgeglichener Modus und protokollieren Sie das Feld model vom ersten Tag an.
2. Schauen Sie sich nach zwei Wochen die Routing-Verteilung an. Wenn trotzdem 90 Prozent bei einem Modell landen, pinnen Sie dieses Modell an und speichern Sie das Markup.
3. Compliance-Arbeitsaufwand? Modellteilmenge nur mit den genehmigten Modellen (mindestens zwei, damit das Failover weiterhin funktioniert) – oder eine angeheftete Bereitstellung in einer Datenzone.
4. Volumen wächst vorhersehbar? PTU für die Grundlast, Spillover für Spitzen – bei direkt eingesetzten Modellen, da der Router kein PTU unterstützt.
5. Führen Sie eine vierteljährliche Neubewertung durch. Der Katalog wechselt monatlich; Die „Was ist neu in Microsoft Foundry“-Beiträge sind das Änderungsprotokoll, das ich tatsächlich gelesen habe.

Fallstricke, die ich jetzt vermeide

• Aufrufe mit großem Kontext an den Router. Das aufgeführte Kontextfenster ist das kleinste Modell im Pool. Ein größerer Aufruf schlägt nicht immer fehl – ​​er schlägt genau dann fehl, wenn der Router ein kleines Modell auswählt, sodass Sie zeitweise Fehler erhalten, die zufällig aussehen. Erhöhen Sie den Boden mit einer Teilmenge oder fassen Sie sie zusammen und kürzen Sie sie vor dem Senden.
• Dem Router bei der Abtastung von Parametern blind vertrauen. Wenn ein Argumentationsmodell ausgewählt wird, werden Parameter wie temperature stillschweigend gelöscht. Wenn Ihre App von ihnen abhängig ist, pinnen Sie ein unlogisches Modell an. reasoning_effort hingegen wird durchgereicht.
• Einzelmodell-Teilmengen. Kein zweites Modell bedeutet kein Failover. Mindestens zwei.
• Automatische Aktualisierung auf Produktionsroutern. Neue Version, neuer Modellpool, neues Kostenprofil – ohne bewusste Entscheidung. Pinne und aktualisiere bewusst.
• Multimodale Parität vorausgesetzt. Die Bildeingabe funktioniert (Routing entscheidet nur über den Text), die Audioeingabe nicht – der Router ist eine Text-First-Funktion.
• Vergleich der Router-Kosten nur mit den Listenpreisen. Der Aufschlag auf Eingabe-Tokens ist real und Prompt-Caching-Rabatte sind bei dynamischem Routing unzuverlässig. Ob der Router gewinnt, hängt von Ihrem Traffic-Mix ab, nicht von der Marketingfolie.

Wohin das führt

Die Modellauswahl wandelt sich von einer Architekturentscheidung zu einer Laufzeitentscheidung. Der Katalog wird weiter wachsen – OpenAI, Anthropic und xAI nebeneinander auf einer Plattform sind in Foundry bereits normal – und das Routing wird mit der Weiterentwicklung der Vorschaumodelle intelligenter. Ich gehe davon aus, dass die Konfiguration mit einem angehefteten Einzelmodell zur Ausnahme wird und regulierten Workloads vorbehalten ist. Der pragmatische Weg heute: Lassen Sie den Router die Breite verwalten, behalten Sie einen kleinen Satz fixierter Bereitstellungen bei, bei denen es auf die Kontrolle ankommt, und überprüfen Sie die Model Router-Dokumente vierteljährlich, da sich diese Funktion schnell entwickelt. Und wenn Sie kleine Modelle stattdessen komplett offline ausführen möchten, ist das eine andere Geschichte – ich habe es in Foundry Lokal auf dem Mac geschrieben.

Ich hoffe, das macht die Orientierung im Modelldschungel etwas einfacher.

Bleiben Sie gesund,

Prost Jannik