PyTorch 2.14 MPS 記憶體不足：2026 年科研訓練怎麼修

先不要取消 MPS 記憶體限制來硬撐訓練：本週先建立錯誤基線，再依序區分真實張量佔用、快取與碎片、計算圖未釋放、動態形狀增長，以及 CPU 回退。只有在最小腳本能穩定重現並完成驗收後，才決定修正程式、鎖定 PyTorch 2.14，或保留 Linux GPU 與 Apple Silicon 雙軌環境。

最後更新於 2026 年 9 月 12 日；版本與 API 資料核實自 PyTorch 官方發布公告、MPS API 文件及相關官方記憶體文件。

這篇文章適合三類讀者：在 Apple Silicon 上訓練或推理時收到 MPS out of memory 錯誤的研究生；需要確認 Linux GPU 與 macOS 結果一致性的科研軟體維護者；以及實驗室沒有 Mac、需要臨時建立乾淨復現環境的課題組技術負責人。

先用症狀分流，而不是把所有問題叫作記憶體不足

PyTorch 2.14 已於 2026 年 9 月 2 日正式發布，官方說明提到 MPS 快取分配器，以及部分記憶體與複製路徑有所調整，可參考官方發布公告。這代表升級可能改善某些分配行為，但不代表每一個 MPS 記憶體問題都已經修復。

先把現象分成四類：

這裡的「評分」是排查優先次序，不是硬體效能分數。macOS 的記憶體壓力是系統層級指標，不能拿來直接替代 MPS API 的配置數字；Apple 對該指標的定義可見活動監視器的記憶體壓力說明。

最初的基線應包含 PyTorch、Python、macOS、Apple Silicon 型號、模型版本、輸入形狀、batch size、隨機種子、完整錯誤訊息，以及錯誤發生在訓練、驗證還是推理階段。沒有這份清單，之後即使「不再出錯」，也無法證明改動真正解決了問題。

先量三種記憶體，再判斷是否真的超出容量

Apple Silicon 的統一記憶體不能簡化成「機器總記憶體全部都能交給 MPS」。macOS、背景程序、Python 本身、CPU 張量、MPS 張量、驅動程式配置與快取都可能同時佔用資源。因此，單看一個百分比或單次錯誤訊息不足以定位根因。

上述 API 的用途與限制，應分別對照 current allocated memory 文件、driver allocated memory 文件及 recommended max memory 文件。建議每個關鍵迭代記錄時間、任務形狀與三種觀察值，而不是只在崩潰後補截圖。

第一輪縮減只改一個變數：先減少 batch size；若曲線仍不變，再回復 batch size 並縮短序列長度或輸入解析度。每次改動都使用同一隨機種子，至少確認最小任務可以完成多個訓練迭代，否則「能啟動」不等於「能穩定訓練」。

第一步：排除模型與輸入本身超過環境邊界

訓練的記憶體工作集不只包括模型參數，還包括中間激活、梯度、優化器狀態與輸入張量。推理則可能因批量、輸出保存及暫存張量而增加佔用。這些項目不應混在一起猜測，應透過最小改動找出主要增量來源。

建議按以下順序操作：

1. 保存目前可重現的模型、輸入與隨機種子。
2. 固定輸入資料型別、序列長度或影像尺寸，只把 batch size 降低。
3. 若錯誤消失，逐步恢復 batch size，記錄首次失敗的任務形狀。
4. 若錯誤不變，還原 batch size，改縮短序列或降低輸入尺寸。
5. 用最小任務完成多個迭代，再測試完整任務。

若只有完整輸入失敗，應把它記為環境容量邊界，而不是宣稱 PyTorch 2.14 發生記憶體洩漏。相反地，若最小輸入也在長時間執行後不斷增長，就要轉向檢查 Python 引用、快取或動態形狀。

注意： 不要同時降低 batch size、改精度、換模型並刪除日誌。這樣雖然可能暫時跑完，卻無法說明是哪個改動改變了故障。

