Dites que vous voulez exécuter un modèle linguistique de grande taille comme Llama2-70B. Un modèle aussi massif nécessite plus de 140 Go de mémoire, ce qui signifie que vous ne pouvez pas exécuter le modèle brut sur votre machine domestique. Quelles sont vos options ? Vous pourriez vous tourner vers un fournisseur de cloud, mais vous pourriez ne pas être trop enthousiaste à l'idée de confier cette charge de travail à une seule entreprise centralisée et de lui confier toutes vos données d'utilisation. Alors ce dont vous avez besoin, c'est d'une inférence décentralisée, qui vous permet d'exécuter des modèles ML sans vous appuyer sur un seul fournisseur.

Le Problème de Confiance

Dans un réseau décentralisé, il ne suffit pas de simplement exécuter un modèle et de faire confiance à la sortie. Disons que je demande au réseau d'analyser un dilemme de gouvernance en utilisant Llama2-70B. Comment savoir qu'il n'utilise pas en réalité Llama2-13B, me donnant une analyse moins bonne, et empochant la différence ?

Dans le monde centralisé, vous pourriez faire confiance à des entreprises comme OpenAI pour faire cela honnêtement parce que leur réputation est en jeu (et dans une certaine mesure, la qualité de LLM est évidente en elle-même). Mais dans le monde décentralisé, l'honnêteté n'est pas présumée, elle est vérifiée.

C'est là que l'inférence vérifiable entre en jeu. En plus de fournir une réponse à une requête, vous prouvez également qu'elle s'est exécutée correctement sur le modèle demandé. Mais comment ?

L'approche naive serait d'exécuter le modèle sous forme de smart contract on-chain. Cela garantirait certainement que la sortie était vérifiée, mais c'est extrêmement impraticable. GPT-3 représente les mots avec une dimension d'encastrement de 12 288. Si vous deviez effectuer une simple multiplication de matrices de cette taille on-chain, cela coûterait environ 10 milliards de dollars aux prix actuels du gaz - le calcul remplirait chaque bloc pendant environ un mois consécutif.

Donc non. Nous allons avoir besoin d'une approche différente.

Après avoir observé le paysage, il est clair pour moi que trois approches principales ont émergé pour s'attaquer à l'inférence vérifiable : les preuves de connaissance nulle, les preuves de fraude optimistes et la cryptographie économique. Chacune a sa propre saveur de sécurité et d'implications en termes de coût.

1. Preuves de connaissance nulle (ZK ML)

Imaginez pouvoir prouver que vous avez exécuté un modèle massif, mais la preuve est effectivement d'une taille fixe quel que soit la taille du modèle. C'est ce que promet ZK ML, grâce à la magie des ZK-SNARKs.

Bien que cela semble élégant en principe, compiler un réseau neuronal profond dans des circuits à connaissance nulle qui peuvent ensuite être prouvés est extrêmement difficile. C'est aussi massivement coûteux - au minimum, vous êtes probablement en train de regarder@ModulusLabs/chapitre-5-le-coût-de-l'intelligence-da26dbf93307">1000x coût pour l'inférence et 1000x latence (le temps pour générer la preuve), sans parler de compiler le modèle lui-même en un circuit avant que tout cela puisse se produire. En fin de compte, ce coût doit être répercuté sur l'utilisateur, donc cela finira par être très cher pour les utilisateurs finaux.

D'autre part, c'est la seule approche qui garantit cryptographiquement la correction. Avec ZK, le fournisseur de modèle ne peut pas tricher, peu importe ses efforts. Mais cela se fait à un coût élevé, ce qui rend cela impraticable pour les grands modèles à l'avenir.

Exemples: EZKL, Modulus Labs, Giza

2. Preuves de fraude optimistes (ML optimiste)

L'approche optimiste est de faire confiance, mais de vérifier. Nous supposons que l'inférence est correcte à moins qu'elle ne soit prouvée autrement. Si un nœud essaie de tricher, les "veilleurs" du réseau peuvent dénoncer le tricheur et le défier en utilisant une preuve de fraude. Ces veilleurs doivent surveiller la chaîne en permanence et réexécuter les inférences sur leurs propres modèles pour garantir que les sorties sont correctes.

