PR

Mac Studio 192GBか中古RTX 3090×2か?XServer VPSで48GiB要求を起動前判定

【PR】この記事にはA8.netのアフィリエイト広告を含みます。

先に結論:Mac Studio 192GBと中古RTX 3090×2のどちらを買うべきかは、XServer VPS 4GBだけでは決められません。ただし、AIジョブが必要とするメモリとCUDA条件を先に宣言すれば、VPSで実行不能な巨大モデルをダウンロード前に拒否できます。実機で1・3・48・192GiB級要求を判定し、1GiBだけallow、残り3件はrejectしました。モデルダウンロード0、コンテナ起動0、公開サービス停止0です。判定は一部解決です。

今回の目的は、48GiB級モデルを4GB VPSへ無理に読み込んでOOMを起こすことではありません。VPSavailable RAM、既存サービス用の予約、物理RAM比率、NVIDIA GPU有無を実測し、危険な処理を起動前に止められるかを確認しました。

Mac Studio 192GBRTX 3090×2は何が違う?

最大の違いはメモリ構成とソフトウェア互換性です。Apple SiliconCPUGPUが使うunified memoryを搭載し、NVIDIA GPUは専用VRAMCUDA ecosystemを持ちます。容量だけを足して同じものとして比較できません。

観点 Mac Studio 192GB RTX 3090×2
メモリ表記 192GB unified memory 24GB GDDR6X×2
CUDA 非対応 対応
2基のメモリ 該当なし 自動で1領域になるとは限らない
使えるモデル量 OS・runtimecache分を差し引く 分割方式・cacheframeworkに依存
今回の実機測定 未所有・未測定 未所有・未測定

RTX 3090は本当に1枚24GB?

NVIDIA公式のGeForce RTX 3090製品仕様は、Standard Memory Config24GB GDDR6Xと記載しています。2枚なら名目容量の合計は48GBです。

しかし、2枚挿せばすべてのLLMソフトから単一48GB GPUとして見えるわけではありません。model paralleltensor split、対応backendPCIe転送、KV cache配置などを確認する必要があります。本記事の「48GiB要求」は事前判定用の容量クラスで、2枚の実効VRAMを再現した値ではありません。

Mac Studioの192GBは全量をモデルへ使える?

Apple公式のMac Studio(2023)技術仕様では、M2 Ultraで128GBまたは192GB unified memoryを選べます。ただしOS、アプリ、model runtimeKV cache、画面描画も同じメモリを使います。

したがって「192GB搭載=192GBのmodel fileをそのまま読み込める」とは限りません。今回の192GiB要求も製品の実使用量ではなく、容量超過を安全に検出するテストケースです。

RedditではなぜMac Studioとデュアル3090で迷っている?

Redditr/LocalLLaMAWhy People Buying Macs Instead of CUDA Machines?」では、192GB unified memoryを持つMac Studioと、合計48GBのNVIDIAカード構成が比較されています。相談の中心は、大容量を取るかCUDAと速度を取るかです。

別の「2×3090 is close to great, but not enough」では、デュアル3090でも70Bモデルの量子化と長いcontextを同時に収めにくいという個別体験が報告されています。投稿者のモデル、量子化、context条件を一般化せず、今回の4GB VPS実測とは分けて扱います。

ZennではMac Studioの大容量メモリをどう評価している?

Zennの「ローカルLLMのための最適なGPU選定:Mac Studio購入の決め手」は、Mac Studioで128GB・192GB級のunified memoryを選べる点を評価する一方、prompt evaluationLLM以外のAIツールではNVIDIA側に利点があると整理しています。

容量、速度、互換性は別の軸です。そこで今回は、速度比較へ進む前に、ジョブの必要量を数値で弾く入口をVPSへ作りました。

XServer VPS 4GBは48GB級モデルを動かせる?

動かせません。今回の実機は物理RAM 3,904.1MiB、available 3,315.7MiB、NVIDIA GPUなしでした。48GiB要求は49,152MiBで、VPSの物理RAM全体の12倍以上です。192GiB要求は196,608MiBです。

