GLM-5.2 corre local: 744B parámetros en 2-bit ocupan 239 GB

Z.ai liberó GLM-5.2, un modelo de lenguaje abierto de 744 mil millones de parámetros que, según los benchmarks públicos, rinde a la par de los modelos propietarios más fuertes del mercado. La noticia para quienes trabajamos en LATAM no es solo el modelo: es que GLM-5.2 local ya es posible en una sola máquina, gracias a los GGUFs dinámicos publicados por Unsloth.

Hasta hace poco, correr un modelo de esta escala fuera de un datacenter era impensable. Hoy, con la cuantización dinámica, el archivo cabe en una Mac con memoria unificada o en un servidor con una GPU y suficiente RAM. Acá te contamos qué cambió, cuánto hardware necesitás y cómo ponerlo a andar.

TL;DR

• GLM-5.2 de Z.ai tiene 744B parámetros totales, 40B activos y ventana de contexto de 1M de tokens.
• Unsloth publicó GGUFs dinámicos que permiten correrlo local en llama.cpp y en Unsloth Studio.
• La cuantización dinámica de 2-bit (UD-IQ2_M) ocupa 239 GB y entra en una Mac de 256 GB de memoria unificada.
• El quant de 1-bit alcanza ~76.2% de precisión top-1 siendo 86% más pequeño que el modelo completo de 1.5 TB.
• El de 2-bit llega a ~82% de precisión; según Unsloth es solo ~24% menos capaz que el modelo full.
• GLM-5.2 rinde a la par de Claude 4.8 Opus, GPT-5.5 y Gemini 3.1 Pro en varios benchmarks.
• Tiene 3 modos de razonamiento: sin pensar, High y Max, controlados con reasoning_effort.

Qué pasó

Z.ai presentó GLM-5.2 como su nuevo modelo abierto orientado a tareas de programación de largo horizonte, razonamiento y trabajo agéntico. La arquitectura es un Mixture of Experts (MoE): tiene 744B parámetros en total, pero en cada paso de inferencia solo activa 40B. Esa diferencia es la clave de por qué un modelo tan grande puede correr en hardware accesible.

El mismo día del lanzamiento, Unsloth publicó sus Dynamic GGUFs, los archivos cuantizados que reducen drásticamente el tamaño del modelo sin destruir su calidad. Con ellos, GLM-5.2 local pasó de ser una promesa a algo que cualquiera con suficiente memoria puede ejecutar en llama.cpp o en la nueva interfaz web Unsloth Studio.

Lo notable es el equilibrio entre tamaño y precisión. El modelo completo en precisión nativa pesa alrededor de 1.5 TB. La versión dinámica de 1-bit ocupa apenas 223 GB —un 86% menos— y aun así conserva cerca del 76.2% de precisión top-1. La de 2-bit, con 239 GB, sube a ~82%. En palabras de Unsloth, el modelo no es un 86% peor por ser un 86% más pequeño: es solo un ~24% menos capaz que el original.

💭 Clave: que un modelo tenga 744B parámetros pero active solo 40B significa que el costo de cómputo por token es el de un modelo de 40B, mientras que la memoria necesaria es la del archivo cuantizado completo. Por eso la cuantización importa tanto acá.

Contexto e historia: por qué la cuantización dinámica cambia el juego

La cuantización es el proceso de representar los pesos de una red neuronal con menos bits. Un modelo nativo suele usar 16 bits por peso; bajar a 4, 2 o incluso 1 bit recorta el tamaño de forma agresiva. El problema clásico es que cuantizar todo por igual degrada la calidad de manera notoria, sobre todo en las capas sensibles.

La propuesta de Unsloth, bautizada Dynamic 2.0, es cuantizar de forma selectiva: algunas capas se mantienen en mayor precisión y otras se comprimen al máximo. El resultado es una curva precisión-tamaño mucho más favorable que la cuantización uniforme. Para medirlo, Unsloth corre KLD (divergencia de Kullback-Leibler), una métrica que compara la distribución de probabilidades del modelo cuantizado contra el original.

Según sus números, los cuantizados dinámicos de 4-bit (UD-Q4_K_XL) y 5-bit (UD-Q5_K_XL) son prácticamente lossless, es decir, sin pérdida perceptible. Y la KLD media sigue una tendencia monótona clara respecto al espacio en disco: incluso en 1-bit, GLM-5.2 sigue funcionando bien.

📌 Nota: el famoso "76% de precisión" no significa que el modelo escupa basura el 24% del tiempo. La pregunta "La capital de Francia es" sigue dando "París" el 100% de las veces. La divergencia ocurre en palabras de relleno y conectores —si un texto puede empezar con "Voy a", "El" o "Qué", el modelo elige entre opciones igualmente correctas con probabilidades ligeramente distintas.

