Quel GPU coûte le moins pour le même résultat ML ?

Définir ce qui comptera comme un résultat accepté

Écrivez la décision avant les essais : « Quelle configuration traite tous mes documents, respecte ma qualité minimale et termine avant mon échéance, pour le budget engagé le plus faible ? » Fixez le scénario : ici, un corpus traité hors ligne. Une application interactive demanderait aussi de définir l’arrivée des requêtes, leur concurrence et la latence admissible ; son classement ne se déduit pas de ce seul essai.

Appelez corpus validé un ensemble complet de sorties qui franchit tous vos contrôles. Un fichier créé n’est pas encore un résultat accepté. Vérifiez les identifiants, le format, la couverture et une métrique liée à votre usage. Inscrivez le seuil et la tolérance par rapport à une référence avant de regarder les temps. Deux configurations peuvent ainsi être équivalentes pour la décision sans produire des nombres identiques bit à bit.

Cette séparation entre jeu de données, objectif de qualité et scénario existe aussi dans les principes de MLPerf Inference. Le protocole ci-dessous est notre méthode de travail à adapter à votre projet ; il ne constitue ni une exécution ni une certification MLPerf.

Sources techniques : MLCommons — scénarios, métriques et objectifs de qualité

Préparer les entrées, la référence et le manifeste

Il vous faut un corpus que vous avez le droit d’utiliser, des réponses de référence ou une procédure d’évaluation, le code d’inférence et un environnement capable d’exécuter le modèle choisi. Séparez les données servant à régler la configuration du corpus final de comparaison. Si vous ajustez les seuils après avoir vu ce dernier, préparez une nouvelle évaluation indépendante pour soutenir la conclusion.

Donnez un identifiant stable à chaque entrée. Conservez une empreinte du corpus, l’ordre de passage, la révision du modèle et du tokenizer, les versions du code et des dépendances. Le manifeste décrit aussi GPU utilisés, précision, quantification, compilation, backend d’attention, politique de padding et longueur maximale. Une troncature différente changerait le travail à comparer.

Relevez le pilote et le backend effectivement présents. Pour une variante AMD, vérifiez la combinaison système, GPU, ROCm et framework dans la matrice officielle. Une documentation consultée ou le nom d’une carte ne prouve pas que cet environnement est installé. Si les piles logicielles diffèrent entre deux essais, la conclusion portera sur les configurations complètes testées.

Sources techniques : AMD — matrice de compatibilité ROCm

Exemple : classer les mêmes 1 000 textes

Voici une expérience à construire avec vos données, sans résultat de performance présumé. Vous voulez classer 1 000 textes dans les catégories de votre projet. Réservez 600 entrées courtes, 300 intermédiaires et 100 longues ; définissez les bornes avec le tokenizer retenu et gardez une répartition représentative des classes. Ce découpage est un exemple de protocole, pas un corpus fourni ni une recommandation universelle de proportions.

Comparez des batches de 1, 4 et 8 avec le même modèle, la même précision, le même ordre et la même règle de padding. La seule variable de cette première série est le batch. Une deuxième série pourra changer la précision ou le matériel, en gardant les autres choix explicitement fixés. Un regroupement par longueur est une nouvelle variante à déclarer, car il modifie l’organisation du travail.

Pour chaque passage, exportez les 1 000 prédictions avec leurs identifiants. Le contrôle doit retrouver exactement les identifiants attendus, sans doublon ni omission. Gardez les prédictions erronées : elles servent au calcul de qualité. Retirer les exemples difficiles améliorerait artificiellement le score et réduirait le corpus réellement traité.

Séparer démarrage, échauffement et passage mesuré

Consignez le téléchargement nécessaire, l’installation, le chargement et la compilation séparément du traitement stabilisé. Ils peuvent être exclus du chronomètre d’un passage tout en occupant une partie de la location. Fixez une règle d’échauffement identique pour toutes les variantes : entrées couvertes, nombre de passages et traitement des recompilations. N’ajustez pas cette règle après avoir vu quelle variante en bénéficie.

