Servir rapidement de grands modèles de langage sur un PC équipé d’un GPU grand public

 (github.com/SJTU-IPADS)
1 points par GN⁺ 2023-12-21 | 1 commentaires | Partager sur WhatsApp
  • PowerInfer est un moteur d’inférence hybride CPU/GPU destiné à servir localement des LLM sur un PC personnel équipé d’un seul GPU grand public
  • Sa conception centrale exploite la localité d’activation de l’inférence LLM : les neurones « hot », fréquemment activés, sont préchargés sur le GPU, tandis que les neurones « cold », qui varient selon l’entrée, sont calculés sur le CPU
  • Dans ses évaluations, PowerInfer indique avoir atteint, avec un seul GPU RTX 4090, une moyenne de 13,20 tokens/s et un maximum de 29,08 tokens/s sur plusieurs LLM, dont OPT-175B, soit 18 % de moins qu’un A100
  • Par rapport à llama.cpp, il annonce une accélération de 11x dans une démo Falcon(ReLU)-40B-FP16 sur RTX 4090 24 Go, et jusqu’à 11,69x dans les évaluations, tout en conservant la précision du modèle
  • La prise en charge se concentre sur les modèles utilisant les fonctions d’activation ReLU/ReGLU/Squared ReLU ; Mistral, Llama original, Qwen, etc., ne sont actuellement pas pris en charge

Le problème que PowerInfer cherche à résoudre

  • PowerInfer est un moteur d’inférence CPU/GPU conçu pour exécuter rapidement des LLM sur des appareils locaux
  • Il cible les PC équipés d’un seul GPU grand public, avec pour objectif une inférence et un serving de LLM à faible latence
  • Le principe clé de sa conception est que l’activation des neurones dans l’inférence LLM suit une distribution en loi de puissance
    • Certains neurones hot sont activés de manière cohérente sur l’ensemble des entrées
    • De nombreux neurones cold varient selon l’entrée spécifique

Inférence hybride CPU/GPU

  • PowerInfer précharge les neurones hot sur le GPU pour y accéder rapidement, tandis que les neurones cold sont calculés sur le CPU
  • Cette approche vise à réduire les besoins en mémoire GPU et les transferts de données entre CPU et GPU
  • Il intègre en plus un prédicteur adaptatif et des opérateurs sparse conscients des neurones afin d’optimiser l’activation des neurones et la sparsité du calcul
  • Dans l’inférence hybride CPU/GPU, tous les blocs d’activation dense sont automatiquement déchargés vers le GPU, puis les FFN sont divisés et déchargés vers le GPU lorsque c’est possible

Évaluations de performance et démos

  • Sur un seul GPU RTX 4090, PowerInfer a atteint une moyenne de 13,20 tokens/s et un maximum de 29,08 tokens/s sur plusieurs LLM, dont OPT-175B
  • Il décrit ce résultat comme seulement 18 % inférieur à celui d’un GPU A100 haut de gamme de classe serveur
  • Il indique être jusqu’à 11,69x plus rapide que llama.cpp, tout en conservant la précision du modèle
  • Dans la démo, Falcon(ReLU)-40B-FP16 tourne sur une seule RTX 4090 24 Go avec une accélération de 11x par rapport à llama.cpp
    • PowerInfer et llama.cpp ont tous deux été exécutés sur le même matériel et utilisent entièrement la VRAM de la RTX 4090
  • Dans une autre évaluation, avec une RTX 4090 24 Go, un modèle ReLU FP16 et une longueur d’entrée de 64, Falcon 40B montre jusqu’à 11x d’accélération et Llama 2 70B jusqu’à 3x
  • Avec une RTX 2080Ti 11 Go, un modèle ReLU INT4 et une longueur d’entrée de 8, Falcon 40B montre jusqu’à 8x d’accélération et Llama 2 70B jusqu’à 3x

Modèles et plateformes pris en charge

Installation et flux d’exécution

  • Les dépendances de build sont CMake 3.17 ou supérieur, Python 3.8 ou supérieur et pip 19.3 ou supérieur
  • Le build pour GPU NVIDIA utilise l’option -DLLAMA_CUBLAS=ON
  • Le build pour GPU AMD repose sur ROCm/HIP, avec -DLLAMA_HIPBLAS=ON et la spécification de AMDGPU_TARGETS
  • Un build CPU-only est également possible
  • La commande d’inférence de base consiste à fournir à l’exécutable main le chemin du modèle, le nombre de tokens à générer, le nombre de threads et le prompt
  • La limite d’utilisation de la VRAM GPU se définit avec l’option --vram-budget
  • Le serving, l’évaluation de perplexité et la génération par lots de PowerInfer prennent en charge des commandes similaires à celles de llama.cpp, mais l’argument -ngl est remplacé dans PowerInfer par --vram-budget