Ces preuves de fraude sont Truebit-stylejeux de défis-réponses interactifs, où vous divisez à plusieurs reprises la trace d'exécution du modèle sur la chaîne jusqu'à ce que vous trouviez l'erreur.

Si cela se produit réellement, cela coûte incroyablement cher, car ces programmes sont massifs et ont d'énormes états internes — une seule inférence GPT-3 coûte environ 1 petaflop (10¹⁵ opérations en virgule flottante). Mais la théorie des jeux suggère que cela ne devrait presque jamais arriver (les preuves de fraude sont également notoirement difficiles à coder correctement, car le code est presque jamais sollicité en production).

Le côté positif est que ML optimiste est sécurisé tant qu'il y a un seul observateur honnête qui fait attention. Le coût est moins cher que ZK ML, mais rappelez-vous que chaque observateur dans le réseau relance chaque requête lui-même. À l'équilibre, cela signifie que s'il y a 10 observateurs, ce coût de sécurité doit être répercuté sur l'utilisateur, il devra donc payer plus de 10x le coût d'inférence (ou autant d'observateurs qu'il y en a).

L'inconvénient, comme c'est généralement le cas avec les rollups optimistes, est que vous devez attendre que la période de contestation se passe avant d'être sûr que la réponse est vérifiée. Cependant, selon la paramétrisation de ce réseau, vous pourriez attendre des minutes plutôt que des jours.

Exemples: Maintenant, Gensyn(bien que actuellement sous-spécifié)

3. Cryptoeconomics (Cryptoeconomic ML)

Ici, nous abandonnons toutes les techniques sophistiquées et faisons la chose simple : un vote pondéré par la mise en jeu. Un utilisateur décide combien de nœuds doivent exécuter sa requête, ils révèlent chacun leurs réponses, et s'il y a une divergence entre les réponses, celui qui fait exception est pénalisé. Des choses d'oracle standard - c'est une approche plus directe qui permet aux utilisateurs de définir leur niveau de sécurité souhaité, équilibrant coût et confiance. Si Chainlink faisait de l'apprentissage automatique, c'est ainsi qu'ils le feraient.

La latence ici est rapide — il vous suffit d'un commit-revealde chaque nœud. Si cela est écrit sur une blockchain, alors techniquement cela peut se produire dans deux blocs.

La sécurité, cependant, est la plus faible. Une majorité de nœuds pourrait rationnellement choisir de collusionner s'ils étaient suffisamment rusés. En tant qu'utilisateur, vous devez réfléchir à la quantité d'enjeu de ces nœuds et au coût que cela leur coûterait de tricher. Cela dit, l'utilisation de quelque chose comme le réinvestissement Eigenlayer et sécurité attribuable, le réseau pourrait fournir efficacement une assurance en cas de défaillance de sécurité.

Mais la partie intéressante de ce système est que l'utilisateur peut spécifier le niveau de sécurité souhaité. Ils pourraient choisir d'avoir 3 nœuds ou 5 nœuds dans leur quorum, ou chaque nœud dans le réseau — ou, s'ils veulent YOLO, ils pourraient même choisir n=1. La fonction de coût ici est simple : l'utilisateur paie pour autant de nœuds qu'ils souhaitent dans leur quorum. Si vous choisissez 3, vous payez 3x le coût d'inférence.

La question délicate ici : pouvez-vous rendre n=1 sécurisé ? Dans une implémentation naïve, un nœud isolé devrait tricher à chaque fois s'il n'y a personne pour vérifier. Mais je soupçonne que si vous cryptez les requêtes et effectuez les paiements via des intentions, vous pourriez être en mesure d'obscurcir le nœud en lui faisant croire qu'il est en fait le seul à répondre à cette tâche. Dans ce cas, vous pourriez facturer à l'utilisateur moyen moins de 2x le coût d'inférence.

Finalement, l'approche cryptéconomique est la plus simple, la plus facile et probablement la moins chère, mais c'est la moins séduisante et en principe la moins sécurisée. Mais comme toujours, le diable se cache dans les détails.

Exemples: Rituel(bien que actuellement insuffisamment spécifié),Réseau Atoma

Pourquoi la ML vérifiable est difficile

