Model Router do Azure Foundry vai de 2 para 28 regiões e troca modelos sem redeploy

A Microsoft expandiu o model router do Foundry Models de duas regiões para 28 em deployments global standard, e para 21 em data zone deployments, segundo reportagem do InfoQ. Até esta atualização, o roteador só rodava em East US 2 e Sweden Central. Junto com o alcance geográfico, o pool de modelos que ele escolhe também foi renovado.

O model router é um endpoint único que decide, a cada requisição, qual modelo de fundação atende melhor àquela chamada, otimizando entre custo, qualidade e latência sem que a aplicação precise saber qual modelo respondeu. Para quem constrói software no Brasil, essa expansão regional é o detalhe que sai do abstrato: passa a ser possível manter inferência dentro de fronteiras geográficas específicas por razões regulatórias, de governança ou de confiança do cliente, algo que duas regiões nos EUA e na Suécia não resolviam.

O que entrou e o que saiu do pool

A renovação de modelos foi na mesma leva. O pool ganhou o Anthropic Claude Opus 4.8 e a família GPT-5.6, e perdeu quatro modelos que chegaram ao fim de vida.

Segundo Sanjeev Jagtap, ao anunciar a atualização, o ponto central é justamente não precisar fazer nada:

O detalhe mais importante é o que você não precisa fazer: essas atualizações acontecem automaticamente. O endpoint permanece estável enquanto o pool de modelos suportados é renovado, então os times não precisam refazer o deploy do model router para receber a atualização.

Sanjeev Jagtap, Microsoft

Estabilidade de API não é estabilidade de comportamento

Aqui mora a parte que o anúncio deixa implícita e que o InfoQ traz à tona. Christos Panagiotidis, Azure↳Azure76 conteúdosDeploy de Azure Stream Analytics job com CI/CD usando Azure PipelinesDevSecOps · mai 2019Azure – Como criar uma base de dados SQL no Microsoft Azure pronta para ser utilizadaData · abr 2019Azure Static Web Apps com Vue.js e Visual Studio CodeDevSecOps · out 2023Ver tudo em DevSecOps → MVP e engenheiro de cloud, faz a distinção que o texto oficial não faz:

Estabilidade de API e estabilidade de comportamento são coisas diferentes.

Christos Panagiotidis, Azure MVP

Na prática, um modelo novo no pool pode mudar estilo de resposta, comportamento de seleção de ferramentas, confiabilidade de saída estruturada, distribuição de latência, uso de tokens, padrão de recusa e modo de falha. Como ele resume: o schema da resposta pode continuar idêntico enquanto o resultado de negócio da aplicação muda.

Para uma implantação padrão, a promessa de Jagtap é verdadeira: o model router opera em modo Balanced sobre todo o conjunto suportado, salvo configuração contrária. Ou seja, um workload no default agora tem dois candidatos que nunca avaliou e quatro que talvez estivesse usando e sumiram, sem redeploy e sem bump de versão. É atualização opt-out, e o opt-out é um ajuste que a maioria dos times nunca tocou.

Os três modos de roteamento

O anúncio não cita, mas existem três modos, e a escolha muda o custo e a qualidade do que sua aplicação entrega:

• Balanced: otimiza custo mantendo qualidade. É o padrão.
• Quality: mira trabalho crítico. A Microsoft cita revisão jurídica, sumários médicos e raciocínio complexo.
• Cost: mira alto volume, como classificação e perguntas simples.

Mudanças de modo ou de subset levam até cinco minutos para valer. Times que restringiram o roteamento a um subconjunto escolhido ficam isolados da renovação: modelos novos só entram se forem adicionados explicitamente.

As pegadinhas que decidem se vale a pena

Algumas restrições publicadas antes ganham peso justamente porque o pool agora muda:

• Janela de contexto é a do menor modelo. A janela efetiva equivale à do menor modelo do pool, e prompts grandes só passam se o roteador escolher um modelo que os suporte. Adicionar um modelo menor ao pool derruba o teto de toda requisição roteada por ele.
• Decisão de roteamento é só texto. Inputs de visão são aceitos, mas imagens não influenciam a escolha do modelo. Áudio não é suportado.
• Há markup embutido. O roteador cobra o próprio prompt de entrada por cima do custo do modelo escolhido. Qualquer promessa de economia já vem com esse acréscimo dentro.
• Claude precisa de deploy separado. Os modelos Anthropic exigem deploy à parte na mesma conta Foundry, com SKU compatível, antes de o roteador poder selecioná-los. Referenciar um Claude num subset sem esse deploy falha com erro InvalidResourceProperties. Claude Opus 4.8 estar na lista suportada não o torna alcançável.

Governança e residência de dados

A Microsoft enquadra a expansão regional em termos de compliance: a inferência precisa ficar dentro de fronteiras geográficas específicas. Ir de 2 para 28 regiões muda o que é viável para times com obrigações de residência de dados, tema quente para quem opera sob LGPD↳LGPD14 conteúdosComo utilizar a LGPD com o objetivo de conformidade e inovação?Gestão Dev & TI · out 2021LGPD coloca pressão inédita nos responsáveis pela tecnologia das empresasData · ago 2021Proteção de dados: LGPD é sancionada e começa a valerData · set 2020Ver tudo em Gestão Dev & TI → e contratos que exigem processamento em território definido. O que o material não esclarece é como uma restrição de data zone interage com a seleção de pool quando o modelo candidato não está disponível dentro daquela fronteira.

O model router respeita a Azure Policy nativa para deploy de modelos Foundry, aplicada em tempo de deploy no portal, REST API, CLI e templates ARM. A lista de publishers permitidos precisa incluir a Microsoft mais o publisher de cada modelo do pool. Isso é governança em tempo de deploy, e fica em aberto como ela se compõe com o novo tier de AI↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → Gateway do Azure API Management, que controla em runtime quais modelos um workload pode alcançar.

O que fazer antes de mandar tráfego de produção

O anúncio não traz medição: sem números de acurácia, sem comparação de custo contra um baseline de modelo único, sem overhead de latência do passo de seleção. A orientação da própria Microsoft é tratar a implantação inicial como configuração de partida e fazer benchmark antes de enviar tráfego de produção. Há um pipeline de avaliação open-source que mede qualidade, custo e latência numa única rodada, com contabilidade de custo ciente do roteador e relatório de quais modelos ele de fato aciona.

Cada resposta traz o modelo escolhido num campo model, então as decisões são auditáveis depois do fato. É a base para a disciplina que Panagiotidis propõe: tratar uma renovação de pool como atualização de dependência gerenciada, registrando o modelo selecionado em cada requisição avaliada, comparando com o período anterior e mantendo um caminho para restringir o pool quando uma atualização produzir resultados inaceitáveis.

Para times de plataforma no Brasil, a leitura prática é direta: a seleção de modelo virou uma decisão de runtime que a plataforma pode tomar, mas a configuração default aceita mudanças no pool conforme elas chegam. Quem não quiser surpresas de comportamento a cada renovação vai querer olhar o subset e o pipeline de avaliação antes que o próximo modelo entre sozinho.

Fonte: InfoQ