Hanterad beräkning i Microsoft Foundry (förhandsversion)

Note

Hanterad beräkning i Foundry är för närvarande i förhandsversion. Den här förhandsversionen tillhandahålls utan ett serviceavtal och vi rekommenderar det inte för produktionsarbetsbelastningar. Vissa funktioner kanske inte stöds eller kan vara begränsade. Mer information finns i Kompletterande villkor för användning av Microsoft Azure-förhandsversioner.

Hanterad beräkning (förhandsversion) är en distributionstyp i Microsoft Foundry som är värd för modeller med öppen källkod på dedikerad GPU-kapacitet utan att du behöver etablera virtuella datorer, använda ett Kubernetes-kluster, skapa containeravbildningar eller äga en modellserverkörning. Microsoft ansvarar för GPU-topologin, körmiljön, containeravbildningen och säkerhetsuppdateringarna. Du väljer den modell, distributionsmall, acceleratorfamilj och skalningsbeteende som passar din arbetsbelastning.

Hanterad beräkning använder samma Foundry-resurs, projekt, slutpunkt, autentisering, nätverkskonfiguration, SDK:er, observerbarhet och faktureringsyta som alla andra distributionstyper i Foundry. När du har distribuerat en modell med hanterad beräkning är programkoden samma som andra Foundry-modeller. endast distributionsnamnet ändras.

Den här artikeln beskriver distributionstypen för hanterad beräkning i Foundry, de begrepp som du arbetar med (modellinstanser, distributionsmallar, acceleratorfamiljer, körningar), katalogen som du kan distribuera från, slutpunkter för slutsatsdragning, skalning, fakturering och kvot, åtkomstkontroll och aktuella begränsningar. Stegvisa distributionsinstruktioner finns i Distribuera modeller med öppen källkod med hanterad beräkning.

Där hanterad beräkning passar i Foundry

Foundry erbjuder tre distributionstyper. Hanterad beräkning är den distributionstyp som ska användas för modeller med öppen källkod på dedikerad GPU-kapacitet.

Distributionstyp Vad det används till Billing Passar bäst för
Standardbetalning per token Foundry-modeller som säljs av Azure Per in- och utdatatoken Lägsta friktionsväg för att komma igång; bursty trafik på värdbaserade modeller utan kapacitetsplanering.
Provisionerad kapacitet Foundry-modeller som säljs av Azure Reserverade enheter för dataflöde Förutsägbar, varaktig belastning på utvalda Foundry-modeller som säljs av Azure med konsekvent svarstid.
Hanterad databearbetning Modeller med öppen källkod och community från Foundry-katalogen Varje timme per acceleratorfamilj Värd för modeller med öppen källkod på dedikerade GPU:er med Foundry-hanterade körningar, privata nätverk och samma SDK:er som de andra distributionstyperna.

Alla tre distributionstyperna delar en enda Foundry-slutpunkt, samma autentiseringsmönster (Microsoft Entra ID och nyckel), samma SDK:er, samma observerbarhetsyta och en enda faktura. Du kan blanda alla tre distributionstyperna i ett enda Foundry-projekt och anropa dem från samma klientkod.

Viktiga begrepp

Det här avsnittet beskriver viktiga begrepp att förstå innan du använder hanterad beräkningsdistribution i Foundry.

Modellinstans

En modellinstans är distributionsenheten i hanterad beräkning. Du väljer inte en virtuell dators SKU eller storleksanpassar en nod. I stället beskriver du arbetsbelastningen i modelltermer och Foundry väljer GPU-topologin under. En instans kan använda en accelerator eller flera, beroende på vilken modell och distributionsmall du väljer. Du skalar en distribution genom att ändra antalet modellinstanser ( capacity värdet på distributions-SKU:n).

Distribueringsmall

En distributionsmall är en namngiven, versionerad resurs som anger hur en specifik modell ska köras. En mall fäster:

  • Körningsmiljön för servering (till exempel vLLM eller SGLang).
  • Acceleratorfamiljen och antalet per instans (till exempel en H100 80 GB eller två A100 80 GB).
  • Kontextlängden som stöds och val av kvantisering.
  • Körningsspecifik justering, till exempel verktygsanrop och resonemangsparsers, bedömningssökväg, hälsoavsökningar, samtidighet av begäranden och eventuella modellspecifika inställningar för kontexttillägg.

