Colibri Ejecuta GLM-5.2 en Hardware de Consumo. Esta Es la Trampa.

Volver

Kevin Riedl

22 min de lectura · 14 de julio de 2026
Última revisión 4 de noviembre de 2026

Siguiente

Colibri sigue pudiendo ejecutar GLM-5.2 con unos 25 GB de RAM. Es un avance en capacidad de memoria, no una promesa de conversación rápida. La medición original del desarrollador obtuvo 0,05-0,1 tokens generados por segundo con la caché fría. A esas velocidades históricas, producir 100 tokens lleva unos 17-33 minutos, sin contar el procesamiento del prompt. Las pruebas posteriores de contenedores concretos son más rápidas: la cifra original no es un límite universal para un presupuesto de 25 GB.

Fuentes revisadas el 4 de noviembre de 2026. La última versión verificada es Colibri v2.1.0, publicada el 31 de octubre. Añade importación GGUF, más rutas Vulkan/CUDA y nuevos modelos. La ruta Brio se ha eliminado: las integraciones actuales usan POST /v1/systemone. Las versiones de septiembre v1.12.0 y v1.11.0 son contexto histórico, no el límite de funciones actual.

Conservamos el enfoque original: qué puede hacer Colibri en tu hardware, cuánto cuesta en latencia y memoria, y cómo probarlo sin confundir un arranque correcto con un despliegue de producción. Todas las velocidades proceden de resultados atribuidos a las fuentes, no de mediciones de Wavect.

¿Qué es Colibri y qué ha cambiado desde nuestro último análisis?

Colibri, escrito Colibrì por sus responsables, es un entorno de inferencia con licencia Apache 2.0 que distribuye pesos entre almacenamiento NVMe, RAM y VRAM opcional. No comprime un modelo de 744.000 millones de parámetros dentro de 25 GB. El checkpoint permanece en disco; solo las partes necesarias en cada momento deben estar en memoria rápida. El README de la versión revisada distingue el motor C sin dependencias del lanzador y la pasarela HTTP en Python. Por tanto, afirmar que el flujo habitual de coli no utiliza Python en ejecución resulta engañoso.

El contenedor Colibri de GLM-5.3 ocupa aproximadamente 419 GB y utiliza la misma familia de motores que GLM-5.2. A diferencia del contenedor recomendado de 5.2, no incluye una cabeza MTP, por lo que esa ruta de decodificación especulativa permanece desactivada. Es otra elección de checkpoint, no una actualización automática de los pesos de 5.2.

¿Qué cambió después de la base de septiembre?

El README de v2.1.0 incluye nuevas rutas MiMo, Flint, Mistral-Large-4 y LFM3. El soporte GPU sigue dependiendo del motor; un controlador Vulkan no garantiza acelerar cada operación. La descarga actual de Inkling ocupa unos 514 GB antes de la conversión densa documentada, frente al antiguo resumen de 469 GB.

La importación GGUF permite que ./coli import model.gguf cree metadatos de una arquitectura compatible. El modo link lee los archivos existentes; copy puede necesitar más disco. Todos los fragmentos deben seguir disponibles. La versión publica un GLM-5.2 UD-IQ1_S de 202 GB y 0,633-0,658 tok/s en su equipo Vulkan. Cambian cuantización y máquina respecto a la base int4 agrupada de 429 GB: no es una mejora de velocidad con calidad equivalente para un portátil de 25 GB.

¿Cómo funciona un modelo de 744B con 25 GB de RAM?

GLM-5.2 es un modelo Mixture-of-Experts: activa unos 40B de sus aproximadamente 744B parámetros por token. Su ficha oficial describe el modelo, pero sus afirmaciones de capacidad no demuestran la calidad de una cuantización concreta de Colibri. El motor mantiene unos 9,9 GB de pesos densos residentes y recupera del almacenamiento los expertos seleccionados. El diseño original contiene 19.456 bloques de expertos distribuidos entre 75 capas MoE y la cabeza MTP.

