Imagina que quieres ejecutar un modelo de lenguaje grande como Llama2-70B. Un modelo tan masivo requiere más de 140 GB de memoria, lo que significa que no puedes ejecutar el modelo en bruto en tu máquina doméstica. ¿Cuáles son tus opciones? Podrías recurrir a un proveedor de servicios en la nube, pero es posible que no te entusiasme confiar en una única empresa centralizada para manejar esta carga de trabajo por ti y recopilar todos tus datos de uso. Entonces, lo que necesitas es inferencia descentralizada, que te permite ejecutar modelos de ML sin depender de un único proveedor.

El Problema de la Confianza

En una red descentralizada, no es suficiente con simplemente ejecutar un modelo y confiar en la salida. Digamos que le pido a la red que analice un dilema de gobernanza usando Llama2-70B. ¿Cómo sé que en realidad no está utilizando Llama2-13B, dándome un análisis peor y quedándose con la diferencia?

En el mundo centralizado, es posible que confíes en que empresas como OpenAI están actuando honestamente porque su reputación está en juego (y en cierto grado, la calidad de LLM es evidente por sí misma). Pero en el mundo descentralizado, la honestidad no se da por sentada, se verifica.

Aquí es donde entra en juego la inferencia verificable. Además de proporcionar una respuesta a una consulta, también demuestras que se ejecutó correctamente en el modelo que solicitaste. ¿Pero cómo?

El enfoque ingenuo sería ejecutar el modelo como un contrato inteligente en cadena. Esto definitivamente garantizaría que la salida fuera verificada, pero esto es extremadamente impráctico. GPT-3 representa palabras con una dimensión de incrustación de 12.288. Si hicieras una sola multiplicación de matrices de este tamaño en cadena, costaría alrededor de $10 mil millones a los precios actuales de gas: la computación llenaría cada bloque durante aproximadamente un mes seguido.

Así que no. Vamos a necesitar un enfoque diferente.

Después de observar el panorama, está claro para mí que han surgido tres enfoques principales para abordar la inferencia verificable: pruebas de conocimiento cero, pruebas de fraude optimistas y criptoeconomía. Cada uno tiene su propio sabor de seguridad e implicaciones de costos.

1. Pruebas de conocimiento cero (ZK ML)

Imagina poder demostrar que ejecutaste un modelo masivo, pero la prueba es efectivamente de un tamaño fijo independientemente de lo grande que sea el modelo. Eso es lo que promete ZK ML, a través de la magia de ZK-SNARKs.

Si bien suena elegante en principio, compilar una red neuronal profunda en circuitos de conocimiento cero que luego se pueden demostrar es extremadamente difícil. También es muy costoso — como mínimo, es probable que estés buscando@ModulusLabs/chapter-5-the-cost-of-intelligence-da26dbf93307">1000x cost for inference and 1000x latency (the time to generate the proof), to say nothing of compiling the model itself into a circuit before any of this can happen. Ultimately that cost has to be passed down to the user, so this will end up very expensive for end users.

Por otro lado, esta es la única aproximación que garantiza criptográficamente la corrección. Con ZK, el proveedor del modelo no puede hacer trampa sin importar lo duro que lo intenten. Pero lo hace a un costo enorme, lo que lo hace impráctico para modelos grandes en el futuro previsible.

Ejemplos: EZKL, Modulus Labs, Giza

2. Pruebas de Fraude Optimistas (ML Optimista)

El enfoque optimista es confiar, pero verificar. Asumimos que la inferencia es correcta a menos que se demuestre lo contrario. Si un nodo intenta hacer trampa, los "observadores" en la red pueden llamar al tramposo y desafiarlo usando una prueba de fraude. Estos observadores tienen que estar vigilando la cadena en todo momento y volviendo a ejecutar las inferencias en sus propios modelos para garantizar que las salidas sean correctas.

