Un écart de configuration visible dans les journaux a fait fuiter 155 réponses d'IA

L'avertissement était affiché au démarrage

Le 26 octobre, Cloudflare a publié son rapport sur une défaillance d'isolation entre locataires dans le modèle GLM-5.3 sur Workers AI. Entre le 27 août et le 9 septembre, 155 réponses à des prompts de plus de 681 280 tokens contenaient des données issues des requêtes d'autres clients. Cloudflare affirme que le calendrier et le volume des requêtes concernées sont cohérents avec un usage ordinaire en contexte long, et qu'elle n'a trouvé aucune preuve d'exploitation délibérée. Le chercheur en sécurité Gadi Evron, de Knostic, a signalé le problème le 8 septembre ; Cloudflare a mis le modèle hors ligne dans les 40 minutes suivant la déclaration de l'incident et l'a rétabli le 9 septembre.

Le détail qui mérite qu'on s'y arrête : Cloudflare affirme avoir eu connaissance de l'écart avant le lancement. Le modèle était configuré pour une fenêtre de contexte de 1 048 576 tokens, mais le pool de mémoire de ses GPU de prefill ne pouvait contenir que 681 280 tokens. Le moteur affiche la taille de ce pool au démarrage et l'expose sous forme de métrique. L'équipe avait supposé que les prompts trop volumineux renverraient simplement une erreur.

Comment un pool de mémoire partagé fuit

Lorsqu'un modèle de langage lit votre prompt, il stocke des résultats intermédiaires, le cache KV, dans la mémoire du GPU. Cette mémoire est un pool partagé de pages de taille fixe. Une requête se voit attribuer des pages lorsqu'elle est admise et les libère lorsqu'elle est terminée. Cloudflare indique que les pages ne sont pas remises à zéro entre deux requêtes, ce qui est courant parmi les moteurs d'inférence, car les effacer coûte en performances. Le moteur doit donc suivre qui possède chaque page.

Cloudflare sert GLM-5.3 selon une architecture scindée : les GPU de prefill traitent le prompt et construisent le cache, puis le transmettent à des GPU de decode distincts qui génèrent la réponse. Côté decode, les pages sont réservées en fonction de la longueur du prompt.

C'est ici que le moteur d'inférence SGLang a failli. Un prompt trop volumineux pour le pool était marqué comme rejeté et remplacé par un espace réservé d'un seul token. Mais les contrôles d'admission en mode désagrégé demandaient si une requête était terminée, et non si elle était rejetée : la requête rejetée est donc passée sans encombre. Le prefill a écrit une page et signalé l'achèvement. Le decode, qui avait réservé huit pages dans l'exemple de la source, a supposé que les huit venaient d'être écrites et a appliqué son attention sur les sept autres, qui contenaient encore les données d'utilisateurs précédents. Le client a reçu un HTTP 200 et une réponse cohérente.

Pourquoi les tests n'ont rien détecté

Cloudflare indique que ses tests de contexte long avant lancement vérifiaient les codes de statut HTTP et les performances, pas la cohérence des sorties. Les codes de succès avaient l'air de prouver que le moteur gérait l'écart. Voilà le signal : la défaillance n'a produit ni erreur, ni plantage, et le texte restait plausible. Le seul symptôme était que les réponses arrivaient plus vite qu'un prefill complet ne le devrait.

C'était aussi un bogue déjà connu en amont. Un autre utilisateur de SGLang l'avait signalé sous le numéro #30233 le 6 juillet, avant l'ouverture de la fenêtre de fuite, et Cloudflare affirme avoir signalé des problèmes similaires depuis la v0.5.10. Le correctif est paru dans la v0.5.20, avec des suites dans les v0.5.21 et v0.5.22 ; Cloudflare recommande aux opérateurs de passer à la v0.5.22 ou à une version ultérieure.

Le schéma plus large

L'inférence multi-locataire dépend désormais de moteurs open source qui évoluent plus vite que leurs contrôles de sécurité. La taille du pool est fixée au démarrage à partir de la mémoire GPU restante, tandis que la longueur de contexte est un réglage distinct et, selon les mots de Cloudflare, rien n'oblige les deux à concorder. La propriété des pages mémoire est partagée entre des machines reliées par RDMA, le transfert direct de mémoire entre nœuds. Cloudflare affirme que seul GLM-5.3 a été touché, parce que ses autres déploiements désagrégés disposent de pools plus grands que leurs fenêtres de contexte. C'est une marge de configuration, pas une garantie d'architecture, et Cloudflare qualifie elle-même de fragile le fait de s'en remettre à la seule taille du pool.

Les questions à vous poser

• Votre fournisseur d'inférence vérifie-t-il, à partir du moteur en cours d'exécution, que la capacité du cache couvre la longueur de contexte annoncée avant chaque changement de déploiement ?
• Ses tests avant lancement examinent-ils la cohérence des sorties et la présence de contenu étranger, ou seulement les codes de statut et la latence ?
• Lorsqu'un moteur en amont a un rapport de bogue ouvert touchant l'isolation, quel est le processus pour le faire remonter avant le lancement ?
• Si vos prompts ont dépassé le seuil de 681 280 tokens sur ce modèle entre le 27 août et le 9 septembre, le fournisseur a-t-il confirmé si vos données figuraient parmi les 155 réponses ?
• Lesquels de vos moteurs auto-hébergés fonctionnent en mode désagrégé, et sont-ils sur une version corrigée ?

Ce qu'il faut surveiller ensuite

Surveillez si d'autres fournisseurs d'inférence et utilisateurs de SGLang publient leurs propres audits pool contre contexte, et si les suites en amont citées par Cloudflare, dont #38704, sont intégrées dans des versions publiées. Le révélateur sera de savoir si les contrôles de capacité deviennent un point de passage standard du déploiement chez tous les fournisseurs, ou s'ils restent le correctif post-incident d'une seule entreprise.