開放的 Agentic Stack:用開源、開放標準與可組合性打造 AI 系統的未來

開場:Matt White — 為什麼 agent 時代的開放性更重要(約 02:58:30–03:04:45)

他先自我介紹:Linux Foundation 前 AI 全球 CTO,曾任 PyTorch Foundation 執行董事與 CTO,現為哥倫比亞大學訪問學者。這一段沒有投影片,他明說「就是我在碎念」,但這是整場的立論基礎。

論點一:能力躍升的同時,開放性正承受真實壓力。 模型現在能跨長脈絡推理、寫並執行程式碼、使用工具與操作軟體、協調日益複雜的工作流,能解複雜數學證明、生成龐大程式庫、驅動會在生產網路上採取行動、產生真實世界影響的系統。而恰恰在這個時刻,「限制甚至禁止 open-weight 模型的取用」已不再是假設性議題——它正在華府與各地被積極辯論;同時也有透過晶片、算力、蒸餾、安全測試與模型釋出流程來控制前沿的提案。

他明確承認:這些安全、資安與國安顧慮是真實且正當的,值得技術上嚴謹的回應。 但另一邊的風險也必須說清楚:粗糙的限制會把能力、基礎設施與決策權集中到極少數機構手上,把 AI 從一個可廣泛取得的通用技術,變成「社會其餘部分只被允許向少數幾間實驗室租用」的東西。「That cannot be the foundation on which we build the future.」

論點二:開放是競爭與安全的來源。 開放帶來競爭,讓研究者能檢視系統、開發者能改造、學生能學習、企業能維持對自身資料與 stack 的主權、國家能建立不永久依賴單一供應商的 AI 能力。開放同時是安全的必要成分:可重現的評估、透明的介面、獨立的審查、共享的安全工具,以及發現並修正問題的能力。

但他也劃清界線:開放不等於無治理,不等於粗心、不安全或放任。開放意味著系統可被檢視、評估、改造與改進;介面可互通、實作可被挑戰,而且沒有任何單一組織控制所有層級或決定誰能參與。

論點三:agent 讓這件事更關鍵,因為 agent 是一個 stack。 一個 agent 包含模型、harness、它能呼叫的工具、它行動的環境、guardrail、讓它變好的 RL 系統、量測它的評估基礎設施,以及支撐一切的算力;它可能依賴 API、憑證、sandbox、記憶、推論系統、編排框架與多種專用硬體,並在完成單一任務的過程中跨越組織、雲端與地理邊界。任一層被封閉並垂直控制,整個生態系就變得不可攜、缺乏競爭、更脆弱。

所以:光有開放模型不夠。還需要開放的環境(agentic 任務才能被重現與分享)、開放的 RL 框架(更多人才能改進模型與 agent)、開放的算力層(工作負載不被單一雲或算力供應商綁架),以及開放的標準(讓所有元件無需向中央平台請求許可就能協同)。

Open agentic stack 不是一個專案、一個框架或一個模型,而是一個由開源軟體、開放標準與可組合元件構成的共享架構。 這場 workshop 就沿著四個基礎層走:環境、模型、強化學習、算力。四場講題各自處理不同的技術挑戰,但共享同一個原則:AI 的未來應該是模組化而非單體、可互通而非受困、開放參與而非許可制。 他強調這不只是哲學偏好,而是健康 AI 生態系在架構、經濟與戰略上的要求。

子講題一:Ben Burtenshaw(Hugging Face)— Open Source Agentic RL Environment(約 03:05:45–03:18:20)

主張:RL 環境是民主化 AI 最好的方式——因為環境「就只是應用程式」,是我們每天都在寫的那種東西,所以人人都能參與。

什麼是 RL 環境。 最簡單的說法:一個 actor / agent 在其中行動的世界。經典例子是西洋棋——棋盤是世界、棋子是狀態、規則是可採取的行動、分數是 reward,而 RL 就是拿這個 reward 去更新 agent。放大到現實:軟體工程可以定義成任務在 GitHub issue、工作在 pull request、分數是測試套件與 CI 的結果——這就是 SWE-smith 這類論文建構軟體工程環境的方式。把 PR 裡的程式碼拿掉、讓 agent 自己生成、再用測試套件給 reward,你就有了一個能訓練軟體工程 agent 的環境。同樣的原型可以搬到 email triage、專案管理等任務——只要在該環境中定義出任務、reward 與狀態,再把它做成應用程式。

