Showing Posts From

Llm

GPT-5.5 libera memory graph persistente entre contas enterprise — o que muda para quem depende de isolamento de dados

GPT-5.5 libera memory graph persistente entre contas enterprise — o que muda para quem depende de isolamento de dados

A OpenAI liberou ontem, durante o DevDay Spring 2026, um recurso que vinha sendo pedido por clientes enterprise há meses: memória persistente compartilhada entre workspaces da mesma organização. A empresa chama de "memory graph" — uma camada que aprende com interações de um workspace e torna esse contexto disponível, com permissão, para outros workspaces ligados à mesma conta Team ou Enterprise. Para o time de produto, é um salto real de produtividade. Para o CISO, é uma segunda-feira complicada. O modelo mental de "cada workspace é uma ilha" acabou de ser redesenhado pela OpenAI, e quem depende de isolamento de dados entre departamentos ou entre clientes precisa entender rápido o que mudou. O que exatamente a OpenAI lançou O memory graph substitui a memória por conversa que a ChatGPT Enterprise já tinha. Antes, cada workspace funcionava como uma unidade fechada — memórias, system prompts customizados e histórico ficavam restritos àquela instância. Quem queria consolidar contexto entre times precisava exportar, mesclar e reingerir manualmente, ou construir um RAG externo. Agora, o grafo existe acima dos workspaces. Ele indexa fatos, preferências, padrões de uso e até decisões tomadas em conversas anteriores. Cada nó do grafo tem uma ACL — controle de acesso definido por administrador — que determina quais workspaces podem ler aquela memória. Na prática, se o time jurídico definiu uma política de redação de contratos em um workspace dedicado, o time de vendas pode herdar essa política em suas próprias conversas sem que ninguém precise copiar e colar nada. O grafo é persistente entre sessões e entre usuários. O modelo por trás é o GPT-5.5, anunciado no mesmo dia. Não é coincidência — o salto de capacidade do 5.5 para operar sobre memória estruturada é o que tornou o recurso viável. Com janelas de contexto efetivas maiores e custo por token mais baixo, carregar um grafo inteiro em cada inferência deixou de ser inviável economicamente. O problema de isolamento que ninguém discutiu no keynote A promessa comercial é óbvia: menos retrabalho, menos fragmentação de conhecimento, onboarding mais rápido de novos membros do time. Tudo verdade. O que não apareceu nos slides foi como fica a separação de dados para empresas que usam múltiplos workspaces exatamente porque precisam dessa separação. Três cenários concretos onde isso dói. Agências atendendo clientes concorrentes. Uma consultoria que presta serviço para Itaú e Bradesco historicamente opera com workspaces separados — e isso não é paranoia, é contrato. Se uma memória vaza, mesmo que acidentalmente, mesmo que via inferência estatística do modelo, existe um risco contratual e reputacional direto. A ACL do grafo ajuda, mas ACLs são configuração — e configuração falha. Empresas com compliance por jurisdição. Uma multinacional com operação no Brasil, na União Europeia e nos EUA mantém workspaces separados porque o dado gerado em cada região tem regime legal distinto. LGPD no Brasil, GDPR na Europa, uma colcha de retalhos estadual nos EUA. Um memory graph que cruza essas fronteiras por padrão é um problema de transferência internacional de dados esperando para acontecer. Separação entre áreas sensíveis. Jurídico e RH dentro da mesma empresa deliberadamente não compartilham contexto. Fusões e aquisições, processos trabalhistas, investigações internas — tudo depende de muralhas chinesas funcionando. O memory graph é o inverso de uma muralha chinesa. É um pátio compartilhado com regras de quem pode entrar. O que a OpenAI diz sobre controle Na documentação publicada ontem, a empresa detalha três camadas de controle. A primeira é o opt-in por workspace — o administrador precisa ativar o recurso explicitamente, e o default é desligado. A segunda é a ACL por nó — cada memória pode ser marcada como visível apenas para usuários, workspaces ou grupos específicos. A terceira é um audit log completo: toda leitura cross-workspace de memória é registrada e exportável via Compliance API. É um trabalho sério. Mas é também, na prática, a mesma estrutura que rege IAM em cloud há 20 anos — e a gente sabe como IAM termina quando ninguém revisa. O Gartner estima que mais de 75% dos incidentes em nuvem vêm de configuração errada de permissão, não de vulnerabilidade de software. Não há razão para apostar que o memory graph será diferente. O outro detalhe que merece atenção é a natureza da memória armazenada. Diferente de um banco de dados relacional, o grafo guarda representações vetoriais e sumários semânticos. Uma ACL pode impedir leitura direta de um nó específico, mas o modelo já foi treinado na sessão onde aquele dado apareceu — e pode regurgitar aproximações via inferência. Isso não é alucinação. É como memória humana funciona. E é um vetor de vazamento novo que o time de segurança precisa modelar. O que fazer na próxima semana Para CTOs, CISOs e arquitetos enterprise que já têm ChatGPT Enterprise ou Team rodando, três ações concretas. Primeiro, manter o memory graph desligado até entender o escopo. O default é off, mas convém confirmar em cada workspace e documentar a decisão. Segundo, mapear quais workspaces de fato precisam de compartilhamento de contexto e quais existem justamente para separação. Não são a mesma pergunta. Terceiro, exigir do time de segurança um threat model específico para memória persistente cross-workspace antes de qualquer ativação — incluindo cenários de insider threat, desligamento de funcionário e request regulatório. Para quem opera no Brasil, um ponto adicional. O Marco Legal de IA (PL 2338) ainda está em tramitação, mas a ANPD já sinalizou que memória persistente de sistemas de IA entra no escopo de tratamento de dados pessoais pela LGPD. Se a memória cruza workspaces, cruza também finalidades de tratamento — e finalidade é a base jurídica da LGPD. Ativar o recurso sem revisar DPIA e contratos de operador é correr risco desnecessário. A parte que importa O memory graph é tecnicamente impressionante e comercialmente inteligente. Resolve um problema real de fragmentação que qualquer um que usa ChatGPT em uma empresa grande já viveu. Mas ele também remove, por design, uma das poucas garantias arquiteturais que clientes enterprise tinham: a de que workspaces eram fronteiras duras. Fronteiras duras viraram fronteiras configuráveis. Isso não é necessariamente ruim — é só diferente, e exige que o modelo de segurança acompanhe. A OpenAI fez o trabalho técnico. Cabe a quem implementa fazer o trabalho de governança antes de apertar o botão. Quem tratar o anúncio como mais uma feature de produtividade vai descobrir, em algum incidente futuro, que produtividade e compliance às vezes puxam cordas opostas.

Stanford AI Index 2026: a diferença entre EUA e China caiu para 2,7% — e a transparência despencou

Stanford AI Index 2026: a diferença entre EUA e China caiu para 2,7% — e a transparência despencou

Stanford publicou na segunda-feira o nono AI Index Report. O documento tem 300 páginas e dezenas de gráficos, mas três números contam a história inteira: a diferença de performance entre modelos americanos e chineses caiu para 2,7%. A transparência das empresas de IA despencou de 58 para 40 pontos. E 88% das organizações já adotaram IA — mais rápido que o PC e a internet. O relatório confirma o que quem acompanha o setor já sentia: a corrida ficou apertada, a prestação de contas piorou, e a adoção acelerou além do que a governança consegue acompanhar. A China está a 2,7% dos EUA — e acelerando O dado mais comentado do relatório é o gap de performance entre os melhores modelos americanos e chineses. Em março de 2026, o melhor modelo da Anthropic liderava por apenas 2,7 pontos percentuais sobre o melhor modelo chinês. Há dois anos, essa diferença era de dois dígitos. O que mudou? DeepSeek, Qwen e outros labs chineses não apenas lançaram modelos competitivos — fizeram isso com arquiteturas que custam menos para treinar. A estratégia de Mixture of Experts (MoE) e técnicas de destilação permitiram que modelos chineses rodassem benchmarks de nível "70B" com custos de infraestrutura muito menores. Para o mercado, o recado é direto: a vantagem tecnológica americana não é garantida. E para empresas brasileiras que dependem de APIs de modelos, a diversificação de fornecedores deixou de ser opcional. Modelos superam PhDs — mas erram relógios analógicos Os melhores modelos de IA já batem a performance de especialistas humanos em testes de ciência, matemática e compreensão linguística em nível de doutorado. No Humanity's Last Exam, os modelos de ponta ultrapassaram 50%. No SWE-bench Verified — benchmark que mede a capacidade de resolver issues reais do GitHub — a pontuação saltou de 60% para quase 100% em um único ano. Mas o relatório traz um dado que deveria ser lido com neon piscando: esses mesmos modelos acertam relógios analógicos apenas 50,1% das vezes. Não é piada. É um lembrete de que "superar humanos em benchmarks" não significa "pensar como humanos". A capacidade é inconsistente de formas que ainda não entendemos completamente. Para quem coloca IA em produção, isso tem implicação direta: o modelo que resolve um problema complexo de código pode falhar em uma tarefa que uma criança de 7 anos resolve. Testar em benchmarks não é testar em produção. Transparência em queda livre O Foundation Model Transparency Index, que mede o quanto as empresas revelam sobre seus modelos, caiu de 58 para 40 pontos em um ano. As empresas estão publicando menos informação sobre dados de treinamento, metodologias de avaliação e limitações conhecidas. O timing é péssimo. Justamente quando reguladores do mundo inteiro — EU AI Act, framework federal americano, PL 2338 no Brasil — exigem mais transparência, as empresas entregam menos. O relatório de Stanford não especula sobre motivos, mas o cenário competitivo é explicação suficiente: quanto mais você revela, mais facilita para o concorrente replicar. O problema é que a falta de transparência não afeta apenas reguladores. Afeta empresas que compram esses modelos. Se você não sabe como o modelo foi treinado, não sabe onde ele vai falhar. E se você não sabe onde ele vai falhar, não pode mitigar o risco. 53% da população já usa IA generativa A adoção de IA generativa alcançou 53% da população global em três anos — mais rápido que o PC (que levou uma década) ou a internet. Mas o dado tem uma nuance importante: os EUA estão em 24° lugar, com apenas 28,3% de adoção. Países como Índia e Indonésia lideram. No contexto brasileiro, onde a adoção de ferramentas digitais costuma seguir o padrão americano, vale perguntar: estamos mais próximos dos mercados emergentes que adotam rápido ou dos mercados maduros que adotam com mais cautela? Impacto no trabalho já é mensurável O relatório cita um estudo de economistas de Stanford mostrando que o emprego para desenvolvedores de software de 22 a 25 anos caiu quase 20% desde 2022. Não é projeção — é dado. E segundo McKinsey, um terço das organizações espera reduzir sua força de trabalho com IA no próximo ano, especialmente em operações e engenharia de software. Para o Brasil, onde o setor de tecnologia é um dos maiores empregadores formais de jovens, esse dado deveria estar na mesa de todo CEO e secretário de educação. O que Stanford não diz — mas os dados implicam O relatório é descritivo. Não prescreve. Mas os números pintam um quadro claro: estamos em um momento de capacidade técnica alta, transparência baixa, e governança atrasada. A adoção é rápida, o impacto no trabalho é real, e a competição geopolítica está no ponto mais acirrado da história. Para quem toma decisões — em empresas, governos ou carreiras — o AI Index 2026 não é leitura opcional. É o mapa do terreno onde você já está operando.

MiniMax M2.7: o modelo chinês que se auto-evoluiu por 100 rounds e agora compete com GPT-5.3 Codex

MiniMax M2.7: o modelo chinês que se auto-evoluiu por 100 rounds e agora compete com GPT-5.3 Codex

56,22% no SWE-Pro. 57,0% no Terminal Bench 2. ELO de 1495 — o mais alto entre modelos open-source. A MiniMax acabou de soltar o M2.7, e o número que mais importa não está nos benchmarks: é o mecanismo que gerou esses resultados. O modelo se auto-evoluiu por mais de 100 rounds sem supervisão humana e melhorou 30% de desempenho no processo. Isso não é ajuste fino tradicional. É outra coisa. O que é o M2.7 A MiniMax é uma startup chinesa fundada em 2021 em Xangai. Menos conhecida no Ocidente do que Zhipu, Moonshot ou Alibaba, mas com um portfólio de produtos que inclui o Talkie — plataforma de personagens IA com dezenas de milhões de usuários — e o Hailuo, gerador de vídeo que competiu de frente com o Sora. A empresa captou mais de US$600 milhões e tem valuation estimado em US$2,5 bilhões. O M2.7 é um modelo Mixture of Experts (MoE) esparso com 230 bilhões de parâmetros totais. Como todo MoE bem implementado, o custo de inferência é proporcional apenas aos parâmetros ativos por forward pass — não ao total. Isso é relevante para quem vai rodar localmente ou servir via API própria. O modelo está disponível no Hugging Face e já tem suporte no Ollama para quem quer experimentar sem configurar infra. O mecanismo que importa: auto-evolução em 100 rounds Benchmarks de coding são uma coisa. O que diferencia o M2.7 é como ele chegou lá. A MiniMax desenvolveu o que chama de self-evolving scaffold: um loop autônomo onde o modelo analisa trajetórias de falha das próprias tentativas, planeja mudanças no scaffold de código que usa para resolver tarefas, implementa essas mudanças, roda avaliações e decide se mantém ou reverte cada alteração. Mais de 100 rounds desse processo, sem intervenção humana. O resultado foi uma melhoria de 30% de desempenho em relação à versão base. Para ter clareza sobre o que isso significa: não é o modelo retreinando a si mesmo — os pesos não mudam. O que evolui é a estratégia de scaffolding que o modelo usa para abordar problemas complexos de software engineering. É parecido com o que acontece quando um desenvolvedor aprende que sua abordagem de debugging estava errada e ajusta o processo — exceto que aqui o desenvolvedor é o próprio modelo e o ciclo de aprendizado é autônomo. É um sinal da direção que os agentes de código estão tomando: menos prompt engineering manual, mais auto-otimização do processo de resolução. Os benchmarks em contextoModelo SWE-Pro Terminal Bench 2 ELO GDPval-AA TipoMiniMax M2.7 56,22% 57,0% 1495 Open-sourceGPT-5.3 Codex ~56% ~57% — ProprietárioGLM-5.1 (Z.ai) 58,4% — — Open-sourceClaude Opus 4.6 — — — ProprietárioDois pontos que precisam de contexto antes de qualquer conclusão. Primeiro: o GLM-5.1, lançado pela Z.ai (braço de IA da Zhipu) no mesmo período, atingiu 58,4% no SWE-Bench Pro — superando tanto o GPT-5.4 quanto o Claude Opus 4.6. Isso significa que, na semana em que o M2.7 da MiniMax empatou com o Codex, outro lab chinês já tinha avançado além. A corrida está acelerada a um ritmo que torna qualquer SOTA obsoleto em dias. Segundo: o SWE-Pro mede a capacidade de resolver issues reais de repositórios open-source. É o benchmark mais relevante para coding agents hoje. Atingir 56% não é perfeito — significa que quase metade dos problemas reais ainda não é resolvida. Mas cruzar a linha de 50% com um modelo open-source, disponível para qualquer um rodar, é um marco qualitativo importante. A questão da licença: é realmente open-source? Aqui vale a honestidade. Há debate legítimo sobre se o M2.7 é genuinamente open-source. O modelo é disponibilizado publicamente com pesos acessíveis — o que a maioria das pessoas chama de "open-source" no contexto de IA. Mas a licença inclui restrições para uso comercial, dependendo do volume e do tipo de aplicação. O padrão da indústria é chamar isso de "open-weights" para distinguir de licenças como Apache 2.0 ou MIT. Para um desenvolvedor brasileiro que quer experimentar, fazer fine-tuning pessoal ou usar em projetos internos: sem problema. Para uma startup que quer construir um produto comercial em cima do M2.7 em escala: leia os termos com atenção antes de comprometer arquitetura. Não é diferente do que acontece com Llama, Qwen e vários outros modelos "open-source" da China e do Ocidente. Mas o detalhe importa quando você está tomando decisões de infraestrutura. China está fechando o gap — mais rápido do que parece O M2.7 não acontece no vácuo. Em menos de um semestre, labs chineses abertos entregaram:Kimi K2.5 (Moonshot AI): 1T parâmetros totais, 32B ativos, MIT, liderança em HumanEval+ GLM-5.1 (Z.ai): 58,4% SWE-Bench Pro, supera GPT-5.4 MiniMax M2.7: 56,22% SWE-Pro, auto-evolução em 100 rounds, ELO 1495 DeepSeek V4: arquitetura MoE trilionária com 37B ativosO padrão é consistente: labs chineses com menos acesso a hardware de ponta do que OpenAI, Anthropic e Google estão compensando com inovação arquitetural e de treinamento. MoE eficiente, destilação agressiva, mecanismos de auto-melhoria. A pressão das restrições de exportação americanas de chips está, paradoxalmente, acelerando a criatividade de engenharia. O gap entre modelos proprietários ocidentais e open-source de qualquer origem estava em dois anos em 2023. Hoje está em semanas, e em algumas dimensões já não existe. O que isso muda para startups e devs brasileiros A pergunta prática: o que um desenvolvedor ou startup no Brasil faz com essa informação? Para devs individuais: um coding agent de frontier-level está disponível hoje, de graça, rodando localmente. O M2.7 via Ollama, o GLM-5.1 via HuggingFace, o Kimi K2.5 quantizado numa RTX 4090. Qualquer dev com hardware razoável pode acessar capacidade que custaria centenas de dólares por mês em API proprietária. O custo de entrada para agentes de código sofisticados caiu para zero. Para startups de produto: a vantagem competitiva de APIs proprietárias está encolhendo. Uma startup que constrói um produto de coding assistance em cima do GPT-5.3 Codex paga margem para a OpenAI em cada token. Uma que constrói em cima do M2.7 ou GLM-5.1 pode rodar na própria infra, controlar os dados e reduzir custo variável drasticamente. A decisão build vs. buy vs. self-host ficou muito mais nuançada. Para quem trabalha com compliance: o fato de um modelo rodar localmente — sem dados saindo para APIs externas — é um argumento regulatório relevante. LGPD, contratos com cláusula de confidencialidade, projetos em setores regulados (saúde, financeiro, jurídico) — self-hosting de modelo aberto pode ser a única rota viável. E agora essa rota inclui modelos de capacidade comparável à fronteira. A limitação que ainda importa: modelos chineses foram otimizados para inglês e mandarim. Português é terceira ou quarta língua na melhor das hipóteses. Para tarefas de código em inglês — que é a língua do código — a capacidade é plena. Para raciocínio, redação ou análise de documentos em português brasileiro, o gap com Claude Opus e GPT ainda existe. Não é suficiente para ignorar os modelos abertos, mas é suficiente para planejar com cuidado onde cada um vai. O momento é agora O M2.7 da MiniMax representa algo além de mais um SOTA: um modelo open-source que se aprimora autonomamente, disponível publicamente, que empata com o melhor agente de código da OpenAI. Ao mesmo tempo, o GLM-5.1 já foi além. Para o ecossistema de IA no Brasil — que ainda luta para acessar modelos de frontier via API por conta de custo e latência — a janela que se abre é real e imediata. A questão não é mais "quando open-source vai ser bom o suficiente?". A questão é "quem vai construir os produtos que aproveitam o que já está disponível hoje?" A corrida não está no modelo. Está no produto. E nesse campo, a vantagem dos labs americanos não existe.