Estas pruebas de fraude son Estilo Truebitjuegos interactivos de desafío-respuesta, donde divides repetidamente la traza de ejecución del modelo en cadena hasta que encuentres el error.

Si esto realmente sucede, es increíblemente costoso, ya que estos programas son enormes y tienen estados internos enormes — una sola inferencia de GPT-3 cuesta aproximadamente 1 petaflop(10¹⁵ operaciones de punto flotante). Pero la teoría de juegos sugiere que esto casi nunca debería suceder (las pruebas de fraude también son notoriamente difíciles de codificar correctamente, ya que el código casi nunca se ejecuta en producción).

El lado positivo es que ML optimista es seguro siempre y cuando haya un único observador honesto que esté prestando atención. El costo es más barato que ZK ML, pero recuerde que cada observador en la red está volviendo a ejecutar cada consulta por sí mismos. En el equilibrio, esto significa que si hay 10 observadores, ese costo de seguridad debe ser trasladado al usuario, por lo que tendrán que pagar más de 10 veces el costo de inferencia (o la cantidad de observadores que haya).

El inconveniente, al igual que con los rollups optimistas en general, es que debes esperar a que pase el período de desafío antes de estar seguro de que la respuesta ha sido verificada. Sin embargo, dependiendo de cómo esté parametrizada esa red, es posible que estés esperando minutos en lugar de días.

Ejemplos: Ora, Gensyn(aunque actualmente no está especificado)

3. Criptoeconomía (ML criptoeconómico)

Aquí dejamos todas las técnicas sofisticadas y hacemos lo simple: votación ponderada por participación. Un usuario decide cuántos nodos deben ejecutar su consulta, cada uno revela sus respuestas y si hay una discrepancia entre las respuestas, se penaliza al que está fuera de lugar. Cosas estándar de oráculo, es un enfoque más directo que permite a los usuarios establecer su nivel de seguridad deseado, equilibrando costos y confianza. Si Chainlink estuviera haciendo ML, así es como lo harían.

La latencia aquí es rápida — solo necesitas una commit-revealde cada nodo. Si esto se está escribiendo en una cadena de bloques, entonces técnicamente esto puede suceder en dos bloques.

Sin embargo, la seguridad es la más débil. La mayoría de los nodos podrían elegir racionalmente colaborar si fueran lo suficientemente astutos. Como usuario, debes considerar cuánto tienen en juego estos nodos y cuánto les costaría hacer trampa. Dicho esto, el uso de algo como Eigenlayer restaking y seguridad atribuible, la red podría proporcionar efectivamente seguro en caso de una falla de seguridad.

Pero la parte interesante de este sistema es que el usuario puede especificar cuánta seguridad desea. Podrían elegir tener 3 nodos o 5 nodos en su quórum, o cada nodo en la red, o, si quieren YOLO, incluso podrían elegir n=1. La función de costo aquí es simple: el usuario paga por la cantidad de nodos que desea en su quórum. Si eliges 3, pagas 3 veces el costo de inferencia.

La pregunta complicada aquí: ¿puedes hacer seguro n=1? En una implementación ingenua, un nodo solitario debería hacer trampa cada vez si nadie está comprobando. Pero sospecho que si encriptas las consultas y haces los pagos a través de intenciones, podrías ser capaz de oscurecer al nodo que en realidad son los únicos que responden a esta tarea. En ese caso, podrías cobrarle al usuario promedio menos de 2 veces el costo de inferencia.

En última instancia, el enfoque criptoeconómico es el más simple, el más fácil y probablemente el más barato, pero es el menos atractivo y en principio el menos seguro. Pero como siempre, el diablo está en los detalles.

Ejemplos: Ritual(aunque actualmente no está especificado),Red Atoma

Por qué Verifiable ML es difícil

