Analyse approfondie · Environ 8 min de lecture
PyTorch MPS : décodage, exactitude et mémoire du pilote doivent être mesurés séparément
L’équipe PyTorch de Hugging Face explique les changements MPS de la version candidate 2.15, avec des preuves distinctes pour le décodage groupé, le stockage FP8, le padding et les travaux futurs de 2.16.
- Publié ici
- Date de la source
- Source vérifiée
Un article technique du 20 octobre, signé par des contributeurs PyTorch de Hugging Face, explique comment des noyaux Metal dédiés modifient le travail du backend MPS sur Apple silicon. Il propose une installation de la version candidate PyTorch 2.15 et un aperçu séparé de 2.16. Son apport utile est un ensemble de goulets d’étranglement et de mesures précis, plutôt qu’une accélération valable pour toutes les charges sur Mac.
Écouter les actualités
Écoutez cet article ou poursuivez la lecture des actualités.
Préparation de la lecture…
Voix de l’appareil
La voix est traitée par votre navigateur ou appareil. AISubHub n’envoie pas le texte à une API audio. Les voix et la lecture écran verrouillé dépendent de l’appareil.
La reprise peut répéter une courte phrase.
En bref
- L’environnement documenté exige Apple silicon, macOS 15 ou ultérieur et Python 3.11 ou ultérieur. L’article présente 2.15 comme une version candidate et distingue les travaux 2.16 disponibles dans les versions nightly ou encore en revue.
- Une spécialisation du décodage pour la multiplication matricielle groupée atteint environ 1.3 fois le débit dans les expériences montrées sur M3 Ultra avec torch.compile. Un autre graphique de softmax mesure les microsecondes d’une opération unique, pas la latence d’une réponse complète.
- Pour un décodage VAE Wan2.2 en 28 tuiles, le pic total de mémoire du pilote rapporté passe de 270.135 à 8.108 GiB, tandis que le pic réservé par l’allocateur reste à 8.070 GiB. Ces mesures de mémoire sont différentes.
1. Commencer par la version et la partie de l’exécution qui change
Les auteurs se présentent comme l’équipe PyTorch de Hugging Face, travaillant en amont avec les mainteneurs et contributeurs de PyTorch. Leur explication porte sur le remplacement de certains chemins MPSGraph par des noyaux Metal dédiés. Il s’agit d’ingénierie du backend : les modèles peuvent en bénéficier sans qu’il s’agisse de nouveaux modèles, et un noyau plus rapide ne démontre pas de meilleures réponses. La configuration indiquée exige un Mac Apple silicon, macOS 15 ou ultérieur et Python 3.11 ou ultérieur.
L’article invite explicitement à essayer une version candidate 2.15 dans un environnement séparé. Les sections suivantes traitent de changements 2.16 pouvant figurer dans les versions nightly ou rester en revue. AISubHub n’a pas vérifié indépendamment le statut des versions stables ultérieures. Pour une comparaison reproductible, il faut relever la compilation exacte, l’appareil, le dtype, les paramètres du compilateur et la charge avant de passer d’une section à l’autre. Sinon, une optimisation à venir peut facilement être prise pour une fonction de la version testée.
2. La spécialisation du décodage modifie une petite opération répétée
Pendant le préremplissage, un modèle traite un bloc d’entrée ; pendant le décodage, il traite à répétition une petite entrée pour produire le token suivant. L’article relie F.linear aux noyaux matrice-vecteur existants et à la fusion des additions de biais compatibles. Sur 96 formes de couches BF16, il rapporte une accélération de moyenne géométrique de 1.23 fois. Les petites projections gagnent le plus, tandis que les grandes couches déjà proches de la limite de bande passante restent près d’une fois. C’est un ensemble de mesures par couche, pas une moyenne du modèle entier.
Pour les mélanges d’experts, la multiplication matricielle groupée native lit les décalages de groupe sur le GPU au lieu de les copier sur le CPU puis de parcourir les groupes. Le graphique de spécialisation du décodage utilise un M3 Ultra avec torch.compile : Qwen3.6-35B-A3B passe de 38.7 à 51.7 tokens par seconde au contexte 512, et de 36.8 à 48.7 au contexte 2048. L’article rapporte séparément de plus grands écarts entre versions complètes par rapport à 2.14. Ces comparaisons, celle du noyau à environ 1.3 fois et les mesures ultérieures de 2.16 n’ont pas la même base ; il ne faut ni les combiner ni les multiplier.
3. Le stockage FP8 et le temps de softmax répondent à des questions différentes
L’ajout de FP8 prend la forme du support des tenseurs torch.float8_e4m3fn, avec un octet par valeur contre deux pour FP16 ou BF16. F.scaled_mm prend en charge la mise à l’échelle par tenseur et par ligne. Cela peut réduire le stockage des tenseurs compatibles, mais ne divise pas par deux la mémoire d’une application entière : les autres tenseurs, tampons de travail et allocations de l’environnement d’exécution demeurent. La quantification et le dtype de sortie de l’exemple comptent aussi pour le comportement numérique. L’article présente la multiplication matricielle FP8 native comme une base de futurs travaux sur les shaders Metal ; le stockage actuel ne doit donc pas être assimilé à une promesse générale d’accélération matérielle.
Le graphique de softmax relève d’une autre expérience. Pour une ligne de logits FP32 et un vocabulaire de 128,256 éléments, il indique 57.4 microsecondes sur MPSGraph et 7.1 sur le noyau Metal ; le texte arrondit à 57 et 7. Un softmax environ huit fois plus rapide peut raccourcir une étape de l’échantillonnage des tokens, mais les autres calculs déterminent toujours la durée totale de génération. Analyse d’AISubHub : mesurer le chemin complet autant que l’opération coûteuse et préserver les unités, afin que des microsecondes par appel ne deviennent pas une affirmation non étayée sur des secondes par réponse.
4. Le padding révèle la mémoire extérieure à l’allocateur de tenseurs
L’exemple Wan2.2 porte précisément sur Wan-AI/Wan2.2-TI2V-5B-Diffusers, avec 8,764 appels de padding constant lors d’un décodage VAE en 28 tuiles. Le passage du padding à Metal fait passer le pic total de mémoire du pilote rapporté de 270.135 à 8.108 GiB. Pourtant, le pic réservé par l’allocateur est de 8.070 GiB dans les deux configurations, et le pic d’allocation courante des tenseurs ne change que de 4.422 à 4.095 GiB. Une seule mesure de l’allocateur manquerait l’essentiel de ce problème particulier. Le résultat ne signifie pas que tous les modèles vidéo ne nécessitent désormais que huit GiB.
L’exactitude est un avantage distinct. Pour un aller-retour d’encodage et de décodage du VAE de Qwen-Image-2.1, les auteurs rapportent que l’accord avec la référence CPU passe de 10.06 à 29.95 dB de PSNR après la correction du padding. Cela concerne le flux de reconstruction testé, pas une note générale de qualité de génération d’images. Les autres changements cités comprennent l’algèbre linéaire complexe, les chemins de calcul arrière et le broadcasting de l’attention. Une vérification utile d’une mise à jour inclut donc les sorties numériques et le pic de mémoire du pilote en plus du débit, avec le même modèle et les mêmes formes d’opérations.
5. Garder visibles les travaux futurs et la validation locale
L’aperçu de 2.16 inclut des changements de soumission des tampons de commandes, l’attention entièrement exécutée sur Metal et d’autres migrations depuis MPSGraph. Les auteurs préviennent que certains travaux sont en revue. Leurs exemples futurs d’attention utilisent aussi un M5 Pro et des dimensions de tête précises, contrairement au graphique de décodage sur M3 Ultra. Ni ces chiffres ni la réduction de taille d’une bibliothèque fournie ne doivent être présentés comme un bénéfice mesuré de l’installation de la candidate 2.15 sur n’importe quel Mac.
Les flux MPS publics et le support de l’enregistrement des flux des tenseurs donnent davantage de contrôle d’ordonnancement aux appels Python, mais l’exemple synchronise toujours avant de lire le résultat. L’article énumère aussi les limites d’opérations restantes et les travaux visant à supprimer les ruptures du graphe de compilation. L’interprétation pratique d’AISubHub consiste à tester un environnement séparé avec les dtype, formes, synchronisation et tolérances de sortie réels de l’application. Nous avons lu l’article complet et ses trois graphiques ; nous n’avons ni installé PyTorch, ni exécuté ses exemples, ni inspecté les pull requests liés, ni reproduit les résultats de temps, de qualité ou de mémoire.
Pourquoi cela compte
Analyse d’AISubHub : les mises à jour du backend doivent être évaluées avec des relevés distincts du débit de décodage complet, des temps d’opérations, de l’exactitude des sorties et des pics de mémoire du pilote. On peut ainsi identifier le changement rapporté qui répond à un véritable goulet d’étranglement, sans généraliser un résultat de noyau à tous les modèles.
Limites et disponibilité
Toutes les mesures sont attribuées aux contributeurs PyTorch de Hugging Face et à leurs configurations déclarées. L’article décrit une version candidate 2.15 et distingue les travaux de 2.16 ; la disponibilité stable ultérieure n’a pas été vérifiée indépendamment. AISubHub n’a ni installé ni exécuté le logiciel, reproduit les benchmarks ou inspecté les implémentations liées. Aucune garantie universelle de vitesse, de capacité à tenir en mémoire ou de qualité numérique n’en découle.
Sources et preuves
Date de la source: · Source vérifiée:
Articles assistés par IA, vérifiés avec les sources primaires citées. Les affirmations des fournisseurs sont attribuées ; la présence ne vaut pas recommandation.