O modelo estrela e o principal do meu fleet atualmente. Trata-se de um fine tune do Qwen3.5-35B-A3B, que atualmente é o melhor modelo de código que tenho. Veja que seu modelo-base está uma geração "atrás" do Qwen3.6 (falarei dele nas menções honrosas), mas mesmo assim, consegue ser melhor que ele nas tarefas de código.

Esse modelo não possui capacidade de visão, diferente do Qwen3.5 base, mas não faz falta porque o foco aqui é código, e nisso ele ganhou em todos os meus testes. O Ornith 1.0 35B atualmente é meu modelo principal para programação, quando os meus tokens da semana acabam…

De qualquer forma, o Ornith também tem uma quantização APEX I-Compact, então o setup é bem parecido com o Qwen3.6-35B-A3B. Em geral, essa quantização, modelos MoE e suporte no backend ik_llama.cpp é o que sempre vou considerar para modelos que exigem offload dessa forma.

Eu já tive uma história de amor e ódio com esse modelo porque, quando usei ele pela primeira vez, foi via Ollama, com a quantização que tinha. E ele rodava com todo o hardware do meu computador no talo, usando muita memória RAM e quase nada de VRAM, porque eu não sabia configurar minha infraestrutura, e eu fazia uns 5 tok/s. De qualquer forma, depois de uma madrugada com todos os programas fechados e esse modelo configurado no OpenCode, foi esse cara que iniciou o meu projeto do harness que estou desenvolvendo, o Sprachspiel.

Mas agora tudo mudou aqui! Com uma quantização APEX I-Compact apropriada, finalmente consegui rodar ele de tal forma que tenho um desempenho aceitável e ainda assim consigo usar meu computador normalmente. A Z.ai manda muito bem, e depois desse modelo, veio a família do GLM 5.x, que é o que mais uso atualmente. Recomendo demais esse modelo para desenvolvimento em geral. É o meu favorito depois do Ornith 1.0.

A família de modelos Qwen3.5 foi muito importante quando lançou nesse ano de 2026, porque foi um dos primeiros indicativos de que poderíamos ter modelos pequenos realmente capazes de fazer coisas. Esse é um dos menores modelos da família, sendo maior apenas que um de 800 milhões (0.8B) e outro de 2 bilhões (2B) de parâmetros. Aqui, eu uso ele como um modelo muito capaz e muito rápido para tarefas mais simples.

Eu arrisco dizer que, se você precisa de um chatbot com capacidades de tool calling mais simples, o Qwen3.5 4B pode ser uma EXCELENTE opção. Caso você já tenha usado o GPT-4o, que foi o "xodozinho" de muita gente, o Qwen3.5 4B é um substituto direto para ele. E isso é um representativo dos saltos da indústria: estamos comparando um modelo grande, rodando em datacenter, de agosto de 2024, com um modelo minúsculo, rodando dentro do seu computador, de março de 2026. Em um ano e meio, a mesma capacidade desceu de centenas de bilhões de parâmetros (estima-se que GPT-4o tinha uns 200B) para apenas quatro bilhões.

Ah, todos os modelos da família Qwen3.5 (sem treinamento extra) suportam visão, mas eu deliberadamente desativo a visão neles para não ter que carregar um arquivo mmproj, economizando VRAM no processo.

Esse é o irmão relativamente maior e o último que compõe a família dos Qwen3.5 realmente pequenos. O 9B é significativamente melhor que o 4B em praticamente tudo, especialmente se você estiver falando de matemática e código (podemos fazer comparação direta entre ele e o GPT-OSS de 120B, então temos outra situação de centenas de bilhões de parâmetros reduzidos a meros bilhões).

O 9B pode ser usado como substituto do 4B quando você precisa que o modelo tenha um "raciocínio" mais apurado e mais qualitativo. Tamanho também é um bom indicador de retenção de quantidade de conhecimento de mundo, e isso é relativamente importante para ajudar o modelo a explorar caminhos diferentes, coisa que você vai precisar com código e com um agente.

