Mac mini M4のリモートノード（シンガポール・日本・韓国・香港・米国西部等）でプロキシ批処理とProResを回すとき、ボトルネックはメモリ・ディスクIO・キュー深さです。指標表、16GB/24GB閾値と意思決定マトリクス、日／月払いの目安。リージョン・遅延・TCO、大容量取得とIO、SSH/VNC入門と併読。料金で確認。
シナリオ（プロキシ／トランスコード）と指標表
プロキシはデコードと小さな書き込み多発、ProResはエンコードと大きなシーケンシャルIO、4444はRAMを特に食います。先に実効帯域とRTTを測り、データに近いノードへワーカーを置いてください。
| シナリオ | 主ボトルネック | RAMの目安 | ディスクの目安 | 実務KPI |
|---|---|---|---|---|
| オフラインプロキシ（H.264/H.265 メザニン） | 同時デコード＋mux | 中程度、4K超でスパイク | ランダムリード＋連続ライト多発 | 固定CQあたり時間当たりクリップ数 |
| ProRes 422 HQ / LT トランスコード | エンコーダ＋フレームプール | UHDタイムラインで高 | 大きなシーケンシャルR/W | プロファイル別リアルタイム係数（RTF） |
| ProRes 4444／アーカイブマスタ | メモリBW＋IO | 非常に高い | 持続ライト > リード | ピーク並列より単一ジョブの安定性 |
| リラップ／メタデータのみ | ファイルシステムメタデータ | 低い | 小さなランダムIO | 分あたりファイル数、APFS空き容量 |
跨境ではワーカー増設前にネット待ちでCPUが空転していないか確認してください。
M4 16GB と 24GB：動画パイプラインの選定閾値
ユニファイドメモリはデコード・エンコード・OSキャッシュを共有します。16GBは重いProResを主1本、24GBはUHD 1本＋軽プロキシや条件付きで422×2が上限寄りです。
| 観点 | M4 16GB | M4 24GB |
|---|---|---|
| 並列 ProRes UHD エンコード | 主1本（HQ/4444はリスク高） | 1本は余裕、監視下で422×2 |
| プロキシファームの並列 | 2〜3ワーカー（SSD依存） | 3〜4ワーカー |
| プレビュー／プレイヤー負荷 | GUI最小またはヘッドレス推奨 | 短時間のGUIレビューに余裕 |
| 将来のコーデック変化（HEVC 10bit等） | タイト、キュー上限を計画 | フォーマット変更の余裕 |
| こう見えたら | 推奨 | アクション |
|---|---|---|
| メモリプレッシャーで2本目開始時にRTFが崩れる | 24GB | エンコードを直列化するか、プロキシ用に2台目 |
| HDソースのオフラインプロキシのみ、夜間2ワーカー安定 | 16GB | キュー深さを上限、SSD空きを監視 |
| 4444マスタ、カラーノード、大型AE/ME連携 | 24GB | 単一ジョブSLA、同一ホストでVNC長時間を避ける |
| 月あたり稼働5日未満のバーストが多い | コスト主導でどちらも可 | 次節の日払い・月払いの式で比較 |
ディスクIOと並列キューのパラメータ
APFSは空き15〜20%以上を維持（一桁%は遅延悪化）。入力／スクラッチ／出力を分離してください。
並列の初期値（計測で調整）：
- プロキシ：16GB＋NVMe MAX_PROXY_JOBS=2、24GBは常駐〜3.5GBなら 3。
- ProRes：UHDのHQ/4444は 1、HD 422はローカルIOで 2 まで。
- スレッド／GET並列：HWスレッドの約75%上限、高RTTはGET 2〜4が安定しやすい。
大容量はストレージ隣の計算アイランドとして扱い、再読みを減らしてください。
日払いから月払いへ：動画バースト時のコスト比較のヒント
安定性 FAQ
まとめ
プロキシはIOと並列、ProResはRAMと直列化が鍵です。表で16/24GBを決め、キュー→ノード数の順で増やし、データのあるリージョンに寄せてください。連続稼働が長いほど月払いレンタル、短期ピークは日払い。最悪の一夜に合わせて段を選び、購入からリモートMacレンタルで伸縮。