🧩 Stations Multi-GPU : NVIDIA, PCIe et VRAM

Après la mémoire unifiée, l’autre grande famille de machines IA on-premise est la station multi-GPU : plusieurs cartes NVIDIA dans une même tour, ou plusieurs accélérateurs dans un serveur.

L’idée paraît simple : additionner la VRAM de plusieurs cartes pour charger des modèles plus gros. En pratique, le multi-GPU n’est pas un simple “pool de mémoire”. Il faut choisir un mode de parallélisme, accepter des échanges entre cartes, et comprendre si ces échanges passent par PCIe, NVLink ou un fabric RDMA / RoCE.

🎯 Pourquoi du multi-GPU ?

Une station multi-GPU répond à trois besoins différents :

Capacité mémoire : charger un modèle qui ne tient pas sur une seule carte.
Débit : servir plus de requêtes en parallèle, souvent en répliquant le modèle.
Latence : accélérer un gros modèle en répartissant ses calculs sur plusieurs GPU.

Ces trois objectifs ne demandent pas la même architecture. Une machine à deux cartes peut être excellente pour servir deux utilisateurs indépendants, mais décevante pour accélérer un seul modèle si les cartes ne communiquent que par PCIe.

🧱 Le paysage matériel : workstation vs serveur

1. GPU workstation PCIe

Les cartes professionnelles de workstation maximisent la flexibilité : elles entrent dans des stations x86 classiques, utilisent CUDA, et restent compatibles avec les moteurs d’inférence courants.

Carte	Mémoire	Bande passante mémoire	Interface	Puissance
NVIDIA RTX 6000 Ada	48 Go GDDR6 ECC	960 Go/s (datasheet)	PCIe 4.0 x16	300 W
NVIDIA RTX PRO 6000 Blackwell Workstation	96 Go GDDR7 ECC	1 792 Go/s	PCIe 5.0	600 W

La RTX 6000 Ada reste une base workstation solide avec 48 Go de GDDR6 ECC et PCIe Gen 4 x16 ¹. La RTX PRO 6000 Blackwell double la capacité à 96 Go, passe à la GDDR7 ECC, annonce 1 792 Go/s de bande passante mémoire et le support PCIe Gen 5 ².

Ce sont des cartes très intéressantes pour l’on-premise car elles offrent de la VRAM locale rapide et un écosystème logiciel mature. Mais dans une station multi-GPU standard, les échanges entre cartes dépendent exclusivement du bus PCIe.

2. Serveurs d’inférence SaaS (L40S, A100)

Entre les stations workstation PCIe et les nœuds HGX datacenter, il existe une catégorie souvent ignorée mais centrale pour les déploiements souverains à l’échelle d’une équipe ou d’un SaaS : le serveur d’inférence rack, optimisé pour servir 10 à 200 utilisateurs simultanés à un coût par token maîtrisé.

GPU	VRAM	Bande passante	FP8 natif	Positionnement
NVIDIA L40S	48 Go GDDR6	864 Go/s	✅ Oui (Ada Lovelace)	Inférence SaaS — meilleur coût/token en production
NVIDIA A100 (80 Go)	80 Go HBM2e	2 000 Go/s	❌ Non (FP16 max)	Legacy solide, disponible chez hébergeurs souverains FR
NVIDIA A100 (40 Go)	40 Go HBM2e	1 555 Go/s	❌ Non	Compromis capacité/coût pour modèles 13–34B
RTX 6000 Ada / RTX 4090	48 / 24 Go	960 / 1 008 Go/s	⚠️ Partiel	On-prem client air-gapped (matériel fourni par le client)

Le NVIDIA L40S — le “joyau caché” de l’inférence 2026

Le L40S (architecture Ada Lovelace) est souvent sous-estimé car il n’a pas la bande passante HBM d’un H100. Il compense par deux avantages décisifs pour l’inférence de production³ :

Tensor Cores 4ᵉ génération avec FP8 natif : la quantification FP8 du modèle et du KV Cache est native, sans contournement logiciel. Sur les architectures Hopper (H100), vLLM doit passer par des émulations FP8 logicielles ; sur Ada, c’est du silicium⁴.
Meilleur coût/token en inférence : les benchmarks MLPerf Inference Datacenter 2024 placent le L40S comme le GPU offrant le plus faible coût par token généré pour les modèles de la classe 70B en production — devant l’A100 et à égalité approximative avec l’H100 sur ce ratio spécifique⁴.

