Fehlerbild: torch.backends.mps.is_available() meldet False, ein Modell lässt sich nicht auf MPS verschieben oder ein Operator bricht ab.

Schnellster Weg: Prüfen Sie zuerst Build und Laufzeit getrennt, dann den tatsächlich aktiven Python-Interpreter und die konkrete Fehlermeldung. Ordnen Sie den Fehler anschließend Gerätewechsel, Operator oder Datentyp zu. Ein aktivierter CPU-Fallback beweist keine GPU-Beschleunigung.

Sofort: Erfassen Sie die Umgebung und den Fehler, bevor Sie Pakete ändern. Als Nächstes: Testen Sie einen kleinen, repräsentativen Ausschnitt Ihrer Forschungspipeline. Die Veröffentlichung von PyTorch 2.14 nennt Verbesserungen für Apple Silicon; sie garantiert aber weder die Unterstützung jedes Operators noch die Eignung Ihres Projekts für MPS (PyTorch-2.14-Veröffentlichung).

Dieser Leitfaden richtet sich an Studierende, Promovierende, Forschende und Hochschul-Supportteams, die PyTorch auf einem Apple-Silicon-Mac einsetzen. Wenn MPS gebaut erscheint, aber nicht verfügbar ist, hilft die folgende Reihenfolge dabei, Umgebungsfehler von Einschränkungen des Modells zu trennen.

PyTorch 2.14 MPS nicht verfügbar: Build und Laufzeit sind verschiedene Prüfungen

torch.backends.mps.is_built() und torch.backends.mps.is_available() beantworten unterschiedliche Fragen. Die erste Prüfung gibt Auskunft darüber, ob der verwendete PyTorch-Build MPS-Unterstützung enthält. Die zweite prüft, ob MPS in der aktuellen Umgebung tatsächlich verfügbar ist. Ein positives Build-Ergebnis allein belegt also nicht, dass Ihr Programm MPS auf diesem Rechner nutzen kann. Die Unterscheidung ist in der PyTorch-Dokumentation zum MPS-Backend beschrieben.

Prüfen Sie beide Werte in genau dem Prozess, in dem später auch Ihr Forschungsprogramm läuft. Ein Test im Terminal ist nicht automatisch repräsentativ, wenn Ihre IDE, Ihr Notebook-Kernel oder ein Skript einen anderen Interpreter startet.

import platform
import sys
import torch

print("Python:", sys.executable)
print("Plattform:", platform.platform())
print("PyTorch:", torch.__version__)
print("MPS gebaut:", torch.backends.mps.is_built())
print("MPS verfügbar:", torch.backends.mps.is_available())

Sichern Sie die Ausgabe zusammen mit der Fehlermeldung. So können Sie später nachvollziehen, ob sich die Umgebung verändert hat, statt sich auf die Erinnerung an ein Terminalfenster zu verlassen.

Eine Rückgabe von False bei is_available() ist noch keine Diagnose. Prüfen Sie, ob das ausgeführte Programm tatsächlich dieselbe Installation verwendet, die Sie kontrolliert haben. Vergleichen Sie den Interpreterpfad aus sys.executable mit dem Interpreter, den Ihre Entwicklungsumgebung oder Ihr Notebook nutzt. Kontrollieren Sie außerdem, ob Sie gerade in einer anderen Shell, einem Container oder einer entfernten Sitzung arbeiten. Diese Unterschiede können erklären, warum derselbe Prüfbefehl an einem Ort ein anderes Ergebnis liefert als an einem anderen.

Importfehler oder wechselnde Ergebnisse: erst die Umgebung, dann die Installation

Wenn import torch scheitert, ist das ein anderes Fehlerbild als ein erfolgreicher Import mit nicht verfügbarem MPS. Ein Importfehler verweist zunächst auf Python, Paketinstallation oder Abhängigkeiten. Ein erfolgreich importiertes PyTorch ohne verfügbares MPS verlangt dagegen eine Prüfung des Builds und der Laufzeitbedingungen.

Gehen Sie vor einer Neuinstallation die tatsächliche Umgebung durch:

  1. Führen Sie den Prüfcode im selben Terminal, Notebook-Kernel oder Programm aus, in dem der Fehler auftritt.
  2. Notieren Sie den Python-Pfad, die angezeigte PyTorch-Version und die beiden MPS-Statuswerte.
  3. Prüfen Sie mit dem Paketmanager Ihrer Umgebung, welches PyTorch-Paket in genau diesem Interpreter installiert ist.
  4. Vergleichen Sie diese Angaben mit der Umgebung, in der der Fehler nicht auftritt.
  5. Erst wenn der Unterschied klar ist, entscheiden Sie, ob Sie die Umgebung korrigieren oder PyTorch neu installieren.