Una caché por capa, la fijación aprendida de expertos frecuentes, la caché del sistema operativo y la ubicación opcional en GPU evitan parte de las lecturas repetidas. La estimación original en frío es de unos 11 GB de pesos de expertos leídos por token generado. Es una estimación de un diseño y una carga concretos, no una constante de todos los modelos, checkpoints o modos especulativos.

Hay dos conceptos distintos: la cuantización cambia la representación de los pesos; los niveles de memoria cambian dónde esperan esos pesos. Obtener el mismo resultado cuantizado en CPU y GPU no demuestra que la cuantización conserve la precisión del modelo original. A la inversa, un motor numéricamente correcto puede seguir siendo demasiado lento para tu aplicación.

¿Qué modelos admite Colibri y cuánto hardware necesitan?

El registro de familias de v1.12.0 permite distinguir una familia de motores de un nombre de checkpoint. Nueve familias no significan nueve identificadores arbitrarios. Cada una necesita implementaciones específicas de enrutamiento, atención, formatos de tensores y conversación. Ese registro de septiembre es anterior a la importación GGUF; v2.1.0 admite las arquitecturas documentadas arriba.

Corrección importante del espacio en disco: el README de septiembre v1.12.0 indicaba 372 GB para el contenedor GLM-5.2. La ficha del contenedor contiene resúmenes de tamaño diferentes, mientras que el listado actual de archivos muestra aproximadamente 429 GB. Planifica según la revisión y los archivos seleccionados, no según el titular anterior. No mezcles GB decimales con GiB binarios. El contenedor E8/IQ3 más pequeño indica unos 289 GB, pero cambia la representación y tiene sus propios compromisos de precisión y coste de decodificación. La reducción no es gratuita.

La documentación del motor DeepSeek V4.1 Flash explica por qué el tamaño completo predice mal el trabajo por token: unos 203 GB son memoria de n-gramas respaldada por disco, y los expertos enrutados cuestan unos 4,5 GB por token antes de los aciertos de caché. Los pesos no requieren conversión, pero la instalación documentada crea el pequeño archivo auxiliar dsv41_engram.json. «Sin conversión» no significa «sin preparación».

También existe una contradicción documental sobre Qwen3.8. El resumen del README de septiembre decía 16 GB como mínimo y solo CPU. Las mediciones detalladas de Qwen3.8 registran unos 16,5 GiB de RSS máxima para una petición corta con cap 32 y plantean 24 GB como tamaño práctico del equipo para ese caso, o 32 GB para una caché mayor. v1.12.0 incorpora CUDA pese a conservar algunos párrafos que niegan su existencia. Prioriza la implementación de la versión y la configuración medida, no una fila aislada.

¿Qué velocidad alcanza Colibri en hardware de consumo?

La colección de benchmarks del proyecto conserva los siguientes resultados de GLM-5.2. La fila Core Ultra 9 con RAM limitada procede de la ficha del contenedor enlazada antes. Son ejecuciones históricas con distintas compilaciones, cachés y representaciones, no una comparación controlada de v1.12.0. Algunas filas antiguas no cumplen los nuevos requisitos de evidencia de corrección GPU del proyecto.

El resultado con seis GPU no representa un portátil de consumo. Pruebas posteriores de ubicación NUMA selectiva alcanzaron unos 9 tok/s en un equipo multisocket concreto. Asimismo, la mejora de Qwen3.6 de 12,8 a 15,7 tok/s, reduciendo su memoria residente de 29 a 17 GB, corresponde a esa carga Qwen. No convierte GLM-5.2 en un modelo de 15,7 tok/s sobre 25 GB.

En un servicio real debes medir la petición completa: espera en cola, prefill del prompt, generación y posibles llamadas a herramientas. Un prompt reutilizado puede tener un prefill casi nulo mientras un documento nuevo sigue siendo lento. Una captura del panel durante una conversación caliente no establece la latencia de documentos nuevos.

¿Qué conviene optimizar primero: RAM, NVMe o GPU?

