- 課金メーターは GPU・ストレージ・帯域の 3 本あり、回り始める時刻も止まる条件も別々であること
- stop / start / reboot / recycle / destroy の 5 操作が、どのメーターを止めて、どのデータを消すか
- 「使い終わって destroy」と「stop したまま放置」で 1 週間の請求がどれだけ開くか(2026-08-24 の実測値で計算)
- 時間あたりの表示価格に帯域費が入っていない理由と、実際の内訳の見方
- 撤収するときに上から順に実行するチェックリスト(volume の消し忘れまで)
課金メーターは 3 本ある
vast.ai の請求は 1 本の料金ではありません。独立した 3 本のメーターの合計です。公式の Billing ページも、この 3 つを「別々の価格・別々の課金」として並べています。ここを 1 本だと思っていると、後で必ず「表示より減りが速い」に出会います。
| メーター | 単位 | 回っている条件 |
|---|---|---|
| GPU(Active rental) | USD/時 | インスタンスが active / connected 状態である毎秒 |
| ストレージ | USD/GB/月 | インスタンスが存在し、かつ online である毎秒。状態は問わない |
| 帯域(Bandwidth) | USD/GB(下り・上り別) | インスタンスに送受信された 1 バイトごと。状態は問わない |
単位の書き方は公式ドキュメントの中で揺れています。Billing ページの散文はストレージを USD/GB/時、帯域を USD/TB と書きますが、search offers が返すフィールドは storage_cost が USD/GB/月、inet_down_cost / inet_up_cost が USD/GB です。本書は実際に自分の目で見る値であるフィールド側に合わせ、USD/GB/月・USD/GB で統一します。
秒課金で、切り上げはない
課金は「Billed by the second」、つまり秒単位です。公式 FAQ は「10 分だけ借りて消したら 1 時間分を取られるのか」という質問に「10 分の利用分だけが課金されます」と答えています。時間単位の切り上げはありません。残高の表示は数秒ごとに更新されます。
回り始める時刻はメーターごとに違います。CLI(= 黒い画面にコマンドを打って操作する道具。本書では vastai コマンドのこと)のガイドの記述が一番はっきりしています。「ストレージ課金は作成時から始まる。GPU 課金はインスタンスが running 状態に達したときから始まる」。Docker イメージ(= コンテナを作るための雛形ファイル。OS とライブラリ一式が固めて入っている)のダウンロード中(コンソールの表示は Loading)は GPU 課金が走らない代わりに、ストレージ課金だけが動いている状態です。公式には「Loading 中は課金されない」と書いたページもありますが、それは GPU 課金に限った話と読むのが、他のページと矛盾しない唯一の解釈です。「Loading 中はタダ」ではありません。
逆に、ホストマシンが Vast のサーバーから切断されている(offline)間は、GPU もストレージも課金されません。これはあなたが操作できることではないので、コスト管理の手段としては数えないでください。
stopped × ストレージのマスが、この章で一番お金を失う場所です。止まって見えるのに GPU 課金が続く状態がある
図 16-1 には出てこない状態がもう 1 つあります。vastai show instances が返す actual_status(= いま実際にコンテナがどうなっているかを表す値)の frozen です。公式の説明は「メモリの内容を保ったまま一時停止している」で、課金欄には GPU charges apply(GPU 課金は発生する)と書かれています。画面上は動いていないのに GPU メーターが回り続ける、唯一の状態です。
ただし frozen に自分から入るためのコマンドは見当たりません。intended_status(= あなたが望んでいる状態)の候補として名前が挙がっているだけで、freeze に相当する CLI コマンドは stop / start / reboot / recycle / destroy のどのリファレンスにも載っていない、というのが公式ドキュメントの現状です。意図して入る状態ではないので、「一覧に frozen が出ていたら、止めたつもりでも GPU 代を払っている」とだけ覚えて、見つけたら中身を退避して destroy してください。
5 つの操作が止めるもの、止めないもの
インスタンスに対してできる操作は 5 つです。名前が似ているので、コマンドと、それぞれが 3 本のメーターとデータに何をするかを 1 枚の表にします。<ID> はインスタンス ID で、vastai show instances の先頭列に出る数字です。表に出てくるコンテナは、借りたマシンの上で動いているあなた専用の実行環境(Linux 一式が入った箱)のことです。
| 操作 | コマンド | GPU 課金 | ディスク課金 | ディスク上のデータ |
|---|---|---|---|---|
| stop | vastai stop instance <ID> | 止まる | 続く | 残る |
| start | vastai start instance <ID> | 再開する | 続く | 残る |
| reboot | vastai reboot instance <ID> | 続く | 続く | 残る |
| recycle | vastai recycle instance <ID> | 続く | 続く | 明記なし |
| destroy | vastai destroy instance <ID> | 止まる | 止まる | 消える |
公式の一行説明も並べておきます。stop は「実行中のインスタンスを停止する」、start は「停止中のインスタンスを起動する」、reboot は「GPU の優先度を失わずにコンテナを停止・起動する」、recycle は「GPU の優先度を失わずに、新しく pull し直した(= 配布元から取得し直した)イメージからコンテナを破棄・再作成する」、destroy は「インスタンスを恒久的に削除する。これは不可逆で、全データを削除する」です。
表のうち reboot と recycle の「GPU 課金は続く」だけは、公式が課金の語で書いていない推論です。根拠は「GPU の優先度を失わない」という一行で、優先度を保つとはその間も GPU の席を押さえ続けることだからです。課金を止める用途に使えないことは、この一点から確実に言えます。
reboot / recycle が脱落するのは、この 2 つが「GPU の席を手放さない」操作だからです。席を押さえている限り 3 本とも回り続けます。2 問目に「残したい」と答えて stop を選ぶと、GPU だけ止まってディスクは払い続ける中途半端な状態になります。recycle でディスク上のデータが残るかは公式ドキュメントに記述がないため、本書は「明記なし」としています。stop は「一時停止」であって「解約」ではない
stop で止まるのは GPU メーターだけです。ディスクは確保したまま残るので、ストレージ課金は 1 秒も止まりません。公式は同じ警告を Storage Types・Pricing・Manage Instances・Billing の 4 か所で繰り返しています。
Storage charges continue even when instances are stopped. Delete instances completely to cease storage billing.
(インスタンスを停止してもストレージ課金は続く。ストレージの請求を止めるには、インスタンスを完全に削除すること)
もう 1 つ、stop には値段以外の代償があります。停止した瞬間に GPU の割り当ては解放され、他のユーザーに貸し出され得ます。これは前払い済みの Reserved インスタンスでも同じです。start で再開すると SCHEDULING 状態に入って GPU の空きを待ちますが、30 秒以上ここから進まないなら、その GPU は他のユーザーに借りられている可能性が高いというのが公式の目安です。待つのをやめるにはもう一度 stop を押します。高優先度のジョブが入っていると、無期限に待つこともあります(この症状の対処は第 17 章にまとめてあります)。
reboot と recycle は「止める」道具ではない
使い分けは単純です。プロセスが固まったときに reboot、イメージを最新版に入れ替えたいときに recycle。どちらも GPU の席を押さえたまま入れ直すので、課金を止める用途には使えません。逆に言えば、stop のように「再開したら GPU が返ってこないかもしれない」というリスクを負わずに、コンテナだけを作り直せるのがこの 2 つの価値です。
recycle については注意が要ります。公式の説明は「コンテナを破棄して新しく pull したイメージから作り直す」「ホスト上で docker の stop / remove を実行する」までで、ディスク上のデータが残るかどうかは一切書かれていません。残る前提で運用しないでください。大事なファイルは先に手元へコピーします。
「止めたまま忘れた」がいくらになるか
ストレージ課金は実際に使った量ではなく、確保した容量に対してかかります。公式 Billing FAQ が「the storage cost (which depends on the size of your storage allocation)」と書いているとおりです。--disk 40 で作ったインスタンスは、中身が 3 GB でも 40 GB 分を払います。しかもディスクサイズは作成後に変更できません(第 7 章)。
月額ストレージ費用 [USD] = storage_cost [USD/GB/月] × 確保した disk [GB]
1 時間あたり [USD/時] = 月額ストレージ費用 ÷ 720 (1 か月を 30 日として計算した場合)
2026-08-24 時点の実測値(1×RTX 5090 / on-demand / 64 件)で当てはめます。storage_cost の中央値は 0.200 USD/GB/月(最小 0.133、最大 0.867 とホスト差が 6.5 倍あります)、GPU の dph_total 中央値は 0.4037 USD/時 でした。
1 つ断り書きがあります。公式は「停止中のインスタンスは、稼働中よりストレージ単価が高いことがある」とも書いていますが、何倍になるかは書かれていません。したがって以下の計算は下限の見積りだと思ってください。止めている間の実額がこれより安くなることはありません。
| 項目 | 計算 | 結果(計算例) |
|---|---|---|
| 40 GB を 1 か月確保 | 40 × 0.200 | 8.00 USD/月 |
| 同じディスクの 1 時間分 | 8.00 ÷ 720 | 約 0.011 USD/時 |
| 同じディスクの 1 日分 | 0.011 × 24 | 約 0.27 USD/日 |
| GPU を 1 時間動かす | 0.4037 × 1 | 約 0.40 USD |
並べると意味が見えます。1 時間だけ使って消し忘れた 40 GB のディスクは、放っておくと 1 か月で GPU 20 時間分の金額になります。1 USD = 150 円として約 1,200 円です。金額としては小さく見えますが、「使っていないのに増え続ける」という性質が問題で、忘れている限り止まりません。
公式の警告はもっと直接的です。
Instances showing in your account are never free, even if your balance is negative or zero.
(アカウントに表示されているインスタンスは、残高がマイナスでもゼロでも、決して無料ではない)
残高が 0 以下になってもメーターは止まりません。インスタンスは自動停止されますが destroy はされず、ディスク課金だけが残高をマイナス方向へ押し続けます(猶予日数は「アカウントの平均日次支出から計算される」とだけ書かれ、具体的な日数は公式に明記されていません)。その後の分岐は第 4 章にあります。
時間あたりの表示価格に入っていないもの
「表示は 0.40 USD/時 なのに、残高の減りが速い」の原因は、ほぼこの節の 2 つです。
1 つ目は、表示価格が想定しているディスク容量です。dph_total(時間あたり総額)は GPU 代とディスク代の合計ですが、検索時のディスク量には既定値があります。CLI の search offers は --storage の既定が 5.0 GiB、REST API は allocated_storage の既定が 8 GB です。つまり検索画面で見た金額は「5〜8 GB しか取らなかった場合」の値であって、実際に 40 GB や 200 GB を確保すればその分だけ上振れします。
2 つ目は帯域です。公式 FAQ の「Why am I getting charged more per hour than expected?」(想定より時間あたりの請求が多いのはなぜか)への回答がはっきり書いています。帯域費は使用量ベースなので、コンソールに出る時間あたり・日あたりの表示価格(cost/hr と cost/day)の内訳には最初から入っていません。単価は価格表示にカーソルを乗せると出る詳細の Internet: セクションで確認します。この詳細は Search ページの offer カードでも、Instances ページのインスタンスカードでも、同じやり方で開けます。
2026-08-24 時点の実測中央値は下り inet_down_cost が 0.0026 USD/GB、上り inet_up_cost が 0.0039 USD/GB でした。15 GB のモデルを Hugging Face(= 機械学習モデルの配布サイト。第 11 章で使います)から落とすと 15 × 0.0026 で約 0.04 USD(計算例)。この水準なら誤差ですが、100 GB クラスのモデルを何度も落とし直す使い方をするなら、offer を選ぶ段階で inet_down_cost を見る価値があります。
実際の内訳は Billing ページの Transaction History → Charges タブで、行のドロップダウンを開くと出ます。画面上は GPU usage / reserved disk storage / upload・download usage に分解され、API 上の同じ内訳は gpu / disk / bwd(下り)/ bwu(上り)の 4 種類です。bwd が大きければ原因はダウンロードだと確定できます。
同じ明細はブラウザを開かずに手元のターミナルからも取れます。毎日の習慣にするならこちらが速いです。
vastai show invoices-v1 --charges
volume は destroy を生き延びる
第 7 章で触れた volume(= インスタンスとは別に作る永続ストレージ。作られた物理マシンに紐づき、同じマシン上の新しいインスタンスに付け直せる)を使った人は、もう 1 本メーターがあります。volume はインスタンスとは別建てで課金され、インスタンスを destroy しても消えません。これは仕様どおりの便利な性質ですが、撤収時には確実に取り残されます。
金額の感覚も持っておいてください。volume の単価も GB 単位・月あたりの storage_cost で、2026-08-24 時点の実測中央値 0.200 USD/GB/月 を当てると、100 GB のモデル置き場は月 20 USD(計算例。1 USD = 150 円として約 3,000 円)です。これはインスタンスを 1 台も持っていない月にも、まるごと請求されます。同じ 100 GB を毎回ダウンロードし直したときの帯域費は 100 × 0.0026 = 0.26 USD なので、「置いておく」より「毎回落とし直す」ほうが桁違いに安いのが実情です。volume を選ぶのは、ダウンロードの待ち時間をお金で買う判断をしたときだけにしてください。
volume の削除には順番があります。attach 済みのインスタンスを先に destroy しないと削除できません(インスタンスが running でも stopped でも同じです)。コンソールなら Storage ページの ⋮ から Delete volume、CLI なら次のとおりです。この操作も不可逆です。
vastai show volumes # 残っている volume の一覧と ID を見る
vastai delete volume <VOLUME_ID> # VOLUME_ID は上の一覧に出た volume の ID
撤収チェックリスト
「作業が終わった」は「課金が止まった」ではありません。次の順番で実行して、最後に自分の目で残高を確認するまでが撤収です。
- 残っているものを全部並べる。
vastai show instancesで一覧を出します。-q(--quiet)を付けると数値 ID だけが 1 行ずつ出るので、複数台をまとめて処理するときの入力に使えます。 - 消す前にデータを退避する。destroy は不可逆で、破棄したインスタンスは一覧で閲覧することすらできません。
vastai copy(第 9 章)で手元へ、または Cloud Sync(= vast.ai 組み込みの同期機能。S3・Google Drive・Backblaze・Dropbox に対応)でクラウドへ出します。この退避はインスタンスが停止中でもできます。公式は「組み込みの 3 手段は停止中のインスタンスに対してもデータを出し入れできる点が独自だ」と書いています。つまりGPU メーターを回さずに退避だけ済ませられるということです。 - destroy する。stop ではディスク課金が止まりません。「後でまた使うかもしれない」は、そのまま毎日 0.27 USD の出費になります。
- volume を別に消す。インスタンスを消しただけでは残ります。
- 前払い済み(Reserved = 前払いして割引を受ける契約。第 6 章)なら返金額を先に見る。削除モーダルに表示されます。すでに受けた割引の巻き戻しと 5% の手数料が引かれます。
- Billing → Charges で内訳を確認する。翌日にもう一度見て、
diskの行が増えていなければ本当に止まっています。
# 1. 残っているインスタンスを確認する(-q なら数値 ID だけが 1 行ずつ出る)
vastai show instances
# 2. /workspace の中身を手元の ./out/ へ退避する(<ID> は上で確認した数字)
# インスタンスが停止中でもこのコピーはできる = GPU 課金は発生しない
vastai copy <ID>:/workspace/ local:./out/
# 3. 破棄する(不可逆。実行前にもう一度 ID を見比べる)
vastai destroy instance <ID>
# 3'. 複数台をまとめて消すときは複数形のサブコマンドに ID を並べる
vastai destroy instances <ID1> <ID2>
# 4. 何も残っていないことを確認する
vastai show instances
この手順を毎回きちんとやる自信がないなら、第 4 章の autobilling 閾値と低残高メールを先に仕掛けておいてください。撤収を忘れても、残高が減り始めた時点でメールが飛びます。手順を守る意志ではなく、仕組みで拾うのが正解です。
GPU 課金を出さずにディスクを掃除する
「ディスクがいっぱいで起動もできない」というときに、起動して掃除しようとすると GPU 課金が発生します。停止中のインスタンスに対しては、起動せずにファイル操作ができます。GPU メーターを回さずに済むので、容量が原因の詰まりはこちらで解きます。
ただし vastai execute で流せるのは ls(一覧)・rm(削除)・du(使用量の集計)の 3 つだけです。df も tar も通りません(それらを使いたいならインスタンスを起動して SSH で入ります)。コマンドはシングルクォートで囲み、結果が返るまで数秒かかることがあります。
vastai execute <ID> 'du -d1 -h' # どのディレクトリが太っているか見る
vastai execute <ID> 'ls -l /workspace/models' # 中に何があるか名前を確かめる
vastai execute <ID> 'rm -r /workspace/models/<フォルダ名>' # <フォルダ名> は上で確かめた不要なフォルダの名前
インスタンスの中から自分を止める
長時間のジョブを流して寝る場合、終わったら自分で消えるようにしておけます。vast.ai のコンテナにはそのインスタンス専用の API キーが環境変数 CONTAINER_API_KEY として入っているので、中から CLI を実行できます。$CONTAINER_ID は自分自身のインスタンス ID が入った環境変数です。このキーはそのインスタンスの start / stop / destroy しかできない制限付きなので、スクリプトに書いても他のインスタンスや残高を触られる心配はありません。
curl -fsSL https://vast.ai/install.sh | bash # コンテナ内に CLI が無ければ入れる
# 下の 2 行はどちらか一方をジョブの最終行に置く
vastai destroy instance $CONTAINER_ID # 3 本とも止める(データも消える)
vastai stop instance $CONTAINER_ID # GPU だけ止める(ディスク課金は続く)
キーが自動で読み込まれない場合は、末尾に --api-key $CONTAINER_API_KEY を付けて明示します。
契約の満了日は自分では延ばせない
すべての offer には最大レンタル期間があり、借りた時点の offer end date がそのまま自分の rental end date になります。この日付は借りた瞬間にロックされ、ホストが offer 側を延長しない限り動きません。満了するとインスタンスは停止し、再起動できません。さらに公式は「満了から 48 時間後に削除されることがある」と警告しています。公式の指示はこうです。
Always assume your instance will be lost once the lifetime expires and copy out any important data before then.
(ライフタイムが切れたらインスタンスは失われるものと常に想定し、それまでに重要なデータをコピーして出しておくこと)
つまずきポイント
止まるのは GPU メーターだけです。ディスクは確保したまま残るので、ストレージ課金は 1 秒も止まりません。40 GB・0.200 USD/GB/月 なら、放置している間ずっと 1 日あたり約 0.27 USD が積み上がります(2026-08-24 の実測中央値での計算例)。しかも stop した瞬間に GPU の割り当ては解放されるので、お金は払い続けているのに席は空けているという一番損な状態です。完全に止めるには destroy しかありません。
課金は確保した容量に対して発生します。使用量ではありません。--disk 200 で作れば、中身が空でも 200 GB 分を払います。しかもディスクサイズは作成後に変更できないので、減らして安くすることもできません。大きめに取ること自体は公式も推奨していますが、その分だけ「消し忘れコスト」も比例して増えることは覚えておいてください。
volume を作っていた場合、それはインスタンスとは別建ての契約です。destroy を生き延び、独立して課金されます。vastai show volumes で残っていないか確認し、不要なら vastai delete volume で消してください。
残高が 0 以下になると停止はされますが destroy はされません。停止中もディスク課金は続くので、残高はマイナス方向に伸び続けます。カードを登録していればそのマイナスは自動課金で埋められ、登録していなければ猶予期間の後にインスタンスとデータごと削除されます。どちらに転んでも自分で選んだ結末ではないので、使い終わったら自分で destroy してください。
理解度チェック
Q1. インスタンスを stop したとき、課金は完全に止まりますか?
止まりません。止まるのは GPU 課金だけで、ストレージ課金は続きます。帯域も、停止中に転送が発生すれば課金されます。3 本のメーターがすべて止まるのは destroy したときだけです。
Q2. 40 GB のディスクを確保したインスタンスを 1 か月止めたまま放置すると、いくらになりますか?
2026-08-24 時点の storage_cost 中央値 0.200 USD/GB/月 で計算すると 40 × 0.200 = 8.00 USD(計算例)です。同じ日の RTX 5090 が約 0.40 USD/時 なので、GPU 20 時間分に相当します。ホスト差が大きく、単価 0.867 のホストなら同じ 40 GB で 34.7 USD/月 になります。
Q3. 表示は 0.40 USD/時 なのに、残高がそれより速く減っています。まずどこを見ますか?
Billing ページの Transaction History → Charges タブで行を開き、内訳(API 上は gpu / disk / bwd / bwu)を見ます。帯域費は使用量ベースなので、時間あたりの表示価格(cost/hr)には最初から含まれていません。bwd が大きければモデルのダウンロードが原因です。disk が想定より大きいなら、検索画面の価格が 5〜8 GB 前提だったことを疑ってください。
Q4. 課金を止めたいとき、reboot や recycle は使えますか?
使えません。どちらも GPU の優先度を保ったままコンテナを入れ直す操作で、席を押さえ続けます。reboot はプロセスを綺麗に起動し直すため、recycle はイメージを新しく pull し直すためのものです。recycle はディスク上のデータが残るかどうかが公式に明記されていないので、実行前に退避してください。
Q5. インスタンスを destroy したのに、まだ請求が発生しています。考えられる原因は?
まず volume です。volume はインスタンスとは別建てで課金され、destroy を生き延びます。vastai show volumes で確認し、vastai delete volume で消します(attach 先のインスタンスを先に destroy しておく必要があります)。次に、消し忘れた別のインスタンスがないかを vastai show instances で確認します。
まとめ
- 課金メーターは GPU(USD/時)・ストレージ(USD/GB/月)・帯域(USD/GB)の 3 本。秒単位で計上され、切り上げはない。ストレージは作成した瞬間から、GPU は
runningになってから回り始める - 5 つの操作のうち 3 本すべてを止められるのは destroy だけ。stop は GPU しか止めず、reboot と recycle は GPU の席を保ち続けるので課金も続く。一覧に
frozenが出ていたら、止まって見えても GPU 課金は発生している - ストレージ課金は確保した容量に対して発生する。2026-08-24 時点の中央値 0.200 USD/GB/月 なら 40 GB で月 8.00 USD、1 日あたり約 0.27 USD(計算例)。止めたまま忘れた 40 GB は、1 か月で GPU 20 時間分
- 時間あたりの表示価格には帯域費が入っていないし、ディスクは 5 GiB(CLI 既定)または 8 GB(REST 既定)しか見込まれていない。ずれを確認する場所は Charges タブの
gpu/disk/bwd/bwu - 撤収は退避 → destroy → volume 削除 → 残高確認の順。volume はインスタンスを消しても残り、契約が満了したインスタンスは再起動できないまま 48 時間で削除され得る
次章では、ここまでで実際に起きる事故を症状から引ける形にまとめます。「接続できない」「GPU が見えない」「ディスクが足りない」を、原因と対処の対応表にしていきます。
参考リンク
- vast.ai — Billing(課金 3 要素・単位・マイナス残高・Billing ページの構成)
- vast.ai — Pricing(秒課金・停止中のストレージ課金の警告)
- vast.ai — FAQ: Billing(10 分利用の課金・Loading 中の扱い・返金)
- vast.ai — Manage Instances(コンソールの状態表示・Scheduling 30 秒の目安)
- vast.ai — FAQ: Instances(ライフタイム・満了後 48 時間・ディスク変更不可)
- vast.ai — Storage Types(コンテナストレージと volume の課金の違い)
- vast.ai — Volumes(作成・attach・削除順序)
- vast.ai CLI — stop instance
- vast.ai CLI — start instance(SCHEDULING とキャンセル方法)
- vast.ai CLI — recycle instance(イメージの pull し直し)
- vast.ai CLI — destroy instance(不可逆・全データ削除)
- vast.ai CLI — destroy instances(複数まとめて破棄)
- vast.ai CLI — show instances(actual_status と課金の対応・frozen・-q)
- vast.ai CLI — execute(停止中でも使える ls / rm / du)
- vast.ai CLI — search offers(storage_cost・inet_*_cost・--storage の既定 5 GiB)
- vast.ai API — Show Charges(内訳 gpu / disk / bwd / bwu)
- vast.ai — Docker Environment(CONTAINER_ID と専用 API キー)