很多 AI 團隊前幾個月都不是被模型卡住，而是被算力流程拖垮。

研究員要一台 H100，平台說先等等。另一個團隊昨天剛把同型 GPU 開在另一朵雲。有人在 Kubernetes 上跑 batch，有人還留在 Slurm，有人乾脆直接去 RunPod 手開。最荒謬的不是 GPU 不夠，而是公司其實有不少卡，只是分散在不同地方，沒有一套像樣的用法。

如果你剛好是那個要收拾現場的人，你大概很熟這種畫面。Slack 裡有人貼 quota 截圖，有人在問哪個 region 還有貨，還有人說先幫我開一台，我今天只跑一下。通常說只跑一下的人，三天後還沒關。

SkyPilot 值得看的原因，就在這裡。

它不是在解模型效果，也不是在解 prompt。它解的是另一段更不討喜、但越做 AI 越躲不掉的問題：怎麼把訓練、微調、批次任務、模型服務這些工作，穩定放到你手上那一堆不一致的算力上。

English TL;DR

• SkyPilot is an open source control plane for AI compute, not just a nicer cloud launcher.
• Its value is giving AI teams one interface to run and manage workloads across Kubernetes, Slurm, and 20+ clouds, with job orchestration, auto-failover, scheduling, and resource utilization features.
• It is most useful when teams already have real GPU operations pain: fragmented infra, multi-cloud capacity issues, idle clusters, or mixed training and serving workloads.
• It is not ideal for teams that only call hosted LLM APIs, have no infra ownership, or just need the fastest single-cloud path.
• Pragmatic takeaway: adopt SkyPilot when compute has become an organizational coordination problem, not just an engineering convenience problem.

不是每一張 H100 都真的在工作

SkyPilot 的 README 很直接，它把自己定位成一套用來 run, manage, and scale AI workloads on any AI infrastructure 的系統。底下支援 Kubernetes、Slurm、還有二十多家雲與算力供應商，工作描述可以用 YAML 或 Python API 寫，然後交給同一套介面去啟動、排隊、重試、同步程式碼、管理資源。

這個定位很重要，因為它代表 SkyPilot 的核心不是幫你比較便宜的 GPU這麼簡單，而是把 AI 團隊常見的幾種分裂狀態收回來：

• 同一家公司有人跑 K8s，有人跑 Slurm
• 開發、訓練、推理分別長成三套流程
• 同一份工作今天丟 AWS，明天丟 GCP，後天去租外部 GPU cloud
• cluster 沒有自動回收，GPU 閒置卻還在燒錢
• 每個人都有自己的 shell script，沒人說得清楚到底哪一份才是正式做法

SkyPilot 想做的，是把這種大家都能跑，但整體很難管的局面，拉回成一個可描述、可遷移、可排程的控制層。

從官方文件看，它近幾個月還持續往前推，5 月剛發 v0.12.2，repo 也仍在更新。這不是只剩口號的專案。

你買到的是 GPU，還是新的排班地獄

很多團隊第一次碰多雲或多算力池，想像都很樂觀。

直覺上會覺得，多接幾家供應商就多幾個選擇，GPU 應該比較不會卡。現場通常不是這樣。多來源算力一旦開始進來，難度不是線性增加，比較像是排班地獄突然長出新的分店。

因為你要開始面對的，不只是哪裡有卡，而是：

• 哪個工作該去哪裡跑才划算
• 哪些任務可以容忍 spot / preemptible
• 哪些工作需要固定叢集，哪些可以外溢到別的雲
• 誰可以搶貴卡，誰不該拿 H100 跑其實 A10 就能做完的任務
• 哪些 cluster 閒著，哪些 queue 已經塞住
• 同一份專案碼，怎麼在不同環境還能有一致的啟動方式

我很有感的一個真人細節是，這種團隊只要進入第二階段，會很常看到有人把瀏覽器停在三四個雲端 console 分頁之間來回刷新，嘴裡講的是訓練計畫，手上做的卻像在搶演唱會門票。那個時候，問題已經不是模型本身，而是算力調度開始吃掉團隊的專注力。

SkyPilot 的價值，就是把這件事從每個人自己搶變成系統幫你安排。

它不是雲端比價網站，它比較像 AI 算力的工作調度層

SkyPilot 最值得看的地方，是它把 AI 工作負載拆成一種比較穩定的描述方式。

在它的 YAML 裡，你可以定義：

• 要什麼資源，例如 GPU 型號、CPU、記憶體、節點數
• 要在哪類 infra 上跑，例如 K8s、AWS、GCP 或其他供應商
• setup 要做什麼
• run 真正執行什麼
• workdir 與檔案掛載怎麼處理
• autostop、fallback、ordered / any_of 等條件怎麼設

這個抽象的意義，不是語法漂亮，而是它讓一份工作不再綁死在某個人電腦上的 shell script，或某個雲服務的專屬設定裡。

你可以把它理解成，SkyPilot 想把 AI compute 這件事，從一次性操作變成可以重複使用的作業描述。對研究團隊來說，這代表實驗比較好重現。對 infra 團隊來說，這代表資源分配與執行路徑終於比較能管。

三種情境，SkyPilot 會比想像中更有感

場景一，訓練與微調工作常常卡在哪裡有 GPU

這是最直接的使用場景。

例如你同時有 AWS quota、自家 Kubernetes 叢集、還租了外部 GPU cloud。平常最大的浪費，不是完全沒卡，而是有人只熟其中一套流程，所以整體資源池雖然分散存在，卻像不存在一樣。

