Colibrì es la prueba de que no necesitás un datacenter para hablar con un modelo de escala frontier — necesitás una laptop, un disco rápido, y un uso muy disciplinado de la memoria.
El proyecto corre GLM-5.2, un modelo Mixture-of-Experts de 744 mil millones de parámetros, en una máquina de consumo con tan solo ~25GB de RAM. Sin cluster, sin H100s alquiladas, sin Mac con 256GB de memoria unificada. Solo un archivo C haciendo algo inteligente con cómo los modelos MoE realmente usan sus pesos.
La idea
Un modelo MoE de 744B no toca los 744B parámetros en cada token. GLM-5.2 activa solo ~40B parámetros por token — y de esos, solo ~11GB cambian de un token al siguiente (los routed experts). El resto es estructuralmente constante.
Colibrì divide el modelo exactamente por esa línea:
- La parte dense — attention, shared experts, embeddings, ~17B params — queda resident en RAM a int4 (~9.9GB).
- Los 21.504 routed experts (75 MoE layers × 256 experts, más el MTP head, ~19MB cada uno a int4) viven en disco (~370GB) y se streamean on demand, respaldados por un LRU cache por layer, un hot-store pineado opcional, y el page cache del OS como una segunda capa gratis.
Todo el motor es un solo archivo C, c/glm.c, de unas 1.300 líneas, más un par de headers chicos. Sin BLAS, sin Python en runtime, sin GPU.
Lo que está implementado
Esto no es una reimplementación de juguete. El forward pass del repo — glm_moe_dsa — está validado token-exact contra un oracle de transformers (32/32 en teacher-forcing, 20/20 en greedy decoding contra un modelo tiny-random construido con la arquitectura real). Más allá del forward pass core:
- MLA attention con KV-cache comprimido: 576 floats por token en vez de 32.768 — una reducción de 57x, porque GLM-5.2 usa 64 heads sin GQA.
- Router sigmoid estilo DeepSeek-V3 (noaux_tc, routed_scaling_factor), shared expert, patrón de first-3-dense-layers.
- Native MTP speculative decoding — GLM-5.2 viene con su propio multi-token-prediction head, que draftea tokens que el modelo principal verifica en un solo forward batcheado. El autor reporta 2.0 tokens/forward con 100% de acceptance en texto estructurado, y es lossless: el output es idéntico al greedy decoding plano.
- Quantization kernels para int8/int4/int2 con per-row scales y AVX2, dequant-on-use.
- Un tokenizer BPE byte-level escrito en C (estilo GPT-2, Unicode-aware, 320k merges) — sin dependencia de Python ni para tokenizar.
- RAM safety: el expert cache se auto-dimensiona desde
MemAvailableal arrancar, así que el OOM killer no tiene voto.
Números (dev box del autor: WSL2, 12 cores, 25GB RAM, NVMe vía VHDX)
| Métrica | Valor |
|---|---|
| Modelo en disco (int4 container) | ~370GB |
| RAM resident (dense, int4) | 9.9GB |
| Tiempo de carga | ~30s |
| Peak RSS durante el chat | ~20GB |
| Costo de decode en cold | ~11GB de disk reads/token |
| Techo de disco en esta máquina | ~1GB/s → ~0.05–0.1 tok/s cold |
| MTP speculation | 2.0 tok/forward |
Lento, por diseño y por hardware. El punto no es throughput — es que un modelo frontier-class de 744B responde correctamente en una máquina que cuesta menos que el fan de un solo H100. El repo incluye sus propias proyecciones de back-of-envelope para hardware mejor — setups con NVMe PCIe4/5 caen en algún punto entre 0.5 y 4 tok/s, y una workstation con 128–256GB de RAM con un hot expert set mayormente cacheado entra en el rango de 5-15 tok/s, terreno interactivo. Son estimaciones propias del proyecto, no mediciones independientes, e invita a la gente a mandar números reales.
Quickstart
cd c
./setup.sh # chequea gcc/OpenMP, compila, corre self-tests
# convertí el modelo (resumable, necesita ~400GB libres en ext4/NVMe):
./coli convert # descarga desde zai-org/GLM-5.2-FP8
# chateá (el RAM budget y el expert cache se dimensionan solos):
COLI_MODEL=/path/to/glm52_i4 ./coli chat
Hay también un build int4 pre-convertido en Hugging Face si preferís saltarte la conversión FP8→int4 (que de otra forma streamea y borra shards de 5GB de uno en uno, así el checkpoint completo de 756GB nunca tiene que existir entero en disco).
Knobs útiles: --topp 0.7 para adaptive expert top-p (30–40% menos I/O de disco), THINK=1 para el reasoning block de GLM-5.2, DRAFT=n para el MTP draft depth, y STATS=f / PIN=f PIN_GB=g para registrar qué experts realmente usás y pinear los más calientes en RAM libre — el motor se pone más rápido cuanto más lo usás.
Dónde encaja esto
La mayoría de los caminos locales a GLM-5.2 asumen hardware serio: el dynamic GGUF de Unsloth quiere un Mac con 256GB+ de memoria unificada o una workstation multi-GPU para llegar a un solo dígito de tokens por segundo. Colibrì apuesta lo contrario — tratar la RAM como el recurso escaso y dejar que un NVMe rápido cargue con el peso. No es un reemplazo para un stack de inferencia bien recursado, pero como forma de hacer hablar a un modelo open-weights frontier real en hardware que ya tenés, es un ángulo genuinamente distinto sobre self-hosted local LLMs — y vale la pena probarlo en tu propia máquina para ver dónde aterriza.
El proyecto es Apache 2.0 (los pesos de GLM-5.2 son MIT de Z.ai), lo construye un solo developer, y está ganando tracción en GitHub desde el lanzamiento.
¿Alguien ya lo probó en su propia laptop? Contanos qué tok/s te tiró y con qué hardware.