Computação gerida no Microsoft Foundry (Pré-visualização)

Computação gerida (pré-visualização) é um tipo de implementação no Microsoft Foundry que aloja modelos de código aberto em capacidade dedicada de GPUs, sem necessidade de aprovisionar máquinas virtuais, operar um cluster do Kubernetes, criar imagens de contentores ou ter um ambiente de execução para disponibilização de modelos. A Microsoft controla a topologia da GPU, o runtime, a imagem do contentor e os patches de segurança. Escolhe o modelo, o modelo de implementação, a família de aceleradores e o comportamento de escalabilidade que se adequam à sua carga de trabalho.

A computação gerida utiliza o mesmo recurso, projeto, ponto final, autenticação, configuração de rede, SDKs, observabilidade e interface de faturação do Foundry que qualquer outro tipo de implementação no Foundry. Depois de implementar um modelo com computação gerida, o código da sua aplicação é o mesmo que qualquer outro modelo Foundry; apenas o nome da implementação muda.

Este artigo explica o tipo de implementação de computação gerida no Foundry, os conceitos com os quais trabalha (instâncias de modelo, templates de implementação, famílias de aceleradores e runtimes), o catálogo a partir do qual pode implementar, os endpoints de inferência, a escalabilidade, a faturação e as quotas, o controlo de acesso e as limitações atuais. Para instruções de implementação passo a passo, veja Implementar modelos open-source com computação gerida.

Onde a computação gerida se encaixa no Foundry

A Foundry oferece três tipos de implantação. Computação gerida é o tipo de implementação a usar para modelos open-source com capacidade dedicada de GPU.

Os três tipos de implementação partilham um único endpoint Foundry, os mesmos padrões de autenticação (Microsoft Entra ID e chave), os mesmos SDKs, a mesma superfície de observabilidade e uma única fatura. Podes misturar os três tipos de deployment num único projeto Foundry e chamá-los a partir do mesmo código cliente.

Conceitos-chave

Esta secção cobre conceitos chave a compreender antes de utilizar a implementação de computação gerida no Foundry.

Instância de modelo

Uma instância de modelo é a unidade de implementação na computação gerida. Não escolhe um SKU da máquina virtual nem dimensiona um nó; em vez disso, descreve a carga de trabalho em termos do modelo, e o Foundry escolhe a topologia de GPU subjacente. Uma instância pode usar um ou vários aceleradores, dependendo do modelo e do modelo de implementação que escolher. Pode dimensionar uma implementação alterando o número de instâncias do modelo (o valor capacity no SKU da implementação).

Modelo de implementação

Um template de implementação é um ativo nomeado e versionado que codifica como um modelo específico deve correr. Um modelo de pins:

• O tempo de execução de serviço (por exemplo, vLLM ou SGLang).
• A família de aceleradores e a contagem por instância (por exemplo, um H100 de 80 GB, ou dois A100 de 80 GB).
• O comprimento do contexto suportado e quaisquer opções de quantização.
• Ajustes específicos em tempo de execução, como analisadores de chamadas de ferramentas e de raciocínio, fluxo de pontuação, verificações de estado, concorrência de pedidos e quaisquer definições de extensão de contexto específicas do modelo.

Quando scriptas uma implementação, consultas o ID do modelo e o Foundry trata do resto. Cada modelo no catálogo normalmente vem com vários modelos que trocam entre a família de aceleradores, o comprimento do contexto e a latência versus o rendimento. Por exemplo, o qwen3-32b modelo expõe quatro modelos lado a lado:

Escolher um modelo predefinido é o único controlo que ajusta como um modelo funciona.

Famílias de aceleradores

As implementações de computação gerida visam uma família de aceleradores, não um SKU específico de máquina virtual. As famílias apoiadas são:

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

São concedidas quotas para cada família de aceleradores e para cada região.

Tempos de execução dos modelos

A computação gerida executa cada modelo num ambiente de execução para disponibilização que a Microsoft cria, analisa, assina e atualiza com correções. Não operas nem reconstróis contentores. O portefólio de runtimes é selecionado consoante a arquitetura do modelo:

As atualizações do runtime e os patches de CVE são aplicados automaticamente às implementações ativas dos clientes. Não é necessário implementar novamente o teu modelo para obter uma atualização em tempo de execução.

Modelos suportados

Pode utilizar a computação gerida no Foundry para implementar modelos da Hugging Face Collection no catálogo de modelos do Foundry, disponibilizados a partir do registo azure-huggingface. Estes modelos têm as seguintes características:

