Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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:
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 Entwickler-Benutzerprinzipal im Bereich der Foundry-Ressourcen.
- 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 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 Diagnoseeinstellungen, um Protokolle zu Log Analytics, Storage oder Event Hubs zur Analyse und Aufbewahrung zu leiten.
Weitere Informationen finden Sie unter Azure Monitor Overview.
Computinginfrastruktur
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.
Typen der Modellbereitstellung
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 gleicht Latenz, Durchsatz und den Verarbeitungsort der Daten unterschiedlich aus:
| Bereitstellungstyp | Datenverarbeitung | Abrechnung |
|---|---|---|
| Globaler Standard | Regionsübergreifendes, Azure verwaltetes | Bezahlung pro Token |
| Global provisioniert | Regionsübergreifendes, Azure verwaltetes | Stündliche reservierte Kapazität |
| Globaler Batch | Regionsübergreifendes, Azure verwaltetes | Preisgestaltung von Batch-Token |
| Datenzonenstandard | Innerhalb der Datenzonengrenze | Bezahlung pro Token |
| Bereitgestellte Datenzone | Innerhalb der Datenzonengrenze | Stündliche reservierte Kapazität |
| Datazone-Batch | Innerhalb der Datenzonengrenze | Preisgestaltung für Batch-Token |
| Standard | Einzelne Region | Bezahlung pro Token |
| Regional bereitgestellt | Einzelne Region | Stündliche reservierte Kapazität |
| Entwickler | Jede Azure-Region (keine Garantie für Datenresidenz) | Pay-per-Token (nur fein abgestimmte Modellauswertung; 24-Stunden-Lebensdauer; kein SLA) |
Ausführliche Informationen zum Auswählen des richtigen Bereitstellungstyps finden Sie unter Bereitstellungstypen für Foundry Models.
Agenten, Auswertungen 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 Ergebnisse im Projektumfang. Batchverarbeitungswarteschlangen sammeln Anfragen zur asynchronen Ausführung zu reduzierten Kosten pro Token. Auf Ergebnisse für alle drei Workloadtypen kann über das Portal oder SDK zugegriffen werden.
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
Workloads werden in logisch isolierten Umgebungen pro Foundry-Ressource ausgeführt. Der Kunden-Code teilt keine Laufzeit-Container mit anderen Mandanten.
Inhaltssicherheit und Schutzschienen
Foundry integriert Inhaltssicherheitskontrollen in das Modell und die Agent-Ableitungspipeline. 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. 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:
- 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 How to configure a private link for 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 Vom Kunden verwaltete Schlüssel für die Verschlüsselung mit Foundry und Einrichten einer Azure Key Vault-Verbindung zu Foundry.
- Ü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
- Foundry-Rollout in meiner Organisation
- Role-basierte Zugriffssteuerung für Microsoft Foundry
- Vom Kunden verwaltete Schlüssel für die Verschlüsselung mit Foundry
- Wie ein private link für Foundry konfiguriert wird
- Bringen Sie Ihre eigenen Ressourcen mit dem Agentenservice mit
- Azure Monitor Übersicht
- Azure OpenAI-Kontingente und -grenzwerte
- Bereitstellungstypen für Foundry-Modelle
- Übersicht über Guardrails und Steuerelemente
- Verfügbarkeit von Features in Cloudregionen