啟動模式
啟動模式決定容器啟動時實際執行什麼、哪些連接埠會被發布，以及你的啟動時指令碼究竟會不會生效。它是範本上影響最大的單一欄位。
四種模式
args | ssh | jupyter | vm | |
|---|---|---|---|---|
| 啟動的是什麼 | 映像檔本身的進入點 | 基礎映像檔的進入點：連接埠 22 上的 sshd | sshd 加上透過 HTTPS 提供的 JupyterLab | 完整的 KVM 虛擬機器 |
| 需要衍生自基礎映像檔 | 不需要 | 必要 | 必要 | 不需要 |
| 隱含的連接埠 | 無 | 前置加入 22，標籤為 ssh | 前置加入 22（ssh）與 8080（jupyter） | 前置加入 22，標籤為 ssh |
| 你宣告的連接埠 | 原樣發布 | 附加在 22 之後，標籤為 app | 附加在 22 與 8080 之後，標籤為 app | 附加在 22 之後，標籤為 app |
args_str | 切分後成為容器的執行命令 | 忽略 | 忽略 | 忽略 |
onstart | 不會套用 | 首次啟動時執行一次 | 首次啟動時執行一次 | 隨啟動一併送出 |
| 報價需求 | 無 | 無 | 無 | 支援 VM 的報價 |
| 連線方式 | 你自己發布的連接埠 | SSH | 開啟 JupyterLab 按鈕，或 SSH | SSH |
args
預設值。Superheat 會完全按照作者的設計執行你的映像檔：使用映像檔原生的進入點，並依 shell 分詞規則把 args_str 切分成執行命令。--model llama-3 --port 8000 會變成四個引數。
啟動路徑上不會注入任何東西，這就是為什麼 onstart 在這裡沒有作用 —— 沒有 Superheat 的進入點可以執行它。如果你在 args 模式下需要做設定工作，請把它內建進映像檔，或讓它成為你的命令做的第一件事。
推論伺服器、訓練工作，以及任何不是你自己建置的上游映像檔，都請使用 args。
指令自己結束時，執行個體會進入 error，error_code 為 workload_completed：任務已經完成，GPU 已釋放，計費也已停止。從日誌取走你需要的東西，然後銷毀它。執行完的任務無法再次啟動。
ssh
會啟動 Superheat 基礎進入點，它會把你的公開金鑰安裝到 /root/.ssh/authorized_keys、在容器連接埠 22 上啟動 sshd、執行一次你的啟動時指令碼，然後交棒給映像檔的 CMD（若沒有就閒置，讓容器保持運作）。
容器連接埠 22 會自動前置加入連接埠清單；你不用自己宣告。主機端的連接埠是從機器已發布的範圍中指派的，而且絕不會是 22 —— 執行個體頁面會替你組出完整的連線字串。
當你想要的是一台可以動手做事的機器，而不是一個可供呼叫的服務時，請使用 ssh。
jupyter
ssh 做的所有事，再加上 JupyterLab。容器連接埠 22 與 8080 都會被前置加入。Jupyter 會使用自我簽署憑證，透過 HTTPS 繫結到 0.0.0.0:8080，根目錄為你的 Jupyter 工作目錄（預設是 /workspace）。把 JupyterLab 開關關掉，就改為提供傳統 notebook。
存取權杖由平台產生、往下傳給容器。主控台會組出已經帶著權杖的 開啟 JupyterLab 連結，並在執行個體的 連線 分頁、存取權杖 底下顯示權杖本身；API 會以執行個體的 access_token 回傳它。請參閱執行個體存取權杖。
Jupyter 使用自我簽署憑證透過 HTTPS 提供服務，讓權杖與你的 notebook 流量在直連路徑上是加密的。出現警告是正常的。
vm
這是完整的 KVM 虛擬機器，而不是容器。VM 範本只能啟動到主機支援 VM 的報價上。在部署頁面上，若把 VM 範本搭配不支援 VM 的報價，該報價無法選取，理由顯示為「這台機器不支援 VM。」，而且部署按鈕會維持停用；API 也會執行同樣的規則，並回傳 422 OFFER_NOT_VM_CAPABLE。啟動時會一併編入 SSH 存取，所以你的連線方式與 ssh 模式相同。
不需要衍生自基礎映像檔的映像檔，因為虛擬機器並不會執行容器的進入點。
為什麼 ssh 與 jupyter 只能用 ACR 上的精選映像檔
ssh 和 jupyter 模式下，Superheat 用基礎映像檔的進入點接管容器，啟動 sshd（jupyter 模式下還有 JupyterLab）。它依據映像檔引用決定是否接管，而不是依據映像檔裡的標籤：在 Superheat CN 上，只有 ACR 上 superheat/ 命名空間裡的映像檔（superheat-cn-registry.cn-shanghai.cr.aliyuncs.com/superheat/<儲存庫>）會被接管。
其他任何映像檔——包括你以 FROM 基礎映像檔建置、推送到自己登錄檔的映像檔——都依它自己的進入點執行，不會自動開放 SSH 連接埠。你自己的映像檔請用 args 模式，並在範本上宣告它提供服務的連接埠。請參閱 Superheat CN 上的映像檔。
連接埠優先順序
隱含的連接埠前置加入之後，清單會依容器連接埠與通訊協定去除重複，優先順序較高的項目勝出：
ssh / jupyter > open_button > app
這個順序讓你可以在連接埠清單中宣告某個連接埠，同時 把開啟按鈕指向它：回傳的項目標籤會是 open_button 而不是 app。這也表示在 ssh 或 jupyter 模式下自己宣告 22 或 8080 不會有任何改變 —— 隱含項目會保有它的角色。
標籤與開啟按鈕請參閱連接埠。
之後變更模式
啟動模式是啟動配方的一部分，所以編輯它會重新產生範本的 hash_id，任何釘選的分享連結都會失效。執行中的執行個體不受影響 —— 它們保有啟動當下所用的配方。