När du skriptar en distribution refererar du till mall-ID:t och Foundry hanterar resten. Varje modell i katalogen levereras vanligtvis med flera mallar som avväger acceleratorfamilj, kontextlängd och svarstid jämfört med dataflöde. Till exempel visar modellen qwen3-32b fyra mallar sida vid sida:

Template Runtime Accelerator Sammanhang
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

Att välja en mall är det enda som styr hur en modell körs.

Acceleratorfamiljer

Hanterade beräkningsdistributioner riktar sig mot en acceleratorfamilj, inte en specifik SKU för virtuella datorer. De familjer som stöds är:

  • NVIDIA A100 80 GB (A100_80GB)
  • NVIDIA H100 80 GB (H100_80GB)
  • AMD MI300X 192 GB (MI_300_192GB)

Kvoten beviljas för varje acceleratorfamilj i varje region.

Modellkörningar

Hanterad datorkapacitet kör varje modell i en körningsmiljö för modellservering som Microsoft bygger, skannar, signerar och uppdaterar med säkerhetskorrigeringar. Du driver eller bygger inte om containrar. Körningsmiljöportföljen väljs per modellarkitektur:

Runtime Använd för Notes
vLLM LLM-servering med högt dataflöde Kontinuerlig batchbearbetning, PagedAttention, tensorparallellitet, LoRA hot-swap. Standard för de flesta stora språkmodeller.
SGLang LLM-servering med strukturerad utdata JSON, regex och grammatikbegränsad generering för agentiska och verktygsbaserade arbetsbelastningar.
TensorRT-LLM NVIDIA-optimerad LLM-servering NVIDIA-slutsatsdragning med låg latens för modellfamiljer där TRT-LLM vinner på svarstid eller dataflöde.
NVIDIA NIM NVIDIA Inference Microservices TensorRT-LLM serverdel med NIM API-kompatibilitet för NVIDIA-publicerade modeller.
Inferens för textinbäddningar (TEI) Inbäddningar, omrankare, klassificerare Acceleratorspecifika kernels för inbäddning och hämtning av frekventa sökvägar.
llama.cpp CPU- och små-GPU-drift GGUF-kvantiserade modeller bakom samma OpenAI-kompatibla API.
hf-serve Vision, ljud, segmentering och övriga pipelines som är inbyggda i Transformers Hugging Faces multimodellserver för modaliteter utanför snabbspåren för LLM och embeddings.

Körningsuppgraderingar och CVE-korrigeringar tillämpas automatiskt på live-kunddistributioner. Du behöver inte driftsätta om modellen för att få en uppdatering av körmiljön.

Modeller som stöds

Du kan använda hanterad beräkning i Foundry för att distribuera modeller från Hugging Face Collection i foundry-modellkatalogen azure-huggingface som hanteras från registret. Dessa modeller har följande attribut:

  • Kuraterad och uppdaterad varje vecka. Trendiga modeller från ekosystemet Hugging Face läggs till kontinuerligt när communityn publicerar dem. Katalogen omfattar text-, visions-, ljud- och multimodala modeller (LLM:er och visionsspråkmodeller för chatt och agenter), automatisk taligenkänning (ASR), talöversättning, inbäddningar, segmentering och bildgenerering.
  • Endast SafeTensors, ingen obetrodd kod. Varje modell i samlingen granskas. Lagringsplatser som kräver körning av Python från tredje part vid inläsningstid (trust_remote_code mönster) åtgärdas eller exkluderas.
  • Förkonfigurerade vikter. Modellvikter hämtas från Hugging Face en gång, valideras och lagras i Azure-lagring som hanteras av Microsoft i de regioner där modellen tillhandahålls. Containeravbildningar lagras i ett Microsoft-hanterat register. Därför behöver inte hanterade beräkningsdistributioner utgående nätverksåtkomst till Hugging Face Hub – du kan distribuera till ett helt privat nätverk utan utgående åtkomst.
  • Licensmetadata har bevarats. Varje modellkort i katalogen registrerar och visar den ursprungliga licensen. Licensgranskning mot Microsoft företagsdistributionsprincip sker under kurationen.

Modellhärdningspipeline

