Mac peut-il installer CUDA : solutions GPU alternatives pour la recherche en 2026

À partir de CUDA 11.0, NVIDIA indique que macOS n’est plus une plateforme prise en charge pour développer ou exécuter des applications CUDA dans ses notes de version officielles (documentation CUDA 11.0). Le gagnant dépend donc du besoin : Linux avec un GPU NVIDIA pour l’entraînement CUDA, un Mac pour les tests macOS ou les calculs compatibles avec MPS, et un environnement double lorsque les deux contraintes sont réelles. Installer CUDA sur Mac n’est pas une solution viable sur Apple Silicon.

Cet article s’adresse aux doctorants qui tentent de migrer un projet CUDA vers un Mac Apple Silicon, aux chercheurs qui évaluent MPS ou Metal, ainsi qu’aux responsables techniques d’un laboratoire qui doivent maintenir un client macOS et une infrastructure Linux GPU.

Le verdict technique : Mac, MPS et CUDA ne désignent pas la même pile

Un Mac Apple Silicon possède un GPU intégré conçu pour l’écosystème Metal. CUDA, de son côté, est la plateforme de calcul de NVIDIA. L’installation d’un kit logiciel ne transforme donc pas le GPU Apple en GPU NVIDIA et ne fournit ni les bibliothèques CUDA, ni les noyaux compilés pour cette architecture.

La documentation Metal d’Apple décrit Metal comme une API de programmation graphique et de calcul pour les GPU Apple. Elle ne constitue pas une couche de compatibilité CUDA. La page Apple consacrée à PyTorch et au backend MPS présente une autre voie : certains frameworks peuvent déléguer leurs opérations au GPU Apple via MPS, lorsque leur version et leurs opérateurs le permettent.

La distinction est importante :

La compatibilité CUDA ne se déduit donc pas de la présence d’un terminal, de Homebrew ou d’un compilateur C++. Ces outils peuvent être utiles pour préparer le code, mais ils ne remplacent pas le matériel et les bibliothèques attendus par CUDA.

Première vérification : un Mac Apple Silicon peut-il exécuter un projet CUDA ?

La réponse est non pour une application CUDA actuelle destinée à fonctionner localement sur macOS. Le point de bascule officiel est CUDA 11.0 et les versions ultérieures, dont les notes de version retirent macOS des plateformes de développement et d’exécution prises en charge. La matrice de compatibilité CUDA de NVIDIA concerne les relations entre versions de CUDA, pilotes et GPU NVIDIA ; elle ne réintroduit pas le support macOS.

Avant toute migration, il faut déterminer ce que le projet appelle réellement « CUDA ». Un fichier de configuration contenant cuda ne suffit pas à conclure. L’audit doit rechercher au moins les éléments suivants :

• les appels explicites à torch.cuda, cupy, numba.cuda ou à une API équivalente ;
• les kernels écrits en CUDA C++ ou compilés avec nvcc ;
• les extensions natives qui incluent des en-têtes CUDA ;
• les bibliothèques binaires liées à cuBLAS, cuDNN, NCCL ou à une autre composante NVIDIA ;
• les scripts qui supposent la présence de nvidia-smi, d’un pilote NVIDIA ou d’une variable d’environnement CUDA ;
• les conteneurs, fichiers d’environnement et instructions de compilation qui imposent une image Linux GPU.

Une première recherche peut être menée dans le dépôt, sans installer de pilote :

rg -n "torch\.cuda|cuda|nvcc|cuDNN|cuBLAS|NCCL|nvidia-smi" .

La sortie suivante ne prouve pas encore que le projet est inexécutable sur Mac, mais elle signale les zones à examiner :

src/train.py:18: device = "cuda"
setup.py:42: extra_compile_args={"nvcc": ["-O3"]}
environment.yml:27: - cudatoolkit
scripts/check_gpu.sh:4: nvidia-smi

À ce stade, le laboratoire doit classer chaque occurrence : simple nom de variable, dépendance optionnelle, extension obligatoire ou étape indispensable du pipeline. Un projet peut afficher une référence CUDA dans un chemin facultatif tout en restant exécutable sur CPU ou MPS. L’inverse est également possible : un dépôt apparemment générique peut charger une extension native CUDA au démarrage.

Pourquoi les anciens guides CUDA pour Mac induisent-ils en erreur ?

Les tutoriels intitulés « CUDA sur Mac » que l’on trouve encore dans les résultats de recherche renvoient souvent à une combinaison historique : Mac Intel, GPU NVIDIA compatible et version ancienne de macOS. Le guide d’installation CUDA pour Mac archivé doit être lu comme un document historique, pas comme une procédure applicable à un Mac Apple Silicon actuel.

Plusieurs indices permettent d’identifier un guide obsolète :

