PowerInfer : faire tourner un LLM sur un seul GPU grand public en séparant neurones chauds et neurones froids

Le problème : un GPU de 24 Go face à des modèles qui n'y tiennent pas

Un modèle de 40 milliards de paramètres en FP16 occupe environ 80 Go. Sur une RTX 4090 dotée de 24 Go, il ne rentre pas. Les solutions habituelles consistent à quantifier agressivement, à décharger des couches vers le CPU, ou à accepter un débit de quelques tokens par seconde. PowerInfer attaque le problème par un autre angle : plutôt que de réduire la précision ou de découper le modèle, il exploite la distribution des activations. La documentation décrit une distribution en loi de puissance des activations de neurones : un petit sous-ensemble, les neurones dits chauds, s'active sur presque toutes les entrées, tandis que la majorité, les neurones froids, dépend du contenu. Ce constat structure tout le reste du moteur. Le public visé est clair : un développeur ou une équipe qui veut servir un LLM en local sur une machine personnelle, sans louer d'A100, et qui accepte de choisir son modèle en fonction de cette contrainte architecturale.

La mécanique : précharger les neurones chauds, calculer les froids sur le CPU

Le principe est un moteur hybride. Les neurones chauds sont préchargés sur le GPU pour un accès rapide. Les neurones froids sont calculés sur le CPU. Cette répartition réduit simultanément la mémoire GPU nécessaire et le volume de transferts entre CPU et GPU, puisque les poids froids ne traversent jamais le bus PCIe. Le README mentionne deux composants supplémentaires : des prédicteurs adaptatifs et des opérateurs sparse neuron-aware. Les prédicteurs anticipent quels neurones vont s'activer, ce qui permet de décider de la cible d'exécution sans synchronisation bloquante. Les opérateurs sparse exploitent la sparsité au niveau du calcul, pas seulement au niveau du stockage. Ce qui rend l'ensemble possible, c'est que le modèle doit être ReLU-sparse : une activation ReLU produit naturellement des zéros, et c'est cette sparsité que le moteur exploite. Sur un modèle dense avec GELU ou SwiGLU, l'hypothèse de départ s'effondre et la répartition chaud/froid n'a plus de sens. C'est la contrainte structurante de tout l'outil, et elle conditionne le choix du modèle avant même de penser au matériel.

Compiler et lancer : ce que la documentation donne réellement

Le README cite CMake comme prérequis, avec une liste de dépendances tronquée à cet endroit du texte fourni. La section Getting Started renvoie à trois étapes : Installation, Model Weights, Inference. Les commandes exactes de compilation ne figurent pas dans l'extrait disponible, donc je ne les reproduis pas : il faut se référer au README complet du dépôt. Ce que la documentation précise, en revanche, c'est la compatibilité avec l'arborescence llama.cpp. Le README indique que la plupart des répertoires examples/ s'utilisent comme avec llama.cpp, notamment le serveur et la génération par lots. C'est un point pratique important : si vous avez déjà des scripts qui pointent vers ces binaires, l'adaptation est limitée. Les plateformes testées sont listées explicitement : x86-64 avec AVX2 sous Linux et Windows, avec ou sans GPU NVIDIA, et les puces Apple M en CPU uniquement sous macOS. Le support Metal est annoncé comme à venir, pas comme disponible. Les modèles compatibles cités sont Falcon-40B, la famille Llama 2, la famille ProSparse Llama 2 et Bamboo-7B. Le support AMD via ROCm est mentionné dans les actualités du 17 mai 2024.

Le piège de la compatibilité llama.cpp