Quantification et compatibilité

  • PowerInfer prend en charge de manière optimisée la quantification de modèles INT4 Q4_0
  • L’exécutable quantize permet de quantifier un modèle PowerInfer GGUF au format Q4_0
  • Le mode d’inférence dense est pris en charge de façon limitée et peut être utilisé d’une manière similaire à llama.cpp
  • Le mode d’inférence dense n’est pas un mode de compatibilité pour tous les modèles
    • Les modèles ReluLLaMA et ProSparse changent de fonction d’activation
    • Les modèles Bamboo changent d’architecture de modèle
  • PowerInfer indique qu’il peut aussi exécuter des poids de modèles llama.cpp pour la compatibilité d’inférence, mais sans gain de performance

Limites et FAQ

  • Les modèles actuellement pris en charge sont limités à ceux qui utilisent les fonctions d’activation ReLU/ReGLU/Squared ReLU
  • Mistral, Llama original, Qwen, etc., ne sont pas pris en charge actuellement
  • En cas de CUDA_ERROR_OUT_OF_MEMORY, il est possible de recréer l’index GPU avec --reset-gpu-index
  • Dans l’implémentation actuelle, l’offloading du modèle peut ne pas être aussi précis qu’attendu ; il est donc possible de réduire légèrement la valeur de --vram-budget ou de désactiver l’offloading des FFN avec --disable-gpu-index
  • PowerInfer explique que la baisse actuelle des métriques de performance des modèles ReLU, en particulier les modèles 70B, vient du fait qu’ils ont été fine-tunés sur seulement 5B tokens, contrairement aux quelque 2T tokens nécessaires à l’entraînement général des LLM

Mises à jour récentes et feuille de route

  • Le 5 janvier 2026, PowerInfer a annoncé Tiiny AI Pocket Lab, qui exécute GPT-OSS-120B int4 localement à 20 tokens/s
  • Le 27 juillet 2025, il a publié SmallThinker-21BA3B-Instruct et SmallThinker-4BA0.6B-Instruct
  • Le 11 juin 2024, il a présenté PowerInfer-2, un framework d’inférence optimisé pour smartphone, indiquant atteindre 11,68 tokens/s sur TurboSparse-Mixtral-47B
  • Le même jour, il a publié Turbo Sparse, expliquant rendre les modèles Mistral et Mixtral sparse à environ 90 % et n’activer que 4B paramètres dans un modèle de type Mixtral
  • Les éléments terminés incluent la publication du code cœur de PowerInfer, la prise en charge de Llama-2 et Falcon-40B, la prise en charge de Bamboo-7B, la prise en charge de Windows, la publication du code d’évaluation de perplexité et la division en ligne des FFN
  • Les éléments restants incluent la prise en charge de text-generation-webui, la prise en charge de Metal pour Mac, la publication du code des modèles OPT, la publication du code d’entraînement du prédicteur et la prise en charge multi-GPU

Article et projets sous-jacents

  • Des détails techniques plus approfondis sont présentés dans l’article PowerInfer
  • PowerInfer utilise la bibliothèque d’opérateurs modifiables de ggml et le runtime d’exécution de llama.cpp
  • THUNLP est mentionné pour la prise en charge des modèles sparse basés sur ReLU
  • PowerInfer indique s’être inspiré des travaux de recherche Deja Vu

À lire aussi