Uso uma quantização Mixture-of-Quants (MoQ), o que é agressivo mas não perde tanto desempenho assim. No meu computador ele é mais lento que o 4B, e meu uso principal dele é quando preciso tratar algum assunto mais filosófico de pesquisa ou quando preciso de uma revisão de código em busca de bugs, algo com o qual ele surpreendentemente se dá muito bem, até marginalmente melhor que o Ornith 1.0 nos meus testes (isso é um resultado mais preliminar, ainda estou trabalhando nesses testes).

Gemma4 foi uma excelente surpresa da Google esse ano, uma família de pequenos modelos abertos e focados justamente em sistemas mais limitados. Digamos que seja a resposta ocidental direta à família Qwen3.5.

Ao contrário do que o nome sugere, os modelos E2B e E4B não significam que são 2B parâmetros e nem 4B parâmetros. Os "E" vem de parâmetros EFETIVOS. Não vou entrar em nuances aqui, mas isso significa que, na verdade, o E2B tem 4.6B parâmetros, mais especificamente, com 2B efetivos.

Esse modelo foi particularmente importante pra mim nas aulas que ministrei sobre como criar agentes com LangChain porque, para pessoas com computadores limitados, era mais interessante instalar Ollama em uma VM do Google Colab e rodar esse modelo de forma persistente, já que ele é suficientemente bom com tool calling. Além disso, eu uso uma quantização Q4_K_XL provida pela Unsloth, mas que também foi feita em cima da variante QAT do Google, que é um tipo de treinamento realizado já com o objetivo de o modelo ser quantizado em sequência, o que significa que ele compensa já no treinamento a perda de precisão que vai sofrer, evitando perda de qualidade.

Essa é a variante "effective" maior do E2B, sendo ela uma E4B. Portanto ela tem 4B parâmetros "efetivos", mas o seu tamanho real é 7.5B parâmetros. Uso uma quantização Q4_K_M da Unsloth (veja que ela não é XL, que tornaria ela incompatível com ik_llama.cpp, o backend que mais utilizo). O E4B é um modelo mais poderoso e gosto de pensar nele como uma resposta direta ao Qwen3.5 9B, porém ele ainda peca um pouco com relação ao modelo chinês.

De forma interessante, eu não uso a versão QAT desse modelo porque, nos meus testes, uma quantização Q4 com QAT (executada no llama.cpp vanilla) não apenas implicou em ganho algum de performance na minha placa de vídeo, como também perdeu ligeiramente em qualidade da tarefa que usei como teste (algo que potencialmente deve estar na margem de erro). Ou seja, como a versão QAT não trouxe benefícios, optei pela quantização Q4_K_M PTQ da Unsloth, que além de compatível com ik_llama.cpp, teve melhor performance nos meus testes.

Esse modelo é encantador. A Liquid AI é uma empresa muito voltada para a criação de modelos MUITO pequenos e a incentivar a comunidade a construir coisas com seus modelos, inclusive realizar fine tuning deles. Esse modelo, em especial, é uma pequena obra prima: 8B de parâmetros totais, então é um modelo pequeno. Mas com apenas 1B de parâmetros ativos. Ou seja, é MoE (então em extremo caso, podemos fazer offload tranquilamente); é suportado no ik_llama.cpp; e ainda existe quantização APEX I-Compact para ele. É o melhor de todos os mundos.

Preciso ser sincero com relação a um aspecto desse modelo: não use-o para código. Ele simplesmente não presta para programar. Ouso dizer que até mesmo um Qwen3.5 2B poderia ser melhor. E são dois os motivos: primeiramente, em apenas 8B, você não empacota tanto conhecimento de mundo e programação; segundo, por ser um MoE A1B, na prática ele vai agir a maior parte do tempo como um modelo 1B, e isso não é praticamente NADA em termos de parâmetros.

