Microsoft Foundry-Architektur

Microsoft Foundry organisiert KI-Workloads über eine mehrschichtige Architektur: eine Ressource auf oberster Ebene für Governance, Projekte zur Entwicklungsisolation und verbundene Azure Dienste für speicher-, such- und geheime Verwaltung.

Dieser Artikel bietet IT-Operations- und Sicherheitsteams Details zur Foundry-Ressource und zur zugrunde liegenden Azure-Dienstarchitektur, deren Komponenten und ihrer Beziehung zu anderen Azure-Ressourcentypen. Verwenden Sie diese Informationen, um zu erfahren, wie Sie Ihre Foundry-Bereitstellung an die Anforderungen Ihrer Organisation anpassen . Weitere Informationen zum Rollout von Foundry in Ihrer Organisation finden Sie unter Foundry Rollout.

Wann diese Architektur verwendet werden soll

Berücksichtigen Sie das Foundry-Ressourcenmodell, wenn Ihr Szenario Folgendes umfasst:

• Erstmaliges Einrichten: Sie starten ein neues KI-Projekt und möchten eine einzelne Ressource, die Modellzugriff, Agenthosting und Auswertungstools bündelt.
• Zugriff auf mehrere Teams: Mehrere Teams benötigen isolierte Projekte mit gemeinsamen Modellbereitstellungen und zentralisierter Governance.
• Compliance-gesteuertes Design: Ihre Organisation erfordert private Netzwerke, vom Kunden verwaltete Verschlüsselung oder Azure RBAC-Bereichsdefinition auf Ressourcen- und Projektebene.
• Azure OpenAI-Migration: Sie wechseln von einer eigenständigen Azure OpenAI-Ressource und möchten vorhandene Richtlinien und RBAC beibehalten, während Sie Agent- und Auswertungsfunktionen hinzufügen.

Für die Einzelentwicklersuche ist eine Foundry-Ressource mit einem Projekt die empfohlene Standardeinstellung. Wenn Ihre Workload nur Azure OpenAI-Fertigstellungen ohne Agenthosting oder Auswertung erfordert, reicht möglicherweise eine eigenständige Azure OpenAI-Ressource aus.

Azure KI-Ressourcentypen und -anbieter

Innerhalb der Azure KI-Produktfamilie können Sie diese Azure-Ressourcenanbieter verwenden, die benutzeranforderungen auf verschiedenen Ebenen im Stapel unterstützen.

Für die meisten KI-Entwicklungsszenarien – einschließlich Agent-Erstellung, Modellbereitstellung und Evaluierungsworkflows – ist die Foundry-Ressource der empfohlene Ausgangspunkt. Gießereiressourcen teilen den Microsoft.CognitiveServices-Anbieternamespace mit Diensten wie Azure OpenAI, Speech, Vision und Language. Dieser Namespace für gemeinsame Anbieter hilft beim Ausrichten von Verwaltungs-APIs, Zugriffssteuerungsmustern, Netzwerk- und Richtlinienverhalten über verwandte KI-Ressourcen hinweg.

Verwenden Sie die folgende Tabelle, um zu ermitteln, welcher Ressourcentyp Ihrer Workload entspricht. Es zeigt die spezifischen Ressourcentypen und -funktionen innerhalb der Microsoft. CognitiveServices-Anbieter:

Ressourcentypen unter denselben Anbieternamespaces verwenden dieselben Verwaltungs-APIs und verwenden ähnliche Azure rollenbasierte Zugriffssteuerung (Azure RBAC) Aktionen, Netzwerkkonfigurationen und Aliase für Azure Policy Konfiguration. Wenn Sie ein Upgrade von Azure OpenAI auf Foundry durchführen, werden Ihre vorhandenen benutzerdefinierten Azure-Richtlinien und Azure RBAC-Aktionen weiterhin angewendet.

Findry-Ressourcenhierarchie

Das folgende Diagramm zeigt eine Foundry-Ressource mit Modellbereitstellungen, Sicherheitseinstellungen, Verbindungen und zwei Projekten. Verbundene Azure Dienste wie Speicher, Key Vault und Azure KI-Suche sind separate Azure Ressourcen unter ihren eigenen Governance-Grenzen:

Verwenden Sie dieses Modell beim Planen von Architektur- und Zugriffsgrenzen:

