9 points par GN⁺ 2025-12-21 | 1 commentaires | Partager sur WhatsApp
  • Des tests comparant l’exécution de GPU AMD, Intel et Nvidia sur un Raspberry Pi 5 à celle sur un PC de bureau montrent dans de nombreux cas une perte de performances limitée à 2 à 5 %
  • Quatre catégories ont été testées — transcodage Jellyfin, rendu GravityMark, inférence LLM/IA et configuration multi-GPU — afin de mesurer l’efficacité et les performances par rapport au coût
  • Dans un cas avec 4 Nvidia RTX A5000 connectés, l’écart de performances reste inférieur à 2 % par rapport à un serveur Intel, le partage de mémoire entre GPU via un switch PCIe jouant un rôle clé
  • Le coût total d’un système eGPU Raspberry Pi est d’environ 350 à 400 $, contre 1 500 à 2 000 $ pour un PC, avec en plus une consommation bien plus faible côté Pi (4 à 5 W au repos contre 30 W)
  • Un exemple qui démontre le potentiel du Raspberry Pi comme plateforme alternative basse consommation et à faible coût pour exploiter efficacement de gros GPU

Aperçu de l’expérience

  • Vérification de la possibilité d’exploiter des GPU malgré la limite de bande passante PCIe Gen 3 x1 (8 GT/s) du Raspberry Pi 5
    • La comparaison a été faite avec un PC de bureau récent (PCIe Gen 5 x16, 512 GT/s)
  • Les tests portaient sur le transcodage multimédia (Jellyfin), le rendu GPU (GravityMark), les performances LLM/IA et les configurations multi-GPU
  • Un essai de fonctionnement simultané de 2 GPU a été réalisé à l’aide d’un switch externe PCIe Gen 4 et d’un backplane 3 slots de Dolphin ICS

Cas d’un Raspberry Pi relié à 4 GPU

  • L’utilisateur GitHub mpsparrow a connecté 4 GPU Nvidia RTX A5000 à un seul Pi
    • Lors de l’exécution du modèle Llama 3 70B, l’écart de performances est resté dans les 2 % par rapport à un serveur Intel (11.83 vs 12 tokens/sec)
  • Le switch PCIe permet le partage de mémoire entre GPU, ce qui contourne la contrainte de bande passante du Pi
  • Même avec un seul GPU, certaines charges montrent des performances équivalentes ou supérieures à celles d’un desktop

Comparaison des coûts et de l’efficacité

  • Configuration Raspberry Pi eGPU : environ 350 à 400 $ ; configuration PC Intel : environ 1 500 à 2 000 $
  • Consommation au repos : Pi 4 à 5 W, PC 30 W
  • À GPU identique mais hors coût du GPU, le Pi est devant à la fois en coût et en efficacité énergétique

Benchmark de transcodage Jellyfin

  • Avec une Nvidia 4070 Ti, le PC garde l’avantage en débit brut (2GB/s)
    • Le Pi atteint environ 850MB/s en PCIe et 300MB/s sur SSD USB
  • Mais pour le streaming multimédia H.264/H.265, le Pi gère aussi sans difficulté le transcodage 1080p et 4K
    • Prise en charge de l’encodage matériel NVENC, avec 2 transcodages simultanés stables
  • Les GPU AMD ont montré quelques problèmes de stabilité en transcodage

Test de rendu GravityMark

  • Tests menés principalement avec des GPU AMD ; le PC est légèrement plus rapide, mais l’écart reste minime
  • Avec une RX 460, le Pi affiche une meilleure efficacité (performances/W) que le PC
  • Sur d’anciens GPU limités au PCIe Gen 3, le Pi conserve un avantage relatif

