Récapitulation et examen final
Dix modules pour passer d'un tenseur brut à un service HTTP qui répond
en 40 millisecondes à partir d'un fichier .pt autonome. Voici le
cours condensé, puis les fils qui le traversent.
Le cours d'un coup d'œil
| Module | L'essentiel à retenir |
|---|---|
| 1. Tenseurs PyTorch | torch.tensor copie, from_numpy partage la mémoire ; les opérations en place cassent l'autograd |
| 2. Autograd | Graphe reconstruit à chaque passe avant ; .grad s'accumule, zero_grad obligatoire |
3. nn.Module | Sous-modules enregistrés dans __init__, nn.ModuleList obligatoire pour une collection ; state_dict seule sérialisation |
4. Dataset/DataLoader | Deux transform distincts, Normalize calibré sur l'entraînement uniquement, num_workers sous if __name__ == "__main__" |
| 5. Boucle d'entraînement | Cinq lignes strictes ; model.train()/eval() change Dropout et BatchNorm sans erreur si oublié |
| 6. Optimiseurs, planificateurs | AdamW par défaut moderne, CosineAnnealingLR sans surprise ; OneCycleLR piloté au pas, les autres à l'époque |
| 7. GPU et précision mixte | Un device unique, pin_memory+non_blocking+num_workers ; autocast+GradScaler divisent la durée par deux |
| 8. Points de contrôle | Cinq états sauvés, map_location pour recharger ailleurs ; meilleur ≠ dernier, deux fichiers distincts |
| 9. Transfert torchvision | weights.transforms() donne la normalisation exacte ; BatchNorm gelée exige .eval() explicite |
| 10. TorchScript et ONNX | trace capture le chemin observé, script analyse la logique ; vérifier numériquement avant toute mise en service |
Les fils qui traversent le cours
Le silence est votre pire adversaire. Aucune des erreurs les plus
coûteuses de ce cours ne lève d'exception : zero_grad oublié, eval()
non appelé, normalisation absente, BatchNorm gelée en apparence,
trace sur un contrôle de flux, prétraitement resté dans le script
d'entraînement. À chaque fois, l'entraînement continue, la métrique
affiche un chiffre, et c'est ce chiffre qui trompe. La discipline
consiste à mettre en place les contrôles avant qu'ils ne servent :
afficher les deux pertes, comparer une version étalon, vérifier
numériquement un export, tester la reprise après sauvegarde.
Ce qui n'est pas dans l'artefact n'existe pas. La leçon revient à
plusieurs modules : state_dict plutôt que l'objet Python (module 3
et 8), transformation exportée avec le modèle (module 10),
normalisation officielle plutôt que copiée à la main (module 9). Avant
toute livraison, la question à se poser est : ce fichier suffit-il à
quelqu'un qui n'a ni mon script, ni mon environnement, ni mon
souvenir de la préparation ?
La performance vient d'un pipeline, pas d'un accélérateur. La
réaction spontanée face à un entraînement lent est de louer un GPU
plus gros. Les modules 4, 6 et 7 proposent l'ordre inverse : mesurer,
alimenter proprement le GPU (pin_memory, num_workers, non_blocking),
activer la précision mixte, essayer torch.compile. Les deux
premières étapes ne coûtent rien et donnent souvent plus que la
troisième, qui multiplie la facture d'infrastructure.
PyTorch expose la machinerie, à charge pour vous de la respecter.
Contrairement à Keras du cours 08, ni fit, ni EarlyStopping, ni
ModelCheckpoint ne sont fournis. C'est la contrepartie de la
souplesse : votre boucle vous appartient, avec ses ordres d'appel
stricts (module 5), sa gestion des modes (train/eval), sa politique
de sauvegarde. Une fois cette infrastructure écrite proprement, elle
sert de patron à tous les projets suivants.
L'examen final
L'examen comporte 40 questions couvrant les dix modules :
comportement de from_numpy et opérations en place, mécanique de
l'autograd et pièges d'accumulation des gradients, enregistrement des
sous-modules et rôle de state_dict, composition d'un pipeline de
données sans fuite entre train et validation, ordre strict des cinq
lignes de la boucle et distinction entre model.eval() et
torch.no_grad, choix d'un optimiseur et pilotage d'un planificateur,
précision mixte avec autocast et GradScaler, contenu d'un point de
contrôle et reprise avec map_location, procédure de transfert en deux
phases et piège de BatchNorm gelée, différence entre trace et
script avec vérification numérique avant service.
Plusieurs questions présentent des situations à diagnostiquer : un
modèle qui ne bouge plus après un w = w - lr * w.grad, une exactitude
qui chute soudainement en validation, un GPU à 30 % d'utilisation,
une perte qui devient NaN à la deuxième époque, une reprise qui écrase
le meilleur checkpoint avec une version dégradée, un modèle exporté qui
prédit autre chose que l'original. C'est le jugement qui est
évalué, pas la mémorisation des signatures d'API.
En cas de réussite, votre attestation d'achèvement est délivrée immédiatement ; son numéro est vérifiable par tout tiers sur la plateforme.
Reprenez le tableau ci-dessus et, pour chaque ligne, demandez-vous
« quel symptôme verrais-je si je me trompais ici ? ». Si vous savez
expliquer pourquoi un w = w - lr * w.grad sur une variable la retire
de la liste des paramètres entraînables, pourquoi geler un ResNet
ne fige pas ses BatchNorm, et pourquoi un modèle tracé peut prédire
la même chose que l'original sauf sur une entrée particulière, vous
êtes prêt. Bonne chance !
Examen final
Prêt à valider ce cours ?
40 questions tirées au hasard dans la banque du cours · seuil de réussite 70 % · certificat PDF vérifiable délivré immédiatement en cas de réussite.
Commencer l'examenConnexion à votre compte InSkillML et abonnement actif requis. Vous pouvez aussi lancer l'examen depuis Mes cours.