Microsoft Foundry-Architektur (klassisch)

Zurzeit wird folgendes angezeigt:Foundry (klassische) Portalversion - Wechseln zur Version für das neue Foundry-Portal

Hinweis

Links in diesem Artikel können Inhalte in der neuen Microsoft Foundry-Dokumentation anstelle der jetzt angezeigten Foundry-Dokumentation (klassisch) öffnen.

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 der zugrunde liegenden Azure-Dienstarchitektur, sowie 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.

Ressourcenanbieter Zweck Unterstützte Dienste
Microsoft. CognitiveServices Unterstützt Agentic- und GenAI-Anwendungsentwicklung beim Verfassen und Anpassen vordefinierter Modelle. Gießerei; Azure OpenAI; Azure Sprache in Gießereitools; Azure Sprache in Gießereitools; Azure Vision in Gießereitools
Microsoft. Suche Unterstützt den Wissensabruf über Ihre Daten Azure KI-Suche

Für die meisten KI-Entwicklungsszenarien – einschließlich Agent-Erstellung, Modellbereitstellung und Evaluierungsworkflows – ist die Foundry-Ressource der empfohlene Ausgangspunkt. Gießerei-Ressourcen teilen den Namespace des Anbieters Microsoft.CognitiveServices mit Diensten wie Azure OpenAI, Sprache, Vision und Sprache. Dieser Namespace für gemeinsame Anbieter hilft beim Ausrichten von Verwaltungs-APIs, Zugriffskontrollmustern, Netzwerken und Richtlinienverhalten in Bezug auf verwandte KI-Ressourcen.

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:

Ressourcentyp Ressourcenanbieter und Typ Kind Unterstützte Funktionen
Microsoft Foundry Microsoft.CognitiveServices/account AIServices Agents, Evaluationen, Azure OpenAI, Speech, Vision, Language und Content Understanding (nur API; Portalunterstützung variiert je nach Region)
Projekt einer Gießerei Microsoft.CognitiveServices/account/project AIServices Unterressource zur obigen Ressource
Azure Sprache in Foundry Tools Microsoft.CognitiveServices/account Speech Speech
Azure Language in den Foundry-Tools Microsoft.CognitiveServices/account Language Language
Azure Vision für Foundry-Tools Microsoft.CognitiveServices/account Vision Sehvermögen

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:

Diagramm mit der Hierarchie der Foundry-Ressource mit einer Governancegrenze, die Modellbereitstellungen, Sicherheitseinstellungen, Verbindungen und zwei Projekte enthält. Verbundene Ressourcen wie Speicher, Key Vault und Azure KI-Suche werden als separate Governancegrenzen angezeigt.

Von Bedeutung

Verbundene Ressourcen wie Storage, Key Vault und Azure KI-Suche sind unabhängig Azure Ressourcen mit ihren eigenen Governancegrenzen. Sie verwalten Netzwerk-, Zugriffsrichtlinien und Complianceeinstellungen für diese Ressourcen separat von der Foundry-Ressource.

Verwenden Sie dieses Modell beim Planen der Architektur und Zugriffsgrenzen.

  • Foundry-Ressource: Oberste Azure-Ressource, in der Sie Governance-Einstellungen wie Netzwerk-, Sicherheits- und Modellbereitstellungen verwalten.
  • Project: Entwicklungsgrenze innerhalb der Foundry-Ressource, in der Teams Anwendungsfälle erstellen und auswerten. Projekte ermöglichen es Teams, innerhalb einer vorkonfigurierten Umgebung Prototypen zu erstellen, indem sie vorhandene Modellbereitstellungen und -verbindungen wiederverwenden, ohne dass eine wiederholte IT-Einrichtung erforderlich ist.
  • Projekt-Assets: Dateien, Agenten, Auswertungen und zugehörige Artefakte, die auf ein Projekt ausgerichtet 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 Projektgrenzen arbeiten.

Hinweis

Die meisten neuen APIs sind im Projektbereich verfügbar. Einige Funktionen, die ursprünglich auf Kontoebene über die Dienste Azure OpenAI, Speech, Vision und Language unterstützt wurden, sind jedoch nur auf der Foundry-Ressourcenebene verfügbar, nicht auf Projektebene. Die Übersetzer-API ist z. B. nur auf der Ressourcenebene "Foundry" verfügbar. Planen Sie Ihre Bereitstellungsstruktur basierend darauf, welche API-Bereiche Ihre Workloads erfordern.

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 Verwaltungsvorgänge auf oberster Ebene von Foundry-Ressourcen, z. B. das Konfigurieren von Sicherheit, das Einrichten 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 Zugriffskontrolle

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 Ressourcenebene oberster Ebene als auch auf einzelner Projektebene festlegen. Zuweisung von verwalteten Identitäten in beiden Bereichen zur Unterstützung von sicherer Automatisierung und Service-Zugriff. Weitere Informationen finden Sie unter Role-based access control for Microsoft Foundry.

