Tarifs : Acquisition Serveur GPU ou Location Cloud Privé

Que ce soit sur l’offre Cloud privé ou acquisition de matériel, les GPU sont les composants essentiels de votre solution de calcul. Deux facteurs sont à prendre en compte le nombre de nœuds de calcul et la quantité de mémoire graphique (vRAM). :

• Multiplication des nœuds : Si votre application nécessite l’exécution de plusieurs applications ou modèles, il vaut mieux multiplier les GPU. Les NVIDIA RTX Pro 6000 Blackwell peuvent se diviser en 2 ou 4 instances (nœuds) pour maximiser l’investissement NVIDIA RTX PRO 6000 BLACKWELL
• VRAM (IA) : Pour les applications d’IA, le dimensionnement principal est la quantité de mémoire virtuelle totale (vRAM) qui doit être suffisante pour accepter les modèles et leur contexte.

Exemple, un modèle Qwen3 Next 80B A3B Instruct avec un contexte de 262 144 tokens (mots) s’exécute sans problème sur deux Nvidia RTX Pro 6000 Blackwell.

Les GPU de la série NVIDIA Blackwell sont divisibles en sous-instances autonomes et isolées, permettant de jouer assez finement sur le nombre de nœuds de calculs disponibles en fonction des besoins de mémoire graphique (vRAM). Dans le cas particulier de la RTX Pro 6000 Blackwell, nous pouvons obtenir les configurations suivantes :

• 1 carte physique avec 96 Go de vRAM
• 2 instances sur une carte physiques avec 48 Go de vRAM
• 4 instances sur une carte physiques avec 24 Go de vRAM

NVIDIA RTX PRO 6000 BLACKWELL

Sur nos offres Cloud Privé, même si notre configurateur ne le propose pas encore pour des questions d’ergonomie, nous pourrons vous mettre à dispositions 2 ou 4 instances (nœuds) par GPU loué sur demande.

Le nombre de cœurs CPU dépends complètement de l’utilisation que vous aurez de votre serveur, qu’il soit physique ou virtuel.

Dans le cas d’un serveur physique, si vous souhaitez installer un hyperviseur et utiliser le matériel pour exécuter plusieurs machines virtuelles avec leurs propres applications, un nombre de cœurs important vous permettra de multiplier le nombre d’applications simultanées sans prendre le risque que les machines n’ait besoin de faire des accès concurrents sur les mêmes cœurs, ralentissant de manière significative les applications.

A titre d’exemple, pour des accès jusqu’à 20 connexions concurrentes, nous utilisons entre 2 et 8 cœurs par application (applications web avec des back-end Python la plupart du temps).

Sur une application en Intelligence Artificielle (IA) pure, ou sur du calcul maximisant l’utilisation des GPU, le nombre de cœurs utilisés est souvent très faible et il faut parfois maximiser la fréquence max au détriment du nombre de cœurs. C’est pour cette raison que nous proposons des versions « F » des CPU AMD Epyc 9004 qui ont une fréquence boost 0,3 à 0,5 Ghz plus élevée par cœurs.

En utilisation inférence IA pure, et sans hyperviseur, 16 cœurs sont amplement suffisants pour que le CPU n’ait pas d’impact sur la vitesse de réponse du modèle, mais les AMD Epyce 9334 offrent un bon compromis prix / nombre de cœurs / fréquence avec 32 cœurs cadencés à 3,9 GHz et un prix bien inférieur aux séries « F » tels que le 9174F avec 16 cœurs, mais une fréquence boost supérieure de 4,4 GHz.

Série AMD Epyc 9004

Sur les serveurs privés virtuels (VPS), les cœurs CPU sont sur-approvisionnés. Par exemple, un serveur avec 128 cœurs se verra affecter 32 machines virtuelles de 8 cœurs, soit 256 cœurs. Cette stratégie ne pose pas de difficultés de performances sur des applications de serveurs web tant que les 32 machines n’utilisent pas les 8 cœurs CPU à 100%.

Cette stratégie, optimale en termes d’optimisation de ressources, a pour autant des contraintes très importantes.

• D’une part, il est important pour le centre de données de surveiller et restreindre les utilisateurs à ce qu’ils appellent une « utilisation loyale » (fair use). Un utilisateur se verra souvent fortement bridé s’il utilise la machine virtuelle à 100% du CPU sur plus de 2h continue.
• D’autre part, et même si cela n’est pas perceptible dans la plupart des utilisations, chaque cœur étant sur-provisionné et partageant sa capacité de calcul sur plusieurs machines virtuelles, ce qui provoque des latences qui peuvent être très pénalisantes dans certaines applications.