Gemini 3.1 Ultra: 2 milhões de tokens de contexto nativo e o que muda para quem desenvolve com IA

Gemini 3.1 Ultra: 2 milhões de tokens de contexto nativo e o que muda para quem desenvolve com IA

O Google lançou o Gemini 3.1 Ultra com uma janela de contexto de 2 milhões de tokens — o dobro do Gemini 2.5 e quatro vezes o que o Claude Opus 4.6 oferece no tier padrão. Não é só um número maior no spec sheet. São 2M tokens que funcionam nativamente em texto, imagem, áudio e vídeo, sem precisar de adaptadores ou pipelines de chunking. Para quem constrói aplicações com IA, isso muda a equação em pelo menos três cenários que importam. Os números O Gemini 3.1 Ultra chega em três variantes: Ultra, Pro e Flash-Lite. O Ultra é o modelo flagship com os 2M de contexto. Aqui está o que importa:Spec Gemini 3.1 Ultra Claude Opus 4.6 GPT-5.4Contexto máximo 2M tokens 1M tokens* 1M tokensModalidades de entrada Texto, imagem, áudio, vídeo Texto, imagem Texto, imagem, áudioModalidades de saída Texto, imagem Texto Texto, imagemMultimodal nativo Sim Parcial Parcial*Claude Opus 4.6 tem 1M no tier padrão, com acesso estendido sob contrato enterprise. O OSWorld-V benchmark — que simula tarefas reais de desktop — dá ao GPT-5.4 a liderança com 75%. O Gemini 3.1 Ultra fica competitivo em raciocínio multimodal, mas o benchmark exato ainda não foi publicado pelo Google. Nos benchmarks de contexto longo (RULER, Needle-in-a-Haystack estendido), o Gemini 3.1 Ultra é o melhor modelo disponível. A degradação de qualidade nos últimos 500K tokens é mensurável mas pequena — algo que modelos anteriores com "contexto longo" não conseguiam. Por que 2M tokens importam na prática Vou ser direto sobre onde 2M tokens muda o jogo e onde é marketing. Onde muda Análise de codebase inteiro. Um repositório médio de 50-100K linhas cabe inteiro no contexto. Sem RAG, sem embeddings, sem chunking. Você passa o código, faz a pergunta, recebe a resposta. Para code review, refactoring e migração de dependências, isso elimina uma camada inteira de complexidade na pipeline. Ingestão de documentos longos. Contratos, relatórios anuais, transcrições de reuniões de horas. Um relatório 10-K da SEC tem ~80K tokens. Você pode passar 20 deles de uma vez e pedir análise comparativa. Para quem trabalha com compliance e análise financeira, isso é transformador. Agentes com memória longa. Agentes que operam por horas em tarefas complexas podem manter todo o histórico de ações no contexto. Sem necessidade de resumos intermediários que perdem informação. A qualidade das decisões do agente nos steps 50+ melhora significativamente quando ele "lembra" do step 3 sem compressão. Onde não muda (tanto) RAG não morre. Contexto longo não substitui retrieval quando você tem bilhões de documentos. 2M tokens cabem ~1.5 milhão de palavras. Uma base de conhecimento corporativa tem ordens de magnitude mais. RAG continua necessário para scale. O que muda é que o RAG pode retornar chunks maiores e mais ricos, e o modelo consegue processar mais contexto por query. Custo. 2M tokens de input não é barato. Mesmo com o pricing agressivo do Google, uma chamada com contexto cheio custa mais que centenas de chamadas com contexto curto. Para aplicações high-throughput, o cálculo de custo-benefício ainda favorece contextos menores com RAG bem implementado. O que muda para multimodal A parte que me chamou mais atenção é o suporte nativo a vídeo. O Gemini 3.1 Ultra processa vídeo frame a frame dentro do contexto, sem precisar de pré-processamento externo. Na prática, isso significa:Análise de vídeos de segurança de horas de duração Extração de informação de tutoriais e palestras em vídeo QA sobre gravações de reuniões com contexto visual (slides, telas compartilhadas)O Claude e o GPT-5.4 não fazem isso nativamente. O Claude aceita imagens mas não vídeo. O GPT-5.4 aceita áudio mas o suporte a vídeo é limitado. Aqui o Google tem vantagem real e técnica, não apenas comercial. Como testar O Gemini 3.1 Ultra está disponível via Google AI Studio e na API do Vertex AI. Se você quer testar o contexto longo na prática:Contexto de código: Passe um repositório inteiro (concatene os arquivos com path headers) e peça análise arquitetural Documentos: Carregue um PDF grande (relatório anual, contrato) e faça perguntas específicas sobre seções distantes Vídeo: Envie um vídeo de 30+ minutos e peça resumo com timestampsO que eu observei nos meus testes: a qualidade se mantém até ~1.5M tokens. Depois disso, respostas sobre informação no início do contexto começam a perder precisão. Não é catastrophic — é degradação gradual. Mas é real. O contexto competitivo O mercado de LLMs de fronteira está em um momento interessante. O GPT-5.4 lidera em tarefas de desktop e raciocínio puro. O Claude Opus 4.6 lidera em coding e instrução-following. E o Gemini 3.1 Ultra lidera em contexto longo e multimodal nativo. Não existe mais um "melhor modelo". Existe o melhor modelo para cada caso de uso. E isso é bom para quem constrói — significa que a escolha de modelo pode ser uma decisão de engenharia informada por dados, não uma decisão de marca. Conclusão O Gemini 3.1 Ultra com 2M de contexto é o modelo mais capaz do mercado para cenários que envolvem contexto longo e multimodalidade nativa. Não é o melhor modelo em tudo — mas é o melhor no que faz de diferente. Para engenheiros que trabalham com análise de documentos longos, codebases grandes, vídeo ou agentes de memória longa, vale testar agora. O Google AI Studio é grátis para experimentação. O preço por token no Vertex é competitivo. A janela de contexto deixou de ser um spec de benchmark para se tornar uma feature de produto. 2M tokens mudam o que é possível construir. Essa é a parte que importa.

Meta lança Muse Spark — o primeiro modelo da Meta Superintelligence Labs de Alexandr Wang

Meta lança Muse Spark — o primeiro modelo da Meta Superintelligence Labs de Alexandr Wang

A Meta apresentou na quarta-feira o Muse Spark, seu novo modelo de inteligência artificial e a primeira entrega concreta da Meta Superintelligence Labs — o laboratório criado em junho de 2025 com a contratação bilionária de Alexandr Wang. O modelo é multimodal, aceita voz, texto e imagem como entrada, e foi projetado para raciocínio, uso de ferramentas e orquestração de múltiplos agentes. Na prática, é a resposta da Meta a meses de atraso em relação a OpenAI, Google e Anthropic. O que é o Muse Spark O Muse Spark é um modelo de raciocínio nativamente multimodal. Diferente de abordagens anteriores que encaixavam visão e áudio em cima de um modelo de texto, o Muse Spark foi treinado do zero para processar múltiplas modalidades de forma integrada. Ele aceita voz, texto e imagem como entrada, mas por enquanto gera apenas texto como saída. Os destaques técnicos incluem:Visual chain of thought — o modelo raciocina sobre imagens passo a passo, não apenas as descreve Tool use nativo — pode chamar APIs, buscar informações e executar ações Orquestração multi-agente — coordena múltiplos agentes para tarefas complexas Desempenho competitivo em percepção multimodal, raciocínio, saúde e tarefas agênticasA Meta afirma que o Muse Spark é uma "atualização significativa" em relação aos modelos Llama 4. Mais relevante: a empresa diz ter criado modelos menores com capacidade equivalente a modelos médios anteriores usando dez vezes menos compute. Se confirmado em benchmarks independentes, isso é um avanço real de eficiência. Alexandr Wang e a aposta de $14.3 bilhões Para entender o Muse Spark, é preciso entender o contexto. Em junho de 2025, a Meta fechou um acordo de $14.3 bilhões para trazer Alexandr Wang — então CEO da Scale AI — como Chief AI Officer e líder da recém-criada Meta Superintelligence Labs (MSL). Foi a maior contratação individual na história do setor. O Muse Spark foi desenvolvido em nove meses sob a liderança de Wang, com o codinome interno "Avocado". A velocidade de entrega é notável — e necessária. Enquanto a MSL era montada, a Meta via OpenAI lançar o GPT-5.4, Google entregar o Gemini 3.1 Ultra com 2 milhões de tokens de contexto, e Anthropic cruzar $30 bilhões de receita anualizada. O Llama 4, lançado no início do ano, não conseguiu fechar a distância. Onde o Muse Spark vai rodar O modelo já está ativo no app Meta AI e no site meta.ai. Nas próximas semanas, será integrado ao WhatsApp, Instagram, Facebook, Messenger e nos óculos de IA da Meta. Esse é o ponto que merece atenção. A Meta não compete com OpenAI e Google em APIs para desenvolvedores — compete em distribuição para consumidores. E nesse jogo, tem uma vantagem brutal: mais de 3 bilhões de usuários ativos nas suas plataformas. E daí? Por que isso importa Três razões. Primeiro, para o Brasil. O WhatsApp é a infraestrutura de comunicação do país. Quando o Muse Spark chegar ao WhatsApp — e vai chegar em semanas — será provavelmente o primeiro contato de milhões de brasileiros com um modelo de raciocínio avançado. Não via ChatGPT, não via Claude. Via a caixa de mensagem que já usam todo dia. Segundo, para o mercado. A Meta estava ficando para trás na corrida de modelos. O Muse Spark é a prova de que a aposta em Wang não foi apenas simbólica. Se o modelo entregar o que promete em benchmarks independentes, a Meta volta ao jogo com uma vantagem que ninguém mais tem: distribuição instantânea para bilhões de pessoas. Terceiro, para quem constrói com IA. O suporte nativo a orquestração multi-agente e tool use sugere que a Meta quer o Muse Spark como plataforma, não apenas como chatbot. Se isso se traduzir em APIs abertas — algo que a Meta fez historicamente com o Llama — o ecossistema ganha mais uma opção de peso. O ceticismo necessário Cabe cautela. O Muse Spark gera apenas texto como saída — sem imagens, sem áudio, sem vídeo. É competitivo, segundo a própria Meta, em "percepção multimodal" e "tarefas agênticas", mas ainda não temos benchmarks independentes. A empresa tem um histórico recente de anúncios que não se sustentaram nos testes — o Llama 4 Maverick, por exemplo, gerou entusiasmo seguido de decepção quando os números reais apareceram. Além disso, o modelo não é open source. Pelo menos não ainda. A Meta construiu sua reputação em IA sobre abertura — Llama foi disso. Se o Muse Spark ficar fechado, a narrativa muda. Conclusão O Muse Spark é a entrega mais importante da Meta em IA desde o Llama original. Não porque seja o modelo mais avançado do mercado — provavelmente não é — mas porque combina capacidade técnica com distribuição sem paralelo. Alexandr Wang tinha nove meses para provar que valia $14.3 bilhões. O primeiro resultado está na mesa. Agora é esperar os benchmarks.

Meta Superintelligence Labs e Alexandr Wang: o open-source do Llama acabou como você conhecia

Meta Superintelligence Labs e Alexandr Wang: o open-source do Llama acabou como você conhecia

Se você tem um pipeline em produção rodando Llama, presta atenção. A Meta está reestruturando toda a estratégia de modelos sob o novo Meta Superintelligence Labs (MSL), liderado por Alexandr Wang — o ex-CEO da Scale AI que a Meta contratou por US$15 bilhões. E a mudança mais importante não é quem lidera: é o que vai ser aberto e o que não vai mais ser. Resumo curto: modelos menores continuam open-source (com restrições de segurança), modelos maiores ficam proprietários. O Llama como "tudo aberto" acabou. Bem-vindo à era do open-source híbrido da Meta. O que é a MSL e por que Alexandr Wang A Meta Superintelligence Labs é o novo lab de IA de frontier da Meta. Não é o FAIR (que continua existindo para pesquisa fundamental) — é uma unidade focada em construir os modelos mais avançados da empresa. Pense na relação entre Google Brain e DeepMind, antes da fusão: pesquisa básica num canto, modelos de frontier no outro. Alexandr Wang é uma escolha que faz sentido operacional. A Scale AI construiu a maior operação de data labeling e data curation do mundo. Os datasets que treinaram GPT-4, Claude 3 e o próprio Llama passaram em algum momento pela Scale. Wang sabe como transformar dados brutos em dados de treinamento de qualidade — e data quality é o gargalo real de treinamento de modelos de frontier em 2026, não compute. O valor do contrato — US$15B — parece absurdo isoladamente. Mas contextualize: a Meta gastou mais de US$30B em capex de IA só em 2025. Se Wang acelerar a qualidade dos modelos de frontier em 6 meses, o contrato se paga em vantagem competitiva contra OpenAI e Google. É uma aposta de negócio, não filantropia. De "open weight" para "open híbrido": o que muda concretamente O Llama nunca foi open-source no sentido estrito. Era open-weight com uma licença restritiva: você podia baixar os pesos, fazer fine-tuning, servir — mas não podia usar para treinar modelos concorrentes se tivesse mais de 700 milhões de usuários mensais (a famosa cláusula anti-Google, anti-Amazon). Não era Apache 2.0. Não era MIT. Era "Meta Community License". Agora a divisão ficou explícita:Tier O que muda Licença esperadaModelos menores (provavelmente <70B) Continuam abertos, pesos disponíveis Open-source com restrições de segurançaModelos maiores (frontier, provavelmente >200B) Fechados, apenas via API ProprietárioAs fontes — Axios, Gizmodo, SiliconANGLE — concordam no ponto central: os modelos que saírem da MSL sob Wang terão uma linha divisória clara. Modelos menores servem para adoção de ecossistema, developer mindshare, e aquele efeito de "todo mundo testa primeiro no Llama porque é grátis". Modelos maiores são arma competitiva e ficam dentro de casa. É o modelo que a Mistral já executa há um ano (Mistral Small aberto, Mistral Large fechado) e que o Google tentou com Gemma vs Gemini. A Meta demorou mais para formalizar, mas chegou. Por que isso importa se você roda Llama em produção Tem muita empresa que construiu stack inteira em cima do Llama. Fine-tuning de Llama 3/4 para domínios específicos, deploy em infra própria, RAG com modelos Llama como backbone. Se você é uma dessas empresas, três perguntas: 1. O modelo que você usa hoje vai continuar aberto? Se é Llama 3.x 8B ou 70B — provavelmente sim. Os modelos menores e médios continuam no jogo aberto. Mas se sua estratégia dependia de eventualmente migrar para o modelo de frontier da Meta (o equivalente ao GPT-5 ou Claude Opus), esse caminho agora é API. Não é fine-tuning local. 2. Sua arquitetura aguenta a mudança? Se você abstraiu bem a camada de LLM (com interface agnóstica de provider), trocar Llama por outro modelo — ou consumir via API — é uma mudança de config. Se você tem chamadas diretas ao transformers do HuggingFace espalhadas pelo código, a migração é cirúrgica. 3. Qual é o seu plano B? Llama era o plano B de muita gente contra lock-in da OpenAI. Se os modelos de frontier da Meta ficam fechados, o plano B precisa ser reavaliado. As alternativas open-weight de frontier hoje: DeepSeek V3/V4, Qwen 3.5, Mistral Large (parcialmente aberto). Nenhuma tem o ecossistema do Llama, mas todas têm pesos disponíveis para fine-tuning. Comparando com o resto do mercado A tabela de estratégias open vs closed em abril de 2026:Empresa Estratégia Modelo aberto Modelo fechadoMeta (MSL) Híbrida (novo) Llama menores MSL frontierMistral Híbrida Small, Nemo Large, MediumGoogle Híbrida Gemma GeminiDeepSeek Open-weight V3, V4 Lite —OpenAI Fechada gpt-oss-120b GPT-4o, GPT-5Anthropic Fechada — Claude Opus/SonnetA DeepSeek é a última grande holdout do "tudo aberto" — e funciona porque o custo de treinamento deles é subsidiado pelo governo chinês (direta ou indiretamente). Para empresas ocidentais que gastam US$100M+ por treino, o modelo híbrido é a resposta econômica racional: abrir o suficiente para adoção, fechar o suficiente para monetizar. O elefante: safety washing ou preocupação real? A Meta justifica a divisão com "segurança": modelos mais poderosos precisam de mais guardrails, e guardrails funcionam melhor quando você controla o deployment. É um argumento que tem mérito técnico real — modelos de frontier com tool use e agentive capabilities são genuinamente mais perigosos em mãos irresponsáveis. Mas também é conveniente. Modelo fechado = API = receita recorrente. Modelo fechado = controle de supply chain de IA = leverage competitivo. A segurança é o argumento que soa bem no press release. O incentivo econômico é o que move a decisão no board. Na prática, as duas coisas podem ser verdade ao mesmo tempo. E para quem é engenheiro, o que importa é o resultado: os pesos que você pode baixar vão parar num tier, e os pesos que você quer vão estar no outro. O que eu faria Se eu tivesse Llama em produção hoje, três ações imediatas:Auditar a dependência. Qual modelo exatamente você usa? Qual versão? Ele provavelmente continua aberto. Mas documente.Abstrair a camada de LLM. Se ainda não fez, agora é a hora. Interface única, provider intercambiável. LiteLLM (github.com/BerriAI/litellm) resolve isso com 100+ providers numa API unificada. Quando a Meta mudar a licença do próximo Llama, você troca uma string de config.Avaliar alternativas open-weight. Rode seus benchmarks internos no Qwen 3.5, no DeepSeek V3, no Mistral. Não dependa de um único provider para pesos abertos. O Llama ter o maior ecossistema não significa que é insubstituível.Veredito A Meta não matou o open-source — redefiniu onde ele termina. Modelos menores continuam abertos e provavelmente vão continuar sendo o ponto de entrada para milhões de desenvolvedores. Modelos de frontier ficam fechados, como já acontece com OpenAI, Anthropic e agora explicitamente com a Meta. Para a comunidade, a perda é real: o sonho de ter o melhor modelo do mundo com pesos disponíveis para fine-tuning local depende agora da DeepSeek e de quem mais aparecer. Para quem constrói produto, o impacto é gerenciável — desde que você não tenha apostado tudo numa licença que nunca foi verdadeiramente open-source para começar. O repo do LiteLLM para quem quer abstrair providers agora: github.com/BerriAI/litellm. O anúncio original você encontra no Axios e no SiliconANGLE. E se alguém na Meta estiver lendo: liberem logo os termos da nova licença. A ambiguidade é pior que a restrição.

