Cómo ejecutar GLM-5.3-Flash localmente

TL;DR

Puedes ejecutar GLM-5.3-Flash localmente porque Z.ai publicó los pesos del modelo bajo la licencia MIT. La condición es la memoria: el modelo tiene unos 320B parámetros totales, aunque solo 18B están activos por token. Los pesos nativos FP8 ocupan aproximadamente 306 GiB antes del overhead de runtime y KV-cache, mientras que las cuantizaciones GGUF habituales van de ~93 GB a 1 bit hasta 200 GB en Q4 y 341 GB en Q8.

Para servir en producción con GPU, vLLM o SGLang es el camino más directo. Para una estación de trabajo con mucha RAM y una o varias GPU de consumidor, KTransformers está diseñado para inferencia heterogénea CPU-GPU. Para el experimento local más sencillo, usa una compilación GGUF con llama.cpp u Ollama. Una GPU normal de 24 GB o 32 GB no puede sostener el modelo completo por sí sola; el uso local en una sola GPU depende de la RAM del sistema, offloading y/o cuantización.

What Is GLM-5.3-Flash?

Para una visión completa del modelo y la interpretación de benchmarks, consulta What Is GLM-5.3-Flash? de CometAPI. Esta guía de despliegue retiene solo los datos de dimensionamiento necesarios aquí: GLM-5.3-Flash es un MoE multimodal 320B / 18B entrenado en un corpus de 30T tokens.

El repositorio oficial lista una ventana de contexto de 1,048,576 tokens, pesos con licencia MIT y vías compatibles de servicio local. La tabla siguiente es la referencia de despliegue; el resto del artículo se centra en instalación, memoria, verificación y resolución de problemas.

Why GLM-5.3-Flash Is More Efficient Than Its Size Suggests

Un modelo de 320B suena como un modelo denso convencional de 320B, pero no es así como GLM-5.3-Flash emplea el cómputo. El enrutador MoE activa solo una fracción de la capacidad de expertos por token, mientras que el rediseño de la atención reduce el coste de retener y recuperar estado de contexto largo.

Z.ai informa de reducciones en cómputo de atención y uso de KV-cache en comparación con GLM-5.3. Eso importa porque la caché KV crece con la longitud del contexto y la concurrencia; un modelo que carga con éxito a 8K de contexto aún puede quedarse sin memoria cuando le pides servir conversaciones mucho más largas.

Fuente: Z.ai official announcement

How Good Is GLM-5.3-Flash?

La tabla a continuación mantiene las puntuaciones de primera parte más relevantes para despliegue. Z.ai reporta resultados de benchmark más altos para GLM-5.3-Flash frente a GLM-5.2; consulta la visión general del modelo de CometAPI para una interpretación más completa de benchmarks. Aquí, la idea práctica es si las ganancias justifican el coste de hardware local y operativo.

El patrón es especialmente relevante para el autoalojamiento: los casos de uso más fuertes del modelo no son el chat casual, sino agentes de código, automatización basada en herramientas, trabajo con documentos de contexto largo y flujos multimodales donde la residencia de datos o el control de la infraestructura pueden justificar el esfuerzo de despliegue.

How Much RAM or VRAM Does GLM-5.3-Flash Need?

La planificación de memoria es la parte más importante de esta guía. La receta oficial de vLLM indica que el checkpoint nativo FP8 es de aproximadamente 306 GiB de pesos FP8. Por lo tanto, KTransformers recomienda reservar al menos 350 GB de memoria del sistema disponible para su ruta nativa FP8 CPU-GPU.

Si usas GGUF, Unsloth publica cuantizaciones desde 1 bit hasta BF16. El tamaño del archivo no es lo mismo que la memoria total en tiempo de ejecución: aún necesitas margen para el runtime, metadatos del modelo, buffers de cómputo, componentes multimodales y KV cache.

La tercera columna es orientación de planificación de despliegue, no una especificación oficial de hardware mínimo. El ajuste real depende de la longitud de contexto, tamaño de batch, runtime, offload a GPU y la implementación de cuantización.

Which Local Runtime Should You Use?

Elige vLLM cuando el throughput y la compatibilidad con el ecosistema son lo más importante. Elige SGLang cuando quieras evaluar servicio agentic, salida estructurada o multimodal. Elige KTransformers cuando el modelo no cabe en memoria de GPU pero tienes cientos de gigabytes de RAM del sistema. Elige llama.cpp u Ollama cuando la cuantización GGUF y la facilidad de experimentación local importen más que igualar el checkpoint nativo.