Esse modelo vai brilhar em qualquer situação em que você precisar de chat e de um agente capaz de realizar tool calls em uma longa cadeia de interações. Ou seja: você consegue usar ele como um pequeníssimo modelo em algo como Hermes Agent ou OpenClaw, assumindo que você só queira algo que responda suas solicitações, tome decisões relativamente elaboradas sobre certos dados, precise agir de forma simples em pipelines, etc. Até mesmo para um virtual pet que ainda seja capaz de realizar coisas úteis… Esse é o cara que consulta e remarca compromissos no calendário enquanto entende sua solicitação que foi feita com linguagem natural.

Como eu disse antes, eu desativei completamente a capacidade de visão (input de imagem) em todos os meus modelos maiores, porque isso gasta mais VRAM para carregar os encoders visuais e a camada de projeção, que efetivamente transforma a entrada da imagem para o formato que a LLM "entende".

A forma que eu uso para mitigar isso é ter bons modelos especialistas em visão. São também LLMs, mas como são especialistas em imagens, costumam se referir a elas como VLMs. É o caso aqui do Qwen3-VL: trata-se de um modelo um pouco mais velho (anterior ao Qwen3.5), mas que é especialista em lidar com imagens, sobretudo muito bom em gerar groundings, ou seja, delimitar e legendar elementos específicos em imagens.

Essa versão do Qwen3-VL em especial, que só tem 4B parâmetros, é excepcionalmente boa em tudo isso, sendo meu modelo de visão mais confiável do fleet para essa tarefa. Quando eu preciso de algo do tipo, eu controlo meus harnesses pra que eles redirecionem tarefas de reconhecimento de elementos via visão computacional para o Qwen3-VL, e o llama-swap trata de descarregar uma LLM pra colocar ele no lugar e responder à requisição, e vice-versa. Obviamente você pode perceber que isso tem um impacto em performance e acaba causando um cache miss, mas bem, quem não tem cão, caça como gato…

O GLM-OCR é um lindo e pequeníssimo modelo criado pela Z.ai (mesmos criadores do GLM 5.2) que é especialista em leitura de documentos, e também é capaz de extrair tabelas formatadas e fórmulas. É uma VLM, portanto, com apenas 940M de parâmetros (menos de 1B!). Cabe inteiro na VRAM, quase não precisa de cache, etc.

O uso dele é extremamente limitado e ele tem também formas muito específicas de ser chamado, você não vai passar textos e mais textos de prompt para ele. Ele não foi treinado para isso. Então, é basicamente um utilitário de propósito muito específico.

O legal de você ter um modelo como o GLM-OCR é justamente o fato de ele ter um tamanho de 1.4GB, não precisar ser quantizado, não usar praticamente NADA de memória de vídeo, e substituir uma stack inteira de extração de dados de documentos que poderia ser feita com Tesseract, Poppler ou bibliotecas desse tipo. Vai te servir para a grande maioria das situações. Apenas crie uma aplicação ou pipeline, carregue o modelo, e faça ele trabalhar para você digitalizando documentos. Simples e confiável.

Esse modelo aqui é interessante demais. Trata-se de um modelo capaz de realizar tradução de 33 línguas e cinco dialetos, totalizando 38, feito pela Tencent. Atualmente é o modelo que eu uso para tradução de texto.

O legal dele é justamente ter um tamanho de 1.8B, então não faz nem cócegas na minha máquina. Todavia, o grande problema desse modelo é que ele não tem muito conhecimento de mundo, já que é tão pequeno. Se você precisar de algum modelo que exija uma tradução com mais nuances da língua que você estiver traduzindo, recomendo dar uma olhada no TranslateGemma, que tem suporte a 72 línguas e tem tamanhos de 4B ou 12B, a depender da sua necessidade.

