PyTorch 2.14 MPS-Speicher nicht ausreichend: 2026 beheben

PyTorch 2.14 MPS-Speicher nicht ausreichend beheben Sie nicht durch das sofortige Abschalten von Speichergrenzen, sondern durch eine geordnete Diagnose von Tensoren, Cache, Rechengraphen, dynamischen Formen und CPU-Fallbacks. In dieser Woche sollten Sie zuerst eine reproduzierbare Minimalaufgabe mit festgehaltenen Versions- und Formdaten erstellen, danach genau eine Speicherursache ändern und die Korrektur in einer sauberen Apple-Silicon-Umgebung erneut prüfen.

Für wen dieser Leitfaden gedacht ist: für Forschende, die beim Training oder bei der Inferenz auf Apple Silicon einen MPS-out-of-memory-Fehler erhalten. Ebenso für Maintainer wissenschaftlicher Software, die Linux-GPU- und macOS-Ergebnisse vergleichen müssen, sowie für technische Verantwortliche eines Labors ohne eigenen Mac, die kurzfristig eine unbelastete Reproduktionsumgebung benötigen.

Zuletzt aktualisiert am 12.09.2026; Versions- und API-Angaben wurden anhand der offiziellen PyTorch-2.14-Veröffentlichungsnotiz sowie der stabilen MPS-Dokumentation geprüft.

Erstdiagnose statt erzwungener Fortsetzung

PyTorch 2.14 wurde laut offizieller Veröffentlichung am 02.09.2026 freigegeben. Die Veröffentlichung beschreibt Anpassungen am MPS-Caching-Allocator sowie an bestimmten Speicher- und Kopierpfaden. Das bedeutet jedoch nicht, dass jedes Problem mit zu wenig MPS-Speicher oder kontinuierlich wachsendem Speicher dadurch gelöst ist. Ein Versionswechsel kann das Verhalten verändern, ersetzt aber keine Ursachenanalyse.

Zunächst muss das beobachtete Verhalten einer Fehlerklasse zugeordnet werden:

Die macOS-Aktivitätsanzeige unterscheidet den systemweiten Speicherdruck von einer einzelnen Prozessanzeige. Deshalb darf ein hoher Prozesswert nicht automatisch als Beweis gelten, dass ausschließlich MPS-Tensoren die Ursache sind. Die Apple-Erklärung zum Speicherdruck beschreibt, wie dieser Systemzustand einzuordnen ist.

Notieren Sie vor jeder Änderung mindestens PyTorch-Version, Python-Version, macOS-Version, Apple-Silicon-Modell, Modellversion, Eingabeformen, Batchgröße, Zufallsinitialisierung und den vollständigen Fehlertext. Ohne diese Basis ist ein späterer Vergleich zwischen zwei Läufen kaum belastbar.

PyTorch MPS out of memory: Was sollte zuerst geprüft werden?
Zuerst werden nicht die Umgebungsvariablen verändert, sondern die Fehlerart und der genaue Speicherverlauf festgestellt. Prüfen Sie anschließend, ob der Speicher bereits durch Modellparameter und Aktivierungen belegt wird, ob nur der Cache wächst oder ob Ihr eigener Code Tensoren beziehungsweise Rechengraphen über Iterationen hinweg hält.

Speicherbild und Gerätegrenzen

Für Apple Silicon ist „Unified Memory“ nicht gleichbedeutend mit „vollständig für MPS verfügbar“. macOS, Python, Bibliotheken, Fenster, Hintergrundprozesse und gegebenenfalls CPU-Arbeit teilen sich den physischen Arbeitsspeicher. Außerdem beschreiben die MPS-APIs unterschiedliche Ebenen der Belegung.

Die Definitionen der ersten beiden Werte finden Sie in der Dokumentation zu current_allocated_memory und driver_allocated_memory. Für die empfohlene Obergrenze ist die Referenz zu recommended_max_memory maßgeblich.

Ein Minimalprotokoll sollte vor und nach einem klar abgegrenzten Arbeitsschritt schreiben:

import torch

def mps_status(label):
    if not torch.backends.mps.is_available():
        print(label, "MPS nicht verfügbar")
        return

    current = torch.mps.current_allocated_memory()
    driver = torch.mps.driver_allocated_memory()
    limit = torch.mps.recommended_max_memory()

    print({
        "label": label,
        "current_allocated": current,
        "driver_allocated": driver,
        "recommended_max": limit,
    })

