Puedes ejecutar un modelo GLM en local porque los pesos están realmente publicados, no tras un formulario de solicitud ni un endpoint alojado. Esta página cubre las cuatro cosas que deciden si un despliegue local funciona: la licencia bajo la que operas, dónde viven los pesos, qué frameworks de servicio están soportados y cómo dimensionar el hardware para la longitud de contexto que realmente necesitas y no solo para el número de parámetros. Ninguna es difícil por separado; acertar en las cuatro a la vez es lo que separa un despliegue que funciona de un fin de semana depurando.
El motivo para molestarse es sencillo. Un modelo GLM de código abierto ejecutándose en tu propio hardware mantiene cada prompt dentro de tu red, no puede quedar obsoleto bajo tus pies y puede ajustarse con datos que nunca enviarías a un tercero. Esas propiedades son la razón por la que los equipos eligen pesos abiertos incluso cuando un modelo alojado puntúa unos puntos más.
Los pesos de los modelos GLM principales se publican con licencia MIT sin restricciones regionales. MIT es prácticamente lo más permisivo que existe en licencias de software: usar, modificar, distribuir y desplegar comercialmente, con atribución y sin garantía. No hay ninguna cláusula adicional de uso aceptable que recorte lo que la licencia concede, ni ninguna cláusula geográfica que decida dónde puedes servirlo.
Eso importa más en los modelos que en el software corriente, porque muchos lanzamientos nominalmente abiertos llevan cláusulas que vuelven legalmente ambiguo el despliegue en producción. Confirma el archivo de licencia que acompaña al checkpoint concreto que descargues: es el texto de referencia y se lee en unos treinta segundos.
Los pesos se publican en HuggingFace y en ModelScope. Ambos alojan los checkpoints completos y no adaptadores o lanzamientos parciales, así que puedes descargarlos con las herramientas estándar de cualquiera de las dos plataformas. Replicar el checkpoint en tu propio almacén de artefactos antes del despliegue es una buena práctica por la misma razón que lo es con las imágenes de contenedor: tu despliegue no debería depender de que un host externo esté disponible justo cuando escalas.
Los autores del modelo indican soporte para cinco stacks de inferencia que, entre todos, cubren prácticamente cualquier forma de despliegue local, desde una sola estación de trabajo hasta un clúster multinodo.
La implementación de referencia. La más lenta para servir en producción, pero la forma más fácil de confirmar que un checkpoint carga y genera correctamente antes de invertir en un stack más rápido. Empieza aquí cuando depures.
La opción habitual en producción. La atención paginada y el batching continuo lo hacen fuerte bajo carga concurrente, y suele ser la ruta más rápida desde un checkpoint descargado hasta un endpoint compatible con OpenAI en tu propio hardware.
Optimizado para la generación estructurada y la reutilización intensiva de prefijos. Merece la pena elegirlo cuando muchas peticiones comparten un prompt de sistema largo o un prefijo de documento común, que es justo la forma de la mayoría de cargas de agentes.
Una ruta de servicio adicional soportada e indicada por los autores del modelo, útil cuando sus características de despliegue encajan mejor con tu infraestructura que las alternativas.
Apunta a la inferencia heterogénea entre CPU y GPU, que es lo que lo hace interesante para hardware limitado: puede descargar partes del modelo a la memoria del sistema y mantener utilizable un modelo grande en una máquina que de otro modo no podría alojarlo.
El error más común en despliegues locales es presupuestar memoria para los pesos y olvidar la caché KV. El número de parámetros marca un suelo, pero la caché escala con la longitud de contexto y la concurrencia, y con contexto largo domina. Es el mismo muro con el que se toparon los autores del modelo al servir el buque insignia: pasados unos cientos de miles de tokens, el cuello de botella deja de ser el cómputo y pasa a ser la capacidad de caché, la eficiencia de los kernels y la sobrecarga de CPU.
La consecuencia práctica es que debes dimensionar según tu distribución real de contexto, no según el máximo que soporta el modelo. Ejecutar GLM-5.2 con una ventana de 128K es una propuesta de hardware muy distinta a ejecutarlo con el millón completo, y la mayoría de cargas de trabajo nunca se acercan al techo. Si tu hardware va justo, los niveles ligeros GLM-4.7-Flash y GLM-4.5-Air, o el GLM-5.1 con contexto de 200K, cabrán donde el buque insignia no lo hace.
Ajusta el modelo a la máquina. En un único acelerador de estación de trabajo, el GLM-4.7-Flash de 30B o GLM-4.5-Air son las opciones realistas y son perfectamente capaces para clasificación, extracción, resumen y ediciones rutinarias de código. En un nodo multi-GPU serio, GLM-5.1 te da una ventana de 200.000 tokens con un coste de caché mucho menor que el buque insignia. En un clúster, GLM-5.2 te da el contexto completo de 1M, niveles de esfuerzo explícitos y la mejor columna de benchmarks publicada de la familia. Para voz a texto en lugar de generación, GLM-ASR cubre la etapa de transcripción bajo la misma licencia.
Todas las cifras de esta página son resultados publicados por los autores del modelo. glmmodel.com los reproduce; no ejecuta estas evaluaciones.
Consulta los benchmarks del modelo GLM y luego pon a trabajar un modelo real. El playground de arriba es gratuito y no te pide nada; si quieres un kit de IA más completo, el plan gratuito de nuestro partner empieza aquí.