Far Labs et Evolving Edge veulent transformer les PC inactifs en infrastructure d’IA

Un PC de gaming haut de gamme reste souvent inactif une fois la partie terminée. Far Labs et Evolving Edge veulent convertir cette capacité inutilisée en ressource informatique louée à des entreprises d’IA : les propriétaires fourniraient leur GPU ou leur processeur, tandis que la plateforme les rémunérerait pour des tâches vérifiées.

L’objectif n’est pas d’entraîner les modèles les plus puissants du marché, une activité qui exige généralement d’immenses grappes de serveurs, mais d’exécuter des modèles déjà entraînés — ce que l’on appelle l’inférence — afin de répondre aux demandes des utilisateurs. 26

L’idée est séduisante : exploiter du matériel déjà présent, répartir les traitements entre de nombreux endroits et réduire la dépendance aux grands centres de données. Mais la vraie difficulté ne consiste pas simplement à faire fonctionner un modèle open source sur une carte graphique domestique. Il faut démontrer que des milliers de machines différentes, connectées de façon intermittente, peuvent fournir un service rapide, sécurisé et prévisible, à un prix intéressant pour les clients comme pour les propriétaires.

Comment fonctionnerait un réseau d’inférence distribué ?

Un tel système repose généralement sur trois éléments : la demande d’un client, une couche d’orchestration qui choisit où exécuter la tâche, et un logiciel installé sur l’ordinateur hôte pour effectuer le calcul.

L’opérateur doit associer chaque requête au matériel disponible en tenant compte de la taille du modèle, de la mémoire nécessaire, de la latence, du taux de disponibilité et des limites fixées par le propriétaire de la machine.

Far Labs : routage et répartition des modèles

FAR AI, le réseau de Far Labs, se présente comme une couche d’inférence distribuée qui connecte des GPU du quotidien et achemine les requêtes en temps réel vers les nœuds les plus adaptés. La société affirme vouloir prendre en charge des usages interactifs sans dépendre entièrement de grappes centralisées. 1112

D’après les éléments disponibles, son ordonnanceur pourrait répartir un modèle entre plusieurs machines lorsqu’un seul ordinateur ne dispose pas de suffisamment de mémoire pour l’héberger entièrement. Cette approche élargirait le nombre de configurations utilisables, mais elle ajouterait aussi des échanges et des dépendances entre les nœuds. Chaque transfert supplémentaire peut peser sur le temps de réponse et la fiabilité.

Far Labs a évoqué un objectif futur de latence inférieure à 100 millisecondes pour l’inférence interactive. Il s’agit d’une cible annoncée, et non d’une mesure démontrant une performance de bout en bout. Dans des conditions réelles, il faut également compter le routage de la requête, l’attente en file, le chargement du modèle, les communications entre machines et le renvoi du résultat.

Evolving Edge : un système fondé sur Ray

Evolving Edge est décrite comme utilisant Ray, un framework de calcul distribué, pour attribuer les tâches de mise à disposition des modèles aux ordinateurs participants. Ray permet de représenter les travaux comme des acteurs gérés, puis de les planifier sur les différents nœuds d’un cluster. 56

Ray fournit des briques utiles pour exécuter des traitements distribués, mais son adoption ne règle pas à elle seule les problèmes les plus difficiles d’un tel marché. L’opérateur doit encore détecter les machines défaillantes ou surchargées, placer les modèles efficacement, gérer des configurations matérielles disparates et décider quand relancer ou dupliquer une tâche.

Peut-on sécuriser des charges de travail sur un PC domestique ?

Faire exécuter du code ou traiter des données provenant de tiers sur un ordinateur personnel pose un problème de sécurité bien plus important que l’installation d’un jeu ou d’une application classique. Un système crédible doit limiter précisément ce que les tâches peuvent consulter et la quantité de ressources qu’elles peuvent mobiliser.

Les protections envisageables comprennent notamment :

• des environnements isolés ou exécutés en bac à sable ;
• le chiffrement des données pendant leur transport ;
• des plafonds pour l’utilisation du processeur, du GPU, de la mémoire, du stockage et du réseau ;
• des limites de durée avec arrêt automatique des tâches ;
• un logiciel hôte pouvant être inspecté et mis à jour.

L’architecture de sandbox documentée par Ray utilise des environnements légers isolés au niveau du noyau pour exécuter du code non fiable et des tâches d’agents. Son implémentation expérimentale s’appuie sur gVisor et des environnements de conteneurs OCI ; les acteurs gérés par Ray peuvent planifier et contrôler les ressources du bac à sable. 17182021

Ces fonctions montrent que des mécanismes de sécurité pertinents existent dans l’écosystème logiciel. Elles ne prouvent pas que Far Labs ou Evolving Edge déploient exactement ces protections en production, que leur configuration est sûre sur les systèmes grand public ou que le nœud actif exécute bien le code inspecté par son propriétaire.

Un logiciel de nœud open source pourrait améliorer la transparence : les hôtes pourraient examiner les contrôles de ressources et les accès aux données. Cela ne constituerait toutefois pas une garantie complète. Il faudrait aussi disposer de versions reproductibles, de mises à jour signées, de permissions clairement définies, d’une procédure de réponse aux vulnérabilités et de preuves que la version déployée correspond bien au code publié.

Quelle comparaison avec Salad ?

Salad est le comparatif le plus évident, car cette entreprise exploite déjà un marché reliant des GPU grand public à des organisations à la recherche de capacité de calcul. Son modèle ne repose ni sur une blockchain ni sur un système de coordination fondé sur des jetons. 13

