O novo modelo open weight alemão de 78B (Kolibri-1) roda a 126 tokens/s em uma GPU (testei a fundo)

Autoria: Prompt Engineer 48 · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Germany’s New 78B Open Model (Kolibri-1) Runs at 126 Tokens/Sec on ONE GPU (I Tested It Hard) · Canal: Prompt Engineer 48 · 15:39 · Assistir no YouTube

Tópicos: Avaliação e benchmarks de IA, Engenharia de prompts e contexto, Inferência e otimização de modelos, Modelos locais e open source

Resumo

O vídeo testa o Kolibri-1, modelo de raciocínio MoE da Aleph Alpha, em uma GPU A100 usando uma versão Q4 para GGUF e um Llama.cpp com patch. O modelo atingiu 126,45 tokens/s na geração e demonstrou bom desempenho em matemática, tool calling e recuperação de informações em contextos longos. Porém, tende a gastar muitos tokens pensando, teve resultados inconsistentes em tarefas visuais e errou fatos de conhecimento geral. O apresentador conclui que pode ser uma boa opção para documentos longos em alemão e inglês, mas recomenda cautela para programação e perguntas de memória factual.

Pontos-chave

O Kolibri-1 tem 78,1 bilhões de parâmetros no total, mas ativa 3,46 bilhões por token.
Na versão Q4 em uma A100 de 80 GB, a geração chegou a 126,45 tokens/s no Llama bench e ficou em torno de 118 tokens/s nos testes com reasoning ativado.
A versão GGUF requer um Llama.cpp com patch; uma compilação padrão não carrega a arquitetura.
O modelo resolveu corretamente os testes de matemática apresentados, mas pode consumir o limite de tokens sem produzir uma resposta final quando o reasoning effort é alto.
Nas tarefas visuais feitas por geração de código, houve um teste aprovado, dois resultados parciais e duas falhas.
Em um teste, o modelo chamou duas ferramentas em paralelo e converteu 4:00 p.m. para 16:00 sem instrução explícita.
O contexto de 1 milhão de tokens exige um override no Llama.cpp; sem ele, o contexto foi limitado a 262.144 tokens.
O teste de needle in a haystack recuperou a informação correta em 196 mil e 719 mil tokens.
O modelo recusou inventar o conteúdo de um artigo acadêmico fictício, mas informou incorretamente seu próprio knowledge cutoff e errou detalhes de uma pergunta sobre a final da Copa de 1998.
O apresentador considera o modelo promissor para documentos longos em alemão e inglês, mas não o recomenda, por enquanto, para coding agent ou tarefas que dependam de fatos memorizados.

Capítulos

Início	Capítulo	Resumo
00:00	Apresentação do Kolibri-1 e sua arquitetura	O apresentador introduz o modelo, seus parâmetros ativos, a licença, os idiomas e os detalhes de arquitetura e treinamento.
04:04	Preparação do ambiente e teste de velocidade	O vídeo mostra os requisitos, a compilação do Llama.cpp com patch e a execução da versão Q4 em uma A100.
06:12	Testes de raciocínio e geração visual	O modelo acerta exemplos de matemática, mas pode esgotar o orçamento de tokens e apresenta resultados variados em tarefas visuais.
10:24	Tool calling e contexto longo	O apresentador testa chamadas paralelas de ferramentas, configura o contexto de 1 milhão de tokens e mede o uso de VRAM.
12:01	Recuperação de informação e confiabilidade factual	O modelo recupera a informação oculta em textos longos, mas apresenta limitações em conhecimento factual e no próprio knowledge cutoff.
14:07	Veredito e casos de uso	O apresentador resume os pontos fortes e fracos e avalia para quem o modelo pode ser uma opção adequada.

Citações

Um modelo de 78 bilhões de parâmetros gera mais rápido que a maioria dos modelos densos pequenos na mesma placa, porque só 3,46 bilhões de parâmetros estão trabalhando. — 05:40

Dê a este modelo um orçamento grande de tokens ou reduza o reasoning effort para baixo em tarefas criativas e de programação. — 07:15

O ajuste no Llama.cpp é uma flag: definir o context_length do colibri 1 para 1.048.576. — 11:29

Com um modelo como este, dê documentos para ele ler. Não peça que se lembre de fatos. — 14:07

Se você precisa de documentos longos em alemão e inglês e quer executar o modelo na sua própria máquina, ele é um forte candidato. — 15:08