Dans notre offre vCPU dédiés, nous vous garantissons que nous hébergeons la machine virtuelle sur un serveur dont les cœurs CPU ne sont pas sur-provisionnés !

La différence de prix entre des vCPU partagés ou dédiés s’explique très rapidement :

• Plus le sur-provisionnement est élevé, moins un cœur partagé ne « coûte » cher. Les offres VPS concurrentes jouent souvent sur ce facteur pour proposer des offres avec un nombre de cœurs élevés à des prix très concurrentiels. Ils sont ensuite obligés d’avoir des politiques de limitation très agressives qui impactent directement la relation client.
• Un cœur dédié ne permet pas de maximiser le taux d’utilisation du serveur, ce qui a un impact direct sur le prix.
• Un cœur dédié sera plus certainement dédié à des calculs continus, plus gourmands en électricité et en climatisation. Le prix reflète également ce surcoût en exploitation.
• Finalement, nos serveurs étant des serveurs de calcul, un CPU de 128 cœurs est associé à 6 GPU. Le fait de limiter le sur-provisionnement contraint fortement l’optimisation des machines virtuelles fonctionnant sur un serveur.

La quantité de RAM est très dépendante de votre application. Par exemple, dans le cas d’applications web la RAM va être très fortement dépendante du nombre d’utilisateurs connectés de manière simultanée. Sur la plupart des applications que nous avons en interne, et qui tournent sur des machines virtuelles Ubuntu Server, 6 Go de Ram est parfaitement adapté en dessous de 20 utilisateurs simultanés. Certaines applications demandent 16 Go pour le même nombre d’utilisateurs.

Attention, quand vous regardez votre utilisation de RAM et en particulier sur Ubuntu, une partie de la RAM qui est considérée comme utilisée n’est en réalité que du cache. Sur des quantités de RAM inférieure à 6 Go cela donne souvent une impression que la RAM est insuffisante.

Dans le cas d’application purement IA et maximisant la mémoire du GPU, l’utilisation de RAM est minimale, et se limite au besoin des applications nécessaires pour exécuter le modèle telles que vLLM où pour que les utilisateurs puissent réaliser les requêtes.

Une fois la quantité totale de RAM nécessaire établie, il ne faut pas faire l’erreur de simplement la diviser par la capacité des modules de RAM pour dimensionner le nombre de modules à utiliser.

En effet si les modules de RAM RDDR5 des processeurs AMD EPYC 9004 fonctionnent à des fréquences relativement faibles (4800 MHz) comparés aux stations de travail AMD THREADRIPPER (jusqu’à 6400 MHz), il faut noter que les processeurs maximisent l’utilisation de la totalité des barrettes (Jusqu’à 12 pour les EPYC contre 8 pour les THREADRIPPER) permettant des accès RAM finalement plus rapide si tous les emplacements mémoires sont pourvus.

Un équilibre entre évolutivité, performance et investissement est donc à trouver. Alors que l’idéal en terme de performances serait de peupler tous les emplacements avec la mémoire la plus petite suffisantes, et il est plus conseillé de mettre des modules avec une capacité plus grande, quitte à ne pas peupler tous les emplacements pour limiter le budget d’acquisition.

Dans tous les cas, peupler au moins 8 emplacement est recommandé et permet d’avoir 67 % du débit maximal d’accès RAM du processeur.

Ratio entre les performances et le nombre de modules des EPYC 9004

Les SSD que nous utilisons sont montées sur des ports PCIe Gen 5 et peuvent être des mémoires NVMe Gen 4 (pour le 1To) ou NVMe Gen 5 (pour le 2 To et 4 To). Dans le premier cas les débits maximaux sont de l’ordre de 5000 Mo/s en lecture et dans le second 14 800 Mo/s, contre 270 Mo/s pour les HDD que nous utilisons

Si la suprématie des SSD en terme de vitesse d’écriture/lecture est indéniable, celle-ci vient au détriments d’un prix bien plus élevé au Mo et surtout d’une durée de vie en écriture bien plus faible. Bien que les durée de vie soient difficiles à comparer, celle des SSD étant bien plus dépendante du nombre de cycle d’écriture que celle des HDD, nous avons une durée de vie moyenne de 1,5 Mhr pour les SSD contre 2,5 Mhrs pour les HDD.