Un serveur bare-metal équipé de deux L40S (96 Go de VRAM totale) constitue la topologie de référence pour héberger un modèle 70B en quantification FP8 et servir 20 à 80 utilisateurs simultanés avec un TTFT < 2 s.

L’A100 — le cheval de trait historique

L’A100 reste le GPU datacenter le plus disponible chez les hébergeurs souverains français (OVHcloud, Scaleway, Outscale). Son immense bande passante HBM2e compense l’absence de FP8 natif pour les modèles en FP16 ou BF16. Il reste pertinent pour :

Les modèles non encore disponibles en FP8 optimisé.
Les déploiements chez des hébergeurs certifiés HDS/SecNumCloud où le L40S n’est pas encore proposé.

RTX workstation pour l’on-prem client (Tier Air-Gapped)

Lorsqu’un client déploie la stack sur son propre matériel (Tier 3 / air-gapped), il n’est pas nécessaire d’imposer des GPU datacenter à 15 000 €. Une station équipée d’une ou deux RTX 6000 Ada (48 Go PCIe) suffit pour servir les requêtes internes d’une équipe de 10 à 30 personnes, à condition que le moteur d’inférence (vLLM ou SGLang) soit correctement configuré.

3. Serveurs NVLink / NVSwitch

Les serveurs datacenter NVIDIA changent de catégorie : dans un système HGX/DGX, les GPU peuvent communiquer via NVLink et NVSwitch plutôt que seulement via PCIe.

NVIDIA décrit les systèmes HGX H100/H200 à huit GPU comme des machines où chaque GPU Hopper peut communiquer à 900 Go/s avec les autres via NVLink/NVSwitch, avec un fabric non bloquant dans le nœud ⁵. Pour Blackwell, NVIDIA indique que la cinquième génération de NVLink double la vitesse par GPU à 1 800 Go/s dans les systèmes adaptés ⁵.

Ce niveau d’interconnexion n’est pas un détail : il rend le tensor parallelism beaucoup plus viable, car les GPU doivent échanger des activations et résultats intermédiaires à chaque génération.

🛣️ PCIe : le goulot discret

PCIe est le bus généraliste qui relie CPU, GPU, SSD et cartes réseau. PCI-SIG indique que PCIe 5.0 monte à 32 GT/s par lane, soit le double de PCIe 4.0 ⁶.

Pour une carte GPU en x16, cela donne un ordre de grandeur théorique d’environ 64 Go/s par direction en PCIe 5.0, avant de tenir compte des contraintes réelles de plateforme. C’est élevé pour de l’I/O généraliste, mais très faible comparé à la bande passante interne d’une carte GPU moderne : 960 Go/s sur RTX 6000 Ada, 1 792 Go/s sur RTX PRO 6000 Blackwell ¹².

graph TD
    A[RAM système] -->|PCIe x16: dizaines de Go/s| B[GPU 0 - VRAM locale]
    A -->|PCIe x16: dizaines de Go/s| C[GPU 1 - VRAM locale]
    B -. echanges inter-GPU via PCIe .-> C
    B -->|GDDR/HBM: centaines a milliers de Go/s| D[Calcul GPU 0]
    C -->|GDDR/HBM: centaines a milliers de Go/s| E[Calcul GPU 1]

Conséquence : si un moteur d’inférence doit beaucoup synchroniser deux GPU via PCIe, l’accélération attendue peut disparaître. Le multi-GPU PCIe fonctionne mieux quand les communications sont rares, quand les requêtes sont indépendantes, ou quand le moteur sait choisir un parallélisme adapté.

Les Switches PCIe (Broadcom PLX) — le P2P sans passer par le CPU

Dans une station standard, les échanges GPU↔GPU transitent via le CPU : GPU 0 écrit en RAM système, le CPU relit, et envoie à GPU 1. C’est lent et charge le processeur inutilement.

Les meilleures stations IA (et certains serveurs de workstation denses) utilisent des puces Switch PCIe — principalement les séries Broadcom PLX PEX — intégrées à la carte mère ou à une carte d’expansion. Ces puces permettent un transfert Peer-to-Peer (P2P DMA) direct :

flowchart LR
    A["GPU 0 VRAM"] -->|"P2P DMA\n(sans CPU ni RAM système)"| B["Switch PCIe (PLX)"]
    B --> C["GPU 1 VRAM"]

Avantages concrets :

La latence de transfert inter-GPU chute significativement
Le CPU est libéré pour d’autres tâches pendant la synchronisation
Le débit reste plafonné à ~64 Go/s (PCIe 5.0 x16) — mais avec une latence bien inférieure au trajet CPU

