Kubernetes 適合跑 Agent 嗎?為 Agent 形狀的問題找基礎設施解法

TL;DR

• Agent 為什麼不適合 Kubernetes:agent 工作負載 bursty(短暫爆發後閒置數分鐘、數小時甚至數週)、不可信(必須跑在 sandbox 裡)、單租戶(sandbox 不能共用,否則失去意義,因而失去攤平開銷的機會)、且有人在迴圈裡(對感知延遲極度敏感)。Kubernetes 是為「跑很久、可水平擴展、開銷可攤平」的東西設計的。
• 現況只有兩種模式:(1) 用 Kubernetes 的 runtime class(預設是 OCI 容器,也有 gVisor 與 microVM)為每個使用者 session 開一個 sandbox pod——但 pod 啟動要數秒,加上 agent 自身的初始化可能再花 10–15 秒以上,於是大家用「閒置等待」來攤平,等待時間從數十秒到數十分鐘不等,期間資源完全浪費。(2) DIY:每台機器一個巨型 workload、內含 manager,自建控制平面排程進這個 mega sandbox——效率可以很高,但等於重新發明大半個 Kubernetes,對小公司與新創幾乎無法維運。
• Agent Substrate:Google 今年開始並已開源的專案,取兩種模式的優點——用 suspend/resume 加雲端儲存,把 agent 多工到預熱好的 worker 上,積極地暫停與恢復,把 5–10 秒到 10 分鐘的閒置壓到一秒甚至更少。目標規模是數十億個 session、每秒上萬次 activation、喚醒時間壓到低三位數毫秒。目前仍是 pre-production,目標是這個秋天進入可用狀態。

重點整理

Agent 工作負載為什麼「形狀不對」(約 00:45:30–00:46:40)

Hockin 說自己習慣從基礎設施由下往上看這個問題:客戶帶著「我們有一堆 agent,要跑很多、而且現在的效率不夠」來找他。Agent 與傳統應用的差異有四點:

1. Bursty:短暫爆發後閒置很久——數分鐘、數小時,甚至數天數週。天真做法會導致大量閒置資源。
2. 通常不可信:因此必須跑在 sandbox 裡,而業界也持續在找新的 sandbox 技術。
3. 單租戶:sandbox 不能共用,不然就失去意義。這代表失去大量最佳化機會,特別是開銷的攤平(amortization of overheads)。
4. 人在迴圈裡:因此對系統的感知延遲非常敏感。

而 Kubernetes 是為「跑很久、水平擴展、成本可攤平」的東西建的。所以「Kubernetes 是不是跑 agent 的正確平台」是一個公道的問題。

現有的兩種做法(約 00:46:40–00:49:50)

做法一:直接用 Kubernetes 的 runtime class

Kubernetes 的 runtime class 讓你定義一種 sandbox:預設是 Docker 式的 OCI 容器,也有 gVisor 與 microVM 的 runtime class,而且它是 Kubernetes 的擴充點,適合做研究。

流程:某個事件(例如使用者開啟一個 chat session)觸發需要一個新的 agent 實例 → 為他建立專屬的單租戶 sandbox pod。但 pod 啟動不是 Kubernetes 最快的事——通常是「秒」等級,而這不夠快;再加上 agent 啟動時要做的事(載入 runtime 環境、瀏覽器等),可能再花 10 到 15 秒以上。Pod ready 後使用者送出訊息、拿到回覆,一個 turn 結束——然後呢?

因為 pod 啟動不免費,大家的做法是等下一個事件。等多久?取決於你的 agent 在做什麼、啟動成本多高,每家算出來的數字都不一樣;他們看到的範圍是低到數十秒、高到數十分鐘。在這段時間裡,agent 佔著誰都用不到的資源。可能在第 9 分 59 秒來了下一個 turn,整個流程重來一次。最後 timeout、判定為 idle,要嘛整個丟棄、要嘛存下狀態然後終止 pod。

而這件事,是對系統上每一個使用者的每一個 agent 的每一個實例都在發生。 有 warm pool、有 suspend/resume 之類的技巧,但 Kubernetes 原生不支援這些,等於在跟系統作對,規模一大就很難自圓其說。