La curva precisión-tamaño de los GGUFs dinámicos de GLM-5.2.

Datos y cifras: requisitos de hardware

El requisito real para correr GLM-5.2 local es la memoria total disponible, sumando VRAM de la GPU más RAM del sistema (o la memoria unificada en una Mac). Unsloth recomienda que esa memoria total supere el tamaño del archivo cuantizado con un margen cómodo. Esta es la tabla de referencia:

• 1-bit — 223 GB de memoria total.
• 2-bit — 245 GB. El quant UD-IQ2_M ocupa 239 GB en disco.
• 3-bit — entre 290 y 360 GB.
• 4-bit — entre 372 y 475 GB.
• 5-bit — 570 GB.
• 8-bit — 810 GB.

El caso más práctico es el de 2-bit. El archivo UD-IQ2_M entra directamente en una Mac con 256 GB de memoria unificada, y también funciona bien en una configuración con una GPU de 24 GB más 256 GB de RAM, descargando las capas MoE al sistema. Eso pone GLM-5.2 al alcance de una estación de trabajo seria, no de un cluster.

El flujo de ejecución, paso a paso

graph LR
  A["Descargar GGUF UD-IQ2_M"] --> B["Cargar en llama.cpp"]
  B --> C["Descarga de capas MoE a RAM"]
  C --> D["Inferencia local"]
  D --> E["Respuesta con razonamiento"]

Cómo correr GLM-5.2 local en tu máquina

Hay dos caminos: llama.cpp para quienes prefieren la línea de comandos, y Unsloth Studio para una interfaz web que detecta tu hardware y descarga las capas automáticamente. Veamos primero el camino clásico con llama.cpp, que funciona igual en los tres sistemas operativos.

1. Compilar llama.cpp y descargar el modelo

En macOS y Linux, el proceso es directo:

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build
cmake --build build --config Release -j

# descargar el quant de 2-bit (239 GB)
huggingface-cli download unsloth/GLM-5.2-GGUF \
  --include "*UD-IQ2_M*" \
  --local-dir models/glm-5.2

En Windows, lo más cómodo es usar PowerShell con CMake instalado (o directamente WSL2, que replica el flujo de Linux):

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build
cmake --build build --config Release

huggingface-cli download unsloth/GLM-5.2-GGUF --include "*UD-IQ2_M*" --local-dir models\glm-5.2

2. Lanzar la inferencia

Una vez descargado el GGUF, arrancás el modelo con los parámetros recomendados por Unsloth para la mayoría de tareas: temperatura 1.0 y top-p 0.95.

./build/bin/llama-cli \
  --model models/glm-5.2/UD-IQ2_M/GLM-5.2-UD-IQ2_M.gguf \
  --temp 1.0 \
  --top-p 0.95 \
  --ctx-size 16384 \
  --reasoning on

La ventana de contexto máxima del modelo es de 1.048.576 tokens, pero podés ajustar --ctx-size según la memoria que tengas libre después de cargar los pesos.

3. Controlar el modo de razonamiento

GLM-5.2 usa el modo "thinking" por defecto. Si querés desactivarlo para respuestas más rápidas, en macOS y Linux:

--chat-template-kwargs '{"enable_thinking":false}'

En Windows PowerShell, hay que escapar las comillas:

--chat-template-kwargs "{\"enable_thinking\":false}"

En versiones recientes de llama.cpp también podés usar los flags más simples --reasoning on o --reasoning off.

💡 Tip: si no querés pelearte con CMake ni con las rutas de los archivos, Unsloth Studio hace todo el trabajo. Busca, descarga y corre GGUFs y modelos safetensor, detecta configuraciones multi-GPU y ofrece tool calling con autorreparación, búsqueda web y ejecución de código Python y Bash, todo desde una UI en MacOS, Windows y Linux.

Unsloth Studio detecta el hardware y descarga las capas MoE automáticamente.

Modos de razonamiento y ajustes finos

GLM-5.2 tiene tres modos de pensamiento: sin pensar (non-thinking) y dos niveles de razonamiento, High y Max. El parámetro reasoning_effort acepta los valores "high", "max" o el razonamiento desactivado. La recomendación de Z.ai es reservar Max Thinking para tareas complicadas —refactorizaciones grandes, depuración de bugs sutiles, problemas de varios pasos— y usar High o non-thinking para lo cotidiano.

Para benchmarks de programación exigentes como SWE-Bench Pro, Unsloth sugiere ajustar top-p a 1.0 manteniendo la temperatura en 1.0. Esos pequeños cambios de muestreo afectan la diversidad de las respuestas y conviene tenerlos presentes si vas a evaluar el modelo de forma sistemática.

Impacto y análisis para LATAM

