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

Cet article décrit la configuration complète d'une station de travail LLM montée en rack et capable de fonctionner 24 h/24 et 7 j/7, sans dépendance au cloud, pour un client du secteur de la recherche. Cette station dispose d'une mémoire vidéo suffisante pour héberger des modèles de classe 70B. Toutes les mesures présentées ici sont basées sur le matériel réel. Aucune estimation artificielle, aucun chiffre marketing.

La construction a été mise en service et livrée en avril 2026. Les tests de mise en service ont été effectués le 10 avril 2026.

Pourquoi 4 cartes RTX 4090 ?

Les exigences en matière de charge de travail étaient claires dès le départ : exécuter un modèle LLM quantifié de 70 milliards de dollars avec une latence acceptable par requête, traiter les requêtes simultanées au sein d’une petite équipe de recherche et conserver l’ensemble des données sur site pour des raisons de contrôle. La question était de savoir combien de GPU et de quel type.

Un modèle de 70 octets au format INT4 (AWQ ou GGUF Q4_K_M) occupe en pratique environ 38 à 40 Go de VRAM. Cela exclut toute solution mono-GPU ; même une RTX 4090 de 24 Go ne peut pas héberger le modèle à elle seule. Il vous faut au moins deux GPU, et de préférence quatre, afin que le service parallèle par tenseurs sous vLLM dispose de la marge nécessaire pour le cache KV.

Quatre cartes RTX 4090 offrent 96 Go de VRAM au total. Cela suffit pour équiper un modèle Llama 3.3 70B AWQ INT4 avec gpu_memory_utilization=0.80 et conserve un espace cache KV suffisant pour les requêtes par lots. Elle offre également une capacité de calcul (4 puces SM de 128 cœurs fonctionnant simultanément) essentielle pour une vitesse de traitement optimale.

L'alternative envisagée était une configuration à 4 cartes RTX Pro 6000 Blackwell, offrant 4 × 96 Go = 384 Go de VRAM. Il s'agit d'une capacité nettement supérieure : bien plus que nécessaire pour un modèle de 70 octets, idéale pour exécuter simultanément plusieurs modèles volumineux ou héberger des modèles de plus de 200 octets avec une quantification raisonnable. Pour cette charge de travail (un modèle principal, un petit lot simultané, sur un poste de travail dédié), cette capacité supplémentaire serait inutilisée et la différence de coût est significative. La configuration à 4 cartes RTX 4090 s'avérait donc la solution optimale pour ce cas d'utilisation.

Une alternative 8× L40 est également disponible. La L40 offre 48 Go de VRAM par carte, la prise en charge ECC et est conçue pour une charge soutenue en centre de données. Pour ce client, la charge de travail ne nécessitait pas de contrats de fiabilité de niveau centre de données, l'absence de certaines particularités des pilotes grand public de la L40 était un avantage mineur et le budget ne le permettait pas. À considérer comme une option de mise à niveau.

Un point important à souligner d'emblée : les cartes RTX 4090 ne disposent pas de NVLink. Toutes les communications entre GPU s'effectuent via PCIe peer-to-peer. Ceci est crucial pour l'inférence parallèle tensorielle (abordée dans la section consacrée aux benchmarks) et il est essentiel d'en prendre connaissance avant de passer commande. Voir N03 pour une analyse complète des situations où NVLink est important et de celles où il ne l'est pas.

Caractéristiques techniques du matériel

Quelques remarques sur les choix :

CPU. L'EPYC 7542 est une puce 32 cœurs de génération Rome dotée de 128 Mo de cache L3 répartis sur 8 CCD. Pour une station de travail d'inférence, son nombre de cœurs bruts est surdimensionné : vous ne saturerez pas 64 threads en inférence pure. Son principal atout réside dans le nombre de lignes PCIe : l'EPYC Rome offre 128 lignes PCIe 4.0 depuis le processeur, ce qui permet d'installer quatre GPU x16 sans partage ni bifurcation de lignes. La RTX 4090 étant un périphérique PCIe 4.0 x16, vous avez besoin de quatre emplacements x16 complets, et l'EPYC les fournit. W02 pour plus de détails sur la topologie des voies.

