Une application monocarte lisible
Commencez par un processus qui charge son modèle, traite un lot et exporte un résultat. Fixez la taille des entrées et le nombre de requêtes. Ce scénario simple permet d’identifier si le prochain effort doit porter sur la mémoire GPU, les données ou la logique Python.
Avec 80 Go, vous pouvez explorer des charges plus volumineuses qu’avec une carte de 24 ou 48 Go, tout en gardant un seul domaine mémoire à gérer. Prévoyez néanmoins une marge pour les allocations temporaires de votre moteur.
Observer les transferts autant que le noyau
Un programme qui recharge les mêmes données entre deux appels peut passer une part importante de son temps hors du calcul utile. Chronométrez séparément préparation CPU, transfert, exécution et récupération du résultat. Pour des mesures CUDA, tenez compte de l’exécution asynchrone afin de ne pas mesurer seulement la soumission du travail.
Validez le fonctionnement avec votre version de PyTorch et les bibliothèques compilées du projet. Gardez un essai sans optimisation comme point de comparaison avant de modifier le chemin d’exécution.
Comparer sans confondre les formats H100
Le H100 SXM et le H100 PCIe ne décrivent pas la même configuration matérielle. Retenez le SXM si votre étude justifie de mesurer son comportement pour des échanges distribués. Retenez plutôt H200 lorsque votre charge monocarte dépasse les 80 Go. L’A100 SXM reste une alternative à examiner pour un environnement Ampere déjà qualifié.
Louer pour produire une décision
Un forfait de 3 jours peut servir à établir le profil initial. Sur 7 jours, testez plusieurs tailles de lots et gardez un rapport comparatif ; sur 30 jours, organisez les exécutions et leur suivi avec des identifiants stables.
Choisissez la durée, le nombre de lots et la préparation dans le configurateur, puis créez votre compte ou connectez-vous. Le règlement suit l’actif et le réseau sélectionnés. Après votre transfert, « J’ai payé » ajoute un signalement à la commande, que vous retrouvez dans votre compte Kernodeck.