Définissez les bornes du temps principal. Pour cet exemple hors ligne, mesurez la lecture du corpus, la tokenisation, les transferts, l’inférence et la matérialisation des prédictions sur l’hôte. Chronométrez ensuite l’évaluation et l’écriture des livrables séparément pour établir la campagne complète. Une durée limitée au calcul GPU ne se compare pas directement à ce temps de traitement.

Les opérations CUDA sont asynchrones : un chronomètre hôte doit attendre la fin des opérations antérieures avant son départ et celle du travail mesuré avant son arrêt. Des événements CUDA conviennent à un périmètre GPU correctement défini. Pour une opération isolée, torch.utils.benchmark.Timer prend en charge l’échauffement et la synchronisation. Gardez les mêmes frontières de mesure entre variantes.

Sources techniques : PyTorch 2.14 — exécution CUDA asynchrone · PyTorch — mesurer avec torch.utils.benchmark

Répéter et conserver les échecs

Prévoyez cinq passages complets par variante pour cette première comparaison. Alternez leur ordre, par exemple 1–4–8 puis 4–8–1 puis 8–1–4, afin qu’une seule variante ne soit pas toujours la première. Conservez la politique de processus, de caches et d’échauffement. Ces cinq passages décrivent votre petite série ; ils ne démontrent pas à eux seuls la stabilité sur une longue période.

Une ligne du tableau brut représente un passage tenté, y compris un arrêt. Elle relie la variante et le corpus aux paramètres, à la durée et au verdict qualité. Les champs expected_ids et observed_ids consignent les nombres d’entrées ; ids_match confirme l’égalité des ensembles, contrôlée dans les fichiers de prédictions conservés séparément. corpus_accepted contient le verdict du passage. Inscrivez les erreurs et le chemin des sorties dans notes. Si une mesure manque, laissez sa cellule vide et indiquez pourquoi. Une absence de GPU n’est pas une mesure de zéro seconde ou de zéro octet.

Si le batch 8 dépasse la mémoire sur les entrées longues, gardez la ligne d’échec et le nombre d’entrées terminées. Ne remplacez pas silencieusement ce passage par un batch plus petit. Le réglage de reprise devient une variante distincte ; son temps et ses tentatives font partie du bilan. Une interruption ou une erreur de format n’est jamais une réussite économique parce qu’elle a été rapide.

Lire les durées sans surinterpréter cinq essais

Présentez les cinq durées brutes, leur médiane, leur minimum et leur maximum, avec le nombre de réussites et d’échecs. La médiane décrit le centre de ces observations ; elle ne supprime pas les incidents. Si un passage est exclu pour une cause extérieure documentée, gardez sa trace et appliquez la même règle d’exclusion à toutes les variantes.

Ne présentez pas un p95 calculé sur cinq passages comme une estimation robuste des cas lents. Pour étudier la latence des requêtes, collectez un ensemble adapté de temps individuels avec le scénario d’arrivée et la concurrence. Les cinq durées de corpus et les latences de 1 000 requêtes ne sont pas la même population.

Si la dispersion observée est comparable à l’écart entre les médianes, la série ne départage pas encore les options. Ajoutez des répétitions dans un protocole commun ou examinez une cause précise : chargement, formes d’entrée, compilation, activité concurrente. Évitez de retenir seulement le meilleur passage de chaque carte.

Vérifier la qualité après un changement de précision

Pour comparer FP32, BF16 ou une quantification, repartez des mêmes entrées et de la même référence. Évaluez le format, la métrique principale et les sous-groupes prévus. Une variante qui dépasse votre tolérance peut être intéressante pour un autre objectif ; elle ne rejoint pas la comparaison à qualité équivalente en abaissant le seuil après coup.