Le README est honnête sur un point qui mérite d'être répété : PowerInfer accepte les poids de modèles llama.cpp, mais sans gain de performance. Autrement dit, charger un GGUF dense classique fonctionne, mais vous perdez tout l'intérêt du projet. C'est une compatibilité de commodité, pas de performance. Ce détail a des conséquences pratiques : un utilisateur qui teste PowerInfer avec son modèle llama.cpp habituel conclura que le moteur est lent, alors que le problème vient du modèle, pas du moteur. La documentation ne propose pas de mécanisme pour détecter ou signaler cette situation. Elle ne fournit pas non plus de tableau indiquant quel gain attendre selon le taux de sparsité du modèle. Les chiffres cités dans l'abstract (13,20 tokens/s en moyenne, pic à 29,08 tokens/s, jusqu'à 11,69x plus rapide que llama.cpp) proviennent de l'évaluation des auteurs sur des modèles spécifiques. Ce ne sont pas des garanties transposables à votre configuration. Le README précise d'ailleurs que sur macOS, faute d'optimisation, l'amélioration n'est pas significative actuellement.

Ce que le dépôt ne dit pas

Plusieurs zones restent floues dans le matériel fourni. Aucune release n'a été récupérée, ce qui signifie qu'il n'existe pas de version taguée à installer : il faut compiler depuis la branche main. Le rythme de publication est irrégulier, avec des entrées d'actualités espacées de plusieurs mois, et le dernier push remonte au 11 mai 2026. Le Project Kanban est cité comme référence pour les priorités de développement, mais son contenu n'est pas accessible dans l'extrait. La question de la maintenance est donc ouverte : le projet est actif, mais l'absence de releases et la dépendance à des modèles ReLU-sparse spécifiques créent un risque de friction à la mise à jour. Si vous adoptez PowerInfer, vous suivez la branche main, ce qui implique de recompiler à chaque changement significatif et de vérifier que les modèles que vous utilisez restent supportés.

Face à llama.cpp : deux philosophies différentes

llama.cpp est l'alternative la plus évidente, et le README lui-même s'y réfère comme point de comparaison. La différence d'approche est nette. llama.cpp mise sur la quantification (Q4, Q5, Q8) pour réduire l'empreinte mémoire, et fonctionne avec n'importe quel modèle GGUF sans hypothèse sur la structure des activations. C'est un outil généraliste, largement déployé, avec un écosystème de modèles quantifiés très vaste. PowerInfer mise sur la sparsité d'activation et exige des modèles ReLU-sparse. En échange de cette contrainte, il peut servir des modèles que llama.cpp ne ferait pas tenir sur un GPU de 24 Go sans quantification agressive, et la documentation annonce un gain pouvant atteindre 11,69x sur Falcon(ReLU)-40B-FP16. Le compromis est donc : généralité et simplicité contre performance conditionnelle. Si votre modèle est dense, llama.cpp est le bon choix. Si vous pouvez adopter un modèle ReLU-sparse et que vous êtes prêt à compiler, PowerInfer devient pertinent.

Licence MIT et coût de mise à jour

PowerInfer est distribué sous licence MIT, ce qui autorise l'usage commercial, la modification et la redistribution, à condition de conserver la notice de copyright. Les modèles eux-mêmes ont leurs propres licences, distinctes de celle du moteur : Falcon-40B, Llama 2 et Bamboo-7B ne sont pas tous sous MIT, et il faut vérifier chaque modèle séparément avant un déploiement commercial. Ce n'est pas un conseil juridique, seulement un rappel que la licence du code ne couvre pas les poids. Côté maintenance, l'absence de releases taguées signifie que chaque mise à jour implique de suivre la branche main et de recompiler. La dépendance à CMake et à des instructions AVX2 impose un matériel x86-64 récent. Le coût réel n'est pas financier : il est en temps d'ingénierie pour maintenir la chaîne de compilation et vérifier la compatibilité des modèles à chaque évolution du dépôt.

Conclusion éditoriale

PowerInfer convient à celles et ceux qui disposent déjà d'un GPU grand public et d'un modèle ReLU-sparse (Falcon-40B, ProSparse Llama 2, Bamboo-7B) et qui acceptent de compiler depuis les sources. Il ne convient pas si votre modèle est dense ou GQA : la documentation indique explicitement qu'avec les poids llama.cpp classiques, il n'y a aucun gain de performance. Avant d'investir du temps, vérifiez que le dépôt propose une release taguée et que votre modèle figure dans la liste des architectures supportées, car rien dans le matériel fourni ne garantit la compatibilité avec d'autres variantes.

Sources officielles

1. Issues
2. License: MIT
3. README
4. Tiiny-AI/PowerInfer on GitHub