Kolibri vs Granite 4.2 3B: Uma aposta de esparsidade de 78B, e o modelo 3B que se recusa a jogar o mesmo jogo

Coloque Kolibri e Granite 4.2 3B lado a lado e a primeira observação honesta é que esta não é uma disputa justa, e não na direção que você suporia. Kolibri é o modelo de mistura de especialistas de 78,1 bilhões de parâmetros da Aleph Alpha, lançado em 3 de outubro de 2026, ativando 3,46 bilhões de parâmetros por token. Granite 4.2 3B é o modelo denso de raciocínio da IBM com aproximadamente três bilhões de parâmetros, cujos pesos chegaram ao Hugging Face em 7 de agosto de 2026, com a ficha do modelo e o blog técnico vindo em seguida, em 25 de agosto. Um é vinte e seis vezes o outro em número total de parâmetros. A razão pela qual eles pertencem à mesma decisão é que ambos são Apache 2.0, ambos são somente texto, ambos são auto-hospedados por design, e ambos foram destinados ao mesmo comprador: uma equipe que quer inteligência documental em hardware que ela controla, com a procedência necessária para sobreviver a uma análise de compras. A pergunta interessante não é qual deles é melhor. É o que o orçamento de parâmetros vinte e seis vezes maior realmente compra, e quanto custa carregá-lo.

A incompatibilidade, dita de forma simples

Granite 4.2 3B é um modelo denso autônomo pós-treinado a partir do Granite-4.1-3B-Base, parte da família Granite 4.2 que a IBM lançou até agosto. Ele tem 40 camadas com atenção de consulta agrupada, um contexto nativo de 128K que a IBM estende para 512K numa quinta fase de pré-treinamento, e três modos de pensamento por consulta: pensamento completo por padrão, um caminho de baixo esforço e um caminho sem pensamento. A ficha da IBM é incomumente franca sobre o que o 3B não é. Ao contrário dos seus irmãos 8B e 30B, ele deliberadamente pulou o bloco especializado de aprendizado por reforço agêntico treinado em ambientes SWE-agent, terminal e de busca, e é por isso que a IBM não lista nenhum número do SWE-bench para ele e descreve o modelo como um especialista em raciocínio, e não como um agente.

Kolibri segue o caminho oposto em todos os eixos. Cinquenta camadas, todas elas de mistura de especialistas, 384 especialistas por camada, com um compartilhado e seis roteados, e uma taxa de esparsidade de cerca de 22,6 para 1. Seu contexto é nativamente de 262.144 tokens, validado para 1.048.576, com a ficha do modelo recomendando que você permaneça em 262.144 ou menos para trabalhos sensíveis à latência. Quatro níveis de esforço de raciocínio. Chamada de ferramentas no estilo Hermes com um parser vLLM fornecido no mesmo repositório que os pesos. E um footprint de aproximadamente 78 GB em FP8, com a configuração mínima da ficha sendo duas placas A100 de 80 GB, duas H100 SXM5, uma H200, uma B200 ou uma B300.

• Parâmetros — Kolibri: 78.103.074.560 no total, 3.457.573.120 ativos por token. Granite 4.2 3B: aproximadamente 3B denso, com todos os parâmetros ativos em cada token.

• Contexto — Kolibri: 16.384 treinado, 65.536 treinado em nível intermediário, 262.144 nativo, 1.048.576 validado. Granite 4.2 3B: 128K nativo, estendido para 512K.

• Modos de raciocínio — Kolibri: nenhum, baixo, médio, alto, definidos através do template de chat. Granite 4.2 3B: completo, de baixo esforço e sem raciocínio, por consulta.

• Chamada de ferramentas — Kolibri: no estilo Hermes, com um parser já incluído. Granite 4.2 3B: sim, mas não o caminho treinado com RL agêntico que seus irmãos maiores receberam.

• Idiomas — Kolibri: alemão e inglês, por design e nada mais. Granite 4.2 3B: inglês em primeiro lugar, com o amplo treinamento multilíngue da IBM por trás.

• Pegada — Kolibri: cerca de 78 GB em FP8, no mínimo duas GPUs. Granite 4.2 3B: aproximadamente 6–8 GB em bfloat16, menos de 2 GB quantizado, de classe laptop.

