Ces derniers jours, j’ai écrit sur @Acurast : on a déjà parlé de la connexion des téléphones, des points et des usages de $ACU.
Aujourd’hui, je vous propose quelque chose sur lequel vous pouvez cliquer et jouer directement.
Acurast a récemment lancé une série de démos Laya. Le modèle d’IA qui les propulse ne tourne pas sur des serveurs cloud traditionnels, mais sur un téléphone Android du réseau Acurast.
La page propose 9 démos, dont Snake, Tetris, Doom, la classification des e-mails, la modération des commentaires en direct et le blocage des injections de prompts. Une API est également disponible.
Laya n’est pas un chatbot.
Laya fait partie des modèles System One.
Il ne rédige pas de longues réponses comme ChatGPT. Donnez-lui un contenu et quelques options prédéfinies : il fera directement un choix et indiquera la probabilité de chaque option.
Par exemple :
Déterminer si un e-mail relève de la boîte de réception, du courrier indésirable ou d’une tentative d’hameçonnage
Déterminer si un commentaire contient une arnaque ou du contenu malveillant
Décider s’il faut autoriser ou bloquer cette tentative d’injection de prompt
Décider où le personnage d’un jeu doit aller ensuite
Un même modèle peut traiter ces tâches qui semblent complètement différentes, car elles reposent toutes sur la même opération : lire l’état actuel, puis choisir parmi les options proposées.
Comment fonctionne un téléphone
Laya est un modèle open source de ConvAI Innovations, distribué sous licence Apache 2.0, et pèse environ 800 Mo.
Pour pouvoir fonctionner sur un téléphone, il a été converti au format ONNX et quantifié en 8 bits. L’inférence s’effectue entièrement sur le processeur du téléphone, sans carte graphique.
L’utilisateur fait un choix sur une page web, qui envoie une requête HTTP à un téléphone du réseau Acurast. Le téléphone exécute le modèle, puis renvoie le résultat.
Selon les chiffres officiels, chaque décision prend environ 0,2 à 1 seconde.
Dans le jeu du serpent, le téléphone décide de la direction à prendre ; pour le tri des e-mails, il détermine la catégorie dans laquelle classer le message. La page affiche également le pays où se trouve l’appareil, les informations sur sa puce, le nombre de décisions déjà traitées et les enregistrements correspondants sur la blockchain.
C’est bien plus concret que de simplement affirmer que « les téléphones peuvent fournir de la puissance de calcul pour l’IA ». On peut envoyer une tâche, la faire traiter par un téléphone et recevoir le résultat : tout le processus est interactif.
Pourquoi ce type d’IA se prête aux réseaux de téléphones
Les plus grands modèles de langage nécessitent toujours un grand nombre de GPU ; un téléphone seul ne peut pas remplacer un centre de données.
Mais dans les produits réels, toutes les requêtes d’IA ne nécessitent pas un grand modèle.
Le classement des tickets de support, la modération de contenu, la détection du courrier indésirable, l’attribution d’étiquettes de risque et les décisions de première ligne des agents sont autant de tâches courtes. Chaque requête est indépendante et ne nécessite pas de conserver un long contexte.
Ces tâches peuvent être réparties entre plusieurs téléphones qui les traitent simultanément.
Si un téléphone ne peut prendre qu’un nombre limité de décisions par seconde, il suffit d’augmenter le nombre d’appareils. Acurast compte déjà plus de 335 000 téléphones connectés dans plus de 175 pays ; ces petites tâches distribuées sont donc parfaitement adaptées à cette échelle.
En outre, ces données sont souvent privées.
Les e-mails, les conversations, les informations du service client et les instructions des agents ne peuvent pas toujours être envoyés à une API centralisée. Acurast confie les tâches à des téléphones authentifiés matériellement, qui les exécutent dans un environnement TEE. Les personnes qui fournissent les appareils ne peuvent pas lire directement les données brutes des tâches.
Quel est le lien avec $ACU ?
La démo de Laya montre non seulement les capacités des téléphones, mais aussi d’où vient la demande de calcul au sein d’Acurast.
Les développeurs déploient des modèles et achètent des ressources de calcul ; les téléphones exécutent les tâches et reçoivent des récompenses correspondantes ; $ACU sert à payer le calcul sur le réseau, à récompenser les fournisseurs de calcul, ainsi qu’au staking et à la gouvernance.
Dans un exemple de déploiement de Laya publié précédemment, l’équipe indique un coût inférieur à 1 ACU par jour. Le prix réel varie selon l’appareil, la tâche et les tarifs en vigueur.
Le coût par requête est faible, mais ces modèles traitent des requêtes en continu.
Les e-mails arrivent sans arrêt, les commentaires sont constamment actualisés et les agents appellent à répétition l’interface de décision. La demande ne vient pas vraiment de la page de démonstration, mais des appels récurrents générés lorsque ces modèles sont intégrés à des produits.
Elle a aussi des limites évidentes
Laya convient pour prendre des décisions rapides, mais pas pour prendre des décisions finales à la place d’un humain.
Lors des tests officiels, la classification des e-mails était correcte pour 144 des 160 messages, soit environ 90 %. Au-delà d’une vingtaine d’options, la précision diminue. Face à des textes complexes ou à des attaques spécialement conçues, le modèle peut aussi se tromper.
Le débit d’un seul téléphone est également limité. Lorsque le nombre de requêtes augmente soudainement, la file d’attente commence à s’allonger.
Il vaut donc mieux l’utiliser en première ligne, pour classer, filtrer et acheminer les demandes, puis confier les quelques cas complexes à un modèle plus puissant ou à un humain.
Commençons par confier au téléphone les tâches qu’il peut accomplir
Avec cette démo, Acurast n’a pas cherché à prouver que les téléphones pouvaient remplacer les GPU.
Elle démontre quelque chose de plus précis : certaines requêtes d’IA réelles ne nécessitent ni de grands modèles coûteux ni un hébergement permanent sur des serveurs centralisés.
Un modèle ouvert, un vrai téléphone et une tâche de calcul vérifiable : cette chaîne fonctionne déjà.
La question est maintenant de savoir si les développeurs vont réellement y déployer des tâches récurrentes comme le tri des e-mails, la modération de contenu ou le backend d’agents. L’infrastructure est en place ; la donnée la plus importante pour la suite sera de voir si la demande de calcul suit.