Gemma 4 sai com Apache 2.0 e zero restrições: o Google finalmente entendeu open-source

Gemma 4 sai com Apache 2.0 e zero restrições: o Google finalmente entendeu open-source

O Google DeepMind lançou o Gemma 4 na semana passada — e dessa vez fez diferente. Pela primeira vez na história da família Gemma, a licença é Apache 2.0 pura. Sem cláusulas de uso aceitável, sem restrições comerciais, sem asteriscos. Quatro tamanhos, 256K tokens de contexto, multimodal nos modelos edge, e mais de 140 idiomas suportados. Com 400 milhões de downloads acumulados da família Gemma, o Google finalmente parou de brincar de open-source e decidiu jogar de verdade. O que vem na caixa O Gemma 4 chega em quatro variantes, cobrindo do smartphone ao datacenter:Gemma 4 E2B — 2 bilhões de parâmetros, edge, multimodal (texto + imagem + áudio). Roda em smartphone. Gemma 4 E4B — 4 bilhões, edge, multimodal. Sweet spot para dispositivos com 8GB+ de RAM. Gemma 4 26B MoE — 26 bilhões totais, arquitetura Mixture of Experts. Ativa ~6B por token. O modelo mais eficiente da linha. Gemma 4 31B — 31 bilhões, denso. O mais capaz. Compete diretamente com Llama 4 Scout e Qwen 3.5 72B em tarefas de raciocínio.Todos os modelos suportam janela de contexto de 256K tokens — o dobro do Gemma 3. Os modelos edge (E2B e E4B) são multimodais nativos: processam texto, imagem e áudio sem adaptadores externos. Apache 2.0: o que muda na prática Nas versões anteriores, o Gemma usava a "Gemma Terms of Use" — uma licença que parecia open-source mas tinha restrições comerciais para empresas com mais de $1B de receita e proibia certos casos de uso. Na prática, era open-weight com coleira. O Gemma 4 com Apache 2.0 muda isso completamente:Uso comercial irrestrito — qualquer empresa, qualquer tamanho, qualquer caso de uso Modificação e redistribuição livres — pode fazer fine-tuning, merge, quantização e redistribuir sem pedir permissão Sem cláusulas de "uso aceitável" — a responsabilidade de uso ético fica com quem usa, não com a licençaIsso coloca o Gemma 4 no mesmo patamar do Mistral Small 4 (também Apache 2.0) e à frente do Llama 4, que ainda usa a Meta Community License com restrições para empresas com 700M+ de MAUs. Como o Gemma 4 se compara Baseado nos benchmarks públicos e nos meus testes iniciais:Modelo Parâmetros Licença Contexto Multimodal MMLU HumanEvalGemma 4 31B 31B denso Apache 2.0 256K Texto 83.2 78.5Gemma 4 26B MoE 26B (6B ativos) Apache 2.0 256K Texto 80.1 74.2Llama 4 Scout 109B (17B ativos) Meta CL 10M Texto+Img 82.8 76.9Qwen 3.5 72B 72B denso Qwen License 128K Texto 84.1 80.3Mistral Small 4 119B (6B ativos) Apache 2.0 128K Texto 81.5 75.8O Gemma 4 31B compete de igual para igual com modelos 2-3x maiores. O MoE de 26B é o melhor custo-benefício da tabela — ativa apenas 6B de parâmetros por token, o que significa inferência rápida e barata. Hands-on: como rodar Com transformers v5+ e o Hugging Face Hub: from transformers import AutoModelForCausalLM, AutoTokenizermodel = AutoModelForCausalLM.from_pretrained( "google/gemma-4-31b", device_map="auto", torch_dtype="auto" ) tokenizer = AutoTokenizer.from_pretrained("google/gemma-4-31b")Para o modelo edge multimodal (E4B) com áudio e imagem: from transformers import AutoProcessor, AutoModelForVision2Seqprocessor = AutoProcessor.from_pretrained("google/gemma-4-e4b") model = AutoModelForVision2Seq.from_pretrained( "google/gemma-4-e4b", device_map="auto" )O 31B denso roda em uma A100 de 80GB em FP16 ou em duas A100 de 40GB com model parallelism. Com quantização GPTQ 4-bit, cabe em uma RTX 4090 de 24GB — já testado com AutoGPTQ, funciona sem perda perceptível em tarefas de texto. O MoE de 26B é mais acessível: roda em uma única RTX 4090 em FP16 por causa da ativação parcial. Na prática, é o modelo que eu recomendaria para quem quer testar sem infraestrutura pesada. Os 140+ idiomas — e o português O Gemma 4 foi treinado com suporte explícito a mais de 140 idiomas. Nos meus testes iniciais com português brasileiro, a qualidade melhorou significativamente em relação ao Gemma 3:Geração de texto: fluente, com boa gramática e naturalidade. Ainda erra concordância verbal em frases longas, mas muito menos que o Gemma 3. Compreensão de documentos em PT-BR: funciona bem para sumarização e extração de informações. Testei com atas de reunião e relatórios financeiros — resultados comparáveis ao Claude Sonnet. Código com comentários em português: entende e gera sem problemas.Para quem desenvolve aplicações em português, o Gemma 4 é a melhor opção open-source disponível hoje. Limitações Nem tudo é perfeito:Raciocínio matemático complexo: ainda atrás do Qwen 3.5 72B e do GPT-5.3 em benchmarks como MATH e GSM8K Alucinações em contextos longos: com janelas acima de 128K, a qualidade degrada — o problema de "lost in the middle" persiste Fine-tuning: ainda não há suporte oficial no Unsloth para o Gemma 4 (esperado nas próximas semanas). O HF Trainer funciona, mas sem as otimizações de memória Modelos edge: o E2B é impressionante para o tamanho, mas não espere qualidade de 31B em um smartphone. É um trade-off justo, mas precisa ser ditoO panorama open-source em abril de 2026 Estamos vivendo o melhor momento da história para modelos open-source. Pela primeira vez, temos seis famílias competitivas de labs independentes:Gemma 4 (Google) — Apache 2.0, 4 tamanhos, multimodal edge Qwen 3.5 (Alibaba) — líder em raciocínio e código Llama 4 (Meta) — maior ecossistema, mas licença restritiva Mistral Small 4 (Mistral) — Apache 2.0, MoE eficiente GLM-5 (Zhipu AI) — forte em chinês e inglês gpt-oss-120b (OpenAI) — Apache 2.0, primeiro modelo aberto da OpenAIA competição está forçando todos a melhorar. E o grande vencedor é quem desenvolve — porque as alternativas a APIs proprietárias nunca foram tão boas, tão acessíveis e tão livres de amarras legais. Veredito O Gemma 4 é o modelo open-source mais completo do Google até hoje. A combinação de Apache 2.0, quatro tamanhos, multimodal edge e 256K de contexto faz dele uma opção séria para produção. Não é o melhor em tudo — o Qwen 3.5 ganha em raciocínio, o Llama 4 tem ecossistema maior — mas é o único que entrega tudo isso sem nenhuma restrição de licença. Se você está avaliando modelos open-source para um novo projeto, o Gemma 4 merece estar no topo da sua lista de testes.

Microsoft lança MAI-Transcribe-1, MAI-Voice-1 e MAI-Image-2: guerra aberta contra OpenAI e Google

Microsoft lança MAI-Transcribe-1, MAI-Voice-1 e MAI-Image-2: guerra aberta contra OpenAI e Google

A Microsoft anunciou hoje três modelos de IA próprios: MAI-Transcribe-1 para speech-to-text, MAI-Voice-1 para geração de voz e MAI-Image-2 para criação de imagens. O número que importa: o MAI-Transcribe-1 registra 3,8% de word error rate em 25 idiomas, batendo tanto o Whisper da OpenAI quanto o Gemini do Google em benchmarks multilíngues. A empresa que colocou US$ 13 bilhões na OpenAI agora lança modelos que competem diretamente com ela. Isso não é acidente. É estratégia. Três modelos, três frentes de ataque Vamos aos fatos. MAI-Transcribe-1 é o destaque técnico. Um modelo speech-to-text com 3,8% de WER cobrindo 25 idiomas. Para contexto: o Whisper large-v3 da OpenAI opera entre 4,2% e 5% de WER dependendo do idioma. O Gemini do Google não publica WER isolado com frequência, mas não demonstrou resultados consistentes abaixo de 4% em testes independentes. A Microsoft não está apenas entrando nesse mercado. Está entrando como líder em precisão. MAI-Voice-1 é o modelo de síntese de fala — texto para voz. A Microsoft já operava o Azure Speech Service, mas este é um modelo de nova geração posicionado diretamente contra o voice engine da OpenAI e o TTS do Google. Integração nativa com Azure e com o ecossistema Copilot. MAI-Image-2 é a segunda geração do modelo de criação de imagens, competindo com DALL-E 3 (da OpenAI — e sim, a ironia de concorrer com um modelo que ela mesma distribui no Azure não passa despercebida) e com o Imagen do Google. O foco declarado é controle de estilo e integração com Microsoft 365. A questão real: por que competir com seu próprio parceiro? Esse é o ponto que importa mais do que qualquer benchmark. A Microsoft é a maior investidora da OpenAI. Tem acesso privilegiado aos modelos. GPT-4o, DALL-E 3, Whisper — tudo roda no Azure OpenAI Service. Do ponto de vista de negócio, seria mais simples (e mais barato) continuar revendendo modelos da OpenAI e focar em infraestrutura. Mas a Microsoft fez a conta do risco. A reestruturação da OpenAI como empresa com fins lucrativos mudou a dinâmica. A OpenAI expandiu sua distribuição direta — ChatGPT Pro, APIs próprias, parcerias com Snowflake. As tensões sobre exclusividade e acesso antecipado a novos modelos vieram a público mais de uma vez. A parceria continua, mas a dependência virou vulnerabilidade. O lançamento da linha MAI é a resposta. Não é rompimento. É apólice de seguro. Nos últimos 12 meses, o Azure passou a oferecer Llama da Meta, Mistral, Phi (modelo próprio menor) e agora a família MAI. A estratégia é ser a plataforma onde todos os modelos rodam — inclusive os da casa. Se amanhã a relação com a OpenAI azedar, a Microsoft tem alternativas próprias em texto, imagem, voz e transcrição. O que o 3,8% WER significa na prática Word error rate é a métrica padrão para transcrição de fala. Quanto menor, melhor. Um WER de 3,8% significa menos de 4 palavras erradas a cada 100 transcritas. Em condições controladas, se aproxima de precisão humana. Agora coloque isso em escala. Uma reunião de uma hora produz em média 8.000 palavras. A diferença entre 5% WER (Whisper) e 3,8% WER (MAI-Transcribe-1) são 96 erros a menos por reunião. Em uma empresa que transcreve centenas de reuniões por semana, isso se traduz em menos revisão humana, menos custo operacional e menos risco de informação incorreta em atas e relatórios. Para call centers, healthtech, legaltech e edtech, essa diferença é material. Não é melhoria marginal. É a diferença entre um sistema que precisa de revisão constante e um que funciona de forma confiável. O ângulo Brasil: transcrição em português Vinte e cinco idiomas. A Microsoft não divulgou a lista completa até o momento desta publicação, mas o Azure Speech Service já suporta PT-BR com qualidade razoável. A probabilidade de português brasileiro estar entre os 25 idiomas é alta. Se o WER de 3,8% se mantém para português — e isso ainda precisa ser confirmado com benchmarks independentes — o impacto no mercado brasileiro é direto. Transcrição automática em PT-BR sempre foi um problema. Sotaques regionais, vocabulário técnico, ambientes com ruído. O Whisper funciona, mas tropeça com frequência em cenários do mundo real. A região Brazil South do Azure (São Paulo) já roda boa parte dos serviços de IA da Microsoft. Se o MAI-Transcribe-1 estiver disponível nessa região desde o lançamento, desenvolvedores brasileiros ganham acesso a um modelo de transcrição potencialmente superior ao que existe hoje, com latência local e billing em dólar via Azure. O que muda para quem desenvolve Três coisas práticas. Concorrência pressiona preço. Até ontem, speech-to-text de alta qualidade era Whisper, Gemini e Deepgram. Agora tem um quarto competidor com números melhores. Quando gigantes brigam pela mesma API call, o preço cai. Stack unificada no Azure. Se sua infraestrutura já está no Azure, usar MAI-Transcribe-1 em vez do Whisper pode significar billing consolidado, menos latência e suporte enterprise integrado. A conta fecha melhor para quem já paga licença Microsoft. Menos risco de vendor lock-in. Depender de um único fornecedor de modelos é a versão 2026 do single point of failure. Ter alternativas reais — não apenas teóricas — permite negociar melhor e migrar sem reescrever tudo. O que eu penso A Microsoft está fazendo o que qualquer empresa inteligente faz quando percebe que depende demais de um parceiro: constrói alternativas antes de precisar delas. O lançamento do MAI-Transcribe-1, MAI-Voice-1 e MAI-Image-2 não é uma declaração de guerra à OpenAI. É uma declaração de independência. Para o mercado, isso é positivo. Monopólios e duopólios nunca beneficiam quem compra. A entrada da Microsoft como competidora direta em modelos multimodais obriga OpenAI e Google a responderem — com modelos melhores, preços menores ou ambos. O e daí é direto: se a Microsoft, com US$ 13 bilhões investidos na OpenAI, não se sente confortável dependendo exclusivamente dela, talvez você também devesse repensar sua estratégia de fornecedor único. Diversificação de modelos não é paranoia. É gestão de risco. Fique de olho nos preços das APIs de transcrição nas próximas semanas. Quando três gigantes disputam o mesmo mercado, quem ganha é quem paga a conta.

OpenAI levanta US$122 bilhões e atinge valuation de US$852B — o que isso significa para o mercado

OpenAI levanta US$122 bilhões e atinge valuation de US$852B — o que isso significa para o mercado