Identifier une carte mère avec switch PLX : Cherchez dans les specs carte mère les mentions “PCIe switch”, “PLX”, “PEX switch”, ou “NVMe bifurcation with PLX”. Les cartes mères HEDT (High-End Desktop) et les plateformes serveur entry-level (AMD EPYC, Intel Xeon) incluent souvent ces puces nativement.

🧠 Les modes de parallélisme

Data Parallel : plusieurs copies du modèle

Le data parallel réplique le modèle sur plusieurs GPU. Chaque carte sert des requêtes différentes.

Avantage : très efficace pour augmenter le débit multi-utilisateur si le modèle tient sur une carte.
Limite : la VRAM ne s’additionne pas pour un seul modèle, car chaque GPU garde sa propre copie.

TensorRT-LLM décrit ce mode comme adapté aux grands lots et scénarios de débit élevé ⁷.

Tensor Parallel : un modèle coupé dans chaque couche

Le tensor parallelism découpe les poids d’une même couche sur plusieurs GPU. C’est le mode intuitif quand un modèle est trop gros pour une seule carte.

vLLM recommande ce mode quand le modèle ne tient pas sur un GPU mais tient dans un nœud multi-GPU ; on configure par exemple --tensor-parallel-size 4 pour quatre GPU ⁸. TensorRT-LLM décrit aussi le TP comme un sharding des poids à travers les GPU ⁷.

Avantage : peut réduire la pression VRAM par GPU et exploiter plusieurs bandes passantes mémoire.
Limite : demande des communications fréquentes ; NVLink/NVSwitch aide beaucoup, PCIe peut devenir limitant.

Pipeline Parallel : le modèle coupé par blocs de couches

Le pipeline parallelism distribue des groupes de couches sur plusieurs GPU. Les activations passent d’une carte à l’autre.

vLLM recommande de combiner tensor parallel et pipeline parallel quand le modèle dépasse un seul nœud, avec tensor_parallel_size pour les GPU par nœud et pipeline_parallel_size pour le nombre de nœuds ⁸. TensorRT-LLM liste aussi ce mode comme stratégie centrale ⁷.

Avantage : plus tolérant aux interconnexions lentes que le TP pur dans certains cas.
Limite : peut créer des “bulles” où certains GPU attendent, surtout avec de petits lots.

⚖️ Choisir entre APU, mono-GPU, multi-GPU PCIe et serveur NVLink

Besoin	Architecture souvent rationnelle	Pourquoi
LLM 70B quantifié, faible bruit, grande RAM	APU / mémoire unifiée	Simple, grande capacité, pas de copie RAM→VRAM
Modèle qui tient en 48–96 Go VRAM	Mono-GPU workstation	Simple, rapide, peu de synchronisation
Plusieurs utilisateurs / plusieurs modèles	Multi-GPU en réplication	Chaque GPU sert une charge indépendante
SaaS souverain, 10–200 users, coût/token optimisé	Serveur L40S ou A100	FP8 natif, meilleur TCO inférence, disponible chez hébergeurs FR
Modèle trop gros pour une carte, même nœud	Multi-GPU avec TP/PP	Possible si le moteur supporte le sharding
Très gros modèles, faible latence, production	Serveur NVLink/NVSwitch	Fabric inter-GPU adapté aux communications fréquentes

Le piège classique est d’acheter “2 × 48 Go” en pensant obtenir une carte virtuelle de 96 Go. C’est seulement vrai si le moteur sait répartir le modèle et si l’interconnexion ne détruit pas le gain.

📋 Le Conseil de l’Architecte

Pour un déploiement souverain on-premise :

Commencer par le besoin de service, pas par le nombre de GPU. Un seul utilisateur sur un gros modèle dense n’a pas les mêmes contraintes qu’un serveur multi-utilisateur.
Privilégier le mono-GPU quand le modèle tient. Une RTX PRO 6000 Blackwell 96 Go peut être plus simple qu’une station 2 × 48 Go pour un modèle qui tient dans 96 Go ².
Utiliser le multi-GPU PCIe pour le débit. Plusieurs cartes peuvent servir plusieurs répliques ou plusieurs modèles avec peu de communication entre elles.
Pour un SaaS souverain ou un service multi-utilisateurs, évaluer le L40S ou l’A100. Un serveur bare-metal 2× L40S offre le meilleur TCO inférence pour un modèle 70B en production. L’A100 reste le choix par défaut chez les hébergeurs souverains français déjà certifiés HDS.
Réserver le tensor parallel exigeant aux interconnexions rapides. vLLM et TensorRT-LLM supportent le TP, mais les docs insistent sur l’importance du réseau/interconnect pour éviter que les communications dominent ⁷⁸.
Ne pas confondre station et datacenter. NVLink/NVSwitch change radicalement le profil, mais il appartient surtout aux plateformes serveur NVIDIA compatibles ⁵.

