執行個體生命週期
執行個體任何時候都恰好處於八種狀態中的一種。它處於哪一種狀態決定了你在意的三件事：你能不能連上它、它是不是正在對你計費，以及有哪些操作可用。
狀態機
正常路徑是 creating → running → stopping → stopped → starting → running。拆除一律是 destroying → destroyed，而且除了 destroyed 本身之外，你可以從任何狀態開始拆除 — 包括執行個體還在建立中、啟動中或停止中的時候。虛線箭頭是主機沒有照要求做的時候，平台把執行個體放回原本的狀態；下文會說明。
要求目前狀態不允許的動作 — 啟動一個已經在執行的執行個體、停止一個還在建立中的執行個體 — 會被拒絕，執行個體維持原狀。
每一種狀態
| 狀態 | 過渡中 | 計費 | 代表的意義 |
|---|---|---|---|
creating | 是 | 無 | 切片已保留，你的工作負載正在第一次啟動。 |
starting | 是 | 無 | 已停止的執行個體正在同一台機器上、以同一顆硬碟重新啟動。 |
running | 否 | GPU，按秒 | 工作負載已就緒。SSH、JupyterLab 與你發布的連接埠都連得上。 |
stopping | 是 | 無 | 容器正在關閉。你的硬碟會保留。 |
stopped | 否 | 硬碟，每 GB 每小時 | 沒有任何東西在執行。硬碟保留，GPU 插槽也一樣，除非平台將它釋放 — 請參閱停止與銷毀。 |
destroying | 是 | 無 | 容器與硬碟正在拆除。 |
destroyed | 否 | 無 | 終點。硬碟已消失，報價回到市集上。 |
error | 否 | 無 | 工作負載無法啟動、執行失敗，或自己跑完了。詳見下文。 |
過渡狀態是平台正在積極處理中的那四種；主控台會用閃動的徽章顯示它們，並在進行期間更頻繁地重新整理。它們會自行完成 — 沒有動作需要重試，不過你可以直接銷毀執行個體，不必等待。
非過渡狀態是穩定的。執行個體會停在 running、stopped、destroyed 或 error，直到你、計費系統或主機自己的回報讓它移動。
每個轉換的成因
| 轉換 | 觸發條件 |
|---|---|
→ creating | 你進行部署：以一則報價、一個範本與一個硬碟大小呼叫 POST /v1/instances。 |
creating/starting → running | 工作負載回報自己已就緒。GPU 計量從這裡開始，而不是在部署時。 |
creating → error | 工作負載無法啟動。 |
running → stopping | 你停止它，或你的餘額到達 $0。你自己的停止會保留 GPU — 除非一筆付款爭議凍結了組織的付款，那時它會像 $0 時的那次停止一樣釋放它們。釋放只在機器支援的情況下發生。 |
stopping → stopped | 關閉完成。硬碟計量從這裡開始。 |
stopping → running | 主機在 30 分鐘內沒有確認停止。容器還在執行，所以 GPU 計量重新開始，停止則會持續重試。它的 error_code 為 stop_timed_out。 |
stopped → starting | 你啟動它。需要餘額足以支付組織所有執行項目一小時的費用，包括這個執行個體。GPU 已被釋放的執行個體必須取回同樣的 GPU：只要其中任何一張正在使用，啟動就會以 409 CAPACITY_UNAVAILABLE 被拒絕，執行個體維持 stopped。 |
starting → stopped | 主機拒絕恢復或連不上，或在 30 分鐘內沒有確認（start_timed_out）。對 GPU 已被釋放的執行個體來說，拒絕通常表示另一位租用者現在正在用它們（gpus_unavailable）。執行個體回到停止狀態，硬碟還在，你可以再次啟動它。 |
stopped → error | 機器回報已停止執行個體的容器不見了 — 它在停止期間結束或遺失，硬碟也隨之而去（workload_gone）。已經沒有可以啟動的東西了。 |
running → error | 工作負載失敗、主機弄丟了它，或某個工作自己跑完了（workload_completed）。GPU 會被釋出。 |
error → running 或 stopped | 平台發現工作負載其實還健在 — 在執行中，或連同硬碟被保留著 — 於是把執行個體放回那個狀態。 |
destroyed 以外的任何狀態 → destroying | 你銷毀它。餘額低於門檻夠久之後，自動銷毀也會對已停止與出錯的執行個體做同樣的事。 |
destroying → destroyed | 拆除完成。硬碟已刪除，報價已釋出。 |
其中兩個觸發條件不是你發動的。組織餘額歸零時，執行中的執行個體會自動停止，已停止執行個體的 GPU 會在機器支援的情況下被釋放。如果餘額之後在零或以下持續 24 小時，並且在 −$5 或以下，已停止與出錯的執行個體就會被銷毀。執行中的執行個體絕不會被直接銷毀 — 它們會先被停止。一筆未結的付款爭議也會釋放已停止執行個體的 GPU，即使餘額為正也一樣。這些都在自動停止與自動銷毀中說明。
部署與啟動都需要餘額足以支付組織整體一小時的消耗 — 每個執行中、啟動中或建立中執行個體的 GPU 與硬碟、每個已停止執行個體的硬碟，以及你正在部署或啟動的那個執行個體的 GPU 與硬碟 — 而不只是大於零。停止與銷毀從來不需要 — 不論餘額是多少，你隨時都能把東西關掉。
計費跟著狀態走
費用依執行個體實際所處狀態的費率結算，而且每次狀態變更都會在變更生效前先結清先前欠的部分。GPU 計量只在 running 時運作。硬碟計量只在 stopped 時運作。四種過渡狀態、error 與 destroyed 都不計費。
這就是為什麼一次花兩分鐘才啟動完成的部署不會為那兩分鐘計費，也是為什麼已停止的執行個體仍會每分鐘在你的帳本裡產生一筆費用。
「error」代表什麼
error 表示工作負載沒有在執行，平台也沒有替你保留它：映像檔拉取失敗、容器拒絕啟動、主機在啟動過程中停止回報、工作負載在執行時失敗或遺失、某個工作自己跑完了，或是一個已停止執行個體的容器從它的機器上消失了。執行個體頁面會在 發生了什麼問題 下說明是哪一種，API 則以執行個體的 error_code 與 error_message 回報。請參閱執行個體為何失敗。
由此可以推出四件事：
- 不會對你計費。 在
error狀態下計量是關閉的，執行個體停在那裡也不會累計任何費用。 - 不會重試。 沒有自動重新啟動。除了銷毀之外，唯一的出路是復原：如果平台之後發現工作負載在執行中，或連同硬碟被保留著，就會把執行個體移回
running或stopped。 - 它可能會被替你清掉。 從未執行過就出錯的執行個體，或已知工作負載已經結束的執行個體，會在進入
error大約一小時後被自動銷毀，硬碟也一併刪除。曾經執行過、而且工作負載可能仍被保留的執行個體則不會 — 它會等平台查清楚它發生了什麼，或等你處理。 - 銷毀是你唯一能做的動作。 你不能啟動、停止或修復一個出錯的執行個體。銷毀它、修好原因，然後重新部署。
啟動失敗的常見原因出在範本而不是硬體：不存在的映像檔名稱或標籤，或是私有登錄庫的憑證有誤。映像檔不是以 Superheat 基礎映像檔為基底的 ssh 或 jupyter 範本也啟動不了，因為這兩種模式依賴基礎映像檔的進入點。
一個跑完的工作 — 指令自行結束的 args 模式範本 — 會以 error_code workload_completed 落入 error。它的 GPU 會立刻被釋出，也不會計費；拿到你需要的東西之後就銷毀它。
從未進入 running 的執行個體沒有日誌可讀，所以請從範本而不是從執行個體來除錯。疑難排解會逐一說明各種具體的失敗情形。
它不花錢。一旦平台看到它的工作負載結束 — 失敗、遺失或跑完 — 它的 GPU 會立刻回到市集上。在工作負載還沒送到主機之前就失敗的部署，則會一直佔著切片，直到執行個體被銷毀為止 — 由你銷毀，或大約一小時後自動銷毀。不論哪一種，在被銷毀之前它都會計入組織 25 個執行個體的上限。
你在哪裡看得到狀態
執行個體頁面會列出除了已銷毀之外的所有項目。透過 API，GET /v1/instances?include_destroyed=true 可以把它們找回來。
每個執行個體頁面會以徽章顯示目前狀態、只顯示目前狀態允許的操作 — 已停止的執行個體顯示「啟動」，執行中的顯示「停止」，destroyed 以外的每個狀態都顯示「銷毀」 — 並在工作負載就緒後，在連線分頁顯示連線資訊。API 會以執行個體上的 allowed_actions 回傳同一份清單。