Varje modell i samlingen Hugging Face passerar genom en femstegs kurationspipeline innan den visas i katalogen:

  1. Identify trending models: Microsoft identifierar trendmodeller baserat på communitysignaler, partnerförfrågningar och kundefterfrågan.
  2. Skärm för efterlevnad och säkerhet: Varje modell genomgår licensgranskning och kontroll av trust_remote_code mönster och anpassad körbar kod.
  3. Build, skanna och publicera runtime-containeravbildningar: Byggd av Microsoft, genomsökt efter CVEs, signerad och publicerad i ett Microsoft hanterat register.
  4. Ladda upp vikter till säker Azure-lagring: Validerade mot modellkortet och lagrade i de regioner där modellen distribueras.
  5. Verifiera och publicera: Varje kombination av modell, körning och accelerator testas för API-överensstämmelse och prestanda och publiceras sedan i katalogen med en distributionssökväg med ett klick.

Inferensändpunkter

Distribution av en modell till hanterade beräkningar gör modellen tillgänglig för inferens på samma enhetliga projektslutpunkt i Foundry som används av distributioner med betalning per token och etablerad genomströmning. Basslutpunkten har mönstret https://<account>.services.ai.azure.com.

Slutpunktsvägar

En hanterad beräkningsdriftsättning kan anropas via två routningsfamiljer på den enhetliga slutpunkten. Vilken väg du väljer beror på om den underliggande modellen och körningen exponerar ett OpenAI-kompatibelt API.

Rutt Sökväg Gäller för Behavior
Hanterad distributionsväg (OSS) <endpoint>/managed-deployments/<deployment-name>/ Alla hanterade beräkningsdistributioner Fungerar för alla modeller som driftsätts i en hanterad beräkningsmiljö, inklusive skräddarsydda modeller som har ett eget SDK. Modeller som exponerar /chat/completions kan också anropas via den här sökvägen med OpenAI-SDK:t genom att rikta klientens base_url till den här sökvägen.
OpenAI-kompatibel väg <endpoint>/openai/v1/ Hanterade beräkningsdistributioner vars körning exponerar ett OpenAI-kompatibelt API (till exempel vLLM, SGLang, TensorRT-LLM, llama.cpp som betjänar chatt eller inbäddningar) OpenAI-SDK:n kan anropa distributionen genom att ställa in base_url på den här sökvägen och skicka distributionsnamnet i model-fältet i begärandenyttolasten. Om en begäran riktas mot den här rutten med ett distributionsnamn vars underliggande modell eller körmiljö inte stöder det OpenAI-kompatibla gränssnittet, returnerar körmiljön HTTP 404.

Viktiga lärdomar:

  • Varje hanterad beräkningsdistribution kan nås via routen https://<account>.services.ai.azure.com/managed-deployments/<deployment-name>/
  • Alla distributioner vars körningsmiljö är OpenAI-kompatibel kan också nås via routen https://<account>.services.ai.azure.com/openai/v1/.
  • Använd OpenAI-vägen när du vill dela klientkod med andra Foundry-distributioner.
  • Använd den hanterade distributionsvägen för modeller som skickar en anpassad SDK eller ett icke-OpenAI-API.

Tip

En hanterad beräkningsdistribution för chattkompletteringar kan också läggas till i en Foundry Agent som en administratörsansluten modell och anropas via Foundry Responses-API:et med samma OpenAI SDK samt samma autentisering, slutpunkt och observerbarhet som vilken annan Foundry-modell som helst.

Slutpunktsautentisering

Hanterade beräkningsdistributioner använder samma autentiseringsmönster som resten av Foundry-slutpunkten:

  • Microsoft Entra-ID (rekommenderas). Hämta en token för scopet https://ai.azure.com/.default och skicka med den som en bearer-token i rubriken Authorization. För att anropa en hanterad beräkningsdistribution med Entra ID måste den anropande identiteten ha rollen Foundry User på Foundry-kontots omfångsnivå. OpenAI SDK i tokenbaserat läge och DefaultAzureCredential fungerar utan någon hanterad beräkningsspecifik konfiguration.
  • Konto-API-nyckel. Skicka foundry-kontonyckeln som Authorization: Bearer <key>. OpenAI SDK skickar nyckeln i det här formuläret automatiskt när du anger api_key argumentet. Nycklar ger samma åtkomst för hanterade beräkningsdistributioner som de ger för distributioner med betalning per token och PTU-distributioner på samma konto.

Båda autentiseringsalternativen fungerar på båda slutpunktsvägarna. Information om klientkodexempel från slutpunkt till slutpunkt (OpenAI SDK med Entra ID- eller API-nyckel) finns i Send a test request.

Scaling

Du skalar en hanterad beräkningsdistribution genom att ändra antalet modellinstanser. När du anger capacity värdet för distributions-SKU:n justerar Foundry antalet GPU:er i enlighet med detta. Totalt antal GPU:er är lika med antalet modellinstanser multiplicerat med de GPU:er per instans som definierats av den distributionsmall som du valde. Foundry kräver inte att du anger storleken på en nod eller väljer en VM-familj.

Omfång för fakturering, kvot och distribution

Hanterad datorkraft faktureras timvis per accelerator. Till skillnad från VM-baserad infrastruktur, där du hyr hela GPU-servrar och betalar för varje GPU i servern oavsett om din modell använder den eller inte, debiteras hanterad beräkningskapacitet per modellinstans. Foundry anpassar storleken på varje modell till det antal GPU:er den faktiskt behöver (en, två, fyra eller åtta), så att du inte betalar för inaktiva acceleratorer som står bredvid din arbetslast. Kostnaden för en distribution är:

Acceleratorer per modellinstans × modellinstanser × drifttimmar × timpris

Timpriserna varierar beroende på acceleratorfamilj (A100, H100, MI300X) och efter distributionsomfång. Aktuell prissättning finns i priskalkylatorn Azure.

Distributionsomfång

Hanterad beräkning (förhandsversion) stöder för närvarande global distribution, som anges via distributionens SKU-namn GlobalManagedCompute. Global driftsättning ger dig störst kapacitet för acceleratorer till lägsta pris.

Quota

Kvot för hanterad beräkning beviljas för varje acceleratorfamilj i varje region via Foundry-kvotprocessen. Den hanterade beräkningskvoten är separat från Azure VM-kvoten. Även om Azure VM-kvoten är en infrastruktur-som-en-tjänst-allokering som är kopplad till specifika regionala VM-SKU:er, är hanterad beräkning ett hanterat PaaS-erbjudande. Befintlig Azure VM-kvot kan inte tillämpas på en hanterad beräkningsdistribution.

Mer information om hur du visar användning, tillskriver kostnader för ett projekt och begär kvot finns i Planera och hantera kostnader för Microsoft Foundry och Hantera och öka kvoter.

Åtkomstkontroll

Hanterad beräkning använder Foundrys rollbaserade åtkomstkontrollmodell (RBAC). Den uppsättning Azure-resursprovideråtgärder som krävs för att skapa, läsa, uppdatera och ta bort en distribution av hanterad beräkning dokumenteras i Rollbaserad åtkomstkontroll för Microsoft Foundry – styrplansåtgärder för hanterad beräkning, tillsammans med de inbyggda roller som ger behörighet för respektive åtgärd.

Snabbt:

  • Cognitive Services Contributor (eller Foundry Owner / Foundry Account Owner) ger fullständig behörighet att skapa, läsa, uppdatera och ta bort distributioner av hanterade beräkningsresurser.
  • Cognitive Services-användare och foundry-användare beviljar skrivskyddad åtkomst till distributioner.
  • Foundry Project Manager ger läsåtkomst till distributioner och acceleratoranvändningsdata, men inte skapa eller ta bort.

Inferens (dataplan) på den enhetliga Foundry-slutpunkten följer Foundrys standardmönster genom att tilldela Foundry User i Foundry-kontots omfång för att anropa driftsättningar med Microsoft Entra ID.

Limitations

Hanterad beräkning finns i offentlig förhandsversion. Observera följande innan du distribuerar produktionsarbetsbelastningar:

  • Innehållsfiltrering: Azure AI Innehållsäkerhets inbyggda filter ingår inte i datasökvägen för hanterad beräkning i den offentliga förhandsversionen. Om du behöver filtrering på begäransnivå eller svarsnivå anropar du api:erna Azure AI Innehållsäkerhet direkt från ditt program.
  • Regionstillgänglighet: Hanterad datorkapacitet lanseras med global räckvidd. Distributioner av datazoner och ytterligare regioner lanseras – se den allmänna tillgänglighetsmatrisen för aktuell täckning.
  • Priser: Timpriser per acceleratorfamilj och region, reserverad kapacitet och åtaganderabatter är under utveckling för distribution av hanterade beräkningsresurser i förhandsversion. Aktuella priser finns i Priskalkylatorn för Azure.

Relaterat innehåll

  • Last updated on