60 毫秒啟動、每天 85 萬台：AI Agent 正在逼傳統雲端架構走向極限

本文整理自《Latent Space》2026 年 5 月播出的單集。

{{< youtube kaX43RRRUKY >}}

---

一個客戶，每天跑 85 萬個沙箱

Daytona 是一家為 AI Agent 提供運算沙箱的基礎建設公司，2026 年 2 月完成 2,400 萬美元 A 輪融資，團隊 25 人，月營收增長率 74%。執行長 Ivan Burazin 在 Latent Space Podcast 上提到了幾個讓人停下來想一下的數字：目前最大的客戶每天運行將近 85 萬個沙箱，逼近百萬大關。另外有一個客戶要求 50 萬個同時運行的沙箱，也就是 50 萬顆 CPU 在某個地方同時轉動。

這些數字的背後是一個正在被重新定義的基礎建設問題。Burazin 在 2025 年初把 Daytona 從「替人類工程師自動化開發環境」的產品，轉型為 AI Agent 專用的運算沙箱。轉型的觸發點很直接：他們把為人類設計的產品交給二、三十個正在開發 Agent 的團隊試用，每個人都說不能用。不是功能缺了什麼，而是架構設計的前提就不對。為人類設計的運算環境，在面對 Agent 的速度、狀態保持、和大規模併發需求時，從根本上就不夠。

對開發者來說，這是一個清楚的訊號：過去二十年為人類使用者打造的那些抽象層（容器、VM、Kubernetes），在面對 Agent 工作負載時碰到了結構性的限制。不是調參數就能解決的。

兩種工作負載，兩種完全不同的形狀

要理解為什麼現有架構不夠用，先得看 Agent 的使用模式到底長什麼樣子。Daytona 把客戶的工作負載分成兩大類，它們的「形狀」差異巨大。

第一類是「背景 Agent」，也就是 Cognition 的 Devin、Lovable、Harvey 這些產品背後的長時間運行 Agent。這類 Agent 的使用曲線和人類很像，遵循「跟著太陽走」的日夜週期：中午是尖峰、午夜是低谷、週末低於工作日。模式可以預測，容量可以提前規劃。如果你的使用者分布在全球不同時區，還可以用地理分散來把曲線壓平，原理跟 Cloudflare 一樣。

第二類是強化學習（RL）訓練和模型評估（eval）。這類工作負載在圖表上看起來像一個又一個的方塊：好幾個小時使用量是零，突然飆到配額上限跑滿，一段時間後又歸零。它們不遵循任何時間規律，因為研究員可能在半夜睡前啟動一輪訓練，讓它跑到隔天早上。Burazin 說，RL 工作負載在幾個月前的佔比還是零，預計這個月會到平台總流量的 50%。成長速度驚人。

這兩種模式疊在一起之後，Daytona 的平均資源使用率只有 15%，但尖峰可以飆到 90%。振幅是 6 倍。這在傳統雲端運算中幾乎沒有先例。Burazin 在他主辦的 Compute Conference 上和 Neon（資料庫）創辦人 Nikita、Parallel（搜尋引擎）創辦人 Parag Agrawal（前 Twitter 技術長）交流後確認，所有為 Agent 打造基礎建設的公司都面臨同樣的尖峰問題。這是 Agent 時代特有的基礎建設挑戰。

面對尖峰只有兩種解法。第一種是提前超額配置：手上永遠備著足夠應對尖峰的硬體。貴，但啟動快。第二種是「即時運算」（just-in-time compute）：需求進來時再向其他供應商申請 VM 或裸機，拿到後配置好、把工作負載搬過去。便宜，但有延遲。而延遲在 RL 場景中是不可接受的，因為 CPU 沙箱產出的結果要餵給 GPU 跑下一輪。CPU 端有等待，昂貴的 GPU 就會閒置。這是花真金白銀的浪費。

回到裸機：為什麼 Kubernetes 不夠用

Daytona 的技術選擇是回到裸機，自己寫排程器。2026 年了還在用裸機？聽起來很復古。但背後有清楚的工程理由。

