FlashProve : Anthropic prouve quel modèle a donné la réponse

Le 2 novembre, la Frontier Red Team d’Anthropic a publié FlashProve, un prototype ouvert d’inférence prouvable (« provable inference »). Il permet à un fournisseur de modèle de prouver cryptographiquement qu’une réponse donnée provient d’un jeu de poids précis, déclaré à l’avance, sans révéler ces poids. Le code est sur GitHub sous licence Apache 2.0.

Quel problème FlashProve résout-il ?

Quand on interroge un modèle via une API, on n’a aucun moyen de vérifier que c’est bien le modèle pour lequel on paie qui a répondu. Les auteurs citent l’exemple d’un service intermédiaire qui remplace discrètement le modèle « for cost reasons », et d’un fournisseur qui pourrait servir une version moins chère ou dégradée et falsifier les journaux.

FlashProve y répond avec un zkSNARK, c’est-à-dire une preuve courte à divulgation nulle de connaissance. Cela fonctionne en deux temps :

1. Une fois par modèle, le fournisseur publie un engagement sur les poids : une courte « empreinte » qui le lie à un seul jeu de poids, sans les dévoiler.
2. Pour chaque requête, le serveur génère une preuve que c’est bien le modèle déclaré qui a produit ces tokens. N’importe qui peut vérifier cette preuve sur un CPU ordinaire, sans accès aux poids.

La preuve a plusieurs propriétés : une preuve honnête passe toujours, une preuve falsifiée est pratiquement impossible à produire, les poids et les valeurs intermédiaires restent cachés, et la preuve elle-même est petite et peu coûteuse à vérifier.

FlashProve est-il rapide ?

C’est là que ça devient intéressant. L’équipe l’a démontré sur Llama 4 Maverick complet, un modèle MoE (mixture-of-experts) de 400 milliards de paramètres, dont environ 17 milliards actifs par token, avec des poids en 4 bits. D’après le billet :

1. Le prouveur a besoin d’un H100 et de 24 cœurs CPU, et diffuse les poids depuis environ 290 Go de mémoire hôte.
2. La phase préparatoire dure environ 39 minutes et ne s’exécute qu’une fois par modèle.
3. Un lot de 24 requêtes prend environ 223 secondes, soit environ 110 tokens par seconde, et une preuve pèse 18,78 Mo.
4. La vérification d’une preuve prend 17 secondes sur 24 threads (21 secondes sur un seul), sans GPU.

Le surcoût reste important : prouver prend environ 72 fois plus de temps que le traitement des mêmes 24 requêtes par vLLM (66 à 77 fois selon les exécutions). À titre de comparaison, les auteurs citent des travaux ouverts antérieurs qui atteignaient des fractions de token par seconde ou tournaient sur des modèles de la taille de GPT-2.

Et Claude dans tout ça ?

Dans le travail de recherche lui-même. Selon les auteurs, Claude a mis au point les améliorations des zkSNARK pour l’inférence et a rédigé la spécification du protocole. L’équipe précise toutefois que Claude « often makes decisions that are hard to evaluate » : les propriétés de sécurité ont donc été formalisées et prouvées en Lean. Le dépôt contient notamment le prouveur, un vérificateur rapide en C++ et un second vérificateur, formellement vérifié, en Lean ; selon les auteurs, les deux concordent sur chaque preuve testée. J’ai parlé de la façon dont Claude gère les preuves formelles à propos de la vérification formelle de 123 bibliothèques open source.

Parmi les auteurs figurent des chercheurs d’Anthropic, de l’EPFL, du MIT, de StarkWare et de Succinct.

À quoi faut-il faire attention ?

D’abord, il s’agit d’un prototype de recherche. Le billet ne dit rien d’une utilisation de FlashProve pour les modèles Claude ni en production chez Anthropic, et le dépôt est marqué comme non maintenu et n’accepte pas de contributions.

Ensuite, les limites décrites par les auteurs eux-mêmes. La preuve couvre une version entière des poids et le décodage glouton (greedy decoding) : les réponses avec échantillonnage peuvent donc différer. Le contexte est limité à 1024 tokens, l’architecture du modèle n’est pas cachée et la conception suppose un modèle MoE. Il n’y a pas non plus de garanties formelles pour le code exécutable rapide.

Enfin, la latence. FlashProve prouve après l’inférence, par lots : on ne reçoit donc pas la preuve en même temps que la réponse.

À quoi cela peut-il servir ?

Les auteurs citent notamment la détection de serveurs compromis ou de modèles substitués, la confirmation du modèle qui a écrit un texte donné, et le contrôle que seuls des modèles approuvés sont servis. Une idée intrigante est la « Proof-of-Failure » : une preuve que le fournisseur a consommé au moins un certain nombre de tokens d’un modèle précis sans obtenir de résultat, par exemple que le modèle n’a trouvé aucun bug dans un correctif après au moins 1 million de tokens.

C’est une approche différente du filigrane de Claude, qui marque le texte de façon statistique et exige une clé secrète pour la détection. FlashProve fournit une preuve mathématique que tout le monde peut vérifier. L’équipe prévoit ensuite de masquer les détails de l’architecture et d’étendre la limite de 1024 tokens à toute la fenêtre de contexte.

FAQ

Qu’est-ce que FlashProve ?

C’est un prototype ouvert d’Anthropic pour l’inférence prouvable : un système de preuves cryptographiques (zkSNARK) qui permet de vérifier qu’une réponse a été générée par un modèle précis et déclaré, sans révéler ses poids.

FlashProve fonctionne-t-il avec Claude ?

Le billet d’Anthropic n’en parle pas. L’équipe l’a testé sur le modèle ouvert Llama 4 Maverick, et le projet lui-même est un prototype de recherche.

Puis-je vérifier moi-même une preuve FlashProve ?

Oui. D’après le README, on peut lancer la vérification d’une preuve d’exemple sous Linux avec g++ 13, avec moins de 2 Go de RAM et sans GPU. Pour générer des preuves sur le modèle complet, il faut un H100 de 80 Go et plusieurs centaines de Go de RAM.

Sous quelle licence est FlashProve ?

Sous licence Apache 2.0. Les poids du modèle ne sont pas inclus : il faut les télécharger sur Hugging Face sous la licence Llama 4.