A conta da Meta no Azure testa a aposta da Microsoft em inferência

A Bloomberg informa que a Meta gasta centenas de milhões de dólares por ano no Azure para consumir trilhões de tokens de IA por semana, o que a torna um dos maiores clientes de IA da Microsoft. A Meta também estaria se preparando para concorrer com o Azure ao vender sua própria capacidade computacional para IA. A mesma empresa agora pode ser cliente do Azure e futura rival, comprando um volume industrial de inferência enquanto constrói outro lugar para atendê-la.

A divisão estrutural agora está visível: donos de modelos de fronteira capturam valor nos produtos, enquanto operadores que mantêm modelos heterogêneos atendendo com confiabilidade em escala global podem capturar uma margem distinta de infraestrutura. Ao mesmo tempo, o Azure pode se tornar menos dependente de qualquer fornecedor de modelos e mais valioso como operador de infraestrutura de IA. Isso exige que a Microsoft transforme capacidade, hardware próprio, ferramentas de implantação e compras corporativas em um plano de controle durável, e não em um aluguel de computação intercambiável.

A primeira máquina de IA do Azure tinha um único inquilino

A ambição de infraestrutura da Microsoft antecede o ciclo da IA generativa. A empresa lançou o Azure Batch AI Training em prévia privada em 2017. Três anos depois, a Microsoft descreveu um supercomputador do Azure com 285,000 processadores, construído exclusivamente para a OpenAI desenvolver modelos distribuídos massivos.

Aquela máquina de 2020 deu a um parceiro estratégico capacidade computacional concentrada suficiente para treinar sistemas além do alcance de configurações comuns de nuvem. A OpenAI forneceu a ambição dos modelos de fronteira; a Microsoft forneceu o capital, os processadores e o sistema distribuído. A Microsoft projetou parte do Azure em torno das exigências da OpenAI e reservou o resultado para uso da OpenAI.

A OpenAI também reduziu um dos riscos mais difíceis em um sistema de alto custo fixo: a incerteza sobre quem ocuparia a máquina. Atuou como cliente âncora antes da existência de um mercado amplo de inferência. A Microsoft aceitou a concentração em um fornecedor em troca de uma carga de trabalho grande o bastante para justificar infraestrutura especializada.

Em 2024, a Microsoft havia começado a montar um produto diferente. O Azure AI Studio entrou em disponibilidade geral com o GPT-4o da OpenAI e a família Phi-3 da Microsoft. O catálogo mostrou que a Microsoft já não esperava que um único endpoint atendesse a todas as aplicações, metas de custo ou restrições de implantação.

O Foundry deslocou a diferenciação para acima do modelo

A Microsoft explicitou a mudança quando lançou o Azure AI Foundry com ferramentas destinadas a facilitar a troca entre modelos de linguagem de grande porte. A Microsoft também afirmou que 60,000 clientes usavam o Azure AI. O Foundry colocou desenvolvimento, implantação e governança acima do modelo subjacente, transformando a escolha do modelo em uma decisão dentro de um ambiente operacional mais amplo.

A Microsoft transformou a escolha de modelos em produto. Um cliente poderia usar o GPT-4o para uma carga de trabalho, o Phi-3 para outra e um modelo diferente mais adiante sem abandonar o fluxo de trabalho do Azure ao redor. A Microsoft poderia então cobrar pelo trabalho que permanecesse depois que o modelo mudasse: provisionar capacidade, implantar endpoints, aplicar controles e dar suporte à conta corporativa.

O consumo reportado da Meta coloca esse desenho sob seu teste mais severo. A Meta possui modelos, aplicações e relações diretas com usuários, mas o Azure ainda pode medir a carga de trabalho de atendimento. A Microsoft não precisa deter a propriedade intelectual ou a interface da aplicação da Meta para obter receita de infraestrutura com a demanda da Meta.