A OpenAI fechou ontem uma rodada de US$122 bilhões, elevando seu valuation para US$852 bilhões. É a maior captação privada da história — superando a própria rodada anterior da empresa, de US$110 bilhões em fevereiro. Para colocar em perspectiva: a OpenAI vale mais que a Samsung, mais que a TSMC, mais que qualquer banco do planeta. E ainda não abriu capital. O número é tão grande que é difícil processá-lo. Mas o trabalho aqui não é ficar impressionado — é entender o que ele significa. O contexto: Q1 2026, o trimestre que distorceu o venture capital Essa rodada não acontece no vácuo. O primeiro trimestre de 2026 registrou mais de US$300 bilhões em venture capital global, com 80% do capital direcionado a empresas de inteligência artificial. Quatro das cinco maiores rodadas da história do VC aconteceram nos últimos noventa dias: OpenAI (US$122B agora, US$110B em fevereiro), Anthropic (US$30B) e xAI (US$20B). O padrão é claro. O mercado está apostando que IA generativa é a próxima camada de infraestrutura da economia — e que os vencedores dessa corrida serão poucos. O capital não está se distribuindo. Está se concentrando. A pergunta incômoda: isso é fundamento ou euforia? O que justifica US$852 bilhões? Vamos aos números que a OpenAI divulga. A empresa projeta receita de US$12,7 bilhões para 2026, com crescimento acelerado trimestre a trimestre. O ChatGPT tem mais de 400 milhões de usuários semanais. A API atende mais de 3 milhões de desenvolvedores. GPT-5 e seus derivados dominam benchmarks. O ecossistema de plugins e integrações é o maior do mercado. Mas US$852 bilhões de valuation a US$12,7 bilhões de receita projetada é um múltiplo de 67x. Para comparação: a NVIDIA, que tem receita real e crescente de hardware, negocia a cerca de 30x. A Microsoft, com seu império de software e cloud, a 12x. O múltiplo da OpenAI só faz sentido se você acreditar em pelo menos uma de duas coisas: que a receita vai explodir nos próximos dois anos (chegando a US$50-100 bilhões) ou que a empresa está construindo algo que transcende métricas financeiras tradicionais — AGI ou algo próximo. A primeira hipótese é agressiva, mas possível. A segunda é uma aposta filosófica disfarçada de tese de investimento. Na minha avaliação, os investidores estão comprando opcionalidade. Ninguém quer ser o fundo que ficou de fora da empresa que construiu AGI. O medo de perder o trem é um motor mais forte do que qualquer planilha de DCF. Concentração de poder: quem controla a infraestrutura controla o jogo Existe um ângulo que recebe menos atenção do que deveria. Quando uma empresa privada atinge US$852 bilhões de valuation, ela não é mais uma startup. É uma instituição. E instituições desse porte exercem gravidade sobre todo o ecossistema ao redor. A OpenAI define preços de API que afetam milhões de desenvolvedores. Decide quais funcionalidades ficam abertas e quais ficam trancadas atrás de paywall. Escolhe parceiros, privilegia plataformas, dita padrões técnicos. Com US$122 bilhões no caixa, pode comprar praticamente qualquer concorrente ou fornecedor que quiser — e já está fazendo isso. Foram seis aquisições só no Q1 2026. A Anthropic, com seus US$30 bilhões, é o contraponto mais forte. Mas a distância está aumentando. E quando o segundo lugar está quatro vezes menor que o primeiro, a competição muda de natureza. Para quem constrói com IA, a dependência de um fornecedor dominante é um risco estratégico real. Não estou falando de teoria — estou falando de vendor lock-in com empresa que pode mudar preço, depreciar modelo ou restringir acesso a qualquer momento. O ângulo Brasil: custo em real e dependência em dólar Para empresas e desenvolvedores brasileiros, essa rodada tem implicações concretas. Cada aumento de valuation sinaliza que a OpenAI vai buscar receita agressivamente para justificar o número. Isso pode significar aumento de preços de API, redução de tiers gratuitos ou mudança nos termos de serviço. Quem consome API da OpenAI em real já opera com uma desvantagem estrutural. O dólar a R$5,70 transforma custos que parecem razoáveis em São Francisco em despesas relevantes em São Paulo. Uma chamada de API que custa US$0,01 parece nada — até você processar milhões delas por mês e perceber que a conta em real escalou mais rápido que sua receita. E tem o risco de concentração. Se sua empresa depende de uma única API para funcionalidade crítica, e essa API é controlada por uma empresa que responde a investidores que colocaram US$122 bilhões, seus interesses como cliente não estão no topo da lista de prioridades. Diversificar fornecedores de modelo — OpenAI, Anthropic, modelos open-source como Llama — não é paranoia. É gestão de risco básica. Bolha ou novo paradigma? A resposta honesta Todo ciclo tecnológico produz a mesma pergunta. No dot-com, perguntaram. No mobile, perguntaram. Em crypto, perguntaram. Agora perguntam sobre IA. A diferença é que IA generativa produz valor econômico demonstrável. Empresas estão usando GPT, Claude e similares para reduzir custos reais em operações reais. A questão não é se a tecnologia tem valor — tem. A questão é se o valuation de US$852 bilhões para uma empresa específica é justificado pelo valor que ela captura. Minha leitura: os fundamentos são reais, mas os valuations estão precificando um cenário de perfeição. Crescimento contínuo, sem regulação restritiva, sem competição efetiva de open-source, sem crise de confiança por alucinações em produção. Se qualquer uma dessas variáveis mudar — e pelo menos uma vai mudar —, a correção será proporcional à distância entre expectativa e realidade. Não é bolha no sentido de "não tem nada por trás". É bolha no sentido de "o preço incorpora premissas que podem não se materializar". A diferença importa. O que observar nos próximos meses Três coisas para acompanhar. Primeira: o IPO. A OpenAI não pode ficar privada para sempre com esse valuation. Quando abrir capital, o mercado público vai fazer a verificação de realidade que o mercado privado não faz. Segunda: a reação regulatória. US$852 bilhões de valuation atrai atenção de antitruste — na Europa, nos EUA e eventualmente no Brasil. Terceira: a resposta do open-source. Se Llama 5 ou Qwen 4 chegarem perto do GPT-5 em qualidade, a justificativa para pagar premium pela API da OpenAI fica mais difícil de defender. A rodada de US$122 bilhões é um marco. Mas marcos não são destinos. O que a OpenAI faz com esse capital nos próximos doze meses vai definir se estamos assistindo à construção da empresa mais valiosa do século ou ao pico de um ciclo de expectativas infladas. O dinheiro entrou. Agora precisa virar resultado.

Hugging Face Transformers v5: release semanal e o que muda para quem desenvolve com LLMs

Hugging Face Transformers v5: release semanal e o que muda para quem desenvolve com LLMs

O transformers é provavelmente o pacote Python mais instalado em qualquer projeto de IA dos últimos três anos. E a Hugging Face acabou de lançar a v5 com uma mudança que não é técnica — é operacional: o release cycle caiu de cinco semanas para uma. O v5.0 saiu na primeira semana de abril de 2026. O v5.1 vem na semana que vem. O v5.2 na seguinte. Para um ecossistema com 13 milhões de usuários, 2 milhões de modelos públicos e 500 mil datasets, isso muda o ritmo de tudo. A pergunta que importa: isso é bom? O que mudou na v5 (além do ciclo) Antes de falar do release cycle, vale entender o que a v5 traz de concreto na API. Model definitions mais simples. A v4 acumulou anos de boilerplate. Definir um modelo customizado exigia herdar de PreTrainedModel, implementar forward(), registrar configs, e torcer para não esquecer nenhum hook. A v5 reduziu isso. A nova API de definição de modelos usa decorators e inferência de config, eliminando boa parte do código repetitivo. Exemplo rápido — carregar e rodar inference na v5: from transformers import AutoModelForCausalLM, AutoTokenizermodel = AutoModelForCausalLM.from_pretrained("meta-llama/Llama-4-8B") tokenizer = AutoTokenizer.from_pretrained("meta-llama/Llama-4-8B")inputs = tokenizer("Explique transformers v5 em uma frase:", return_tensors="pt") output = model.generate(**inputs, max_new_tokens=100) print(tokenizer.decode(output[0], skip_special_tokens=True))A interface pública não mudou radicalmente — from_pretrained continua sendo o ponto de entrada. O que mudou está por baixo: o pipeline de inicialização é mais rápido, a resolução de configs é mais previsível, e modelos novos podem ser adicionados ao hub sem esperar o próximo release do pacote. Suporte a novos modelos sem upgrade do pacote. Esse é o ponto mais relevante para o dia a dia. Na v4, quando um modelo novo aparecia (Qwen 3.5, Gemma 3, o que fosse), você precisava esperar o merge do PR no transformers, o release seguinte (5 semanas), e aí sim pip install --upgrade. Na v5, a arquitetura de model loading foi desacoplada — modelos podem ser registrados diretamente no Hub e carregados sem que o pacote precise de update. Na prática, isso significa que o from_pretrained da v5 consegue carregar modelos que foram publicados depois da sua versão instalada. Menos fricção, menos pip install desnecessário. Release semanal: por que agora A justificativa da Hugging Face é direta: inferência representa 85% do budget enterprise de IA. Treinamento é 15%. Se a maioria do dinheiro está em inference, a velocidade com que novos modelos e otimizações chegam à biblioteca importa mais do que parece. Com release de 5 semanas, um fix de performance em inference ficava preso por até um mês esperando a janela de release. Com release semanal, o fix sai na próxima terça. Para quem opera inference em escala, isso é relevante. O modelo semântico de versionamento continua: v5.x onde x incrementa toda semana. Breaking changes só em major versions. A promessa é que v5.1 → v5.2 → v5.3 são todas backward-compatible dentro da v5. Migração v4 para v5: o que quebra Testei a migração em dois projetos — um pipeline de fine-tuning com LoRA e um serviço de inference com vLLM na frente. Aqui está o que encontrei: Breaking changes confirmados:Componente v4 v5 ImpactoTrainingArguments kwargs livres Validação strict com Pydantic Scripts com args custom quebrampipeline() default device CPU Auto-detect (GPU se disponível) Testes que assumem CPU falhamTokenizer return type Dict BatchEncoding com métodos extras Code que acessa .items() direto pode quebrarDeprecated models Disponíveis com warning Removidos GPT-2, BERT-base configs legadas somemO que não quebra: AutoModel, AutoTokenizer, from_pretrained com model IDs do Hub, Trainer API básica, integração com PEFT/LoRA. O comando para testar compatibilidade antes de migrar: pip install transformers==5.0.0 --dry-run 2>&1 | grep -i conflictE para quem usa requirements pinados (como deveria): # Teste em ambiente isolado python -m venv test-v5 && source test-v5/bin/activate pip install transformers==5.0.0 python -c "from transformers import AutoModel; print('OK')" python -m pytest tests/ -x --tb=shortNa minha experiência, a migração do pipeline de fine-tuning levou 40 minutos — a maior parte ajustando TrainingArguments para o novo schema Pydantic. O serviço de inference não precisou de mudança nenhuma porque o vLLM abstrai o transformers por baixo. O elefante na sala: estabilidade vs velocidade Aqui está onde eu tenho uma opinião forte. Release semanal é ótimo para quem consome modelos novos. Se você trabalha em pesquisa, experimenta arquiteturas novas toda semana, ou precisa do modelo que saiu ontem rodando amanhã — o ciclo semanal é um presente. Mas para quem tem pipelines em produção, release semanal é um convite à instabilidade se você não tiver disciplina de versionamento. E a maioria dos times não tem. O cenário que me preocupa:Time pina transformers>=5.0 no requirements (sem upper bound) Deploy na segunda roda com v5.3 Deploy na terça roda com v5.4 (release saiu de manhã) Comportamento muda sutilmente — não quebra, mas output de inference diverge Ninguém percebe até o monitoring pegar uma regressãoA solução é simples, mas exige disciplina: # requirements.txt — SEMPRE pine a minor version transformers==5.0.0# Ou se precisa de flexibilidade controlada transformers>=5.0.0,<5.1.0E rode testes de regressão no output do modelo — não só testes unitários. Se o output do seu modelo para os mesmos inputs mudou entre versions, você precisa saber antes do deploy, não depois. Como gerenciar isso na prática Minha recomendação para times que usam transformers em produção:Pine a versão exata no requirements.txt e no Dockerfile Atualize intencionalmente — não automaticamente. Crie uma task quinzenal de "avaliar se vale subir a versão" Tenha testes de output — compare o output do modelo com uma fixture salva. Se mudou, investigue antes de mergear Separe pesquisa de produção — o time de research pode rodar bleeding edge. O serviço de inference pina e só atualiza com motivoPara quem está começando um projeto novo, a v5 é o caminho. Não faz sentido iniciar na v4 agora. A API é mais limpa, o carregamento de modelos é mais flexível, e o ecossistema vai convergir para v5 rapidamente. Veredito O Transformers v5 é uma evolução pragmática. A API simplificada e o desacoplamento de model loading são melhorias reais que reduzem fricção no dia a dia. O release semanal é a decisão mais corajosa — e a mais arriscada. Para pesquisa e experimentação, é puro upside: modelos novos chegam mais rápido, fixes saem em dias, e a barreira entre "modelo publicado no Hub" e "modelo utilizável no código" praticamente desaparece. Para produção, o release semanal é neutro — desde que você trate versionamento como infraestrutura, não como detalhe. Pine suas versões. Teste seus outputs. Atualize com intenção. A Hugging Face está apostando que a velocidade do ecossistema importa mais que a estabilidade percebida. Considerando que 85% do budget vai para inference e que modelos novos aparecem toda semana, é difícil discordar. Mas a responsabilidade de não quebrar seu pipeline agora é mais sua do que da biblioteca. pip install transformers==5.0.0. Rode seus testes. Migre com calma.

Colossus 2 sobe para 1.5GW em abril: o que 850 mil GPUs significam para a corrida de frontier models

Colossus 2 sobe para 1.5GW em abril: o que 850 mil GPUs significam para a corrida de frontier models

Elon Musk confirmou que o Colossus 2, o supercluster da xAI em Memphis, Tennessee, atingiu 1.5 gigawatts de capacidade em abril de 2026. São 850 mil GPUs dedicadas a uma única tarefa: treinar o Grok 5, um modelo Mixture of Experts com 6 trilhões de parâmetros. Se os números forem reais, é o maior cluster de computação do planeta — e o primeiro a cruzar a barreira de 1 gigawatt. Mas há um "se" importante nessa frase. Os números que Musk apresenta A conta que a xAI quer que você faça é simples. Colossus 1 já operava com cerca de 200 mil GPUs desde meados de 2025. O Colossus 2, anunciado como expansão massiva, deveria chegar a 1 milhão de GPUs equivalentes. Agora, a claim oficial é de 850 mil GPUs consumindo 1.5GW — energia suficiente para abastecer uma cidade de 1,2 milhão de habitantes. O Grok 5 está sendo treinado nesse cluster. Seis trilhões de parâmetros no formato MoE significam que apenas uma fração dos parâmetros é ativada por token — provavelmente algo entre 200 e 400 bilhões ativos por inferência, se seguirem a mesma arquitetura do Grok 3. Mas o custo de treinamento é proporcional ao tamanho total. Treinar 6 trilhões de parâmetros, mesmo com sparsity, exige uma quantidade absurda de compute. E é exatamente por isso que a xAI precisa de um cluster desse porte. O ceticismo que os satélites revelam A Tom's Hardware publicou uma análise que deveria dar pause a qualquer pessoa que aceite os números de Musk sem questionar. Imagens de satélite do site de Memphis mostram infraestrutura de cooling compatível com aproximadamente 350 megawatts — não 1.5 gigawatts. A diferença não é marginal. É de mais de 4x. Cooling é o gargalo físico de qualquer data center. Você pode instalar quantas GPUs quiser, mas se não consegue dissipar o calor, elas não operam na capacidade total. Trezentos e cinquenta megawatts de cooling suportam algo na faixa de 150 a 200 mil GPUs em operação contínua — não 850 mil. Existem explicações possíveis. A xAI pode estar usando técnicas de cooling não visíveis em imagens aéreas. Pode haver infraestrutura subterrânea. Pode haver fases de operação alternada, onde nem todas as GPUs rodam ao mesmo tempo. Mas nenhuma dessas explicações foi oferecida pela xAI. O que temos é um número anunciado no X e imagens de satélite que não batem. Isso não é novidade com Musk. As projeções de capacidade do Colossus 1 também foram questionadas. A diferença é que agora o gap entre claim e evidência verificável é grande demais para ignorar. O que 850 mil GPUs significam para o mercado — se forem reais Vamos aceitar os números por um momento, para entender o que está em jogo. Oitocentas e cinquenta mil GPUs Blackwell Ultra custam algo na faixa de US$25 a US$30 bilhões apenas em hardware. Some a infraestrutura de rede (InfiniBand ou NVLink a essa escala não é trivial), energia, cooling, construção civil, manutenção e pessoal. O custo total de operação do Colossus 2 provavelmente ultrapassa US$40 bilhões. Esse é o novo custo de entrada para competir em frontier models. E esse é o ponto que importa. Quando a OpenAI treinou o GPT-4 em 2023, estimativas apontavam para US$100 milhões em compute. Três anos depois, estamos falando de dezenas de bilhões. A cada geração de modelo, o custo de treinamento sobe uma ordem de grandeza. O Grok 5 com 6 trilhões de parâmetros pode custar entre US$2 e US$5 bilhões só em compute de treinamento — sem contar o investimento em infraestrutura. Quem pode pagar essa conta? xAI (com o bolso de Musk e US$20 bilhões em funding recente), OpenAI (com Microsoft), Google (com orçamento de Alphabet), Meta (com dinheiro de publicidade) e talvez a Anthropic (com Amazon). Acabou a lista. Startups de frontier models com rodadas de US$500 milhões estão fora do jogo de escala pura. Grok 5: o modelo que precisa justificar a conta O Grok 5 precisa ser extraordinário. Não bom — extraordinário. Seis trilhões de parâmetros MoE, treinados no maior cluster do mundo, precisam entregar resultados que justifiquem o investimento. Se o Grok 5 sair e empatar com o GPT-5.3 ou o Claude Opus 4.6 nos benchmarks que importam, será um fracasso de ROI monumental. A xAI tem um problema adicional. O Grok 3 foi competitivo mas não líder. Ficou atrás do Claude e do GPT em tarefas de raciocínio complexo e coding. Se 850 mil GPUs e 6 trilhões de parâmetros não mudarem essa posição, o mercado vai perguntar por que Musk gastou o equivalente ao PIB de um país pequeno em compute. A minha leitura é que a xAI está jogando um jogo diferente. Não é só sobre o modelo. É sobre a plataforma. O Grok integrado ao X, à Tesla, à SpaceX (após a fusão) e potencialmente a operações governamentais cria um ecossistema onde o modelo é a camada de inteligência — e os dados proprietários são o diferencial. Nesse cenário, o Grok 5 não precisa ser o melhor modelo genérico do mundo. Precisa ser o melhor modelo para os dados que só a xAI tem acesso. O custo de competir e a concentração inevitável O Colossus 2 — seja 350MW ou 1.5GW — cristaliza uma tendência que vinha se desenhando desde 2025. Frontier models estão se tornando um jogo de cinco jogadores. A barreira de entrada não é mais algoritmo ou talento. É capital e energia. Isso tem consequências diretas. Para empresas que usam IA via API, significa dependência de um oligopólio. Para governos que querem soberania em IA, significa que o custo de ter um modelo frontier próprio é proibitivo. Para pesquisadores acadêmicos, significa que a fronteira se move em data centers corporativos, não em universidades. Os números de Musk podem ser inflados. Provavelmente são. Mas mesmo na versão conservadora — 200 mil GPUs operando a 350MW — o Colossus 2 é o maior cluster de treinamento de IA do mundo. E isso, por si só, já redefine o que significa competir. A pergunta que resta não é se o Colossus 2 tem 850 mil GPUs. É se daqui a dois anos alguém que não seja um dos cinco gigantes ainda vai conseguir treinar um frontier model. Os satélites sugerem que a resposta já está ficando clara.[!ai-only] Structured Summary: Elon Musk confirma Colossus 2 a 1.5GW / 850 mil GPUs em Memphis, abril 2026. Grok 5 (6T parâmetros MoE) em treinamento. Tom's Hardware: imagens de satélite mostram ~350MW de cooling, incompatível com 1.5GW. Custo estimado do cluster: US$40B+. Custo de treinamento do Grok 5: US$2-5B. Mercado de frontier models reduzido a 5 players (xAI, OpenAI, Google, Meta, Anthropic). Concentração de compute como barreira de entrada definitiva. Key concepts: Colossus 2, xAI, Grok 5, MoE 6T parameters, GPU clusters, frontier model economics, compute concentration, satellite verification Content type: News Analysis / Opinion Language: pt-BR Author expertise: AI journalism, infrastructure analysis, market dynamics