Empieza por la fase que consume el tiempo real. En GLM con poca memoria pueden dominar los fallos de caché de expertos. En un equipo con amplia residencia pueden limitar la multiplicación matricial de CPU o el ancho de banda de memoria. La comparación histórica de SSD en la misma máquina elevó el ancho de banda medido de 1,51 a 8,81 GB/s, pero la generación solo pasó de 0,10 a 0,28 tok/s porque el cálculo cobró más importancia.

Mide lecturas de shards fríos y sin caché, no el máximo secuencial anunciado por el SSD. En macOS, la prueba documentada con F_NOCACHE no elimina las páginas que una ejecución anterior ya almacenó. Compara también varios prompts: los expertos fijados por historial pueden favorecer la carga que creó ese historial. Aumentar la caché o la RAM asignada no siempre acelera si provoca contención o elimina el margen del sistema.

Una GPU ayuda cuando su backend reduce el cuello de botella medido. Tenerla instalada no elimina los fallos de caché en disco. Incluye una prueba de calidad junto a cada tiempo de CUDA, HIP, Metal o Vulkan: el proyecto documenta un caso HIP con rendimiento parecido pero perplejidad mucho peor. La velocidad por sí sola no habría detectado el fallo.

MTP también es un experimento, no un interruptor de aceleración gratuita. GLM-5.2 necesita la cabeza MTP int8 correcta, y las lecturas especulativas adicionales pueden perjudicar con caché fría. El atajo del router --topp 0.7 cambia explícitamente el enrutamiento con pérdida; no equivale al muestreo habitual de tokens de salida. Reevalúa la calidad siempre que cambies la semántica del modelo.

¿Cuánta calidad conserva la ruta int4 de GLM-5.2?

La evidencia disponible sigue siendo más limitada que una afirmación de «calidad frontier en un portátil». Una pequeña prueba GLM-5.2 del proyecto publica un 62,5 % de precisión normalizada media en HellaSwag, ARC y MMLU, con solo 40 preguntas por tarea. Su experimento separado con OLMoE midió una pérdida por cuantización de 8,2 puntos porcentuales, de la que las escalas agrupadas recuperaron aproximadamente el 63 %. Es información sobre un método, no una comparación limpia entre GLM-5.2 original e int4.

Hay evidencia GLM más directa que ese resumen antiguo: la ficha int4 agrupada publica en HellaSwag un 87,0 % frente al 83,5 % de la variante int4 por fila, con 200 preguntas. La ficha E8 también compara con int4 agrupado, pero las muestras pequeñas y el enrutamiento consciente de caché activado no aíslan el error de cuantización. Son pruebas útiles y limitadas, no equivalencia con el modelo original ni demostración de razonamiento fiable en producción.

Para tu evaluación, conserva checkpoint, cuantización, plantilla de prompt y resultados esperados. Incluye negativos difíciles, entradas multilingües y tareas que antes entraban en bucle o agotaban la salida. Comprueba tanto la respuesta como la terminación. Una implementación exacta a nivel de token y una respuesta empresarial útil contestan preguntas distintas.

¿El streaming de expertos desgasta el SSD?

No contabilices 11 GB de lecturas como 11 GB consumidos de la resistencia de escritura. La explicación de Kingston sobre TBW y DWPD define estas métricas mediante datos escritos y ciclos de programación y borrado. La ruta de expertos de Colibri es intensiva en lectura, pero descargas, conversión, estado persistido y swap del sistema pueden escribir datos.

Supervisa temperatura, salud SMART y actividad de swap durante una ejecución larga y representativa. Deja margen de RAM para evitar que la caché provoque paginación intensiva en escritura. Una NVMe dedicada de 1 TB es una previsión razonable para la descarga de referencia de unos 429 GB más margen operativo, no un mínimo del software ni una garantía de que cualquier conversión desde el original quepa. Revisa aparte el espacio temporal.

De Brio a System One: ¿cómo migrar los clientes existentes?

El contrato actual de System One sustituye a /v1/brio, disponible hasta v1.12.1. Envía state y un objeto de questions tipadas: choice usa etiquetas con descripciones, noul preguntas sí/no y score niveles ordenados. Las respuestas están en answers. No basta con cambiar la URL: los antiguos formatos options y schema no se trasladan sin cambios.