How to Run GLM-5.3-Flash with Native Weights

Run with vLLM

vLLM es la opción más orientada a producción si tienes aceleradores de clase servidor. La receta oficial actual soporta múltiples estrategias de paralelización y documenta servicio nativo FP8. Trata las configuraciones publicadas como setups de referencia, no como una promesa de que todas las combinaciones de GPU funcionarán con las mismas flags.

Paso 1: Prepara el entorno

Usa Linux con un stack NVIDIA compatible, suficiente memoria agregada de GPU para el checkpoint más el overhead de runtime y una versión reciente de vLLM o el contenedor recomendado por la receta actual. Empieza con una ventana de contexto más pequeña mientras validas el despliegue en lugar de asignar inmediatamente la ventana completa de un millón de tokens.

Paso 2: Inicia el servidor

pip install vllm

vllm serve "zai-org/GLM-5.3-Flash" \
  --tensor-parallel-size 8 \
  --served-model-name zai-org/GLM-5.3-Flash

Para despliegues avanzados, la receta oficial de vLLM documenta KV cache FP8 en sistemas Blackwell compatibles, decodificación especulativa MTP, análisis de llamadas a herramientas, análisis de razonamiento y desagregación de prefill/decode. Revisa la receta actual de vLLM antes de copiar flags a producción porque el soporte puede cambiar rápidamente.

Paso 3: Prueba el endpoint compatible con OpenAI

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "zai-org/GLM-5.3-Flash",
    "messages": [
      {"role": "user", "content": "Reply with OK"}
    ]
  }'

Run with SGLang

SGLang es otra ruta de servicio de primera clase listada en la tarjeta oficial del modelo. Vale especialmente la pena probarlo para agentes de alta concurrencia, generación estructurada, solicitudes multimodales y aplicaciones con uso intensivo de herramientas.

Paso 1: Instala SGLang

pip install sglang

Paso 2: Lanza el servidor del modelo

python3 -m sglang.launch_server \
  --model-path "zai-org/GLM-5.3-Flash" \
  --host 0.0.0.0 \
  --port 30000

Paso 3: Verifica el endpoint

curl -X POST "http://localhost:30000/v1/chat/completions" \
  -H "Content-Type: application/json" \
  --data '{
    "model": "zai-org/GLM-5.3-Flash",
    "messages": [{"role": "user", "content": "Give me three local deployment checks."}]
  }'

La tarjeta oficial del modelo en Hugging Face también proporciona ejemplos de solicitudes multimodales para SGLang. Si necesitas tool calling, usa las flags del parser recomendadas por la receta actual de SGLang en lugar de asumir que las flags de una versión anterior de GLM siguen sin cambios.

Run with KTransformers

KTransformers es la opción más importante para usuarios que interpretan “local” como una estación de trabajo y no como un servidor con ocho GPU. Su implementación de GLM-5.3-Flash lee directamente los pesos FP8 oficiales y realiza inferencia heterogénea de expertos CPU-GPU.

El tutorial actual dice que el modelo FP8 ocupa aproximadamente 306 GiB y recomienda 350 GB de memoria del sistema. Soporta GPUs NVIDIA SM89 y SM120, incluyendo hardware RTX de las series 40 y 50, además de kernels de expertos de CPU AVX-512 FP8. El tutorial incluye configuraciones de lanzamiento tanto para cuatro GPU como para una sola GPU.

Una sola RTX 4090 o RTX 5090 puede participar en la inferencia, pero eso no convierte a GLM-5.3-Flash en un modelo de 24–32 GB. La mayor parte del modelo sigue viviendo fuera de la VRAM de la GPU, por lo que la capacidad de memoria del sistema y el ancho de banda se vuelven centrales para el rendimiento.

Paso 1: Crea un entorno de Python limpio

conda create -n glm53flash python=3.11 -y
conda activate glm53flash

Paso 2: Instala KTransformers

pip install "ktransformers[sglang]"

Paso 3: Descarga los pesos oficiales

Descarga zai-org/GLM-5.3-Flash desde Hugging Face al almacenamiento local. Asegúrate de tener suficiente espacio en disco para el checkpoint y suficiente RAM para la configuración activa del servidor.

