Anthropic publica FlashProve: demostrar la inferencia de un modelo cuesta entre 70 y 95 veces lo que cuesta ejecutarla

Compras acceso a un modelo caro a través de un intermediario. Llega la respuesta, aparece el nombre del modelo y se emite la factura. ¿Cómo comprobar que ese modelo realmente procesó la solicitud? Es difícil determinarlo con fiabilidad solo por la calidad del texto. El 2 de noviembre, Anthropic presentó FlashProve, un prototipo abierto que permite verificar la relación entre un resultado y unos pesos fijados de antemano. Para los desarrolladores, su interés reside en la posibilidad de auditar al proveedor, aunque el coste impide por ahora aplicarlo a cada solicitud. Anuncio de Anthropic.

Qué acredita exactamente la prueba

Imaginemos un servicio que promete procesar documentos con un modelo determinado. Primero, el proveedor publica un compromiso criptográfico: lo vincula a un conjunto concreto de pesos sin revelar sus valores. Después entrega una prueba junto con el resultado de los cálculos. El cliente la verifica en una CPU, sin descargar los pesos ni volver a ejecutar el modelo de gran tamaño.

FlashProve se basa en zkSNARK, un protocolo criptográfico para verificar cálculos. En este escenario, quien verifica recibe la confirmación de que el resultado declarado corresponde al modelo comprometido y a los datos de entrada. La propia prueba está diseñada para no revelar los pesos. Esto permite separar dos tareas: el proveedor almacena el modelo y realiza los cálculos pesados, mientras que el cliente verifica la evidencia recibida. El principio se describe en el informe técnico.

Pero queda una pregunta: ¿quién confirmó que el identificador publicado corresponde realmente al modelo por el que has pagado? Si el intermediario elige unos pesos baratos y los presenta como un modelo caro, una prueba válida no detectará el engaño. El identificador debe obtenerse de antemano de una parte de confianza. Este límite de confianza se indica expresamente en el README del proyecto.

Para un equipo de producto, esto añade un requisito a los acuerdos con el proveedor: no basta con recibir un archivo con la prueba. Hay que entender con qué referencia se contrasta y quién responde por ella.

Por qué es fácil malinterpretar los 110 tokens por segundo

El experimento se realizó con Llama 4 Maverick, pesos de 4 bits y un contexto de 1024 tokens. Con un lote de 24 solicitudes, una sola H100 procesaba unos 110 tokens de entrada por segundo mientras generaba las pruebas. Es la velocidad de procesamiento de los prompts, no la de entrega de nuevos tokens al usuario. Cada solicitud de esta medición demostraba un único token siguiente. Condiciones de medición.

La diferencia es considerable. Es fácil interpretar la cifra de 110 como la velocidad de un chat completo con respuestas verificables. En realidad, cada solicitud del lote esperaba a que terminaran las pruebas de todo el lote: aproximadamente 221–226 segundos, antes de cualquier verificación adicional. Por eso no se puede convertir una cifra de rendimiento en promesas de latencia para el usuario. Son características distintas de un mismo experimento. Tabla de rendimiento.

Según la estimación de Anthropic, generar las pruebas requiere aproximadamente entre 70 y 95 veces el tiempo de GPU de una inferencia convencional mediante vLLM. La prueba de la solicitud de ensayo ocupa unos 19 MB. En una API a gran escala, esto modifica de forma considerable los costes de cómputo y transferencia de datos. Estimación de los autores.

Qué comprobar antes de experimentar

Las garantías se aplican a una implementación concreta del modelo que utiliza números enteros. Determinar si sus respuestas coinciden con las de la versión convencional, que trabaja en coma flotante, requiere una evaluación independiente. Además, la verificación estricta de una coincidencia exacta y el modo que admite desviaciones ofrecen garantías diferentes. Que el programa termine correctamente no explica por sí solo qué ha acreditado exactamente. La verificación también abarca únicamente las posiciones de tokens especificadas. Limitaciones conocidas.

Mi conclusión práctica es empezar por verificar un ejemplo guardado y analizar la salida del verificador. El repositorio ofrece una forma de hacerlo sin GPU, y el código se publica bajo Apache 2.0. Aun así, los autores describen el proyecto como un artefacto de investigación sin mantenimiento. Repositorio de FlashProve.

Para un equipo que esté desarrollando un sistema de auditoría de API de IA, el siguiente paso útil es formular sus propios requisitos: qué cálculos necesita acreditar, quién certifica los pesos y cuánto puede esperar. Después, medir el coste en su propio caso de uso. Demostrar la procedencia de una respuesta no hace que su contenido sea correcto por sí mismo. Pero sí proporciona una vía técnica para comprobar una promesa del proveedor que hoy a menudo hay que aceptar de buena fe.