La PyTorch Foundation a publié PyTorch 2.12 mercredi — 2 926 commits de 457 contributeurs depuis 2.11. La manchette performance est un swap de backend sur une opération de niche qui s'avère beaucoup compter : `linalg.eigh` batché sur CUDA est jusqu'à 100× plus rapide après la dépréciation du backend MAGMA hérité au profit de cuSolver, avec les heuristiques de dispatch mises à jour pour utiliser `syevj_batched` sans condition. Des workloads qui tournaient en minutes auparavant — courants en calcul scientifique et dans toute étape d'entraînement ML qui a besoin de décompositions propres de matrices batchées — tournent maintenant en secondes, fermant enfin un gap de longue date avec CuPy. Séparément, Adagrad rejoint Adam, AdamW et SGD avec `fused=True`, exécutant l'étape d'optimiseur dans un seul kernel CUDA au lieu de plusieurs lancements séparés. Le lowering `addcdiv` basé sur FMA sur XPU apporte une parité numérique bit-à-bit entre `torch.compile` et le mode eager sur les GPU Intel — petit isolément mais porteur si tu chassais des comportements d'optimiseur compilé irreproductibles.

L'histoire stratégique, c'est le pivot cross-backend. PyTorch 2.12 introduit `torch.accelerator.Graph`, une API device-agnostique pour la capture et replay de graphes qui unifie l'abstraction au-dessus des implémentations spécifiques au backend comme `torch.xpu.XPUGraph`. Chaque backend s'enregistre via une interface légère `GraphImplInterface` ; `c10::Stream` et `torch.Stream` exposent maintenant `is_capturing()` comme remplacement backend-agnostique du `is_current_stream_capturing` spécifique au device. Le support initial couvre CUDA et XPU (Intel), avec extensibilité aux backends hors-arbre via `PrivateUse1`. C'est la contrepartie framework de la dynamique du moat CUDA couverte plus tôt cette semaine : PyTorch facilite explicitement la participation des accélérateurs non-CUDA au modèle de programmation graph-capture, qui est la couche où vit Inductor et la plupart du travail de performance. Les utilisateurs ROCm gagnent les segments mémoire expansibles, les collectives mémoire symétrique rocSHMEM, et le pipelining FlexAttention dans la même release — le chemin AMD a eu un bump notable.

Deux autres changements à flagger pour les builders. Premièrement, `torch.export.save` et `torch.export.load` sérialisent maintenant correctement le dtype `float8_e8m0fnu` utilisé comme exposant de bloc partagé dans les formats de quantification Microscaling (MX) — MXFP4, MXFP6, MXFP8. Jusqu'à présent, les modèles utilisant ces techniques de quantification agressives ne pouvaient pas être exportés via le chemin de déploiement PyTorch standard ; les équipes livrant des LLMs en environnements contraints en coût ou edge devaient inventer leur sérialisation custom. Ce gap est fermé. Deuxièmement, le control flow `torch.cond` peut maintenant être capturé et rejoué à l'intérieur de CUDA Graphs via les nœuds IF conditionnels de CUDA 12.4 — précédemment, le branchement dépendant des données forçait un fallback aux CUDA graph trees parce que l'évaluation de branche se faisait sur le CPU. Avec 2.12, l'évaluation de branche reste sur GPU dans une seule capture de graphe (backends eager et cudagraphs ; support Inductor prévu). Pour les workloads style agent ou RL avec du control flow dépendant des données, ça enlève une vraie falaise de performance.

Pour les builders : c'est une release à faible friction si tu es déjà sur la track 2.x — la plupart des gains sont transparents (dispatch eigh, Adagrad fusé, FMA addcdiv) et ne demandent aucun changement de code. Le fix d'export Microscaling est celui à lever immédiatement si tu livres des modèles quantifiés ; clone l'exemple dans la doc et re-teste ton pipeline d'export. L'API torch.accelerator.Graph est surtout pertinente si tu cibles Intel XPU ou bâtis un accélérateur custom — la signification à long terme, c'est que PyTorch abstrait maintenant explicitement la capture de graphe à travers les backends, ce qui est la fondation que tout challenger CUDA sérieux a besoin de bâtir dessus. Les équipes d'entraînement distribué devraient regarder les ajouts ncclx + gloo de FlightRecorder et le nouveau `seq_num` NCCL pour la corrélation des collectives entre ranks — les deux sont des améliorations de qualité-de-vie concrètes pour le debugging. Les notes de release valent une lecture end-to-end si tu maintiens un pipeline d'entraînement ; les items manchette ci-dessus sont un échantillon, pas la liste complète.