Paso 4: Inicia el servidor de una sola GPU

MODEL_PATH=/path/to/GLM-5.3-Flash

CUDA_VISIBLE_DEVICES=0 python -m sglang.launch_server \
  --model-path "$MODEL_PATH" \
  --kt-weight-path "$MODEL_PATH" \
  --served-model-name GLM-5.3-flash \
  --host 0.0.0.0 \
  --tp-size 1 \
  --context-length 501025 \
  --mem-fraction-static 0.65 \
  --chunked-prefill-size 2048 \
  --kt-method FP8 \
  --kt-cpuinfer 64 \
  --kt-threadpool-count 2 \
  --kt-num-gpu-experts 0 \
  --kt-gpu-prefill-token-threshold 2048 \
  --cuda-graph-bs 1 2 4 \
  --limit-mm-data-per-request '{"image":8,"video":1}' \
  --mm-process-config '{"image":{"max_pixels":1254400}}' \
  --tool-call-parser glm47 \
  --reasoning-parser glm45

El tutorial usa una configuración validada de 501,025 tokens aunque el modelo soporta hasta 1M de contexto. Eso es un recordatorio útil: configura el contexto que realmente necesitas, no el máximo promocionado, porque el margen de contexto tiene un coste directo en memoria.

Paso 5: Comprueba el servidor

curl http://localhost:30000/v1/models

El endpoint de chat compatible con OpenAI es texto plano: http://localhost:30000/v1/chat/completions.

How to Run a Quantized GLM-5.3-Flash GGUF Model

Run GLM-5.3-Flash with llama.cpp

Si no quieres ejecutar el checkpoint nativo FP8, GGUF hace el objetivo de memoria más flexible. Unsloth publica múltiples cuantizaciones GGUF de GLM-5.3-Flash y proporciona comandos directos de llama.cpp. La compilación Q4_K_XL pesa unos 200 GB, por lo que incluso esta vía “amigable para consumidores” sigue asumiendo un sistema con mucha memoria.

Instalar en macOS o Linux

curl -LsSf https://llama.app/install.sh | sh

Instalar en Windows

winget install llama.cpp

Inicia un servidor local con Q4_K_XL

llama serve -hf unsloth/GLM-5.3-Flash-GGUF:UD-Q4_K_XL

Ejecuta directamente en la terminal

llama cli -hf unsloth/GLM-5.3-Flash-GGUF:UD-Q4_K_XL

Si tu máquina no puede alojar Q4_K_XL, existen archivos más pequeños de 3 bits, 2 bits y 1 bit. No elijas el menor ancho de bits solo porque quepa: una cuantización agresiva puede cambiar la fiabilidad del razonamiento, el formato de tool calls, la calidad de código y el comportamiento multimodal. Valida la compilación exacta en tu propio conjunto de pruebas.

Run GLM-5.3-Flash with Ollama

Ollama es la ruta de línea de comandos más corta si ya lo usas para modelos locales. Unsloth documenta la carga directa desde Hugging Face para sus compilaciones GGUF de GLM-5.3-Flash.

ollama run hf.co/unsloth/GLM-5.3-Flash-GGUF:UD-Q4_K_XL

La conveniencia de Ollama no cambia el tamaño subyacente del modelo. Q4_K_XL sigue pesando unos 200 GB, y las versiones de menor bit cambian memoria por calidad. Si solo tienes 32–64 GB de RAM del sistema, GLM-5.3-Flash no es un objetivo local sensato; usa un modelo más pequeño o una API alojada.

Choose a GGUF Quantization

Elige la cuantización de mayor calidad que quepa con suficiente margen para runtime y KV-cache. Comienza con Q4_K_XL cuando tengas aproximadamente 256 GB o más de memoria del sistema; considera compilaciones de menor bit solo cuando los límites de hardware lo requieran y valida razonamiento, generación de código, llamadas a herramientas y comportamiento multimodal contra una referencia nativa o alojada antes del despliegue.

How to verify Your Local Deployment

Un log de arranque exitoso no es suficiente. Prueba los comportamientos de los que tu aplicación realmente dependerá. Una secuencia de aceptación útil es: generación básica de texto, tu longitud real de contexto, tool calling con tus esquemas, entrada multimodal si se necesita y throughput bajo concurrencia realista.

