Cloudflare опубликовала подробный отчет об инциденте, описывающий, как ошибка обработки кэша в ее бессерверной платформе искусственного интеллекта привела к тому, что по меньшей мере 155 пользователей развертывания модели GLM-5.3 получили ответы, содержащие фрагменты подсказок и выходных данных других клиентов. Отчет, опубликованный 26 октября в качестве скоординированного раскрытия информации вместе с проектом механизма вывода с открытым исходным кодом SGLang, предлагает редкий публичный взгляд на систему многопользовательского обслуживания LLM — и предупреждение о предположениях безопасности памяти графического процессора.
Как была обнаружена утечка Подробнее об этой истории — в нашем новости об ИИ.
По данным Cloudflare, исследователь безопасности Гади Эврон из Knostic предупредил компанию 8 сентября 2026 года через программу вознаграждений за обнаружение ошибок HackerOne. Evron сообщил, что очень длинные запросы, отправленные в модель GLM-5.3 на платформе Cloudflare Workers AI, иногда возвращали текст, принадлежащий сеансам других пользователей. 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.
Почему общая память графического процессора является секретным вопросом
В отчете объясняется практика, которая удивит многих разработчиков приложений: механизмы вывода обычно не обнуляют страницы кэша KV между запросами, потому что следующий запрос просто перезаписывает их. Это преднамеренный компромисс с производительностью, общий для всех механизмов вывода, но, как показывает этот инцидент, любой путь, позволяющий сгенерировать ответ до того, как эти страницы будут полностью перезаписаны, превращает оптимизацию производительности в вектор утечки данных.
Раскрытие информации дошло до сообщества разработчиков: за считанные часы история набрала 123 балла на Hacker News, при этом обсуждение было сосредоточено на том, как режим сбоя — запрос, который должен был громко завершиться неудачей, а не тихо продолжаться в поврежденном состоянии — отражает классические уроки проектирования распределенных систем.
Более широкий урок для инфраструктуры искусственного интеллекта
Этот инцидент является напоминанием о том, что периметр безопасности приложений ИИ теперь простирается глубоко в инфраструктуру вывода. Мультитенантная модель обслуживания концентрирует данные многих клиентов с помощью общих ускорителей, общих пулов кэша и все более экзотических архитектур, таких как дезагрегированное предварительное заполнение и удаленный прямой доступ к памяти. Незначительного несоответствия между объявленным контекстным окном модели и физической емкостью, предоставленной для его обслуживания, было достаточно, чтобы нарушить изоляцию арендаторов.
Для предприятий, использующих бессерверные платформы искусственного интеллекта, вывод из отчета Cloudflare двоякий: ошибки изоляции арендаторов при обслуживании LLM реальны и уже случались в производстве, а время ответа поставщиков — менее 24 часов от отчета до отключения, один день на исправление и восстановление — является стандартом усердия, которого следует требовать от любого провайдера, обрабатывающего конфиденциальные запросы.
---
Будьте в курсе ИИПоследние новости, аналитика и прорывы в сфере ИИ — всё в одном месте.
Читать больше новостей об ИИ →
