TL;DR\nO Managed Compute da Microsoft Foundry remove a sobrecarga operacional de executar modelos open source em GPUs. Você escolhe o modelo, o template de deployment e a família de aceleradores (A100, H100, MI300X), e a plataforma gerencia o restante: roteamento, escalabilidade, patches de segurança e observabilidade. Para empresas brasileiras, significa reduzir a dependência de equipes especializadas em infraestrutura, acelerar o time-to-market e controlar custos com faturamento por acelerador, sem abrir mão de compliance e privacidade.\n\n## O que muda com o Managed Compute?\nA Microsoft Foundry acaba de anunciar o Managed Compute, uma plataforma gerenciada para customizar e servir modelos de IA open source em capacidade GPU elástica – sem que sua equipe precise operar máquinas virtuais, clusters Kubernetes ou runtimes de inferência. O Managed Compute reúne três componentes em uma experiência única: o catálogo de modelos do Foundry, os runtimes e frameworks que servem esses modelos, e a capacidade GPU subjacente. É aberto por design: acesso a milhares de modelos open source via parceria com Hugging Face, customização com fine-tuning supervisionado ou reinforcement learning, e deploy seguro de pesos treinados em outro lugar.\n\nJunto com o modelo pay-per-token (ponto de partida de menor atrito) e o provisioned throughput (carga previsível em produção para modelos frontier), o Managed Compute completa o Microsoft Foundry como uma plataforma única para servir modelos de IA em escala: frontier, open source e customizados – tudo por um único endpoint, um conjunto de SDKs e uma única fatura.\n\n## Onde o Managed Compute se encaixa no Foundry?\nO Foundry possui três tipos de deployment. O Managed Compute é o construído para modelos open source e customizados em capacidade GPU dedicada.\n\n| Tipo de deployment | O que serve | Faturamento | Ideal para |\n|-------------------|-------------|-------------|------------|\n| Pay-per-token | Modelos first-party (Azure Direct), incluindo Azure OpenAI | Por token de input e output | Ponto de partida de baixo atrito; tráfego intermitente em modelos hospedados sem planejamento de capacidade |\n| Provisioned throughput units (PTU) | Modelos first-party (Azure Direct) | Unidades de throughput reservadas | Carga previsível e sustentada em modelos first-party com latência consistente |\n| Managed Compute | Modelos open source e da comunidade do catálogo Foundry | Por hora por família de acelerador | Hospedar modelos open source em GPUs dedicadas com runtimes gerenciados, rede privada e os mesmos SDKs dos demais tipos |\n\n## Por que modelos open source, por que agora?\nA IA open source amadureceu rapidamente. Os melhores modelos abertos hoje igualam os modelos frontier em benchmarks de raciocínio, codificação e instrução. Uma nova geração de modelos pequenos especializados está atingindo qualidade state-of-the-art em tarefas focadas (entendimento de documentos, re-ranking, code completion, chat de domínio específico) com fração do custo e latência de modelos grandes de propósito geral. O padrão entre empresas é consistente: times usam APIs gerenciadas para inovação rápida em inteligência frontier, depois trazem modelos abertos e customizados para rotas onde precisam de mais controle sobre comportamento, customização, residência de dados e custo.\n\nO que faltava era uma maneira fácil de executar esses modelos abertos em produção. Hoje, isso geralmente significa montar uma stack do zero: provisionar VMs GPU, subir e operar Kubernetes, configurar rede e autenticação, escolher e operar um runtime de inferência, endurecer containers, aplicar patches de CVEs e construir observabilidade e atribuição de custos do zero. Mesmo quando uma equipe consegue fazer tudo isso, o resultado frequentemente subutiliza GPUs caras, carece de padrões avançados de serving (como disaggregated prefill/decode) e trava workloads em SKUs e regiões específicas, lentas e caras de migrar. O Managed Compute foi construído para tirar esse trabalho do seu time – o foco é o modelo, não a infraestrutura.\n\n## Modelos, não máquinas: a plataforma GPU como serviço do Foundry\nCom o Managed Compute, a unidade de deployment é o modelo, não a máquina. Na prática, isso significa:\n\n### Fim da dor de dimensionamento de VMs GPU\nColocar um modelo open source em infraestrutura GPU bruta dá trabalho real: você precisa avaliar arquitetura do modelo (dense vs. mixture-of-experts), quantidade de parâmetros, memória KV-cache, paralelismo tensor vs. data parallelism e quantização, mapeando tudo para uma SKU de VM com o número e classe certos de GPUs. As VMs da família ND do Azure vêm com oito GPUs fixas por nó, então você precisa empacotar vários modelos em um nó – ou deixar aceleradores ociosos. O Managed Compute remove esse trabalho: você escolhe três coisas – um modelo, um template de deployment e uma família de aceleradores (A100, H100, MI300X) – e o Foundry provisiona o número certo de GPUs. O template codifica runtime, contagem de GPUs, comprimento de contexto, quantização e o ajuste de latência vs. throughput necessário para servir bem o modelo.\n\nA cota é rastreada por família de acelerador (H100_80GB, A100_80GB, MI_300_192GB) no recurso do Foundry, separada da cota de VM do Azure.\n\n### Escalonamento com roteamento cache-aware: maior throughput, menor latência\nAdicione mais instâncias de modelo para aumentar a capacidade de tokens do seu deployment. Todas as instâncias ficam atrás de uma única URL de endpoint, e o Foundry roteia entre elas com três inteligências:\n\n- Balanceamento de carga ciente de concorrência: as requisições são distribuídas com base no número de requests em andamento em cada instância.\n- Affinity de prefixo de prompt para cache hits: o Foundry faz hash do prefixo de cada requisição na borda e roteia requisições com o mesmo prefixo (system prompts compartilhados, definições de ferramentas, contexto RAG) para a mesma instância, mantendo o KV cache quente e o time-to-first-token baixo.\n- Affinity de sessão multi-turn: ao enviar um identificador de sessão, o Foundry mantém as interações de um usuário na mesma instância, acumulando ganhos de cache ao longo da sessão.\n\nTodos os três são controlados por soft affinity com limites de carga. Quando a instância preferida atingir o limite, o request é desviado para outra. Você obtém localidade de cache e carga equilibrada sem escrever um load balancer.\n\n### Contêineres e upgrades de runtime, in-place\nAs stacks de serving open source evoluem rápido: novas versões de runtime são lançadas a cada poucas semanas; CVEs no model server, imagem base e camadas CUDA surgem continuamente. Em DIY, cada patch é problema seu: reconstruir container, retestar, redeploy, drenar tráfego, tentar novamente. O Managed Compute aplica upgrades de container e runtime em deployments ativos em segundo plano (em runtimes suportados), entregando patches de segurança e melhorias sem que você precise redeployar.\n\n<div class="inline-cta"><a href="/contact">Quer reduzir o custo operacional da sua IA na nuvem? Converse com a Nuvem Online e descubra como otimizar seu ambiente.
\n\n## Um recurso Foundry, três tipos de deployment\nO Managed Compute convive com pay-per-token e provisioned throughput no mesmo recurso Foundry, unificando as experiências de administração, desenvolvimento e observabilidade:\n\n-
Experiência de administração: um único recurso Foundry para configurar e governar toda a hospedagem de modelos (frontier, open source, custom). RBAC, rede privada, identidade, gestão de custos e auditoria são configurados uma vez e aplicados a todos os deployments. Menor pegada de infraestrutura = menor custo operacional e melhor TCO.\n-
Experiência do desenvolvedor: uma única superfície de API para inferência. Os mesmos SDKs, mesma autenticação, mesma URL de endpoint. Trocar de um modelo frontier para um aberto significa apenas alterar o parâmetro 'model' para o nome do novo deployment; o código cliente, auth e observabilidade permanecem os mesmos. Deployments open source integram-se ao Foundry Agents e Responses API da mesma forma que modelos frontier.\n-
Experiência de observabilidade: uma única superfície do Azure Monitor para todos os deployments. Taxas de requisição, percentis de latência (TTFT, TBT), uso de tokens e tags de faturamento por deployment fluem para as mesmas métricas do Azure Monitor, Log Analytics e dashboards Grafana, sejam frontier, open source ou customizados. Um conjunto de alertas, um modelo de atribuição de custos, um lugar para olhar quando algo der errado.\n\nIsso funciona porque o Managed Compute roda na mesma plataforma Kubernetes de hiperscala que alimenta pay-per-token e provisioned throughput no Foundry. O roteamento, escalonamento, multi-tenancy e a malha operacional que servem modelos frontier são a mesma malha que serve seus modelos abertos e customizados. A menos que você esteja executando uma arquitetura de modelo profundamente customizada com seu próprio runtime, a economia de TCO e imposto DIY é substancial – ainda mais considerando que as GPUs do Foundry têm preço equivalente às VMs GPU equivalentes do Azure.\n\n## Deploy e scoring de um modelo de pesos abertos\nA Hugging Face Collection no Foundry Model Catalog é o ponto de partida: um conjunto curado de modelos open-weight com cards de modelo espelhados, metadados de licença preservados e um caminho com um clique da página do modelo Hugging Face para um deployment no Managed Compute. O que você deploya é o mesmo modelo open-weight que a comunidade publica – avaliações e comportamento se mantêm. O que muda é a camada operacional: um container curado e endurecido em um runtime validado, com patches de CVE, isolamento e identidade, rede e governança do Azure aplicados por padrão.\n\nA partir daí, o deployment segue cinco passos:\n\n1. Navegue pelo catálogo e escolha um modelo. O wizard de deploy também expõe o model id, deployment template id e acceleratorType necessários se você for scriptar o deploy via SDK ou REST.\n2. Escolha um deployment template (otimizado para latência ou throughput, família de acelerador, comprimento de contexto, quantização).\n3. Configure o número de instâncias para escalar o throughput.\n4. Faça o deploy pelo portal, CLI, SDK ou REST.\n5. Faça o scoring via endpoint unificado do Foundry com o SDK que você já usa.\n\n### Deployment templates\nUm deployment template é a unidade de escolha no passo 2: um asset nomeado e versionado que define o runtime, a família e contagem de aceleradores, o comprimento de contexto e o ajuste específico do runtime para servir bem o modelo. Escolher um template é o único ajuste que você faz para definir "como quero que este modelo seja executado".\n\nPor exemplo, o qwen3-32b oferece quatro templates lado a lado no wizard:\n\n| Template | Runtime | Acelerador | Contexto |\n|----------|---------|------------|----------|\n| qwen–qwen3-32b–40k-nvidia-a100 | vLLM | 1 × A100 80 GB | 40K |\n| qwen–qwen3-32b–40k-nvidia-h100 | vLLM | 1 × H100 80 GB | 40K |\n| qwen–qwen3-32b–128k-nvidia-2xa100 | vLLM | 2 × A100 80 GB | 128K |\n| qwen–qwen3-32b–128k-nvidia-2xh100 | vLLM | 2 × H100 80 GB | 128K |\n\nCada template chega pré-ajustado para o modelo: configurações de runtime, parsers de tool-call e reasoning, caminho de scoring, health probes, concorrência de requisições e quaisquer extensões de contexto específicas do modelo são definidas pela Microsoft, com compensações explicitadas na descrição do template. Ao scriptar o deploy, você referencia o template e o Foundry cuida do resto.\n\n### SDK\n
python\nfrom azure.identity import DefaultAzureCredential\nfrom azure.mgmt.cognitiveservices import CognitiveServicesManagementClient\n\nclient = CognitiveServicesManagementClient(DefaultAzureCredential(), SUBSCRIPTION_ID)\n\ndeployment = client.managed_compute_deployments.begin_create_or_update(\n resource_group_name=RESOURCE_GROUP,\n account_name=ACCOUNT_NAME,\n deployment_name=\"qwen3-32b\",\n resource={\n \"sku\": {\"name\": \"GlobalManagedCompute\", \"capacity\": 1},\n \"properties\": {\n \"model\": \"azureml://registries/azure-huggingface/models/qwen--qwen3-32b/versions/1\",\n \"deploymentTemplate\": \"azureml://registries/azure-huggingface/deploymenttemplates/qwen--qwen3-32b--40k-nvidia-h100/labels/latest\",\n \"acceleratorType\": \"H100_80GB\",\n },\n },\n).result()\n\nAs três propriedades mapeiam as três escolhas:
model é o que você serve,
deploymentTemplate define runtime e contagem de GPUs,
acceleratorType escolhe a família de aceleradores. É uma família de acelerador, não uma SKU de VM. O Foundry dimensiona o nó internamente.\n\n### Scoring\nObtenha o endpoint e a chave de API na página de detalhes do deployment no portal do Foundry, ou programaticamente com o mesmo management client:\n
python\napi_key = client.accounts.list_keys(RESOURCE_GROUP, ACCOUNT_NAME).key1\nendpoint = f\"https://{ACCOUNT_NAME}.services.ai.azure.com/openai/v1\"\n\nDepois chame com o OpenAI SDK. O campo
model recebe o nome do deployment definido no
begin_create_or_update:\n
python\nfrom openai import OpenAI\n\nopenai_client = OpenAI(base_url=endpoint, api_key=api_key)\n\ncompletion = openai_client.chat.completions.create(\n model=deployment.name,\n messages=[{\"role\": \"user\", \"content\": \"What is the capital of France?\"}],\n)\n\nprint(completion.choices[0].message)\n\nMesma autenticação, rede e managed identity que qualquer outro deployment do Foundry. Se você já chama modelos frontier por um endpoint Foundry, deployments do Managed Compute aparecem atrás da mesma URL com as mesmas credenciais.\n\n### Use deployments do Managed Compute com Foundry Agents e Responses API\nUm deployment do tipo chat-completions no Managed Compute pode ser integrado ao Foundry Agents hoje como um modelo conectado via admin, seja pelo botão "Add to agent" na página de detalhes, seja seguindo o padrão de API Management gateway documentado em learn.microsoft.com/azure/foundry/agents/how-to/ai-gateway. A integração nativa com Foundry Agents (que remove esse passo extra) está a caminho.\n\nUma vez conectado, você chama o agente via Foundry Responses API com um
agent_reference:\n
python\nfrom azure.identity import DefaultAzureCredential\nfrom azure.ai.projects import AIProjectClient\n\nproject_client = AIProjectClient(\n endpoint=\"https://<your-resource>.services.ai.azure.com/api/projects/<your-project>\",\n credential=DefaultAzureCredential(),\n)\nopenai_client = project_client.get_openai_client()\n\nagent_ref = {\"name\": \"my-agent\", \"version\": \"1\", \"type\": \"agent_reference\"}\n\nr1 = openai_client.responses.create(\n input=[{\"role\": \"user\", \"content\": \"My favorite color is teal and my dog's name is Mochi.\"}],\n extra_body={\"agent_reference\": agent_ref},\n)\nprint(r1.output_text)\n\nA memória da conversa é server-side: você não precisa gerenciar histórico no cliente. Encadeie turnos passando o
previous_response_id:\n
python\nr2 = openai_client.responses.create(\n input=[{\"role\": \"user\", \"content\": \"What is my favorite color and my dog's name?\"}],\n extra_body={\"agent_reference\": agent_ref},\n previous_response_id=r1.id,\n)\nprint(r2.output_text)\n# -> \"Your favorite color is teal, and your dog's name is Mochi.\"\n\nRemova o
previous_response_id e o agente começa uma nova conversa.\n\n## Observabilidade e performance\nTodo deployment do Managed Compute emite automaticamente métricas do Azure Monitor, sem agente, instrumentação de cliente ou mudanças no SDK. Elas cobrem os três aspectos essenciais em produção:\n\n| Família | O que cobre |\n|---------|------------|\n| HTTP requests | Volume e disponibilidade de requisições |\n| Latency | Tempo de resposta ponta a ponta, time-to-first-token e inter-token decode time |\n| Usage | Contagens de tokens de input, output e total |\n\nEssas métricas se integram ao stack de monitoramento do Azure que você já usa: portal Metrics, Log Analytics (KQL), dashboards Grafana ou qualquer outro consumidor do Azure Monitor.\n\n## Preços, faturamento e residência de dados\nDiferente de infraestrutura baseada em VM, onde você aluga servidores GPU inteiros e paga por cada GPU da máquina, o Managed Compute cobra por instância de modelo. O Foundry dimensiona cada modelo para as GPUs que ele realmente precisa (1, 2, 4 ou 8), eliminando o custo de aceleradores ociosos. O faturamento é por hora por acelerador, e o custo total é
aceleradores por instância × número de instâncias × horas rodando × taxa horária.\n\n### Global vs. Data Zone: escolha o escopo no momento do deploy\nCada deployment do Managed Compute roda em um de dois escopos, selecionados via SKU do deployment:\n\n-
Global Managed Compute (
GlobalManagedCompute): a capacidade mais ampla e a menor taxa horária. Escolha padrão para a maioria dos workloads. Disponível no lançamento.\n-
Data Zone Managed Compute (
DataZoneManagedCompute): a mesma plataforma gerenciada, com tráfego e processamento mantidos dentro de uma zona de dados definida para requisitos de residência e soberania. Em breve, com um pequeno prêmio sobre o Global.\n\n| Medidor | Global Managed Compute ($/hr/GPU) |\n|---------|----------------------------------|\n| A100 80GB | $3,95 |\n| H100 80GB | $7,91 |\n| MI300X 192GB (em breve) | $7,91 |\n\nOs gastos aparecem no Azure Cost Management junto com o resto do uso do Foundry.\n\n## Segurança, identidade e rede prontas para empresa\nO Managed Compute faz parte do seu projeto Foundry e da sua assinatura Azure. Os mesmos controles que você já aplica a outros recursos do Azure se aplicam aos deployments do Managed Compute:\n\n- Autenticação via Microsoft Entra ID para control plane e data plane. Managed identities suportadas para chamadas serviço a serviço, eliminando chaves estáticas.\n- Azure RBAC para quem pode criar, modificar, escalar ou invocar deployments.\n- Rede privada via Azure Private Link e private endpoints, com integração VNet gerenciada pelo cliente para tráfego de saída.\n- Azure Policy para guardrails (allow-listing de modelos ou famílias de acelerador, tags obrigatórias, restrições de região) com Activity Log e diagnostic settings para trilhas de auditoria.\n\n## Conclusão e próximos passos\nDisponível agora em preview: faça deploy de qualquer modelo base do catálogo Foundry nos aceleradores A100 ou H100 no escopo Global, atrás de um endpoint unificado do Foundry, com suporte a Playground, métricas do Azure Monitor, tags de faturamento por deployment e upgrades de runtime e patches de CVEs curados.\n\nNo roadmap: escopo Data Zone e aceleradores MI300X para maior escolha de residência e hardware; Bring Your Own Weights (pesos completos e adaptadores LoRA) com os mesmos templates e governança; e modelos protegidos por IP com sobretaxa opcional do publisher.\n\nCom o Managed Compute, modelos frontier, proprietários e open source vivem atrás de um único endpoint Foundry, uma única superfície SDK e uma única fatura. A complexidade operacional que tornava modelos abertos a escolha mais difícil desapareceu.\n\n## Perguntas Frequentes\n-
O que é o Managed Compute na Microsoft Foundry?\n Resposta: É uma plataforma gerenciada para customizar e servir modelos de IA open source em GPU elástica, sem a necessidade de operar VMs, clusters Kubernetes ou runtimes de inferência. A Microsoft cuida do provisionamento, escalabilidade, patches de segurança e observabilidade.\n\n-
Como funciona a precificação do Managed Compute?\n Resposta: O faturamento é por hora por acelerador (GPU), de acordo com o modelo e a família escolhida (A100, H100, MI300X). Não se paga por GPUs ociosas – a plataforma aloca exatamente o número de GPUs que o modelo precisa. Há dois escopos: Global (mais barato) e Data Zone (para requisitos de residência de dados).\n\n-
Posso usar minhas próprias chaves de criptografia e redes privadas?\n Resposta: Sim. O Managed Compute é integrado ao Microsoft Entra ID para autenticação, suporta managed identities, Azure RBAC, Azure Private Link, VNet integration e Azure Policy. Os mesmos controles de segurança aplicados a outros recursos do Azure se aplicam automaticamente.\n\n-
Como integrar o Managed Compute com deployments existentes do Foundry?\n Resposta: Ele coexiste com Pay-per-token e Provisioned Throughput no mesmo recurso do Foundry. Um único endpoint, SDKs e superfície de observabilidade atendem modelos frontier, open source e customizados. A troca entre modelos é feita apenas alterando o parâmetro 'model' no código cliente.\n\n-
Quais modelos open source estão disponíveis no catálogo?\n Resposta: Milhares de modelos são acessíveis via parceria com Hugging Face, incluindo Qwen3-32B, Llama, Mistral e outros. O catálogo inclui modelos curados com templates de deployment pré-ajustados para latência ou throughput, em diferentes contextos e quantizações.\n\n---\n
Artigo originalmente publicado por Manoj Bableshwar em Azure Updates - Latest from Azure Charts.
