テンプレートとディスク容量

テンプレートは「新しいインスタンスのためのレシピ」

公式の説明でいちばん短いのは「テンプレートは docker run のラッパーだと考えてよい」です。Docker（= アプリと必要なライブラリをまとめて持ち運べる箱にする仕組み）のイメージを 1 つ選び、そこに起動の仕方・環境変数・公開ポート・ディスクの既定値を添えた設定の束が、テンプレートです。vast.ai ではすべてのインスタンスがテンプレートを必要とします。「テンプレートを使わない」という選択肢はありません。

置き場所は Templates ページで、テンプレートカードの鉛筆アイコンを押すと編集画面（Config タブと ReadMe タブの 2 枚）が開きます。初心者が触るべき欄は多くありません。まず全体像を押さえます。

この章でいちばん重要なのは、次の 1 点です。テンプレートは「新しいインスタンスのためのレシピ」であり、すでに作ったインスタンスには適用できません。公式ドキュメント（Templates Introduction）の見出しがそのまま「Can't Change Template on Existing Instance」で、回答は「テンプレートの変更は新しいインスタンスにしか影響しない」「別のテンプレートを使うには新しいインスタンスを作る」「必要ならデータ移動ツールでデータを移す」の 3 行です。動いているインスタンスの設定を直したくなったら、直す先はインスタンスの中身（SSH（= 遠くのコンピューターに安全にログインする仕組み）で入ってコマンドを打つ）か、作り直しのどちらかになります。

作り方の指針も公式が明言しています。「ゼロから作るより、推奨テンプレートから始めて改造せよ。互換性が確保され、起動も速くなる」。改造版は「My Templates」に自分のコピーとして保存されるので、元の推奨テンプレートが壊れることはありません。

Blackwell は CUDA 12.8 必須 — イメージを変えると 5090 が消える

RTX 5090 は Blackwell（= NVIDIA の GPU アーキテクチャ世代の名前。RTX 5090 / 5080 / 5070 / 5060 がこの世代）の GPU です。ここに vast.ai 公式が特別な警告を出しています。「Blackwell GPU は、以前の世代の NVIDIA GPU に見られたような後方互換性を持たない。したがってテンプレートと Docker イメージが CUDA 12.8 と PyTorch 2.7 以上を使うよう設定されていることが重要である」。CUDA（= NVIDIA の GPU を計算に使うためのソフトウェア基盤）のバージョンは、借りたマシン側ではなく自分が選んだ Docker イメージが決めます。技術 FAQ も「CUDA バージョンは Docker イメージに依存する」と明記しています。正確には、マシン側のドライバが「ここまでなら動く」という上限（画面では Max CUDA version、API では cuda_max_good）を決め、その上限の範囲内で実際にどの CUDA を使うかをイメージが決める、という二段構えです。

そして、この要件が検索結果の中身を変えます。公式の記述はこうです。「このタイプの GPU と互換であることが分かっているテンプレートは、offer リストに自動的にこれらの GPU を表示する。対応していないテンプレートは、検索時に非対応カードを除外する」。つまり offer 一覧に何が出るかは、選んでいるテンプレート次第です。5090 を狙って検索しているのに 1 件も出ないとき、疑うべきは在庫ではなく手元のテンプレートです。

ここで安心できる実測があります。2026-08-24 に公開 API から取った 1×RTX 5090 の on-demand offer 64 件では、マシン側が対応する CUDA の上限（cuda_max_good）は 12.8 / 12.9 / 13.0 / 13.1 / 13.2 / 13.3 のいずれかで、12.8 未満は 1 件もありませんでした。ドライバも 570.x〜580.x 系です。ホスト側はすでに要件を満たしています。ボトルネックになるのは自分が選ぶ Docker イメージだけという構図です。

だから公式は、RTX 5000 系を借りる手順の中で名指しの警告を出しています。「Docker イメージを変更してはならない。CUDA 12.8 と PyTorch の dev バージョンを維持する必要があるからだ。互換性のない Docker イメージに切り替えると、5 シリーズの互換性を失う可能性がある」。なお同じページの冒頭は「PyTorch 2.7 以上」と書いており、dev / nightly が必須なのか 2.7 以上の安定版で足りるのかは公式内で表現が揺れています。迷うなら次の [Automatic] に任せるのが安全です。

[Automatic] タグが代わりに考えてくれる