RAM. Le système était livré avec 512 Go de mémoire DDR4 ECC LRDIMM, dépassant les 256 Go initialement spécifiés. Cette mémoire vive supplémentaire s'avère ici particulièrement utile : le chargement des modèles depuis le NVMe s'effectue par étapes via la RAM système avant leur transfert vers la VRAM, et pour les modèles plus volumineux ou lors de la commutation entre modèles, les 512 Go permettent de stocker simultanément plusieurs ensembles de poids de modèles en RAM et d'éviter les lectures NVMe répétées.

NVMe. Le stockage du modèle (2 To) se fait sur un disque NVMe PCIe 4.0 haute vitesse. La vitesse de lecture séquentielle est cruciale lors du chargement : un fichier de modèle de 38 Go, avec une vitesse de lecture séquentielle de 4 589 Mo/s, se charge en 8 à 10 secondes environ. Les temps de chargement mesurés le confirment : llama.cpp a chargé le fichier GGUF Q4_K_M de 70 octets en 10.8 secondes ; vLLM (qui génère également les graphes CUDA lors du chargement) a mis 95 secondes.

Double alimentation. Le châssis utilise deux alimentations ATX. Il s'agit d'une alimentation séparée : chaque alimentation alimente une partie du système, généralement deux GPU et les composants de carte associés. Si une alimentation tombe en panne, les GPU qui y sont connectés ne sont plus alimentés. Ce n'est pas une redondance N+1 ; c'est une configuration de capacité d'alimentation, et non un système de basculement. Pour les systèmes de production où la disponibilité est contractuelle, cette distinction est importante. Voir W04 pour une discussion complète sur le dimensionnement des alimentations.

Flux d'air du châssis. Le châssis est conçu pour un montage en rack et bénéficie d'un flux d'air industriel dirigé de l'avant vers l'arrière. Les cartes graphiques ne sont pas à l'air libre ; elles sont placées dans un canal de flux d'air dirigé, les ventilateurs du boîtier aspirant l'air à travers les dissipateurs thermiques et l'évacuant par l'arrière. Ce système est ainsi adapté à un fonctionnement continu 24 h/24 et 7 j/7 en environnement rack. Voir W05 pour les détails de conception thermique.

Pile logicielle

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

Résultats de la mise en service

Référence de calcul GPU

Le premier test consiste toujours en un calcul brut : multiplication matricielle en FP16 (chemin Tensor Core) et FP32. Cela confirme le bon fonctionnement des cartes et fournit une base de calcul à comparer aux spécifications nominales.

À titre de référence : la puissance de calcul théorique maximale du Tensor Core FP16 de la RTX 4090 est d'environ 330 TFLOPS, et d'environ 82.6 TFLOPS en FP32. Les résultats du test, à environ 52 % de la puissance maximale FP16, sont conformes aux attentes : la mesure correspond à une multiplication matricielle à débit soutenu qui n'atteint pas la puissance maximale théorique d'un noyau GEMM optimisé manuellement. Ces résultats confirment le bon fonctionnement et la cohérence des quatre matrices de Tensor Core.

Le GPU 1 affiche des performances FP16 inférieures d'environ 6 % aux autres. Cette variation est normale pour une même puce. Il ne s'agit pas d'un défaut matériel.

Bande passante mémoire GPU

La bande passante VRAM de 920 Go/s est conforme aux spécifications de la RTX 4090 (1 008 Go/s en pointe ; l’écart correspond à la surcharge liée aux benchmarks). C’est cette bande passante qui influe directement sur le débit de décodage : chaque jeton généré nécessite le chargement de l’ensemble des tenseurs de cache KV et de poids depuis la VRAM. La bande passante limite donc directement la vitesse de génération.

