Análisis en profundidad · Unos 6 min de lectura
Cloudflare explica el incidente de aislamiento de caché de GLM-5.3 y los límites de una respuesta exitosa
La divulgación del 26 de octubre distingue la exposición de agosto y septiembre de las correcciones y del trabajo de integridad aún pendiente.
- Publicado aquí
- Fecha de la fuente
- Fuente revisada
Cloudflare publicó el 26 de octubre un informe sobre datos de unas solicitudes que aparecieron en otras en su despliegue de GLM-5.3 en Workers AI. Atribuye el incidente a una diferencia de capacidad y a un fallo de rechazo de SGLang. Describe un servicio reparado el 9 de septiembre, no una nueva avería ni un defecto demostrado en todos los despliegues del modelo.
Escucha las noticias
Escucha este artículo o continúa con las noticias.
Preparando la lectura…
Voz del dispositivo
El navegador o dispositivo procesa la voz. AISubHub no envía el texto a una API de audio. Las voces y la reproducción con pantalla bloqueada dependen del dispositivo.
Al continuar puede repetirse una frase breve.
Resumen
- Cloudflare informa de 155 respuestas afectadas entre el 27 de agosto y el 9 de septiembre, todas para prompts de más de 681 280 tokens. No son 155 clientes.
- El contexto anunciado era de 1 048 576 tokens y el pool de prefill admitía 681 280. Tras la corrección admite unos 2,04 millones; también se reparó la ruta de rechazo.
- La empresa recomienda SGLang v0.5.22 o posterior para despliegues desagregados. La detección depende de la arquitectura y el trabajo de integridad no constituye una garantía universal.
La fecha de divulgación no es la del incidente
Cloudflare sitúa la exposición entre el lanzamiento en Workers AI, el 27 de agosto, y el 9 de septiembre. Gadi Evron, de Knostic, informó del problema el 8 de septiembre. El día 9 se declaró el incidente a las 13:22 UTC, se restringió el modelo a las 14:00 y se restableció el acceso público a las 19:40 tras cambios y validación. El 26 de octubre corresponde a la publicación coordinada.
La empresa identifica 155 respuestas con datos de solicitudes recientes de otros clientes al mismo modelo. Excluidas sus pruebas y las del investigador, considera que el volumen y los tiempos coincidían con un uso normal de contexto largo, sin indicios de explotación deliberada. Eso no prueba que nunca hubiera abuso. También afirma que no resultaron afectados otros modelos de Workers AI.
La ventana anunciada superaba la capacidad física
En este despliegue, las GPU de prefill procesaban el prompt y pasaban la caché de claves y valores mediante Mooncake y RDMA a las GPU de decode. SGLang calculaba el tamaño del pool con la memoria restante tras cargar los pesos; el límite de contexto se configuraba por separado. Así coexistían un contexto de 1 048 576 tokens y un pool de solo 681 280.
Cloudflare reconoce que conocía la diferencia antes del lanzamiento, pero esperaba un rechazo seguro porque las pruebas devolvían respuestas exitosas. El informe admite una carencia: se comprobaron estados HTTP y rendimiento sin validar adecuadamente la salida. La explicación describe una interacción entre configuración y motor; no aporta pruebas de una puerta trasera en los pesos del modelo.
Un rechazo pendiente siguió pareciendo una solicitud activa
El planificador marcaba la solicitud excesiva para rechazo y sustituía su prompt por un marcador de un token. Sin embargo, la admisión desagregada comprobaba si la solicitud había terminado, no si estaba rechazada. El error pendiente no satisfacía esa condición. Ambos extremos aceptaban una solicitud que debía finalizar con error.
El diagrama ilustra ocho páginas reservadas: la solicitud nueva escribía una, mientras decode podía leerla junto con siete páginas antiguas. Son cantidades explicativas, no estadísticas del incidente. El cliente podía recibir HTTP 200, un recuento de tokens plausible y texto coherente que incluía material anterior. Entregar una respuesta no demostraba aislamiento correcto.
La reparación inmediata actuó en dos capas
Cloudflare dice que cambió la configuración para disponer de aproximadamente 2,04 millones de tokens en prefill, por encima del contexto de 1 048 576. También hizo que el rechazo pendiente terminara en admisión, antes de asignar o transferir caché, y validó ambas medidas antes de reabrir. Ampliar únicamente el pool dejaría una dependencia frágil de futuras opciones de memoria.
La tabla distingue la corrección inicial en v0.5.20, el rechazo anticipado en v0.5.21 y mejoras hasta v0.5.22. La recomendación para operadores desagregados es v0.5.22 o posterior, o aplicar los parches correspondientes. Se refiere a ese modo de servicio y esas correcciones, no a una comparativa de rendimiento ni a seguridad automática por instalar una versión.
Las escrituras en tránsito complican la vida de las páginas
El informe explica otra clase de fallo: abortar una solicitud no retira escrituras RDMA ya enviadas. Si se reutilizan páginas demasiado pronto, una escritura tardía puede corromper otra solicitud. A diferencia de esa carrera temporal, el rechazo de este incidente seguía de forma determinista la ruta equivocada. Ambos casos exigen conservar la propiedad hasta que terminen todas las operaciones participantes.
Cloudflare describe liberación diferida en ambos roles, lotes Mooncake acotados, cambios de desconexión en el balanceador y verificaciones de despliegue. Recomienda medir los pools reales tras cambios de pesos, cuantización o paralelismo. Checksum y KV Canary no cubren todas las arquitecturas; hay que comprobar la cobertura, no suponer que una opción habilitada verifica cada solicitud.
La garantía de integridad a largo plazo sigue pendiente
Cloudflare probó en agosto un prototipo de etiquetas de página en GLM-5.2. Informa de un coste inferior al 1% en rendimiento y latencia de cola, pero lo desactivó poco después por problemas de fiabilidad. El dato describe un experimento limitado, no una protección activa ni una medición general. Borrar las páginas al liberarlas todavía figura como propuesta preliminar.
Un checksum valida la transferencia; comprobar la propiedad de las páginas extendería la validación a lecturas posteriores. Cloudflare también planea modelar formalmente el protocolo distribuido y reconoce límites de las demostraciones. Análisis de AISubHub: aislamiento, rechazo y ciclo de vida requieren comprobaciones separadas, distinguiendo medidas implantadas, prototipos y garantías futuras.
Por qué importa
Análisis de AISubHub: el aislamiento entre clientes necesita criterios de aceptación propios. Los códigos de estado, el recuento de tokens y la velocidad pueden parecer correctos aunque falle la propiedad de la memoria; las pruebas de errores y de configuración responden a preguntas diferentes de un benchmark.
Límites y disponibilidad
El alcance, la reparación y la ausencia de indicios de explotación deliberada proceden del relato de Cloudflare. AISubHub no ha auditado el servicio ni los parches. No se demuestra que todos los despliegues GLM resultaran afectados ni que cualquier configuración SGLang sea inmune a errores de caché.
Fuentes y pruebas
Fecha de la fuente: · Fuente revisada:
Contenido editorial asistido por IA y contrastado con fuentes primarias. Las afirmaciones del proveedor se atribuyen; la inclusión no implica recomendación.