つまずき集とトラブルシュート

最初の 1 手は「いまどの状態か」を見ること

vast.ai のトラブルは、症状の名前で分類しても解けません。同じ「繋がらない」でも、インスタンスがまだ起動していないのか、起動しているのに鍵が違うのかで、やることが正反対になるからです。だから最初の 1 手は必ず「状態の確認」です。

ここで最初の壁になるのが、vast.ai には状態を表す語彙が 2 系統あることです。Web コンソール（cloud.vast.ai）のインスタンスカードに出る大きなボタンの文字と、CLI（= 手元の端末に vastai というコマンドを入れて操作する方式）や API（= プログラムから操作するための窓口）が返すフィールドの値は、名前が一致しません。両方を突き合わせられるようにしておきます。

intended_status が running なのに actual_status が running でないなら、それは「あなたは動かしたいのに動いていない」という状態です。この 2 つのズレが、この章のほとんどの症状の正体です。

vastai show instance <ID>                  # ID はインスタンスカードに出ている数字（例: 12371）
vastai show instances-v1 --status exited    # 状態で絞って一覧する
vastai logs <ID> --tail 100                 # コンテナのログを末尾 100 行だけ見る
vastai logs <ID> --daemon-logs              # コンテナではなく、ホスト側デーモンのシステムログ

--status に指定できるのは running / loading / exited の 3 つだけです。コンソール派なら、インスタンスカードの Logs ボタンで同じログがライブで流れます。起動直後は「waiting on logs」と出ることがあるので、少し待って開き直してください。

この章では対処として同じ 2 つの操作が繰り返し出てきます。先に意味だけ決めておきます。1 つは destroy（= インスタンスを完全に破棄する操作。ディスクのデータは消えますが、GPU 課金もストレージ課金も止まります）。もう 1 つは report（= インスタンスカードのレンチアイコンを押して「このマシンはおかしい」と Vast へ報告する操作）です。どちらも「このマシンを諦めて別のマシンに移る」ための操作で、ホスト側が原因の症状ではこれが公式の対処そのものになります。

running に届かない

借りたのに使えるようにならないケースです。コンソールのボタン表示が、いまどこで止まっているかを教えてくれます。なお、無事に running まで到達したインスタンスは、コンソール側では Open（クリックでブラウザからアクセス）または Connect（クリックで SSH 情報を表示）というボタンに変わります。この 2 つが出ていれば「ロードは終わっている」という意味です。

Loading 中に GPU 課金は始まりません（GPU の課金は running に達してからです）。ただしストレージ課金は作成した瞬間から動いているので、「Loading 中はタダ」ではありません。この点は公式ドキュメントの中でも書き方が揺れていて、FAQ には「Loading 中は課金されない」とだけ書かれたページがある一方、CLI と SDK の Hello World ページは「ストレージ課金は作成時から、GPU 課金は running に達してから」と書き分けています。安全側に倒して「ディスク代は作った瞬間から発生している」と考えてください。

Creating や Loading から進まないのが自分で指定した Docker イメージのときは、原因がイメージ側にあることがよくあります。SSH と Jupyter のランチモード（= インスタンス作成時に選ぶ接続方式）は、既存のイメージにセットアップスクリプトを注入する実装なので、イメージ本来の entrypoint（= コンテナ起動時に最初に実行される命令）が呼ばれなくなります。公式の回避策は 2 つです。素の Entrypoint ランチモードに切り替えて SSH や Jupyter を自分で立てること、そして元の entrypoint の中身を onstart（= インスタンスが起動するたびに自動実行されるスクリプト）へ移すことです。

二度と running にならない 3 つの状態

この章で一番損害が大きい罠です。actual_status が exited（コンテナが予期せず終了）・unknown（ホストからの生存信号が来ていない）・offline（ホストが切断）になったら、そのインスタンスは二度と running にはなりません。公式 API リファレンスも「Poll trap」という見出しで同じ警告を出しています。

