- 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
2 commentaires
Avis sur Hacker News
J’ai moi aussi récemment acheté un GPU de datacenter et je l’ai branché dans mon système, donc voici quelques retours d’expérience absents de l’article
Les NVIDIA V100 et AMD MI50 de réforme sont assez abordables pour des expérimentations locales : environ 200 dollars pour 16 Go et 400 à 500 dollars pour 32 Go, mais ce sont tous les deux des cartes très anciennes. Cela dit, il existe une communauté de développeurs amateurs qui continue à les faire vivre sur des plateformes et avec des modèles récents
Petite précision : le V100 ne prend pas en charge le bfloat16. Pour bidouiller des modèles en local, la perte de performance n’est pas énorme, mais du point de vue des fonctionnalités matérielles, c’est une carte en voie de sortie
Le MI50 prend en charge le bf16, mais n’est pas supporté par les versions récentes d’AMD ROCm. Le support Vulkan est bon et il fonctionne sur la plupart des grandes plateformes comme llama.cpp et vllm, mais avec des désagréments comme une recompilation manuelle. Heureusement, la communauté open source a déjà bien préparé le terrain
Il ne faut surtout pas sous-estimer les exigences de refroidissement de ce type de carte. Un GPU grand public peut throttler dans un petit boîtier sans ventilateur supplémentaire, mais un GPU de datacenter, dans les mêmes conditions, surchauffera même au repos. Il faut au minimum acheter plusieurs bons ventilateurs de 120 mm, ou investir dans un refroidissement liquide
Au final, j’ai acheté un AMD MI100 32 Go pour 950 dollars. J’aime bien AMD, le ROCm récent est pris en charge, et la configuration était relativement simple. J’envisage d’en acheter un deuxième pour faire tourner des modèles plus gros comme qwen3-coder-next
Le carénage s’adapte parfaitement à l’entrée d’air du GPU, ce qui permet d’envoyer tout le flux d’air du ventilateur monté vers le GPU, et on peut aussi lier la courbe de vitesse du ventilateur à la température du GPU
Ce genre de carte suppose un flux d’air de niveau serveur, probablement avec une arrivée d’air froid. Mon ami a imprimé un support de ventilateur, l’a fixé dessus, et depuis ça fonctionne bien
Moi aussi je regarde ce type de carte d’un peu plus près, mais pour l’instant je n’arrive pas vraiment à justifier l’achat, parce que faire tourner les modèles Qwen3.6 MOE sur une 6800xt reste supportable pour les projets que je veux confier à l’IA locale
Le travail est impressionnant, mais le vrai problème n’est pas d’avoir 30 tok/s, ce qui suffit pour le codage agentique et le chat, c’est le prefill
Un prefill lent ruine immédiatement les charges de travail de type agent. D’après l’article original, traiter 10000 tokens à environ 150 tok/s fait 100000 / 150 secondes, soit environ 11 minutes et 6,7 secondes, donc l’attente est loin d’être négligeable
C’est aussi un problème général des LLM locaux sur Mac. Les Mac sont bien placés pour offrir beaucoup de mémoire à haute bande passante, mais leur puissance de calcul reste très en retrait par rapport aux GPU dédiés de la génération actuelle. Certaines configurations coûteuses de Mac Studio peuvent faire tourner de très gros modèles à un débit en tok/s acceptable, mais il faut parfois attendre longtemps avant que la génération de tokens ne commence
Dans un langage comme le C++, où les modules sont séparés entre définitions (.h) et implémentations (.cpp), on pourrait prendre tous les fichiers d’en-tête du projet comme préfixe, puisqu’ils ont peu de chances de changer souvent
Plus généralement, l’idée serait d’avoir un agent dont l’objectif principal de gestion de contexte est de réutiliser un préfixe mis en cache
Pour mettre en cache même des fichiers déjà modifiés, l’agent pourrait construire le contexte à partir d’un préfixe fixe représentant une partie ou la totalité du code source au début de la session, puis ajouter ensuite les modifications à la fin. Il faudrait alors un prompt demandant explicitement d’utiliser uniquement les définitions les plus récentes des fonctions
Par exemple, si au départ le fichier A contient les fonctions X, Y et Z, alors le préfixe du prompt contiendra X Y Z. Si l’utilisateur remplace Y par Y', on ajoute ce contenu au contexte, de sorte que le préfixe mis en cache reste inchangé et qu’on obtienne X Y Z Y'
Si on veut que le LLM commence à collaborer instantanément dès qu’on bascule sur un projet, c’est frustrant, mais même le meilleur collaborateur humain a besoin d’un long temps d’onboarding avant de pouvoir contribuer de manière significative
Contrairement à ce qu’écrit l’auteur, la Tesla V100 SXM2 16 Go n’est pas de classe DGX, mais de classe HGX
Il existe deux variantes du V100, SXM2 et SXM4, la seconde allant jusqu’à 80 Go de mémoire embarquée. On trouve souvent 8×A100 80 Go SXM4 installés sur un riser HGX, ce qui donne un fabric NVSwitch et 640 Go de HBM2e mutualisée. C’est de la mémoire empilée dans le package, avec une bande passante mémoire d’environ 2 To/s, dans un format rack standard 2U
Le V100 n’offre pas 2 To/s
HGX, c’est plutôt quelque chose comme un DGX avec de la configuration supplémentaire
En voyant seulement le titre, je m’attendais à voir comment on utilisait ça pour jouer, mais au final il ne faisait que lancer un LLM
Les AMD MI250X sont aussi intéressantes. 128 Go de HBM2E, 3 To/s, et on en voit parfois d’occasion à moins de 1 000 dollars
Le problème, c’est qu’il faut un socket OAM. Je n’ai pas vu de moyen simple de les brancher sur une carte mère standard
En plus, les unités HPE démontées qu’on voit à bas prix sur eBay demandent un truc propriétaire spécifique à HPE pour fonctionner, et je n’ai encore vu personne réussir à percer ça
La MI250X s’insère physiquement et le système la voit, mais le pilote ne fonctionne pas. Le test a été fait avec une MI250X HPE
Dans ce fil, il circule une rumeur selon laquelle il existerait deux types de MI250X : une version pour HPE et les autres. La version HPE nécessiterait un firmware spécial, contrairement à la version standard. Comme la plupart des MI250X du marché de l’occasion semblent être des HPE, prudence pour les acheteurs
Excellent article. J’ai souvent envisagé ce genre de cartes de datacenter pour des projets, et maintenant ça me donne vraiment envie d’en acheter une
La partie qui compare le prix du matériel au coût des tokens a été décisive
Félicitations. La plupart des gens n’ont sans doute pas envie de déboguer les pilotes, le kernel, l’ACPI, les adaptateurs et les connecteurs de ventilateurs, mais pour ceux qui sont prêts à le faire, le rapport performances/prix est totalement délirant
Je ne trouve pas très honnête une évaluation du type : « si vous voulez le meilleur absolu, il y a aussi Opus 4.8. Mais le coût de 20 minutes d’usage intensif est supérieur au prix total de ce GPU et de son adaptateur. Et pourtant l’écart est étonnamment faible »
J’utilise tous les jours des modèles de pointe avec des tokens API prépayés, mais je dépasse à peine 100 dollars par mois. C’est impressionnant d’avoir trouvé comment brûler le double en 20 minutes, mais je ne pense pas que cela reflète la réalité actuelle de beaucoup de gens. Une manière d’utiliser les LLM qui consomme énormément sert ici commodément d’homme de paille dans la discussion
Il est presque toujours plus économique de payer des coûts d’API que d’héberger soi-même une infrastructure équivalente. Je ne suis pas opposé à l’auto-hébergement, mais l’article présente la rentabilité comme motivation principale de cette tentative. Si vous consommez moins de 10^9 tokens par mois, je ne pense pas qu’il soit très utile de passer du temps à essayer de rivaliser avec les hyperscalers. L’argent se trouve surtout dans l’intégration de cette technologie au business existant
Si votre usage est aussi léger, un abonnement sera bien plus économique. Au-delà, l’intérêt de basculer une partie en local dépendra surtout du prix de votre électricité. Dans mon cas, clairement non
/fast, c’est faisable en une dizaine de minutesJe ne sais vraiment pas comment les autres s’en servent
D’après ccusage, sans l’abonnement Max à 100 dollars, j’aurais dû payer environ 4 173 dollars à Anthropic en mai
Input │ Output │ Cache Create │ Cache Read │ Total Tokens │ Cost (USD)
1,948,016 │ 19,435,081 │ 103,626,350 │ 6,244,194,278 │ 6,369,203,725 │ $4173.09
Ce sont des chiffres recalculés récemment ; je n’ai pas du tout utilisé le mode Fast, mais j’ai utilisé Opus pour la plupart des tâches
Mon usage n’est même pas particulièrement extrême. En général, Claude Code tourne en continu sur un ou deux projets, parfois même pendant mon sommeil. J’atteins souvent 60 à 80 % de la limite hebdomadaire
Ça fait plaisir de voir du vieux matériel recyclé. J’utilise deux Tesla V100 dans un serveur Supermicro X10DRU-i bi-processeur
Avec qwen3.6-27B-mtp, sur des tailles de contexte moyennes, donc sous 128k, j’obtiens environ 35 à 40 tok/s en inférence, et j’ai aussi lancé de longues tâches d’agents consommant des centaines de millions de tokens. Si j’avais payé ça via l’API Claude, cela aurait coûté plusieurs centaines de dollars, voire plus
Mais l’usage principal de ces cartes reste le calcul scientifique. Elles offrent plus de 7 TFLOPS en FP64, ce qui est excellent vu leur âge, et c’est un niveau qu’il reste difficile d’obtenir même sur des cartes grand public récentes depuis que NVIDIA a bridé les performances des cartes grand public après Kepler. Le serveur est au sous-sol, et il fait un vacarme incroyable
La partie la plus intéressante, et probablement la plus utile pour le plus grand nombre, c’est sans doute le contrôle des ventilateurs. Il faut absolument pouvoir les contrôler pour faire ça. C’est vraiment très bruyant
Si vous envisagez ce genre de cartes, il faut aussi savoir que la consommation au repos des V100 est très élevée. Même sans rien charger, elles tirent 25 à 35 W, et une fois un modèle chargé, elles montent facilement jusqu’à 50 W
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 sourireIl 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 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/…
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
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