容量要求 VPS物理RAMに対する倍率 CUDA 結論
1,024MiB 約0.26倍 不要 条件内
3,072MiB 約0.79倍 不要 サービス余白不足
49,152MiB 約12.59倍 要求 RAMGPUとも不足
196,608MiB 約50.36倍 不要 RAM不足

[PR]
VPSでいろいろ試すなら『XServer VPS』

なぜ巨大モデルを実際に起動しなかった?

実行不能が明らかな処理を起動しないこと自体が今回の実験だからです。公開中のCaddyFastAPIPostgreSQLを巻き込んでOOMさせるより、admission controlで拒否理由を記録する方が実運用に近く、安全です。

危険な方法 今回の方法
48GiBモデルをダウンロードする 宣言working setだけを読む
loadしてOOMを待つ safe allocatableと比較する
swap込みで入ると判断する swapmodel capacityへ数えない
CUDA有無を実行後に知る GPU device/runtimeを先に確認

安全に使えるメモリ上限をどう計算した?

VPS/proc/meminfoから物理RAMavailable RAMを読み、次の小さい方を採用しました。

  1. available RAM 3,315.7MiB − 公開サービス予約1,024MiB = 2,291.7MiB
  2. 物理RAM 3,904.1MiB × 60% = 2,342.5MiB

よってsafe allocatable2,291.7MiBです。固定値だけでなく、その時点のavailableを使うため、既存サービスの負荷が増えれば許可量も下がります。

実測項目
MemTotal 3,904.1MiB
MemAvailable 3,315.7MiB
サービス予約 1,024MiB
物理RAM比率上限 60%
safe allocatable 2,291.7MiB
swap free 1,928.8MiB、容量判定には不使用

1GiBと3GiB要求はどう判定された?

1,024MiB要求はsafe allocatable以下なのでallowでした。根拠は、手元で確認済みのqwen3:0.6b model artifact 522,653,767 bytesruntimecontextの余白を加えた包絡値です。前回実験では実際のコンテナ最大710.1MiBでした。

3,072MiB要求はrejectです。available RAMだけなら3,315.7MiBあるため入りそうに見えますが、公開サービス用1GiBを残せません。「空いているから全部使う」を防げました。

要求 判定 理由 実際の起動
1,024MiB allow 2,291.7MiB以下 判定のみ、起動なし
3,072MiB reject 安全上限を780.3MiB超過 なし

RTX 3090×2相当の48GiB要求はどうなった?

2つの理由でrejectしました。宣言working set 49,152MiBがsafe allocatable 2,291.7MiBを超え、さらにCUDA要求に対してNVIDIA device/runtimeを検出できませんでした。

チェック 必要 実機 結果
working set 49,152MiB 2,291.7MiBまで reject
CUDA true NVIDIA GPUなし reject
モデル取得 不要 0件 未開始
コンテナ 不要 0件 未開始

Mac Studio相当の192GiB要求はどうなった?

196,608MiBが安全上限を194,316.3MiB超えるためrejectしました。CUDAは要求しませんが、CPU RAMだけでも収容不能です。swap free 1,928.8MiBを足しても桁が違い、そもそもswapmodel memoryとして扱っていません。

この結果はMac Studioの性能否定ではありません。「4GB VPSへ192GB級の仕事を送るべきでない」というrouting判断です。

VPSの公開サービスは止まらなかった?

前後とも正常でした。動いていたコンテナはCaddyFastAPIPostgreSQLの3つで、判定前後の集合は完全一致しました。

確認 before after
公開ready ready ready
database ok ok
artifact storage ok ok
稼働コンテナ 3 3、同一
新規model download 0 0

途中で発生した問題と解決方法は?

初回はSSHユーザーでdocker psを直接実行し、Docker socketの権限不足で停止しました。判定開始前だったため、モデル、コンテナ、ジョブは作られていません。

既存のVPS運用で許可されているsudo docker psへ、状態確認部分だけを変更しました。2回目は4要求の判定、前後のコンテナ一覧、公開readyを1つのJSONへ保存できました。

