Warum ich darüber schreibe

Es war gegen Ende meiner letzten Session bei Microsoft. Die Slides waren durch, der Kaffee kalt – und dann kamen die Fragen. Nicht eine, nicht zwei. Immer wieder dasselbe Thema, aus dem Publikum, im Nachgang, auf LinkedIn:

„

Über 11.000 Modelle im Katalog – aber welches ist denn jetzt das richtige für mich?

Ich hab ehrlich gesagt kurz geschluckt. Weil die Frage so simpel klingt und gleichzeitig so verdammt berechtigt ist. 11.000 Modelle. Das ist keine Auswahl mehr, das ist ein Regal ohne Beschilderung in einem Supermarkt, den jemand über Nacht auf die dreifache Größe erweitert hat.

Und das Zweite, was mich beschäftigt hat: Die Leute, die fragten, waren keine Einsteiger. Das waren Admins, Architekten, Power User – Leute, die wissen, was sie tun. Trotzdem stand die Frage im Raum. Das sagt mir: Es ist kein Wissensproblem. Es ist ein Orientierungsproblem.

Genau dafür ist dieser Artikel da.

Was ist der Model Catalog in Azure AI Foundry überhaupt?

Azure AI Foundry (früher Azure AI Studio) ist Microsofts zentrale Plattform, um KI-Anwendungen zu bauen, zu testen und zu deployen. Der Model Catalog darin ist die Schaltzentrale für Modellauswahl – und er wächst rasant.

Du findest dort Modelle von Microsoft selbst (Phi-Familie), OpenAI (GPT-4o, o1, o3…), Meta (Llama), Mistral, Cohere, Stability AI, xAI, Google (Gemma), Anthropic (Claude) – und viele mehr. Kuratiert, kategorisiert, mit Benchmarks und Beschreibungen versehen.

Der entscheidende Vorteil gegenüber dem direkten API-Zugriff: Die meisten Modelle im Katalog laufen innerhalb der Azure-Infrastruktur. Das bedeutet: Deine Daten verlassen nicht die Azure-Region, in der dein Tenant konfiguriert ist. Für Enterprise-Umgebungen mit Datenschutz- und Compliance-Anforderungen ist das kein Nice-to-have – das ist Voraussetzung.

⚠️ Wichtiger Hinweis zu Anthropic-Modellen (Stand: aktuell)
Anthropic-Modelle (Claude-Familie) werden im Foundry-Katalog angeboten, aber nach aktuellem Stand läuft die Datenverarbeitung noch über amerikanische Infrastruktur – nicht über Azure direkt. Für DSGVO-sensible Workloads oder Umgebungen mit EU-Datenlokalisierungspflicht ist das ein Stopper. Das ist kein permanenter Zustand, aber Stand heute ein relevanter. Prüfen, bevor ihr deployt.

Das Eingemachte: Wie wähle ich das richtige Modell?

1

Versteh, was du eigentlich willst

Klingt banal. Ist es nicht. Bevor du den Katalog öffnest, beantworte dir drei Fragen:

  • Was ist der Use Case? Text generieren, Code schreiben, Bilder analysieren, Dokumente zusammenfassen, Sprache verstehen?
  • Wie viel Kontext brauche ich? Kurze Prompts oder lange Dokumente mit viel Kontext?
  • Was sind meine Compliance-Anforderungen? EU-Datenhaltung, Branchenvorschriften, interne Policies?

Erst danach macht der Katalog Sinn.

2

Klein starten – ernsthaft

Das ist meine klare Empfehlung und ich stehe dazu: Fang mit den Mini-Modellen an.

GPT-4o mini, Phi-3.5-mini, Llama 3.2 (kleinere Varianten) – die sind schneller, günstiger in der Token-Abrechnung und für die meisten Testszenarien völlig ausreichend. Wenn du merkst, dass das Modell an seine Grenzen kommt – Qualität schwankt, Kontext geht verloren, Antworten werden flach – dann steigst du auf die großen Varianten.

Warum das wichtig ist: Größere Modelle kosten nicht nur mehr pro Token. Sie sind auch langsamer in der Inferenz, was in produktiven Szenarien relevant wird. Und: Wenn du ein Konzept mit einem Mini-Modell nicht zum Laufen bringst, liegt es meistens nicht am Modell – sondern am Prompt oder am Design deiner Lösung.

3

Modelle haben Spezialitäten – nutz sie

Hier ein paar konkrete Beispiele, die den Unterschied machen:

Modell Stärke Typischer Use Case
GPT-4o OpenAI Multimodal, Reasoning, langer Kontext Dokumentenanalyse, komplexe Agents
Phi-3.5 / Phi-4 Microsoft Effizient, stark bei Reasoning für die Größe Edge-Szenarien, kostensensitive Workloads
Llama 3.x Meta Open-Weight, flexibel anpassbar Fine-Tuning-Projekte, On-Prem-Szenarien
Mistral Large Mistral Stark in europäischen Sprachen, Code Mehrsprachige Anwendungen, Code-Assistenz
Sora ⚠ Kein Text-LLM Videogenerierung, visuelles Verständnis Bild- und Videoworkflows – nicht für Text!
Deepseek Deepseek Stark in Mathematik, Coding, Analytik Technische Analysen, STEM-Domänen
☕ Achte auf …
Sora ist kein Sprachmodell im klassischen Sinne. Wer Sora für Textaufgaben einspannt, ist auf dem Holzweg – und verbrennt dabei Token-Budget ohne Gegenwert. Deepseek ist sehr leistungsstark in analytischen Domänen, aber: Datenverarbeitung und Herkunft im Compliance-Kontext unbedingt prüfen.
4

Lies die Modellbeschreibungen. Wirklich.

Ich weiß, es klingt nach „lies die Anleitung“ – aber es lohnt sich. Im Foundry Model Catalog stehen bei jedem Modell:

  • Benchmarks und Vergleichswerte
  • Empfohlene Use Cases
  • Kontextfenstergröße (Context Window)
  • Lizenzmodell und Nutzungsbedingungen
  • Preismodell pro Token

Gerade der letzte Punkt wird unterschätzt. Die Token-Kosten zwischen einem Mini-Modell und dem Vollmodell derselben Familie können Faktor 10–20 auseinander liegen. Bei produktiven Workloads mit hohem Durchsatz ist das kein akademisches Detail mehr – das ist Budget-Planung.

5

Enterprise Data Protection im Blick behalten

Für Foundry-Projekte in Enterprise-Umgebungen gilt: Nutze Modelle, die nachweislich über Azure-Infrastruktur verarbeiten. Das gibt dir:

  • Datenhaltung in deiner konfigurierten Azure-Region
  • Integration in bestehende Azure-Sicherheitsarchitektur (Private Endpoints, VNET, Managed Identity)
  • Compliance-Nachweisbarkeit

Modelle, bei denen du dir nicht sicher bist, kannst du im Foundry-Projekt deployen, testen – und wenn sie nicht passen, wieder deinstallieren. Die Plattform ist dafür gebaut. Nutze das als Sandbox, nicht als Produktivumgebung.

Praxis-Check

So merkst du, dass es läuft

  • Das Modell antwortet konsistent und im erwarteten Format
  • Die Latenz passt zu deinem Anwendungsfall
  • Die Token-Kosten bleiben im geplanten Rahmen
  • Deine Compliance-Anforderungen sind dokumentiert und erfüllt

Wenn’s nicht klappt – diese 3 Dinge prüfen

🔍 Troubleshooting
  • Falsches Modell für den Use Case? Hast du ein Sprachmodell für einen Bildworkflow genutzt oder umgekehrt?
  • Kontextfenster zu klein? Lange Dokumente brauchen Modelle mit großem Context Window – das ist nicht bei allen gleich.
  • Datenverarbeitung unklar? Vor dem produktiven Einsatz: Prüf im Foundry-Katalog explizit, wo das Modell verarbeitet wird. Im Zweifel: Nachfragen, nicht annehmen.

Fazit

Die 11.000 Modelle sind keine Bedrohung – die sind eine Chance. Aber wie bei jedem großen Werkzeugkasten gilt: Wer planlos reingreift, verliert Zeit und Geld.

Meine Empfehlung ist simpel: Recherchiere, lies die Beschreibungen, starte mit Mini-Modellen, und steig erst dann hoch, wenn du weißt, was du brauchst. Foundry gibt dir die Möglichkeit, Modelle sicher zu testen und wieder zu entfernen – das ist ein Feature, kein Notausgang.

Und bei allem Enthusiasmus für neue Modelle: Compliance zuerst. Ein Modell, das deine Daten in die falsche Region schickt, ist kein Modell für dein Unternehmen – egal wie gut die Benchmark-Zahlen sind.

☕ Espresso-Moment

Das richtige Modell ist nicht das stärkste – es ist das, das deinen Use Case löst, dein Budget respektiert und deine Daten dort lässt, wo sie hingehören.

☕

Kurz-Checkliste: Modellauswahl in Azure AI Foundry

  • Use Case klar definiert, bevor der Katalog geöffnet wird
  • Mit Mini-Modellen starten (z.B. GPT-4o mini, Phi-3.5-mini)
  • Modellbeschreibung und Benchmarks im Katalog gelesen
  • Spezialisierungen beachtet (Sora ≠ Textmodell, Deepseek = analytisch/technisch)
  • Token-Kosten vor dem Deployment verglichen
  • Datenverarbeitungsstandort geprüft (Azure-Region vs. Drittland)
  • Anthropic-Modelle: aktuell US-Verarbeitung – Compliance-Check Pflicht
  • Modell im Foundry-Projekt als Test deployen, evaluieren, ggf. deinstallieren

Hattest du beim letzten Projekt auch das Modell-Auswahl-Problem? Erzähl mir davon – ich bin gespannt, welche Use Cases euch gerade beschäftigen. 💬