🔭 Accélérateurs non-NVIDIA : état en 2026

Au-delà de NVIDIA, plusieurs constructeurs positionnent des alternatives pour l’inférence et l’entraînement on-premise. L’état du marché en 2026 reste celui d’un écosystème en formation — intéressant à surveiller, pas encore recommandé pour des déploiements B2B stricts.

Tenstorrent (Wormhole / Blackhole)

Tenstorrent (fondé par Jim Keller) commercialise les accélérateurs Wormhole (N150, N300) et annonce la génération Blackhole. L’architecture est software-first, basée sur des cœurs RISC-V avec une SRAM locale massive et de la GDDR6 externe, et une interconnexion Ethernet intégrée entre puces ⁹.

Avantages revendiqués : coût d’achat nettement inférieur à des GPU NVIDIA équivalents en TFLOPS, pile logicielle open-source TT-Forge (TT-Metal + compilateur MLIR), interconnexion Ethernet native pour le scale-out sans switch propriétaire.

Limites réelles en 2026 :

vLLM standard incompatible : il faut utiliser le fork tenstorrent/vllm avec un environnement tt-metal compilé manuellement — procédure non triviale, non maintenue par l’équipe vLLM principale. Source communautaire ⁹ — voir aussi la note dans Moteurs d'Inférence.
Compatibilité modèles partielle : le compilateur TT-Forge ne supporte pas encore tous les opérateurs des architectures récentes — une compatibilité « 90 % des modèles » est insuffisante pour des déploiements B2B qui doivent garantir le comportement de chaque modèle.
Écosystème logiciel jeune : pas encore de support officiel HuggingFace, LangChain, ni des outils de monitoring courants (Prometheus metrics, OpenTelemetry).

📚 Sources et Références

NVIDIA, RTX 6000 Ada Generation Graphics Card (48 Go GDDR6 ECC, PCIe Gen 4 x16, 300 W). https://www.nvidia.com/en-us/products/workstations/rtx-6000/ ↩ ↩² ↩³
NVIDIA, RTX PRO 6000 Blackwell Workstation Edition (96 Go GDDR7 ECC, 1 792 Go/s, PCIe Gen 5, 600 W). https://www.nvidia.com/en-us/products/workstations/professional-desktop-gpus/rtx-pro-6000/ ↩ ↩² ↩³ ↩⁴
NVIDIA, L40S Product Page (Ada Lovelace, FP8 Tensor Cores, 48 Go GDDR6 ECC). https://www.nvidia.com/en-us/data-center/l40s/ ↩
MLCommons, MLPerf Inference Datacenter v4.1 Results (benchmark inférence datacenter, coût/token). https://mlcommons.org/benchmarks/inference-datacenter/ ↩ ↩²
NVIDIA Technical Blog, NVIDIA NVLink and NVIDIA NVSwitch Supercharge Large Language Model Inference (NVLink/NVSwitch, 900 Go/s Hopper, 1 800 Go/s Blackwell). https://developer.nvidia.com/blog/nvidia-nvlink-and-nvidia-nvswitch-supercharge-large-language-model-inference/ ↩ ↩² ↩³
PCI-SIG, PCI Express 5.0 FAQ (32 GT/s par lane, double PCIe 4.0). https://pcisig.com/faq?field_category_value%5B%5D=pci_express_5.0 ↩
NVIDIA TensorRT-LLM, Parallelism in TensorRT LLM (TP, PP, DP, EP, CP). https://nvidia.github.io/TensorRT-LLM/features/parallel-strategy.html ↩ ↩² ↩³ ↩⁴
vLLM, Parallelism and Scaling (tensor parallel, pipeline parallel, Ray, multiprocessing, GPUDirect RDMA). https://docs.vllm.ai/en/stable/serving/parallelism_scaling/ ↩ ↩² ↩³
Tenstorrent, vLLM integration with TT-Metal (architecture Wormhole, fork tenstorrent/vllm, compatibilité partielle vLLM standard), 2025. https://github.com/tenstorrent/tt-metal/blob/main/tech_reports/LLMs/vLLM_integration.md ↩ ↩²