Anthropic открыла FlashProve: проверка модели обходится в 70–95 раз дороже вывода

Вы покупаете доступ к дорогой модели через посредника. Ответ приходит, название модели указано, счёт выставлен. Как проверить, что запрос действительно обработала она? По качеству текста надёжно определить это трудно. Anthropic 2 ноября представила FlashProve — открытый прототип, который позволяет проверить связь результата с заранее зафиксированными весами. Для разработчика здесь интересен способ аудита поставщика, хотя стоимость пока мешает применять его к каждому запросу. Анонс Anthropic.

Что именно подтверждает доказательство

Представим сервис, который обещает обрабатывать документы определённой моделью. Поставщик сначала публикует криптографическое обязательство: оно связывает его с конкретным набором весов, скрывая сами значения. Затем вместе с результатом вычислений выдаёт доказательство. Клиент проверяет его на CPU, без скачивания весов и повторного запуска большой модели.

Основа FlashProve — zkSNARK, криптографический протокол для проверки вычислений. В этом сценарии проверяющий получает подтверждение, что заявленный результат соответствует зафиксированной модели и входным данным. Само доказательство устроено так, чтобы не раскрывать веса. Это позволяет разделить две задачи: поставщик хранит модель и выполняет тяжёлые вычисления, клиент проверяет полученное свидетельство. Принцип описан в техническом отчёте.

Но остаётся вопрос: кто подтвердил, что опубликованный идентификатор действительно относится к купленной вами модели? Если посредник сам выбрал дешёвые веса и сам назвал их дорогой моделью, корректное доказательство этого обмана не обнаружит. Идентификатор нужно заранее получать от доверенной стороны. Такая граница доверия прямо указана в README проекта.

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

Почему 110 токенов в секунду легко понять неправильно

Эксперимент провели на Llama 4 Maverick с четырёхбитными весами и контекстом в 1024 токена. При пакете из 24 запросов одна H100 обрабатывала около 110 входных токенов в секунду при построении доказательств. Это скорость обработки промптов, а не выдачи новых токенов пользователю. Каждый запрос в этом замере доказывал один следующий токен. Условия измерений.

Разница существенная. Число 110 легко принять за скорость полноценного чата с проверяемыми ответами. Фактически запрос в пакете ждал завершения доказательств всего пакета: примерно 221–226 секунд, ещё до дополнительной проверки. Поэтому переносить показатель пропускной способности в обещания задержки для пользователя нельзя. Это отдельные характеристики одного эксперимента. Таблица производительности.

По оценке Anthropic, доказательства требуют примерно в 70–95 раз больше времени GPU, чем обычный вывод через vLLM. Размер доказательства для тестового запроса — около 19 МБ. Для массового API это заметно меняет расходы на вычисления и передачу данных. Оценка авторов.

Что проверить перед экспериментом

Гарантии относятся к конкретной целочисленной реализации модели. Совпадение её ответов с обычной версией, работающей с плавающей точкой, требует отдельной оценки. Кроме того, строгая проверка точного совпадения и режим с допустимыми отклонениями дают разные гарантии. Успешное завершение программы само по себе ещё не объясняет, что именно она подтвердила. Проверка также охватывает только указанные позиции токенов. Известные ограничения.

Мой практический вывод: начинать стоит с проверки сохранённого примера и разбора результата верификатора. В репозитории есть такой маршрут без GPU, код опубликован под Apache 2.0. При этом авторы обозначают проект как исследовательский артефакт без сопровождения. Репозиторий FlashProve.

Для команды, которая строит аудит AI API, следующий полезный шаг — сформулировать собственное требование: какие вычисления нужно подтверждать, кто удостоверяет веса и сколько можно ждать. А затем измерить стоимость на своём сценарии. Доказательство происхождения ответа само по себе не делает ответ правильным по смыслу. Зато оно даёт технический способ проверить обещание поставщика, которое сегодня часто приходится принимать на веру.