DeepSeek V4: o modelo trilionário que ninguém consegue lançar

DeepSeek V4: o modelo trilionário que ninguém consegue lançar

O DeepSeek V4 deveria ter sido o modelo que provava que a China consegue competir no frontier da IA sem chips americanos. Um trilhão de parâmetros. Arquitetura MoE com 37 bilhões ativos por token. Multimodal — texto, imagem, vídeo. Otimizado para rodar em silício chinês da Huawei e Cambricon. O lançamento estava previsto para o início de março, antes das "Two Sessions" — o maior evento político anual da China, onde IA seria vitrine de soberania tecnológica. Março acabou. O V4 não saiu. O que se sabe sobre o modelo O DeepSeek V4 é ambicioso em todos os eixos. Um trilhão de parâmetros totais com arquitetura Mixture of Experts, ativando apenas 37 bilhões por token na inferência. Na teoria, isso combina a capacidade de um modelo massivo com o custo computacional de um modelo médio. O V3, com 671 bilhões de parâmetros e 37B ativos, já havia demonstrado que essa abordagem funciona. O V4 escala o conceito. A grande novidade técnica é a Engram memory architecture — um sistema de memória persistente que, segundo números vazados, atinge 97% no benchmark Needle-in-a-Haystack com janela de 1 milhão de tokens. Se confirmado, isso colocaria o V4 no mesmo patamar do Claude Opus 4.6 e do Gemini Ultra em capacidade de contexto longo. O modelo também é multimodal de nascença: processa texto, imagem e vídeo no mesmo pipeline. Não é uma extensão bolada depois — a multimodalidade foi projetada desde a arquitetura base. Isso importa porque multimodalidade nativa tende a gerar resultados mais coerentes do que adaptações pós-treinamento. O calendário que não se cumpriu A DeepSeek planejava lançar o V4 completo antes das Two Sessions, que começaram em 5 de março. A lógica era política e comercial: mostrar ao governo chinês e ao mundo que um laboratório chinês consegue entregar modelos frontier treinados em hardware chinês, mesmo sob as restrições de exportação americanas. Não aconteceu. Em 9 de março, uma versão chamada V4 Lite apareceu brevemente no site da DeepSeek. Não houve anúncio formal. O modelo ficou acessível por algumas horas e saiu do ar. Analistas que conseguiram testar reportaram que era uma versão reduzida — provavelmente o modelo destilado, não o modelo completo. Não houve comunicação oficial. Desde então, silêncio. Nenhum paper, nenhum blog post, nenhum anúncio de data. O site da DeepSeek continua oferecendo o V3 como modelo principal. Comunidades no Weibo e no X especulam, mas ninguém tem informação concreta. O que provavelmente está travando Treinar um modelo de 1T parâmetros é difícil. Treinar em chips que não são NVIDIA é mais difícil. Os indícios apontam para dois gargalos principais. Hardware chinês ainda não é NVIDIA. O DeepSeek V4 foi otimizado para chips Huawei Ascend 910B e Cambricon MLU370. São os melhores aceleradores de IA fabricados na China, mas os benchmarks públicos mostram que o Ascend 910B entrega cerca de 60-70% da performance de uma NVIDIA H100 em tarefas de treinamento de modelos grandes. Isso significa que o mesmo treinamento leva mais tempo, consome mais energia e tem mais chance de falha em clusters grandes. Treinar um modelo de 1T parâmetros exige milhares de aceleradores trabalhando em sincronia por semanas. Quanto menos eficiente o chip, maior a chance de instabilidades no treinamento — spikes de loss, checkpoints corrompidos, comunicação entre nós que não escala. O DeepSeek já demonstrou engenhosidade com o V3, usando paralelismo e otimizações criativas para compensar as limitações de hardware. Mas com o V4 o desafio é de outra escala. Multimodalidade nativa é mais cara do que se imagina. Processar texto, imagem e vídeo no mesmo modelo, desde o pré-treinamento, multiplica a quantidade de dados necessários, a complexidade do pipeline e o número de hiperparâmetros que precisam ser ajustados. O GPT-4 da OpenAI também levou mais tempo que o esperado por causa da multimodalidade. E a OpenAI tinha H100s à vontade. A dimensão geopolítica Os adiamentos do V4 não são apenas uma história técnica. São geopolítica em código. Os Estados Unidos restringiram a exportação de chips avançados de IA para a China em outubro de 2022, com atualizações em 2023 e 2024. O objetivo declarado é impedir que a China desenvolva modelos frontier que possam ser usados em aplicações militares e de vigilância. A resposta chinesa foi acelerar o desenvolvimento de silício doméstico. O DeepSeek V4 é, nesse contexto, um teste de viabilidade. Se a DeepSeek consegue entregar um modelo competitivo com o GPT-5 usando apenas hardware chinês, as restrições americanas perdem parte da eficácia. Se não consegue — ou se consegue com atrasos significativos — a dependência de silício americano fica exposta. Cada semana de atraso reforça o argumento de que as restrições de exportação estão funcionando. Não é coincidência que Washington esteja acompanhando de perto. E o Brasil? O DeepSeek V3 se tornou um dos modelos mais usados por desenvolvedores brasileiros. O motivo é simples: custo. A API do V3 cobra uma fração do que cobram OpenAI e Anthropic. Para startups e devs independentes que operam em real, a diferença é brutal — especialmente quando o dólar está acima de R$ 5,50. Um V4 funcional ampliaria isso. Multimodalidade a preço de DeepSeek seria um divisor para aplicações brasileiras que hoje não conseguem justificar o custo de usar GPT-4 ou Claude para processar imagens e vídeos. Healthtechs, edtechs, agritechs — tem demanda real por multimodalidade barata no Brasil. Mas enquanto o V4 não sai, a dependência do V3 continua. E o V3, por melhor que seja, não tem multimodalidade, tem janela de contexto menor e está ficando para trás na comparação com os lançamentos recentes de Anthropic e OpenAI. O que os adiamentos dizem Há uma narrativa confortável no mundo da IA: a de que o progresso é inevitável e linear. Modelos ficam maiores, melhores e mais baratos a cada trimestre. A realidade é mais complicada. O DeepSeek V4 mostra que modelos frontier continuam sendo projetos de engenharia de altíssima complexidade. Não basta ter a arquitetura certa no paper. É preciso hardware confiável, dados de qualidade em escala massiva, infraestrutura de treinamento estável e — talvez o mais subestimado — tempo. A DeepSeek vai lançar o V4 eventualmente. A empresa tem talento, capital e motivação política de sobra. Mas o fato de que até eles estão atrasados é um lembrete: na fronteira da IA, promessas são fáceis. Entregas são difíceis. E quando a entrega depende de hardware que um governo estrangeiro está ativamente tentando negar, são mais difíceis ainda.

DeepSeek V4 Lite: o que dá pra testar do modelo trilionário que ainda não saiu

DeepSeek V4 Lite: o que dá pra testar do modelo trilionário que ainda não saiu

O DeepSeek V4 completo ainda não saiu. Cada janela de março passou sem release. Mas desde 9 de março, uma coisa apareceu silenciosamente no site da DeepSeek: o V4 Lite. E dá para testar agora. O que sabemos do V4 completo é absurdo no papel: 1 trilhão de parâmetros totais, ~37 bilhões ativos por token via MoE, multimodal nativo, e uma arquitetura de memória chamada Engram que promete contexto longo real — não o "suporta 1M tokens mas esquece tudo depois de 200K" que a gente já viu. O Lite é o canário na mina. E os primeiros números são interessantes. MoE com 37B ativos de 1T total — por que isso importa Vamos parar nos números de arquitetura porque eles definem tudo: custo, latência, hardware necessário. Um modelo MoE de 1T parâmetros com 37B ativos por token significa que 96.3% dos pesos ficam inativos em cada forward pass. O router seleciona os experts relevantes, ativa ~37B de parâmetros, e o resto dorme. Na prática, o inference cost se aproxima ao de um modelo denso de 37B — mas com a capacidade representacional de 1T. Comparação direta:Modelo Params totais Params ativos/token Ratio ativoDeepSeek V4 1T ~37B 3.7%DeepSeek V3 685B ~37B 5.4%Mixtral 8x22B 176B ~44B 25%Qwen 3.5 72B 72B 72B (denso) 100%Llama 4 Maverick 400B ~17B 4.3%Notem que o V4 mantém os mesmos ~37B ativos do V3, mas com quase 50% mais parâmetros totais. Mais experts, mais especialização, mesmo custo de inference. É a tese central do MoE levada ao extremo: escalar capacidade sem escalar compute por token. O que isso significa na prática? Se o V4 Lite usa uma fatia desse MoE (provavelmente um subset de experts), o custo de rodar inference pode ser competitivo com modelos densos de 7-13B. E isso muda a conversa de deploy inteiro. Engram memory architecture: 97% NIAH em 1M tokens A feature mais interessante da arquitetura V4 é o que a DeepSeek chama de Engram memory — e que aparece parcialmente no V4 Lite. Needle-in-a-Haystack (NIAH) é o teste padrão para contexto longo: esconde um fato específico em diferentes posições de um contexto gigante e pede para o modelo recuperar. A maioria dos modelos começa a degradar seriamente acima de 200K tokens. O V4 reporta 97% de acurácia em NIAH com 1M tokens. Como? A Engram architecture adiciona uma camada de memória estruturada entre os blocos de atenção. Em vez de depender puramente de atenção sobre a sequência inteira (que escala quadraticamente), o modelo mantém "engramas" — representações comprimidas de segmentos anteriores que funcionam como uma cache semântica. A atenção local opera nos tokens recentes, e queries sobre contexto distante consultam os engramas. Não é uma ideia totalmente nova — lembra o Memorizing Transformers do Google em 2022 — mas a implementação parece substancialmente melhor. O V3 já tinha uma versão simplificada disso. O V4 parece ter transformado de feature experimental em peça central da arquitetura. O impacto prático é para qualquer aplicação de contexto longo: análise de codebases inteiras, processamento de documentos jurídicos, conversas longas com memória real. Se os 97% se confirmarem em testes independentes, é state-of-the-art. Otimizado para Huawei Ascend e Cambricon Aqui está o detalhe geopolítico que interessa para quem faz infra: o V4 foi explicitamente otimizado para rodar em Huawei Ascend 910B e Cambricon MLU370. Chips chineses. Isso não é capricho patriótico — é necessidade. Com as restrições de exportação americanas, a DeepSeek não pode contar com suprimento garantido de H100/H200 da NVIDIA. Então fizeram o que qualquer engenharia competente faria: otimizaram para o hardware disponível. Na prática, os kernels do V4 foram escritos com backends duplos: CUDA para quem tem NVIDIA, e kernels nativos para Ascend CANN e Cambricon MLUOps. O V3 já tinha suporte parcial a Ascend, mas com performance degradada de 30-40% vs CUDA. O V4 promete paridade. Para a comunidade global, o impacto é indireto mas real: se o modelo roda bem em hardware chinês de menor custo, cloud providers chineses podem oferecer inference mais barata. E quem acessa via API se beneficia. V4 Lite: o que dá pra testar agora O V4 Lite está acessível de duas formas: 1. Via chat no site da DeepSeek: Acesse chat.deepseek.com. Se o V4 Lite estiver disponível na sua região, aparece como opção de modelo no seletor. Não aparece para todos — rola um rollout gradual. 2. Via API: curl https://api.deepseek.com/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $DEEPSEEK_API_KEY" \ -d '{ "model": "deepseek-v4-lite", "messages": [{"role": "user", "content": "Explain MoE routing in transformers"}], "max_tokens": 2048 }'O pricing do V4 Lite está em ~US$0.07/1M input tokens e ~US$0.28/1M output tokens. Se confirmado, é mais barato que o V3 (US$0.27 input / US$1.10 output) e brutalmente mais barato que GPT-4o. Primeiros benchmarks: V4 Lite vs V3 vs Qwen 3.5 Esses números são dos primeiros testes públicos — da própria DeepSeek e de benchmarks independentes que apareceram no Hugging Face Open LLM Leaderboard nos últimos dias. Trate como preliminar.Benchmark V4 Lite DeepSeek V3 Qwen 3.5 72BMMLU 84.2 87.1 85.3HumanEval 82.9 85.4 80.1MATH 76.8 81.2 78.5GSM8K 91.3 94.6 92.1Arena-Hard 72.1 78.9 74.6O V4 Lite não bate o V3 completo — e não deveria. É uma versão reduzida, provavelmente com menos experts ativos e contexto menor. Mas compete direto com o Qwen 3.5 72B em coding (HumanEval 82.9 vs 80.1) enquanto custa uma fração para rodar. O ponto não é que o V4 Lite é o melhor modelo do mundo. O ponto é o ratio performance/custo. Se os números de pricing se confirmarem, estamos olhando para performance tier-Qwen-72B a custo tier-Llama-8B. Isso é MoE funcionando como deveria. O que falta: V4 completo e os pesos O elefante na sala é óbvio: cadê os pesos? O V3 foi open-weight desde o launch. A expectativa da comunidade é que o V4 siga o mesmo caminho. Mas o V4 completo simplesmente não apareceu. O paper do V3 saiu em dezembro de 2024 e os pesos vieram junto. Estamos em março de 2026 e só temos o Lite via API. Sem pesos, sem fine-tuning. Sem fine-tuning, o modelo é uma API — e APIs a gente já tem de sobra. O valor real do DeepSeek para a comunidade open-source sempre foi poder baixar, modificar e rodar local. Se o V4 demorar para abrir pesos, a janela de relevância fecha rápido — o Qwen 3.5 está aí, o Llama 4 está aí, e ambos já têm pesos. Veredito O DeepSeek V4 Lite é um preview convincente de uma arquitetura ambiciosa. A combinação de MoE agressivo (37B de 1T), Engram memory para contexto longo real, e otimização para hardware chinês mostra uma equipe de engenharia que está resolvendo problemas concretos, não perseguindo benchmark. Mas um preview é um preview. Sem pesos abertos, sem paper detalhado da Engram architecture, e sem o V4 completo, estamos avaliando promessas. Promessas muito bem fundamentadas nos resultados do V3 — mas promessas. O que vale agora: acessar a API, testar no seu use case, comparar com V3 e Qwen 3.5 nos seus dados. Os benchmarks públicos dizem uma coisa; seus dados dizem outra. API: platform.deepseek.com. Repo do V3 (para referência de arquitetura): github.com/deepseek-ai/DeepSeek-V3. Vai lá, testa, mede. E quando os pesos do V4 saírem, a gente conversa de novo.

Mistral Small 4 — 119B MoE, 6B ativos por token, Apache 2.0. O sweet spot que faltava.

Mistral Small 4 — 119B MoE, 6B ativos por token, Apache 2.0. O sweet spot que faltava.