生態系:「capability cycle」。 他把老派機器學習的 MATTER cycle(model, annotate, train, test, evaluate, revise)更新成能力循環:discover → benchmark → represent → train。

1. 用 harness 或 prompt 誘出(elicit) 一個能力,看到模型「做得到,只是不太可靠」。
2. 用另一套 evaluation harness 量測這個能力的頻率與可靠度,社群可以在上面迭代。
3. 把它表徵成資料集,最終成為環境——這一步需要領域專業。像 Mercor 這類公司會去接觸並雇用各領域專家,圍繞某個能力打造 RL 環境,部分基於 benchmark,但理想上兩者之間不能有洩漏。
4. 交給 trainer 訓練——又是另一段軟體 stack、另一個社群。

結論:環境正是把能力從領域專家搬進模型的載體;能力進了權重之後,大家就往下一個能力前進。既然這麼多社群都在環境上交會,這一層就非開放不可——「想像一下如果資料集是封閉格式,那會有多可怕」。

現況的問題:環境極度分散。 你只能去論文與 GitHub 找。最近的 Kimi K3 論文附帶了數千個環境,MiniMax 論文他記得有一萬個,連第一篇 DeepSeek 論文也有約一千個。而這些實作方式各異、分享方式各異,很多是被販售的,不像 open-weight 模型那樣唾手可得。他形容這很像 2017 年當 MLE 的日子:在 GitHub 找到實作、再去 Google Drive 找權重,什麼都沒有像今天的 model checkpoint 那樣可暴露、可互通。

訓練時問題會複合。 訓練流程是一個框架(如 TRL 或 Unsloth)根據模型的行為更新模型,而中間需要一個 agent harness 去執行任務、與環境互動、使用環境裡的工具,然後才更新模型。每一條邊都是一個需要被介面化的層——harness 不能寫死它預期的環境定義,而且還得同時支援多種 harness(他點名 Codex、Claude Code 等)。

OpenEnv 的解法。

• 環境 hub:Hugging Face 上目前有約 4,000 個環境,以標準格式提供,可接進大多數主流訓練框架。其他 hub 還有 Prime Intellect,更多正在出現;他們正與其他組織共享規格,讓別人建 hub 時也能用同一套 spec 下載與分享環境。
• CLI 體驗像 Docker:openenv init 給你一個 hello-world 環境的骨架(只回傳一個泛用分數),接著你只要寫自己的業務邏輯——或請 coding agent 幫你生成。也可以從 verifiers 之類的函式庫匯入環境,然後在 hub 上 push / pull / fork。
• 下一步是 discover 與 validate:目前找到適合自己用例的環境很困難,能在 hub 上搜尋之後就能撈到一堆社群環境;但這帶來新問題——哪個環境比較好?哪個真的對我的用例有幫助? 於是有了新的 validate 指令:確認 spec 有效,並且訓一個小模型看它是否在給定 benchmark 上帶來提升。這兩個指令合起來,就構成 post-training 中整合環境的自主迴路。

怎麼用一個 RL 環境? 三條路,由易到難:

1. Evaluation(他建議大多數人從這裡開始):把典型工作負載表徵成環境,拿模型(權重或純 API)跑一組任務加 reward function,得到一個總分。
2. Reinforcement learning(核心用法):拿一個 policy 在環境中 rollout 得到一組動作,對每次 rollout 算 reward,用 GRPO 之類的演算法取整組平均後更新權重,反覆迭代。
3. Distillation:這時不能從字串/token 蒸餾,需要 log probabilities。取一個 student 與一個 teacher,讓 student 在環境中執行任務、取其 log probs;再讓 teacher 在同一批 token 上 rollout、取其 log probs;用兩者的差(reverse KL)更新 student。變體包括 self-distillation(拿 student 最好的一次跟平均比),或給 student 特權資訊 / 提示——例如在 PR 情境裡,一開始就把真正的解法給 agent,再用它「差的一次」與「好的一次」之差來更新權重。