1 commentaires

 
GN⁺ 2023-12-21
Avis sur Hacker News

  • Dans la plupart des domaines du machine learning, il n’existe pas vraiment de concept de neurones hot/cold, donc il m’a fallu un moment pour comprendre, et l’article ne semble pas non plus le définir directement.
    Avec ReLU, si la sortie vaut souvent 0, on peut considérer le neurone comme « cold », ce qui a du sens, mais LLaMA, à l’origine, n’utilise pas ReLU. En regardant de nouveau GitHub, cette approche ne fonctionne en fait que sur des modèles ReLU, et un groupe « fine-tune » des modèles en ReLU pour obtenir de la sparsité : https://huggingface.co/SparseLLM
    Elle ne s’applique donc pas à n’importe quel modèle qu’on trouve couramment sur Internet, mais le progrès en lui-même semble important. À l’avenir, on pourrait se diriger vers un compromis entre des modèles plus grands et des fonctions d’activation moins idéales, et je me demande aussi comment la sparsité sera comptabilisée si les régulations américaines ou européennes prennent comme critère les FLOPs ou le nombre de paramètres.
    Comme piste de recherche future, il semble possible de conserver les fonctions d’activation existantes comme le SwiGLU de LLaMA, tout en utilisant la quantification pour définir les zones de saturation comme neurones hot/cold.

    • Je me demande quand et comment ce genre de réglementation est apparu. Devoir se soucier d’une régulation sur les FLOPs / le nombre de paramètres pendant le développement me paraît assez étrange.
    • Omettre l’indice majeur selon lequel c’est réservé aux modèles ReLU dans un README qui revendique une compatibilité avec LLaMA est un vrai problème.
    • https://huggingface.co/SparseLLM/ReluFalcon-40B indique aussi « We utilize PowerInfer for inference ».

  • Ce serait vraiment génial de pouvoir faire tourner un Mixtral dé-censuré avec ça. Sur une RTX 4090, cela pourrait rendre possible une quantification au-delà de 3 bits.

    • Je me demande pourquoi ça reçoit des votes négatifs, alors que les LLM dé-censurés ont généralement tendance à mieux s’en sortir, au moins dans les benchmarks, que les versions « lobotomisées » ou alignées.
    • Dans la démo, ils font tourner un modèle plus grand sur une RTX 4090 avec 24 Go de VRAM. Implémenter l’activation sparse dans un Mixture of Experts n’est peut-être pas simple, mais cela semble être une excellente direction, qui pourrait permettre un traitement uniquement sur CPU ou avec des GPU beaucoup moins chers.
      Mixtral possède déjà, techniquement, une activation sparse contrôlée par un réseau neuronal, mais comme dans le mème d’Inception, il faut « aller plus profond ».
    • Une configuration à deux GPU peut être considérée comme assez grand public, et j’espère qu’elle sera bientôt prise en charge. En 4 bits, il devrait même rester largement de la place pour l’espace de contexte.
      Tout cela étant un fork de llama.cpp, j’espère que ça finira un jour dans le projet amont.
    • Ça a l’air bien : https://www.youtube.com/watch?v=q2KpPUOsBCs

  • Comme ils disent travailler sur Mistral-7B, mon implémentation de Mistral dédiée au GPU utilise un peu plus de 5 Go de VRAM : https://github.com/Const-me/Cgml
    Elle tourne plutôt bien sur la plupart des GPU grand public, mais ne prend actuellement en charge que Windows.

    • Ça a l’air assez intéressant. Je me demande si ça tournerait aussi sur un ordinateur portable Intel Core i7.
    • Tu peux essayer ollama. Ça utilise llmcpp et ne nécessite qu’environ 4 Go.

  • Vraiment impressionnant. llama.cpp est certes très apprécié, mais son approche d’offloading vers GPU externe reste relativement simple : le traitement du prompt se fait sur GPU et le modèle est divisé au milieu.
    Ce qui est intéressant, c’est que la sparsité d’activation est suffisamment importante pour être exploitable, alors que du point de vue du machine learning traditionnel, les accès mémoire sont considérés comme très aléatoires.
    J’aimerais qu’un jour on puisse offloader les neurones cold vers le GPU intégré. Le fait qu’ils envisagent des kernels Metal m’intrigue aussi, car je pensais que le gain de performance venait du pool mémoire hybride. Si ce n’est pas le cas, cela ne semblerait utile que pour les anciens Mac AMD, mais il y a peut-être quelque chose qui m’échappe.

    • Pour Apple Silicon et Metal, l’idée pourrait être de placer les neurones cold côté CPU/Accelerate et les neurones hot côté GPU afin d’utiliser les deux.
      S’il n’y a pas de copie entre GPU et CPU et que l’on utilise déjà la mémoire unifiée, l’accélération pourrait être limitée, mais ce serait intéressant si cela permet d’exploiter davantage de fonctions de la puce en parallèle. Pour éviter la baisse de performance due à la chaleur, il vaudrait sans doute mieux n’utiliser que les cœurs d’efficacité, et le mode jeu fonctionne probablement de cette manière.

  • Dans cette implémentation, il semble falloir une certaine connaissance du modèle lui-même pour décider quelles parties placer en mémoire système et lesquelles placer en mémoire GPU.
    Idéalement, je me demande si cela pourrait être calculé automatiquement, ou si les futurs modèles fourniront une interface permettant d’automatiser ce genre d’algorithme de placement. Si l’algorithme doit être adapté à chaque architecture de modèle, la maintenance de ce projet risque d’être assez difficile.

    • C’est globalement l’impression que ça donne. Ils fournissent un script pour combiner les poids du « Predictor » avec le modèle d’origine, mais sur la page d’accueil GitHub, on ne voit pas clairement comment ces poids sont créés.
      Une accélération par 10 est vraiment impressionnante. Si elle est reproductible sur d’autres modèles, l’identification des neurones hot/cold pour optimiser l’inférence pourrait devenir une partie courante du développement des modèles.

  • Pour les personnes qui ne vont pas tester elles-mêmes, les informations importantes du README sont à peu près celles-ci : PowerInfer a été testé sur CPU x86-64 sous Linux (AVX2), sur CPU x86-64 sous Linux avec GPU NVIDIA, et sur les puces Apple M sous macOS.
    En revanche, ils disent ne pas avoir encore optimisé pour Mac, donc le gain de performance actuel n’est pas très important. Parmi les fonctionnalités à venir figurent les modèles Mistral-7B et un backend Metal d’inférence sparse pour macOS.

    • Les modèles llama2 téléchargeables et le fichier convert.py méritent aussi d’être mentionnés.

  • Le fait qu’ils aient conçu un moteur d’inférence hybride GPU-CPU en exploitant une distribution composée d’un petit nombre de neurones hot activés de façon constante sur l’ensemble des entrées et d’un grand nombre de neurones cold qui varient selon l’entrée est excellent.
    L’explication est que les neurones hot sont préchargés sur le GPU pour un accès rapide, tandis que les neurones cold sont calculés sur le CPU, ce qui réduit fortement les besoins en mémoire GPU et les transferts de données CPU-GPU.

  • Tout le monde compare à llama.cpp parce que c’est la voie facile. Il faut que tout le monde sache que llama.cpp est lent. Il faudrait comparer avec exllamav2 ou d’autres implémentations optimisées.

    • Dans ce cas, comme le code est littéralement une modification de llama.cpp, la comparaison avec llama.cpp est pertinente. Ce n’est pas juste l’utilisation de la bibliothèque de calcul matriciel ggml : c’est un fork qui reprend tel quel main.cpp et le code llama.cpp standard, donc la comparaison directe est possible.
      https://github.com/ggerganov/llama.cpp/pull/4543 [Review] Merge PowerInfer with llama.cpp mainline #4543
      https://github.com/ggerganov/llama.cpp/discussions/4534#disc... On y trouve aussi l’explication selon laquelle « l’accélération par 11 est un peu choisie sur mesure, car le code GPU de llama.cpp pour Falcon 40B n’est pas bien optimisé ».
    • exllama ne prend pas en charge les contraintes syntaxiques, donc on est coincé avec llama.cpp.
      En plus, exllama semble aussi avoir des effets secondaires côté cohérence : https://www.reddit.com/r/LocalLLaMA/comments/17w57eu/llm_for...
    • ExLlama n’est-il pas réservé au GPU ? Ce gain de vitesse vise le cas d’usage avec répartition GPU+CPU.
    • Je serais curieux de savoir ce qu’on recommanderait si l’objectif est quelque chose de plus rapide, mais qu’on peut aussi empaqueter et distribuer dans une application.

  • Ce serait vraiment génial de pouvoir générer un fichier de prédicteur de parcimonie pour n’importe quel modèle. Pour l’instant, cela semble ne concerner que les 4 modèles qu’ils ont traités.
    En regardant la page et le code, il ne semble pas y avoir d’outil inclus pour effectuer cette étape. Pour le moment, je vais attendre un peu, et j’espère que ces fonctionnalités finiront par être réintégrées comme options dans llama.cpp. Ce n’est pas seulement la bibliothèque matricielle ggml qui est utilisée, c’est basé sur le code llama.cpp standard.

  • Rien qu’avec l’expression « GPU grand public », on pourrait croire que cela tourne sur plusieurs modèles, mais comme c’est souvent le cas avec ce genre d’articles, je me demande si, en pratique, ce n’est pas réservé à la RTX 4090.

    • Rien ne me vient à l’esprit qui soit spécifiquement réservé à la 4090. En général, ce qui compte, c’est la VRAM : s’il faut 24 Go, une 3090 peut aussi convenir, et deux cartes de 12 Go sont également une option.
      Cette technique elle-même est une approche générale qui permet de faire tourner de plus gros modèles sur de petits GPU, et améliore fortement les performances de l’offloading CPU. Au-delà du cas où le plus gros modèle tourne en fp16 sur une 4090, exécuter le même modèle en quantification 4 bits sur une 2080Ti montrait aussi, pour LLaMA, une accélération d’environ 3×.
      Il semble donc très probable que, sur desktop, les modèles 33B deviennent le nouveau standard, et qu’avec une seule 3090 ou 4090 on puisse faire tourner du 70B à une vitesse de chat en temps réel.