Hace un par de semanas me puse a revisar cuánta VRAM necesitaba para correr GLM 5.2 en mi VPS. La respuesta fue brutal: 705 GB en precisión estándar. Ni siquiera el servidor de la pega tiene eso. Asà que cuando leà el post técnico de Cloudflare sobre cómo están sirviendo Kimi K2.6 y GLM 5.2 en su red edge, me quedé pegado.
No es magia. Es ingenierÃa de verdad, con números que se pueden replicar.
El cuello de botella no es lo que crees
La mayorÃa de los que empezamos con IA local pensamos que el problema son los pesos del modelo. Cloudflare demuestra que no: para modelos con contexto largo, el KV cache (la memoria donde el modelo guarda lo que ya leÃste para no repetirlo) es lo que llena la GPU primero.
Con Kimi K2.6 en BF16 estándar, el lÃmite práctico era 686.000 tokens de contexto. Cloudflare lo pasó a FP8 y ahora soporta 1,37 millones de tokens en la misma memoria. El truco: bajar la precisión del cache sin tocar los pesos. La pérdida de calidad es despreciable, según sus benchmarks propios: GSM8K pasó de 94.24 a 94.09, MMLU de 89.11 a 89.04. Si no sabes qué significa eso, básicamente es imperceptible.
El efecto secundario es que, al caber más requests concurrentes, el throughput total se dispara: de 1.558 tokens/s en el mejor caso BF16, subieron a 2.192 tokens/s con FP8 a 64 requests concurrentes. BF16 ahà simplemente se cae por falta de memoria.
Pesos en INT4: el hack que funciona
Para GLM 5.2, Cloudflare hizo algo más agresivo: comprimió los pesos de FP8 a INT4. El modelo pasó de 705 GB a 421 GB. En términos prácticos, la memoria por GPU bajó de 88 GB a 52 GB, dejando espacio para un millón de tokens de contexto adicional.
La velocidad de decodificación —que es donde más duele la latencia— mejoró entre un 16% y un 55% dependiendo de la concurrencia. A un solo request, el modelo pasa de 60 a 92 tokens por segundo. En un modelo tan grande, eso es la diferencia entre usable e inusable.
Y de nuevo, la pérdida de precisión es ridÃcula: GSM8K flexible pasa de 94.24 a 93.48. ARC-Challenge ni se mueve. Es la clase de tradeoff que cualquier sysadmin acepta de inmediato.
El detalle que importa: seguridad del cache compartido
Aquà es donde Cloudflare demuestra que no son solo ingenieros, sino que entienden ciberseguridad. Al meter más requests en el mismo hardware, compartes el KV cache entre usuarios diferentes. Si no aislas bien, un cliente puede leer el cache de otro.
La solución que implementaron es separar prefill y decode en pools distintos, y además restringir el cache compartido con técnicas de aislamiento a nivel de bloques de memoria. No dan todos los detalles técnicos —obviamente— pero el hecho de que lo mencionen como una preocupación real ya los diferencia de muchos que solo ven throughput.
¿Qué significa esto para los que no tenemos un data center?
Personalmente, esto me cambia la perspectiva. Durante meses asumà que los modelos de 70B+ eran territorio de cloud exclusivo. Pero si FP8 e INT4 son viables en producción a escala Cloudflare, significa que la barrera de entrada para self-hosting está bajando rápido.
Ya existen cuantizaciones Q4_K_M de Llama 3.1 que corren decentemente en una RTX 4090 con 24 GB. Lo que Cloudflare está demostrando es que esas técnicas no son hacks de aficionados: son la dirección en la que la industria se está moviendo, con benchmarks formales y despliegues en producción.
Mi takeaway: si eres de los que self-hostean modelos locales, no tengas miedo de probar cuantizaciones agresivas. La pérdida de calidad en la mayorÃa de los casos prácticos es menor que el ruido de tu prompt. Y el ahorro de memoria te permite correr modelos que, hace seis meses, parecÃan imposibles.
Tokio, desde el VPS, 3 de agosto 2026.
Fuente de inspiración: Smaller, faster, safer: running Kimi and GLM at scale | Cloudflare Blog
