1. Problemanalyse
Rosetta-x86-Python deaktiviert MPS oft still. Kleine Batches sättigen Metal nicht; große Batches sprengen den einheitlichen Speicher. Numerik weicht von CUDA-Reduktionen ab. Notebooks brauchen torch.mps.empty_cache() nach Epochen. Für produktive SLAs sollten reproduzierbare Lockfiles und nachvollziehbare Messreihen vorliegen (Datenschutz: keine Nutzerdaten in öffentlichen Logs).
2. Entscheidungsmatrix
| Achse | CPU | MPS | MLX | Remote |
|---|---|---|---|---|
| Stärke | Compat | torch-Ökosystem | Apple-Pfad | Isolation |
| Risiko | Deckel | Ops/Numerik | Doppelstack | Betrieb |
3. Fünf Schritte
- arm64-Interpreter und Torch-Build fixieren.
- MPS-Gates und Dummy-Matmul loggen.
- Batch-Sweep mit Durchsatz und Speicherpegel.
- Nach jeder Epoche gc und empty_cache.
- Beschleunigung vs CPU prüfen; Hotspots dokumentieren und zu MLX/Remote splitten.
4. Schwellen (ersetzen durch Messung)
- Weniger als 22% Step-Gewinn bei unter 18% GPU-Zeit: Datenpfad prüfen.
- Mehr als 26% Speicheranstieg über zehn Epochen: Referenzen und Remote-Host.
- Bitweise CUDA-Loss: Training verschieben oder MPS auf Vorverarbeitung begrenzen.
5. Symptomtabelle
| Symptom | Hypothese | Gegenmaßnahme |
|---|---|---|
| Schnell dann langsam | Cache | Batch, Flush |
| Eine Schicht langsam | Kernlücke | Profiler |
6. MLX oder Remote
LLM-lastig: zuerst Ollama+MLX-Artikel. Laptop teilt Speicher mit Videokonferenz: Remote-Knoten laut SSH/VNC-Leitfaden. Operatoren nicht in zwei Wochen schließbar: Architektur splitten.
7. FAQ
MPS vs MLX modellabhängig. Stable Torch für SLA. Docker-MPS: Colima-Artikel lesen.
8. Tiefe Analyse
MPS ist eine Kompatibilitätssteuer auf Metal, keine CUDA-Garantie. Dokumentieren Sie Torch-Version, Commit, Batch, Peak-Speicher, Fallback-Flags. Engine-Vergleich definiert Verträge; Docker-Artikel isoliert Virtualisierungsverlust. Remote-Mac-Miete reduziert Notebook-als-Server-Nachteile.
9. Observability
| Signal | Zuerst | Milderung |
|---|---|---|
| Beschleunigung ~1x | Device/Sync | Profiler |
| OOM | Dynamischer Graph | empty_cache |
10. Abschluss
Laptops für Exploration, geteilte Knoten für Zusagen. MACGPU bietet öffentliche Tarife ohne Login-Zwang. Vor externen Latenz-SLAs arm64-Nachweis und Kurven beilegen.
11. DataLoader, Synchronisation und Täuschung durch GPU-Leerlauf
Wenn die GPU-Zeile im Monitor klein wirkt, ist das nicht automatisch ein Beleg dafür, dass MPS „aus“ ist. Häufig blockiert der CPU-Pfad: Dekodierung, Farbraumkonvertierung, schwere Augmentationen oder ein Trainingsloop, der jeden Schritt mit loss.item() synchronisiert. Profilieren Sie deshalb bewusst kurze Fenster nach Warm-up und trennen Sie eine reine Datenpipeline-Messung von einer reinen Forward-Messung. Beim Hochdrehen von num_workers zahlen Sie mit zusätzlichem Resident Set auf demselben unified-memory-Budget; auf 16 GB kann mehr Parallelität schaden als nutzen. Schreiben Sie Workerzahl, Batch und p95 in eine Zeile, damit Reviewer den Kontext sehen.
pin_memory-Empfehlungen aus CUDA-Datencentern sind Hypothesen. Messen Sie mit dem Profiler, ob doppelte Host-zu-Device-Kopien entstehen, statt Konfigurationen zu übernehmen, die für Linux-Server geschrieben wurden. Wenn Sie später auf einen Remote-Mac-Pool wechseln, übernehmen Sie dieselbe Cache-Verzeichnisstruktur; sonst erklären Sie Durchsatzunterschiede fälschlich mit „besserer GPU“.
12. Profiler lesen, ohne Rätselraten
Nehmen Sie fünfzig Schritte, exportieren Sie CPU- und MPS-Aktivitäten und achten Sie auf Warteschlangen: kleine Kernel-Selbstzeiten bei großen Warteanteilen deuten auf Synchronisation oder Fallback hin. Für Vision-Pipelines führen Sie eine zweite Aufnahme nur für Resize, Normalize und Collate aus, damit Speicherlatenz nicht fälschlich der Faltungsmathematik angelastet wird. Bei Multiprocessing dokumentieren Sie Seeds und worker_init_fn im README, sonst wiederholen Sie endlos Debatten über nicht reproduzierbare Kurven.
13. Numerik, Auftragsverarbeitung und klare Toleranzen
Bitweise identische Loss-Kurven zwischen CUDA-Clustern und Mac-Laptops sind selten ein sinnvolles Gate. Definieren Sie stattdessen produktrelevante Validierungsmetriken mit Toleranzbändern und halten Sie dtype-Regeln für Gewichte, Normschichten und Reduktionen tabellarisch fest. Wo strenge Reproduzierbarkeit rechtlich oder wissenschaftlich nötig ist, bleiben Sie auf einer Plattform oder führen Sie eine formal abgenommene Differenztabelle. Das reduziert Reibung zwischen Forschung und Plattformteam und schützt gleichzeitig nachvollziehbare Dokumentationspfade im Sinne sauberer Verarbeitungsprotokolle.
14. Mikro-Szenario: ViT-tiny auf einem 16 GB MacBook Air
Ein Batch, der auf A100 funktionierte, kann auf einem schlanken Notebook sofort in Swap rutschen. Sweepen Sie batch in kleinen Schritten und notieren Sie immer Paare aus Peak-Speicher und Durchsatz. Wiederholen Sie dasselbe Protokoll auf einem 64 GB Remote-Knoten; wenn der Sweet spot wandert, erklären Sie das mit I/O-Pfad und thermischem Budget, nicht mit Marketingvokabular.
15. Multiprocessing und Dateideskriptoren unter macOS
Fork-Annahmen aus Linux-Playbooks passen nicht eins zu eins. Bei sporadischen Deadlocks reduzieren Sie auf einen Loader-Prozess, reproduzieren, führen Worker schrittweise wieder ein. Kombinieren Sie das mit dem internen Artikel zu Konkurrenz auf unified memory, wenn parallel ein anderer Inferenzdienst läuft.
16. Checkpointing, AMP und Gradientenakkumulation
MPS-AMP entspricht nicht jeder CUDA-Semantik. Bei Akkumulation über Mikro-Batches prüfen Sie Skalierung und Optimizer-Schritte erneut. Mit aktiviertem Gradient Checkpointing ändert sich das Profil; erwähnen Sie das neben jedem veröffentlichten Throughput-Wert.
17. Felder im Laborbuch, die Auditoren lieben
Checksum des Datenshards, Liste geschlossener Hintergrundapps, Netzteilstatus, Low-Power-Modus, Mount-Typ des Caches, nach Remote-Migration die RTT zum Artefakt-Speicher. Das klingt pedantisch, bis ein zwölfprozentiger Rückgang als thermisches Drosseln auf Batteriebetrieb entlarvt wird. Wer diese Felder pflegt, verkürzt Postmortems und vermeidet wiederholte Profiler-Feldzüge.