On-demand・Interruptible・Reserved の選び方

3 つの契約を分けているのは優先度

vast.ai は世界中のホスト（= GPU を貸し出す個人やデータセンター）から直接借りる市場です。1 台のマシンに借り手が複数集まったとき、誰を動かして誰を待たせるかを決める規則が要ります。その順番の規則が、そのまま契約の種類になっています。値段の差は順番の結果であって、原因ではありません。

公式が定めている優先度は 3 段です。

1. On-demand と Reserved — 高優先度。中断されない
2. Interruptible で高い入札 — 資源が空いているときに動く
3. Interruptible で低い入札 — より高い入札が終わるまで一時停止

用語を 1 文ずつ定義します。On-demand（= 固定価格で借りる、中断されない契約）。Interruptible（= 入札で借りる契約。自分より高い入札や on-demand の要求が入ると止められる）。Reserved（= 前払いして割引を受ける契約。中断はされない）。作成画面で選べるのは前の 2 つだけで、Reserved は借りたあとに変換して作ります。

「中断されない」には境界が 1 つあります。offer カードの Max Duration（= このマシンで結べる契約の最大期間。第 5 章）です。借りた時点の offer の終了日がそのまま自分のレンタル終了日になり、その日付は借りた瞬間に固定されます。満了するとインスタンスは停止し、公式は「期限切れのインスタンスは期限切れの 48 時間後に削除されることがある。期限切れの状態では再起動できない」と警告しています。On-demand が守るのは「他人に押しのけられないこと」までです。

Interruptible は入札で順位が決まる

Interruptible では価格を自分で宣言します。これが入札額（bid price）（= 1 時間あたりこれだけ払う、と自分で決める額）で、高く入札した人ほど優先度が上がります。offer 側には min_bid（= その offer に入札できる下限額。単位は USD/時）が付いていて、これより低い額では入札できません。

検索するときに種別を bid にすると、表示価格が最低入札額ベースの値に切り替わります。CLI（= ターミナルから打つコマンド）なら -b がその指定で、-d（on-demand）-r（reserved）と切り替えられます。

vastai search offers -b 'gpu_name=RTX_5090 num_gpus=1 rentable=true'

CLI では GPU 名のスペースをアンダースコアに置き換えて RTX_5090 と書きます。REST API（= プログラムから vast.ai を操作するための窓口）に同じ条件を渡すときは、スペース区切りの RTX 5090 で一致しました（2026-08-24 実測）。公式ドキュメントの中でも両方の書き方が混在しているので、検索結果が 0 件で返ってきたら、まずこの綴りを疑ってください。

借りるときは、インスタンス作成時に入札額を渡します。入札額を渡さなければ on-demand として作られます（REST API の price フィールド、CLI の --bid_price）。うっかり Interruptible になることはありません。稼働中に入札額を上げ直すこともできます。

vastai show instances
vastai change bid <インスタンス ID> --price 0.36

<インスタンス ID> には 1 行目の vastai show instances で出てくる自分のインスタンスの番号を入れます。--price の単位は USD/時 で、ここに書いた額が新しい 1 時間単価になります（0.36 なら 0.36 USD/時）。省略すると「勝てる入札額」が自動で使われます。指定できる範囲は 0.001〜32 USD/時で、下限を割ると 400 と Please set a bid price >= 0.001. が返ります。

負けたときに何が起きるかが、この契約の本質です。公式 FAQ の回答は明快で、「インスタンスは停止される（動いているプロセスは kill される）」です。ディスク上のデータは保持されますが、インスタンスは機能しません。優先度が戻れば自動的に再開しますが、再開まで長く待つことがあります。公式が挙げる備えは「頻繁にディスクへ保存」「重要な出力はクラウドストレージへ」「長時間ジョブにはチェックポイント（= 途中経過をファイルに書き出しておき、そこから再開できるようにする作り）を実装」の 3 つ。中断は通知で拾えます（通知種別 client:outbid、表示名は「Instance outbid」。Webhook = 自分のサーバーへ自動で飛ばす通知でも受け取れます）。

中断が頻発するときの公式の対処は 3 つです。① 入札額を上げる ② 需要の低いマシンを選ぶ ③ 重要な処理は on-demand にする（作成時に入札額を渡さない）。AWS の Spot や GCE の preemptible（= どちらも大手クラウドの「安いかわりに中断される」枠）と違い、vast.ai は自分で入札額を決める直接入札です。GCE の preemptible にある「24 時間で必ず止まる」上限のような制限もありません。outbid されなければ無期限に動き続けられます。

