Microsoft Foundry-architectuur

Microsoft Foundry organiseert AI-workloads via een gelaagde architectuur: een foundry-resource op het hoogste niveau voor governance, projecten voor isolatie van ontwikkeling en verbonden Azure-services voor opslag-, zoek- en geheimenbeheer.

Dit artikel biedt IT-operaties en beveiligingsteams details over de Foundry-resource en onderliggende Azure-servicearchitectuur, de bijbehorende onderdelen en de relatie met andere Azure-resourcetypen. Gebruik deze informatie om te helpen bij het aanpassen van uw Foundry-implementatie aan de vereisten van uw organisatie. Zie Foundry Rollout voor meer informatie over het implementeren van Foundry in uw organisatie.

Wanneer u deze architectuur gebruikt

Overweeg het Foundry-resourcemodel wanneer uw scenario betrekking heeft op:

  • Eerste keer instellen: u start een nieuw AI-project en wilt één resource die modeltoegang, hosting van agents en evaluatiehulpprogramma's bundelt.
  • Toegang voor meerdere teams: meerdere teams hebben geïsoleerde projecten nodig met gedeelde modelimplementaties en gecentraliseerd beheer.
  • Compliancegestuurd ontwerp: uw organisatie vereist privénetwerken, door de klant beheerde versleuteling of Azure RBAC-bereik op zowel resource- als projectniveaus.
  • Azure OpenAI-migratie: u stapt over van een zelfstandige Azure OpenAI-resource en wilt bestaande beleidsregels en RBAC behouden terwijl u agent- en evaluatiemogelijkheden toevoegt.

Voor verkenning van één ontwikkelaar is een Foundry-resource met één project de aanbevolen standaardinstelling. Als uw workload alleen Azure OpenAI-voltooiingen vereist zonder agenthosting of evaluatie, is een zelfstandige Azure OpenAI-resource mogelijk voldoende.

Azure AI-resourcetypen en -aanbieders

Binnen de Azure AI-productfamilie kunt u deze Azure resourceproviders gebruiken die ondersteuning bieden voor gebruikersbehoeften op verschillende lagen in de stack.

Resourceprovider Purpose Ondersteunde services
Microsoft. CognitiveServices Biedt ondersteuning voor ontwikkeling van Agentic- en GenAI-toepassingen voor het opstellen en aanpassen van vooraf gemaakte modellen. Foundry; Azure OpenAI; Azure Spraak in Foundry Tools; Azure Taal in Foundry Tools; Azure Vision in Foundry Tools
Microsoft. Zoek Ondersteunt het ophalen van kennis over uw gegevens Azure AI Zoeken

Voor de meeste AI-ontwikkelscenario's, waaronder het bouwen van agents, het implementeren van modellen en evaluatiewerkstromen, is de Foundry-resource het aanbevolen uitgangspunt. Foundry-bronnen delen de Microsoft.CognitiveServices-provider naamruimte met services zoals Azure OpenAI, Speech, Vision en Language. Deze gedeelde providernaamruimte helpt bij het afstemmen van beheer-API's, toegangsbeheerpatronen, netwerken en beleidsgedrag voor gerelateerde AI-resources.

Gebruik de volgende tabel om te bepalen welk resourcetype overeenkomt met uw workload. Hier ziet u de specifieke resourcetypen en mogelijkheden in de Microsoft. CognitiveServices-provider:

Hulpmiddelsoort Resourceprovider en -type Kind Ondersteunde mogelijkheden
Microsoft Foundry Microsoft.CognitiveServices/accounts AIServices Agents, Evaluaties, Azure OpenAI, Speech, Vision, Language en Content Understanding
Gieterij Project Microsoft.CognitiveServices/accounts/projects AIServices Subresource voor het bovenstaande
Azure Spraak in Foundry Tools Microsoft.CognitiveServices/accounts Speech Toespraak
Azure Taaltechnologie in Foundry Tools Microsoft.CognitiveServices/accounts Language Taal
Azure Vision in Foundry Tools Microsoft.CognitiveServices/accounts Vision Visie

Resourcetypen onder dezelfde providernaamruimten delen dezelfde beheer-API's en gebruiken vergelijkbare Azure op rollen gebaseerd toegangsbeheer (Azure RBAC) acties, netwerkconfiguraties en aliassen voor Azure Policy-configuratie. Als u een upgrade uitvoert van Azure OpenAI naar Foundry, blijven uw bestaande aangepaste Azure-beleid en Azure RBAC-acties van toepassing.

hiërarchie van foundry-resources

