Un desarrollador ha conseguido ejecutar GLM-5.2, un modelo de mezcla de expertos con unos 744.000 millones de parámetros, en un ordenador de consumo con alrededor de 25 GB de memoria RAM y sin tarjeta gráfica. El proyecto se llama Colibrì y no hace que el modelo sea rápido: su aportación consiste en tratar la RAM, la memoria gráfica y el almacenamiento como niveles de una misma jerarquía, cargando desde el disco únicamente los expertos necesarios para generar cada token.
Las claves de Colibrì y GLM-5.2 en 30 segundos
- GLM-5.2 tiene unos 744.000 millones de parámetros, pero activa cerca de 40.000 millones para generar cada token.
- Colibrì mantiene 9,9 GB de pesos compartidos en RAM y almacena unos 370 GB de expertos cuantizados en el disco.
- El runtime principal está escrito en C y no necesita Python, BLAS ni una GPU durante la inferencia.
- En un equipo con 25 GB alcanza entre 0,05 y 0,1 tokens por segundo.
- El experimento demuestra viabilidad técnica, no una experiencia comparable con un servicio cloud.
El repositorio, creado por el desarrollador JustVugg, ha superado las 16.400 estrellas y las 1.500 bifurcaciones en GitHub. Su primera versión estable se publicó el 19/07/2026 bajo licencia Apache 2.0, mientras los pesos de GLM-5.2 están disponibles con licencia MIT.
La cifra de 25 GB puede llevar a una conclusión equivocada. Colibrì no comprime todo el modelo hasta hacerlo caber en esa cantidad de memoria. Los cientos de gigabytes de pesos siguen siendo necesarios, pero se mantienen en una unidad de almacenamiento y se trasladan a RAM a medida que el modelo los solicita.
El resultado es demasiado lento para mantener una conversación normal, pero permite ejecutar localmente un modelo que en su formato original está pensado para infraestructuras con numerosas GPU y grandes cantidades de memoria de alta velocidad.
Los 744.000 millones de parámetros no trabajan al mismo tiempo
GLM-5.2 pertenece a la familia de modelos Mixture of Experts (MoE), o mezcla de expertos. En lugar de utilizar todos sus parámetros para cada fragmento generado, incorpora numerosos bloques especializados y un router que decide cuáles deben intervenir.
Z.ai describe GLM-5.2 como su modelo abierto para tareas prolongadas, programación y trabajos con hasta un millón de tokens de contexto. Su arquitectura dispone de 256 expertos en cada capa MoE y selecciona ocho de ellos por token. En total, el modelo mantiene unos 744.000 millones de parámetros, pero solo activa alrededor de 40.000 millones en cada paso de inferencia.
Esto no significa que los restantes puedan eliminarse. El router puede escoger expertos diferentes en el siguiente token, según el texto, el idioma, la tarea y el contexto acumulado. Todos los pesos deben permanecer disponibles en algún lugar, aunque no necesariamente en la memoria más rápida.
Colibrì divide el modelo en dos grandes grupos:
| Parte del modelo | Tamaño aproximado | Ubicación habitual |
|---|---|---|
| Atención, embeddings y expertos compartidos | 17.000 millones de parámetros | RAM |
| Pesos compartidos cuantizados a int4 | 9,9 GB | Residentes en memoria |
| 19.456 expertos enrutados | Unos 370 GB | SSD o NVMe |
| Expertos usados con frecuencia | Depende de la RAM disponible | Caché en memoria |
| Expertos seleccionados para el token actual | Unos 11 GB variables | Cargados cuando se necesitan |
La cifra correcta del proyecto es 19.456 expertos enrutados, no más de 21.000. Proceden principalmente de 75 capas MoE con 256 expertos cada una, a las que se añaden los pesos relacionados con la cabeza de predicción de múltiples tokens.
La parte densa incluye componentes que participan constantemente en la inferencia, como la atención, los embeddings y los expertos compartidos. Colibrì los cuantiza a cuatro bits y los mantiene en RAM, donde ocupan unos 9,9 GB.
Los expertos variables se guardan en el disco. Cada uno ocupa aproximadamente 19 MB en el contenedor int4 utilizado por el proyecto. Cuando el router escoge un conjunto concreto, el runtime localiza sus archivos, los carga y ejecuta los cálculos correspondientes.
El ahorro de memoria procede de no mantener los 370 GB de expertos simultáneamente en RAM. La contrapartida es el tiempo empleado en leerlos desde el almacenamiento.
La caché intenta evitar que el SSD frene cada palabra
Un sistema que leyese todos los expertos desde el disco para cada token funcionaría, pero el rendimiento sería todavía peor. Colibrì aplica varias técnicas para reducir el número de accesos y ocultar parte de su latencia.
El runtime mantiene una caché independiente por capa utilizando una política LRU, que conserva los expertos utilizados recientemente y descarta los menos solicitados. También registra qué expertos selecciona con más frecuencia cada carga de trabajo. Con esos datos puede fijar en RAM los más habituales y ajustar el reparto conforme se utiliza el modelo.
El comportamiento recuerda al de un sistema operativo cuando administra memoria virtual, aunque el objeto gestionado no son páginas convencionales, sino matrices completas pertenecientes a los expertos del modelo.
El motor también agrupa las tres matrices de cada experto para leerlas mediante una única operación pread. Un conjunto limitado de operaciones de entrada y salida asíncronas carga los pesos mientras la CPU trabaja con los expertos que ya están disponibles.
Además, incorpora un mecanismo que intenta anticipar qué expertos necesitará la siguiente capa. Según las mediciones del proyecto, el enrutamiento resulta predecible con una precisión del 71,6 % con una capa de antelación. Este porcentaje procede de las pruebas de Colibrì y puede variar según la tarea, el idioma y la distribución de las consultas.
El proceso puede resumirse en cinco pasos:
| Paso | Función |
|---|---|
| Enrutar | Determinar qué expertos necesita el token |
| Unificar | Evitar cargar varias veces el mismo experto |
| Colocar | Decidir si se obtiene desde VRAM, RAM o disco |
| Solapar | Leer pesos mientras se ejecutan otros cálculos |
| Aprender | Registrar qué expertos conviene conservar en caché |
Colibrì no modifica la selección realizada por el router en función del hardware disponible. Si el modelo solicita un experto que está en el disco, el sistema espera a que llegue en lugar de reemplazarlo por otro que ya esté en memoria.
Esta decisión conserva el funcionamiento previsto de la arquitectura, pero sacrifica velocidad. Un modo más agresivo podría limitar el modelo a los expertos residentes, aunque entonces cambiaría el resultado de la inferencia y dejaría de ejecutar fielmente el mismo modelo.
De 0,05 tokens por segundo a seis RTX 5090
El equipo original con 25 GB de RAM alcanza entre 0,05 y 0,1 tokens por segundo cuando la caché está fría. En términos prácticos, el sistema puede tardar entre 10 y 20 segundos en producir un solo token. Una respuesta moderadamente larga puede requerir decenas de minutos.
No es una velocidad competitiva frente a una API o un modelo pequeño ejecutado localmente. Tampoco pretende serlo. Ese equipo representa el mínimo demostrado por el autor para mantener el modelo operativo sin reducir dinámicamente la precisión ni alterar el comportamiento del router.
Las mediciones recopiladas por el proyecto muestran cuánto cambia el rendimiento cuando los expertos pueden permanecer en niveles más rápidos:
| Configuración | Velocidad comunicada |
|---|---|
| Equipo con 25 GB, CPU y expertos desde disco | 0,05-0,1 tokens/s |
| Ordenador con 128 GB y CPU, caché caliente | Alrededor de 1,8 tokens/s |
| Equipo con una RTX 5070 Ti | 1,07 tokens/s |
| Seis RTX 5090 con todos los expertos residentes | Entre 5,8 y 6,8 tokens/s |
Estas cifras proceden del proyecto y de pruebas aportadas por su comunidad. No son comparaciones independientes ni se ejecutaron necesariamente con idénticos procesadores, almacenamiento, contexto, temperatura de caché y configuración. Sirven para mostrar la influencia de la ubicación de los pesos, no para establecer una clasificación definitiva de hardware.
Resulta especialmente llamativo que un sistema con mucha RAM y solo CPU pueda superar en una prueba concreta a un portátil con una GPU. La explicación no está únicamente en la capacidad de cálculo. Si la configuración con 128 GB mantiene más expertos en memoria y evita accesos al SSD, puede compensar parte de la diferencia frente a un acelerador con poca VRAM.
Colibrì convierte así el despliegue del modelo en un problema de colocación de datos. La GPU acelera las multiplicaciones, pero deja de ser suficiente cuando debe esperar constantemente a que los pesos lleguen desde un nivel más lento.
Un runtime en C, pero no todo el proyecto es una sola aplicación sin dependencias
El núcleo de inferencia se concentra en el archivo c/glm.c y varios encabezados pequeños. No necesita BLAS, Python ni una GPU durante su ejecución. Utiliza C, OpenMP y llamadas del sistema para cargar y procesar los pesos.
No obstante, describir todo Colibrì como una aplicación de “C puro y cero dependencias” requiere matices. El repositorio también contiene código Python para la conversión inicial del modelo y para una pasarela opcional compatible con la API de OpenAI. Añade componentes CUDA, un backend experimental para Metal, una interfaz web y una aplicación de escritorio basada en Tauri.
Python se utiliza una vez para descargar y convertir progresivamente los pesos FP8. El proceso evita necesitar los aproximadamente 756 GB de la fuente completa de forma simultánea, pero el usuario todavía debe reservar alrededor de 370 GB para el contenedor int4 final, además del espacio temporal y de las cachés.
El almacenamiento no es, por tanto, un detalle secundario. Un disco mecánico convertiría las esperas en algo todavía menos práctico. El proyecto cobra sentido con una unidad NVMe rápida y suficiente espacio libre.
Colibrì también implementa una caché de claves y valores comprimida para la atención. Utiliza 576 valores de coma flotante por token en lugar de 32.768, una reducción declarada de 57 veces. La caché puede guardarse en disco para reabrir una conversación sin volver a procesar todo el contexto anterior.
Otra función es la decodificación especulativa mediante la cabeza MTP de GLM-5.2. Esta propone varios tokens y permite que el modelo principal los verifique conjuntamente. El proyecto advierte de que la cabeza debe conservarse en int8: su cuantización a int4 redujo la aceptación de borradores hasta prácticamente cero en sus pruebas.
Ejecutar el modelo no equivale a servirlo en producción
El principal valor de Colibrì no es convertir un portátil en un competidor de un clúster de IA. La diferencia de velocidad, concurrencia y capacidad para atender contextos largos continúa siendo enorme.
Una infraestructura de producción mantiene los pesos en memoria de alta velocidad, atiende varias solicitudes a la vez, agrupa tokens y distribuye el cálculo entre aceleradores. El equipo de 25 GB ejecuta una conversación de forma secuencial y pasa gran parte del tiempo esperando al almacenamiento.
También existe una diferencia entre conservar la lógica del modelo y demostrar que la cuantización int4 mantiene toda su calidad. Colibrì asegura haber validado una secuencia de 32 tokens de forma exacta frente a una implementación de referencia y publica pruebas sobre el coste de la cuantización. Esa comprobación respalda la implementación del recorrido de inferencia, pero no sustituye a una evaluación amplia sobre razonamiento, programación, idiomas y contexto largo.
GLM-5.2 incorpora un contexto anunciado de un millón de tokens, atención dispersa y mejoras para tareas prolongadas. Ejecutar esa capacidad completa en un equipo con 25 GB añadiría otra presión sobre la memoria y los tiempos de procesamiento. Z.ai presenta el modelo como una solución para programación agéntica y proyectos largos, pero sus resultados publicados proceden de infraestructuras mucho más potentes.
El experimento sí demuestra una idea relevante: en un modelo MoE, el requisito de memoria rápida puede separarse parcialmente del tamaño total de sus pesos. Los parámetros que no participan en un token concreto pueden permanecer en un nivel más lento, siempre que el runtime sepa localizarlos, anticiparlos y cargarlos.
El hardware sigue imponiendo el rendimiento. Lo que cambia es el mínimo necesario para que el modelo funcione. Colibrì rebaja ese mínimo mediante arquitectura de software, cachés y una lectura precisa del diseño interno de GLM-5.2.
Preguntas frecuentes
¿GLM-5.2 cabe realmente en 25 GB de RAM?
No completamente. Unos 9,9 GB permanecen cargados en RAM y alrededor de 370 GB de expertos cuantizados se guardan en el disco. Los expertos se transfieren a memoria cuando el modelo los necesita.
¿Colibrì necesita una tarjeta gráfica?
No. Puede funcionar únicamente con CPU, aunque también ofrece capas opcionales para CUDA y un backend experimental para Metal. La GPU mejora el rendimiento cuando permite mantener más pesos en memoria rápida.
¿Qué velocidad alcanza en un ordenador con 25 GB?
El proyecto comunica entre 0,05 y 0,1 tokens por segundo con la caché fría. Esto equivale aproximadamente a un token cada 10 o 20 segundos.
¿Todo Colibrì está escrito únicamente en C?
El núcleo de inferencia en tiempo de ejecución sí está concentrado en C y no necesita Python ni BLAS. El repositorio completo incorpora Python para la conversión y la API opcional, además de CUDA, TypeScript y otros componentes.
