Matrice de référence PyTorch 2.13 : ce qu'il faut tester avant les mises à niveau FlexAttention, CuTeDSL, torchcomms et FSDP2

PyTorch 2.13 est le genre de version qui peut donner à une équipe le sentiment d'être en retard avant d'avoir exécuté une seule tâche. FlexAttention retient davantage l'attention, Apple Silicon MPS est plus important pour le développement local, CuTeDSL pointe vers le travail du noyau de niveau inférieur, torchcomms et FSDP2 modifient les conversations de formation distribuée, et le travail de mémoire se poursuit autour de couches telles que nn.LinearCrossEntropyLoss.

Cette liste est utile. Il ne s'agit pas d'un plan de mise à niveau.

Le blog officiel de la version PyTorch et les notes de version de GitHub sont la carte de ce qui a changé. Ils ne prouvent pas que votre charge de travail devrait évoluer cette semaine. Traitez chaque chiffre attrayant de vitesse ou de mémoire comme une cible de reproduction locale. Si vos propres scripts, matériels, tranches de données, choix de précision et chemin de restauration ne prennent pas en charge la revendication, celle-ci est simplement le résultat de quelqu'un d'autre.

La même discipline s'applique aux équipes qui réfléchissent déjà à des changements, comme dans LLM servant des plans de migration. Isolez le changement, mesurez-le et rendez la restauration ennuyeuse. L'habitude de preuve des document AI test benchs a également sa place ici : chaque résultat de référence a besoin d'une source, d'un ID d'exécution, d'un environnement, d'une commande et d'une décision.

La question n'est pas de savoir si la version 2.13 est plus rapide

Une mise à niveau du framework échoue rarement parce que la fonctionnalité principale est fausse. Cela échoue parce que l’équipe teste un chemin et se lance dans un autre.

Un benchmark d'attention CUDA peut sembler bon, tandis que l'exportation échoue dans un environnement d'exécution en aval. MPS peut exécuter la démo, tandis qu'un véritable modèle clairsemé retombe ou manque de mémoire. Une tâche distribuée peut montrer une étape plus rapide, tandis que la récupération au point de contrôle devient difficile à faire confiance. Le processeur peut être traité comme une solution de secours ennuyeuse, puis CI bloque la version car un petit chemin d'opérateur a changé.

Voici la version brutale : un benchmark qui ne peut pas déclencher un rollback n'est qu'un graphique.

PyTorch 2.13 devrait être testé en tant que changement de plate-forme. Cela signifie la même charge de travail, et non une charge de travail plus jolie, sur tous les backends que l'équipe utilise réellement. Les ordinateurs portables Apple Silicon, les serveurs CUDA, les travailleurs ROCm, les tâches CPU CI et les clusters distribués n'échouent pas de la même manière. Une matrice de test utile accepte cela dès le départ.

La matrice de test multiplateforme PyTorch 2.13

{
  "matrix": "optijara-cross-platform-pytorch-2-13",
  "versions": ["current_baseline", "pytorch_2_13"],
  "backends": ["mps", "cuda", "rocm", "cpu", "distributed"],
  "gates": ["correctness", "latency", "throughput", "peak_memory", "determinism", "compile_export", "rollback"],
  "decisions": ["adopt", "isolate", "defer", "rollback"]
}

Commencez par le contrôle

L'exécution du contrôle est l'endroit où de nombreux programmes de référence s'interrompent discrètement.

Gelez la version actuelle de PyTorch, la validation du modèle, la tranche d'ensemble de données, la version de tokenizer ou de prétraitement, la politique de départ, le mode de précision, la forme du lot, la longueur de la séquence et le masque d'attention. Enregistrez le modèle matériel, le backend de l'accélérateur, les versions du pilote ou du runtime, le lanceur distribué, les paramètres du compilateur et les variables d'environnement. Si la charge de travail comporte à la fois des modes d’entraînement et d’inférence, référencez les deux.

Gardez ensuite les pièces ennuyeuses identiques. Mêmes scripts. Mêmes entrées. Même politique d’échauffement. Même fenêtre de mesure. Ne comparez pas une exécution PyTorch 2.13 soigneusement réglée avec une base de référence obsolète que personne n'a touchée depuis des mois.

