Diga que deseja executar um modelo de linguagem grande como o Llama2-70B. Um modelo tão massivo requer mais de 140GB de memória, o que significa que não pode executar o modelo bruto no seu computador doméstico. Quais são as suas opções? Pode recorrer a um fornecedor de nuvem, mas pode não estar muito inclinado a confiar numa única empresa centralizada para lidar com esta carga de trabalho para si e recolher todos os seus dados de utilização. Então, o que precisa é de inferência descentralizada, que lhe permite executar modelos de ML sem depender de nenhum fornecedor único.

O Problema da Confiança

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

No mundo centralizado, pode confiar que empresas como a OpenAI estão a fazer isto honestamente porque a sua reputação está em jogo (e até certo ponto, a qualidade da LLM é evidente por si só). Mas no mundo descentralizado, a honestidade não é assumida — é 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 - a computação encheria todos os blocos por cerca de um mês inteiro.

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

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

1. Provas de Conhecimento Zero (ZK ML)

Imagine poder provar que executou um modelo massivo, mas a prova é efetivamente de um tamanho fixo, independentemente de quão grande seja o modelo. É isso que o ZK ML promete, através da magia dos ZK-SNARKs.

Embora pareça elegante em princípio, compilar uma rede neural profunda em circuitos de conhecimento zero que podem então ser comprovados é extremamente difícil. Também é massivamente caro — no mínimo, provavelmente está a olhar 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), para não falar da compilação do próprio modelo num circuito antes que qualquer coisa possa acontecer. No final, esse custo tem de ser repassado para o utilizador, por isso acabará por ser muito caro para os utilizadores finais.

Por outro lado, esta é a única abordagem que garante criptograficamente a correção. Com ZK, o fornecedor do modelo não pode trapacear, não importa o quanto tente. Mas isso tem 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 se prove o contrário. Se um nó tentar trapacear, os "observadores" na rede podem chamá-lo de trapaceiro e desafiá-los usando uma prova de fraude. Esses observadores têm que estar observando a cadeia o tempo todo e reexecutando as inferências em seus próprios modelos para garantir que as saídas estejam corretas.

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

