Cloudflare ha publicado un informe sobre un problema de aislamiento de inquilinos (tenant isolation) que afectó al modelo GLM‑5.3 alojado en Workers AI y que permitió que respuestas a ciertas solicitudes incluyeran datos de peticiones previas de otros clientes. La compañía atribuye la causa a una combinación de una descoordinación de configuración y un fallo en el motor de inferencia SGLang.
Qué ocurrió y por qué sucedió
El fallo se produjo cuando solicitudes con contextos extremadamente largos —más de 681.280 tokens— fueron procesadas por una configuración en la que la ventana de contexto anunciada del modelo (1.048.576 tokens) no encajaba con el tamaño del pool de caché KV disponible en las GPUs de prefill (681.280 tokens). SGLang, en su modo disgregado de prefill/decodificación, marcó internamente como rechazadas las solicitudes que excedían la capacidad del pool y las sustituyó por un marcador de un token.
En lugar de abortar y devolver un error al cliente, el componente de prefill generó una caché KV correspondiente al marcador y transfirió esa estructura al nodo de decode. Allí la transferencia fue interpretada como completa y el nodo de decode asumió que la caché había sido sobrescrita íntegramente, cuando en realidad quedaba la mayor parte del estado previo sin reemplazar. Al generar la respuesta, el decode atendió sobre páginas de caché que contenían datos residuales de solicitudes anteriores, provocando la mezcla de contenido entre peticiones de distintos clientes.
Alcance y comprobaciones
Cloudflare recibió el informe de un investigador de seguridad el 8 de septiembre y reprodujo el problema al día siguiente, retirando el modelo afectado en menos de 40 minutos tras declarar el incidente. Entre el 27 de agosto y el 9 de septiembre se identificaron 155 respuestas afectadas; todas correspondían a prompts más largos del umbral citado. Tras investigar, la compañía no encontró indicios de explotación deliberada y señaló que los patrones de las solicitudes encajan con un uso legítimo de contextos largos.
Medidas tomadas y correcciones
- Ajuste de configuración: Cloudflare modificó la configuración de GLM‑5.3 para que el pool de KV en las GPUs de prefill tenga capacidad suficiente para alojar el contexto anunciado por el modelo. Con ello, una petición que entre en la ventana de contexto del modelo también cabe en el pool, evitando la ruta de rechazo que desencadenaba el fallo.
- Parche en SGLang: además de la corrección de la configuración, se introdujeron cambios en el motor de inferencia para hacer segura la ruta de rechazo. Es decir, las solicitudes que deban rechazarse ahora se retiran en la cola de admisión antes de cualquier asignación o transferencia de KV, devolviendo inmediatamente el error correspondiente. También se añadió verificación en el nodo de decode para confirmar que el número de tokens transferidos coincide con lo reservado.
Cloudflare validó ambas soluciones contra el script de reproducción proporcionado por el investigador y mediante pruebas internas antes de restaurar el modelo.
Qué significa para administradores y dueños de sitios
Para operadores de infraestructuras y administradores de modelos alojados en plataformas gestionadas: este evento subraya la necesidad de comprobar la coherencia entre la configuración de contexto del modelo y los recursos reales de la infraestructura (como la memoria destinada al KV cache). Las inconsistencias pueden no manifestarse en pruebas básicas y solo aparecer con cargas o contextos extremos.
Acciones prácticas recomendadas:
- Supervisar métricas y logs que expongan el tamaño del pool de KV y alertar si difieren de la ventana de contexto esperada.
- Incluir pruebas con prompts muy largos en los planes de validación antes de desplegar modelos con contextos ampliados.
- Aplicar actualizaciones y parches en motores de inferencia (como SGLang) que añadan comprobaciones de integridad en rutas de rechazo y verificación de tokens transferidos.
Coordinación con el proyecto upstream
Cloudflare publicó su informe de manera coordinada con un post del equipo de SGLang y colaboró con los mantenedores upstream para incorporar las correcciones y endurecimientos. La compañía recuerda que el tamaño del pool en SGLang se calcula en tiempo de arranque a partir de la memoria GPU disponible y que nada obliga a que esa cifra coincida con la longitud de contexto anunciada del modelo, por lo que es responsabilidad del desplegador verificar esa correspondencia.
Lee también:
- ASRock lanza la Creator Radeon AI Pro R9700: tarjeta de workstation para inferencia local con 32 GB
- Ecoblox y Rimac colaboran para integrar baterías automotrices en centros de datos modulares
Fuente: Cloudflare Blog