Die Werte werden in Bytes ausgegeben. Vergleichen Sie nicht nur den Endwert, sondern den Verlauf nach Modellinitialisierung, erstem Batch, Rückwärtslauf und mehreren Wiederholungen. Ein einzelner Messpunkt kann nicht zeigen, ob Speicher dauerhaft gehalten, nur zwischengespeichert oder später wieder freigegeben wird.

Wie lässt sich der tatsächliche MPS-Verbrauch auf Apple Silicon prüfen?
Lesen Sie current_allocated_memory() und driver_allocated_memory() getrennt aus und stellen Sie beide Werte dem macOS-Speicherdruck gegenüber. Erst die gemeinsame Zeitreihe zeigt, ob aktive Tensoren, Treiberreservierungen oder die gesamte Umgebung wachsen.

Modellgröße, Batch und Eingabeformen

Wenn die aktive Tensorbelegung bereits während eines kurzen Laufs stark ansteigt, liegt die erste Grenze meist in der Arbeitslast selbst. Prüfen Sie Modellparameter, Aktivierungen, Optimizer-Zustände, Batchgröße, Sequenzlänge und Bild- beziehungsweise Signalauflösung getrennt voneinander.

Die wichtige Regel lautet: Ändern Sie nicht gleichzeitig Batchgröße, Präzision, Eingabeform und Modellarchitektur. Sonst lässt sich nach einem erfolgreichen Lauf nicht feststellen, welche Maßnahme geholfen hat.

Verwenden Sie für den Vergleich denselben Zufallsstart, dieselbe Eingabedatei und dieselben Modellgewichte. Ein kleinerer Batch, der nur einen einzigen Durchlauf schafft, ist noch keine Reparatur. Für eine wissenschaftliche Aussage muss der verkleinerte Lauf den relevanten Abschnitt mehrfach und mit identischem Protokoll absolvieren.

Warum wächst der MPS-Speicher trotz kleinerem Batch weiter?
Ein kleinerer Batch verringert nur einen Teil der aktiven Belegung. Wenn Ausgaben, Loss-Tensoren mit Gradienten, Hidden States oder Logdaten zwischen den Iterationen referenziert bleiben, kann der Speicher trotzdem wachsen. Auch wechselnde Eingabeformen können neue temporäre oder kompilierte Pfade erzeugen.

Cache, Fragmentierung und dynamische Formen

torch.mps.empty_cache() ist kein allgemeiner Speicher-Reset. Die Funktion gibt nicht belegte Cache-Bereiche frei; Tensoren, die noch referenziert werden, bleiben davon unberührt. Die offizielle API-Beschreibung von empty_cache() setzt deshalb eine klare Grenze für diese Maßnahme.

Warum gibt torch.mps.empty_cache() nicht den gesamten Speicher frei?
Weil die Funktion nur nicht mehr verwendete, zwischengespeicherte Bereiche betrifft. Aktive Tensoren, daran hängende Rechengraphen und Speicher, den der Treiber weiterhin reserviert, werden dadurch nicht automatisch gelöscht. Ein niedrigerer Cache-Wert beweist daher nicht, dass die Ursache des Wachstums beseitigt wurde.

Führen Sie zwei getrennte Versuche durch: zuerst mit einer konstanten Eingabeform, anschließend mit dem realistischen Formwechsel. Zeichnen Sie jeweils aktuelle Tensorbelegung, Treiberbelegung und Systemdruck auf. Wenn nur der dynamische Versuch anwächst, ist die Formvariation ein wichtiger Hinweis. Wenn beide Versuche anwachsen, müssen Referenzen und Arbeitslast weiter untersucht werden.

Achtung: Setzen Sie keine hohe Speichergrenze herab oder herauf, nur damit ein einzelner Lauf fortgesetzt wird. Die MPS-Umgebungsvariablen von PyTorch verändern Allokations- und Fallback-Verhalten; sie sind Diagnosewerkzeuge mit möglichen Stabilitäts- und Vergleichsfolgen, keine Reparatur für einen ungeklärten Rechengraphen.

Rechengraphen, Ausgaben und Protokollierung

Ein häufiger Fehler liegt nicht im Modell, sondern in der Trainingsschleife. Beispiele sind eine Liste, in die bei jeder Iteration ein Tensor mit aktivem Gradienten geschrieben wird, ein Logger, der komplette Vorhersagen speichert, oder ein rekurrenter Hidden State, der unbeabsichtigt mit dem Graphen der vorherigen Iteration verbunden bleibt.

Prüfen Sie den Code in dieser Reihenfolge:

1. Speichern Sie für Metriken nur skalare Werte oder lösen Sie die Tensorverbindung mit detach() an der passenden Stelle.
2. Legen Sie keine vollständigen Vorhersagetensoren ab, wenn für die Auswertung nur ein kleiner Auszug oder ein aggregierter Wert benötigt wird.
3. Verwenden Sie bei reiner Inferenz den passenden Rahmen mit torch.no_grad() oder torch.inference_mode(), ohne die Grenzen dieser Modi mit einem Trainingslauf zu vermischen.
4. Setzen Sie Gradienten nach jedem Trainingsschritt entsprechend dem gewählten Optimierungsablauf zurück.
5. Trennen Sie Zustände über Iterationen hinweg ausdrücklich, wenn das Modell keinen Graphen über mehrere Schritte benötigt.
6. Testen Sie danach eine Minimalrunde ohne Logger, Ergebnisliste und Export.

Der entscheidende Beweis ist ein A/B-Lauf: Die Modellrechnung bleibt gleich, nur die nicht notwendige Ergebnisaufbewahrung wird entfernt. Sinkt dadurch die aktive Belegung oder endet das kontinuierliche Wachstum, liegt die Ursache wahrscheinlich in einer Python-Referenz oder einem verbundenen Graphen. Bleibt der Verlauf unverändert, rücken Cache, dynamische Formen, Modellgröße oder Fallbacks in den Vordergrund.

CPU-Fallback und gemischte Gerätepfade

MPS und CPU können in einem Lauf kombiniert werden, ohne dass die Ursache sofort sichtbar ist. Ein nicht unterstützter Operator, ein explizites .to("cpu"), CPU-Eingaben oder ein aktivierter automatischer Fallback können Kopien und zusätzliche Speicherpfade erzeugen. Die PyTorch-Dokumentation zum MPS-Backend sollte deshalb neben dem konkreten Operatorverhalten geprüft werden.

Unterscheiden Sie drei Fälle:

• Der Code verschiebt einen Tensor selbst auf die CPU und später wieder zurück auf MPS.
• PyTorch fällt für einen bestimmten Operator automatisch auf die CPU zurück.
• Ein Teil der Eingabepipeline bleibt auf der CPU, während das Modell auf MPS liegt.

Erstellen Sie für den kritischen Abschnitt ein kleines Skript, das dasselbe Modell und dieselbe Eingabe zuerst auf MPS und danach auf CPU ausführt. Protokollieren Sie, an welcher Operation der MPS-Lauf scheitert, ob eine Warnung erscheint und ob die Ergebnisse innerhalb der für das Projekt festgelegten Toleranz liegen. Ein CPU-Erfolg beweist nicht, dass der MPS-Pfad korrekt oder speichereffizient ist.

Ein spezifischer GitHub-Fall kann dabei einen Suchhinweis liefern, aber keinen allgemeinen Beweis. Die betreffende Nutzerbeschreibung im PyTorch-Repository muss nach Version, Betriebssystem, Hardware, Status und Reproduktionsbedingungen gelesen werden. Ein dort gemeldetes Verhalten gilt nur als Bericht für diese Umgebung, solange es nicht unabhängig bestätigt ist.

Saubere Reproduktion und Auswahl der nächsten Maßnahme

Wenn das Problem auf dem Arbeitsrechner nicht eindeutig einzuordnen ist, richten Sie eine isolierte Umgebung auf einem echten Apple-Silicon-Mac ein. Installieren Sie nur die festgelegte Python-Version, PyTorch 2.14, die minimal notwendigen Abhängigkeiten und das Reproduktionsskript. Alte Caches, unklare Paketstände und gleichzeitig laufende Anwendungen würden sonst die Diagnose verfälschen.

Abnahme-Checkliste

• [ ] PyTorch-, Python- und macOS-Version sind zusammen mit dem Apple-Silicon-Modell dokumentiert.
• [ ] Modellgewichte, Eingabebeispiel, Zufallsstart und Eingabeformen sind festgehalten.
• [ ] Der vollständige Originalfehler ist unverändert archiviert.
• [ ] current_allocated_memory() und driver_allocated_memory() werden zu definierten Zeitpunkten geloggt.
• [ ] Der macOS-Speicherdruck wird während des Laufs kontrolliert.
• [ ] Batchgröße, Sequenzlänge oder Auflösung wurden einzeln und nicht gleichzeitig verändert.
• [ ] Ein Minimaltest ohne Ergebnislisten, umfangreichen Logger und unnötige Tensorreferenzen wurde ausgeführt.
• [ ] MPS- und CPU-Läufe verwenden dasselbe Reproduktionsskript, soweit das technisch möglich ist.
• [ ] Ein aktivierter CPU-Fallback ist dokumentiert und nicht stillschweigend als MPS-Ergebnis gewertet.
• [ ] Lockfile, Skript, Eingabeprobe, Speicherprotokoll, Ausgabezusammenfassung und Linux-Vergleich liegen gemeinsam vor.
• [ ] Ein zweiter Verantwortlicher kann den Test mit genau diesen Dateien erneut ausführen.

