5分鐘完成機器人納管、10秒啟動跨集群任務，清華大學聯合無問芯穹開源具身智能雲原生平臺RLark

開源一座具身智能的新“塔臺” 一架架飛機在空中有序飛行，按時起降，看似只是飛機自己的事情，實際上，它需要持續與機場、跑道、航線以及地面資源系統協同。這正是“塔臺”存在的意義：它負責把分散的飛機和地面、空中的資源協調組織起來，讓飛機根據各自的任務有序運行。而當飛機越來越多、航線越來越複雜，這種統一管控和協調也就變得越來越重要。具身智能也同樣如此。一項具身任務，本質上是多個角色的協同：機器人和相機等現場設備、雲端算力、訓練與推理程序，以及連接這些角色的通信和運行環境。

而隨著更多機器人投入研發與應用，這種協同的複雜度與成本更將進一步放大：設備需要一個個接入，任務需要分別部署，雲端與現場需要反覆配置網絡，不同設備和程序出了問題，還要逐一排查設備、網絡、程序。因此，當機器人從“單機”走向更大的“機群”，具身智能也需要一座新的“塔臺”——不只是“把設備接進來”，而是統一組織管理分散的算力、設備和執行程序，讓它們圍繞同一項任務協同高效運行。為解決這一問題，清華大學與無問芯穹共同打造並開源面向具身智能的雲原生納管平臺 RLark。

平臺以自研的具身設備運行時（embodied-runtime）和任務級跨集群網絡互聯技術為核心，打通“真實設備如何被統一調度”與“跨地域任務如何互聯運行”兩個關鍵環節。一方面，統一管理機器人、相機等具身設備的運行時環境，讓設備可以像 GPU 一樣被申請、調度和複用；另一方面，針對不同任務和網絡流量特徵，對跨集群通信進行任務級隔離，並優化大小包傳輸性能，提升雲端與現場協同運行的效率。最終，RLark 可以將雲端算力、邊緣節點和具身設備納入統一資源體系，並以一項完整任務為單位組織運行。讓一次實驗中完成的接入、部署與通信配置，能夠在後續任務中複用。

運維人員通過一行命令即可接入並統一管理設備，研究人員通過一份任務配置，即可將訓練、推理和真機交互程序部署到不同集群。目前，RLark 已完成 3 個集群、近百個雲邊端節點的統一納管，覆蓋 4 種型號的具身設備，設備納管從小時級縮短至約 5 分鐘，任務提交後可在 10 秒內即可啟動運行。同時，RLark 進一步結合訓練框架，打通了跨地域的採集、訓練與真機驗證閉環。為具身智能實驗走向更大規模的設備與更復雜的協同場景提供基礎支撐。RLark 將從用戶界面、API、後端服務，到任務編排、跨集群互聯和具身設備運行時的整套能力開放出來，降低具身基礎設施的使用門檻，讓更多團隊可以直接部署和使用。

開源地址： github.com/RLinf/RLark 項目文檔： rlark.readthedocs.io 快速開始： github.com/RLinf/RLark#quick-start 01 從設備接入到真機訓練，一場具身智能的跨地域實測 為了驗證雲端算力與現場設備能否圍繞同一項任務協同運行，團隊將 RLark 與強化學習基礎設施框架 RLinf 結合，在廣東雲端 GPU 集群與北京機器人現場之間，完成了一次跨地域的真機實測。這項實驗同時涉及現場機器人與相機、雲端 GPU，以及訓練、推理和真機交互等多個執行角色。

現場設備負責交互和數據採集 雲端 GPU 承擔訓練計算，訓練得到的策略再用於後續真機交互。RLark 負責設備申請、跨集群部署、任務實例互聯與運行狀態彙集。RLinf 負責訓練計算與數據協作，兩者共同支撐實驗運行。這次實驗重點驗證的，不只是“能不能把設備連起來”，而是 RLark 能否讓一項原本需要多處配置、多個程序協作的複雜實驗，更快準備、更簡單運行，並形成完整的採集—訓練—驗證閉環。1.5 分鐘完成設備納管：讓雲和端的資源可被統一申請 實驗準備階段，運維人員首先將雲端 GPU 集群與現場設備所在集群接入 RLark，由各集群 Agent 同步節點容量、資源信息與運行狀態。

隨後，通過具身設備運行時（embodied-runtime）接入已適配的雙臂機器人與相機，將真實硬件註冊為任務可申請、可調度的資源。在測試環境下，具身設備納管從傳統的1小時驟降為 5 分鐘。完成接入後，研究人員可以在平臺中統一查看兩地資源的位置、類型與可用情況，並在後續實驗中持續申請和複用，無需每次重新接入設備。2.10 秒內啟動任務：用一份任務配置組織兩地執行 資源準備就緒後，研究人員通過一份任務配置，定義訓練、推理和真機交互等執行角色，聲明各角色所需的資源、實例數量與部署位置。例如，訓練角色使用雲端 GPU，真機交互角色申請現場機器人與相機，共同歸屬於同一項具身任務。