Il faut éviter les pilotes trouvés sur des forums, les correctifs non vérifiés et les images virtuelles présentées comme des solutions universelles. Une machine virtuelle ne crée pas automatiquement un GPU NVIDIA compatible. Elle ajoute au contraire une couche de virtualisation, des problèmes de pilotes et une nouvelle variable dans la reproductibilité des expériences.

Le bon réflexe consiste à vérifier la date, le système visé, l’architecture processeur, le GPU attendu et le statut du document. Une page archivée peut servir à comprendre pourquoi certains collègues ont autrefois utilisé CUDA sur Mac ; elle ne permet pas d’affirmer qu’un Mac récent peut encore le faire.

Attention : la réussite de brew install, de l’installation de Python ou même de la compilation d’un binaire ne valide pas l’accès à CUDA. Seule l’exécution du chemin de calcul requis, avec ses bibliothèques et ses résultats de référence, peut confirmer la compatibilité.

Deuxième étape : distinguer une migration MPS d’une réécriture CUDA

Remplacer une chaîne comme cuda par mps peut constituer un test initial dans PyTorch, mais ce n’est pas une preuve de migration terminée. Un backend MPS doit disposer d’une implémentation pour les opérateurs utilisés, accepter les formes de tenseurs du projet et produire des résultats suffisamment proches pour le protocole scientifique.

Apple documente le backend MPS de PyTorch pour les Mac équipés d’un GPU Apple ; sa page de prise en main mentionne notamment macOS 12.3 ou une version ultérieure comme prérequis documenté (guide Apple pour PyTorch MPS). Ce type de version minimale doit être vérifié à nouveau lors de la publication, car le support dépend aussi de la version du framework.

Un diagnostic limité peut ressembler à ceci :

import torch

print("MPS disponible :", torch.backends.mps.is_available())

device = torch.device("mps" if torch.backends.mps.is_available() else "cpu")
print("Périphérique sélectionné :", device)

Exemple de sortie :

MPS disponible : True
Périphérique sélectionné : mps

Cette sortie confirme seulement que PyTorch détecte le backend. Elle ne confirme pas que le modèle complet, ses extensions et son pipeline de données fonctionnent.

Les problèmes de migration se répartissent en quatre familles :

• Opérateurs non couverts. Une opération peut être disponible sur CUDA mais absente ou différente sur MPS.
• Extensions personnalisées. Un module compilé avec nvcc ne devient pas une extension Metal par changement de chaîne de caractères.
• Écarts numériques. Les résultats peuvent varier à cause des types, de l’ordre des opérations, des noyaux utilisés ou de la gestion des valeurs limites.
• Outils de débogage. Les profilers et diagnostics conçus pour CUDA ne s’appliquent pas directement à Metal.

PyTorch documente une possibilité de repli vers le CPU avec la variable PYTORCH_ENABLE_MPS_FALLBACK=1 (variables d’environnement MPS) :

PYTORCH_ENABLE_MPS_FALLBACK=1 python train.py --config config.toml

Ce mécanisme peut aider à localiser un opérateur non pris en charge. Il peut aussi masquer une différence de chemin d’exécution. Le laboratoire doit donc enregistrer les opérations exécutées sur MPS et celles basculées sur CPU, plutôt que de considérer le lancement réussi comme une validation.

Metal peut être pertinent pour une application audio, vidéo ou de design qui doit exploiter le GPU Apple, notamment lors d’une validation de rendu, d’un traitement de signal ou d’une interface scientifique. Les outils Metal d’Apple et la documentation sur les calculs GPU avec Metal sont alors les références adaptées. Ils ne transforment toutefois pas un kernel CUDA existant en kernel Metal.

Quel environnement choisir selon la dépendance réelle ?

La décision ne doit pas commencer par le prix d’une machine, mais par la fonction qui doit être validée. Un Mac est pertinent si le projet doit tester une application macOS, une chaîne audio ou vidéo spécifique, une interface graphique, un comportement de fichiers ou un backend MPS. Linux avec GPU NVIDIA reste nécessaire si la recherche dépend de kernels CUDA, de bibliothèques NVIDIA ou d’un entraînement déjà calibré sur cette pile.

La documentation officielle d’installation CUDA sous Linux rappelle que l’environnement Linux doit être évalué avec son GPU, son pilote et ses composants logiciels associés. Il faut donc demander au responsable de l’infrastructure quelles versions sont réellement disponibles, au lieu de copier une commande issue d’un autre cluster.

Dans un environnement double, le Mac peut servir à éditer le code, lancer des tests d’interface, examiner les résultats, vérifier une distribution macOS ou exécuter un petit cas MPS. Le calcul CUDA demeure sur Linux. Git, un fichier d’environnement verrouillé, des jeux de données versionnés et un format de sortie commun réduisent les écarts entre les deux systèmes.

