GLM-5.2 en local: Ollama + LM Studio, el gigante MIT

#¿Por qué GLM-5.2 en local?

La mayoría de los modelos «frontier» (los más grandes y capaces) siguen encerrados detrás de una API: GPT, Gemini o las versiones de más de 100B de Qwen y DeepSeek. GLM-5.2 rompe esta lógica. Zhipu AI ha publicado los pesos completos bajo la licencia MIT —la más permisiva que existe, sin cláusula de atribución ni de compartir bajo la misma licencia— y la comunidad ha producido versiones cuantizadas en GGUF que funcionan desde el lanzamiento. Resultado: puedes alojar un modelo de categoría frontier en casa, sin cuenta, sin cuota y sin fugas de datos.

El interés no está en la velocidad: seamos claros, un modelo de 753B ejecutado en local nunca competirá con un endpoint en la nube en capacidad de respuesta. El interés está en la soberanía total sobre un modelo que, en calidad bruta, está a la altura de los mejores servicios propietarios: razonamiento prolongado, trabajo con grandes bases de código y un contexto de 1 millón de tokens. Para un agente de programación que trabaja durante horas con código propietario sujeto a un NDA, la velocidad pasa a un segundo plano frente a la confidencialidad.

#Lo que cambia desde GLM-5.1

Si buscas instalar un GLM de tamaño razonable en una GPU de 12 a 24 GB, esta guía no es la adecuada: GLM-5.1 (modelos densos de 9B y 32B) está hecho para eso, y nuestra guía específica lo cubre en detalle. GLM-5.2 está dirigido a otro público. La confusión es frecuente porque los nombres son consecutivos, pero los dos modelos no pertenecen a la misma categoría de hardware.

Arquitectura

GLM-5.1 es denso (9B, 32B). GLM-5.2 es un MoE de 753B en total, con una fracción de expertos activados por token. No se despliega en una única GPU de consumo.

Licencia

GLM-5.1 está bajo GLM License (variante de Apache con atribución). GLM-5.2 pasa a la licencia MIT pura: uso comercial sin restricciones, ninguna cláusula viral.

Contexto

128k en GLM-5.1 (1M mediante YaRN, con degradación). GLM-5.2 admite de forma nativa 1M tokens, una verdadera ventaja para el análisis de grandes repositorios.

Hardware objetivo

GLM-5.1: una GPU de 8 a 24 GB. GLM-5.2: un Mac con 256 GB de memoria unificada, un equipo con varias GPU o un servidor con mucha RAM y offload.

Casos de uso

GLM-5.1 para un asistente local que responda con rapidez. GLM-5.2 para un modelo de vanguardia de referencia, cuando la calidad prima sobre la velocidad.

#753B MoE: entender el modelo

GLM-5.2 es un Mixture-of-Experts: entre sus 753 mil millones de parámetros, solo una fracción se activa por cada token generado. Es esto lo que hace que la inferencia sea viable localmente — el cálculo por token sigue siendo razonable — pero el peligro está en otro lugar: todos los pesos deben caber en memoria, incluso los expertos que no se están utilizando en un momento dado. Es la memoria, no la potencia de cálculo, lo que limita.

Parámetros totales

753B, distribuidos entre un backbone compartido y un conjunto de expertos a los que se enruta dinámicamente.

Parámetros activos

Una fracción por token (enrutamiento top-k). Es lo que permite una tasa de generación decente a pesar del tamaño total.

Contexto

Contexto nativo de 1M de tokens. Atención: la caché KV con 1M de tokens consume muchísima memoria; resérvala para los casos que lo justifiquen.

Licencia

MIT. Puedes realizar un ajuste fino, redistribuir e integrar el modelo en un producto comercial sin obligaciones.

Formato

Pesos originales en BF16 (~1,5 TB). No se pueden usar tal cual en local: ahí es donde entran las versiones cuantizadas en formato GGUF.

#Las cuantizaciones GGUF (unsloth)

La comunidad ha producido las cuantizaciones que hacen viable GLM-5.2. Las cuantizaciones dinámicas de unsloth son la referencia: aplican una precisión variable según la importancia de las capas, lo que conserva mejor la calidad que una cuantización uniforme con el mismo tamaño en memoria. Esto es decisivo a muy baja precisión, donde cada bit cuenta.

Q2_K_XL (unsloth)

~200 GB. El punto de entrada realista. Calidad reducida pero utilizable: es la versión que cabe en un Mac de 256 GB o en un equipo con varias 4090.

Q4_K_M

~380-400 GB. El punto óptimo de calidad, pero reservado para servidores con muchísima memoria o configuraciones multi-GPU potentes.

Q5_K_M

~480 GB. Poca mejora perceptible respecto a Q4 para este tipo de modelo; rara vez se justifica en local.