実測: 差は 1〜2 割しかない

公式ドキュメントは Interruptible の節約幅を「on-demand より 50% 以上安いことが多い」「コストを 50〜80% 節約」と書いています。ところが RTX 5090 に絞って実際の相場を取ると、この幅は出ません。

次は 2026-08-24 に vast.ai の公開 API から取得した実測値です（1 枚構成の RTX 5090、いま借りられる offer、価格の安い順に 64 件）。表の verified は「vast.ai の内部テストを通ったマシン」という検証状態のことです（第 5 章）。

中央値で比べると 0.4037 USD/時 に対して 0.34 USD/時 前後、割引率は 1〜2 割です。1 USD = 150 円として、60 円/時 が 51 円/時 になるだけの差です。「spot なら半額」は 2026-08-24 の 5090 には当てはまりませんでした。最安値の 0.106 USD/時 はその offer の最低入札額そのものなので、わずかでも高い入札が入れば負ける水準です。

計算例: (0.4037 − 0.34) × 100 時間 = 約 6.4 USD（1 USD = 150 円として約 960 円）

100 時間走らせてようやく 1,000 円弱の差で、その間に何度か中断され再開待ちが入ることと引き換えです。相場は日単位で動くので、判断する前に自分で今日の数字を取ってください。API キーは無くても公開 offer は返ってきました（2026-08-24 実測。公式仕様は Bearer トークン必須と書かれています）。

curl -s -X POST "https://console.vast.ai/api/v0/bundles" \
  -H "Content-Type: application/json" \
  -d '{"limit":64,"type":"bid","rentable":{"eq":true},
       "gpu_name":{"eq":"RTX 5090"},"num_gpus":{"eq":1},
       "order":[["dph_total","asc"]]}'

"type" を "bid" と "ondemand" の 2 回に分けて叩き、返ってきた dph_total（= GPU 代 + 割当ストレージ代の 1 時間単価）を見比べます。"limit" に 200 と書いても返るのは最大 64 件でした。

Reserved は「予約して借りる」ものではない

名前から「先に枠を確保して安く借りる方式」を想像しますが、実際は逆です。まず on-demand で借りて、そのインスタンスにクレジットを前払いして変換します。手順は 2 段階です。

1. Search ページで RENT を押して on-demand として借りる
2. Instances ページのインスタンスカードにある緑の discount badge を押し、前払いできる期間（例: 1 か月 / 3 か月 / 6 か月）から選んで確定する

deposit（= 前払いする金額）と割引率はシステムが自動計算し、変換後はカードに Saved % バッジが出ます。CLI なら次の 2 コマンドです。2 行目を実行した瞬間に、指定した額のクレジット（= vast.ai にあらかじめ入金しておく残高）がそのインスタンスに固定されます。途中でやめると 5% の手数料を取られるので、「このインスタンスを何か月使うか」を決めてから金額を入れてください。

vastai show instances
vastai prepay instance <インスタンス ID> <前払いする USD 額>

<インスタンス ID> には 1 行目の出力に並ぶ自分のインスタンスの番号を、<前払いする USD 額> には 50 のように数字だけを入れます（通貨記号は書きません）。公式ドキュメントに載っている実行例と、その出力がこれです（金額に付く通貨記号だけ外してあります）。

vastai prepay instance 24973511 50
prepaid for 0.546 months of instance 24973511 applying 50.0 credits for a discount of 3.5000000000000004%

末尾の 3.5000000000000004% は浮動小数点の丸め誤差がそのまま表示されているだけで、割引は 3.5% だと読みます。50 USD を入れても 0.546 か月分しかカバーできず、割引は 3.5% しか付いていません。割引率は「前払い額が何か月分をカバーしたか」で決まるので、1 か月分に届かない額ではほとんど意味がありません。上限は公式資料の中で 3 通りに書かれています。ガイドは「最大 50%」、前払い API のリファレンスは「典型的な最大は 40%」で割引率フィールドの範囲は 0.0〜0.4、CLI は「1 か月で 0.2、3 か月で 0.3」。期待値は 2〜3 割、上限は 4〜5 割と幅で見ておくのが正確です。

借りる前に値段を見ることもできます。Search ページで On-demand フィルタを Reserved フィルタに切り替え、必要なら duration フィルタ（例: 1 か月）を設定し、Rent ボタンにマウスを乗せると内訳に Reserved cost のセクションが出ます。CLI なら vastai search offers -r です。