做法二:在 Kubernetes 上自建(DIY)

每台機器一個巨型 workload,裡面是一個 manager application;自建的控制平面負責把東西排程進那個 mega sandbox,manager 管生命週期。對 Kubernetes 而言一切都是不透明的,你會重新發明 Kubernetes 的一大部分。它可以非常有效率,但建起來相當複雜,對小公司特別是新創來說難以維運。

Agent Substrate:兩種模式的交集(約 00:49:50–00:55:00)

Hockin 說他做 Kubernetes 12 年,深信「在基礎設施這件事上,開放的一定會贏」。所以今年他們著手做一個新東西,取兩種模式的優點:能用 Kubernetes 的地方就用(幾乎所有人的機隊裡都有一些 Kubernetes),需要新元件的地方才自己建。他很坦白:這裡沒有石破天驚的新研究,他們做的是把客戶與使用者身上最好的點子黏成一個大家都能用的東西。

專案名為 Agent Substrate,已開源。核心模型很直接:不要閒置資源;用 suspend/resume 加雲端儲存,把 agent 多工到預熱好的 runner 上,並積極地暫停與恢復,把 5–10 秒到 10 分鐘的閒置壓到一秒或更短。

目標(Google 式的大規模視角):數十億個 session 在管理之下、每秒數千到數萬次 activation、喚醒時間壓進低三位數毫秒。

術語:

運作流程:從任一現代 Kubernetes 叢集開始(支援 kind,所以筆電上就能跑)。叢集管理員部署一個 Agent Substrate 實例:API server 與儲存層、負責與 Kubernetes 同步資料的 controller、一個或多個 worker pool(建立 deployment→pod 來跑你的工作負載)、管理 worker 的 atelet、以及知道怎麼把外部流量帶進內部的 atenet proxy。接著 substrate 管理員建立一個或多個 actor template,controller 看到後做預備工作:把 template 啟動起來、拍一份快照(他們稱為 golden snapshot)存起來備用。

到 substrate 層(他提醒其中一部分還是 aspirational,仍在開發中):由更上層的系統從 template 建立一個 actor(注意:建立 actor 不等於執行 actor)。以聊天應用為例,前端做完授權等工作後建立 actor;使用者送出 prompt → 路由到 atenet proxy → 喚醒 actor,透過 router 送訊息把它指派給一個 worker → 因為是新 actor,就從 golden snapshot 喚醒 → proxy 把訊息轉給現在已在執行的 actor。這整個過程只要幾百毫秒,而且還在繼續優化。

Turn 一結束,actor 大概就閒置了,於是叫它回去睡覺——他們稱為 pause:拍快照、把資料搬走,worker 隨即解除指派、可供其他 actor 使用。這些都能以「一次 API 操作 / 一次 agent transaction」的速度發生。下一個 prompt 進來就再跑一次循環;最後沒有訊息了,資料會被搬到雲端儲存,「睡到明天」。

從最高層看:一個 Kubernetes 叢集可以是筆電上的單節點,也可以是雲端的 20 萬節點;每個節點跑多個 worker;而每個 agent 有 99.999% 的時間是閒置的——算一下就知道為什麼能衝到「數十億」那個數量級。

現況與邀請(約 00:55:00–00:55:30)

Agent Substrate 是開源專案,目前仍是 pre-production grade,他們的目標是這個秋天結束前進入可用狀態。他要的回饋很具體:經驗、需求,以及你們拿 agent 在做什麼的脈絡。

金句

"Kubernetes was built for things that run for a long time and tend to be scale out, horizontally scalable, and you can amortize your costs."(約 00:46:29)

一句話說完為什麼 agent 的形狀跟 Kubernetes 不合。

"I have a deeply held belief that when it comes to infrastructure, open always wins."(約 00:49:56)

做了 12 年 Kubernetes 的人給 Agent Substrate 開源的理由。

"Each of those agents are idle 99.999% of the time, so you can do the math and see we're driving up to those billions of numbers."(約 00:54:50)

這個數字就是整套 suspend/resume 設計的經濟學基礎。