Cloudflare опублікувала докладний звіт про інцидент, в якому описується, як помилка обробки кешу на безсерверній платформі штучного інтелекту призвела до того, що принаймні 155 користувачів розгортання моделі GLM-5.3 отримували відповіді, що містили фрагменти підказок і вихідних даних інших клієнтів. Звіт, опублікований 26 жовтня як скоординоване розкриття інформації разом із проектом механізму висновку з відкритим кодом SGLang, пропонує рідкісний публічний погляд на систему багатокористувацького обслуговування LLM — і попередження про припущення щодо безпеки пам’яті GPU.
Як було виявлено витік For more context on this story, see our ongoing AI news.
За даними Cloudflare, дослідник безпеки Гаді Еврон з Knostic попередив компанію 8 вересня 2026 року через програму винагороди за помилки HackerOne. Evron повідомив, що дуже довгі підказки, надіслані моделі GLM-5.3 на платформі Workers AI Cloudflare, іноді повертали текст, який належав сесіям інших користувачів. Cloudflare відтворив проблему наступного ранку та вимкнув модель того ж дня, відновивши її 9 вересня після розгортання виправлень.
Постраждала модель @cf/zai-org/glm-5.3 — модель агентського кодування від Z.ai, яку Cloudflare обслуговує через Workers AI, безсерверну платформу висновків компанії. Cloudflare підтвердив, що жодна інша модель, розміщена на платформі, не постраждала.
Що сталося насправді
Цей інцидент пов’язаний з двома проблемами, що збігаються, одна – операційна, а друга – у самому двигуні.
По-перше, неправильна конфігурація. Cloudflare розгорнув GLM-5.3 із контекстним вікном із 1 048 576 токенів, але в кеш-пулі ключ-значення (KV) на її графічних процесорах попереднього заповнення було місце лише для 681 280 токенів. Компанія визнала, що знала про цю невідповідність перед запуском і очікувала, що механізм логічного висновку безпечно відхилятиме запити надмірної довжини.
По-друге, помилка двигуна. У режимі дезагрегованого попереднього заповнення/декодування — архітектурі, яку використовує Workers AI, у якому один пул графічних процесорів обробляє запит і передає отриманий кеш KV в окремий пул графічних процесорів, які генерують відповідь — SGLang неправильно обробив запит на надмірну довжину. Підказка, яка не відповідала пулу, була внутрішньо позначена як відхилена та замінена заповнювачем з одним маркером. Але замість того, щоб переривати запит і повертати клієнтську помилку, етап попереднього заповнення генерував кеш KV для підказки-заповнювача та передавав його до вузла декодування, який потім виробляв відповідь, яка змішувала залишки даних із попередніх запитів, які спільно використовували ті самі сторінки пам’яті.
Результат: у період з 27 серпня по 9 вересня невелика кількість клієнтів, які використовували модель, отримали відповіді, що містили дані із запитів інших клієнтів, зроблених незадовго до їхнього. Загалом це вплинуло на 155 відповідей — усі, як виявив Cloudflare, на запити, довші за 681 280 токенів.
Немає доказів навмисної експлуатації
Cloudflare заявила, що після виключення власного тестування та запитів дослідника на перевірку, уражені запити відповідали за часом і обсягом звичайному довгоконтекстному використанню, і компанія не знайшла доказів того, що хтось навмисно використовував помилку. Оскільки кожен відповідний запит перевищував місткість малогабаритного пулу, вікно експонування було жорстко обмеженим — срібна підкладка, яка походить від тієї самої неправильної конфігурації, яка спричинила проблему.
Виправлення: більші пули та безпечніший шлях до відмови
Усунення працювало на обох шарах несправності. Cloudflare переконфігурував розгортання GLM-5.3 відповідно до конфігурації GLM-5.2, звільнивши достатньо пам’яті графічного процесора, щоб попередньо заповнений пул KV тепер містив близько 2,04 мільйона токенів — це приблизно вдвічі більше, ніж довжина контексту моделі з 1 048 576 токенів. Підказка, яка відповідає контекстному вікну, тепер завжди відповідає пулу.
Але компанія також підкреслила, що покладатися лише на розмір пулу є крихким: зміни квантування, тензорного паралелізму, розмірів графів CUDA або майбутньої версії моделі можуть мовчки змінити розмір пулу. Таким чином, він також виправив сам шлях відхилення SGLang, гарантуючи, що відхилений запит буде перервано чисто замість генерації та передачі кешу для заповнювача. Обидві зміни було перевірено на відповідність сценарію відтворення дослідника та власним тестам маркерів канарки Cloudflare, перш ніж модель було відновлено, а виправлення були надіслані розробникам підтримки SGLang.
Чому спільна пам'ять GPU є секретним питанням
У звіті пояснюється практика, яка здивує багатьох розробників додатків: механізми логічного висновку зазвичай не обнуляють сторінки кешу KV між запитами, тому що наступний запит просто перезаписує їх. Це навмисний компроміс продуктивності, поширений у механізмах логічного висновку, але, як показує цей випадок, будь-який шлях, який дозволяє згенерувати відповідь до того, як ці сторінки буде повністю перезаписано, перетворює оптимізацію продуктивності на вектор витоку даних.
Спільнота розробників оприлюднила цю інформацію: історія досягла 123 пунктів на Hacker News за кілька годин, а обговорення зосереджувалося на тому, як режим відмови — запит, який повинен був голосно провалитися, замість того, щоб мовчазно продовжуватись у пошкодженому стані — відображає класичні уроки розробки розподілених систем.
Більш широкий урок для інфраструктури ШІ
Інцидент є нагадуванням про те, що периметр безпеки для додатків AI тепер поширюється глибоко в інфраструктуру висновків. Обслуговування моделі з декількома клієнтами концентрує дані багатьох клієнтів за допомогою спільних прискорювачів, спільних пулів кешу та все більш екзотичних архітектур, як-от дезагрегованого попереднього заповнення та віддаленого прямого доступу до пам’яті. Незначної невідповідності між рекламованим вікном контексту моделі та фізичною потужністю, наданою для її обслуговування, було достатньо, щоб порушити ізоляцію клієнта.
Для підприємств, які створюють безсерверні платформи штучного інтелекту, висновок зі звіту Cloudflare подвійний: помилки ізоляції клієнта в обслуговуванні LLM реальні та вже мали місце у виробництві, а час відповіді постачальників — менше 24 годин від звіту до вимкнення, один день для виправлення та відновлення — є стандартом старанності вимагати від будь-якого постачальника, який обробляє конфіденційні запити.
---
Stay Ahead of AIGet the latest AI news, analysis, and breakthroughs — all in one place.
Read more AI news →