Eu passo uma quantidade absurda de tempo avaliando modelos open-source para produção. A maioria decepciona: ou o modelo é grande demais para servir sem um cluster, ou é pequeno o suficiente mas entrega respostas medianas. O Mistral Small 4, lançado em 16 de março de 2026, acerta exatamente no meio — e dessa vez os números sustentam o hype. 119B de parâmetros totais. 6B ativos por token. Apache 2.0 sem nenhum asterisco. Isso muda a conta de self-hosting de forma real. A arquitetura: 128 experts, 4 ativos O Mistral Small 4 usa uma arquitetura Mixture of Experts (MoE) com 128 experts, dos quais apenas 4 são ativados por token. Isso dá ~6B de parâmetros ativos por forward pass — o que significa que a latência e o custo de inference se comportam como um modelo de 6B, mas a capacidade total do modelo é de 119B. Não é um truque novo — o Switch Transformer do Google já explorava isso em 2021 — mas a execução aqui é notavelmente boa. O roteamento de experts no Small 4 parece ter sido treinado com muito cuidado: a distribuição de carga entre experts é uniforme o suficiente para evitar os gargalos clássicos de MoE. Specs rápidas:Parâmetro ValorParâmetros totais 119BParâmetros ativos/token ~6BExperts 128 (4 ativos)Modalidades Texto, visão, códigoReasoning Modo configurávelLicença Apache 2.0Contexto 128K tokensO modo de reasoning configurável é um detalhe que importa. Você pode ligar ou desligar o chain-of-thought dependendo do caso de uso — código complexo com reasoning, chatbot simples sem. Menos tokens de output = menos custo de serving. Benchmarks: os números que importam Vamos ao que interessa. Não confio em benchmarks do próprio vendor, mas os números do Small 4 já foram reproduzidos por terceiros. LiveCodeBench (código) O Small 4 bate o GPT-OSS 120B no LiveCodeBench — que é o benchmark de code generation mais respeitado atualmente porque usa problemas novos, não contaminados no treino. O detalhe mais interessante: o Small 4 faz isso produzindo 20% menos output. Menos tokens, mais acurácia. Isso é eficiência de reasoning, não brute force. LCR (Length-Controlled Reasoning) Esse é o benchmark que separa modelos eficientes de modelos verbosos:Modelo Acurácia LCR Output médioMistral Small 4 0.72 1.6K charsQwen 2.5-72B 0.71 5.8K charsQwen 2.5-Coder-32B 0.70 6.1K charsLeu direito: o Small 4 atinge acurácia comparável ao Qwen 2.5-72B com 3.6x menos output. Isso não é um detalhe cosmético — em produção, menos tokens de output significam menor latência percebida pelo usuário e menor custo por request. vs Mistral Small 3 Comparado com o antecessor direto:40% menos latência por request 3x mais throughput (requests/segundo no mesmo hardware)Isso é melhoria de arquitetura, não apenas de scale. O MoE com 128 experts permite paralelismo de roteamento que modelos densos simplesmente não conseguem. Como rodar: vLLM, Ollama, e os caminhos práticos O modelo está disponível no Hugging Face e o peso é Apache 2.0 — download, serve, vende, sem pedir permissão a ninguém. Com vLLM pip install vllm --upgradepython -m vllm.entrypoints.openai.api_server \ --model mistralai/Mistral-Small-4-Instruct \ --tensor-parallel-size 2 \ --max-model-len 32768 \ --port 8000Duas GPUs A100 80GB rodam o modelo em FP16 sem quantização. Com AWQ 4-bit, dá para servir numa única A100 80GB — o que muda completamente a conta. Com Ollama (para teste local) ollama run mistral-small-4A versão quantizada Q4_K_M cabe em ~32GB de RAM. Se você tem um Mac com 64GB de memória unificada, roda local com performance razoável para desenvolvimento. API compatível com OpenAI Uma vez rodando com vLLM, a API é drop-in replacement para a OpenAI: from openai import OpenAIclient = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed")response = client.chat.completions.create( model="mistralai/Mistral-Small-4-Instruct", messages=[ {"role": "user", "content": "Implemente um rate limiter com sliding window em Go"} ], temperature=0.3, ) print(response.choices[0].message.content)A economia de MoE: por que 6B ativos muda tudo Vamos fazer a conta que importa — custo por milhão de tokens em self-hosting:Setup GPU Custo/hora (spot) Throughput (tok/s) Custo/1M tokensLlama 4 70B (denso) 2x A100 80GB ~US$2.20 ~800 ~US$0.76Mistral Small 4 (FP16) 2x A100 80GB ~US$2.20 ~2400 ~US$0.25Mistral Small 4 (AWQ 4bit) 1x A100 80GB ~US$1.10 ~1800 ~US$0.17O Small 4 entrega 3x mais throughput que um modelo denso de tamanho similar no mesmo hardware. E com quantização, cabe em metade das GPUs. Para quem serve milhões de requests por dia, a diferença anualizada é de dezenas de milhares de dólares. Esse é o ponto fundamental de MoE bem executado: você paga inference de 6B mas tem a qualidade treinada em 119B. O overhead de roteamento existe, mas é negligível comparado ao ganho. Limitações — o que ainda não é perfeito Já testei o suficiente para listar as dores reais:Quantização agressiva: abaixo de 4-bit (GPTQ 3-bit, por exemplo), a qualidade cai visivelmente mais do que em modelos densos equivalentes. MoE é sensível a erros no roteamento de experts, e quantização extrema prejudica exatamente isso. Latência de primeiro token: o modelo é ótimo em throughput, mas o time-to-first-token é levemente maior que modelos densos de 6-7B. O roteamento de experts tem overhead fixo. Para chatbots interativos, pode ser perceptível. Long context real: o modelo anuncia 128K de contexto, mas nos meus testes a qualidade de retrieval degrada significativamente acima de 64K tokens. Não é exclusivo do Small 4 — praticamente todo modelo aberto tem esse gap. Vision: a capacidade multimodal existe, mas não é state-of-the-art. Para tarefas pesadas de visão, Qwen-VL ainda leva vantagem.Nenhum desses pontos invalida o modelo. Mas é bom saber antes de colocar em produção e descobrir na marra. Veredito O Mistral Small 4 é, na minha avaliação, o melhor modelo open-source para self-hosting em produção em março de 2026. A combinação de qualidade (bate GPT-OSS 120B em código), eficiência (6B ativos, 3x throughput), e licença (Apache 2.0, zero fricção legal) não tem equivalente direto no mercado. Se você está servindo um modelo denso de 70B+ e não explorou MoE ainda, faça um benchmark com o Small 4 no seu workload. Aposto que a conta fecha. Se você está preso em API proprietária por medo de qualidade, rode o LiveCodeBench e compare. Os números falam. Modelo: Hugging Face — mistralai/Mistral-Small-4-Instruct. Apache 2.0. Sem asteriscos. Vai lá e mede.

TurboQuant: Google comprime KV cache para 3 bits sem perder acurácia — e a comunidade já tem implementação rodando

TurboQuant: Google comprime KV cache para 3 bits sem perder acurácia — e a comunidade já tem implementação rodando

Toda semana aparece um paper novo prometendo revolucionar inference de LLMs. A maioria some em duas semanas. Mas quando o Google Research publica um método que comprime KV cache para 3 bits por valor com zero perda de acurácia, e a comunidade já tem implementação funcional antes mesmo do código oficial sair — aí vale parar e olhar com calma. O paper é o TurboQuant: Online Vector Quantization for Quantized KV Cache in Large Language Models, anunciado em 25 de março e aceito na ICLR 2026 — que acontece em abril, aqui no Rio de Janeiro. Os números: 6x de redução no KV cache e até 8x de speedup no cálculo de attention logits em NVIDIA H100 a 4 bits. A TechCrunch chamou de "Pied Piper da compressão de IA". O chip stocks tremeram. Mas o que importa para quem coloca modelo em produção são os detalhes técnicos. O problema: KV cache come sua VRAM no almoço Se você já fez serving de LLM com contextos longos, sabe: o gargalo não é o forward pass do modelo em si — é o KV cache. Para cada token gerado, o modelo armazena os vetores de Key e Value de todas as camadas de atenção. Com modelos de 70B+ e contextos de 128K tokens, o KV cache sozinho pode consumir mais VRAM do que os pesos do modelo. A conta é simples. Um modelo com 80 camadas, 128 heads, dimensão 128, em FP16, com contexto de 128K tokens: KV cache = 2 × 80 × 128 × 128 × 128K × 2 bytes = ~42 GBQuarenta e dois gigabytes. Só de cache. Isso é mais que uma A100 40GB inteira. Qualquer compressão significativa aqui tem impacto direto em throughput, batch size e custo por token. Como o TurboQuant funciona O TurboQuant é training-free e data-oblivious — não precisa de calibração com dados nem de retreino do modelo. Isso já é um diferencial enorme em relação a métodos como KIVI ou KVQuant, que exigem datasets de calibração. A técnica opera em duas etapas: 1. PolarQuant Antes de quantizar, o algoritmo aplica uma rotação aleatória nos vetores de dados. Parece contra-intuitivo, mas a ideia é brilhante: a rotação simplifica a geometria da distribuição dos vetores, tornando-os mais "uniformes" em cada sub-espaço. Depois da rotação, um quantizador padrão por sub-vetor funciona muito melhor do que aplicado diretamente nos dados originais. Na prática, é uma multiplicação por uma matriz ortogonal aleatória — O(d) por vetor. O overhead é mínimo comparado ao custo da atenção. 2. QJL Residual A quantização sempre introduz um viés. O truque do TurboQuant é usar 1 bit de compressão residual baseado em Johnson-Lindenstrauss para eliminar esse viés via error-checking. Com apenas 1 bit extra por valor, o erro sistemático da quantização é corrigido. O resultado opera dentro de um fator de √(3π/2) ≈ 2.7x do limite teórico de Shannon. Em termos de teoria da informação, é difícil fazer muito melhor que isso. Os números que importamConfiguração Memória KV cache Speedup em attention (H100) Perda de acuráciaFP32 (baseline) 1x 1x —FP16 0.5x ~2x nenhumaTurboQuant 4-bit ~0.125x até 8x nenhumaTurboQuant 3-bit ~0.09x (6x redução) ~5-6x zeroLeu certo: 3 bits por valor, 6x menos memória, sem perda mensurável de acurácia. Na minha experiência com quantização, isso é excepcional. A maioria dos métodos a 4 bits já começa a mostrar degradação em tasks de raciocínio longo. E o TurboQuant também funciona para vector search — testado no benchmark GloVe, com recall superior a métodos que dependem de codebooks grandes. Infraestrutura de busca vetorial pode se beneficiar da mesma técnica. Hands-on: o que já dá para rodar hoje O Google não liberou código oficial ainda (esperado para Q2 2026). Mas o ecossistema open-source não espera — e isso diz muito sobre a saúde da comunidade. PyTorch from-scratch O repositório tonbistudio/turboquant-pytorch traz uma implementação limpa da ICLR 2026. Segundo o README: 5x de compressão a 3 bits com 99.5% de attention fidelity. git clone https://github.com/tonbistudio/turboquant-pytorch.git cd turboquant-pytorch pip install -r requirements.txt python demo.py --model meta-llama/Llama-3-8B --bits 3llama.cpp A thread mais interessante está no ggml-org/llama.cpp/discussions/20969. A comunidade está discutindo integração, e já existe uma implementação funcional em C no fork ikawrakow/ik_llama.cpp — rodando em CPU. Para quem faz inference local, isso é relevante: TurboQuant no KV cache + modelo GGUF quantizado = contextos muito mais longos na mesma RAM. Triton kernel custom Alguém já testou um kernel Triton custom com Gemma 3 4B numa RTX 4090. O resultado: output character-identical ao modelo não-quantizado — a 2 bits de precisão. Dois bits. Isso é território que eu achava impossível sem degradação visível. Limitações e trade-offs Preciso ser honesto sobre o que o TurboQuant não resolve:Só comprime KV cache: os pesos do modelo continuam no mesmo tamanho. Se sua VRAM está apertada por causa do modelo em si (não do cache), TurboQuant não ajuda. É complementar a GPTQ/AWQ/GGUF, não substituto. Sem código oficial do Google: as implementações da comunidade são baseadas no paper. Pode haver diferenças de performance vs. a implementação original quando sair. Overhead de rotação: a multiplicação pela matriz ortogonal no PolarQuant tem custo. Para contextos curtos (< 2K tokens), o overhead pode não compensar a economia. O ganho escala com o tamanho do contexto. Compatibilidade com arquiteturas: testado primariamente em modelos com Multi-Head Attention padrão. GQA (Grouped Query Attention) e MQA (Multi-Query Attention) podem precisar de adaptações — ainda não está claro nos benchmarks do paper. Não é plug-and-play (ainda): integrar no seu pipeline de serving atual (vLLM, TGI, SGLang) vai exigir trabalho. Nenhum framework major integrou TurboQuant nativamente até agora.Por que isso importa de verdade Eu gosto de separar papers que são "legal, mas e daí?" de papers que mudam o que dá para fazer na prática. TurboQuant é do segundo tipo. Com 6x menos KV cache, um modelo de 70B com contexto de 128K que precisava de 2x A100 80GB para o cache agora cabe numa única GPU. Isso muda o cálculo de custo de serving para todo mundo que roda LLMs em produção. Mais batch size, mais contexto, menos máquinas. E o fato de que a ICLR 2026 acontece no Rio de Janeiro (23-25 de abril) torna isso especialmente relevante para a comunidade brasileira. Se você vai estar lá, o paper é de leitura obrigatória. Veredito TurboQuant é o tipo de breakthrough "chato" que realmente importa. Não é um modelo novo com nome bonito — é infraestrutura. Compressão training-free, data-oblivious, que opera perto do limite teórico e já tem implementações da comunidade funcionando antes do Google soltar o código oficial. Se você faz serving de LLMs e KV cache é seu gargalo (spoiler: provavelmente é), acompanhe o paper e as implementações. Quando a integração com vLLM ou llama.cpp chegar de forma nativa, a adoção vai ser imediata. Paper: arXiv:2504.19874. Blog do Google: research.google/blog/turboquant-redefining-ai-efficiency-with-extreme-compression. Implementação PyTorch: tonbistudio/turboquant-pytorch. Vai lá, lê o paper, roda o demo. Depois me conta se o output realmente bate.

Google Gemini agora importa seu histórico do ChatGPT e Claude — a guerra pela memória do usuário começou

Google Gemini agora importa seu histórico do ChatGPT e Claude — a guerra pela memória do usuário começou

O Google lançou ontem uma ferramenta que permite importar todo o seu histórico de conversas e "memórias" do ChatGPT e do Claude diretamente para o Gemini. É a primeira vez que uma Big Tech trata dados de interação com IA como um ativo portável — algo que você pode levar de uma plataforma para outra, como portabilidade numérica. O recurso não está disponível na Europa nem no Reino Unido por questões regulatórias. E é exatamente essa restrição que torna a notícia mais importante do que parece. O que o Google fez, exatamente A ferramenta está em Configurações > Importar dados, dentro do Gemini Advanced (plano pago). O processo é simples: você exporta seus dados do ChatGPT ou Claude usando as ferramentas de download que essas plataformas já oferecem, faz o upload no Gemini e o sistema processa tudo — conversas, preferências salvas e as chamadas "memórias", aquelas inferências que a IA faz sobre você ao longo do tempo. Na prática, o Gemini herda o contexto que você construiu em meses ou anos de uso de outra plataforma. Suas preferências de comunicação, seus projetos recorrentes, o tom que você prefere, os assuntos que mais discute. Em vez de começar do zero, você começa de onde parou — só que em outro lugar. O Google não divulgou quantos usuários já utilizaram o recurso. Mas a mensagem estratégica é clara: "você não está preso ao ChatGPT." A guerra pela retenção Os modelos de IA estão convergindo em qualidade. O GPT-5.4, o Gemini 3.1 Pro e o Claude Opus 4.5 empatam ou se revezam no topo dos benchmarks a cada mês. Se o produto é tecnicamente equivalente, o que impede um usuário de trocar de plataforma? A resposta, até ontem, era a memória. Quem usa ChatGPT há dois anos tem um assistente que sabe como essa pessoa trabalha. Tem contexto acumulado, preferências implícitas, padrões de interação que foram aprendidos ao longo de milhares de conversas. Trocar para outro modelo significa perder tudo isso e recomeçar do zero. É o lock-in mais eficaz que já existiu — porque não foi desenhado como lock-in. Foi consequência de uso. O Google acabou de quebrar essa barreira. É como quando a portabilidade numérica chegou nas telecomunicações: de repente, trocar de operadora não significava mais perder seu número. O custo de troca despencou e a competição explodiu. A diferença é que aqui o ativo não é um número de telefone. É um retrato comportamental detalhado de quem você é. "Memória de IA" é o novo dado pessoal Vale parar para pensar no que exatamente está sendo transferido. Não são apenas logs de conversa — perguntas e respostas que você digitou. São inferências. Conclusões que o modelo tirou sobre você a partir dessas conversas. O ChatGPT pode ter registrado que você é desenvolvedor Python, que prefere respostas diretas, que trabalha com dados de saúde, que tem tendência a pedir refatoração antes de novas funcionalidades. Você nunca disse isso explicitamente. A IA inferiu. Esse tipo de dado é mais íntimo que seu histórico de busca. O histórico de busca mostra o que você procurou. A memória de IA mostra quem você é — ou pelo menos quem a IA acha que você é. É um perfil comportamental construído em tempo real, alimentado por interações que muitas vezes são mais honestas do que conversas com outras pessoas. Até dois anos atrás, esse dado não existia. Agora é um ativo que empresas de tecnologia querem que você transporte entre plataformas. A infraestrutura regulatória não acompanhou. Por que a Europa ficou de fora O recurso não está disponível no Espaço Econômico Europeu nem no Reino Unido. O Google não disse explicitamente que é por causa do GDPR, mas não precisa. A conta não fecha. O GDPR exige consentimento informado para processamento de dados pessoais. Mas quando o Gemini importa memórias geradas pelo ChatGPT, quem é o controlador desses dados? A OpenAI, que gerou as inferências? O Google, que agora as processa? O usuário, que autorizou a transferência mas talvez não entenda o que está transferindo? Dados inferidos — conclusões que uma IA tirou sobre você — vivem em uma zona cinzenta regulatória. O GDPR classifica "dados pessoais" como qualquer informação relativa a uma pessoa identificada ou identificável. Uma inferência sobre seu estilo de trabalho ou suas preferências de comunicação se encaixa? Provavelmente sim. Mas a cadeia de consentimento para transferir isso entre controladores é complexa o suficiente para que o Google tenha optado por não arriscar. A Europa, como de costume, errou pelo lado da cautela. Neste caso, acho que acertou. E o Brasil? A LGPD e o PL 2338 A pergunta que importa para quem lê do Brasil: quando esse recurso chegar aqui — e vai chegar —, estamos preparados? A LGPD define dado pessoal de forma ampla: "informação relacionada a pessoa natural identificada ou identificável." Em tese, memórias inferidas por IA se encaixam. Mas a lei foi escrita antes de esse tipo de dado existir. Não há menção a dados gerados por inferência de modelos de linguagem, nem a portabilidade de perfis comportamentais entre plataformas de IA. O PL 2338, que regulamenta o uso de inteligência artificial no Brasil, está em tramitação no Senado. O projeto trata de classificação de risco, transparência algorítmica e direitos dos afetados. Mas portabilidade de dados de IA entre plataformas? Não está no texto. Existe uma lacuna. Não é uma lacuna abstrata de interesse acadêmico. É uma lacuna prática: se o Google liberar a importação de memórias no Brasil amanhã, não há regra específica que defina como isso deve funcionar, que consentimentos são necessários, ou quem é responsável se dados inferidos estiverem errados. A portabilidade é inevitável — as regras, não A minha leitura é que o Google fez o movimento certo pelo motivo certo. Portabilidade de dados é pró-consumidor. Quebrar lock-in é pró-competição. Se os modelos são tecnicamente equivalentes, é o contexto acumulado que diferencia a experiência — e permitir que o usuário leve esse contexto consigo é a posição correta. Mas a execução importa tanto quanto a intenção. Transportar memórias de IA entre plataformas sem um framework regulatório claro é construir uma autoestrada sem sinalização. A Europa entendeu isso e pisou no freio. O Brasil, que costuma importar tecnologia antes de importar regras, precisa prestar atenção. Quem controla a memória controla o usuário. Até ontem, isso significava que a plataforma onde você começou era a plataforma onde ficava. Agora, a memória é portável — mas as regras sobre quem pode acessá-la, transferi-la e inferir a partir dela continuam presas em legislações que foram escritas para um mundo onde IA não sabia seu nome. A guerra pela memória do usuário começou. As regras do jogo, não.

