PyTorch 2.14 MPS メモリ不足：2026年の研究訓練をどう直すか

PyTorch 2.14でMPSメモリ不足が出た場合、最初にMPSの上限を無理に解除して学習を続けるべきではありません。PyTorch 2.14は2026年9月2日に正式公開され、MPSのキャッシュアロケーターや一部のメモリ・コピー経路が調整されましたが、すべてのメモリ不足や増加を解決したという意味ではありません。まず実テンソル、キャッシュと断片化、計算グラフ、動的形状、CPUフォールバックを切り分け、最小タスクで再現できる状態に戻します。

最終更新：2026年9月12日。PyTorch 2.14の公開日とMPS関連の変更は、PyTorch公式リリースノートおよび公式MPS文書を確認しています。

この手順は、Apple Silicon Macで研究モデルを学習・推論する研究生、Linux GPUとmacOSで同じプロジェクトを検証するソフトウェア保守担当者、研究室にMacがなく一時的な再現環境を必要とする技術責任者を対象にしています。

まず「容量不足」と「メモリ増加」を分けます

MPS out of memoryという表示だけでは、原因は決まりません。PyTorchがMPSへの割り当てに失敗した場合、macOSがプロセスを終了した場合、処理が極端に遅くなって応答しなくなった場合、常駐メモリだけが増え続ける場合では、取るべき対策が異なります。

最初の実行では、次の情報を一つの記録にまとめます。

• PyTorch 2.14の正確なバージョン
• PythonとmacOSのバージョン
• Apple Siliconのチップ名
• モデル名、バッチサイズ、系列長、画像解像度などの入力形状
• 学習か推論か、CPUフォールバックを有効にしているか
• 完全なエラー出力と、エラーが発生した処理段階

MPSの確認では、torch.mps.current_allocated_memory()とtorch.mps.driver_allocated_memory()を同じ実行中に記録します。前者はMPSテンソルが現在使用しているメモリ、後者はMPSドライバーが確保しているメモリを示すため、意味が同じではありません。定義はそれぞれcurrent_allocated_memoryの公式APIとdriver_allocated_memoryの公式APIで確認できます。

macOS側では、アクティビティモニタのメモリプレッシャーも併記します。これはMPS専用の使用量ではなく、システム全体の圧迫を判断する情報です。Appleのメモリプレッシャー説明に沿って、MPSの数値と混同せずに読み取ります。

研究タスクを縮小し、どこで増えたかを固定します

モデルパラメーター、順伝播の活性値、勾配、オプティマイザー状態、バッチ内の入力が、同じタイミングでMPSメモリを使うとは限りません。Apple SiliconはCPUとGPUが統合メモリを共有しますが、搭載メモリ全体をそのままMPSで安全に利用できるわけではありません。OS、Python、データローダー、他のアプリケーションも同じシステム資源を使います。

変更は一度に一つだけにします。

1. まず同じ乱数シードで、入力サンプルを最小化します。
2. バッチサイズだけを下げ、一定回数の反復が完了するか確認します。
3. 改善しなければ、系列長または画像解像度だけを縮小します。
4. それでも失敗する場合は、モデル構造またはオプティマイザー状態を含む最小構成を作ります。
5. 複数回の反復で、初回だけ成功するのか、長時間後に増えるのかを記録します。

この順序なら、「バッチを下げたから直った」のか、「入力形状を変えたことで別の経路になった」のかを区別できます。研究結果の再現性を守るため、最終的な評価では縮小した条件を本番条件と混同せず、どの変更が結果に影響したかを記録してください。

キャッシュと動的形状は別の問題として検証します

empty_cache()を呼んでも、使用中のテンソルや計算グラフは消えません。このAPIが対象にするのは、未使用のキャッシュ領域です。したがって、呼び出し後もメモリが下がらないからといって、直ちにMPSの解放機能が壊れているとは判断できません。empty_cacheの公式仕様でも、解放対象は未使用キャッシュとして説明されています。

次の二つの処理を分けて実行します。