Q8_0 / BF16

De 800 GB a 1,5 TB. Es terreno de los servidores profesionales con GPU, fuera del alcance de un equipo de consumo.

# huggingface-cli doit être installé : pip install -U huggingface_hub
# Q2_K_XL est réparti en plusieurs shards GGUF
huggingface-cli download unsloth/GLM-5.2-GGUF \
  --include "*Q2_K_XL*" \
  --local-dir ./glm-5.2-gguf

#Requisitos de hardware realistas

No existe una configuración «ligera» para GLM-5.2. A continuación, se muestran los dos perfiles que realmente funcionan, sin engaños con los números.

Mac Apple Silicon 256 GB

Un Mac Studio de la serie M con 256 GB de memoria unificada permite ejecutar Q2_K_XL con margen para el contexto. La memoria unificada es aquí una ventaja decisiva: no hay separación CPU/GPU.

Mac 192 GB

Es viable, pero con poco margen: Q2_K_XL cabe, pero reduce la ventana de contexto y cierra todo lo demás. 128 GB quedan por debajo del umbral viable.

Equipo con varias GPU

Varias RTX 4090 (24 GB cada una) + mucha RAM del sistema para descargar parte del procesamiento en la CPU. Los 200 GB no caben únicamente en la VRAM: se reparten entre GPU y RAM.

Almacenamiento

Como mínimo, 200 GB libres para Q2 y un SSD NVMe rápido (la carga inicial lee cientos de GB).

RAM del sistema (equipo)

Al menos 128 GB de RAM si descargas parte de los expertos a la CPU, 256 GB para trabajar con comodidad.

#1. Instalación con LM Studio

LM Studio es a menudo el más sencillo para un modelo de este tamaño, especialmente en Mac: su motor MLX y su gestión de memoria están bien probados, y la interfaz muestra en tiempo real cuánta memoria requiere el modelo antes de cargarlo. Es valioso cuando estás cerca del límite.

1. 01
   1. Instalar LM Studio

   Descarga LM Studio desde el sitio oficial (lmstudio.ai) e instálalo. En Mac, elige la versión nativa para Apple Silicon.
2. 02
   2. Buscar el modelo

   En la pestaña de búsqueda, escribe «GLM-5.2» y localiza el repositorio unsloth GGUF. LM Studio muestra para cada cuantización si es compatible con la RAM disponible (etiqueta verde/naranja/roja).
3. 03
   3. Elegir la cuantización Q2_K_XL

   Selecciona la variante Q2_K_XL. LM Studio descarga automáticamente todos los shards — espera un tiempo considerable según tu conexión (200 GB).
4. 04
   4. Ajustar el contexto

   Antes de cargar, reduce la longitud de contexto a un valor razonable (8k-16k para probar). No configures 1M de inicio: la caché KV dispararía el consumo de memoria.
5. 05
   5. Cargar y probar

   Haz clic en «Load». Vigila el indicador de memoria. Una vez cargado el modelo, envía un primer prompt y mide la velocidad mostrada en tok/s.

#2. Instalación con Ollama

Ollama también puede servir GLM-5.2 a partir de un GGUF, mediante un Modelfile que apunta a los archivos descargados. Esta es la vía preferida si quieres exponer el modelo mediante una API compatible con OpenAI a otras herramientas (agentes, IDE, Open WebUI).

# Fichier : Modelfile
FROM ./glm-5.2-gguf/GLM-5.2-Q2_K_XL-00001-of-00005.gguf

PARAMETER num_ctx 16384
PARAMETER temperature 0.6

# Créer l'entrée Ollama à partir du Modelfile
ollama create glm-5.2 -f Modelfile

# Lancer
ollama run glm-5.2

Una vez creado, GLM-5.2 se sirve como cualquier modelo Ollama en el endpoint predeterminado http://localhost:11434. Cualquier cliente compatible con OpenAI puede entonces consultarlo apuntando a esta dirección.

# Dans un autre terminal, après le premier prompt
ollama ps

#3. Configuración de un Mac con 256 GB

Es la configuración más elegante para GLM-5.2. La memoria unificada de Apple Silicon significa que la GPU y la CPU comparten la misma memoria: sin transferencias costosas ni reparto manual. Un Mac Studio con 256 GB carga el Q2_K_XL y deja espacio para un contexto cómodo.

Modelo cargado

Q2_K_XL (~200 GB) cabe, con ~40-50 GB restantes para el KV-cache y el sistema.

Velocidad esperada

Aproximadamente 5 a 12 tok/s en generación según la longitud del contexto. Cómodo para trabajos asincrónicos, frustrante para chats interactivos rápidos.

Contexto utilizable

32k a 64k sin problemas. Subir hasta 128k+ es posible, pero consume rápidamente la memoria a través del KV-cache.

