1. Définir un résultat avant de choisir la carte
Choisissez un échantillon qui traverse toute votre application. Pour l’inférence, partez de quelques entrées représentatives et d’un format de sortie attendu. Pour l’adaptation d’un modèle, prévoyez une courte exécution qui lit les données, effectue une mise à jour et écrit un checkpoint. Le but est de vérifier le chemin complet avant de lui confier le volume final.
Prenons un exemple pédagogique : vous voulez classer des documents. Préparez douze documents identifiés, dont plusieurs longueurs et un cas que le programme doit refuser proprement. Fixez les catégories autorisées et la destination des résultats. Les douze identifiants devront apparaître exactement une fois dans le bilan, avec un résultat accepté ou une erreur explicite. Ce scénario est à adapter à votre application ; il ne suppose aucun modèle ou débit particulier.
Faites défiler le tableau pour lire toutes les colonnes.| Point à vérifier | Critère préparé avant le lancement |
|---|---|
| Entrées | 12 identifiants uniques ; fichiers lisibles ; un cas invalide prévu. |
| Résultats | Une catégorie autorisée par document accepté ; aucun identifiant inventé. |
| Échecs | Un motif rattaché à chaque document refusé ; pas de disparition silencieuse. |
| Fin de l’essai | Acceptés + refusés = 12 ; rapport et résultats relus depuis une copie. |
2. Choisir le backend, la mémoire et le forfait
Commencez par les bibliothèques du projet. Une dépendance CUDA vous oriente vers une chaîne NVIDIA ; une offre MI300X demande d’examiner la prise en charge de ROCm, notamment celle des extensions. Le sélecteur officiel PyTorch distingue système et plateforme de calcul : recopier une commande d’un autre poste ne constitue pas une vérification de compatibilité.
Comparez ensuite la mémoire nécessaire à une tâche représentative : poids, entrées, calculs intermédiaires et états propres à votre méthode. La taille du fichier du modèle ne suffit pas. Si vous ne connaissez pas encore le pic, gardez ce point comme objectif du pilote, sans annoncer qu’un modèle tiendra à partir de son seul nombre de paramètres.
Choisissez 3, 7 ou 30 jours et de 1 à 10 lots. Un lot contient une carte, sauf B200 qui en contient deux. Plusieurs cartes ne répartissent pas automatiquement le programme et n’unifient pas leur mémoire. Prévoyez dans la durée l’installation, les contrôles, le calcul et l’export ; les douze documents du pilote servent à vérifier la procédure, pas à prédire mécaniquement la durée de toute la campagne.
3. Préparer un dossier qui survit au changement de machine
Rassemblez la révision du code, les dépendances, la référence des données et du modèle, les paramètres et la commande d’entrée. Indiquez comment fournir les accès nécessaires séparément. Un chemin vers votre répertoire personnel n’est pas une procédure de transfert : remplacez les suppositions implicites par des paramètres et vérifiez les chemins depuis le dossier du projet.
La préparation Ubuntu, PyTorch, Blender ou personnalisée choisie dans la configuration exprime votre besoin. Elle ne prouve pas que votre projet, ses extensions ou ses licences sont déjà installés. Décrivez ce qui doit être présent puis contrôlez l’environnement effectivement reçu avant de commencer le traitement.
Pour notre lot de documents, gardez une entrée pilote immuable, un fichier de paramètres et un répertoire de résultats distinct par essai. Écrivez aussi comment relire le bilan. Ce dossier n’a pas besoin d’être volumineux ; il doit éviter que la réussite dépende d’une cellule oubliée, d’un terminal ancien ou d’un fichier non copié.
projet/
README.md # installation, lancement, contrôle
requirements-rebuild.txt # dépendances et provenance documentées
config/pilote.json # paramètres sans secret
data/pilote/ # les 12 entrées autorisées
src/ # votre application
runs/ # un sous-dossier par essai4. Relire la commande puis suivre les étapes du service
Le récapitulatif doit correspondre à votre choix : modèle, durée, lots, nombre total de cartes, préparation et montant USD. Le total est le prix du lot pour la durée, multiplié par le nombre de lots. Le prix du lot B200 inclut déjà ses deux cartes : ne multipliez pas une seconde fois par le nombre de GPU.
Pour une première commande, créez votre compte avec prénom, nom, email et mot de passe. Si vous avez déjà un compte, connectez-vous ; si vous êtes déjà connecté, les coordonnées sont préremplies. Le compte permet de retrouver les commandes et le solde depuis un autre navigateur. Le parcours ne demande ni procédure KYC ni pièce d’identité.
Pour payer en crypto, utilisez l’actif, le réseau, l’adresse, le montant et l’échéance affichés pour le règlement concerné. Après le transfert, « J’ai payé » enregistre votre signalement. Il ne confirme ni réception des fonds ni mise à disposition. Un solde USD suffisant peut également régler intégralement la location. Suivez ensuite les informations de préparation et les accès effectivement communiqués.
5. Contrôler le lancement avant le volume final
Lorsque la ressource est mise à disposition, identifiez l’interpréteur réellement utilisé et l’environnement chargé. Lancez le diagnostic minimal avant votre application. Un import PyTorch réussi ne démontre pas un calcul GPU ; un calcul simple réussi ne valide pas toutes les extensions du modèle. Le dossier de diagnostic décrit cette progression et fournit une ressource téléchargeable.
Exécutez ensuite votre pilote dans un répertoire de sortie neuf. Pour les documents, vérifiez les identifiants, les catégories, le nombre de réussites et les refus attendus. Examinez plusieurs résultats avec leurs entrées : une sortie syntaxiquement valide peut rester incorrecte pour l’usage. Ne passez au corpus complet qu’après avoir écrit ce qui a été accepté et ce qui reste à corriger.
Si le lancement échoue, notez la première erreur et l’étape atteinte. Vérifiez l’interpréteur avant de réinstaller ; les chemins avant de recopier ; la taille des entrées avant d’augmenter le batch. Changez un facteur à la fois. Si le processus dure, organisez son suivi séparément de la connexion interactive utilisée pour le démarrer.
6. Récupérer une preuve utilisable et décider de la suite
Copiez les résultats et leur bilan vers un emplacement que vous contrôlez, puis relisez cette copie. Vérifiez qu’elle contient les paramètres et références nécessaires pour comprendre le résultat. Ne considérez pas un fichier présent dans l’environnement de calcul comme votre seule sauvegarde. Faites ce contrôle pendant le pilote, sans attendre l’échéance de la location.
Pour un entraînement, ajoutez un test de reprise dans un nouveau processus. Le mini-projet Kernodeck démontre une méthode sur CPU ; votre application doit encore qualifier ses propres états, précision et données. Pour les documents indépendants, la reprise consiste plutôt à identifier les éléments terminés et ceux à retraiter.
Votre décision finale peut être de lancer le volume prévu, de corriger l’environnement ou de revoir la configuration. Conservez cette décision avec son motif. Un pilote qui révèle une incompatibilité est utile : il transforme un problème flou en condition précise à résoudre avant d’engager davantage de calcul.