Mettre un GPU de datacenter dans un PC gaming pour 200 £

 (blog.tymscar.com)
1 points par GN⁺ 2 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Le seul RTX 4080 16GB ne suffisait pas pour un environnement local de LLM, donc un Tesla V100 SXM2 16GB d’occasion et un adaptateur ont été ajoutés pour environ 200 £, afin d’obtenir un total de 32 Go de VRAM
  • Le V100 SXM2 est un GPU serveur sans slot PCIe, sans sortie d’affichage et sans connecteur d’alimentation standard, mais il a pu être installé dans un PC gaming grâce à un adaptateur SXM2-to-PCIe
  • Le ventilateur serveur affichait 82 dB par défaut, ce qui le rendait difficile à utiliser en intérieur, mais un câble jumper PH2.0-2.54 mm relié au header ventilateur de la carte mère a permis d’obtenir un contrôle PWM et un fonctionnement silencieux
  • Avec le tensor splitting de llama.cpp, le modèle Qwen3.6-27B-MTP Q5_K_M a été réparti entre le RTX 4080 et le V100, ce qui a permis d’obtenir un contexte de 128k et une vitesse d’inférence d’environ 32 tok/s
  • Ce n’est pas aussi propre qu’un GPU unique de 32 Go et il reste des problèmes de pilotes, de CUDA et de warm reboot, mais les GPU serveur d’occasion peuvent constituer une alternative bon marché pour étendre la VRAM d’un LLM local

Un environnement local de LLM de 32 Go monté pour 200 £

  • Les 16 Go de VRAM du RTX 4080 seuls ne suffisaient pas pour exécuter les modèles locaux souhaités, donc un GPU de datacenter d’occasion a été ajouté au PC gaming via un adaptateur
  • Un Tesla V100 SXM2 16GB et un adaptateur SXM2-to-PCIe ont été achetés pour environ 200 £ au total, afin de constituer un environnement à 32 Go de VRAM cumulés sur deux GPU
  • Un modèle de 27B paramètres a été réparti sur les deux GPU et exécuté à environ 32 tokens/s, avec l’ensemble du modèle et du contexte logés en VRAM
  • L’expérience n’est pas équivalente à celle d’un GPU grand public unique de 32 Go, mais la capacité VRAM obtenue coûte bien moins cher qu’un RTX 5090 32GB

Tesla V100 SXM2 et adaptateur

  • Le Tesla V100 SXM2 16GB est un GPU destiné aux serveurs NVIDIA DGX et aux racks d’hyperscalers
    • Il ne dispose ni d’un slot PCIe classique, ni d’une sortie vidéo, ni d’un connecteur d’alimentation standard
    • Il est conçu pour être monté sur une carte propriétaire dans un serveur et communiquer via NVLink
    • Un adaptateur séparé est nécessaire pour le brancher directement sur une carte mère
  • Le V100 est un GPU Volta avec 16 Go de mémoire HBM2 et 5120 cœurs CUDA
    • Le prix d’achat sur eBay était d’environ 150 £
    • Bien qu’il date de 2017, sa puissance de calcul et sa VRAM restent pertinentes pour un usage local de LLM
  • La bande passante mémoire HBM2 est son principal avantage
    • Le V100 offre 900GB/s de bande passante via un bus mémoire 4096-bit
    • C’est 22 % de plus que les 736GB/s de GDDR6X du RTX 4080
    • C’est aussi supérieur aux 400GB/s de l’Apple M3 Max, aux 546GB/s du M4 Max et aux 614GB/s du M5 Max
  • L’AMD RX 7900 XTX atteint 24 Go de GDDR6 et 960GB/s de bande passante, soit un peu plus que le V100, mais coûte plus de 700 £
    • La prise en charge de l’inférence LLM via ROCm est encore jugée plus rugueuse que sous CUDA
    • Le V100 fournit 94 % de la bande passante d’une RX 7900 XTX pour moins d’un quart du prix, et fonctionne avec llama.cpp
  • Le RTX 5090, avec 1,792GB/s, surclasse nettement le V100, mais son prix dépasse 2,000 £
    • En inférence LLM, la bande passante mémoire est un goulet d’étranglement déterminant pour les tokens/s, d’où son importance
  • L’adaptateur SXM2-to-PCIe n’est pas un produit officiel NVIDIA et n’est pas pris en charge officiellement
    • Il se présente comme un PCB nu avec un socket SXM2 d’un côté et un connecteur PCIe edge de l’autre
    • Il coûtait environ 50 £, portant le total de la configuration à environ 200 £
    • Grâce à lui, il a été possible d’installer le V100 16GB sur la carte mère aux côtés du RTX 4080

