Anthropic dévoile FlashProve : vérifier un modèle coûte 70–95 fois plus cher que l’inférence

Vous achetez l’accès à un modèle coûteux auprès d’un intermédiaire. La réponse arrive, le nom du modèle est indiqué et la facture est émise. Comment vérifier que c’est bien ce modèle qui a traité la requête ? La qualité du texte ne permet guère de le déterminer de manière fiable. Le 2 novembre, Anthropic a présenté FlashProve, un prototype ouvert permettant de vérifier qu’un résultat correspond à des poids fixés à l’avance. Pour les développeurs, l’intérêt réside dans cette méthode d’audit du fournisseur, même si son coût empêche encore de l’appliquer à chaque requête. Annonce d’Anthropic.

Ce que la preuve confirme exactement

Imaginons un service qui promet de traiter des documents avec un modèle donné. Le fournisseur publie d’abord un engagement cryptographique : celui-ci le lie à un ensemble précis de poids, tout en masquant leurs valeurs. Il fournit ensuite une preuve avec le résultat des calculs. Le client la vérifie sur CPU, sans télécharger les poids ni exécuter à nouveau le grand modèle.

FlashProve repose sur un zkSNARK, un protocole cryptographique de vérification des calculs. Dans ce scénario, le vérificateur obtient la confirmation que le résultat annoncé correspond au modèle fixé et aux données d’entrée. La preuve elle-même est conçue pour ne pas révéler les poids. Cela permet de répartir les tâches : le fournisseur conserve le modèle et effectue les calculs lourds, tandis que le client vérifie la preuve reçue. Le principe est décrit dans le rapport technique.

Une question demeure toutefois : qui a confirmé que l’identifiant publié correspond réellement au modèle pour lequel vous avez payé ? Si l’intermédiaire choisit lui-même des poids bon marché et les présente comme ceux d’un modèle coûteux, une preuve valide ne détectera pas cette tromperie. L’identifiant doit être obtenu au préalable auprès d’un tiers de confiance. Cette limite de confiance est explicitement indiquée dans le README du projet.

Pour une équipe produit, cela ajoute une exigence aux accords avec le fournisseur : recevoir un fichier de preuve ne suffit pas. Il faut savoir à quelle référence cette preuve est comparée et qui répond de cette référence.

Pourquoi les 110 tokens par seconde peuvent prêter à confusion

L’expérience a été menée sur Llama 4 Maverick avec des poids sur quatre bits et un contexte de 1024 tokens. Avec un lot de 24 requêtes, un seul H100 traitait environ 110 tokens d’entrée par seconde tout en produisant les preuves. Il s’agit de la vitesse de traitement des prompts, et non du débit de nouveaux tokens envoyés à l’utilisateur. Dans cette mesure, chaque requête apportait la preuve d’un seul token suivant. Conditions de mesure.

La distinction est importante. Le chiffre de 110 peut facilement être pris pour le débit d’un véritable service de chat aux réponses vérifiables. En réalité, chaque requête du lot attendait la fin de la production des preuves pour l’ensemble du lot : environ 221–226 secondes, avant même la vérification supplémentaire. On ne peut donc pas transformer ce débit en promesse de latence pour l’utilisateur. Ce sont deux caractéristiques distinctes d’une même expérience. Tableau des performances.

Selon Anthropic, produire les preuves demande environ 70–95 fois plus de temps GPU qu’une inférence classique avec vLLM. La preuve d’une requête de test pèse environ 19 Mo. Pour une API à grande échelle, cela modifie sensiblement les coûts de calcul et de transfert de données. Estimation des auteurs.

Ce qu’il faut vérifier avant de se lancer

Les garanties portent sur une implémentation précise du modèle en arithmétique entière. La concordance de ses réponses avec celles de la version habituelle, qui utilise des nombres à virgule flottante, nécessite une évaluation distincte. De plus, la vérification stricte d’une correspondance exacte et le mode autorisant des écarts n’offrent pas les mêmes garanties. Le simple fait que le programme se termine correctement ne dit pas encore ce qu’il a effectivement confirmé. La vérification ne couvre par ailleurs que les positions de tokens spécifiées. Limites connues.

Mon conseil pratique : commencer par vérifier un exemple enregistré et analyser le résultat du vérificateur. Le dépôt propose cette démarche sans GPU ; le code est publié sous licence Apache 2.0. Les auteurs présentent toutefois le projet comme un artefact de recherche sans maintenance. Dépôt FlashProve.

Pour une équipe qui développe un dispositif d’audit des API d’IA, l’étape suivante consiste à préciser ses propres exigences : quels calculs doivent être attestés, qui certifie les poids et quel délai est acceptable. Il faut ensuite mesurer le coût dans son propre cas d’usage. Prouver la provenance d’une réponse ne garantit pas, en soi, sa justesse sur le fond. Cela fournit en revanche un moyen technique de vérifier une promesse du fournisseur qu’il faut aujourd’hui souvent accepter sur parole.