Le débit GPU-à-GPU (19 à 22 Go/s via PCIe peer-to-peer) constitue la contrainte architecturale pertinente pour le traitement parallèle des tenseurs. Avec NVLink, ce débit atteint 900 Go/s. Avec PCIe uniquement, on n'obtient qu'environ 2 % de cette valeur. Ce n'est pas catastrophique pour l'inférence — la majeure partie des communications parallèles des tenseurs sur un modèle AWQ INT4 de 70 octets répartis sur 4 GPU reste dans les limites de PCIe — mais cela réduit la vitesse de décodage d'une requête unique par rapport à un système connecté via NVLink. Voir la section des benchmarks ci-dessous. N03 pour une discussion plus large.

Une anomalie : la bande passante entre le périphérique et l’hôte a été mesurée à 1.4 Go/s, bien en deçà des ~26 Go/s attendus pour PCIe Gen4 x16. Il s’agit d’un comportement CUDA connu avec la mémoire non verrouillée. Si votre application transfère fréquemment des données du GPU vers l’hôte (par exemple, en échantillonnant les logits de sortie dans un pipeline personnalisé), utilisez torch.pin_memory() ou préallouer des tampons épinglés. Les pipelines de service vLLM et llama.cpp standard ne déclenchent pas ce chemin dans la boucle active.

Toutes les liaisons PCIe sont confirmées en Gen4 x16 (16 GT/s) sous charge. Au repos, le pilote utilise le mode d'économie d'énergie ASPM et les liaisons passent en Gen1 (2.5 GT/s) ; ce comportement est normal et n'indique aucun défaut de câblage ou de carte d'extension.

Stockage NVMe

Ce sont d'excellentes performances NVMe pour un SSD PCIe 4.0 grand public/prosumer. Pour le déploiement de modèles, le chiffre pertinent est la lecture séquentielle : 4 589 Mo/s signifie qu'un modèle de 38 Go est chargé en RAM en environ 8 à 9 secondes avant tout transfert en VRAM. Les 568 000 IOPS aléatoires sont plus pertinentes si vous exécutez un pipeline de récupération (RAG, stockage vectoriel) où la charge de travail consiste en de nombreuses petites lectures aléatoires ; ce SSD gère cela sans devenir un goulot d'étranglement.

Inférence vLLM — Lama 3.3 70B AWQ INT4

Il s'agit du principal critère de référence. Modèle : casperhansen/llama-3.3-70b-instruct-awq. Serveur : 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 en requête unique nécessite un contexte. vLLM 0.19.0 a exécuté le modèle AWQ avec le awq noyau, pas noyau awq_marlinL’ awq_marlin Le noyau est la voie la plus rapide pour AWQ sur les GPU Ada Lovelace (RTX 4090) et Blackwell — les notes de test indiquent qu'il n'a pas été sélectionné lors de cette phase de mise en service, et l'amélioration attendue est de 2 à 3 fois sur la vitesse de décodage d'une seule requête. awq_marlin, le même modèle sur le même matériel devrait atteindre environ 16 à 24 tok/s en flux unique.

Le débit cumulé de 179.3 tok/s sur 32 requêtes simultanées est plus représentatif de la production. Il correspond à la latence globale qu'observera une petite équipe accédant simultanément au point de terminaison. Le traitement par lots continu dans vLLM permet d'amortir les requêtes simultanées sur le cache KV et le calcul d'attention, ce qui explique pourquoi un nombre d'utilisateurs multiplié par 32 n'entraîne pas une latence 32 fois supérieure.

La latence de 2 043 ms sur une requête de 16 jetons correspond au TTFT (temps d'obtention du premier jeton) minimal sous vLLM sur cette configuration. Pour les cas d'utilisation interactifs (chat, assistance au code), cette latence est relativement faible. Le principal facteur est la surcharge liée à la diffusion/rassemblement parallèle des tenseurs sur quatre GPU via PCIe : chaque étape de préremplissage nécessite une opération AllReduce sur les quatre cartes via l'interface PCIe. Avec NVLink, ce TTFT serait d'environ 50 à 100 ms ; avec le PCIe P2P à 20 Go/s, il est plus élevé. Il s'agit du coût direct de l'architecture sans NVLink pour les requêtes uniques sensibles à la latence (voir [référence manquante]). N03).