起動を待つスクリプトを書くときは、公式の推奨どおり 10 秒間隔でポーリング（= 一定の間隔で状態を問い合わせ続けること）し、この 3 つの値を見たら即座に打ち切るようにします。通常の起動時間はイメージのサイズ次第で 1〜5 分です。終端状態のチェックもタイムアウトも無いループを回すと、永久に待ちながらディスク課金だけが積み上がります。ポーリングそのものを避けたいなら、onstart スクリプトから「準備できた」というコールバック（= 完了をこちらへ知らせる通知）を送らせる方法も公式に案内されています。

stop したら戻れなくなった

公式トラブルシューティングの筆頭に置かれている症状です。停止したインスタンスを再開しようとすると Scheduling に入り、そこから進まなくなります。

仕組みはこうです。stop すると、あなたが使っていた GPU は解放され、他のユーザーに貸し出される可能性があります。start は「その GPU を取り戻す」動作なので、すでに他のジョブが乗っていると、そのジョブが終わるまで待たされます。公式は「しばらく待つリスクを受け入れられないなら、インスタンスを停止しないこと」とまで書いています。

実務上の判断基準は明快です。Scheduling が 30 秒を超えたら、その GPU は他のユーザーに借りられていると考えてよいと公式が書いています。キャンセルするには停止ボタンをもう一度押します。空くのを無期限に待つ可能性があるので、データを新しいインスタンスへコピーする方が早いことがほとんどです。

そもそも待ち行列に並ばずに済ませる方法が 2 つあります。どちらも「GPU の優先度を失うリスクなしに」と公式が明記しているコマンドです。

vastai reboot instance <ID>    # コンテナを stop / start し直す（プロセスを綺麗に入れ替えたいとき）
vastai recycle instance <ID>   # イメージを新しく pull し直してコンテナを作り直す

もう 1 つ、待っても復活しない停止があります。契約の満了（lifetime 切れ）です。offer（= ホストが出している「この GPU をこの値段で貸します」という 1 件の募集。検索結果に並ぶ 1 行）には最大レンタル期間があり、借りた時点の終了日がそのままあなたの契約終了日として固定されます。満了したインスタンスは再起動できず、満了から 48 時間後に削除されることがあります。延長はホストの裁量なので、期限が来たら失われる前提でデータを退避してください。

入れない・開かない

running なのに手元から届かないケースです。ここから先はほぼすべて手元の設定で直ります。

SSH がパスワードを聞いてくる / Permission denied

大前提として、vast.ai に SSH（= 遠くのコンピューターに安全にログインする仕組み）のパスワードは存在しません。鍵認証だけです。パスワードを聞かれたら、それは「鍵が届いていない」というサインです。まず秘密鍵が読み込まれているかを確認します。

ssh-add; ssh-add -l              # 秘密鍵をエージェントに読み込み、読み込まれた一覧を表示
cat ~/.ssh/id_ed25519.pub        # 公開鍵を表示する（この出力を「全部」コピーする）
chmod 600 ~/.ssh/id_ed25519      # 秘密鍵の権限を自分だけに絞る
ssh -vv -p <PORT> root@<IP>      # PORT と IP はインスタンスの Connect ボタンに出ている値

公開鍵を cloud.vast.ai/manage-keys に貼るときの定番ミスが 1 つあります。先頭の ssh-rsa（または ssh-ed25519）から末尾の user@host まで、1 行を丸ごと貼ってください。真ん中の長い文字列だけでは動きません。Permission denied (publickey) が出たときの公式の手順も、①アカウントに鍵が登録されているか ②正しい秘密鍵を使っているか ③パーミッション ④-vv で詳細ログ、の順です。接続直後の失敗は数秒待って再試行すると通ることがあります。

vastai attach ssh <ID> "$(cat ~/.ssh/id_rsa.pub)"   # 動いている Docker インスタンスに鍵を後付けする

ファイル転送で詰まる原因の 8 割はオプションの大文字小文字です。scp と sftp はポート指定が大文字の -P、ssh は小文字の -p。公式ドキュメントもわざわざ注意書きを入れています。

Jupyter の警告とポートの行方