En puntuación con modelos de lenguaje, normalize: "sum" es ahora el valor predeterminado. mean es opcional y puede distorsionar comparaciones entre etiquetas de distinta longitud. Cada pregunta independiente lee el estado; a diferencia del schema secuencial anterior, las posteriores no ven automáticamente los valores elegidos antes. Encadena explícitamente las decisiones dependientes.

El resultado anterior de cuatro campos Brio con Qwen3.6, 103,8 frente a 246,0 segundos, sigue siendo evidencia histórica, no un benchmark GLM ni una garantía actual de System One. No generar texto libre no elimina el coste de prefill, puntuación y caché. Las probabilidades y la confianza no garantizan de forma calibrada que la decisión empresarial sea correcta. Conserva revisión humana y prueba etiquetas, costes de error y umbrales con casos propios.

Nuestro análisis del modelo de decisiones Jev cubre esa categoría por separado. Compatibilidad de protocolo no implica calidad equivalente ni autorización.

¿Cómo instalar y probar Colibri v2.1.0?

Para compilar de forma reproducible en un sistema Unix compatible, fija la versión en lugar de descargar un futuro main sin especificar. Instala primero Python 3 y un compilador C compatible con OpenMP. Los comandos siguientes no descargan los pesos: /nvme/glm52_i4 ya debe contener el checkpoint GLM-5.2 int4 agrupado con MTP int8 enlazado antes. Para Windows u otros compiladores y backends, sigue las instrucciones de esa plataforma.

git clone --branch v2.1.0 --depth 1 https://github.com/JustVugg/colibri.git
cd colibri/c
./setup.sh
export COLI_MODEL=/nvme/glm52_i4
./coli doctor --deep
./coli plan
./coli chat

doctor --deep comprueba la preparación del modelo; plan explica su distribución. Ninguno demuestra precisión ni latencia de servicio. Guarda el plan y la revisión o checksums del checkpoint con el registro del benchmark. La misma familia carga GLM-5.3, pero necesita su propio contenedor y no debes esperar el comportamiento MTP de GLM-5.2.

Para probar la pasarela, inicia un servidor persistente en un terminal. Sustituye el marcador por un secreto local robusto y conserva la dirección de loopback durante la evaluación:

export COLI_API_KEY='replace-with-a-long-random-local-secret'
COLI_MODEL=/nvme/glm52_i4 ./coli serve \
  --host 127.0.0.1 --port 8000 --model-id glm-5.2-colibri

En un segundo terminal, configura COLI_API_KEY con el mismo secreto y envía este ejemplo sintético de System One. El identificador del modelo debe coincidir con el del servidor. La petición propone una cola de revisión: no devuelve un pago ni determina si realmente hubo un cargo duplicado.

curl --fail-with-body http://127.0.0.1:8000/v1/systemone \
  -H "Authorization: Bearer ${COLI_API_KEY:?Set the same key as the server}" \
  -H 'Content-Type: application/json' \
  --data-binary '{
  "model": "glm-5.2-colibri",
  "state": "The ticket reports two charges for one renewal. The payment ledger has not been checked.",
  "questions": {
    "queue": {
      "type": "choice",
      "instructions": "Which team should inspect the evidence?",
      "criteria": {
        "billing": "Inspect the payment ledger",
        "technical support": "Investigate a technical fault",
        "human review": "Insufficient evidence; ask a person"
      }
    }
  },
  "normalize": "sum"
}'

El ejemplo se basa en el contrato API documentado, no en una integración en vivo probada para este artículo. En una aplicación, añade un timeout acorde al prefill medido, valida la respuesta y gestiona rechazos de cola o fallos del motor. No publiques el listener en Internet solo para conectar un editor remoto.

¿Puede utilizarse la API con Claude Code o una aplicación empresarial?

