东南大学等打造：让机器人真正"看懂世界、动起来"的统一推理引擎

最近，东南大学、南京大学、微软研究院与清华大学人工智能产业研究院联合发布了一项新研究，预印本编号为arXiv:2607.02501，感兴趣的话可以直接去查。

想象一下，你家里有个机器人助手，它得用眼睛看周围，用“脑子”理解人说的话，然后指挥手臂干活。但如今市面上机器人AI模型越来越多，每个都有自己的运行方式和配套工具，简直像不同品牌的电器非要用不同的插头——买台新设备就得换一套插座。这种混乱让机器人落地变得极其折腾。这篇论文干的事，就是打造一个“万能插座”：一个叫Embodied.cpp的统一推理运行时，让各种机器人AI模型都能顺畅地插进去运行。

一、机器人AI的“插头乱象”：为什么现在的软件生态一团糟

走进一家餐厅，厨房里有炒锅、蒸锅、烤箱、微波炉，每件设备处理不同食材，服务员端盘子的节奏和厨师翻炒的节奏也完全不同。机器人AI的运行方式与此高度相似——它不是一个统一整体，而是由若干模块协同工作的复杂系统。

目前主流的机器人AI模型可以分成两大家族。第一类叫“视觉-语言-动作模型”，缩写VLA，顾名思义，它同时处理视觉信息、语言指令，并输出机器人的动作。第二类叫“世界-动作模型”，缩写WAM，这类模型更进一步——它不仅控制机器人动作，还会在脑子里先“预测未来会发生什么”，再根据这个预测决定怎么动。打个比方：VLA模型像一位经验丰富的厨师，看到食材、听到菜名，直接下手操作；WAM模型更像一位会下棋的大厨，切菜之前先在脑海里推演几步——“如果我先焯水再爆炒，效果会不会更好”。

这两类模型目前都依赖各自专属的Python代码栈，就像每位厨师只用自己那套专用刀具，根本不能共用。研究团队发现，哪怕一个模型在实验室里表现再好，要真正部署到机器人上，工程师还得手写传感器数据的包装代码、给不同硬件平台写特殊的运行路径、在机器人控制逻辑里再拼一堆胶水代码。随着模型种类越来越多，这种重复劳动只会越来越重。

与此同时，现有的通用AI推理框架，比如llama.cpp、ONNX Runtime、SGLang、vLLM等，都是为“问答式”场景设计的——用户发一条请求，模型回一条回复，完成交互。但机器人运行在一个持续的闭环控制过程中，就像骑自行车，你不能骑一下停一下再骑，必须持续调整方向和力度。这种“持续闭环”与“一问一答”的本质差异，使得现有推理框架无法直接用于机器人AI部署。

二、机器人AI运行的三道“难关”：研究团队面临的真实挑战

研究团队在深入分析后，把机器人AI部署的核心困难归纳为三个方面，每个都需要在系统设计层面认真应对。

第一道难关是“多速度同步运行”。不同类型的机器人AI模型，其内部各个模块的运行频率完全不同。感知摄像头数据的模块可能每隔几帧才需要刷新一次，而机器人手臂的动作指令却需要每秒钟发出很多条。如果强制让所有模块按同一个节奏运行，要么浪费计算资源，要么延误关键的控制信号。这就好比一个乐队，小提琴手、打击乐手、指挥各有各的节奏，不能强迫所有人同步敲击同一个节拍。

第二道难关是“低延迟优先的闭环控制”。机器人控制对延迟极其敏感——如果AI模型的推理时间太长，机器人的反应就会滞后，动作就会出错。更棘手的是，机器人通常运行在算力受限的边缘设备上，比如英伟达Jetson开发板、瑞芯微RK系列芯片、普通x86工控机等，这些设备的计算能力远不及数据中心的服务器。在这类硬件上做到低延迟、低抖动的实时推理，是一个真实且艰难的工程挑战。

第三道难关是“可扩展的机器人专用接口”。机器人AI不只是输入文字、输出文字那么简单。输入端可能包括RGB摄像头图像、深度图像、机器人自身的关节角度（专业叫“本体感觉”）、历史动作记录、力传感器数据、触觉传感器数据，甚至是仿真环境提供的虚拟状态信息。输出端同样多样，可能是离散的动作标记、连续的动作向量、一段时间窗口内的动作序列（专业叫“动作块”）、对未来世界状态的预测，或者是层级控制中的中间指令。一个固定的“文字进、文字出”接口根本无法承载这些需求。

