Colibrì: el minimotor que hace funcionar un modelo de 744B en hardware consumer
Cada semana, la comunidad de código abierto de la inteligencia artificial local parece buscar su tema de conversación favorito, y la que acaba de pasar parece haber elegido un repositorio en GitHub con un nombre curioso y una promesa casi absurda: hacer funcionar GLM-5.2, un modelo Mixture-of-Experts de 744 mil millones de parámetros, en un ordenador con apenas 25 GB de RAM. El proyecto se llama Colibrì y es obra de un solo desarrollador, JustVugg, quien en la sección de agradecimientos de su README admite con una honestidad desarmante haber escrito y probado todo en un portátil de doce núcleos. Sin laboratorio, sin clúster, sin patrocinio de hardware. Solo una obsesión técnica llevada hasta el final.
Hay que decir de inmediato, con la misma honestidad que el autor reserva para su propio trabajo: Colibrì no está pensado para un público masivo, no es un producto y no aspira a convertirse en uno. Es un experimento, en el sentido más clásico del término, el de quien quiere descubrir dónde se encuentra realmente el límite físico de una máquina consumer cuando se le pide soportar un modelo que, en condiciones normales, requeriría cientos de gigabytes de memoria dedicada. Y es precisamente este marco experimental, más que el rendimiento en sí, lo que lo hace interesante de contar.
Qué hay dentro del motor
El corazón de Colibrì reside en un solo archivo C de unas 2.400 líneas, glm.c, acompañado de algunos encabezados mínimos. Cero dependencias externas, cero librerías de álgebra lineal como BLAS, cero runtime de Python durante la inferencia propiamente dicha (Python entra en juego solo en la fase de conversión offline del modelo, una tarea que realiza una sola vez y luego sale de escena). Es un planteamiento que recuerda a la filosofía de ciertos proyectos históricos de la informática, aquellos en los que la elección de escribir menos código, pero escribirlo bien, se convierte en sí misma en una declaración de intenciones.
Hay algo en esta obstinación minimalista que hace pensar en ciertas producciones musicales de la escena IDM británica de los años noventa: pocos instrumentos, reglas rígidas y, sin embargo, resultados sorprendentemente complejos que emergen de un sistema deliberadamente pobre en elementos. Colibrì funciona más o menos así: un motor pequeñísimo que orquesta un modelo colosal, sin adornos, sin niveles de abstracción superfluos, con el objetivo declarado de hacer funcionar exactamente una arquitectura, GLM-5.2, y de hacerlo con una fidelidad verificable respecto a la implementación original en transformers.
GLM-5.2, el modelo monstruoso
Para entender por qué esta hazaña tiene sentido técnico, primero hay que entender qué significa realmente "744 mil millones de parámetros". GLM-5.2 es un modelo Mixture-of-Experts, una arquitectura en la que la red no procesa cada token con toda su capacidad, sino que la distribuye entre miles de subredes especializadas, llamadas expertos, activando solo una pequeña parte de ellas para cada token generado. En el caso de GLM-5.2, los expertos enrutables son 21.504, distribuidos en 75 capas MoE de 256 expertos cada una más una cabeza adicional para la decodificación especulativa, para un total global de 19.456 expertos según el recuento que el propio proyecto utiliza en su panel de control. De todos estos, solo unos 40 mil millones de parámetros se activan realmente para cada token individual, y de estos apenas 11 GB cambian realmente de un token a otro, los enrutados por el router.
Es una distinción crucial, porque significa que el problema ya no es "cómo mantengo 744 mil millones de parámetros en memoria", sino "cómo hago llegar al procesador, a tiempo, solo los 11 GB que sirven de verdad en este instante". Es el mismo principio, aplicado con radicalidad extrema, que gobierna otros motores de inferencia MoE nacidos en estas semanas, y que vale la pena tener en mente cuando más adelante comparemos Colibrì con un primo conceptual nacido por los lares de Redis.
La jerarquía de memoria de tres niveles
La idea técnica que sustenta todo el proyecto es, en el fondo, sencilla de explicar con una analogía. Imaginad una biblioteca interminable en la que la parte del catálogo que consultáis cada día está sobre vuestro escritorio, la que necesitáis de vez en cuando está en una estantería en otra habitación, y la que abrís raramente está en un almacén externo desde el que hay que solicitarla a propósito. Colibrì trata la VRAM, la RAM y el disco exactamente como tres niveles de esta misma biblioteca, gestionados como una única jerarquía de memoria.
La parte densa del modelo (atención, expertos compartidos, embeddings, unos 17 mil millones de parámetros) permanece siempre residente en RAM en formato int4, ocupando unos 9,9 GB. Los más de 21.000 expertos enrutados, en cambio, viven en disco en un contenedor int4 que pesa en total unos 370 GB, y se cargan dinámicamente solo cuando el router del modelo decide activarlos, gracias a una caché LRU para cada capa, un "almacén caliente" opcional para los expertos más usados y la caché de página del sistema operativo que actúa como nivel intermedio gratuito. Es en este punto cuando el cuello de botella se desplaza, de forma casi filosófica, del cálculo a la lectura: ya no es la CPU la que decide qué tan rápidos sois, es el disco.
Hardware mínimo, expectativas realistas
Colibrì funciona en Linux, WSL2, macOS y, desde su evolución más reciente, también en Windows 11 nativo gracias a un nivel de compatibilidad escrito específicamente. Se necesita un procesador con soporte AVX2, al menos 16 GB de RAM y unos 370 GB libres en una unidad NVMe local, nunca en una unidad compartida de red. No es un requisito baladí, pero sigue siendo órdenes de magnitud más asequible que el clúster de GPU que se necesitaría para cargar el mismo modelo en su totalidad a precisión completa.
La distinción más importante, sin embargo, no se refiere al hardware mínimo sino a la diferencia entre "funciona" e "es practicable". Colibrì funciona incluso en la configuración más modesta probada por el autor: doce núcleos y 25 GB de RAM tras una máquina virtual WSL2 con un disco que lee a unos 1 GB por segundo. Pero a esa velocidad el modelo produce respuestas a un ritmo comprendido entre 0,05 y 0,1 tokens por segundo desde caché fría, un valor que hace que la experiencia se parezca más a un telegrama que a una conversación. Es un proyecto pensado para ser llevado más allá, no para ser usado tal cual en la configuración de partida.
Las cifras honestas de rendimiento
El README del proyecto dedica una sección entera, titulada sin ironía "cifras honestas", precisamente a aclarar esta distancia entre teoría y práctica. En la máquina de desarrollo, un cold start cuesta unos 11 GB de lecturas de disco por cada token generado, lo que significa que la velocidad depende casi por completo del throughput del propio disco: con un límite físico de unos 1 GB por segundo en esa configuración, el resultado es precisamente el 0,05-0,1 tokens por segundo mencionado anteriormente.
Las cosas cambian sensiblemente cuando la comunidad ha empezado a probar Colibrì en hardware más capaz, y aquí los datos recogidos en las issues del repositorio se convierten en el verdadero laboratorio del proyecto. En un Ryzen AI Max con 128 GB de RAM la velocidad sube a unos 0,37-0,40 tokens por segundo una vez que la caché se ha calentado. En un Mac con chip M5 Max y 128 GB de memoria unificada se llega a unos 1 token por segundo con la configuración base, y a más de 2 tokens por segundo habilitando el backend experimental Metal. El punto de datos más extremo proviene de un banco de seis tarjetas RTX 5090 conectadas juntas, donde manteniendo todo el parque de expertos residente entre VRAM y RAM se alcanzan los 6 tokens por segundo en decodificación sobre petición individual, una cifra que empieza a acercarse a un uso realmente conversacional, aunque obtenida con una inversión en hardware que ya nada tiene de consumer.
Un detalle técnico interesante se refiere a la decodificación especulativa nativa de GLM-5.2, la llamada MTP, en la que una pequeña cabeza adicional del modelo intenta adivinar de antemano los tokens siguientes, que el motor principal luego verifica en un único paso. Funciona solo si esa cabeza se cuantiza a 8 bits en lugar de a 4: con la precisión equivocada, la aceptación de los tokens propuestos cae a cero, mientras que con la correcta sube entre el 39 y el 59 por ciento, aportando hasta 2,8 tokens generados por cada paso del modelo. Es el tipo de detalle aparentemente minúsculo que, en un sistema tan llevado al límite, marca la diferencia entre un proyecto utilizable y uno que se bloquea sin una razón aparente.
La caché que aprende
Uno de los aspectos más fascinantes de Colibrì, desde el punto de vista puramente conceptual, es que el motor se observa a sí mismo mientras trabaja y aprende de sus propios patrones de uso. Cada sesión de chat actualiza un archivo que registra qué expertos han sido realmente activados, y al siguiente reinicio el motor usa esa cronología para decidir qué expertos mantener precargados en la RAM disponible. Cuanto más se usa, más se acostumbra la máquina, en un sentido muy literal, a vuestras conversaciones.
A esto se añade un mecanismo de prefetch predictivo, todavía experimental, que aprovecha una regularidad interesante descubierta en el comportamiento del router: el estado de una capa tras la atención permite anticipar correctamente el 71,6 por ciento de los expertos que serán activados por la capa siguiente, un valor medido por los propios colaboradores del proyecto. Un hilo de I/O dedicado puede, por tanto, empezar a leer del disco los expertos de la siguiente capa mientras la actual todavía está calculando, superponiendo tiempo de lectura y tiempo de cálculo en lugar de sumarlos en secuencia.
Un lugar propio en el panorama local
Colibrì no nace en el vacío. En las mismas semanas, otro proyecto ha catalizado la atención de la comunidad de la inferencia local con una filosofía sorprendentemente similar: DwarfStar (en código DS4), el motor escrito por Salvatore Sanfilippo, alias antirez, el creador de Redis, de quien hablé en Codemotion. También DwarfStar es un motor en C escrito desde cero, optimizado de modo maníaco para un solo modelo, y también allí la estrategia para sortear los límites de la memoria consumer pasa por una combinación de cuantización agresiva y streaming de los expertos desde el disco en Mac con arquitectura Metal.
Las diferencias, sin embargo, son tan instructivas como las similitudes. DwarfStar apuesta por DeepSeek V4 Flash, un modelo MoE más contenido con 284 mil millones de parámetros totales y 13 mil millones activos, y lo comprime hasta un archivo GGUF de unos 81 GB gracias a una cuantización asimétrica calibrada empíricamente sobre los pesos que de verdad importan. Colibrì, por el contrario, elige el camino opuesto y más radical: no comprime el modelo para que quepa en la RAM disponible, lo deja enorme, unos 370 GB en disco, y construye en cambio todo un sistema de almacenamiento en caché y streaming para gestionar su inmensidad sin comprometer su precisión declarada. Donde DwarfStar dice "hago el modelo más pequeño porque la RAM es la que es", Colibrì dice "dejo el modelo grande como está y reinvento el modo en que la memoria lo toca". Son dos respuestas diferentes a la misma pregunta y, puestas en comparación, cuentan mejor que cualquier benchmark cuán vivo está, en este momento, el fermento en torno a la inferencia local de modelos de frontera.
Hay además una diferencia de escala que merece la pena subrayar: DwarfStar trabaja sobre un modelo de 284 mil millones de parámetros pensado para hardware Apple de gama alta, con benchmarks que alcanzan los 25-36 tokens por segundo en generación en Mac Studio. Colibrì afronta un modelo casi tres veces más grande, 744 mil millones de parámetros, y lo hace en la condición más hostil posible, un PC genérico con RAM limitada y un disco cualquiera, obteniendo en consecuencia cifras mucho más modestas. No es una comparación de igual a igual, y es justo decirlo con claridad, pero es precisamente la distancia entre los dos enfoques lo que hace evidente cuánto espacio de maniobra entre "compresión del modelo" y "streaming inteligente de la memoria" queda aún por explorar.
Por qué importa, más allá de la demo
Más allá del atractivo técnico inmediato, Colibrì toca un tema que en los últimos meses ha vuelto a ser central en el debate sobre la inteligencia artificial: la soberanía tecnológica, es decir, la posibilidad concreta de ejecutar modelos capaces sin depender de una infraestructura en la nube de terceros. Un modelo que funciona íntegramente en vuestro propio hardware, por lento que sea, no envía ni un solo byte de conversación a un servidor externo, y esto para ciertos contextos (investigación, desarrollo de herramientas propietarias, experimentación con datos sensibles) tiene un valor que va más allá de la simple curiosidad técnica.
Colibrì sugiere además algo más amplio sobre el futuro de los modelos MoE en hardware consumer: que el camino para democratizar el acceso a los modelos de frontera no pasa necesariamente, o solamente, por hacerlos más pequeños. Pasa también por repensar radicalmente cómo se gestiona la memoria, tratando RAM, VRAM y disco como un único recurso fluido en lugar de como compartimentos estancos. Es una intuición que, si llegara a madurar más allá del estadio experimental, podría influir en el modo en que se diseñan los próximos runtime de inferencia, mucho más allá del perímetro de un solo proyecto personal.
Los nudos aún abiertos
Sería deshonesto con los lectores y con el propio espíritu del proyecto cerrar sin enumerar las críticas que Colibrì todavía arrastra consigo. La velocidad en condiciones de caché fría sigue siendo bajísima, al límite de lo inutilizable para cualquier tarea que requiera respuestas rápidas. La dependencia del rendimiento del almacenamiento es total: quien no disponga de un NVMe realmente rápido verá cifras difícilmente distinguibles de un tiempo de espera agotado. Está además la cuestión, aún abierta, de la precisión: un primer benchmark de calidad realizado por la comunidad ha medido una puntuación del 62,5 por ciento en una batería de tests estándar, sensiblemente más baja respecto al 85-95 por ciento publicado para la versión original del modelo a precisión completa, aunque el propio autor invita a la cautela, señalando que el método de evaluación usado penaliza estructuralmente a un modelo pensado para razonar paso a paso, y que hace falta todavía una comparación directa y controlada entre las dos precisiones para aislar de verdad el coste de la cuantización del ruido de la medida.
Hay que añadir, por último, una constatación más prosaica: la usabilidad para un público no técnico es, en el estado actual, prácticamente nula. Configurar Colibrì significa descargar cientos de gigabytes, convertir pesos, leer variables de entorno e interpretar logs de diagnóstico. Es una herramienta para quien ya sabe lo que está haciendo, no una aplicación lista para usar, y hacen falta benchmarks independientes en hardware más variado antes de poder decir con certeza hasta qué punto las cifras publicadas son representativas fuera del laboratorio artesanal en el que nació el proyecto.
Conclusiones
Colibrì no demuestra que los modelos enormes se hayan vuelto cómodos de usar en un ordenador cualquiera, y sería engañoso contarlo así. Demuestra, más bien, que los límites de la inferencia local pueden ser llevados mucho más allá de lo que la mayoría de los expertos habrían apostado hasta hace pocas semanas, tratando la escasez de memoria no como un obstáculo insuperable sino como un vínculo de diseño que sortear con creatividad ingenieril. Es un proyecto importante de contar precisamente porque, junto a experimentos paralelos como DwarfStar, muestra hacia dónde va realmente el ecosistema de la IA de código abierto en este momento: no hacia una única solución definitiva, sino hacia una pluralidad de estrategias, quien comprime el modelo, quien reinventa la memoria, que se confrontan abiertamente en el mismo terreno.
Colibrì no es el futuro de la IA local para todos, pero es una señal clarísima de cuánto los runtime se están volviendo más creativos al superar los límites físicos del hardware.