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.

Revisamos de nuevo el proyecto el 2 de septiembre de 2026. Colibri v1.10.1 cubre ocho familias; las funciones multimodales y de tools de las APIs compatibles con OpenAI y Anthropic dependen del motor. Seguimos separando resultados medidos de estimaciones.

¿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 ya incluye motores específicos para GLM-5.2, GLM-5.3-Flash, Inkling, Kimi K3, DeepSeek V4 Flash, Qwen3.8-Flash-Next, Qwen3.6 y OLMoE. Es más que la demo inicial de GLM, pero no un cargador GGUF universal. Ofrece CLI, web UI local, converter, benchmarks, APIs compatibles con OpenAI y Anthropic, y rutas para CPU, CUDA, HIP/ROCm, Vulkan 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.

No traslades benchmarks hosted o full precision al build int4. El primer ensayo pequeño de GLM-5.2 obtuvo 62,5 % de accuracy normalizada media en HellaSwag, ARC y MMLU con solo 40 preguntas por tarea. Un A/B posterior con OLMoE midió una pérdida pura de cuantización de 8,2 puntos y escalas agrupadas recuperaron cerca del 63 %. Eso no sustituye un A/B limpio de GLM-5.2. El proyecto también advierte que mirrors per-row antiguos rendían unos nueve puntos peor y podían entrar en bucles en think mode. Colibri demuestra ejecución de GLM-5.2 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: 19.456 bloques en 75 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.

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 372 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 372 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 372 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 ofrece backends CUDA, HIP/ROCm, Vulkan y Metal. Pero una GPU de 16-32 GB guarda una fracción pequeña de 372 GB. Ayuda con alta tasa de hits y un cuello de expert compute; poco si manda NVMe. La aceleración y el comportamiento numérico dependen del motor, backend y hardware. La documentación GPU advierte que el output greedy no tiene que coincidir token por token con CPU. 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?

Sí, cuando existe un motor validado para esa familia. La versión 1.10.1 soporta GLM-5.2, GLM-5.3-Flash, Inkling, Kimi K3, DeepSeek V4 Flash, Qwen3.8-Flash-Next, Qwen3.6 y OLMoE. No es un cambio de modelo automático: attention, router, tokenizer, tensor layout, chat template y converter requieren implementación y validación por arquitectura.

Los requisitos documentados van desde unos 7 GB de disco y 8 GB de RAM para OLMoE hasta 1,6 TB y 32 GB o más para Kimi K3. GLM-5.2 requiere unos 372 GB y 16 GB de RAM mínima; GLM-5.3-Flash, 195 GB y 25 GB; Inkling, 469 GB y 25 GB; DeepSeek V4 Flash, 167 GB y 16 GB; Qwen3.8-Flash-Next solo CPU, 185,5 GB y 16 GB; Qwen3.6, unos 20 GB y 24 GB de RAM para residencia completa.

¿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.

Colibri usa pesos int4 con pérdida. Es una decisión distinta a conservar BF16 con exactitud. Nuestra guía sobre compresión de pesos LLM sin pérdida frente a Q8 GGUF explica la alternativa bit-exact, la nueva evidencia de GLM-5.2 y los gates de producción que aún debe superar un runtime comprimido.

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

Sirve para integración y ahora ofrece models, chat/completions, SSE, endpoint Anthropic Messages, custom stops en la ruta OpenAI, cola de admisión acotada, contadores de salud y allowlists de host y CORS. No equivale a vLLM o SGLang. Imágenes, logprobs y penalties no están soportados; audio solo se acepta con checkpoints de audio Inkling compatibles. Tools dependen del motor: la matriz actual los marca para GLM-5.2, DeepSeek V4 Flash y Kimi K3, pero no para Inkling, Qwen3.8-Flash-Next u OLMoE. Las peticiones se encolan porque ejecuta una generación a la vez. Hasta 16 KV slots aíslan conversaciones, pero no crean continuous batching.

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.

Antes de dimensionar hardware para este runtime poco común, usa nuestra guía de llmfit para encontrar LLM locales que caben en tu equipo. llmfit compara candidatos densos y MoE, contexto y cuantización antes de descargar. No predice el streaming de expertos desde NVMe de Colibri, así que mantén el benchmark de storage como prueba separada.

Cómo probar Colibri antes de comprar

1. Define 30-100 prompts representativos y un criterio de aceptación.
2. Usa el checkpoint int4 con escalas agrupadas recomendado y MTP int8; evita los mirrors per-row antiguos 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.

Convertir un resultado de viabilidad en algo que sirva a usuarios reales es un trabajo distinto de demostrar que el modelo arranca: evaluaciones, enrutado, fallback, observabilidad y un despliegue que tu equipo pueda operar. Eso es lo que cubre nuestro servicio de habilitación de IA, incluido el paso previo de mapear el flujo de datos antes de elegir infraestructura en región europea o autoalojada.

Fuentes y metodología

Arquitectura, requisitos y estado de release proceden del repositorio Colibri y la versión v1.10.1. Las restricciones y mediciones proceden de la documentación de API, GPU y benchmarks. Modelo, licencia, contexto y benchmarks de lanzamiento proceden de Z.ai y la model card oficial. Datos comprobados el 2 de septiembre de 2026.