他認為這件事會怎麼成功:leaderboard。 環境目前活在一個「影子領域」——在圍繞模型發布的社群討論裡幾乎不被提及。他相信只要大家開始自己建環境、試環境,再把它們放上 leaderboard、找出哪些真的對模型成功有貢獻,就會有更多人參與。

子講題二:Daniel Han Chen(Unsloth)— Making Open Models Not Suck(約 03:19:38–03:35:35)

Unsloth 是誰。 Hugging Face 上最大的組織之一,約 4 億次累計下載(他說這數字已過時),是全世界第三大的模型散布者,大模型小模型都發。但他們不只散布模型,還修 bug:與全球各大實驗室與硬體供應商合作,在模型送到你手上之前先修好問題。他點名 OpenAI 的 gpt-oss、Llama、Gemma、Mistral 都曾有問題。「如果你在筆電上跑開源模型,它八成被我們以某種方式修過。」

量化的現況。 Kimi K3 幾天前(週一)發布,是任何人都能下載的最強 open-weight 模型,原始大小 1.5 TB;他們把它量化到 1 bit,降到約 600 GB。難點在於 Kimi K3 原生就是 4-bit,從 4-bit 再壓到 1-bit 省下的空間有限;但他們的結果是保留 76–78% 的準確率,體積減少 82%——「把模型縮小 82%,不會讓它笨 82%,只會笨 16% 左右」。另外 DeepSeek V4 Flash 前一天(0731)在一個奇怪的時區突然發布,他們也量化了,現在只需 90 GB 的 VRAM 或 RAM 就能跑;他評價它是同尺寸中最好的模型——Kimi K3 更強但體積巨大,V4 Flash 則真的能塞進你的本機。

METR 曲線與「推理發明前的平行線」。 他展示 METR 的任務時長圖:模型現在能完成人類要花 16 小時的任務(50% 成功率;80% 成功率下約 6 小時)。他自己把 Mythos / Fable 標成紅線,也標了 GPT-5.6 Sol——這是移除作弊案例後的數字;若把作弊案例算進去,GPT-5.6 Sol 是 270 小時,但那不是好例子,移除後約 16 小時。

他的核心觀察是曲線上那段水平區:2023 到 2024 年左右其實有一段近似停滯(GPT-4 到 GPT-4o 進步不大),原因是強化學習與推理當時還沒被發明。如果分開擬合「推理發明前」與「推理發明後」兩段趨勢: - 灰線(推理前):能力每 7 個月翻倍;若 OpenAI 沒推出 o1-preview、沒告訴大家可以做推理,模型現在早就平原化了。 - 綠線(加入 RL 與推理後):翻倍時間縮短到 3.5 個月——「Opus 5 幾天前發布,再等 3.5 個月就會有比它更好的」。

但他強調前提是趨勢會延續:根本問題是綠線會不會一直往上,還是我們會退回灰線、AI 放慢然後得再發明新東西。「這是我們有生之年會看到答案的問題——你只要等 3.5 到 7 個月就知道了。」

開源模型追上封閉模型了嗎? 他先引 Artificial Analysis 的開源 vs 閉源曲線:開放模型已經非常接近閉源。但他說自己最愛的單一 benchmark 是 WeirdML(Google 搜 "weird ML"),理由是很難被 game。依 WeirdML:Fable 5 表現很好但極度昂貴;就成本與準確率的平衡而言他推薦 Opus 5 High;開放模型裡 Kimi K3 非常強大,也在榜上。

他接著把「閉源分數減開放分數」畫成一條差距曲線:約一年半前有一段他稱為 open source drought(開源乾旱) 的落差,對應 o1-preview 之後開放模型跟不上的時期;而 DeepSeek R1 公開了 GRPO 怎麼做之後,開放模型重回趨勢線。他的估計:若 DeepSeek 沒有公開 GRPO,開放模型會落後閉源 16 個月;現在只落後約 2 個月。 有一篇 blog post 外推到 2026 年 12 月會出現與閉源同級的開放模型——但這都是趨勢外推,「誰知道呢,等幾個月就知道了」。

