Showing Posts From

Benchmarks

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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.

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

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.

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

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.

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

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

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