三、解剖机器人AI的“大脑结构”：VLA模型与WAM模型的全景分析

在动手构建运行框架之前，研究团队首先系统梳理了现有各类机器人AI模型的内部结构，这是整个工作的基础。

在VLA模型家族中，研究团队识别出四种主要的架构演化方向。最早期的形态叫“自回归标记VLA”，代表作是谷歌的RT-2和OpenVLA。这类模型用一个统一的大模型骨干网络，像写作文一样，一个字一个字地生成动作指令标记。这种方式结构简单，但所有工作都由一个模块完成，灵活性不足。

第二种形态叫“VLM骨干VLA”，代表作包括Octo、pi0、pi0.5以及MuseVLA。这类模型保留了一个强大的视觉-语言预训练骨干网络，但在输出端专门配备了一个连续动作生成头，专门处理平滑的运动输出，而不是把动作硬塞进离散标记的框架里。

第三种形态叫“层级VLA”，代表作有Hi Robot、GeneralVLA、RT-H以及谷歌的Gemini Robotics 1.5。这类模型把任务拆成两层：上层是一个“战略规划师”，负责理解高层目标并产生子目标或选项；下层是一个“执行者”，专门接收子目标并产生精细的动作指令。两层之间有清晰的接口，各司其职。

第四种形态叫“异步VLA”，代表作有GR00T N1、Fast-in-Slow以及DAM-VLA。这类模型把执行分成快慢两个时间尺度：负责“慢思考”的模块处理复杂语义理解，负责“快反应”的模块处理高频动作执行，两者通过缓冲区协调，互不阻塞。这一设计直接对应了前面说的“多速度同步运行”难题。

在WAM模型家族中，研究团队同样总结了四种组织方式。“预测后动作WAM”的代表作是UniPi，它把未来预测和动作执行明确分成两个独立阶段，世界模型先算出未来的状态，动作专家再根据这个预测输出指令。“统一自回归建模WAM”的代表作是WorldVLA和LingBot-VA，它把世界预测和动作生成压缩到同一个自回归标记空间里联合生成，结构更紧凑。“共享骨干WAM”的代表作是DreamZero、Fast-WAM、Cosmos Policy以及统一视频动作模型UWM，这类模型让世界建模和动作生成共用一个骨干网络，但仍然暴露出可以独立调度的功能块。“潜空间WAM”的代表作是LaWAM和Being-H0.7，这类模型把未来预测压缩成一个紧凑的“潜在未来”向量，交给下游动作专家消费，而不是生成完整的未来帧，计算开销更小。

通过这番全景扫描，研究团队得出了三个关键洞察：首先，模块化结构已经成为现代机器人AI模型的核心特征，而非例外；其次，子目标、缓冲状态、预测未来、潜在子目标这些中间状态，已经从模型内部的隐藏细节变成了必须在运行时显式管理的对象；第三，时序结构越来越由模型本身定义，运行框架必须支持有状态的多组件编排，而不能假设所有东西都是一次同步的请求-回复。

四、Embodied.cpp的设计蓝图：一套“万能厨房”的建造方案

理解了问题所在，研究团队把他们的解决方案设计成一个五层架构，可以用“万能厨房”这个比喻来理解整个体系。

最外层是两排接口：左边是“食材入口”（输入适配器），右边是“出菜口”（部署适配器）。食材入口负责把各种来源的数据统一规范化——无论是真实摄像头的视频流、力传感器的数值、IMU的姿态数据，还是LIBERO、DROID、BridgeData、RT-X等标准数据集里的样本，全部经过这个入口转换成运行时内部统一认识的格式，就像餐厅的备料间，不管食材从哪里买来，进入厨房之前都要洗净、切好、分类。出菜口则负责把模型产生的动作指令翻译成机器人或仿真器能理解的格式，支持ROS（机器人操作系统）、Apollo Cyber RT、Isaac Sim、Gazebo等主流机器人软件生态。

