Fable5 devient cher, les GPU locaux manquent : DRIFT répartit l’exécution d’un LLM entre Mac et CUDA
(github.com/TaewoooPark)Les LLM s’éloignent des particuliers, et DRIFT y répond en répartissant un même LLM sur plusieurs appareils personnels.
DRIFT est un projet open source qui exécute un même LLM en le répartissant, couche par couche, sur plusieurs appareils personnels.
Aujourd’hui, pour un développeur individuel qui veut manipuler l’IA directement, les deux options sont difficiles. L’accès aux modèles de pointe comme Fable5 est de plus en plus restreint, tandis que les modèles locaux, malgré la promesse de “tourner sur mon ordinateur”, exigent en pratique une mémoire GPU assez élevée et une configuration conséquente. Même lorsque les modèles sont ouverts, la capacité de les exécuter à une échelle suffisante reste concentrée sur quelques matériels et plateformes. Au final, cela crée un environnement d’IA centralisé et limite fortement le niveau d’accès des particuliers aux technologies les plus récentes.
La question posée par DRIFT est simple.
Si une seule machine ne peut pas prendre en charge tout le modèle, plusieurs appareils personnels ne pourraient-ils pas exécuter ensemble un même modèle ?
DRIFT exécute un même modèle en combinant le GPU Apple d’un Mac (MPS) et le GPU NVIDIA d’un PC Windows/Linux (CUDA). Il découpe le modèle au niveau des couches de décodeur et n’envoie entre les nœuds ni le modèle complet ni le cache KV, mais seulement les hidden states. La communication ne passe pas par des objets PyTorch ni des handles CUDA, mais par un protocole neutre en octets basé sur TCP + msgpack.
Voici ses principales fonctionnalités.
- Partitionnement automatique d’un même LLM au niveau des couches de décodeur
- Exécution hybride Mac MPS et NVIDIA CUDA
- Utilisation de TCP + msgpack pour la communication entre nœuds
- Atténuation du goulot d’étranglement de bande passante du nœud head grâce à un mode chaîne P2P
- Wire chiffré basé sur X25519 et ChaCha20-Poly1305
- Vérification du travail de chaque nœud via des reçus signés Ed25519
- Failover fondé sur re-split + replay lorsqu’un nœud tombe en cours d’exécution
- API HTTP compatible OpenAI
- Partitionnement théoriquement possible jusqu’au nombre de couches de décodeur. Avec Qwen par défaut, un même modèle peut être réparti sur jusqu’à 28 machines ; avec Gemma, jusqu’à 35 machines. Le point d’équilibre réaliste actuel se situe autour de 2 à 4 machines
Parmi les projets qui résolvent des problèmes similaires, on trouve Exo et llama.cpp RPC. Exo permet de regrouper des machines Apple Silicon comme un cluster local, mais la communication entre nœuds étant liée à MLX, il est difficile de sortir de l’écosystème Apple. llama.cpp RPC peut exploiter plusieurs backends, mais il s’agit d’une approche RPC attachée au runtime ggml/llama.cpp. La différence de DRIFT est d’avoir fait remonter la frontière entre les nœuds vers un protocole d’octets neutre, plutôt que de la lier à un runtime ML particulier. L’objectif est donc d’intégrer, dans l’exécution d’un même modèle, des combinaisons normalement difficiles à placer dans un même runtime distribué, comme Apple MPS et NVIDIA CUDA.
L’implémentation de DRIFT repose sur Python et PyTorch, mais le contrat entre les nœuds est défini d’une manière qui ne dépend pas de PyTorch. Le chargement et l’exécution des modèles utilisent Hugging Face Transformers, safetensors et PyTorch MPS/CUDA, tandis que l’extérieur expose une API compatible OpenAI basée sur Starlette/Uvicorn. La communication interne est enveloppée dans un framing msgpack et une couche de chiffrement, avec une conception qui vise à séparer “quel modèle tourne sur quel appareil” de “quels octets les nœuds s’échangent”.
À titre personnel, ce qui rend ce projet intéressant est qu’il ne commence pas à parler de “décentralisation de l’IA” par l’économie des tokens ou par de vastes réseaux. Ce qu’il faut d’abord, c’est une couche d’exécution permettant réellement à des appareils personnels de participer à l’exécution d’un même modèle. Il faut pouvoir vérifier qui a calculé quelle couche, récupérer lorsqu’un nœud disparaît et disposer d’une structure qui ne soit pas liée à un fournisseur ou à un datacenter précis, afin de construire ensuite un réseau plus vaste par-dessus.
DRIFT n’est pas un projet qui met la vitesse en avant. Sa priorité est plutôt l’exactitude. Il met l’accent sur la vérification que l’exécution distribuée produit la même réponse que l’exécution sur une seule machine. D’après le README, il a franchi plusieurs tests de parité avec Qwen2.5-1.5B-Instruct, et inclut aussi des expériences mêlant Mac MPS et NVIDIA CUDA.
Alors que les modèles d’IA de pointe se ferment de plus en plus et que l’IA locale exige encore du matériel coûteux, DRIFT pose une question très concrète.
Quand les modèles frontier s’éloignent des clients particuliers, peut-on mutualiser les ressources individuelles pour en augmenter la puissance ?
1 commentaires
DRIFT est un projet qui cherche d’abord à déterminer s’il est possible de répartir correctement l’exécution d’un même LLM sur des appareils personnels hétérogènes, plutôt que de faire la course à la vitesse !
J’aimerais recueillir vos avis éclairés et vos retours, notamment sur la question de savoir si ses différences par rapport à Exo / llama.cpp RPC / Petals sont suffisamment convaincantes, ainsi que sur les points supplémentaires exigés en production pour une exécution hybride MPS↔CUDA.