Local ou nuvem já não é a pergunta. Windows e NVIDIA tornam a alocação de modelos uma política de roteamento

Para dois anos, a pergunta de IA empresarial no desktop era binária: enviar o trabalho para um modelo na nuvem ou ficar sem. Em 7 de outubro, Microsoft e NVIDIA fizeram um caso coordenado de que a resposta agora é “ambos, por tarefa”, e que o sistema operacional deve ajudar a decidir.

Isso desloca a decisão real. Já não é onde sua IA roda. É quem escreve a regra que envia cada tarefa para algum lugar.

O que foi anunciado

A Microsoft descreveu o Windows como uma plataforma para o que chama de inteligência híbrida: agentes rodam localmente quando faz sentido e acessam a nuvem quando precisam. As peças, com seu status:

• GitHub HydraFusion roteia cada tarefa para o modelo certo, na nuvem ou no dispositivo. A Microsoft o lista como preview experimental ainda em outubro.
• Windows ML roda modelos locais na GPU, NPU ou CPU.
• Microsoft Execution Containers, em disponibilidade geral (GA), definem quais arquivos e redes agentes locais podem acessar. Cobrimos em nossa análise sobre contenção de agentes no Windows.
• Funcionalidades híbridas no Copilot devem ser lançadas nos próximos meses, opt-in, começando em mercados selecionados.

A Microsoft também diz que 40% dos laptops corporativos são agora PCs Copilot+ e que esses PCs rodam cerca de 2 trilhões de inferências locais por mês. Esses são números da própria Microsoft.

A NVIDIA apresentou o RTX Spark, que combina uma GPU RTX Blackwell com até 6.144 núcleos, uma CPU Grace com até 20 núcleos e até 128GB de memória unificada, com desempenho avaliado em um petaflop de FP4. Laptops da Acer, ASUS, Dell, HP, Lenovo, Microsoft, MSI e Gigabyte abriram pré-venda em 7 de outubro, com envio a partir de 16 de outubro; desktops compactos chegam em novembro. O Surface RTX Spark Dev Box da Microsoft chega em novembro, apenas nos EUA. Nenhuma das empresas listou disponibilidade por país para o restante.

A NVIDIA também mostrou o DGX Station for Windows como preview: 748GB de memória coerente e até 20 petaflops de computação FP4, o que a NVIDIA diz ser suficiente para modelos de até escala de trilhão de parâmetros. A Microsoft diz que estará disponível ainda este ano.

O que realmente muda

Inferência local não é novidade; perguntamos quando um agente empresarial pertence a uma caixa embaixo da mesa alguns dias atrás. O que é novo é que o roteamento está se tornando um recurso de plataforma. Quando o sistema operacional e as ferramentas de desenvolvimento decidem qual modelo cuida de qual etapa, a alocação deixa de ser uma revisão de arquitetura feita uma vez e se torna uma decisão de runtime tomada milhares de vezes por dia.

Essa decisão tem pelo menos quatro entradas, e cada uma pertence a um dono diferente:

• Privacidade: esses dados podem sair do dispositivo? Segurança e privacidade são donas dessa resposta.
• Latência: o usuário espera por esta etapa? Times de produto são donos disso.
• Custo: quanto custa uma chamada à nuvem contra hardware já pago? Finanças e FinOps são donos disso.
• Capacidade: um modelo local é bom o suficiente para esta tarefa? Só a avaliação pode dizer.

1. Tarefa chega
2. Política de dados: pode sair do dispositivo?
3. Checagem de capacidade por evals
4. Orçamento de custo e latência
5. Modelo local ou modelo na nuvem

• Política de roteamento de propriedade da empresa: Política de dados: pode sair do dispositivo? · Checagem de capacidade por evals · Orçamento de custo e latência

Requisição de agenteRegras com donos nomeados

O roteador é o novo ponto de controle

Um roteador que escolhe o “modelo certo” otimiza para algo. Em uma ferramenta de fornecedor, isso geralmente é qualidade e gasto de tokens. Sua empresa pode precisar que ele otimize primeiro para classificação de dados, o que um roteador genérico não sabe fazer.

A classificação de dados precisa chegar ao roteador. Se um arquivo está marcado como confidencial, a decisão de roteamento deve ver esse rótulo antes de qualquer chamada à nuvem. Pergunte a qualquer fornecedor como seu roteador consome seus rótulos, não apenas se ele suporta modelos locais.

Capacidade local se torna uma linha de FinOps. Pagar uma vez por uma estação de trabalho de grande memória que roda um modelo aberto capaz muda a curva de custo para usuários pesados, como desenvolvedores rodando agentes o dia todo. Também adiciona atualização de hardware, atualizações de modelo e patch à função de alguém. Argumentamos em nosso artigo sobre gerenciar um portfólio de modelos que cada modelo que você roda é algo que você opera; um modelo em cada mesa é muitos deles.

A avaliação tem que cobrir os dois caminhos. Se a mesma tarefa pode cair em um modelo local de 125B ou em um modelo de fronteira na nuvem, testes de qualidade precisam rodar nos dois, ou o roteador vai baixar a qualidade silenciosamente para economizar custo.

Previews são previews. HydraFusion é experimental, DGX Station for Windows é preview, e os recursos do Copilot estão a meses de distância. Faça piloto, não padronize.

O que fazer agora

1. Escreva a política de roteamento antes de comprar o hardware: quais classes de dados devem ficar locais, quais tarefas precisam de qualidade de fronteira, quanto cada caminho pode custar.
2. Escolha um grupo de uso pesado, geralmente desenvolvedores, para um piloto local-mais-nuvem, e meça custo por tarefa nos dois caminhos.
3. Exija um log de cada decisão de alocação: tarefa, modelo, localização e motivo.
4. Estenda as avaliações aos modelos locais que você permite, com os mesmos conjuntos de teste dos modelos na nuvem.
5. Combine qualquer agente local com contenção e decida quem gerencia esses dispositivos.

A conclusão

O runtime híbrido está chegando ao desktop, em parte enviado e em parte em preview. O hardware vai se resolver. A parte a acertar agora é a política de roteamento: escrita pela empresa, aplicada pela plataforma e visível em um log.