SwarmLLM vient de publier sa version 0.2.0, un projet open source qui répartit un même grand modèle de langage entre plusieurs navigateurs exécutés sur des appareils différents. La version s'accompagne d'une démonstration datée du 7 septembre avec Qwen 3.8 27B partagé entre un MacBook et un iPhone, ainsi que du moteur WebGPU, du transport WebRTC, des journaux de mesure, des tests et d'un modèle de menace documenté.
L'intérêt principal n'est pas la vitesse annoncée par le projet, faute de reproduction indépendante. Le changement d'architecture est plus tangible : chaque appareil ne charge qu'une tranche de couches, puis transmet directement l'état intermédiaire au navigateur suivant. De la mémoire et du calcul disponibles sur plusieurs machines peuvent ainsi être réunis sans installer un environnement d'inférence natif sur chaque nœud.
Un modèle peut dépasser la mémoire de chaque appareil
Dans SwarmLLM, la tokenisation, les embeddings, la tête finale du modèle et l'échantillonnage restent sur le navigateur hôte. Les blocs du modèle sont découpés en plages de couches contiguës. Une fois sa plage calculée, un appareil convertit l'état caché en f16 et l'envoie au participant suivant par un canal WebRTC.
Pour Qwen 3.8 27B, la documentation indique un état de 5 120 valeurs, soit environ 10 Ko à transmettre à chaque étape. Chaque appareil télécharge uniquement les poids correspondant aux couches qui lui sont attribuées et les conserve dans le cache du navigateur. Il ne s'agit donc pas de transformer plusieurs machines en un seul GPU, mais de mettre en commun leur capacité mémoire et une partie de leur puissance de calcul.
La version 0.2.0 rend cette organisation accessible dans une simple « salle » ouverte dans le navigateur. Par rapport à des solutions qui demandent Python, un serveur RPC ou un binaire sur chaque machine, cette approche réduit fortement le coût de mise en place. Elle peut donc intéresser des laboratoires, des formations ou de petites équipes disposant d'un parc matériel hétérogène.
Les chiffres de performance doivent rester attribués au projet
SwarmLLM rapporte 9,0 tokens par seconde en décodage simple et 16,1 avec décodage spéculatif sur un NVIDIA GB10. Le journal compare ces chiffres à 8,0 tokens par seconde pour une version précise de llama.cpp utilisant le même fichier GGUF sur la même machine. Le projet rapporte aussi 7,7 tokens par seconde lorsque le modèle 27B est partagé entre un MacBook et un iPhone sur le même réseau Wi-Fi, tandis que la vidéo de la version 0.2.0 affiche 10,7 tokens par seconde sur une génération de 400 tokens.
Ces mesures n'ont pas été reproduites par un tiers. Elles ne permettent donc pas d'affirmer que l'inférence dans le navigateur est globalement plus rapide qu'une exécution native. Le même journal montre d'ailleurs une limite importante : sur le GB10, llama.cpp aurait atteint 377 tokens par seconde pour le traitement initial du prompt, contre 44 pour SwarmLLM. Le projet documente également une baisse sensible lorsque le nombre de relais entre navigateurs augmente.
La conclusion utile porte donc sur la possibilité de répartir la mémoire et le déploiement, pas sur une supériorité générale en vitesse.
La spéculation sert surtout à amortir les allers-retours réseau
Une génération autorégressive distribuée se heurte vite à la latence : si chaque token doit traverser plusieurs appareils, le réseau peut devenir plus coûteux que le calcul. SwarmLLM utilise la tête de prédiction multi-token de Qwen pour proposer plusieurs tokens à la fois, puis les fait vérifier en lot par le modèle principal.
La documentation précise que seuls les tokens confirmés par le tronc du modèle sont conservés. Au premier désaccord, le token calculé par le modèle principal est retenu et les états récurrents sont restaurés depuis une copie. Les tests du projet imposent que le chemin spéculatif produise la même séquence que le décodage simple avec le même échantillonneur.
Ce choix vise directement le problème du réseau. Dans un moteur réparti entre navigateurs, accélérer les noyaux de calcul ne suffit pas : chaque tour de réseau doit transporter davantage de travail utile.
Le périmètre de confiance est la salle entière
La documentation de sécurité est explicite. Le serveur de signalisation ne transporte pas les données du modèle et WebRTC chiffre les communications entre navigateurs. En revanche, tous les participants d'une salle voient la conversation, et les états intermédiaires ne doivent pas être considérés comme une protection de confidentialité.
Surtout, la version actuelle ne vérifie pas qu'un appareil distant a exécuté correctement les couches qui lui ont été confiées. Un participant malveillant pourrait renvoyer des activations modifiées. Le projet place l'audit des calculs dans sa feuille de route et ne présente pas les salles ouvertes à des inconnus comme sûres aujourd'hui.
La disparition d'un fournisseur central ne supprime donc pas la confiance : elle la déplace vers chaque navigateur participant. Pour des données sensibles, il faut savoir non seulement où le modèle tourne, mais aussi qui est autorisé à prendre part au calcul.
Le cas d'usage le plus crédible est un pool local temporaire
L'analyse d'Aipolix est que SwarmLLM est aujourd'hui plus convaincant comme couche temporaire de calcul local que comme substitut à un nuage décentralisé. Une équipe peut réunir pour quelques heures des appareils déjà présents, exécuter un modèle qui ne tiendrait pas sur une seule machine, puis dissoudre le groupe sans déployer de logiciel sur chaque nœud.
Trois contrôles deviennent alors essentiels : figer l'artefact exact du modèle, limiter la salle à des participants de confiance et conserver la topologie ainsi que les conditions de mesure lorsqu'une comparaison de performance compte. La version 0.2.0 ne vérifie pas encore le calcul des pairs et le contrôle d'intégrité cryptographique des fichiers de modèle reste annoncé pour plus tard.
Le projet est encore jeune et de petite taille, et ses performances devront être reproduites indépendamment. Mais son code montre déjà une forme de déploiement concrète : distribuer l'inférence locale au niveau du navigateur, en échangeant la limite de mémoire d'une seule machine contre des contraintes de latence réseau et de confiance entre participants.