Pexon Consulting | 9 Min. Lesezeit | 15.07.2026
TL;DR
Open-Weight-Modelle wie DeepSeek, Llama und Mistral laufen im Azure-AI-Foundry-Model-Catalog entweder serverless (pro Token, DeepSeek-R1 ab 1,35 USD pro 1M Input-Tokens) oder auf Managed Compute (eigene GPU, fixe Stundenkosten). Pexon Consulting, Microsoft Partner aus Deutschland, deployt beide Varianten DSGVO-konform in EU-Regionen. Der Pilot steht in 6 Wochen.
Warum Open-Weight-Modelle im Foundry-Catalog, nicht im Eigen-Hosting
Die kurze Antwort: Weil das Betriebsrisiko woanders liegt als die meisten denken. Ein DeepSeek-R1 auf eigener Hardware zu betreiben ist nicht das Problem, den Sync mit Modell-Updates, GPU-Treibern, Autoscaling und Security-Patches über Monate zu halten, ist es. Der Foundry-Catalog nimmt diesen Betriebsteil ab und lässt die Gewichte trotzdem in deiner Azure-Umgebung.
Was Microsoft früher „Azure AI Foundry“ nannte, heißt seit Anfang 2026 offiziell Microsoft Foundry. Der Model-Catalog umfasst inzwischen über 11.000 Modelle von OpenAI, Anthropic, Meta, Mistral, DeepSeek, xAI, Cohere, NVIDIA und Hugging Face (Stand Juli 2026). Für Unternehmen relevant ist nicht die Zahl, sondern dass die offenen Gewichte darunter dieselbe Deployment-, Auth- und Netzwerk-Pipeline nutzen wie die proprietären Modelle.
Der Unterschied zum reinen Eigen-Hosting: Du bekommst einen Azure-nativen Endpoint mit Entra-ID-Auth, Private Link, Content Safety und Monitoring ohne diese Schicht selbst zu bauen. Bei DeepSeek-R1, das auf GitHub aktuell rund 92.000 Sterne trägt (Stand Juli 2026), ist die Community groß genug, dass du das Modell auch offline betreiben könntest. Die Frage ist selten „können wir das hosten“, sondern „wollen wir vier Ingenieure dauerhaft an den Betrieb binden“.
Unsere klare Position: Für 80 Prozent der Enterprise-Fälle ist der Foundry-Catalog der bessere Startpunkt als ein selbstgebauter vLLM-Cluster. Eigen-Hosting lohnt erst, wenn du fine-getunte Gewichte, harte Air-Gap-Anforderungen oder sehr konstante Hochlast hast. Zu dem Punkt kommen wir weiter unten.
Welche Open-Weight-Modelle im Catalog verfügbar sind
Der Foundry-Catalog trennt Modelle in zwei Gruppen: „sold directly by Azure“ (Microsoft rechnet ab, serverless verfügbar) und „from partners and community“ (oft nur Managed Compute). Für Open-Weight sind vier Familien praxisrelevant.
DeepSeek-V3-0324 ist ein Mixture-of-Experts-Modell mit 671 Milliarden Parametern, von denen pro Token 37 Milliarden aktiv sind, Context-Länge bis 128.000 Tokens. Das Modell wurde im Mai 2026 im Catalog aktualisiert. Für reine Reasoning-Aufgaben (Code, mathematische Ableitungen, Ticket-Klassifikation) nehmen wir in Projekten meist DeepSeek-R1, für breite Chat- und RAG-Last eher DeepSeek-V3 oder Mistral-Large.
Ein Hinweis zu Phi: Die kleinen Phi-4-Modelle laufen auf einer einzelnen GPU und teils sogar CPU-nah. Für Edge-nahe Klassifikation oder Vorfilterung vor einem großen Modell sind sie unterschätzt und deutlich günstiger als jeder 400B-Aufruf.
Managed Compute vs Serverless: die eigentliche Entscheidung
Serverless nimmst du, wenn die Last schwankt und du schnell starten willst. Managed Compute nimmst du, wenn die Last konstant hoch ist, du eigene Gewichte einspielst oder strikte Isolation brauchst. Das ist die ganze Regel, alles andere sind Details.
Bei Serverless (Model-as-a-Service) hostet Microsoft die Infrastruktur, du bekommst nur einen API-Endpoint und zahlst pro Token. Kein GPU-Provisioning, kein Kaltstart, keine Kapazitätsplanung. Der Preis ist transparent: DeepSeek-R1 kostet 1,35 USD pro 1M Input-Tokens und 5,40 USD pro 1M Output-Tokens (Azure-AI-Foundry-Preisliste, zuletzt verifiziert 2. Juni 2026). Bei 128.000 Tokens Context und bis 8.192 Output-Tokens pro Request ist das gut kalkulierbar.
Bei Managed Compute deployst du das Modell auf Azure-ML-Compute in deinem eigenen Subscription-Scope. Du zahlst die GPU-Stunde (eine ND-H100-Instanz statt pro Token) und bekommst dafür volle Kontrolle über Region, Netzwerk und Skalierung. Das rechnet sich ab einer bestimmten Dauerauslastung: Wer eine A100- oder H100-Instanz rund um die Uhr auslastet, fährt gegenüber Token-Preisen oft günstiger, aber nur bei echter Dauerlast.
Der Denkfehler, den wir oft sehen: Teams starten auf Managed Compute, weil es „professioneller“ klingt, und zahlen dann GPU-Stunden für eine Instanz, die nachts und am Wochenende idle steht. Unsere Empfehlung: Starte serverless, miss den echten Token-Verbrauch vier Wochen lang, und wechsle nur dann auf Managed Compute, wenn die Rechnung es belegt. Andersrum ist der Wechsel teuer.
So deployst du ein Open-Weight-Modell per CLI
Ein serverless Endpoint für DeepSeek-R1 ist in Foundry mit der Azure-ML-CLI in unter fünf Minuten live. Du brauchst die Azure CLI plus die ml-Extension, ein Foundry-Projekt und die passende EU-Region. Der folgende Ablauf legt Endpoint und Credentials an.
# CLI-Voraussetzungen: az login + ml-Extension installiert
# Defaults auf das Foundry-Projekt setzen (Region Sweden Central wegen EU-Residenz)
az extension add --name ml
az configure --defaults workspace=mein-foundry-projekt
group=rg-ai-prod
location=swedencentral
# Serverless-Endpoint mit DeepSeek-R1 aus dem Model-Catalog anlegen
az ml serverless-endpoint create
--name deepseek-r1-eu
--model-id "azureml://registries/azureml-deepseek/models/DeepSeek-R1"
--resource-group rg-ai-prod
--workspace-name mein-foundry-projekt
# API-Key des Endpoints auslesen (Zugriff aus der App)
az ml serverless-endpoint get-credentials --name deepseek-r1-euDer zurückgegebene Endpoint akzeptiert das Azure-AI-Model-Inference-Format, also denselben Payload wie ein Azure-OpenAI-Aufruf. Ein Test-Request gegen den frischen Endpoint sieht so aus:
# Test-Call an den serverless DeepSeek-R1-Endpoint
# ENDPOINT_URL und API_KEY aus dem get-credentials-Output einsetzen
curl "${ENDPOINT_URL}/chat/completions"
-H "Content-Type: application/json"
-H "Authorization: Bearer ${API_KEY}"
-d '{
"model": "DeepSeek-R1",
"messages": [
{"role": "user", "content": "Fasse den DSGVO-relevanten Teil des Vertrags zusammen."}
],
"max_tokens": 2048
}'Für Managed Compute läuft derselbe Weg über az ml online-endpoint create plus eine Deployment-Definition mit GPU-Instanztyp. Der Unterschied liegt nicht in der CLI, sondern darin, dass du dort die Instanz-SKU und das Autoscaling selbst festlegst. Für den Einstieg ist serverless der schnellere und günstigere Weg.
DSGVO und EU-Region: wo der Foundry-Catalog stolpert
Serverless heißt nicht automatisch EU-konform, und genau hier machen Teams den teuersten Fehler. Der Model-Catalog kann Prompts je nach Deployment-Typ außerhalb der EU verarbeiten, obwohl der Speicher in der EU liegt. Unter DSGVO Art. 4(2) ist auch die reine Inferenz ein Verarbeitungsvorgang, nicht nur die Speicherung.
Konkret: Für EU-Datenresidenz brauchst du Data-Zone-Deployments. Die unterstützten EU-Data-Zone-Regionen sind aktuell Sweden Central und Germany West Central. Ein „Global Standard“-Deployment dagegen kann Requests je nach Auslastung außerhalb der gewählten Region routen, damit ist strikte EU-Only-Verarbeitung nicht garantiert.
Ein aktuelles Beispiel, warum das kein Randthema ist: Anthropics Claude erreichte im Juli 2026 General Availability auf Microsoft Foundry, aber nur in US-Regionen. Ein Microsoft-Engineer bestätigte, EU-Region-Deployments seien „geplant, aber nicht terminiert“. Wer also europäische Datenresidenz braucht, kann Claude auf Foundry aktuell nicht produktiv einsetzen. Bei DeepSeek, Llama und Mistral als Open-Weight-Modelle bist du hier flexibler, weil du sie auf Managed Compute in einer EU-Region komplett selbst hostest.
Unsere Empfehlung für regulierte Kunden (Banking, Versicherung, Energie): Open-Weight-Modell auf Managed Compute in Germany West Central oder Sweden Central, hinter Private Link, mit Entra-ID-Auth. Dann verlässt kein Token die EU-Region, und du hast die Verarbeitungskontrolle, die DSGVO Art. 44 bis 49 fordert. Das ist mehr Aufwand als ein serverless Global-Endpoint, aber es ist der Unterschied zwischen auditfähig und nicht.
Wann Foundry-Catalog statt Eigen-Hosting
Foundry-Catalog gewinnt fast immer beim Start, Eigen-Hosting gewinnt bei Sonderfällen. Die Entscheidung hängt an drei Fragen, nicht an Ideologie.
Nimm den Foundry-Catalog, wenn du schnell live sein willst, schwankende Last hast oder Azure-native Auth, Monitoring und Content Safety ohne Eigenbau brauchst. Das trifft auf die meisten RAG-, Assistenz- und Klassifikations-Use-Cases zu.
Nimm Eigen-Hosting (eigener vLLM- oder Triton-Cluster auf AKS), wenn du fine-getunte Gewichte fahren willst, die nicht im Catalog stehen, wenn du echte Air-Gap-Anforderungen ohne jede Azure-Kontrollebene hast, oder wenn deine Dauerlast so konstant und hoch ist, dass du jede GPU-Stunde zu 100 Prozent auslastest. Das ist der schmalere Fall, als die meisten annehmen.
Worauf du bei der Auswahl achten solltest:
- Lastprofil messen, nicht schätzen (Token pro Tag, Peak vs. Durchschnitt) bevor du Managed Compute wählst.
- Region festlegen (Sweden Central oder Germany West Central für EU) vor dem ersten Deployment, nicht danach.
- Auth-Modell klären (Entra ID statt API-Key im Klartext) für Produktivbetrieb.
- Content Safety aktivieren, gerade bei Open-Weight-Modellen ohne eingebaute Guardrails.
- Exit-Pfad definieren: Open-Weight heißt, du kannst das Modell später auch außerhalb Azure fahren, das ist ein echter Vorteil gegen Lock-in.
Häufig gestellte Fragen
Was kostet ein Open-Weight-Modell im Azure-AI-Foundry-Catalog?
Serverless zahlst du pro Token: DeepSeek-R1 liegt bei 1,35 USD pro 1M Input- und 5,40 USD pro 1M Output-Tokens (Stand 2. Juni 2026). Managed Compute rechnet nach GPU-Stunde, eine H100-Instanz kostet mehrere Euro pro Stunde unabhängig von der Auslastung. Serverless ist bei schwankender Last günstiger, Managed Compute erst ab hoher Dauerauslastung.
Managed Compute oder Serverless: was ist besser für den Start?
Serverless, fast immer. Du hast keinen Kaltstart, kein GPU-Provisioning und zahlst nur was du nutzt. Managed Compute lohnt erst, wenn ein vierwöchiger Messlauf zeigt, dass deine Dauerlast die GPU-Stunden gegenüber Token-Preisen rechtfertigt. Andersherum zu wechseln ist der teurere Weg.
Sind DeepSeek, Llama und Mistral über Foundry DSGVO-konform?
Nur wenn du die Region richtig setzt. Ein Data-Zone- oder Managed-Compute-Deployment in Sweden Central oder Germany West Central hält die Verarbeitung in der EU. Ein Global-Standard-Endpoint kann Requests außerhalb der EU routen, das ist unter DSGVO Art. 4(2) bereits eine relevante Verarbeitung. Für regulierte Branchen empfehlen wir Managed Compute hinter Private Link.
Welches Open-Weight-Modell passt für RAG und Assistenz-Anwendungen?
Für breite Chat- und RAG-Last nehmen wir meist DeepSeek-V3 oder Mistral-Large, für reine Reasoning-Aufgaben DeepSeek-R1. Für günstige Vorfilterung oder Klassifikation vor dem großen Modell sind die kleinen Phi-4-Modelle unterschätzt. Die Modellwahl sollte an der Aufgabe hängen, nicht am Benchmark-Ranking.
Kann ich ein Foundry-Modell später auf eigene Hardware migrieren?
Bei Open-Weight-Modellen ja, das ist ihr zentraler Vorteil. DeepSeek, Llama und Mistral haben offene Gewichte, du kannst sie später auf einem eigenen vLLM-Cluster auf AKS oder on-premise fahren. Damit vermeidest du den Lock-in, den du bei proprietären Modellen wie Claude oder GPT hast. Der Foundry-Catalog ist dann Startrampe, nicht Endstation.
Nächster Schritt
Wenn du gerade evaluierst, welches Open-Weight-Modell und welcher Deployment-Modus zu deiner Last passt, machen wir daraus in sechs Wochen einen laufenden, DSGVO-konformen Foundry-Betrieb inklusive EU-Region, Auth und Kosten-Monitoring.
Verwandte Themen
→Llama, Mistral und DeepSeek im Enterprise-Einsatz
→Datensouveränität und KI in der EU-Region
