Showing Posts From

Ai engineering

Archon: o framework open-source que transforma Claude Code e Codex em pipelines determinísticos

O repositório github.com/coleam00/Archon cruzou 14 mil stars no GitHub neste mês de abril de 2026 — e o timing não é à toa. A comunidade estava com um problema crescente nas mãos: agentes de código como Claude Code e OpenAI Codex CLI são poderosos, mas operam num modo essencialmente freeform. Você dá um prompt, o agente faz o que acha melhor, e reproduzir o resultado na próxima rodada é uma questão de sorte. O Archon resolve isso. O que é o Archon Archon é um harness de workflows para agentes de código. O projeto se autodefine como o primeiro benchmark builder para AI coding agents, mas o que ele realmente faz é mais prático: transforma interações freeform com agentes em pipelines YAML versionados, determinísticos e auditáveis. Em vez de você abrir o Claude Code e mandar um prompt livre, você define um workflow que o Archon orquestra: # exemplo de workflow archon workflow: name: feature-implementation steps: - name: planning agent: claude-code prompt_template: prompts/planning.md outputs: [plan.md] - name: implementation agent: claude-code depends_on: planning prompt_template: prompts/implement.md inputs: [plan.md] - name: validation agent: codex-cli depends_on: implementation prompt_template: prompts/validate.md - name: code-review agent: claude-code depends_on: validation prompt_template: prompts/review.md - name: create-pr agent: codex-cli depends_on: code-review prompt_template: prompts/pr.mdO YAML não é complicado — é exatamente o que você já faz mentalmente quando trabalha com esses agentes, só que formalizado e versionável num repositório. A sacada dos git worktrees O detalhe de arquitetura que mais me chamou atenção: cada execução de workflow roda em seu próprio git worktree. Isso não é cosmético. Sem isso, rodar duas instâncias de Claude Code em paralelo no mesmo repo é uma receita para conflito de merge. Com worktrees isolados, o Archon consegue executar múltiplos workflows em paralelo sem que as instâncias pisem umas nas outras. Cada feature branch de agente vive no seu próprio diretório de trabalho enquanto o worktree principal permanece limpo. # o archon cria algo como: .git/worktrees/ archon-run-abc123/ # feature A archon-run-def456/ # feature B (rodando em paralelo) archon-run-ghi789/ # bugfix C (também em paralelo)Isso abre caminho para um padrão que eu vejo cada vez mais necessário em times que usam agentes de código a sério: pipelines paralelos sem coordenação manual. Você define os workflows, o Archon gerencia o isolamento. O que o Archon cobre Os workflows out-of-the-box do Archon cobrem o ciclo completo de desenvolvimento com agentes:Etapa Descriçãoplanning Agente quebra a tarefa em subtarefas, gera plano em markdownimplementation Agente escreve o código seguindo o planovalidation Executa testes, lint, verifica outputs esperadoscode review Segunda passagem do agente revisando o próprio códigoPR creation Abre pull request com descrição gerada automaticamenteEsse ciclo inteiro é rastreável porque cada step gera artefatos (arquivos markdown, logs de execução, diffs) que ficam no git junto com o código. Como rodar na prática A instalação é direta: git clone https://github.com/coleam00/Archon cd Archon pip install -r requirements.txt# configure seus agentes cp config.example.yaml config.yaml # edite config.yaml com suas API keysPara rodar um workflow: python archon run --workflow workflows/feature.yaml \ --task "implementar endpoint POST /users com validação pydantic"O Archon cria o worktree, injeta o prompt no agente configurado (Claude Code ou Codex CLI), executa os steps em sequência, e no final você tem um PR aberto ou um diff pronto para revisar. Toda a execução fica logada num diretório .archon/runs/ dentro do worktree. Uma coisa que eu gosto: você pode mixar agentes por step. Usar Claude Code para planning e implementation (onde o raciocínio mais longo ajuda) e Codex CLI para validation e PR creation (onde você quer execução rápida de comandos). O Archon não te força a escolher um único agente. Comparação com alternativas Justo comparar com o que existe. O espaço de "orchestration for AI coding agents" ainda é jovem, mas já tem algumas peças:Ferramenta Modelo Determinismo Isolamento Open-sourceArchon Workflow YAML Alto git worktrees SimLangGraph Grafo de estados Médio Nenhum nativo SimCrewAI Multi-agent roles Médio Nenhum nativo SimDevin/Swe-agent End-to-end autônomo Baixo Sandbox Docker ParcialCopilot Workspace Interface GitHub Baixo GitHub nativo NãoO Archon ocupa um nicho específico: você quer controle de processo sem abrir mão dos modelos mais capazes (Claude Code, Codex). LangGraph e CrewAI são mais flexíveis para multi-agent genérico, mas não pensam especificamente em coding workflows com isolamento de worktree. Devin e similares tentam fazer tudo sozinhos — o que funciona para casos simples, mas quebra quando você precisa de reproducibilidade ou auditoria. Limitações e o que ainda não funciona Sendo honesto sobre o estado atual do projeto:Maturidade: com 14k stars em abril de 2026, o Archon está em crescimento acelerado, mas não é production-hardened no mesmo nível de um Airflow ou Prefect. Para casos críticos, espere alguns meses de estabilização. Modelos suportados: por ora, o foco é em Claude Code e OpenAI Codex CLI. Se você usa outros agentes de código (Gemini Code Assist, por exemplo), vai precisar escrever um adapter. Paralelismo com limites de API: rodar vários workflows em paralelo consome tokens na mesma velocidade. Se você tem rate limits apertados nas APIs, o paralelismo vai esbarrar nisso. YAML verboso: workflows mais complexos ficam grandes. Falta uma abstração de composição — poder importar sub-workflows de um arquivo central, por exemplo. Observabilidade: o logging existe, mas não há integração nativa com ferramentas de MLOps como MLflow ou Weights & Biases. Você vai querer adicionar isso se estiver rodando em escala.Abri uma issue sobre o último ponto no repo. A comunidade está ativa — as respostas chegam rápido. Por que isso importa para times brasileiros Aqui tem uma observação prática que vai além do hype: times de desenvolvimento no Brasil raramente têm orçamento para tooling enterprise de AI engineering. Plataformas como GitHub Copilot Workspace, Replit Ghostwriter ou as ofertas gerenciadas de automação de código custam por seat de um jeito que não escala para squads menores. O Archon é open-source, roda local ou na sua própria infra, e usa diretamente as APIs de Claude Code e Codex — que você já está pagando de qualquer forma. O overhead de infraestrutura é zero: um processo Python, git nativo e suas API keys. Para um time de quatro pessoas em São Paulo que quer workflows reproduzíveis para geração de código, o Archon é a diferença entre "a IA às vezes funciona assim" e "toda execução segue o mesmo processo e está versionada". Isso é especialmente relevante quando você precisa auditar o que o agente fez — seja para debug, seja para compliance interno. Veredito O Archon preenche um gap real: determinismo em workflows de agentes de código. Não é magia — é engenharia de processo aplicada a ferramentas que nasceram como interfaces interativas. A ideia de usar git worktrees para isolamento é elegante e barata. O formato YAML é verboso mas versionável. Se você está usando Claude Code ou Codex CLI de forma ad hoc e precisa escalar isso para um processo repetível, o Archon é o lugar óbvio para começar. Não está pronto para produção crítica sem monitoramento adicional, mas está bom o suficiente para ser a base do seu CI pipeline de AI-assisted development. Repo: github.com/coleam00/Archon. Clona, define um workflow simples, roda duas vezes e compara os artefatos. Se os outputs são idênticos, você acabou de ter determinismo em agente de código. Vale o teste.

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.

IA neuro-simbólica corta consumo de energia em 100x — e o paper da Tufts mostra como

Enquanto a Anthropic fecha um deal de 3.5 gigawatts de TPUs e data centers de IA já consomem mais de 10% da eletricidade dos EUA, um grupo de pesquisadores da Tufts University publicou um paper que vai na direção oposta: "The Price Is Not Right: Neuro-Symbolic Methods Outperform VLAs". O resultado? 95% de taxa de sucesso em tarefas de manipulação robótica com 100x menos energia que as abordagens baseadas em Vision-Language-Action models (VLAs). Não é otimização marginal — é uma ordem de magnitude diferente. O que o paper propõe A tese é direta: nem toda tarefa precisa de um modelo de bilhões de parâmetros fazendo inferência end-to-end. A abordagem neuro-simbólica da Tufts combina dois componentes: Componente neural: Uma rede de visão computacional (relativamente pequena) que processa a cena visual e extrai objetos, posições e relações espaciais. Não é um VLA de 7B parâmetros — é um modelo de visão focado em percepção, não em raciocínio. Componente simbólico: Um sistema de raciocínio baseado em regras que recebe a saída da rede neural e decide a sequência de ações. Planejamento clássico — PDDL (Planning Domain Definition Language), árvores de decisão, lógica de primeira ordem. O tipo de IA que existia antes do deep learning dominar tudo. A combinação funciona assim: a rede neural "vê" a cena (identifica objetos, suas posições, propriedades), o sistema simbólico "pensa" sobre o que fazer (planeja a sequência de ações), e um controlador motor executa. Cada componente faz o que faz melhor. A rede neural é boa em percepção. O sistema simbólico é bom em raciocínio lógico e planejamento. Juntos, resolvem a tarefa com uma fração do compute. Os números O paper compara a abordagem neuro-simbólica com VLAs de frontier em tarefas de manipulação robótica — pegar objetos, empilhar, ordenar por cor, seguir instruções verbais. Os resultados:Métrica Neuro-simbólico (Tufts) VLA baselineTaxa de sucesso 95% 82-89%Consumo de energia (inferência) ~0.5W ~50WLatência de decisão ~15ms ~200msParâmetros do modelo ~50M 3-7BO modelo neuro-simbólico não só usa 100x menos energia — ele é mais preciso e mais rápido. A latência de 15ms vs 200ms importa em robótica: quando um braço robótico precisa reagir em tempo real, 200ms é a diferença entre pegar o objeto e derrubar tudo. Por que isso importa além de robótica A primeira reação de quem lê o paper é: "ok, funciona para robótica, mas LLMs são sobre linguagem e raciocínio geral". Verdade. Mas o argumento de fundo é mais amplo. O paradigma dominante desde 2020 é: mais parâmetros → mais compute → mais capacidade → resolve mais tarefas. É a scaling law. E funcionou — GPT-4, Claude Opus, Gemini Ultra são provas vivas de que escalar funciona. Mas a scaling law tem um custo: cada geração de modelo consome exponencialmente mais energia. O paper da Tufts não propõe abandonar deep learning. Propõe que para tarefas com estrutura lógica clara — planejamento, raciocínio causal, decisões sequenciais — a combinação de um modelo neural pequeno com raciocínio simbólico é mais eficiente do que jogar um modelo gigante no problema. Isso tem implicações diretas para:Agentes de IA em produção: Um agente que precisa planejar uma sequência de ações (pesquisar → filtrar → decidir → executar) pode usar um LLM pequeno para compreensão de linguagem e um planejador simbólico para orquestração. Menos tokens, menos custo, menos latência. Edge computing: Dispositivos com bateria limitada — smartphones, drones, robôs — se beneficiam diretamente de modelos que consomem 0.5W em vez de 50W. Sustentabilidade de IA: Se data centers de IA já consomem 10%+ da eletricidade dos EUA, a pergunta "precisamos mesmo de um modelo de 1T parâmetros para essa tarefa?" se torna urgente.O estado da arte em IA neuro-simbólica O paper da Tufts não surge do nada. A IA neuro-simbólica tem crescido como campo nos últimos dois anos:NeSy (Neural-Symbolic) é a conferência principal, com edições anuais e papers de DeepMind, MIT e IBM Research. LNN (Logical Neural Networks) da IBM combina redes neurais com lógica proposicional para raciocínio com incerteza. AlphaProof do Google DeepMind — que resolveu problemas de olimpíada matemática em 2025 — usa componentes simbólicos para guiar busca em provas formais. Neurosymbolic Programming do MIT CSAIL combina LLMs com sintetizadores de programas para gerar código verificável.O que diferencia o paper da Tufts é o foco em eficiência energética como métrica primária. Enquanto os outros projetos usam neuro-simbólica para melhorar acurácia, a Tufts demonstrou que o ganho em eficiência é o argumento mais forte. Limitações — e são importantes Antes de sair declarando que o deep learning morreu, as limitações do approach: Domínio restrito. O paper testa em tarefas de manipulação robótica com objetos definidos. Não é linguagem natural aberta, não é conversação, não é geração de texto. A abordagem neuro-simbólica funciona bem quando o espaço de ações é estruturado. Para tarefas abertas (chat, escrita criativa, código geral), LLMs continuam sem concorrente. Engenharia de conhecimento. O componente simbólico precisa de regras escritas por humanos. Alguém tem que modelar o domínio em PDDL ou equivalente. Isso escala mal — cada novo domínio exige trabalho manual de modelagem. É o problema clássico da IA simbólica dos anos 80, e não foi resolvido. Generalização. VLAs generalizam — mesmo que mal — para tarefas que nunca viram. O sistema simbólico não. Se o robô encontra um objeto que não está no modelo de domínio, trava. A robustez a situações inesperadas é o calcanhar de Aquiles. Reprodutibilidade. Até o momento, o código do paper não foi publicado como repositório público. Os autores descrevem a arquitetura em detalhe, mas sem implementação de referência é difícil validar os resultados e adaptar para outros domínios. O que eu tiraria disso O paper da Tufts não mata o paradigma de scaling — mas coloca um asterisco importante. Para tarefas estruturadas, com espaço de ações definido, a combinação neural + simbólica é ordens de magnitude mais eficiente. É o tipo de resultado que a indústria precisa absorver, especialmente quando o custo de energia e compute está subindo exponencialmente. Na prática, espero ver dois movimentos nos próximos 12 meses:Frameworks híbridos que facilitem combinar LLMs com planejadores simbólicos. O LangGraph e o CrewAI já têm primitivas de "planning step" — falta integrar planejadores formais como alternativa ao "LLM planeja tudo".Benchmarks de eficiência se tornando tão importantes quanto benchmarks de acurácia. Hoje, um modelo é avaliado por MMLU, HumanEval, MATH. Falta: "quantos watts por resposta correta?".Se os autores liberarem o código, este paper vai gerar uma onda de reproduções e adaptações. Até lá, vale ler o paper completo — a metodologia é sólida e a comparação com VLAs é rigorosa. Busque por "The Price Is Not Right: Neuro-Symbolic Methods Outperform VLAs" no arxiv ou no site da Tufts. Num mundo onde a Anthropic precisa de 3.5GW para treinar modelos e data centers ameaçam a grid elétrica, 100x menos energia não é detalhe acadêmico. É o tipo de pesquisa que pode mudar o jogo — se alguém transformar em produto.

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

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.