Séparez l’échauffement de la compilation de la mesure en régime permanent. Capturez la latence p50 et p95 lorsque la latence est importante, les jetons ou les échantillons par seconde lorsque le débit est important, la mémoire maximale, la dérive numérique, le temps de compilation, les ruptures de graphique, le coût de redémarrage et le mode de défaillance. La même règle de gel de la charge de travail apparaît dans tests d'IA multimodaux en temps réel : si le test change pendant l'évaluation, le résultat devient difficile à faire confiance.

FlexAttention sur MPS et CUDAFlexAttention mérite des tests construits à partir des véritables modèles d'attention de l'équipe. Une attention particulière ne suffit pas si la migration est motivée par un comportement clairsemé ou à contexte long. Incluez des masques causals, des modèles de fenêtres coulissantes, des modèles de blocs clairsemés, de longues longueurs de séquence, une précision mixte et des passes arrière. Les documents officiels FlexAttention définissent la surface de l'API. Le guide de profilage Hugging Face aide les équipes à lire les traces d'attention au lieu de se fier à un seul chiffre de débit global.

Sur Apple Silicon, les tests MPS devraient dépasser le succès de l’importation. Exécutez le même motif clairsemé, le même masque, la même forme de lot et la même longueur de séquence prévus pour le travail réel. Comparez avec la référence MPS précédente et, si possible, une référence CUDA ou CPU pour vérifier l'exactitude. Surveillez les opérateurs non pris en charge, les replis silencieux, les pics de mémoire et les dérives de précision mixte.

Sur CUDA, ajoutez des vérifications déterministes en amont. Répétez les analyses ensemencées. Comparez les dégradés aux tolérances convenues. Conservez l’ancien SDPA ou le chemin d’attention personnalisé à côté de FlexAttention jusqu’à ce que le nouveau chemin gagne sa place. Si un comportement déterministe fait partie de l'exigence de déclenchement, le portail n'est pas à vitesse moyenne. La porte est reproductible avec les mêmes paramètres de graine, de précision et de backend.

Portes du noyau, de la mémoire et du compilateur

CuTeDSL devrait se trouver dans une voie de prototype, à moins que l'équipe ne possède déjà une maintenance de noyau personnalisée. Le test n’est pas seulement la vitesse. C'est la propriété. Qui débogue le code ? Quel matériel est requis ? Comment l’équipe va-t-elle le comparer au comportement standard de PyTorch ? À quelle vitesse peut-il être désactivé lorsqu'un pilote, une forme ou un mode de précision change ?

nn.LinearCrossEntropyLoss appartient à une voie de mémoire et d’exactitude. Comparez la mémoire maximale, le temps de pas, le comportement des logits, le comportement de précision mixte, les signaux de convergence et la compatibilité avec la pile d'entraînement. Un gain de mémoire n'a de valeur que si le chemin de perte entraîne toujours le modèle prévu et ne crée pas de nouveau travail d'intégration.

Pour torch.compile et export, utilisez des portes au lieu de l'optimisme. Comptez les sauts de graphique. Enregistrez la surcharge de compilation. Testez de vraies formes dynamiques, pas seulement une démo propre de forme fixe. Vérifiez l'exportation lorsque le modèle quitte Python pour un autre environnement d'exécution. L'article de normalisation-fusion du 10 juillet constitue un contexte architectural utile car la fusion peut modifier le trafic mémoire et la structure du noyau. Cela ne supprime toujours pas le besoin de preuves spécifiques à la charge de travail. Pour une portabilité plus large, comparez cela avec AI computing portability testing, où le choix du backend doit être prouvé sous des contraintes pratiques.

Tests distribués et de secours

Le chevauchement de torchcomms et de FSDP2 nécessite des tests de système distribué, pas des tests de cases à cocher. Pour torchcomms, mesurez le comportement collectif, la latence, la bande passante, la gestion des pannes, la disponibilité du backend et la compatibilité avec les outils de lancement existants. Confirmez que la surveillance explique toujours ce qui se passe lorsqu'une tâche ralentit.