O relato da Bloomberg continua sendo uma apuração baseada em fontes, e nenhuma das empresas confirmou a relação comercial. O gasto reportado é um sinal relevante, não uma prova de que a Microsoft construiu uma fonte durável de receita multimodelo. Ainda assim, um contrato não confirmado desse porte mostra por que a Microsoft construiu acima do modelo: a demanda pode vir de uma empresa com seus próprios modelos e aplicações.

A inferência torna racks vazios o fracasso caro

O treinamento chega como projeto. A inferência chega como fila. Cada solicitação de usuário cria outro problema de agendamento entre aceleradores, memória, redes e energia. À medida que a adoção cresce, a carga se repete em vez de terminar com uma rodada de pesquisa. Os trilhões de tokens semanais reportados da Meta tornam a mudança concreta: o Azure estaria operando um serviço industrial, não hospedando um experimento de modelo.

O Barclays projetou que os investimentos de capital em inferência superariam os de treinamento em dois anos e chegariam a $208.2 billion em 2026. Desafiantes no setor de chips seguiram esses gastos rumo à inferência porque o atendimento recompensa uma combinação diferente de latência, eficiência energética, acesso à memória e custo por resultado.

A vantagem da Microsoft depende da utilização, porque os aceleradores continuam envelhecendo enquanto não há solicitações. Um processador à espera de trabalho ainda ocupa um prédio energizado, imobiliza capital comprometido e consome parte de uma cadeia de suprimentos escassa. Um operador com muitos clientes e tipos de modelo tem mais oportunidades de preencher essas lacunas, desde que seu software consiga alocar cada carga de trabalho na capacidade adequada sem violar requisitos de latência, confiabilidade ou implantação.

A TrendForce afirmou que os data centers consumiriam mais de 70% de toda a produção de memória de alto desempenho em 2026, com pouca capacidade nova de fabricação esperada antes de 2027. Separadamente, o chefe de infraestrutura de IA do Google disse aos funcionários que a empresa precisava dobrar a capacidade computacional a cada seis meses para atender à demanda. Para um operador, a economia da inferência depende de combinar cada chip com memória, rede e energia suficientes no lugar certo quando a solicitação chega.

Compromissos de longo prazo decorrem dessa escassez. O mercado emergente do megawatt contratado permite que desenvolvedores de modelos reservem capacidade energizada anos antes que uma aplicação gere o tráfego necessário para preenchê-la. Operadores de nuvem carregam o problema de equilíbrio: pouca capacidade perde demanda, enquanto capacidade demais deixa equipamentos caros à espera em uma sala construída para uso contínuo.

Maia leva o limite de custo do Azure para dentro

O programa de silício próprio da Microsoft dá ao Azure outra forma de equilibrar sua frota. O Azure precisa de hardware que reduza o custo por token útil, satisfaça requisitos de latência e confiabilidade e reduza a dependência de um único fornecedor externo. A Microsoft precisa de controle sobre a estrutura de custos mais do que de supremacia em benchmarks.

A Microsoft estaria preparando um acelerador Maia 300 e discutindo com a TSMC a produção de mais de 300,000 chips para 2027. A empresa e a TSMC não confirmaram esses planos, portanto nem o volume nem o cronograma devem ser tratados como capacidade garantida. A escala reportada identifica o problema que a Microsoft tenta resolver: o Azure não pode operar como uma utility se outro fornecedor determina o preço e a disponibilidade de cada motor crítico dentro dele.

A Microsoft também se juntou à Intel, Google, Meta e outros no Ultra Accelerator Link Promoter Group, que desenvolve um padrão para conectar chips de servidores aceleradores de IA. Juntos, silício próprio e interconexão padronizada apoiariam uma frota componível, na qual o Azure pode combinar diferentes aceleradores e preservar poder de negociação sobre fornecedores.

