由东南大学、东南大学等打懂世南京大学、造让正微软研究院及清华大学人工智能产业研究院联合开展的机器界动前沿研究，已于2026年7月2日以arXiv预印本形式发布（论文编号：arXiv:2607.02501）。起的擎该研究旨在解决机器人AI部署中的统推碎片化难题，有兴趣深入了解的理引读者可通过上述编号查询完整论文。

想象一下，东南大学等打懂世如果家里的造让正机器人助手需要“看”环境、“听”指令并执行动作，机器界动但目前市面上的起的擎AI模型就像不同品牌的电器，插头规格各异，统推导致部署极其繁琐。理引这篇论文提出的东南大学等打懂世解决方案是打造一个名为 Embodied.cpp的“万能插座”——一个统一的推理运行时（Unified Inference Runtime），旨在让各类机器人AI模型能够无缝接入并高效运行。造让正

一、机器界动 机器人AI生态的“插头乱象”：为何软件部署如此艰难？

机器人AI的运行并非单一整体，而是由多个模块协同工作的复杂系统，其现状类似于餐厅后厨：炒锅、蒸锅、烤箱各司其职，节奏各异。目前主流的机器人AI模型主要分为两大阵营：

1. 视觉-语言-动作模型（VLA）：如经验丰富的厨师，直接根据视觉信息和语言指令生成动作。
2. 世界-动作模型（WAM）：如擅长推演的大厨，先预测未来状态，再据此制定动作策略。

尽管模型能力日益增强，但其部署面临巨大障碍：
* 代码栈割裂：两类模型均依赖专属的Python代码栈，工程师需为不同硬件和传感器手写适配代码，重复劳动繁重。
* 推理范式错位：现有通用框架（如llama.cpp、ONNX Runtime等）专为“一问一答”式交互设计，而机器人需要的是类似骑自行车的“持续闭环控制”，现有框架无法直接适用。

二、 机器人AI部署的三大核心挑战

研究团队将机器人AI部署的难点归纳为以下三个维度：

1. 多速度同步运行（Multi-rate Synchronization）
   感知模块（如摄像头）与动作执行模块（如机械臂）的频率差异巨大。强制同步会导致资源浪费或控制滞后，需实现类似乐队中不同乐器节奏的异步协调。

2. 低延迟优先的闭环控制（Low-Latency Closed-Loop Control）
   机器人对延迟极度敏感，且常运行于算力受限的边缘设备（如Jetson、RK芯片）。在有限算力下实现低抖动、实时的推理，是极具挑战性的工程难题。

3. 可扩展的专用接口（Scalable Interfaces）
   机器人输入输出远超简单的文本交互，涵盖RGB图像、深度图、本体感觉、力/触觉数据及动作序列等。固定格式的接口无法承载这种多样性。

三、 模型架构全景解析：VLA与WAM的内部逻辑

在构建框架前，团队对现有模型进行了系统梳理：

VLA模型家族

• 自回归标记VLA（如RT-2, OpenVLA）：统一骨干网络，逐字生成动作标记，结构简单但灵活性低。
• VLM骨干VLA（如Octo, pi0, MuseVLA）：保留强大视觉-语言骨干，配备专用连续动作生成头，输出更平滑。
• 层级VLA（如Hi Robot, Gemini Robotics 1.5）：分层设计，上层负责战略规划，下层负责精细执行。
• 异步VLA（如GR00T N1, DAM-VLA）：区分“慢思考”与“快反应”，通过缓冲区协调，解决多速率同步问题。

WAM模型家族

• 预测后动作WAM（如UniPi）：世界模型预测未来，动作专家据此决策，阶段独立。
• 统一自回归建模WAM（如WorldVLA, LingBot-VA）：将世界预测与动作生成压缩至同一空间，结构紧凑。
• 共享骨干WAM（如DreamZero, Cosmos Policy）：共用骨干网络，但暴露独立调度功能块。
• 潜空间WAM（如LaWAM, Being-H0.7）：压缩未来预测为潜在向量，降低计算开销。

关键洞察：模块化、显式中间状态管理以及时序编排已成为现代机器人AI的核心特征，运行框架必须支持有状态的多组件编排。

四、 Embodied.cpp设计蓝图：打造“万能厨房”

Embodied.cpp采用五层架构，旨在提供高效、通用的机器人AI运行环境：

1. 接口层（Input/Output Adapters）
2. 输入：统一规范化各类数据（视频流、传感器数据、标准数据集样本），清洗并分类。

3. 输出：支持ROS、Apollo Cyber RT、Isaac Sim、Gazebo等主流生态，将动作指令转化为机器人可执行格式。

4. 序列构建器（Sequence Builder）
   将多模态输入拼装为模型可处理的序列，如同备菜摆盘。

5. 骨干执行引擎（Backbone Execution）
   核心计算层，运行大型视觉-语言模型（如PaliGemma, Hunyuan-VL）。支持图计算重放、缓冲区复用及算子融合，针对CPU/GPU/NPU优化Batch-1小批量推理，确保低延迟。

6. 头部插件（Head Plugins）
   可插拔模块，支持连续动作流、扩散模型动作块、世界状态预测等多种输出类型，无需改动底层结构。

7. 算子仓库（Operator Repository）
   收录专用算子与内核，新模型可直接调用，避免重复造轮子。

调度机制：采用模块化多速率执行，感知、预测、动作模块按各自频率独立运行，互不阻塞。

五、 实战验证：VLA模型部署数据

团队在两款代表性VLA模型上进行了闭环评测：

结论：延迟和内存差异主要源于模型架构本身，而非框架开销。Embodied.cpp成功实现了无额外负担的统一运行。

六、 初步WAM评测：极致压缩与精度保持

针对WAM模型（以LingBot-VA为例），团队进行了微基准测试，对比Python原始实现（BF16）与Embodied.cpp量化版本（GGUF Q4_K）：

• 内存优化：单个Transformer块内存从 312.2 MiB降至 88.1 MiB（缩减约72%）。
• 延迟表现：从 3.236 ms 微降至 3.171 ms。
• 精度损失：平均绝对误差（MAE）< 3.3×10⁻³，余弦相似度 > 9.997×10⁻¹，几乎无损。

这表明Embodied.cpp对WAM组件的量化支持高效且精确，为边缘设备部署复杂WAM模型奠定了基础。

七、 行业对比：填补统一推理运行时空白

与现有主流框架相比，Embodied.cpp的优势如下：

• llama.cpp：擅长边缘LLM，但无VLA/WAM原生支持，无机器人接口。
• ONNX Runtime：支持边缘部署，但VLA/WAM集成需大量定制开发。
• SGLang/vLLM：专注云端大规模服务，缺乏边缘能力和机器人接口。
• vla.cpp：支持VLA统一运行及机器人连接，但不支持WAM，模块化支持有限。

Embodied.cpp是首个同时原生支持VLA和WAM、支持模块化多速率执行、适配边缘异构硬件，并直接对接真实机器人和仿真器的统一推理运行时。

结语

Embodied.cpp 如同机器人AI领域的“USB标准”，解决了模型架构多样化与部署平台碎片化之间的矛盾。尽管WAM完整闭环评测仍在进行中，但现有成果已证明其在VLA部署的高成功率及WAM量化的高效性。随着机器人走向真实世界，此类统一、可扩展、低延迟的推理运行时将发挥关键作用。

• GitHub仓库：搜索 SEU-PAISys/Embodied.cpp
• 论文链接：arXiv:2607.02501

Q&A

Q1：Embodied.cpp和llama.cpp有什么区别？
A：llama.cpp主要优化本地大语言模型的“问答”式推理；Embodied.cpp专为机器人AI设计，支持持续闭环控制、多模块异步协同，并直接对接传感器硬件及仿真器（如Isaac Sim），两者定位截然不同。

Q2：VLA和WAM模型部署到机器人上最难的点是什么？
A：三大难点：1. 感知、推理、动作模块频率不同，需异步协调；2. 边缘设备算力有限，需优化低延迟Batch-1推理；3. 输入输出类型复杂（图像、力觉等），现有“文本进文本出”接口无法覆盖。

Q3：LingBot-VA量化后内存大幅下降，精度会受影响吗？
A：测试显示，Q4_K量化将内存从312.2 MiB降至88.1 MiB，同时平均绝对误差低于0.033，余弦相似度高于0.9997，与原版BF16精度几乎一致，实际应用中精度损失极小。