Esse modelo, quantizado a 1-bit, e o modelo Ternary (do qual vou falar a respeito mais tarde), saíram enquanto eu ainda estava escrevendo esse post, então tive que dar uma parada e testá-los. E eu devo dizer, são marcos INCRÍVEIS.

O Bonsai 27B 1-bit é uma quantização do Qwen3.6-27B muito especial, feita pela PrismML, que comprimiu o modelo de tal forma que ele tivesse o tamanho de um modelo de 4B de parâmetros com quantização Q4.

Uma quantização tão extrema é excelente porque fornece para a gente uma prova de conceito de que é possível ter modelos com tamanhos ainda menores no disco e na memória, mas com a mesma quantidade de parâmetros de um modelo ainda maior.

O Qwen3.6-27B é atualmente o estado da arte para os modelos locais, e agora, se você tiver uma placa de vídeo de 8GB, pode usufruir desse modelo rodando em uma velocidade decente e com um contexto longo! O Bonsai ainda não é excelente para iterar sobre tarefas de edição de código por um longo período⁷, mas a PrismML promete mitigar isso no futuro.

Importante: para conseguir as velocidades aí acima, eu precisei reduzir o contexto dele para 32K. Isso realmente não é muito. Eu diria que menos de 64K já inviabiliza o uso de um modelo em um agente.

Esse é um pequeno modelo da InternScience que saiu pouco depois do seu variante 35B-A3B. Como o variante maior, é um fine tune do Qwen3.5-4B. Mas o interessante desse modelo é que ele apresenta alguns incrementos interessantes com relação à sua base: foi treinado para comportamento agentic e de long-horizon, ou seja, foi feito para servir como um agente capaz de operar de forma autônoma por muito tempo, em cima do mesmo prompt.

Esse modelo, porém, não é o melhor modelo para código da sua categoria. Eu recomendo muito esse modelo caso você esteja interessado em pesquisa e contexto científico. Nos testes em que fiz, dei a ele uns quatro PDFs diferentes e pedi para ele fazer uma síntese e amarrar os conceitos entre os quatro, e ele executou essa tarefa com maestria. Também fiz um outro teste em que pedi para que ele pesquisasse na internet e categorizasse as fontes em um relatório e também em um CSV com bastante rigor, e ele executou todas as tarefas com perfeição segundo o meu critério, e por bastante tempo.

O modelo "estrela" para execução local em hardware mais limitado, criado pela Alibaba, da notória família Qwen de modelos cujas versões open-weights são adoradas pelo mundo todo. É o maior modelo "de fábrica" que tenho, e em geral funciona muito bem para tudo, sendo um modelo grande com boa performance. Sua arquitetura é baseada no Qwen3.5 de mesmo tamanho, mas ele recebeu treinamento extra para agentes e para execução de longo tempo.

Para o deploy do modelo ficar mais leve, eu deliberadamente desativei a capacidade de visão dele. Isso é um ponto importante, porque significa que não precisamos carregar tensores mmproj para tratar o input de imagem, fazendo o modelo precisar de bem menos memória em geral para carregar, e permitindo um contexto muito maior.

Esse modelo tem uma arquitetura MoE (mixture of experts), o que significa que, dos 35 bilhões de parâmetros no modelo, nem todos estarão ativados ao emitir cada token, mas sim apenas os experts para aquele token a ser emitido. Isso nos dá uma vantagem em sistemas mais limitados: acaba se tornando possível para a gente deixar os "experts mais importantes", ou os principais, na placa de vídeo, e o resto a gente faz offload para a memória normal. Ou seja, se são 35B, com 3B ativos (por token), então o modelo vai acabar se comportando, em maioria, com uma velocidade de um modelo de 3 bilhões de parâmetros, o que é muito rápido no meu computador. Junte isso ao ik_llama.cpp como backend, feito especialmente para sistemas mais limitados, e você pode realizar memory pinning, o que permite que a GPU se comunique diretamente com as partes da memória RAM em que os experts estão carregados, via DMA. Esse é o segredo da mágica dos 30 tokens por segundo de decode com esses modelos MoE.

