1. 課題整理：多モーダルはメモリ契約である
（1）ViT 系ではパッチ幾何が固定なら、コストは短辺の二乗に近づきます。512→1024 は「2倍」ではなくおおよそ4倍の圧力になりがちです。（2）IDE・ブラウザ・プレビューと共有する統合メモリでは、スワップが初回だけ極端に遅く見えます。（3）前処理→視覚エンコーダ→投影→デコーダのどこかが Metal 外だと、フレームワークのせいに見えます。
2. テキストのみと多モーダルのボトルネック対照
| 観点 | テキスト LLM | 画像／短尺動画 |
|---|---|---|
| 主なメモリ要因 | 文脈×層×精度 | 解像度、フレーム数、視覚トークン幅、バッチ |
| まず触るべきレバー | 量子化・文脈削減 | ピクセルを減らす→バッチ→モデルクラス |
3. 五ステップ受入
- 入力契約（最大辺・最大フレーム・色空間）を README に固定する。
- 384→512→768 の解像度ラダーでピークメモリと TTFT を記録する。
- 対話用途は batch=1 から始め、オフラインのみ増やす。
- 視覚と言語で精度方針を揃え、混在はフレームワーク対応を確認する。
- 固定シードとフィクスチャで最小受入スクリプトを毎晩回す。
4. レビュー向け数値（必ず自ビルドで再測定）
- 32GB 統合メモリ環境で短辺 512→1024 はピークに 6〜12GB 級の差が出ることがあります（実装依存）。
- TTFT SLO が 800ms 未満なのに視覚エンコードだけで 400ms を超えるなら、まず解像度とフレーム間引きです。
- 週あたりエンジニア 4 時間超をローカル OOM／熱制御に費やすなら、高メモリのリモート Apple Silicon が ROI で勝ちやすいです。
5. リモート Mac に移す判断
| シグナル | アクション |
|---|---|
| 768 超の短辺や複数フレームを常時処理しメモリが黄ばむ | 専用推論サービスを高メモリのリモート Apple Siliconへ。SSH/VNC ガイド。 |
| 夜間に数千アセット評価 | キューと固定バッチでリモート実行、手元はスポット検証のみ。 |
| クリエイティブ作業と推論が同一マシンで常時スワップ | 重いフォワードを分離し、Metal／色彩パイプラインは Apple Silicon リモートで維持。統合メモリの挙動を参照。 |
| lockfile は揃うが性能だけズレる | まず前処理バージョンと入力解像度を diff。重みを疑う前に前処理を。 |
6. FAQ：動画フレーム、動的解像度、リモートは速いか
Q: 全フレームをそのまま送る？ サンプリング方針（例: 1fps やショット検出）が先。全フレーム必須ならキーフレーム＋差分フレームに分割し、差分は軽い動き検知や低解像プレビューに回すのが現実的です。
Q: リモートは常に速い？ 往復遅延やシリアライズが支配すれば遅くなります。優位なのはメモリ余白・隔離・24h キュー。固定フィクスチャで p95 がノード上で安定し、ノートはブラウザや NLE と帯域を奪い合うなら「運用可能」と言えます。
Q: テキスト MLX と同じ venv？ 可能ですが依存が広いので多モーダル受入は別スクリプト推奨。Q: 動的解像度は？ モデル前で縮小し、ログに版を残すこと。ブランチごとに切り抜きが違うと「同じ URL でもテンソルが違う」事故が出ます。
Q: OOM したら大きいモデルへ？ 多くはテンソル二重保持やデバッグ用の活性キャッシュが原因。構造を直してからバックボーンやノードを検討してください。
7. 深掘り：多モーダルはパイプライン工学
2026 年、モデレーションやタグ付け、添付ファイル理解など本番パイプラインに載ります。入力分布は裾が重く、平均レイテンシだけでは運用が破綻します。分位点と解像度階層をセットで報告してください。
統合メモリは VRAM 壁を消しますが、クリエイティブアプリと推論の帯域競合は残ります。Metal とメディアコーデックを揃えたいなら、リモートも Apple Silicon が摩擦が少ないです（スタック比較）。
本番移行後に時間を食うのは回帰と整合です。モデルのマイナー更新、前処理ライブラリ、OS の小更新でデコード経路が変わり、「先週は動いた」が「今週はフラaky」になります。受入はモデル／前処理／OSの三層に分け、一度に一層だけ変えてください。
MLX と周辺はまだ速く動きます。ベンチ一発より、解像度ラダーとピークメモリ曲線を資産化してください。手元のハーネスが緑なら、高解像・長時間バッチは専用ノードへ。インタラクティブ機は試行錯誤に専念させます。
8. 可観測性と SLO：「たまに遅い」を数値化する
多モーダル障害は「ユーザーが遅いと言う」から始まりがちです。runbook には少なくとも三つ：ピーク常駐、p95 の初回有用出力までの時間（製品定義に従う）、スワップインやメモリ圧イベント。三つ同時に悪化なら入力仕様超過を疑い、三つ目だけならデスクトップ混載を疑います。
HTTP ならゲートウェイで受け取った素のピクセル寸法とモデル境界のテンソル形状を両方ログし、食い違いでアラート。EXIF 自動回転や CDN の色空間変換が原因で、MLX 本体は無関係なのに落ちるケースが多いです。
| 観測項目 | 取り方 | 異常時に疑うもの |
|---|---|---|
| ピーク常駐 | 固定フィクスチャを 20 回、max を取る | 解像度段、バッチ、中間活性の保持 |
| p95 TTFT | 段階的な同時実行で負荷 | 視覚エンコーダ、ディスク I/O、シリアライズ、キュー詰まり |
| スワップ／圧イベント | 画面収録や書き出しタイムラインと照合 | インタラクティブ混載、同期、ブラウザタブ過多 |
9. エビデンスパック：社内・ベンダーへの要求
精度のスクショだけでは足りません。固定版（重み、tokenizer、前処理スクリプトのハッシュ）、解像度段ごとのピーク帯と p95、失敗コーパス（OOM・タイムアウト・色ずれ）を揃えてください。失敗例なしのレビューは本番初週で崩れやすいです。
リモート前提ならネットワークとシリアライズ予算も：最大ボディ、圧縮の有無、gRPC と REST の比較。巨大 JSON+base64 でゲートウェイが詰まり、「リモートが遅い」に見える例は MLX とは無関係です。
10. Metal 経路・前処理契約・キュー規律
モデル数式の前に三段の防壁。第一にMetal 経路：想定デバイスで動くか。混合精度・CPU フォールバック・NumPy コピーで常駐が倍になることがあり。代表入力でビジョンタワー配置を検証する一行ガードは MLX の版が変わっても有効です。
第二に前処理契約は API と同様に厳密に。色空間・EXIF・リサイズはトークン幾何を変えます。順序を文書化し重みと版固定。リサイズ核を変えるだけでラダーが無効化されるのでスタック全体で版管理してください。
第三にキュー規律：公平スケジューリング、レート制限、取り込み追いつかないときのバックプレッシャー。テンソルは速くてもサムネ同期で詰まれば遅く見えます。
統合メモリは CPU／GPU／メディア等で共有予算。HEVC 書き出しやブラウザの HW デコードだけで残量が変わるため、専用ノードは「弱いから」ではなく机のマルチテナントを避けるためです。
フェイルオーバーと同様に劣化モード（低解像・グレースケール・視覚タイムアウト時はテキストのみ）を用意し、ドキュメントと CI フィクスチャ ID を一致させてください。
11. まとめと MACGPU
ローカルは反復、高解像・大量バッチは専用ノード。解像度と FPS は硬いレバーで、スワップは尾遅延を増幅します。リモート Apple Silicon は対話机から推論を外しつつ Metal／コーデック整合を保てます。高メモリのリモート Mac を試したい場合は MACGPU のプランを参照してください（CTA、ログイン不要）。