lama.cpp — Lama 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échargées sur GPU.

llama.cpp atteint environ 20 tok/s en décodage mono-flux, une performance supérieure à celle de vLLM AWQ actuelle, grâce à son noyau basé sur cuBLAS qui fonctionne parfaitement avec la quantification Q4_K_M. Contrairement à vLLM, llama.cpp ne prend pas en charge le traitement par lots de plusieurs requêtes simultanées ; la limite de 20 tok/s est donc une performance maximale par session, et non une capacité globale. Pour les flux de travail interactifs mono-utilisateur, llama.cpp offre une vitesse de lecture confortable pour la sortie en anglais.

La vitesse de traitement des invites de 1 568 jetons/s est élevée. Elle mesure la rapidité avec laquelle le modèle peut ingérer l'invite (phase de préremplissage). Un préremplissage rapide est crucial lors de l'exécution d'un modèle sur des invites système ou des contextes de documents longs. À 1 568 jetons/s, un contexte de document de 4 000 jetons est traité en moins de 3 secondes avant le début de la génération.

Pour les aspects économiques et la comparaison avec les alternatives cloud, voir T01 (tok/s par euro) et T02 (coût par million de jetons sur site par rapport au cloud).

À quoi servent les deux moteurs ?

Essai de résistance — Charge soutenue

Trois tests de résistance de 60 secondes ont été effectués pour vérifier la stabilité thermique et électrique sous charge maximale : test de résistance du GPU uniquement, test de résistance du CPU uniquement et test de résistance combiné GPU+CPU.

Gravure GPU (multiplication de matrice FP16 à 100 %, 60 s)

Aucun problème de calcul sur les quatre GPU. La température est passée d'environ 28 °C à un plateau stable à la 40e seconde. Le GPU 2 a atteint la température la plus élevée (72 °C), ce qui en fait la carte la plus chaude dans le flux d'air du boîtier à cet endroit. Le seuil de limitation thermique de la RTX 4090 est de 83 °C ; la température maximale mesurée (72 °C) laisse une marge de 11 °C. Le système n'a subi aucune limitation de fréquence.

La limite de puissance était fixée à des valeurs différentes pour les quatre cartes (480 W, 450 W, 500 W, 480 W). Il s'agit d'une incohérence mineure qui devrait être corrigée. nvidia-smi -pl 480 -i 0,1,2,3 (ou toute autre limite appropriée) pour fixer des plafonds cohérents avant la mise en production.

Test combiné de sollicitation du GPU et du CPU (les 4 GPU et les 64 cœurs du CPU simultanément, 60 s)

L'ajout de 64 cœurs CPU à pleine charge n'a entraîné qu'une baisse de 0.6 % de la puissance de calcul GPU totale. Le processeur EPYC 7542 consomme environ 200 W (TDP) à pleine charge ; le système combiné fonctionnait à une consommation totale d'environ 2.1 à 2.2 kW. Toutes les températures sont restées dans les limites acceptables : le GPU 2 a atteint une température maximale de 73 °C sous charge combinée, soit 10 °C en dessous du seuil de limitation thermique.

La charge moyenne a dépassé 55 pendant la phase de test du processeur (ce qui est normal pour 64 cœurs). Le système est resté parfaitement stable tout au long de l'expérience : aucun incident thermique, aucune erreur de calcul, aucun plantage du noyau.

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

Ce qui a bien fonctionné