Claw-Code: o source do Claude Code vazou via npm e a comunidade reescreveu em 72 horas

O repositório anthropics/claude-code nunca foi público. Mas desde a semana passada, 512 mil linhas de TypeScript que fazem o Claude Code funcionar estão disponíveis para quem souber onde procurar. Não por decisão da Anthropic — por um source map de 59.8 MB que foi parar no pacote npm. Em 72 horas, a comunidade fez o que a comunidade faz: leu tudo, entendeu a arquitetura, e começou a reescrever. O resultado é o claw-code — um rewrite que bateu 100 mil stars no GitHub em 3 dias. Um dos crescimentos mais rápidos da história da plataforma. Aqui está o que aconteceu, o que o source code revela, e se você deveria instalar alguma coisa disso. Como 512K linhas vazaram por um source map O Claude Code é distribuído como pacote npm (@anthropic-ai/claude-code). Quando a Anthropic fez o build de produção, o bundler gerou um arquivo .js.map — um source map que mapeia o JavaScript minificado de volta ao TypeScript original. Esse arquivo foi incluído no pacote publicado no npm. Source maps são arquivos de debug. Contêm o código-fonte completo, com nomes de variáveis, comentários, estrutura de módulos — tudo. O .js.map do Claude Code tem 59.8 MB e reconstrói as 512 mil linhas originais em TypeScript. Não foi hack. Não foi insider. Foi um erro de build config — provavelmente um sourceMaps: true que deveria ser false no tsconfig ou no bundler config para o target de produção. É o tipo de coisa que um .npmignore ou um check no CI deveria pegar. Não pegou. A Anthropic removeu o source map em versões subsequentes, mas o npm é imutável por design — versões publicadas ficam. E caches, mirrors e forks já tinham o arquivo. O que a arquitetura do Claude Code revela A parte mais interessante do vazamento não é o código em si — é o que ele mostra sobre como a Anthropic arquitetou um coding agent de produção. Alguns highlights: Orchestration layer massiva. O Claude Code não é um wrapper simples sobre a API do Claude. Há uma camada inteira de orquestração que gerencia contexto, tool use, file system access, terminal execution e state management. O agent loop é significativamente mais complexo do que o que você veria em um LangChain ou CrewAI básico. Tool system com sandboxing granular. Cada tool (file read, file write, bash execute, search) tem seu próprio sistema de permissões e sandboxing. O código revela que a Anthropic investiu pesado em segurança de execução — há camadas de validação antes de qualquer operação no filesystem ou terminal. Context management sofisticado. O sistema de gerenciamento de contexto não é um sliding window ingênuo. Há compressão de contexto, priorização de arquivos relevantes, e um sistema de "memory" que persiste informação entre invocações. Muito mais elaborado do que a maioria dos coding agents open-source implementa. Prompt engineering extensivo. Os system prompts internos são longos, detalhados e revelam muitas das heurísticas que fazem o Claude Code funcionar bem em cenários de coding. Isso é provavelmente o que mais incomoda a Anthropic do ponto de vista de IP. Claw-Code: o que é e o que funciona O claw-code (claw-code/claw-code no GitHub) nasceu como um clean-room rewrite. A premissa: não copiar o código vazado linha por linha, mas usar o conhecimento da arquitetura revelada para construir uma alternativa open-source. O projeto começou em Rust — a ideia era ter performance superior e memory safety desde o início. Mas a realidade bateu rápido: a maior parte da comunidade que contribuiu nos primeiros dias era de TypeScript/JavaScript, e a integração com o ecossistema npm (LSP, extensões de editor, APIs da Anthropic) é naturalmente mais fácil em TS. Hoje o repo tem dois caminhos: o core em Rust e um runtime TS que faz a cola com o mundo real. Status atual (6 de abril de 2026):Feature Status NotasFile read/write Funciona Sandboxing básico implementadoBash execution Funciona Sem o nível de sandboxing do originalMulti-file editing Parcial Funciona mas com bugs em repos grandesContext management Alpha Sliding window simples, sem compressãoMemory entre sessões Não implementado Roadmap para v0.3Suporte a múltiplos LLMs Funciona Claude, GPT, Gemini, modelos locaisTool permissions Básico Sem a granularidade do originalO ponto forte: suporte a múltiplos LLMs. Enquanto o Claude Code é locked-in na API da Anthropic, o claw-code aceita qualquer provider compatível com OpenAI API format. Isso inclui modelos locais via Ollama ou vLLM. Oh-My-Codex: a camada de orquestração O oh-my-codex é um projeto relacionado mas distinto. Em vez de reescrever o Claude Code, ele funciona como uma camada de orquestração que pode usar o claw-code, o Claude Code original, ou qualquer outro coding agent como backend. Pense nele como um multiplexer de coding agents: você define regras de roteamento (qual agent para qual tipo de tarefa), políticas de fallback, e logging centralizado. É mais útil para quem quer comparar agents ou rodar múltiplos em paralelo do que para quem quer um substituto direto do Claude Code. Repo: ainda em fase early, menos de 5K stars, mas com uma arquitetura modular que faz sentido para cenários enterprise. 100K stars em 3 dias: o que isso significa Para colocar em perspectiva:Projeto Tempo para 100K starsclaw-code ~3 diasDeepSeek V3 ~14 diasllama.cpp ~6 mesesStable Diffusion (web UI) ~4 mesesLangChain ~8 mesesStars não são tudo — a maioria das 100K pessoas não vai contribuir código nem usar o projeto em produção. Mas o número diz algo sobre o estado da comunidade dev em 2026: a demanda por coding agents open-source é enorme, e a frustração com vendor lock-in é real. O vazamento funcionou como catalisador de algo que já estava latente. Antes do claw-code, projetos como Aider, Continue e o próprio OpenHands já tentavam construir coding agents open-source. Nenhum tinha a informação arquitetural que o vazamento forneceu. Implicações de IP: é legal? é safe? Aqui a coisa fica cinzenta. O código vazado: Ler código que foi inadvertidamente publicado em um pacote npm público é, na maioria das jurisdições, legal. O npm é uma plataforma pública. Source maps são arquivos técnicos padrão. Não houve invasão de sistema. Usar o código: Copiar trechos do código vazado em outro projeto é violação de copyright. O código da Anthropic é proprietário. Não importa que vazou por acidente — a propriedade intelectual não muda. Clean-room rewrite: O claw-code se posiciona como clean-room, mas o grau de separação real é questionável. Quando os mesmos desenvolvedores que leram o source original escrevem o rewrite, provar independência é difícil. A Anthropic pode argumentar que o conhecimento arquitetural específico constitui trade secret. Na prática: A Anthropic provavelmente não vai processar contribuidores individuais — o custo reputacional seria enorme. Mas pode enviar takedown notices, especialmente se encontrar trechos de código copiados diretamente. O risco é mais para quem usa em produção em empresas, onde um claim de IP pode gerar problemas reais. Segurança de instalar: O repositório claw-code tem código aberto — você pode auditar. Mas é um projeto de 3 dias. O sandboxing é mínimo comparado ao original. Executar bash commands via um agent com permissões fracas no seu sistema é risco real. Não rode em máquinas de produção. Use containers ou VMs dedicadas. Veredito: instalar ou esperar? Depende do cenário. Instale se: Você quer experimentar, entender como coding agents funcionam por dentro, ou precisa de suporte a LLMs que não sejam Claude. Use em repos pessoais, projetos de aprendizado, sandboxes isolados. Não instale se: Você precisa de algo production-ready, trabalha em empresa com política de IP, ou espera o mesmo nível de polish do Claude Code. O claw-code tem 3 dias de vida. Trate como alpha experimental. O que eu faria: Instalar num container descartável, testar com um modelo local via Ollama, e ler o código do agent loop. Independente de usar ou não o claw-code no dia a dia, entender a arquitetura que ele revela sobre coding agents é educação técnica de primeira linha. O vazamento do Claude Code não é só uma história de IP ou de source maps mal configurados. É um snapshot de como a Anthropic pensa sobre coding agents — e de como a comunidade open-source responde quando recebe um blueprint. A velocidade da resposta diz mais sobre 2026 do que sobre o projeto em si. Repo do claw-code: github.com/claw-code/claw-code. Vai lá, lê o source, e forma sua opinião. Só não roda com sudo.

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.

Agentic MLOps: como A2A e MCP estão substituindo DAGs do Airflow por equipes de agentes