Jupyter（= ブラウザの中でコードを書いて実行できるノートブック環境。Jupyter ランチモードで作ったインスタンスに付いてきます）を開こうとして「この接続は保護されていません」と出るのは、自己署名証明書（= 公的な認証局を通さず自前で発行した証明書）を使っているためです。Windows と Linux は警告画面の Advanced（詳細設定）→ Proceed（アクセスする）で押し通せますが、macOS は証明書をインストールしないと OS がページを開かせないことがあります。証明書は jvastai_root.cer をダウンロードして入れます。

入れ方と「いつから効くか」は OS で違います。macOS はファイルをダブルクリックすると Login キーチェーンに入るので、キーチェーンアクセスで Vast.ai Jupyter というエントリを開き、Trust の When using this certificate を Always Trust に変えます。これは稼働中のインスタンスにも将来のインスタンスにも即座に反映されます。Windows はファイルをダブルクリック → Install Certificate → Place all certificates in the following store を選んで Trusted Root Certification Authorities を指定します。この手順ではマシンの再起動が必要で、しかも Chrome の設定画面から入れた場合は新規に作るインスタンスにしか効かず、既存のインスタンスには警告が残ります。Linux の Chrome は設定から Manage Certificates を開き、Authorities タブでインポートします。

「ポートを開けたのに繋がらない」は仕組みを知れば一撃です。vast.ai のインスタンスは自分専用の IP を持たず、開放した内部ポートは共有 IP 上のランダムな外部ポートに割り当てられます。内部 8081 が外部 33526 になる、といった具合です。対応表はインスタンス上部の IP Port Info ポップアップに出ます。疎通確認は公式が強く勧めている次の 1 行が確実です。

python -m http.server 8081       # インスタンス側で実行し、ブラウザで PUBLIC_IP:EXTERNAL を開く

ファイル一覧が出れば経路は生きています。なお1 インスタンスあたりの開放ポートは合計 64 個までです。

作ったあとで「このポートも開けておけばよかった」と気づいたときの救済もあります。Vast.ai 製の base image を使うテンプレートには Instance Portal（= Open ボタンを押したときに最初に出る、インスタンス内で動く Web アプリへのリンクを並べたページ）が入っています。その Tunnels ページの入力欄に http://localhost:7860 のようにアプリの待ち受け先を書いて Create New Tunnel を押すと、そのポート用のトンネルが作られます。テンプレート作成時にポートを設定していなくてもアクセスできるようになるので、インスタンスを作り直さずに済みます（押した直後は使えるようになるまで少し待ちます）。

SSH そのものが死んでいてファイルを触りたいときは、限定コマンドの実行が使えます。

vastai execute <ID> 'du -d2 -h'   # 実行できるのは ls / rm / du の 3 つだけ。結果が出るまで数秒かかる

細かいところでは、Jupyter でファイルを削除しても空き容量が増えないという相談があります。Jupyter は削除をゴミ箱への移動として扱うためで、rm -r ~/.local/share/Trash で恒久的に消えます。

GPU が見えない・CUDA が動かない

入れたのに GPU が無い、という状況です。まずこれを打ちます。

nvidia-smi

No devices were found のような出力が返ってきたら、自分で直そうとしないでください。公式の対処はただ 1 つ、レンチアイコンからマシンを report して、別のマシンを借りるです。これはホスト側のハードウェアかドライバーの異常であり、コンテナの中でできることはありません。2026-08-24 時点の実測では 1× RTX 5090 の相場は中央値 0.4037 USD/時（1 USD = 150 円として約 61 円）なので、1 時間粘るより 5 分で乗り換える方が確実に安く済みます。

GPU は見えているのに CUDA（= NVIDIA の GPU で計算を走らせるための実行環境）が動かない場合は、RTX 5090 固有の事情があります。5090 が属する Blackwell 世代は旧世代ほどの後方互換性を持たず、テンプレートと Docker イメージが CUDA 12.8 および PyTorch 2.7 以上で構成されている必要があります。

CUDA のバージョンはホストではなく Docker イメージが決めています。nvcc --version（コンパイラ側）と nvidia-smi（ドライバー側）で表示が食い違うのはこのためです。SSH か Jupyter のターミナルで python を起動し、次の 3 行を打つのが手早い確認です。

import torch
print(f"CUDA available: {torch.cuda.is_available()}")
print(f"GPU device: {torch.cuda.get_device_name(0)}")