Version Tag の欄で選べる [Automatic] は、借りるマシン自身の CUDA バージョンと互換な最新イメージを pull（= ダウンロード）する特殊なタグです。推奨テンプレートでは既定でこれが入っています。仕組みには前提が 1 つあります。イメージのタグに CUDA バージョンの文字列が含まれている場合にのみ機能します。公式の例では my-image-cuda-12.8 は CUDA 12.8 対応マシンで読み込まれ、CUDA 12.6 しか持たないマシンでは my-image-cuda-12.6 が取られます。RTX 5 系を借りるための公式手順も、Step 2 が「Version Tag に [Automatic] が設定された推奨テンプレートを選べ（これが既定のオプション）」です。

逆に、自分でタグを固定しなければならない場面もあります。公式の新しめの実行例は 3 本とも「latest タグでは動かない」と明記しており、MiniMax-M2 は vllm/vllm-openai:nightly、GLM-4.7-Flash は lmsysorg/sglang:dev-pr-17247 を名指しで要求します。新しいモデルを追いかけるときは latest が罠になり、タグを固定するのが正解です。この判断が必要になるのは第 13 章以降で、いま覚える必要はありません。

launch mode で、起動後に立つプロセスが変わる

Select Launch Mode の 3 択は、コンテナが立ち上がった直後に何のプロセスが動いているかを決めます。画面の表記そのままで並べます。

用語を 1 文で置きます。Jupyter（= ブラウザ上でコードを打って実行できる作業環境）。ENTRYPOINT（= Docker イメージに焼かれた「起動したらこれを実行する」コマンド）。sshd（= SSH の接続を受け付ける側で動くプログラム）。推奨テンプレートは通常 Jupyter モードで起動します（アクセスがいちばん簡単なため）。

この置き換えが、初心者が最初に踏む罠です。公式の警告をそのまま引きます。「Jupyter モードと SSH モードのどちらでも、イメージの docker entrypoint は実行されない。vast のインスタンスセットアップスクリプトに置き換えられる。だからサービスの起動には on-start セクションを使え」。加えて具体的な作法まで書かれています。「イメージの ENTRYPOINT または CMD コマンドを探し、on-start セクションの末尾でそのコマンドを呼べ」。自前のイメージで「Web UI が開かない」「API が応答しない」というときは、たいていこれが原因です。

逆方向の失敗もあります。docker ENTRYPOINT モードは SSH も Jupyter も入れないので、そのままでは中に入れません。ただしトラブル時の逃げ道としては有効で、「カスタムイメージで SSH や Jupyter モードに不明瞭なロードエラーが出るなら、よりシンプルな Entrypoint モードを試して、SSH や Jupyter は自分でセットアップせよ」という公式 Tip があります。

どちらを選ぶかは用途で決まります。公式の判断材料から初心者に効くものだけ挙げると、Jupyter を選ぶのは SSH をブロックする会社のネットワークの内側にいるとき、ブラウザが切断されても生き残る永続ターミナルが欲しいとき。SSH を選ぶのは VS Code の Remote-SSH のような IDE 統合を使うとき、scp や rsync でファイルを頻繁に送るときです。第 8 章では SSH モードで 1 台借ります。

コマンドから作る場合は、CLI（= ターミナルから打つコマンド）の --ssh / --jupyter / --direct（proxy を経由しない直接接続）の組み合わせで指定します。末尾が _direct の起動種別だけがインスタンス自身にポートを用意し、_proxy 系は vast.ai のインフラ経由でルーティングします（第 9 章）。

イメージを変えずに中身を足す

「このライブラリを入れたい」「起動時にこのモデルを落としておきたい」。イメージ欄を書き換えたくなる動機はここですが、5090 を使う限りその道は塞がっています。公式が用意した迂回路が 2 本あります。

① On-start Script（短い初期化）

インスタンス起動中に走る短い Bash スクリプト（= Linux のコマンドを上から順に並べて書いたもの）です。Jupyter または SSH モードのときだけ利用できます。Entrypoint モードを選ぶと、この欄の代わりに「entrypoint に引数を渡す欄」が画面に追加されます。最も有用な用途は公式の言葉どおり「entrypoint が実行されていたらイメージが起動していたはずのサービスを立ち上げる」ことです。

ここに文字数の上限があります。API リファレンスは onstart フィールドは 4048 文字（4096 ではありません）と明記し、「より長いスクリプトは gzip+base64 せよ」と添えています。画面の On-start Script 欄にも同じ上限が掛かるかどうかは公式ドキュメントに明記がありませんが、同じ値が効く前提で設計しておくのが安全です。いずれにせよ、初心者が gzip+base64 まで行く必要はありません。長くなったら次の PROVISIONING_SCRIPT に移します。

もう 1 つ、公式が強く指示している 1 行があります。SSH / Jupyter モードでは、自分で設定した環境変数が SSH・tmux・Jupyter のセッションから既定では見えません。見えるようにするには on-start から /etc/environment に書き出します。vast.ai が公開しているイメージでは entrypoint 側で自動的に処理されるので、これが必要なのは他人が作ったイメージを使うときです。

