Por Canuto  

Un proyecto de código abierto llamado Colibri asegura que puede ejecutar GLM-5.2, un modelo MoE de 744.000 millones de parámetros, en una laptop con apenas 25 GB de RAM. La hazaña no elimina los límites de la física, pero sí propone una ruta alternativa para correr modelos gigantes fuera de centros de datos y sin GPU dedicada.
***

  • Colibri ejecuta GLM-5.2 de 744.000 millones de parámetros en C puro, sin dependencias y sin GPU obligatoria.
  • El motor mantiene en RAM la parte densa del modelo y transmite expertos desde disco bajo demanda, con un contenedor int4 de cerca de 370 GB.
  • El proyecto funciona en hardware de consumo, pero su velocidad depende en gran medida del SSD, la RAM disponible y la caché de expertos.

La idea de correr un modelo de inteligencia artificial de escala frontera en una laptop suele sonar imposible. Sin embargo, un proyecto llamado Colibri afirma haber abierto una ruta distinta al ejecutar GLM-5.2, un modelo MoE de 744.000 millones de parámetros, en una máquina de consumo con unos 25 GB de RAM.

El anuncio fue resumido por @chenzeling4, quien destacó que el sistema funciona en C puro, sin dependencias, y sin necesidad obligatoria de GPU. La frase central fue tan breve como provocadora: 744B parámetros, en una laptop, con 25 GB de RAM.

Más allá del titular llamativo, la clave técnica está en que GLM-5.2 no activa sus 744.000 millones de parámetros en cada token. Al ser un modelo de mezcla de expertos, o MoE, solo activa alrededor de 40.000 millones por token.

Esa diferencia cambia por completo el problema. En vez de cargar todo el modelo en memoria, Colibri mantiene residente la parte densa y trae desde disco los expertos necesarios a demanda, una decisión que desplaza el cuello de botella desde la RAM hacia el almacenamiento.

El resultado no es una experiencia veloz en términos absolutos. Pero sí representa una demostración de ingeniería que podría influir en el debate sobre IA local, costos de inferencia y acceso a modelos grandes sin depender de infraestructura con GPU de alto precio.

Cómo funciona Colibri y por qué 744.000 millones no significan 744.000 millones en memoria

El repositorio del proyecto describe a Colibri como un motor diminuto para un modelo inmenso. Su promesa central es ejecutar GLM-5.2, un modelo MoE de 744.000 millones de parámetros, en una máquina de consumo con cerca de 25 GB de RAM.

La estrategia parte de una observación simple pero decisiva. En un modelo MoE no todos los parámetros participan en cada paso de generación, porque el enrutador activa solo una fracción de expertos para cada token.

Según la documentación del proyecto, solo unos 40.000 millones de parámetros se activan por token. De ese conjunto, alrededor de 11 GB son los que cambian de un token a otro, porque corresponden a expertos dirigidos que pueden almacenarse fuera de la RAM principal.

La parte densa del modelo, que incluye atención, expertos compartidos y embeddings, suma cerca de 17.000 millones de parámetros. Esa porción se mantiene residente en RAM en formato int4 y ocupa aproximadamente 9,9 GB.

Los expertos dirigidos, en cambio, viven en disco. El proyecto habla de 21.504 expertos dirigidos, distribuidos en 75 capas MoE por 256 expertos, más la cabeza MTP, con un tamaño cercano a 19 MB por experto en int4.

Eso lleva el tamaño en disco del contenedor del modelo a cerca de 370 GB. En otras palabras, Colibri no reduce mágicamente la dimensión del modelo, sino que reorganiza cómo y cuándo se accede a él.

El motor está implementado en un solo archivo C, identificado como c/glm.c, de unas 2.400 líneas, acompañado por encabezados pequeños. El proyecto remarca que no necesita BLAS, no requiere Python en tiempo de ejecución y no obliga a usar GPU.

Esa austeridad técnica ayuda a explicar el interés que ha despertado. En un entorno donde muchos sistemas de inferencia dependen de pilas enormes de software, Colibri apuesta por un diseño plano, legible y extremadamente específico para este caso de uso.

Qué trae el motor y qué compromisos asume en el camino

