很多 AI 團隊一開始以為自己在做模型或 agent，後來才發現真正每天追著人跑的是 GPU。

不是「有沒有 GPU」這麼簡單，而是同一批 workload 有時要開發環境，有時要 batch job，有時要 training，有時要長跑 inference service；今天 H100 貴，明天 L40S 夠用，後天 AMD MI300X 有空，某些任務又要跑在自家機房。Kubernetes 能解一部分，但它不是專門為 AI 團隊的採購、排程、spot 失敗、模型 cache、multi-node training、服務 endpoint 和異質 accelerator 取捨而生。Slurm 很強，但對很多偏產品與雲端原生團隊來說，又像走進另一個年代的機房。

dstack 值得看的地方，就在這個縫裡。它不是又一個模型框架，也不是 vLLM / SGLang 的替代品。官方 README 和文件把它定位成 unified control plane for GPU provisioning and orchestration，目標是讓 training、inference 和 agentic workloads 可以跨 GPU cloud、Kubernetes、on-prem cluster 跑起來。更白話地說，它想替 AI 團隊處理「去哪裡找算力、怎麼排、怎麼跑、怎麼停、怎麼把服務露出來」這一整串麻煩事。

從近期活躍度看，這不是睡著的 repo。GitHub 頁面顯示 dstack 有約 2.2k stars、3,819 commits，主題直接標在 GPU、Kubernetes、Slurm、training、inference、agentic orchestration；官方 release 在 2026-08-06 發 0.21.0，PyPI 又在 2026-08-27 上傳 0.21.3。0.21.0 release note 還特別提醒新 0.21.x CLI 不相容舊 0.20.x server，這種不太討喜但很實際的資訊，反而說明它正在做基礎架構層面的整理，而不是只靠漂亮 demo 撐場。

English TL;DR

dstack is an open-source control plane for GPU provisioning and orchestration across GPU clouds, Kubernetes, and on-prem clusters. Its value is not replacing inference engines or training frameworks, but giving AI teams a more practical layer for fleets, dev environments, tasks, inference services, volumes, gateways, and experimental agent-driven inference presets. It is worth evaluating when GPU availability, cost, heterogeneous hardware, and deployment sprawl are becoming operational problems. It is probably too much if you only run small local experiments or rely entirely on hosted model APIs.

dstack 是什麼？

dstack 可以先理解成 AI workload 的算力控制平面。

官方文件的說法是，它支援任何 GPU cloud、Kubernetes 或 on-prem cluster，並且能簡化 development、training 和 inference。README 也列出它支援 NVIDIA、AMD、Google TPU、Tenstorrent 這些 accelerator。這個定位很重要，因為 dstack 沒有試圖取代你熟悉的工具鏈：你仍然可以用 vLLM 跑模型服務，用 SGLang 做 serving，用 TRL 或 Axolotl 做 training，用 Ray 或其他框架跑分散式任務。dstack 切的是下一層：這些工作到底要在哪些機器上跑，資源怎麼拿，服務怎麼維持，失敗怎麼重試，GPU 閒置時要不要退掉。

它的核心概念大致可以拆成幾塊。

第一是 fleets。官方文件說，送出 runs 之前必須先建立 fleet；fleet 同時是 instance pool，也是 provision template。它可以是 backend fleet，也就是從雲端或 Kubernetes 動態 provision；也可以是 SSH fleet，直接把既有 on-prem servers 納入管理。這點對很多團隊很實際，因為現實世界的 GPU 來源通常不乾淨：有些在雲上，有些在 Kubernetes cluster，有些是公司買的裸機，有些臨時從供應商租。

第二是 dev environments、tasks 和 services。文件列出的 config 類型包括 fleets、dev environments、tasks、services、presets、volumes。dev environment 比較像給工程師或 agent 進去工作的互動式環境；task 比較像 training、batch 或其他一次性 job；service 則是長跑的 inference endpoint。這種分法比「全部都是 pod」更貼近 AI 團隊每天真的在做的事。

第三是 provisioning 與運行細節。README 寫到，dstack 會管理 provisioning、job queuing、auto-scaling、networking、volumes、run failures、out-of-capacity errors、port-forwarding 等問題。這些聽起來不性感，但就是 AI infra 最容易把人磨掉的地方：不是模型不會跑，而是跑到一半 capacity 沒了、spot 被收回、cache 沒保住、endpoint 找不到、GPU 利用率太低，最後整個團隊開始用 Slack 人肉排程。

為什麼現在值得看？