env | grep _ >> /etc/environment

CLI から同じことをするならこう書きます。<OFFER_ID> には検索結果で選んだ offer の ID（第 5 章の一覧に出る数字）を入れます。--disk 80 は確保するディスク容量（GB）で、決め方は 5 節・6 節で扱います。--image vastai/pytorch は vast.ai 自身が配っているベースイメージです。5090 を借りるなら、ここを別のイメージに差し替えないでください（2 節）。

vastai create instance <OFFER_ID> --image vastai/pytorch --disk 80 \
  --ssh --direct \
  --onstart-cmd "env | grep _ >> /etc/environment"

② PROVISIONING_SCRIPT（長い初期化）

環境変数としてスクリプトの URL を渡す方式です。中身は URL の先にあるので文字数の制限を受けません。公式はこれを「どの Docker イメージでも動く / Docker のビルドが不要でもっともシンプル / パッケージのインストール・モデルのダウンロード・サービスの設定に最適」と位置づけています。手順は次のとおりです。

1. Templates ページで base-image または Pytorch を検索する
2. 選んだテンプレートの Edit をクリックする
3. Environment Variables セクションに PROVISIONING_SCRIPT という変数を追加し、値に shell スクリプトを指す URL（GitHub や Gist）を入れる
4. 「+」をクリックして環境変数を追加する（押し忘れると保存されません）
5. Create and Use をクリックする

スクリプトは初回起動時に走ります。インストール先は /workspace/ に置くのが公式の指示です。中身の骨格も公式が示しています（/venv/main/bin/activate は vast.ai のベースイメージに入っている Python 仮想環境です）。

#!/bin/bash
cd /workspace/
set -eo pipefail
. /venv/main/bin/activate
pip install your-packages

ディスク容量を決める数字は 3 か所にある

ここが初心者の事故がもっとも多い場所です。ディスク容量に見える数字は 3 か所にあり、実際の割当を決めているのは 1 つだけです。

公式の言い方は端的です。「ディスク容量は検索インターフェースで設定する。テンプレートではない」「既定は 10 GB。必要に応じて増やせ」「インスタンス作成後は変更できない」。既定値が資料によって 8 と 10 に分かれているのは、Web の画面と API で別の既定を持っているためです。自分でスライダーを動かせばどちらも関係なくなります。

「変更できない」は複数のページで繰り返されています。FAQ の回答は「No. ディスクサイズは恒久的で、インスタンス作成後に変更できない」。足りなくなったときに公式が挙げる選択肢は 3 つだけです。① より大きいディスクで新しいインスタンスを作ってデータを移す ② volume（= インスタンスとは別建ての永続ストレージ。destroy しても生き残る）を attach して容量を足す ③ クラウドストレージをあふれ分として使う。ただし ② の volume は作られた物理マシンに紐づき、同じマシンの上のインスタンスにしか付けられません。しかも増えるのはマウント位置（GUI から作った場合の既定は /data）に生える別領域で、pip install や Docker イメージの展開先そのものが広がるとは公式ドキュメントに書かれていません。「イメージが大きすぎてディスクに入らない」型の失敗は volume では救えないと考えておくのが安全です。

課金の条件も押さえます。公式 Billing FAQ の文言は「ストレージ確保サイズに依存した料金を、インスタンスが存在しオンラインである毎秒課金する」です。使っていなくても確保した容量ぶん全額が課金対象で、ストレージ課金は作成した瞬間から（GPU 課金は running になってから）始まり、stop では止まりません。止める唯一の方法は destroy です。

ディスクの月額 = 確保 GB × storage_cost（USD/GB/月）

2026-08-24 時点の 1×RTX 5090 の offer 64 件では storage_cost の中央値が 0.20 USD/GB/月 でした。計算例: 80 GB を 1 か月確保すると 80 × 0.20 = 月 16 USD（1 USD = 150 円として約 2,400 円）、500 GB なら月 100 USD。GPU を 1 時間だけ使った 0.40 USD より、置きっぱなしのディスクのほうが高くつきます。

では何 GB 取ればいいのか

ディスクの中身は 4 つに分かれます。イメージ本体 ＋ モデルのダウンロードキャッシュ ＋ 使うモデルファイル ＋ 作業領域（ログ・出力・チェックポイント）。このうち最初に効くのはモデルです。第 3 章の式（重み GB ＝ パラメータ数 × 1 パラメータあたりのビット数 ÷ 8）で計算すると、8B（= 80 億パラメータ）を bf16（= 1 パラメータを 16 ビットで持つ形式）で落とせば 16 GB、32B を 4 bpw（bits per weight = 1 パラメータあたりのビット数。小さいほど軽くなる代わりに粗くなる）の量子化で落とせば 16 GB。モデル 1 個で 16 GB 前後というのが、この本の主役の相場です。