Far Labs met l’accent sur le routage en temps réel et l’inférence distribuée, avec la possibilité de répartir un modèle entre plusieurs nœuds. Evolving Edge est plutôt présentée comme une plateforme reposant sur un environnement distribué basé sur Ray et une bêta ouverte. Salad bénéficie, elle, d’une expérience opérationnelle sur un marché de GPU grand public ; les nouveaux entrants doivent encore montrer que leur architecture peut offrir une disponibilité, une demande, un support et une rémunération comparables.

La distinction est essentielle : la décentralisation décrit une architecture, pas un résultat de performance. Un réseau peut réunir de nombreux ordinateurs tout en restant exploité de manière centralisée, peu fiable ou non rentable.

Le principal problème non résolu : la rentabilité des hôtes

Le paiement brut reçu par un propriétaire n’est que le point de départ du calcul. Il faut aussi prendre en compte le coût de l’électricité, de la chaleur et du refroidissement, de la connexion Internet, de la maintenance, de la dépréciation du matériel et de la disponibilité réduite de la machine pour un usage personnel.

S’inscrire au réseau ne signifie pas être utilisé. Un GPU connecté, mais recevant peu de tâches rémunérées, peut générer très peu de revenus tout en consommant de l’électricité et en imposant des coûts d’administration ou d’usure. Sans barème de paiement transparent, hypothèses d’utilisation, durée des tâches et estimations de consommation, les futurs hôtes ne peuvent pas calculer un retour sur investissement crédible.

Une inférence soutenue peut aussi entraîner davantage de chaleur, d’activité des ventilateurs et d’utilisation de la mémoire. La pertinence économique dépendra du GPU concerné, du prix local de l’électricité, du taux de disponibilité, de l’intensité des tâches et de la valeur de revente du matériel. Les éléments disponibles ne permettent pas d’affirmer qu’il s’agit d’un revenu passif ou que la participation sera rentable pour la majorité des propriétaires.

Pourquoi les promesses de latence et de coût doivent être vérifiées en production

Le matériel grand public distribué peut présenter un avantage potentiel : les machines existent déjà et certains utilisateurs pourraient vouloir monétiser une capacité autrement inutilisée. Mais le réseau doit toujours financer l’orchestration, la bande passante, la supervision, les tâches échouées, la réplication, le support, la sécurité et la rémunération des hôtes.

La même prudence s’impose pour la latence. Le démarrage rapide d’un bac à sable dans un déploiement Kubernetes précis n’équivaut pas à une inférence de bout en bout en moins de 100 millisecondes sur des réseaux résidentiels. Le chiffre inférieur à 100 millisecondes cité dans la documentation de Ray concerne le démarrage d’un bac à sable dans une configuration particulière, et non une garantie pour un réseau de nœuds grand public déployé à l’échelle d’Internet. 17

Les systèmes d’IA décentralisés reposent par ailleurs généralement sur des calculs hors chaîne. Les blockchains généralistes sont mal adaptées aux volumes de calcul et de données de l’apprentissage automatique ; elles servent donc le plus souvent de couche de coordination ou de paiement, plutôt que d’exécuter directement les modèles. 1

Un grand réseau pourrait-il survivre à la disparition de nombreux nœuds ?

Un réseau distribué peut être plus résilient qu’une machine unique s’il dispose d’une capacité de secours suffisante et peut déplacer rapidement les tâches lorsque des nœuds disparaissent. Des travaux liés à Ray décrivent la reconstruction des dépendances de tâches perdues lorsque des nœuds sont retirés, ainsi que la récupération du débit lorsque ces nœuds reviennent. 30

Ce bénéfice reste conditionnel. Un réseau d’inférence en production aurait besoin de redondance, de réplication des modèles, d’un placement intelligent des tâches et d’une détection rapide des pannes. Des défaillances corrélées — panne d’un fournisseur d’accès, coupure électrique régionale, mise à jour logicielle défectueuse ou baisse des incitations financières — pourraient faire disparaître de nombreux nœuds simultanément.

La répartition d’un modèle entre plusieurs ordinateurs crée également un compromis. Elle peut rendre utilisable du matériel qui ne pourrait pas héberger seul le modèle complet, mais elle augmente le trafic réseau et le nombre de points de défaillance. L’équilibre dépendra du type de charge et de la stratégie de planification choisie par l’opérateur.

Ce que les propriétaires de GPU devraient vérifier

Tant que ces réseaux ne publient pas davantage de données, les futurs hôtes devraient considérer la participation comme un service expérimental aux revenus variables, et non comme un revenu passif garanti. Avant d’installer le logiciel d’un nœud, ils devraient rechercher :

1. une formule de rémunération claire et un historique des paiements ;
2. un taux d’utilisation mesuré, plutôt que le seul nombre de machines inscrites ;
3. des estimations réalistes de l’électricité et du refroidissement ;
4. une documentation précise des permissions et des limites de ressources ;
5. des tests de sécurité ou des audits indépendants ;
6. des mesures de latence, de disponibilité et d’échec des tâches ;
7. une procédure simple pour mettre le nœud en pause ou le supprimer.

Far Labs et Evolving Edge testent une idée crédible : utiliser du matériel grand public dispersé pour compléter la capacité centralisée d’inférence. Cette technologie pourrait convenir à certains modèles plus petits et à des usages ciblés. Mais la viabilité globale du modèle restera à démontrer tant que les entreprises ne fourniront pas de preuves que leur réseau est sécurisé, réactif, résilient et suffisamment utilisé pour rémunérer les hôtes après prise en compte de leurs coûts réels.