Z.ai afirma que su propio modelo construyó la pila de servicio que lo ejecuta, sobre 100.000 chips chinos

El 17 de septiembre de 2026, la empresa china de IA Z.ai publicó el relato técnico de un proyecto que se lee menos como un anuncio de lanzamiento y más como un cuaderno de ingeniería. La compañía afirmó haber construido desde cero un servicio de inferencia de producción completo para su modelo GLM-5.3-Flash sobre un clúster de más de 100.000 aceleradores de IA de fabricación china, y que un agente de IA ejecutado sobre el propio modelo hizo buena parte del trabajo de bajo nivel.

Lectura relacionada: Un coinventor de ChatGPT dice que a la IA le falta un modelo que no hable · Los propios creadores de la IA advierten sobre las máquinas que están construyendo.

Z.ai, antes conocida como Zhipu AI, afirma que nadie había operado antes aceleradores chinos nacionales a esa escala para un modelo multimodal de frontera. El relato, publicado en el blog de la compañía, expone las limitaciones del hardware, el papel del agente y los errores concretos que sus ingenieros y el agente corrigieron. Es un documento corporativo, no un benchmark independiente, y las cifras de rendimiento proceden de la propia Z.ai. Leído así, sigue siendo una de las descripciones públicas más detalladas de lo que exige servir un modelo grande sobre silicio que no se diseñó pensando en el ecosistema de software de Nvidia.

Lo que Z.ai dice haber construido

GLM-5.3-Flash se lanzó el 26 de agosto de 2026. Es un modelo de mezcla de expertos de 320.000 millones de parámetros con unos 18.000 millones de parámetros activos por token, un híbrido de atención dispersa y lineal, y una ventana de contexto de hasta un millón de tokens. La compañía lo publicó bajo la licencia MIT.

El problema del servicio no era solo el modelo. Z.ai afirmó que los aceleradores chinos que utilizó tienen menos memoria y ancho de banda en chip que las tarjetas gráficas convencionales, y que el ecosistema de software a su alrededor era inmaduro, con soporte incompleto de kernels y comportamientos que deberían haber estado documentados pero que hubo que descubrir por experimentación. A eso se sumaban una arquitectura nueva, una ventana de contexto muy larga y peticiones multimodales.

La respuesta de la compañía combinó dos cosas: un agente y un bucle de retroalimentación.

Un agente que propone, ingenieros que deciden

Z.ai describe un Infra Agent impulsado por GLM-5.3 que proponía diagnósticos, parches de kernels y ediciones de la pila. Los ingenieros humanos fijaban los objetivos y los límites del sistema y revisaban los cambios que entrañaban riesgo real, incluido cualquiera que afectara a la precisión numérica, la concurrencia o la seguridad de producción.

El método que la compañía llama retroalimentación densa es la parte que merece la pena entender. Una métrica de extremo a extremo puede decirle a un agente que algo ha empeorado, pero no por qué. Una prueba de precisión fallida, un aumento del 30 por ciento en el tiempo hasta el primer token o una caída del 20 por ciento en el rendimiento de salida no identifican la capa responsable. El enfoque de Z.ai integra pruebas de corrección, registros de ejecución, trazas de ejecución, microbenchmarks y métricas de extremo a extremo en flujos de trabajo repetibles, de modo que el agente puede validar una hipótesis localmente en lugar de esperar a un despliegue completo y una prueba de carga tras cada cambio.

Según el relato, tres propiedades hacen que eso funcione. La retroalimentación tiene que ser local, ligada a parámetros de lanzamiento, cambios de código, kernels o condiciones de entrada concretos. Tiene que ser barata y rápida de obtener. Y tiene que permitir una verificación objetiva, porque una correlación por sí sola no establece una causa raíz.

Tres correcciones y lo que demuestran

El relato repasa tres casos de ingeniería, y cada uno muestra lo poco glamuroso que es el trabajo de servicio.

El primero es un problema numérico. Cuando Z.ai comparó las rutas de kernel particionadas y no particionadas, encontró un problema de precisión en la ruta de paralelismo de contexto del kernel KDA. La operación tl.dot recurría por defecto al cálculo en TF32 incluso cuando sus entradas eran FP32, de modo que los errores se acumulaban durante la fusión de estados y crecían con la longitud del contexto. La corrección fijó la precisión de entrada en tf32x3, que utiliza tres operaciones de tensor core en TF32 para producir un resultado más preciso. Z.ai afirmó que el cambio se integró en el proyecto ascendente Flash Linear Attention, en una pull request abierta y fusionada el 27 de agosto de 2026.

El segundo es un cuello de botella de concurrencia. El equipo fijó un criterio de aceptación según el cual el prefill más la transferencia de KV debía ejecutarse dentro del 5 por ciento de una línea base solo con prefill. El agente encontró diferencias superiores al 20 por ciento en algunos escenarios y las atribuyó a DeepEP v1.2.1, donde dos llamadas internas no liberaban el bloqueo global del intérprete de Python. Mientras esas llamadas retenían el bloqueo, el hilo de transferencia del mismo proceso no podía adquirirlo a tiempo, así que la planificación se desajustaba y el solapamiento con el cómputo se reducía. Tras la corrección, que liberaba el bloqueo durante los intervalos relevantes, Z.ai afirmó que la diferencia cayó por debajo del 1 por ciento en las mismas condiciones.