• Licença — ambas Apache 2.0, ambas sem cláusula de uso aceitável nem limite de usuários ativos mensais.

• Serviço — Kolibri: o plugin vLLM aleph-alpha-inference ou a imagem de contêiner publicada. Granite 4.2 3B: vLLM, SGLang, Transformers, GGUF e Ollama em granite4.2:3b.

O que os 75 bilhões de parâmetros extras oferecem

Três coisas, e vale a pena ser preciso sobre quais delas estão estabelecidas e quais são apenas alegadas.

O primeiro é alemão. Esta é a diferença real mais acentuada entre os dois modelos e não é uma linha de benchmark. A Aleph Alpha construiu o Kolibri em torno de um corpus bilíngue alemão-inglês, visando cerca de 20 por cento de alemão numa execução de pré-treinamento de 20 trilhões de tokens, e terminou com um conjunto de 2,4 trilhões de tokens em alemão, 80 por cento do qual foi curado ou gerado pelo próprio laboratório. A ficha explica por que isso exigiu trabalho: conjuntos de dados alemães abertos e deduplicados forneceram apenas 390 bilhões de tokens, uma ordem de magnitude abaixo, por isso o laboratório reajustou um filtro do Common Crawl especificamente para o alemão e reformulou documentos alemães existentes em verbetes de enciclopédia, diálogos e passagens. O detalhe do filtro é o que é preciso lembrar. Um pipeline padrão de dados linguísticos descarta documentos com demasiadas palavras longas, e a prosa administrativa alemã excede rotineiramente o limite do inglês para o comprimento médio das palavras — então as configurações padrão apagam silenciosamente o registro em que a administração pública escreve. A IBM não construiu o Granite para esse corpus. O Granite 4.2 3B dará conta do alemão; não foi concebido em torno do registro jurídico e administrativo alemão, e nenhum ranking lhe dirá a diferença.

O segundo é o contexto longo que sobrevive a documentos reais. O teto de 512K do Granite é genuinamente grande, mas os dois modelos chegaram lá de maneiras diferentes, e o design posicional do Kolibri é o argumento de contexto longo mais convencional. Trate os números do RULER da IBM — 67,52 em 64K e 55,30 em 128K no material publicado da família 4.2 — como a divulgação honesta de quanto a qualidade de recuperação se deteriora até 128K, e lembre-se de que o Kolibri não tem nenhuma curva de degradação publicada equivalente.

O terceiro é a margem de raciocínio bruta, e é aqui que a resposta honesta é "não tanto quanto a proporção de parâmetros sugere". O pipeline de treinamento do Kolibri rendeu-lhe uma execução de pré-treinamento de 20 trilhões de tokens em 768 NVIDIA B200s ao longo de 21 dias, e a própria tabela comparativa da Aleph Alpha, com o Kolibri em esforço de raciocínio alto, coloca-o em 75,5 na média em inglês e 70,8 na média em alemão de uma comparação de quatorze modelos — em que ele perde para um modelo denso de 27 bilhões de parâmetros da Alibaba na maioria das linhas. As alegações de destaque do Granite 4.2 3B são suas próprias: AIME 2025 em 78,33, GPQA em 54,80, LiveCodeBench v6 em 69,71 e MMLU-Pro em 67,84, todos relatados pela IBM e não reproduzidos. Suítes diferentes, harnesses diferentes, fornecedores diferentes. Não existe nenhum número com o mesmo harness para este par em lugar algum, e não vamos inventar um.

Onde cada um realmente se destaca

Execute o Granite 4.2 3B se a sua restrição for a máquina. Com 6–8 GB em bfloat16, ou menos de 2 GB quantizado, ele cabe em um laptop, em uma única GPU de workstation ou em uma caixa de borda isolada (air-gapped) que nunca verá duas H100s. Ele é servido por cinco runtimes diferentes, incluindo Ollama e GGUF, o que importa quando o alvo da implantação é o laptop de outra pessoa, e não o seu próprio rack. E seu model card é excepcionalmente confiável justamente porque a IBM registrou o que deixou de fora. Um fornecedor que se recusa a reivindicar resultados do SWE-bench para um modelo de 3B está dizendo onde o modelo para.