Colibri no se presenta como un experimento superficial, sino como un motor con múltiples optimizaciones enfocadas en GLM-5.2. Entre ellas figuran una implementación fiel del avance del modelo, atención MLA, caché KV comprimido y enrutamiento sigmoide estilo DeepSeek-V3.

Uno de los datos más llamativos es la reducción del caché KV. La documentación indica 576 floats por token en lugar de 32.768, lo que equivale a una estructura 57 veces más pequeña en un modelo que usa 64 cabezas y no GQA.

También incluye decodificación especulativa nativa MTP. En ese esquema, la propia cabeza de predicción de múltiples tokens de GLM-5.2 propone tokens y el modelo principal los verifica en un avance por lotes.

El proyecto advierte que esa cabeza debe mantenerse en int8. Según sus mediciones comunitarias, si se cuantiza a int4 la aceptación del borrador cae a entre 0% y 4%, mientras que en int8 sube a entre 39% y 59%.

Con esa configuración, la comunidad reportó entre 2,2 y 2,8 tokens por avance. Aun así, la documentación aclara que con una caché fría la especulación puede empeorar el tiempo efectivo, porque cada borrador verificado obliga a cargar expertos adicionales.

El motor también incorpora muestreo con temperatura y top-p, kernels de punto entero, absorción de peso MLA para decodificación y adelanto de lectura asíncrona de expertos. Además suma atención dispersa DSA, persistencia de caché KV y prefetch experimental basado en predicción del enrutador.

Otro rasgo importante es la persistencia de conversación. El modo de servicio guarda la caché KV MLA comprimida en archivos .coli_kv, con un costo aproximado de 182 KB por token, para reabrir sesiones de forma cálida incluso tras reiniciar el motor.

En conjunto, la propuesta no dice que ejecutar un modelo de 744.000 millones sea barato en términos de latencia. Lo que sostiene es que sí puede volverse manejable en equipos de consumo, si se aceptan compensaciones severas en velocidad y almacenamiento.

Rendimiento real: la barrera ya no es la RAM, sino el disco

La propia documentación del proyecto es directa sobre sus límites. En una prueba bajo WSL2, con 12 núcleos, 25 GB de RAM y NVMe a través de VHDX, el modelo ocupa cerca de 370 GB en disco y tarda unos 30 segundos en cargar.

La RAM residente de la parte densa es de 9,9 GB. Durante el chat, el pico RSS llega a cerca de 20 GB, con un límite automático pensado para evitar que el sistema entre en intercambio y active el OOM killer del kernel.

El problema duro aparece en la decodificación en frío. El proyecto calcula un costo de lectura desde disco de unos 11 GB por token, resultado de 75 capas por 8 expertos dirigidos.

Con un techo de disco cercano a 1 GB por segundo en ese entorno de prueba, el rendimiento frío estimado cae a entre 0,05 y 0,1 tokens por segundo. En otras palabras, la computadora puede hacerlo, pero el usuario tiene que convivir con tiempos de respuesta muy lentos.

La documentación insiste en que eso no invalida la demostración. Su argumento es que se trata de un modelo de clase frontera respondiendo correctamente en una máquina mucho más barata que un acelerador de centro de datos.

También añade una nota sobre la salud del SSD. El flujo de Colibri es de solo lectura, por lo que el desgaste por escrituras no sería el riesgo principal, aunque sí podrían surgir problemas si el sistema se queda sin RAM o si el disco entra en estrés térmico sostenido.

Ese matiz importa porque evita la lectura triunfalista. Colibri no elimina el costo físico de mover datos, sino que lo traslada a un componente más accesible para usuarios avanzados: un SSD local grande y razonablemente veloz.

En ese sentido, el proyecto reubica la discusión. Ya no pregunta si un modelo de este tamaño puede “caber” en una laptop de forma tradicional, sino si puede sobrevivir con una arquitectura de streaming lo bastante disciplinada.

Compatibilidad, herramientas y la posibilidad de usarlo como servicio

El repositorio ofrece un modelo GLM-5.2 preconvertido a int4 alojado en Hugging Face, además de una variante comunitaria con cabezas MTP en int8. Eso permite evitar por completo el paso de conversión desde el checkpoint FP8 original.

