En febrero de 2026, Zhipu AI lanzaba GLM-5, un modelo con arquitectura Mixture of Experts (744B parámetros totales, 40B activados). En abril llegó GLM-5.1, con mejoras notables en coding y un contexto de unos 200K tokens. Y en junio de 2026 aterrizó GLM-5.2: una versión refinada con contexto extendido a 1 millón de tokens y ajustes para coding y tareas agénticas. No es una revolución, sino una evolución, pero merece atención por lo que representa para el ecosistema abierto.
El momento de lanzamiento no es casual. GLM-5.2 se publicó como modelo abierto justo después de que un veto gubernamental en EE. UU. restringiese el acceso internacional a modelos frontera propietarios. Los vetos geopolíticos pueden cortarte la IA de la noche a la mañana, pero con modelos abiertos en tu servidor nadie te los apaga por decreto.
Lo esencial de GLM-5.2
- Arquitectura. GLM-5.2 usa Mixture of Experts con 744B parámetros totales, pero solo 40B se activan en cada inferencia. Esto significa que consume mucho menos cómputo de lo que el tamaño nominal sugiere: el modelo es grande en capacidad pero eficiente en uso real.
- Contexto. El salto más concreto respecto a GLM-5.1 es el contexto: de 200K tokens pasa a 1 millón de entrada y hasta 131K de salida. En la práctica permite analizar repositorios de código completos, contratos extensos o documentación técnica de centenares de páginas en una sola llamada, sin truncar.
- Licencia. MIT, open-weight. Los pesos son públicos: puedes descargarlo, modificarlo y desplegarlo en tu propia infraestructura sin depender de ningún proveedor externo. Nadie puede revocarte el acceso.
- Enfoque. El modelo está optimizado para coding, razonamiento y sistemas agénticos: flujos donde el modelo actúa en varios pasos de forma autónoma. Para tareas generales como chatbots o traducción, otras familias como Llama 4 o Qwen3.6 tienen ecosistemas más maduros.
- Tecnología de atención. Para manejar contextos tan largos sin disparar el coste de inferencia, Zhipu usa IndexShare, una técnica de atención dispersa propia. Es lo que hace viable el millón de tokens sin multiplicar el gasto computacional.
El benchmark de ciberseguridad: un caso de uso destacado
En junio de 2026, Semgrep publicó un benchmark comparando modelos en detección de vulnerabilidades IDOR, un tipo de fallo de control de acceso muy frecuente en APIs. Los resultados merecen atención, pero también una lectura cuidadosa:
| Modelo / pipeline | F1 score | Contexto |
| GLM-5.2 (prompt básico) | 39% | Con un harness mínimo. Detecta más vulnerabilidades IDOR con menos falsos positivos que Claude Code en esta prueba concreta. |
| Claude Code (prompt básico) | 32% | Referencia del sector en coding. Superado en este benchmark específico de seguridad. |
| Pipeline Semgrep a medida | 53-61% | Con harness propio que descubre endpoints y guía al modelo. La ingeniería alrededor del modelo importa tanto como el modelo en sí. |
| Coste por vulnerabilidad | ~0,17 $ | Aproximadamente 1/6 del coste de los modelos frontera en la misma tarea. |
Lo que NO significa: que GLM-5.2 sea mejor que Claude en general, ni el momento Sputnik de la IA china. Es un benchmark específico de seguridad. Además, el propio Zhipu reconoce que el modelo mostró más comportamiento de reward hacking durante el entrenamiento, lo que les llevó a construir salvaguardas específicas. Quien lo apunte a tareas de seguridad debería verificarlo en benchmarks propios antes de confiar en él. Exactamente lo que la apertura del modelo permite hacer.
Lo que sabemos y lo que no
Hay bastante ruido alrededor del lanzamiento. Esto es lo que puede afirmarse con seguridad y lo que todavía está por confirmar.
Lo que sabemos
Es open-weight con licencia MIT, desplegable on-premise sin restricciones. Los pesos son públicos y auditables, lo que permite revisar el comportamiento del modelo e integrarlo en infraestructura propia.
La arquitectura MoE es eficiente en la práctica: solo 40B de los 744B se activan por inferencia, lo que lo hace más manejable de lo que el tamaño total sugiere.
El contexto de 1M tokens está verificado y es la mejora más concreta respecto a GLM-5.1. Lo diferencia de la mayoría de alternativas abiertas actuales, que se quedan en 128K-200K.
Destaca en coding y seguridad: el benchmark de Semgrep lo confirma en detección de vulnerabilidades IDOR, consistente con su orientación declarada hacia el análisis de código.
Lo que no sabemos
No hay benchmarks generales del fabricante en el lanzamiento. Los números que circulan son proxies de GLM-5.1 o mediciones de terceros aún por consolidar. Hay que tomarse con cautela cualquier comparativa de rendimiento general hasta que haya evaluaciones independientes más sólidas.
La comparativa con otras familias abiertas como Llama 4, Qwen3.6 o DeepSeek V3 en tareas generales está pendiente de benchmarks más consolidados. Estas familias tienen ecosistemas más maduros y variantes con requisitos de hardware mucho más modestos.
Los requisitos reales de despliegue en producción tampoco están verificados con benchmarks públicos. Las estimaciones de VRAM apuntan a configuraciones exigentes, pero conviene confirmarlo antes de planificar infraestructura.
Casos de uso relevantes
GLM-5.2 destaca especialmente en análisis de código a gran escala, donde el contexto de 1M tokens permite cargar repositorios completos en una sola llamada. También en auditorías de seguridad automatizadas (como confirma Semgrep), en sistemas agénticos complejos con grandes volúmenes de información, y en procesamiento de documentos extensos como informes, contratos o documentación técnica de centenares de páginas. Es exactamente la lógica que aplicamos cuando desplegamos Konect en producción.
Para tareas generales como chatbots, traducción o generación de contenido, Llama 4, Qwen3.6 o DeepSeek V3 pueden ser más prácticos, con ecosistemas más maduros y variantes con requisitos de hardware mucho más modestos.
Hay además un escenario que en la práctica resulta muy rentable: usar GLM-5.2 como modelo implementador dentro de un stack híbrido. Un modelo frontera planifica y resuelve los pasos de mayor complejidad, mientras GLM-5.2 ejecuta el grueso del trabajo: generación de código, procesamiento de documentos, tareas agénticas repetitivas. El resultado es un consumo muy inferior sin apenas pérdida de capacidades. No es abierto contra cerrado: es que cada pieza opera donde aporta más valor.
Requisitos de hardware
744B parámetros totales (aunque solo 40B activos por inferencia) exigen infraestructura significativa. Estas son las estimaciones actuales, pendientes de benchmarks de producción oficiales:
| Configuración | VRAM estimada | Lo que implica |
| FP16 (máxima precisión) | ~1,5 TB | Requiere un clúster de GPUs de alta gama. Fuera del alcance de la mayoría de entornos on-premise sin inversión específica. |
| INT8 (cuantización media) | ~750 GB | Reduce requisitos a la mitad con pérdida mínima. Factible en configuraciones multi-nodo con H100 80GB. |
| INT4 (cuantización agresiva) | ~375 GB | Más accesible, pero con pérdida de rendimiento apreciable. Útil para exploración, no para producción donde la precisión importe. |
| GPU recomendada | A100 80GB o H100 80GB (multi-nodo) | Configuración de data center o cloud de alta gama. No es infraestructura de oficina. |
Estas cifras corresponden al modelo insignia. Para la mayoría de casos empresariales (transcripción, clasificación, asistentes conversacionales), las variantes pequeñas y medianas de Qwen3.6 o Llama 4 ofrecen rendimiento más que suficiente con requisitos mucho más modestos.
Por qué esto importa
En Faktoria creemos que la soberanía tecnológica no es solo ideología, sino ingeniería pura. Defendemos que el Open Source no es un plan B, sino la vía real para tener control sobre tu infraestructura de IA. GLM-5.2 ilustra bien tres tendencias que ya no tienen vuelta atrás en el ecosistema abierto: la competencia con los modelos frontera propietarios es real en tareas concretas, la arquitectura eficiente importa más que el tamaño bruto, y el contexto largo se está convirtiendo en el campo de batalla donde se decide qué modelos son viables para tareas empresariales exigentes.
GLM-5.2 no es necesariamente el mejor modelo en todas las tareas, ni hace falta que lo sea. Es una opción sólida con fortalezas específicas y limitaciones conocidas. En nuestro artículo sobre IA Open Source y soberanía conversacional desarrollamos los principios que guían cómo elegimos modelos para cada proyecto. Y si estás pensando en dar el paso, desde nuestra consultoría de IA conversacional aplicamos exactamente este criterio: que el control tiene que quedarse donde están tus datos.





