TranScope: процессор знает, на каких данных училась LLM
Судебный спор: автор утверждает, что его книгу скормили языковой модели без разрешения. Спросить саму модель бесполезно, она не помнит источники и уверенно выдумывает. Проверка по выходам тоже не работает: constant-time вычисления и маскировка уверенности сводят современные атаки на принадлежность данных к случайному угадыванию. Ответ лежит не в софте, а в железе. Работа, вышедшая на arXiv в начале октября 2026 года (2610.06848), показывает: счётчики производительности процессора хранят след обучающих данных. Инструмент TranScope читает этот след с точностью до 99,8% и не задаёт модели ни одного вопроса.
Что такое TranScope
TranScope, первый инструмент для определения принадлежности текста к обучающей выборке по микроархитектурным сигналам, работает с тем, что процессор оставляет при инференсе: счётчиками производительности, энергопотреблением и паттернами доступа к памяти. Ему не нужны выходы модели, суррогатные модели или повторные запросы. Достаточно запустить открытую модель на своём железе и прочитать показания счётчиков.
Внутри метод устроен как следственный протокол. Сначала строится эталон: набор знакомых и незнакомых текстов. Потом модель прогоняется под контролем (ядро закреплено, SMT выключен, частота фиксирована), собирается телеметрия по 263 счётчикам, разложенным на семь подсистем процессора, и вычисляются размеры эффекта. Авторы подчёркивают, что счётчики работают как присяжные, а не как единственная улика. Вывод оформляется как проверяемая справка: доверительные интервалы, карта подсистем, оценка ложных срабатываний. Бинарного вердикта инструмент не выносит.
Как знакомый текст выдаёт себя
Причинная цепочка в статье выглядит так: знакомство с обучающим корпусом, близость идентификаторов токенов, локальность строк таблицы эмбеддингов, резидентность в кэше и TLB, расхождение счётчиков.
Конкретный пример. Пусть модель училась на новостях до 2020 года. Заголовок марта 2020-го про COVID-19 токенизируется в слова, которые встречались в корпусе миллионы раз: China получает идентификатор 2859, virus 3142, spread 4293. Идентификаторы идут плотной группой в узкой полосе словаря. Заголовок февраля 2022-го про вторжение в Украину состоит из редких слов: Kyiv получает идентификатор 27631, invasion 18204, shelling 14208. Они разлетаются по всему словарю.
Дальше в дело вступает арифметика памяти. Каждый токен адресует строку таблицы эмбеддингов по формуле BASE + идентификатор × размер строки. У BERT-base строка занимает 3072 байта (768 значений по 4 байта), почти целую страницу памяти по 4 КБ. Переход между «China» и «virus» это прыжок на 283 × 3072 байта, примерно 0,83 МБ, через пару страниц. Переход между «Kyiv» и «invasion» растягивается на 9427 × 3072 байта, около 28,9 МБ, в 35 раз дальше, через тысячи страниц.
Для процессора разница принципиальная. Знакомый текст укладывается примерно в 70 страниц, которые остаются резидентными в TLB, буфере трансляции адресов: обращения идут по быстрому пути. Незнакомый распыляет чтения по сотням страниц, каждая новая вызывает промах TLB и обход таблицы страниц стоимостью около 200 циклов, а за ним поход в DRAM.
На уровне софта модель выполняет одни и те же операции в том же порядке. Именно поэтому утечку не замечали раньше: разница в 20 обходов таблицы страниц на 52 миллиона циклов не видна в общем времени выполнения, но счётчики производительности фиксируют её уверенно.
Есть и любопытная деталь из того же эксперимента: у BERT-large число обходов перестаёт расти, потому что объём вычислений большой модели перекрывает вклад таблицы эмбеддингов. Ставку авторы делают на совокупность сигналов: даже там, где отдельный счётчик даёт слабый сигнал, агрегат по сотням событий сохраняет разделение.
Что показали эксперименты
Замеры шли на Intel Sapphire Rapids: одно изолированное ядро, отключённый SMT, 263 счётчика производительности. Модели: BERT (от 4,4 до 110 млн параметров), ViT (от 22 до 307 млн), Pythia (от 70 млн до 2,8 млрд) и GPT-2 (от 124 млн до 1,5 млрд).
Даже на крошечном BERT с 4,4 млн параметров AUC составляет 0,92 при точности 84%. С ростом до 110 млн параметров точность доходит до 99%, а ложные срабатывания и пропуски падают почти до нуля уже после 30 млн параметров у BERT и 70 млн у Pythia. У GPT-2 точность 96% на 124 млн параметров, 100% на 355 млн и 82% на 1,5 млрд, единственный разворот тренда в исследовании. Семейство Pythia держит около 99% по всему диапазону до 2,8 млрд.
В сводке статьи пятнадцати счётчиков Intel вместе с энергопотреблением хватает, чтобы получить AUC 0,995, точность 99,8%, полноту 100% и долю ложных срабатываний 0,5%. Лучший предыдущий результат, PETAL, составляет 0,6 AUC, причём ему требуется обучение суррогатной модели размером с исследуемую. TranScope обходится одним прогоном.
Классификатор для этих замеров намеренно простой: четырёхслойный перцептрон с 512, 128, 32 и одним нейроном на выходе. С каждого прогона снимается 1596 признаков, сто образцов знакомого текста и сто незнакомого с десятью повторами дают две тысячи наблюдений, которых хватает для обучения с разделением 80 на 20. Тонкая настройка под конкретную модель не требуется.
Отдельно проверялось, что будет на современных ускорителях. На бэкенде IPEX с инструкциями AMX точность монотонно растёт с размером модели, с 81% на 4 млн параметров до 93% на 110 млн. Аппаратные ускорители не прячут сигнал, а усиливают его.
Ещё один эксперимент разделял два корпуса настоящих текстов: письма Enron против документов NIH Exporter. Оба набора это обычные предложения, но модель видела только один из них. Точность разделения 98%.
Самый наглядный кейс связан с New York Times. GPT обучался на данных до ноября 2019 года, и статья 2019 года против статей 2020-2023 годов выдаёт себя: на 56% меньше обращений к памяти за пределами ядра, на 12% меньше промахов TLB, при этом время выполнения отличается не более чем на 1,2%.
Питание оказалось третьим независимым каналом. Разница в энергопотреблении между знакомым и незнакомым текстом растёт с размером модели: от 2,6% у BERT-mini до 4,5% у BERT-base. А у ViT сильнее всего выделяется счётчик микрокодовых ассистов для плавающей точки с эффектом d = 2,52, самым крупным из измеренных в работе. Для масштаба: d выше 0,8 уже считается большим эффектом.
Почему constant-time защиты слепы
Классические атаки по сторонним каналам разбиваются о constant-time вычисления: если время работы не зависит от входных данных, утечку не с чем связать. TranScope обходит ограничение, потому что читает сигналы ниже уровня времени. Время стабильно, а число обходов таблицы страниц, промахов TLB, очисток конвейера и обращений к памяти за пределами ядра меняется. Пайплайн-очистки расходятся с эффектом d ≈ 0,84, циклы восстановления конвейера с d ≈ 0,73.
Маскировка уверенности тоже не помогает: методу вообще не нужны выходы модели. Предыдущим поколениям атак требовалось куда больше: метод Шокри 2017 года строил теневые модели, LiRA усиливал мощность через отношения правдоподобия, и обоим нужны были выходы и уверенность классификатора. Аппаратные предшественники вроде TLBleed и Cache Telepathy цеплялись за адаптивные сети с ветвлениями и плавающим таймингом. На статических трансформерах без ветвлений все они слепли. Авторы описывают это как новый класс канала: счётчики расходятся при неподвижном тайминге.
Юридический сценарий и двойное назначение
Модель угроз в статье необычная и при этом самая реалистичная из возможных. Никакой жертвы нет: аудитор скачивает публичную модель, запускает её на своём железе и читает счётчики на своей машине. Не нужно синхронизироваться с чужой инфраструктурой, обходить гипервизор или договариваться с владельцем модели. Это ровно то, что делает каждый пользователь открытых весов.
Отсюда двойное назначение. С одной стороны, это первый практичный инструмент проверки нарушений авторских прав: можно построить доказательство того, что спорный текст оставил след в модели. Авторы называют такие сигналы свидетелями происхождения (provenance witness) и подчёркивают, что один свидетель ничего не решает, но несколько согласованных сигналов вместе дают сильный аргумент для суда. С другой стороны, это новый канал атаки на приватность: тот же метод позволяет выяснить, был ли конкретный текст в обучающей выборке.
Сценарий не ограничен дата-центрами. Индустрия движется к локальному запуску моделей: Apple Foundation Models, Microsoft Aion Instruct и Adobe Firefly исполняются на пользовательском железе. Если модель работает на вашей машине, её счётчики тоже ваши.
Что предлагают менять в железе
Статья не заканчивается демонстрацией атаки. Вторая её половина это рекомендации архитекторам процессоров, потому что каждый расходящийся счётчик одновременно и утечка, и подсказка о том, где современные AI-нагрузки упираются в железо. Трансформеры генерируют больше 300 обходов таблицы страниц на один инференс, чего не видели предыдущие рабочие нагрузки, а обходы для страниц 2-4 МБ надёжно разделяют знакомые и незнакомые тексты.
Авторы предлагают учитывать таблицу эмбеддингов при разбиении TLB, хранить её на больших страницах и добавить упреждающую подкачку обходов под паттерны gather/scatter. Отдельная находка: чем шире покрытие обучающих данных, тем ниже среднее энергопотребление инференса. Покрытие обучения становится новой осью в энергомоделях, а не только вопросом качества.
Часто задаваемые вопросы
Это работает только с открытыми моделями?
Да, для замера нужен локальный запуск на своём железе, поэтому облачные API напрямую так не проверить: счётчики процессора недоступны клиенту. Но тренд на локальные модели, от Apple Foundation Models до открытых весов Llama, Pythia и BERT, расширяет область применения с каждым релизом.
Можно ли защититься от TranScope?
Constant-time вычисления и маскировка уверенности не помогают: утечка происходит ниже уровня времени и не требует выходов модели. Дифференциальная приватность защищает от атак по выходам, но не от микроархитектурных сигналов. Направление защиты авторы видят в железе: сегментация TLB под таблицы эмбеддингов, большие страницы и предикторы, обученные на паттернах доступа.
Насколько это дорого для аудитора?
Дешевле всех предыдущих методов. Нужен обычный процессор с доступом к счётчикам (на Linux достаточно параметра perf_event_paranoid = -1), сотня образцов текста для эталонных распределений и лёгкий классификатор на четыре слоя. Ни суррогатных моделей, ни выходов модели.
Итог
TranScope показывает, что граница между «училась» и «не училась» проступает на уровне кремния: счётчики производительности, TLB и энергопотребление хранят отпечаток обучающего корпуса, который не стирают ни constant-time защиты, ни маскировка выходов. С ростом моделей и интеграцией ускорителей сигнал только усиливается. Для правообладателей это первый рабочий инструмент проверки, для приватности новый канал утечки, а для архитекторов процессоров список задач на следующие поколения чипов.
Проверить идею можно и на своём ноутбуке: запустите локальную модель под perf stat на знакомом и незнакомом тексте и сравните счётчики. Если разница воспроизведётся, вы увидите тот самый сигнал, о котором пишут авторы.