Définir ce qui permettra de clôturer la campagne
« Entraîner un modèle » ne définit ni le travail à acheter ni le moment où il est terminé. Préférez un objectif comme comparer un témoin et deux variantes sur un corpus figé, puis livrer leurs prédictions, une analyse des erreurs et un artefact rechargeable. Le résultat négatif peut suffire : montrer qu’aucune variante ne respecte le seuil évite une campagne plus longue mal ciblée.
Séparez trois catégories avant la commande : indispensable pour conclure, utile si le temps le permet, exploratoire. Le témoin, le contrôle des données et une vérification de reprise appartiennent généralement à la première. Fixez un point de décision après le pilote : continuer, réduire une variante facultative ou revoir la question. Le forfait disponible ne doit pas devenir une obligation de remplir chaque heure.
Construire un calendrier de bout en bout
Une extrapolation à partir d’un pas d’entraînement déjà chaud oublie parfois le chargement, les entrées longues, la validation et les fichiers de sortie. Distinguez les plages pendant lesquelles la machine est mobilisée et le temps humain de préparation. Des plages indépendantes peuvent se chevaucher ; deux étapes qui utilisent le même GPU ne deviennent pas parallèles parce qu’elles ont deux lignes dans un tableau.
Voici un calendrier illustratif, sans vitesse GPU mesurée. Il réserve 48 heures séquentielles depuis le début de la préparation jusqu’à la récupération des résultats. Dans une fenêtre de 72 heures, il laisse 24 heures non engagées. Cette soustraction vérifie seulement le calendrier : ni l’installation, ni une variante de dix heures ne sont des délais promis par IteraGPU.
| Étape | Heures prévues | Résultat attendu |
|---|---|---|
| Préparation des entrées et environnement | 4 | Versions, fichiers et chemins vérifiés |
| Pilote complet | 2 | Chargement, mise à jour, validation et sauvegarde |
| Référence | 8 | Sorties et métriques du témoin |
| Deux variantes prioritaires | 20 | Deux passages complets, 10 h réservées à chacun |
| Évaluation et lecture des erreurs | 6 | Critère d’acceptation appliqué |
| Export et contrôle de relecture | 2 | Dossier récupérable |
| Reprise prévue | 6 | Marge affectée à un incident |
| Total | 48 | 24 h restantes dans une fenêtre de 3 jours |
Comparer les forfaits sans inventer une facturation horaire
Le prix d’un lot couvre la durée sélectionnée. Une RTX 4090 du catalogue coûte 47,14 USD pour trois jours, 110 USD pour sept jours et 390 USD pour trente jours. Ces montants sont les tarifs IteraGPU ; ils ne mesurent pas le nombre de modèles entraînés. Deux lots sur trois jours représentent 94,28 USD. Le lot B200 inclut déjà deux GPU : sa composition ne multiplie pas une seconde fois son prix.
Si le calendrier illustratif s’allonge de 30 heures, il atteint 78 heures et dépasse trois jours de six heures. Examinez alors le forfait de sept jours, ou un protocole réduit qui répond encore à la question. Acheter deux lots peut aider des variantes indépendantes si votre environnement le permet ; cela ne raccourcit pas automatiquement une exécution et ne fusionne pas les mémoires.
Sources techniques : Tarifs IteraGPU et unités de location · Calculer les forfaits et vérifier la fenêtre
Prioriser les variantes par leur utilité pour la décision
Après le pilote, actualisez vos hypothèses de durée et demandez quel résultat modifierait le choix. Une variante presque identique au témoin peut être moins informative qu’un contrôle qui isole une cause. Évitez de lancer d’un coup toutes les combinaisons de rang, précision, taux d’apprentissage et longueur. Le guide d’ablations montre comment poser un petit plan interprétable.
Inscrivez la règle d’arrêt avant les essais : perte non finie, qualité sous un seuil, entrée indispensable tronquée ou absence de reprise utilisable. Si l’arrêt survient, conservez son identifiant et sa raison. Une exécution interrompue ne devient pas un livrable accepté, mais elle reste une dépense et parfois une information décisive. Une nouvelle configuration après correction mérite un nouvel identifiant.
Prévoir le coût d’une interruption
Une reprise d’entraînement demande plus que les poids seuls. La documentation PyTorch distingue les paramètres du modèle et l’état de l’optimiseur ; la progression doit aussi être conservée. Selon la boucle, ajoutez les états nécessaires du planificateur, du scaler, des aléas et du parcours des données. Décidez si vous voulez reprendre l’apprentissage ou simplement relancer une inférence.
Testez une sauvegarde précoce puis son rechargement dans un nouveau processus. Comptez le temps d’écriture, de transfert et de restauration dans le calendrier. Un intervalle de sauvegarde ne se choisit pas uniquement pour produire beaucoup de fichiers : rapprochez la perte de travail tolérable et le coût observé de l’opération. Vérifiez aussi où vivent ces fichiers et comment vous les récupérerez avant la fin de la période.
Sources techniques : PyTorch — sauvegarde et reprise
Rapporter le budget au résultat utile
À la clôture, donnez le forfait engagé, les autres dépenses réellement incluses et le nombre de livrables ayant passé les contrôles annoncés. Les dépenses externes éventuelles restent séparées du prix de la location ; n’inventez ni taux de taxe ni coût de transfert non fourni. Le coût d’une campagne n’est pas effacé lorsque son résultat est négatif.
Exemple arithmétique conditionnel : si un forfait de 47,14 USD permet de livrer deux corpus distincts complets et acceptés, sa part de location est 23,57 USD par corpus. Rejouer cinq fois le même corpus pour chronométrer ne donne pas cinq corpus utiles. Avec zéro corpus accepté, le ratio est indéfini ; affichez le coût engagé et la cause du rejet, jamais un coût nul. Pour une décision de recherche, décrivez plutôt la conclusion obtenue que de créer une unité artificielle.
Clôturer avec des fichiers que vous pouvez relire
Préparez le dossier de sortie pendant la campagne : manifeste, paramètres, mesures brutes, prédictions, motifs d’arrêt et instructions de rechargement. Vérifiez les identifiants attendus, les fichiers vides et les chemins dépendant d’un dossier temporaire. Pour un adaptateur, gardez la révision exacte de la base. Un fichier présent mais impossible à recharger n’est pas une sortie vérifiée.
Rapprochez prévu et réalisé sans réécrire le plan initial : temps réservé, temps constaté, écarts expliqués, décisions prises. Le carnet IteraGPU peut conserver la synthèse et la référence de commande ; vos fichiers bruts et sauvegardes restent à organiser. La campagne suivante démarre alors avec une meilleure estimation et une liste plus courte d’incertitudes.
Questions pratiques
Trois jours suffisent-ils pour ma campagne ?
Trois jours donnent une fenêtre de 72 heures, pas une promesse de débit. Additionnez préparation, essais, évaluation, reprises et récupération ; confirmez les durées sur un pilote représentatif. Si le plan dépasse la fenêtre, réduisez un travail facultatif ou examinez une durée plus longue.
Puis-je répartir le prix entre mes expériences ?
Vous pouvez définir une répartition analytique interne, par objectif ou temps mobilisé. Elle ne change pas le forfait de la commande. Documentez la règle et incluez les essais échoués pour éviter de minorer le coût du résultat retenu.
Le moins cher à trois jours est-il toujours le bon choix ?
Le prix ne départage que des configurations qui satisfont déjà la compatibilité, la mémoire et la qualité requises. Une offre moins chère qui ne termine pas la charge utile ne répond pas à la même décision.