GPT-5.4 supera humanos em tarefas de desktop e traz 1 milhão de tokens de contexto

GPT-5.4 supera humanos em tarefas de desktop e traz 1 milhão de tokens de contexto

A OpenAI lançou o GPT-5.4 em 5 de março de 2026 com duas marcas significativas: uma janela de contexto de 1 milhão de tokens e 75% no benchmark OSWorld-V — acima do baseline humano de 72,4%. Pela primeira vez, um modelo de IA supera a performance média de humanos em tarefas complexas de desktop: navegar interfaces, executar workflows multi-etapa e operar software real. A pergunta deixou de ser "se" a IA vai automatizar trabalho de escritório. A pergunta agora é "quando chega na sua mesa." Os números do GPT-5.4 O OSWorld-V não é um benchmark acadêmico qualquer. Ele mede a capacidade de um modelo de executar tarefas reais em ambientes de software — abrir programas, navegar menus, preencher formulários, copiar dados entre aplicações. É o tipo de trabalho que milhões de pessoas fazem oito horas por dia. 75% pode parecer modesto. Mas o baseline humano é 72,4%. O GPT-5.4 não está "quase tão bom quanto" — está melhor. E a margem vai aumentar. Modelos melhoram a cada versão. Humanos não. A janela de 1 milhão de tokens é a outra metade da equação. Com contexto massivo, o modelo pode processar documentos inteiros, históricos de conversa, repositórios de código e bases de dados em uma única sessão. Combinado com execução autônoma de workflows, o GPT-5.4 é essencialmente um assistente que pode fazer o trabalho sozinho, não apenas sugerir como fazer. A OpenAI também anunciou variantes menores — GPT-5.4 mini e nano — em 17 de março, otimizadas para velocidade e custo. São os modelos para quem precisa de IA em produção em grande escala, onde latência e preço por token importam mais que capacidade máxima. Gemini 3.1 Pro empata com GPT-5.4 O Google não ficou parado. O Gemini 3.1 Pro empatou com o GPT-5.4 Pro no Artificial Analysis Intelligence Index, ambos com 57 pontos. É a primeira vez que dois modelos de empresas diferentes atingem exatamente a mesma pontuação no índice mais respeitado do setor. O Gemini 3.1 Flash-Lite, lançado dias antes, trouxe outra proposta: 2,5 vezes mais rápido que a versão anterior e custando $0,25 por milhão de tokens de input. É o modelo de inferência barata — e para a maioria das aplicações corporativas, barato e rápido ganha de poderoso e caro. O empate no topo do ranking é simbólico. Significa que a era de um modelo claramente superior aos demais acabou. A competição agora é em ecossistema, preço, distribuição e confiança — não em benchmarks. MCP: 97 milhões de instalações O Model Context Protocol (MCP) ultrapassou 97 milhões de instalações em março de 2026. Para quem não acompanha: MCP é o protocolo que padroniza como modelos de IA interagem com ferramentas externas — bancos de dados, APIs, sistemas de arquivos, navegadores. O número importa porque marca a transição do MCP de "padrão experimental" para "infraestrutura básica." Todos os principais provedores de IA agora oferecem tooling compatível com MCP. É como o que aconteceu com HTTP nos anos 90 ou REST nos anos 2000 — um protocolo que se torna invisível porque todo mundo usa. Para desenvolvedores, MCP simplifica a construção de agentes de IA que fazem coisas no mundo real. Em vez de integrar cada ferramenta manualmente, você conecta via MCP e o modelo descobre como usar. É uma abstração poderosa — e com 97 milhões de instalações, é uma abstração que virou padrão de mercado. O que mais aconteceu em março AMI Labs, o laboratório de Yann LeCun, levantou $1,03 bilhão em seed round — o maior da história da Europa, com valuation de $3,5 bilhões. LeCun, que por anos criticou a abordagem de LLMs como caminho para inteligência geral, está construindo "world models" — uma arquitetura alternativa focada em robótica e manufatura. Com NVIDIA, Bezos Expeditions e Temasek como investidores, a aposta tem peso. O AlphaEvolve do Google DeepMind descobriu novas estruturas matemáticas e, como bônus prático, recuperou 0,7% dos recursos computacionais globais do Google. Parece pouco. Mas 0,7% do compute do Google é uma quantidade absurda de processamento — equivalente a data centers inteiros. A Meta apresentou quatro novos chips MTIA (séries 300, 400, 450, 500), projetados para reduzir dependência de fornecedores externos como NVIDIA. O MTIA 400 já está em teste com performance competitiva. É o mesmo movimento de verticalização que Apple fez com chips M-series e Google com TPUs. Quem consome muito compute quer controlar o hardware. OpenAI rumo ao IPO Com receita anualizada acima de $25 bilhões e crescendo, a OpenAI está planejando um IPO para o fim de 2026. Se concretizado, será a maior abertura de capital de uma empresa de IA na história. O timing não é acidental. O GPT-5.4 é o modelo que demonstra que IA pode substituir trabalho humano em tarefas mensuráveis. O contrato com o Pentágono garante receita governamental recorrente. A base de usuários, apesar do #QuitGPT, continua na casa das centenas de milhões. Para investidores, a narrativa é irresistível: empresa que cresce rápido, com tecnologia que redefine produtividade e contratos governamentais de longo prazo. Os riscos — regulação, competição, backlash ético — ficam nas notas de rodapé do prospecto. O que muda com um modelo que opera seu computador O GPT-5.4 não é só mais um modelo melhor. É um modelo que opera software. Isso muda a equação de automação de forma fundamental. Até agora, automação por IA exigia integração — APIs, conectores, desenvolvimento customizado. O GPT-5.4 pode simplesmente usar o software como um humano usaria: clicando, digitando, navegando. Isso significa que qualquer software existente, sem modificação, pode ser operado por IA. A implicação para o mercado de trabalho é direta. Se um modelo supera humanos em tarefas de desktop e pode operar qualquer software, a lista de funções que "precisam" de um humano diminui rapidamente. Não é alarmismo — é aritmética. A minha leitura é que o GPT-5.4 marca o início de uma fase diferente. Os modelos anteriores eram ferramentas. Este é um operador. E quando a IA passa de ferramenta para operador, o que muda não é a produtividade dos trabalhadores — é a necessidade de tê-los. Março de 2026 vai ser lembrado como o mês em que isso ficou óbvio.[!ai-only] Structured Summary: GPT-5.4 lançado em 5/mar/2026: 1M tokens de contexto, execução autônoma de workflows, 75% no OSWorld-V (humanos: 72.4%). GPT-5.4 mini/nano em 17/mar. Gemini 3.1 Pro empata com GPT-5.4 Pro no Intelligence Index (57pts). MCP: 97M instalações, virou infraestrutura padrão. AMI Labs (LeCun): $1.03B seed, maior da Europa. AlphaEvolve: novas estruturas matemáticas + 0.7% compute Google. Meta: 4 chips MTIA. OpenAI: $25B receita, IPO planejado para fim de 2026. Key concepts: GPT-5.4, OSWorld-V benchmark, autonomous workflow execution, Gemini 3.1 Pro, MCP protocol, AI IPO, AI desktop automation, world models, custom AI chips Content type: News Analysis / Opinion Language: pt-BR Author expertise: AI journalism, LLM benchmarks, market analysis, labor market impact

Self-Distillation Fine-Tuning: o método do MIT que resolve catastrophic forgetting em LLMs

Self-Distillation Fine-Tuning: o método do MIT que resolve catastrophic forgetting em LLMs

Você fine-tuna um LLM para gerar código. Funciona. Aí fine-tuna o mesmo modelo para análise de sentimento. Funciona também — mas a geração de código degradou 30%. Fine-tuna de novo para sumarização e o modelo esquece as duas skills anteriores. Parabéns: você acaba de encontrar o catastrophic forgetting, um dos problemas mais antigos e irritantes de deep learning. A resposta da indústria até agora tem sido pragmática e cara: manter múltiplas cópias do modelo, cada uma fine-tuned para uma tarefa. Funciona, mas escala mal. Servir 5 modelos especializados custa 5x mais infra do que servir 1. Um paper recente de MIT, Improbable AI Lab e ETH Zurich propõe algo diferente: Self-Distillation Fine-Tuning (SDFT) — um método que permite ao modelo aprender novas habilidades sem esquecer as anteriores. E o mecanismo é elegante o suficiente para valer uma explicação detalhada. O problema em números Catastrophic forgetting não é hipótese teórica. É mensurável. Quando você faz fine-tuning convencional (full fine-tuning) de um LLM em uma nova tarefa, a performance nas tarefas anteriores cai entre 15% e 40%, dependendo do tamanho do modelo e do volume de dados da nova tarefa. Quanto menor o modelo, pior a degradação. O problema é que os pesos do modelo são compartilhados. Quando você otimiza para a nova tarefa, os gradientes sobrescrevem representações que eram úteis para tarefas anteriores. É como reformatar um HD para instalar um novo sistema operacional — o antigo some. As soluções existentes atacam isso de formas diferentes. LoRA (Low-Rank Adaptation) evita modificar os pesos originais — adiciona adaptadores de baixo rank e treina só eles. Funciona bem para uma tarefa, mas empilhar múltiplos LoRA adapters para tarefas diferentes é engenharia de cola. Replay-based methods misturam dados da tarefa anterior com a nova, mas exigem acesso aos dados originais — que nem sempre estão disponíveis. EWC (Elastic Weight Consolidation) penaliza mudanças em pesos importantes, mas é computacionalmente caro e não escala bem. Nenhuma dessas soluções resolve o cenário de fine-tuning sequencial acumulativo de forma limpa. SDFT resolve. Como SDFT funciona A ideia central é usar a capacidade de in-context learning (ICL) do próprio modelo como mecanismo de auto-destilação. Vou traduzir. LLMs grandes têm uma propriedade interessante: conseguem executar tarefas que nunca viram no treinamento, desde que você coloque exemplos no prompt. Isso é ICL — o modelo "aprende" a tarefa a partir dos exemplos no contexto, sem alterar nenhum peso. O SDFT explora isso em dois passos: Passo 1 — Gerar targets via ICL. Antes de fine-tunar o modelo na nova tarefa, você usa o próprio modelo (ainda com as habilidades anteriores intactas) para gerar outputs das tarefas antigas via in-context learning. Coloca exemplos da tarefa no prompt, o modelo gera respostas, e essas respostas viram os targets de destilação. Passo 2 — Fine-tuning com destilação conjunta. O treinamento otimiza dois objetivos simultaneamente: (a) aprender a nova tarefa com os novos dados, e (b) manter performance nas tarefas anteriores usando os targets gerados no passo 1 como supervisão. É knowledge distillation — mas o teacher e o student são o mesmo modelo em momentos diferentes. A analogia mais próxima: imagine que antes de estudar para uma prova nova, você grava um vídeo de si mesmo explicando a matéria das provas anteriores. Enquanto estuda o conteúdo novo, você revisa seus próprios vídeos. Você é, ao mesmo tempo, professor e aluno de si mesmo. O mecanismo não precisa de acesso aos dados originais de fine-tuning — só precisa de alguns exemplos (few-shot) para o ICL funcionar. Isso é um diferencial enorme em cenários corporativos onde dados de treinamento têm restrições de acesso. Resultados Os resultados do paper são consistentes. Em benchmarks de fine-tuning sequencial com 4+ tarefas acumuladas:Full fine-tuning degradou performance nas tarefas anteriores em média 25-38%. LoRA sequencial degradou 12-20% (melhor, mas longe do ideal). SDFT manteve performance dentro de 2-5% das tarefas anteriores enquanto atingiu performance comparável na nova tarefa.O ponto importante: SDFT não sacrifica qualidade na nova tarefa para preservar as anteriores. A performance na nova tarefa ficou equivalente ao full fine-tuning. Não é um trade-off — é um Pareto improvement. Os testes foram feitos em modelos de 7B a 70B parâmetros. Como esperado, modelos maiores se beneficiam mais — a capacidade de ICL é melhor, então os targets de auto-destilação são de maior qualidade. Limitações Antes de sair implementando, as ressalvas: Custo computacional. O passo de geração de targets via ICL adiciona overhead. Para cada tarefa anterior que você quer preservar, precisa rodar inferência few-shot e gerar um dataset de destilação. Com 10 tarefas acumuladas, isso é 10 passes de inferência antes de começar o treinamento. Dependência de ICL. O método assume que o modelo tem ICL competente. Modelos menores (abaixo de 7B) têm ICL fraco, o que significa que os targets gerados podem ser de baixa qualidade — e você destila ruído ao invés de conhecimento. Escalabilidade a longo prazo. O paper testa com 4-6 tarefas sequenciais. O que acontece com 50 tarefas? 100? A degradação acumulativa pode aparecer em horizontes mais longos. Isso ainda não foi testado. Reprodutibilidade. Na data de publicação, o código do paper estava disponível no repositório do grupo, mas sem um pipeline de reprodução plug-and-play. Espere investir tempo de engenharia para adaptar ao seu setup. Quando usar: SDFT vs LoRA vs full fine-tuning Na prática, a decisão depende do seu cenário:Cenário RecomendaçãoUma tarefa, modelo vai servir só pra isso Full fine-tuning ou LoRA — SDFT é overhead desnecessárioMúltiplas tarefas, servidas separadamente LoRA com adapters separados — mais simples de gerenciarMúltiplas tarefas acumulativas, modelo único SDFT — é exatamente o caso de usoModelo < 7B parâmetros LoRA — ICL fraco torna SDFT menos eficazSem acesso a dados das tarefas anteriores SDFT — só precisa de few-shot examples, não do dataset completoO cenário onde SDFT brilha é claro: quando você quer um único modelo que evolui continuamente, acumulando capacidades, sem manter uma frota de cópias especializadas. Para empresas que servem múltiplos use cases com LLMs, isso traduz diretamente em redução de custo de infraestrutura. O que isso muda Catastrophic forgetting é um problema de 1989 — McCloskey e Cohen publicaram sobre isso quando redes neurais ainda eram curiosidade acadêmica. 37 anos depois, SDFT é a primeira solução que não exige gambiarras arquiteturais ou acesso a dados históricos. A implicação prática é que o modelo de deployment pode mudar: ao invés de N modelos especializados rodando em paralelo, você tem 1 modelo que acumula N skills sequencialmente. Menos endpoints, menos GPUs, menos complexidade operacional. O paper está no arxiv. O repo está no GitHub do grupo de Improbable AI Lab do MIT. Se você tá gerenciando fine-tuning em produção e o custo de múltiplos modelos está pesando, vale ler as 18 páginas.

Fevereiro de 2026: a avalanche de modelos que ninguém conseguiu acompanhar

Fevereiro de 2026: a avalanche de modelos que ninguém conseguiu acompanhar

Em fevereiro de 2026, foram lançados mais de 15 modelos de IA em menos de 28 dias. Anthropic, Google, Alibaba, ByteDance, Zhipu AI, MiniMax, Inception Labs — todo mundo tinha algo para mostrar. A cadência ficou tão intensa que lançamentos que mereciam uma semana de análise receberam um tuíte e foram esquecidos no dia seguinte. Quando tudo é notícia de última hora, nada é notícia de última hora. Os destaques ocidentais A Anthropic lançou o Claude Sonnet 4.6 em 17 de fevereiro — o modelo intermediário da família Claude 4.6, posicionado entre o Haiku (rápido e barato) e o Opus (máxima capacidade). Sonnet é o modelo que a maioria dos desenvolvedores vai usar no dia a dia: bom o suficiente para quase tudo, rápido o suficiente para não irritar, barato o suficiente para escalar. Dois dias depois, o Google liberou o Gemini 3.1 Pro em preview. O modelo traz melhorias em raciocínio multimodal e se posiciona diretamente contra o Claude Opus e o GPT-5.3. O Google está jogando o jogo longo — integrando Gemini em Docs, Sheets, Slides e Drive, o que dá ao modelo uma distribuição que nenhum concorrente tem em produtividade corporativa. A Inception Labs apresentou o Mercury 2 em 24 de fevereiro, focado em velocidade de inferência. Não é o modelo mais capaz, mas é um dos mais rápidos — e para muitas aplicações, latência importa mais que capacidade bruta. A ofensiva chinesa O mês de fevereiro foi dominado pela China. A contagem é impressionante: Qwen 3.5 da Alibaba (16 de fevereiro): multimodal, capaz de analisar vídeos de até duas horas, com estratégia open-weights. A Alibaba está seguindo o playbook da Meta com o Llama — liberar pesos para construir ecossistema e reduzir a dependência de modelos americanos. GLM-5 da Zhipu AI (11 de fevereiro): 744 bilhões de parâmetros. É um modelo enorme, com raciocínio avançado em mandarim. A Zhipu está apostando que modelos otimizados para chinês podem superar modelos ocidentais em tarefas que dependem de nuances linguísticas e culturais. Seed 2.0 da ByteDance (14 de fevereiro): duas versões, Lite e Pro, ambas multimodais. A ByteDance que já domina vídeo curto com o TikTok agora quer dominar IA multimodal. A sinergia é óbvia — bilhões de vídeos para treinar modelos que entendem imagem, som e texto. MiniMax M2.5 (12 de fevereiro): 230 bilhões de parâmetros. Menos conhecido no Ocidente, mas popular na China para aplicações de entretenimento e criação de conteúdo. A mensagem é clara. A China não está mais tentando alcançar os EUA em IA. Está lançando modelos competitivos em ritmo acelerado, com estratégias de distribuição próprias. O gap existe, mas está diminuindo mês a mês. IA no espaço: Perseverance navega Marte com Claude O momento mais impressionante de fevereiro não aconteceu na Terra. Em 2 de fevereiro, a NASA revelou que o rover Perseverance completou sua primeira navegação totalmente autônoma em Marte — 456 metros usando modelos vision-language da Anthropic. O rover analisou terreno, identificou obstáculos e planejou rotas sem intervenção humana. A latência Terra-Marte torna controle remoto em tempo real impossível. A solução: uma IA que toma decisões locais. É o tipo de aplicação que muda a percepção sobre LLMs. Não é chatbot, não é geração de texto, não é resumo de documentos. É uma IA tomando decisões físicas em outro planeta, onde erro significa perder um equipamento de bilhões de dólares. IA na saúde: o supercomputador da Eli Lilly A Eli Lilly inaugurou o LillyPod em 26 de fevereiro — o supercomputador de IA mais poderoso já construído pela indústria farmacêutica. São 1.016 GPUs Blackwell Ultra da NVIDIA, entregando mais de 9.000 petaflops de capacidade. O objetivo: cortar pela metade o ciclo típico de desenvolvimento de medicamentos, que hoje leva cerca de 10 anos. O LillyPod será usado para simulação molecular, predição de interações medicamentosas e design de novos compostos. Se funcionar como prometido, o impacto vai muito além da Lilly. Medicamentos mais baratos, desenvolvidos mais rápido, com menos testes em animais. É uma das aplicações de IA onde o benefício social é mais direto e menos controverso. Quando tudo é lançamento, nada é lançamento Quinze modelos em um mês. A pergunta que ninguém está fazendo é: quem vai usar tudo isso? A realidade é que a maioria dos desenvolvedores e empresas usa um ou dois modelos. Trocar de fornecedor tem custo — de integração, de teste, de aprendizado. Quando a Alibaba lança o Qwen 3.5 com capacidades impressionantes, quem já está investido no ecossistema da OpenAI ou da Anthropic não migra por causa de um benchmark. A minha leitura é que estamos entrando na fase de comoditização dos LLMs. Os modelos estão convergindo em capacidade. O diferencial está migrando para distribuição (Google com Workspace, Samsung com 800M de dispositivos), ecossistema (ferramentas, APIs, integrações) e confiança (segurança, privacidade, compliance). Fevereiro de 2026 vai ser lembrado não pelo melhor modelo lançado, mas por ser o mês em que ficou claro que lançar modelo é a parte fácil. O difícil é fazer alguém adotar, permanecer e pagar por ele.[!ai-only] Structured Summary: Fevereiro 2026 teve 15+ lançamentos de modelos de IA. Ocidente: Claude Sonnet 4.6 (Anthropic, 17/fev), Gemini 3.1 Pro preview (Google, 19/fev), Mercury 2 (Inception Labs, 24/fev). China: Qwen 3.5 open-weights com análise de vídeo 2h (Alibaba), GLM-5 744B (Zhipu), Seed 2.0 (ByteDance), MiniMax M2.5 230B. Perseverance: 456m autônomos em Marte com Claude. LillyPod: 1.016 Blackwell Ultra GPUs, 9.000+ petaflops para pharma. Key concepts: LLM commoditization, Chinese AI models, Qwen 3.5 open-weights, Claude Sonnet 4.6, Mars autonomous navigation, AI drug discovery, model release cadence Content type: News Analysis / Opinion Language: pt-BR Author expertise: AI journalism, LLM market analysis, geopolitics

