A semana em que o custo de IA migrou da GPU pra memória, agentes encararam sistemas reais de empresa, e a pesquisa entregou réguas mais honestas pra medir o que está em produção.
Sete vírgula oito milhões de dólares. É o custo de um rack Vera Rubin. E dois milhões disso são só memória.
Quatrocentos e trinta e cinco por cento de alta em relação à geração anterior. O custo da memória agora cresce mais rápido do que o da GPU — e o gargalo de custo em IA mudou de endereço.
Esta é a ai|expert Edition. A semana em que o custo de infraestrutura migrou da GPU pra memória, agentes entraram em sistemas reais de empresa, e a pesquisa entregou as réguas que faltavam pra medir o que está de fato em produção.
Vamos destrinchar a aritmética. Um rack Vera Rubin VR200 NVL72 custará, segundo estimativa do Morgan Stanley, sete vírgula oito milhões de dólares aos hyperscalers. A GPU domina em volume: setenta e dois GPUs Rubin, a cinquenta e cinco mil dólares cada um em pedidos de volume, somam três vírgula noventa e seis milhões de dólares — o maior item de linha isolado no bill of materials. Mas memória chegou a dois milhões de dólares. Vinte e cinco por cento do custo total do sistema indo para memória é uma proporção que não existia em nenhuma geração anterior de acelerador da Nvidia.
E o que importa não é só onde o número está hoje — é a trajetória. No GB300 NVL72 da geração anterior, memória custava uma fração disso. No Vera Rubin, cresceu quatrocentos e trinta e cinco por cento. A GPU também encareceu, mas não nesse ritmo. O custo de memória agora cresce mais rápido do que o de compute. O culpado são três camadas simultâneas, não uma. O rack VR200 leva cinquenta e quatro terabytes de LPDDR5X — três vezes mais do que os dezessete terabytes do GB200. O SemiAnalysis estima que a Nvidia pagou oito dólares por gigabyte de LPDDR5X no primeiro trimestre de 2026. Nesse preço, só a LPDDR5X some quatrocentos e oito mil dólares por rack. Se o preço subir para dez dólares — o que o mercado upstream está sinalizando — chegamos a quinhentos e quarenta mil. Por rack.
E tem uma terceira linha no BOM que simplesmente não existia antes. Armazenamento 3D NAND: aproximadamente um milhão de dólares por rack. No GB200 NVL72, esse número era virtualmente zero. Uma categoria inteiramente nova no custo do sistema. Quando você soma LPDDR5X, NAND e o HBM4 on-die nos próprios GPUs Rubin, memória em todas as suas formas domina a curva de custo do cluster. Isso não é flutuação de commodity — é mudança estrutural na composição do BOM.
E o mercado upstream confirma que a pressão não é temporária. Fabricantes taiwanesas de módulos de memória — Adata, TeamGroup, Innodisk, GoldKey, Apacer, Transcend, Silicon Power — captaram coletivamente vinte e oito bilhões de dólares taiwaneses, cerca de oitocentos e oitenta milhões de dólares americanos, em debêntures conversíveis, empréstimos sindicalizados e colocações privadas de ações. Só para poder comprar e estocar chips enquanto os preços disparam. A Adata é a maior tomadora isolada: dois bilhões em debêntures, doze bilhões em empréstimos bancários sindicalizados, e uma emissão privada de trinta milhões de ações ainda pendente.
O TrendForce estimou que os preços de contrato de DRAM convencional subiram entre noventa e noventa e cinco por cento no primeiro trimestre de 2026, com mais cinquenta e oito a sessenta e três por cento projetados para o segundo trimestre. NAND flash subiu aproximadamente sessenta por cento no primeiro trimestre, com projeção de setenta a setenta e cinco por cento adicionais no segundo. Em revisão publicada no início de maio, o preço de DRAM móvel foi ajustado para cima: noventa e três a noventa e oito por cento de aumento trimestral, enquanto Samsung, Micron e SK Hynix finalizavam negociações com clientes.
O detalhe comportamental mais revelador desta semana: o chairman da Adata, Simon Chen, confirmou que provedores de serviços em nuvem procuraram a empresa para fechar acordos de fornecimento de longo prazo. Ele descreveu isso como "ocorrência rara". Quando um hyperscaler bate na porta de um fabricante de módulos de memória para fechar contrato direto, é porque a alocação via fab não está cobrindo a demanda. As fábricas priorizam DRAM de servidor e HBM — que vão direto para clusters de GPU e aceleradores de IA — sobre DRAM de consumo. Nova capacidade de fab não deve chegar em volume antes do fim de 2027. Os fabricantes de módulo estão tomando dívida para manter posição de mercado, não para expandir capacidade.
A conclusão prática para arquitetos é direta: se você está orçando um cluster de inferência para o segundo semestre de 2026, não use os preços de memória do ano passado como referência. Modele pelo menos sessenta por cento a mais. Design de kernel eficiente em memória, estratégias de quantização que minimizem pressão sobre memória de ativações, e avaliação cuidadosa de armazenamento NAND em pipelines de inferência deixaram de ser otimizações de desempenho — são decisões diretas de capex.
Enquanto o custo de hardware explode, a geografia de quem fabrica esse hardware está sendo redesenhada. Jensen Huang confirmou na call de resultados do primeiro trimestre da Nvidia — com a receita crescendo oitenta e cinco por cento ano a ano para oitenta e um vírgula sessenta e dois bilhões de dólares — que a empresa "largamente cedeu" o mercado chinês de aceleradores de IA à Huawei. A China, que já respondeu por pelo menos um quinto da receita de data center da Nvidia, foi zerada nas projeções internas da companhia.
A frase exata de Huang: "We've really largely conceded that market to them." Isso é mais revelador do que o número de receita, porque a Nvidia cresceu oitenta e cinco por cento sem a China. O mercado disponível fora da China é suficientemente grande para justificar não tentar contornar os controles. O governo Trump exigiu licença para exportar H100, H200 e chips relacionados em abril. Huang disse aos investidores para "não esperar nada" em termos de aprovações. Alibaba, Tencent, ByteDance e JD.com receberam aprovações individuais para H200 — mas um representante comercial americano confirmou que controles de exportação de chips foram excluídos das negociações bilaterais de maio com a China.
A Huawei respondeu com o Ascend 910C: chip dual-chiplet no processo DUV de sete nanômetros da SMIC, entregando até oitocentos teraFLOPS em FP16, cento e vinte e oito gigabytes de HBM, três vírgula dois terabytes por segundo de bandwidth de memória. A Huawei projeta produção de seiscentas mil unidades em 2026 — quase o dobro do output de 2025. No nível de rack, o CloudMatrix 384 integra trezentos e oitenta e quatro chips Ascend 910C e entrega aproximadamente trezentos petaFLOPS em BF16, contra cento e oitenta do GB200 NVL72 da Nvidia em termos brutos.
Com quatro vezes mais consumo de energia e dois vírgula três vezes menos eficiência por watt. A escala bruta existe — mais silício, clusters maiores — e funciona para inferência em produção. Mas há uma evidência empírica que importa mais do que qualquer comparação de benchmark: a DeepSeek abandonou o hardware Ascend no treinamento do R2 após encontrar falhas de estabilidade e throughput em escala e voltou para H800s. Quando o laboratório que mais investe em otimização de hardware da China não consegue fazer o hardware doméstico funcionar para treinamento de fronteira, a limitação é real e documentada.
A Bernstein Research coloca o market share da Nvidia na China em oito por cento em 2026, contra sessenta e seis por cento em 2024. A Huawei está em cinquenta por cento. O mercado de aceleradores na China não está encolhendo — está sendo atendido por outra empresa, com outra arquitetura de software. Huang ainda quer voltar: "We would be more than delighted to serve the market." Mas a própria guidance da Nvidia assume que a porta permanece fechada.
O que isso muda para quem está fora da China: a demanda global pela Nvidia está concentrada nos mercados que a empresa ainda pode atender. Isso pressiona preços e prazos de entrega globalmente. E há uma questão de software que equipes com workloads China-facing precisam resolver agora: o CANN da Huawei faz bridge para PyTorch via camadas de adaptação e funciona para cargas Transformer padrão. Mas suporte a FP8 no Ascend 910C não está confirmado. Pipelines de inferência construídos em quantização FP8 — o padrão em produção no H100 e posteriores — regridem para INT8 ou FP16 no Ascend, com throughput efetivo reduzido. Se seu stack depende de FP8, resolva esse problema de engenharia antes de comprometer plataforma.
E nessa semana o capital privado fez uma aposta grande na próxima camada do stack. Blackstone e Google anunciaram uma joint venture de vinte e cinco bilhões de dólares para criar um cloud dedicado de TPU — o primeiro canal de distribuição de terceiros para o silício do Google fora da interface padrão do GCP. A Blackstone entra com cinco bilhões de dólares em equity inicial, com o restante do valor em dívida estruturada contra os ativos de data center e equipamentos. Meta: quinhentos megawatts de capacidade online até 2027.
O modelo segue o template do CoreWeave aplicado ao silício do Google: infraestrutura de terceiros rodando aceleradores de um único fornecedor como compute-as-a-service. A Blackstone traz profundidade de data center — é a maior provedora global, dona do QTS Realty Trust desde 2021. O Google fornece TPUs, software e serviços. Benjamin Treynor Sloss, que passou mais de duas décadas construindo a infraestrutura global do Google, sai da empresa para liderar a nova entidade como CEO. Thomas Kurian, CEO do Google Cloud, descreveu os TPUs como "otimizados especificamente para eficiência e desempenho na era de IA".
O track record existe: Anthropic, Citadel Securities e o próprio Gemini já rodam workloads de produção em TPUs. O chip existe desde 2015 — uma década de uso em produção, design purpose-built para treinamento e inferência de IA, com vantagem documentada de eficiência para cargas agentivas.
Mas nenhum preço foi divulgado no anúncio. Nenhum SLA, nenhum benchmark de latência, nenhum custo por exaflop. E a restrição arquitetural central não mudou: TPUs rodam melhor em JAX e XLA. Workloads construídas em PyTorch e CUDA exigem porting não trivial. Um novo canal de procurement não é uma nova arquitetura de chip. Espere os números operacionais antes de qualquer plano de migração. A Blackstone também apostou na Anthropic separadamente mais cedo em maio — isso é estratégia de portfólio de compute, não escolha de stack única.
Agentes de IA saindo de demo para produção é o fio que atravessa todas as notícias de produto desta semana. A Anthropic, no evento Code with Claude em Londres em dezenove de maio, lançou em público beta os sandboxes auto-hospedados e em research preview os MCP Tunnels. Os dois atacam o mesmo chokepoint: equipes de segurança que se recusam a aprovar agentes cujo ambiente de execução fica fora do perímetro corporativo.
A arquitetura separa dois problemas que antes vinham embalados juntos. O loop do agente — orquestração, gerenciamento de contexto, recuperação de erros — permanece na infraestrutura da Anthropic. A execução de ferramentas migra para o ambiente controlado pelo cliente. Quatro provedores gerenciados no lançamento: Cloudflare com microVMs e zero-trust secrets injection; Daytona com ambientes stateful via SSH e pause-and-restore; Modal com startup abaixo de um segundo e escala para centenas de milhares de sandboxes concorrentes; e Vercel com isolação de VM em milissegundos e VPC peering. Organizações também podem trazer seu próprio sandbox client.
Os MCP Tunnels resolvem uma superfície diferente. Não onde o código roda — mas com o que o agente fala. Um gateway leve implantado dentro da rede privada abre uma única conexão criptografada saindo para o proxy de roteamento da Anthropic. Sem regras de firewall de entrada. Sem endpoints públicos. Bancos de dados internos, APIs privadas, sistemas de ticketing — tudo vira ferramenta chamável pelo agente.
Mas há uma distinção que equipes em verticais reguladas precisam nomear explicitamente antes de levar para aprovação de compliance. Mesmo quando toda execução de ferramenta acontece localmente, metadados de orquestração — estado de sessão, contexto — ainda fluem pelos sistemas da Anthropic. "Compute fica no nosso VPC" e "orquestração não sai do nosso VPC" são duas aprovações de compliance inteiramente diferentes. Confundi-las é o que transforma um ciclo de aprovação de duas semanas em quatro meses. A Anthropic publicou quatro arquiteturas de referência e três estudos de caso de produção — é isso que vai para a reunião de compliance, não o slide de produto.
Três integrações de produção já estão rodando. Clay com um agente de GTM chamado Sculptor em Managed Agents e Daytona, construindo e monitorando workflows autonomamente. Rogo — plataforma de IA para finanças institucionais — construindo um agente analista em Managed Agents e Vercel Sandbox para dados proprietários. E a Amplitude com um agente de design interno no ar em Cloudflare. A equipe da Amplitude chegou a uma versão funcional em dois dias. Outro CTO citado pela Anthropic fez o deployment inicial em menos de uma semana usando Modal.
Dito isso — MCP Tunnels está em research preview com linguagem explícita de "as-is". Sem SLA. Para piloto controlado com dados não regulados, certo. Para pipeline de produção crítico em vertical regulada, não. A distinção entre preview e GA vai custar caro para a equipe que ignorar.
Na mesma semana, a Cloudflare completou sua stack de infraestrutura para agentes com seis camadas nomeadas e uma reconstrução profunda do Browser Run. O produto anterior rodava em infraestrutura compartilhada com o Browser Isolation da Cloudflare, otimizado para sessões humanas longas e estáveis. Agentes de IA geram padrões completamente diferentes: curtos, espetados, altamente concorrentes. A migração para Containers dedicados com pools regionais de Chromium pré-aquecidos entregou quatro vezes mais concorrência — cento e vinte browsers simultâneos, ante trinta — e cinquenta por cento menos latência nas ações rápidas.
A migração de estado de Workers KV para D1 com Queues é o padrão técnico mais diretamente replicável desta semana. Workers KV tem consistência eventual — isso criava race conditions quando múltiplos agentes tentavam reservar o mesmo recurso em paralelo. D1 com Queues é transacional, com batch writes suportando até quinhentos mil containers por localidade. Se você roda agentes concorrentes contra qualquer store com consistência eventual e está vendo race conditions em atribuição de recursos, locking transacional na camada de dados resolve mais limpo do que locking no nível de aplicação.
A stack completa tem seis camadas. Compute, com Workers V8 para tarefas leves e Sandboxes Linux completos em GA para agentes que precisam de git, bash e servidor de desenvolvimento. Orchestration, os Dynamic Workflows — aproximadamente trezentas linhas MIT-licensed, cada passo independentemente retryável, cada sleep hibernando sem custo acumulado para tenants ociosos. Memory em private beta, com busca paralela em cinco canais e Reciprocal Rank Fusion para unir resultados, com perfis de memória compartilhados entre equipes de agentes. Browser Run reconstruído com suporte a WebGL e WebMCP. E uma camada de Commerce co-desenhada com a Stripe, onde agentes podem criar contas Cloudflare, registrar domínios, iniciar assinaturas e ir para produção autonomamente, com um cap padrão de cem dólares por mês por provedor.
Essa camada de Commerce exige atenção específica. Um agente que pode registrar domínios e iniciar assinaturas cria uma superfície de gasto autônomo. O cap de cem dólares é um guardrail operacional, não um controle de política de segurança. Em escala, com múltiplos agentes executando autonomamente, isso pode gerar eventos de billing inesperados rapidamente. O risco precisa de controles no nível de política de autorização, não deixado no default.
E a diferença de posicionamento em relação às alternativas merece ser nomeada. AWS tem um Agent Registry, mas sem browser layer gerenciado e sem equivalente a Agent Memory. Google Cloud tem o GKE Agent Sandbox, mas como primitivo Kubernetes, não serviço gerenciado. A Cloudflare opera esses mesmos primitivos internamente nos próprios produtos — o que chama de "Customer Zero". Esse é um sinal operacional relevante de maturidade.
Enquanto a infraestrutura de agentes amadurece, há uma tensão crescendo do lado dos desenvolvedores humanos que operam esses sistemas — e que precisa ser nomeada. Uma firma de segurança de API rastreou um aumento de dez vezes nas descobertas mensais de segurança dentro de empresas Fortune 50 entre dezembro de 2024 e junho de 2025: de mil para mais de dez mil vulnerabilidades por mês. O período coincide com o pico de adoção de ferramentas de coding com IA. Volume de código está superando a capacidade de revisão humana.
O problema documentado pelo 404 Media não é que a IA escreve código ruim. É que os mandatos de adoção estão medindo participação, não qualidade. Um funcionário da Amazon começou a inflar números de uso de IA para satisfazer métricas de adoção — sem usar o output. Um desenvolvedor disse diretamente ao veículo: "A qualidade real do output não importa tanto quanto nossa disposição em participar." O Google reporta setenta e cinco por cento do código novo gerado por IA. A Anthropic, noventa por cento. O CTO da Microsoft projeta noventa e cinco por cento até 2030. Esses percentuais medem força de mandato — não velocidade de entrega, não taxas de defeito, não saúde de engenharia.
O GitClear analisou duzentos e onze milhões de linhas de código. Ferramentas de coding com IA elevaram código copy-paste de oito vírgula três para doze vírgula três por cento de todas as mudanças. Duplicação de blocos cresceu oito vezes. Atividade de refatoração caiu de vinte e cinco para menos de dez por cento. Refatoração é um indicador preditivo de custo de manutenibilidade de longo prazo. Quando cai para menos da metade, o código entregue hoje cria trabalho multiplicado para quem vier depois.
E há um ensaio clínico randomizado com cinquenta e dois engenheiros que é difícil de ignorar. Quem usou assistência de IA completou a tarefa em tempo similar ao grupo de controle, mas tirou dezessete por cento a menos no quiz de compreensão subsequente: cinquenta contra sessenta e sete por cento. Tarefas de debug mostraram a queda mais acentuada. Velocidade ficou estável. Compreensão caiu. E as métricas padrão não capturam isso: DORA metrics firmes, contagem de PRs subindo, cobertura de código verde. O dashboard parece saudável enquanto o conhecimento no time se deteriora.
Um engenheiro disse para o 404 Media: "Está me deixando mais burro com certeza."
Outro: "Estamos construindo um ninho de ratos de dívida técnica que será impossível de desembaraçar quando esses modelos ficarem proibitivamente caros."
E o output realizável desta rodada de adoção, o que podemos medir até agora, são demissões, não melhoria de qualidade. Meta cortou oito mil pessoas, dez por cento da força de trabalho, citando ganhos de IA. Microsoft ofereceu aposentadoria voluntária para aproximadamente cento e vinte e cinco mil pessoas, sete por cento da força de trabalho americana. Snapchat cortou dezesseis por cento da equipe. Headcount é o entregável. Não taxa de defeito, não confiabilidade de sistema, não velocidade de lançamento.
E tem um caso específico que ilustra como decisões de produto aparentemente pequenas se propagam de forma invisível por semanas em produção. A Anthropic publicou em vinte e três de abril um postmortem rastreando seis semanas de queixas de degradação do Claude Code a três mudanças de produto sobrepostas — nenhuma delas uma regressão de modelo. Os pesos do modelo permaneceram estáveis. Tudo era camada de produto.
Três mudanças, três timelines distintas, três cohorts de usuários diferentes — criando a aparência de degradação ampla e inconsistente. Primeira: em quatro de março, o esforço de raciocínio padrão do Claude Code foi rebaixado de alto para médio para evitar que a UI parecesse travada. Ficou assim por trinta e três dias. Segunda: em vinte e seis de março, um bug de cache fez a poda de raciocínio antigo disparar em cada virada de turno, não uma vez após período de inatividade. Um usuário com novecentos mil tokens em contexto ficando inativo por uma hora enfrentava um cache miss completo na próxima mensagem — e cada mensagem subsequente também virava cache miss, explicando o drain acelerado de rate limit. Corrigido em dez de abril. Terceira: em dezesseis de abril, um cap de verbosidade no system prompt do Opus 4.7 limitou texto entre tool calls a vinte e cinco palavras e respostas finais a cem palavras. Testes internos não mostraram regressão. Investigação posterior encontrou queda de três por cento em avaliações de coding. Revertido em vinte de abril.
Stella Laurenzo, diretora do grupo de IA da AMD, analisou seis mil oitocentos e cinquenta e dois arquivos de sessão do Claude Code — dezessete mil oitocentos e setenta e um blocos de thinking, duzentos e trinta e quatro mil setecentos e sessenta tool calls. Ela encontrou que reads-per-edit colapsou de seis vírgula seis para dois vírgula zero. De pesquisa-primeiro para edição-primeiro. Sua equipe descreveu isso como tornando a ferramenta inadequada para trabalho de engenharia complexo.
E a distinção que o postmortem não deixou clara o suficiente: duas das três mudanças eram tradeoffs deliberados de produto, não bugs. O rebaixamento de esforço de raciocínio e o cap de verbosidade foram decisões conscientes. Apenas o comportamento de cache foi regressão não intencional. Tratá-los uniformemente como "degradação de qualidade" gerou a crítica legítima que apareceu no Hacker News.
Um comentarista colocou assim: "Mudar o system prompt por baixo dos usuários quando você publicou benchmarks usando um system prompt mais antigo parece enganoso."
Operadores rodando Claude Code em pipelines automatizados precisam tratar mudanças de system prompt e defaults de esforço como variáveis de deployment — não como constantes. Instrumente profundidade de raciocínio por sessão e reads-per-edit antes do próximo rollout, não depois.
A última parte desta edição são três trabalhos publicados esta semana que, juntos, entregam algo mais raro do que um benchmark: instrumentos de medição honestos para o que já está em produção. O primeiro mede acurácia factual por idioma e região. Um estudo de catorze dias — de nove a vinte e dois de fevereiro de 2026 — conduzido por Mirac Suzgun e Emily Shen avaliou seis chatbots de produção em duas mil e cem perguntas factuais derivadas de reportagens do mesmo dia do BBC News, cobrindo seis serviços regionais: EUA e Canadá, árabe, Afrique, hindi, russo e turco.
Os seis modelos: Gemini 3 Flash, Gemini 3 Pro, Grok 4, Claude 4.5 Sonnet, GPT-5 e GPT-4o mini. Em múltipla escolha, os melhores sistemas chegam a mais de noventa por cento de acurácia em eventos reportados horas antes. O mesmo sistema em formato de resposta aberta perde onze a treze pontos percentuais. A média do cohort cai dezesseis a dezessete pontos. Esse é o formato que usuários reais usam — não múltipla escolha.
O gap regional é o dado mais operacionalmente relevante do estudo. Todos os modelos atingem sua menor acurácia em hindi: setenta e nove por cento, contra oitenta e nove a noventa e um por cento nos demais idiomas. Uma diferença de dez a doze pontos. A análise de citações revela o mecanismo: modelos respondendo perguntas em hindi citam a Wikipedia em inglês mais do que qualquer veículo jornalístico em hindi. Mais de setenta por cento dos erros rastreiam para recuperação do documento errado, não para falha de raciocínio. Quando os modelos recuperaram a fonte correta, extraíram respostas com alta taxa de acerto.
E as queries com premissas falsas expõem a vulnerabilidade mais profunda. Modelos marcando entre oitenta e oito e noventa e seis por cento em perguntas limpas despencaram para dezenove a setenta por cento quando as questões embutiam erros factuais sutis. Um modelo aceitou premissas fabricadas sessenta e quatro por cento das vezes. E há um paradoxo de detecção: o modelo com melhor capacidade de detectar premissa falsa ficou em segundo lugar em robustez adversarial. Detecção e recuperação são parcialmente independentes — você não pode inferir robustez adversarial a partir de capacidade de detecção.
A conclusão prática: alta acurácia em inglês não transfere para outros idiomas. Um modelo mostrando noventa por cento em avaliação em inglês pode estar rodando a setenta e nove por cento ou menos nos idiomas que seus usuários realmente falam. Log de citações no nível de chamada é o único jeito de diagnosticar viés de recuperação antes que vire problema de produção. Avaliações em inglês sozinhas subestimam a deriva regional em dez a doze pontos.
O segundo trabalho da semana é mais teórico — mas tem uma ferramenta diagnóstica prática que equipes de fine-tuning podem usar imediatamente. Vishal Rajput publicou no arXiv de maio de 2026 um paper que unifica sete famílias de robustez — adversarial, adaptação de domínio, invariância fotométrica e por oclusão, generalização composicional, robustez temporal, segurança de alinhamento e regularização anisotrópica clássica — sob um único princípio estatístico. O princípio de matching: estime a covariância das perturbações de deployment que preservam o rótulo, depois regularize o Jacobiano do encoder para que seu range cubra essa covariância.
CORAL, IRM, penalidades de Jacobiano, metric learning, restrições estilo RLHF — todos recastados como estimadores diferentes do mesmo objeto. Não truques independentes de robustez — variantes do mesmo problema estatístico. O trabalho valida o princípio em treze experimentos pré-registrados, de benchmarks clássicos de ML até um LLM de sete bilhões de parâmetros. Doze dos treze passaram no ordenamento previsto: regularizador matched superou o isotrópico, que superou o mismatched. A exceção foi o Office-31, um failure de eigengap nomeado antes do experimento rodar.
O resultado que mais importa para equipes fazendo fine-tuning: no experimento com Qwen2.5-7B, o regularizador matched style-PMH melhorou honestidade seletiva e preservou o Style TDI onde o DPO padrão degradou o Style TDI. Métodos de alinhamento podem degradar robustez de deployment de maneiras que acurácia em avaliação não detecta. O trabalho introduz o Trajectory Deviation Index — um probe sem rótulo de sensibilidade de embedding para monitoramento de deployment, quando acurácia de tarefa e norma de Frobenius do Jacobiano não são suficientes. Adicione ao seu harness de avaliação antes do próximo fine-tune.
E encerrando na fronteira da pesquisa: a NVIDIA publicou o Gated DeltaNet-2, de Ali Hatamizadeh, Yejin Choi e Jan Kautz. O trabalho ataca uma limitação estrutural em todos os modelos de linear attention com delta-rule anteriores. O problema: Gated DeltaNet e KDA usam um único gate escalar para governar duas operações de memória distintas — apagar conteúdo obsoleto no eixo da chave e commitar conteúdo novo no eixo do valor. Forçar uma única decisão de escrita em duas preocupações separadas causa interferência que embaralha associações existentes quando o sistema deveria estar revisando seletivamente.
A solução: dois gates independentes por canal. Um erase gate b_t no eixo da chave. Um write gate w_t no eixo do valor. O modelo recupera o KDA quando ambos colapsam para o mesmo escalar — é uma generalização estrita, não substituição de arquitetura. Implementado em Triton com um algoritmo chunkwise WY e backward pass consciente dos gates, rodando num único H100, com throughput quase flat em relação ao comprimento de sequência.
Os números para inferência de longo contexto: no benchmark RULER multi-key needle-in-a-haystack em quatro mil tokens, o Gated DeltaNet-2 recorrente marca trinta e sete vírgula oito, contra vinte e oito do KDA e vinte e sete vírgula oito do Gated DeltaNet — um salto de trinta e cinco por cento. Em S-NIAH-3 a dois mil tokens: de sessenta e três vírgula dois do KDA para oitenta e nove vírgula oito. Acurácia média geral no conjunto de commonsense e language modeling: cinquenta e três vírgula onze, contra cinquenta e dois vírgula vinte e oito do KDA. O erase gate responde pela maior parte do ganho — proteção seletiva no lado da chave impede que associações existentes sejam sobrescritas durante escritas não relacionadas.
Duas limitações críticas para adoção. A licença é NVIDIA Source Code License-NC — não comercial. Equipes construindo produtos de inferência comercial precisam negociar uma licença separada; não é open source. E o treinamento foi feito em sequências de quatro mil tokens. Os scores RULER são extrapolação de avaliação em contextos mais longos, não validação. Antes de comprometer arquitetura, valide nos seus próprios comprimentos de contexto operacionais.
O princípio que fica, independente da licença: desacoplar operações de erase e write por canal. Compartilhar um gate escalar entre os dois é uma perda de precisão mensurável — e o Gated DeltaNet-2 quantifica exatamente quanto essa perda custa em recuperação de longo contexto.
Esta semana, o custo de IA mudou de endereço — da GPU para a memória — e os agentes saíram dos demos para os sistemas reais de empresa. As réguas chegaram: para medir acurácia regional, robustez de alinhamento, e quanto custa um gate mal projetado em contextos longos. Wire na segunda. Edition na próxima sexta. Bom trabalho.