第二步：處理快取、碎片與動態形狀

torch.mps.empty_cache() 只能釋放目前未被使用的快取，不能移除仍被張量、梯度、計算圖或 Python 容器引用的記憶體；官方 API 文件也明確限定了它的作用範圍，可參考 empty_cache 說明。因此，反覆呼叫清理函式卻看不到系統數字完全下降，並不自動代表 API 失效。

應把固定形狀與變化形狀拆開測試：

• 固定相同 batch size、序列長度與輸入尺寸，執行最小迴圈。
• 再讓每次輸入形狀變化，觀察 current_allocated_memory 與 driver_allocated_memory 的差異。
• 每個階段都記錄系統記憶體壓力，而非只抄 MPS 數字。
• 若固定形狀穩定、變化形狀增長，優先檢查重複編譯、快取池及資料整理流程。
• 若兩者都增長，回到輸出引用與計算圖檢查。

不要把 recommended_max_memory 當成可任意突破的目標，也不要直接取消高水位限制。MPS 環境變數的意義與風險應依照官方環境變數文件判讀；改變限制可能讓系統更早進入壓力狀態，並不能修正仍被程式持有的張量。

第三步：找出計算圖、輸出與日誌中的隱性引用

降低 batch size 後仍持續增長，常見的程式層線索包括把 loss、預測結果、隱藏狀態或帶梯度張量直接追加到列表，或把它們交給長期存在的日誌物件。每次迭代多保留一個引用，都可能讓相關計算圖無法回收。

訓練程式應逐項檢查：

• 保存數值時是否先轉成不帶梯度的值，而不是保存完整張量。
• 跨迭代的 hidden state 是否在正確邊界 detach。
• 梯度清零是否位於預期位置，且沒有把舊梯度交給列表或快取。
• 評估與推理是否使用合適的 no_grad 或 inference_mode 範圍。
• 日誌是否保存每一步完整輸出，而不是只保存必要摘要。

可先刪除非必要的結果保存與日誌，再執行固定形狀最小迴圈。如果記憶體曲線因此穩定，修復方向就是解除引用；如果沒有變化，才回到後端分配、動態形狀或系統壓力。

第四步：確認 CPU 回退沒有改變整條記憶體路徑

MPS 不支援或行為受限的算子，可能令部分工作轉到 CPU；而輸入仍留在 CPU、程式中途顯式搬移裝置，也會形成混合路徑。這時候所有增長都歸因於 MPS，會導致錯誤修復方向。

請把模型拆成最小可重現腳本，分別在 MPS 與 CPU 執行，並記錄：

• 第一個失敗的算子或階段；
• 輸入、模型與輸出的裝置位置；
• 是否啟用 CPU fallback；
• MPS 與 CPU 的錯誤訊息及輸出摘要；
• 同一輸入是否走過不同的複製路徑。

MPS 是 PyTorch 的後端之一，並非所有模型算子都能以相同方式執行；官方的 MPS 後端說明應作為相容性核對起點。GitHub 上的特定問題報告，例如相關使用者回報，只能說明某些版本、模型與環境組合曾出現問題，不能直接推廣成所有 Apple Silicon 都有同一故障。

FAQ：把搜尋問題轉成可驗收的排查動作

PyTorch MPS out of memory 應先檢查甚麼？

先保存完整錯誤與環境基線，再查看 MPS 張量配置、驅動程式配置和 macOS 記憶體壓力。接著只縮小一項任務變數，確認問題是立即超出容量，還是執行一段時間後才增長。

為甚麼 torch.mps.empty_cache 沒有釋放全部記憶體？

它只處理未使用的快取，仍被張量、計算圖、梯度或 Python 容器引用的記憶體不會被釋放。若清理後仍有增長，應檢查輸出列表、隱藏狀態及日誌物件，而不是無限重複呼叫清理函式。

Apple Silicon 訓練時怎樣查看 MPS 實際佔用？