第一個原因，是 AI workload 的型態變得比傳統 web service 更碎。

一般後端服務多半長得像：固定 container、固定流量、固定 autoscaling 規則、CPU / memory 比較好估。AI workload 則很像一堆性格不一樣的東西混在一起。資料科學家要開互動環境，研究員要跑 multi-node training，產品要部署 inference service，agent team 要跑大量工具使用測試，平台團隊還要在不同雲和自家機器之間找便宜 GPU。你可以全部塞進 Kubernetes，但代價是得補一堆 AI-specific glue。

dstack 的吸引力不是「不用理解基礎設施」，而是把常見 AI 基礎設施動作收斂到一個比較窄的操作模型。定義 .dstack.yml，建立 fleet，apply task 或 service，讓系統處理 provision、queue、retry、endpoint、volumes 和閒置回收。這不會讓 infra 消失，但會把問題從「每個團隊自己拼雲端 API、Kubernetes YAML、SSH 腳本、Slurm 指令」變成「在一套 AI workload model 裡做取捨」。

第二個原因，是 2026 年的 GPU 策略越來越不可能只押一家。

模型推理成本還在壓，長上下文、RAG、agent workflow 又讓使用量越來越不穩。今天某家雲的 H100 沒貨，明天另一家有便宜 L40S，後天 AMD 或 TPU 在特定任務上性價比更好。dstack 這類 vendor-agnostic orchestration 的價值，就在於讓團隊不要把所有 workload 寫死在某個供應商控制台或某套 cluster assumptions 裡。

第三個原因，是 dstack 開始往更 AI-specific 的 inference operating layer 補功能。官方 README 的 latest news 提到 2026 年有 replica groups、PD disaggregation support、NVIDIA Dynamo integration、Kubernetes multiple clusters、Slurm backend，以及 0.20.29 的 presets：agent-driven inference optimization。Presets 文件也明說這是 experimental，但方向很有意思：讓 agent 協助 benchmark 模型 variant，找到符合 context length、TTFT、throughput、VRAM 等要求的 inference configuration，再用 portable format 部署出去。

這條路線如果做得好，dstack 會不只是「幫我開 GPU 跑 job」，而是更靠近「幫我在可用算力、模型 variant、效能限制和部署環境之間做實驗」。對 AI 團隊來說，這比單純的 cluster abstraction 更有價值。

適合誰？

最適合的是已經有多種 AI workload 的團隊。

如果你的團隊同時有開發環境、training jobs、batch evaluation、model inference services，而且這些工作需要不同 GPU、不同時長、不同擴縮策略，那 dstack 很值得試。尤其當你已經開始用人工方式決定「這個任務丟哪裡」「那台 GPU 現在能不能用」「這個 service 要不要退掉」「spot 被打斷怎麼補」，代表問題已經不是單純寫幾個 shell script 可以乾淨解掉。

第二類，是想跨雲或混合自有機房的團隊。

dstack 的 backend fleet 和 SSH fleet 設計，正好對應這種不完美現實。你可以從雲端或 Kubernetes provision，也可以把既有 on-prem Linux + Docker 主機接進來。文件也提醒，SSH fleet 的主機需要預先裝好 Docker、GPU driver / accelerator software、passwordless sudo，SSH server 也要允許轉發。這不是零設定，但至少它承認很多團隊真的有自家機器，而不是假設全世界都活在同一個雲端控制台裡。

第三類，是平台工程或 MLOps 團隊。

如果你的角色是替公司內部多個 AI product line 提供算力入口，dstack 的價值會比單一模型團隊更明顯。因為你關心的是共用 pool、權限、projects、secrets、metrics、events、gateway、volume、成本與利用率，而不是只把某個 demo 跑起來。dstack 不會自動給你完整治理，但它提供了一個比散落腳本更容易制度化的入口。

不適合誰？

如果你只是本機玩模型，先不用。

一張消費級 GPU、一台工作站、幾個 notebook、一個小 demo，直接用 Docker、uv、conda、Ollama、vLLM 或 LM Studio 可能更快。dstack 的 server、fleet、project、YAML configuration 對這種情境反而是額外負擔。工具不是越完整越好，太早引入控制平面，很容易把探索期搞成平台建設期。

如果你完全使用 hosted model API，也不用急。

OpenAI、Anthropic、Gemini、OpenRouter 這類 API-first stack 的主要問題，多半是成本監控、prompt 版本、eval、trace、fallback、rate limit、資料治理。這時候 LiteLLM、Helicone、Langfuse、Opik、Phoenix、DeepEval 可能更貼近痛點。dstack 管的是你自己要跑 compute 的世界；如果你沒有要自管 GPU，它不是第一優先。

