Avant de comparer les puces, classez votre travail dans l’un des scénarios suivants.

PyTorch fournit bien un périphérique mps qui exploite Metal Performance Shaders sur macOS. La documentation précise toutefois que le comportement dépend de la version de macOS, de la machine compatible et des opérateurs utilisés. Le fait que l’installation de PyTorch réussisse ne prouve donc pas que votre modèle complet fonctionnera sans modification. (docs.pytorch.org)

Pour un projet de bio-informatique, d’analyse audio, de traitement vidéo ou de vision scientifique, la question n’est pas « quelle puce est la plus rapide ? ». Elle est plutôt : le chemin d’exécution utilisé par votre expérience existe-t-il sur la cible choisie, avec les mêmes entrées et les mêmes sorties ?

Première étape : distinguer l’API PyTorch des dépendances du dépôt

Un script qui utilise uniquement des modules standards comme torch, torch.nn, torch.optim et des opérations courantes peut être relativement simple à porter. En revanche, un dépôt de recherche peut appeler indirectement :

• une extension compilée avec nvcc ;
• une bibliothèque liée à cuBLAS, cuDNN ou une autre composante NVIDIA ;
• un opérateur personnalisé écrit en C++ ou CUDA ;
• un module qui suppose l’existence de torch.cuda ;
• un système de lancement multi-GPU ;
• un noyau optimisé qui n’a pas de chemin MPS.

CUDA n’est pas seulement un nom de périphérique. Il s’agit d’une plateforme comprenant des bibliothèques, un compilateur, des outils de débogage et des mécanismes de déploiement pour GPU NVIDIA. La documentation NVIDIA décrit également les usages multi-GPU et HPC de cet écosystème. Remplacer une chaîne de caractères dans un fichier de configuration ne recrée pas ces composants sur macOS. (docs.nvidia.com)

Deuxième étape : rechercher les indices de dépendance CUDA

Dans le dépôt du laboratoire, examinez les fichiers suivants :

1. requirements.txt, environment.yml ou pyproject.toml ;
2. les scripts d’installation contenant cuda, cudnn, nvcc ou torch.utils.cpp_extension ;
3. les imports comme flash_attn, xformers, apex ou un module local compilé ;
4. les arguments --local_rank, --nproc_per_node et les appels à torch.distributed ;
5. les journaux d’exécution mentionnant libcuda, cuDNN, CUDA out of memory ou un noyau propriétaire.

Ces éléments ne prouvent pas tous qu’un portage est impossible, mais ils indiquent que le projet doit être audité avant toute décision. Le modèle peut être compatible avec MPS tandis qu’un seul composant périphérique bloque l’exécution.

Troisième étape : accepter le repli CPU comme un échec de validation

PyTorch documente la variable PYTORCH_ENABLE_MPS_FALLBACK, qui permet de revenir au CPU lorsque certaines opérations ne sont pas prises en charge par MPS. Cette option est utile pour diagnostiquer un modèle, mais elle peut aussi masquer le fait qu’une partie du calcul ne s’exécute plus sur le GPU. (docs.pytorch.org)

Pour une validation scientifique, vous devez donc consigner :

• les opérations exécutées sur MPS ;
• les opérations revenues sur CPU ;
• les changements de précision éventuels ;
• les différences numériques sur un même échantillon ;
• le temps d’attente acceptable pour l’expérience.

Un script qui « termine » grâce au repli CPU n’est pas nécessairement un environnement de calcul adapté à votre étude.

Point de vigilance : ne concluez pas qu’un modèle est compatible MPS après un seul passage réussi. Utilisez une entrée représentative, une sauvegarde de poids réelle et le même traitement de données que dans le protocole scientifique.

Imaginez un doctorant qui développe un outil d’analyse audio pour classer des signaux expérimentaux. L’entraînement principal reste sur le serveur Linux du laboratoire, mais l’application doit être installée et testée sur macOS pour une équipe partenaire. Dans ce cas, Apple Silicon n’a pas besoin de remplacer le serveur de calcul. Il sert à vérifier :

• l’installation de Python et des paquets ;
• le chargement du modèle ;
• l’exécution d’un fichier audio réel ;
• l’export des prédictions ;
• l’affichage d’un résultat dans une interface macOS ;
• la reprise après fermeture et redémarrage.

Le même raisonnement s’applique à un programme de traitement vidéo, à un outil de design scientifique ou à un logiciel pédagogique distribué aux étudiants. Linux peut prouver que l’algorithme fonctionne. Il ne prouve pas que le paquet macOS, ses bibliothèques et son parcours utilisateur sont corrects.

Une validation MPS doit porter sur le parcours complet

Utilisez cette séquence plutôt qu’un test de performance isolé :

1. créer un environnement Python propre ;
2. installer PyTorch depuis la source officielle ;
3. vérifier que torch.backends.mps.is_available() renvoie une valeur exploitable ;
4. charger le modèle et un petit jeu de données représentatif ;
5. exécuter une inférence ou quelques itérations d’entraînement ;
6. comparer les sorties avec celles obtenues sur Linux ;
7. exporter les résultats dans le format prévu par le projet ;
8. fermer puis relancer l’environnement ;
9. conserver les journaux et les versions utilisées.

Apple recommande une vérification explicite de la disponibilité de MPS et fournit un exemple de création de tenseur sur le périphérique mps. La page précise également que les outils de ligne de commande Xcode sont nécessaires pour la procédure présentée. (developer.apple.com)

Cette méthode est plus informative qu’un classement général entre GPU. Elle vous indique si le problème réel se situe dans le modèle, l’opérateur, la mémoire, le paquet Python ou l’interface macOS.