前払いクレジットはそのインスタンスに固定され、Reserved インスタンスは別のホストへ移せません。期中にクレジットを足すと割引が毎回再計算されるため、公式は「期中に少額を足すのは避けよ。かえってレートが悪くなることがある」と警告しています。

早期解約すると、すでに受け取った割引を回収され、さらに 5% の手数料が引かれます。公式の計算例では、on-demand 1 USD/時（= 月 720 USD）、1 か月の Reserved が月 576 USD のとき、即解約なら返金 576 USD、15 日後は残高 288 USD に対して返金約 212 USD、満了までいれば 0 USD です。前払い残高は vastai show deposit <インスタンス ID> で確認できます。

借りたあとに変えられるのは 1 方向だけ

種別は借りる前に決めるものです。公式が挙げている変換の可否はこれだけです。

セレクタを押し間違えたら作り直すしかありません。ディスクサイズが作成時に固定されるのと同じ性質です（第 7 章）。逆に言えば、on-demand で始めておけば後から Reserved に変換する道は開いたままです。公式が「最速の経路」として挙げる 4 点の最後も「まず on-demand で始める（あとから reserved に変換できる）」でした。

どれを選ぶか

公式が用途別に挙げている推奨はこうです。本番推論・時間制約が厳しいジョブは On-demand。ハイパーパラメータ探索（= 設定値を変えながら同じ学習を何度も回す作業）・データ前処理・開発とテストは Interruptible。複数日にわたる学習・定常負荷は Reserved。判断軸は「途中で止まったときに、自分で再開できる作り方をしてあるか」の 1 点です。

GPU を借りるのが初めてなら、最初の数回は On-demand を選んでください。理由は 3 つです。

• 差が小さい。2026-08-24 時点の 1×RTX 5090 では中央値で 1〜2 割、1 時間あたり 10 円ほどの差でしかない
• 切り分けができなくなる。接続が切れたとき、outbid による中断なのか自分の設定ミスなのかを見分けるのは、慣れていないうちは難しい
• 後戻りできる。on-demand は Reserved へ変換できる。逆向きと Interruptible への変更はできない

Interruptible に移るのは、途中結果をディスクへ書き出す形にできてからで十分です。Reserved は同じインスタンスを 1 か月以上使い続けると決まってからで構いません。1 か月に届かない前払いでは割引がほとんど付かないからです。

つまずきポイント

理解度チェック

まとめ

• 3 つの契約は優先度の規則そのもの。On-demand と Reserved は高優先度で中断されず、Interruptible は入札額の順に並び、下位は上位が終わるまで止まる
• Interruptible で負けるとプロセスは kill され、データは残る。再開の時刻は自分では決められない。min_bid は入札の下限で、動く保証の線ではない
• 2026-08-24 時点の 1×RTX 5090 は、中央値 0.4037 USD/時 に対し入札ベース 0.34 USD/時 前後。差は 1〜2 割で、100 時間走らせて約 6.4 USD の違い
• Reserved は「on-demand を借りてから discount badge で前払いに変換する」もの。50 USD の前払いでは割引 3.5%。上限は資料間で 40%〜50% と食い違う
• 変換できるのは On-demand → Reserved の 1 方向だけ。迷ったら on-demand。それが唯一「後から選び直せる」選択肢

次章では、この契約の上に載せるテンプレート（= Docker イメージと起動設定）とディスク容量を決めます。RTX 5090 では CUDA 12.8 以上が必須で、イメージを不用意に変えると 5090 の offer が候補から消えます。

参考リンク

• vast.ai — Instance Types（3 種の比較・優先度・変換可否）
• vast.ai — FAQ: Rental Types（outbid 時の挙動・AWS Spot との違い）
• vast.ai — Reserved Instances（変換手順・返金計算例・警告）
• vast.ai — Pricing（課金の 3 要素と秒課金）
• vast.ai — Billing（課金単位・残高不足時の挙動）
• vast.ai API — Change Bid（入札額の変更と下限 0.001）
• vast.ai API — Prepay Instance（割引率の範囲と 411）
• vast.ai API — Creating Instances（price を省くと on-demand）
• vast.ai API — Search Offers（type と min_bid、dph_total）
• vast.ai CLI — search offers（-b / -d / -r とフィールド一覧）
• vast.ai CLI — prepay instance（既定の割引関数と実行例）