RunPod Global Volumeを試した｜料金の実測とモデル置き場としての使い勝手

📝 本記事にはアフィリエイトリンクが含まれています。

要約

RunPodで2026年9月15日にベータ公開された「Global Volume」を、ACE-Step 1.5 XLのモデル置き場として使ってみました。

Global Volumeは、データセンターに縛られないストレージです。一度作れば、どのリージョンのPodからでも添付できます。

この記事では、作り方とPodへの添付、Hugging Faceからモデルを直接置けたか、実際の請求額、起動時間がどう変わったかをまとめています。

はじめに

僕はRunPodでACE-Step 1.5 XLを動かす公開テンプレートを作っています。このテンプレートは、Podを起動するたびにHugging Faceからモデルをダウンロードする作りなんです。

毎回40〜70秒ほどダウンロードを待つことになるので、モデルをどこかに置いておけたら楽だな、とは前から思っていました。ただ、これまでのネットワークボリュームはデータセンターに紐づくので、GPUの空いているリージョンに合わせて使い分けるのが面倒だったんですよね。

そこに出てきたのがGlobal Volumeです。リージョンに縛られないなら、置いたモデルをどこからでも読めるはずです。本当にそう使えるのか、いくらかかるのかを試してみました。

RunPodの登録がまだの場合は、先にRunPodの始め方ガイドを見てください。

RunPodのGlobal Volumeとは

Global Volumeは、RunPodのストレージの新しい種類です。公式ドキュメントでは、リージョンに依存しない伸縮型のストレージで、どのPodからでも起動時に添付できる、と説明されています。

執筆中の2026年9月28日には、公式ドキュメントにGPUのServerlessエンドポイントへ添付する手順も載りました。ただ、同じ日に僕のコンソールでエンドポイントの設定画面を開いたところ、Global Volumeを選ぶ欄はまだありませんでした。この記事はPodで試した結果です。

用途としては「書き込みは少なく、読み込みが多い」ものが想定されていて、モデルを置いて推論に使うのが代表例です。学習やチェックポイントの保存のように頻繁に書き込む用途は、これまでどおりネットワークボリュームを使うよう案内されています。

ネットワークボリュームとの違い

公式ドキュメントに書かれている範囲で、ネットワークボリュームと比べるとこうなります。

1つのPodには、Global Volume 1個とネットワークボリューム1個まで添付できます。

注意したいのは、Podの起動後にボリュームへ加えた変更は、コンテナ内にすぐ反映されない場合があると公式ドキュメントに書かれている点です。起動した時点の中身を前提にして使う作りになっています。

もう1つ、クレジット残高が$0になると、Global Volumeは15日後に完全に削除されます。置きっぱなしにするなら、低残高通知は有効にしておいたほうが安心です。

料金の仕組み（$0.09/GB/月＋IOPS）

料金は「容量」と「操作（IOPS）」の2本立てです。

容量のほうは $0.09/GB/月 と公開されています。ストレージ一覧の Pricing 列にマウスを乗せると $0.09/GB/month + IOPS と表示されます。作成画面や詳細画面には出てこないので、最初は探しました。

操作のほうは、公式ドキュメントに次の単価が載っています（2026年9月28日に確認）。

ファイル操作1回が、内部では複数のリクエストになることがあるとも書かれています。なので、単価だけでは実際の額が読めません。そこで実際に置いて、Billingに何が出るかを見ました。結果は後半の「料金を実測した結果」にまとめています。

RunPodのほかのストレージの料金はRunPodの料金ガイドで整理しています。

Global Volumeの作り方とPodへの添付

リージョン指定なしで作れる

作り方はシンプルです。

1. 左メニューの Storage を開き、「+ New volume」を押す
2. Storage type で Global volume を選び、名前を入れる
3. 「Create global volume」を押す

作成画面には「Region-independent — No data center selection required」と書かれていて、データセンターを選ぶ欄がありません。容量を決める欄もなく、置いた分だけ増えていく作りです。作った後にできる操作も、名前の変更と削除だけでした。

一覧の Location 列は Any と表示されます。

Podのデプロイ画面で添付する（マウントパス）