Herramienta recomendada

LM Studio por su sencillez, u Ollama si conectas agentes a él.

#4. Equipo con RTX 4090 en 2 bits

En un PC, hay que tener en cuenta la separación entre VRAM y RAM. Una sola RTX 4090 (24 GB) obviamente no basta para alojar 200 GB: la estrategia consiste en cargar tantos expertos como sea posible en la VRAM y transferir el resto a la RAM del sistema mediante llama.cpp. El rendimiento en tokens por segundo depende entonces directamente de la proporción GPU/CPU y de la velocidad de tu RAM.

./llama-server \
  -m glm-5.2-gguf/GLM-5.2-Q2_K_XL-00001-of-00005.gguf \
  -c 16384 \
  -ngl 99 \
  --n-cpu-moe 40 \
  -fa \
  --host 0.0.0.0 --port 8080

-ngl 99

Intenta colocar el mayor número de capas en el GPU. llama.cpp llena la VRAM disponible y pasa el resto al CPU.

--n-cpu-moe 40

Mantiene las capas MoE indicadas en la CPU. Es el ajuste clave para un MoE: se coloca la estructura principal densa en VRAM y se descargan los expertos en la RAM. Ajusta el número según tu VRAM.

-fa

Flash Attention, reduce el consumo de memoria de la caché KV. Mantenerlo activado.

Multi-GPU

Con 2 a 4 RTX 4090, llama.cpp reparte la carga automáticamente (--split-mode). Más VRAM = menos carga transferida a la CPU = mayor tasa de generación.

#5. Agentes de código de larga duración

Es ahí donde GLM-5.2 en local cobra todo su sentido pese a su lentitud. A un agente de programación que refactoriza una gran base de código, lee decenas de archivos y razona durante horas no le importa una latencia de unos segundos por token: trabaja en segundo plano. Lo que cuenta es la calidad del razonamiento y el contexto de 1M que le permite tener presente todo el repositorio, sin que una sola línea de código propietario salga de tu máquina.

Contexto masivo

Un millón de tokens permite introducir toda una base de código en el prompt en lugar de fragmentarla, lo que mejora la coherencia de las modificaciones de varios archivos.

Tool calling

GLM-5.2 gestiona llamadas de herramientas en formato OpenAI, esencial para un agente que lee, escribe y ejecuta.

Endpoint OpenAI

A través de Ollama (localhost:11434) o llama.cpp (localhost:8080), conecta Aider, Cline o cualquier agente que use la API de OpenAI.

Trabajo asincrónico

Inicia la tarea y haz otra cosa. A 5-10 tok/s, una refactorización grande lleva tiempo, pero se ejecuta sin supervisión.

#Expectativas honestas y resolución de problemas

Ninguna guía seria afirmará que ejecutar un 753B en local sea fluido. Estos son los problemas reales y sus soluciones.

Swap de disco = muerte

Si el modelo acaba usando la memoria de intercambio en disco, la generación pasa a tardar segundos por token. Reduce el contexto, usa una versión cuantizada más pequeña o cierra las otras aplicaciones que consumen mucha RAM.

Carga muy lenta

Cargar 200 GB desde un SSD tarda varios minutos. Es normal. Un SSD NVMe rápido hace una gran diferencia; un disco externo USB debe evitarse.

OOM al cargar

En Mac, ajusta el límite de GPU (iogpu.wired_limit_mb). En PC, aumenta --n-cpu-moe para enviar más expertos a RAM.

Pérdida de calidad

Con una cuantización de 2 bits, el modelo puede generar más alucinaciones. Reduce la temperatura (0.6 o menos) y prioriza las cuantizaciones dinámicas de unsloth en lugar de un Q2 uniforme.

Velocidad decepcionante

Es esperable. Un modelo del tamaño de los modelos de vanguardia no es rápido en local. Si buscas velocidad, GLM-5.1 32B o un Qwen3 responderán mucho más rápido.

#Para ir más allá

GLM-5.2 es un caso extremo que abarca la cuantización, el hardware y el despliegue de agentes. Estas guías cubren los fundamentos que debes dominar en esos ámbitos.

El hermano menor razonable

«GLM 5.1 en local: la alternativa de pesos abiertos que debes conocer»: si tu hardware tiene un límite de 24 GB, este es el modelo GLM que necesitas, con una respuesta mucho más rápida.

Entender las cuantizaciones

«Elegir la cuantización (Q4, Q5, Q8, FP16)»: imprescindible para entender por qué la cuantización dinámica de 2 bits hace accesible GLM-5.2 sin destruirlo.

Programar con un agente local

« Aider + Ollama: programar en el terminal con un agente 100% local » — el punto de partida para conectar GLM-5.2 a un verdadero flujo de trabajo de desarrollo.