Le problème du ventilateur serveur et sa résolution

  • Le V100 SXM2 a été conçu pour fonctionner dans l’environnement de refroidissement industriel d’un serveur 2U
    • Le ventilateur de l’adaptateur est beaucoup trop bruyant pour une pièce ordinaire
    • Mesuré avec une Apple Watch, le bruit atteignait 82 dB, décrit comme entre un broyeur d’évier et une tondeuse à gazon
  • Dans la configuration d’origine, il n’était pas possible de contrôler le ventilateur
    • Les tentatives avec nvidia-smi, l’exploration des périphériques Linux et Windows Afterburner ont toutes échoué
    • Le ventilateur de l’adaptateur semble partir du principe qu’il tourne à 100 % en permanence dans un rack serveur
  • Un test avec une pile 9V a permis de confirmer le brochage du ventilateur
    • En branchant des fils jumper sur VCC et ground puis en appliquant une pile 9V, le ventilateur s’est mis à tourner
    • Il est alors devenu bien plus silencieux qu’en fonctionnement nominal à 12V, ce qui a confirmé la possibilité de le piloter
  • Le ventilateur s’est comporté comme un ventilateur standard de boîtier PC
    • Des fils jumper ont été insérés dans le connecteur du ventilateur puis reliés à un header ventilateur libre de la carte mère
    • La carte mère pouvait lire les RPM et assurer aussi le contrôle PWM
    • Même maintenu à 10 % de vitesse, il ne dépassait pas 50°C en pleine charge et devenait quasiment inaudible
  • Le câble final était un câble jumper male 2.54 mm vers female PH2.0
    • Le connecteur du ventilateur de l’adaptateur est une prise JST PH2.0 à 4 broches
    • Le header ventilateur de la carte mère utilise le standard 0.1 inch, soit un pas de 2.54 mm
    • Le côté PH2.0 female a été connecté aux broches tachometer et PWM du ventilateur, et le côté 2.54 mm male au header ventilateur de la carte mère
    • Un câble jumper à 2 £ et une vérification du connecteur ont suffi à résoudre le problème des 82 dB

Étendre la VRAM avec deux GPU

  • La configuration GPU finale est la suivante
    • RTX 4080 : 16 Go de VRAM, architecture Ada
    • Tesla V100 : 16 Go de VRAM, architecture Volta
    • Total : 32 Go de VRAM répartis sur les deux GPU
  • llama.cpp peut répartir le modèle sur deux GPU grâce au tensor splitting
    • Les couches sont traitées en pipeline via le bus PCIe
    • Le RTX 4080 traite une partie des couches et le V100 le reste
    • Ce n’est pas plus rapide qu’un GPU unique de 32 Go, mais cela fonctionne, pour environ 10 % du coût d’un tel GPU
  • La consommation du V100 a été observée à environ 150 W au maximum
    • Ce n’est pas insignifiant pour un GPU d’inférence LLM local, mais ce n’est pas non plus anormalement élevé
  • Un V100 32GB reste une option possible
    • Il coûte plus du double du prix payé ici, mais permet tout de même d’obtenir 32 Go de HBM2 sur une seule carte pour quelques centaines de livres
    • Deux V100 32GB permettraient d’atteindre 64 Go de VRAM, pour environ 20 % du prix actuel d’un RTX 5090
  • Le format SXM2 prend en charge NVLink par défaut
    • Dans une vraie configuration multi-GPU, les GPU pourraient communiquer entre eux à haute bande passante
    • Même via l’adaptateur PCIe, les performances en tensor split se sont révélées suffisamment solides