任務提交後，RLark 將配置下發至相應集群，由 Agent 創建執行實例，並建立實例之間的跨集群通信關係。在資源已接入且具備運行條件的測試環境下，任務提交後 10 秒內即可在平臺側啟動，無需逐臺登錄設備、分別部署程序。3.全鏈路跑通：實現採集—訓練—真機驗證閉環 任務啟動後，現場機器人與相機持續產生交互數據，並回傳雲端由 RLinf 用於訓練；訓練後更新的策略再用於後續真機交互，形成採集—訓練—驗證的持續循環。本次實驗連續運行約 36 分鐘，訓練推進至 323 個全局訓練步驟（global step），完整跑通了設備申請、跨集群調度、真機數據回傳、雲端訓練和策略更新全鏈路。

運行過程中，研究人員可以從同一任務入口查看各角色的狀態，並沿執行實例、節點、設備與日誌定位異常。後續更換設備、調整角色規模或算法參數時，可以直接修改並複用任務配置，減少重新搭建實驗流程的工作。通過這次實驗，RLark 將原本分散在不同地點的設備、算力和執行程序組織到同一項任務中，驗證了雲端算力與現場設備圍繞同一項任務協同運行的能力，實現了從資源接入、任務啟動到持續運行的一體化協同。4.

通信優化專項測試：跨地域真機訓練更流暢 RLark 結合虛擬尋址、gVisor 用戶態網絡棧與 SSH 安全隧道，為分佈在雲端和現場的執行實例建立通信通道，由平臺統一維護路由、隧道與轉發關係，支撐真機數據回傳與策略同步。在此基礎上，通過訓練框架 RLinf 的分佈式通信方式，進一步優化數據流轉，減少不必要的跨域傳輸，協同完成任務級跨集群通信優化。為了進一步驗證這條跨地域任務鏈路的通信能力，團隊針對任務級跨集群網絡互聯開展了專項測試。在受限網絡環境下，RLark 的大包單流吞吐較測試所用 VPN 方案提升約 49%，小包單流吞吐提升約 14%；在高帶寬環境下，大包單流吞吐接近 2 Gbps。

更高的傳輸效率，為模型、交互數據和運行信息在雲端與現場之間持續傳輸提供了更穩定的通信基礎。與傳統的 EasyTier方案對比，RLark 顯著減少了跨地域真機任務運行過程中因網絡傳輸造成的卡頓。02 RLark 技術路徑：貫通設備接入與任務運行 一項具身任務真正運行起來，需要解決的不只是設備接入，還包括任務怎麼部署、不同集群之間怎麼通信，以及運行過程中出了問題怎麼定位。RLark 採用控制面與數據面分離的架構，將分散在雲端、邊緣和實驗現場的資源納入統一管理。

RLark整體技術架構圖 用戶通過 Web 控制台、API 或命令行工具（CLI）管理資源、提交任務；控制面承擔“塔臺”的協調職責，統一維護資源信息、任務配置與通信關係；各集群中的 Agent 負責本地任務部署、資源同步與狀態回傳。這座“塔臺”主要由四項核心技術共同支撐： 1.自研具身設備插件與運行時：讓機器人成為可管理調度的資源 RLark 將雲端算力、邊緣節點與機器人、相機等具身設備納入統一資源體系。各集群 Agent 持續向控制面同步資源信息和運行狀態，用戶可以從同一入口查看資源的位置、類型與可用情況。

針對具身設備，RLark 研發了具身設備運行時（embodied-runtime），通過統一硬件抽象，將機器人、相機等真實設備轉化為雲原生系統中可識別、可申請、可調度的資源，使其能夠與 GPU 等算力資源共同參與任務編排。這一過程由設備插件與運行時協同完成：設備插件發現並註冊已適配的具身設備，將其資源信息提供給 Kubernetes；各集群 Agent 向控制面同步資源信息與運行狀態，形成覆蓋雲端算力、邊緣節點和現場設備的統一資源視圖。任務申請資源後，平臺組織資源分配，運行時為執行實例提供訪問所分配硬件的能力，打通從資源聲明、調度分配到真實設備使用的完整鏈路。

研究人員因此可以在同一份任務配置中聲明 GPU、機械臂和相機的類型與數量，由平臺統一組織使用。機器人由需要單獨連接和配置的外部設備，轉變為能夠與算力一起申請、分配和複用的任務資源。2.任務級跨集群通信優化：讓同一任務中分散的角色真正連接 RLark 研發了任務級跨集群網絡互聯技術，通過虛擬地址與 SSH 安全隧道，將同一任務中分佈在不同集群的執行實例連接起來，為雲端訓練、推理與現場真機交互提供統一通信通道。在此基礎上，訓練框架可進一步優化任務部署與數據流轉，減少不必要的跨域傳輸。首先，由 RLark 建立並管理網絡隧道，實現跨域互聯。

其核心是將執行實例的通信地址與實際部署位置解耦：平臺為實例分配虛擬地址，通過 TUN 虛擬網絡接口接收流量，由 gVisor 用戶態網絡棧處理，再經 SSH 安全隧道轉發至對端。實例通過虛擬地址相互訪問，底層路由、隧道與轉發路徑由平臺統一維護。同時，RLark 通過通信域（Domain）組織互聯範圍，結合成員關係與證書認證控制訪問，減少跨集群部署時逐一配置網絡的工作。在此基礎上，RLinf框架基於 RLark 提供的隧道，對流量進行本地化適配。該技術源自 RLinf 推出的面向真實機器人在線策略學習系統 USER，支持在真機交互過程中持續採集數據並更新模型策略。

在與 RLark 的協同中，RLinf 將觀測數據處理、推理與真機交互等環節組織在邊緣側，讓高頻交互和原始數據處理就近完成，再通過 RLark 提供的跨集群通道回傳訓練所需的數據、下發更新後的策略，減少原始觀測數據全量回傳帶來的帶寬開銷。技術論文見團隊發表在 RSS 2026 的《RLinf-USER: A Unified and Extensible System for Real-World Online Policy Learning in Embodied AI》 https://arxiv.org/abs/2602.07837 3.

聲明式任務編排：讓實驗從“腳本拼接”變成“一份配置” RLark 通過自定義任務類型，用 Job、Task 和 Worker 三層模型描述一項具身實驗：Job 代表整項任務，Task 描述訓練、推理、真機交互等執行角色，Worker 則是實際承擔這些角色的執行實例。用戶通過一份配置，聲明各角色需要的資源、實例數量和部署位置。任務提交後，控制面將部署配置下發至相應集群，由 Agent 創建 Worker 並回傳狀態。平臺統一管理各集群中的 Worker，通過持續調協，使實際運行狀態與任務配置保持一致。

後續實驗可以複用同一份配置，按需調整設備、角色規模與部署位置；具有階段依賴的流程，還可以通過 Workflow 組織多個 Job，減少維護多套啟動腳本和手動銜接實驗步驟的工作。4.任務級運行觀測：讓問題沿著任務鏈路逐層排查定位 任務運行出現異常後，如何快速知道問題出在哪裡？RLark 以同一項任務為主線，將 Job、Task、Worker 與相關節點、設備、事件和日誌關聯起來。各集群 Agent 回傳的狀態在控制面統一彙集，讓用戶能夠從一個入口查看整項任務及各執行角色的運行情況。

任務未按預期推進時，用戶可以沿著“任務—角色—執行實例”逐層排查：先判斷哪個角色未正常運行，再定位到具體 Worker，檢查其事件、日誌及關聯節點和設備的狀態。平臺同時提供 Web Terminal 與 TensorBoard 入口，支持進一步檢查運行環境、設備訪問和訓練過程，減少登錄多臺機器、跨系統尋找和核對異常信息的工作。03 共同建設持續生長的具身智能新 “塔臺” 具身智能的硬件與運行環境仍在快速變化。新的機器人、相機和傳感器還在持續接入；不同場地的網絡條件需要逐一驗證；實驗規模擴大後，調度、通信與異常恢復也會出現更多新的工程問題。

這意味著，具身智能需要的不只是一個能夠“把設備接進來”的工具，而是一套可以持續擴展、複用和共同演進的基礎設施。RLark 選擇開源，正是希望將設備適配、任務配置和真實實驗中的基礎設施經驗沉澱為可複用能力。管理員可以通過平臺管理集群、節點、設備信息和基礎組件；研發人員可以通過 Web 控制台配置採集、訓練和評測任務，並使用工作流、通信域、存儲、日誌與遠程終端管理執行過程。RLark 同時提供 API，便於接入既有算法框架與研發工具鏈。後續，RLark 將繼續完善設備與芯片適配、輕量運行時、跨域通信、任務異常恢復和實驗配置複用。

我們歡迎機器人及芯片廠商參與設備適配，歡迎算法團隊分享數據採集、訓練和驗證場景，也歡迎基礎設施開發者參與任務編排、網絡與運行觀測能力建設。我們也期待能與開源社區攜手，共同建設這座支撐具身智能走向更大規模、更復雜場景的新“塔臺”。項目地址： github.com/RLinf/RLark 歡迎 Star、部署試用、提交 Issue 或參與貢獻。