Se você já manteve um pipeline de ML em produção com Airflow, sabe o que é acordar às 3h da manhã porque uma DAG de retraining falhou no step 14 de 23. O log diz Task failed: validation_step_3. Qual validation? De qual modelo? Com quais dados? Boa sorte. O artigo da InfoQ publicado em março de 2026 — "Architecting Agentic MLOps with A2A and MCP" — propõe algo que venho testando nos últimos meses: trocar DAGs rígidos por equipes de agentes que se comunicam via protocolos padronizados. Não é hype. É uma mudança de arquitetura com trade-offs reais que vale a pena entender. O problema com DAGs de MLOps Pipelines tradicionais de ML — Airflow, Prefect, Dagster — tratam MLOps como uma sequência linear: ingestão → feature engineering → treino → validação → deploy → monitoramento. Cada step é um nó no grafo. A lógica de decisão ("o modelo passou no threshold?", "precisa de rollback?") vira um emaranhado de BranchPythonOperator e XComs que ninguém quer debugar. O problema não é o Airflow. É que ML pipelines não são lineares. Validação pode exigir retreino com dados diferentes. Deploy pode precisar de canary progressivo com rollback automático. Monitoramento pode detectar drift e disparar retraining sem esperar o schedule. Tentar expressar isso como um DAG estático é como tentar desenhar um fluxograma para uma conversa — funciona no PowerPoint, quebra na realidade. A2A + MCP: os dois protocolos que habilitam a mudança Antes de entrar na arquitetura, vale alinhar os protocolos. Já cobri MCP em detalhe no post anterior, mas o resumo rápido:MCP (Model Context Protocol, Anthropic): protocolo de conexão entre agentes e ferramentas externas. O agente declara o que precisa, o MCP server expõe as capabilities. Pense nele como a interface entre o agente e o mundo — registries de modelo, buckets S3, APIs de monitoramento, o que for.A2A (Agent-to-Agent, Google): protocolo de comunicação entre agentes. Diferente do MCP que conecta agente→ferramenta, o A2A conecta agente→agente. Cada agente publica um Agent Card declarando suas capabilities, aceita Tasks via JSON-RPC, e pode negociar formatos de resposta. É o que permite que um Validation Agent peça ao Training Agent para retreinar com parâmetros específicos sem hardcodar essa lógica.A convergência dos dois é o que torna Agentic MLOps viável. MCP para acessar infraestrutura, A2A para coordenar decisões entre agentes. A arquitetura em camadas O paper da InfoQ propõe três agentes core: Orchestrator Agent O cérebro do pipeline. Recebe o trigger (schedule, webhook, drift alert) e decide o plano de execução. Diferente de uma DAG, o plano é dinâmico — o orchestrator avalia o contexto (qual modelo, qual dataset, qual o estado do último deploy) e monta a sequência em runtime. Validation Agent Responsável por qualidade do modelo. Roda suítes de teste, verifica drift de dados, compara métricas com baselines. O ponto-chave: via A2A, ele pode rejeitar um modelo e pedir retreino com instruções específicas ("accuracy caiu 3pp no segmento X, retreinar com oversampling desse segmento"). Em uma DAG, isso seria um loop com estado compartilhado que ninguém quer manter. Deployment Agent Gerencia canary, blue-green, rollback. Conecta via MCP ao Kubernetes, ao registry de modelos, ao Prometheus. Se o canary falha, comunica via A2A ao Orchestrator que decide o próximo passo — rollback, retreino, ou escalar para um humano. Hands-on: esqueleto de um pipeline agêntico Para materializar a ideia, montei um esqueleto usando CrewAI (que já suporta A2A e MCP nativamente desde a v0.8) com MCP servers para acessar MLflow e Kubernetes: # agentic_mlops_crew.yaml agents: orchestrator: role: "ML Pipeline Orchestrator" goal: "Coordinate model retraining and deployment" tools: - mcp_server: "mlflow-registry" # MCP: acessa model registry - mcp_server: "s3-datasets" # MCP: acessa datasets a2a_capabilities: - "plan_execution" - "escalation" validator: role: "Model Quality Gate" goal: "Validate model performance against baselines" tools: - mcp_server: "mlflow-registry" - mcp_server: "evidently-monitoring" # MCP: drift detection a2a_capabilities: - "validation_report" - "retrain_request" deployer: role: "Model Deployment Manager" goal: "Safe progressive rollout with automatic rollback" tools: - mcp_server: "k8s-serving" # MCP: KServe/Seldon - mcp_server: "prometheus-metrics" a2a_capabilities: - "canary_status" - "rollback_trigger"O fluxo em pseudo-código: # orchestrator recebe trigger trigger = await orchestrator.receive_task(event)# monta plano dinâmico baseado no contexto plan = orchestrator.plan( model=trigger.model_id, reason=trigger.reason, # "scheduled" | "drift_detected" | "manual" last_deployment=await mlflow.get_latest(trigger.model_id) )# treina e envia para validação via A2A model_artifact = await orchestrator.execute_training(plan) validation = await validator.validate( # A2A call model=model_artifact, baseline=plan.baseline_metrics, required_segments=plan.critical_segments )if validation.status == "REJECTED": # validator pode pedir retreino com instruções específicas plan = orchestrator.replan(validation.feedback) # loop controlado pelo orchestrator, não por uma DAG elif validation.status == "APPROVED": deployment = await deployer.canary_deploy( # A2A call model=model_artifact, traffic_pct=10, monitor_minutes=30 )A diferença fundamental: a lógica de decisão vive nos agentes, não no grafo. Quando o validator rejeita um modelo, ele não apenas retorna False — ele retorna contexto ("accuracy no segmento enterprise caiu 4pp, dataset de treino tem 12% menos amostras desse segmento vs. mês passado"). O orchestrator usa esse contexto para replanejar. Trade-offs reais: quando NÃO migrar Seria desonesto vender isso como solução universal. Aqui estão os trade-offs que encontrei:Aspecto DAG tradicional Agentic MLOpsLatência de decisão Milissegundos (if/else) Segundos (LLM inference por decisão)Custo Compute do step Compute + tokens de LLM por agenteDebuggability Log linear, fácil de rastrear Traces distribuídos, precisa de observabilidade sériaDeterminismo 100% reproduzível Decisões do LLM podem variar entre runsComplexidade inicial Alta (DAG), mas conhecida Alta (agentes), e poucos dominamO custo de LLM inference em cada decisão é real. Em um pipeline que roda 50 vezes por dia, cada chamada ao orchestrator com contexto de 4K tokens custa. Fiz a conta para um cenário com 3 agentes, 8 chamadas LLM por run, usando Claude Sonnet: **$2.40/dia** vs. zero de compute decisório no Airflow. Para pipelines de alta frequência, isso escala. E o determinismo é a objeção mais séria. Se o Validation Agent aprova um modelo na segunda-feira e rejeita o mesmo modelo na terça com os mesmos dados, você tem um problema de auditoria. A mitigação que funciona: usar LLMs com temperature 0 para decisões binárias e logar o chain-of-thought completo como artefato de compliance. Quando faz sentido migrar Na minha experiência, Agentic MLOps compensa quando:Seu pipeline tem lógica de decisão complexa — múltiplos caminhos de retreino, rollback condicional, validação por segmento Você já tem MCP servers para sua infra (MLflow, K8s, monitoramento) — montar isso do zero é um projeto separado A frequência do pipeline é baixa/média — diário ou semanal, não a cada 5 minutos Você precisa de feedback loops que hoje são manuais — o Validation Agent substitui aquele Slack alert que um engenheiro olha (ou não) antes de aprovar o deploySe seu pipeline é treino → valida threshold → deploy sem ramificações, Airflow resolve. Não complique. O que vem pela frente O paper da InfoQ menciona Agent Registries — um catálogo onde agentes de MLOps publicam suas capabilities via A2A e podem ser compostos dinamicamente. Imagine um marketplace interno onde o time de ML publica um "Feature Quality Agent" e o time de infra publica um "Cost Optimization Agent", e o orchestrator compõe os dois no mesmo pipeline sem ninguém escrever glue code. Ainda está cedo. A maioria das empresas não tem nem MCP servers para a infra de ML, muito menos agentes A2A em produção. Mas a direção é clara: MLOps vai de orquestração imperativa para coordenação declarativa. De DAGs para equipes. Se você já tem MCP rodando e está pensando no próximo passo, o repo de referência da InfoQ é um bom ponto de partida. E se você ainda está no Airflow com 47 BranchPythonOperators aninhados — bom, pelo menos agora sabe que existe alternativa.

NVIDIA Physical AI Data Factory Blueprint: o repo open-source que muda como você gera dados de treinamento para robótica

A NVIDIA fez algo raro em 16 de março: anunciou que vai abrir no GitHub a pipeline completa de geração de dados sintéticos para Physical AI. Não é um paper. Não é um blog post com diagramas bonitos e zero código. É o blueprint inteiro — geração, augmentation, curadoria e avaliação de dados de treinamento para robôs, veículos autônomos e vision agents. O Cosmos Evaluator já está no GitHub. O repo completo está prometido para este mês. Se você trabalha com robótica, sim-to-real transfer ou qualquer coisa que precisa de dados de treinamento que não existem no mundo real, isso muda a equação. Aqui está o que você precisa saber antes de clonar. A arquitetura: quatro estágios, um pipeline O Data Factory Blueprint é uma pipeline de quatro estágios construída sobre os Cosmos foundation models. Cada estágio resolve um problema específico na cadeia de dados para Physical AI. Estágio 1 — Geração via Cosmos World Models. Os Cosmos models são world models: dados um prompt de cena (posição de objetos, iluminação, física do ambiente), eles geram sequências de vídeo sintético fisicamente plausíveis. Não estamos falando de renders estáticos. São sequências temporais com gravidade, colisões, deformações — o tipo de dado que um robô precisa para aprender a interagir com o mundo real. A NVIDIA treinou esses models em datasets massivos de vídeo real, e o output é bom o suficiente para substituir horas de captura em ambiente controlado. Na prática, o fluxo começa com uma descrição de cena no Omniverse: from cosmos_data_factory import SceneGeneratorscene = SceneGenerator( environment="warehouse", objects=["pallet", "box_cardboard", "forklift"], physics_engine="PhysX", camera_config="multi_view_4x" )# Gera 1000 sequências de 5 segundos cada dataset = scene.generate( num_sequences=1000, duration_sec=5, variations=["lighting", "object_pose", "texture"] )Cada sequência vem com ground truth automático: bounding boxes, segmentation masks, depth maps, poses 6DoF dos objetos. É o tipo de anotação que custaria centenas de horas de trabalho manual. Estágio 2 — Augmentation com domain randomization. Dados sintéticos puros sofrem de um problema conhecido: o sim-to-real gap. O modelo aprende features que existem na simulação mas não no mundo real (iluminação perfeita demais, texturas uniformes demais, ausência de sujeira). O blueprint ataca isso com domain randomization agressiva — variação sistemática de texturas, iluminação, ruído de câmera, poses de objetos e condições ambientais. O pipeline aplica augmentation em camadas: augmentation: texture_randomization: true lighting_variations: ["dawn", "noon", "overcast", "fluorescent"] camera_noise: gaussian_std: 0.02 motion_blur_prob: 0.3 object_pose_jitter: translation_cm: 2.0 rotation_deg: 15.0 background_randomization: trueA ideia é que se o modelo funciona com todas essas variações, ele vai funcionar no mundo real. Na minha experiência com sim-to-real, isso é 80% verdade — os 20% restantes você resolve com fine-tuning em dados reais limitados. Estágio 3 — Curadoria automatizada. Nem todo dado sintético é útil. Sequências onde objetos atravessam paredes, colisões fisicamente impossíveis, cenas com oclusão total — tudo isso é lixo de treinamento. O pipeline inclui um módulo de curadoria que filtra automaticamente sequências com anomalias físicas e balanceia a distribuição do dataset por cenário, iluminação e complexidade de cena. Estágio 4 — Avaliação com Cosmos Evaluator. Esse é o componente que já está no GitHub (github.com/NVIDIA/cosmos-evaluator). O Evaluator mede a qualidade dos dados gerados em três dimensões: fidelidade física (os objetos se comportam como deveriam?), diversidade (o dataset cobre variação suficiente?) e utilidade downstream (treinar com esses dados melhora performance em tarefas reais?). # Já disponível no GitHub git clone https://github.com/NVIDIA/cosmos-evaluator.git cd cosmos-evaluator pip install -e .# Avaliar um dataset gerado cosmos-eval --dataset ./my_synthetic_data \ --metrics physical_fidelity diversity downstream_utility \ --report ./eval_report.jsonO report gera scores por métrica e um breakdown por cena. Na documentação atual, physical fidelity acima de 0.85 e diversity acima de 0.70 são os thresholds recomendados antes de usar o dataset para treinamento. Quem já está usando — e para quê A NVIDIA não está lançando isso no vácuo. Quatro empresas já operam com versões internas do pipeline:FieldAI — dados sintéticos para navegação autônoma em ambientes não estruturados (canteiros de obra, áreas de desastre) Uber — geração de cenários de edge case para veículos autônomos. O tipo de situação que acontece uma vez a cada 100 mil km e que você não pode esperar capturar em dados reais Skild AI — treinamento de foundation models para controle robótico generalista. Com o valuation de US$14B e foco em robot brains, dados sintéticos em escala são a base da tese Teradyne — robótica industrial, com foco em manipulação de objetos variados em linhas de montagemO padrão é claro: empresas que precisam de volumes massivos de dados anotados para robótica e não podem (ou não querem) coletá-los exclusivamente no mundo real. Os trade-offs que a NVIDIA não vai destacar no keynote Vamos ao que importa: onde isso não funciona tão bem quanto o marketing sugere. Custo de GPU. Gerar dados sintéticos com Cosmos world models não é grátis. Cada sequência de 5 segundos em resolução 1080p exige ~4 minutos em uma A100. Para um dataset de 100 mil sequências, são ~6.700 horas de GPU. A US$1,50/hora na AWS, isso dá ~US$10K só em compute de geração. Augmentation e avaliação adicionam mais 20-30%. O custo total de um dataset robusto fica na faixa de US$12-15K. É mais barato que coleta real em muitos cenários, mas não é trivial. Sim-to-real gap não desaparece. Domain randomization ajuda, mas não resolve 100% do problema. Na minha experiência, modelos treinados exclusivamente em dados sintéticos perdem 15-25% de performance quando transferidos para o mundo real sem fine-tuning adicional. O blueprint trata dados sintéticos como complemento de dados reais, não substituto completo — e essa é a abordagem correta. Dependência do Omniverse. O estágio de geração roda sobre o NVIDIA Omniverse. É uma plataforma poderosa, mas é lock-in. Se amanhã você quiser migrar a geração para outra engine (Unity, Unreal, ou um renderer custom), o pipeline vai precisar de adaptação significativa nos estágios 1 e 2. Os estágios 3 e 4 são mais agnósticos. Qualidade vs quantidade. Existe uma tentação de gerar milhões de sequências e jogar tudo no treinamento. O paper do Cosmos Evaluator mostra que datasets curados de 50K sequências consistentemente superam datasets brutos de 500K. Mais dados não é melhor dados. Como começar a testar hoje O Cosmos Evaluator já está disponível. Para o resto do pipeline, a NVIDIA prometeu abril — o que significa que pode aparecer a qualquer momento. Enquanto o repo completo não sai, o caminho pragmático:Clone o Cosmos Evaluator e rode com um dataset existente para entender as métricas Instale o Omniverse (versão gratuita para desenvolvedores) e familiarize-se com a geração de cenas sintéticas via Replicator Monitore o repo github.com/NVIDIA/physical-ai-data-factory — a naming convention segue o padrão dos outros repos da NVIDIA# Setup básico do Evaluator git clone https://github.com/NVIDIA/cosmos-evaluator.git cd cosmos-evaluator python -m venv .venv && source .venv/bin/activate pip install -e ".[dev]"# Rodar com dataset de exemplo cosmos-eval --dataset examples/sample_warehouse \ --metrics all \ --output-format jsonVeredito O Physical AI Data Factory Blueprint é o tipo de release que importa mais do que parece no dia do anúncio. Não é um modelo novo com benchmark recorde. É infraestrutura — a parte chata e essencial que determina se Physical AI sai do demo e entra na produção. A decisão de abrir o código é estratégica: a NVIDIA quer que o ecossistema inteiro gere dados no formato Cosmos, treine no stack NVIDIA e rode em hardware NVIDIA. Open-source aqui é growth strategy, não altruísmo. Mas isso não diminui a utilidade. Se você precisa de dados de treinamento para robótica, o custo de gerar internamente caiu de "projeto de pesquisa de 6 meses" para "pipeline configurável em semanas". Clone o Evaluator. Teste as métricas com seus dados. E quando o repo completo aparecer neste mês, você já vai saber o que medir.

HQQ — Half-Quadratic Quantization: quantize um 70B em 5 minutos sem calibration data