• 同一形状の入力を繰り返す固定形状テスト
• 系列長、画像サイズ、バッチ構成が変わる動的形状テスト

固定形状では安定し、動的形状だけでdriver_allocated_memoryが増えるなら、キャッシュプール、断片化、カーネルや処理経路の再利用条件を疑います。一方、両方でcurrent_allocated_memoryが反復ごとに増えるなら、Python側の参照や計算グラフが残っている可能性が高くなります。

recommended_max_memory()は判断材料の一つですが、システム全体の空きメモリを保証する値ではありません。推奨最大メモリの公式APIを確認しつつ、macOSのメモリプレッシャーと実際のエラーを合わせて判断します。

注意：MPSの高水位制限を意味を理解せずに解除し、長時間の学習を続ける方法は推奨しません。システム全体が圧迫され、プロセス停止や再現不能な挙動につながるため、環境変数を変更する場合も公式のMPS環境変数文書で意味とリスクを確認してください。

計算グラフとログの参照を切断します

バッチサイズを下げてもMPSメモリが増え続ける場合、モデルの大きさより、反復ごとに古いテンソルを保持しているコードが原因になっていることがあります。

典型的には、次の書き方が問題になります。

• lossをそのままリストへ追加する
• 勾配付きの予測結果をログオブジェクトへ渡す
• 隠れ状態をdetachせず次の反復へ渡す
• 学習ループ内で不要な中間テンソルを保存する
• 推論時にno_gradまたはinference_modeの範囲が不足している

学習では、勾配を次の反復へ意図せず残していないか、保存が必要な値だけをCPU側へ移しているかを確認します。推論では、評価用の出力を保存する処理と、グラフを保持する処理を分離します。

検証用には、データ読み込み、モデル呼び出し、損失計算、必要最小限の出力だけを残したループを作ります。そのループでメモリが安定するなら、削除したログ、評価指標、結果保存のどれかを一つずつ戻し、増加する行を特定します。

CPUフォールバックがメモリ経路を変えます

MPSで未対応または挙動に制限のある演算子を含むモデルでは、CPUフォールバックが結果とメモリ経路を変えることがあります。MPS上に置いた入力が演算子の境界でCPUへ移され、処理後に再びMPSへ戻る構成では、MPSだけを見ても増加の理由を説明できません。

まず、モデルと入力がどのデバイスにあるかを処理単位で確認します。次に、CPUフォールバックを有効にした場合と無効にした場合を、同じ最小スクリプトで別々に実行します。PyTorchのMPSバックエンド説明には、対応状況や利用方法を確認するための公式情報があります。

比較時は、次の四点を保存します。

• 失敗する演算子または処理段階
• MPSとCPUでの出力形状
• 許容できる数値差の定義
• current_allocated_memoryとdriver_allocated_memoryの推移

GitHubの個別Issueは、特定の環境におけるユーザー報告としては参考になりますが、一般的な再現条件とは限りません。たとえば関連するPyTorchのIssueを確認する場合も、対象バージョン、macOS、モデル、再現手順が一致するかを先に見ます。

FAQ：長時間実行へ進む前の確認

本文の確認だけでは判断しにくい検索意図を、実行順序に沿って整理します。

MPSのエラーを修正したと判断する条件は、単に一度起動できることではありません。固定した入力、環境、乱数シードで複数回の反復を完了し、メモリ記録と出力要約を残せることが最低限の合格条件です。

再現環境を作り、修正・ロック・二系統を判断します

既存のMacでだけ発生する問題は、古いキャッシュ、複数のPython環境、混在した依存関係、以前の実験プロセスに影響されます。研究室にMacがない場合は、Apple Siliconの実機へ短期間アクセスし、PyTorch 2.14と必要最小限の依存関係だけを入れた隔離環境を作る方が、原因の切り分けに向いています。

再現パッケージには、次の項目を含めます。

• 環境一覧と依存関係のロックファイル
• MPSへ移す最小スクリプト
• 入力サンプルまたは入力生成条件
• 完全なエラー出力
• 反復ごとのメモリ記録
• 出力の要約と許容する数値差
• Linux GPU側で同じ入力を実行した結果