Il faut également ajouter qu’une configuration RAID est essentielle dans un serveur, à minima pour améliorer la robustesse des disques en créant un volume d’au moins deux disques avec un taux de panne acceptable d’un disque. Cela améliore en plus les performances d’accès en lecture.

En conclusion, l’utilisation des HDD doit être réservée au stockage de volumes de données importants pour des données donc l’accès lent n’handicapera pas l’ergonomie (images, vidéos, …) et favoriser l’utilisation de SSD avec des configurations RAID.

Qu’est ce qu’ un RAID

La capacité de stockage est très dépendante de votre application, et nous avons toujours tendance à la sous-estimer.

Dans le cas de l’acquisition d’une solution nous recommandons de dimensionner l’espace nécessaire de manière grossière, et de le disposer sur maximum 3 disques SSD en RAIDZ1 pour démarrer. Il sera facile de rajouter un disque sur un tel volume.

En utilisation inference IA pure, l’espace de stockage n’est pas le frein principal et une configuration 2 x SSD de 2To sera idéale pour débuter, et laissera une marge de progression importante du stockage.

De quelle quantité de stockage disposerai-je en fonction du Raid choisis ?

Les ports SFP, au même titre que les ports RJ45, définissent un format d’interface réseau. Initialement créés pour accueillir les modules du même nom pour la fibre optique, ils ont évolués pour couvrir de nombreuses application. Sur les serveurs les câbles de Connection Cuivre Directe (DAC Cable) permettent de lier le serveur avec le switch. Sinon des modules SFP vers RJ45 existent.

De manière similaire le port SFP a évolué avec la progression des besoins et des technologies : depuis le SFP à 1Gbps au SFP 112 à 100 Gbps la principale limite vient des coûts associés au matériel : l’interface réseau du serveur, le câble et le switch.

Par défaut notre serveur est pourvu de 2 ports SFP28 à 25 Gbps. Associé dans le même lien cela permet de proposer une connection redondante à 50 Gbps à des coûts tout à fait abordables.

Dérivée du format SFP, le QSFP offre quatre fois le débit d’un port SFP dans un format un peux plus important.

Qu’est ce que le SFP

Si le liens 50Gpbs est insuffisant, les deux ports QSFP+ que nous proposons en option alternatives vous permettrons d’aller jusqu’à 100 Gbps au prix d’un coût matériel réseau bien supérieur. Cette carte réseau prenant un emplacement PCIe, vous ne pourrez mettre que 5 GPU au maximum.

Pour des besoins encore plus poussés, tels que la création de clusters GPU dépassant 6 unités, les cartes réseaux ConnectX de NVIDIA permettent de relier les serveur entre-eux. Les différents serveurs peuvent accéder directement aux GPU des autres serveurs sur un lien Ethernet optimisé en terme de latence et de débit. Cette technologie est appelée Infiniband par NVIDIA. Nous proposons ainsi une carte NVIDIA ConnectX 7 avec deux ports QSFP112 permettant de faire des clusters de serveurs GPU à 400 Gbps.

Un serveur de calcul peut s’utiliser comme une station de travail en mode « bureau » où comme un PC distant. Mais pour maximiser l’utilisation de cet investissement et favoriser son utilisation pour plusieurs besoins indépendants, l’hyperviseur est essentiel.

Un hyperviseur vous permettra de très facilement déployer des Machines Virtuelles (VM) avec le système d’exploitation que vous voudrez en fonction de l’application. La sauvegarde des VM et leurs redéploiement est très facile, et vous garantira des temps d’indisponibilité les plus réduits possibles, notamment en cas de problème de mises à jour.

Nous privilégions Proxmox qui est un hyperviseur open source très répandu et basé sur des outils standards Linux / Débian. Bien qu’une utilisation en licence gratuite soit possible, sur des environnement de production il est recommandé d’utiliser des offres sous licence Entreprise qui démarrent à 115 € par CPU et par année.

Une solution de virtualisation utilisera une très faible partie des ressources CPU et consommera moins de 6 Go de RAM. Elle permettra de gérer simplement sur une interface unique des cluster de serveurs et associée à une redondance matérielle, elle donnera la possibilité de mettre en place des architectures Haute Disponibilité sur les applications.

La virtualisation aura des impacts significatifs en termes de performances sur des applications de calcul CPU pur, ou sur les applications où les accès disques et RAM sont conséquents. L’ordre d’idées est de 5% à 15% de perte de performances brute.