Aligner les pilotes et CUDA sur NixOS

  • La configuration logicielle s’est déroulée de manière relativement fluide grâce à NixOS
  • Le V100 utilise une puce Volta, et NVIDIA a abandonné la prise en charge de Volta à partir de la branche de pilotes 560
    • Le dernier pilote prenant en charge à la fois le RTX 4080 Ada et le V100 Volta est la branche 550.x
    • Sur NixOS, cela correspond à nvidiaPackages.legacy_535
  • Ce pilote ne prend en charge que CUDA 12.2 maximum
    • Le nixpkgs actuel fournit CUDA 12.6 et au-delà
    • Il a donc fallu récupérer CUDA 12.2 depuis nixpkgs 24.05
  • Le pilote exige le kernel Linux 6.6
    • Le pilote legacy ne prend pas en charge les kernels plus récents
  • Même sur un serveur d’inférence headless, il a fallu activer services.xserver.enable = true
    • Sans ce réglage, le module noyau NVIDIA ne se chargeait pas
  • La configuration NixOS essentielle reposait sur le kernel, le pilote NVIDIA legacy et la déclaration du pilote NVIDIA pour X server
boot.kernelPackages = pkgs.linuxPackages_6_6;
hardware.nvidia.package = config.boot.kernelPackages.nvidiaPackages.legacy_535;
services.xserver.enable = true;
services.xserver.videoDrivers = [ "nvidia" ];
  • CUDA 12.2 a été importé via un overlay depuis une ancienne version de nixpkgs
nixpkgs.overlays = [
  (final: prev: {
    cudaPackages_12_2 = nixpkgs-cuda.legacyPackages.${prev.system}.cudaPackages_12_2;
  })
];
  • Les deux GPU sont bien détectés et CUDA fonctionne correctement
  • La définition complète de la machine figure dans ce commit du dépôt dotfiles
    • Il inclut aussi la définition du service llama.cpp et un build personnalisé épinglé à la bonne version

Modèle exécuté et performances

  • Le modèle utilisé est la version quantifiée Qwen3.6-27B-MTP Q5_K_M
    • La taille du modèle est d’environ 19 Go
    • En utilisant les deux GPU, l’ensemble du modèle tient en VRAM avec encore de la marge pour le contexte
  • Les principaux réglages d’exécution sont les suivants
    • Model : Qwen3.6-27B-MTP Q5_K_M, 19GB
    • Context size : 128k tokens
    • GPU layers : 99, offload complet
    • Tensor split : -ts 1.0,1.0, répartition égale sur les deux GPU
  • Les performances observées sont les suivantes
    • Inference speed : environ 32 tok/s
    • Prompt processing : environ 133~160 tok/s
  • Les 32 tokens/s sont jugés suffisants pour un usage conversationnel
    • Cela reste vrai même avec un tensor split via PCIe entre deux GPU d’architectures différentes
    • En tenant compte de la latence réseau, cela est présenté comme plus rapide que la plupart des endpoints d’API cloud

