Colibri Ejecuta GLM-5.2 en Hardware de Consumo. Esta Es la Trampa.

Sí, Colibri puede ejecutar GLM-5.2 en una máquina con unos 25 GB de RAM. No, esa máquina no se convierte en un Claude local. La velocidad fría medida por el desarrollador es 0,05-0,1 token por segundo: un token cada 10-20 segundos, sin contar el procesamiento del prompt. Una respuesta breve de 100 tokens tarda aproximadamente 17-33 minutos.

El logro técnico es real. Colibri ejecuta un Mixture-of-Experts de 744.000 millones de parámetros en hardware incapaz de guardar el modelo entero en RAM o VRAM. Convierte NVMe, memoria del sistema y VRAM opcional en niveles de una jerarquía. La contrapartida es directa: el disco aporta capacidad y las lecturas pagan la latencia.

Este análisis refleja el proyecto a 14 de julio de 2026. Separamos mediciones, resultados de la comunidad y estimaciones porque el repositorio cambia deprisa.

¿Qué es Colibri?

Colibri, estilizado Colibrì, es un runtime de inferencia escrito principalmente en C para modelos MoE sparse muy grandes sobre almacenamiento, RAM y VRAM opcional. Upstream apunta hoy a la arquitectura glm_moe_dsa específica de GLM-5.2. También incluye un motor OLMoE para validación y quantization a menor escala; no es un cargador universal de modelos frontier. Ofrece CLI, web UI local, converter, benchmarks, API de texto compatible con OpenAI y rutas experimentales para CPU, CUDA y Metal.

El runtime usa Apache 2.0 y los pesos de GLM-5.2 usan MIT. Es una combinación permisiva para uso comercial. Pero GLM-5.2 se describe mejor como open-weight: pesos y licencia públicos no hacen reproducibles los datos ni todo el entrenamiento.

El modelo no se comprime hasta 25 GB. El checkpoint int4 completo sigue en disco. Colibri conserva en memoria las partes siempre usadas y carga los expertos que pide el router. Esa diferencia es el proyecto.

¿Por qué GLM-5.2?

Z.ai publica una arquitectura 744B-A40B: 744.000 millones de parámetros totales y unos 40.000 millones activos por token. El proveedor anuncia contexto de un millón de tokens, 81,0 en Terminal-Bench 2.1 y 62,1 en SWE-bench Pro; son resultados del vendor, no prueba neutral. Artificial Analysis situó GLM-5.2 como líder open-weight de su índice al lanzamiento. Eso respalda “frontier-class open weight”, no superioridad universal.

No traslades benchmarks hosted o full precision al build int4. El primer ensayo pequeño de Colibri obtuvo 62,5 % de accuracy normalizada media en HellaSwag, ARC y MMLU con solo 40 preguntas por tarea. La muestra, el protocolo y la falta de un A/B full-precision contra int4 impiden una conclusión. Colibri demuestra ejecución mejor que retención de calidad.

¿Cómo ejecuta 744B con 25 GB de RAM?

1. Pesos densos residentes: attention, embeddings, shared experts y piezas siempre activas ocupan unos 9,9 GB en int4.
2. Expertos en NVMe: 21.504 bloques en las capas MoE y el MTP head, de unos 19 MB cada uno.
3. Routing por token: GLM-5.2 selecciona ocho expertos por capa MoE.
4. Reutilización: LRU por capa, pin aprendido, page cache y VRAM opcional guardan los expertos calientes.
5. Solapamiento: prefetch y pipeline intentan leer expertos fríos mientras calculan los residentes.

La cuenta explica el benchmark: 75 capas × ocho expertos × unos 19 MB son aproximadamente 11,4 GB leídos por token frío. A 1 GB/s, solo el disco consume unos once segundos. El techo cercano a 0,09 tok/s coincide con el resultado medido.

¿Qué velocidad da Colibri?

Estos datos proceden de la tabla comunitaria del repositorio; no los hemos reproducido. El tiempo para 100 tokens usa 100 / tok_s y excluye prefill y cola.

Time to first token puede ser mucho peor con caché fría o prompts largos. Seis RTX no implican 6 tok/s en una GPU. Una repetición limpia con una sola RTX 5090 mostró casi cero mejora porque el CPU ya igualaba expert matmul y storage seguía limitando. Un objetivo conversacional habitual de 20-30 tok/s queda lejos incluso del mejor resultado publicado.

Los cuellos reales

RAM y aciertos de caché

Con 24-32 GB, los pesos densos, KV, scratch y el sistema dejan poca caché. Un test de 24 GB logró solo 3-4 % de hits y 0,07 tok/s aunque el direct read medía 2,74 GB/s. Con 128 GB se pueden fijar decenas de gigabytes de expertos aprendidos. Un workload repetitivo gana más que preguntas aleatorias: los expertos calientes para código pueden no servir para legal.

Lectura real, no la cifra de la caja

Colibri lee en paralelo bloques dispersos de unos 19 MB en un archivo de 370 GB. Importa el iobench directo sobre un shard frío, no el pico secuencial del fabricante. En el mismo Ryzen, pasar de 1,51 a 8,81 GB/s mejoró generación de 0,10 a 0,28 tok/s: el disco subió 5,8× y el output 2,9× porque el cuello se desplazó al cálculo.