O lançamento desse modelo foi bela supresa. Trata-se de um modelo relativamente leve e confiável para código, que uso esporadicamente para tarefas pequenas. O único defeito dele é ser grande demais em comparação com o Ornith e o Qwen3.6, o que significa que eu acabo preferindo os outros dois, mas é uma boa opção, especialmente quando você precisa de um código analisado por uma IA diferente, como uma espécie de "segunda opinião". Criado pela empresa canadense Cohere.

Esse modelo é meio engraçado. Ele é um fine tune do Qwen3.5-35B-A3B, na mesma pegada do Ornith 1.0 35B. Porém, apesar de ele ser decente em programação (ficando atrás do Ornith e do Qwen3.6 em testes que fiz aqui), ele aparentemente foi feito com a pretensão de ser um orquestrador de outros modelos. Por isso acredito em utilizá-lo para planejamento e distribuição de tarefas.

Mas meu computador dificilmente roda um modelo ao mesmo tempo, então o Agents-A1 ficou para outra oportunidade.

Esse é um modelo especialista em vision, sendo portanto algo que a gente pode chamar de VLM também. Antes de usar o Qwen3-VL, esse era o modelo que estava utilizando, e inclusive ele é rápido o suficiente para que eu consiga usar uma quantização Q5 em vez de Q4 (o que significa uma ligeira melhor qualidade). Recomendo como uma alternativa mais lightweight, para um especialista em visão.

Esse modelo é bem interessante, porque ele não é um modelo para chat nem para agente. Trata-se de um World Model. Esse tipo de modelo foi feito para renderizar estados de um certo domínio após a aplicação de certas ações sobre um estado anterior. No caso específico do Qwen-AgentWorld, a ideia é fazer isso com uma LLM clássica treinada do zero para isso⁸.

Eu diria que existe muito espaço pra esses modelos, por enquanto como modelo de apoio para construção de agentes, mas por enquanto não temos adoção nem uma compreensão robusta da maioria sobre o potencial desses caras.

Esses modelos são muito legais, e na verdade são um conjunto de pequenos modelos. Os LFM2.5-VL são modelos especializados em visão computacional e que inclusive entendem groundings (enquadramento com coordenadas exatas de elementos em imagens). Existem variantes de 450M e 1.6B parâmetros, e em especial uma variante extract para esses dois tamanhos, que responde só com JSON.

A Liquid AI recomenda inclusive fazer fine tuning dos modelos deles para as suas necessidades, e eu consegui inclusive fazer fine tune do LFM2.5-VL-450M-Extract para que ele fizesse reconhecimento e groundings de mãos em imagens, e inclusive usando esse mesmo hardware limitado que tenho! Recomendo bastante a experiência.

Esse modelo aqui é exatamente a mesma coisa do Bonsai 27B com quantização de 1-bit, a diferença é que ele usa uma quantização em trinário. Se você tiver um pouco mais de hardware para ceder para execução de um modelo como esse, é interessante que você experimente essa variante porque ela tende a ter uma qualidade melhor, sobretudo em termos de codificação. Todavia, a PrismML recomenda mais a variante de 1-bit justamente porque o objetivo é vencer a constraint de tamanhos, em especial quando o assunto for rodar modelos em celulares e dispositivos embarcados.

Diferente dos outros modelos, esse aqui é um modelo para gerar embeddings. Esse tipo de modelo é particularmente interessante quando o assunto é RAG, indexação, pesquisa semântica, etc. O legal especificamente desse modelo é que ele foi treinado com uma técnica chamada Matryoshka embeddings. É meio complicado explicar do que se trata isso, mas imaginando que o embedding seja um grande vetor multidimensional em que cada valor dele corresponda mais-ou-menos a um conceito semântico específico para a LLM, esse tipo de treinamento faz com que o modelo priorize as dimensões de maior carga semântica para o início do vetor. Isso significa que, se for necessário descartar valores ao final do vetor de embeddings, você pode fazer isso sem perder tanta qualidade no embedding.

