1. 痛みの分解
Python が Rosetta x86 のままだと MPS が無効化されます。batch が小さすぎると Metal を十分に使えず、大きすぎるとユニファイドメモリが跳ね上がります。一部演算子は CPU フォールバックとなり、数値経路は CUDA と完全一致しません。ノートブックでは epoch 境界での torch.mps.empty_cache() と gc.collect() が必須です。
2. 意思決定表
| 軸 | CPU | MPS | MLX | リモート |
|---|---|---|---|---|
| 強み | 互換 | torch 資産再利用 | Apple 最適化 | 隔離と SLO |
| リスク | 上限 | 演算子・数値 | 二重運用 | 運用コスト |
3. 五手順 Runbook
- arm64 の Python を固定し、torch ビルドを記録します。
is_builtとis_available、ダミー matmul の device をログします。- batch を掃引し、スループットとメモリ水位を保存します。
- 各 epoch 後に
gc.collect(); torch.mps.empty_cache()を実行します。 - CPU 比の加速とホット演算子を確認し、MLX かリモートへ分岐します。
4. 引用閾値（要実測置換）
- CPU 比で step が 22% 未満しか縮まず GPU 利用率が 18% を下回る場合はデータ面を疑います。
- 10 epoch でメモリが 26% 以上上がる場合は参照リークとリモート専用機を検討します。
- CUDA と損失を bitwise で揃える必要がある場合は訓練場所を見直します。
5. フォールバック症状表
| 症状 | 仮説 | 対処 |
|---|---|---|
| 初期は速い | キャッシュ | batch 調整と解放 |
| 特定層のみ遅い | カーネルギャップ | profiler |
6. MLX／リモートへ進む条件
LLM 推論が中心なら Ollama＋MLX の記事を先に読みます。会議アプリと IDE とメモリを奪い合うならリモートへ移し、SSH／VNC ガイドで接続を設計します。演算子が二週間で収束しないならアーキテクチャ分割を受け入れます。
7. FAQ
MPS と MLX の速度はモデル依存です。SLO 用途では安定版 torch を固定します。Docker 内 MPS は Colima 記事の仮想化コストを先に読みます。
8. 深掘り：MPS は互換性の税金です
研究コードを Metal に繋ぐ橋として MPS は有用ですが、CUDA 1:1 を期待しないでください。Metal のスループットと小 batch のオーバーヘッド、ユニファイドメモリの恩恵とスワップの罰則を同じ図に描けることが重要です。五要素（torch 版、コミット、batch、ピークメモリ、フォールバックフラグ）を実験ノートに残してください。
エンジン比較記事では契約（解像度、batch、量子化）を定義し、Docker 記事では GPU 可視性の損失を別ゲートにします。リモート Mac レンタルはノートを夜間サーバ化する習慣を減らします。
9. 観測性ミニ表
| 信号 | 先に見る | 緩和 |
|---|---|---|
| 加速 1x 付近 | device と同期 | profiler |
| OOM | 動的グラフ | empty_cache |
10. まとめ
ノート PC は探索に適し、共有ノードは約束に適します。MACGPU はログイン不要で公開されているプランとヘルプから、リモート Apple Silicon を試せます。外部へ遅延を約束する前に arm64 証明と曲線を添付してください。
11. DataLoader と同期：GPU 利用率が低い理由は MPS 外にあります
Activity Monitor の GPU 列だけを見て「MPS が効いていない」と決めつけると、本質から遠ざかります。多くの場合、JPEG デコード、色空間変換、重い拡張、あるいは学習ループ内の loss.item() や逐次ログが CPU 側で同期点を増やし、Metal 側は短いバーストの間に待機します。対策は、数十ステップに限定したプロファイルで「データのみ」「順伝播のみ」を分離して比較することです。num_workers を増やすほどワーカー常驻メモリが増えるため、16GB 級では逆効果になることもあります。増減のたびにピーク常驻と p95 を併記してください。
pin_memory は CUDA 向け記事のコピペ設定ではなく、Mac 上では仮説として検証します。profiler でホスト—デバイス間の余分なコピーが見えたときだけ手を入れる方が、設定迷子を防げます。
12. torch.profiler の読み方（短い窓で十分です）
ウォームアップ後の数十ステップを切り出し、CPU と MPS の両方を記録します。自己時間は小さいが待ち行列が長いカーネルは、同期や未対応演算子の匂いがします。Vision 系では前処理だけを別キャプチャし、ストレージ遅延と畳み込み本体を混同しないでください。DataLoader のマルチプロセス利用時は、乱数シードと worker_init_fn を README に明文化し、「同じスクリプトで再現しない」議論を防ぎます。
13. 数値の話を製品指標に落とす
CUDA クラスタとの損失をビット単位で揃えるのは現実的ではないケースが多いです。検証指標（mAP や top-1）で許容差を定義し、dtype 方針（重み、正規化、還元）を表形式で残してください。厳密再現が必要な領域は単一プラットフォームに閉じるか、差分表をレビュー承認します。
14. 小さな具体例：16GB ノートでの ViT-tiny バッチ探索
A100 で動いた batch をそのまま持ち込むと、ユニファイドメモリとスワップが会話に割り込みます。batch を段階的に変え、メモリピークと tokens 相当のスループットをペアで記録します。同じ手順を 64GB のリモート Mac で繰り返し、最適点が移動した理由を I/O と熱の観点で説明できるようにします。
15. マルチプロセスとファイル記述子
macOS ではフォーク周りの前提が Linux とは異なります。デッドロックが出たら一旦単一プロセスで切り分け、ワーカーを一つずつ戻します。併せて、サイト内のローカル LLM 並行記事の統一メモリ議論を参照し、他プロセスとの競合を実験ノートに書き留めてください。
16. チェックポイントと勾配累積
MPS 上の AMP は CUDA と同じ挙動を保証しません。マイクロバッチ累積ではスケーリングと optimizer ステップの対応を再確認し、チェックポイント有効時はプロファイル結果が変わることを注記します。公開する数値には、どの戦略を使ったかを必ず添えます。
17. 実験台帳に書くべき地味な欄
データセットシャードのチェックサム、バックグラウンドアプリの有無、電源アダプタ接続、低電力モードのオンオフ、キャッシュディレクトリのマウント種別などを欄外に用意します。地味に見えますが、12% の劣化がサーマルスロットリングだった事後分析を短縮します。リモート移行後は、アーティファクトストアまでの RTT も一行添えてください。