Enregistrez les graines et les options déterministes utilisées. PyTorch ne garantit pas une reproductibilité complète entre versions, plateformes ou exécutions CPU et GPU, même avec la même graine. Précisez donc ce que vous cherchez à reproduire : sorties identiques, écart numérique borné ou qualité métier acceptable. Pour un protocole stochastique, prévoyez plusieurs graines communes et conservez leurs résultats séparés.

Sources techniques : PyTorch 2.14 — portée et limites de la reproductibilité

Utiliser la mémoire comme un critère de faisabilité

Une option doit terminer le corpus avec ses entrées longues avant que son coût soit comparé. Relevez le pic mémoire par périphérique et le périmètre du compteur. Avec PyTorch, memory_allocated suit les tenseurs et memory_reserved la mémoire gérée par l’allocateur : ces valeurs ne s’additionnent pas. Les pics correspondants peuvent survenir à des instants différents.

Le notebook du dossier mémoire aide à distinguer estimation et observation. Son exercice ne remplace pas la mesure de votre modèle : chargez votre environnement, conservez les paramètres et réexécutez votre charge. Une capacité annoncée par carte et un prix de lot ne permettent pas de déduire un débit, une interconnexion ou une répartition automatique du modèle sur plusieurs GPU.

Sources techniques : PyTorch 2.14 — compteurs et allocateur mémoire

Choisir la durée avec le calendrier complet

La durée nécessaire n’est pas seulement la somme des kernels GPU. Construisez une fenêtre d’accès allant de la préparation sur la location à la récupération des livrables : installation, contrôles, échauffement, comparaisons, reprises prévues, évaluation et export. Ajoutez les périodes d’attente pendant lesquelles vous avez encore besoin de conserver la location. Lorsque des tâches se chevauchent, raisonnez sur le calendrier réel plutôt qu’en additionnant deux fois leurs durées.

Exemple de calendrier, sans hypothèse de vitesse : vous souhaitez garder l’accès du lundi à 9 h au vendredi à 9 h, dans le même fuseau et hors changement d’heure. Cette fenêtre couvre 96 heures. Elle dépasse les 72 heures d’un forfait de 3 jours et tient dans les 168 heures d’un forfait de 7 jours. Cela ne prouve pas que vos traitements finiront à temps : leurs durées restent à mesurer.

Le calculateur permet de renseigner votre fenêtre totale et affiche les forfaits de 3, 7 et 30 jours. Un forfait qui couvre le calendrier devient un candidat. Si la campagne dépasse la période retenue, modifiez le programme ou chiffrez explicitement les périodes supplémentaires nécessaires ; ne supposez pas une prolongation automatique.

Calculer le coût engagé avec nos forfaits

Le budget d’une location est le prix du forfait pour un lot, multiplié par le nombre de lots. Le coût par corpus validé divise ensuite ce montant entier par les corpus utiles effectivement acceptés sur le périmètre annoncé. Si aucun corpus n’est accepté, le ratio est non défini. La dépense engagée, elle, reste dans le bilan.

Les prix ci-dessous proviennent de notre catalogue, version du 24 septembre 2026. Ils illustrent la règle de calcul, sans établir quel GPU termine votre charge le plus vite. Un lot B200 comprend déjà deux cartes : multiplier son prix une seconde fois par deux compterait ces cartes deux fois. Deux lots de RTX 4090 pour 7 jours coûtent ainsi 220 USD ; un lot de deux B200 pour 7 jours coûte 2 071 USD.

Un passage court ne transforme pas le forfait en facture à l’heure. Le calculateur utilise le total du forfait, même si une partie de la période reste inutilisée. Pour un budget de projet plus large, consignez séparément les autres dépenses réellement applicables et leur justification. Ne mélangez pas des coûts mesurés chez l’une des variantes avec des postes oubliés chez l’autre.

Sources techniques : IteraGPU — forfaits du catalogue

Compter des livrables utiles, pas des répétitions de mesure