进入厨房内部，第二层是“序列构建器”，负责把规范化的多模态输入（图像、语言、状态）拼装成模型骨干网络能处理的输入序列，就像把备好的食材按照食谱要求摆盘，等待下锅。

第三层是“骨干执行”，这是整个厨房的核心炉灶，承担了最重的计算工作——运行大型视觉-语言骨干网络（比如PaliGemma或Hunyuan-VL），提取跨模态的特征表示。这一层的设计特别注重延迟优先的融合推理，支持图计算重放、缓冲区复用、算子融合以及后端专属分发，在CPU、GPU、NPU等不同硬件上都能高效运行batch-1的小批量推理。

第四层是“头部插件”，这是可更换的出餐模块，专门处理各种不同类型的输出。想要输出连续动作流，就换上流式动作头；想要输出扩散模型预测的动作块，就换上扩散头；想要输出世界状态的预测，就换上世界预测头。每种头部都是一个独立的插件，不需要改动底层厨房结构，只换前端出餐口就行。

贯穿整个体系的是一个“机器人AI算子仓库”，收录了各类机器人AI模型所需的专用算子和内核，就像厨房里备齐了各种调料和烹饪工具，新来的模型只需要从仓库里取用现成组件，不必从零搭建。

在运行调度层面，Embodied.cpp采用模块化多速率执行机制，让不同的模块可以按照各自需要的频率运行，互不干扰。感知编码器可以每隔若干帧才刷新一次特征缓存，预测分支只在需要世界预测时才激活，动作头则以更高的控制频率持续产出指令。这种设计直接对应了机器人AI的“多速度同步”难题。

五、实战验证：两款VLA模型的实际部署数据

研究团队在两款代表性的VLA模型上对Embodied.cpp进行了完整的闭环评测。

第一款是HY-VLA，它的骨干网络是腾讯混元VL大模型，同时处理来自三个不同角度摄像头的视频流，并利用视频历史和记忆视觉路径来增强场景理解，每次产生20个动作的动作块。研究团队在RoboTwin仿真平台的“place_empty_cup”任务（把一个空杯子放到指定位置）上进行测试，结果是100%的任务成功率，置信区间为83.9%到100%。这款模型的服务端推理延迟为1340.3毫秒，每个环境步骤的摊销延迟为735.9毫秒，峰值显存占用6850 MiB。延迟偏高是由于骨干网络较大、三路视觉输入以及视频历史路径的综合影响。

第二款是pi0.5，出自Physical Intelligence，骨干网络是PaliGemma，动作块长度为50步。研究团队对它进行了对应的C++部署配置测试，成功率为91%，置信区间为86%到94%。由于PaliGemma骨干网络更轻量、动作块更长（分摊了单步推理成本），pi0.5的每步延迟低至56.85毫秒，推理延迟266.6毫秒，峰值显存6546 MiB，在实际机器人控制中具有更好的实时性。

两款模型的对比充分说明了一个道理：同样通过Embodied.cpp运行，不同架构的模型在延迟和内存上的差异是由骨干网络规模、视觉输入复杂度和动作块长度决定的，而不是由推理框架本身造成的。这正是一个好的统一运行时应有的特性——它不引入额外开销，只暴露模型本身的特性。

六、初步WAM评测：内存从312 MiB降到88 MiB，精度几乎零损失

由于WAM模型（以LingBot-VA为代表）的完整闭环版本在受限的本地边缘设备上尚未完全稳定，研究团队采取了一个务实的做法：只对LingBot-VA的第一个Transformer块进行微基准测试，评估Embodied.cpp在WAM侧的能力。

LingBot-VA的骨干网络基于万象（Wan）视频生成模型的WanTransformerBlock，计算量相当可观。研究团队用Python原始实现（BF16精度，即16位脑浮点数格式）作为基准，与Embodied.cpp中对应的GGUF Q4_K量化版本（4位整数量化）进行对比。

量化是一种常见的模型压缩技术，可以把模型参数从高精度数值压缩成低精度整数，大幅减少内存占用，代价是可能带来一定的精度损失。研究团队用100个随机输入样本，测量了两个版本的输出差异，使用“平均绝对误差”（MAE，数值越小越好）和“余弦相似度”（越接近1越好）两个指标衡量精度损失。