CPU, memoria y especulación

Con hit de caché mandan matrix multiplication cuantizada y ancho de banda RAM. El MTP correcto en int8 alcanzó 39-59 % de aceptación y 2,2-2,8 tokens por forward; el mirror int4 anterior casi anulaba la especulación. En frío puede empeorar: las cargas de expertos subieron de unas 660 a 1.100 por token. --topp 0.7 reduce lecturas, pero altera el routing de forma lossy y obliga a repetir evals.

¿Colibri desgasta el SSD?

La inferencia normal apenas debería consumir el TBW. Los 11 GB por token son lecturas. La NAND se desgasta principalmente al programar y borrar; Micron considera despreciable el desgaste por lectura. El streaming de expertos es read-only.

• La instalación escribe una vez: unos 370 GB descargados; convertir 756 GB FP8 supera fácilmente 1 TB de host writes entre shards y output.
• El swap sí es peligroso: poca RAM causa escrituras sostenidas y hunde la velocidad.
• KV persiste algo: alrededor de 182 KB por token, pequeño pero no cero.
• Las lecturas calientan: Samsung documenta thermal throttling. Usa disipador, airflow y SMART.

Una NVMe local de 1 TB con espacio libre y refrigeración es más sensata que apretar 370 GB junto al sistema en 500 GB. RAID 0 aumenta ancho de banda y superficie de fallo; resérvalo para artefactos recuperables.

¿Una GPU lo hace rápido?

A veces. Colibri puede fijar expertos calientes en VRAM, ejecutar trabajo denso con CUDA y usar Metal. Pero una GPU de 16-32 GB guarda una fracción pequeña de 370 GB. Ayuda con alta tasa de hits y un cuello de expert compute; poco si manda NVMe. Multi-GPU aún usa contextos independientes y copias vía host, sin P2P/NCCL, sharding de expertos ni librerías Tensor Core maduras. No compres una GPU para Colibri hasta que el profiling señale cálculo, no disco o RAM.

¿Puede ejecutar DeepSeek, Qwen, Kimi u otros modelos?

No como cambio de model ID. No es llama.cpp genérico. Tokenizer, atención, router, layout, MTP y contenedor implementan GLM-5.2. Otra arquitectura necesita engine, converter y validación.

El fork Colibri-Hy3 adapta el diseño al Hy3 de Tencent, 295B totales y 21B activos, con motor C, GQA, router y converter propios para unos 142 GB int4. Prueba que la idea es portable y que el soporte no es plug-and-play. Los modelos densos se benefician mucho menos.

¿Y el contexto de un millón?

GLM-5.2 anuncia un millón de tokens, pero eso no es práctico en 25 GB. El servidor usa 4.096 por defecto y la persistencia KV comprimida ronda 182 KB/token: un millón serían unos 182 GB solo de KV, antes de pesos, scratch y caché. Capacidad del modelo y capacidad del sistema son afirmaciones distintas.

¿La API compatible con OpenAI está lista para producción?

Sirve para integración: models, chat/completions, SSE, usage y sampling básico. No equivale a vLLM o SGLang. Es text-only; tools, imagen/audio, custom stops, logprobs y penalties fallan. Las peticiones se encolan porque ejecuta una secuencia. Hasta 16 KV slots aíslan conversaciones, pero no crean continuous batching. La autenticación es una API key local compartida.

Para clientes necesitas load tests, aislamiento, límites, observabilidad, security review, recuperación, checksums, política de updates, eval gates y fallback. Nuestro framework de break-even entre modelos locales y APIs cubre los costes; el throughput single-sequence de Colibri eleva mucho el listón.

¿Quién debería usarlo?

Su valor comercial actual es de instrumento de viabilidad: comprobar tu workload privado, la calidad int4, los expertos calientes y qué nivel de hardware elimina el cuello medido.

Cómo probar Colibri antes de comprar

1. Define 30-100 prompts representativos y un criterio de aceptación.
2. Usa el checkpoint convertido con MTP int8 y verifica tamaños.
3. Ejecuta coli doctor y coli plan.
4. Mide storage frío con direct I/O, no con la cifra del fabricante.
5. Registra TTFT, tok/s, hit rate, peak RSS, calidad y tiempo total.
6. Separa resultados fríos y calientes.
7. Cambia RAM, NVMe, VRAM y flags CPU de uno en uno.
8. Compara máquina, electricidad e ingeniería con un endpoint hosted por tarea exitosa.

Al salir del lab, añade eval gate y fallback. La misma disciplina aparece en nuestro caso Twinsoft AI y la guía de selección tecnológica: la arquitectura responde a restricciones medidas.

Fuentes y metodología

Arquitectura, requisitos, features y velocidad proceden del repositorio Colibri y sus issues. Modelo, licencia, contexto y benchmarks de lanzamiento proceden de Z.ai y la model card oficial. Artificial Analysis solo respalda capacidad independiente, no velocidad Colibri. Datos comprobados el 14 de julio de 2026.