Para equipos en América Latina, GLM-5.2 local resuelve tres dolores reales. El primero es el costo: una vez que tenés el hardware, no pagás por token ni dependés de tarifas en dólares que se mueven con el tipo de cambio. El segundo es la latencia: correr el modelo en tu propia red elimina el viaje de ida y vuelta a servidores en otro continente, algo que se nota en flujos agénticos con muchas llamadas encadenadas.

El tercero, y quizá el más importante para sectores regulados, es la privacidad. Un banco, una fintech o un hospital que no puede mandar datos sensibles a una API externa ahora tiene una alternativa abierta y de calidad competitiva. GLM-5.2 corriendo dentro de tu infraestructura significa que el código propietario, los registros médicos o los datos financieros nunca salen de tus paredes.

La contrapartida honesta es el hardware. Una máquina con 256 GB de memoria unificada o un servidor con GPU y abundante RAM no es barato, y en la región el acceso a ese equipo puede ser limitado o muy caro de importar. Pero el cálculo cambia cuando lo comparás con el gasto recurrente de una API a escala: para una empresa con volumen alto y constante, la inversión inicial se amortiza.

⚠️ Ojo: los cuantizados de 1-bit y 2-bit son excelentes para la mayoría de los usos, pero para tareas muy fuera de distribución —dominios raros, idiomas poco representados o lógica extremadamente precisa— Unsloth recomienda subir a 4-bit, donde hay un salto claro de calidad según la KLD. No asumas que el quant más chico sirve para todo.

Qué sigue

La tendencia es clara: los modelos abiertos de frontera ya no se quedan atrás de los propietarios, y la cuantización dinámica los está volviendo ejecutables fuera de los grandes datacenters. Si GLM-5.2 rinde a la par de Claude 4.8 Opus, GPT-5.5 y Gemini 3.1 Pro en los benchmarks de Artificial Analysis y otros, la pregunta para muchos equipos deja de ser "qué API uso" y pasa a ser "qué corro yo mismo".

El siguiente paso natural es el fine-tuning: Unsloth promociona entrenar modelos el doble de rápido con un 70% menos de VRAM, lo que abre la puerta a adaptar GLM-5.2 a dominios específicos sin un presupuesto de gigante. Para desarrolladores en LATAM, vale la pena experimentar primero con el quant de 2-bit en una máquina prestada o en la nube por horas, medir si la calidad alcanza para tu caso, y recién entonces decidir la inversión en hardware.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Qué significa que GLM-5.2 tenga 744B parámetros pero solo 40B activos?

Es una arquitectura Mixture of Experts. El modelo contiene 744B parámetros en total repartidos entre muchos "expertos", pero en cada token solo enruta el cálculo a un subconjunto que suma 40B. El costo de cómputo por token es el de un modelo de 40B, aunque la memoria necesaria es la del archivo completo.

¿Puedo correr GLM-5.2 local en una laptop normal?

No. Incluso el quant más pequeño de 1-bit necesita 223 GB de memoria total. Hace falta una Mac con 256 GB de memoria unificada o un servidor con GPU más RAM abundante. Una laptop estándar de 16 o 32 GB no alcanza.

¿La cuantización de 2-bit arruina la calidad del modelo?

Según los datos de Unsloth, no de forma dramática. El quant dinámico de 2-bit alcanza ~82% de precisión top-1 siendo 84% más pequeño que el original, lo que equivale a ser solo ~24% menos capaz. La mayor parte de la divergencia ocurre en palabras de relleno, no en el contenido factual.

¿Qué diferencia hay entre llama.cpp y Unsloth Studio?

llama.cpp es el motor de inferencia por línea de comandos, ideal si querés control total y scripting. Unsloth Studio es una interfaz web que usa llama.cpp por debajo, pero agrega descarga automática de modelos, detección de multi-GPU, tool calling con autorreparación y ejecución de código, todo sin tocar la terminal.

¿Cómo desactivo el modo de razonamiento para respuestas más rápidas?

Pasás --chat-template-kwargs '{"enable_thinking":false}' en macOS o Linux (con las comillas escapadas en Windows PowerShell), o usás el flag simplificado --reasoning off en versiones recientes de llama.cpp.

¿Cuánto contexto soporta realmente?

La ventana máxima es de 1.048.576 tokens (1M). En la práctica, el contexto que puedas usar depende de la memoria libre tras cargar los pesos, así que se ajusta con el parámetro --ctx-size.

Referencias

• Unsloth Documentation: GLM-5.2 — How to Run Locally — guía oficial con tabla de hardware, settings recomendados y análisis de cuantización (fuente principal).
• unslothai/unsloth en GitHub — repositorio del proyecto Unsloth, con instrucciones de instalación y fine-tuning.
• ggml-org/llama.cpp en GitHub — el motor de inferencia usado para correr los GGUFs localmente.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.