XServer VPSで便利だった点は?

観点 実体験
Linux指標 /proc/meminfoで実availableを取得できた
事前判定 モデル取得前にmemory/CUDA条件を比較できた
サービス分離 公開3コンテナを動かしたまま判定できた
監査 allow/reject理由をJSONで残せた
遠隔操作 Chromeを使うPCからSSH経由で再現できた

分かりにくかった点・初心者が迷いそうな点は?

迷いどころ 注意点
24GB×2=必ず48GBモデル frameworkと分割方式を確認する
192GBを全量モデルへ使える OS、runtimecacheの余白が必要
availableが3GiBなら3GiB使える 公開サービス予約を差し引く
swapRAMとして足す 性能と安定性のため容量判定から外す
allowなら必ず成功 model formatcontextruntimeも別判定する

ディスク容量は問題なかった?

VPS144.3GiB total129.9GiB freeでした。大きなmodel fileを保存できそうに見えますが、ディスクへ置けることとRAMへロードできることは別です。今回はreject対象を1byteもダウンロードしませんでした。

実運用では、ダウンロード前にdisk freechecksumlicensemodel sizeを確認し、load前にworking setbackend条件を判定する二段階が必要です。

AIスマホ調査システムではどう使う?

ジョブへ必要条件を持たせ、VPSが対応可能なworkerだけへ割り振ります。これにより、Android操作は自宅PC、軽量要約はVPSCUDA処理は将来のNVIDIA PC、大容量モデルは将来のMacなどへ分離できます。

要件フィールド 判定
memory_mib 1024 / 49152 workersafe allocatable以下か
cuda true / false NVIDIA deviceruntimeがあるか
android_usb true 所有端末を接続したworker
artifact_free_mib 画像容量 保存先に余白があるか
max_seconds 調査期限 推定時間内に終わるか

今後どう拡張する?

  1. Ollama manifestGGUF metadataからmodel bytesを自動取得する。
  2. context長に応じたKV cache見積もりを追加する。
  3. workerごとにCPURAMVRAMCUDAMetalAndroid USBを登録する。
  4. allow後もcgroup上限とready監視を必須にする。
  5. reject時はAPI、別worker、縮小modelという代替候補を返す。

よくある質問

XServer VPS 4GBで48GB級モデルをswap実行できる?

実用的な代替としては扱えません。今回もswapmodel capacityへ数えず、起動前rejectしました。

RTX 3090を2枚買えば必ず48GBとして使える?

いいえ。各24GBという公式仕様は確認できますが、modelを2枚へ分割できるかはframeworkbackendmodel構造、通信に依存します。

Mac Studio 192GBなら196,608MiB要求が通る?

この実験からは判断できません。192GiBは判定用profileで、Appleの192GB仕様や実際のusable memoryと同一ではありません。

なぜ3GiBも拒否した?

公開サービス用1GiBを残すとsafe allocatableが2,291.7MiBになったためです。available全量をmodelへ渡さない設計です。

この判定器だけでOOMを完全に防げる?

防げません。runtime overheadcontext、並列数、memory leakもあります。事前判定に加えてcgroup上限、health監視、再試行が必要です。

[PR]
VPSでいろいろ試すなら『XServer VPS』

Mac Studio 192GBか中古RTX 3090×2の悩みは解決した?

判定は一部解決です。どちらを買うべきかは、今回の4GB VPS実験だけでは決められません。しかし、必要量を宣言した4profileのうち、1GiBだけallow、3・48・192GiBを起動前rejectできました。モデルダウンロードとコンテナ起動は0で、公開API、databaseartifact storageも前後とも正常でした。

XServer VPS192GB Macやデュアル3090の代用品ではなく、ジョブの入口で無理な処理を止め、適切なworkerへ振り分ける司令塔として役立ちます。高価な実機を選ぶ前に、VPS、既存PC、APIで不足条件を記録し、その不足を埋める機材だけを検討するのが次の一手です。

コメント

タイトルとURLをコピーしました