O repo dropbox/hqq não tem a contagem de stars do Ollama ou do Unsloth, mas resolve um problema que todo mundo que roda LLM local enfrenta: quantização rápida sem precisar de dataset de calibração. Quantizar um Llama-2-70B com GPTQ leva horas. Com HQQ, leva menos de 5 minutos. E a qualidade é competitiva. Já testei em alguns cenários e o trade-off é real: você troca um pouco de perplexidade por uma velocidade de quantização absurda e zero dependência de dados externos. Para quem itera rápido — testando modelos novos toda semana — isso muda o workflow. O que é HQQ e como funciona HQQ significa Half-Quadratic Quantization. A ideia central vem de otimização convexa: em vez de resolver o problema de quantização de uma vez (minimizar erro de reconstrução dos pesos), o HQQ divide em dois subproblemas alternados — um que otimiza os pesos quantizados e outro que otimiza um termo auxiliar. Cada subproblema tem solução fechada, então converge rápido sem precisar de gradiente. Na prática, isso significa:Sem calibration data. GPTQ e AWQ precisam de um dataset (geralmente WikiText ou C4) para calibrar a quantização. HQQ trabalha apenas com os pesos do modelo. Isso elimina um passo que pode introduzir bias dependendo do dataset escolhido. 50x mais rápido que GPTQ. O Llama-2-70B quantiza em ~5 minutos vs horas com GPTQ. Numa A100 40GB, testei um Qwen 3.5 72B em 4-bit e levou 7 minutos. Suporta 8, 4, 3, 2 e 1-bit. A maioria dos métodos foca em 4-bit. HQQ vai até 1-bit (com perda de qualidade significativa, claro).O repo oficial está em github.com/dropbox/hqq, mantido pela Mobius Labs (adquirida pelo Dropbox). Já está integrado ao Hugging Face Transformers nativamente. Benchmark: HQQ vs GPTQ vs AWQ vs GGUF Números de perplexidade no WikiText-2 (menor = melhor). Modelo base: Llama-2-70B.Método 4-bit PPL 3-bit PPL 2-bit PPL Tempo de quantizaçãoFP16 (baseline) 3.32 — — —GPTQ 3.47 4.12 7.89 ~4hAWQ 3.44 4.08 — ~2hHQQ 3.52 4.21 5.86 ~5minGGUF (Q4_K_M) 3.49 — — ~15minEm 4-bit, HQQ fica ~0.05-0.08 de perplexidade atrás de GPTQ/AWQ. É mensurável mas irrelevante na prática para a maioria dos use cases. A diferença real é o tempo: 5 minutos vs horas. Em 2-bit, HQQ brilha. GPTQ degrada severamente (7.89), enquanto HQQ mantém 5.86. E o dado mais impressionante: um Llama-2-70B quantizado em 2-bit via HQQ tem perplexidade menor que um Llama-2-13B em FP16 — usando memória comparável. Como instalar e usar Instalação # Versão estável pip install hqq# Com backend torchao (recomendado para inference rápida) pip install hqq[torchao]# Com backend Marlin (kernels otimizados para 4-bit) pip install hqq[marlin]# Bleeding edge pip install git+https://github.com/dropbox/hqq.gitQuantização via Hugging Face Transformers A forma mais simples — já integrado no HF: from transformers import AutoModelForCausalLM, HqqConfigquant_config = HqqConfig( nbits=4, # bits por peso (8, 4, 3, 2, 1) group_size=64, # tamanho do grupo de quantização axis=1, # eixo de quantização )model = AutoModelForCausalLM.from_pretrained( "Qwen/Qwen2.5-72B-Instruct", quantization_config=quant_config, device_map="auto", )Pronto. O modelo carrega já quantizado. Sem dataset, sem etapa separada de calibração. Para inference mais rápida Depois de quantizar, troque o backend para kernels fusionados: # torchao int4 — ~158 tok/s no Llama3-8B numa 4090 from hqq.utils.patching import prepare_for_inference prepare_for_inference(model, backend="torchao")# Marlin — até ~200 tok/s na mesma config prepare_for_inference(model, backend="marlin")Na minha 4090, um Llama 4 8B quantizado em 4-bit com HQQ + backend torchao roda a 155 tokens/segundo. Com Marlin, sobe para 192. Comparável ao que se consegue com GGUF no llama.cpp. Quando usar HQQ vs alternativasCenário Melhor escolha Por quêIteração rápida, testando modelos novos HQQ 5min vs horas. Sem dataset.Deploy em produção, máxima qualidade 4-bit AWQ ou GPTQ ~0.05 PPL melhor em 4-bitRodar local no llama.cpp/Ollama GGUF Ecossistema maduro, CPU+GPUQuantização 2-bit agressiva HQQ Melhor quality/compression nesse rangeFine-tuning com LoRA pós-quantização HQQ Compatível com PEFT out-of-the-boxModelos não-LLM (vision, audio) HQQ Model-agnostic, funciona em qualquer arquiteturaO ponto fraco do HQQ: em 4-bit puro, GPTQ e AWQ ainda ganham em perplexidade se você tem tempo e dados de calibração. Se você vai deployar um modelo em produção e ele vai rodar meses sem mudar, vale investir as horas extras do GPTQ. Se você está experimentando, comparando 3 modelos diferentes na mesma tarde, HQQ é imbatível. O ângulo custo: por que quantização importa no Brasil Uma A100 40GB na AWS São Paulo custa ~US$3.50/hora. Em real, passa de R$20/hora. Um Qwen 3.5 72B em FP16 precisa de pelo menos 2x A100 80GB (~US$8/hora). Quantizado em 4-bit com HQQ, cabe numa única A100 40GB. Conta rápida: se você roda inference 8h/dia, 22 dias/mês:FP16 (2x A100 80GB): ~US$1.408/mês HQQ 4-bit (1x A100 40GB): ~US$616/mêsSão ~US$800/mês de diferença. Em real, R$4.400. Por modelo. Por mês. Quantização não é otimização — é survival skill. Limitações reais Perplexidade em 4-bit. HQQ perde ~0.05-0.08 para GPTQ/AWQ. Para a maioria dos use cases isso não importa, mas se você está servindo um modelo para milhões de queries e cada fração de qualidade conta, a diferença existe. Ecossistema de inference. llama.cpp e Ollama usam GGUF. vLLM suporta GPTQ e AWQ nativamente. HQQ funciona melhor no ecossistema Hugging Face / PyTorch. Se seu stack de serving é vLLM, a integração com HQQ é possível mas não tão polida. 1-bit e 2-bit. HQQ suporta, mas a qualidade em 1-bit é ruim para uso prático. 2-bit é usável para modelos grandes (70B+), mas não para modelos menores onde cada bit conta mais. Veredito HQQ resolve um problema real de forma elegante: quantização rápida, sem dados, com qualidade competitiva. Não é o melhor em tudo — GPTQ/AWQ ganham em 4-bit puro, GGUF tem ecossistema maior. Mas para quem itera rápido, testa modelos toda semana e precisa de resultados em minutos, é a melhor opção disponível. O repo: github.com/dropbox/hqq. Docs no HF: huggingface.co/docs/transformers/quantization/hqq. Instala com pip install hqq, quantiza em 5 minutos, mede no seu use case. Se for melhor que o que você usa hoje, migra. Se não for, pelo menos você gastou 5 minutos testando, não 5 horas.

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.

MCP em produção — 97M downloads, design patterns do arxiv, e o que ainda quebra

