A Microsoft anunciou a expansão do Foundry Local com suporte a single-node no Azure Local, agora em Public Preview. Este movimento é um passo importante para empresas brasileiras que operam em setores industriais, mineração, energia ou manufatura, onde a dependência de conectividade cloud constante para processos críticos de tomada de decisão é um risco inaceitável.
Historicamente, a inferência de modelos de IA exigia uma conexão estável ou arquiteturas multi-node complexas. Com essa atualização, o Foundry Local permite rodar modelos de IA diretamente no nível de máquina — seja no factory floor, em gabinetes elétricos ou em unidades remotas — mantendo a consistência operacional do ecossistema Azure e a governança via Azure Arc.
Principais recursos desta preview
O Foundry Local expõe APIs padrão REST e compatíveis com OpenAI, facilitando a integração para times de TI e engenharia de IA que já utilizam padrões de desenvolvimento cloud-aligned. Os destaques da preview incluem:
- Azure Arc extension para Foundry Local: Gerenciamento, configuração, updates e workloads de governança simplificados através do portal do Azure.
- Catálogo de modelos: Deployment nativo de modelos generativos através de control-plane API requests.
- Suporte a OCI registries: Capacidade de rodar modelos preditivos personalizados (formato ONNX) mantidos em registros próprios do cliente.
- Endpoints de inferência: Consumo via HTTP para modelos generativos e preditivos.
- Orquestração Multi-model: Permite o uso de múltiplos modelos locais dentro de um cluster único, ideal para aplicações onde um modelo generativo atua como orquestrador de modelos preditivos.
O deployment em single-node no Azure Local garante:
- Hardware validado: Utilização de nodes compactos (formato 1U) ou robustos, listados no catálogo do Azure Local.
- AKS on Azure Local: O Foundry Local é executado como um workload containerizado gerenciado por Kubernetes, mantendo o padrão operacional.
- GPU Access: Acesso facilitado via NVIDIA device plugin no AKS, permitindo que o ONNX Runtime utilize GPUs de forma direta, sem a necessidade de configurações complexas no sistema operacional host.
Opções de instalação para single node
A escolha entre as duas abordagens depende do nível de autonomia que sua operação exige:
- Arc-enabled Kubernetes Extension (Recomendado para TI/OT): Ideal quando a organização busca que a Microsoft gerencie o deployment lifecycle (updates, health monitoring, configuration drift detection). É a via de menor sobrecarga operacional, eliminando a necessidade de gerenciar Helm releases via
kubectl.
- Helm Chart (Recomendado para Engenharia de Plataforma e GitOps): Indicado se o seu time já domina Helm ou Flux e necessita de controle granular sobre alocação de memória GPU, node affinity ou StorageClass para o cache de modelos. É a escolha adequada para cenários multissítio onde você deseja centralizar updates via repositório Git.
Cenários de uso e impacto
Nossa análise consultiva aponta que a grande vantagem está na soberania operacional. Em ambientes industriais brasileiros de infraestrutura crítica, a capacidade de o Foundry Local tratar exceções locais (como falhas de WAN) é mandatória. O uso do Qwen2.5-7B, por exemplo, rodando em AKS localmente com consumo de VRAM otimizado, permite que equipes de campo consultem manuais de segurança ou workflows LOTO (Lockout/Tagout) mesmo em locais com isolamento de rede total.
Comparativo: Dispositivos vs. Azure Local
É fundamental distinguir o Foundry Local para dispositivos (focado em desenvolvimento/estação de trabalho) desta versão.* O release para Azure Local é uma infraestrutura de produção, pensada para que múltiplos workloads consumam um único endpoint de inferência, com resiliência garantida por Kubernetes.
Para as empresas brasileiras, a integração com o Azure Arc é o ponto chave para manter o compliance e a visibilidade centralizada (Observability) sem sacrificar o desempenho da latência local.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.