token 價格暴跌是合理的嗎? 他注意到 OpenAI 幾天前把 GPT Luna 降價 80%,聽起來驚人,但他認為其實不奇怪,並在演講前實際算了一遍:

• 依 SemiAnalysis 的 InferenceX 對 vLLM / SGLang 等推論引擎在 NVIDIA 與 AMD GPU 上的 benchmark:DeepSeek V4 Pro 在單張 GB300 上約 13k tokens/s 吞吐 → 一小時 4,700 萬 token。
• GB300 的價格約 每 GPU 每小時 5 美元。
• 兩者相除:DeepSeek V4 Pro 的地板價約 11 美分 / 百萬 token。而 DeepSeek 實際收 44 美分 / 百萬輸入 token、87 美分 / 百萬輸出 token——所以並不是在燒錢。
• 同理,假設 GPT-5.6 Luna 與 DeepSeek V4 同尺寸(他明說「很可能不是」),OpenAI 降到那個價位仍有約 1 美元 / 百萬輸出 token 的空間。
• 對照組:Kimi K3 是新架構、尚未充分最佳化,依 SemiAnalysis 約 5k tokens/s per GPU(比 DeepSeek 慢約 2.6 倍),地板價約 30 美分 / 百萬 token;而它實際收 15 美元 / 百萬輸出 token——也就是 Moonshot 與其他推論供應商在你的 API 費用上賺了約 14.17 美元。「他們如果想降,可以一路降到 30 美分。」結論:這些模型的價格仍然偏高,DeepSeek 是唯一接近地板價收費的。

另一條路:在本機跑。 他也喜歡看 Arena 的 Pareto efficiency 圖(他說自己不太看 Arena 分數,但這張圖有用):很多開源模型都在 Pareto 前緣上。以 web development(HTML/前端)為例,Opus 5 Max 目前最好,Kimi K3 緊追在後;GLM 5.2 等模型也在圖上。而如果你不想付 API 費用,可以在本機跑——成本降到只剩電費與一些前期投入。

這正是 Unsloth 在做的事:用 dynamic quantization 把模型壓到極小的 bit 數。GLM 5.2 的 1-bit 版是個好例子——一次 prompt(沒有讓它改 bug、修 bug)就表現得非常好,對比的還是全精度的閉源模型。他們也發布 perplexity 與 KL divergence 的 benchmark 佐證 1-bit 可用。他們的目標是繼續往下壓:Kimi 現在 600 GB「大概還塞不進你的電腦」,他們想做到甚至低於 1 bit,例如把 Kimi 壓到 250 GB。

最後一個重點:ARC-AGI 的 harness 設定。 幾天前 OpenAI 指出 ARC-AGI benchmark 對 GPT 其實不太公平,原因是評測用了 175k token 的 rolling truncation,而且沒有啟用 compaction、沒有啟用 preserve thinking。他的結論很直接:只要打開這兩個 flag,OpenAI 模型的準確率就能一路提升到 40%——你什麼都不用做。(他在此因時間不足跳過剩下的投影片。)

子講題三:Shang Yang(RadixArk)— Miles: An Intro to Enterprise Facing RL with Miles(約 03:36:48–03:45:35)

講者自我介紹:RadixArk 的 research resident,同時是 MIT 博士生,代表團隊介紹 Miles。

Miles 是什麼:RadixArk 開發的開源 RL 引擎,面向前沿模型的生產級強化學習,主打快速與穩定。定位是「穩定、高效、可重現的大規模 RL 系統」——讓你用最小的力氣,就能在現代語言模型上、搭配各種環境與 reward 設計跑起 RL 訓練。

三層架構:

1. Rollout 層:以 SGLang 作為 rollout 引擎,專為高吞吐生成最佳化,且與當今的 agentic 系統、agentic 環境與 agentic infra 高度相容。
2. 編排層(中間):把 rollout 引擎與後端訓練系統組織成一個整體,讓系統高效運轉。
3. 訓練層:支援 Megatron 與 FSDP 等不同訓練引擎,也可在自己的算力上自訂訓練引擎。