Pour les équipes qui veulent valider une application macOS sans acheter immédiatement une machine, une solution de Mac distant pour les tests peut être comparée à l’accès déjà disponible au cluster Linux. Les détails de coût et de durée doivent être vérifiés sur la page de tarifs de location Mac, sans confondre cette location avec un accès à un GPU NVIDIA CUDA.

Troisième étape : établir une preuve de migration reproductible

Une migration acceptable doit produire une preuve, pas seulement une capture d’écran montrant que le programme démarre. La procédure suivante permet de séparer les erreurs d’installation, les incompatibilités d’opérateurs et les divergences scientifiques.

1. Définir le périmètre. Sélectionnez une tâche minimale représentative : une inférence, une itération d’entraînement, un traitement audio ou une étape de prétraitement. Écartez d’abord les fonctions périphériques.

2. Verrouiller les dépendances. Conservez le fichier d’environnement, les versions de Python, du framework, des bibliothèques natives et des outils de compilation. Ne remplacez pas automatiquement une dépendance CUDA par un paquet portant un nom similaire.

3. Fixer les données de référence. Utilisez le même extrait de données, le même format d’entrée, la même graine aléatoire et les mêmes paramètres. Un résultat obtenu sur un autre échantillon ne permet pas une comparaison sérieuse.

4. Exécuter le chemin CUDA de référence. Enregistrez les sorties, les erreurs, les types numériques et les métadonnées de l’environnement Linux GPU. Les résultats de référence doivent être conservés avec le code correspondant.

5. Tester le chemin MPS ou CPU. Exécutez exactement la même tâche sur le Mac. Notez les opérateurs non pris en charge, les replis CPU et les différences de précision. Le mécanisme de repli MPS doit être activé seulement pour diagnostiquer, puis testé séparément.

6. Comparer les sorties. Définissez avant le test une tolérance acceptable pour le domaine scientifique : écart sur une métrique, différence maximale sur un tenseur ou conservation d’un classement. Cette tolérance appartient au protocole du projet, pas à une règle générale de CUDA ou de Metal.

7. Tester les artefacts finaux. Vérifiez les fichiers produits, les chemins, les encodages, les visualisations, les journaux et, pour l’audio ou la vidéo, la lecture et l’export. Un modèle numériquement correct peut encore produire un livrable inutilisable sur macOS.

8. Décider avec un critère d’arrêt. Si une extension indispensable reste CUDA-only, le calcul doit revenir sur Linux. Si le sous-ensemble MPS respecte les critères du projet et que la validation macOS est nécessaire, le Mac peut rester dans le flux de travail. Si aucun test macOS n’est requis, louer ou acheter un Mac n’apporte pas de solution au besoin CUDA.

Le tableau suivant peut servir de fiche de décision lors d’une réunion de laboratoire :

Cette méthode répond aussi au cas d’un chercheur qui doit simultanément maintenir macOS et NVIDIA GPU : les deux environnements ne sont pas fusionnés artificiellement. Ils sont reliés par des interfaces explicites. Le code partagé reste portable, tandis que les composants propres à CUDA, MPS ou Metal sont testés comme des implémentations distinctes.

Ce que la location d’un Mac résout — et ce qu’elle ne résout pas

Un Mac distant ne doit pas être présenté comme une alternative à un serveur Linux CUDA. Pour un projet dont le seul objectif est l’entraînement CUDA, la bonne décision est de conserver l’accès à une infrastructure Linux avec GPU NVIDIA. Louer un Mac dans ce but ajouterait un poste macOS sans fournir la capacité de calcul recherchée.

La situation change si le laboratoire doit aussi tester une application macOS, vérifier une interface, exécuter un outil scientifique disponible uniquement sur macOS, examiner un rendu audio ou vidéo, ou confirmer le comportement d’un client Apple Silicon. Dans ce cas, un Mac temporaire peut éviter l’achat prématuré d’un poste qui resterait inutilisé entre deux campagnes de validation. SFTPMAC fournit un accès distant à un Mac réel via les méthodes prévues par son service ; les conditions de disponibilité et de livraison doivent être confirmées avant la réservation.

Le choix de la location d’un Mac pour un laboratoire est donc cohérent lorsque la contrainte macOS est ponctuelle ou complémentaire. Il ne remplace ni un GPU NVIDIA, ni un cluster Linux, ni une extension CUDA obligatoire. Le bon usage consiste à réserver le Mac aux tâches macOS et MPS, puis à conserver le calcul CUDA sur la plateforme qui le prend officiellement en charge.

Pour un projet de recherche, cette séparation coûte souvent moins cher en temps d’analyse qu’une tentative de contournement : les anciens pilotes, les machines virtuelles non reproductibles et les correctifs non documentés peuvent créer des erreurs difficiles à distinguer d’un problème scientifique. Un environnement double, testé avec des données identiques et des critères d’acceptation écrits, donne une décision défendable devant une équipe, un encadrant ou un comité de reproductibilité.