• Foundry-Ressource: Azure-Ressource auf oberster Ebene, bei der Sie Governance-Einstellungen wie Netzwerk, Sicherheit und Modellbereitstellungen verwalten.
• Project: Entwicklungsgrenze innerhalb der Foundry-Ressource, in der Teams Anwendungsfälle erstellen und auswerten. Projekte ermöglichen es Teams, Prototypen in einer vorkonfigurierten Umgebung zu erstellen und dabei vorhandene Modellbereitstellungen und -verbindungen wiederzuverwenden, ohne wiederholt IT-Einrichtungen vornehmen zu müssen.
• Projekt-Assets: Dateien, Agenten, Auswertungen und zugehörige Artefakte, die einem Projekt zugewiesen sind.
• Verbindete Ressourcen: Azure Dienste wie Speicher, Key Vault und Azure KI-Suche, auf die die Foundry-Ressource über Verbindungen verweist. Diese Ressourcen verfügen über separate Governancegrenzen, sodass Sie ihre Netzwerk- und Zugriffsrichtlinien unabhängig voneinander verwalten.

Durch diese Trennung können IT-Teams zentrale Steuerelemente auf Ressourcenebene anwenden, während Entwicklungsteams innerhalb von Grenzen auf Projektebene arbeiten.

Sicherheitsgesteuerte Trennung von Bedenken

Gießerei erzwingt eine klare Trennung zwischen Management- und Entwicklungsvorgängen, um sichere und skalierbare KI-Workloads sicherzustellen.

Ressourcenverwaltung auf höchster Ebene

Die obersten Verwaltungsvorgänge von Foundry-Ressourcen umfassen das Konfigurieren der Sicherheit, das Herstellen der Konnektivität mit anderen Azure-Diensten und das Verwalten von Bereitstellungen. Dedizierte Projektcontainer isolieren Entwicklungsaktivitäten und bieten Grenzen für die Zugriffssteuerung, Dateien, Agents und Auswertungen.

Rollenbasierte Zugriffssteuerung

Azure RBAC-Aktionen spiegeln diese Trennung von Bedenken wider. Steuerungsebenenaktionen, z. B. das Erstellen von Bereitstellungen und Projekten, unterscheiden sich von Datenebenenaktionen, z. B. beim Erstellen von Agents, beim Ausführen von Auswertungen und beim Hochladen von Dateien. Sie können RBAC-Zuordnungen sowohl auf der obersten Ressourcenebene als auch auf der einzelnen Projektebene festlegen. Weisen Sie verwaltete Identitäten in beiden Bereichen zu, um den sicheren Automatisierungs- und Dienstzugriff zu unterstützen. Weitere Informationen finden Sie unter Role-based access control for Microsoft Foundry.

Allgemeine Einstiegsaufgaben für das Onboarding mit geringsten Rechten umfassen:

• Azure AI User für jeden Entwicklerbenutzer-Prinzipal auf der Foundry-Ressourcenebene.
• Azure AI User für jede vom Projekt verwaltete Identität im Bereich der Foundry-Ressource.

Rollendefinitionen und Leitfaden zur Bereichsplanung finden Sie unter Role-basierte Zugriffssteuerung für Microsoft Foundry.

Überwachung und Beobachtbarkeit

Azure Monitor segmentiert Metriken nach Bereich. Sie können Verwaltungs- und Nutzungsmetriken auf der obersten Ebene anzeigen, während projektspezifische Metriken, z. B. Auswertungsleistung oder Agentaktivität, auf die einzelnen Projektcontainer beschränkt sind.

Zu den wichtigsten Überwachungsfunktionen gehören:

• Metriken auf Ressourcenebene: Tokenverbrauch, Modelllatenz, Anforderungsanzahl und Fehlerraten für alle Projekte.
• Project-Level-Metriken: Auswertungsausführungsergebnisse, Anzahl der Agentaufrufe und Dateivorgangsaktivitäten.
• Diagnoseprotokollierung: Aktivieren Sie die Diagnostikeinstellungen, um Protokolle zur Analyse und Aufbewahrung an Log Analytics, Storage oder Event Hubs weiterzuleiten.

Weitere Informationen finden Sie unter Azure Monitor Overview.

Recheninfrastruktur

Foundry verwaltet die Computeinfrastruktur für Modellhosting, Agentausführung und Batchverarbeitung. In diesem Abschnitt werden Bereitstellungstypen, Agent- und Evaluierungsinfrastruktur, Integration des virtuellen Netzwerks, Mandantenisolation, Sicherheitskontrollen für Inhalte und regionale Verfügbarkeit behandelt.

Bereitstellungsarten für Modelle

Foundry unterstützt mehrere Bereitstellungstypen für das Modellhosting, gruppiert nach Datenverarbeitungsbereich: global (regionsübergreifend), Datenzone (innerhalb einer definierten Grenze) und regional (einzelne Region). Jeder Typ hat eine unterschiedliche Balance zwischen Latenz, Durchsatz und Datenverarbeitungsstandort.

