InfraestructuraAnálisis · En radarX: @ai_radar_→ original

Colibri, en C puro, ejecuta modelos MoE de más de 700B parámetros sin GPU

El repositorio JustVugg/colibri ha reunido unas 47,4 mil estrellas en GitHub, +802 en un día. Es un motor en C puro para modelos MoE gigantes: no mantiene todos los pesos en memoria, sino que va trayendo del disco a los «expertos» necesarios a medida que genera. Se declara compatibilidad con GLM, Kimi, DeepSeek y Qwen. Se promete ejecutar modelos desde 700B parámetros sin GPU, pero la publicación no indica la velocidad.

Procesado por IA desde X: @ai_radar_; editado por Hamidun News
Colibri, en C puro, ejecuta modelos MoE de más de 700B parámetros sin GPU
Fuente: X: @ai_radar_. Collage: Hamidun News.
Escuchar artículo
Ficha técnica y cifras clave
ParámetroDatos
Fuente originalX: @ai_radar_ ↗
Editor jefe
Dato clave #1MoE activa solo una pequeña parte de los pesos en cada token
El precio de este truco es la velocidadel disco es más lento que la memoria de vídeo
Dato clave #3Antes de adoptarlo, mida los tokens por segundo en su propio SSD

Cuando se habla de ejecutar enormes modelos open-weight, la conversación suele terminar igual: «hace falta un rack de GPU». El repositorio Colibri propone otro camino. Según una publicación en el agregador AI Radar, el proyecto ha reunido unas 47,4 mil estrellas, 802 de ellas en un solo día. Es una señal fuerte de interés, aunque la propia publicación solo se ha visto 29 veces y casi no ofrece detalles. Veamos qué se sabe y qué conviene comprobar por cuenta propia.

Qué se afirma

Colibri se describe como un motor en C puro para ejecutar grandes modelos MoE en ordenadores corrientes. La característica clave: los expertos se cargan desde el disco según se necesitan. Entre las familias compatibles figuran GLM, Kimi, DeepSeek y Qwen. La tesis principal del autor de la publicación: los modelos de 700B o más se pueden ejecutar sin tarjeta gráfica.

El C puro también es un argumento. Supone mínimas dependencias, una compilación sencilla y un control claro de la memoria. Para código de infraestructura, donde importa cuántos bytes se leen del disco y cuándo, es una elección razonable.

Cómo funciona, con un ejemplo sencillo

MoE (Mixture of Experts) funciona así: en cada capa del modelo hay decenas o cientos de «expertos», es decir, bloques de pesos independientes. Para cada token, un router especial elige solo unos pocos. El resto permanece inactivo en ese momento.

Imagine una biblioteca con miles de libros. Para responder a una pregunta concreta hacen falta páginas de ocho libros. El enfoque clásico arrastra toda la biblioteca a la sala de trabajo, es decir, a la memoria de vídeo o a la RAM. Para un modelo de 700B, eso son cientos de gigabytes. El enfoque de Colibri, tal como se describe, es distinto: sobre la mesa solo está lo necesario y el resto queda en la estantería, es decir, en el SSD. Cuando el router pide nuevos expertos, el motor los lee del disco.

Una aritmética sencilla muestra la escala. 700 mil millones de parámetros en formato de 4 bits ocupan aproximadamente 350 GB. No caben en la RAM de un PC corriente, pero sí en un buen disco NVMe. Por cada token solo se lee una fracción de esos pesos, y en eso se sostiene toda la idea.

Limitaciones que la publicación no menciona

Primero, la velocidad. Un disco NVMe lee órdenes de magnitud más lento que la memoria de una GPU. Si cada token requiere expertos nuevos, la generación se topará con el cuello de botella del disco. La publicación no da ninguna cifra de tokens por segundo, y esa es la métrica principal. Quizá sea tolerable para procesamiento por lotes o experimentos, pero un chat interactivo o un ciclo de agente con decenas de llamadas podrían resultar penosos.

Segundo, el almacenamiento. Se necesitan cientos de gigabytes libres y una unidad rápida. En un SATA antiguo o un HDD el panorama será bastante peor.

Tercero, calidad y compatibilidad. No se sabe qué formatos de cuantización se admiten ni cuánto coincide el resultado con las implementaciones de referencia. La afirmación «funciona con DeepSeek, Kimi, GLM, Qwen» aún no significa que funcione cada versión de cada modelo.

Por último, la propia fuente. La publicación parece un resumen automático de un repositorio en tendencia. Conviene verificar directamente en GitHub la cifra de estrellas y la lista de modelos.

Qué hacer con esto en la práctica

Si es desarrollador o fundador y evalúa LLM autoalojados, Colibri merece un lugar en su lista para una prueba rápida. Los pasos son sencillos:

  • Lea el README y la lista de modelos y formatos compatibles.
  • Tome un modelo MoE de tamaño medio y mida los tokens por segundo en su propio SSD.
  • Compare el resultado con el alquiler de una GPU o con una API convencional. Para tareas poco frecuentes, datos privados y escenarios sin conexión, un disco en lugar de una tarjeta gráfica puede resultar más rentable.
  • No lleve el proyecto a producción hasta ver benchmarks estables y un historial de commits activo.

El panorama general es este: la arquitectura MoE hace que los modelos gigantes exijan menos cómputo por token, y herramientas como Colibri intentan que exijan menos hardware. Si las afirmaciones se confirman, la barrera de entrada para experimentar con modelos de clase 700B bajará notablemente. Pero por ahora es una promesa, no un resultado medido.

Historia

Preguntas frecuentes sobre la noticia

¿Qué se sabe sobre Qué se afirma?

Colibri se describe como un motor en C puro para ejecutar grandes modelos MoE en ordenadores corrientes. La característica clave: los expertos se cargan desde el disco según se necesitan. Entre las familias compatibles figuran GLM, Kimi, DeepSeek y Qwen. La tesis principal del autor de la publicación: los modelos de 700B o más se pueden ejecutar sin tarjeta gráfica. El C puro también es un argumento. Supone mínimas dependencias, una compilación sencilla y un control claro de la memoria.

Cómo funciona, con un ejemplo sencillo?

MoE (Mixture of Experts) funciona así: en cada capa del modelo hay decenas o cientos de «expertos», es decir, bloques de pesos independientes. Para cada token, un router especial elige solo unos pocos. El resto permanece inactivo en ese momento. Imagine una biblioteca con miles de libros. Para responder a una pregunta concreta hacen falta páginas de ocho libros. El enfoque clásico arrastra toda la biblioteca a la sala de trabajo, es decir, a la memoria de vídeo o a la RAM.

¿Qué se sabe sobre Limitaciones que la publicación no menciona?

Primero, la velocidad. Un disco NVMe lee órdenes de magnitud más lento que la memoria de una GPU. Si cada token requiere expertos nuevos, la generación se topará con el cuello de botella del disco. La publicación no da ninguna cifra de tokens por segundo, y esa es la métrica principal. Quizá sea tolerable para procesamiento por lotes o experimentos, pero un chat interactivo o un ciclo de agente con decenas de llamadas podrían resultar penosos. Segundo, el almacenamiento.

ZK
Zhemal Khamidun — CPO de Alpina Digital, product manager de AlpinaGPT. Crea productos de IA desde 2019. Hamidun News es un proyecto personal que creció hasta ser un agregador en producción con más de 6.000 lectores.
✦ Unified AI Workspace · Nomad

Test Frontier LLMs & Autonomous Agents in One Workspace

Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.

Try Nomad AI →Launch Nomad Agent
¿Qué te parece?
Cargando comentarios…