Comparaison des performances IA et LLM

  • Lors du test de l’AMD Radeon AI Pro R9700 (32GB VRAM), les performances ont été inférieures aux attentes, possiblement à cause d’un problème de pilote ou de réglage BAR
  • Avec une Nvidia RTX 3060 (12GB), le Pi est plus rapide que le PC sur le modèle Llama 2 13B
  • Les mesures d’efficacité montrent que le Pi est meilleur en débit par watt que le PC
  • Même avec une RTX 4090, l’écart reste dans les 5 % sur un grand modèle (Qwen3 30B), avec dans de nombreux cas un avantage au Pi en efficacité
  • Les backends CUDA et Vulkan fonctionnent tous deux correctement sur le Pi

Expérience en configuration double GPU

  • Utilisation d’une carte d’interconnexion PCIe Dolphin et d’un MXH932 HBA
  • La désactivation de l’ACS a permis l’accès direct à la mémoire entre GPU
  • Avec une combinaison de modèles de GPU différents (4070, A4000), le pooling de VRAM n’est pas pris en charge, ce qui limite le gain de performances
  • Avec des GPU identiques, il devient possible d’exécuter des modèles plus grands comme Qwen3 30B
  • La combinaison AMD RX 7900 XT + R9700 a échoué à exécuter certains modèles à cause de problèmes de pilote
  • Le PC Intel reste globalement plus rapide, mais le Pi conserve des performances proches sur les grands modèles

Conclusion

  • En performances absolues et en confort d’utilisation, le PC garde l’avantage
  • Mais pour les charges centrées sur le GPU dans un environnement basse consommation et à faible coût, le Raspberry Pi constitue une alternative pratique
  • Une réduction de 20 à 30 W au repos est possible, et les SBC basés sur Rockchip ou Qualcomm offrent encore une meilleure efficacité et davantage de bande passante I/O
  • L’objectif de l’expérience était de comprendre les limites du Pi et l’architecture du GPU computing, tout en confirmant le potentiel des systèmes compacts