如果公司已經有成熟 Kubernetes / Slurm / Ray / internal scheduler，而且平台團隊能服務 AI 團隊，也不一定要換。

dstack 更像是降低 AI compute orchestration 摩擦的產品化路線。若你現有系統已經能處理 multi-node training、queue、quota、spot retry、GPU utilization、model endpoint、observability 和 cost allocation，導入 dstack 就要看能不能減少實際維運成本，而不是只因為它比較新。

場景一：跨雲找 GPU 跑訓練與 batch jobs

第一個具體場景，是一個小型 AI 團隊要跑 fine-tuning、evaluation 和資料處理 batch。

這類團隊通常不會一開始就有完美 cluster。可能今天用 AWS，明天用 Lambda，偶爾有 Nebius 或 Crusoe 供給，另外還有幾台公司買的 GPU 主機。問題不是某一次 job 不能跑，而是每次都要重新處理 credentials、region、instance type、spot policy、磁碟、網路、環境安裝和中斷恢復。

dstack 的 fleet model 對這裡有用。你可以定義 backend fleet，讓節點數從 0 開始，等有 runs 才 provision；也可以設定 idle_duration，讓閒置機器超過時間就退掉。對成本敏感的團隊，這比「大家記得手動關機」可靠多了。你也可以用 spot policy 控制是否允許 spot、on-demand 或 auto。這些不是演算法能力，卻直接影響月底帳單。

比較務實的 PoC 方式，是挑一個已知會常跑的 evaluation 或 fine-tuning job，把它搬成 .dstack.yml task，測三件事：任務是否真的比原本更容易重跑，失敗和中斷是否比較好處理，跨 backend 時是否能少改 application code。如果這三件事沒有改善，只是換了一種 YAML，那就不值得。

場景二：把 vLLM / SGLang 服務部署成可回收的 inference endpoint

第二個場景，是部署開源模型服務。

dstack 的 services 文件展示了把模型服務跑起來的路徑：定義 service、commands、port、model、volumes、resources，然後 dstack apply，系統會 provision instance 並執行 service。文件裡的例子也直接出現 vLLM、SGLang、Qwen、MI300X 這類真實 inference 元件，不是抽象的 hello world。

這對產品團隊的價值，在於把 inference service 從「某台機器上有一個人手動開的 server」變成比較可描述、可重跑、可回收的資源。你可以指定 GPU memory、shm size、disk、cache volume，也可以設定 utilization policy，例如 GPU 低於某個利用率太久就終止。這很適合內部測試服務、短期 benchmark endpoint、活動型產品流量，或不同模型版本的比較。

但這裡也要清楚：dstack 不是推理引擎。模型吞吐、KV cache、batching、attention kernel、quantization、P/D disaggregation 的細節，仍然主要看 vLLM、SGLang、TensorRT-LLM、Dynamo、llm-d 等工具。dstack 更像是把這些東西放到可運行的 compute context 裡。它能幫你管理服務生命週期，不會自動替你調出最佳 tokens/sec。

場景三：給 coding agent 或研究 agent 一個可申請的工作環境

第三個場景比較新：agentic workloads。

README 已經把 agentic workloads 寫進專案描述，也提到可以安裝 dstack skills，讓 Claude、Codex、Cursor 這類 AI agents 建立 fleets、提交 workloads、編輯設定。這個方向很合理，因為越來越多 coding agent 需要的不只是讀寫 repo，還需要臨時開環境、跑測試、跑 benchmark、部署預覽、甚至用 GPU 做模型或資料任務。

如果每個 agent 都能透過受控的 dstack project 申請 dev environment 或 task，平台團隊就比較有機會管理權限、成本和資源回收。這比把雲端憑證直接塞給 agent，或讓 agent 透過一堆臨時 shell 腳本開機器，風險低很多。

不過這條路仍然要很小心。agent 能申請 compute，不代表它應該無限制地申請 compute。dstack 可以提供控制平面，但 quota、審批、成本上限、secret scope、network boundary、任務 sandbox 還是要另外設計。否則 agentic orchestration 很容易從自動化變成自動燒錢。

限制與缺陷：它解的是編排，不是所有 MLOps

dstack 第一個限制，是它會引入新的控制平面。