資料流:rollout 引擎與外部環境或 agent 框架互動產生 trajectory(SGLang 提供生成層,環境本身可依客戶需求高度客製)→ 中間層把 trajectory 轉成 reward 與 loss 等訓練訊號 → Megatron / FSDP 做 forward/backward、算 loss、更新權重 → 權重同步回推論引擎,整條 pipeline 循環運轉。

為什麼用 SGLang 當 rollout 後端: - 與 RL 工作負載共同演化,包含 partial rollout 支援與專用的 rollout 控制,容易針對特定工作負載定制。 - router 設計效能高:精心設計的快取與負載平衡以支撐高吞吐生成。 - 原生支援與訓練引擎的非同步生成——這是當代 RL 演算法的關鍵特性。 - 迭代快,且有許多最佳化,例如與 Miles 搭配的 speculative decoding,可在 RL 的 rollout 階段使用。

Miles 如何改變 RL 開發流程: - 可客製:用可插拔的 function pass 支援不同工作負載,自定 RL 工作負載、reward function 與更新方法都很容易。 - 模組化且非侵入式:更換訓練後端(FSDP / Megatron)很容易,未來會支援更多後端。

系統設計細節: - Multi-agentic rollout;特別支援 token-in-token-out(TITO)——同一段 multi-turn 生成不需要反覆 tokenize / detokenize,省下大量成本、也讓推論更穩定。 - R3(routing replay):訓練 MoE 模型時,同一個請求在不同次執行可能被路由到不同的 expert;R3 確保這件事完全可重現。 - 低精度:端到端 MXFP8 支援,以及 rollout 階段的 per-token NVFP4 量化,可大幅降低延遲、提升吞吐——都已在他們最新的 blog 以真實訓練工作負載驗證。 - LoRA 支援,供資源受限情境下用較少 GPU 訓練大模型。

支援矩陣與實績: - Day-zero 支援最新模型:Kimi K3、Thinking Machines Lab 的 Ling(逐字稿作 "inkling",待確認)、DeepSeek V4、Nemotron Ultra 等。 - 廣泛的精度與硬體支援;fine-tuning recipe 不只 SFT / RL,也支援 on-policy distillation。 - 已在 超過 10,000 張 GPU 的 RL 訓練工作負載上驗證。以 Kimi K2.6 為例,生成吞吐加速到 每 GPU 每分鐘 12.5k output tokens。 - 穩定性最佳化:R3、TITO,以及精度對齊訓練(降低 training–inference mismatch);另有容錯恢復,並支援 Ray on Kubernetes、Slurm、bare metal 等叢集後端。

近期成果: - Kimi K3(近 3 兆參數)day-zero 支援,並用 Miles 在數學題目上做 fine-tuning,準確率從 40% 左右提升到 76%。 - Ling(Thinking Machines Lab,兆級參數):做了全參數 fine-tuning 與 LoRA fine-tuning,並最佳化 LoRA adapter 同步(把 LoRA rank merge 進 SGLang 推論引擎),把時間從近 50 秒降到不到 3 秒。 - 一篇混合精度訓練的近期 blog:驗證用 MXFP8 或 NVFP4 等不同精度選擇,能在維持模型準確率與訓練穩定性的同時,大幅加速 rollout 與推論。

子講題四:Romil Bhardwaj(SkyPilot)— AI Needs an Open Compute Layer(約 03:46:13–03:55:58)

論點:AI 需要一個開放的算力層——具體來說,是一個坐在工作負載與實際 GPU 之間的東西。

為什麼建 AI infra 這麼難?他用 OpenAI 當例子:2016 年與 Azure 簽下 GPU 獨家供應協議;2024 年又與 Oracle 簽了 100 億美元的合約換更多算力;僅僅一年後又與 CoreWeave 簽了 110 億美元。而即使如此仍不夠——Sam Altman 還在推特上喊「我們需要更多 GPU,你要是能弄到就打給我們」。他的推論很直接:如果地球上資金最雄厚的公司都拿不到足夠的 GPU、也拿不到單一叢集裡的量,那你大概也拿不到。GPU 短缺是非常真實的。