大多數沙箱供應商的做法是在虛擬機器上面跑 Firecracker（一種輕量虛擬化技術），然後在上面再跑工作負載。這個架構有兩個結構性的限制。第一，硬碟狀態通常不屬於沙箱本身，而是透過網路掛載（像 AWS 的 EBS），每一次檔案讀寫都會經過網路，引入延遲。對人類來說這個延遲感知不到，但對每秒可能做上千次 I/O 的 Agent 來說，累積起來就是明顯的效能損失。第二，大部分沙箱是 preemptible 的，有存活時限。時間到了就回收。

Agent 要的恰恰是相反的特性：毫秒級啟動、有狀態運行（可以暫停和恢復，像筆電蓋上螢幕再打開）、持續運行直到任務完成。Burazin 形容這是「Lambda 的速度加上 EC2 的持久性」。他們試過 Kubernetes，不夠快。試過 HashiCorp 的 Nomad，沒辦法實現需要的有狀態模式。最後，技術長從十幾年前做 CodeAnywhere（瀏覽器端 IDE）時寫過的自建排程器裡找到靈感，決定回到最底層重做。

Daytona 的架構是這樣的：沙箱的範本（snapshot）預先載入到裸機伺服器上的 NVMe 固態硬碟。當 Agent 發出「啟動沙箱」的 API 請求時，排程器把請求導向已經存放對應範本的實體機器，直接在本地啟動。因為硬碟和 CPU 之間沒有任何網路層，I/O 速度等於原生 NVMe 的速度。結果是：單一沙箱從 API 請求到就緒只要 60 毫秒（包含網路往返），同時啟動 50,000 個沙箱大約 75 秒。對比公開數據，部分競爭對手完成同樣規模的併發啟動需要超過 2,000 秒，也就是超過 30 分鐘。

Burazin 強調，光是啟動速度快並不等於贏得市場。他把 benchmark 視為「門票」：你必須在排行榜上，但客戶真正在乎的是其他東西，包括併發上限、功能完整度、和支援回應速度。

動態調整與巢狀隔離

速度之外，Daytona 的架構還有兩個技術特性值得開發者注意。

第一是動態資源調整。Agent 執行任務時經常會碰到記憶體不足（OOM）的問題。傳統做法是沙箱直接 crash，Agent 要自己處理錯誤恢復。Daytona 的做法不同：系統可以在執行期間動態擴充記憶體和磁碟空間，而不需要重啟沙箱。Burazin 說在大多數其他平台上，這幾乎是不可能做到的事，因為容器和 VM 的資源配額通常在啟動時就鎖定了。這個特性在 RL 訓練場景中特別有用，因為訓練過程中的記憶體需求往往是不可預測的。

第二是巢狀隔離。Daytona 的預設隔離方式是用 Sysbox 加固的 Docker 容器，安全等級相當於 VM，但仍保持容器的效能優勢。更關鍵的是，它支援 Docker-in-Docker：你可以在沙箱裡面再跑 Docker Compose，甚至啟動一個 K3s（輕量 Kubernetes）叢集。這對 RL 訓練和評估工作來說是大幅拓展了可行的任務範圍。如果你的 Agent 需要在隔離環境中啟動一整套微服務架構來測試程式碼，在 Daytona 上可以直接做到，不需要自己管理底層的容器巢狀問題。

Terminal Revenge 框架（一個知名的 Agent 評估框架）在官方文件中直接推薦 Daytona 作為沙箱供應商。Burazin 強調這是非付費的自發推薦，反映的是技術層面的契合度。

作業系統沙箱：Windows 的機會與 macOS 的限制

除了 Linux 容器，Daytona 正在把產品延伸到完整作業系統的沙箱，讓 Agent 能操作 Windows 和 macOS 的圖形介面。這在業界叫做「Computer Use」，概念是讓 Agent 像人類實習生一樣登入應用程式、操作介面、匯出資料。

Windows 沙箱是目前進展最快的。Daytona 可以在幾秒內啟動一個 Windows 環境，支援即時快照和分叉。相比之下，在 EC2 或 Azure 上開一台 Windows 實例需要 3 到 5 分鐘。秒級啟動意味著 Agent 可以在工作流中隨時開一台 Windows 電腦、做完事、快照保存狀態，成本按秒計算。