添付は、Pods の「+ Deploy」から入ったデプロイ画面で行います。Storage のところにGlobalバッジ付きで並ぶので、それを選ぶだけです。ボリュームの一覧の「⋮」→ Deploy や、詳細画面の「Configure Pod with volume」からも同じ画面に進めます。

リージョンを北米・欧州・特定のデータセンター（EU-FR-1）に絞った場合も、どれでもGlobal Volumeを選べました。

マウントパスの既定は /workspace です。テンプレートの Edit template overrides で書き換えられます。

僕のテンプレートは /workspace にログや出力を書くので、Global Volumeは /runpod-gv にマウントしました。頻繁に書き込むものをGlobal Volumeに置きたくなかったからです。そのうえで、モデルの置き場所を決める環境変数 MODEL_ROOT を /runpod-gv/models/acestep15xl に向けています。

Hugging Faceからモデルを直接置けるか試した

一番気になっていたのがここです。Global Volumeはアトミックリネームやパーミッション設定に対応していません。Hugging Faceのダウンロードは、一時ファイルを作ってから本来の名前にリネームする動きをするので、そこで失敗するのではないかと思っていました。公式ドキュメントにも、Hugging Faceなどからモデルを落とすと警告が出ることがある、と書かれています。

パーミッション警告は出るが最後まで落ちる

結果は、4ファイルとも最後までダウンロードできました。

どのファイルでも、次の警告は出ました。

Could not set the permissions on the file
'/runpod-gv/models/acestep15xl/comfy-files/.cache/huggingface/download/.../....incomplete'
Error: [Errno 1] Operation not permitted
Continuing without setting permissions.

パーミッションを設定できなかったけれど、そのまま続けます、という警告です。公式ドキュメントで予告されていた警告がそのまま出た形ですね。心配していたリネームのほうは、エラーになりませんでした。

条件は RTX 4090 ×1 / EU-RO-1（Secure Cloud）/ テンプレート v3.4.0 です（2026年9月23日）。

書き込み後のボリュームの詳細画面はこうなりました。

モデルは4ファイルなのに、オブジェクトは30個あります。差分はHugging Faceのダウンロードが .cache/huggingface/ に作るメタデータのファイルです。操作課金があるストレージなので、ファイルの数が見えるのはありがたいところです。

コンテナディスクは30MBしか使わない

Podの Telemetry タブを見ると、Container disk usage は 30MB / 100GB でした。

19.9GBのモデルがコンテナディスクではなく、Global Volumeのほうに落ちていることがここから分かります。起動時にダウンロードする方式だと、このモデルがまるごとコンテナディスクに乗るので、コンテナディスクを小さくできる余地もありそうです。

料金を実測した結果

料金は Billing → Billing explorer の「Global Volumes」タブで確認できます。列は Start date / Storage / Requests / Storage billed / Total で、容量の課金（Storage）と操作の課金（Requests）が分かれて出ます。

置いているだけならRequestsは$0

最初にテストで置いたモデル（14.0GB・27オブジェクト。今のテンプレートより1ファイル少ない構成）を5日間そのままにして、6日目に削除しました。そのときの日ごとの請求です。

Requestsが出たのは、書き込んだ9月17日だけでした。モデルを置いてPodを消した後の4日間は、Requestsは$0で、Storageだけが毎日同じ額で出ています。初日のStorage billedが少ないのは、書き込んだのが日の途中だったからだと思います。

ボリュームを削除した9月22日も、Requestsは$0でした。削除には操作の課金が付いていません。Storageはこの日も前日と同じ14.021 GBで出ていました。

5日間の請求はこうだった

容量のほうは、置いていた9月17日〜21日の5日間で合計 $0.050、1日まるごと置いていた日は $0.012 でした。

一方、この構成のときにボリューム詳細画面に出ていた Monthly cost は $1.26 です。こちらは 14.0GB × $0.09 の計算と一致するので、公表単価から出した見積りの表示だと思います。

請求の側からは、この見積りとは違う数字が出ていた、というのが僕の観測です。ベータ期間中の1ボリューム・5日間だけの記録で、課金の締め方もまだよく分かっていないので、ここから単価を言い切ることはしません。実際にいくらかかるかは、Billing explorerの数字で確かめるのが確実です。

モデルを書き込んだ日の請求

