Analyse approfondie · Environ 6 min de lecture
Cloudflare analyse l’incident d’isolation du cache de GLM-5.3 et les limites d’une réponse réussie
La publication du 26 octobre distingue l’exposition d’août et septembre des corrections et des protections d’intégrité encore inachevées.
- Publié ici
- Date de la source
- Source vérifiée
Cloudflare a publié le 26 octobre un compte rendu d’exposition de données entre requêtes dans son déploiement GLM-5.3 sur Workers AI. L’entreprise l’attribue à un écart de capacité associé à un défaut de gestion des rejets dans SGLang. Le service a été rétabli le 9 septembre : il ne s’agit ni d’une nouvelle panne ni d’un défaut démontré dans tous les déploiements du modèle.
Écouter les actualités
Écoutez cet article ou poursuivez la lecture des actualités.
Préparation de la lecture…
Voix de l’appareil
La voix est traitée par votre navigateur ou appareil. AISubHub n’envoie pas le texte à une API audio. Les voix et la lecture écran verrouillé dépendent de l’appareil.
La reprise peut répéter une courte phrase.
En bref
- Cloudflare rapporte 155 réponses affectées entre le 27 août et le 9 septembre, toutes pour des prompts dépassant 681 280 tokens. Il s’agit de réponses, pas de clients.
- Le contexte annoncé était de 1 048 576 tokens, contre 681 280 pour le pool de préremplissage. Le pool corrigé atteint environ 2,04 millions ; le chemin de rejet a aussi été réparé.
- L’entreprise recommande SGLang v0.5.22 ou ultérieur aux exploitants désagrégés. La détection dépend de l’architecture et les travaux futurs ne constituent pas une garantie universelle.
La divulgation est postérieure à l’incident
Cloudflare situe l’exposition entre le lancement sur Workers AI le 27 août et le 9 septembre. Gadi Evron, de Knostic, a signalé le problème le 8 septembre. Le lendemain, l’incident a été déclaré à 13:22 UTC, le modèle restreint à 14:00 et le service public rétabli à 19:40 après modifications et validation. Le 26 octobre est la date de publication coordonnée.
L’entreprise identifie 155 réponses contenant des éléments de requêtes récentes d’autres clients au même modèle. Hors ses propres tests et ceux du chercheur, elle juge les horaires et volumes compatibles avec un usage ordinaire de longs contextes, sans indice d’exploitation délibérée. Cela ne démontre pas qu’aucun abus n’a eu lieu. Elle affirme aussi que les autres modèles Workers AI étaient épargnés.
Le contexte annoncé dépassait le pool physique
Les GPU de préremplissage traitaient le prompt puis transmettaient le cache clés-valeurs via Mooncake et RDMA aux GPU de décodage. SGLang dimensionnait le pool avec la mémoire restante après chargement des poids. La limite de contexte étant indépendante, une fenêtre de 1 048 576 tokens coexistait avec un pool limité à 681 280.
Cloudflare reconnaît avoir connu cet écart avant le lancement, mais avoir supposé un rejet sûr parce que les essais de longs contextes réussissaient. Le rapport admet que les états HTTP et les performances ont été vérifiés sans validation suffisante du contenu produit. Il décrit une interaction configuration-moteur, sans apporter de preuve d’une porte dérobée dans les poids du modèle.
Un rejet en attente restait une requête active
L’ordonnanceur marquait une requête trop grande pour rejet et remplaçait son prompt par un substitut d’un token. En mode désagrégé, l’admission vérifiait si la requête était terminée, et non rejetée. L’erreur en attente ne satisfaisait pas ce test. Les deux côtés acceptaient donc une requête qui aurait dû se terminer en erreur.
Le schéma représente huit pages réservées : la nouvelle requête en écrivait une, mais le décodeur pouvait aussi lire sept pages anciennes. Ces nombres sont illustratifs, pas des statistiques d’incident. Le client pouvait recevoir HTTP 200, un comptage plausible et un texte cohérent comprenant des données antérieures. La réussite de la réponse ne prouvait pas l’isolation.
La réparation immédiate comportait deux niveaux
Cloudflare indique avoir porté le pool de préremplissage à environ 2,04 millions de tokens, au-delà des 1 048 576 du contexte. Le moteur termine aussi les rejets en attente dès l’admission, avant allocation ou transfert de cache. Les deux changements auraient été validés avant réouverture. Agrandir le pool seul laisserait une dépendance fragile aux réglages mémoire ultérieurs.
Le tableau distingue un premier correctif en v0.5.20, un rejet plus précoce en v0.5.21 et des renforcements jusqu’à v0.5.22. Cloudflare conseille v0.5.22 ou ultérieur, ou les rétroportages adaptés, aux exploitants désagrégés. Cette recommandation concerne ce mode de service et ces correctifs ; ce n’est ni une comparaison de performances ni une sécurité automatique attachée au numéro de version.
Les écritures en vol compliquent la durée de vie
Le rapport décrit une autre famille de défauts : interrompre une requête ne rappelle pas les écritures RDMA déjà envoyées. Réaffecter les pages trop tôt permet à des écritures tardives de corrompre une autre requête. Contrairement à cette course temporelle, le rejet de cet incident suivait systématiquement le mauvais chemin. Les deux cas exigent de conserver la propriété jusqu’à la fin des opérations participantes.
Cloudflare décrit libération différée des deux côtés, lots Mooncake bornés, traitement des déconnexions modifié et contrôles de déploiement. Elle recommande de mesurer les pools réels après changements de poids, quantification ou parallélisme. Checksum et KV Canary ne couvrent pas toutes les architectures ; il faut vérifier la couverture plutôt que supposer qu’une option activée examine chaque requête.
Les protections d’intégrité futures restent inachevées
Un prototype d’étiquettes de pages a été testé sur GLM-5.2 en août. Cloudflare rapporte moins de 1% de coût en débit et latence de queue, mais l’a désactivé peu après pour des problèmes de fiabilité. Ce résultat concerne une expérience limitée, pas une protection actuellement déployée ni un coût général. L’effacement des pages à leur libération reste une proposition préliminaire.
Les checksums vérifient le transfert ; contrôler la propriété des pages étendrait la validation aux lectures ultérieures. Cloudflare prévoit aussi une modélisation formelle du protocole distribué tout en reconnaissant les limites des preuves. Analyse AISubHub : isolation, rejet et cycle de vie nécessitent des validations distinctes, avec une séparation claire entre protections déployées, prototypes et garanties futures.
Pourquoi cela compte
Analyse AISubHub : l’isolation des locataires doit avoir ses propres critères de recette. Codes HTTP, comptage des tokens et vitesse peuvent sembler corrects malgré une erreur de propriété mémoire ; contrôler la configuration et les chemins d’échec ne remplace pas un benchmark, et réciproquement.
Limites et disponibilité
Le périmètre, la correction et l’absence d’indices d’exploitation délibérée relèvent du compte rendu de Cloudflare. AISubHub n’a audité ni le service ni les correctifs. Le rapport ne prouve pas que tous les déploiements GLM étaient touchés, ni que toute configuration SGLang est désormais exempte d’erreurs de cache.
Sources et preuves
Date de la source: · Source vérifiée:
Articles assistés par IA, vérifiés avec les sources primaires citées. Les affirmations des fournisseurs sont attribuées ; la présence ne vaut pas recommandation.