A contrario les GPU peuvent être directement « attachés » à la machine virtuelle, évitant des latences liés à la couche de traitement de l’hyperviseur et la perte de performance sur du calcul GPU est donc insignifiante.

Nous sommes en train de faire un article comparatif sur ce sujet. N’hésitez pas à nous contacter pour en discuter.

En conclusion :

• Perte de performance peu significative sur du calcul GPU,
• Apport de souplesse précieux,
• Réduction des temps d’installation ou de récupération d’OS très significative,
• Maximisation de la rentabilité de l’investissement,
• Coût non significatif de l’hyperviseur

Nous recommandons d’en utiliser un systématiquement, sauf en cas d’utilisation particulière où l’hyperviseur pourrait handicaper les performances ou en utilisation purement individuelles où toutes les ressources sont dédiés à une personne.

Décrouvrez prochainement notre article a venir : Proxmox

En terme d’hyperviseur, nous recommandons Proxomox qui est au moins aussi performant que ses pendants non open sources, tels que VMware ou Hyper-V, à une fraction de leurs prix. Cette solution est basée sur Debian et nécessite une certaine connaissance de cet environnement Linux pour être assurer un déploiement correct.

Décrouvrez prochainement notre article a venir : Proxmox

En terme de système d’exploitation que ce soit sans hyperviseur (Bare metal) ou sur les machines virtuelles (VM), le choix dépendra essentiellement du type d’application que vous installez dessus.

A titre d’exemple, nous favorisons les machines virtuelles Debian, en particulier pour tous nos serveurs web, mais sommes contraints sur Windows pour certain services tels que nos coffres de gestion de contenu CAO mécanique (PDM) qui fonctionnent sur des machines virtuelles Windows Server.

Bien que nos serveurs puissent être utilisés en une utilisation station de travail, ils ne sont pas adapté à ce type d’usage. Le premier frein que vous allez découvrir est le manque de sortie video autre qu’un sub-D 9 qui limitera fortement la résolution graphique.

Voici nos recommendation pour une utilisation idéale, mais n’oubliez pas que nous pouvons vous aider à tous moment à dimensionner votre projet !

N’hesitez pas a nous contacter cliquez ici !

Système d’exploitation

Il est donc fortement recommandé d’installer un HYPERVISEUR ou un système d’exploitation qui vous permettra un accès à distance, par exemple Windows 11 Professional.

Alimentation

Il est important de noter qu’au delà de 3500 W, soit 4 cartes graphiques, un circuit d’alimentation dédié est nécessaire avec une alimentation directe depuis le compteur électrique et un disjoncteur 25 ou 30 A.

En plus de ces considérations, pour protéger votre investissement et garantir la disponibilité de celui-ci il est essentiel d’utiliser un onduleur qui permettra à votre système de s’arrêter normalement en cas de coupure de courant prolongée. En fonction du nombre de cartes graphiques et de votre besoin en terme de qualité de service l’onduleur devra délivrer entre 2000 W et 5000 W en sortie sur batterie. Au delà de 3000 W, nous recommandons d’utiliser des configuration doubles onduleurs de 3000 W dans lesquelles le serveur s’arrête automatiquement dès que l’un des onduleurs passe sur un niveau de batterie faibles. Un onduleur 3000 W peut coûter entre 700 € et 3000 € en fonction de sa capacité et de sa marque.

Pour une garantie de service complète un groupe électrogène avec un Inverseur de sources automatiques (ATS) peut être indispensable.

Climatisation

Mieux l’électronique est refroidie (en dehors des considérations de condensation), plus sa durée de vie sera longue et les « bugs » rares.

Pour garantir une qualité de service et un fonctionnement normal de votre serveur, la pièce dans laquelle il se situe doit rester impérativement en dessous de 40°C, et idéalement en dessous de 25°C.

La climatisation du local est donc souvent indispensable, et nécessite un dimensionnement au cas pire. Par exemple sur une installation avec un seul serveur de 6 GPU qui pourrait être amené à fonctionner de manière continue à sa charge maximale, et une température extérieure de 35 °C, nécessitera un local pourvu d’une climatisation de 4500 W qui consommera 1 500 W d’électricité.

Réseau

Du coté réseau, un simple accès 1 Gbps peut convenir.