同時記錄 current_allocated_memory 與 driver_allocated_memory，再對照活動監視器的記憶體壓力。前者偏向目前張量配置，後者包含驅動程式配置，兩者都不能單獨代表整台 Mac 的可用資源。

降低 batch size 後 MPS 記憶體為甚麼還會增長？

因為 batch size 只改變單次工作集，不能處理計算圖引用、輸出保存、跨迭代 hidden state 或動態形狀快取。用固定形狀最小迴圈並移除結果保存，通常比繼續縮小 batch size 更能區分程式問題。

實驗室沒有 Mac 如何復現 PyTorch MPS 錯誤？

使用真實 Apple Silicon Mac 建立隔離環境，鎖定 PyTorch 2.14、Python、macOS、輸入樣本及模型提交版本。復現包還要保存記憶體紀錄、輸出摘要與 Linux 對照，才能判定是環境特有問題還是程式本身問題。

第五步：用乾淨環境決定修復、鎖版或雙軌

當本機已安裝多套 Python、舊快取與不同版本套件，繼續在原環境反覆測試的成本會高於重新建立隔離環境。實驗室沒有 Mac 時，可先參考遠端 Mac 連線與使用說明，在真正的 Apple Silicon 主機上建立只包含鎖定版本與最小依賴的環境。

乾淨復現的操作順序如下：

1. 固定程式碼提交版本、PyTorch 2.14、Python、macOS 與套件鎖定檔。
2. 只安裝執行最小腳本所需的依賴，不先搬入整個實驗室環境。
3. 放入固定輸入樣本與隨機種子，記錄 MPS API 和系統壓力。
4. 分別測試固定形狀、變化形狀，以及移除輸出保存後的版本。
5. 在 Linux GPU 上以相同輸入和評估指標產生對照摘要。
6. 由第二位成員依鎖定檔和最小腳本重新執行，確認結果可交接。

完成後可用以下清單作為驗收門檻：

• [ ] 完整錯誤訊息、環境版本與硬體平台已保存。
• [ ] 已分開記錄張量配置、驅動程式配置與系統記憶體壓力。
• [ ] batch size、形狀或輸入尺寸是逐項修改，而非一次全部更改。
• [ ] 已檢查 loss、輸出、hidden state、梯度與日誌引用。
• [ ] 已確認模型是否發生 CPU 回退或不必要的裝置搬移。
• [ ] 固定形狀最小腳本可完成指定迭代，且不持續增長。
• [ ] 已保存 Linux GPU 對照結果，但沒有把平台差異直接宣稱為科研結果等價。
• [ ] 若問題只在特定組合出現，已鎖定可重現版本並保留雙軌驗證。

若錯誤只在某個 PyTorch、macOS 或模型組合出現，合理做法是鎖定該組合並記錄限制，而不是宣布 PyTorch 2.14 已經解決所有 MPS 記憶體問題。若最小腳本在乾淨環境仍無法穩定重現，則應把「無法重現」本身列入驗收結果，避免把一次成功執行誤當成修復證據。

從成本與風險看，Mac 租用適合哪一段工作

如果目前方案是直接在 Windows 或 Linux 實驗室機器上猜測 macOS 行為，缺點是沒有真正的 MPS 後端、難以重現 Apple Silicon 的裝置路徑，而且反覆改動共用環境會污染其他研究工作的依賴。若改用購買 Mac，則會把一次性的復現需求變成硬體採購、維護與閒置成本；若完全依賴雲端非 Apple Silicon 環境，又無法回答這個 MPS 故障是否只在 macOS 發生。

因此，當目標只是短期建立乾淨復現環境、完成最小腳本與雙軌驗收時，按週或按月租用一台具備完整權限的遠端 Apple Silicon Mac，通常比改造現有 Linux/Windows 環境更容易控制變因。可先查看 JexMac 的方案資訊，再依復現週期決定是否延長；若是長期高負載訓練、需要實體儀器介面，或已有穩定 Apple Silicon 工作站，直接自購或保留 Linux GPU 可能更合理。

常見問題