Cloudflare ha explicado algunos de los cambios que ha introducido en Workers AI para ejecutar modelos abiertos de gran tamaño como Kimi K2.6 de Moonshot AI y GLM 5.2 de Z.ai de forma más eficiente. La compañía asegura haber reducido el consumo de memoria de GPU y el coste por inferencia mediante nuevas técnicas de optimización, manteniendo prácticamente intacta la precisión de los modelos.

Las claves de las optimizaciones de Cloudflare en 20 segundos

• Workers AI incorpora nuevas técnicas para ejecutar modelos abiertos de gran tamaño con menos memoria GPU.
• Cloudflare combina caché KV en FP8, pesos comprimidos en INT4 y nuevos mecanismos de protección de memoria.
• La compañía afirma mantener prácticamente la misma precisión que los modelos originales.
• El objetivo es aumentar el número de solicitudes simultáneas y reducir el coste por inferencia.

La publicación ofrece una visión poco habitual del trabajo que existe detrás de la ejecución de modelos de lenguaje a gran escala, donde el reto ya no consiste únicamente en disponer de GPUs más potentes, sino en aprovechar mejor cada gigabyte de memoria disponible.

El verdadero cuello de botella está en la memoria

Cloudflare explica que modelos como Kimi K2.6 o GLM 5.2 destacan por su capacidad para manejar contextos muy largos y arquitecturas Mixture of Experts (MoE), pero precisamente esas características hacen que su despliegue resulte especialmente exigente desde el punto de vista de la memoria.

En muchos casos, el principal límite no son los propios parámetros del modelo, sino la denominada KV Cache, una estructura que almacena las claves y valores de atención generados durante la conversación para evitar recalcular todo el contexto en cada nueva respuesta.

Con conversaciones largas, esta caché puede ocupar más memoria que el propio modelo.

Reducir la caché a la mitad con FP8

Una de las optimizaciones consiste en almacenar la KV Cache utilizando precisión FP8 en lugar de BF16.

Según Cloudflare, este cambio reduce aproximadamente a la mitad el espacio necesario para almacenar la caché. En el caso de Kimi K2.6, el contexto máximo que puede mantenerse en memoria pasa de unos 686.000 tokens a cerca de 1,37 millones de tokens.

Aunque el rendimiento por petición individual disminuye ligeramente debido a las conversiones necesarias entre formatos numéricos, la mejora aparece cuando aumenta la concurrencia.

Con BF16 el sistema agotaba la memoria con 32 solicitudes simultáneas, mientras que FP8 permite llegar hasta 64 peticiones concurrentes, alcanzando aproximadamente 2.192 tokens por segundo, un incremento cercano al 41 % respecto al máximo conseguido con BF16.

Cloudflare añade que sus pruebas internas no detectan diferencias apreciables de precisión entre ambos formatos en benchmarks como GSM8K, MMLU o ARC.

GLM también reduce el tamaño del modelo con INT4

La segunda técnica afecta directamente a los pesos del modelo.

Para GLM 5.2, Cloudflare utiliza una cuantización INT4, reduciendo el tamaño del modelo desde aproximadamente 705 GB hasta 421 GB, cerca de un 40 % menos.

Esta reducción permite liberar memoria en cada GPU para dedicarla a una mayor cantidad de contexto y, además, acelera la fase de generación de texto.

Los datos publicados muestran mejoras de rendimiento especialmente visibles cuando existe poca concurrencia. En una única petición simultánea, GLM pasa de generar unos 60 tokens por segundo utilizando FP8 a aproximadamente 92 tokens por segundo con INT4.

La compañía reconoce que esta técnica no resulta igual de beneficiosa durante la fase inicial de procesamiento (prefill), donde continúa utilizando FP8 al tratarse de una operación limitada principalmente por capacidad de cálculo y no por ancho de banda de memoria.

Más eficiencia exige más mecanismos de seguridad

Incrementar el número de peticiones que comparten la memoria de una GPU también aumenta el riesgo de errores durante la reutilización de la KV Cache.

Para minimizar ese riesgo, Cloudflare ha desarrollado un sistema de verificación de integridad de la caché que comprueba que cada solicitud accede únicamente a las páginas de memoria que le corresponden.

Si detecta cualquier inconsistencia, la petición se cancela antes de devolver una respuesta potencialmente incorrecta.

Según los datos publicados, este mecanismo añade un impacto inferior al 1 % tanto en rendimiento como en latencia, por lo que la compañía considera que el coste es asumible para mejorar la fiabilidad del sistema.

El reto ahora es servir más modelos al mismo coste

Cloudflare afirma que seguirá ampliando estas optimizaciones al resto de su infraestructura.

Entre las próximas líneas de trabajo menciona la expansión del uso de FP8 para la KV Cache, nuevas técnicas de compresión como NVFP4 sobre la arquitectura Blackwell de NVIDIA y la implantación generalizada de las comprobaciones de integridad de memoria.

Más allá de los detalles técnicos, el artículo refleja una tendencia creciente en la industria de la IA: la carrera ya no consiste únicamente en desarrollar modelos más grandes, sino en conseguir ejecutarlos de forma más eficiente para atender a un mayor número de usuarios sin disparar los costes de infraestructura.

Preguntas frecuentes

¿Qué modelos optimiza Cloudflare?

La compañía describe las mejoras aplicadas principalmente a Kimi K2.6, desarrollado por Moonshot AI, y GLM 5.2, de Z.ai, ambos disponibles en Workers AI.

¿Qué ventaja aporta usar FP8 para la KV Cache?

Reduce aproximadamente a la mitad el consumo de memoria de la caché, permitiendo atender más solicitudes simultáneamente sin afectar de forma significativa a la precisión del modelo.

¿Qué consigue la cuantización INT4?

Comprime los pesos del modelo para ocupar menos memoria GPU y mejorar la velocidad de generación durante la fase de decodificación.

¿Se pierde precisión al reducir el tamaño del modelo?

Según los benchmarks publicados por Cloudflare, las diferencias respecto a las versiones originales son mínimas y no resultan significativas en las pruebas utilizadas por la compañía.