Étude de cas : station de travail IA 4x RTX 4090

Cet article documente une configuration complète commandée par un client du secteur de la recherche, qui avait besoin d'une station de travail d'inférence LLM montable en rack, capable de fonctionner 24h/24 et 7j/7, avec assez de VRAM pour héberger des modèles de classe 70B sans dépendre du cloud. Tout ce qui suit est mesuré sur le matériel réel. Aucune estimation synthétique, aucun chiffre marketing.

La configuration a été commandée et livrée en avril 2026. Les tests de mise en service ont été réalisés le 2026-04-10.

Pourquoi 4× RTX 4090

Le besoin était clair dès le départ : faire tourner un LLM 70B quantifié avec une latence utilisable sur requête unique, servir des requêtes simultanées pour une petite équipe de recherche et tout garder sur site pour des raisons de contrôle des données. La question était de savoir combien de GPU, et lesquels.

Un modèle 70B en INT4 (AWQ ou GGUF Q4_K_M) occupe en pratique environ 38–40 GB de VRAM. Cela élimine d'emblée toute solution mono-GPU — même une RTX 4090 avec ses 24 GB ne peut héberger le modèle à elle seule. Il en faut au moins deux, et de préférence quatre, pour que le service en parallélisme de tenseurs sous vLLM dispose de marge pour le cache KV.

Quatre cartes RTX 4090 totalisent 96 GB de VRAM. C'est suffisant pour charger un modèle Llama 3.3 70B AWQ INT4 avec gpu_memory_utilization=0.80 tout en conservant un espace de cache KV appréciable pour les requêtes par lots. Cela apporte aussi une capacité de calcul — 4× puces de 128 SM fonctionnant simultanément — qui compte pour la vitesse de traitement des prompts.

L'alternative envisagée était 4× RTX Pro 6000 Blackwell, soit 4× 96 GB = 384 GB de VRAM. On change alors complètement de catégorie : bien plus de VRAM que n'en demande un seul modèle 70B, un choix adapté à l'exécution simultanée de plusieurs grands modèles ou à l'hébergement de modèles de classe 200B+ avec une quantification raisonnable. Pour cette charge de travail — un modèle principal, un lot simultané réduit, un budget de station de travail mono-locataire — cette capacité supplémentaire serait restée inutilisée et l'écart de prix est important. Les 4× RTX 4090 étaient la bonne réponse au cas d'usage décrit.

Une alternative en 8× L40 existe également dans la gamme. La L40 offre 48 GB de VRAM par carte, la prise en charge de l'ECC et elle est conçue pour une charge soutenue en centre de données. Pour ce client, la charge de travail n'exigeait pas de contrats de fiabilité de niveau centre de données, l'absence des caprices de pilotes propres aux cartes grand public ne constituait qu'un avantage mineur et le budget n'allait pas jusque-là. À connaître comme voie d'évolution.

Un plafond architectural à annoncer d'emblée : les cartes RTX 4090 n'ont pas de NVLink. Toute la communication entre GPU passe par le PCIe peer-to-peer. C'est important pour l'inférence en parallélisme de tenseurs (voir la section benchmarks) et il vaut mieux l'avoir compris avant de commander. Voir N03 pour un traitement complet des cas où NVLink compte et de ceux où il ne compte pas.

Spécifications matérielles

Quelques remarques sur ces choix :

CPU. L'EPYC 7542 est une puce de génération Rome à 32 cœurs, avec 128 MB de cache L3 répartis sur 8 CCD. Pour une station de travail d'inférence, c'est surdimensionné en nombre de cœurs bruts — vous ne saturerez pas 64 threads en inférence pure. Là où il justifie sa place, c'est le budget de lignes PCIe : l'EPYC Rome fournit 128 lignes PCIe 4.0 depuis le CPU, ce qui permet d'installer quatre GPU en x16 complet sur cette plateforme sans partage de lignes ni bifurcation. La RTX 4090 est un périphérique PCIe 4.0 x16 ; il vous faut quatre ports x16 complets, et l'EPYC les fournit. Voir W02 pour le détail de la topologie des lignes.

RAM. Le système a été livré avec 512 GB de DDR4 ECC LRDIMM, au-delà des 256 GB spécifiés à l'origine. La RAM système supplémentaire est réellement utile ici : le chargement d'un modèle depuis le NVMe transite par la RAM système avant le transfert vers la VRAM, et pour des modèles plus volumineux ou lorsqu'on alterne entre modèles, 512 GB permettent de conserver plusieurs jeux de poids en RAM simultanément et d'éviter des lectures NVMe répétées.