La documentación de la pasarela describe rutas de chat y completado compatibles con OpenAI y /v1/messages bajo el protocolo Anthropic. Compatibilidad de protocolo no garantiza idéntico uso de herramientas ni calidad de programación. Los grandes prompts de sistema y catálogos de herramientas de los agentes pueden aumentar mucho la latencia inicial frente a un chat manual breve.

La ruta habitual de servicio sigue ejecutando una generación cada vez, con admisión limitada y respuestas HTTP 429 para solicitudes rechazadas o caducadas en cola. Los slots KV conservan contextos separados cuando el motor lo permite; no son batching continuo ni una capacidad idéntica en todos los motores. Ajusta los tiempos de cola a duraciones medidas, no a titulares optimistas de tokens por segundo.

Visión, logprobabilidades y herramientas dependen del motor y endpoint. System One puntúa opciones, pero no habilita cada parámetro, imagen o tool en todas partes. Valida la combinación exacta; los casos no admitidos deben fallar explícitamente, no descartar datos en silencio.

¿Dónde tiene sentido empresarial Colibri ahora?

Nuestra valoración pasa de un «no está listo para producción» genérico a evaluar la carga y el motor seleccionado por separado. El proyecto tiene capacidades y mejoras concretas, pero este análisis no establece un nivel de servicio de producción. GLM-5.2 transmitido desde disco en una máquina de 25 GB sigue siendo una mala elección para chats concurrentes y rápidos de clientes.

La ejecución local puede mejorar el control del tráfico del modelo. No resuelve por sí sola permisos, retención, copias de seguridad, telemetría del cliente o control de acceso. Para las cifras económicas, utiliza nuestro marco de equilibrio entre modelos locales y APIs, en lugar de considerar gratuitos los tokens no facturados. Antes de comprar hardware, nuestra guía de hardware con llmfit ayuda a preseleccionar combinaciones convencionales de modelos y runtimes; no simula la caché de expertos de Colibri.

¿Cómo medir una actualización antes de depender de ella?

Sigue el protocolo reproducible de benchmarks del proyecto y conserva los registros originales. Empieza por tareas representativas, no por un saludo. Anota commit, revisión del modelo, conversión, comandos, longitud de contexto, distribución RAM/VRAM y almacenamiento.

Separa casos fríos, repeticiones idénticas y prompts rotatorios dentro de un servidor persistente. Publica latencia inicial, tiempo completo, salida aceptada, velocidad de decodificación, aciertos de caché, bytes leídos y memoria máxima. Alterna las configuraciones entre repeticiones para evitar que temperatura, historial o carga de fondo decidan el resultado. Para System One, registra también opciones, normalización, coste de clasificación errónea y tasa de revisión humana.

Nuestra recomendación de implementación es comenzar en modo sombra: calcular la respuesta sin ejecutar la acción empresarial, compararla con el proceso actual y ampliar después de revisarla. La diferencia entre una demo prometedora y un sistema operable también aparece en nuestro caso Twinsoft AI y nuestra guía de selección tecnológica. El servicio de AI enablement de Wavect cubre evaluación, integración, observabilidad y mecanismos de respaldo.

Fuentes, fecha de revisión y limitaciones

Este es un análisis técnico basado en fuentes, actualizado el 4 de noviembre de 2026 sobre v2.1.0. Las fuentes primarias están junto a las afirmaciones correspondientes. Usamos código y documentación etiquetados por versión cuando están disponibles; los repositorios de modelos pueden cambiar. Se conserva la publicación original del 14 de julio de 2026.

No hemos descargado ni ejecutado estos grandes checkpoints, reproducido benchmarks comunitarios ni probado un despliegue System One en vivo para esta actualización. Los tiempos usan segundos = tokens_de_salida / tokens_por_segundo, sin prefill ni cola. La razón de Brio se calcula con 246.0 / 103.8. Los criterios de aceptación y la idoneidad empresarial son nuestro análisis, no garantías del proyecto. Las discrepancias documentales se identifican en lugar de convertirlas en afirmaciones universales aparentemente seguras.

¿Necesitas convertir estas pruebas en una decisión de despliegue? Habla con Wavect sobre una evaluación medible de IA local.