• Selecionado e atualizado semanalmente. Modelos em tendência do ecossistema Hugging Face são adicionados continuamente à medida que a comunidade os publica. O catálogo abrange texto, visão, áudio e modelos multimodais (LLMs e modelos de linguagem de visão para chat e agentes), reconhecimento automático de fala (ASR), tradução de voz, embeddings, segmentação e geração de imagens.
• Apenas SafeTensors, nada de código não confiável. Todos os modelos da Coleção são avaliados. Repositórios que exigiriam a execução de Python de terceiros aquando do carregamento (trust_remote_code padrões) são corrigidos ou excluídos.
• Pesos pré-preparados. Os pesos dos modelos são obtidos do Hugging Face uma única vez, validados e armazenados no armazenamento do Azure gerido pela Microsoft nas regiões onde o modelo é disponibilizado. As imagens dos contentores estão armazenadas num registo gerido pela Microsoft. Como resultado, as implementações de computação geridas não precisam de acesso de saída à rede para o Hugging Face Hub — pode implementar numa rede totalmente privada, sem tráfego de saída.
• Metadados da licença preservados. Cada ficha de modelo do catálogo regista e apresenta a licença de origem. A revisão das licenças face à política de distribuição empresarial da Microsoft ocorre durante a curadoria.

Processo de curadoria de modelos

Cada modelo da coleção Hugging Face passa por um pipeline de curadoria em cinco etapas antes de aparecer no catálogo:

1. Identificar modelos em tendência: Microsoft identifica modelos em tendência com base em sinais da comunidade, pedidos de parceiros e procura dos clientes.
2. Verificar a conformidade e segurança: Cada modelo passa por revisão e inspeção de licenças para padrões trust_remote_code e código executável personalizado.
3. Criar, analisar e publicar imagens de contentor de runtime: Criadas pela Microsoft, analisadas quanto a CVEs, assinadas e publicadas num repositório gerido pela Microsoft.
4. Carregar os pesos para o armazenamento seguro do Azure: Validados em relação à ficha do modelo e armazenados nas regiões onde o modelo é disponibilizado.
5. Validar e publicar: Cada combinação de modelo, runtime e acelerador é testada quanto à conformidade e desempenho da API, sendo depois publicada no catálogo com um caminho de deployment com um clique.

Pontos de extremidade de inferência

A implementação de um modelo para computação gerida torna o modelo disponível para inferência no mesmo endpoint unificado do projeto Foundry usado pelas implementações pay-per-token e throughput provisionado. O ponto final base tem o padrão https://<account>.services.ai.azure.com.

Rotas de terminais

Uma implantação de computação gerida pode ser invocada através de duas famílias de rotas no endpoint unificado. A rota que escolher depende se o modelo subjacente e o runtime expõem uma API compatível com OpenAI.

Conclusões principais:

• Cada implementação de computação gerida pode ser acedida através da rota https://<account>.services.ai.azure.com/managed-deployments/<deployment-name>/
• Qualquer implantação cujo ambiente de execução seja compatível com OpenAI também pode ser acedida através da rota https://<account>.services.ai.azure.com/openai/v1/.
• Use a via OpenAI quando quiser partilhar código de cliente com outras implementações do Foundry.
• Use a rota de implementações geridas para modelos que enviem um SDK personalizado ou API não-OpenAI.

Autenticação de terminal

As implementações de computação gerida utilizam os mesmos padrões de autenticação que o resto do endpoint Foundry:

• Microsoft Entra ID (recomendado). Adquira um token para o https://ai.azure.com/.default escopo e passe como token de portador no Authorization cabeçalho. Para chamar uma implementação de computação gerida com o Entra ID, a identidade de chamada tem de ter a função Foundry User no âmbito da conta do Foundry. O SDK OpenAI está em modo baseado em tokens e DefaultAzureCredential funciona sem qualquer configuração específica de computação gerida.
• Chave API da conta. Passe a chave da conta Foundry como Authorization: Bearer <key>. O SDK OpenAI envia automaticamente a chave nesta forma quando defines o api_key argumento. As chaves concedem o mesmo acesso em implementações de computação gerida que em implementações pay-per-token e PTU na mesma conta.

Ambas as opções de autenticação funcionam nas duas rotas do endpoint. Para exemplos de código cliente de ponta a ponta (SDK OpenAI com Entra ID ou chave API), veja Enviar um pedido de teste.

Scaling

Escala-se uma implementação de computação gerida alterando o número de instâncias do modelo. Quando defines o capacity valor no SKU de implementação, o Foundry ajusta a contagem da GPU em conformidade. O total de GPUs é igual ao número de instâncias de modelo multiplicado pelas GPUs por instância definidas pelo template de implementação que escolheste. A Foundry não lhe pede para definir a dimensão de um nó nem escolher uma família de VMs.

Faturação, quotas e âmbito de implementação

A computação gerida é faturada por hora e por acelerador. Ao contrário da infraestrutura baseada em VM, em que alugas servidores completos com GPU e pagas por cada GPU do servidor, quer o teu modelo a utilize ou não, a capacidade de computação gerida é cobrada por instância de modelo. A Foundry dimensiona corretamente cada modelo para o número de GPUs de que realmente necessita (uma, duas, quatro ou oito), para que não pague por aceleradores inativos ao lado da sua carga de trabalho. O custo de uma implementação é:

Aceleradores por instância do modelo × instâncias do modelo × horas de execução × taxa horária

As tarifas horárias variam consoante a família de aceleradores (A100, H100, MI300X) e o âmbito de implantação. Para preços atuais, consulte a calculadora de preços Azure.

Âmbito da implementação

A computação gerida (pré-visualização) suporta atualmente a implementação Global, definida através do nome SKU da implementação GlobalManagedCompute. A implementação global dá-lhe a maior capacidade de aceleração à taxa mais baixa.

Quota

A quota de computação gerida é concedida para cada família de aceleradores, em cada região, através do processo de quota da Foundry. A quota de computação gerida é separada da quota Azure VM. Enquanto a quota de VM do Azure é uma alocação de infraestrutura como serviço ligada a SKUs regionais específicos de VM, a computação gerida é uma oferta PaaS gerida. A quota existente de VM do Azure não pode ser aplicada a uma implementação de computação gerida.

Para detalhes sobre visualização, atribuição de custos a um projeto e pedido de quotas, consulte Planear e gerir custos para Microsoft Foundry e Gerenciar e aumentar quotas.

Controlo de acesso

A computação gerida utiliza o modelo de controlo de acesso baseado em funções (RBAC) da Foundry. O conjunto de operações do fornecedor de recursos do Azure necessário para criar, consultar, atualizar e eliminar uma implementação de computação gerida está documentado em Controlo de acesso baseado em funções para o Microsoft Foundry — operações do plano de controlo da computação gerida, juntamente com as funções incorporadas que concedem permissões para cada operação.

De relance:

• Cognitive Services Contributor (ou Foundry Owner / Foundry Account Owner) concede permissões completas de criação/leitura/atualização/eliminação nas implementações de computação gerida.
• Utilizador dos Serviços Cognitivos e Utilizador do Foundry concedem acesso só de leitura às implementações.
• Foundry Project Manager concede acesso de leitura a implementações e a dados de utilização de aceleradores, mas não cria ou elimina.

A inferência (plano de dados) no endpoint unificado do Foundry segue o padrão padrão do Foundry, atribuindo Foundry User no âmbito da conta Foundry para chamar implementações com Microsoft Entra ID.

Limitações

A computação gerida está em versão prévia pública. Note o seguinte antes de implementar cargas de trabalho em produção:

• Filtragem de conteúdo: Os filtros incorporados do Segurança de conteúdo de IA do Azure não fazem parte do percurso de dados da computação gerida durante a pré-visualização pública. Se precisar de filtragem ao nível de pedido ou de resposta, ligue diretamente para as APIs Segurança de conteúdo de IA do Azure diretamente da sua aplicação.
• Disponibilidade de região: Lançamentos de computação gerida com âmbito global. As implantações de Zonas de Dados e regiões adicionais estão a ser implementadas — consulte a matriz de disponibilidade geral para a cobertura atual.
• Preços: As tarifas horárias por família de aceleradores e região, capacidade reservada e descontos de compromisso estão a evoluir para a implementação de computação gerida em pré-visualização. Para as taxas atuais, consulte a calculadora de preços Azure.

Conteúdo relacionado

• Implementar modelos open-source com computação gerida
• Visão geral da implementação para os Modelos Microsoft Foundry
• Controlo de acesso baseado em funções para Microsoft Foundry
• Planeie e gere custos para Microsoft Foundry
• Gerir e aumentar as quotas
• Autenticação e autorização na Foundry