Les cinq répétitions d’un même benchmark servent à observer la dispersion. Elles ne deviennent pas cinq corpus de production utiles simplement parce que cinq fichiers ont été écrits. Définissez les livrables attendus avant la campagne et ne comptez chaque livrable accepté qu’une fois. Si le travail réel porte sur plusieurs corpus, chaque configuration doit traiter les mêmes corpus et appliquer la même règle de qualité.

Dans le calculateur, laissez le nombre de corpus vide tant que les livrables utiles ne sont pas réellement terminés et validés. La case de qualité confirme votre propre contrôle ; l’outil ne lit ni vos prédictions ni vos métriques. Renseignez uniquement la quantité constatée. La fenêtre de campagne peut être une hypothèse de planning, mais une prévision de capacité ne remplace pas des résultats acceptés.

Le bilan final réunit, pour chaque configuration admissible, les verdicts de qualité, les durées brutes, la fenêtre de campagne, le forfait engagé et le nombre de livrables acceptés. Une option rapide peut être utile pour une échéance serrée sans être la moins chère. Deux options qui tiennent dans le même calendrier peuvent être départagées par leur coût engagé, leurs échecs ou l’incertitude qui subsiste.

Télécharger le protocole et garder une preuve réutilisable

Le dossier IteraGPU Lab v1 rassemble les supports de cette comparaison et de la mesure mémoire. Commencez par le README et le protocole de qualité, puis complétez le tableau brut avec vos passages. Les cellules de performance restent vierges avant une exécution ; les tarifs sont des données de catalogue, séparées des mesures.

Pour chiffrer deux lots de RTX 4090 pendant 7 jours, placez calcul_forfaits.py et tarifs-forfaits.csv dans le même dossier, ouvrez un terminal dans ce dossier et lancez la commande ci-dessous avec Python 3.10 ou plus récent. Elle affiche un forfait de 220,00 USD pour deux GPU. L’option facultative --accepted-results reçoit votre nombre entier de corpus utiles distincts réellement terminés et validés. Omettez-la tant que ce constat n’existe pas : le script calcule alors seulement le forfait, sans inventer un coût par résultat.

Conservez ensemble le manifeste, les empreintes d’entrées, les prédictions, les verdicts et le tableau des tentatives. La note de décision indique le réglage retenu, la charge couverte et la raison du choix. Vous pourrez la rapprocher de votre location dans le carnet IteraGPU et relancer exactement la question expérimentale lors d’un changement de modèle ou de version.

Ce protocole hors ligne ne qualifie pas à lui seul un service interactif, un entraînement jusqu’à convergence ou un autre jeu de données. Pour ces usages, redéfinissez l’unité utile et les contrôles avant de comparer. Les fichiers fournis servent à préparer et consigner vos essais ; ce dossier ne présente aucune comparaison mesurée entre les configurations du catalogue ni économie observée.

python calcul_forfaits.py --gpu rtx-4090 --days 7 --lots 2

• IteraGPU Lab v1 — dossier complet ↓

  Archive des scripts, du notebook, des tableaux et des instructions.

• Protocole de qualité ↓

  Entrées, critères d’acceptation et règles de comparaison à fixer avant les essais.

• Tableau des résultats bruts ↓

  Feuille vierge pour conserver les paramètres, mesures, verdicts et échecs.

• Calcul des forfaits ↓

  Calcul du budget avec prix par lot, durées de 3, 7 et 30 jours et corpus validés.

• Tarifs des forfaits ↓

  Instantané des prix de notre catalogue utilisés par le calcul fourni.

• Notebook de mesure mémoire ↓

  Calculs et exercice de mesure à interpréter avec le dossier mémoire.

• Script de mesure mémoire ↓

  Version Python de l’exercice, avec contrôle de l’environnement.

• Instructions et prérequis ↓

  Périmètre des outils et procédure pour les exécuter et conserver les sorties.

• Licence des ressources ↓

  Conditions de réutilisation des ressources originales du dossier.