Verwenden Sie für eine Neuinstallation die aktuelle Auswahlhilfe für die offizielle PyTorch-Installation. Sie sollten keine Installationszeile aus einem älteren Beitrag übernehmen, ohne zu prüfen, ob sie zu Ihrem Betriebssystem, Ihrer Python-Umgebung und dem gewünschten PyTorch-Build passt. Ein Upgrade auf eine neue Version ist kein Ersatz für eine Diagnose: Ändern Sie möglichst nicht mehrere Komponenten zugleich, wenn Sie die Ursache eines Fehlers finden müssen.

Wenn der Import in einem Terminal funktioniert, aber ein Notebook MPS nicht erkennt, kontrollieren Sie zuerst den Notebook-Kernel. Installieren Sie nicht vorsorglich ein weiteres Paket in eine beliebige Umgebung: Ein erfolgreicher Installationsbefehl sagt noch nicht, dass Ihr Projekt anschließend genau dieses Paket lädt.

Gerätemigration scheitert oder ein Operator bricht ab: Fehlerarten auseinanderhalten

Ein Fehler bei model.to("mps") oder tensor.to("mps") tritt beim Wechsel des Geräts auf. Ein Fehler erst während der Berechnung kann auf einen nicht implementierten Operator, eine nicht unterstützte Operation oder einen Datentyp zurückgehen. Diese Fälle sollten nicht pauschal als „PyTorch wurde falsch installiert“ zusammengefasst werden.

Die offiziellen MPS-Hinweise beschreiben die Unterstützung und Einschränkungen des Backends. Prüfen Sie die MPS-Dokumentation für PyTorch 2.14 anhand der konkreten Operation, die den Fehler auslöst. Wenn die Fehlermeldung auf einen Datentyp wie float64 verweist, behandeln Sie das als eigenen Kompatibilitätsfall. Ein Fallback für eine nicht implementierte Operation ist keine allgemeine Lösung für Datentypgrenzen; die aktuelle MPS-Dokumentation zu Datentypen sollte für diesen Punkt maßgeblich sein.

Für die Fehlersuche reduzieren Sie den problematischen Ablauf auf eine minimale Eingabe, die den Fehler noch auslöst. Notieren Sie, ob der Fehler beim Erzeugen des Tensors, beim Verschieben auf MPS oder erst während eines bestimmten Rechenschritts entsteht. Entfernen Sie nicht einfach die Operation, die scheitert, wenn sie für die wissenschaftliche Aussage Ihres Projekts wichtig ist. Stattdessen prüfen Sie, ob es eine fachlich zulässige Alternative gibt, und validieren diese gegen die Projektanforderungen.

CPU-Fallback: Fortsetzen ist nicht gleich Beschleunigen

Ein CPU-Fallback kann bestimmte nicht unterstützte MPS-Operationen auf der CPU ausführen. Das kann dabei helfen, einen Ablauf diagnostisch fortzusetzen. Es beweist aber nicht, dass die Operation auf der GPU ausgeführt wurde, und es behebt nicht jede Einschränkung des Backends. Prüfen Sie dafür die PyTorch-Dokumentation zu MPS-Umgebungsvariablen. Aktivieren Sie einen Fallback also gezielt zur Untersuchung, nicht als stillschweigende Bestätigung, dass Ihr GPU-Pfad funktioniert.

Beobachten Sie im Test, ob der problematische Rechenschritt tatsächlich auf MPS läuft oder über die CPU abgewickelt wird. Wenn Sie den Ausführungspfad nicht kontrollieren können, sollten Sie aus einer erfolgreichen Programmausführung keine Aussage über MPS-Leistung oder GPU-Nutzung ableiten. Für eine belastbare Bewertung brauchen Sie neben dem Ende des Laufs auch einen Nachweis dafür, welche Geräte die relevanten Berechnungen ausgeführt haben.

Wenn Sie den Fallback nur einschalten, damit das Programm „durchläuft“, dokumentieren Sie ihn als Teil der Testbedingungen. Sonst vergleichen Sie womöglich einen MPS-Lauf mit einem gemischten MPS- und CPU-Lauf, ohne den Unterschied zu bemerken.

Programmstart ist kein Forschungsnachweis: Gerätepfad und Ergebnisse prüfen

Ein Modell, das sich laden lässt, kann trotzdem an einer späteren Operation scheitern. Und ein Lauf, der ohne Abbruch endet, sagt allein noch nichts über die wissenschaftliche Verwendbarkeit des Ergebnisses aus. Prüfen Sie die Gerätezuordnung in einem kleinen Test, bevor Sie den vollständigen Workflow ausführen.

import torch

device = torch.device("mps")
x = torch.randn(4, device=device)
print("Tensor-Gerät:", x.device)

y = x * 2
print("Ergebnis-Gerät:", y.device)

