Anthropic представила FlashProve для криптографической проверки инференса
Anthropic представила FlashProve — открытый исследовательский прототип для криптографической проверки инференса. Он предназначен для ситуаций, когда пользователь обращается к дорогой языковой модели через сторонний API-роутер или реселлера и не может определить по ответу, какая система действительно обработала запрос.
Прототип позволяет установить, соответствуют ли выбранные токены ответа заранее зафиксированным весам конкретной модели. Это проверка происхождения вычисления, а не качества текста: FlashProve не показывает, насколько ответ полезен или точен, и не является готовой функцией Claude либо публичного API Anthropic.
Как устроена проверка
Механизм работает в два этапа. До обработки запросов провайдер формирует криптографический commitment для определённого набора весов и публикует его идентификатор. После генерации ответа FlashProve создаёт доказательство для выбранных токенов. Для проверки клиенту нужны запрос, ответ, commitment ID и публичные файлы commitment.
Проверка выполняется на CPU — без доступа к исходным весам и без повторного запуска модели. По смыслу это похоже на цифровую подпись, но подтверждается не авторство текста, а то, что конкретные токены выдала зафиксированная модель на заданном запросе. При этом доказательство скрывает веса и промежуточные значения, однако не скрывает архитектуру и размеры модели.
Одного доказательства недостаточно, чтобы понять, кто именно выбрал модель. Провайдер может заранее зафиксировать любой набор весов, поэтому commitment ID должен поступать от независимой доверенной стороны. Если его выдаёт тот же сервер, который затем формирует и проверяет доказательство, можно криптографически подтвердить работу не той модели, за которую заплатил клиент.
Результаты эксперимента
FlashProve тестировали не на Claude, а на Llama 4 Maverick от Meta — MoE-модели с 400 млрд параметров. При обработке одного токена активируется около 17 млрд параметров. В эксперименте использовали публичную 4-битную версию весов, одну видеокарту NVIDIA H100 и 24 CPU-ядра.
В строгом сценарии длина входного окна составляла 1024 токена, а каждое доказательство относилось только к одному следующему токену. Для 24 запросов система сформировала доказательства за 223 секунды. Средняя пропускная способность prefill составила 110 токенов в секунду при batch size 24, размер одного доказательства — 18,78 МБ, а проверка заняла 17 секунд на 24 потоках CPU и 21 секунду на одном потоке.
Показатель 110 токенов в секунду не означает, что FlashProve с такой скоростью генерирует или проверяет полноценные ответы. Он относится только к обработке входного контекста. В пересчёте на одну GPU создание доказательств занимало в 66–77 раз больше времени, чем пакетный prefill vLLM на 24 запросах, а при максимальной испытанной нагрузке разрыв достигал 94 раз. Сравнение приблизительное: FlashProve использовала 4-битные веса на одной H100, а vLLM — FP8-версию модели на восьми H100, причём замеры проводились отдельно.
В репозитории также приведён тест всех токенов заранее сохранённых ответов, где получена скорость 39,1 выходного токена в секунду. Однако это был режим clipped-gap, а не строгая проверка exact match: ответы заранее подбирали так, чтобы они укладывались в заданные пороги, а сам движок инференса не запускали. Такой результат показывает соблюдение порогов, но не доказывает, что каждый токен был первым выбором модели. При слишком мягких порогах могут проходить и ответы, которые не совпадают с наиболее вероятным выбором.
Ограничения прототипа
FlashProve работает постфактум: сначала модель создаёт ответ, затем отдельный этап формирует доказательство. Это приводит к дополнительной задержке и повторным вычислениям. Текущий протокол ограничен контекстом в 1024 токена и проверяет целочисленную версию квантованных весов при жадном декодировании. Ответы, полученные с другим режимом семплирования, не обязаны совпадать с доказанным результатом.
Прототип рассчитан на MoE-модели и не поддерживает dense-архитектуры. Время создания доказательства и другие побочные каналы не скрываются, поэтому возможные утечки через них не входят в заявленные гарантии. Кроме того, у доказательства нет идентификатора клиента и времени создания. Чтобы защититься от повторного использования старого proof, клиент должен добавлять в запрос собственный свежий nonce и отдельно хранить запрос, ответ и доказательство.
Отдельно Anthropic подчёркивает различие между протоколом и исполняемым кодом. Lean формально доказывает свойства протокола для Lean-верификатора. Быстрый C++-верификатор cp_verify и CUDA-генератор cp_prove тестировались на соответствие протоколу, но их формальная эквивалентность Lean-спецификации не доказана. Для программы cp_commit также нет формального доказательства, что commitment ID действительно связан с теми весами, которые она зафиксировала. Репозиторий помечен как исследовательский, проект не поддерживается и не принимает внешние изменения.
Практическое значение
Технология может пригодиться для проверки API-посредников и реселлеров, независимых бенчмарков, аудита поставщиков и подтверждения используемой модели в критически важных задачах. Но доказательство имеет смысл только вместе с заранее полученным доверенным commitment ID и ясными правилами, определяющими, какие токены и в каком режиме нужно проверять.
До практического применения FlashProve предстоит увеличить поддерживаемый контекст, научиться строго проверять полный ответ, надёжно связать commitment ID с названием модели и встроить формирование доказательств в реальный поток API-запросов. Anthropic также уточняет, что FlashProve не является механизмом, с помощью которого компания выполнила цель Safety Roadmap по подписанию inference-трафика: для этого используется отдельная система с подписью трафика и повторным вычислением запросов на доверенном сервере. Поэтому сейчас FlashProve следует рассматривать как демонстрацию криптографического подхода, а не как готовый способ проверить происхождение любого ответа ИИ.
