Diga que você quer executar um modelo de linguagem grande como Llama2-70B. Um modelo tão massivo requer mais de 140GB de memória, o que significa que você não pode executar o modelo bruto em sua máquina doméstica. Quais são suas opções? Você pode recorrer a um provedor de nuvem, mas pode não estar muito inclinado a confiar em uma única empresa centralizada para lidar com essa carga de trabalho para você e absorver todos os seus dados de uso. Então, o que você precisa é de inferência descentralizada, que permite que você execute modelos de ML sem depender de nenhum provedor único.

O Problema da Confiança

Em uma rede descentralizada, não é suficiente apenas executar um modelo e confiar na saída. Digamos que eu peça à rede para analisar um dilema de governança usando Llama2–70B. Como eu sei que na verdade não está usando Llama2–13B, me dando uma análise pior e embolsando a diferença?

No mundo centralizado, você pode confiar que empresas como a OpenAI estão fazendo isso honestamente porque sua reputação está em jogo (e, em certa medida, a qualidade do LLM é autoevidente). Mas no mundo descentralizado, a honestidade não é presumida - é verificada.

Aqui é onde a inferência verificável entra em jogo. Além de fornecer uma resposta a uma consulta, você também prova que ela foi executada corretamente no modelo solicitado. Mas como?

A abordagem ingênua seria executar o modelo como um contrato inteligente on-chain. Isso definitivamente garantiria que a saída fosse verificada, mas isso é extremamente impraticável. O GPT-3 representa palavras com uma dimensão de incorporação de 12.288. Se você fizesse uma única multiplicação de matriz desse tamanho on-chain, custaria cerca de $10 bilhões aos preços atuais de gás — o cálculo preencheria cada bloco por cerca de um mês.

Então, não. Vamos precisar de uma abordagem diferente.

Depois de observar a paisagem, está claro para mim que surgiram três abordagens principais para lidar com a inferência verificável: provas de conhecimento zero, provas de fraude otimistas e criptoeconomia. Cada um tem sua própria característica de segurança e implicações de custo.

1. Provas de Conhecimento Zero (ZK ML)

Imagine ser capaz de provar que você executou um modelo massivo, mas a prova é efetivamente de um tamanho fixo, independentemente de quão grande seja o modelo. Isso é o que o ZK ML promete, através da magia do ZK-SNARKs.

Embora pareça elegante na teoria, compilar uma rede neural profunda em circuitos de conhecimento zero que podem então ser provados é extremamente difícil. Também é extremamente caro - no mínimo, você provavelmente está olhando para@ModulusLabs/capítulo-5-o-custo-da-inteligência-da26dbf93307">Custo 1000x para inferência e 1000x de latência (o tempo para gerar a prova), sem falar na compilação do próprio modelo em um circuito antes que qualquer coisa possa acontecer. No final, esse custo terá que ser repassado ao usuário, então isso acabará sendo muito caro para os usuários finais.

Por outro lado, esta é a única abordagem que garante criptograficamente a correção. Com ZK, o provedor do modelo não pode trapacear, não importa o quanto tente. Mas isso é feito a custos enormes, tornando isso impraticável para grandes modelos num futuro previsível.

Exemplos: EZKL, Modulus Labs, Giza

2. Provas de Fraude Otimistas (ML Otimista)

A abordagem otimista é confiar, mas verificar. Assumimos que a inferência está correta, a menos que seja provado o contrário. Se um nó tentar trapacear, os 'observadores' na rede podem denunciar o trapaceiro e desafiá-lo usando uma prova de fraude. Esses observadores precisam estar monitorando a cadeia o tempo todo e reexecutando as inferências em seus próprios modelos para garantir que as saídas estejam corretas.

Essas provas de fraude são Estilo Truebitjogos desafio-resposta interativos, onde você bissecta repetidamente o rastro de execução do modelo on-chain até encontrar o erro.

Se isso realmente acontecer, é incrivelmente caro, já que esses programas são massivos e têm estados internos enormes - uma única inferência GPT-3 custa cerca de 1 petaflop (10¹⁵ operações de ponto flutuante). Mas a teoria dos jogos sugere que isso quase nunca deve acontecer (provas de fraude também são notoriamente difíceis de codificar corretamente, já que o código quase nunca é executado em produção).

O lado positivo é que o ML otimista é seguro, desde que haja um único observador honesto prestando atenção. O custo é mais barato do que o ZK ML, mas lembre-se de que cada observador na rede está reexecutando cada consulta por si só. No equilíbrio, isso significa que se houver 10 observadores, esse custo de segurança deve ser repassado ao usuário, então eles terão que pagar mais do que 10x o custo de inferência (ou quantos observadores houverem).

A desvantagem, assim como em rollups otimistas em geral, é que você precisa esperar o período de desafio passar antes de ter certeza de que a resposta foi verificada. Dependendo de como essa rede é parametrizada, no entanto, você pode estar esperando minutos em vez de dias.

Exemplos: Ora, Gensyn(embora atualmente insuficientemente especificado)

3. Criptoeconomia (ML Criptoeconômico)

Aqui abandonamos todas as técnicas sofisticadas e fazemos a coisa simples: votação ponderada pela participação. Um usuário decide quantos nós devem executar sua consulta, cada um revela suas respostas, e se houver uma discrepância entre as respostas, o estranho é cortado. Coisas de oráculo padrão — é uma abordagem mais direta que permite aos usuários definir seu nível de segurança desejado, equilibrando custo e confiança. Se a Chainlink estivesse fazendo ML, é assim que eles fariam.