Für ein Labor ohne Mac ist eine kurzfristig gemietete, echte Apple-Silicon-Umgebung sinnvoller als eine unklare lokale Annahme über die spätere Hardware. Entscheidend ist nicht nur der Zugang, sondern die Übergabe eines reproduzierbaren Pakets. Informationen zu einer kontrollierten Remote-Mac-Arbeitsumgebung sollten Sie deshalb erst nach der technischen Klärung prüfen; die Diagnose bleibt unabhängig vom Anbieter.

Kosten- und Stabilitätsentscheidung

Die wirtschaftlich günstigste Lösung hängt davon ab, ob nur ein kurzer Reproduktionstest oder ein dauerhaftes Training benötigt wird. Ein eigener Mac vermeidet wiederkehrende Mietvorgänge, bindet aber Kapital und muss gepflegt werden. Ein Linux-GPU-System kann für das Haupttraining geeigneter sein, reproduziert jedoch keinen MPS-spezifischen Fehler. Eine Remote-Apple-Silicon-Umgebung schließt genau diese Lücke, ohne dass das Labor sofort eigene Hardware beschaffen muss.

Aktuelle Mietoptionen sollten Sie anhand der benötigten Laufzeit und des tatsächlich verfügbaren Apple-Silicon-Modells vergleichen; konkrete Preise ändern sich und werden hier nicht ohne eine belastbare Quelle genannt. Für eine erste Kalkulation können Sie die JexMac-Preisübersicht mit dem voraussichtlichen Reproduktionsfenster abgleichen.

Ergebnisbewertung und wissenschaftliche Grenze

Ein Lauf, der nicht mehr abstürzt, ist noch kein Nachweis für identische wissenschaftliche Ergebnisse. Vergleichen Sie neben dem erfolgreichen Abschluss auch Ausgabezusammenfassungen, Fehlermeldungen, verwendete Geräte, Fallbacks und die Speicherprotokolle. Wenn die MPS-Variante nur nach einer starken Änderung der Eingabeform oder mit CPU-Fallback funktioniert, muss diese Bedingung in der Dokumentation stehen.

PyTorch 2.14 kann durch die beschriebenen Anpassungen am MPS-Speicherverhalten einen anderen Verlauf zeigen als eine frühere Umgebung. Daraus folgt aber weder, dass jedes Wachstum ein PyTorch-Fehler ist, noch dass ein Upgrade alle Modelle stabil macht. Bei einer versions- oder systemabhängigen Abweichung ist ein festgehaltener, reproduzierbarer Versionsstand wissenschaftlich wertvoller als ein unkontrolliertes Weiteraktualisieren.

Wenn das bestehende Linux-GPU-Setup zwar stabil trainiert, aber den MPS-Fehler nicht reproduzieren kann, ist die Doppelspur die sauberere Entscheidung: Linux für den geeigneten Hauptlauf und Apple Silicon für macOS-spezifische Kompatibilitäts- und Reproduktionstests. Ein Labor ohne Mac sollte daher nicht vorschnell Hardware kaufen, aber ebenso wenig einen Remote-Lauf als Beweis für Linux- oder MPS-Ergebnisgleichheit behandeln.

Wer derzeit auf einem gemeinsam genutzten Windows- oder Linux-System arbeitet, hat für diesen Spezialfall drei reale Nachteile: Der MPS-Fehler lässt sich dort nicht direkt nachstellen, System- und Paketänderungen sind oft nicht vollständig kontrollierbar, und zusätzliche Übergaben zwischen Laborrechner und Testumgebung erschweren die Beweiskette. Wenn nach dem Minimaltest weiterhin unklar bleibt, ob der Fehler aus dem Code oder aus einer verunreinigten lokalen Umgebung stammt, bietet eine zeitlich begrenzte JexMac-Miete eine praktische Gegenprobe auf einem echten Apple-Silicon-Mac. Nach erfolgreicher Bestätigung können Sie sachlich entscheiden, ob Sie die Umgebung weiter mieten, zum Linux-GPU-Hauptlauf zurückkehren oder beide Pfade als dauerhaft dokumentierte Testspur behalten.