NVMe. Le stockage des modèles (2 TB) repose sur un disque NVMe PCIe 4.0 à haute vitesse. La vitesse de lecture séquentielle compte au chargement : un fichier de modèle de 38 GB lu à 4,589 MB/s en séquentiel se charge en 8–10 secondes environ. Les temps de chargement mesurés le confirment : llama.cpp a chargé le GGUF 70B Q4_K_M en 10.8 secondes ; vLLM (qui construit aussi les graphes CUDA au chargement) a mis 95 secondes.

Double alimentation. Le châssis utilise deux blocs d'alimentation ATX. Il s'agit d'une alimentation répartie : chaque bloc alimente une partie du système — typiquement deux GPU et les composants de carte associés. Si un bloc tombe en panne, vous perdez les GPU de son rail. Ce n'est pas une redondance N+1 ; c'est un dispositif de capacité électrique, pas un dispositif de bascule. Pour les systèmes de production où la disponibilité est contractuelle, cette distinction compte. Voir W04 pour la discussion complète sur le dimensionnement des alimentations.

Flux d'air du châssis. Le châssis est au format rack, avec un flux d'air industriel dirigé de l'avant vers l'arrière. Les GPU ne sont pas à l'air libre : ils se trouvent dans un canal d'air dirigé, des ventilateurs de boîtier faisant passer l'air sur les dissipateurs avant de l'évacuer à l'arrière. Le système convient donc à un fonctionnement soutenu 24h/24 et 7j/7 en environnement rack. Voir W05 pour le détail de la conception thermique.

Pile logicielle

L'environnement Python se trouve dans /home/logic/llm-env/, les modèles sur le NVMe dans /mnt/nvme/models/.

Résultats de mise en service

Référence de calcul GPU

Le premier test est toujours le calcul brut : multiplication matricielle en FP16 (chemin Tensor Core) et en FP32. Cela confirme que les cartes fonctionnent correctement et fournit une base de calcul à comparer aux spécifications nominales.

Pour référence : le pic théorique FP16 sur Tensor Core de la RTX 4090 est d'environ 330 TFLOPS, et le FP32 d'environ 82.6 TFLOPS. Les chiffres du benchmark, à ~52 % du pic FP16, sont attendus — la mesure porte sur un matmul en débit soutenu, qui n'atteint pas le pic théorique d'un noyau GEMM optimisé à la main. Ils confirment que les quatre blocs Tensor Core fonctionnent et restent cohérents entre eux.

Le GPU 1 est ~6 % en dessous des autres en FP16. Il s'agit d'une variation normale du silicium au sein d'un même lot de tri. Aucun défaut matériel.

Bande passante mémoire GPU