Si vous souhaitez utiliser pleinement les capacités réseaux de votre serveur un commutateur réseau (switch) disposant de 2 ports SFP28 est cependant nécessaire, mais superflu dans beaucoup de cas d’usages. Ce type de débit est par contre très intéressant sur des application à haute disponibilité où plusieurs serveurs synchronisent leurs données en permanence. Ce type d’équipement démarre à 600 € HT.

Si votre application nécessite une garantie de service, utiliser deux switch dans des configurations redondantes peut être nécessaire, mais n’est pas indispensable dans la majorité des cas d’utilisation.

Stockage

Bien que les serveurs que nous proposions puissent accueillir un espace de stockage conséquent, nous avons tendance à ségréger le calcul et le stockage pur. Une unité serveur dédié au stockage, ou un NAS, pourront faire l’affaire.

Redondance

Dans le cas où la disponibilité de votre application serait critique, une installation redondante et secourue pourrait être indispensable. Dans ce cas en plus de deux commutateurs réseaux redondants et des considération sur l’alimentation électrique, il vous faudra certainement une configurations avec deux serveurs identiques.

Vous souhaitez que nous vous accompagnions dans le dimensionnement de votre installation, nous sommes disponibles.

Nous pouvons proposer des configurations où les ports Display-Port des cartes graphiques sont exposés sur demande. La considération la plus important à avoir est que dans ce type de configuration nous proposons impérativement un flux d’air qui va de l’arrière vers l’avant du serveur pour des considération de filtration de l’air et nous filtrons l’air entrant par l’arrière du serveur. Tous les équipements de la baie doivent donc être adaptés de façons à ne pas re-circuler de l’air chaud dans les équipements.

Dans cette configuration vous pourrez utiliser jusqu’à 24 écrans 4K à 360 Hz ou 12 écrans 8K à 100 Hz.

Efiscience ne propose qu’un seul contrat au format « Pay as you go ». Après avoir définis les ressources CPU et le stockage à la souscription du contrat, vous aurez la possibilité de réserver sur un calendrier les ressources GPU dont vous avez besoins.

Vous ne payez rien tant que la machine est éteinte et les GPU ne sont pas réservés !

Le capacité des ressources GPU que vous envisagez, qui vous sera demandée à la souscription, est une information indicative pour dimensionner la charge des serveurs. Votre machine virtuelle (VM) est hébergée sur un serveur physique avec 6 GPU, que vous partagerez avec les autres machines virtuelles.

Efiscience s’engage à vous garantir plus de 30% de capacité moyenne disponible, cependant plus vous réserverez tôt plus la disponibilité sera élevée. Il vous faudra dans tous les cas réserver au plus tard 30 minutes avant l’heure de démarrage souhaité.

Une fois la réservation effectuée le GPU sera automatiquement affecté à votre machine virtuelle et apparaîtra dessus après un simple redémarrage (qui peut être automatisé au besoin). A la fin de la réservation le GPU sera désaffecté et la machine virtuelle sera redémarrée pour permettre la liberation des ressources. Pendant toute la durée de la réservation la machine est considérée comme allumée.

Les réservations peuvent être modulée pendant la durée de la réservation (par exemple si le calcul est achevé, vous pouvez ajuster la fin de la réservation au plus proche de votre besoin) tant que la durée finale n’est pas inférieure à 70% de la durée initiale.

Les réservations peuvent être annulées jusqu’à 12h avant le début de la réservation sans pénalité (dans la limite d’une seul fois par semaine et deux fois par mois au maximum).

En dehors des heures de réservation votre machine virtuelle est accessible au prix d’une machine « Sans GPU » avec les ressources définies à la souscription du contrat.

Certains cas vous permettent de bénéficier de réductions importantes sur les périodes de réservation :

• Si vous réservez vos ressources GPU plus de 3 jours consécutifs vous êtes considérés comme « Heavy User » et vous bénéficiez de réduction de plus de 10% sur le coût horaire. Le tarif est dégressif en rapport du nombre de jours de réservation, et ce jusqu’à 120 jours consécutifs.
• Si vous réservez vos ressources GPU la nuit uniquement (entre 20h et 7h) sur 5 jours d’affilés vous êtes considéré comme « Night Bird » et vous bénéficiez de réduction de plus de 15% par rapport au coût horaire. Le tarif est dégressif en rapport du nombre de nuits de réservation, et ce jusqu’à 30 nuits consécutives.

Sauf demandes particulière, après 15 jours calendaires sans démarrage, et deux relances mails, votre VM est automatiquement détruite.