Tal vez te preguntes por qué no tenemos todo esto ya? Después de todo, en el fondo, los modelos de aprendizaje automático son simplemente programas de computadora muy grandes. Demostrar que los programas se ejecutaron correctamente ha sido durante mucho tiempo el pan de cada día de las blockchains.

Es por eso que estos tres enfoques de verificación reflejan las formas en que las blockchains aseguran su espacio de bloque: los ZK rollups utilizan pruebas ZK, los optimistic rollups utilizan pruebas de fraude y la mayoría de las blockchains L1 utilizan criptoeconomía. No es sorprendente que llegáramos básicamente a las mismas soluciones. Entonces, ¿qué hace que esto sea difícil cuando se aplica a ML?

ML es único porque las computaciones de ML generalmente se representan como gráficos de cálculo densos que están diseñados para ejecutarse de manera eficiente en GPUs. No están diseñados para ser probados. Entonces, si deseas probar las computaciones de ML en un entorno ZK u optimista, deben ser recompiladas en un formato que haga esto posible, lo cual es muy complejo y costoso.

La segunda dificultad fundamental con ML es el no determinismo. La verificación del programa asume que las salidas de los programas son determinísticas. Pero si ejecutas el mismo modelo en diferentes arquitecturas de GPU o versiones de CUDA, obtendrás salidas diferentes. Incluso si tienes que forzar a cada nodo a usar la misma arquitectura, todavía tienes el problema de la aleatoriedad utilizada en los algoritmos (el ruido en los modelos de difusión, o el muestreo de tokens en LLMs). Puedes solucionar esa aleatoriedad controlando laRNGsemilla. Pero incluso con todo eso, todavía te queda el último problema amenazante: la no determinismo inherente en las operaciones de punto flotante.

Casi todas las operaciones en las GPUs se realizan en números de punto flotante. Los puntos flotantes son quisquillosos porque son no asociativo — es decir, no es cierto que (a + b) + c siempre sea lo mismo que a + (b + c) para puntos flotantes. Debido a que las GPU están altamente paralelizadas, el orden de las sumas o multiplicaciones puede ser diferente en cada ejecución, lo que puede derivar en pequeñas diferencias en la salida. Es poco probable que esto afecte la salida de un LLM dada la naturaleza discreta de las palabras, pero para un modelo de imagen, puede resultar en valores de píxeles sutilmente diferentes, lo que lleva a que dos imágenes no coincidan perfectamente.

Esto significa que debes evitar el uso de puntos flotantes, lo que supone un golpe enorme al rendimiento, o debes permitir cierta flexibilidad al comparar las salidas. De cualquier manera, los detalles son complicados y no puedes abstraerlos exactamente. (Por eso, resulta que el EVM no compatiblenúmeros de punto flotante, aunque algunas blockchains como CERCAdo.)

En resumen, las redes de inferencia descentralizadas son difíciles porque todos los detalles importan, y la realidad tiene una cantidad sorprendente de detalle.

En conclusión

Ahora mismo, las blockchains y el ML claramente tienen mucho que decirse mutuamente. Uno es una tecnología que crea confianza, y el otro es una tecnología que la necesita desesperadamente. Si bien cada enfoque de inferencia descentralizada tiene sus propios compromisos, estoy muy interesado en ver qué hacen los emprendedores con estas herramientas para construir la mejor red posible.

Pero no escribí esta pieza para que sea la última palabra. Estoy pensando mucho en estas ideas en tiempo real y teniendo muchos debates vibrantes con personas. Siempre he encontrado que escribir es la mejor manera de probar mis ideas. Si estás construyendo algo en este espacio, ¡contáctame! Siempre me encantaría saber en qué estás trabajando, y si puedes demostrarme lo contrario, tanto mejor.

Descargo de responsabilidad：

1. Este artículo es reimpreso de [Investigación Dragonfly], Todos los derechos de autor pertenecen al autor original [Haseeb Qureshi]. If there are objections to this reprint, please contact the Gate Learnequipo, y lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.