MTP et entrée image

  • MTP signifie Multi-Token Prediction
    • L’inférence LLM classique prédit un token à la fois, l’accepte, puis passe au suivant
    • Le MTP prédit plusieurs tokens futurs d’un coup, puis vérifie ceux qui sont corrects
    • Les tokens acceptés sont en pratique presque gratuits, tandis que les prédictions erronées reviennent au chemin classique
  • Le résultat du MTP est un gain de vitesse d’environ 1.5 à 2× sans perte de précision
    • Dans cette configuration, on indique qu’il est possible de passer d’environ 32 tok/s à 50~60 tok/s lorsque le MTP fonctionne bien
    • L’effet est particulièrement marqué sur des sorties prévisibles comme le code
  • La prise en charge du MTP dans llama.cpp est encore récente
    • La version de llama.cpp dans nixpkgs ne prend pas encore en charge l’architecture MTP de Qwen3.6
    • Il a fallu compiler llama.cpp depuis les sources à partir d’un commit précis ajoutant cette prise en charge
    • Sur NixOS, une derivation personnalisée a été épinglée sur ce commit afin de rendre l’ensemble reproductible
    • Changer de modèle ou de version de llama.cpp se fait en modifiant une ligne de configuration puis en lançant nixos-rebuild switch
  • Qwen3.6-27B prend aussi en charge l’entrée image via un fichier de projecteur multimodal mmproj distinct
    • Ce fichier additionnel pèse environ 928MB
    • Le vision encoder convertit les pixels de l’image en espace d’embeddings de tokens pour le LLM
    • Le modèle ne “voit” pas les images comme un humain
    • Le LLM traite simplement les vecteurs convertis comme une autre séquence de tokens
  • Les flags d’exécution de llama.cpp sont les suivants
--mmproj /mnt/nas/llamacpp/mmproj-F16.gguf --mmproj-offload
  • --mmproj-offload charge le vision encoder sur le GPU avec le modèle
    • Cela permet de conserver une inférence rapide même avec des entrées image

Usage local

  • Cette configuration est utilisée avec OpenCode
    • OpenCode est un assistant de développement IA pouvant fonctionner avec des modèles locaux
  • Le serveur LLM tourne sur le desktop, mais l’utilisation se fait depuis d’autres appareils
    • Il est accessible en réseau depuis d’autres machines de la maison
    • Depuis l’extérieur, l’accès se fait via Tailscale
  • Dans OpenCode, l’utilisation du serveur llama.cpp se fait en configurant l’URL d’API
    • Le modèle s’exécute localement
    • Les réponses sont rapides et les données ne quittent pas le réseau

Problèmes restants et limites

  • Le V100 disparaît parfois après un warm reboot
    • Après un redémarrage où seul l’OS repart mais où la carte mère reste alimentée, il arrive que le V100 n’apparaisse plus dans lspci et nvidia-smi
    • Cela semble lié à un problème d’énumération ACPI du slot PCIe
    • Une extinction complète suivie de quelques secondes d’attente puis d’un redémarrage à froid résout toujours le problème
  • Sans le V100, llama.cpp ne démarre pas
    • Le modèle ne tient pas sur un seul GPU de 16 Go
    • Le service entre donc dans une boucle de crash tant que le GPU n’est pas revenu
    • Comme les redémarrages se font généralement en présence de l’utilisateur, cela n’est pas considéré comme un problème majeur en pratique
  • Répartir un tensor split entre deux GPU d’architectures différentes n’est pas aussi propre qu’un GPU unique
    • Le V100 n’est pas non plus le GPU le plus rapide pour l’inférence
    • Mais son rapport qualité-prix est jugé très élevé

Options et conclusion

  • Pour environ 200 £, le résultat obtenu est le suivant
    • Un GPU de datacenter de 16 Go fonctionnant aux côtés d’un GPU gaming
    • Un total de 32 Go de VRAM pour l’inférence locale de LLM
    • 32 tokens/s sur un modèle à 27B paramètres
    • Une fenêtre de contexte de 128k tokens
    • La prise en charge vision pour les entrées image
    • Un modèle exécuté entièrement en local, sans cloud ni coût au token
  • Le vrai coût a été le bruit du ventilateur, mais il a été résolu avec un câble jumper et l’identification du bon connecteur
  • Pour qui veut faire tourner un vrai modèle local, le marché de l’occasion des GPU serveur peut représenter une alternative
    • Même sans GPU existant, un V100 unique monté dans un boîtier serveur bon marché peut offrir 16 Go de VRAM et un environnement local de LLM exploitable
    • Le V100 SXM2 n’est pas la seule option
    • Le P40 offre 24 Go pour un coût comparable, mais il est plus lent et n’a pas de Tensor Cores
    • Le V100 32GB est plus cher, mais reste moins coûteux qu’un GPU grand public offrant la même quantité de VRAM
  • Il faut toutefois se préparer au problème du ventilateur