今のテンプレートの構成（19.9GB・30オブジェクト）を9月23日に書き込んだ日の請求はこうでした。この日にGlobal Volumeを使ったのは、書き込み用のPod 1台だけです。

書き込み1回分のRequestsは $0.011 でした。最初のテスト（14.0GB・27オブジェクト）のときは $0.009 だったので、どちらも1セント前後です。

書き込んだ後、Podを立てずに置いていた9月24日〜26日は、Requestsは$0でStorageだけが出ています。最初のテストのときと同じ出方でした。

1回起動するといくらかかるか

Global Volumeのモデルを読むPodを起動したときの操作の課金は、Billingへの反映を待って追記します。

計測した9月28日は、Global Volumeを読むPodを何台か起動しています。日ごとの合計でしか出ないので、「計測した日の合計」として載せる予定です。

起動時間は短くなるか：起動時DLと比べた

比較の条件

これまでの「起動時にHugging Faceからコンテナディスクへダウンロードする方式」と、「Global Volumeに置いたモデルを読む方式」を比べました。

モデルを書き込んだのは EU-RO-1 のPodなので、US-MO-1 で起動すると、そのまま「別のリージョンから読めるか」の確認にもなります。

GPUは最初RTX 4090で測るつもりでした。ただ、計測した日は北米のSecure Cloudに4090の空きがなく、両方の方式をH100 SXMでそろえて測り直しています。

終点を「ComfyUIが起動するまで」ではなく「初回生成が終わるまで」にしたのは、Global Volumeの場合はモデルを最初に読み込むタイミングでストレージから読むことになるからです。起動の時点で区切ると、その読み込みの時間が抜けてしまいます。

別リージョンのPodからもそのまま見えた

US-MO-1 のPodで Web Terminal を開くと、EU-RO-1 で書いた4ファイルが同じサイズで見えました。起動ログにも model already exists が4ファイル分出て、ダウンロードはスキップされています。

[start] models: /runpod-gv/models/acestep15xl
[start] model already exists: split_files/diffusion_models/acestep_v1.5_xl_base_bf16.safetensors
[start] model already exists: split_files/text_encoders/qwen_0.6b_ace15.safetensors
[start] model already exists: split_files/text_encoders/qwen_4b_ace15.safetensors
[start] model already exists: split_files/vae/ace_1.5_vae.safetensors

ファイルの所有者は nobody:nogroup、パーミッションは -rw-rw-rw- になっていました。パーミッションを設定できないという公式ドキュメントの説明どおりです。

起動時にダウンロードする方式の結果

これまでのテンプレートのやり方です。3回とも同じサーバーに割り当たり、2回目と3回目はイメージがキャッシュされていました。

Hugging Faceからのダウンロードは、3回とも69秒前後でほとんど揺れませんでした。

Global Volumeから読む方式の結果

同じ条件で、モデルをGlobal Volumeから読んだ結果です。

ダウンロードが無いぶん、ComfyUIが起動するまでは速くなりました。3回目はイメージがキャッシュされたサーバーに当たって、Deployから10秒ほどでComfyUIが開いています。

ところが、初回の生成に10分前後かかりました。1回目は22分以上です。一度モデルが載ってしまえば、2回目の生成は起動時DL方式と同じ11秒前後でした。

1回目のPodでは、途中で僕がComfyUIの画面から別の生成を1本流しています。そのため、1回目の「2回目の生成」だけは条件が少し違います。

Global Volumeから読むと初回生成が遅かった理由

時間がかかっていたのはモデルの読み込み

ComfyUIのログを区間ごとに分けると、時間のほとんどは「Model Initializing」、つまりモデルの重みを読み込む待ちでした。生成の計算そのものは、起動時DL方式と同じくらいの速さです。

待っている間、PodのGPU・CPUの使用率はほぼ0%でした。1回目の生成中に Web Terminal からComfyUIのプロセスが読んだ量を見ると、1秒あたり約7MBずつしか増えていませんでした。

ファイルを頭から読むだけなら速い

Global Volumeそのものが遅いのかを確かめるため、別のPodで拡散モデル（約10GB）を cat で頭から読むだけの時間を測りました。

$ time cat /runpod-gv/models/acestep15xl/comfy-files/split_files/diffusion_models/acestep_v1.5_xl_base_bf16.safetensors > /dev/null