Basic smoke test

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "zai-org/GLM-5.3-Flash",
    "messages": [
      {"role": "user", "content": "Return exactly: LOCAL_OK"}
    ],
    "reasoning_effort": "low"
  }'

La tarjeta del modelo define niveles de reasoning_effort y por defecto usa max. Para la reproducción de benchmarks, mantén max; para una estación de trabajo lenta, low o high pueden hacer las pruebas iterativas mucho más prácticas.

Luego añade comprobaciones específicas de la carga:

• Contexto largo: envía un documento o un prompt del tamaño de un repositorio cercano a tu longitud de producción prevista, no el máximo de 1M por defecto.
• Tool calling: verifica el JSON de argumentos, la selección de herramientas, la recuperación tras errores de herramientas y llamadas repetidas.
• Multimodal: prueba los formatos de imagen o video y los rangos de resolución que usarás en la práctica.
• Concurrencia: mide latencia y memoria mientras múltiples solicitudes están activas.
• Cuantización: compara el mismo conjunto de prompts contra una referencia nativa o alojada antes de aprobar una compilación GGUF de bajo bit.

How to Reduce GLM-5.3-Flash Memory Use

Use a smaller context window

El modelo soporta hasta 1M de tokens, pero la mayoría de flujos locales no necesitan tanto contexto en cada solicitud. Reduce el máximo configurado hasta que coincida con tu aplicación. Esto reduce la presión de KV-cache y puede convertir un despliegue inestable en uno utilizable.

Quantize the weights

Pasar de BF16 a Q8, Q6, Q4 o GGUF de menor bit puede recortar drásticamente la memoria de pesos. La contrapartida es la calidad de salida y a veces la compatibilidad de runtime, así que trata el nivel de cuantización como una elección de modelo, no solo una opción de almacenamiento.

Use CPU offload

KTransformers y llama.cpp pueden mover una gran parte del estado del modelo a la RAM del sistema. Esta es la principal razón por la que la inferencia de GLM-5.3-Flash en una sola GPU es plausible, pero también traslada el cuello de botella de rendimiento hacia la capacidad de CPU y el ancho de banda de memoria.

Reduce concurrency

Cada solicitud simultánea de contexto largo consume caché y buffers de runtime adicionales. Un despliegue en estación de trabajo suele rendir mejor con un objetivo de concurrencia pequeño y una cola explícita que con paralelismo al estilo servidor.

How to Improve Interactive Latency

Para uso local interactivo, bajar reasoning_effort puede reducir la longitud del razonamiento generado, la latencia de respuesta y el consumo de tokens. No reduce la memoria necesaria para cargar los pesos del modelo; puede reducir el uso de caché en tiempo de solicitud solo de forma indirecta al acortar la secuencia generada. Usa low para iteración rápida y cambia a high o max cuando una tarea necesite razonamiento más profundo o un comportamiento comparable a benchmarks.

Should You Run GLM-5.3-Flash Locally or Use an API?

El autoalojamiento es atractivo cuando importan la privacidad, la residencia de datos, la operación offline, configuraciones de inferencia personalizadas o hardware propio inactivo. Es menos atractivo cuando necesitas acceso ocasional al modelo sin mantener cientos de gigabytes de memoria y un stack de servicio complejo.

Si el despliegue local no es un requisito, puedes acceder a GLM-5.3-Flash mediante un flujo de chat-completions compatible con OpenAI usando el ID de modelo glm-5.3-flash. Esto es útil como endpoint de referencia para comparar tu compilación local cuantizada con una implementación alojada o como respaldo de producción mientras pruebas el autoalojamiento.

from openai import OpenAI
import os

client = OpenAI(
    base_url="https://api.cometapi.com/v1",
    api_key=os.environ["COMETAPI_KEY"],
)

response = client.chat.completions.create(
    model="glm-5.3-flash",
    messages=[{"role": "user", "content": "Reply with OK"}],
)

print(response.choices[0].message.content)

Common Problems When Running GLM-5.3-Flash Locally

The model loads, then crashes on a long prompt

Esto usualmente significa que dimensionaste para los pesos pero no para la KV cache. Reduce la longitud del contexto y la concurrencia, luego aumenta gradualmente mientras monitorizas la memoria de GPU y del sistema.

A Q4 file fits on disk but not in RAM

