El servicio de modelos más pequeños de Cloudflare reduce la memoria, pero la seguridad se convierte en la prueba decisiva
El servicio de modelos más pequeños de Cloudflare ahora permite alojar el doble de contexto de Kimi en la memoria GPU, aunque acepta un procesamiento ligeramente más lento con una concurrencia habitual. La empresa también comprime los pesos de GLM y verifica las páginas de caché compartida antes de que las operaciones de decodificación compatibles las lean. En conjunto, estos cambios convierten la memoria GPU de un límite fijo en un recurso que Cloudflare puede gestionar activamente.
Esto importa porque los modelos Kimi de Moonshot AI y los modelos GLM de Z.ai no son incorporaciones convencionales a un catálogo de inferencia. Combinan grandes cantidades de parámetros, ventanas de contexto extensas y arquitecturas de mezcla de expertos. Un modelo de mezcla de expertos activa partes seleccionadas de su red para cada token, lo que reduce el cómputo sin hacer pequeños sus pesos almacenados.
El conflicto no es simplemente Cloudflare frente a otro proveedor de inferencia. Se trata de alta utilización frente a aislamiento seguro en hardware compartido. Empaquetar más solicitudes en una GPU mejora la economía y el rendimiento total, pero también aumenta las consecuencias de una gestión defectuosa de la caché.
Cloudflare afirma que su nueva configuración conserva la precisión del modelo mientras aumenta la capacidad. Sin embargo, la mayoría de las mediciones de respaldo proceden del propio conjunto de evaluación e infraestructura de Cloudflare. La siguiente prueba es determinar si esas mejoras se mantienen estables entre cargas de trabajo, generaciones de hardware y volúmenes de producción mucho mayores.
Qué cambió Cloudflare para Kimi y GLM
Cloudflare combinó tres técnicas de memoria porque ninguna optimización por sí sola resuelve el servicio de modelos a escala de frontera.
La empresa detalló los cambios en un informe técnico del 3 de agosto. Aplica cuantización FP8 a la caché KV de Kimi, compresión INT4 a los pesos de GLM y etiquetas de integridad a las páginas de caché compartida. Cada técnica aborda una restricción distinta dentro del mismo sistema de inferencia.
Una caché KV almacena las claves y los valores de atención creados para los tokens que el modelo ya ha procesado. Permite que un modelo continúe una conversación sin recalcular todo el prompt antes de cada token generado. Los prompts largos y las solicitudes concurrentes hacen que esa caché crezca rápidamente.
Cloudflare almacena los datos de caché de Kimi K2.6 en FP8 e4m3 en lugar de BF16. FP8 utiliza ocho bits para cada valor de coma flotante, mientras que BF16 utiliza dieciséis. Esa conversión reduce a la mitad la huella de memoria de la caché.
Según Cloudflare, el contexto disponible en memoria aumenta de unos 686.000 tokens a aproximadamente 1,37 millones de tokens. Se trata de capacidad agregada en el despliegue probado, no de un nuevo límite de ventana de contexto para un solo usuario. La distinción importa porque la optimización aumenta principalmente la concurrencia.
Cloudflare realizó un cambio independiente para GLM 5.2. Comprimió los pesos del modelo de FP8 a INT4, una representación entera de cuatro bits. Según los informes, el checkpoint se redujo de 705 GB a 421 GB, o cerca de un 40 por ciento.
Un despliegue con paralelismo tensorial de ocho vías divide el modelo entre ocho GPU. Con esa configuración, Cloudflare afirma que el uso de memoria cayó de aproximadamente 88 GB a 52 GB por GPU. El espacio restante puede alojar alrededor de 1,18 millones de tokens de caché KV.
El tercer cambio protege la caché compartida creada por este empaquetado más denso. Cada página de caché física recibe una etiqueta que cambia cada vez que la página se reasigna. El servidor registra las páginas y etiquetas que espera cada solicitud.
Antes de que las operaciones de decodificación compatibles lean esas páginas, Cloudflare verifica las asignaciones. Una discrepancia hace que la solicitud afectada se detenga. Por tanto, el sistema debería fallar de forma segura en lugar de leer datos asociados a otra solicitud.
Estas técnicas se sitúan sobre la arquitectura más amplia de Cloudflare para modelos grandes. La empresa describió anteriormente la inferencia Infire como un motor basado en Rust diseñado para su red distribuida de GPU. También separa el prefill y la decodificación en grupos de recursos distintos.
El prefill procesa un prompt entrante y crea su estado inicial de caché. La decodificación genera la respuesta token a token. Esas fases ejercen presión sobre las GPU de forma diferente, lo que permite a Cloudflare optimizar cada grupo por separado.
Esa separación es esencial para el nuevo diseño. Cloudflare mantiene cachés BF16 y pesos FP8 donde domina el cómputo. Utiliza representaciones más pequeñas donde la capacidad de memoria o el ancho de banda se convierten en el recurso limitante.
El resultado no es una única configuración de modelo comprimido que sirva para todo. Es un sistema de servicio consciente de las fases que cambia los formatos según la carga de trabajo. Esto crea más complejidad operativa, pero evita imponer una sola concesión sobre toda la solicitud.
Por qué las cachés más pequeñas de Cloudflare superan a la velocidad bruta
La cuantización de la caché KV de Kimi gana al admitir más trabajo, no al hacer que cada solicitud sea individualmente más rápida.
Cloudflare probó la decodificación de Kimi K2.6 en un despliegue H200 desagregado. Con una solicitud concurrente, la caché BF16 entregó 137 tokens por segundo. La versión FP8 entregó 125, lo que hizo que la caché comprimida fuera más lenta con esa carga.
El patrón continuó al aumentar la concurrencia. Con ocho solicitudes, BF16 alcanzó 731 tokens por segundo, frente a 689 para FP8. Con dieciséis solicitudes, las mediciones fueron de 1.106 y 1.028 tokens por segundo.
BF16 alcanzó 1.558 tokens por segundo con 32 solicitudes concurrentes. Sin embargo, entonces agotó la memoria disponible. Cloudflare afirma que la caché FP8 continuó hasta 64 solicitudes y entregó 2.192 tokens por segundo.
Esa cifra final es aproximadamente un 41 por ciento superior al mayor rendimiento medido de BF16. Cloudflare también informa de un coste por token aproximadamente un 30 por ciento menor. La mejora procede de realizar más trabajo en el mismo despliegue, no de acelerar cada solicitud con poca carga.
Esta distinción evita un titular fácil pero engañoso. La cuantización introduce trabajo de conversión cuando el kernel de atención lee los valores almacenados en caché. Con la misma concurrencia, los resultados BF16 de Cloudflare siguieron siendo varios puntos porcentuales más rápidos.
La cuantización de la caché KV de Kimi solo se vuelve valiosa cuando los límites de memoria impiden que el formato más grande acepte más solicitudes. Intercambia una eficiencia moderadamente menor por solicitud por una capacidad total mucho mayor. Es una decisión razonable cuando la demanda se mantiene lo bastante alta como para aprovechar el espacio añadido.
Es menos valiosa cuando el tráfico es escaso. Un despliegue que atienda solo unas pocas solicitudes simultáneas absorbería la sobrecarga de conversión sin utilizar la capacidad adicional. Por tanto, el enfoque de Cloudflare depende de dirigir suficiente trabajo compatible hacia cada grupo de decodificación.
Aquí es donde la infraestructura global adquiere relevancia estratégica. Los grandes proveedores pueden agregar tráfico de muchos clientes y mantener ocupados aceleradores costosos. Los operadores más pequeños suelen enfrentarse a una demanda irregular, lo que les impide capturar las mismas mejoras de utilización.
Cloudflare ya utiliza afinidad de sesión y caché de prefijos en Workers AI. La caché de prefijos reutiliza el estado calculado de comienzos idénticos de prompts. Su lanzamiento de modelos grandes expuso el uso de tokens almacenados en caché e introdujo una cabecera de afinidad de sesión para mejorar el enrutamiento de caché.
La optimización más reciente aborda una capa diferente. La caché de prefijos evita trabajo repetido de prefill, mientras que FP8 amplía la capacidad de decodificación. La combinación de ambas puede reducir el cómputo duplicado y admitir más secuencias activas.
Cloudflare comparó la precisión en varias evaluaciones. En GSM8K, BF16 obtuvo 94,24 mientras que FP8 obtuvo 94,09. Los resultados de MMLU fueron 89,11 y 89,04, respectivamente.
La caché FP8 obtuvo 67,49 en ARC-Challenge, frente a 66,72 para BF16. En MMLU-Pro, FP8 registró 79,29 mientras que BF16 alcanzó 80,29. La validez de las llamadas a herramientas se midió en 92,6 por ciento para FP8 y 92,2 por ciento para BF16.
Cloudflare describe estos resultados como indistinguibles. Esa conclusión es plausible dentro del conjunto reportado, pero las puntuaciones no demuestran equivalencia universal. Pequeños cambios numéricos pueden afectar prompts poco frecuentes, trazas largas de agentes o tareas fuera de las evaluaciones seleccionadas.
Varias pruebas también producen resultados no deterministas. Una diferencia mínima de puntuación puede reflejar muestreo, ruido de evaluación o cuantización. Los lectores necesitarían ensayos repetidos e intervalos de confianza para separar esas causas.
El benchmark interno mcxams de la empresa produjo resultados idénticos: ambas configuraciones superaron 61 de 63 pruebas. Las evaluaciones internas pueden reflejar bien las necesidades de producción, pero los externos no pueden inspeccionar independientemente su cobertura.
Por tanto, la cuantización de la caché KV de Kimi debe juzgarse como un resultado operativo con evidencia de calidad alentadora. No es un hallazgo general de que todos los modelos puedan usar valores de caché FP8 de forma segura. Las distribuciones de atención y la sensibilidad numérica difieren entre arquitecturas.
El verdadero logro de Cloudflare es identificar dónde compensa el cambio de formato. El prefill sigue estando limitado por el cómputo, por lo que la empresa mantiene su caché en BF16. La decodificación pasa a estar limitada por la memoria, lo que hace útil la representación FP8 más pequeña con una mayor concurrencia.
Esa decisión respalda la tesis central. Una mejor inferencia no siempre significa que una solicitud se ejecute más rápido. A escala, a menudo significa completar más trabajo útil antes de que el hardware alcance su límite de memoria.
La verdadera competencia es la memoria por token útil
El alojamiento de modelos de frontera depende cada vez más de la eficiencia de memoria, y no solo de los recuentos de parámetros destacados.
Kimi K2.6 pertenece a una familia de modelos que combina grandes pesos almacenados con capacidades de contexto largo y agentes. La documentación actual del modelo de Cloudflare enumera una ventana de contexto de 262.144 tokens, entradas de visión, llamadas a herramientas y salidas estructuradas.
Esas capacidades generan demandas de memoria superpuestas. Los pesos del modelo deben seguir accesibles durante la generación. Cada conversación activa también construye una caché KV creciente, mientras que el procesamiento por lotes exige que el servidor rastree muchas secuencias simultáneamente.
Un modelo puede caber en la memoria GPU y aun así no ser rentable de servir. Si sus pesos dejan poco espacio para páginas de caché, cada despliegue admite menos usuarios activos. Los lotes inactivos o insuficientemente llenos desperdician entonces una costosa capacidad de aceleración.
Esta es la competencia que las representaciones más pequeñas de Cloudflare están diseñadas para cambiar. La métrica relevante pasa a ser los tokens útiles producidos por unidad de memoria, dentro de límites aceptables de latencia y calidad. La velocidad bruta con una sola solicitud revela solo una parte de ese sistema.
El cambio también presiona a los proveedores que dependen principalmente de pilas de inferencia estándar. Si dos servicios utilizan hardware y pesos de modelo similares, el proveedor con mejor gestión de caché puede aceptar más trabajo concurrente. También puede repartir los costes fijos de infraestructura entre más tokens generados.
Sin embargo, las mejoras de software no eliminan las diferencias de hardware. Las GPU H200 proporcionan una cantidad considerable de memoria de alto ancho de banda, mientras que los sistemas Blackwell más nuevos añaden distintas capacidades de baja precisión. Los resultados de una configuración de acelerador no se transferirán automáticamente a otra.
La forma del tráfico importa igual de mucho. Los agentes de programación pueden enviar prompts grandes, reutilizar prefijos, llamar a herramientas y continuar durante muchos turnos. Las sesiones de chat para consumidores pueden utilizar prompts más cortos y patrones de seguimiento menos previsibles.
Una carga de trabajo agéntica puede mantener una secuencia residente durante más tiempo. Eso aumenta el valor de la capacidad de caché, pero también dificulta la planificación. Una solicitud inusualmente larga puede ocupar memoria mientras esperan muchas solicitudes más pequeñas.
El diseño desagregado de prefill y decodificación de Cloudflare responde a este desequilibrio. La ingesta de prompts, intensiva en cómputo, se ejecuta en un grupo. La generación, sensible a la memoria, se ejecuta en otro, lo que permite que cada grupo escale y utilice distintos formatos numéricos.
Este diseño también introduce costes de coordinación. El estado de la caché debe trasladarse o permanecer accesible a través del límite entre fases. Las decisiones de enrutamiento deben tener en cuenta la memoria disponible, los prefijos existentes, la profundidad de la cola y la longitud prevista de cada respuesta.
El proyecto SGLang proporciona el marco de servicio utilizado en los experimentos y el tráfico de producción de Cloudflare. Cloudflare afirma que colabora con el proyecto para incorporar parches y funciones al código principal. Eso hace que algunas mejoras estén disponibles más allá de un único proveedor.
La infraestructura abierta puede reducir la brecha de software entre las grandes plataformas y los operadores independientes. Sin embargo, la experiencia de despliegue sigue siendo importante. Un kernel o una función de planificación publicados no proporcionan automáticamente el volumen de tráfico, la telemetría ni la planificación de capacidad de Cloudflare.
Esa diferencia hace que la presión competitiva sea indirecta. Cloudflare no presenta Kimi ni GLM como modelos exclusivos. Sostiene que su infraestructura puede operar modelos frontera de pesos abiertos con suficiente eficiencia para ofrecer acceso compartido y sin servidores.
Los desarrolladores de modelos también se benefician de este acuerdo. Moonshot AI y Z.ai pueden llegar a usuarios que no quieren aprovisionar clústeres multi-GPU. Un soporte de alojamiento más amplio puede aumentar la adopción y generar más comentarios sobre cargas de trabajo reales.
A cambio, el proveedor asume una responsabilidad más exigente. Debe preservar el comportamiento del modelo mientras transforma los formatos numéricos. También debe impedir que el estado de caché de un inquilino afecte la salida de otro.
Por tanto, los operadores más sólidos optimizarán conjuntamente tres variables: capacidad de memoria, calidad de salida y aislamiento. Mejorar solo dos crea un servicio inestable. Una mayor densidad sin aislamiento plantea preocupaciones de seguridad, mientras que la compresión sin pruebas de calidad entraña el riesgo de regresiones silenciosas.
Para los compradores, el liderazgo en benchmarks sigue siendo relevante, pero incompleto. Un modelo impresionante solo resulta útil cuando la capa de servicio ofrece una latencia predecible y llamadas a herramientas correctas. Las colas largas pueden eliminar el valor práctico de un modelo más potente.
Los desarrolladores también deben separar la calidad del modelo de la calidad del proveedor. El mismo checkpoint de Kimi o GLM puede comportarse de forma distinta entre hosts debido a la cuantización, los valores predeterminados de muestreo, las políticas de caché y el software de servicio.
Una evaluación de producción debe medir tareas completas, no respuestas aisladas. Entre las señales útiles se incluyen la validez de las llamadas a herramientas, las tasas de tiempo de espera, la consistencia en sesiones largas y la latencia bajo concurrencia realista. Estas métricas revelan si la optimización de memoria mejora realmente la aplicación.
La compresión de pesos de GLM modifica el equilibrio entre fases
La compresión de pesos de GLM acelera la decodificación porque unos pesos más pequeños reducen el tráfico de memoria, pero ralentiza la fase de prefill, intensiva en cómputo.
Cloudflare convirtió los pesos de GLM 5.2 de FP8 a INT4. Durante la decodificación, el sistema transmite repetidamente los pesos del modelo desde la memoria GPU de alto ancho de banda. Mover menos bytes puede generar cada token antes cuando el ancho de banda de memoria es el cuello de botella.
El resultado con baja concurrencia fue el más claro. Con una solicitud, FP8 generó 60 tokens por segundo, mientras que INT4 alcanzó 92. Esto representa una ganancia reportada del 55 por ciento.
Con ocho solicitudes simultáneas, el rendimiento aumentó de 425 a 513 tokens por segundo. La ganancia fue del 21 por ciento. Con dieciséis solicitudes, INT4 produjo 825 tokens por segundo, frente a 683 para FP8.
La mejora siguió siendo visible con mayor carga. INT4 alcanzó 1.267 tokens por segundo con 32 solicitudes, frente a 994 para FP8. Con 64 solicitudes, los resultados respectivos fueron 1.933 y 1.672.
La compresión de pesos de GLM no genera el mismo beneficio durante el prefill. Los pesos INT4 deben expandirse antes de la multiplicación de matrices. Cloudflare midió aproximadamente 8.660 tokens de prefill por segundo para INT4, frente a 10.160 para FP8.
Por tanto, usar INT4 en todas partes sacrificaría el rendimiento del procesamiento de prompts. Cloudflare mantiene FP8 para el prefill y asigna INT4 a la decodificación. La división preserva el formato con mejores resultados medidos para cada fase.
Este hallazgo coincide con el trabajo anterior de Cloudflare sobre compresión de pesos sin pérdida. Ese proyecto exploró múltiples rutas de ejecución porque los tamaños de lote y las formas de las matrices cambian el equilibrio entre descompresión y cómputo.
El enfoque actual de GLM utiliza cuantización con pérdida, en lugar de aquel método anterior sin pérdida. Convertir pesos FP8 a INT4 asigna más valores a menos estados representables. Las pruebas de precisión se vuelven esenciales porque los pesos originales no pueden reconstruirse exactamente.
Cloudflare informó de diferencias inferiores a 0,8 puntos en los benchmarks evaluados. MMLU promedió 86,60 para FP8 y 86,54 para INT4. Las puntuaciones exactas de MMLU-Pro fueron 80,80 y 80,47.
En precisión ARC-Challenge, FP8 registró 64,93 por ciento e INT4 registró 64,85 por ciento. Ambos formatos superaron 62 de 63 casos en el benchmark interno mcxams de Cloudflare.
GSM8K mostró una diferencia algo mayor. FP8 logró un 94,39 por ciento de coincidencia exacta, mientras que INT4 alcanzó un 93,56 por ciento. La puntuación flexible produjo un 94,24 y un 93,48 por ciento.
Cloudflare afirma que la calidad del modelo comprimido es indistinguible. Las cifras públicas respaldan una pequeña diferencia media, pero dejan abiertas varias preguntas. La empresa no publicó resultados para todos los comportamientos agénticos o multilingües.
GLM se utiliza habitualmente para programación, uso de herramientas y tareas multilingües. Los benchmarks académicos generales no capturan todos los modos de fallo en esos contextos. Un argumento de función mal formado puede importar más que un pequeño cambio en la precisión media.
Los fallos numéricos poco frecuentes son especialmente difíciles de detectar. Un benchmark puede mostrar una calidad agregada estable mientras un modelo comprimido cambia su comportamiento ante prompts inusuales. Las trazas de razonamiento largas pueden amplificar una diferencia temprana.
Eso no hace que INT4 sea inadecuado. Significa que las decisiones de despliegue requieren pruebas específicas de la carga de trabajo y monitorización continua. Los proveedores deben comparar la configuración exacta del modelo que reciben los usuarios, no solo un checkpoint de referencia.
La misma cautela se aplica a las afirmaciones sobre velocidad. Los tokens por segundo dependen de la longitud de entrada, la longitud de salida, el batching, el hardware, los kernels y la planificación. Las mediciones de Cloudflare describen su sistema probado, no un nivel universal de rendimiento de GLM.
Aun así, la división por fases ofrece una lección arquitectónica útil. La cuantización no debe tratarse como una decisión estática de exportación. Un proveedor puede mantener múltiples representaciones y dirigir el cómputo hacia el formato adecuado para cada etapa.
Esa flexibilidad tiene costes. Varios formatos de pesos consumen almacenamiento y complican el despliegue. Los ingenieros deben verificar la compatibilidad, seleccionar los kernels correctos y evitar la deriva de configuración entre los grupos de GPU.
La disciplina operativa determina si la complejidad compensa. Si una solicitud llega al grupo equivocado o una revisión del modelo cambia el comportamiento numérico, las ganancias teóricas de rendimiento importan poco. La automatización y la observabilidad pasan a formar parte de la propia optimización.
Los resultados reportados por Cloudflare muestran por qué los proveedores aceptan esa complejidad. Un checkpoint un 40 por ciento más pequeño deja memoria sustancial para secuencias activas. Una decodificación más rápida mejora entonces la latencia en el punto donde los usuarios ven llegar los tokens.
El equilibrio es concreto, no abstracto. La compresión de pesos de GLM compra capacidad y velocidad de decodificación a cambio de añadir riesgo numérico y sobrecarga de prefill. Cloudflare gestiona ese intercambio al aislar el formato en la fase donde resulta ventajoso.
La seguridad de la caché KV compartida se convierte en un problema de producción
Una mayor densidad de GPU incrementa el valor de cada página de caché, al tiempo que vuelve más peligroso un seguimiento de propiedad defectuoso.
La atención paginada divide el almacenamiento de la caché KV en bloques reutilizables, en lugar de requerir una asignación continua por solicitud. El batching continuo añade y elimina secuencias mientras una GPU permanece ocupada. En conjunto, estos métodos reducen el desperdicio de memoria.
También crean un exigente problema de contabilidad. Las páginas físicas de caché se asignan, leen, liberan y reasignan constantemente. El sistema de servicio debe preservar la correspondencia correcta entre cada secuencia lógica y sus páginas físicas.
Una asignación obsoleta podría hacer que una solicitud leyera una página incorrecta. Eso podría corromper la respuesta, bloquear la operación o exponer un estado asociado a otra secuencia. La consecuencia exacta depende del fallo y de los controles circundantes.
Cloudflare afirma que los errores muy poco frecuentes adquieren relevancia operativa con su volumen de solicitudes. Su artículo utiliza un error de uno entre mil millones como umbral ilustrativo. Esa afirmación describe la necesidad de una defensa, no una tasa de incidentes divulgada.
El mecanismo de integridad de la empresa asocia una etiqueta cambiante a cada página física. Una solicitud registra las etiquetas que espera. Las operaciones de decodificación compatibles validan esos valores antes de leer la caché compartida.
Una discrepancia de etiqueta cancela la solicitud afectada. Este diseño favorece un fallo explícito frente a devolver una salida basada en el estado equivocado. Se asemeja a los contadores de generación utilizados en otros sistemas de gestión de memoria.
Cloudflare evaluó la comprobación en un modelo de producción de tamaño medio utilizando dos workers de prefill y dos de decodificación. Las pruebas usaron entradas de 8.192 tokens y salidas de 1.000 tokens. La concurrencia reportada osciló entre una y ocho.
El rendimiento disminuyó entre un 0,38 y un 0,79 por ciento en esas pruebas. El aumento de latencia p95 osciló entre un 0,42 y un 0,80 por ciento. Cloudflare afirma que incluso el límite superior de confianza se mantuvo cerca del uno por ciento.
La empresa ejecuta la validación como una comprobación de lote independiente. Evitó fusionar la operación en el kernel de atención porque los grupos de hilos de la GPU podrían crear una condición de carrera. Sigue disponible un rastreador no operativo para los despliegues donde la comprobación está desactivada.
Estos resultados hacen que las comprobaciones de integridad parezcan económicas. Sin embargo, la evaluación no cubrió todos los tamaños de modelo, formas de secuencia ni niveles de concurrencia. También se centró en operaciones de decodificación compatibles, un matiz que merece atención.
Los lectores no deben interpretar el mecanismo como una prueba completa de aislamiento entre inquilinos. La integridad de la caché es una capa defensiva dentro de un sistema de servicio más amplio. El enrutamiento, la asignación de memoria, la corrección de los kernels y el aislamiento de procesos siguen siendo relevantes.
La comprobación puede detectar una discrepancia de generación de página que su rastreador comprende. No puede identificar automáticamente todos los errores numéricos o defectos de software. Una etiqueta válida no demuestra que el contenido de la página sea semánticamente correcto.
También existe una tensión entre el despliegue opcional y la protección universal. Cloudflare afirma que la comprobación de integridad se activa por despliegue. Su objetivo declarado es hacer que la función sea lo suficientemente económica como para dejarla activada en todas partes.
Hasta que eso ocurra, los clientes no pueden asumir que todas las rutas de modelo utilizan la misma protección. Una documentación clara sobre la cobertura ayudaría a los desarrolladores a evaluar el riesgo restante. Las pruebas de seguridad independientes aportarían evidencia más sólida que las mediciones de rendimiento por sí solas.
No obstante, el caso de seguridad refleja un cambio importante en la ingeniería de inferencia. Las funciones de rendimiento ahora requieren un razonamiento explícito sobre el estado entre solicitudes. La optimización de memoria ya no puede evaluarse únicamente mediante gráficos de rendimiento.
La compresión intensifica esa necesidad. Las cachés Kimi FP8 permiten mantener activas más solicitudes. Los pesos GLM INT4 crean más espacio para páginas de caché. Ambos cambios aumentan la cantidad de estado compartido que gestiona un despliegue.
Por tanto, el principal adversario en esta historia es la densidad insegura. El objetivo no es el empaquetado máximo a cualquier coste. Es una mayor utilización que preserve los límites entre solicitudes y un comportamiento aceptable del modelo.
El enfoque de Cloudflare sitúa la comprobación de seguridad cerca del recurso compartido. Eso puede detectar errores de asignación antes de que los datos almacenados en caché entren en una operación de atención. La terminación temprana también limita la propagación del estado corrupto.
Las solicitudes canceladas siguen afectando la fiabilidad. Si las comprobaciones empiezan a activarse con frecuencia, los usuarios verán errores o reintentos incluso cuando el aislamiento funcione según lo previsto. Los operadores deben seguir las tasas de discrepancia, investigar las causas y evitar tormentas de reintentos.
Cloudflare no ha divulgado una tasa de discrepancias en producción en el artículo. Esa métrica ausente importa más que la sobrecarga sintética por sí sola. Una comprobación de bajo coste es útil, pero su valor operativo queda más claro cuando informa de detecciones reales.
La empresa también tiene incentivos para presentar la nueva densidad como segura. Sus pruebas deben tratarse como una divulgación técnica del operador del sistema. Son informativas, pero no equivalen a una auditoría independiente.
Para los desarrolladores, la lección más amplia es práctica. La inferencia compartida oculta la complejidad de la infraestructura, pero no la elimina. Las evaluaciones de proveedores deberían incluir controles de aislamiento, gestión de fallos y transparencia sobre incidentes, junto con la latencia y la calidad del modelo.
Qué observar a medida que se extienden las optimizaciones
Tres señales mostrarán si el servicio de modelos más pequeños de Cloudflare se convierte en una ventaja duradera o sigue siendo una configuración especializada.
La primera señal es un despliegue más amplio de cachés FP8. Cloudflare afirma que está ampliando las cachés KV FP8 a una mayor parte de su flota. La cobertura en modelos y hardware adicionales demostraría que la cuantización de caché KV de Kimi se generaliza más allá de una configuración medida.
Las pruebas útiles incluirían datos de concurrencia, latencia de cola y calidad para distintas longitudes de secuencia. Resultados estables en esas dimensiones reforzarían el argumento de Cloudflare sobre la eficiencia de memoria. Excepciones frecuentes específicas de cada modelo lo debilitarían.
La segunda señal es la validación de NVFP4 en GPU Blackwell. NVFP4 es el formato de coma flotante de cuatro bits de Nvidia para hardware más reciente. Cloudflare afirma que está probando esa representación como otra vía hacia pesos más pequeños.
Un despliegue exitoso podría ampliar la compresión de pesos de GLM más allá de INT4 y volver a cambiar el equilibrio entre prefill y decode. También pondría a prueba si Cloudflare puede trasladar su estrategia consciente de las fases entre generaciones de aceleradores.
El resultado importante no es una única cifra máxima de rendimiento. Hay que observar la latencia de extremo a extremo, las evaluaciones de calidad y la capacidad de memoria con procesamiento por lotes en producción. Esas mediciones mostrarían si una menor precisión ofrece mejoras útiles a nivel de aplicación.
La tercera señal es una cobertura universal de integridad de caché. Cloudflare quiere habilitar comprobaciones en todas partes a un coste insignificante. Alcanzar ese objetivo conectaría una mayor densidad con un control de seguridad predeterminado y consistente.
Las divulgaciones de cobertura deberían identificar los modelos, operaciones y hardware compatibles. Las métricas de detección aportarían aún más valor, especialmente si Cloudflare explica con qué frecuencia se producen discrepancias y qué las provoca.
Estas señales importan porque las pruebas actuales de la empresa son sólidas, pero acotadas. Muestran mejoras significativas en modelos y despliegues seleccionados. No demuestran que todas las cargas de trabajo se beneficien de los mismos formatos.
Los desarrolladores deberían probar sistemas Kimi y GLM alojados utilizando prompts, cadenas de herramientas y concurrencia realistas. Deben seguir el tiempo hasta el primer token, la velocidad de generación, las tasas de tiempo de espera y el éxito de las tareas completas. También deberían comparar el comportamiento después de actualizaciones de modelos realizadas por el proveedor.
Los equipos también deberían conservar su propio historial de evaluaciones. Una base de conocimientos de ingeniería con capacidad de búsqueda puede conectar resultados de benchmarks, incidentes, cambios de configuración y anuncios de proveedores. Ese contexto ayuda a distinguir una regresión del modelo de un cambio de infraestructura.
Cloudflare ha alejado el debate sobre los modelos de frontera de la simple disponibilidad. La pregunta más difícil es si un proveedor puede mantener modelos grandes rápidos, económicos, precisos y aislados bajo concurrencia real. Observe las tres señales de despliegue y, después, evalúe el sistema mediante cargas de trabajo completas en lugar de un solo benchmark o gráfico de rendimiento.