real    0m46.775s
user    0m0.042s
sys     0m9.035s

約10GBが47秒、1秒あたり約213MBです。同じファイルでも、頭から順に読むだけなら47秒、ComfyUIが読み込むと3分半〜12分かかった、という結果でした。

Global Volumeの読み込みの速さそのものではなく、ComfyUIのモデルの読み込み方との組み合わせで遅くなっているようです。ComfyUIがどういう読み方をしているかまでは確かめていません。

コンテナディスクにコピーしてから読むと

そこで、Podが起動した後にモデルをGlobal Volumeからコンテナディスクへ cp でコピーし、ComfyUIにはコピーしたほうを読ませる方法も1回だけ試しました。

コピーした後の初回生成は17.7秒で、起動時DL方式と同じ速さに戻りました。ただ、コピーに3分半かかるので、全体では起動時DL方式より遅いままです。

モデルの置き場所3通りの比較

僕のテンプレートの構成（Hugging Faceにある公開モデル・合計約20GB）では、起動時にダウンロードする今のやり方がいちばん早く生成まで進みました。この日のUS-MO-1では、Hugging Faceからのダウンロードが1秒あたり約280MB出ていたのが大きいと思います。

GPUの時間で見ると、Global Volumeから直接読む方式は、生成を始めるまで起動時DL方式より9分ほど長くPodを動かしていたことになります。H100 SXMは執筆時点で $3.49/時 でした。

使ってみて気になったところ

APIからはGlobal Volumeが見えない

僕はPodの作成や課金の確認を、RunPodのAPI（MCP経由）でも行っています。ところが、執筆時点ではGlobal VolumeがAPIの結果に出てきませんでした。

Global Volumeを添付したPodは、コンソールからしか作れませんでした。課金もコンソールのBilling explorerで確認することになります。自動化や監視を組みたい人は、ベータの間はこの点に注意したほうがよさそうです。

課金は翌日にならないと確認できない

Billing explorerには「Billing data is 1 hour behind」と書かれています。ただ、僕が見た範囲では、日ごとの行はもっと遅れて出てきました。

日ごとの区切りはUTCなので、日本時間だと朝9時で1日が締まります。9月22日（UTC）の行を9月23日に3回見に行ったときは、こうでした。

同じ日の11時台に書き込んだ9月23日分の行も、16時の時点ではまだありませんでした。1回の観測なので毎日この時刻とは限りませんが、その日の操作の課金は、翌日の夕方くらいに見に行くつもりでいたほうがよさそうです。

よくある質問

まとめ

Global Volumeを、ACE-Step 1.5 XLのモデル置き場として試しました。

• データセンターを選ばずに作れて、北米・欧州のどちらに絞ったPodのデプロイ画面でも選べた
• Hugging Faceからの直接ダウンロードは、パーミッション警告は出るものの最後まで通った
• モデルを置いているだけの日は、Requestsは$0で、Storageだけが出ていた
• EU-RO-1で書いたモデルが、US-MO-1のPodからそのまま見えた
• APIからは見えないので、作成も課金の確認もコンソールで行う
• ダウンロードが無いぶんComfyUIの起動は速くなったが、ComfyUIから直接読むと初回の生成まで10分前後かかった
• ファイルを頭から読むだけなら約10GBが47秒で、コンテナディスクへコピーしてから読むと約4分44秒まで縮んだ
• それでも、Hugging Faceから起動時にダウンロードする方式（約1分39秒）のほうが早かった

今回の結果だけで言えば、Hugging Faceから取れる公開モデルなら、起動時にダウンロードするやり方で十分だと感じました。

Global Volumeが活きてきそうなのは、Hugging Faceに置いていないモデル（自分で作ったLoRAや非公開のモデルなど）を、GPUの空いているリージョンを選ばずに使いたい場合です。この使い方は今回まだ試していないので、試したら追記します。

ベータの間は仕様も料金も変わりうるので、使う前に公式ドキュメントとBilling explorerで確かめてください。この記事も、検証を進めて追記していきます。

紹介リンクから登録して$10をチャージすると、$5〜$500のクレジットがランダムでもらえます（Googleアカウントでの登録が対象です）。