Conceitos e entidades

Kolibri-1 (modelo): Modelo de raciocínio MoE da Aleph Alpha com 78,1 bilhões de parâmetros totais e 3,46 bilhões ativos por token.
Aleph Alpha (empresa): Empresa que desenvolveu o Kolibri-1 e publicou os resultados de benchmark mencionados no vídeo.
GGUF (conceito): Formato usado no vídeo para executar uma versão quantizada do modelo com Llama.cpp.
llama.cpp (ferramenta): Implementação usada para compilar e executar a versão GGUF do modelo, com um patch para dar suporte à arquitetura.
RunPod (empresa): Serviço usado para alugar uma GPU A100 e realizar os testes.
A100 (ferramenta): GPU de 80 GB de VRAM usada para testar a velocidade e o uso de memória do modelo.
Hugging Face (empresa): Plataforma onde o apresentador disponibilizou o arquivo GGUF usado no vídeo.
needle in a haystack (conceito): Teste de contexto longo que verifica se o modelo consegue recuperar uma informação inserida em meio a um texto extenso.

Tradução completa (pt-BR)

00:00 Certo. Então, uma empresa alemã acabou de lançar um modelo com 78 bilhões de parâmetros, e eu o executei em uma A100, a 118 tokens por segundo. Vale lembrar que apenas 3,46 bilhões desses parâmetros são usados em cada token. Esse é o truque todo, e neste vídeo vamos testar se ele se sustenta. Ele se chama Colibri 1. Tem pesos abertos e foi lançado em 3 de outubro. Agora, já fiz um vídeo separado em que converto os arquivos SafeTensors para GGUF, passo a passo. Esse vídeo tem

00:30 cerca de 7 minutos e meio, e o link está na descrição. O GGUF que criei está no Hugging Face, em Prompt 48 Colibri 1 GGUF. Neste vídeo, vamos pegar a versão Q4 desse repo, alugar uma GPU na RunPod e tentar levá-la ao limite. Então, o que é o Colibri? É um modelo de raciocínio de mistura de especialistas da Aleph Alpha, e Colibri é a palavra alemã para beija-flor. Se você olhar o model card aqui, verá que ele tem 78,1 bilhões de parâmetros no total e 3,46 bilhões ativos por token. A

01:01 licença é Apache 2.0. Os idiomas são alemão e inglês, e o corte de conhecimento é em 18 de junho de 2026. Ele oferece um modo de raciocínio com esforço baixo, médio e alto, além de tool calling. O argumento comercial da empresa é a soberania. Eles dizem que o modelo foi desenvolvido na Alemanha e treinado em infraestrutura na Alemanha e na Finlândia, sob a legislação europeia, para que um hospital ou banco possa executá-lo em suas próprias máquinas, sem que uma parte externa tenha controle. Essa é a alegação deles, e é um verdadeiro diferencial para muitas organizações.

01:32 Agora, vamos ler o arquivo de configuração em vez da página de marketing, porque é lá que está a parte interessante. São 50 camadas: 40 delas usam atenção de janela deslizante, com uma janela de 513 tokens na configuração, e 10 usam atenção completa, uma a cada cinco camadas. O model card diz 512, e a configuração diz 513, então vou seguir a configuração aqui. Cada camada tem 384 especialistas; seis especialistas roteados e um especialista compartilhado são ativados para cada token. É assim que se chega a 78

02:03 bilhões de parâmetros em armazenamento e 3,46 bilhões em computação. E há apenas quatro cabeças de chave e valor, com uma dimensão de cabeça de 128. Juntando esses fatores, o cache fica pequeno. Calculei isso antes de tocar na GPU: para 262 mil tokens. Um arranjo denso normal precisaria de 25 GB de cache em 16 bits, e este arranjo precisa de cerca de cinco. É cinco vezes menor, e vou conferir esse número mais tarde com uma medição real. Quanto ao treinamento, o relatório diz que foram usados 20 trilhões de tokens no pré-treinamento, aproximadamente 62%

02:33 em inglês, 24% em alemão e 14% em código. Depois, 3,44 trilhões de tokens no treinamento intermediário e cerca de 200 bilhões para contexto longo. O hardware foi composto por 768 GPUs B200 durante 21 dias. Eles usaram o otimizador Meon e um método de roteamento que chamam de balanceamento por quantis exatos, para que os especialistas compartilhem o trabalho igualmente. Tudo isso vem do fornecedor. Eu não treinei nada, então considere que é o que eles relatam. Agora, os benchmarks. Tudo o que aparece nesta tela foi informado pela própria Aleph Alpha

03:04 e executado com a estrutura de avaliação própria deles. Eles dizem que a pontuação geral em inglês é 75,5, contra 74,7 do Qwen 3.5 35B com 3B ativos. Em alemão, é 70,8 contra 69,8. No AIME 2025 em inglês, é 96,9. No GPQA Diamond, é 84,3. A mesma tabela também traz más notícias, e mérito deles por publicá-las. A recuperação de informações em contexto fechado é 51, a última posição entre 12 modelos, segundo o texto de Tejas Kumar. No tool calling em várias interações no

03:34 BFCL, a pontuação é 39,8. No SWE-Bench verified, é 66,4. Tejas também aponta que, com 128 mil tokens, a pontuação no Ruler cai para 67,9, embora a pontuação com um milhão de tokens seja maior. Quanto a números independentes, procurei por Colibri no Artificial Analysis, no LM Arena e no Live Bench no dia do lançamento, mas não encontrei nenhum resultado. Portanto, ninguém independente verificou essas tabelas ainda. É por isso que, no restante deste vídeo, vou testar as coisas por conta própria.

04:04 Aqui está o primeiro problema. A forma oficial de executar este modelo é por meio de um plugin vLLM da Aleph Alpha, e o hardware mínimo indicado no model card é de duas GPUs A180 ou uma H200. Os pesos têm cerca de 78 GB em FP8. O model card não menciona Llama.cpp, Llama nem LM Studio em lugar nenhum. Uma versão padrão não consegue carregar a arquitetura. Por isso, o GGUF que publiquei precisa de uma versão corrigida do Llama.cpp, e a correção vem da Hob Forge, que fez o trabalho difícil de adicionar a arquitetura. Crédito a eles,

04:35 o link está no repo. Meu arquivo Q4KM tem 47,45 GB. Se quiser saber como fiz a conversão, veja o outro vídeo. Então, vamos alugar uma GPU. Aqui está uma instância da RunPod com uma A100 SXM, 80 GB de VRAM, por US$ 1,59 por hora. Baixei o arquivo Q4 diretamente para a RAM, clonei o Llama.cpp na mesma revisão do meu model card, apliquei a correção e iniciei a compilação com CUDA. E dá para ver que ela falhou. O CMake diz

05:07 que o compilador CUDA não foi encontrado. O binário NVCC estava na máquina, mas não estava no path. Adicionei-o ao path, passei o local do compilador para o CMake e a segunda compilação foi concluída. Meu model card diz que os backends de GPU não foram verificados porque meus próprios testes naquele vídeo foram apenas em CPU. Portanto, esta é a primeira vez que este arquivo é executado em uma GPU. Certo, Llama bench com todas as camadas transferidas para a GPU. O modelo carrega com 44,19 GB e 78,1 bilhões de parâmetros. O processamento do prompt é de 2.497 tokens por

05:40 segundo. A geração é de 126,45 tokens por segundo. Então, um modelo com 78 bilhões de parâmetros gera mais rápido do que a maioria dos modelos densos pequenos na mesma placa, porque apenas 3,46 bilhões de parâmetros estão em uso. No servidor real, com o raciocínio ativado, observei cerca de 118 tokens por segundo ao longo dos meus testes. Essa parte da promessa se confirma nesta placa. Vamos começar com coisas simples. Primeiro, uma pergunta em alemão: por que a Alemanha foi organizada como uma federação depois de 1945?

06:12 Responda em cinco frases e cite dois artigos da Lei Fundamental. Dá para ver que o alemão é fluente; o modelo cita o artigo 20 e o artigo 30, e ambos existem e dizem o que ele afirma. Agora, matemática. Quantos pares ordenados de números de 1 a 100 têm a soma dos quadrados divisível por 7? Primeiro, fiz uma busca exaustiva no meu laptop, e a resposta é 196. O modelo raciocinou usando os quadrados módulo 7, concluiu que ambos os números precisam ser múltiplos de 7 e respondeu 196.

06:43 Cerca de 3.200 tokens, 27 segundos. Depois, um quebra-cabeça de disposição de cinco pessoas. Minha busca exaustiva indica 10 arranjos. Foi aqui que encontrei o primeiro problema com o modelo. Com esforço de raciocínio alto e um limite de 12 mil tokens, o modelo passou todo o orçamento pensando. O rastro de raciocínio tinha quase 35 mil caracteres, e a resposta final estava vazia. Aumentei o limite para 40 mil tokens e executei de novo. Ele respondeu 10, que está correto, depois de 12.400 tokens e cerca de

07:15 106 segundos. A mesma coisa aconteceu com as tarefas de programação. Pedi um jogo da cobrinha com esforço médio e 40 mil tokens, e recebi 53 mil caracteres de raciocínio e nenhum jogo. Então, o conselho prático é simples: dê a este modelo um orçamento grande de tokens ou reduza o esforço de raciocínio para baixo em tarefas criativas e de programação. Esse é um padrão que quero que você lembre, porque ele volta a aparecer. Agora, a parte visual. Colibri é um modelo de texto. Ele não consegue olhar para imagens, então a forma como testo recursos visuais é pedir que ele

07:45 escreva código que desenhe coisas e depois abrir o resultado em um navegador. Primeiro, Snake com esforço baixo, cerca de 9.700 tokens. Escrevi um pequeno bot que joga lendo o estado do jogo. Dá para ver a pontuação subir até 20, a velocidade passar de 150 milissegundos por etapa para 50, e o recorde ser atualizado. Nenhum erro no console. Este passou. Segundo, um sistema solar animado, 3.100

08:17 tokens. Ele é renderizado, o Sol brilha e os planetas orbitam, mas, se olhar com atenção, há grandes arcos de elipse perdidos atravessando a tela. O controle deslizante fica cortado na parte de baixo, e nem todos os oito planetas aparecem no quadro. Funciona, mas não é bonito. Terceiro, 20 bolas quicando dentro de um hexágono giratório. Ele funciona, a gravidade funciona, e as bolas colidem umas com as outras e com as paredes. Os números nas bolas estão ausentes, e o contorno do hexágono está

08:48 quase invisível. Uma tentativa parcial. Quarto, um explorador de Mandelbrot. Este custou 22.700 tokens, quase 3 minutos, e a tela está completamente preta até mesmo no zoom 1. Isso é uma falha. E, por último, o pelicano andando de bicicleta. Com esforço médio, ele desenhou uma forma arredondada sobre duas rodas. Com esforço alto e 5.600

09:19 tokens, desenhou uma forma de boneco de neve sentada em uma barra, sem bicicleta. A ilustração foi um fracasso. Agora, a parte de que gostei. Pedi uma função Python que mesclasse intervalos com um bloco de autoteste. O modelo a escreveu, eu a executei, e ela falhou no próprio assert. Se você ler o assert, o erro está no teste. Um par invertido é normalizado, então a mesclagem deveria resultar em um intervalo, mas o próprio teste do modelo esperava dois. Colei o erro de volta e disse: “Corrija o que estiver errado.” Uma rodada, cerca de 63

09:51 segundos, e a saída diz que todos os testes passaram. Esse é o ciclo para o qual eu realmente usaria este modelo. Tentei o mesmo ciclo com o Mandelbrot. Disse que a tela ficava preta no zoom 1 e não acrescentei mais nada. Cerca de 16.000 tokens e 4 minutos depois, ele me deu uma versão que desenha o fractal inteiro no zoom 1. O zoom ainda se desloca depois de quatro cliques no mesmo ponto. A visualização acaba no canto da tela. Então, eu diria que isso foi corrigido pela metade.

10:24 Agora, tool calling. Porque foi aqui que o modelo teve o pior desempenho na tabela de benchmark. Dei a ele duas ferramentas: uma para consultar o clima e outra para agendar reuniões, que exige o horário no formato de 24 horas. Depois escrevi: “Agende a reunião às 16h.” Dá para ver que ele chamou as duas ferramentas em paralelo, em uma única rodada. A consulta do clima contém Heidelberg e Celsius, e a chamada para agendar a reunião contém a data e o horário 16:00. Ninguém mandou converter 16h. Ele fez isso por conta própria. Devolvi resultados falsos: 14 °C com chuva fraca, e a segunda rodada compôs a resposta usando apenas esses campos, incluindo o ID da reunião, sem inventar dados.

10:57 Um teste não é um benchmark, então não vou afirmar que 39,8 está errado. Estou dizendo que este teste foi bem executado. Agora, o tamanho do context window, o principal destaque: 1 milhão de tokens, segundo a ficha do modelo. Iniciei o servidor com um contexto de 1 milhão, e o log disse que o contexto do slot excedia o contexto de treinamento do modelo e estava sendo limitado. O slot ficou com 262.144 tokens, não 1 milhão.

11:29 Examinei os metadados do GGUF e encontrei o motivo. O tamanho do contexto está definido como 262.144. Esse valor veio de max_position_embeddings na configuração original. Todas as instruções da própria Alibaba para vLLM dizem que é necessário usar uma substituição para chegar a 1 milhão. Então, é algo que precisamos corrigir na ficha do meu modelo GGUF, e vou acrescentar as instruções para usar a substituição. A correção no llama.cpp é uma única flag: override-kv colibri-1.context_length=1048576.

12:01 Depois disso, o log mostra contexto do slot de 1.048.576, sem limite. Aqui está a verificação que prometi. Carreguei o servidor com diferentes tamanhos de contexto e verifiquei a VRAM. Com contexto de 8.000, 45.929 MB. Com 262.000, 51.137. Com 1.000.000, 67.267. A diferença entre 8.000 e 262.000 é 5,09 GB. Minha previsão com base na

12:31 configuração era 4,84. Isso fica dentro de uma margem de cerca de 5%. Então, um cache de 1 milhão de tokens cabe em uma A100 com pesos Q4. Caber é diferente de funcionar, então o próximo teste é o da agulha. Para o teste da agulha no palheiro, crio um texto longo com frases repetitivas e sem conteúdo relevante e insiro uma linha a 46% do texto. A linha diz que a frase secreta do cofre é indigo pangolin 77. Depois, no final, peço a frase secreta. Com cerca de 196.000 tokens, levou 122

13:01 segundos, e a resposta foi exatamente indigo pangolin 77. Apenas 323 caracteres de raciocínio. Depois, o teste maior, com a substituição ativada: cerca de 719.000 tokens, a mesma frase secreta a 46% do texto. Levou 914 segundos, cerca de 15 minutos, e a geração desacelerou para 50 tokens por segundo nessa profundidade. A resposta foi exatamente indigo pangolin 77. A ficha diz 1 milhão de tokens. Testei com 719.000 e ele encontrou a agulha.

13:34 Dois testes de honestidade. Primeiro, um artigo falso. Pedi que resumisse um artigo da NeurIPS 2023 que inventei, com autores fictícios. Ele não inventou um resumo. Disse que não tinha o artigo e que ele talvez fosse hipotético. Ótimo. Mas, na mesma resposta, disse que seu corte de conhecimento era em outubro de 2023. A ficha do modelo diz junho de 2026, então ele não sabe qual é seu próprio corte de conhecimento. Segundo, perguntas de conhecimento sem consulta. Quem venceu a final da Copa do Mundo de 1998? França, por 3 a 0 contra o Brasil, correto. A capital de Burkina Faso

14:07 e o ano da independência, corretos. Mas os autores dos gols estavam errados. Ele disse que Zidane marcou um pênalti e que Blanc marcou. Na partida real, Zidane marcou dois gols de cabeça e Petit marcou o terceiro; Blanc não marcou na final. Isso corresponde ao que a tabela do fornecedor diz sobre conhecimento sem consulta. Com um modelo como este, forneça documentos para ele ler. Não peça que se lembre de fatos. Então, qual é o veredito? Vou listar. O que funcionou? 126 tokens por segundo em Q4

14:37 em uma A100, correto. Matemática e lógica, chamadas paralelas de ferramentas bem executadas com conversão de argumentos, um ciclo de autorreparo que corrigiu o próprio erro em uma rodada, um teste da agulha perfeito com 196.000 tokens e, novamente, com 719.000, usando a substituição. O que não funcionou? Ele pensa demais e consome todo o orçamento com esforço médio e alto. Dois dos cinco testes visuais falharam completamente e outros dois foram apenas parciais. Os fatos sem consulta não são confiáveis, e a janela de 1 milhão de tokens fica desativada no GGUF até você usar a substituição.

15:08 Sobre a GPU: o arquivo Q4 tem 44 GB de pesos. Em uma placa de 48 GB, mal cabe com um contexto curto. Medi 45,9 GB em uso com 8.000 tokens. Uma placa de 80 GB dá folga. Qualquer placa menor exige descarregar parte para a memória do sistema, e não testei isso, então não posso dizer qual seria a velocidade. Para quem é? Se você precisa trabalhar com documentos longos em alemão e inglês e quer executar o modelo na sua própria máquina, ele é uma ótima opção. Se quer um agent de programação ou um modelo que se lembre de fatos, eu procuraria outra opção por enquanto.

15:39 Então, neste vídeo, vimos o Kolibri-1 rodando em uma GPU real, com um teste de velocidade, um teste de contexto e uma série de exemplos difíceis, incluindo os que falharam. Se quiser ver como criei o GGUF, assista ao vídeo sobre a conversão. Mostro o processo passo a passo, de SafeTensors para GGUF. E, se quiser ler mais, vou deixar o link para a página principal na descrição abaixo. Conte como foi se você experimentar no seu próprio sistema. Vejo você em outro vídeo. Confira o próximo vídeo.

Transcrição original

[00:00] All right. So, a German company just released a 78 billion parameter model and I ran it on 1 A100 at 118 tokens per second. Mind you, only 3.46 billion of those parameters work on each token. That is the whole trick and in this video we are going to test whether the trick holds up. It is called Colibri 1. It is open weight and it came out on the 3rd of October. Now, I already made a separate video where I convert the safe tensors files into GGUF step by step. That one is

[00:30] about 7 and 1/2 minutes and the link is in the description. The GUF I made is on Hugging Face under prompt 48 Colibri 1 GGUF. In this video we are going to take the Q4 version from that repo, rent a GPU on RunPod, and try to break it. So, what is Colibri? It is a mixture of experts reasoning model from Aleph Alpha and Colibri is the German word for hummingbird. If you look at the model card here, it has 78.1 billion parameters in total and 3.46 billion active per token. The

[01:01] license is Apache 2.0. The languages are German and English and the knowledge cutoff is the 18th of June 2026. It supports a reasoning mode with low, medium, and high effort and it supports tool calling. The company pitch is sovereignty. They say it was built in Germany, trained on infrastructure in Germany and Finland under European law, so hospital or a bank can run it on their own machines with no outside party in control. That is their claim and it is a real selling point for a lot of organizations.

[01:32] Now, let’s go ahead and read the config file instead of the marketing page because that is where the interesting part is. There are 50 layers, 40 of them use sliding window attention with a window of 513 tokens in the config and 10 of them use full attention, one in every five layers. The model card says 512 and the config says 513, so I’m going with the config here. Each layer has 384 experts, six routed experts plus one shared expert fire for every token. That is how you get 78

[02:03] billion in storage and 3.46 billion in compute. And there are only four key value heads with a head dimension of 128. Put those together and the cache gets small. I worked it out before touching the GPU at 262,000 tokens. A normal dense layout would need 25 GB of cache in 16-bit and this layout needs about five. That is five times smaller and I will check that number later with a real measurement. On training, the report says 20 trillion tokens in pre-training, roughly 62%

[02:33] English, 24% German, and 14% code. Then 3.44 trillion tokens in mid-training and about 200 billion for long context. The hardware was 768 B200 GPUs for 21 days. They used the Meon optimizer and a routing method they call exact quantile balancing so that the experts share the work evenly. All of this is from the vendor. I did not train anything so take it as what they report. Now the benchmarks. Everything on this screen is self-reported by Aleph Alpha

[03:04] run with their own evaluation framework. They say the overall English score is 75.5 against 74.7 for a Qwen 3.5 35B with 3B active. German is 70.8 against 69.8. AIME 2025 in English is 96.9. GPQA Diamond is 84.3. The same table also has the bad news and credit to them for printing it. Close book retrieval is 51, the last of 12 models according to Tejas Kumar’s write-up. Multi-turn tool calling on

[03:34] BFCL is 39.8. SWE-Bench verified is 66.4. Tejas also points out that at 128,000 tokens, the ruler score dips to 67.9 even though the million token score is higher. As for independent numbers, I searched for Colibri on artificial analysis, LM Arena, and Live Bench on the day of release, and I could not find any. So, nobody independent has verified these tables yet. That is why the rest of this video is me testing things myself.

[04:04] Here’s the first problem. The official way to run this model is a vLLM plugin from Aleph Alpha, and the minimum hardware on the card is two A180 gig cards or one H200. The weights are about 78 GB in FP8. The card does not mention Llama.cpp or Llama or LM Studio anywhere. A stock build cannot load the architecture. That is why the GGUF I published needs a patched Llama.cpp, and the patch comes from Hob Forge, who did the hard work of adding the architecture. Credit to them,

[04:35] it is linked in the repo. My Q4KM file is 47.45 GB. If you want to know how I converted it, that is the other video. So, let’s go ahead and rent a GPU. This is a run pod with one A100 SXM 80 GB of VRAM at $1.59 an hour. I downloaded the Q4 file straight into RAM, cloned Llama.cpp at the same revision as my model card, applied the patch, and started the CUDA build. And you can see it failed. CMake says

[05:07] the CUDA compiler is not found. The NVCC binary was on the machine, but it was not on the path. I added it to the path, passed the compiler location to CMake, and the second build went through. My model card says GPU backends are unverified because my own tests in that video were CPU only. So, this is the first time this file runs on a GPU. All right, Llama bench with every layer offloaded to the GPU. The model loads as 44.19 GB, 78.1 billion parameters. Prompt processing is 2,497 tokens per

[05:40] second. Generation is 126.45 tokens per second. So, a 78 billion parameter model generates faster than most small dense models do on the same card because only 3.46 billion parameters are working. In the real server with reasoning on, I saw about 118 tokens per second across my tests. That part of the promise is real on this card. Let’s start with simple things. First, a German question. Why Germany was organized as a federation after 1945?

[06:12] Answer in five sentences and name two articles of the basic law. You can see that the German is fluent and it names article 20 and article 30 and both of those exist and say what it claims. Next, math. How many ordered pairs of numbers from 1 to 100 have a square sum divisible by 7? I brute-forced this on my laptop first and the answer is 196. The model reasoned through the squares modulo 7, worked out that both numbers must be multiples of 7 and answered 196.

[06:43] About 3,200 tokens, 27 seconds. Then, a seating puzzle with five people. My brute force says 10 arrangements. This is where I hit the first problem with the model. With high reasoning effort and a 12,000 token limit, the model spent the whole budget thinking. The reasoning trace was almost 35,000 characters and the final answer was empty. I raised the limit to 40,000 tokens and ran it again. It answered 10, which is correct after 12,400 tokens and about

[07:15] 106 seconds. The same thing happened with the coding tasks. I asked for a snake game with medium effort and 40,000 tokens and I got 53,000 characters of thinking and no game. So, the practical advice is simple. Give this model a big token budget or lower the reasoning effort to low for creative and coding tasks. This is a pattern I want you to remember because it comes back. Now, the visual part. Colibri is a text model. It cannot look at images, so the way I test visuals is by asking it to

[07:45] write code that draws things and then I open the result in a browser. Snake first with low effort, about 9,700 tokens. I wrote a small bot that plays it by reading the game state. You can see the score climbing to 20, the speed going from 150 milliseconds per step down to 50, and the high score updates. No errors in the console. This one is a pass. Second, an animated solar system, 3,100

[08:17] tokens. It renders, the sun glows, planets orbit, but if you look carefully, there are huge stray ellipse arcs crossing the screen. The slider is clipped at the bottom, and not all eight planets are in the frame. It works, it is not pretty. Third, 20 balls bouncing inside a rotating hexagon. It runs, gravity works, balls collide with each other and the walls. The numbers on the balls are missing and the hexagon outline is

[08:48] barely visible. A partial pass. Fourth, a Mandelbrot explorer. This one cost 22,700 tokens, nearly 3 minutes, and the canvas is completely black even at zoom one. That is a fail. And last, the pelican riding a bicycle. At medium effort, it drew a blob on two wheels. With high effort and 5,600

[09:19] tokens, it drew a snowman shape sitting on a barbell, no bicycle. The art is a fail. Now, the part I like. I asked for a Python function that merges intervals with a self-test block. The model wrote it, I ran it, and it crashed on its own assert. If you read the assert, the bug is in the test. A reverse pair gets normalized, so the merge should give one interval and the model’s own test expected two. I pasted the error back and said, “Fix whatever is wrong.” One round, about 63

[09:51] seconds, and the output says all tests pass. That is the loop I would actually use this model for. I tried the same loop on the Mandelbrot. I told it the canvas is black at zoom one and nothing else. About 16,000 tokens and 4 minutes later, it gave me a version that draws the full fractal at zoom one. The zoom still drifts after four clicks on the same spot. The view ends up in the corner of the screen. So, I would call that half fixed.

[10:24] Tool calling next. Because this is where the benchmark table was weakest. I gave it two tools, a weather lookup and a meeting booker that wants time in 24-hour format. Then I wrote, “Book the meeting at 4:00 p.m.” You can see it called both tools in parallel in one turn. The weather call has Heidelberg and Celsius, and the meeting call has the date and time 16:00. Nobody told it to convert 4:00 p.m. It did that on its own. I fed fake results back, 14° with light

[10:57] rain, and the second turn composed the answer using only those fields, including the meeting ID, no invented data. One test is not a benchmark, so I’m not going to claim 39.8 is wrong. I’m saying this one was clean. Now, context length, the headline feature, 1 million tokens, says the card. I started the server with a context of 1 million, and the log said the slot context exceeds the training context of the model and is capping. The slot was 262,144 tokens, not a million.

[11:29] I dumped the GG GUF metadata and found the reason. Context length is stored as 262,144. That value came from max position embeddings in the original config. All of Alpha’s own instructions for VL LM say you need an override to get the million. So, this is a thing we have to fix in my GGUF model card and I will add the override instructions there. The fix on llama.cpp is one flag, override kv colibri 1.context_length set to 1,048,576.

[12:01] After that, the log says slot context 1,048,576, no capping. Here’s the check I promised. I loaded the server at different context sizes and read the VRAM. At 8,000 context, 45,929 MB. At 262,000, 51,137. At 1,000,067,267. The difference between 8,000 and 262,000 is 5.09 GB. My prediction from the

[12:31] config was 4.84. That is within about 5%. So, a full million tokens of cache fits on 1A 100E with a Q4 weights. Fitting is different from working, so the next test is the needle. For the needle in a haystack, I build a long text of boring repeated sentences and plant one line at 46% depth. The line says the secret vault passphrase is indigo pangolin 77. Then I ask for the passphrase at the end. At about 196,000 tokens, it took 122

[13:01] seconds and the answer was exactly indigo pangolin 77. Only 323 characters of reasoning. Then the big one with the override on, about 719,000 tokens, same passphrase at 46% depth. It took 914 seconds, about 15 minutes, and generation slowed to 50 tokens per second at that depth. The answer was indigo pangolin 77 exactly. The card says 1 million tokens. I tested 719,000 and it found the needle.

[13:34] Two honesty tests. First, a fake paper. I asked it to summarize a NeurIPS 2023 paper that I made up with invented authors. It did not invent a summary. It said it did not have the paper and that it might be hypothetical. Good. But in the same answer it said its knowledge cutoff is October 2023. The model card says June 2026, so it does not know its own cutoff. Second, closed book trivia. Who won the 1998 World Cup final? France 3-0 against Brazil, correct. Capital of Burkina Faso

[14:07] and independence year, correct. But the goal scorers were wrong. It said Zidane scored a penalty and that Blanc scored. In the real match, Zidane scored two headers and Petit scored the third and Blanc did not score in the final. That matches what the vendor table says about closed book knowledge. With a model like this, give it documents to read. Do not ask it to remember facts. So, what is the verdict? Let me put it as a list. What worked? 126 tokens per second at Q4

[14:37] on 1A 100, correct. Math and logic, clean parallel tool calling with argument conversion, a self-repair loop that fixed its own bug in one round, a perfect needle at 196,000 tokens, and again at 719,000 with the override. What did not work? It overthinks and burns the whole budget on medium and high effort. Two of the five visual tests failed outright and two more were only partial. Closed book facts are unreliable and the million token window is switched off in the GUF until you override it.

[15:08] About the GPU, the Q4 file is 44 GB bytes of weights. On a 48 GB card, it barely fits at a short context. I measured 45.9 GB in use at 8,000 tokens. An 80 GB card is comfortable. Anything smaller needs offloading to system memory and I did not test that so I cannot tell you the speed. Who is this for? If you need German and English long documents and you want to run it on your own machine, it is a strong candidate. If you want a coding agent or a model that remembers facts, I would look elsewhere for now.

[15:39] So in this video we have seen Colibri 1 running on a real GPU with a speed test, a context test and a set of tough examples including the ones that failed. If you want to see how I made the GBUF, watch the conversion video. I show it step by step from safe tensors to GBUF. And if you’re interested in reading further, I will link to the main page in the description below. Let me know how it goes if you try it on your own system. I will see you in another one. Check out the next video.