El 13 de junio de 2026 Zhipu (Z.ai) publicó GLM-5.2 con licencia MIT, sin restricciones regionales, sin cláusulas de uso comercial y sin letra pequeña: puedes descargarlo, desplegarlo, ajustarlo y venderlo integrado en tu producto. Es de lo más permisivo que se ha visto en un modelo de esta escala.
En los diez días siguientes he tenido tres conversaciones prácticamente idénticas. Un responsable de sistemas lee la noticia, entiende —correctamente— que el modelo es libre, y concluye —incorrectamente— que puede instalarlo en el servidor de la oficina y dejar de pagar tokens a una API americana. Cuando le pregunto qué hardware tiene, la respuesta suele ser una máquina con una GPU de 24 GB, a veces dos.
GLM-5.2 no cabe ahí. No cabe ni de lejos. Y esa distancia entre "es libre" y "lo puedo desplegar" es, ahora mismo, la confusión más cara del sector.
En abril escribí aquí una guía de arquitectura de IA on-premise para cumplir con el RGPD en la que defendía que desplegar IA dentro del perímetro europeo ya no exige un equipo de ML ni un data center. Lo sigo defendiendo; este artículo no la contradice, la matiza en el punto donde más se está malinterpretando. La opción on-premise es real, pero la puerta de entrada es un modelo pequeño, no el modelo grande del que habla la prensa técnica. Confundir las dos cosas es la vía más rápida a un presupuesto de hardware que no se aprueba o, peor, a uno que se aprueba y no sirve.
Dos cosas distintas que se llaman igual
"Modelo abierto" mezcla en una sola etiqueta dos propiedades que no tienen nada que ver:
- Qué te deja hacer la licencia. Es una cuestión jurídica. La resuelve tu asesor legal leyendo un fichero de texto.
- Qué hardware necesitas para ejecutarlo. Es una cuestión física. La resuelve una multiplicación.
Un modelo puede ser máximamente permisivo en lo primero y absolutamente inalcanzable en lo segundo. GLM-5.2 es exactamente ese caso. La licencia es un permiso, no una capacidad.
El eje de la licencia
En la práctica te vas a encontrar tres familias:
- MIT y Apache 2.0. Permisivas de verdad. Uso comercial, modificación, redistribución, fine-tuning, sin límite de usuarios ni de región. Apache 2.0 añade una concesión expresa de patentes que a algunos departamentos legales les gusta tener por escrito. Aquí están GLM-5.2 (MIT), Gemma 4 (Apache 2.0), Qwen3.6 (Apache 2.0), la familia gpt-oss de OpenAI (Apache 2.0) y DeepSeek V4 (MIT).
- Licencias propias con condiciones. El texto se parece a una licencia abierta pero incorpora restricciones: umbrales de usuarios activos a partir de los cuales necesitas un acuerdo aparte, obligaciones de atribución en el producto, o políticas de uso aceptable incorporadas por referencia. Son perfectamente utilizables, pero hay que leerlas antes de construir encima.
- Licencias no comerciales o solo de investigación. Descargables, pero inservibles para un producto que factura.
"Descargable en Hugging Face" no equivale a "puedo usarlo en mi producto". Antes de construir sobre un modelo, alguien de tu equipo tiene que abrir el fichero LICENSE del repositorio y leerlo entero, igual que harías con cualquier dependencia de software. En modelos con licencia propia, las condiciones se activan justo cuando el producto empieza a funcionar bien: al superar cierto volumen de usuarios.
El eje del hardware
Este es el que se salta todo el mundo, y es el que manda. Vamos con la aritmética.
La cuenta que decide si cabe o no
Hay una fórmula, es sencilla, y hacerla antes de una reunión de presupuesto te ahorra un trimestre:
GB de VRAM solo para los pesos ≈ (nº de parámetros × bits por parámetro) ÷ 8
Los bits por parámetro dependen de la precisión con la que guardes el modelo:
| Precisión | Bits por parámetro | Bytes por parámetro | Efecto en calidad |
|---|---|---|---|
| FP16 / BF16 | 16 | 2 | Referencia, sin pérdida |
| FP8 | 8 | 1 | Pérdida pequeña en la mayoría de tareas |
| INT4 / Q4 | 4 | 0,5 | Pérdida perceptible según la tarea; hay que medirla |
Con eso, un modelo denso de 8.000 millones de parámetros en FP16 ocupa unos 16 GB solo de pesos. El mismo modelo en Q4, unos 4 GB. Un 70B en Q4, unos 35 GB. La cuenta es directa y no admite optimismo.
Y luego está el KV cache, que es donde se rompen los presupuestos. Cada petición en vuelo mantiene en memoria las claves y valores de atención de todo su contexto, y ese consumo crece con la longitud del contexto y con el número de peticiones simultáneas. Con un solo usuario y prompts cortos es despreciable; en producción, con ventanas largas y decenas de conversaciones abiertas, se come varios gigas por encima de los pesos. Un servidor dimensionado justo para los pesos no es un servidor: es una demo que se cae el primer día que la usan diez personas a la vez.
Dimensiona siempre con margen sobre los pesos, no al ras. La regla operativa que usamos: si los pesos no dejan holgura suficiente para el KV cache de tu concurrencia esperada y su longitud de contexto real, el modelo no cabe en ese hardware, aunque el fichero quepa en disco. "Cabe" significa "sirve peticiones a la vez", no "carga".
La trampa específica de los modelos MoE
Aquí es donde el asunto se vuelve contraintuitivo, y es justo el error que lleva a la gente a pensar que GLM-5.2 es viable.
Los modelos grandes de 2026 son mixture-of-experts: tienen un número enorme de parámetros totales, pero por cada token solo se activa una fracción. GLM-5.2 ronda los 744.000 millones de parámetros totales con unos 40.000 millones activos por token. DeepSeek V4-Flash, unos 284.000 millones totales con unos 13.000 millones activos.
La lectura tentadora es: "si solo se activan 40B, necesito memoria para 40B". Es falsa. El enrutador puede mandar el siguiente token a cualquier experto, así que todos los expertos tienen que estar residentes en memoria. Lo que ahorra el MoE es cómputo por token —y por tanto velocidad y coste energético—, no memoria. Para la cuenta de VRAM, lo que manda es el número de parámetros totales.
Esa es exactamente la razón por la que un modelo con 40B activos necesita hardware de rack y no una tarjeta gráfica.
Qué hace falta para GLM-5.2, con la cautela debida
Z.ai no publicó en el lanzamiento una especificación oficial de hardware ni una suite completa de benchmarks propios. Las cifras que circulan vienen de proveedores de GPU en la nube que lo han puesto en marcha, no del fabricante. Con esa advertencia por delante, el orden de magnitud que se maneja es:
- En FP8, del orden de 372 GB de VRAM como mínimo operativo, lo que en la práctica significa 4 GPUs H100 de 80 GB; en producción se recomiendan 8×H200.
- En FP16/BF16, alrededor de 1.500 GB solo de pesos: territorio multinodo.
- Se sirve con vLLM o SGLang, que son las dos piezas estándar para esto.
Trata esas cifras como orden de magnitud, no como especificación. Ni siquiera cuadran limpiamente con la fórmula de arriba: 744.000 millones de parámetros a 8 bits darían del orden de 744 GB solo de pesos, el doble de los 372 GB que se citan. Esa distancia sale de cómo esté cuantizado y distribuido cada despliegue concreto, y es precisamente el motivo para no llevar un número de un blog a una propuesta de compra. Si vas a comprar hardware, exige a tu proveedor la configuración exacta que ha medido: precisión, motor de serving, longitud de contexto y concurrencia. Sin esos cuatro datos, una cifra de VRAM no significa nada.
Aun quedándonos en la lectura más favorable, la conclusión no cambia: el suelo de entrada de GLM-5.2 son cuatro H100. No es hardware de pyme. Es hardware de proveedor de infraestructura.
Y lo mismo vale, con números más suaves, para DeepSeek V4: 284.000 millones de parámetros totales siguen sin caber en una máquina de oficina por muy MIT que sea la licencia y por mucho que solo active 13.000 millones por token.
Tabla de "qué cabe dónde"
Esta es la tabla que le enseño a un cliente antes de hablar de nada más. Las cifras son aproximadas, cuentan solo los pesos y suponen cuantización razonable; el KV cache va aparte y hay que sumarlo.
| VRAM disponible | Hardware típico | Qué entra de verdad | Dónde se rompe |
|---|---|---|---|
| 8–16 GB | Portátil con GPU dedicada, RTX 4060/4070, móvil de gama alta (variantes pequeñas) | Gemma 4 E2B y E4B; gpt-oss-20b; modelos densos de 7–14B en 4 bits | Cualquier cosa por encima de ~20B; contextos largos con varios usuarios |
| 24 GB | Una RTX 4090 / 5090, workstation de sobremesa | Qwen3.6-27B en 4 bits; Gemma 4 26B/31B cuantizado; densos de 30B en 4 bits | 70B incluso en Q4; ventanas de 1M de contexto |
| 80 GB | Una H100 o H200, servidor de rack de una GPU | gpt-oss-120b (cabe en una sola GPU de 80 GB); densos de 70B en Q4 con holgura para KV cache | Cualquier MoE de cientos de miles de millones de parámetros totales |
| 140–320 GB | 2× a 4× H100, chasis de servidor multi-GPU | DeepSeek V4-Flash cuantizado; densos de 70B en FP16 | GLM-5.2 en FP8, según proveedores, va justo o no entra |
| ≥ 372 GB | 4×H100 mínimo, 8×H200 recomendado | GLM-5.2 en FP8 (cifra de proveedores, no oficial) | — |
| ~1.500 GB | Multinodo con interconexión rápida | GLM-5.2 en FP16/BF16 | — |
Léela de derecha a izquierda: la columna que importa no es la de lo que entra, sino la de dónde se rompe. Casi todos los proyectos que he visto fracasar por hardware lo hicieron porque alguien miró la primera columna y se saltó la última.
Los que sí caben en una pyme
La buena noticia es que la parte útil del catálogo abierto es la que cabe. En orden de menos a más exigente:
- Gemma 4 (Google, 2 de abril de 2026, Apache 2.0). La familia más versátil del año en tamaños razonables: variantes E2B y E4B que corren en un móvil o un portátil, y versiones de 26B y 31B para una sola GPU. Si tu caso es clasificación, extracción estructurada, resumen o RAG sobre documentación interna, empieza aquí.
- Qwen3.6-27B (abril de 2026, Apache 2.0). Cuantizado a 4 bits cabe en 24 GB, es decir, en una tarjeta de sobremesa. Fuerte en multilingüe y en código.
- gpt-oss-20b y gpt-oss-120b (OpenAI, agosto de 2025, Apache 2.0). El 20b funciona en 16 GB; el 120b entra en una sola GPU de 80 GB. Que un modelo de 120.000 millones de parámetros quepa en una única H100 es, en términos de despliegue, mucho más relevante para una pyme que cualquier titular sobre modelos de 744B.
- DeepSeek V4 (24 de abril de 2026, MIT). Potente y con ventana de 1M de contexto, pero con 284.000 millones de parámetros totales en su variante Flash ya está fuera del alcance de una máquina única. Lo incluyo para que se vea dónde está la frontera, no como recomendación de despliegue interno.
El listón práctico para una primera IA on-premise en una pyme está en una sola GPU. Con Gemma 4, Qwen3.6-27B o gpt-oss en una máquina bien dimensionada, servidos con vLLM, cubres la inmensa mayoría de casos empresariales reales: RAG sobre documentación, clasificación de correo y tickets, extracción de datos de facturas y contratos, redacción asistida. Si tu caso está ahí, no necesitas mirar los modelos de cientos de miles de millones de parámetros.
El matiz que lo cambia todo: el más caro no siempre gana
Si el artículo acabara aquí, la conclusión sería "modelo grande = mejor, pero inalcanzable". Y eso tampoco es cierto. El 22 de junio de 2026 Semgrep publicó una evaluación independiente en tareas de ciberseguridad que merece leerse entera, porque hace lo que casi ningún benchmark hace.
El montaje: un conjunto de vulnerabilidades de tipo IDOR (referencias directas a objetos inseguras, uno de los fallos de autorización más comunes en aplicaciones web), el mismo prompt para todos los modelos y F1 como métrica —es decir, penalizando tanto los fallos que se escapan como las falsas alarmas—. Los resultados:
| Configuración | F1 |
|---|---|
| GLM 5.2 con harness de prompt mínimo | 39% |
| Claude Code (Opus 4.6) con SDK | 37% |
| Claude Code (Opus 4.8/4.7) | 28% |
Y el dato que de verdad importa: unos 0,17 $ por vulnerabilidad encontrada con GLM 5.2, aproximadamente la sexta parte del coste de modelos frontera comparables.
Tres cosas hacen que esto valga mucho más que un benchmark de fabricante. Es de un tercero sin interés en el resultado. Tiene metodología descrita. Y, sobre todo, mide coste por unidad de resultado, no una puntuación abstracta: no dice "es un 4% mejor", dice "encuentra un fallo por la sexta parte del dinero".
Un detalle metodológico que conviene subrayar: la configuración ganadora de GLM 5.2 era la de harness mínimo, mientras que los competidores corrían sobre un SDK completo. Que un andamiaje más simple rinda más es un recordatorio de que en estas evaluaciones se mide el sistema entero —modelo más prompt más herramientas—, no el modelo desnudo. Cambiar el harness cambia el resultado, y por eso los números de una evaluación no se trasladan sin más a tu caso.
La pregunta correcta no es "¿cuál es el mejor modelo?", sino "¿cuál es el mejor modelo para esta tarea concreta a este coste concreto?". Son preguntas distintas y con frecuencia tienen respuestas distintas. Una organización con varios casos de uso acabará, casi seguro, con más de un modelo en producción: no por indecisión, sino porque es lo correcto. Ya expliqué en el repaso de benchmarks de agentes de junio por qué el rendimiento depende brutalmente de la tarea; esto es el mismo fenómeno visto desde la factura.
Ojo con la otra cara: el resultado de Semgrep es en una tarea, IDOR, con una metodología. No autoriza a concluir que GLM 5.2 sea mejor que los modelos frontera en general, ni que lo sea en tu dominio. Autoriza a concluir algo más modesto y más útil: que el orden de mérito cambia según la tarea, y que si no lo mides en la tuya estás decidiendo a ciegas.
Y un detalle que cierra el círculo con la primera mitad del artículo: ese coste de 0,17 $ por vulnerabilidad se obtiene consumiendo GLM 5.2 por API. Ser un modelo de pesos abiertos no obliga a alojarlo. Es una opción, no una consecuencia.
Entonces, ¿cuándo compensa on-premise de verdad?
Tras un año largo viendo estos proyectos, mi lista se ha vuelto más corta y más exigente. On-premise compensa cuando concurren al menos dos de estas tres condiciones:
- Hay datos que no pueden salir. No "preferiríamos que no salieran": no pueden. Historiales clínicos, secreto profesional, expedientes con datos de categoría especial, información sometida a un régimen contractual o sectorial estricto. Aquí el on-premise ayuda a cumplir el marco de protección de datos porque elimina de raíz la transferencia internacional, no porque el hardware "cumpla" nada por sí mismo. La guía de arquitectura on-premise desarrolla ese análisis en detalle.
- El volumen es alto y estable. La amortización de una GPU exige uso sostenido. Consumo esporádico o muy variable favorece a la API, que escala a cero cuando nadie la usa. Un servidor con una GPU parada el 90% del tiempo es la forma más cara de no usar IA.
- La latencia importa de verdad. Casos interactivos donde el tiempo hasta el primer token se nota, o donde la conectividad no está garantizada (planta industrial, sede sin buen enlace, dispositivo desconectado).
Y sigue sin compensar cuando: aún estás validando si la IA aporta valor —para eso está el framework de validación en cuatro semanas, y se hace con API—; no hay nadie en el equipo capaz de operar Linux con GPU; o el caso exige capacidades que solo dan los modelos frontera.
Un despliegue on-premise mal operado es peor que una API, también en protección de datos. He visto endpoints de inferencia expuestos sin autenticación y bases vectoriales con toda la documentación interna accesible desde la red plana de la oficina. Tener el dato en tu rack no garantiza nada si el rack está mal cerrado: control de acceso, aislamiento de red y registros de auditoría no dejan de ser obligatorios por estar en casa.
La opción intermedia que casi nadie plantea
La conversación se plantea casi siempre como binaria —API o servidor propio— y la respuesta correcta suele estar en medio. No por cobardía: porque es la arquitectura que mejor refleja cómo son los datos de una empresa real, donde no todo es igual de sensible.
Clasifica por sensibilidad del dato, no por caso de uso.
- Lo que contiene datos personales sensibles, secreto profesional o información estratégica → modelo pequeño local. Gemma 4 o Qwen3.6-27B en una sola GPU cubren clasificación, extracción, resumen y RAG interno con calidad de sobra para la mayoría de estas tareas. El dato nunca sale.
- Lo que no es sensible o puede anonimizarse de forma robusta antes de salir → API, con el modelo que mejor rinda en esa tarea a ese coste. Aquí entra el resultado de Semgrep: el mejor modelo para esa tarea puede ser uno abierto consumido por API, y salir seis veces más barato.
- La frontera entre ambos mundos vive en tu capa de orquestación, no en el modelo: una decisión de enrutado explícita, registrada y auditable, con la anonimización aplicada antes de cruzarla y no confiada al modelo.
Esto tiene una consecuencia de diseño que conviene asumir desde el primer día: el modelo concreto tiene que ser una pieza intercambiable. Contratos de entrada y salida estables, evaluaciones automatizadas propias y capacidad de conmutar entre proveedor local y remoto sin tocar la lógica de negocio. En un año en el que aparecen modelos relevantes cada pocas semanas, atarse a uno es tan mala idea como atarse a un proveedor. Y si vas a mandar algo fuera, revisa antes qué riesgos tiene meter datos de empresa en herramientas de terceros.
Cierre: primero la multiplicación, después el presupuesto
Lo que ha cambiado en 2026 no es que los modelos abiertos sean buenos —lo eran ya— ni que las licencias sean permisivas —GLM-5.2 con MIT es notable, pero Apache 2.0 lleva tiempo siendo la norma—. Lo que ha cambiado es la escala: los modelos abiertos punteros han crecido tanto que han dejado de ser desplegables por sus destinatarios naturales. La apertura de la licencia y la accesibilidad del despliegue se han separado, y mucha gente sigue leyéndolas como una sola cosa.
La disciplina que propongo son tres pasos, en este orden:
- Haz la multiplicación antes de la reunión. Parámetros totales × bits ÷ 8, más KV cache para tu concurrencia real. Si no cabe, no cabe, y ninguna licencia lo va a arreglar.
- Mide en tu tarea, no en el benchmark de nadie. Un modelo barato puede ganarle a uno caro en tu caso concreto. Solo lo sabrás si montas tu propia evaluación con tus propios datos.
- Decide el despliegue por la sensibilidad del dato, no por la nota del modelo ni por la estética de "tenerlo en casa".
Si tuviera que resumirlo en una frase para llevar a un comité: licencia abierta significa que puedes, no que quepa. Y para la mayoría de pymes españolas, el camino sensato es un modelo pequeño en una sola GPU para lo que no puede salir, y API para todo lo demás. No es la respuesta épica, pero es la que funciona y la que se amortiza.
En Lin-ia dimensionamos este tipo de arquitecturas antes de que nadie firme una orden de compra de hardware: primero el caso de uso, después la evaluación con datos reales, y solo al final la máquina. Si estás en ese punto y quieres una segunda opinión antes de comprometer presupuesto, escríbenos y lo vemos.
Lecturas relacionadas: arquitectura de IA on-premise RGPD-compliant, qué saben hacer de verdad los agentes de IA y cómo validar un caso de uso de IA antes de invertir.