macOS 的挑戰大得多，主要來自 Apple 的授權限制。第一，每台實體 Mac 同時只能跑兩個虛擬機器。第二，每 24 小時只能授權給不同的使用者一次。如果 Agent 用了一秒就放開，那台機器接下來的 23 小時 59 分 59 秒都不能分給別人用，定價模式完全不同。第三，也是最棘手的：macOS 的記憶體快照和暫停恢復只能在同一台實體機器上操作，不能把快照搬到另一台機器上做負載平衡。這等於直接封死了水平擴展的路。

不過 Burazin 認為 macOS 沙箱仍然有強烈需求，特別是 RL 訓練場景。邏輯是：如果你用 macOS 環境來訓練模型操作 Mac 應用程式，下一代模型在 macOS 上的能力就會大幅進步，屆時需要在 macOS 上跑 Agent 的場景就會爆發。供給和需求會互相推動。他甚至喊話 Apple：如果放寬虛擬化的併發限制，光是授權費的規模就會遠超現有收入。

CPU 即將成為瓶頸

最後一個開發者應該放在腦中的趨勢：CPU 短缺可能比你想得更近。

半導體分析機構 Semi Analysis 的 Dylan Patel 在 Daytona 的 Compute Conference 上提出了一個通常不被討論的警告：GPU 短缺的連鎖效應正在向下游蔓延。先是 GPU 不夠，接著高頻寬記憶體（HBM）不夠，現在輪到 CPU。所有的 Agent 沙箱、資料庫、搜尋引擎、CI/CD pipeline 全都跑在 CPU 上，而這些服務的用量全都以每月 40% 以上的速度在成長。

Burazin 觀察到，這個 40% 的月增長率幾乎是整個 Agent 基礎建設市場的基準線。「如果你做這塊，月增長沒到 40% 左右，那不是你做得好或不好的問題，那就是市場在走的速度。你不需要做什麼就能有這個成長。」言下之意是，真正的競爭力不在於能否搭上這波成長，而在於能不能跑贏它。

在這個脈絡下，提前鎖定 CPU 產能正在從一個運營議題變成戰略議題。就像 GPU 供應商的成長上限取決於 NVIDIA 願意分多少晶片給你，CPU 基礎建設公司的成長上限未來也會受限於能取得多少實體硬體。Daytona 目前跑在共管機房（colocation）的裸機上，架構已經設計成可以在需要時轉向自建資料中心。Burazin 說目前從毛利率角度還不划算，因為自建需要大量資本投入，而效益只是個位數百分點的改善。但他們已經把這個選項留在架構裡了。

另一個有趣的面向是 CI/CD。Agent 時代 PR 的產出量暴增，有公司一天開出一千個 PR，全部要跑 CI。現有的 CI runner（不管是 GitHub Actions 還是其他服務）根本消化不了。有人已經在問 Daytona 的沙箱能不能當 GitHub runner 用。Burazin 沒有承諾這會變成產品，但這個需求的出現本身就說明了一件事：Agent 的連鎖效應正在衝擊軟體開發工具鏈的每一個環節。

我的觀察

這集 Podcast 的技術細節很扎實，但我覺得對臺灣開發者最有啟發性的是一個更大的結構性觀察：Agent 時代的基礎建設，正在從頭打造。

過去十多年，我們一路往「更高的抽象層」推：從實體機器到 VM，從 VM 到容器，從容器到 Kubernetes，從 Kubernetes 到 serverless。每一層的目的都是讓人類開發者不用去管底層的複雜性。但 Agent 不是人類。它不需要友善的 UI 或直覺的操作介面，它需要的是極速回應、可程式化控制、和原生的 API 存取。結果是，過去被封裝起來的底層能力，現在又得重新暴露出來。

Daytona 回到裸機、自建排程器，本質上是在說：對 Agent 這個新的「使用者」而言，過去建起來的抽象層反而是包袱。如果你正在思考「我的產品該怎麼支援 Agent」，答案可能不是在既有架構上加一層 API，而是從頭問一個問題：如果使用者不是人類，我該從哪一層開始設計？