典型 AI 組織的算力現況:AI 團隊手上有一些 NeoCloud 保留量(hyperscaler 沒容量時簽的 2–3 年合約);又加了一些 hyperscaler 的 on-demand 實例補容量;因法規或想把資料留在自家而又有一些 on-prem 叢集;客戶在歐洲所以還得在歐洲再開一個叢集;最後為了跑環境與 sandbox,還需要一大票 CPU,於是又多維護一個 CPU 叢集。每一個決策在當下都合理,但結果是你現在得管理一大堆叢集。

RL 讓情況更糟——它把問題變成排程問題。 一次 RL 訓練整體是一個 job,但由許多子元件構成,且資源需求截然不同:trainer 需要大量 VRAM、需要很猛的 GPU;rollout server(產生 trajectory 的那個)不需要那麼多 VRAM,但需要很多張才能大量生成;而若做程式碼生成,sandbox 需要大量並行 CPU 來執行所有 trajectory,而且要求很快的啟動速度。

為什麼不直接用現成方案? - Slurm:二十年前來自 HPC 世界,他認為是最好的進階排程與 quota / 優先權管理系統之一。但不支援容器形式的隔離(pyroot 之類可以硬接上去,但本來就不是為此設計),而且從來不是為 serving 而生——它是 batch job 導向。 - Kubernetes:約十年前出現,微服務起家,很有彈性、為雲而生。但學習曲線極陡(「把 Kubernetes 交給一個研究員,他大概只能去問 agent 怎麼用」),而且缺少 AI 需要的原語,尤其是 gang scheduling——同樣得靠 Volcano 之類的排程器硬接。

更關鍵的是:兩者都是單一叢集管理器,都不解決「我有 10 個叢集在跑,要怎麼管」的問題。所以真正缺的不是更好的排程器,而是管理這些排程器與平台的東西。

目標不是取代 Kubernetes 或 Slurm——它們在各自的領域很好——而是橋接:一邊是訓練、serving、sandbox 這些工作負載,一邊是散落在 Kubernetes、Slurm 等處的破碎算力。理想的開放統一算力層要能最佳化可得性、決定 job 跑在哪裡最好、處理執行,而且讓工作負載不必知道底下是什麼。

SkyPilot 就是在做這件事:完全開源、讓你在任何有算力的地方使用 AI 算力,核心理念是 bring your own framework——Ray、PyTorch、OpenEnv、Unsloth,你自己的框架都行;你只要提交「我需要 8 張 B300 跑這個」,SkyPilot 就負責編排:掃過你的 Slurm 叢集、Kubernetes 叢集甚至雲端 VM,安排資源、跑 job、把 log 與結果交回來。專案起源於幾棟樓外的 Soda Hall,根植於 Sky Computing Lab 的研究,社群活躍,也被目前最大的一些公司使用。

實際長什麼樣: - 最簡單的取得資源方式就是 sky launch,指定要跑在哪個 infra、需要什麼 GPU。從 Kubernetes 換到 AWS 只是改一個 flag;換 GPU 型號也是改一個 flag(你的應用不需要知道底下跑什麼)。 - 更複雜的情境用 job groups 這個宣告式抽象:例如「我有一個 rollout server 需要這些資源、跑這些指令;我要開一千個 sandbox 跑東西;rollout server 跑 H100,trainer 跑 B200」,交給 SkyPilot 編排整個工作負載。過程中還附帶 service discovery 與生命週期管理——其中一個 job 掛掉不代表整輪要失敗,它會自動重啟那個 job。

Serving 同樣受益:你獲得跨所有叢集的容量——不必在單一叢集起一個 KServe 實例,而是讓 SkyPilot 跨叢集跑推論;發生故障時可無縫把 replica 搬到還有容量的區域。而把所有工作負載都走同一層之後,還能做一件有意思的事:在同一批算力上同時跑推論與訓練——推論請求暴增時,SkyPilot 可以動態把資源從訓練挪給推論(先 preempt 訓練 job,由你的 checkpointing 邏輯保住進度);等尖峰過去再自動縮回推論、繼續訓練。

最後他強調 bring-your-own:你不是把信用卡交給 SkyPilot 去買算力,而是自帶算力、自帶資料,一切跑在你自己的環境裡。結語呼應開場:我們不需要重新發明或取代 Kubernetes 與 Slurm,需要的是一個統一層,橋接工作負載與你手上那一堆叢集。