结果相当亮眼：每个Transformer块的内存占用从312.2 MiB大幅降低到88.1 MiB，缩减到原来的约28%；同时延迟从3.236毫秒降到3.171毫秒，略有改善；MAE保持在3.3×10⁻²以内，余弦相似度保持在9.997×10⁻¹以上，几乎与原始版本一致。换句话说，内存省了超过70%，但模型的输出几乎没有变化——就像用压缩格式保存一张照片，文件小了很多，但肉眼看起来和原图没有区别。

这一结果表明，Embodied.cpp对WAM侧Transformer组件的量化支持是有效且精确的，为后续完整闭环WAM部署奠定了基础。

七、与现有系统的正面比较：Embodied.cpp填补了哪些空白

研究团队对现有主流推理运行时做了一次系统性的横向对比，维度包括：是否原生支持VLA模型、是否原生支持WAM模型、是否支持模块化多组件推理优化、是否能在边缘设备上运行、是否支持异构硬件联合使用、是否能直接连接真实机器人、是否能直接连接仿真器。

llama.cpp在边缘设备运行上表现出色，但不原生支持VLA或WAM，没有机器人接口，也没有仿真器接口。ONNX Runtime支持边缘部署和异构硬件，但对VLA/WAM的支持需要大量自定义集成。SGLang专注于大规模云端LLM服务，既不支持边缘部署，也没有机器人接口。vLLM-Omni对VLA和WAM有部分支持，但缺乏边缘能力和机器人接口。vla.cpp是目前最接近的相关工作，它把七种VLA架构统一到了一个可移植的C++运行时中，并且支持机器人连接，但它仍然仅限于VLA模型，不支持WAM，对模块化多组件推理的支持也有限，仿真器连接是部分支持状态。Embodied.cpp在上述所有维度上均实现了原生支持，是第一个同时覆盖VLA和WAM两个家族、支持模块化执行、能在边缘异构硬件上运行、并直接对接机器人和仿真器的统一推理运行时。

说到底，Embodied.cpp做的事情并不神秘，但它填补的是一个真实存在、且越来越重要的空缺。机器人AI模型的研究正在高速前进，模型架构越来越多样，部署平台越来越碎片化，如果每个新模型都要重新搭一套部署工具，工程师的精力会大量消耗在重复劳动上，而不是真正有价值的模型创新。就像USB标准的出现让各种外设终于能插到同一台电脑上一样，Embodied.cpp试图成为机器人AI部署领域的那个“通用插口”。

当然，这项工作目前仍处于早期阶段，论文本身也坦率地承认WAM的完整闭环评测尚未完成，受限于本地边缘设备的稳定性。但已经呈现的结果——两款VLA模型的100%和91%成功率，以及WAM单块内存缩减72%且精度几乎无损——已经为这个方向提供了扎实的初步支撑。随着越来越多的机器人AI模型从实验室走向真实世界，这类可移植、可扩展、延迟优先的统一推理运行时的价值只会越来越凸显。

Q&A

Q1：Embodied.cpp和llama.cpp有什么区别？

A：llama.cpp主要面向文字生成类的大语言模型，优化目标是在本地设备上高效完成“问答”式的请求-响应推理。Embodied.cpp则专门为机器人AI设计，支持持续闭环控制、多模块多速率协同运行，并直接对接摄像头、力传感器等机器人硬件和Isaac Sim等仿真器，是两个定位完全不同的运行框架。

Q2：VLA模型和WAM模型部署到机器人上最难的点是什么？

A：最核心的难点有三个：一是感知、推理、动作各模块运行频率不同，必须异步协调而非强制同步；二是机器人控制对延迟极敏感，但边缘设备算力有限，需要专门优化batch-1小批量推理；三是机器人的输入输出种类繁多（图像、关节角度、力传感器等），现有框架固定的“文字进文字出”接口根本无法覆盖。

Q3：LingBot-VA量化后内存下降那么多，实际用起来精度会受影响吗？

A：根据Embodied.cpp的测试，使用Q4_K量化将单个Transformer块的内存从312.2 MiB降至88.1 MiB，同时用100个随机样本验证，输出的平均绝对误差低于0.033，余弦相似度高于0.9997，与原版BF16精度几乎一致，实际使用中的精度损失非常有限。