Colibri é a prova de que você não precisa de um datacenter para conversar com um modelo de escala frontier — você precisa de um laptop, um disco rápido e um uso muito disciplinado da memória.
O projeto executa GLM-5.2, um modelo Mixture-of-Experts com 744 bilhões de parâmetros, em uma máquina de consumo com apenas ~25GB de RAM. Sem cluster, sem H100s alugadas, sem Mac com 256GB de memória unificada. Apenas um arquivo C fazendo algo inteligente com a forma como os modelos MoE realmente usam seus pesos.
A ideia
Um modelo MoE de 744B não toca os 744B parâmetros em cada token. GLM-5.2 ativa apenas ~40B parâmetros por token — e desses, apenas ~11GB mudam de um token para o próximo (os routed experts). O resto é estruturalmente constante.
Colibri divide o modelo exatamente por essa linha:
- A parte densa — attention, shared experts, embeddings, ~17B params — fica residente em RAM em int4 (~9.9GB).
- Os 21.504 routed experts (75 MoE layers × 256 experts, mais o MTP head, ~19MB cada um em int4) vivem em disco (~370GB) e são streamados sob demanda, apoiados por um cache LRU por layer, um hot-store opcional fixado e o page cache do SO como uma segunda camada gratuita.
Todo o motor é um único arquivo C, c/glm.c, com cerca de 1.300 linhas, mais alguns headers pequenos. Sem BLAS, sem Python em runtime, sem GPU.
O que está implementado
Isso não é uma reimplementação brinquedo. O forward pass do repo — glm_moe_dsa — é validado token-exato contra um oracle de transformers (32/32 em teacher-forcing, 20/20 em greedy decoding contra um modelo tiny-random construído com a arquitetura real). Além do forward pass core:
- MLA attention com KV-cache comprimido: 576 floats por token em vez de 32.768 — uma redução de 57x, porque GLM-5.2 usa 64 heads sem GQA.
- Router sigmoid no estilo DeepSeek-V3 (noaux_tc, routed_scaling_factor), shared expert, padrão de first-3-dense-layers.
- Decodificação especulativa MTP nativa — GLM-5.2 vem com seu próprio multi-token-prediction head, que esboça tokens que o modelo principal verifica em um único forward batcheado. O autor relata 2.0 tokens/forward com 100% de aceitação em texto estruturado, e é lossless: a saída é idêntica ao greedy decoding simples.
- Kernels de quantização para int8/int4/int2 com escalas por linha e AVX2, dequant-on-use.
- Um tokenizer BPE byte-level escrito em C (estilo GPT-2, Unicode-aware, 320k merges) — sem dependência de Python nem para tokenizar.
- Segurança em RAM: o cache expert se auto-dimensiona a partir de
MemAvailableao iniciar, assim o assassino de OOM não tem voto.
Números (máquina de dev do autor: WSL2, 12 cores, 25GB RAM, NVMe via VHDX)
| Métrica | Valor |
|---|---|
| Modelo em disco (contentor int4) | ~370GB |
| RAM residente (densa, int4) | 9.9GB |
| Tempo de carregamento | ~30s |
| Peak RSS durante o chat | ~20GB |
| Custo de decode a frio | ~11GB de leituras de disco/token |
| Teto de disco nesta máquina | ~1GB/s → ~0.05–0.1 tok/s a frio |
| Especulação MTP | 2.0 tok/forward |
Lento, por design e por hardware. O ponto não é throughput — é que um modelo frontier-class de 744B responde corretamente em uma máquina que custa menos que o ventilador de um único H100. O repo inclui suas próprias projeções de back-of-envelope para hardware melhor — setups com NVMe PCIe4/5 caem em algum ponto entre 0.5 e 4 tok/s, e uma workstation com 128–256GB de RAM com um hot expert set principalmente em cache entra no intervalo de 5-15 tok/s, terreno interativo. São estimativas do próprio projeto, não medições independentes, e convida as pessoas a enviar números reais.
Quickstart
cd c
./setup.sh # verifica gcc/OpenMP, compila, executa self-tests
# converta o modelo (resumível, precisa de ~400GB livres em ext4/NVMe):
./coli convert # baixa de zai-org/GLM-5.2-FP8
# converse (o orçamento de RAM e o cache expert se auto-dimensionam):
COLI_MODEL=/path/to/glm52_i4 ./coli chat
Há também um build int4 pré-convertido no Hugging Face se preferir pular a conversão FP8→int4 (que de outra forma faz stream e apaga shards de 5GB de um em um, assim o checkpoint completo de 756GB nunca precisa existir inteiro em disco).
Botões úteis: --topp 0.7 para adaptive expert top-p (30–40% menos I/O de disco), THINK=1 para o bloco de reasoning de GLM-5.2, DRAFT=n para a profundidade do draft MTP, e STATS=f / PIN=f PIN_GB=g para registrar quais experts você realmente usa e fixar os mais quentes em RAM livre — o motor fica mais rápido quanto mais o usa.
Onde isso se encaixa
A maioria dos caminhos locais para GLM-5.2 assumem hardware sério: o dynamic GGUF de Unsloth quer um Mac com 256GB+ de memória unificada ou uma workstation multi-GPU para chegar a um único dígito de tokens por segundo. Colibri aposta o oposto — tratar a RAM como o recurso escasso e deixar um NVMe rápido carregar o peso. Não é um substituto para um stack de inferência bem recursado, mas como forma de fazer falar um modelo open-weights frontier real em hardware que você já tem, é um ângulo genuinamente distinto sobre LLMs locais self-hosted — e vale a pena testá-lo em sua própria máquina para ver onde aterrissa.
O projeto é Apache 2.0 (os pesos de GLM-5.2 são MIT de Z.ai), é construído por um único desenvolvedor, e está ganhando tração no GitHub desde o lançamento.
Alguém já testou em seu próprio laptop? Conte-nos qual tok/s você conseguiu e com qual hardware.