Diese Probe bestätigt, dass Tensoren in diesem einfachen Beispiel dem MPS-Gerät zugeordnet sind. Sie beweist nicht, dass alle Modelloperationen Ihres Projekts unterstützt werden. Testen Sie anschließend den kleinsten repräsentativen Abschnitt Ihrer Pipeline, der die relevanten Operatoren, Datentypen und Datenformen enthält. Prüfen Sie dabei, ob Ihr Programm an der erwarteten Stelle scheitert oder einen Fallback nutzt.

Legen Sie für den Vergleich mit CPU vorab fest, welche Kennzahlen und Toleranzen für Ihre Fragestellung fachlich vertretbar sind. Vergleichen Sie dieselben Eingaben, sichern Sie Konfiguration und Ausgaben und notieren Sie, welcher Gerätepfad zum Einsatz kam. Berücksichtigen Sie außerdem Zufallszustände und nichtdeterministische Vorgänge: Die PyTorch-Hinweise zur Reproduzierbarkeit erläutern, warum identische Ergebnisse nicht pauschal über unterschiedliche Umgebungen hinweg garantiert werden.

Für wissenschaftliche Arbeit zählt nicht nur die numerische Nähe eines einzelnen Laufs. Prüfen Sie, ob Abweichungen Ihre Schlussfolgerung, die Rangfolge von Modellen oder die Interpretation eines Experiments beeinflussen. Verwenden Sie dafür die Kriterien Ihres Projekts und dokumentieren Sie Änderungen am Rechenpfad. Bei sensiblen Forschungsdaten sollten Sie vor jeder Verarbeitung auf einem extern verwalteten Rechner die Vorgaben Ihrer Hochschule, Ihre Datenschutzpflichten nach DSGVO und die Regeln zur Datenübermittlung beachten. Für die erste Funktionsprüfung genügt häufig ein anonymisiertes oder synthetisches Beispiel.

Prüfliste und Entscheidung: MPS, CPU oder HPC

Arbeiten Sie die Prüfpunkte nacheinander ab. Wenn ein Punkt nicht erfüllt ist, beheben Sie zuerst genau diesen Befund, bevor Sie zum nächsten wechseln.

  • [ ] Ich habe is_built() und is_available() in derselben Laufzeitumgebung geprüft.
  • [ ] Ich habe Interpreterpfad, PyTorch-Version und Plattform zusammen mit dem Fehlerprotokoll gesichert.
  • [ ] Ich kann unterscheiden, ob der Fehler beim Import, beim Gerätewechsel oder bei einem Operator auftritt.
  • [ ] Ich habe geprüft, ob der Fehler einen Datentyp betrifft, und nicht angenommen, dass CPU-Fallback ihn behebt.
  • [ ] Ich habe einen repräsentativen Projektausschnitt ausgeführt und den tatsächlichen Gerätepfad kontrolliert.
  • [ ] Ich habe CPU- und MPS-Ergebnisse mit denselben Eingaben sowie anhand fachlich begründeter Kriterien verglichen.
  • [ ] Ich habe bei externen oder entfernten Rechnern geklärt, ob die Datenverarbeitung nach den Hochschulregeln zulässig ist.
Weg Wann er passt Was Sie vor der Freigabe prüfen
MPS weiterverwenden Build und Laufzeit sind verfügbar, und die relevanten Operationen laufen auf MPS. Repräsentativer Projektlauf, Gerätepfad, Ergebnisqualität und dokumentierte Umgebung.
Vorübergehend CPU nutzen Sie müssen einen kleinen Test oder eine Diagnose fortsetzen, und die Laufzeit ist vertretbar. Ob der CPU-Pfad Ihre Forschungsanforderungen erfüllt; ein Erfolg ist kein Nachweis für MPS-Unterstützung.
HPC verwenden Das Projekt benötigt eine etablierte Clusterumgebung, größere Rechenressourcen oder einen vom Labor vorgegebenen Linux-Workflow. Softwareverfügbarkeit, Warteschlangen, Datenzugriff, Übertragungsregeln und Reproduzierbarkeit im HPC-System.
Migration pausieren Ein notwendiger Operator oder Datentyp scheitert und eine fachlich gültige Alternative ist ungeklärt. Fehlermeldung, minimale Reproduktion und Anforderungen des Forschungsprotokolls, bevor Sie Ergebnisse vergleichen.

Für eine Einordnung von Mac, CPU und Hochschul-HPC nach Aufgabentyp lesen Sie auch den Leitfaden zur Aufteilung wissenschaftlicher Rechenaufgaben. Wenn Sie eine macOS-Umgebung benötigen, aber kein Gerät vor Ort verfügbar ist, prüfen Sie die tatsächlichen Konditionen und den vorgesehenen Zugriff in der Übersicht der Mietangebote. Eine Remote-Mac-Sitzung kann eine konkrete Kompatibilitätsprüfung ergänzen; sie ersetzt weder einen HPC-Cluster für passende Großrechenaufgaben noch die Freigabe Ihrer Hochschule für sensible Daten.