Execute o Kolibri se o corpus for o ponto central e o hardware existir. Uma equipe com contratos em alemão, documentação técnica ou processos administrativos, um nó existente com duas GPUs e a exigência de que os pesos nunca saiam do edifício é exatamente para quem este lançamento foi projetado. A janela nativa de 262.144 tokens, o cache KV FP8, os quatro níveis de esforço e o caminho de chamada de ferramentas do Hermes apontam todos para fluxos de trabalho de documentos, e não para chat. O tokenizador bilíngue faz parte do mesmo argumento: a Aleph Alpha relata 4,90 bytes médios por token em texto web alemão, contra 4,35 para o GPT-5 e 3,28 para o Kimi K3, todos medidos pelo fornecedor em seu corpus, e mais caracteres por token é um efeito direto no custo de inferência, e não uma pontuação. Se isso se mantiver, acumula-se em cada página que você processa.

A assimetria que ninguém anuncia está nos dados. A IBM publicou os pesos do Granite 4.2 3B e um relato técnico detalhado de como o modelo foi construído, mas não os dados de treinamento. A Aleph Alpha publicou o pipeline, a proveniência dos dados e a cifra de energia junto com os pesos do Kolibri — 20 trilhões de tokens de pré-treinamento, 9,5×10² MWh, incluindo a sobrecarga do data center e excluindo o ajuste fino supervisionado e o aprendizado por reforço. Para uma equipe que precisa responder "de onde veio o texto deste modelo", essa diferença não é cosmética.

A realidade do roteamento para ambos

Nenhum dos dois modelos está hoje num catálogo alojado. O Kolibri não tem sequer um SKU de API de fornecedor — o lançamento é composto por pesos mais um relatório técnico — e o Granite 4.2 3B é distribuído como pesos para cinco stacks de runtime, sem endpoint alojado da IBM. Ambas são propostas de auto-alojamento, e a questão prática para a maioria das equipas não é qual delas adotar, mas sim se a carga de trabalho justifica possuir qualquer uma delas.

É aí que uma camada de roteamento justifica seu lugar, mesmo para modelos que ela não carrega. Examinamos o catálogo do OrcaRouter com todas as grafias de ambos os nomes de modelos, e nem o Kolibri nem o Granite 4.2 3B estão lá, então não vamos fingir o contrário. O que o OrcaRouter oferece é a forma barata de descobrir se a decisão de hardware se justifica antes de você tomá-la: aponte um caminho de teste para um pequeno nível de mixture-of-experts que já está roteado — a variante Gemma 4 26B-A4B a US$ 0,06 por milhão de tokens de entrada e US$ 0,33 por milhão de saída, com uma janela de 262.144 tokens — e veja se sua carga de trabalho de documentos em alemão realmente precisa do que o Kolibri oferece, em uma única chave compatível com OpenAI, pelo preço de tabela do provedor sem nada acrescentado. Se precisar, você compra as GPUs com evidências, e não com um palpite. Se não precisar, você acabou de economizar um pedido de hardware.

O veredito, e o que o mudaria

Isto não é um confronto com um vencedor. Kolibri e Granite 4.2 3B respondem a perguntas diferentes em faixas de preço diferentes, e a única classificação honesta é por restrição: se a restrição for hardware, Granite 4.2 3B é o único dos dois que se qualifica. Se a restrição for trabalho com documentos de registro regulatório alemão em ambiente local, Granite 4.2 3B nunca esteve na disputa e Kolibri é o artefato mais interessante — um lançamento legítimo de pesos abertos de 78B, Apache 2.0, com o pipeline de dados e o tokenizador publicados junto aos pesos.

Duas coisas resolveriam a comparação. Uma execução independente do Kolibri em uma tarefa de QA documental em alemão testaria a alegação que o lançamento foi realmente criado para fazer, já que nenhum leaderboard a mede atualmente. E uma reprodução independente dos números de raciocínio do Granite 4.2 3B diria se uma máquina de classe laptop consegue se manter no subconjunto da sua carga de trabalho que nunca precisou de 78 bilhões de parâmetros em primeiro lugar. Até que uma dessas aconteça, compre por restrição, não por contagem de parâmetros.