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

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.

Actualizado y contrastado con las fuentes el 24 de septiembre de 2026. La versión más reciente verificada para este análisis es Colibri v1.12.0, publicada el 20 de septiembre. Ya no basta con describirlo como un experimento principalmente textual con ocho familias. Brio puntúa respuestas permitidas sin generar una contestación, el panel se ha rediseñado y se han corregido problemas de backend y validación. La versión 1.11.0 ya había incorporado DeepSeek V4.1 Flash como novena familia de motores.

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.

¿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. Colibri no es un cargador GGUF genérico.

Corrección importante del espacio en disco: el README etiquetado sigue indicando 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 antiguo del README sigue diciendo 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.

¿Qué es el modo Brio de Colibri y cuándo resulta útil?

Brio es un modo de puntuación del modelo ya cargado en Colibri, no un modelo nuevo ni una integración con Jev o Laya. Proporcionas un conjunto cerrado de respuestas. El motor evalúa los tokens de cada opción y devuelve una respuesta seleccionada, puntuaciones relativas y entropía normalizada en lugar de generar texto libre.

El endpoint acepta tres formatos: options para una pregunta, questions para varias sobre el mismo contexto y schema para campos cuyos valores deben proceder de listas permitidas. Aquí schema es el mapa de campos a valores permitidos de Brio, no un JSON Schema arbitrario. El servidor escribe la estructura JSON; el modelo solo puntúa los valores. Una salida bien formada puede seguir conteniendo una decisión equivocada.

Cero tokens de completado no equivale a coste de inferencia cero. El documento todavía necesita prefill y cada opción requiere puntuación. Las instantáneas de prefijos evitan parte del procesamiento repetido mientras el motor permanece activo. Reiniciarlo elimina esas instantáneas; las peticiones intercaladas y los slots KV disponibles influyen en su reutilización. El ejemplo documentado de cuatro campos tardó 103,8 segundos con Brio frente a 246,0 generando texto, aproximadamente 2,37 veces más rápido por cálculo. Es un experimento Qwen3.6 del proyecto, no un benchmark GLM ni un ahorro universal.

Por defecto, Brio promedia las logprobabilidades de los tokens antes de normalizar las puntuaciones entre opciones. Esto reduce una penalización simple por longitud, pero no convierte la puntuación en una probabilidad calibrada de acierto. Entropía baja significa que domina una opción ofrecida, no que se haya ofrecido la correcta. Incluye una vía de abstención, prueba distintas etiquetas y longitudes y calibra los umbrales de revisión con ejemplos etiquetados. Añadir «human review» no garantiza que el modelo se abstenga de forma fiable.

Por ello merece la pena probar clasificaciones repetidas sobre un documento común cuando importa ejecutar localmente. No significa superar automáticamente a un clasificador pequeño, una regla o un endpoint alojado de decisiones. Nuestro análisis del modelo de decisiones Jev aborda esa categoría separada. Esta sección se limita a aprovechar mejor el motor existente de Colibri.

¿Cómo instalar y probar Colibri v1.12.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 v1.12.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 Brio. 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/brio \
  -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.",
    "question": "Which team should inspect the evidence?",
    "options": ["billing", "technical support", "human review"],
    "normalize": "mean"
  }'

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.

Algunos párrafos de la API todavía niegan globalmente el soporte de imágenes y logprobabilidades. Es demasiado amplio para la versión actual: motores recientes incluyen visión y Brio utiliza explícitamente logprobabilidades de opciones. A la inversa, Brio no demuestra que todos los parámetros habituales, bloques multimodales o herramientas funcionen en todos los endpoints. Valida motor, endpoint y formato exactos. Las combinaciones no compatibles deben fallar de forma explícita, no descartar datos silenciosamente.

¿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 Brio, 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 24 de septiembre de 2026 sobre v1.12.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 Brio 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.