A latência aqui é rápida — você só precisa de um commit-revealde cada nó. Se isso estiver sendo gravado em um blockchain, então tecnicamente isso pode acontecer em dois blocos.

A segurança, no entanto, é a mais fraca. A maioria dos nós poderia escolher racionalmente colaborar se fosse astuta o suficiente. Como usuário, você precisa pensar em quanto esses nós têm em jogo e quanto lhes custaria trapacear. Dito isso, usando algo como o restaking Eigenlayer e segurança atribuível, a rede poderia fornecer efetivamente seguro no caso de uma falha de segurança.

Mas a parte legal deste sistema é que o usuário pode especificar o quanto de segurança deseja. Eles podem optar por ter 3 nós ou 5 nós em seu quórum, ou cada nó na rede — ou, se quiserem YOLO, até poderiam escolher n=1. A função de custo aqui é simples: o usuário paga por quantos nós deseja em seu quórum. Se você escolher 3, pagará 3x o custo de inferência.

A questão complicada aqui: você consegue tornar n=1 seguro? Em uma implementação ingênua, um nó solitário deveria trapacear toda vez se ninguém estiver verificando. Mas suspeito que se você criptografar as consultas e fizer os pagamentos por meio de intenções, pode ser capaz de obscurecer para o nó que eles são realmente os únicos a responder a essa tarefa. Nesse caso, você pode cobrar do usuário médio menos do que o custo de inferência 2x.

No final das contas, a abordagem criptoecômica é a mais simples, a mais fácil e provavelmente a mais barata, mas é a menos sexy e, princípio, a menos segura. Mas como sempre, o diabo está nos detalhes.

Exemplos: Ritual(embora atualmente subespecificado),Rede Atoma

Por que Verifiable ML é Difícil

Você pode se perguntar por que ainda não temos tudo isso? Afinal, no fundo, os modelos de aprendizado de máquina são apenas programas de computador realmente grandes. Provar que os programas foram executados corretamente há muito tempo é o pão com manteiga das blockchains.

É por isso que esses três métodos de verificação refletem as maneiras como as blockchains garantem seu espaço de bloco - os ZK rollups usam provas ZK, os rollups otimistas usam provas de fraude e a maioria das blockchains L1 usa criptoeconomia. Não é surpresa que chegamos basicamente às mesmas soluções. Então, o que torna isso difícil quando aplicado ao ML?

ML é único porque as computações de ML geralmente são representadas como grafos de computação densos que são projetados para serem executados de forma eficiente em GPUs. Eles não são projetados para serem provados. Portanto, se você deseja provar as computações de ML em um ambiente ZK ou otimista, elas precisam ser recompiladas em um formato que torne isso possível - o que é muito complexo e caro.

A segunda dificuldade fundamental com ML é o não determinismo. A verificação do programa assume que as saídas dos programas são determinísticas. Mas se você executar o mesmo modelo em diferentes arquiteturas de GPU ou versões CUDA, você obterá saídas diferentes. Mesmo se você tiver que forçar cada nó a usar a mesma arquitetura, ainda terá o problema da aleatoriedade usada nos algoritmos (o ruído nos modelos de difusão, ou amostragem de tokens em LLMs). Você pode corrigir essa aleatoriedade controlando a RNG semente. Mas mesmo com tudo isso, você ainda fica com o problema final ameaçador: o não determinismo inerente às operações de ponto flutuante.

Quase todas as operações em GPUs são feitas em números de ponto flutuante. Os pontos flutuantes são delicados porque são não associativo— isto é, não é verdade que (a + b) + c seja sempre o mesmo que a + (b + c) para pontos flutuantes. Por serem altamente paralelos, a ordem das adições ou multiplicações pode ser diferente em cada execução, o que pode se propagar em pequenas diferenças na saída. Isso é improvável que afete a saída de um LLM dada a natureza discreta das palavras, mas para um modelo de imagem, pode resultar em valores de pixel sutilmente diferentes, levando duas imagens a não corresponderem perfeitamente.

Isso significa que você precisa evitar o uso de pontos flutuantes, o que representa um golpe enorme para o desempenho, ou você precisa permitir alguma flexibilidade na comparação de saídas. De qualquer forma, os detalhes são complicados e você não pode exatamente abstraí-los. (É por isso que, no final das contas, o EVM não suportanúmeros de ponto flutuante, embora algumas blockchains como NEARdo.)

Em resumo, as redes de inferência descentralizadas são difíceis porque todos os detalhes importam ea realidade tem uma quantidade surpreendente de detalhes.

Em Conclusão

Neste momento, as blockchains e a ML claramente têm muito a dizer uma à outra. Uma é uma tecnologia que cria confiança, e a outra é uma tecnologia que está extremamente necessitada dela. Embora cada abordagem para inferência descentralizada tenha seus próprios compromissos, estou muito interessado em ver o que os empreendedores farão com essas ferramentas para construir a melhor rede possível.

Mas eu não escrevi este texto para ser a última palavra - estou pensando muito sobre essas ideias em tempo real e tendo muitos debates vibrantes com as pessoas. Sempre achei que escrever é a melhor maneira de testar minhas ideias. Se você está construindo algo neste espaço, entre em contato! Eu sempre adoraria saber no que você está trabalhando - e se você puder me provar errado, melhor ainda.

Aviso:

1. Este artigo é reproduzido de [Pesquisa Dragonfly], Todos os direitos autorais pertencem ao autor original [Haseeb Qureshi]. Se houver objeções a esta reimpressão, por favor, entre em contato com o Gate Learnequipe, e eles vão lidar com isso prontamente.
2. Responsabilidade Legal: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.