Se isso alguma vez realmente acontecer, será incrivelmente custoso, uma vez que estes 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 (as provas de fraude também são notoriamente difíceis de codificar corretamente, uma vez 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 que esteja prestando atenção. O custo é mais barato do que o ZK ML, mas lembre-se de que cada observador na rede está executando novamente cada consulta por si próprios. 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 da inferência (ou quantos observadores houver).

O inconveniente, como geralmente acontece com rollups otimistas, é que você tem que esperar o período de desafio passar antes de ter certeza de que a resposta está verificada. No entanto, dependendo de como a rede está parametrizada, você pode estar à espera de minutos em vez de dias.

Exemplos: Now, Reencontro(embora atualmente insuficientemente especificado)

3. Criptoeconomia (ML Criptoeconómico)

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

A latência aqui é rápida — só precisa de uma commit-revealde cada nó. Se isto estiver a ser escrito para uma blockchain, então tecnicamente isto pode acontecer em dois blocos.

A segurança, no entanto, é a mais fraca. A maioria dos nós poderia escolher racionalmente colaborar se fossem suficientemente astutos. Como utilizador, tem de ponderar quanto é que estes nós têm em jogo e quanto lhes custaria fazer batota. Dito isto, usar algo como Eigenlayer para reestacar e segurança atribuível, a rede poderia fornecer eficazmente seguro no caso de uma falha de segurança.

Mas a parte interessante deste sistema é que o usuário pode especificar quanto de segurança deseja. Eles podem escolher ter 3 nós ou 5 nós em seu quórum, ou cada nó na rede - ou, se quiserem YOLO, até mesmo 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 da inferência.

A questão complicada aqui: você pode tornar n=1 seguro? Numa implementação ingénua, um nó solitário deveria trapacear sempre se ninguém estiver a verificar. Mas suspeito que, se encriptar as consultas e fizer os pagamentos através de intenções, talvez consiga obscurecer ao nó que na realidade são o único a responder a esta tarefa. Nesse caso, poderá cobrar ao utilizador médio menos do que 2x o custo de inferência.

Em última análise, a abordagem criptoecômica é a mais simples, a mais fácil e provavelmente a mais barata, mas é a menos sexy e, em princípio, a menos segura. Mas como sempre, o diabo está nos detalhes.

Exemplos: Ritual(embora atualmente mal especificado),Rede Atoma

Por que Verifiable ML é Difícil

Pode perguntar-se por que é que ainda não temos isto tudo? Afinal, no fundo, os modelos de aprendizagem automática são apenas programas de computador realmente grandes. Provar que os programas foram executados corretamente tem sido há muito o pão e manteiga das blockchains.

É por isso que essas três abordagens de verificação refletem as maneiras como as blockchains garantem seu espaço de bloco - os ZK rollups usam provas ZK, os optimistic rollups usam provas de fraude e a maioria das blockchains L1 usa criptoeconomia. Não é surpresa que tenhamos chegado 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 são geralmente representadas como gráficos de computação densos que são projetados para serem executados eficientemente 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 devem ser recompiladas em um formato que torne isso possível - o que é muito complexo e caro.

A segunda dificuldade fundamental com o ML é o não determinismo. A verificação do programa pressupõe que as saídas dos programas são determinísticas. Mas se executar o mesmo modelo em diferentes arquiteturas de GPU ou versões do CUDA, obterá diferentes saídas. Mesmo que tenha de forçar cada nó a utilizar a mesma arquitetura, ainda tem o problema da aleatoriedade utilizada nos algoritmos (o ruído nos modelos de difusão, ou a amostragem de tokens em LLMs). Pode corrigir essa aleatoriedade controlando a RNGseed. 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. Como as GPUs são altamente paralelizadas, a ordem das adições ou multiplicações pode ser diferente em cada execução, o que pode causar pequenas diferenças na saída. Isso é improvável de afetar a saída de um LLM, dada a natureza discreta das palavras, mas para um modelo de imagem, pode resultar em valores de pixel ligeiramente diferentes, levando a que duas imagens não coincidam perfeitamente.

Isto significa que ou precisa de evitar o uso de pontos flutuantes, o que significa um golpe enorme no desempenho, ou precisa de permitir alguma flexibilidade na comparação de saídas. De qualquer forma, os detalhes são complicados, e não pode exatamente abstrai-los. (Por isso, acontece que a EVM não suportanúmeros de ponto flutuante, embora algumas blockchains como NEAR do.)

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

Em Conclusão

Neste momento, as blockchains e a aprendizagem automática claramente têm muito a dizer um ao outro. Uma é uma tecnologia que cria confiança e a outra é uma tecnologia que precisa muito dela. Embora cada abordagem à inferência descentralizada tenha seus próprios compromissos, estou muito interessado em ver o que os empreendedores fazem com essas ferramentas para construir a melhor rede possível.

Mas não escrevi este texto para ser a última palavra - estou a refletir muito sobre estas ideias em tempo real e a ter muitos debates vibrantes com as pessoas. Sempre achei que escrever é a melhor maneira de testar as minhas ideias. Se estás a construir algo neste espaço, entra em contacto! Gostaria sempre de saber no que estás a trabalhar - e se conseguires provar que estou errado, tanto melhor.

Aviso Legal：

1. Este artigo é reproduzido de [Pesquisa Dragonfly], Todos os direitos de autor pertencem ao autor original [Haseeb Qureshi]. Se houver objeções a esta reimpressão, por favor entre em contato com o Gate Learnequipa e eles vão tratar disso prontamente.
2. Responsabilidade de Isenção: 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 equipa Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.