Телеметрия роутера MoE выдаёт данные дообучения: атака точнее на 2,7–9,4 п.п.

Если вы дообучаете MoE-модель на закрытых данных и параллельно пишете логи маршрутизации «для мониторинга», эти логи могут оказаться каналом утечки. В новой работе на arXiv (2610.10616) авторы описывают атаку membership inference, которая использует телеметрию роутера. Она определяет, входил ли конкретный пример в датасет дообучения. На трёх архитектурах MoE и трёх доменах данных прирост TPR при 1% FPR составил от 2,7 до 9,4 процентных пункта в каждой из девяти конфигураций. Сравнивали со сильным ансамблем сигналов на стороне выхода модели.

Как устроена атака

Mixture-of-Experts модели на каждом слое выбирают, каких экспертов подключить к токену. Эти решения часто логируют для отладки, анализа нагрузки и аудита безопасности. В отличие от текста ответа, такие данные показывают внутреннюю работу сети.

Авторы объединяют два типа признаков. Первый — привычные выходные сигналы вроде уверенности модели и потерь на примере. Второй — агрегированные признаки маршрутизации. Классификатор членства обучается на независимо дообученных shadow-моделях, а затем применяется к целевой. Доступ к её обучающим данным для этого не нужен.

Ключевые результаты из аннотации:

• 3 архитектуры MoE × 3 домена данных = 9 конфигураций, и в каждой телеметрия улучшает атаку.
• Прирост TPR при 1% FPR: от +2,7 до +9,4 п.п. над ансамблем выходных сигналов.
• Утечка сохраняется при полном дообучении, обучении с замороженным роутером, LoRA и instruction tuning.
• Достаточно дискретных выборов экспертов, ограниченной телеметрии или одной shadow-модели.
• Зашумление телеметрии снижает дополнительную утечку только вместе с её точностью.

Почему роутеру не нужно запоминать

Интуитивная защита звучит так: заморозим роутер, и он не сможет запомнить обучающие примеры. Механистический анализ показывает, что это не работает. Дообучение записывает информацию о членстве в скрытые представления. Роутер читает эти представления и тем самым выдаёт их проекцию, даже когда его собственные параметры не менялись. Специфическая память роутера для утечки не нужна.

Отсюда следует важный вывод для защиты. Достаточно того, что роутер видит скрытые состояния, и точечные правки в нём ничего не решат. Лечить придётся либо саму телеметрию, либо то, как данные попадают в веса.

Цифры стоит читать с оговоркой. В аннотации нет абсолютных значений TPR, только прирост. Девять пунктов при 1% FPR заметны, а два с половиной выглядят скромно. Но именно этот режим с низким уровнем ложных срабатываний определяет, насколько атака пригодна для реального аудита или злоупотребления. Системно положительный эффект во всех девяти настройках убедителен сам по себе.

Что делать командам, которые логируют роутинг

Практические выводы из работы и ближайшие следствия из неё:

• Относитесь к логам маршрутизации как к данным, производным от обучающей выборки. Ограничьте доступ, срок хранения и экспорт во внешние системы мониторинга.
• Не отдавайте сырую телеметрию клиентам и сторонним аудиторам вместе с ответами модели, особенно для моделей, дообученных на пользовательских или медицинских данных.
• Снижайте гранулярность. Агрегаты вместо потокенных выборов экспертов уменьшают сигнал. Но авторы показывают, что дискретных выборов уже хватает, так что это смягчение, а не гарантия.
• Зашумление работает как размен. Утечка падает ровно настолько, насколько падает полезность телеметрии для отладки. Нужно заранее решить, какой точностью вы готовы пожертвовать.
• Включите проверку в процесс оценки рисков. Обучите несколько shadow-моделей на своей архитектуре и посмотрите, насколько вырастает атака при добавлении роутинга. Работа показывает, что хватит и одной.
• Рассмотрите защиту на уровне самого дообучения, например дифференциальную приватность. Это уже мой вывод, а не результат статьи, но логика прямая: если сигнал живёт в скрытых представлениях, закрывать нужно источник.

Мониторинг MoE-инфраструктуры, где логи экспертов нужны для балансировки нагрузки и отладки, придётся проектировать с оглядкой на приватность.