O valor de encoding que registrei ali em cima é bem alto, como podemos ver, e o mais legal disso é que é um valor CPU-only. Eu nem gasto a minha placa de vídeo quando o assunto é rodar modelos de embedding.

Mais um modelo pequeno da Liquid AI, dessa vez para gerar embeddings também. Mais uma vez, é o tipo de modelo que eu executo CPU-only. Veja que ele tem uma diferença considerável na performance, mas isso também tem a ver com o fato de que o embedding dele tem mais dimensões (1K).

Esse é um excelente modelo não apenas para geração de imagens, mas também para edição delas: você pode fornecer uma imagem como exemplo e ele vai gerar uma nova imagem usando-a como base, de acordo com o prompt que você fornecer.

As únicas ressalvas que faço são o seguinte: primeiro, ele tem uma tendência a gerar imagens com uma iluminação e um detalhamento mais cartunesco; segundo, por algum motivo, ele tende a envelhecer, e muito, as pessoas que for gerar. Isso é contornável com um bom trabalho de prompting, mas eu precisei embutir um modo enhance no meu utilitário para que uma LLM qualquer (à escolha) saiba como mitigar e contornar esses problemas.

Esse modelo também faz snap do tamanho da imagem para 2048x2048, por isso ele pode demorar mais na geração, e também gerar imagens de altíssima qualidade. Como isso sugere, esse é o modelo mais lento e mais pesado, mas vale o teste.

Esse é o modelo principal que uso hoje, mantenho ele instalado sempre. É sem dúvida o modelo que gera imagens com a melhor qualidade em geral. A melhor forma de fazer os inputs para ele é com uma estrutura em JSON que eu pessoalmente tenho MUITA PREGUIÇA de escrever, e por isso mais uma vez uso a extensão --enhance da ferramenta de geração de imagens que criei para fazer com que uma LLM do meu fleet gere o prompt adequadamente pra mim.

Esse modelo gera verdadeiras obras de arte de alta qualidade e lida muito bem com gerar imagens com texto também.

O único defeito desse modelo é a censura embutida nele, que é exagerada. Uma das coisas que fiz para testar esses modelos quando os instalei foi gerar uma imagem do Alucard, da franquia Castlevania. E é impossível descrever o Alucard sem falar em vampiros, tema gótico, estilo chiaroscuro, etc. O resultado de usar prompts desse tipo é que o modelo acaba bloqueando completamente a imagem e renderizando apenas uma imagem de cor sólida com um letreiro de "content blocked by safety filter". Mas isso é simples de contornar na maioria das situações, basta fazer um prompt melhor, mesmo.

O Bonsai Image 4B é de longe o modelo mais leve em termos de tamanho. Foi o primeiro modelo de difusão que coloquei aqui. Ele possui uma base de um FLUX.2 Klein 4B, porém quantizado para 1.58-bit em ternário. Como você pode ver, ele lembra um pouco o que a PrismML fez com o Bonsai 27B, e a forma de criar prompts para ele é mais com descrições da cena em linguagem natural. Keyword stacking (ex. insistir em referenciar alta qualidade várias vezes) e mood contraditório não são com ele.

A ferramenta que criei para rodar esses modelos de difusão começou a existir primariamente por causa desse modelo, porque ele depende de um backend próprio (gemlite) para execução.

Esse modelo foi produzido pela Alibaba (criadores da família Qwen). Usa uma base Lumina2, e opera melhor gerando imagens 1024x1024 que 512x512, sendo portanto o único modelo referenciado aqui que prefere resoluções maiores. É um bom modelo para gerações de boa qualidade. Se estiver em dúvida de onde começar, esse é um bom começo.