El tercero es una mejora de rendimiento de un kernel. Z.ai hizo que el agente destilara técnicas de kernels escritos a mano en proyectos como SGLang, Flash Linear Attention y DeepGEMM en patrones de optimización reutilizables. En un kernel de decodificación KDA, una optimización de la división redujo el tiempo de ejecución un 9,6 por ciento. La retroalimentación señaló entonces el cómputo como cuello de botella, y el agente fusionó cuatro operaciones repetidas de normalización y compuerta en FP32 en un único bloque de hilos, lo que según la compañía produjo una aceleración de 1,71x respecto a la versión anterior.

Ninguna de estas cosas es un avance decisivo por sí sola. En conjunto son el tipo de trabajo que ha mantenido duradera durante años la ventaja de software de Nvidia: no el chip aislado, sino los miles de pequeñas correcciones que hacen que un chip sea utilizable a escala. Un agente capaz de asumir parte de esa carga cambia el coste de portar un modelo a un silicio nuevo.

El nivel de velocidad FlashX

Además del trabajo de infraestructura, Z.ai abrió un nivel de servicio llamado GLM-5.3-FlashX en su API alrededor del 18 de septiembre de 2026. La compañía lo presenta como una versión de alta velocidad de la familia Flash y afirma que la generación máxima alcanza aproximadamente 200 tokens por segundo, utilizando capacidad del mismo clúster de aceleradores nacionales. Pandaily informó de que este nivel posiciona el trabajo como un producto de latencia para producción más que como un nuevo modelo base.

El momento importa. Un nivel de servicio más rápido es una promesa comercial sobre capacidad, no solo un benchmark. Les dice a los desarrolladores que el clúster no es una demostración puntual, sino un sistema contra el que la compañía pretende vender.

Qué significa aquí la mejora recursiva de sí mismo

Z.ai enmarca el proyecto como un ejemplo temprano de mejora recursiva de sí mismo, la idea de que un modelo puede mejorar los sistemas que lo entrenan o lo sirven. Después se distancia de la expresión. La compañía declara que no ha alcanzado la mejora recursiva de sí mismo y que elegir objetivos, fijar límites y evaluar riesgos siguen siendo responsabilidades humanas que, a su juicio, las personas deben conservar.

La distinción es honesta e importante. Un agente que parchea kernels bajo revisión humana está muy lejos de un sistema que fija sus propios objetivos. La afirmación más concreta y limitada es que la ingeniería de sistemas de bajo nivel, una categoría de trabajo que ha resistido la automatización, puede ser parcialmente automatizable cuando el modelo dispone de retroalimentación densa, local y verificable sobre la máquina en la que se ejecuta.

Por qué la inferencia ajena a Nvidia es la verdadera historia

La mayor importancia radica en de dónde puede venir la capacidad de inferencia. Si un modelo multimodal de escala frontera puede servirse con un coste por token competitivo sobre aceleradores chinos, entonces la limitación de la industria china de IA deja de ser tanto el acceso a los chips más rápidos de Nvidia y pasa a ser más la madurez del hardware y el software nacionales. Z.ai afirmó que la utilización del hardware y el coste por token alcanzaron niveles comparables a las GPU de Nvidia convencionales, lo que, si se sostiene, es un desafío directo al supuesto de que servir IA de vanguardia exige hardware de Nvidia.

Esa afirmación merece escrutinio. Z.ai compara su propio clúster con una economía de Nvidia que no controla, y no ha publicado la comparación carga por carga que resolvería la cuestión. El propio modelo base se probó de forma anónima en OpenCode y OpenRouter como ox-alpha antes del lanzamiento, y Z.ai afirmó que se convirtió en el modelo más usado en ambas plataformas en una semana, procesando más de 62 billones de tokens en seis días.

El contexto es un esfuerzo cada vez mayor en China por reducir la dependencia de los chips estadounidenses. Los fabricantes nacionales de aceleradores, los proveedores de memoria y los proveedores de nube han pugnado por cubrir esa brecha, y la capa de software ha sido la parte más difícil. Una pila de servicio funcional y asistida por agentes es una prueba de concepto para ese esfuerzo, aunque su economía todavía no esté verificada de forma independiente.

Salvedades y qué hay que observar

Casi todas las cifras que aparecen aquí proceden de Z.ai. La ganancia de rendimiento de 3x, el plazo inferior a dos semanas, la aceleración de kernel de 1,71x y la comparación con la economía de Nvidia son declaraciones de la compañía. La pull request de GitHub es pública y verificable, lo que da cierto respaldo independiente al caso de la precisión numérica, pero el resto no se ha reproducido fuera de la empresa.

Tres cosas serán importantes en los próximos meses. Primero, si usuarios independientes reproducen las afirmaciones de rendimiento y coste sobre el mismo hardware o uno similar. Segundo, si las optimizaciones que describe Z.ai son reutilizables en otros aceleradores chinos o específicas de su propio clúster. Tercero, si FlashX mantiene su latencia prometida a escala cuando llegue tráfico real, y no una huella de la semana de lanzamiento.

Por ahora, la historia es un dato en un debate que ha durado todo el año: con qué rapidez puede cerrarse la brecha de software en torno al hardware de IA ajeno a Nvidia, y cuánto de ese trabajo pueden hacer los propios modelos. La respuesta de Z.ai es que una parte significativa ya es posible. La carga de la prueba recae ahora en los benchmarks que vengan después.

Portada: el logotipo de Zhipu AI (Z.ai). Logotipo de dominio público vía Wikimedia Commons.