Si el usuario desea convertirlo por su cuenta, el proyecto incluye una herramienta offline FP8 a int4. Según la descripción, descarga una parte a la vez, dequantiza, reempaqueta al contenedor del motor y elimina la parte temporal, sin requerir tener simultáneamente los 756 GB del checkpoint FP8.

La ruta de tiempo de ejecución sigue siendo minimalista. Python se usa solo para tareas auxiliares de conversión o para el gateway HTTP, mientras la inferencia real corre en el mismo motor de C.

Colibri también expone un servicio compatible con la API de OpenAI mediante el comando coli serve. Ese modo mantiene el modelo cargado en un proceso persistente y ofrece endpoints de solo texto como chat completions, completions y modelos.

La primera versión de ese servidor atiende una generación a la vez. El proyecto explica que, como el motor posee un contexto KV mutable, las solicitudes concurrentes se encolan en FIFO en lugar de fingir una paralelización insegura.

Además, hay soporte para contextos KV aislados mediante slots, lo que permite mantener hasta 16 contextos de secuencia independientes. Cada slot conserva su historial de tokens, memoria KV comprimida y archivo de persistencia propio.

La compatibilidad no se limita a Linux o WSL2. El proyecto afirma que puede compilar y ejecutarse de forma nativa en Windows 11 x86-64 con MinGW-w64, usando una capa de compatibilidad que mapea funciones POSIX a la API de Windows.

También existe un backend CUDA experimental para tensores residentes. Sin embargo, el proyecto aclara que los expertos transmitidos se mantienen deliberadamente en CPU, porque mover un experto desde NVMe a GPU en cada uso solo sustituiría el cuello de botella del disco por uno de PCIe.

Qué dicen las cifras comunitarias y por qué este proyecto importa más como señal que como producto final

Las cifras compartidas por la comunidad muestran resultados muy distintos según el hardware. En una Apple M5 Max con 128 GB unificados y SSD interno, el proyecto reporta 14,2 GB por segundo en O_DIRECT y alrededor de 1,06 tokens por segundo, con MTP apagado.

En un Ryzen AI 9 HX 370 con 128 GB de RAM y una unidad WD SN850X, la comunidad reportó 0,37 tokens por segundo con cabeza MTP int8, límite de caché ampliado y 46,7 GB de expertos fijados automáticamente. En ese caso, la tasa de acierto de expertos llegó a 66%.

Otro ejemplo citado es un Ryzen 9 9950X con 123 GB de RAM. Al mover el modelo desde una unidad Crucial P3 QLC Gen3 a un Samsung 9100 PRO PCIe 5.0, el ancho de banda medido pasó de 1,51 GB por segundo a 8,81 GB por segundo en O_DIRECT.

Ese cambio elevó el rendimiento desde 0,10 hasta 0,28 tokens por segundo. Más importante aún, el perfil dejó de estar dominado por el disco y pasó a mostrar mayor peso del matmul de CPU.

La tesis del proyecto queda resumida ahí. Una vez que el almacenamiento deja de ser el principal cuello de botella, el problema vuelve a la computación, la RAM disponible para expertos calientes y, eventualmente, a la utilidad de un backend CUDA más maduro.

El propio repositorio ofrece predicciones aproximadas. Habla de entre 0,5 y 1 token por segundo en Linux nativo con NVMe PCIe 4 y 32 GB de RAM, de entre 2 y 4 tokens por segundo en configuraciones con NVMe PCIe 5 o RAID0 y 64 GB, y hasta entre 5 y 15 tokens por segundo en equipos con más núcleos y mejores kernels.

Esas cifras no deben leerse como una promesa cerrada, sino como hipótesis de escalado. El proyecto reconoce que necesita más datos reales de máquinas más potentes y pide a la comunidad abrir incidencias con resultados verificables.

En términos periodísticos, esa honestidad quizá sea el elemento más importante. Colibri no vende una fantasía de velocidad, sino una prueba de que un modelo descomunal puede operar fuera del entorno habitual de hyperscalers, si se diseña una arquitectura que trate al disco como extensión dinámica del modelo.

Para la industria de IA, eso podría no reemplazar a la GPU ni a los servidores de alto rendimiento. Pero sí empuja una conversación relevante sobre soberanía tecnológica, experimentación local y acceso a modelos grandes para investigadores, desarrolladores y entusiastas con presupuestos muy distintos.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados