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 或参与贡献。

本文由无问芯穹提供，量子位获授权转载，观点归原作者所有。