In het volgende diagram ziet u een Foundry-resource met modelimplementaties, beveiligingsinstellingen, verbindingen en twee projecten. Verbonden Azure-services zoals Storage, Key Vault en Azure AI Zoeken zijn gescheiden Azure-bronnen onder hun eigen beheersdomeinen:

Diagram met de hiërarchie van foundry-resources met een governancegrens met modelimplementaties, beveiligingsinstellingen, verbindingen en twee projecten. Verbonden resources zoals Storage, Key Vault en Azure AI Zoeken worden weergegeven als afzonderlijke governancegrenzen.

Belangrijk

Verbonden resources zoals Storage, Key Vault en Azure AI Zoeken zijn onafhankelijk Azure resources met hun eigen governancegrenzen. U beheert de instellingen voor netwerken, toegangsbeleid en naleving voor deze resources afzonderlijk van de Foundry-resource.

Gebruik dit model bij het plannen van architectuur en toegangsgrenzen:

  • Foundry resource: Azure resource op het hoogste niveau, waar u beheerinstellingen beheert, zoals netwerken, beveiliging en modelimplementaties.
  • Project: Ontwikkelingsgrens binnen de Foundry-resource waar teams use cases bouwen en evalueren. Met projecten kunnen teams prototypen binnen een vooraf geconfigureerde omgeving maken, bestaande modelimplementaties en verbindingen hergebruiken zonder herhaalde IT-instellingen.
  • Project assets: Bestanden, agents, evaluaties en gerelateerde artefacten die zijn toegewezen aan een project.
  • Connected resources: Azure services zoals Storage, Key Vault en Azure AI Zoeken waarnaar de Foundry-resource verwijst via verbindingen. Deze resources hebben afzonderlijke beheergrenzen, zodat u hun netwerk- en toegangsbeleid onafhankelijk beheert.

Met deze scheiding kunnen IT-teams gecentraliseerde besturingselementen toepassen op resourceniveau, terwijl ontwikkelteams binnen grenzen op projectniveau werken.

Opmerking

De meeste nieuwe API's zijn beschikbaar in het projectbereik. Sommige mogelijkheden die oorspronkelijk op accountniveau worden ondersteund via Azure OpenAI-, Speech-, Vision- en Taalservices zijn echter alleen beschikbaar op het resourceniveau Van Foundry, niet op projectbereik. De Translator-API is bijvoorbeeld alleen beschikbaar op het niveau van de Foundry-resource. Plan uw implementatiestructuur op basis van welke API-bereiken uw workloads vereisen.

Beveiligingsgestuurde scheiding van problemen

Foundry dwingt een duidelijke scheiding af tussen beheer- en ontwikkelingsbewerkingen om veilige en schaalbare AI-workloads te garanderen.

Resourcebeheer op het hoogste niveau

De beheerbewerkingen voor Foundry-resources op het hoogste niveau, zoals het configureren van beveiliging, het tot stand brengen van connectiviteit met andere Azure-services en het beheren van implementaties. Toegewezen projectcontainers isoleren ontwikkelingsactiviteiten en bieden grenzen voor toegangsbeheer, bestanden, agents en evaluaties.

Op rollen gebaseerd toegangsbeheer

Azure RBAC-acties weerspiegelen deze scheiding van problemen. Besturingsvlakacties, zoals het maken van implementaties en projecten, verschillen van gegevensvlakacties, zoals het bouwen van agents, het uitvoeren van evaluaties en het uploaden van bestanden. U kunt RBAC-toewijzingen instellen op zowel het bovenste resourceniveau als op individueel projectniveau. Wijs beheerde identiteiten toe op beide bereiken ter ondersteuning van beveiligde automatisering en servicetoegang. Zie Toegangsbeheer op basis vanRole voor Microsoft Foundry voor meer informatie.

Algemene startopdrachten voor onboarding met minder bevoegdheden zijn onder andere:

  • Azure AI-gebruiker voor elke ontwikkelaarsgebruikersprincipal op het Foundry-resourcebereik.
  • Azure AI-gebruiker voor elke door het project beheerde identiteit in het resourcebereik Foundry.

Zie Toegangsbeheer op basis van rollen en bereikplanning voor Microsoft Foundry voor richtlijnen voor roldefinities en bereikplanning.

Bewaking en waarneembaarheid

Azure Monitor segmenteert metriek per bereik. U kunt metrische beheer- en gebruiksgegevens weergeven op de resource op het hoogste niveau, terwijl projectspecifieke metrische gegevens, zoals evaluatieprestaties of agentactiviteit, zijn afgestemd op de afzonderlijke projectcontainers.