1 commentaires

 
GN⁺ 2025-12-21
Commentaires Hacker News
  • Pour faire tourner des LLM en local, le GPU est au final l’élément clé
    Donc je me demande quel est l’ordinateur le moins cher qu’on puisse mettre à côté d’un GPU
    Je n’ai pas les compétences pour comprendre ou corriger des problèmes comme BAR, donc j’utilise simplement une boîte x86 bon marché avec un GPU correct branché dedans
    Mais je n’arrive pas à me sortir de la tête l’idée qu’il existe encore une méthode plus efficace

    • Je gère un site participatif qui recense les combinaisons matérielles optimales pour les LLM locaux
      Le site est inferbench.com, et le code source est dans le dépôt GitHub
    • Pour l’instant, il est difficile d’obtenir des performances vraiment significatives avec un seul périphérique PCIe
      J’estime qu’il faut au minimum 128 Go de RAM pour accompagner le GPU
      Les performances CPU peuvent être modestes, mais comme il faut prendre en charge plusieurs lignes PCIe, un CPU serveur d’entrée de gamme comme un AMD EPYC convient bien
    • Tu n’as pas envisagé d’utiliser de l’Apple Silicon comme un M4 Max ou un M3 Ultra ?
      C’est plutôt bien adapté aux LLM de taille intermédiaire
    • Le système que tu décris, c’est en pratique exactement le rôle d’un DGX Spark
  • Je ne comprends pas pourquoi la partie multi-GPU serait surprenante
    La plupart des frameworks LLM, comme llama.cpp par exemple, découpent le modèle par couches, donc il y a une dépendance séquentielle et on ne peut pas vraiment paralléliser le travail même avec plusieurs GPU
    Certains GPU sont aussi plus rapides pour le traitement du prompt, et d’autres pour la génération de tokens, donc mélanger Radeon et NVIDIA peut parfois être utile
    Les vrais gains de performance sont possibles avec des backends comme le mode tensor parallel
    Là, le réseau de neurones est découpé dans le sens du flux de données, donc il faut une bonne interconnexion entre GPU, comme PCIe x16, NVlink, Infinity Fabric, etc.
    Sans cela, l’utilisation des GPU peut sembler très irrégulière
    Il est intéressant d’explorer des moyens de découper un LLM pour exécuter plusieurs tâches en parallèle, par exemple avec une architecture d’agents où l’on sépare les rôles de « manager » et « ingénieur »

    • Oui, c’est exactement le principe des systèmes d’agents
      Le modèle manager construit les prompts, les modèles subordonnés travaillent en parallèle, puis renvoient leurs résultats
    • Dire que la taille des transferts inter-couches est de l’ordre du kilooctet est exagéré
      En réalité, cela monte à l’échelle du mégaoctet selon la longueur de séquence
      Par exemple, si le hidden state de Qwen3 30B est de 5120, cela représente 5120 octets par token en quantification 8 bits
      Au-delà de 200 tokens, on passe déjà à l’échelle du Mo
      Même une bande passante PCIe x1 d’environ 2 Go/s suffit, mais la latence peut être un problème plus important
  • Je suis vraiment content que quelqu’un ait fait ce genre d’expérience
    Moi aussi, en branchant un eGPU à un vieux portable, je me suis déjà demandé : « est-ce qu’on ne pourrait pas faire ça aussi avec un Raspberry Pi ? »

  • J’aurais bien aimé voir aussi les performances en jeu
    Cela dit, il est difficile de trouver des jeux AAA compatibles ARM, et forcer l’émulation x86 avec FEX ne serait pas très équitable

    • L’enjeu serait sans doute de trouver un jeu qui ne soit pas limité par le CPU
  • Avec le constrained decoding (basé sur un schéma JSON), l’utilisation CPU monte à 100 %
    J’ai observé le même phénomène sur mon instance vLLM

  • Le PCIe 3.0 offre environ 1 Go/s par ligne, soit des vitesses comparables à de l’Ethernet 10 Gb
    Il n’est pas impossible qu’un jour les GPU fonctionnent de manière autonome, sans système hôte
    Il y a déjà eu des cas comme le Radeon Pro SSG, où un SSD était directement attaché au GPU,
    et une petite puce RISC-V ou un contrôleur de classe Raspberry Pi pourrait suffire
    Article lié : TechPowerUp
    Une architecture où le GPU est directement relié au switch réseau, avec du 400Gbe ou une communication basée sur CXL, paraît réaliste
    Et des technologies flash de nouvelle génération comme la High Bandwidth Flash pourraient aussi finir par remplacer la DRAM
    Articles liés : ServeTheHome, Tom’s Hardware

  • Ces données me font reconsidérer la configuration de mon PC principal
    Un mini-PC à 300 dollars consommant moins de 20 W devrait suffire
    Pour le web, la vidéo et un peu de jeu, ce serait largement suffisant,
    et pour les tâches lourdes, il suffirait de se connecter à distance à une station de travail

    • Je fais des essais avec une combinaison VM Proxmox + eGPU
      1 vCPU et 4 Go de RAM suffisent déjà pour le surf web et des projets perso
      On dirait bien que les fabricants de matériel ont survendu l’idée que « les pros ont besoin d’un portable très puissant »
    • En passant d’un mini-PC Ryzen 8 cœurs à un desktop 8 cœurs, mes tests unitaires s’exécutent beaucoup plus vite
      La différence de TDP crée un écart de performances important
    • J’utilise aussi un mini-PC Beelink, et mon bureau est beaucoup plus propre,
      tandis que les machines puissantes restent dans un espace insonorisé, ce qui est très agréable
  • Je me demande pourquoi l’architecture PCI/CPU elle-même est encore nécessaire
    Comme chez Apple et NVIDIA, mettre le CPU et le MPP dans le même package semble aller dans la bonne direction

    • Cette approche est avantageuse pour les charges de travail sensibles à la latence,
      mais pour les gros calculs comme en IA ou en HPC, l’écart n’est peut-être pas si grand