Ausführliche Informationen zum Auswählen des richtigen Bereitstellungstyps finden Sie unter Bereitstellungstypen für Foundry Models.

Agents, Bewertungen und Batchverarbeitung

Agents, Auswertungen und Batchaufträge werden von Microsoft vollständig verwaltet. Agentworkloads werden in der Containerinfrastruktur der Plattform ausgeführt, die die Integration des virtuellen Netzwerks für isolierte Szenarien unterstützt. Auswertungen rufen Modellendpunkte auf, vergleichen Ausgaben mit Bewertungskriterien und Speichern von Ergebnissen im Projektbereich. Batchverarbeitungswarteschlangen schließen Anforderungen für die asynchrone Ausführung bei reduzierten Preisgestaltungen pro Token ab. Auf Ergebnisse für alle drei Workloadtypen kann über das Portal oder SDK zugegriffen werden.

Integration virtueller Netzwerke

Wenn Ihre Agents eine Verbindung mit externen Systemen herstellen, können Sie den Netzwerkdatenverkehr mithilfe von containerinjektion isolieren, wobei die Plattform ein Subnetz in Ihr virtuelles Netzwerk einspeist und die lokale Kommunikation mit Ihren Azure Ressourcen innerhalb desselben virtuellen Netzwerks ermöglicht.

Foundry unterstützt zwei Netzwerkmodelle für die ausgehende Isolation:

Mandantenisolation

Workloads werden in logisch isolierten Umgebungen pro Foundry-Ressource ausgeführt. Kundencode teilt keine Laufzeitumgebungen mit anderen Mandanten.

Inhaltssicherheit und Schutzschienen