容量が尽きる・落ちる・遅い

ディスクで最初に知っておくべき事実は 1 つです。ディスクサイズは作成時に固定され、後から変更できません。公式は「容量が尽きたら、より大きなディスクで新しいインスタンスを作る必要がある」と答え、「必要だと思う量より常に多めに割り当てること」と勧めています。稼働中は df -h で監視し、98% に達すると公式の通知が「Instance storage full」として飛び、この付近からジョブが失敗し始めます。尽きたときの選択肢は、より大きいディスクで新しいインスタンスを作ってデータを移すか、Volume（= インスタンスとは別建てで作る保存領域）を接続するか、クラウドストレージへ退避するかの 3 つです。Volume は作成した物理マシン上のインスタンスにしか接続できないので、「別のマシンへ引っ越す」用途には使えません。

メモリ不足は 2 種類あり、対処が別です。1 つはシステム RAM の不足で、割り当てのベースラインを超えて使ったときに OOM killer（= メモリが尽きたときにプロセスを強制終了する仕組み）に殺される形で現れます。CPU と RAM は「マシン全体に対する、借りた GPU の枚数比」で按分されます。公式が挙げている例は、4 枚挿しのマシンから 1 枚を借りたインスタンスは CPU ベースラインの 25% というものです。計算例として、8 枚挿しマシンの 1 枚（2026-08-24 時点の実測 offer にも、8 枚のうち 1 枚を借りている状態を示す gpu_frac = 0.125 が実在します）なら 8 分の 1 になります。空きがあれば一時的に超えて使えますが、そうするとシステム RAM の空きが尽きた瞬間にプロセスが殺されるリスクを背負います。ベースライン内に収めるのが唯一の予防策です。

もう 1 つは VRAM（= GPU 自身が持つメモリ。モデルの重みと計算の途中結果はここに載る）の不足で、CUDA out of memory として現れます。公式の対処は 3 つです。バッチサイズ（= 一度にまとめて処理するデータの件数）を下げる、gradient checkpointing（= 計算の途中結果を保存せず、必要になったら再計算してメモリを節約する手法）を有効にする、mixed precision（= 一部の計算を 16 ビットの精度で行って必要メモリと計算時間を減らす手法）を使う。RTX 5090 の VRAM は 32 GB（2026-08-24 時点の実測 offer では gpu_ram が全件 32607 MB）なので、これを超える大きさのモデルを丸ごと VRAM に載せることはできません。

「思ったより遅い」の原因として公式が挙げているのは、CPU ボトルネック（データ読み込みが追いつかない）、ネットワーク I/O、CUDA が有効になっていないこと、コンシューマー GPU のサーマルスロットリング（= 熱くなりすぎたときに性能を落として自分を守る動作）、そしてマルチ GPU 構成での PCIe 帯域（= GPU と CPU をつなぐバスの速度）です。なお 2026-08-24 時点の実測では、1× RTX 5090 の offer にも pci_gen が 3.0 のホストが混ざっています。モデルの読み込みだけがやたら遅いときは、GPU ではなくこの世代を疑ってください。まずは GPU が実際に働いているかを見てから、原因を絞り込みます。

もう 1 つ、初心者が高確率で踏むのが環境変数です。SSH / Jupyter のローンチモードでは、自分で設定した環境変数が SSH・tmux（= 接続が切れても中の作業が生き残るようにする端末ソフト。SSH で入ると既定でこの中に入ります）・Jupyter のセッションの中に既定で入りません。「テンプレートに設定したはずの API キーが空だ」の正体はこれです。onstart スクリプトから書き出しておきます。

env | grep _ >> /etc/environment   # アンダースコアを含む変数だけを書き出す
env >> /etc/environment            # 全部書き出す

外部ポートの番号が入っている VAST_TCP_PORT_22 のような変数もアンダースコアを含むので、上の 1 行目で拾えます。

全部止まった・借りられない、そして鳴らしておく警報