Häufige Fragen zu MPS-Fehlern in der Forschung

Warum ist MPS trotz Apple-Silicon-Mac nicht verfügbar?

Der Chip allein bestätigt nicht, dass PyTorch im gestarteten Prozess einen passenden Build lädt oder MPS zur Laufzeit nutzen kann. Vergleichen Sie die Ergebnisse von is_built() und is_available() und kontrollieren Sie, ob Terminal, Notebook und IDE denselben Interpreter verwenden. Erst danach lohnt es sich, Systembedingungen oder eine Neuinstallation zu untersuchen.

Was bedeutet „MPS gebaut, aber nicht verfügbar“?

„Gebaut“ bezieht sich auf die MPS-Unterstützung im PyTorch-Build. „Verfügbar“ fragt, ob die aktuelle Kombination aus Build und Laufzeit MPS tatsächlich verwenden kann. Sichern Sie beide Werte zusammen mit Interpreterpfad, PyTorch-Version und Plattform. Stimmen diese Angaben zwischen zwei Ausführungsorten nicht überein, untersuchen Sie zuerst den Umgebungsunterschied.

Kann CPU-Fallback nicht unterstützte PyTorch-MPS-Operatoren abfangen?

Bei bestimmten nicht implementierten Operationen kann ein Fallback auf CPU helfen, einen Lauf fortzusetzen. Daraus folgt aber nicht, dass der betroffene Schritt GPU-beschleunigt wird. Außerdem sind Datentypbeschränkungen ein separater Fall. Dokumentieren Sie den Fallback und prüfen Sie anhand der offiziellen Umgebungsvariablen, was tatsächlich aktiviert ist.

Wie vergleiche ich CPU- und MPS-Ergebnisse für eine Forschungsarbeit?

Verwenden Sie dieselben Eingaben und vergleichen Sie nicht nur, ob beide Läufe beendet wurden. Dokumentieren Sie Gerätepfad, relevante Konfiguration und die für Ihr Projekt wichtigen Ergebniskennzahlen. Definieren Sie fachlich begründete Toleranzen und untersuchen Sie Abweichungen, die Ihre Schlussfolgerung beeinflussen könnten. PyTorch weist darauf hin, dass Reproduzierbarkeit nicht pauschal für jede Umgebung garantiert werden kann.

Wann sollte ich statt MPS einen Hochschul-HPC-Cluster verwenden?

Wählen Sie HPC, wenn Ihre Forschungsgruppe einen Clusterworkflow vorgibt, die erforderlichen Programme dort verfügbar sind oder die Aufgabe für den lokalen Mac ungeeignet ist. Prüfen Sie vorher Datenzugriff, Übertragungsregeln und die Verfügbarkeit der benötigten Software. Ein Mac kann trotzdem für kleinere Kompatibilitätstests oder Entwicklungsarbeiten nützlich sein, ersetzt aber nicht automatisch Ihre Laborinfrastruktur.

Ihr nächster Schritt: erst einen sicheren Test, dann die passende Umgebung

Wenn MPS verfügbar ist, aber Ihr Projekt an einem Operator oder Datentyp scheitert, ändern Sie nicht sofort den gesamten Forschungsworkflow. Erstellen Sie zuerst eine minimale Reproduktion mit anonymisierten Daten, dokumentieren Sie den Gerätepfad und vergleichen Sie die Resultate mit Ihrem CPU- oder HPC-Baseline-Lauf. Wenn der Mac-Test nur einen begrenzten Teil Ihrer Arbeit betrifft, lassen sich lokale, entfernte und institutionelle Ressourcen anhand dieses konkreten Bedarfs abwägen.

Eine Remote-Mac-Umgebung ist vor allem dann eine Option, wenn Ihnen für einen zeitlich begrenzten macOS-Test die passende Hardware fehlt. Prüfen Sie vor einer Entscheidung die verfügbaren Zugangsbedingungen und den Datenschutzrahmen; die Informationen zu den Mac-Angeboten sind dafür der nächste Anlaufpunkt. Für dauerhaft hohe Rechenlast, einen zwingend vorgeschriebenen HPC-Workflow oder Anforderungen an physische Schnittstellen ist eine Miete nicht automatisch die passende Lösung.

Zuletzt aktualisiert am 23.10.2026. Die Angaben wurden anhand der PyTorch-2.14-Veröffentlichung, der MPS-Dokumentation und der Dokumentation zu MPS-Umgebungsvariablen geprüft.