Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Note
Beheerde rekenkracht in Foundry is momenteel beschikbaar als preview-versie. Deze preview wordt aangeboden zonder een service level agreement en we raden deze niet aan voor productieworkloads. Bepaalde functies worden mogelijk niet ondersteund of hebben mogelijk beperkte mogelijkheden. Zie Aanvullende gebruiksvoorwaarden voor Microsoft Azure Previews voor meer informatie.
Managed Compute (preview) is een implementatietype in Microsoft Foundry die als host fungeert voor opensource-modellen op toegewezen GPU-capaciteit zonder dat u virtuele machines hoeft in te richten, een Kubernetes-cluster hoeft te gebruiken, containerinstallatiekopieën kunt bouwen of eigenaar bent van een runtime voor modelverdiening. Microsoft is eigenaar van de GPU-topologie, runtime, containerimage en beveiligingspatches. U kiest het model, de implementatiesjabloon, de familie van de accelerator en het schaalgedrag dat past bij uw workload.
Beheerde berekening maakt gebruik van dezelfde Foundry-resource, project, eindpunt, verificatie, netwerkconfiguratie, SDK's, waarneembaarheid en factureringsoppervlak als elk ander implementatietype in Foundry. Nadat u een model met beheerde rekenkracht hebt geïmplementeerd, is uw toepassingscode hetzelfde als elk ander Foundry-model; alleen de implementatienaam wordt gewijzigd.
In dit artikel wordt het type beheerde rekenimplementatie in Foundry uitgelegd, de concepten waarmee u werkt (modelexemplaren, implementatiesjablonen, acceleratorfamilies, runtimes), de catalogus die u kunt implementeren vanaf, deductie-eindpunten, schalen, facturering en quotum, toegangsbeheer en huidige beperkingen. Zie Opensource-modellen implementeren met beheerde berekeningen voor stapsgewijze instructies.
Waar beheerde rekenresources binnen Foundry passen
Foundry biedt drie implementatietypen. Beheerde berekening is het implementatietype dat moet worden gebruikt voor opensource-modellen op toegewezen GPU-capaciteit.
| Implementatietype | Wat het bedient | Billing | Ideaal voor |
|---|---|---|---|
| Standaard betalen per token | Foundry-modellen verkocht door Azure | Per invoer- en uitvoertoken | De eenvoudigste manier om aan de slag te gaan; piekbelasting bij gehoste modellen zonder capaciteitsplanning. |
| Ingestelde doorvoer | Foundry Models verkocht door Azure | Gereserveerde doorvoereenheden | Voorspelbare, aanhoudende belasting op geselecteerde Foundry-modellen die worden verkocht door Azure met consistente latentie. |
| Volledig beheerde rekenprocessen | Opensource- en communitymodellen uit de Foundry-catalogus | Per uur, per acceleratorfamilie | Open-sourcemodellen hosten op toegewezen GPU's met door Foundry beheerde runtimes, privénetwerken en dezelfde SDK's als de andere implementatietypes. |
Alle drie de implementatietypen delen één Foundry-eindpunt, dezelfde verificatiepatronen (Microsoft Entra ID en sleutel), dezelfde SDK's, hetzelfde waarneembaarheidsoppervlak en één factuur. U kunt alle drie de implementatietypen in één Foundry-project combineren en deze aanroepen vanuit dezelfde clientcode.
belangrijke concepten
In deze sectie worden de belangrijkste concepten besproken die u moet begrijpen voordat u een beheerde rekenimplementatie gebruikt in Foundry.
Modelexemplaren
Een modelinstantie is de implementatie-eenheid in beheerde rekenkracht. U kiest niet zelf een VM-SKU of de grootte van een knooppunt; in plaats daarvan beschrijft u de werkbelasting in termen van modellen, en kiest Foundry de onderliggende GPU-topologie. Een instantie kan één accelerator of meerdere accelerators gebruiken, afhankelijk van het model en de implementatiesjabloon die u kiest. U schaalt een implementatie door het aantal modelexemplaren (de capacity waarde in de implementatie-SKU) te wijzigen.
Uitrolsjabloon
Een implementatiesjabloon is een benoemd, versiebeheerasset dat codeert hoe een specifiek model moet worden uitgevoerd. Een sjabloonpinnen:
- De serviceruntime (bijvoorbeeld vLLM of SGLang).
- De familie van de accelerator en het aantal per instantie (bijvoorbeeld één H100 80 GB of twee A100 80 GB).
- De ondersteunde contextlengte en eventuele kwantisatieopties.
- Runtimespecifieke afstemming, zoals hulpprogramma-aanroepen en redeneringsparsers, scorepad, statustests, gelijktijdigheid aanvragen en eventuele modelspecifieke contextextensie-instellingen.
Wanneer u een implementatie scriptt, verwijst u naar de sjabloon-id en verwerkt Foundry de rest. Elk model in de catalogus wordt doorgaans geleverd met verschillende sjablonen, waarbij een afweging wordt gemaakt tussen acceleratorfamilie, contextlengte en latentie versus doorvoer. In het qwen3-32b model worden bijvoorbeeld vier sjablonen naast elkaar weergegeven:
| Template | Runtime | Versneller | Context |
|---|---|---|---|
qwen--qwen3-32b--40k-nvidia-a100 |
vLLM | 1 × A100 80 GB | 40 K |
qwen--qwen3-32b--40k-nvidia-h100 |
vLLM | 1 × H100 80 GB | 40 K |
qwen--qwen3-32b--128k-nvidia-2xa100 |
vLLM | 2 × A100 80 GB | 128 K |
qwen--qwen3-32b--128k-nvidia-2xh100 |
vLLM | 2 × H100 80 GB | 128 K |
Het kiezen van een sjabloon is de enige instelling waaraan u draait voor hoe een model werkt.
Acceleratorfamilies
Beheerde rekenimplementaties richten zich op een acceleratorfamilie, niet op een specifieke SKU voor virtuele machines. De ondersteunde families zijn:
- NVIDIA A100 80 GB (
A100_80GB) - NVIDIA H100 80 GB (
H100_80GB) - AMD MI300X 192 GB (
MI_300_192GB)
Quota wordt per acceleratorfamilie per regio toegekend.
Uitvoeringstijden van modellen
Met beheerde berekening wordt elk model uitgevoerd op een ondersteunende runtime die Microsoft bouwt, scant, ondertekent en patches uitvoert. U kunt geen containers gebruiken of herbouwen. De runtimeportfolio wordt geselecteerd per modelarchitectuur:
| Runtime | Gebruiken voor | Aantekeningen |
|---|---|---|
| vLLM | LLM-server met hoge doorvoer | Continue batchverwerking, PagedAttention, tensorparallelisme, LoRA hot-swap. Standaard voor de meeste grote taalmodellen. |
| SGLang | LLM-server met gestructureerde uitvoer | JSON-, regex- en grammatica-beperkte generatie voor agentische en toolgebruikende workloads. |
| TensorRT-LLM | door NVIDIA geoptimaliseerde LLM-inferentie | NVIDIA-deductie met lage latentie voor modelfamilies waarbij TRT-LLM wint op latentie of doorvoer. |
| NVIDIA NIM | NVIDIA-inferentie-microservices | TensorRT-LLM back-end met NIM API-compatibiliteit voor door NVIDIA gepubliceerde modellen. |
| Tekstembeddings-inferentie (TEI) | Insluitingen, herrankeringen, classificaties | Accelerator-specifieke kernels voor het insluiten en ophalen van dynamische paden. |
| llama.cpp | CPU- en kleine GPU-bediening | Met GGUF gekwantiseerde modellen achter dezelfde OpenAI-compatibele API. |
| hf-serve | Visie, audio, segmentatie, andere transformers-native pijplijnen | Hugging Face's multimodelserver voor modaliteiten buiten de snelle paden voor LLM's en embeddings. |
Runtime-upgrades en CVE-patches worden automatisch toegepast op live klantimplementaties. U implementeert uw model niet opnieuw om een runtime-update op te halen.
Ondersteunde modellen
U kunt beheerde berekeningen in Foundry gebruiken om modellen te implementeren vanuit de Hugging Face Collection in de Foundry-modelcatalogus, die wordt geleverd vanuit het azure-huggingface register. Deze modellen hebben de volgende kenmerken:
- Wekelijks gecureerd en vernieuwd. Trending modellen uit het Hugging Face-ecosysteem worden continu toegevoegd wanneer de community ze publiceert. De catalogus omvat tekst-, vision-, audio- en multimodale modellen (LLM's en vision-language modellen voor chat en agents), automatische spraakherkenning (ASR), spraakomzetting, insluitingen, segmentatie en het genereren van afbeeldingen.
- Alleen SafeTensors, geen niet-vertrouwde code. Elk model in de verzameling wordt gescreend. Repositories waarvoor bij het laden Python-code van derden moet worden uitgevoerd (
trust_remote_code-patronen), worden verholpen of uitgesloten. - Vooraf voorbereide gewichten. Modelgewichten worden eenmaal opgehaald van Hugging Face, gevalideerd en opgeslagen in door Microsoft beheerde Azure-opslag in de regio's waar het model wordt aangeboden. Containerimages worden opgeslagen in een door Microsoft beheerd containerregister. Als gevolg hiervan hebben beheerde rekenimplementaties geen uitgaande netwerktoegang nodig tot Hugging Face Hub . U kunt implementeren in een volledig particulier netwerk zonder uitgaand verkeer.
- Licentiemetagegevens blijven behouden. Elke catalogusmodelkaart legt de upstream-licentie vast en geeft deze weer. Licentiebeoordeling op basis van het enterprise-distributiebeleid van Microsoft vindt plaats tijdens curatie.
Pijplijn voor modelcuratie
Elk model in de hugging Face-verzameling doorloopt een pijplijn met vijf fasen voordat het in de catalogus wordt weergegeven:
- Trendingsmodellen identificeren: Microsoft identificeert trendingmodellen op basis van communitysignalen, partneraanvragen en klantvraag.
-
Scherm voor naleving en beveiliging: elk model ondergaat licentiebeoordeling en inspectie voor
trust_remote_codepatronen en aangepaste uitvoerbare code. - Gebouwd, gescand en gepubliceerd runtime-containerimages: Gebouwd door Microsoft, gescand op CVE's, ondertekend en gepubliceerd in een door Microsoft beheerd containerregister.
- Modelgewichten uploaden naar beveiligde Azure-opslag: Gevalideerd aan de hand van de modelkaart en opgeslagen in de regio's waar het model wordt aangeboden.
- Valideren en publiceren: elke combinatie van modellen, runtime en accelerator wordt getest op API-conformiteit en -prestaties, en vervolgens gepubliceerd naar de catalogus met een implementatiepad met één klik.
Inference-eindpunten
Door een model te implementeren op beheerde rekenkracht wordt het model beschikbaar voor inferentie op hetzelfde geünificeerde Foundry-projecteindpunt dat wordt gebruikt door pay-per-token-implementaties en implementaties met ingerichte doorvoer. Het basiseindpunt heeft het patroon https://<account>.services.ai.azure.com.
Eindpuntroutes
Een beheerde compute-implementatie kan worden aangeroepen via twee routefamilies op het geïntegreerde eindpunt. De route die u kiest, is afhankelijk van of het onderliggende model en de runtime een openAI-compatibele API beschikbaar maken.
| Route | Pad | Van toepassing op: | Gedrag |
|---|---|---|---|
| Route voor beheerde implementaties (OSS) | <endpoint>/managed-deployments/<deployment-name>/ |
Alle beheerde rekenimplementaties | Werkt voor elk model dat is geïmplementeerd op beheerde berekeningen, inclusief op maat gemaakte modellen die worden verzonden met hun eigen SDK. Modellen die /chat/completions blootstellen, kunnen ook via deze route worden aangeroepen met de OpenAI SDK door de client base_url naar dit pad te laten verwijzen. |
| OpenAI-compatibele route | <endpoint>/openai/v1/ |
Beheerde rekenimplementaties waarvan de runtime een openAI-compatibele API beschikbaar maakt (bijvoorbeeld vLLM, SGLang, TensorRT-LLM, llama.cpp die chat- of insluitingen biedt) | De OpenAI SDK kan de deployment aanroepen door base_url in te stellen op dit pad en de deployment name door te geven in het veld model van de aanvraagpayload. Als een aanvraag is gericht op deze route met een implementatienaam waarvan het onderliggende model of de runtime geen ondersteuning biedt voor het openAI-compatibele oppervlak, retourneert de runtime HTTP 404. |
Belangrijkste conclusies:
- Elke beheerde compute-implementatie is bereikbaar op de
https://<account>.services.ai.azure.com/managed-deployments/<deployment-name>/route - Elke implementatie waarvan de runtime openAI-compatibel is, is ook bereikbaar op de
https://<account>.services.ai.azure.com/openai/v1/route. - Gebruik de OpenAI-route als u clientcode wilt delen met andere Foundry-implementaties.
- Gebruik de route voor beheerde implementaties voor modellen die een aangepaste SDK of niet-OpenAI-API verzenden.
Tip
Een beheerde berekeningsimplementatie met chat-voltooiingen kan ook worden toegevoegd aan een Foundry-agent als een model dat is verbonden met een beheerder en kan worden aangeroepen via de Foundry Responses-API met dezelfde OpenAI SDK, met behulp van dezelfde verificatie, eindpunt en waarneembaarheid als elk ander Foundry-model.
Eindpuntverificatie
Beheerde rekenimplementaties gebruiken dezelfde verificatiepatronen als de rest van het Foundry-eindpunt:
- Microsoft Entra ID (aanbevolen). Verwerf een token voor het
https://ai.azure.com/.defaultbereik en geef dit door als een bearer-token in deAuthorizationheader. Voor het aanroepen van een implementatie van beheerde rekenresources met Entra ID moet de aanroepende identiteit beschikken over de rol Foundry User binnen het bereik van het Foundry-account. De OpenAI SDK in tokengebaseerde modus enDefaultAzureCredentialwerken zonder configuratie die specifiek is voor beheerde rekenresources. - Account-API-sleutel. Geef de sleutel van het Foundry-account door als
Authorization: Bearer <key>. De OpenAI SDK verzendt de sleutel in dit formulier automatisch wanneer u hetapi_keyargument instelt. Sleutels verlenen dezelfde toegang voor beheerde rekenimplementaties als voor betalen per token en PTU-implementaties in hetzelfde account.
Beide verificatieopties werken op beide eindpuntroutes. Zie Send een testaanvraag verzenden voor end-to-end clientcodevoorbeelden (OpenAI SDK met Entra ID- of API-sleutel).
Scaling
U schaalt een beheerde rekenimplementatie door het aantal modelexemplaren te wijzigen. Wanneer u de capacity waarde voor de implementatie-SKU instelt, past Foundry het AANTAL GPU's dienovereenkomstig aan. Het totale aantal GPU's is gelijk aan het aantal modelinstanties vermenigvuldigd met de GPU's per exemplaar dat is gedefinieerd door de implementatiesjabloon die u hebt gekozen. Foundry vraagt u niet om de grootte van een knooppunt te wijzigen of een VM-familie te kiezen.
Facturerings-, quota- en uitrolbereiken
Beheerde rekenkracht wordt per uur per accelerator gefactureerd. In tegenstelling tot op VM's gebaseerde infrastructuur, waarbij u volledige GPU-servers huurt en betaalt voor elke GPU op de server, ongeacht of uw model deze gebruikt, brengt beheerde compute kosten per modelinstantie in rekening. Foundry stemt elk model af op het aantal GPU’s dat het daadwerkelijk nodig heeft (één, twee, vier of acht), zodat u niet betaalt voor ongebruikte versnellers die naast uw workload ongebruikt blijven. De kosten van een implementatie zijn:
Accelerators per modelinstantie × modelinstanties × draaiuren × uurtarief
Uurtarieven variëren per acceleratorfamilie (A100, H100, MI300X) en per implementatiebereik. Zie de Azure prijscalculator voor actuele prijzen.
Implementatiebereik
Beheerde rekenkracht (preview) ondersteunt momenteel globale implementatie, ingesteld via de naam GlobalManagedComputevan de implementatie-SKU. Wereldwijde implementatie biedt u de breedste capaciteit van de accelerator met het laagste tarief.
Quota
Het beheerd rekenquotum wordt per acceleratorfamilie en per regio verleend via het Foundry-quotumproces. Het beheerde rekenquotum is separate van Azure VM-quotum. Hoewel het Azure-VM-quotum een IaaS-toewijzing is die gekoppeld is aan specifieke regionale VM-SKU's, is beheerde rekenkracht een beheerd PaaS-aanbod. Bestaande Azure VM-quotum kan niet worden toegepast op een beheerde rekenprocesimplementatie.
Zie Kosten plannen en beheren voor Microsoft Foundry en Quota beheren en verhogen voor meer informatie over het bekijken van het gebruik, het toeschrijven van kosten aan een project en het aanvragen van quota.
Toegangsbeheer
Beheerde rekenkracht maakt gebruik van het RBAC-model (op rollen gebaseerd toegangsbeheer) van Foundry. De reeks bewerkingen van de Azure-resourceprovider die nodig zijn om een implementatie van beheerde compute te maken, te lezen, bij te werken en te verwijderen, worden beschreven in Op rollen gebaseerd toegangsbeheer voor Microsoft Foundry — control-plane-bewerkingen voor beheerde compute, samen met de ingebouwde rollen waarmee elke bewerking wordt verleend.
In één oogopslag:
- Bijdrager voor Cognitive Services (of Foundry Owner / Foundry Account Owner) verleent volledige bevoegdheden voor maken/lezen/bijwerken/verwijderen van beheerde rekenresource-implementaties.
- Cognitive Services-gebruiker en Foundry-gebruiker verlenen alleen-lezentoegang tot implementaties.
- Foundry Project Manager geeft leestoegang tot implementaties en acceleratorgebruiksgegevens, maar niet om deze te maken of te verwijderen.
Inferentie (gegevensvlak) op het geünificeerde Foundry-eindpunt volgt het standaard Foundry-patroon, waarbij Foundry User wordt toegewezen op het bereik van het Foundry-account om deployments aan te roepen met Microsoft Entra ID.
Limitations
Beheerde rekenkracht bevindt zich in openbare preview. Let op het volgende voordat u productieworkloads implementeert:
- Contentfilters: Ingebouwde Azure AI Content Veiligheid-filters maken geen deel uit van het beheerde rekengegevenspad in openbare preview. Als u filteren op aanvraag- of antwoordniveau nodig hebt, roept u de Azure AI Content Veiligheid API's rechtstreeks vanuit uw toepassing aan.
- Beschikbaarheid van regio's: Beheerde compute wordt uitgebracht met wereldwijd bereik. Implementaties van gegevenszones en extra regio's worden geïmplementeerd. Zie de matrix voor algemene beschikbaarheid voor de huidige dekking.
- Prijzen: uurtarieven per acceleratorfamilie en regio, gereserveerde capaciteit en toezeggingskortingen ontwikkelen zich voor beheerde rekenimplementatie in preview. Zie de Azure-prijscalculator voor actuele tarieven.