El tamaño del archivo GGUF no es la huella completa en tiempo de ejecución. Deja un margen significativo para buffers de runtime, caché y el sistema operativo.

Single-GPU KTransformers is extremely slow

Eso puede esperarse cuando la mayor parte del trabajo de expertos se sirve desde memoria de CPU. Revisa la colocación NUMA, el ancho de banda de memoria, el soporte de instrucciones de CPU, el comportamiento del almacenamiento durante la carga y si tu carga de trabajo estaría mejor servida por un modelo cuantizado más pequeño.

Tool calling returns malformed JSON

Confirma que tu runtime usa el parser recomendado para la integración actual de GLM-5.3-Flash. Las flags del parser pueden cambiar entre versiones del framework, así que no reutilices a ciegas un comando de lanzamiento escrito para un modelo GLM anterior.

Ollama or llama.cpp starts downloading hundreds of gigabytes

Eso es normal para esta familia de modelos. Verifica la etiqueta de cuantización antes de iniciar la descarga, confirma el espacio libre en disco y revisa primero el tamaño de archivo correspondiente en el repositorio GGUF.

FAQ

Can I run GLM-5.3-Flash on an RTX 4090?

Sí, una RTX 4090 puede participar en la inferencia heterogénea CPU-GPU de KTransformers, pero los 24 GB de VRAM están muy lejos de sostener el checkpoint completo. La ruta FP8 oficial de KTransformers aún requiere aproximadamente 350 GB de memoria del sistema disponible.

Can I run GLM-5.3-Flash on an RTX 5090?

Sí, las GPU de la serie RTX 50 están explícitamente incluidas en la lista de soporte actual de KTransformers. Como con una 4090, la restricción clave es el resto del sistema: capacidad de RAM, ancho de banda de memoria, soporte de CPU y la cantidad de contexto que asignas.

Can I run GLM-5.3-Flash with 128 GB RAM?

Solo las cuantizaciones GGUF más agresivas se acercan a ese rango: Q2_K_XL ronda 109 GB e IQ2_XXS unos 102 GB. Una vez que se incluye el overhead de runtime y la KV cache, 128 GB es un objetivo muy ajustado. No es la configuración a elegir si quieres calidad predecible o contexto largo.

Can GLM-5.3-Flash run in Ollama?

Sí. Unsloth documenta la carga directa en Ollama para sus compilaciones GGUF, incluyendo UD-Q4_K_XL.

How much VRAM does GLM-5.3-Flash need?

No existe un único número correcto de VRAM. El despliegue nativo de servidor distribuye el checkpoint entre aceleradores; KTransformers combina VRAM de GPU con cientos de gigabytes de RAM del sistema; llama.cpp puede offloadear un GGUF cuantizado entre CPU y GPU. Planifica según el runtime y la cuantización que pretendes usar.

Is GLM-5.3-Flash open source?

La formulación más segura es pesos abiertos bajo licencia MIT. El repositorio oficial en Hugging Face lista explícitamente la licencia MIT y proporciona checkpoints descargables.

Is local GLM-5.3-Flash cheaper than the API?

No automáticamente. El alojamiento local puede tener sentido cuando ya posees hardware adecuado, mantienes una alta utilización de forma constante o debes mantener los datos dentro de tu infraestructura. Para cargas intermitentes, el acceso alojado suele evitar una gran carga fija de hardware y operaciones.

Conclusion

GLM-5.3-Flash es inusualmente eficiente para un modelo con aproximadamente 320B parámetros totales, pero “Flash” no debe confundirse con “pequeño”. Su diseño MoE de 18B parámetros activos reduce el cómputo, mientras que la atención híbrida lineal y dispersa hace que el contexto largo sea sustancialmente más barato, pero los pesos aún exigen cientos de gigabytes a menos que uses cuantización agresiva.

La decisión práctica de despliegue es, por tanto, directa: usa vLLM o SGLang para infraestructura GPU de clase servidor; usa KTransformers cuando tienes una estación de trabajo con muchísima memoria del sistema y quieres inferencia nativa FP8 CPU-GPU; usa llama.cpp u Ollama cuando importan más la cuantización GGUF y la facilidad de experimentación. Si ninguno de esos perfiles de hardware coincide con tu máquina, usa un endpoint alojado de GLM-5.3-Flash en lugar de forzar un modelo de 320B en una configuración local inadecuada.