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