停止ボタンを押していないのにインスタンスが全部停止していたら、公式の答えは 1 行です。クレジット残高を確認してください。0 以下になるとインスタンスは自動的に停止されます。停止後もディスク課金は続き（残高がマイナスでも同様です）、クレジットカードを登録していないアカウントでは、インスタンスと保存データが destroy されます。カードがあれば自動課金でマイナスが埋められ、削除から保護されます。

止まったのが全部ではなく 1 台だけなら、それが interruptible（= 自分で入札価格を決めて安く借りる代わりに、より高い入札に負けると停止させられる借り方）かどうかを確認してください。入札に負けるとインスタンスは停止され、実行中のプロセスは kill されます。ディスクのデータは残りますが処理は中断するので、この借り方を選ぶなら「途中経過をこまめにディスクへ保存し、クラウドストレージにも退避する」設計が前提になります。止まったことにすぐ気づくための Instance outbid という通知も用意されています。

そもそも借りられない、spend_rate_limit というエラーが出る場合は、新規アカウントの支出レート上限に当たっています。未認証のアカウントでは上限がほぼゼロなので、まずメール認証を済ませてください。上限は時間の経過とともに自動的に上がります。それでも足りなければ、より安いインスタンスを試すか数時間待ち、解決しなければコンソール右下のオンラインサポートチャット（24 時間 365 日）に相談します。なお、インスタンスの不具合でサポートに連絡するときは instance ID を必ず添えるのが公式の指示です。

スクリプトから API を叩いていて HTTP 429 が返る場合は、レート制限（= 短時間に叩きすぎないよう API 側が掛けている上限）です。上限はエンドポイントごと・利用者ごとに「同じエンドポイントを次に叩けるまでの最短間隔」として課されます。Retry-After（= 何秒後に再試行してよいかを伝えるヘッダー）は返らないので、待ち時間は自分で決めて実装する必要があります。ポーリング間隔を延ばすのが最初の一手です。

ここまでの事故は、どれも「気づくのが遅れる」ことで損害が確定します。vast.ai の通知は、まさにその手前に置けるように作られています。

残高については公式が具体的な設定値まで書いています。自動課金（autobilling）の閾値を平均的な日次か週次の支出額あたりに置き、低残高メール通知の閾値をその約 75% に置く。こうしておくと、自動課金が失敗しても残高が 0 になるずっと前に気づけます。設定は cloud.vast.ai/billing です。

つまずきポイント

理解度チェック

まとめ

• 症状の名前ではなく actual_status とコンソールのボタン表示から入る。intended_status とのズレが症状の正体
• exited / unknown / offline は終端。ポーリングは 10 秒間隔・タイムアウト必須で、見えたら destroy
• stop は GPU を手放す操作。数分の中断なら reboot、終わったなら destroy。recycle 後のデータ保持は公式に明記が無い
• SSH は鍵のみ。鍵はインスタンス作成の前に登録する。scp は -P、ssh は -p
• nvidia-smi が GPU を返さない、Connecting から進まない — この 2 つは report して乗り換えるのが公式の対処
• ディスクは作成時に固定。RTX 5090 は CUDA 12.8 / PyTorch 2.7 以上が必須で、イメージを勝手に差し替えない
• 全台止まったらまず残高。1 台だけなら interruptible の入札に負けていないかを見る
• 通知は借りる前に有効化する。自動課金の閾値は日次〜週次の支出額、低残高メールはその 75%

次章は、ここまでの 17 章で出てきたコマンド・料金・選択基準を 1 ページに畳んだ早見表です。困ったときに最初に開く場所として使ってください。

参考リンク

• Troubleshooting — Vast.ai Docs
• Manage Instances（ボタン表示と状態の対応）
• CLI: show instance（actual_status の値一覧）
• API Reference: Hello World（Poll trap の警告）
• Connect: SSH
• Connect: Jupyter（証明書のインストール）
• Connect: Networking（ポートの割り当て）
• RTX 5 Series（CUDA 12.8 / PyTorch 2.7 要件）
• Billing（残高 0 以下の挙動と autobilling）
• Notifications（通知タイプ一覧）
• Connect: Instance Portal（Tunnels ページ）
• API Reference: Rate Limits and Errors（429 の扱い）
• Technical FAQ（Docker-in-Docker・遅いときの切り分け）