A Microsoft pode internalizar mais da economia de hardware para cargas de trabalho adequadas ao Maia, continuar usando aceleradores da Nvidia ou de outros fornecedores onde tiverem melhor desempenho e colocar ambos por trás do mesmo sistema voltado ao cliente. A carga de engenharia do Azure cresce porque frotas heterogêneas são mais difíceis de agendar e suportar. Sua posição de negociação pode melhorar com esse ônus se os clientes comprarem um endpoint confiável em vez de especificar cada componente sob ele.

O melhor recurso do Foundry também enfraquece sua retenção

A troca mais fácil de modelos no Foundry permite que uma equipe de compras direcione GPT-4o, Phi-3 ou um modelo futuro por um único ambiente operacional. Isso dá aos clientes uma razão para adotar o Azure e um mecanismo para mover cargas de trabalho para fora dele. A Microsoft não pode contar com o modelo para manter a conta cativa.

A portabilidade entre aceleradores dá ao comprador uma alavanca semelhante. Um cliente que pode mover uma carga de trabalho de inferência entre chips ou nuvens compatíveis pode solicitar propostas concorrentes para computação bruta. A Microsoft precisa tornar o trabalho ao redor — acesso à capacidade, controles de implantação, disponibilidade regional, governança, suporte e compras comerciais — mais caro de reconstruir do que migrar a carga de trabalho.

A Meta representa esse limite. A empresa estaria planejando um negócio de nuvem que venderia computação e modelos de IA contra AWS, Azure e Google Cloud. Se a Meta está comprando capacidade do Azure hoje, pode estar cobrindo uma escassez temporária, diversificando o fornecimento ou atendendo à demanda enquanto sua própria infraestrutura se desenvolve; as evidências disponíveis não estabelecem qual dos casos é o correto. O mesmo volume que torna um cliente valioso também pode justificar internalizar o serviço.

Essa possibilidade não torna o acordo reportado com o Azure irracional para nenhum dos lados. A Meta pode comprar capacidade antes de possuir o suficiente. A Microsoft pode obter receita de uma demanda que talvez migre mais tarde. A duração do contrato, o escopo da carga de trabalho e os custos de troca — e não o tamanho de uma conta anual reportada — determinariam qual parte detém a posição mais forte.

A entrega de energia decide quem cobra o pedágio

A Oracle demonstra por que demanda anunciada não pode substituir entrega. A receita de nuvem da Oracle aumentou 27% em relação ao ano anterior, mas investidores questionaram se a empresa conseguiria abrir data centers suficientes para a OpenAI. A Oracle tinha clientes pedindo capacidade; a questão não resolvida era se concreto, energia, equipamentos e comissionamento poderiam chegar dentro do cronograma.

A Microsoft carrega o mesmo risco de execução em escala maior. A capacidade de data centers nos EUA construída, em andamento, planejada ou paralisada superou 80 gigawatts em 2025. Estimava-se que os planos das Big Tech exigiriam outros 44 gigawatts até 2028. Cada interconexão paralisada ou construção atrasada interrompe a cadeia entre um acordo de IA assinado e um token atendido.

A intensidade de capital impede a Microsoft de tratar capacidade ociosa como um seguro inofensivo. O Azure precisa comprometer dinheiro antes que os clientes revelem os modelos, chips e regiões exatos de que precisarão, e depois preservar flexibilidade suficiente para absorver mudanças na demanda. O Foundry incentiva clientes a trocar de modelo; o Maia altera a combinação de hardware; escassez de memória restringe configurações; a disponibilidade de energia fixa cargas de trabalho a locais físicos. O software de nuvem abstrai o hardware, mas cada abstração de IA agora exige uma conexão elétrica muito maior.

O supercomputador da Microsoft em 2020 trazia um único nome na porta porque a exclusividade era a arquitetura. O Azure AI Foundry agora torna a placa substituível, enquanto Maia, contratos de memória e racks energizados mantêm a sala cara. A Meta pode comprar dessa sala enquanto constrói uma rival ao lado. A aposta da Microsoft é que operar a sala continue mais difícil de substituir do que o nome em sua porta.