Les 920 GB/s de bande passante VRAM sont conformes aux spécifications de la RTX 4090 (1,008 GB/s en pic ; l'écart vient de la surcharge du benchmark). C'est ce chiffre qui compte pour le débit de décodage : chaque token généré impose de charger depuis la VRAM l'ensemble du cache KV et des tenseurs de poids, si bien que la bande passante fixe directement le plafond de la vitesse de génération.

Le chiffre GPU-à-GPU (19–22 GB/s en PCIe peer-to-peer) est la contrainte architecturale pertinente pour le service en parallélisme de tenseurs. Avec NVLink, ce chemin atteint 900 GB/s. En PCIe seul, vous en obtenez environ 2 %. Ce n'est pas catastrophique pour l'inférence — l'essentiel des échanges en parallélisme de tenseurs pour un modèle 70B AWQ INT4 réparti sur 4 GPU tient dans ce que le PCIe peut absorber — mais cela bride la vitesse de décodage sur requête unique par rapport à un système relié en NVLink. Voir la section benchmarks ci-dessous, ainsi que N03 pour la discussion élargie.

Une anomalie : la bande passante périphérique-vers-hôte mesurée à 1.4 GB/s, très en dessous des ~26 GB/s attendus en PCIe Gen4 x16. C'est un comportement CUDA connu avec de la mémoire non épinglée. Si votre application transfère fréquemment des données du GPU vers l'hôte (par exemple l'échantillonnage des logits de sortie dans un pipeline personnalisé), utilisez torch.pin_memory() ou préallouez des tampons épinglés. Les pipelines de service standard vLLM et llama.cpp ne sollicitent pas ce chemin dans la boucle critique.

Tous les liens PCIe sont confirmés en Gen4 x16 (16 GT/s) sous charge. Au repos, le pilote active l'économie d'énergie ASPM et les liens retombent en Gen1 (2.5 GT/s) — c'est normal et ce n'est pas un défaut de câblage ou de riser.

Stockage NVMe

Ce sont de solides chiffres NVMe pour un disque PCIe 4.0 grand public ou prosumer. Pour le service de modèles, le chiffre pertinent est la lecture séquentielle : 4,589 MB/s signifient qu'un modèle de 38 GB se charge en RAM en 8–9 secondes environ, avant tout transfert vers la VRAM. Les 568K IOPS aléatoires comptent davantage si vous exécutez un pipeline de recherche (RAG, base vectorielle), où la charge consiste en de nombreuses petites lectures aléatoires — ce disque l'encaisse sans devenir le goulot d'étranglement.

Inférence vLLM — Llama 3.3 70B AWQ INT4

C'est le benchmark central. Modèle : casperhansen/llama-3.3-70b-instruct-awq. Service : vLLM 0.19.0 avec tensor_parallel_size=4, max_model_len=2048, gpu_memory_utilization=0.80.

La vitesse de décodage de 8.0 tok/s sur requête unique mérite d'être replacée dans son contexte. vLLM 0.19.0 a exécuté le modèle AWQ avec le noyau awq, et non awq_marlin. Le noyau awq_marlin est le chemin le plus rapide pour AWQ sur les GPU Ada Lovelace (RTX 4090) et Blackwell — les notes du benchmark indiquent qu'il n'a pas été retenu lors de cette mise en service, et le gain attendu est de 2–3× sur la vitesse de décodage en requête unique. Avec awq_marlin, le même modèle sur le même matériel devrait atteindre environ 16–24 tok/s en flux unique.

Les 179.3 tok/s agrégés sur 32 requêtes simultanées sont le chiffre le plus pertinent en production. C'est ce qu'une petite équipe sollicitant l'endpoint en même temps verra comme débit combiné du système. Le batching continu de vLLM fait que les requêtes simultanées amortissent le cache KV et le calcul d'attention sur l'ensemble du lot : c'est pourquoi 32× plus d'utilisateurs ne produit pas 32× plus de latence.

Les 2,043 ms de latence sur une requête de 16 tokens constituent le plancher de TTFT (temps jusqu'au premier token) sous vLLM dans cette configuration. Pour des usages interactifs (chat, assistance au code), c'est plutôt lent. Le principal facteur est la surcharge de dispersion/regroupement du parallélisme de tenseurs entre quatre GPU via le PCIe — chaque étape de préremplissage impose un AllReduce sur les quatre cartes à travers le bus PCIe. Avec NVLink, on serait à environ 50–100 ms de TTFT ; avec le PCIe P2P à 20 GB/s, le délai s'allonge encore. C'est le coût direct de l'architecture sans NVLink sur les requêtes uniques sensibles à la latence (voir N03).

llama.cpp — Llama 3.3 70B Q4_K_M GGUF

Modèle : Llama-3.3-70B-Instruct-Q4_K_M.gguf. Backend : llama-cpp-python 0.3.20 avec CUDA/cuBLAS, toutes les couches déportées sur les GPU.

llama.cpp délivre environ 20 tok/s en décodage sur flux unique — mieux que le chiffre vLLM AWQ actuel, ce qui s'explique par le chemin de noyau cuBLAS de llama.cpp, bien adapté à la quantification Q4_K_M. llama.cpp ne gère pas le traitement par lots de plusieurs requêtes simultanées comme le fait vLLM : les 20 tok/s sont donc un plafond par session, pas une capacité agrégée. Pour un flux de travail interactif mono-utilisateur, llama.cpp à 20 tok/s offre une vitesse de lecture confortable pour une sortie en anglais.

La vitesse de traitement du prompt, à 1,568 tok/s, est élevée. Elle mesure la rapidité avec laquelle le modèle ingère le prompt (phase de préremplissage). Un préremplissage rapide compte lorsque vous travaillez avec de longs prompts système ou un contexte documentaire. À 1,568 tok/s, un contexte de 4,000 tokens est traité en moins de 3 secondes avant le début de la génération.

Pour l'aspect économique et la comparaison avec les alternatives cloud, voir T01 (tok/s par euro) et T02 (coût par million de tokens sur site vs cloud).

À quoi sert chacun des deux moteurs

Test de charge — charge soutenue

Trois tests de charge de 60 secondes ont été menés pour vérifier la stabilité thermique et électrique sous charge maximale : burn GPU seul, burn CPU seul et burn GPU+CPU combiné.

Burn GPU (multiplication matricielle FP16 à 100 %, 60 s)

Zéro erreur de calcul sur les quatre GPU. Les températures sont montées d'une base de ~28°C jusqu'à un plateau stable dès la 40e seconde. Le GPU 2 est le plus chaud, à 72°C — c'est la carte la plus exposée dans le flux d'air du châssis à cette position. Le seuil de throttling thermique de la RTX 4090 est de 83°C ; la température la plus élevée mesurée (72°C) laisse 11°C de marge. Le système n'a à aucun moment réduit ses fréquences.

Les plafonds de puissance étaient réglés à des valeurs différentes sur les quatre cartes (480 W, 450 W, 500 W, 480 W). C'est une incohérence mineure, à normaliser : nvidia-smi -pl 480 -i 0,1,2,3 (ou la limite qui convient) pour fixer des plafonds homogènes avant la mise en production.

Burn combiné GPU + CPU (les 4 GPU + 64 threads CPU simultanément, 60 s)

L'ajout de 64 threads CPU à 100 % de charge n'a fait baisser les TFLOPS GPU agrégés que de 0.6 %. L'EPYC 7542 consomme environ 200 W de TDP à pleine charge ; l'ensemble du système tournait à environ 2.1–2.2 kW. Toutes les températures sont restées dans la marge : le GPU 2 a culminé à 73°C sous charge combinée, soit encore 10°C sous le seuil de throttling.

La charge moyenne a dépassé 55 pendant la phase de burn CPU, ce qui est attendu pour 64 threads. Le système est resté parfaitement stable du début à la fin : aucun incident thermique, aucune erreur de calcul, aucun kernel panic.

Cela confirme que le système convient à des charges de travail d'inférence soutenues 24h/24 et 7j/7 où le CPU est également sollicité (prétraitement, tokenisation, surcharge de l'infrastructure de service).

Ce qui a bien fonctionné

La plateforme EPYC. Le budget de lignes PCIe est réellement réglé. Les quatre cartes RTX 4090 fonctionnent en Gen4 x16 complet sous charge, comme l'a confirmé le contrôle d'état PCIe 04d. Pas de bifurcation, pas de ports dégradés. Certaines configurations AMD Ryzen à quatre GPU font tourner deux ports ou plus en x8 ; sur EPYC Rome, ce n'est pas le cas.

RAM. 512 GB, c'est confortable. Pendant le chargement du modèle par llama.cpp, le fichier GGUF de 38 GB est mappé en mémoire ; disposer de 512 GB permet d'exécuter plusieurs processus à côté du serveur LLM sans concurrence sur la mémoire.

Vitesse séquentielle du NVMe. 4,589 MB/s en lecture séquentielle maintiennent des temps de chargement courts. Sur un flux de travail d'itération de modèles — charger, tester, changer de modèle —, cela compte sur une journée entière.

Thermique. Température soutenue dans le pire des cas : 73°C (GPU 2, burn combiné), avec 10°C de marge. Dans une charge de travail d'inférence typique, les GPU ne tourneront pas à 100 % en continu — le décodage est limité par la bande passante VRAM, pas par le calcul — si bien que les températures réelles d'exploitation seront inférieures au pic du test de charge.

Évaluation du prompt à 1,568 tok/s avec llama.cpp. Ce chiffre nous a agréablement surpris. Le chemin de préremplissage cuBLAS sur quatre 4090 est rapide. Les applications à long contexte en profitent.

Ce qui nous a surpris

Le mauvais noyau AWQ sous vLLM. Le benchmark s'est exécuté avec le noyau awq au lieu de awq_marlin. La suite de mise en service l'a déclenché automatiquement d'après la configuration du modèle à ce moment-là. Avec awq_marlin, le débit sur requête unique devrait passer de 8 tok/s à 16–24 tok/s. C'est un correctif de configuration logicielle, pas une limite matérielle — vérifiez la chaîne de méthode de quantification de vLLM lors de la mise en place du service de production.

Bande passante D2H. Le transfert périphérique-vers-hôte à 1.4 GB/s nous a pris de court lors de l'analyse initiale. C'est un comportement de CUDA lié à la mémoire non épinglée, pas un défaut PCIe. Pour les piles de service standard (vLLM, llama.cpp), cela n'a aucune incidence. Pour du code d'inférence personnalisé qui transfère des tenseurs vers le CPU pour un post-traitement, utilisez des allocations en mémoire épinglée.

Erreurs PCIe AER corrigées sur le GPU 3. Pendant le benchmark vLLM, le GPU 3 (bus c1:00.0) a enregistré des erreurs PCIe corrigées (RxErr + BadTLP). Elles ont été corrigées automatiquement par le matériel et n'ont pas affecté les calculs. Cause probable : l'insertion du riser PCIe ou une renégociation du lien à la vitesse Gen4. Nous recommandons de surveiller sous charge de production soutenue ; si le nombre d'erreurs augmente, réinsérez le câble riser du GPU 3. Aucune erreur pendant les tests de charge eux-mêmes.

Bref décrochage du lien réseau. L'interface réseau est brièvement tombée puis revenue pendant la charge du benchmark GPU (13:38 UTC). Probablement un transitoire électrique dû à la montée en puissance simultanée des GPU. En production, avec nvidia-persistenced en service (ce qui maintient les contextes GPU initialisés), les transitoires au démarrage de la charge sont plus faibles. Activez nvidia-persistenced comme service systemd avant la mise en production.

Ce que nous ferions autrement pour la v2

Activer awq_marlin dès le départ. Vérifiez le chemin de noyau de quantification de vLLM pendant la mise en service, et non après. Ajoutez un contrôle d'identité du noyau au script de mise en service.

Normaliser les limites de puissance GPU avant les benchmarks. Les quatre cartes sont livrées avec des limites différentes (480 W, 450 W, 500 W, 480 W). Fixer une limite homogène (nvidia-smi -pl) avant le premier benchmark donne des chiffres plus propres et plus comparables, et évite la consommation hétérogène pendant le burn combiné.

Ajouter une pile de supervision dès la livraison. Prometheus avec l'exportateur DCGM, plus Grafana : quelques heures d'installation suffisent pour rendre visibles en temps réel la température des GPU, l'utilisation de la VRAM et les taux d'erreurs PCIe. À livrer dans le cadre de la mise en service standard plutôt qu'à laisser comme tâche post-livraison. Voir L05 pour le guide d'installation de la pile.

Inscrire nvidia-persistenced dans le fichier d'unité systemd lors de l'installation du système. C'est une seule ligne, mais elle est systématiquement oubliée. Sans elle, la première mise en charge des GPU après une période calme prend quelques secondes de plus et produit le transitoire électrique à l'origine du décrochage réseau.

Extension du LVM. Le disque système (512 GB SATA) n'a que 100 GB alloués à la partition LVM. Les 374 GB restants ne sont pas alloués. Aucune raison de les laisser ainsi : lvextend et resize2fs prennent 30 secondes et vous rendent cet espace pour le système, les journaux et les couches Docker.

Envisager un second NVMe pour le stockage des modèles. L'unique NVMe de 2 TB héberge aujourd'hui tous les modèles et se remplira à mesure que la bibliothèque grandira. Un second NVMe de 4 TB en RAID 0, ou simplement monté séparément sur /mnt/nvme2, apporterait de la souplesse et maintiendrait de hautes performances en lecture séquentielle sur une bibliothèque totale plus vaste.

Comparaison : les alternatives à cette configuration

La charge de travail du client aurait pu être abordée avec un autre matériel. Voici une comparaison honnête :

Les 4× RTX 4090 et leurs 96 GB constituent la configuration minimale viable pour faire tourner Llama 3.3 70B AWQ INT4 sous vLLM avec un débit par lots significatif. Ce n'est pas un plafond : une configuration à 8 GPU ajoute de la capacité proportionnellement. Pour un client du secteur de la recherche qui veut une station de travail dédiée unique — et non un cluster de service —, 4× est souvent le bon point de départ.

Ni la configuration 4×, ni la 8× ne disposent de NVLink entre les GPU, ce qui signifie que l'inférence en parallélisme de tenseurs passe par le PCIe. La conséquence pratique porte sur la latence TTFT des requêtes uniques, pas sur le débit agrégé par lots. Pour une charge de travail à l'échelle d'une équipe (des dizaines de requêtes par heure, pas des milliers), ce n'est pas un facteur limitant. Pour des exigences de TTFT sous 100 ms, voir N03 ainsi que les raisons pour lesquelles la gamme vise le multi-GPU relié en PCIe plutôt que des systèmes à fabric NVSwitch.

Puissance totale et planification électrique

Sous charge GPU soutenue, la puissance totale du système s'est établie autour de 1,900–2,200 W mesurés sur les rails GPU (1,914 W en burn GPU seul ; ~2,100 W estimés en combiné avec le CPU, les disques et la carte). Tenez compte des pertes de rendement des alimentations (comptez 90 %) et prévoyez au minimum un circuit 16 A/230 V, 20 A étant préférable pour disposer de marge.

La double alimentation répartit cette charge sur deux prises. Les deux prises doivent se trouver sur des circuits capables d'absorber la charge indépendamment : si l'alimentation A alimente deux GPU à 500 W chacun plus 200 W de carte et de CPU, cela fait 1,200 W sur son circuit. Dimensionnez en conséquence.

Budget de refroidissement du local : considérez ce système comme 2.5 kW en continu (estimation prudente, pertes de rendement et marge incluses). Pour une salle serveurs ou une baie accueillant plusieurs systèmes, le total grimpe vite.

Voir P01 pour les considérations monophasé vs triphasé et P04 pour le dimensionnement des disjoncteurs.

Fourchette de prix

Une configuration à ces spécifications — plateforme EPYC 7542, 512 GB de RAM ECC, 4× RTX 4090, 2 TB de NVMe, châssis rack à double alimentation — se situe dans la fourchette 18,000–24,000 € HT aux prix actuels des composants, selon le châssis retenu, le moment de l'approvisionnement en RAM et la disponibilité des GPU. Le délai est de 10–28 jours selon la disponibilité des composants, confirmé à la commande.

Cette fourchette ne comprend ni l'installation, ni le PDU de baie, ni le réseau (switch 10 GbE, câblage), ni aucune licence logicielle. Le système est livré avec Ubuntu 24.04 LTS préinstallé et l'environnement virtuel Python préconfiguré ; apportez vos propres poids de modèles.

Ce à quoi cette configuration convient

• Inférence LLM pour la recherche et les petites équipes. Faire tourner un modèle 70B pour une équipe de 5–15 utilisateurs. Les 179 tok/s agrégés sous vLLM absorbent confortablement les sessions simultanées.
• Évaluation et itération de modèles. Les temps de chargement rapides du NVMe rendent le passage d'un modèle candidat à l'autre très rapide. Le budget de lignes PCIe de la plateforme EPYC garantit que les quatre GPU sont toujours à pleine bande passante.
• Déploiements souverains en matière de données. Toute l'inférence est locale. Aucun token ne quitte le bâtiment. C'est la principale raison non économique d'héberger sur site dans un contexte de recherche.
• Point d'entrée 70B à budget maîtrisé. La RTX 4090 est le GPU grand public doté du plus de VRAM. Avec 24 GB par carte et quatre cartes, les 96 GB au total vous amènent à la classe 70B sans passer aux tarifs des GPU professionnels.

Ce à quoi cette configuration ne convient pas

• Un TTFT sous 100 ms sur requête unique. La topologie de parallélisme de tenseurs en PCIe P2P impose un plancher de TTFT pour les grands modèles. S'il vous faut une latence interactive rapide sur des modèles 70B+, cette architecture n'est pas le bon choix. Il vous faut des GPU reliés en NVLink, c'est-à-dire une tout autre catégorie de matériel (voir N03).
• Exécuter plusieurs grands modèles simultanément. Avec 96 GB de VRAM au total et gpu_memory_utilization=0.80, vous disposez d'environ 77 GB exploitables. Un second modèle 70B INT4 ne tiendrait pas. Si vous devez héberger deux modèles en même temps, passez à une plateforme offrant plus de VRAM par GPU, ou davantage de GPU.
• Le service de production à grande échelle. Pour des centaines d'utilisateurs simultanés ou une disponibilité garantie par SLA, cette architecture (aucune carte réseau additionnelle sur un châssis à 4 GPU, nœud unique, GPU grand public sans ECC) n'est pas la bonne base. Le serveur Kentino AI à 8 GPU avec L40 ou RTX Pro 6000 Blackwell, une supervision correcte et deux cartes réseau, lui, l'est.
• L'entraînement de grands modèles. Avec 96 GB de VRAM au total, vous pouvez affiner (LoRA, QLoRA) des modèles 70B, mais vous ne pouvez pas les entraîner sur l'ensemble de leurs paramètres. À l'entraînement, le budget VRAM est plus contraint qu'à l'inférence. Si l'entraînement fait partie du plan de charge, prenez-le en compte.

---

Cet article fait partie du Wiki Kentino, série C (études de cas). Données de configuration mesurées le 2026-04-10. Article publié le 2026-05-15. Corrections et mesures complémentaires bienvenues à info@kentino.com.