一架架飞机在空中有序飞行，按时起降，看似只是飞机自己的事情，实际上，它需要持续与机场、跑道、航线以及地面资源系统协同。 这正是「塔台」存在的意义： 它负责把分散的飞机和地面、空中的资源协调组织起来，让飞机根据各自的任务有序运行。而当飞机越来越多、航线越来越复杂，这种统一管控和协调也就变得越来越重要 。 具身智能也同样如此。 一项具身任务，本质上是多个角色的协同：机器人和相机等现场设备、云端算力、训练与推理程序，以及连接这些角色的通信和运行环境。 而 随着更多机器人投入研发与应用，这种协同的复杂度与成本更将进一步放大 ：设备需要一个个接入，任务需要分别部署，云端与现场需要反复配置网络，不同设备和程序出了问题，还要逐一排查设备、网络、程序。 因此，当机器人从「单机」走向更大的「机群」，具身智能也需要一座新的「塔台」—— 不只是「把设备接进来」，而是 统一组织管理分散的算力、设备和执行程序，让它们围绕同一项任务协同高效运行 。 为解决这一问题，清华大学与无问芯穹共同打造并开源 面向具身智能的云原生纳管平台 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 从设备接入到真机训练，一场具身智能的跨地域实测 为了验证云端算力与现场设备能否围绕同一项任务协同运行，团队将 RLark 与强化学习基础设施框架 RLinf 结合，在 广东云端 GPU 集群与北京机器人现场 之间，完成了一次 跨地域的真机实测 。 这项实验同时涉及现场机器人与相机、云端 GPU，以及训练、推理和真机交互等多个执行角色。 现场设备 负责交互和数据采集 云端 GPU 承担训练计算，训练得到的策略再用于后续真机交互。 RLark 负责设备申请、跨集群部署、任务实例互联与运行状态汇集。 RLinf 负责训练计算与数据协作，两者共同支撑实验运行。 这次实验重点验证的，不只是「能不能把设备连起来」，而是 RLark 能否让一项原本需要多处配置、多个程序协作的复杂实验， 更快准备、更简单运行，并形成完整的采集 — 训练 — 验证闭环 。 视频地址：https://mp.weixin.qq.com/s/Jdr1wzniQD689afKGHuJ5g 5 分钟完成设备纳管：让云和端的资源可被统一申请 实验准备阶段，运维人员首先将云端 GPU 集群与现场设备所在集群接入 RLark，由各集群 Agent 同步节点容量、资源信息与运行状态。随后，通过具身设备运行时（embodied-runtime）接入已适配的双臂机器人与相机，将真实硬件注册为任务可申请、可调度的资源。 在测试环境下， 具身设备纳管从传统的 1 小时骤降为 5 分钟 。完成接入后，研究人员可以在平台中统一查看两地资源的位置、类型与可用情况，并在后续实验中持续申请和复用，无需每次重新接入设备。 10 秒内启动任务：用一份任务配置组织两地执行 资源准备就绪后， 研究人员通过一份任务配置，定义训练、推理和真机交互等执行角色，声明各角色所需的资源、实例数量与部署位置 。例如，训练角色使用云端 GPU，真机交互角色申请现场机器人与相机，共同归属于同一项具身任务。 任务提交后，RLark 将配置下发至相应集群，由 Agent 创建执行