Pour le chevauchement FSDP2, mesurez le temps d'étape, l'attente de communication, le pic de mémoire, la sauvegarde et le chargement des points de contrôle, la gestion de l'état de l'optimiseur et la mise à l'échelle sur le nombre de nœuds contrôlés. N'approuvez pas le chevauchement d'une étape rapide. Une meilleure voie est celle qui entraîne, contrôle les points, récupère et laisse suffisamment de preuves aux opérateurs pour déboguer la prochaine panne.Les vérifications ROCm et CPU maintiennent les chemins de secours honnêtes. Une équipe ne peut pas former son plus grand modèle sur le CPU, mais les tâches CPU protègent souvent le CI, le développement local et les tests de fumée. Le ROCm peut siéger dans une flotte mixte. Un succès uniquement CUDA ne devrait pas approuver une flotte qui dépend également des ordinateurs portables Apple Silicon, des travailleurs ROCm ou du repli du processeur.

Erreurs courantes et mises en garde

L’erreur la plus courante consiste à modifier la charge de travail tout en modifiant le cadre, puis à attribuer au cadre le mérite du résultat. Gardez la charge de travail fixe. Une autre erreur consiste à tester CUDA en mode heureux tout en ignorant les ordinateurs portables MPS, les travailleurs ROCm, les tâches d'exportation et le CPU CI. Une troisième consiste à traiter la dérive numérique après coup, car le débit s'est amélioré.

D'autres pièges sont moins glamour. Les équipes comptent l'échauffement de la compilation comme une vitesse stable. Ils signalent un débit moyen mais manquent la mémoire maximale. Ils testent des séquences plus courtes que celles utilisées en production. Ils répètent les réclamations des notes de version comme si ces affirmations étaient des garanties. Ils ignorent la restauration parce que le benchmark semblait propre.

Les mises en garde doivent être écrites avant le début de l’exécution. Le coût de mise en œuvre peut dépasser un petit gain de référence. Le matériel, les pilotes, la précision et la forme de la charge de travail peuvent changer la réponse. Les données de référence peuvent nécessiter des contrôles de confidentialité si les invites, les étiquettes ou les échantillons sont sensibles. Le comportement du cache peut donner une meilleure apparence aux exécutions répétées qu’à la première exécution. La qualité de l'évaluation détermine si une dérive de précision est visible. Les API prototypes et les chemins de noyau personnalisés peuvent ajouter des tâches de maintenance que le numéro de vitesse n'indique pas.

Différez l’adoption de PyTorch 2.13 lorsque les modèles clairsemés critiques ne sont pas testés, que les vérifications déterministes en amont échouent, que les chemins d’exportation ne sont pas pris en charge, que la récupération distribuée est fragile, que les budgets de mémoire sont dépassés ou que la restauration dépend d’héroïsmes manuels. L'isolement n'est pas un échec. C'est souvent la réponse des adultes.

Liste de contrôle de mise en œuvre et plan de mesure

Utilisez une fenêtre de référence de deux semaines si le changement concerne la formation en production, le développement de modèles ou le service des dépendances. La première semaine devrait couvrir l'examen des sources, la capture de la ligne de base, le gel de l'environnement et les tests sur un seul nœud. La deuxième semaine devrait couvrir les tests distribués, les portes du compilateur et d'exportation, la répétition du rollback et une décision Canary.

Le plan de mesure doit enregistrer la latence p50 et p95, le débit, la mémoire maximale, le temps de compilation, les ruptures de graphique, la dérive numérique, la répétabilité déterministe, le comportement des points de contrôle et la durée de restauration. Stockez les ID d’exécution, les détails du matériel, les versions de logiciels, les commandes, les identifiants de tranches d’ensemble de données, les URL sources, les portes de réussite ou d’échec et les notes de reproduction.Définissez des seuils avant d’exécuter les tests. Un cahier de recherche, une formation nocturne, un service d'inférence destiné au client et une tâche de réglage fin distribuée ne doivent pas partager un seul seuil. Décidez de ce qui justifierait l’adoption avant que les graphiques n’existent. Autrement, le benchmark devient une négociation après coup.

Si une équipe a besoin d'aide pour transformer les notes de version en tests d'infrastructure d'IA reproductibles, Optijara peut l'aider à concevoir la matrice, à automatiser la capture des preuves et à transformer les mises à niveau du framework en plans d'adoption mesurés. PyTorch 2.13 devrait générer une charge de travail d'adoption par charge de travail, backend par backend.