Vous pourriez vous demander pourquoi nous n'avons pas déjà tout cela ? Après tout, fondamentalement, les modèles d'apprentissage automatique ne sont que de très grands programmes informatiques. Prouver que les programmes ont été exécutés correctement est depuis longtemps le cœur de métier des blockchains.

C'est pourquoi ces trois approches de vérification reflètent les façons dont les blockchains sécurisent leur espace de bloc - les ZK rollups utilisent des preuves ZK, les rollups optimistes utilisent des preuves de fraude, et la plupart des blockchains L1 utilisent la cryptéconomie. Il n'est pas surprenant que nous soyons arrivés à des solutions pratiquement identiques. Alors, qu'est-ce qui rend cela difficile lorsqu'il est appliqué à l'apprentissage automatique ?

ML est unique car les calculs de ML sont généralement représentés sous forme de graphes de calcul denses conçus pour être exécutés efficacement sur les GPU. Ils ne sont pas conçus pour être prouvés. Donc, si vous voulez prouver les calculs de ML dans un environnement ZK ou optimiste, ils doivent être recompilés dans un format qui rend cela possible, ce qui est très complexe et coûteux.

La deuxième difficulté fondamentale avec ML est le nondéterminisme. La vérification de programme suppose que les sorties des programmes sont déterministes. Mais si vous exécutez le même modèle sur différentes architectures GPU ou versions CUDA, vous obtiendrez des sorties différentes. Même si vous devez forcer chaque nœud à utiliser la même architecture, vous avez toujours le problème de l'aléatoire utilisé dans les algorithmes (le bruit dans les modèles de diffusion, ou l'échantillonnage de jetons dans les LLM). Vous pouvez corriger ce hasard en contrôlant leRNGsemence. Mais même avec tout cela, vous vous retrouvez toujours confronté au problème final menaçant : le nondéterminisme inhérent aux opérations en virgule flottante.

Presque toutes les opérations sur les GPUs sont effectuées sur des nombres à virgule flottante. Les flottants sont capricieux car ils sont non associatif— c'est-à-dire, ce n'est pas vrai que (a + b) + c est toujours la même chose que a + (b + c) pour les points flottants. Parce que les GPU sont hautement parallélisés, l'ordre des additions ou des multiplications peut être différent à chaque exécution, ce qui peut se traduire par de petites différences de sortie. Cela est peu probable d'affecter la sortie d'un LLM étant donné la nature discrète des mots, mais pour un modèle d'image, cela peut entraîner des valeurs de pixels subtilement différentes, conduisant à ce que deux images ne correspondent pas parfaitement.

Cela signifie que vous devez éviter d'utiliser des points flottants, ce qui entraîne une énorme perte de performance, ou vous devez autoriser une certaine souplesse dans la comparaison des sorties. De toute façon, les détails sont délicats et vous ne pouvez pas les abstraire exactement. (C'est pourquoi, il s'avère, l'EVM ne prend pas en chargenombres en virgule flottante, bien que certains blockchains comme NEARdo.)

En bref, les réseaux d'inférence décentralisés sont difficiles car tous les détails comptent, et la réalité a une quantité surprenante de détails.

En Conclusion

En ce moment, les blockchains et l'IA ont clairement beaucoup à se dire. L'un est une technologie qui crée la confiance, et l'autre est une technologie qui en a grandement besoin. Bien que chaque approche de l'inférence décentralisée ait ses propres compromis, je suis très intéressé de voir ce que les entrepreneurs font avec ces outils pour construire le meilleur réseau possible.

Mais je n'ai pas écrit ce morceau pour qu'il soit la dernière parole - je réfléchis beaucoup à ces idées en temps réel et j'ai beaucoup de débats animés avec des gens. J'ai toujours trouvé que l'écriture est le meilleur moyen de tester mes idées. Si vous construisez quelque chose dans cet espace, contactez-moi ! J'aimerais toujours apprendre ce sur quoi vous travaillez - et si vous pouvez me prouver que j'ai tort, tant mieux.

Clause de non-responsabilité：

1. Cet article est repris de [Dragonfly Research], Tous les droits d'auteur appartiennent à l'auteur original [Haseeb Qureshi]. If there are objections to this reprint, please contact the Porte Apprendreéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.