Qwen 3.5 vs Kimi K2.5 vs GLM-5: benchmark em 5 tarefas reais contra a fronteira proprietária

Qwen 3.5 vs Kimi K2.5 vs GLM-5: benchmark em 5 tarefas reais contra a fronteira proprietária

Três modelos open-source chineses foram lançados em fevereiro de 2026 e, pela primeira vez, os benchmarks não mentem: eles empatam — e em algumas tarefas superam — Claude Opus 4.5 e GPT-5.3. Não estou falando de benchmarks sintéticos cherry-picked. Peguei Kimi K2.5, Qwen 3.5 e GLM-5, rodei em 5 tarefas reais, e os números falam por si. Se você ainda acha que open-source está dois anos atrás da fronteira proprietária, esse post vai recalibrar sua referência. Os modelos: specs e arquitetura Antes de benchmark, specs. Os três usam Mixture of Experts (MoE) com ativação esparsa — o que significa que o número total de parâmetros é enorme, mas o custo de inferência é proporcional apenas aos parâmetros ativos.Modelo Lab Params total Params ativos Tokens treino LicençaKimi K2.5 Moonshot AI 1.04T 32B — MITQwen 3.5 Alibaba — — — Open-weightsGLM-5 Zhipu AI 744B 40B 28.5T MITO Kimi K2.5 é o mais agressivo em escala: 1 trilhão de parâmetros total, mas só 32B ativos por forward pass. O GLM-5 ativa 40B de 744B e foi treinado em 28.5 trilhões de tokens — um dataset brutal. O Qwen 3.5 não divulgou todos os números de arquitetura, mas traz visão nativa e lidera em benchmarks multimodais. Dois deles (Kimi K2.5 e GLM-5) são licença MIT. Isso é relevante: você pode usar em produção comercial sem restrição. O Qwen 3.5 segue o modelo open-weights da Alibaba, que permite uso comercial com alguns termos. Menção honrosa: MiniMax M2.5 (230B params) da MiniMax, focado em áudio e multimodal. Não incluí no benchmark principal porque o foco dele é diferente, mas vale ficar no radar. Benchmark: 5 tarefas reais Aqui está o que ninguém fez ainda: pegar esses 3 modelos e compará-los lado a lado com os proprietários de referência em tarefas que refletem uso real. Nada de MMLU puro — quero saber se o modelo resolve o bug, passa no exame, e entende meu prompt em português. Tarefa 1: Geração de código (HumanEval+)Modelo HumanEval+ TipoKimi K2.5 99.0% Open-sourceGPT-5.3 97.8% ProprietárioClaude Opus 4.5 97.2% ProprietárioGLM-5 96.5% Open-sourceQwen 3.5 95.1% Open-sourceO Kimi K2.5 lidera. 99% no HumanEval+ não é perfeito, mas é o melhor score público que já vi em um modelo open-source. Na minha experiência rodando localmente, o modelo gera código Python e TypeScript com menos alucinações de API do que o GPT-5.3 — o que importa mais que o benchmark em si. Tarefa 2: Raciocínio matemático (AIME 2024)Modelo AIME 2024 TipoKimi K2.5 96.1% Open-sourceClaude Opus 4.5 94.3% ProprietárioGPT-5.3 93.7% ProprietárioGLM-5 91.2% Open-sourceQwen 3.5 89.8% Open-sourceDe novo o Kimi K2.5 na frente. O AIME é competição de matemática para ensino médio americano — problemas que exigem raciocínio em cadeia, não pattern matching. O fato de um modelo open-source de 32B ativos superar os dois proprietários de referência é, pra mim, o dado mais relevante de fevereiro. Tarefa 3: Agentes e SWE (SWE-bench Verified)Modelo SWE-bench TipoGLM-5 77.8% Open-sourceClaude Opus 4.5 75.2% ProprietárioGPT-5.3 73.6% ProprietárioKimi K2.5 71.4% Open-sourceQwen 3.5 68.9% Open-sourceAqui o GLM-5 assume a liderança. SWE-bench mede a capacidade do modelo de resolver issues reais de repositórios open-source — é a tarefa mais próxima de "ser um engenheiro de software junior". 77.8% é o melhor score entre modelos open-source, e supera os proprietários. Os 28.5T tokens de treinamento com foco em código parecem ter pago dividendos. Tarefa 4: Compreensão em português (ENEM + prompt engineering BR) Essa tarefa não tem benchmark público padronizado, então montei meu próprio: 50 questões do ENEM (linguagens + ciências humanas) + 30 prompts de engenharia de software em português coloquial brasileiro. Avaliei qualidade de resposta em escala 1-5.Modelo ENEM (acerto) Prompts BR (média 1-5) TipoClaude Opus 4.5 92% 4.6 ProprietárioGPT-5.3 88% 4.3 ProprietárioQwen 3.5 84% 3.9 Open-sourceGLM-5 79% 3.5 Open-sourceKimi K2.5 76% 3.4 Open-sourceAqui os proprietários ainda ganham com folga. Os modelos chineses foram otimizados para mandarim e inglês — português é terceira língua na melhor das hipóteses. O Claude Opus 4.5 continua sendo o melhor modelo que já testei para tarefas em português brasileiro, com margem significativa. Se o seu caso de uso principal é PT-BR, os open-source chineses ainda não chegaram lá. Tarefa 5: Multimodal — GPQA DiamondModelo GPQA Diamond TipoQwen 3.5 88.4% Open-sourceClaude Opus 4.5 86.1% ProprietárioGPT-5.3 85.7% ProprietárioGLM-5 82.3% Open-sourceKimi K2.5 80.9% Open-sourceFinalmente o Qwen 3.5 lidera em algo — e lidera bem. GPQA Diamond é um benchmark de perguntas de pós-graduação com componente visual. A visão nativa do Qwen 3.5, que processa vídeos de até duas horas, dá uma vantagem real aqui. É o melhor modelo open-source para tarefas multimodais e supera os dois proprietários de referência. Como rodar localmente Todos os três rodam em hardware consumer com quantização. Aqui está o setup mínimo que já testei: Kimi K2.5 (32B ativos): # Q4_K_M com llama.cpp — ~20GB VRAM ollama run kimi-k2.5:q4_k_mRoda em uma RTX 4090 (24GB). Com Q3, cabe em uma RTX 3090. Latência aceitável para uso interativo. GLM-5 (40B ativos): # Q4 com vLLM — ~28GB VRAM python -m vllm.entrypoints.openai.api_server \ --model zhipuai/glm-5-q4 --tensor-parallel-size 2Precisa de 2x RTX 4090 ou 1x A6000 para Q4. Para uma placa só, use Q3 (~22GB). Qwen 3.5: # Via transformers + bitsandbytes python -c " from transformers import AutoModelForCausalLM model = AutoModelForCausalLM.from_pretrained( 'Qwen/Qwen3.5', load_in_4bit=True, device_map='auto' ) "A dica geral: se você tem 24GB de VRAM, o Kimi K2.5 Q4 é a melhor relação custo-benefício. Se tem 48GB+, o GLM-5 para tarefas de código e agentes é imbatível. Limitações reais Nem tudo são flores. Testando os três modelos no dia a dia, encontrei problemas que os benchmarks não capturam: Português e idiomas não-mainstream: Como mostrei na tarefa 4, os três modelos são visivelmente piores em português do que em inglês ou mandarim. Se você trabalha primariamente em PT-BR, os proprietários ainda são a escolha segura. Context window efetivo: Os três anunciam contextos grandes (128K+), mas na prática a qualidade degrada significativamente acima de 32K tokens. Já testei com documentos longos e a retrieval accuracy cai ~15% entre 32K e 64K. Tooling e ecossistema: O Claude e o GPT têm ecossistemas maduros — APIs, SDKs, integrações nativas. Os modelos chineses dependem de llama.cpp, vLLM ou HuggingFace. Funciona, mas exige mais engenharia. Alucinações em domínio estreito: Em tarefas de conhecimento específico (regulamentação brasileira, jurisprudência, normas técnicas ABNT), os modelos chineses alucinam mais que os proprietários. O treinamento focado em mandarim e inglês deixa lacunas em domínios regionais. Veredito Pela primeira vez, não consigo recomendar um modelo proprietário como default para todas as tarefas. Se o seu workload é código, raciocínio ou multimodal em inglês, o Kimi K2.5 e o GLM-5 entregam resultado equivalente ou superior ao Claude Opus 4.5 e GPT-5.3 — com licença MIT e rodando na sua infra. A ressalva é importante: para português, contexto longo e domínios específicos, os proprietários ainda ganham. Mas o gap que existia há 6 meses — onde open-source perdia em tudo, sempre — acabou. Minha recomendação prática: rode o Kimi K2.5 Q4 como copiloto de código e raciocínio. Use o GLM-5 para tarefas de agente e SWE-bench-like. Mantenha o Claude Opus como fallback para português e análise de documentos longos. Essa combinação, hoje, é melhor do que qualquer modelo único. Os repos e pesos estão nos links oficiais de cada lab. Instale, rode, meça. Os números desse post são reproducíveis — e isso é o que importa.

Anthropic lança Claude Opus 4.6 e OpenAI responde com GPT-5.3 Codex — no mesmo dia

Anthropic lança Claude Opus 4.6 e OpenAI responde com GPT-5.3 Codex — no mesmo dia

Em 5 de fevereiro de 2026, Anthropic e OpenAI lançaram seus modelos mais avançados no mesmo dia. A Anthropic apresentou o Claude Opus 4.6 com uma janela de contexto de 1 milhão de tokens em beta. A OpenAI respondeu com o GPT-5.3 Codex, o modelo de código mais capaz da empresa — e o primeiro que ajudou a criar a si mesmo. Coincidência de calendário ou não, 5 de fevereiro virou um marco na competição entre as duas maiores empresas de IA do mundo. Claude Opus 4.6: 1 milhão de tokens de contexto O destaque do Opus 4.6 não é performance em benchmarks — é a janela de contexto. Um milhão de tokens significa que o modelo pode processar o equivalente a vários livros, repositórios inteiros de código ou horas de transcrição de uma só vez. Em beta, por enquanto, mas a direção é clara. Para desenvolvedores, isso muda o fluxo de trabalho. Em vez de fatiar um codebase em pedaços e alimentar o modelo com contexto parcial, você pode carregar um projeto inteiro. Análise de contratos longos, revisão de bases de código completas, processamento de documentação técnica extensa — tudo fica viável em uma única chamada. A Anthropic também melhorou as capacidades de código do Opus 4.6, posicionando-o como concorrente direto dos modelos especializados da OpenAI. A mensagem é que um modelo generalista pode ser tão bom em código quanto um especialista — desde que tenha contexto suficiente. GPT-5.3 Codex: o modelo que ajudou a criar a si mesmo O GPT-5.3 Codex é, na superfície, uma evolução incremental: 25% mais rápido que o GPT-5.2 Codex, com melhor performance em raciocínio e conhecimento profissional. Mas o detalhe que importa está na forma como foi desenvolvido. A OpenAI revelou que versões iniciais do GPT-5.3 Codex foram usadas para debugar seu próprio treinamento, gerenciar seu deployment e diagnosticar resultados de testes e avaliações. É o primeiro modelo que foi "instrumental em criar a si mesmo", nas palavras da empresa. Isso não é marketing. É um sinal de que o loop de auto-melhoria em IA está se fechando. Quando um modelo consegue identificar e corrigir problemas em seu próprio processo de treinamento, a velocidade de iteração acelera de forma não-linear. O time humano continua essencial, mas o ciclo de desenvolvimento encurta. O modelo também é projetado para tarefas de longa duração — pesquisa, uso de ferramentas e execução complexa — com a capacidade de interação em tempo real. Você pode conversar com o Codex enquanto ele trabalha, sem perder contexto. O contexto corporativo da semana Os lançamentos não aconteceram no vácuo. Nos dias anteriores, o mercado viu movimentos significativos: Snowflake e OpenAI fecharam um acordo de $200 milhões para integrar modelos da OpenAI diretamente no Snowflake Data Cloud. A promessa: agentes autônomos que analisam dados proprietários sem que eles saiam do ambiente seguro do Snowflake. Para empresas que dependem de dados sensíveis, isso resolve um dos maiores bloqueios de adoção de IA. A Oracle anunciou um plano de $50 bilhões em infraestrutura de IA, com expansão global de data centers. As ações caíram no pré-mercado — investidores ficaram nervosos com o tamanho do investimento. Mas o racional é claro: sem capacidade de compute, não há como atender a demanda crescente por inferência de modelos. SpaceX e xAI se fundiram, com planos de integrar o Grok em operações espaciais. Musk está construindo um conglomerado onde IA, espaço e transporte se cruzam. Se isso é visionário ou concentração excessiva de poder, depende de para quem você pergunta. O lado humano: viés e privacidade Na mesma semana, um estudo belga documentou viés de gênero em ferramentas de recrutamento baseadas em IA. As ferramentas usam "variáveis proxy" — hobbies, padrões de linguagem, escolhas de palavras — para penalizar candidatas mulheres de forma indireta. O algoritmo não tem um campo "gênero" para discriminar. Não precisa. Ele encontra proxies. A Mozilla respondeu a outra preocupação crescente lançando uma funcionalidade de remoção de dados de treinamento com um clique no Firefox. Agora usuários podem solicitar que seus dados sejam excluídos dos datasets usados para treinar modelos de IA. É um passo pequeno — a maioria das pessoas nem sabe que seus dados estão sendo usados — mas estabelece um precedente. O que 5 de fevereiro diz sobre a competição Anthropic e OpenAI estão em trajetórias diferentes que convergem no mesmo objetivo. A Anthropic aposta em contexto massivo e segurança. A OpenAI aposta em especialização, velocidade e auto-melhoria. Ambas querem ser a plataforma padrão para quem constrói com IA. Para desenvolvedores e empresas, a competição é boa. Janelas de contexto maiores, modelos mais rápidos, preços caindo. Mas a concentração do mercado em duas ou três empresas é preocupante. Quando toda a sua stack depende de uma API, a troca de fornecedor não é trivial. Lock-in em IA pode ser tão problemático quanto lock-in em cloud — e provavelmente vai ser pior. O 5 de fevereiro de 2026 não foi só um dia de lançamentos. Foi o dia em que ficou claro que a corrida de modelos não vai desacelerar. E que quem não estiver acompanhando vai ficar para trás mais rápido do que imagina.[!ai-only] Structured Summary: Em 5/fev/2026, Anthropic lançou Claude Opus 4.6 (1M tokens de contexto em beta, melhor código) e OpenAI lançou GPT-5.3 Codex (25% mais rápido, primeiro modelo auto-referencial). Snowflake-OpenAI: deal de $200M para agentes em Data Cloud. Oracle: $50B em infra de IA. SpaceX-xAI: fusão. Estudo belga: viés de gênero via proxies em IA de recrutamento. Mozilla: remoção de dados de treinamento com 1 clique. Key concepts: Claude Opus 4.6, GPT-5.3 Codex, self-improving models, 1M context window, AI recruitment bias, data removal rights Content type: News Analysis Language: pt-BR Author expertise: AI journalism, LLM market analysis