Foundry integriert Inhaltssicherheitssteuerungen in die Modell- und Agenten-Inferenzpipeline. Guardrails definieren Risiken zum Erkennen, Interventionspunkte zum Scannen (Benutzereingabe, Ausgabe, Toolaufrufe (Vorschau) und Toolantworten (Vorschau) und Reaktionsaktionen, wenn ein Risiko erkannt wird. Inhaltsfilter werden inline mit Modellanforderungen ausgeführt und können pro Bereitstellung konfiguriert werden. Weitere Informationen finden Sie unter Guardrails und Steuerelemente – Übersicht und Schweregrad der Inhaltsfilterung.

Regionale Verfügbarkeit

Rechenkapazitäten variieren je nach Azure-Region. Die Verfügbarkeit von Modellen, Optionen zum Bereitstellungstyp und die Unterstützung von Features wie zum Beispiel Agents oder Auswertungen können sich je nach Region unterscheiden. Vergewissern Sie sich, dass Ihre Zielregion die erforderlichen Funktionen vor der Bereitstellung unterstützt. Informationen zur aktuellen Verfügbarkeit finden Sie unter Featureverfügbarkeit in Cloudregionen.

Datenspeicher

Foundry bietet flexible und sichere Datenspeicheroptionen zur Unterstützung einer vielzahl von KI-Workloads.

Verwalteter Speicher für den Dateiupload

Im Standardsetup verwendet Foundry Microsoft verwaltete Speicherkonten, die logisch getrennt sind und direkte Dateiuploads für ausgewählte Anwendungsfälle wie OpenAI-Modelle und Agents unterstützen, ohne dass ein vom Kunden bereitgestelltes Speicherkonto erforderlich ist.

Bringen Sie Ihren eigenen Speicher mit

Optional können Sie eigene Azure Storage-Konten verbinden. Gießereitools wie Auswertungen und Batchverarbeitung können Eingaben aus diesen Konten lesen und Ausgaben an diese schreiben. Ausführliche Informationen zu unterstützten Szenarien finden Sie unter Eigene Ressourcen mit dem Agentendienst.

Agentstatusspeicher

• Mit dem Setup des basic Agent speichert der Agent-Dienst Threads, Nachrichten und Dateien im Microsoft verwalteten Mehrinstanzenspeicher mit logischer Trennung.
• Mit dem standard-Agent-Setup bringen Sie Ihre eigenen Azure Ressourcen für alle Kundendaten , einschließlich Dateien, Unterhaltungen und Vektorspeichern. In dieser Konfiguration werden Daten innerhalb Ihrer Speicherkonten pro Projekt isoliert.

Vom Kunden verwaltete Schlüsselverschlüsselung

Standardmäßig verschlüsseln Azure-Dienste Daten im Ruhezustand und bei der Übertragung mithilfe von von Microsoft verwalteten Schlüsseln mit FIPS 140-2-kompatibler 256-Bit-AES-Verschlüsselung. Es sind keine Codeänderungen erforderlich.

Um stattdessen Ihre eigenen Schlüssel zu verwenden, bestätigen Sie diese Voraussetzungen, bevor Sie vom Kunden verwaltete Schlüssel für Foundry aktivieren:

• Key Vault wird in derselben Azure Region wie Ihre Foundry-Ressource bereitgestellt.
• Die Soft-Löschung und der Sperrschutz vor Löschung sind im Key Vault aktiviert.
• Verwaltete Identitäten verfügen über erforderliche Schlüsselberechtigungen, z. B. die Rolle Key Vault Crypto User bei Verwendung Azure RBAC.

Bringen Sie Ihr eigenes Schlüsselarchiv

Standardmäßig speichert Foundry alle schlüsselbasierten API-Verbindungsschlüssel in einem verwalteten Azure Key Vault. Wenn Sie geheime Schlüssel selbst verwalten möchten, verbinden Sie Ihren Schlüsseltresor mit der Foundry-Ressource. Eine Azure Key Vault Verbindung verwaltet alle Verbindungsschlüssel auf Projekt- und Ressourcenebene. Weitere Informationen finden Sie unter how to set up an Azure Key Vault connection to Foundry.

Weitere Informationen zur Datenverschlüsselung finden Sie unter vom Kunden verwalteten Schlüssel für die Verschlüsselung mit Foundry.

Datenstandort und Compliance

Foundry speichert alle ruhenden Daten in der angegebenen Azure Geographie. Inferenzdaten (Eingabeaufforderungen und -fertigstellungen) werden gemäß dem Bereitstellungstyp verarbeitet: Globale Bereitstellungen können zu jeder Azure-Region weitergeleitet werden, während Datenzonenbereitstellungen innerhalb der US- oder EU-Zone bleiben und standardmäßige oder regionale Bereitstellungen in der Bereitstellungsregion verarbeitet werden. Ausführliche Informationen finden Sie unter Bereitstellungstypen. Foundry unterstützt kein automatisches regionsübergreifendes Failover. Wenn Ihre Organisation die Verfügbarkeit von mehreren Regionen erfordert, stellen Sie separate Foundry-Ressourcen in jeder Zielregion bereit, und verwalten Sie die Datensynchronisierung und das Routing auf der Anwendungsebene. Details zur Compliancezertifizierung finden Sie in Azure Compliancedokumentation.

Überprüfen von Architekturentscheidungen

Überprüfen Sie vor dem Rollout Folgendes für Ihre Zielumgebung:

• Stellen Sie sicher, dass die erforderlichen Modelle und Features in Ihren Bereitstellungsregionen verfügbar sind. Ausführliche Informationen finden Sie unter Featureverfügbarkeit in Cloudregionen.
• Überprüfen Sie, ob Rollenzuweisungen sowohl auf der Gießereiressourcen- als auch auf Projektebene korrekt definiert sind. Ausführliche Informationen finden Sie unter Role-based access control for Microsoft Foundry.
• Überprüfen sie die Anforderungen an die Netzwerkisolation und private Zugriffspfade. Ausführliche Informationen finden Sie unter Konfigurieren eines privaten Links für Foundry.
• Bestätigen Sie die Anforderungen an verschlüsselungs- und geheime Verwaltung, einschließlich vom Kunden verwalteter Schlüssel und Azure Key Vault Integration. Ausführliche Informationen finden Sie unter Kundengesteuerte Schlüssel für die Verschlüsselung mit Foundry und wie man eine Azure Key Vault-Verbindung zu Foundry einrichtet.
• Überprüfen Sie Kontingente und Grenzwerte für Ihre Zielressourcen, einschließlich Modellbereitstellungsgrenzwerte und Ratengrenzwerte. Weitere Informationen finden Sie unter Azure OpenAI-Kontingente und -grenzwerte und Agent Service Limits, Quotas und Regionen.

Verwandte Inhalte

• Einführung von Foundry in meiner Organisation
• Role-basierte Zugriffssteuerung für Microsoft Foundry
• Vom Kunden verwaltete Schlüssel für die Verschlüsselung mit Foundry
• So konfigurieren Sie einen privaten Link für Foundry
• Eigenressourcen mit dem Agentendienst verwenden
• Azure Monitor Übersicht
• Azure OpenAI-Kontingente und -grenzwerte
• Bereitstellungstypen für Foundry-Modelle
• Übersicht über Guardrails und Steuerelemente
• Verfügbarkeit von Features in Cloudregionen