Si votre groupe entraîne déjà des modèles sur un cluster Linux, la migration vers Apple Silicon doit être justifiée par un besoin macOS précis. CUDA reste le choix rationnel lorsque :

• le dépôt dépend d’extensions compilées pour NVIDIA ;
• l’entraînement utilise plusieurs GPU ;
• la reproductibilité dépend d’un environnement CUDA documenté ;
• les bibliothèques du laboratoire sont provisionnées sur Linux ;
• la durée d’entraînement rend tout essai exploratoire coûteux ;
• les expériences doivent être relancées automatiquement sur un ordonnanceur HPC.

La documentation PyTorch expose des mécanismes et des concepts spécifiques à torch.cuda, notamment la sélection de périphérique, les flux d’exécution et les graphes CUDA. Ces éléments ne sont pas interchangeables avec MPS par simple substitution syntaxique. (docs.pytorch.org)

Le risque principal n’est pas seulement une erreur au démarrage. Vous pouvez aussi rencontrer :

• une opération non prise en charge au milieu d’une époque ;
• une consommation mémoire différente de celle observée sur Linux ;
• une sortie numérique légèrement différente ;
• un ralentissement provoqué par des transferts CPU ;
• une extension impossible à compiler ;
• une expérience difficile à reproduire par les autres membres du groupe.

Dans ce contexte, la meilleure décision est souvent de conserver Linux GPU pour l’entraînement et d’ajouter Apple Silicon uniquement pour la validation macOS.

Une location de Mac distant peut servir de banc d’essai, mais elle ne doit pas être utilisée comme une promesse de performance universelle. Le test doit répondre à une question concrète : « mon expérience minimale fonctionne-t-elle sur cette cible ? »

Cinquième étape : préparer un protocole de test limité

Préparez un dossier contenant :

• le fichier d’environnement ;
• le commit exact du code ;
• un modèle ou un poids de test ;
• quelques données non sensibles ;
• la commande de lancement ;
• les sorties attendues ;
• un script de comparaison numérique ;
• une procédure de nettoyage.

Évitez de transférer des données confidentielles ou soumises à des règles institutionnelles sans validation préalable. Vérifiez aussi les droits d’accès, la conservation des fichiers, les méthodes de transfert et la possibilité de supprimer les résultats à la fin de l’essai.

Sixième étape : contrôler les échecs plutôt que forcer la réussite

L’essai doit être arrêté ou réorienté si :

• une extension essentielle dépend de CUDA ;
• le modèle revient fréquemment sur CPU ;
• la mémoire disponible ne permet pas de charger le cas représentatif ;
• les résultats divergent au-delà de la tolérance définie par le protocole ;
• la session distante ne permet pas de conserver le processus attendu ;
• le transfert des données devient incompatible avec la politique du laboratoire.

À l’inverse, poursuivez vers une location plus longue si le modèle charge correctement, si le résultat est cohérent, si l’environnement se recrée et si la validation macOS constitue une étape obligatoire du projet.

Le double environnement est souvent la solution la plus réaliste pour une équipe universitaire. Il sépare deux objectifs qui sont fréquemment confondus :

• Linux GPU pour l’entraînement, les extensions CUDA et les campagnes longues ;
• Apple Silicon pour la validation macOS, MPS, l’inférence locale et les tests d’application.

Les variables de gestion mémoire MPS montrent d’ailleurs que la mémoire n’est pas un détail secondaire. PyTorch documente notamment un plafond haut par défaut de 1,7, un seuil bas de 1,4 pour la mémoire unifiée et un seuil bas de 1,0 pour certains systèmes à mémoire discrète. Ces paramètres ne donnent pas la mémoire réellement disponible pour votre modèle, mais ils montrent pourquoi un modèle qui passe sur une machine peut échouer sur une autre configuration. (docs.pytorch.org)

Pour choisir une durée de location, ne partez pas du nom de la puce. Prenez un seul cas réel : le dépôt utilisé par votre équipe, un modèle représentatif et une sortie attendue. Une période courte suffit pour vérifier l’installation et l’inférence. Une période plus longue ne se justifie que si vous devez observer plusieurs relances, une intégration logicielle ou un cycle expérimental complet.

Les solutions Mac distant pour les tests scientifiques peuvent compléter un laboratoire qui ne possède aucun matériel macOS. Si votre décision se rapproche finalement d’un achat ou d’un accès régulier à une machine dédiée, comparez aussi les contraintes de commande d’un Mac mini M4 avec la souplesse d’une location temporaire.

Un laboratoire uniquement équipé de Linux ou de Windows conserve un avantage évident pour CUDA, les clusters et les entraînements lourds. Mais cette organisation laisse souvent trois angles morts : aucune validation macOS avant la livraison, un accès difficile aux outils Apple pour les étudiants et une dépendance à la disponibilité du matériel interne. Acheter un Mac pour un besoin ponctuel immobilise aussi un budget et ne garantit pas que le modèle PyTorch sera compatible MPS.

Dans ce cas précis, louer un Mac via KVMNODE peut être plus pertinent qu’un achat immédiat : vous testez d’abord votre véritable dépôt, vous complétez l’environnement Linux existant et vous arrêtez la dépense si l’essai révèle une dépendance CUDA bloquante. Si le projet exige au contraire un entraînement continu, plusieurs GPU ou des interfaces physiques locales, conservez le cluster Linux ou investissez dans le matériel correspondant plutôt que de louer un Mac pour le mauvais usage.

Commencez donc par une validation MPS ciblée, avec vos dépendances et vos données de test. Si elle réussit, choisissez la durée de location adaptée à votre calendrier scientifique ; si elle échoue sur CUDA ou sur une extension native, gardez Linux GPU comme environnement principal et utilisez Apple Silicon uniquement lorsque la validation macOS est réellement requise.