推測で決める必要はありません。公式ガイドが構成ごとに実数を書いているので、近いものに合わせるのが確実です。表の VRAM（= GPU 側に載っているメモリ。RTX 5090 は 32 GB）はディスク容量とは別物なので、混同しないでください。ディスクが足りていても VRAM が足りなければモデルは動きません。

キャッシュの位置も知っておくと無駄が減ります。Hugging Face（= モデルの配布サイト）からダウンロードしたファイルは既定で ~/.cache/huggingface/hub に入ります。置き場所は環境変数 HF_HOME で変えられ、何が溜まっているかは hf cache ls、消すのは hf cache rm や hf cache prune です。キャッシュに落としたものを別フォルダにコピーすると、同じ重みが 2 か所を占めます。16 GB のモデルなら 32 GB です。

足りなくなってからでも打てる手はあります。稼働中の空き容量は df -h で見ます。Jupyter で削除したファイルはゴミ箱に残るので rm -r ~/.local/share/Trash まで実行しないと空きません。そして停止中のインスタンスでも、起動せずにファイルを消せます（= GPU 課金を発生させずに掃除できる）。<INSTANCE_ID> は vastai show instances に出る自分のインスタンスの番号、big-model-file.gguf は消したいファイルの名前に置き換えます（1 行目で名前と容量が分かります）。vastai execute で使えるコマンドは ls / rm / du の 3 つだけです。

vastai execute <INSTANCE_ID> 'du -d1 -h'
vastai execute <INSTANCE_ID> 'rm big-model-file.gguf'

最後に、借りたマシンの CUDA とディスクを起動直後に確かめる 3 行を置きます。1 行目と 2 行目が CUDA の確認（公式が挙げている方法）、3 行目がディスクです。nvidia-smi が「No devices were found」を返したら、そのマシンは壊れています。公式の指示は「レンチアイコンからマシンを report して、別のマシンを借りろ」です。

nvidia-smi
nvcc --version
df -h /

つまずきポイント

理解度チェック

まとめ

• テンプレートは docker run のラッパーで、新しいインスタンスのためのレシピ。すでに動いているインスタンスには効かない。改造するなら推奨テンプレートのコピーから始める
• RTX 5090（Blackwell）は後方互換性を持たないので CUDA 12.8 / PyTorch 2.7 以上が要件。イメージ欄を書き換えると offer 一覧から 5090 が消える。Version Tag は [Automatic] のままにする
• 2026-08-24 時点の実測では、1×RTX 5090 のホストは全件が CUDA 12.8 以上に対応していた。ボトルネックはホストではなく自分が選ぶイメージ
• launch mode は起動後に立つプロセスを決める。Jupyter / SSH モードではイメージの ENTRYPOINT が置き換えられるので、サービスは On-start Script（API の onstart は 4048 文字上限）か PROVISIONING_SCRIPT（URL 指定なので文字数制限なし）で立てる
• ディスクの実際の割当を決めるのは検索ページのスライダー。既定 10 GB、作成後は変更不可、課金は確保容量ぶんで stop では止まらない。モデル 1 個で 16 GB 前後を見込み、余らせる側に振る

次章では、ここまでの知識を使って実際に 1 台借ります。SSH 鍵を登録し、テンプレートを選び、Rent を押して起動を確認するまでを 15 分・0.2 USD 程度で通します。

参考リンク

• vast.ai — RTX 5 Series（CUDA 12.8 要件とイメージ変更の警告）
• vast.ai — Template Settings（全項目と [Automatic] タグ、launch mode 3 択）
• vast.ai — Templates Introduction（既存インスタンスには適用できない）
• vast.ai — Creating Templates（推奨テンプレートから改造する）
• vast.ai — Advanced Setup（PROVISIONING_SCRIPT の手順と例）
• vast.ai — Choosing Templates（ディスクは検索側で設定する）
• vast.ai — Storage Types（リサイズ不可・停止中も課金）
• vast.ai — Docker Environment（環境変数とポート、割当は静的）
• vast.ai — FAQ: Instances（ディスクサイズは変更できない）
• vast.ai — FAQ: Billing（確保サイズに対する毎秒課金）
• vast.ai — CUDA（launch mode の選び方、nvidia-smi の異常時）
• vast.ai — PyTorch（/venv/main/、必要ディスクの目安）
• vast.ai API — Create Template（onstart は 4048 文字）
• vast.ai — Templates ページ（テンプレートの一覧と編集）