Typische Anfangsaufgaben für geringste Privilegien-Onboarding umfassen:

  • Azure AI User für jeden Entwicklerbenutzer als Prinzipal im Kontext der Foundry-Ressource.
  • Azure AI User für jede projektverwaltete Identität im Foundry-Ressourcenbereich.

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 Management- und Nutzungsmetriken auf der obersten Ebene anzeigen; während projekt-spezifische Metriken, wie z. B. Auswertungsleistung oder Agentaktivität, auf die einzelnen Projekt-Container 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 Diagnoseneinstellungen, um Protokolle an Log Analytics, Storage oder Event Hubs zur Analyse und Speicherung weiterzuleiten.

Weitere Informationen finden Sie unter Azure Monitor Overview.

Computinginfrastruktur

Foundry verwaltet die Computeinfrastruktur für Modellhosting, Agentausführung und Batchverarbeitung.

Typen der Modellbereitstellung

Die Standardbereitstellung in Foundry-Ressourcen bietet eine Modell-Hosting-Architektur.

Verwaltetes Computing für Agenten und Auswertungen

Agents, Auswertungen und Batchaufträge werden als verwaltete Container-Compute ausgeführt und vollständig von Microsoft verwaltet. Auswertungen rufen Modellendpunkte auf und vergleichen Ausgaben mit Benotungskriterien. Gießerei speichert Ergebnisse im Projektbereich, auf die über das Portal oder SDK zugegriffen werden kann.

Integration in ein virtuelles Netzwerk

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:

Modell So funktioniert es Kompromiss
Vom Kunden verwaltetes VNet (BYO) Sie stellen das VNet und ein dediziertes Subnetz bereit, das an Microsoft.App/environments delegiert wurde. Die Plattform wird in Ihr Subnetz eingefügt und ermöglicht die lokale Kommunikation mit Ihren privaten Azure-Ressourcen. Vollständige Kontrolle über die Netzwerkkonfiguration; erfordert Ihre eigene Netzwerkverwaltung.
Verwaltetes VNet (Vorschau) Foundry verwaltet das VNet in Ihrem Auftrag. Einfachere Einrichtung; schränkt Anpassungsoptionen ein. Ausführliche Informationen finden Sie unter Konfigurieren des verwalteten virtuellen Netzwerks.

Hinweis

Einige netzwerkisolte Szenarien erfordern das SDK oder die CLI anstelle des Portals. Beispielsweise können Bereitstellungen mit privaten Endpunkten, die den gesamten öffentlichen Zugriff blockieren, nicht über die Portal-UI konfiguriert werden. Ausführliche Informationen finden Sie unter How to configure a private link for Foundry.

Mieterisolierung

Von Microsoft verwaltete Rechenressourcen führen Workloads in pro Projekt logisch isolierten Umgebungen aus. Der Kundencode teilt keine Laufzeitcontainer mit anderen Mandanten.

Inhaltssicherheit und Schutzschienen

Foundry integriert Sicherheitskontrollen für Inhalte in die Modell- und Agent-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.

Scaling

Verwaltete Rechenressourcen für Agenten und Auswertungen skalieren automatisch je nach Arbeitslastbedarf. Das Modellhosting wird je nach Bereitstellungskonfiguration skaliert.

Regionale Verfügbarkeit

Rechenkapazitäten variieren je nach Azure-Region. Modellverfügbarkeit, Bereitstellungsoptionen und Featureunterstützung wie Agenten oder Bewertungen können sich in verschiedenen Regionen 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.

Datenspeicherung

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ßereiwartungswerkzeuge wie Auswertungen und Batchverarbeitung können Eingaben aus diesen Konten lesen und Ausgaben in diese Konten schreiben. Ausführliche Informationen zu unterstützten Szenarien finden Sie unter Bringen Sie Ihre eigenen 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 nach Projekt isoliert.

Vom Kunden verwaltete Schlüsselverschlüsselung

Standardmäßig verschlüsseln Azure-Dienste ruhende Daten und Daten während 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.
  • Der Soft Delete und der Löschschutz sind für 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 Ihre eigene Key Vault

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.

Datenresidenz und Compliance

Foundry speichert alle ruhenden Daten in der angegebenen Azure-Region. Die Verarbeitung von Inferenzdaten (Eingabeaufforderungen und -vollendungen) erfolgt gemäß dem Bereitstellungstyp: Globale Bereitstellungen können zu jeder Azure-Region geleitet werden, Datenzonen-Bereitstellungen verbleiben innerhalb der US- oder EU-Zone und standard- oder regionale Bereitstellungen werden in der jeweiligen Bereitstellungsregion verarbeitet. 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: