Colibrì põe modelo de 744 bilhões de parâmetros em PC comum

O modelo cabe na RAM porque não usa tudo

O GLM-5.2 usa uma arquitetura Mixture-of-Experts. Embora tenha 744 bilhões de parâmetros, ativa cerca de 40 bilhões por token. Só aproximadamente 11 GB mudam entre tokens, porque essa parte contém os especialistas roteados.

O Colibrì mantém a parte densa na RAM. Atenção, especialistas compartilhados e embeddings somam cerca de 17 bilhões de parâmetros e ocupam 9,9 GB em int4. Os 21.504 especialistas roteados ficam no disco, em cerca de 370 GB. Cada um ocupa aproximadamente 19 MB em int4.

O programa lê do armazenamento apenas os especialistas necessários. A equipe escreveu o motor em C puro e eliminou dependências de outros engines. O projeto trata VRAM, RAM e armazenamento como uma hierarquia única de memória.

A versão exibida na página do projeto inicia o GLM-5.2 em 32 segundos e mantém 9,9 GB residentes. Em seis RTX 5090, o painel mostra 4 tok/s, tempo até o primeiro token de 1,6 segundo e nenhum acesso ao disco. Esse resultado não representa o computador de 32 GB.

O debate no Hacker News alcançou 937 pontos e 240 comentários. A página coletou quatro comentários para comparação técnica. O conflito não está em saber se o método funciona, mas em decidir quando a velocidade deixa de servir para uso real.

A velocidade separa demonstração de ferramenta

O autor do projeto priorizou fazer o modelo responder, mesmo devagar. Ele também investigou MTP e uma possível implementação de DSA para contexto longo. No computador com 32 GB de RAM, a execução chegou a 0,1 tok/s.

Para walrus01, esse número muda o caso de uso. “Minha principal dúvida é se, quando colocado em uso prático, isso pode ser medido em tokens por segundo ou se será mais como 1 token por minuto”, escreveu. Ele considera modelos locais a 1 tok/s úteis para tarefas que rodam durante a noite, mas diz que 0,05 a 0,1 tok/s “não é realmente utilizável para muita coisa”.

A crítica não rejeita o desenho. “Acho que este é um projeto fantástico em conceito geral”, afirmou walrus01, que quer ver modelos de 350B a 900B rodando localmente em hardware acessível. A proposta, para ele, é ler os pesos no SSD NVMe a cada token, em vez de carregar o modelo inteiro.

shrinks99 concordou com o valor técnico, mas manteve a ressalva prática. “É ótimo ver pessoas rodando esse enorme lançamento FOSS em uma máquina comum, mesmo que não seja terrivelmente prático neste momento”, escreveu. Ele afirmou que sua empresa testa o GLM-5.2 localmente em hardware “absurdamente caro”.

Cieric seguiu caminho parecido dentro do llama.cpp. Em vez de escolher manualmente o que fica na memória, ele usou mmapping para mapear o modelo inteiro e deixou o kernel do Linux administrar os dados. Seu teste limitou o llama.cpp a 16 GB dos 32 GB disponíveis, e a estimativa teórica chegou a 1,8 tok/s com Medusa, embora as cabeças adicionais ainda não estivessem totalmente treinadas.

Os comentários convergem em um ponto: mover pesos do armazenamento pode viabilizar modelos que não cabem na RAM. kodablah descreveu a mesma estratégia em geração de imagem e vídeo, com um orçamento de VRAM e streaming de pesos por LRU. Segundo ele, mover bytes mapeados por mmap entre disco e VRAM custa menos que o cálculo em modelos menores, especialmente com pipelining e double-buffering.

O que continua aberto é a distância entre executar e trabalhar. O Colibrì garante que a falta de memória rápida reduz a velocidade, mas não altera silenciosamente a precisão nem a semântica do router. Quem decide adotar a técnica precisa medir tempo por token, tempo de inicialização, uso do disco e duração total da tarefa. Para uma tarefa noturna, 0,1 tok/s pode bastar; para interação contínua, o mesmo número pode inviabilizar o sistema.