SkyPilot 在這裡的價值，是讓工作可以用相對一致的方式描述，再交給系統去找可用資源、切換 infra、甚至做 auto-failover。這種能力對做訓練、LoRA 微調、RL、批次 embedding 的團隊特別有感，因為他們最怕的不是多花五分鐘，而是排了半天最後還是因為容量或流程碎裂白等。

場景二，你有 Kubernetes，但 AI 團隊其實沒有真的享受到它

很多公司都說自己已經有 K8s，但 AI 團隊的實際體驗不一定好。因為 vanilla Kubernetes 對資料科學家、研究員、甚至很多應用工程師來說，操作門檻還是高，排程、debug、開發體驗、遠端工作目錄同步，常常不是那麼順手。

SkyPilot 很刻意地把自己也定位成讓 Kubernetes 更像 AI 工作台的一層。官方文件甚至直接拿它和原生 K8s 做對照，強調 SSH into pods、sync code、連 IDE、gang scheduling、multi-cluster 等能力。

所以它適合的一種團隊，不是沒有 K8s 的團隊，而是有 K8s 但 AI 使用體驗還不夠好的團隊。這兩者差很多。

場景三，你同時有 batch job 和 model serving，卻不想養兩套世界

AI 團隊很容易長出兩條平行宇宙。

一條是訓練、微調、批次資料處理。另一條是線上模型服務、API deployment、推理節點。表面上它們都在吃 GPU，但日常流程、資源管理方式、部署習慣，常常完全不同。

SkyPilot 的例子與文件範圍其實很廣，從 training、serving 到各種 LLM workload 都有。這表示它不只想幫你 launch 一次性工作，也想把 batch 與 serving 放回同一套資源治理視角裡。

對平台團隊來說，這點很重要。因為很多成本不是花在 GPU，而是花在兩邊各養一套規則。

先別急著把所有工作都搬過去

SkyPilot 有吸引力，但它絕對不是那種裝了就世界和平的工具。

1. 它不適合只串 SaaS 模型 API 的團隊

如果你的 AI 產品主要是用 OpenAI、Anthropic、Gemini 這種 hosted API，根本沒有自己管訓練、GPU、K8s、batch 任務，那 SkyPilot 幾乎不是你的題。

它解的是 compute orchestration，不是 LLM app integration。

2. 它不是零維運，也不是不用懂 infra

SkyPilot 把很多東西包起來，不代表底下那些配額、網路、權限、映像、掛載、雲帳號與 K8s/Slurm 差異就消失了。

比較誠實的說法是，它讓複雜度比較可控，但沒有把複雜度變不見。

如果組織裡沒有人願意承接這層平台責任，最後很可能只是多了一個更大的抽象層，出事時大家照樣往下翻。

3. 抽象層再好，還是會遇到供應商特性外漏

多雲與多環境最麻煩的地方，本來就不是 CLI 能不能統一，而是各家供應商在網路、儲存、配額、啟動速度、磁碟、region 容量、GPU 型號可得性上都不同。

SkyPilot 已經做了很多統一，但你不能期待每一種底層差異都被完全抹平。真正上 production 後，還是會碰到文件上支援，不代表你的組織環境裡就沒有例外這種事。

4. 小團隊如果規模還沒到，可能會太重

如果你們只有少量訓練工作，大家都在單一雲、單一 cluster，而且目前排程與資源利用還沒有變成組織問題，那直接用原生雲服務、既有 Kubernetes 流程，甚至固定手動操作，可能都更省。

不是每個團隊都需要 control plane。太早導入，會有點像先蓋交通號誌，再等第一台車出現。

如果不選 SkyPilot，通常是在解別的題

這篇如果只說它好，不夠準。

如果你今天的問題是：

• 單一雲上的模型訓練流程，而且你不打算跨雲，也不想多一層抽象
  那原生雲服務可能更直接。

• 你已經有很成熟的 Kubernetes 平台團隊，內部早就把 AI 排程、開發體驗、成本控管都補齊
  那 SkyPilot 未必是必要層。

• 你只是在找推理極致效能
  那重點應該放在 vLLM、SGLang、TGI 這類推理層，而不是 SkyPilot。

• 你需要的是 DAG / workflow 編排
  那 Airflow、Argo Workflows、Prefect、Ray 這些工具可能更貼近工作流本身。

SkyPilot 最合理的定位，不是取代所有東西，而是當你的痛點剛好落在 AI 算力管理、跨環境執行、資源利用與工作負載治理 這一層時，它會突然很對。

採用判斷

結論，SkyPilot 值得看的地方，不在於它又多支援了幾家雲，也不只是找便宜 GPU這麼表面。

它真正補到的，是 AI 團隊一進入真實算力運作後，最容易變得混亂的那一段，工作描述不一致、算力分散、調度靠人、K8s 與 Slurm 各玩各的、batch 與 serving 分家、閒置資源沒人回收。

比較務實的導入方式，不是一次把所有工作搬進去，而是先挑一種最痛的 workload 開始，例如：

• 微調/訓練任務常常搶不到 GPU
• 多個算力池明明都存在，卻沒辦法統一調度
• 團隊已經有 Kubernetes，但 AI 工作流程還是很卡
• batch 與 serving 的資源規則開始互相打架

如果你們現在只是偶爾跑幾個實驗，SkyPilot 可以先放進觀察名單。

但如果你已經開始覺得，AI 團隊最大的內耗不是模型不夠強，而是算力怎麼分、工作怎麼排、資源怎麼收，這個 repo 就不是可看可不看，而是很可能已經進入該認真評估的區間了。