La plateforme EPYC. Le problème de la répartition des lignes PCIe est enfin résolu. Les quatre cartes RTX 4090 fonctionnent à pleine capacité Gen4 x16 en charge (confirmé dans le 04d Vérification de l'état PCIe : aucune bifurcation, aucun emplacement dégradé. Certaines configurations AMD Ryzen à quatre GPU utilisent deux emplacements ou plus en x8 ; ce n'est pas le cas sur EPYC Rome.

RAM. 512 Go, c'est confortable. Lors du chargement du modèle llama.cpp, le fichier GGUF de 38 Go est alloué en mémoire ; disposer de 512 Go permet d'exécuter plusieurs processus en parallèle du serveur LLM sans conflit de mémoire.

Vitesse séquentielle NVMe. Une vitesse de lecture séquentielle de 4 589 Mo/s permet de réduire les temps de chargement. Dans un flux de travail d'itération de modèles (chargement, tests, changement de modèles), cela représente un gain de temps considérable sur une journée.

Thermiques. Température maximale soutenue de 73 °C (GPU 2, test de charge combiné) avec une marge de 10 °C. Lors d'une charge de travail d'inférence classique, les GPU ne fonctionnent pas en continu à 100 % d'utilisation ; le décodage est limité par la bande passante de la VRAM, et non par la puissance de calcul. Par conséquent, les températures de fonctionnement réelles seront inférieures au pic atteint lors du test de charge.

llama.cpp 1 568 tok/s évaluation de l'invite. Ce résultat nous a agréablement surpris. Le préremplissage cuBLAS sur quatre 4090 est rapide. Les applications nécessitant un contexte long en tirent pleinement parti.

Ce qui nous a surpris

Le noyau vLLM AWQ manque. Le test de référence a été effectué avec le awq noyau au lieu de awq_marlinLa suite de mise en service a déclenché cela automatiquement en fonction de la configuration du modèle à ce moment-là. awq_marlinLe débit par requête devrait passer de 8 tok/s à 16–24 tok/s. Il s'agit d'une correction de configuration logicielle et non d'une limitation matérielle ; vérifiez votre chaîne de quantification vLLM lors de la mise en service en production.

Bande passante D2H. Le débit de 1.4 Go/s entre le périphérique et l'hôte nous a surpris lors de l'analyse initiale. Il s'agit d'un comportement lié à l'absence de mémoire verrouillée en CUDA, et non d'un défaut PCIe. Pour les piles de service standard (vLLM, llama.cpp), cela n'a pas d'importance. En revanche, pour le code d'inférence personnalisé qui transfère les tenseurs vers le CPU pour le post-traitement, il est recommandé d'utiliser des allocations de mémoire verrouillées.

Erreurs corrigées de l'AER du GPU 3 PCIe. Lors du test vLLM, le GPU 3 (bus c1:00.0) a enregistré des erreurs PCIe corrigées (RxErr + BadTLP). Ces erreurs ont été corrigées automatiquement par le matériel et n'ont pas affecté les calculs. Cause probable : problème d'insertion de la carte d'extension PCIe ou renégociation de la liaison à la vitesse Gen4. Il est recommandé de surveiller le GPU 3 en cas de charge de production soutenue ; si le nombre d'erreurs augmente, vérifiez l'insertion de la carte d'extension. Aucune erreur n'a été constatée lors des tests de charge.

Brève liaison NIC. L'interface réseau a brièvement été interrompue puis rétablie pendant le test de performance du GPU (13h38 UTC). Probablement une coupure de courant due à la mise sous tension simultanée du GPU. En production avec nvidia-persistenced En fonctionnement (ce qui maintient les contextes GPU initialisés), les transitoires de puissance au démarrage du chargement sont plus faibles. Activer nvidia-persistenced en tant que service systemd avant la mise en production.

Ce que nous ferions différemment pour la v2

Permettre awq_marlin dès le début. Vérifiez le chemin du noyau de quantification vLLM pendant la mise en service, et non après. Ajoutez une vérification d'identité du noyau au script de mise en service.

Normalisez les limites de puissance du GPU avant d'effectuer les tests de performance. Les quatre cartes ont été livrées avec des limites configurées différentes (480 W, 450 W, 500 W, 480 W). Définir une limite cohérente (nvidia-smi -pl) avant le premier test de référence, on obtient des chiffres plus propres et plus comparables, et on évite la consommation d'énergie irrégulière pendant la combustion combinée.

Ajouter une pile de surveillance lors de la livraison. Prometheus, avec l'exportateur DCGM et Grafana, se configure en quelques heures et permet de visualiser en temps réel la température du GPU, l'utilisation de la VRAM et les taux d'erreur PCIe. Il est recommandé d'intégrer cette configuration à la mise en service standard plutôt que de la laisser comme tâche après livraison. Voir L05 pour le guide de configuration de la pile.

Pin nvidia-persistenced dans le fichier d'unité systemd lors de l'installation du système d'exploitation. C'est une simple ligne de code, mais elle est systématiquement oubliée. Sans elle, la première charge du GPU après une période d'inactivité prend quelques secondes de plus et provoque la surtension à l'origine du dysfonctionnement de la carte réseau.

Extension LVM. Le disque système (512 Go SATA) ne dispose que de 100 Go alloués à la partition LVM. Les 374 Go restants ne sont pas alloués. Il n'y a aucune raison de les laisser ainsi. lvextend et resize2fs Cela prend 30 secondes et vous permet de récupérer cet espace pour la surcharge du système d'exploitation, les journaux et les couches Docker.

Envisagez un deuxième SSD NVMe pour le stockage des modèles. Le disque NVMe unique de 2 To contient actuellement tous les modèles et se remplira à mesure que la bibliothèque de modèles s'agrandira. Un second disque NVMe de 4 To, en RAID 0 ou simplement comme disque séparé, peut être utilisé. /mnt/nvme2 Le montage permettrait d'ajouter de la flexibilité et de maintenir des performances de lecture séquentielle élevées sur une bibliothèque totale plus importante.

Comparaison : Alternatives à cette configuration

La charge de travail du client aurait pu être gérée avec un matériel différent. Voici une comparaison objective :

La configuration minimale requise pour exécuter Llama 3.3 70B AWQ INT4 sous vLLM avec un débit de traitement par lots satisfaisant est une configuration à 4 cartes RTX 4090 et 96 Go de RAM. Il ne s'agit pas d'une limite ; une configuration à 8 GPU augmente proportionnellement les capacités. Pour un client de recherche souhaitant une station de travail dédiée (et non un cluster de serveurs), une configuration à 4 cartes est souvent un bon point de départ.

Ni la configuration 4× ni la configuration 8× ne disposent de NVLink entre les GPU, ce qui signifie que l'inférence parallèle des tenseurs s'effectue via PCIe. En pratique, cela se traduit par une latence TTFT pour les requêtes individuelles, et non par un débit global par lots. Pour une charge de travail d'équipe (quelques dizaines de requêtes par heure, et non des milliers), ce n'est pas un facteur limitant. Pour des exigences de TTFT inférieures à 100 ms, voir [référence manquante]. N03 et les raisons pour lesquelles cette gamme cible les systèmes multi-GPU connectés PCIe plutôt que les systèmes à architecture NVSwitch.

Planification globale de l'énergie et de l'électricité

Sous charge GPU soutenue, la consommation totale du système était d'environ 1 900 à 2 200 W mesurée aux rails du GPU (1 914 W pour le GPU seul ; environ 2 100 W avec le CPU, les disques et la carte mère). Tenez compte des pertes d'efficacité de l'alimentation (estimées à 90 %) et prévoyez un circuit de 16 A/230 V minimum, 20 A étant préférables pour plus de marge.

La configuration à double alimentation répartit la consommation sur deux prises. Ces deux prises doivent être alimentées par des circuits capables de supporter la charge indépendamment : si l’alimentation A alimente deux cartes graphiques de 500 W chacune, plus 200 W pour la carte mère et le processeur, cela représente 1 200 W sur son circuit. Dimensionnez l’alimentation en conséquence.

Budget refroidissement de la salle : considérez ce système comme ayant une puissance continue de 2.5 kW (estimation prudente, incluant les pertes d’efficacité et une marge). Pour une salle serveur ou une baie contenant plusieurs systèmes, la puissance totale augmente rapidement.

Voir P01 pour les considérations monophasées et triphasées et P04 pour le dimensionnement du disjoncteur.

Bande de prix

Une configuration répondant à ces spécifications — plateforme EPYC 7542, 512 Go de RAM ECC, 4 cartes graphiques RTX 4090, disque SSD NVMe de 2 To, châssis rack avec double alimentation — se situe dans la catégorie 18 000 € à 24 000 € HT Le prix des composants varie selon le châssis choisi, la disponibilité de la RAM et du GPU. Le délai de livraison est de 10 à 28 jours, selon la disponibilité des composants (confirmée lors de la commande).

Cette gamme de prix n'inclut pas l'installation, le boîtier de distribution d'alimentation (PDU) pour rack, la mise en réseau (commutateur 10 GbE, câblage) ni les licences logicielles. Le système est livré avec Ubuntu 24.04 LTS préinstallé et l'environnement virtuel Python préconfiguré ; veuillez vous munir de vos propres poids de modélisation.

Ce modèle est idéal pour :

• Recherche et inférence LLM en petite équipe. Nous utilisons un modèle 70B pour une équipe de 5 à 15 utilisateurs. Le débit agrégé de 179 tok/s sous vLLM gère sans problème les sessions simultanées.
• Évaluation et itération du modèle. Les temps de chargement rapides des disques NVMe permettent de basculer rapidement entre les modèles compatibles. Grâce à la bande passante PCIe allouée à la plateforme EPYC, les quatre GPU fonctionnent toujours à pleine capacité.
• Déploiements souverains en matière de données. Toutes les inférences sont effectuées localement. Aucun jeton ne quitte le bâtiment. C'est la principale raison non économique de privilégier une exécution sur site dans le cadre de la recherche.
• Point d'entrée à 70 milliards de yuans, adapté aux budgets serrés. La RTX 4090 est la carte graphique grand public offrant la plus grande capacité de VRAM. Avec 24 Go par carte et quatre cartes offrant 96 Go au total, elle atteint la classe 70B sans pour autant atteindre le prix des cartes graphiques professionnelles.

Ce que cette configuration ne permet pas de faire

• TTFT en requête unique inférieur à 100 ms. L'architecture PCIe P2P parallèle à tenseurs impose une limite minimale au TTFT pour les grands modèles. Si vous avez besoin d'une latence interactive rapide pour des modèles de plus de 70 milliards d'octets, cette architecture n'est pas adaptée. Il vous faut des GPU connectés via NVLink, ce qui implique une toute autre catégorie de matériel (voir N03).
• Exécution simultanée de plusieurs modèles volumineux. Avec une mémoire vidéo totale de 96 Go gpu_memory_utilization=0.80Vous disposez d'environ 77 Go utilisables. Un second modèle INT4 de 70 octets ne pourrait pas être installé. Si vous devez héberger deux modèles simultanément, passez à une plateforme avec plus de VRAM par GPU ou plus de GPU.
• Service de production à grande échelle. Pour des centaines d'utilisateurs simultanés ou une disponibilité garantie par SLA, cette architecture (sans cartes réseau supplémentaires sur un châssis 4 GPU, nœud unique, GPU grand public avec ECC désactivé) n'est pas adaptée. Le serveur K-AI 8 GPU avec L40 ou RTX Pro 6000 Blackwell, une surveillance adéquate et deux cartes réseau est plus approprié.
• Entraînement de grands modèles. Avec 96 Go de VRAM au total, vous pouvez affiner (LoRa, QLoRa) sur 70 milliards de modèles, mais vous ne pouvez pas les entraîner avec tous leurs paramètres. Pour l'entraînement, la VRAM est plus limitée que pour l'inférence. Si l'entraînement fait partie de votre plan de travail, tenez-en compte.

---

Ceci fait partie du wiki de Kentino, série C (Études de cas). Données de construction mesurées le 10 avril 2026. Article publié le 15 mai 2026. Corrections et mesures complémentaires bienvenues. info@kentino.com.