1. Analyse des freins
Python x86 sous Rosetta désactive souvent MPS. Petits batches sous-utilisent Metal ; grands batches saturent la mémoire unifiée. La numération diffère des réductions CUDA. Les notebooks exigent torch.mps.empty_cache() à chaque frontière d’époque pour stabiliser les courbes.
2. Matrice de décision
| Axe | CPU | MPS | MLX | Distant |
|---|---|---|---|---|
| Forces | Compat | actifs torch | chemin Apple | isolation SLO |
| Risques | plafond | opérateurs | double stack | exploitation |
3. Cinq étapes
- Figez l’interpréteur arm64 et la build torch.
- Journalisez is_built, is_available, matmul témoin.
- Balayez les batchs, enregistrez débit et pic mémoire.
- Après chaque époque : gc et empty_cache.
- Comparez l’accélération vs CPU ; documentez les hotspots puis bifurquez.
4. Seuils (à remplacer par mesures)
- Moins de 22 % de gain sur le pas de temps et GPU < 18 % : inspectez le pipeline de données.
- > 26 % de mémoire après dix époques : fuite probable, envisagez un hôte distant dédié.
- Alignement bitwise avec CUDA : déplacez l’entraînement ou limitez MPS au prétraitement.
5. Table symptômes
| Symptôme | Hypothèse | Action |
|---|---|---|
| Rapide puis lent | cache | batch, flush |
| Une couche lente | trou de noyau | profiler |
6. Quand MLX ou pool distant
Si l’inférence LLM domine, lisez d’abord Ollama+MLX. Si la mémoire unifiée sert simultanément visioconférence et IDE, migrez vers un Mac distant selon le guide SSH/VNC. Si les opérateurs ne convergent pas en deux semaines, acceptez une architecture scindée.
7. FAQ
MPS vs MLX dépend du modèle. Pour des SLA, figez torch stable. Docker+MPS : lisez Colima pour le coût VM.
8. Analyse créative / industrielle
MPS est un pont créatif entre recherche PyTorch et Metal, mais pas un clone CUDA. Apple Silicon excelle quand mémoire unifière et outils graphiques convergent ; documentez version torch, commit, batch, pic mémoire, drapeaux fallback. L’article moteurs définit le contrat ; l’article Docker isole la perte de visibilité GPU. Louer un Mac distant évite de transformer chaque portable en serveur nocturne.
9. Observabilité
| Signal | D’abord | Atténuation |
|---|---|---|
| Accélération ~1x | device/sync | profiler |
| OOM | graphe dynamique | empty_cache |
10. Clôture
Le portable explore ; le nœud partagé promet. MACGPU expose des offres publiques sans login pour essayer un Mac Apple Silicon distant. Avant tout SLA externe, joignez preuve arm64 et courbes.
11. Chaîne de données et illusions d’inactivité GPU
Dans les ateliers créatifs, la timeline GPU semble souvent « froide » alors que le CPU décode, recadre, applique des LUT agressives ou synchronise des logs pas à pas. Ce n’est pas une preuve que MPS est absent : c’est une invitation à profiler une fenêtre courte après warm-up, puis à isoler une capture « données seules ». Monter num_workers augmente la mémoire résidente de chaque worker sur une puce à mémoire unifiée ; sur 16 Go, quatre workers affamés plus trente onglets navigateur peuvent effacer le gain attendu. Notez batch, workers et p95 sur la même ligne de cahier.
Le drapeau pin_memory hérité des guides CUDA n’est pas une évidence sur macOS : laissez le profiler révéler des copies host-device superflues plutôt que de copier une recette pensée pour un rack Linux.
12. Lire torch.profiler avec exigence narrative
Choisissez cinquante pas stables, enregistrez CPU et MPS, distinguez temps propre et attentes. Pour la vision, une seconde capture sur resize/normalize/collate évite d’attribuer à Metal des saccades venues du stockage. Si vous multipliez les processus DataLoader, figez les graines et worker_init_fn dans le README : sinon, la courbe « irréproducible » devient un folklore d’équipe.
13. Parité numérique et langage produit
Exiger une égalité bit à bit des losses entre cluster CUDA et portable MPS est rarement un critère utile. Définissez des métriques de validation (mAP, top-1) avec bandes de tolérance et consignez les politiques de dtype pour poids, normalisation et réductions. Là où la reproductibilité stricte est indispensable, restez sur une seule plateforme ou publiez un tableau d’écarts validé.
14. Scénario concret : ViT-tiny sur MacBook 16 Go
Le batch qui roulait sur A100 peut provoquer du swap immédiat ici. Balayez par paliers, notez couples pic mémoire / débit, puis rejouez le même protocole sur un nœud distant 64 Go. Si le sweet spot se déplace, expliquez-le par chemin I/O et marge thermique, pas par slogan marketing.
15. Multiprocessing et descripteurs de fichiers
macOS n’hérite pas des mêmes hypothèses de fork que Linux. En cas de deadlock intermittent, repassez à un seul processus de chargement, reproduisez, réintroduisez les workers un par un. Croisez avec l’article sur la concurrence mémoire unifiée lorsque d’autres services d’inférence tournent localement.
16. Points de contrôle, AMP et accumulation
L’AMP MPS ne mime pas CUDA mot pour mot. Avec accumulation micro-batch, revérifiez scaling et pas d’optimiseur. Le checkpointing de gradients change le profil : citez la stratégie à côté de chaque chiffre de throughput publié.
17. Carnet de bord : détails ingrats qui sauvent des semaines
Checksum du shard, applications fermées, adaptateur secteur, mode basse consommation, type de montage du cache, RTT vers le dépôt d’artefacts après migration. Ces lignes paraissent triviales jusqu’à ce qu’une régression de douze pour cent s’avère être un throttling thermique sur batterie. Les équipes qui les remplissent ferment leurs post-mortems plus vite.