你需要 server、CLI、project config、backend config、fleet config、secrets、profiles、升級策略。0.21.0 release note 也提醒，0.21.x CLI 不相容舊 0.20.x server，升級時應該 server 和 CLI 一起更新，或先更新 server。這代表它不是一個完全無感的薄 wrapper，而是一個需要被維運的系統。當團隊規模還小，這層維運成本可能比收益更明顯。

第二個限制，是底層 provider 和硬體差異不會消失。

dstack 可以抽象化 provisioning 與 workload model，但不同雲的 quota、instance availability、網路拓撲、driver、ROCm / CUDA / TPU runtime、檔案系統、container image、NCCL / RCCL，都仍然可能讓工作卡住。文件中 SSH fleet 對 host requirements 的要求很具體，這是好事，也提醒你：只要碰到自管 GPU，底層衛生條件還是不能省。

第三個限制，是治理能力要自己補齊。

AI compute orchestration 不是只有「能跑」。還要知道誰用了多少錢、哪個 project 可以開哪種 GPU、哪些 secret 能被哪個 workload 讀取、spot 中斷造成的 retry 成本怎麼算、模型服務對外暴露到哪裡、log 和 metrics 保存多久。dstack 有 projects、secrets、metrics、events、gateways 這些概念，但企業級治理通常還需要接進現有 IAM、billing、security review 和 observability。

第四個限制，是 presets 還是 experimental。

agent-driven inference optimization 很吸引人，因為誰都想要「幫我找出最佳部署組合」。但文件明確標示 presets may change。這類功能適合拿來實驗和觀察方向，不適合一開始就押成核心 production contract。尤其自動 benchmark 和自動選型如果沒有固定 workload、固定 SLO、固定成本模型，很容易得出看似精準、其實不適用的答案。

替代方案怎麼看？

如果你已經是 Kubernetes-heavy 團隊，Kubernetes 加 Kueue、Volcano、Ray、KServe、NVIDIA GPU Operator、Dynamo 或 llm-d 可能更符合既有平台路線。優點是能接進現有 cluster governance；缺點是 AI 團隊要面對更多 Kubernetes 細節。

如果你是 HPC / research lab，Slurm 仍然很強，尤其在排隊、配額、multi-node training 和共享 cluster 上有成熟經驗。dstack 的 Slurm backend 反而可以被看成一種橋：不是取代所有 Slurm，而是讓 AI 團隊用更現代的 workload interface 接到既有資源。

如果你只想跑 inference endpoint，BentoML、KServe、Ray Serve、Modal、Runpod、Replicate、Baseten 或雲端託管服務都值得比較。dstack 的優勢在於跨算力來源與 AI workload 編排；如果你只要簡單部署 API，專門的 inference platform 可能更省事。

如果你的主要痛點是 LLM observability、prompt management、eval、feedback loop，那 Langfuse、Opik、Phoenix、Helicone、DeepEval、Promptfoo 這類工具更貼題。dstack 可以管 compute，但不會替你判斷模型回答品質，也不會自動建立產品評測體系。

Star History

採用判斷

比較穩健的結論是：dstack 值得 AI infra / MLOps 團隊放進候選清單，但不要把它當成「不用管基礎設施」的捷徑。

它真正有價值的時刻，是你已經被 GPU 的來源、價格、閒置、供給、中斷、異質硬體、training job、inference service 和 agent 工作環境拖住。這時候 dstack 提供的 fleets、tasks、services、volumes、gateways、presets 和跨 backend 模型，能把很多散落的操作收斂成比較可管理的流程。

但如果你還在產品探索期，使用 hosted APIs，或只有單機小實驗，先不要急著上控制平面。把 eval、成本監控、資料品質、模型選型和最小可行部署做好，通常更有回報。

採用 dstack 的最小測試，不該是「裝起來跑 hello world」。比較務實的是選一個真實 workload：一個常跑的 fine-tuning job、一個 vLLM / SGLang endpoint，或一個 agent 需要的 GPU task。用它測 provision 時間、失敗恢復、GPU 利用率、閒置回收、跨 backend 可攜性和團隊操作負擔。若它能讓這些指標變簡單，dstack 就不是多一層 YAML；它是在替團隊買回 AI compute 的掌控感。

參考資料

• dstack GitHub: https://github.com/dstackai/dstack
• dstack Docs: https://dstack.ai/docs/
• dstack Releases: https://github.com/dstackai/dstack/releases
• dstack Fleets: https://dstack.ai/docs/concepts/fleets/
• dstack Services: https://dstack.ai/docs/concepts/services/
• dstack Presets: https://dstack.ai/docs/concepts/presets/
• dstack PyPI: https://pypi.org/project/dstack/