Em novembro de 2024, quando a Anthropic lançou o Model Context Protocol, os SDKs tinham 2 milhões de downloads mensais e a maioria das pessoas nem sabia o que era. Eu lembro de olhar a spec e pensar "isso é interessante, mas quem vai adotar?". Dezesseis meses depois, são 97 milhões de downloads mensais e eu preciso admitir que estava errado. MCP virou o protocolo padrão de conexão entre LLMs e ferramentas externas. Claude, GPT-5.4, Gemini — todos suportam. São 5.800+ servers no ecossistema. 4.750% de crescimento. E agora saiu um paper no arxiv que finalmente documenta o que funciona e o que não funciona quando você tenta colocar isso em produção. O paper: arxiv 2603.13417 O paper "Bridging Protocol and Production: Design Patterns for Deploying AI Agents with MCP" é exatamente o tipo de documento que faltava. Não é um paper teórico sobre a beleza do protocolo — é um catálogo de design patterns extraídos de deploys reais de agentes usando MCP. Os patterns que mais me interessaram: 1. Gateway Pattern Em vez de cada agente se conectar diretamente a N MCP servers, você coloca um gateway na frente que gerencia conexões, auth e rate limiting. Parece óbvio, mas 90% dos tutoriais mostram conexão direta. Em produção com 10+ servers, sem gateway você vai ter um pesadelo de configuração e debug. 2. Tool Composition Pattern Combinar ferramentas de múltiplos MCP servers em uma única chamada do agente. O paper mostra que a melhor abordagem é composição declarativa — o agente declara o que precisa, e o orquestrador resolve quais servers chamar. Tentativas de composição imperativa (o agente decidindo a sequência de chamadas) são frágeis e difíceis de debugar. 3. Fallback Chain Pattern Quando um MCP server não responde, ter uma cadeia de fallback com servers alternativos. O paper documenta três estratégias: retry simples, fallback para server alternativo, e degradação graceful (retornar resultado parcial). Na prática, já implementei a terceira e é a que menos frustra o usuário final. 4. Context Window Management O pattern mais técnico e mais útil. MCP servers podem retornar quantidades enormes de contexto — um server de database pode devolver milhares de linhas. O paper propõe um context budget por tool call, onde o orquestrador limita o output de cada server para caber no context window do modelo. Sem isso, um server guloso come o contexto inteiro e o agente perde acesso às outras ferramentas. Hands-on: criando um MCP server Chega de teoria. Vamos montar um MCP server básico que expõe uma API de busca para um agente. TypeScript (SDK oficial) npm install @modelcontextprotocol/sdkimport { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js"; import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"; import { z } from "zod";const server = new McpServer({ name: "search-server", version: "1.0.0", });// Registra uma tool que o agente pode chamar server.tool( "search_docs", "Busca na documentação interna", { query: z.string().describe("Termo de busca"), limit: z.number().default(5).describe("Máximo de resultados"), }, async ({ query, limit }) => { // Aqui vai sua lógica real — Elasticsearch, pgvector, whatever const results = await searchIndex(query, limit); return { content: [ { type: "text", text: JSON.stringify(results, null, 2), }, ], }; } );const transport = new StdioServerTransport(); await server.connect(transport);Python (SDK via PyPI) pip install mcpfrom mcp.server import Server from mcp.server.stdio import stdio_server from mcp.types import TextContent, Toolserver = Server("search-server")@server.tool() async def search_docs(query: str, limit: int = 5) -> list[TextContent]: """Busca na documentação interna.""" results = await search_index(query, limit) return [TextContent(type="text", text=str(results))]async def main(): async with stdio_server() as (read, write): await server.run(read, write, server.create_initialization_options())if __name__ == "__main__": import asyncio asyncio.run(main())Ambos os SDKs usam stdio como transport padrão — o client spawna o server como processo filho e se comunica via stdin/stdout. Isso é simples para desenvolvimento, mas em produção você vai querer HTTP/SSE (Server-Sent Events), que ambos os SDKs já suportam. Conectando no Claude Desktop (teste rápido) Edite o claude_desktop_config.json: { "mcpServers": { "search-docs": { "command": "node", "args": ["./dist/server.js"] } } }Reinicie o Claude Desktop e a tool search_docs aparece disponível. O agente pode invocá-la naturalmente durante a conversa. O que ainda quebra em produção Aqui é onde eu troco o chapéu de entusiasta pelo de engenheiro cansado. MCP em produção tem problemas reais que o hype esconde. Auth cross-server O maior gap. Cada MCP server gerencia sua própria autenticação. Se você tem 15 servers, o usuário precisa autenticar em cada um separadamente. Não existe um padrão de SSO ou token federation nativo no protocolo. O blog da WorkOS documenta bem esse problema e propõe soluções, mas nenhuma é oficial ainda. Na prática, o que eu faço é injetar tokens via variáveis de ambiente no momento do spawn do server. Funciona, mas é um hack — e não escala para cenários onde o token precisa ser refreshed durante a sessão. Session state MCP sessions são stateless por padrão. Se o server crashar e reiniciar, todo o contexto acumulado se perde. O paper do arxiv propõe um State Checkpoint Pattern, mas ninguém implementou isso nos SDKs oficiais ainda. Se seu agente depende de estado acumulado ao longo de uma conversa (e a maioria depende), você precisa implementar persistência por conta própria. Streaming O suporte a streaming de respostas longas é inconsistente entre implementações. O SDK TypeScript lida bem com SSE, mas o SDK Python tem edge cases com backpressure que podem causar memory leaks em sessões longas. Já perdi horas debugando isso. Observabilidade Não existe um padrão de tracing entre client e servers MCP. Se uma cadeia de 5 tool calls falha, boa sorte descobrindo onde foi. Eu adaptei OpenTelemetry manualmente nos meus servers, mas deveria ser built-in. Roadmap 2026: o que vem por aí O The New Stack publicou o roadmap que a comunidade está trabalhando. Os pontos mais relevantes:Auth padronizado: OAuth 2.1 como padrão de autenticação para MCP servers. Finalmente. Streamable HTTP transport: substituição do SSE por um transport mais robusto para produção. Registry protocol: um padrão para discovery de MCP servers — tipo um DNS para ferramentas de agentes. Elicitation: capacidade do server pedir informação adicional ao usuário via o client, sem interromper o fluxo do agente.Se o auth padronizado e o registry saírem no Q2 como prometido, MCP vira um protocolo enterprise-ready de verdade. Até lá, prepare-se para escrever bastante glue code. Veredito MCP não é mais experimental. 97 milhões de downloads mensais e suporte universal dos providers transformaram o protocolo em padrão de facto. O paper arxiv 2603.13417 é leitura obrigatória para quem está deployando agentes — os design patterns economizam semanas de tentativa e erro. Mas "padrão de facto" não significa "maduro". Auth, state e observabilidade são problemas reais que você vai enfrentar. O roadmap promete resolver boa parte disso em 2026, e a velocidade da comunidade (de 2M para 97M downloads em 16 meses) me dá alguma confiança. Se você ainda não tem MCP servers no seu stack de agentes, comece com o Gateway Pattern e um server simples como o exemplo acima. Mantenha o escopo pequeno, instrumente tudo, e prepare-se para reescrever o auth quando o padrão OAuth 2.1 sair. Paper: arxiv.org/abs/2603.13417. SDK TypeScript: @modelcontextprotocol/sdk. SDK Python: mcp no PyPI. Vai lá, monta um server, quebra em produção, e me conta o que deu errado.

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

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.

Nemotron Coalition — NVIDIA, Mistral, Perplexity e Cursor juntos por modelos abertos (ou quase)

A NVIDIA decidiu que não basta fabricar as GPUs onde os modelos rodam — agora quer organizar quem constrói os modelos. A Nemotron Coalition reúne um lineup que, no papel, impressiona: Reflection AI, Mistral AI, Perplexity, Cursor, LangChain e Black Forest Labs. O objetivo declarado: desenvolver modelos frontier abertos. A pergunta que importa: abertos de verdade ou "abertos"? Quem está na mesa Vamos aos membros e o que cada um traz:Membro O que faz Valuation / RelevânciaNVIDIA Infraestrutura (GPUs, CUDA, NeMo) Líder do ecossistemaReflection AI Modelos frontier, fundada por ex-DeepMind $25B valuationMistral AI Modelos abertos (Mistral, Mixtral, Voxtral) Líder europeu em open-weightsPerplexity Search AI Referência em RAG em produçãoCursor AI code editor ~1M+ devs ativosLangChain Framework de orquestração LLM Padrão de facto em AI appsBlack Forest Labs Modelos de geração de imagem (FLUX) FLUX.1 é o Stable Diffusion killerA Reflection AI é o nome que mais chama atenção. Fundada por ex-líderes do DeepMind, com $25 bilhões de valuation, é a aposta mais cara da coalizão. O fato de ser membro fundador sugere que vai contribuir com capacidade significativa de treinamento de modelos. O que já existe: Nemotron 3 Super A NVIDIA não entrou nessa conversa de mãos vazias. O Nemotron 3 Super já está disponível:120B de parâmetros 60.47% no SWE-Bench Verified — para contexto, isso é enterprise-grade para coding Foco em coding e raciocínio para ambientes corporativos Treinado no stack NeMo da NVIDIAO SWE-Bench Verified é o benchmark que mais importa se você está avaliando modelos para coding em produção. 60.47% coloca o Nemotron 3 Super no mesmo patamar de modelos como Claude 3.5 Sonnet e GPT-4o nas tarefas que esse benchmark mede. Não é state-of-the-art, mas é competitivo — e com weights disponíveis. NemoClaw: deployment enterprise em TypeScript O outro artefato concreto é o NemoClaw — um plugin TypeScript para deployment enterprise do OpenClaw (4.200 stars). A ideia é reduzir a fricção entre "modelo treinado" e "modelo em produção" para equipes enterprise. # Instalação do NemoClaw npm install @nvidia/nemoclaw# Configuração básica npx nemoclaw init --model nemotron-3-super-120bimport { NemoClaw } from '@nvidia/nemoclaw';const deployment = new NemoClaw({ model: 'nemotron-3-super-120b', quantization: 'int8', maxConcurrency: 32, });const result = await deployment.inference({ prompt: "Refactor this function to use async/await", maxTokens: 2048, });Se funciona tão bem quanto o marketing sugere, ainda preciso testar mais a fundo. Mas a direção é certa: abstrair a complexidade de deployment de modelos grandes para que times enterprise não precisem de um PhD em MLOps para colocar um modelo em produção. A pergunta incômoda: open-source ou open-weights? Aqui é onde eu coloco o chapéu de cético. "Open" no mundo de AI em 2026 virou um espectro, não um binário. Vamos olhar o histórico dos próprios membros da coalizão:Membro Licença típica dos modelos Genuinamente open?Mistral Apache 2.0 (alguns), CC BY NC (Voxtral) Depende do modeloNVIDIA Custom NVIDIA license Não (source-available)Black Forest Labs FLUX.1 [dev]: custom non-commercial Não para uso comercialReflection AI Ainda não lançou modelos TBDPerplexity Não treina modelos base N/ACursor Não treina modelos base N/AQuando a Mistral lança o Mistral 7B sob Apache 2.0, isso é open-source. Quando lança o Voxtral sob CC BY NC 4.0, é open-weights para pesquisa. Quando a NVIDIA distribui o Nemotron sob licença custom, é "dê uma olhada mas leia as letras miúdas". A coalizão fala em "modelos frontier abertos". Mas aberto com qual licença? Apache 2.0? MIT? Ou mais uma variação de "weights disponíveis, licença restritiva, uso comercial só via API"? Essa distinção importa. Para pesquisadores e hobbyists, open-weights é suficiente. Para empresas que querem fine-tunar e deployar on-premise, a licença é tudo. E até agora, nenhum anúncio da coalizão especificou licenças dos modelos futuros. O contexto geopolítico: DeepSeek e a corrida por modelos abertos A Nemotron Coalition é explicitamente posicionada como resposta ocidental ao DeepSeek e ao ecossistema de AI aberta da China. Os números dão contexto:4.3 milhões de repos relacionados a AI no GitHub 178% de crescimento YoY em projetos de LLM Ollama: 162K stars — a forma como a maioria dos devs roda modelos localmente Dify: 130K stars — plataforma de AI apps obra/superpowers: 92.1K starsO DeepSeek abriu modelos competitivos com licenças permissivas e forçou o Ocidente a responder. A lógica geopolítica é: se a China lidera em modelos abertos, a infraestrutura de AI global passa a depender de modelos chineses. A coalizão é a tentativa de evitar isso. Mas aqui está o paradoxo: para competir com DeepSeek em abertura, a coalizão precisa ser tão aberta quanto o DeepSeek. E o DeepSeek distribuiu modelos sob MIT License. Se a Nemotron Coalition entregar modelos sob licenças restritivas, o argumento geopolítico cai por terra — devs vão usar o que funciona e é livre, independente de onde vem. O que isso significa para quem constrói com esses modelos Na prática, três cenários possíveis: Cenário otimista: A coalizão entrega modelos frontier com licença Apache 2.0 ou MIT, com qualidade competitiva com GPT-4o e Claude Opus. NVIDIA subsidia o treinamento com hardware, membros contribuem expertise. O ecossistema open ganha um boost real. Cenário realista: Os modelos saem com licenças custom que permitem uso comercial com restrições. Algo tipo "pode usar, não pode competir conosco, precisa atribuir". Útil para a maioria dos casos, mas não é genuinamente open. Os melhores checkpoints ficam atrás de APIs pagas. Cenário cínico: A coalizão vira um veículo de marketing para NVIDIA vender mais H200s e para os membros ganharem visibilidade. Os modelos "abertos" são mid-tier e os frontier de verdade ficam proprietários. Basicamente o que já temos hoje, com um logo bonito. Na minha experiência, a realidade tende a ficar entre o realista e o cínico. E tudo bem — mesmo modelos mid-tier abertos têm valor. Mas é importante calibrar expectativas. O que fazer agora Se você está construindo produtos sobre modelos open:Monitore os releases da coalizão — especialmente as licenças, não só os benchmarks Teste o Nemotron 3 Super se seu caso de uso é coding enterprise — 60.47% no SWE-Bench é relevante Não aposte tudo num único ecossistema — a coalizão pode entregar ou não, tenha abstrações que permitam trocar de modelo Continue acompanhando DeepSeek — a competição é boa para devs independente de quem ganhe# Testar Nemotron 3 Super localmente via Ollama ollama pull nemotron:120b ollama run nemotron:120b "Explain the trade-offs of microservices vs monolith"Limitações e o que não sabemos Para ser transparente sobre os gaps:Nenhum modelo da coalizão foi lançado ainda — tudo é promessa e roadmap Licenças dos futuros modelos não foram definidas publicamente A dinâmica entre membros (que são competidores entre si em vários mercados) pode gerar atrito O funding model não é claro — quem paga o compute? Só a NVIDIA? A Reflection AI, apesar do valuation de $25B, ainda não entregou um modelo públicoVeredito A Nemotron Coalition tem o potencial de ser um marco para modelos abertos no Ocidente. Ou pode ser mais uma aliança corporativa que produz whitepapers e press releases. O histórico de coalizões tech sugere cautela. O que vai definir o sucesso ou fracasso é simples: qual licença vai estar no primeiro modelo frontier que lançarem? Se for Apache 2.0 ou MIT, eu passo a levar a sério. Se for mais uma licença custom com restrições, é marketing. Enquanto isso, o DeepSeek continua lançando modelos competitivos sob MIT. A competição por abertura é a melhor coisa que aconteceu para desenvolvedores. Independente de quem ganhe a corrida geopolítica, quem ganha de verdade é quem roda ollama pull e tem um modelo frontier para usar sem pedir permissão. Vou monitorar e reportar conforme os releases aconteçam. Por enquanto, é tudo promessa — e promessa em tech tem shelf life curto.

OpenAI comprou o Astral — o que acontece com uv, Ruff e ty?

Na quarta-feira passada, 19 de março, a OpenAI anunciou a aquisição do Astral. Se o nome não te diz nada, as ferramentas dizem: uv, Ruff e ty. Ou seja — o package manager que substituiu pip+poetry no meu workflow, o linter que matou flake8+isort na minha CI e o type checker que está sendo construído para competir com mypy. Tudo isso agora pertence à OpenAI. Eu uso uv e Ruff diariamente. Em todo projeto. Em toda CI. Quando vi a notícia, minha reação foi a mesma de meio milhão de devs Python: "e agora?" O que a OpenAI comprou O Astral criou três ferramentas que viraram infraestrutura do ecossistema Python moderno:uv — Package manager e project manager em Rust. Substituição drop-in para pip, pip-tools, poetry e virtualenv. Ordens de magnitude mais rápido. Ruff — Linter e formatter em Rust. Implementa regras de flake8, isort, pyupgrade e mais. 10-100x mais rápido que as alternativas em Python. ty — Type checker em Rust. Ainda em desenvolvimento, mas já promete ser uma alternativa séria ao mypy.Essas ferramentas são usadas por milhões de desenvolvedores Python. Não é exagero — é o novo default. Se você criou um projeto Python nos últimos 12 meses, provavelmente tem pelo menos Ruff no seu pyproject.toml. O que a OpenAI diz O comunicado oficial promete:Manter todos os projetos open-source Continuar o desenvolvimento com a mesma equipe Integrar o time do Astral com o Codex — o braço de coding da OpenAIA integração com Codex é a parte que importa. A tese é clara: a OpenAI quer que seu AI coding assistant entenda profundamente o ecossistema Python. Quem melhor para isso do que o time que construiu as ferramentas de tooling mais rápidas do ecossistema? O que a história ensina Toda vez que big tech compra um projeto open-source, a promessa é a mesma: "vamos manter aberto, vamos investir mais, a comunidade só ganha." A prática costuma ser diferente. Casos recentes:Projeto Comprador/Evento Promessa O que aconteceuRedis Redis Labs → Redis Inc "Sempre open-source" Mudou de BSD para RSALv2 + SSPL em 2024Terraform HashiCorp "Open-source core" Mudou de MPL para BSL em 2023Docker Mirantis (partes) Continuidade Docker Desktop virou pago para empresasMySQL Sun → Oracle Manter GPL Fork MariaDB nasceu por desconfiançaA OpenAI não precisa mudar a licença amanhã para causar dano. Basta priorizar features que servem ao Codex sobre features que a comunidade precisa. Basta reduzir a cadência de releases. Basta deixar PRs da comunidade apodrecendo no backlog. Simon Willison escreveu uma análise detalhada que vale a leitura completa. O ponto central dele: a OpenAI tem um histórico de promessas sobre "openness" que não se sustentaram. O próprio nome da empresa é uma ironia a essa altura. O padrão de aquisições da OpenAI Astral não é um caso isolado. A OpenAI também adquiriu recentemente:Promptfoo — ferramenta open-source de security testing para AI, sendo integrada ao OpenAI Frontier Windsurf — editor de código (competidor do Cursor), comprado antes do AstralNo total: 17 aquisições em 3 anos, 6 só em 2026. A OpenAI está comprando a stack de desenvolvimento de AI de ponta a ponta: editor (Windsurf), toolchain Python (Astral), segurança (Promptfoo), modelos (Codex). Quando uma empresa compra a ferramenta que você usa para escrever código, a ferramenta que você usa para testar código E a ferramenta que você usa para gerenciar dependências — isso não é diversificação. É verticalização. O que muda na prática (hoje) Resposta honesta: nada, por enquanto. As ferramentas continuam open-source, as licenças não mudaram, os repos estão ativos. Ruff v0.9.x está saindo normalmente. O uv recebeu update essa semana. O que você deve fazer agora: # Verificar suas versões atuais uv --version ruff --version# Continuar usando normalmente # Não troque tooling por paranoiaNão entre em pânico. Não migre de volta para pip+flake8 por medo. Mas faça algo que todo engenheiro deveria fazer de qualquer forma: mapeie alternativas. Alternativas para monitorar Se um dia a licença mudar ou o desenvolvimento desacelerar:Ferramenta Astral Alternativa Statusuv pdm, hatch, pip-tools Ativos, mas significativamente mais lentosRuff flake8 + isort + black Funcionais, mais lentos, mais configty mypy, pyright Maduros e mantidos por Python e Microsoft respectivamenteA realidade inconveniente: uv e Ruff são tão superiores às alternativas que a comunidade criou uma dependência difícil de reverter. Esse é exatamente o tipo de cenário que torna aquisições como essa preocupantes. A licença como canário na mina O indicador número um para monitorar é a licença. Ruff e uv são MIT License hoje. Se um dia aparecer um commit mudando para BSL, SSPL ou qualquer variante "source-available-mas-não-open-source", é hora de forkar. Outros sinais de alerta:CLA (Contributor License Agreement) mais restritivo que o atual PRs da comunidade com tempo de review crescente Features exclusivas para integração com Codex/OpenAI que não beneficiam o uso standalone Redução de releases sem explicação técnicaConfigure um watch nos repos e monitore changelogs: # Watch nos repos relevantes # github.com/astral-sh/uv # github.com/astral-sh/ruff # github.com/astral-sh/ty# RSS dos releases # https://github.com/astral-sh/ruff/releases.atom # https://github.com/astral-sh/uv/releases.atomO que a JetBrains pensa Detalhe relevante: a JetBrains, no blog do PyCharm, publicou análise sobre a aquisição. O tom foi diplomático mas a mensagem nas entrelinhas era clara — eles estão preparando integração nativa com Ruff e uv no PyCharm independente de qualquer mudança que a OpenAI faça. Ou seja: até as IDEs estão se protegendo. Veredito Eu vou continuar usando uv e Ruff amanhã. São as melhores ferramentas para o job e não existe alternativa equivalente hoje. Mas vou fazer isso com um olho nos changelogs e outro nas licenças. A OpenAI prometeu manter tudo aberto. Talvez cumpra. Mas na minha experiência, quando uma empresa de $300 bilhões compra uma ferramenta de developer tooling, não é porque ama open-source — é porque a ferramenta serve à estratégia de produto. E quando a estratégia mudar, o compromisso com "open" muda junto. Ceticismo não é paranoia. É engenharia de risco. O melhor que a comunidade Python pode fazer agora é o que sempre fez: manter forks viáveis, contribuir com os projetos enquanto são abertos e não colocar todos os ovos na mesma cesta. A história já mostrou o roteiro — só não sabemos em qual ato estamos.

Voxtral TTS 4B — hands-on com o TTS open-source da Mistral que roda em smartphone

Na quarta-feira, a Mistral soltou o Voxtral TTS 4B e eu passei as últimas 48 horas rodando ele em tudo que tinha à mão — laptop com RTX 3060, um Pixel 8 e, por curiosidade mórbida, num Raspberry Pi 5. O resultado curto: é o primeiro modelo TTS open-weights que eu considero competitivo com ElevenLabs de verdade. O resultado longo: tem um asterisco do tamanho de um caminhão na licença. O que é o Voxtral TTS 4B Modelo text-to-speech com 4 bilhões de parâmetros, lançado pela Mistral AI em 26 de março de 2026. Os pesos estão no HuggingFace sob licença CC BY NC 4.0 (já volto nisso). Suporta 9 idiomas: inglês, francês, alemão, espanhol, holandês, português, italiano, hindi e árabe. Os números que importam:Métrica Voxtral 4B ElevenLabs Flash v2.5 ElevenLabs v3 OpenAI TTSTime-to-first-audio 90ms ~120ms ~200ms ~150msNaturalidade (human eval) Superior baseline Paridade —Parâmetros 4B Proprietário Proprietário ProprietárioOpen weights Sim Não Não NãoIdiomas 9 29 29 57Emotion steering Sim Sim Sim LimitadoAquele 90ms de time-to-first-audio é o número que me fez parar o que estava fazendo. Para contexto: 90ms é abaixo do limiar de percepção humana de latência em conversação (~150ms). Isso significa TTS em tempo real, em dispositivos edge, sem precisar de roundtrip para cloud. Como rodar localmente Via HuggingFace Transformers pip install transformers torch acceleratefrom transformers import AutoModelForTextToWaveform, AutoTokenizer import soundfile as sfmodel_id = "mistralai/Voxtral-4B-TTS-2603" model = AutoModelForTextToWaveform.from_pretrained( model_id, torch_dtype="auto", device_map="auto", ) tokenizer = AutoTokenizer.from_pretrained(model_id)text = "Olá, esse é o Voxtral rodando localmente no meu laptop." inputs = tokenizer(text, return_tensors="pt").to(model.device)with torch.no_grad(): audio = model.generate(**inputs)sf.write("output.wav", audio.cpu().numpy(), samplerate=24000)No meu laptop com RTX 3060 (12GB VRAM), o modelo carregou em ~8 segundos e gerou áudio para uma frase de 15 palavras em 112ms. Em fp16, o consumo de VRAM ficou em ~7.5GB. Cabe tranquilo em qualquer GPU moderna. Via API da Mistral (para produção) Se a licença NC te travou (como vai travar a maioria), a Mistral oferece o modelo via API a US$0.016 por 1.000 caracteres. Para comparação:Serviço Preço por 1K charsVoxtral API US$0.016ElevenLabs (Scale) ~US$0.024OpenAI TTS ~US$0.030Deepgram Aura ~US$0.015Competitivo, mas não é o mais barato. Deepgram fica centavos abaixo. A diferença está na qualidade — e nos human evals, o Voxtral empatou com ElevenLabs v3, que é a referência do mercado. from mistralai import Mistralclient = Mistral(api_key="sua-chave-aqui")response = client.audio.speech.create( model="voxtral-4b-tts", input="Texto para sintetizar em português brasileiro.", voice="alloy", response_format="wav", )with open("output.wav", "wb") as f: f.write(response.content)Qualidade: o que dizem os human evals A Mistral publicou resultados de avaliação humana comparando Voxtral com ElevenLabs. Os avaliadores classificaram naturalidade, clareza e expressividade em escala MOS (Mean Opinion Score):Voxtral 4B vs ElevenLabs Flash v2.5: Voxtral superior em naturalidade e expressividade Voxtral 4B vs ElevenLabs v3: paridade — nenhuma diferença estatisticamente significativaEu fiz meus próprios testes informais em português. O Voxtral acerta bem a prosódia e não tem aquele "sotaque de robô" que modelos menores costumam ter. Onde ele ainda derrapa: frases muito longas (acima de ~200 palavras) começam a perder entonação natural no final. E nomes próprios em português com acentuação complexa às vezes saem truncados. O emotion steering funciona razoavelmente bem. Adicionando tags de emoção ao prompt, consegui gerar variações de tom (entusiasmado, sério, calmo) que soavam distintas e não caricatas. Não é nível voice actor, mas é muito acima do que TTS open-source entregava até agora. A licença: o elefante na sala CC BY NC 4.0. Non-commercial. Isso significa: você pode baixar, rodar, experimentar, usar em projetos pessoais e pesquisa. Não pode colocar num produto que gera receita sem pagar pela API. Na minha opinião, isso é simultaneamente compreensível e frustrante. Compreensível porque a Mistral precisa monetizar — modelo TTS de qualidade custa caro para treinar. Frustrante porque o valor real de open weights é justamente permitir deployment on-premise em produção. Com NC, o open-weights vira basicamente uma demo para convencer você a assinar a API. Compare com alternativas genuinamente open: o Coqui TTS (Mozilla Public License) e o Piper (MIT) são 100% livres para uso comercial. Mas nenhum chega perto da qualidade do Voxtral. É o tradeoff clássico. O que isso significa para edge AI O ponto que mais me anima não é o Voxtral em si — é o que ele representa. Um modelo TTS de 4B parâmetros rodando com 90ms de latência em smartphone prova que:TTS de qualidade não precisa de cloud. Se a Mistral conseguiu com 4B, é questão de tempo até um modelo Apache 2.0 aparecer com qualidade similar. Edge AI saiu do PowerPoint. Não é mais "em breve será possível rodar modelos no device". Já é possível. Agora. O gargalo mudou. Não é mais compute — é licença. O hardware já é capaz. Quem destravar o modelo certo com a licença certa leva o mercado.Limitações e trade-offs Para ser honesto com quem está avaliando:Licença NC bloqueia uso comercial direto com os pesos abertos 9 idiomas é bom, mas ElevenLabs suporta 29 e OpenAI 57. Se você precisa de coreano ou japonês, não é aqui Voice cloning não está incluído no release open-weights. ElevenLabs e Deepgram oferecem isso out-of-the-box Frases longas perdem naturalidade — mantenha os chunks abaixo de 150 palavras para melhor resultado Documentação ainda é mínima — o model card no HuggingFace é o que temVeredito O Voxtral TTS 4B é o melhor modelo TTS open-weights que existe hoje, ponto. A qualidade compete com ElevenLabs, a latência é best-in-class e o fato de rodar em smartphone abre portas que cloud-only não abre. Mas a licença NC é uma limitação real para quem quer usar em produção. Se seu caso de uso é comercial, você vai acabar na API — que é boa e competitiva em preço, mas aí você perdeu a vantagem do "open" e está comparando API com API. Para pesquisa, prototipagem e projetos pessoais: vai lá e roda. Os weights estão em huggingface.co/mistralai/Voxtral-4B-TTS-2603. Para produção: faça as contas entre a API da Mistral, ElevenLabs e Deepgram. O melhor deal depende do seu volume e dos idiomas que precisa. O que eu quero mesmo é ver alguém treinar um modelo dessa qualidade com licença Apache 2.0. Aí sim o jogo muda de verdade.

ICLR 2026 é no Rio: 19.797 submissions, 5.300 aceitos — os 7 papers que você precisa ler antes de abril

Três números: 19.797 submissions. 5.300+ aceitos. Taxa de aceitação para oral: ~1.1%. Se você achou que o ICLR já era grande, 2026 redefiniu a escala. E pela primeira vez na história, a conferência acontece na América Latina — Riocentro, Rio de Janeiro, 23 a 27 de abril. Eu passei as últimas duas semanas filtrando os aceitos. Critério simples: paper tem que ter código disponível (ou prometido), benchmark reproduzível e resolver um problema que eu consiga usar em produção nos próximos 6 meses. Sobraram 7. O panorama antes dos papers A taxa de aceitação geral ficou em 28.18% — a mais baixa em três anos. A média de score caiu para 5.39 (contra 6.0+ em 2025). Isso não significa que os papers pioraram. Significa que a barra subiu e que o volume de submissions inflou com trabalho incremental. O sinal útil está mais diluído, e filtrar ficou mais importante do que nunca. As tendências dominantes nos aceitos:Post-training scaling — o treino não termina no pre-training Quantização — rodar modelos grandes em hardware menor Vision-Language-Action (VLA) — modelos que veem, entendem e agem Reward modeling — alinhar LLMs sem supervisão humana bruta Scaling laws para MoE — prever custo antes de gastar GPUDito isso, vamos aos papers. 1. SliderQuant: quantização pós-treino que respeita a heterogeneidade das camadas Problema: métodos de quantização pós-treino (PTQ) aplicam a mesma estratégia para todas as camadas. Mas camadas diferentes têm distribuições diferentes — forçar uniformidade destrói qualidade em bit-widths agressivos (3-4 bits). O que faz: SliderQuant trata cada camada como um problema independente de quantização. O framework seleciona automaticamente o design de quantização ideal por camada, combinando weight-only e weight-activation quantization. Resultado-chave: supera métodos existentes (GPTQ, AWQ) em Llama 3, Qwen 2.5 e DeepSeek-R1 distilled — incluindo modelos MoE. Em W4A4 no Llama-3-70B, a perplexidade cai 0.3 pontos comparado ao melhor baseline anterior. Por que importa: se você roda modelos em GPUs consumer ou precisa espremer inferência em edge, esse paper é leitura obrigatória. Quantização não é mais one-size-fits-all.Paper: OpenReview2. Joint MoE Scaling Laws: MoE pode ser mais eficiente em memória que modelos densos Problema: todo mundo assume que MoE gasta mais memória que dense models porque tem mais parâmetros totais. Mas ninguém tinha scaling laws que modelassem a relação entre parâmetros ativos, número de experts e dataset size juntos. O que faz: os autores treinaram 280+ experimentos (até 2.7B ativos, 5B totais) e derivaram scaling laws conjuntas para dense e MoE sob budgets fixos de memória e compute. Resultado-chave: MoE pode ser mais eficiente em memória que dense models para o mesmo nível de performance. Isso inverte a sabedoria convencional. Por que importa: se você está decidindo a arquitetura do seu próximo modelo ou sizing infra para serving, esses scaling laws são a planilha que faltava.Paper: arXiv 2502.05172 Dados: HuggingFace3. On-Policy Distillation: o student aprende com os próprios erros Problema: distillation tradicional treina o student com dados gerados pelo teacher. Mas na hora da inferência, o student gera seus próprios tokens — e o distribution shift entre treino e inferência é fatal para modelos autoregressivos. O que faz: GKD (Generalized Knowledge Distillation) treina o student nas suas próprias sequências geradas, usando feedback do teacher sobre essas sequências. O student literalmente aprende dos seus erros, não dos acertos do teacher. Resultado-chave: integração direta com RLHF — você combina distillation e alignment num pipeline só. Performance consistentemente superior a distillation off-policy em tasks de geração longa. Por que importa: se você está destilando um modelo grande para produção, trocar off-policy por on-policy é low-hanging fruit com ganho real.Paper: OpenReview | arXiv4. Precision-Aware Scaling Laws: prevendo a perda antes de quantizar Problema: você treina um modelo em FP16, quantiza para INT4 e reza para a qualidade não cair muito. Não existe uma forma principled de prever quanto vai perder. O que faz: propõe que treinar em precisão baixa reduz a "contagem efetiva de parâmetros" do modelo. Com isso, deriva scaling laws que preveem a perda adicional tanto de treino em low precision quanto de quantização pós-treino. Resultado-chave: para inferência, a degradação por PTQ aumenta conforme o modelo é treinado com mais dados. Para treino, modelos maiores em precisão mais baixa podem ser compute-optimal. Ou seja: existe um sweet spot e agora dá para calcular. Por que importa: antes de alocar milhões em compute, você pode simular cenários de precisão e prever o trade-off. Isso é engenharia, não chute.Paper: ICLR 2026 proceedings5. MedAgentGym: 72K tasks para treinar agentes de IA biomédica Problema: agentes LLM para biomedicina existem, mas não há um environment padronizado para treiná-los e compará-los. O que faz: cria um ambiente interativo com 72.413 instâncias de tarefas em 129 categorias, derivadas de 12 cenários biomédicos reais. Benchmarkou 29 LLMs e aplicou RL offline e online. Resultado-chave: RL online atingiu +45.28% de ganho sobre o baseline. A diferença entre modelos comerciais e open-source é brutal — e quantificada. Por que importa: se você trabalha com IA em saúde ou quer treinar agentes especializados, esse é o gym que faltava. Environment padronizado = benchmarks comparáveis = progresso mensurável.Paper: ICLR 2026 proceedings6. PAPL: diffusion language models que sabem onde limpar primeiro Problema: diffusion language models geram texto "limpando" uma sequência corrompida em paralelo. Mas a escolha de quais posições limpar a cada step é aleatória — o que é ineficiente. O que faz: Planner Aware Path Learning (PAPL) introduz um planner que decide quais posições limpar a cada step, alinhando o treino com a inferência planejada via Planned ELBO. Resultado-chave: melhora resultados em geração de proteínas, texto e código. Não é um ganho marginal — é a diferença entre random denoising e denoising inteligente. Por que importa: diffusion LMs são a alternativa mais promissora a modelos autoregressivos para geração paralela. Se essa linha de pesquisa decolar, o serving cost cai drasticamente.Paper: ICLR 2026 proceedings7. UniVLA: modelo unificado de visão, linguagem e ação Problema: modelos de robótica tipicamente separam percepção (visão), planejamento (linguagem) e execução (ação) em módulos diferentes. Isso cria gargalos de integração. O que faz: UniVLA modela visão, linguagem e ação como sequências discretas de tokens num único modelo autoregressivo. Um transformer, três modalidades. Resultado-chave: state-of-the-art em benchmarks de manipulação robótica (LIBERO, CALVIN, SIMPLER). A unificação não compromete performance em nenhuma modalidade individual. Por que importa: physical AI é a próxima fronteira. Se você está em robótica ou automação industrial, esse paper mostra que a convergência VLA não é hype — já funciona em benchmarks standard.Paper: OpenReview Código: GitHubWorkshop que vale a inscrição: SPOT O SPOT (Scaling Post-Training for LLMs) é o workshop que mais me interessa nessa edição. 64 papers aceitos, foco em scaling laws para SFT e RL, arquiteturas MoE e reward modeling. Acontece no dia 27 de abril (último dia da conferência). Se post-training é o seu jogo — e deveria ser, porque é onde o valor prático se materializa — esse workshop condensa o estado da arte em um dia.Site: spoticlr.github.ioPara quem vai e para quem fica Se você está indo ao Rio: a comunidade brasileira de ML está organizando side events. Fique de olho no Twitter/X do @iclr_conf e nos grupos locais. O Riocentro é longe de tudo, então planeje logística com antecedência. Se você não vai: todas as sessões terão streaming. Os papers já estão no OpenReview. Monte sua lista de leitura agora, não em abril. Veredito ICLR 2026 no Rio é simbólico para a comunidade latino-americana, mas o valor real está nos proceedings. Dos 5.300+ aceitos, a maioria é ruído incremental — como em toda conferência grande. Os 7 papers acima são os que eu colocaria na fila de implementação de qualquer time de ML engineering. O tema unificador: post-training não é mais pós-pensamento. Quantização, distillation, scaling laws, reward modeling — tudo isso é tão importante quanto o pre-training. E os papers desse ano finalmente têm as scaling laws e os benchmarks para provar. Nos vemos no Riocentro. Ou no stream.

LangGraph vs CrewAI vs OpenAI Agents SDK: o guia técnico para escolher seu framework de agentes em 2026

Três frameworks, um problema: você precisa colocar um agente de IA em produção e não sabe qual stack escolher. Eu construí o mesmo agente — pesquisa web, análise de resultados, geração de relatório — em LangGraph, CrewAI e OpenAI Agents SDK. Esse post é o resultado. Não é review de documentação. É código rodando, com números. O cenário do teste O agente é simples de propósito. Três etapas:Pesquisa web — recebe um tema, busca fontes relevantes Análise — filtra e ranqueia os resultados por relevância Relatório — gera um resumo estruturado com citaçõesSe um framework não consegue fazer isso bem, não merece estar na conversa. Se consegue, a pergunta passa a ser: com quantas linhas de código, quanto tempo de setup e quão fácil é debugar quando algo quebra às 2h da manhã. LangGraph: controle total, complexidade proporcional Repo: github.com/langchain-ai/langgraph — 27.100 buscas mensais no Google, o que mostra que muita gente está pelo menos curiosa. LangGraph modela o agente como um grafo direcionado com estado. Cada nó é uma função, cada aresta é uma transição condicional. Você define explicitamente o fluxo: qual nó executa depois de qual, sob quais condições, com qual estado compartilhado. Para o nosso agente de três etapas, o código ficou assim (simplificado): from langgraph.graph import StateGraph, ENDgraph = StateGraph(AgentState) graph.add_node("search", search_web) graph.add_node("analyze", analyze_results) graph.add_node("report", generate_report) graph.add_edge("search", "analyze") graph.add_edge("analyze", "report") graph.add_edge("report", END)app = graph.compile(checkpointer=MemorySaver())O resultado: ~120 linhas para o agente completo com estado, checkpointing e retry. O StateGraph te dá controle absoluto sobre o fluxo — você sabe exatamente o que vai executar e quando. O checkpointer salva estado entre etapas, o que significa que se a etapa de análise falhar, você retoma dali sem reprocessar a pesquisa. Onde brilha: workflows complexos com branching condicional, loops de feedback e estado persistente. Se o seu agente precisa decidir entre cinco caminhos possíveis baseado no output da etapa anterior, LangGraph é onde você quer estar. Onde dói: a curva de aprendizado. Modelar tudo como grafo é poderoso, mas verboso. Para um agente linear de três etapas, parece overengineering. E o ecossistema LangChain como dependência transitiva ainda carrega bagagem — eu gastei mais tempo resolvendo imports do que escrevendo lógica de negócio. CrewAI: multi-agente role-based, prototipagem rápida Repo: github.com/crewAIInc/crewAI — 44.600 stars no GitHub, v1.10.1 em março de 2026. CrewAI pensa diferente. Em vez de nós num grafo, você define agentes com papéis e tarefas. O framework cuida da orquestração. Para o nosso caso: from crewai import Agent, Task, Crewresearcher = Agent( role="Pesquisador Web", goal="Encontrar fontes relevantes sobre o tema", tools=[SerperTool()], llm="gpt-4o" )analyst = Agent( role="Analista de Conteúdo", goal="Filtrar e ranquear resultados por relevância", llm="gpt-4o" )writer = Agent( role="Redator de Relatórios", goal="Gerar relatório estruturado com citações", llm="gpt-4o" )crew = Crew( agents=[researcher, analyst, writer], tasks=[search_task, analyze_task, report_task], process=Process.sequential )result = crew.kickoff(inputs={"topic": "AI agents 2026"})~75 linhas para o agente completo. Cerca de 40% menos código que o LangGraph para o mesmo resultado. E o tempo de prototipagem caiu proporcionalmente — do pip install ao primeiro output funcional, foram 22 minutos contra 38 no LangGraph. O grande diferencial em 2026: suporte nativo a MCP (Model Context Protocol) e A2A (Agent-to-Agent). O CrewAI v1.10 trata MCP como cidadão de primeira classe. Conectar um servidor MCP é uma linha de config, não um wrapper custom. E o protocolo A2A permite que crews diferentes se comuniquem entre si — o que abre a porta para arquiteturas multi-equipe que eram impraticáveis há seis meses. Onde brilha: prototipagem. Se você precisa validar uma ideia de agente multi-step com stakeholders na terça, CrewAI é a resposta. A abstração role-based é intuitiva para times que pensam em termos de "quem faz o quê" em vez de "qual nó conecta com qual". Onde dói: controle fino. Quando o agente precisa tomar decisões complexas de roteamento, a abstração role-based começa a vazar. Eu precisei de um hack para implementar retry condicional na etapa de análise — algo que no LangGraph seria uma aresta no grafo. E o debugging de interações entre agentes ainda é opaco: quando o analista recebe lixo do pesquisador, o stack trace não ajuda muito. OpenAI Agents SDK: o novo na área Repo: github.com/openai/openai-agents-python — lançado em 2026, lightweight e opinionated. O Agents SDK da OpenAI é o mais recente dos três e não tenta esconder sua proposta: se você já usa modelos OpenAI, esse é o caminho de menor fricção. from openai_agents import Agent, Runnersearch_agent = Agent( name="researcher", instructions="Pesquise fontes relevantes sobre o tema dado.", tools=[web_search_tool], model="gpt-4o" )analysis_agent = Agent( name="analyst", instructions="Analise e ranqueie os resultados por relevância.", model="gpt-4o" )report_agent = Agent( name="writer", instructions="Gere relatório estruturado com citações.", model="gpt-4o" )result = Runner.run( search_agent, handoffs=[analysis_agent, report_agent], input="AI agents 2026" )~60 linhas. O mais enxuto dos três. O conceito de handoffs entre agentes é elegante — cada agente decide quando passar a bola para o próximo, e o Runner gerencia o ciclo de vida. Onde brilha: simplicidade e integração nativa com a API da OpenAI. Tracing vem embutido. O guardrail system é nativo. Se sua stack já é OpenAI de ponta a ponta, a integração é quase zero-config. Onde dói: lock-in. O SDK assume modelos OpenAI. Usar Claude ou Gemini exige adaptadores que não são oficiais. E para workflows complexos com estado persistente, o modelo de handoffs é limitado — não tem checkpointing nativo, não tem branching condicional explícito. É opinado no bom sentido quando seu caso é simples, e no mau sentido quando não é. A tabela que importaCritério LangGraph CrewAI OpenAI Agents SDKLinhas de código (agente de 3 etapas) ~120 ~75 ~60Tempo até primeiro output 38 min 22 min 18 minControle de fluxo Granular (grafo explícito) Médio (process types) Básico (handoffs)Estado persistente Nativo (checkpointer) Via memória de crew Não nativoSuporte a MCP Via integração manual Nativo (v1.10+) ParcialSuporte a A2A Não nativo Nativo Não nativoDebugging Bom (LangSmith) Médio (logs verbosos) Bom (tracing embutido)Observabilidade LangSmith/LangFuse Integrações terceiras Dashboard OpenAIVendor lock-in Baixo Baixo Alto (OpenAI models)GitHub Stars ~18K ~44.6K ~8KCurva de aprendizado Alta Média BaixaPydantic AI e AgentOps: o que mais importa Menção rápida a dois pontos que vão influenciar sua decisão. Pydantic AI (github.com/pydantic/pydantic-ai) não é um framework de agentes — é uma camada type-safe e async-first para interações com LLMs. Eu uso como building block dentro de agentes LangGraph: o grafo cuida do fluxo, Pydantic AI cuida do contrato de dados. Se você quer controle total do schema, vale o combo. AgentOps é a disciplina que ninguém pensa no protótipo e todo mundo precisa em produção. Como monitoro decisões de agentes? Como debugo fluxos multi-step? Ferramentas como LangFuse, AgentOps.ai e Arize Phoenix estão preenchendo o gap. Minha recomendação: escolha a ferramenta de observabilidade antes de escolher o framework. MCP e A2A estão acelerando isso. MCP padroniza como agentes acessam contexto externo. A2A padroniza como agentes conversam entre si. Ambos são agnósticos de framework — e quem adota primeiro (CrewAI, no momento) ganha vantagem prática. Minha recomendação por caso de uso "Preciso de controle total sobre um workflow complexo com estado." LangGraph. Sem hesitar. Se o seu agente tem branching, loops, retry condicional e precisa de checkpointing, é a ferramenta certa. Paga-se o custo da complexidade com previsibilidade. "Preciso prototipar rápido e validar com stakeholders." CrewAI. O tempo de prototipagem 40% menor é real. A abstração role-based comunica bem para não-técnicos. E com MCP/A2A nativos, o protótipo tem mais chance de sobreviver à produção. "Minha stack é 100% OpenAI e o caso é relativamente simples." OpenAI Agents SDK. Menor fricção, menor boilerplate, tracing embutido. Mas saiba que está comprando lock-in junto. "Quero type-safety e controle total do schema." Pydantic AI, possivelmente combinado com LangGraph para orquestração. Limitações desse comparativo O agente do teste é simples de propósito — três etapas lineares. Em workflows com 10+ nós e branching dinâmico, as diferenças se amplificam a favor do LangGraph. O OpenAI Agents SDK é novo demais para ter battle-testing em produção pesada. E "linhas de código" é uma métrica imperfeita, mas para engenheiros avaliando tempo de implementação, é um proxy útil. Veredito Não existe framework perfeito — existe framework certo para o problema. Em março de 2026, o ecossistema de agentes está fragmentado da melhor forma possível: frameworks especializados para casos especializados. A pior decisão é ficar parado avaliando. A segunda pior é escolher por hype. Clone o repo. Rode o agente. Meça. Decida.

pgvector 0.8 e o fim dos vector databases dedicados? Benchmark com Qdrant, Weaviate e Milvus

O pgvector 0.8.0 saiu e o changelog tem um número que muda a conversa: 5.7x de melhoria em performance. Latência de query filtrada caiu de 120ms para 70ms em dataset de 10M vetores. Quem já rodou vector search em produção sabe o que isso significa — é a diferença entre "preciso de um Qdrant" e "meu Postgres resolve". Faz um ano que escuto a mesma pergunta em toda call de arquitetura: "qual vector database a gente usa?". A resposta padrão era Qdrant, Weaviate ou Milvus. A nova resposta pode ser: o que você já tem rodando. Resolvi parar de especular e rodar os números. Montei benchmark com pgvector 0.8, Qdrant, Weaviate e Milvus em três cenários que cobrem 90% do que vejo em produção. Aqui estão os resultados. Setup do benchmark Antes dos números, o setup — porque benchmark sem contexto é marketing.Dataset: 1M vetores, 1536 dimensões (tamanho padrão de embedding OpenAI text-embedding-3-small) Hardware: 8 vCPUs, 32GB RAM, SSD NVMe, Ubuntu 22.04 pgvector: 0.8.0 sobre PostgreSQL 16, HNSW index com m=16, ef_construction=200 Qdrant: 1.13, configuração padrão com HNSW Weaviate: 1.28, flat + HNSW hybrid Milvus: 2.5, IVF_FLAT com nlist=1024 Cenários: RAG app, e-commerce search, document retrieval Métrica: latência p50 e p99, throughput (queries/sec), uso de memória em steady stateCada cenário rodou 10 mil queries após warmup de 1 mil. Nada de cherry-picking. Os números Cenário 1: RAG App (busca semântica simples) Query típica: embedding de pergunta do usuário → top-10 chunks mais similares. Sem filtro de metadata.Métrica pgvector 0.8 Qdrant Weaviate Milvusp50 latência 8ms 4ms 12ms 9msp99 latência 22ms 11ms 38ms 27msThroughput 420 q/s 890 q/s 310 q/s 380 q/sRAM (steady) 4.2 GB 5.8 GB 7.1 GB 6.3 GBQdrant domina. Não é surpresa — o engine inteiro foi desenhado para isso. Mas 8ms no pgvector é perfeitamente aceitável para um RAG app. Nenhum usuário percebe a diferença entre 4ms e 8ms na busca quando a chamada ao LLM depois vai levar 800ms. Cenário 2: E-commerce Search (busca com filtros) Query típica: embedding do produto → top-20 similares com filtro por categoria, faixa de preço e disponibilidade. Aqui é onde vector DBs dedicados costumavam massacrar o pgvector.Métrica pgvector 0.8 Qdrant Weaviate Milvusp50 latência 15ms 6ms 18ms 14msp99 latência 45ms 18ms 72ms 41msThroughput 280 q/s 620 q/s 210 q/s 300 q/sRAM (steady) 4.8 GB 6.2 GB 7.8 GB 6.9 GBO pgvector 0.8 melhorou absurdamente aqui. Na versão 0.7, essa query filtrada batia 120ms fácil. Cair para 15ms no p50 é o upgrade que fecha a porta para muitas migrações. Qdrant ainda ganha em throughput puro — se você processa milhares de buscas por segundo, a diferença importa. Se são dezenas ou centenas, não. Cenário 3: Document Retrieval (dataset com metadata pesada) Query típica: embedding de documento → top-5 similares com filtro por data, departamento, idioma, tipo de documento e nível de acesso. Cinco filtros simultâneos.Métrica pgvector 0.8 Qdrant Weaviate Milvusp50 latência 23ms 8ms 25ms 19msp99 latência 68ms 24ms 91ms 58msThroughput 190 q/s 480 q/s 160 q/s 220 q/sRAM (steady) 5.1 GB 6.5 GB 8.2 GB 7.1 GBMais filtros, mais gap. O Qdrant foi projetado para esse tipo de filtragem complexa — ele faz pre-filtering nativo no índice HNSW, enquanto o pgvector filtra no PostgreSQL e depois ranqueia. Ainda assim, 23ms no p50 é operável para qualquer aplicação enterprise que não seja real-time. O que os números dizem (e o que não dizem) Três observações: 1. O pgvector come memória significativamente menos. Em todos os cenários, usou 25-40% menos RAM que os concorrentes. Se você já tem um PostgreSQL com 32GB alocados e sobra headroom, vector search vem "de graça" em termos de infra. Se precisa subir um Qdrant separado, são mais 6GB de base + overhead operacional. 2. Qdrant ganha em tudo, mas a margem importa menos do que parece. 4ms vs 8ms é 2x em porcentagem. Em experiência de usuário, é irrelevante. A diferença real aparece em throughput — se você serve milhares de queries simultâneas, Qdrant escala melhor. Se serve centenas, tanto faz. 3. Weaviate e Milvus ficaram atrás nos três cenários. Weaviate tem features interessantes (módulos de reranking, integração com modelos), mas em performance bruta perdeu para todo mundo. Milvus se saiu ok mas não justifica a complexidade operacional — rodar Milvus em produção exige etcd, MinIO e um cluster inteiro. O paradigma mudou: "vector" é data type, não categoria de banco O que torna o pgvector 0.8 significativo não é só a performance. É o que ele representa. "Vector" está virando um data type, não uma categoria de banco de dados. PostgreSQL, Oracle e MongoDB adicionaram suporte nativo a vetores. O movimento é claro: busca vetorial é uma feature, não um produto. Isso é o mesmo padrão que vimos com JSON. Em 2012, todo mundo falava em document databases. MongoDB era obrigatório. Depois o PostgreSQL adicionou jsonb, e 80% das empresas que "precisavam" de MongoDB descobriram que não precisavam. O pgvector está fazendo o mesmo trajeto. Quando o pgvector NÃO resolve Vou ser direto sobre as limitações porque esconder isso seria desonesto:Billion-scale (>100M vetores): o HNSW do pgvector começa a sofrer. Qdrant e Milvus têm estratégias de sharding e quantização que escalam melhor nessa faixa. Latência sub-2ms: se seu SLA exige p99 abaixo de 5ms, pgvector não chega lá. Qdrant sim. Real-time updates com alta concorrência: inserir e buscar simultaneamente em alta frequência ainda causa lock contention no PostgreSQL. Vector DBs dedicados foram desenhados para isso. Filtros complexos em escala: com 5+ filtros e dataset acima de 50M, o gap de performance entre pgvector e Qdrant cresce de 2x para 5x+.Se você tem algum desses requisitos, vector DB dedicado continua sendo a resposta certa. Veredito Minha conclusão vai ser impopular entre quem vende vector database: para a maioria das empresas, pgvector 0.8 sobre PostgreSQL cobre 80% dos casos de uso de busca vetorial. Se você está construindo um RAG app, search semântico em catálogo ou retrieval de documentos com dataset abaixo de 50M vetores — pgvector resolve. Sem novo banco para operar, sem novo vendor para gerenciar, sem nova infra para monitorar. É uma extensão do banco que você já tem. Vector DB dedicado faz sentido em dois cenários: acima de 100M vetores ou com requisitos de latência abaixo de 2ms no p99. Fora disso, é complexidade operacional sem retorno proporcional. O pgvector 0.8 não matou os vector databases dedicados. Mas reduziu drasticamente o número de empresas que precisam de um. Para testar você mesmo: CREATE EXTENSION vector; CREATE INDEX ON items USING hnsw (embedding vector_cosine_ops); — e rode seus próprios benchmarks. Os meus estão aí. Agora mostre os seus.

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.

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.

Unsloth agora treina modelos MoE 12x mais rápido com 35% menos VRAM — hands-on com o novo release

Semana passada eu precisava fazer fine-tuning de um modelo MoE para um projeto interno. Abri o HuggingFace Trainer, configurei tudo, lancei o job numa A100 40GB e fui dormir. Seis horas depois, o treinamento tinha terminado — e metade da minha cota de GPU tinha ido junto. Aí saiu o novo release do Unsloth. Mesmo modelo, mesma config, mesma GPU: 70 minutos. Não é typo. Setenta minutos. O repositório é github.com/unslothai/unsloth, com mais de 30 mil stars no GitHub. E esse release merece cada uma delas. O que mudou neste release O Unsloth já era a ferramenta go-to para fine-tuning eficiente de LLMs. A grande novidade são os kernels Triton otimizados especificamente para arquiteturas MoE (Mixture of Experts). Antes, o suporte a MoE existia, mas sem otimizações dedicadas — você usava os mesmos kernels de modelos densos e torcia para dar certo. Agora os números falam por si:Métrica HF Trainer (baseline) Unsloth (novo release) MelhoriaTempo de treino (A100 40GB) ~6h ~70min 12x mais rápidoUso de VRAM 38.2 GB 24.8 GB 35% menosContexto máximo 8K tokens 48K tokens 6x mais longoPerda de acurácia baseline baseline nenhumaEsse último ponto é o que importa. Não é um tradeoff velocidade-por-qualidade. Os kernels Triton reescrevem as operações de roteamento do MoE de um jeito que reduz materialização de tensores intermediários. Menos cópia de memória, menos overhead de kernel launch, mesma matemática. Modelos suportados no release: DeepSeek, GLM-4.7-Flash, Kimi-2.5, Llama 4, Mistral, Gemma 2, Qwen 2.5. Basicamente tudo que você vai querer usar em produção. Hands-on: fine-tuning de um Llama 4 8B Chega de slide. Vamos rodar. 1. Instalação pip install "unsloth[triton] @ git+https://github.com/unslothai/unsloth.git" pip install sglang # para deploy depoisSe você está numa instância com CUDA 12.x, o Triton já vem compatível. Em CUDA 11.8, precisa do triton-nightly. Não tente rodar sem Triton — os kernels MoE dependem dele. 2. Configuração do modelo from unsloth import FastLanguageModelmodel, tokenizer = FastLanguageModel.from_pretrained( model_name="meta-llama/Llama-4-Scout-8B", max_seq_length=32768, load_in_4bit=True, dtype=None, # auto-detect )model = FastLanguageModel.get_peft_model( model, r=16, target_modules=[ "q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj", ], lora_alpha=16, lora_dropout=0, bias="none", use_gradient_checkpointing="unsloth", )O use_gradient_checkpointing="unsloth" é o que ativa os kernels otimizados. Sem isso, você está rodando o path padrão do HuggingFace. 3. Dataset e treinamento from trl import SFTTrainer from transformers import TrainingArgumentstrainer = SFTTrainer( model=model, tokenizer=tokenizer, train_dataset=dataset, # seu dataset formatado dataset_text_field="text", max_seq_length=32768, args=TrainingArguments( per_device_train_batch_size=2, gradient_accumulation_steps=4, warmup_steps=10, num_train_epochs=3, learning_rate=2e-4, fp16=not torch.cuda.is_bf16_supported(), bf16=torch.cuda.is_bf16_supported(), output_dir="outputs", optim="adamw_8bit", ), )trainer.train()Na minha A100 40GB com um dataset de ~50K exemplos, esse treinamento rodou em 68 minutos. O pico de VRAM foi 24.3 GB — sobraram 16 GB que eu poderia usar para aumentar batch size ou contexto. 4. Salvando o modelo model.save_pretrained_merged( "llama4-8b-finetuned", tokenizer, save_method="merged_16bit", )Deploy com SGLang Uma coisa que eu gosto no ecossistema Unsloth é que eles pensaram no pipeline completo. Treinou? Deploy com SGLang. Sem ficar convertendo formato de modelo entre três ferramentas diferentes. python -m sglang.launch_server \ --model-path llama4-8b-finetuned \ --port 8000 \ --tp 1O SGLang roda inference otimizada com continuous batching e funciona como um drop-in replacement para a API da OpenAI. Seu código de aplicação não muda — é apontar a URL e pronto. Pipeline inteira open-source: Unsloth para treino, SGLang para serving. Sem vendor lock-in, sem licença enterprise obscura. Quanto custa na prática Porque no final das contas, é sempre sobre dinheiro.Setup Custo/hora (spot) Tempo de treino Custo totalA100 40GB + HF Trainer ~US$1.10/h 6h US$6.60A100 40GB + Unsloth ~US$1.10/h 70min US$1.28A10G 24GB + Unsloth (4bit) ~US$0.50/h ~2.5h US$1.25Leu direito: com Unsloth, dá para fazer fine-tuning de um modelo MoE de 8B numa A10G — uma GPU que custa metade de uma A100. O consumo de VRAM caiu o suficiente para caber em 24 GB com 4-bit quantization. Para quem roda fine-tuning frequente, a diferença anualizada é brutal. Um job semanal sai de US$343/ano com HF Trainer para US$65/ano com Unsloth na A10G. Mesmo dinheiro, cinco vezes mais experimentos. Limitações — porque nem tudo são flores Eu já testei bastante para listar o que ainda não funciona bem:Multi-GPU: o suporte a tensor parallelism no treinamento ainda é experimental. Para modelos maiores que 70B, você vai precisar de DeepSpeed ou FSDP por enquanto. Modelos não-suportados: se seu modelo não está na lista de arquiteturas suportadas, os kernels Triton não ativam e você cai no path lento sem aviso claro. Verifique a compatibility matrix no repo. Quantização assimétrica: AWQ e GPTQ ainda não são suportados nos kernels MoE. É QLoRA com bitsandbytes ou full precision. Documentação: melhorou muito, mas ainda tem gaps. O notebook de exemplo para MoE não cobre todos os edge cases. Já abri duas issues no repo.Nada disso é um deal-breaker, mas é bom saber antes de começar. Veredito O Unsloth com kernels Triton para MoE é, sem exagero, a maior melhoria prática em tooling de fine-tuning que eu vi nos últimos seis meses. 12x mais rápido, 35% menos VRAM, sem perda de acurácia — e tudo open-source. Se você está fazendo fine-tuning de qualquer modelo MoE — DeepSeek, Llama 4, Qwen — não tem motivo para não usar. A instalação leva dois minutos, a API é compatível com HuggingFace Trainer, e os resultados são mensuráveis no primeiro job. Repo: github.com/unslothai/unsloth. Vai lá, roda, mede. Depois me conta.