Belangrijke bewakingsmogelijkheden zijn onder andere:

  • Metrische gegevens op resourceniveau: Tokenverbruik, modellatentie, aantal aanvragen en foutpercentages voor alle projecten.
  • Projectniveau statistieken: resultaten van evaluatieuitvoeringen, aantal oproepen van agenten en bestandsbewerkingsactiviteit.
  • Diagnostische logboekregistratie: diagnostische instellingen inschakelen voor het routeren van logboeken naar Log Analytics, Opslag of Event Hubs voor analyse en retentie.

Zie Azure Monitor overview voor meer informatie.

Computing-infrastructuur

Foundry beheert de rekeninfrastructuur voor modelhosting, agentuitvoering en batchverwerking. In deze sectie worden implementatietypen, agent- en evaluatieinfrastructuur, integratie van virtuele netwerken, tenantisolatie, besturingselementen voor inhoudsveiligheid en regionale beschikbaarheid behandeld.

Modelimplementatietypen

Foundry ondersteunt meerdere implementatietypen voor modelhosting, gegroepeerd op gegevensverwerkingsbereik: globaal (meerdere regio's), gegevenszone (binnen een gedefinieerde grens) en regionaal (één regio). Elk type zorgt voor een andere balans tussen latentie, doorvoer en gegevensverwerkingslocatie:

Implementatietype Gegevensverwerking Facturering
Algemene standaard Meerdere regio's, Azure beheerd Betalen per token
Globaal geprovisioneerd Meerdere regio's, Azure beheerd Gereserveerde capaciteit per uur
Globale batch Meerdere regio's, Azure beheerd Prijzen van Batch-token
Standaard gegevenszone Binnen de grens van de gegevenszone Betalen per token
Gegevenszone voorzien Binnen de grens van de gegevenszone Gereserveerde capaciteit per uur
Batch van gegevenszone Binnen de grens van de gegevenszone Prijzen van Batch-token
Standaard Eén regio Betalen per token
Regionaal voorzien Eén regio Gereserveerde capaciteit per uur
Ontwikkelaar Elke Azure regio (geen garantie voor gegevenslocatie) Betalen per token (alleen aangepaste modelevaluatie; levensduur van 24 uur; geen SLA)

Zie Implementatietypen voor Foundry-modellen voor meer informatie over het kiezen van het juiste implementatietype.

Agents, evaluaties en batchverwerking

Agents, evaluaties en batchtaken worden door Microsoft volledig beheerd. Agentworkloads worden uitgevoerd in de containerinfrastructuur van het platform, die ondersteuning biedt voor integratie van virtuele netwerken voor scenario's die zijn geïsoleerd van het netwerk. Evaluaties roepen modeleindpunten aan, vergelijken uitvoer met beoordelingscriteria en slaan resultaten op binnen het projectbereik. Batchverwerkingswachtrijen verwerken inferentieaanvragen voor asynchrone uitvoering tegen gereduceerde tarieven per token. Resultaten voor alle drie de workloadtypen zijn toegankelijk via de portal of SDK.

Integratie van virtueel netwerk

Wanneer uw agents verbinding maken met externe systemen, kunt u netwerkverkeer isoleren met behulp van containerinjectie, waarbij het platform een subnet in uw virtuele netwerk injecteert, waardoor lokale communicatie mogelijk is met uw Azure resources binnen hetzelfde virtuele netwerk.

Foundry ondersteunt twee netwerkmodellen voor uitgaande isolatie:

Model Hoe het werkt Compromis
Door de klant beheerd VNet (BYO) U geeft het VNet en een toegewezen subnet op dat is gedelegeerd aan Microsoft.App/environments. Het platform injecteert in uw subnet, waardoor lokale communicatie mogelijk is met uw persoonlijke Azure resources. Volledige controle over netwerkconfiguratie; vereist uw eigen netwerkbeheer.
Beheerd VNet (preview) Foundry beheert het VNet namens u. Eenvoudigere installatie; beperkt aanpassingsopties. Zie Het beheerde virtuele netwerk configureren voor meer informatie.

Opmerking

Voor sommige netwerkisolatiescenario's is de SDK of CLI vereist in plaats van de portal. Implementaties met privé-eindpunten die alle openbare toegang blokkeren, kunnen bijvoorbeeld niet worden geconfigureerd via de gebruikersinterface van de portal. Zie Een privékoppeling configureren voor Foundry voor meer informatie.

Tenantisolatie

Workloads worden uitgevoerd in logisch geïsoleerde omgevingen per Foundry-resource. Klantcode deelt geen runtimecontainers met andere tenants.

Veiligheid en richtlijnen voor inhoud

Foundry integreert veiligheidsmaatregelen voor inhoud in de pijplijn voor model- en agentdeductie. Kaders definiëren risico's om te detecteren, interventiepunten om te scannen (gebruikersinvoer, uitvoer, toolaanroepen (preview) en toolreacties (preview)) en reactieacties wanneer een risico wordt gedetecteerd. Inhoudsfilters worden inline uitgevoerd met modelaanvragen en kunnen per implementatie worden geconfigureerd. Zie Overzicht van kaders en besturingselementen enernstniveaus voor inhoudsfilters voor meer informatie.

Regionale beschikbaarheid

De rekenmogelijkheden variëren per Azure regio. Beschikbaarheid van modellen, opties voor implementatietypen en functieondersteuning, zoals agents of evaluaties, kunnen verschillen tussen regio's. Controleer of uw doelregio de vereiste mogelijkheden ondersteunt voordat u deze inricht. Zie Beschikbaarheid van functies in cloudregio's voor actuele beschikbaarheid.

Gegevensopslag

Foundry biedt flexibele en veilige opties voor gegevensopslag ter ondersteuning van een breed scala aan AI-workloads.

Beheerde opslag voor het uploaden van bestanden

In de standaardinstelling gebruikt Foundry Microsoft beheerde opslagaccounts die logisch zijn gescheiden en ondersteuning bieden voor directe bestandsuploads voor bepaalde use cases, zoals OpenAI-modellen en agents, zonder dat hiervoor een door de klant verstrekt opslagaccount is vereist.

Gebruik je eigen opslag

U kunt eventueel uw eigen Azure Storage-accounts verbinden. Foundry-hulpprogramma's zoals evaluaties en batchverwerking kunnen invoer van deze accounts lezen en uitvoer naar deze accounts schrijven. Zie Bring-Your-Own Resources met de Agent-service voor meer informatie over ondersteunde scenario's.

Agentstatusopslag

  • Met de basisagent-instelling slaat de door Microsoft beheerde Agent-service threads, berichten en bestanden op in multitenant-opslag met een logische scheiding.
  • Met de installatie van de standaardagent brengt u uw eigen Azure resources mee voor alle klantgegevens, inclusief bestanden, gesprekken en vectorarchieven. In deze configuratie worden gegevens per project binnen uw opslagaccounts geïsoleerd.

Door de klant beheerde sleutelversleuteling

Standaard versleutelen Azure-diensten gegevens in rust en in transport met behulp van Microsoft-beheerde sleutels met FIPS 140-2-compatibele 256-bits AES-encryptie. Er zijn geen codewijzigingen vereist.

Als u in plaats daarvan uw eigen sleutels wilt gebruiken, moet u deze vereisten bevestigen voordat u door de klant beheerde sleutels inschakelt voor Foundry:

  • Key Vault wordt geïmplementeerd in dezelfde Azure regio als uw Foundry-resource.
  • Voorlopig verwijderen en zuiveringsbescherming zijn ingeschakeld in de Key Vault.
  • Beheerde identiteiten hebben de vereiste sleutelmachtigingen, zoals de rol Key Vault Crypto User bij het gebruik van Azure RBAC.

Gebruik je eigen Key Vault

Foundry slaat standaard alle op API-sleutels gebaseerde verbindingsgeheimen op in een beheerde Azure Key Vault. Als u liever geheimen zelf beheert, verbindt u uw sleutelkluis met de Foundry-resource. Eén Azure Key Vault verbinding beheert alle verbindingsgeheimen op project- en resourceniveau. Zie voor meer informatie hoe u een Azure Key Vault-verbinding met Foundry instelt.

Zie door de klant beheerde sleutels voor versleuteling met Foundry voor meer informatie over gegevensversleuteling.

Gegevenslocatie en -naleving

Foundry slaat alle data in rust op in de aangewezen Azure regio. Inferentiegegevens (prompts en voltooiingen) worden verwerkt volgens het implementatietype: globale implementaties kunnen worden gerouteerd naar elke Azure-regio, implementaties van gegevenszones blijven binnen de VS- of EU-zone en standaard- of regionale implementaties worden in de implementatieregio verwerkt. Zie Implementatietypen voor meer informatie. Foundry biedt geen ondersteuning voor automatische failover tussen regio's. Als uw organisatie beschikbaarheid voor meerdere regio's vereist, implementeert u afzonderlijke Foundry-resources in elke doelregio en beheert u gegevenssynchronisatie en routering op de toepassingslaag. Zie Azure compliancedocumentatie voor meer informatie over nalevingscertificering.

Architectuurbeslissingen valideren

Voordat u gaat implementeren, valideert u het volgende voor uw doelomgeving:

Verwante inhoud

  • Last updated on