À lire aussi

1 commentaires

 
GN⁺ 2 시간 전
Avis sur Lobste.rs

  • L’approche est vraiment géniale, et le phénomène où le GPU disparaît du PCIe est d’autant plus intriguant qu’il peut avoir énormément de causes
    Le bruit du ventilateur du GPU qui monte fort m’a rappelé l’époque où je travaillais dans l’équipe NVIDIA CUDA. Un collègue ajoutait la fonction de contrôle des ventilateurs à NVML et nvidia-smi, et j’entendais par-dessus la cloison le ventilateur accélérer puis ralentir, avant de le voir passer la tête avec un grand sourire
    Il disait que c’était sa fonctionnalité préférée parmi celles sur lesquelles il avait travaillé, parce qu’on pouvait entendre le résultat au moment exact où le code se mettait à fonctionner

  • Si vous vous intéressez à l’auto-hébergement de LLM, les Dell OEM RTX 3090 sont en général moins chères que les produits des grandes marques, et on pouvait en trouver autour de 800 dollars canadiens
    Il faut maintenant que je lise davantage sur le fonctionnement de vLLM. Le modèle se met parfois à cracher de longues listes de noms et d’adjectifs liés au sujet, donc j’ai probablement mal configuré quelque chose

    • Je me demande quels modèles vous faites tourner sur une RTX 3090
      Je pensais que la plupart des modèles vraiment utilisables demandaient au minimum 48 à 64 Go de VRAM pour tourner correctement, et c’est pour ça que je croyais que les puces Apple série M avec mémoire unifiée étaient populaires dans ce domaine

  • Ce genre de produit existe déjà aussi sous une forme prête à l’emploi, mais ça se limite à 3 mois de garantie constructeur
    https://ebay.com/itm/297819576914/…

    • C’est vraiment tentant. J’imagine que la modification du ventilateur mentionnée ici n’a pas été faite

  • Aux États-Unis, les modèles 32 Go d’occasion se négocient autour de 600 dollars
    Pour l’adaptateur, je pense que je l’achèterais directement en Chine, son pays d’origine

  • Je me demande s’il existe un équivalent côté AMD. J’utilise en ce moment deux W7900 de 48 Go, et j’aimerais étendre la configuration pour pouvoir faire tourner des modèles plus gros

    • Dans une certaine mesure, oui. Il y a l’Instinct MI60 de la même époque que la V100 ; c’est assez ancien, mais il y a 32 Go de VRAM, et il existe déjà en version carte PCIe
      Il faut ajouter le refroidissement, mais pas besoin de bricoler avec des adaptateurs
      Je lis tout ce que je trouve sur les configurations de modèles en local, et pour l’instant, dans la tranche de besoin intermédiaire en VRAM de 48 à 128 Go, il ne semble vraiment pas y avoir de point idéal en rapport qualité-prix. En gros, il y a trois options : plusieurs GPU de datacenter d’il y a trois générations (Tesla V100, Instinct MI60), plusieurs produits d’entrée de gamme de génération actuelle avec beaucoup de VRAM (Arc Pro B70), ou des boîtiers tout-en-un de génération actuelle (DGX Spark, Mac Mini, Strix Halo)
      Pour quelqu’un qui passe d’un GPU grand public de 32 Go ou de deux GPU de 16 Go, chacune implique des compromis, mais a aussi des avantages. En revanche, si vous utilisez déjà deux cartes de 48 Go, je ne sais pas vraiment s’il existe une mise à niveau en matériel d’occasion qui donne l’impression d’un vrai gain sensible