A semana em que ficou claro: agentes em produção não travam por falta de modelo — travam por falta de engenharia de dados, governança de permissão e átomos de silício.
Zero vírgula um seis seis.
É a nota média dos melhores agentes do mundo tentando redesenhar o próprio algoritmo de treinamento. O teto da auto-melhoria recursiva que estão vendendo como o futuro do seu stack.
Esta é a edição da ai|expert. A semana em que ficou claro: agentes em produção não travam por falta de modelo — travam por falta de engenharia de dados, governança de permissão e átomos de silício.
Existe um mito de produção que a indústria tem perpetuado em silêncio há dois anos. O mito diz: quando o seu agente falha, reescreva o prompt. Invista mais em modelo, aumente o contexto, tente outra arquitetura de chain-of-thought. A Thoughtworks publicou essa semana a autópsia mais direta que já li sobre por que equipes prototype em uma semana e engessam por seis meses. E a conclusão é desconfortável: o gap não é de modelo. É organizacional. [ref: agent-readiness-gap-why-databr]
O diagnóstico começa com um número. Um cliente da Thoughtworks tinha quarenta e sete tabelas com a palavra "revenue" no catálogo de dados. O agente conseguia consultar todas as quarenta e sete. O problema não era capacidade de consulta — era que ele não sabia qual usar, não conseguia aplicar definições regionais corretamente e não conseguia explicar a escolha que fez. Para o agente, quarenta e sete tabelas de receita são quarenta e sete respostas igualmente prováveis. Para o time de finanças, só uma delas importa. [ref: agent-readiness-gap-why-databr]
A Thoughtworks divide a falha em duas camadas. A camada de plataforma — Unity Catalog, controles de acesso, lineage — está quase resolvida. A camada de significado não está. "Revenue" numa mesma empresa pode significar receita contabilizada, faturada ou reconhecida, dependendo do time. "Customer" significa coisas diferentes para vendas e operações. Duas tabelas compartilhando uma coluna customer_id compartilham uma chave — não necessariamente um join válido. A recomendação: marcar relacionamentos como inferidos até que um dono de domínio os verifique. Essa disciplina evita erros silenciosos que surgem apenas quando o output do agente é checado depois que uma decisão já foi tomada. [ref: agent-readiness-gap-why-databr]
A evidência empírica de que curadoria de contexto bate reescrita de prompt vem do benchmark interno da Databricks. Vinte e oito perguntas, junho de 2026: o Genie Agent respondeu 84,5% corretamente na primeira tentativa. O melhor agente de código de uso geral testado ficou em 52,4%. O pior, em 25%. E o Genie foi duas vezes mais rápido. A diferença não é o modelo subjacente — é a camada de contexto governado herdada do Unity Catalog. Os concorrentes foram anonimizados, replicação independente ainda não é possível, mas o princípio se sustenta no campo. [ref: agent-readiness-gap-why-databr]
A Databricks tem nome para o problema padrão que ocorre sem contexto governado: "first revenue table it finds". O agente pega a primeira tabela de receita que encontra numa busca por keyword — não a que o time de finanças realmente mantém. O resultado é tecnicamente originado de dados, mas operacionalmente errado. A solução não é um prompt melhor. É curadoria no Unity Catalog: definições de métricas formalizadas, com fórmula, dono, dimensões, sistema de record, regras temporais e exceções explicitamente documentadas — e versionadas. [ref: databricks-designing-productio]
E quando o seu Genie Agent retorna respostas inconsistentes, a Databricks é direta: audite os assets do Unity Catalog antes de tocar no prompt. O Genie Ontology — em preview restrito — escaneia notebooks, dashboards, pipelines e lineage, extrai fragmentos de conhecimento, os ranqueia via OntoRank — um engine inspirado no PageRank que pesa autoridade do criador, amplitude de uso, linkage com datasets certificados e frescor — e injeta os mais relevantes em tempo de query. Ele se auto-mantém, o que é fundamental porque definições de métricas derivam depois que times as constroem manualmente. [ref: agent-readiness-gap-why-databr]
Mas um contexto que se auto-atualiza é certo para descoberta. Não é certo para apresentações de board para o CFO. Você precisa versionar definições ao lado da camada aprendida, pinar agentes a um release nomeado e testar contra aquele release específico — não contra dados ao vivo. Esse ponto a Thoughtworks faz questão de colocar em negrito.
Há um caso de produção que vai além da curadoria de tabelas e que fecha esse primeiro bloco de forma elegante. O Netflix open-sourced em junho o `oci-agent` — um pacote Python para inferência causal observacional usando um loop actor-critic — e desde então está rodando mais de cem análises causais por mês com ele. A arquitetura é instrutiva para qualquer time que deploya agentes em workloads analíticos de alto stakes. [ref: netflix-open-sources-agentic-w]
Descreve o loop.
Um agente Actor recebe o plano do humano, refina em uma spec de análise, preenche um notebook Jupyter com template e o executa. Um agente Critic recebe o output, avalia em três níveis — insatisfatório, satisfatório com ressalvas, totalmente satisfatório — e recomenda mudanças de spec. O loop roda até o Critic aprovar ou uma condição de parada ser atingida. Cada artefato — planos, specs, plots, notebooks executados — fica versionado e publicado num file store onde o humano pode verificar resultados localmente. O Netflix chama isso de "process audits". [ref: netflix-open-sources-agentic-w]
Por que process audits em vez de acurácia em leaderboard? Porque inferência causal de dados observacionais não tem ground truth. Você não avalia esse agente com acurácia numérica contra um oráculo externo — você avalia se ele seguiu o playbook, se o Critic flagou os diagnósticos certos, se um humano consegue re-executar o notebook e chegar na mesma resposta. Isso muda fundamentalmente o que você precisa construir como infra de eval.
O case study que eles publicam é a demonstração mais clara de por que estrutura causal importa. Perguntaram ao Claude bruto e ao `oci-agent` o mesmo: qual o impacto de engajar com um novo tipo de entretenimento — a vertical de games deles, chamada de Tipo X — sobre retenção de dois meses. O `oci-agent` retornou uma estimativa que era apenas 25% do resultado do Claude bruto. O modelo sem estrutura causal superestimou o efeito causal em quatro vezes. O Critic flagou viés de adotante precoce e um teste placebo que falhou, e disparou iterações com parâmetros ajustados até chegar numa estimativa defensável. [ref: netflix-open-sources-agentic-w]
Quatro vezes. Essa é a diferença entre uma decisão de produto correta e uma que parece correta.
E quatro diagnósticos rodam automaticamente no `oci-agent`: balanço de covariáveis — diferença padronizada de média abaixo de 0,2 após ponderação; overlap — propensity score entre 0,1 e 0,9; um teste de resultado placebo; e análise de sensibilidade a confundidores ocultos. O Critic os avalia antes de emitir qualquer rating. Se o seu data science stack roda trabalho causal observacional hoje — estimativa de métricas proxy, análise de impacto de retenção, atribuição de feature — o `oci-agent` entrega um template actor-critic já testado em carga de produção, com thresholds de diagnóstico e playbooks definidos. A mensagem que o Thoughtworks e o Netflix entregam em conjunto: curar dados é a alavanca que importa. Reescrever prompt é o reflexo de quem ainda não encontrou a causa raiz. [ref: netflix-open-sources-agentic-w]
Mas enquanto arquitetos brigam com ontologias e evais de processo, uma segunda narrativa avançava em silêncio. A narrativa de que o modelo se melhora sozinho — e que, portanto, os problemas de produção se resolvem por osmose conforme a próxima geração chega. Essa narrativa teve uma semana muito ruim.
Dois papers. Publicados com horas de diferença. Chegando à mesma conclusão por caminhos opostos.
O primeiro: "Phantom Gains: Auditing Self-Improvement Against a Measured Null". Xu, Yan, Chen e Kechadi, publicado no arXiv em 20 de agosto de 2026. Três rodadas de self-training com LoRA rank-32 num Qwen3-8B. Resultado: ganhos detectáveis — zero. Pior: o self-training degradou problemas que o modelo base já resolvia, a taxas mensuravelmente acima do ruído de medição. [ref: phantom-gains-auditing-self-im]
O dado isolado não é o que me preocupa. É a metodologia que escondeu esse dado por todo esse tempo. Os autores identificaram sete falhas de medição no pipeline padrão de avaliação de auto-melhoria. Cada uma delas, isolada, é capaz de inverter um resultado publicado. Não de distorcer levemente — de inverter completamente.
A mais reveladora: a estatística de "expansão", projetada para separar aquisição genuína de capacidade de simples refinamento de conhecimento parcial — essa estatística atribuiu ao modelo Qwen3-8B congelado, sem nenhum treinamento adicional, uma taxa de aquisição de capacidade de 0,280. O modelo não aprendeu absolutamente nada. A métrica diz que aprendeu. Isso significa que toda vez que você vê um número de "expansão de capacidade" num paper de self-training, você está provavelmente olhando para ruído de inferência, não aprendizado. [ref: phantom-gains-auditing-self-im]
O paper propõe um teste exato por problema contra uma baseline poolada sob controle de false-discovery-rate. Aplicado a replicatas held-out, detecta nada — a resposta certa quando o modelo não mudou — e permanece estável sob mudanças na correção de testes múltiplos, taxa de erro e tamanho do pool. Um indicador que se move com threshold de FDR não está medindo capacidade. Está medindo a sensibilidade do pipeline de avaliação. [ref: phantom-gains-auditing-self-im]
E tem um finding de corrupção que demanda ação imediata de quem roda self-training iterativo. O self-training degradou problemas que o modelo base resolve na baseline — a taxas acima do ruído medido. Times rastreando acurácia agregada não veem isso: um novo ganho em um problema compensa numericamente uma regressão em outro. Auditoria por nível de transição expõe a regressão. Auditoria por acurácia média a esconde. A implicação prática: antes de shipar qualquer pipeline de self-training, rode o modelo base congelado pelo stack completo de eval ao menos tantas vezes quantas cada arm treinado, e construa estatísticas de mudança de capacidade contra esse null medido — não contra zero assumido. [ref: phantom-gains-auditing-self-im]
E o segundo paper vai direto ao mecanismo que justificaria composição de auto-melhoria. O AI4AI-Bench, do Navers Lab e da Einsia.AI, publicado também em 20 de agosto. A pergunta de pesquisa: agentes LLM conseguem redesenhar algoritmos de treinamento para produzir modelos melhores? Essa é a base teórica da melhoria recursiva — a ideia de que um agente pode melhorar o processo que vai produzir o próximo agente. [ref: ai4ai-bench-can-agents-design-]
A escala: 0 é modelo não-informativo, 0,1 é o algoritmo que o repositório já vem com ele, 1,0 é o ótimo teórico. Resultado: nota média de 0,166 em 29 configurações de 6 sistemas em 10 repositórios de pesquisa congelados. O melhor sistema individual chegou a 0,250 — fechando menos de um quinto do gap entre o baseline atual e o possível. Seis sistemas testados, nenhum demonstrando invenção algorítmica confiável. [ref: ai4ai-bench-can-agents-design-]
O design do benchmark é adversarial a atalhos. Cada repositório cobre uma família distinta de algoritmos de treinamento: objetivos, regras de atualização, schedules de regularização. O agente tem quatro horas num único GPU B300 para ler o código, propor mudanças e testar ideias contra uma métrica proxy. Produz um patch de código-fonte — nada mais. Sem pesos cacheados, sem estado retido. Esse patch roda em container limpo por até doze horas, avaliado por um evaluator fixo que estava oculto do agente durante as quatro horas de trabalho. [ref: ai4ai-bench-can-agents-design-]
A maioria dos agentes nunca chega a mudar como o modelo aprende. Movem pesos de loss, ajustam batch sizes, ou simplesmente não fazem nada substantivo. As submissões que de fato editam o algoritmo de aprendizado têm média de 0,226. As que não editam: 0,126. Esse gap de 0,100 é toda a diferença entre uma tentativa significativa e inércia algorítmica. [ref: ai4ai-bench-can-agents-design-]
Mais raciocínio compra disposição para entrar no código de treinamento. Muda a fração de submissões que edita o algoritmo de 8% para 64%, e a média de 0,094 para 0,196. Mas não compra capacidade de melhorá-lo uma vez dentro. Design algorítmico — a camada onde ganhos se compõem por todos os treinamentos futuros, incluindo o que produz o próximo agente — permanece o único nível de auto-melhoria recursiva que ainda requer um humano. [ref: ai4ai-bench-can-agents-design-]
O que esses dois papers matam em conjunto é uma narrativa específica: que o modelo, ao se auto-melhorar, vai eventualmente resolver os problemas de produção que discutimos no bloco anterior. A resposta é: não com o mecanismo de self-training disponível hoje. E talvez mais importante — o fato de que não dávamos conta disso sugere que boa parte dos "ganhos" publicados nos últimos dois anos pode ser ruído de medição bem apresentado.
Então, se o modelo não se audita sozinho — quem audita? E com qual infraestrutura? Porque essa semana duas peças de governança agentica ficaram mais concretas do que nunca, e as duas resolvem problemas que nenhum prompt resolve.
A Cloudflare colocou o WriteGuard em beta privado. É uma camada de policy, atribuição e auditoria que senta entre o portal de servidores MCP da Cloudflare e cada tool conectada. Classifica cada chamada por tier de risco e intercepta writes antes de executar. A política é definida em TypeScript ao lado da configuração da tool — sem mudanças no servidor MCP em si. Esse ponto importa à escala. [ref: mcp-gets-its-first-granular-ac]
O incidente que motivou isso está descrito no próprio blog de engenharia deles. Um agente rodando em background sob a identidade OAuth de um engenheiro fechou milhares de tickets no Jira numa tarde — a um ritmo que nenhum humano sustentaria — antes de alguém perceber. O sistema registrou cada ação sob o nome do engenheiro, sem forma alguma de separar o que foi ação humana do que foi ação do agente. E o portal interno da Cloudflare cresceu de 13 servidores conectados em abril de 2026 para 27 hoje. Construir controles em cada servidor separadamente produziria comportamento inconsistente a cada novo servidor adicionado. [ref: mcp-gets-its-first-granular-ac]
Os quatro tiers são diretos. Chamadas read-only — buscar issues, ler um merge request, ver status de pipeline — passam sem alteração. Chamadas de impacto mínimo — adicionar uma reação, marcar notificação como lida — são apenas logadas. Writes contidos — criar um merge request, adicionar comentário, atualizar campo de issue — recebem atribuição de agente injetada na aplicação downstream no formato que a aplicação aceita, mais um audit event assíncrono. Operações críticas — merge em main, trigger de deploy em produção, bulk delete de records — são bloqueadas antes de executar. Tiers são configuráveis por tool; uma tool merge_mr classificada como Critical nunca executa sem uma policy explícita permitindo. [ref: mcp-gets-its-first-granular-ac]
O detalhe de design que importa na prática: o WriteGuard não cria contas standalone de agente. Herda as permissões do humano via Cloudflare Access e OAuth. Se o engenheiro não pode fechar determinado issue, o agente também não pode. Mas herança de permissão sozinha não resolve atribuição. O audit trail distingue "Joe, Claude Code, sessão abc123" de "Joe, navegador". Os eventos de auditoria são enviados de forma assíncrona — zero latência adicionada ao caminho de tool call — e removidos de valores que contenham secrets. Cada evento registra: server, tool, risk tier, outcome, usuário, cliente e duração. [ref: mcp-gets-its-first-granular-ac]
O contexto regulatório é mais urgente do que parece. Pesquisadores de segurança encontraram mais de 21 mil instâncias de servidores MCP expostos na internet, com aproximadamente 92% sem autenticação OAuth básica. O WriteGuard é a resposta do lado do servidor — e porque o controle fica no servidor, o usuário final não consegue contorná-lo trocando de cliente ou desabilitando um hook local. É proteção que não depende da disciplina do usuário. [ref: mcp-gets-its-first-granular-ac]
E a AWS foi mais longe no problema de sequência com o Dogwood — extensão do Cedar para governar sequências de chamadas de ferramentas de agentes, não apenas requisições individuais. O Cedar tradicional é stateless por design: a mesma requisição retorna a mesma resposta independentemente do estado anterior, tornando raciocínio automatizado e auditoria tratáveis. Mas agentes operam em sequências. As restrições que os times querem vivem em sequências: obter aprovação antes de agir, ficar abaixo de um total acumulado, parar de contatar partes externas depois de tocar dados confidenciais. Essas regras são inaplicáveis na camada de policy hoje sem o Dogwood. [ref: aws-dogwood-sequence-aware-pol]
A cláusula `when temporal` é o mecanismo. Ela lê o histórico de eventos do agente: requisições de tool calls, outcomes, argumentos de input, principal solicitante. Quatro operadores cobrem a superfície prática: `formerly` — algo aconteceu numa janela de tempo? — `count_within`, `count_distinct_within` e `sum_within`. Um operador `bind` atribui um agregado a um nome para comparação com a requisição atual. O schema de action é gerado diretamente do manifest de tools MCP do agente. [ref: aws-dogwood-sequence-aware-pol]
Tem um detalhe de concorrência que é quase uma armadilha pronta para produção. Uma política de rate limit expressa como soma sobre eventos de resposta falha contra chamadas paralelas. Três transferências de dois mil dólares chegam antes de qualquer uma liquidar — a policy somando respostas não vê nada em voo e aprova as três contra um cap de cinco mil dólares. Somar eventos de requisição em vez de resposta nega a terceira. Uma palavra separa correto de quebrado. Em configurações multi-agente onde chamadas se intercalam, a exposição multiplica. [ref: aws-dogwood-sequence-aware-pol]
O custo de usar condições temporais: elas perdem o raciocínio automatizado do Cedar. Uma policy usando `when temporal` não pode ser formalmente analisada para completude ou contradição. A AWS construiu uma linguagem separada em vez de estender o Cedar porque as duas propriedades estão em tensão fundamental. O interpreter de referência está disponível sob Apache 2.0, mas não é para autorização em produção — é exploração enquanto a linguagem estabiliza. Políticas Cedar existentes permanecem válidas em Dogwood sem migração. [ref: aws-dogwood-sequence-aware-pol]
O Dogwood e o Cloudflare MCP 2026-07-28 resolvem metades adjacentes do mesmo problema. Os headers MCP — Mcp-Protocol-Version, Mcp-Method, Mcp-Name — tornam o tráfego de agente legível para infraestrutura HTTP. O Dogwood expressa o que uma sequência de chamadas tem permissão de totalizar. Os dois são pré-requisitos para rodar agentes com nome dentro de um perímetro de compliance.
A governança do agente virou stack de infra. Não é mais checklist de compliance no final do projeto — é decisão de arquitetura no início.
E debaixo de toda essa discussão de software — modelos, ontologias, políticas de sequência — há uma física que não dobra na vontade de nenhum engenheiro. A física dos átomos de silício. E essa semana a estrutura financeira que governa esses átomos ficou mais visível e mais concentrada do que em qualquer ponto dos últimos dois anos.
Em agosto de 2026, a Nvidia anunciou dois movimentos que remodelam a natureza da sua vantagem competitiva. Primeiro: um memorando com Goldman Sachs, Apollo Global Management, Blackstone, BlackRock, Brookfield e KKR para mobilizar mais de 500 bilhões de dólares em capital de terceiros para financiamento de GPUs. Segundo: um compromisso de até 105 bilhões de dólares para um datacenter da OpenAI no campus Pike County, Ohio, incluindo um investimento direto de 1,5 bilhão em energia e capacidade de aproximadamente 4 gigawatts. [ref: nvidias-capital-moat-why-chip-]
A leitura superficial é: a Nvidia está apostando forte no ecossistema. A leitura correta é diferente. O free cash flow trimestral da Nvidia chegou a 48,5 bilhões de dólares — crescimento de dezoito vezes em três anos. Eles têm 30,2 bilhões em títulos de equity negociáveis, contra 12,9 bilhões um ano antes. Participações em private equity subiram de 3,39 bilhões para 22,25 bilhões em doze meses. No último ano fiscal, investiram 17,5 bilhões em empresas privadas e fundos de infraestrutura, "primariamente para apoiar startups em estágio inicial", segundo o filing na SEC. Startups que então compram os produtos deles diretamente ou via cloud providers. [ref: nvidias-capital-moat-why-chip-]
O padrão é repetitivo o suficiente para ser chamado de estratégia. CoreWeave: participação da Nvidia mais um acordo de compra de compute de 6,3 bilhões de dólares com vigência até 2032. Quando a Nvidia investiu dez bilhões na Anthropic em novembro de 2025, o lab entrou num acordo separado para comprar 30 bilhões em capacidade de compute na Microsoft Azure e comprometer deploy dos sistemas Grace Blackwell e Vera Rubin. O investimento de 30 bilhões na OpenAI, finalizado em fevereiro de 2026 numa valuation pós-money de 852 bilhões, é estruturado parcialmente em torno de leases de GPU. [ref: nvidias-capital-moat-why-chip-]
O analista do Mizuho, Jordan Klein, chamou de "pré-financiar a compra dos seus próprios GPUs". A SemiAnalysis encontrou que 9 dos 10 startups mais financiados no Forbes AI50 receberam capital da Nvidia — incluindo OpenAI, Anthropic e Mistral. Quando o budget de infraestrutura inicial de um startup inclui dinheiro da Nvidia e o lease de GPU roda até 2032, a decisão de procurement deixa de ser análise neutra de custo por FLOP. Torna-se bloqueada. O lock-in virou balanço patrimonial. [ref: nvidias-capital-moat-why-chip-]
Mas o moat tem uma fraqueza real e é importante nomeá-la. O custo de troca do CUDA cai quando os modelos rodam, não quando treinam. AMD ROCm e o TorchTPU do Google — um caminho de execução nativo PyTorch para TPUs, co-desenvolvido com a Meta — estão ganhando tração em stacks de inferência. E a aquisição da Groq pela Nvidia — cujas Language Processing Units baseadas em SRAM superam GPUs na fase de geração autoregressiva — sinaliza que a empresa está se movendo para dominar o segmento de inferência especializado antes que os concorrentes o reivindiquem. [ref: nvidias-capital-moat-why-chip-]
Dito isso: sair da Nvidia agora não é portar kernels CUDA. É desfazer arranjos financeiros embutidos nas pilhas de capital do fornecedor. São escapes de natureza diferente, com custo diferente.
E o piso de preço do token não é definido pela eficiência do modelo. É definido pela capacidade de fábrica da TSMC. Que está chegando ao limite físico.
O nó N3 da TSMC é o gargalo atual. Todo roadmap principal de acelerador convergiu nele: Rubin da Nvidia, ASICs customizados da Broadcom, TPUv7 do Google, série MI da AMD, Annapurna, MediaTek. A SemiAnalysis modela demanda de IA — aceleradores, CPUs host, silício de rede — consumindo pouco menos de 60% de toda a produção N3 em 2026. Em 2027, essa cifra chega a 86%, praticamente expulsando chips de smartphone e PC do mesmo nó. A utilização do N3 deve superar 100% no segundo semestre de 2026. [ref: fab-capacity-not-model-efficie]
As wafers ficam mais caras a cada ciclo. Uma wafer 3nm custa entre 19.500 e 21.000 dólares. Uma wafer 2nm: acima de 30.000 — um prêmio de mais de 50%. A TSMC anunciou aumentos de preço por quatro anos consecutivos a partir de 2026, com 3nm subindo aproximadamente 3% e nós mais avançados podendo chegar a 10%. Esses aumentos não são uma anomalia de ciclo — são uma trajetória de precificação que você pode modelar hoje para os próximos quatro anos. [ref: fab-capacity-not-model-efficie]
E o packaging é onde o gargalo fica ainda mais apertado. Uma wafer fabricada perfeitamente não se torna um acelerador de IA funcional sem o CoWoS — o processo 2.5D da TSMC que bonda o die do acelerador a pilhas de memória de alta largura de banda num interposer de silício. O CEO da TSMC, C.C. Wei, declarou que o CoWoS está esgotado até o final de 2026. A TSMC está escalando a produção de CoWoS em aproximadamente dez vezes desde o final de 2023, chegando a 120.000 a 130.000 wafers por mês até o final de 2026 — uma expansão totalmente consumida antes de ser entregue. Lead times rodam de 52 a 78 semanas. A Nvidia reservou a maioria da alocação disponível. [ref: fab-capacity-not-model-efficie]
O efeito no preço de inferência é direto. Preços de contrato de aluguel de um ano do H100 subiram 40% desde o piso de outubro de 2025. Preços de memória aumentaram seis vezes no último ano. DRAM deve dobrar ou triplicar novamente, com capacidade crescendo apenas 20 a 30% ao ano. Novos fabs, acionados pelos sinais de demanda do final de 2025, não vão entregar volume relevante antes de 2027 ou 2028. [ref: fab-capacity-not-model-efficie]
A SemiAnalysis rastreou o próprio gasto com tokens saindo de aproximadamente dez mil dólares por ano no final de 2023 para sete milhões anualizados no início de 2025 — 28% da base salarial de 25 milhões deles. Quando o custo de inferência representa mais de um quarto da sua folha, o piso de token vira uma questão existencial, não uma linha de item de infra. [ref: fab-capacity-not-model-efficie]
Dylan Patel, co-fundador da SemiAnalysis, projeta a TSMC atingindo cem bilhões de dólares de capex anual em 2028, com alívio real de capacidade chegando não antes do final de 2027. Eficiência de modelo importa — modelos de raciocínio que entregam mais outputs por token deslocam a economia unitária. Mas eles não desbloqueiam wafer starts adicionais. Não encurtam a fila de CoWoS de 52 a 78 semanas. Não alteram a trajetória de precificação de quatro anos da TSMC. [ref: fab-capacity-not-model-efficie]
Então onde os hyperscalers estão apostando para sair do gargalo de banda de memória enquanto aguardam capacidade de fab? Na disaggregação de memória. A Marvell está entregando um portfólio em três tiers, cada um atacando um raio diferente da GPU — e a tese é direta: em grandes clusters de inferência rodando modelos com footprints de centenas de gigabytes e janelas de contexto longas, pressão de KV-cache e saturação de largura de banda de memória chegam antes do budget de FLOP ser esgotado. [ref: memory-disaggregation-architec]
No nível do servidor: o Bravera SC6 — controlador SSD PCIe 6.0 para offload de KV-cache. O diferencial é uma flash translation layer gerenciada pelo host, dando aos hyperscalers controle direto sobre amplificação de escrita, coleta de lixo e wear leveling — em vez de delegar ao firmware. Suporte a múltiplos fornecedores de NAND importa quando a cadeia de suprimentos de SSD está instável. [ref: memory-disaggregation-architec]
No rack: a família Structera CXL. O Structera X faz expansão de memória usando inventário DDR4 ou DDR5 existente, com compressão a bordo que entrega de 2 a 2,5 vezes a capacidade efetiva versus configurações padrão. A Meta está usando expansão de memória baseada em CXL em milhões de servidores, reciclando módulos DDR4 de máquinas desativadas em vez de comprar novos. O Structera S4 é um switch CXL 3.1 com uma camada de conversão de protocolo PCIe-over-CXL, conectando CPUs e GPUs a pools CXL mesmo quando o silício host não tem lanes CXL nativas — crítico para clusters construídos em gerações anteriores de GPU. [ref: memory-disaggregation-architec]
Além do rack: a Photonic Fabric usa links ópticos para estender um tier de memória compartilhada em até 50 metros — atravessando racks adjacentes dentro de um pod de datacenter. O alvo é inferência de contexto longo, modelos onde o KV-cache sozinho esgota a DRAM por servidor. A Marvell reporta offload de até 32 TB de KV-cache quente e afirma melhoria de 2 a 3 vezes no throughput de tokens dentro do mesmo envelope de energia e footprint. [ref: memory-disaggregation-architec]
Com uma ressalva que eles próprios colocam: o ganho de 2 a 3 vezes assume workload limitado por largura de banda de memória. Configurações limitadas por compute vão ver menos. E a Photonic Fabric é a aposta mais ousada arquiteturalmente — memória compartilhada óptica introduz novos modos de falha, jitter de latência em links de 50 metros e complexidade operacional que DDR local não tem. Para arquitetos escalonando agora, a entrada de menor risco está no Structera X e no S4 — reciclagem de DDR4 e CXL pooling funcionam sem mudanças de infraestrutura óptica. A avaliação da Photonic Fabric fica para clusters onde 32 TB de offload de KV-cache quente muda os fundamentos econômicos. [ref: memory-disaggregation-architec]
E o ponto que conecta esse bloco com tudo que discutimos hoje: construa modelos de custo de inferência em torno de economia de fab primeiro, curvas de eficiência de modelo depois. O piso do preço do token é definido pelo cronograma de preços de nó da TSMC, pelas filas de alocação de CoWoS e pelos mercados spot de HBM. Nenhum desses fatores rastreia contagens de parâmetros de modelo. A Nvidia garantiu que, quando o silício existir, ela o financia. A TSMC definirá quando ele existirá. E a Marvell está apostando que a memória será o gargalo até lá. [ref: memory-disaggregation-architec]
Três blocos, uma tese: o que trava agentes em produção não é o modelo — é o que o modelo não consegue ver, o que ele não tem permissão de fazer, e o que custa produzir o próximo token. Wire na segunda abre com os números da Databricks Document Intelligence — extração sete pontos melhor a um quinto do custo — e o schedule reordering que devolveu trinta e três pontos de utilização de GPU sem CapEx. Até lá.