修正が特定のPyTorch、macOS、モデル形状の組み合わせにだけ効くなら、そのバージョンを固定し、別環境での検証を止めないでください。Apple Siliconで動いたことは、Linux GPUで数値結果や性能が同一になることを意味しません。逆に、Linuxで安定していることも、MPSでのメモリ経路を保証しません。

優先度スコアで次の作業を選ぶ

以下のスコアは、実行順を決めるための編集上の目安です。性能比較の測定値ではありません。

• 5点：最初に確認 — 完全なエラー、環境一覧、入力形状、3種類のメモリ情報を保存する
• 4点：次に確認 — バッチ、系列長、解像度を一つずつ縮小する
• 4点：コードを確認 — loss、予測結果、隠れ状態、ログが参照を保持していないか調べる
• 3点：バックエンドを確認 — CPUフォールバックと未対応演算子を最小スクリプトで分離する
• 2点：最後に調整 — キャッシュや環境変数を変更し、変更前後の挙動を記録する

再現前の勾配・メモリ確認リスト

• [ ] PyTorch 2.14、Python、macOS、Apple Siliconの情報を保存した
• [ ] 完全なMPSエラーと発生した処理段階を保存した
• [ ] 入力形状と乱数シードを固定した
• [ ] current_allocated_memoryを反復ごとに記録した
• [ ] driver_allocated_memoryとmacOSのメモリプレッシャーを併記した
• [ ] 固定形状と動的形状を別々に実行した
• [ ] loss、出力、隠れ状態、ログの参照を点検した
• [ ] CPUフォールバックの有無を分けて確認した
• [ ] Linux GPU側の入力、出力要約、許容差を保存した
• [ ] 修正版を複数回実行し、安定性を確認した

このチェックが未完了のまま「PyTorch 2.14で修正された」と結論づけると、研究結果の説明責任を果たしにくくなります。再現できない場合は、修正済みと断定せず、Apple SiliconとLinux GPUの二系統を残す方が安全です。

Macがない研究室での費用判断

研究室の既存環境がLinux GPU中心なら、長期的な重い学習はその環境に残し、Apple SiliconではMPS固有の再現、macOS向け動作確認、短時間の推論検証に役割を限定する方法が現実的です。Mac実機の購入は物理アクセスや常設運用に向きますが、研究テーマの一時的な検証だけなら、購入費、保管、更新、学内共有の調整が負担になります。

一方で、遠隔のMacレンタルも万能ではありません。大量データを毎回転送する必要がある場合、物理センサーやUSB機器を使う場合、長期間にわたって高負荷学習を続ける場合は、研究室のLinux GPUや購入した実機の方が適しています。接続方式、作業時間、ファイル転送、権限を事前に確認するには、JexMacのヘルプを参照してください。

最小スクリプトを作った後も、コードの問題かローカル環境の汚染か判断できないなら、クリーンなApple Silicon環境で短期間だけ再現する価値があります。JexMacの料金案内で利用条件を確認し、本文の検証パッケージをそのまま持ち込めば、購入前にMPS固有の失敗を切り分けられます。

現在のLinux GPUだけで進める方法は、macOS固有の不具合を再現できず、研究室外のApple Silicon利用者へ配布する検証も不足しやすいという弱点があります。手元のMacだけで進める方法は、環境が一台に固定され、依存関係の汚染や長時間ジョブの中断を切り分けにくくなります。こうした制約を避け、必要な期間だけ実機のmacOS環境を確保したい場合は、JexMacでApple Siliconの検証環境を借り、修正後にLinux GPUへ戻す、または二系統を維持する運用が妥当です。

まずは最小スクリプト、入力サンプル、メモリ記録、Linux対照結果をそろえてから、短期のMac利用を判断してください。これなら、単なる「動いた」という確認ではなく、PyTorch 2.14 MPSの故障条件と修正範囲を説明できる検証になります。

よくある質問