在 2025 年这个时间节点谈“具身智能”你会发现一个非常明显的趋势大模型不再只存在于云端聊天框里而是开始往“胳膊”“轮子”“机械爪”上迁移。业界把这类尝试统称为 Vision-Language-Action Model也就是视觉-语言-动作模型简称 VLA。而 VLM视觉语言模型则是 VLA 的认知底座。这篇文章会比较系统地讲清楚三条主线VLM 和 VLA 到底有什么区别OpenVLA、Octo、π₀ 这三套架构各自解决什么问题以及如果你打算在自己的机器人项目里跑通一个 VLA 推理应该从哪下手。文中会给出可参考的 Python 推理代码、C 桥接层示例以及树莓派小车部署时的硬件选型建议适合初学者建立框架认知也适合刚转向具身智能开发的工程师快速做技术选型。1. 具身智能与 VLM、VLA 的关系1.1 什么是具身智能“具身智能”可以拆成两个词来理解具身、智能。所谓“具身”指的是智能体有一个物理载体比如机械臂、四足机器人、人形机器人、履带小车。它不再像 ChatGPT 那样只能通过文字与你交互而是能通过传感器感知真实物理世界再通过电机、气缸、舵机等执行器改变世界状态。所谓“智能”在今天的语境下通常指大模型带来的理解、推理、规划能力。比如看到桌上一只红色杯子模型能理解“把红色杯子放到托盘里”这句话的含义并结合图像中的位置信息规划出一条可行的轨迹。所以具身智能研究的核心问题可以概括为一句话如何让智能体借助大模型的感知与推理能力在非结构化环境中完成物理操作任务。这句话里的“非结构化环境”很重要。工业机械臂之所以不叫具身智能是因为它在固定工位上重复执行固定轨迹环境高度结构化。真正难的是桌面乱糟糟、物体位置随机、光照变化、指令措辞不确定机器人仍然能完成任务。1.2 从 VLM 到 VLA从“能看懂”到“能动手”VLM 的全称是 Vision-Language Model视觉语言模型。它接受图像和文本输入输出文本。比如输入一张桌子照片和问题“桌上有几个苹果”VLM 能回答“3 个”。VLA 的全称是 Vision-Language-Action Model视觉语言动作模型。它在 VLM 基础上多了一个动作输出而且这个输出不再是文本而是机器人可以执行的 action。action 可以是末端执行器的位姿增量也可以是关节角度的增量还可以是 6 自由度的速度指令。两者的关系可以这样理解能力维度VLMVLA输入图像 文本图像 文本有些还包括历史状态输出自然语言动作向量 / 动作 token典型任务视觉问答、物体识别、场景描述抓取、放置、推拉、叠放、导航是否直接控制机器人否是训练数据图文对、视觉问答数据遥操作数据、机器人轨迹数据VLM 很多时候被用来做“感知和规划”VLA 则负责把规划结果落到真正可执行的动作上。如果做一个 3 层架构来理解就是感知层VLM / 视觉编码器负责理解场景。规划层大模型或专门的规划模块负责拆解任务。控制层VLA 或传统控制算法负责输出低层动作。1.3 两个典型误区先避开误区一VLA 只是“VLM 加了一个全连接层”。这种说法过于简化。VLA 的关键难点在于动作的表示方式、动作与视觉特征的跨模态对齐、以及高频实时推理带来的工程挑战。它不是简单地在 VLM 后面接一个回归头。误区二有了 VLAPID 控制、MPC、轨迹规划就完全不需要了。VLA 目前主要输出的是高层动作意图或短时步的低层动作实际部署时仍然需要底盘控制器、机械臂逆解、电机伺服环、安全限位等底层控制逻辑。VLA 更像是一套“决策大脑”而不是末端电机的替代品。2. VLM 入门视觉语言模型的工作原理2.1 VLM 的基本组成几乎所有现代 VLM 都包含三个组件视觉编码器、语言模型、模态对齐模块。视觉编码器的作用是把图片切分成若干 patch再转换成视觉 token。常见实现包括 CLIP 的 ViT、SigLIP、DINOv2 等。语言模型一般就是 Transformer decoder负责理解文本指令并生成回答。模态对齐模块负责把视觉 token 映射到语言模型的语义空间。# 一个典型的 VLM 推理流程示意 from transformers import AutoModelForVision2Seq, AutoProcessor processor AutoProcessor.from_pretrained(your_vlm_model_id) model AutoModelForVision2Seq.from_pretrained(your_vlm_model_id) image desk.png prompt 请描述桌面上的物体位置。 inputs processor( textprompt, imagesimage, return_tensorspt ) output_ids model.generate(**inputs, max_new_tokens64) answer processor.batch_decode(output_ids, skip_special_tokensTrue) print(answer)注意不同 VLM 的加载方式差异很大上面的代码只是通用概念示意实际使用时要按你选择的模型仓库去调整 processor 和 model 的调用方式。2.2 VLM 在机器人里的工作流在机器人系统里VLM 通常承担三个职责。第一是场景理解。机器人需要知道面前有什么物体、物体在什么位置、它们的属性是什么。例如“托盘里是一个银色杯子还是蓝色螺丝刀”这类任务直接用 VLM 就能完成。第二是任务拆解。拿到一句高层指令“把桌面清理干净”VLM 可以输出自然语言的子任务序列先拿起杯子放到水槽再把螺丝刀放回工具盒最后把抹布叠好。这一步通常输出的是文本结构化结果比如 JSON 数组。第三是错误检测与状态判断。机器人执行完一个动作后VLM 可以拍一张照片并判断“杯子是否已经放到托盘里”用于闭环验证。一个常见的工作流是用户指令 - VLM 任务拆解 - 子任务列表 - 每个子任务调用 VLA 或控制策略 - 执行后 VLM 验证结果 - 进入下一个子任务这个流程中VLM 负责“认知”VLA 或传统控制策略负责“动作”。2.3 为什么 VLM 不能直接控制机械臂原因是输出空间不匹配。VLM 输出的是文本 token而机械臂控制器需要的是数值向量比如手爪开合状态、末端目标位姿、关节角度增量。如果要让 VLM 直接控制机械臂就需要把数值动作序列转换成文本这会造成严重的信息损失也带来推理延迟问题。再往深处说VLM 的注意力机制是为“语言上下文相关性”设计的它对连续轨迹、力学约束、执行器限制没有先验概念。它能告诉你“应该把杯子拿起来”但它很难告诉你“在这一帧图像下关节 3 需要转动 0.2 弧度”。所以才会需要 VLA让模型从机器人的实际轨迹数据中去学习如何把视觉特征、语言指令映射到动作向量。3. VLA把语言指令变成机器人动作3.1 VLA 的架构思路VLA 的基本架构通常可以分为两层底座模型 动作头。底座模型通常是预训练过的 VLM。优势很明显模型已经具备视觉理解和语言推理能力只需要再学一层“动作知识”。这样可以减少对机器人动作数据量的依赖。动作头则负责把模型最终输出的隐藏状态转换成动作向量。在 OpenVLA 这类开源模型中常见做法是让 VLM 输出离散的动作 token再通过一个离散 token 到连续动作的映射器还原成机器人可以执行的动作。在 π₀ 这类通用机器人大脑中做法会更偏“直接回归”。模型预测连续动作 chunk也就是未来若干步的动作序列一次性输出减少高频推理带来的延迟问题。3.2 动作空间的编码方式机器人动作通常用三种方式表示。第一种是关节空间表示。比如 6 自由度机械臂输出 6 个关节角的增量值。优点是控制精确缺点是不同机器人结构不同迁移难度大。第二种是末端执行器空间表示。输出三维位置增量、三维姿态增量以及手爪开合状态。优点是便于跨机械臂迁移但需要下游机器人具备逆运动学能力。第三种是离散化 token 表示。把连续的动作值离散成若干区间再转成 token。比如 OpenVLA 就使用这种方案模型最终输出的是离散动作 token 序列。在实际部署中动作空间选择决定了 VLA 模型的通用性和工程复杂度。如果你的目标是做单台六轴机械臂研究首选末端执行器表示如果你的目标是让同一套模型适配多种机器人可能需要考虑关节空间与本体标定的配合。3.3 VLA 的训练流程简述VLA 训练一般分两步。第一步是加载预训练 VLM 权重保持大部分参数冻结只对部分层进行微调。第二步是在机器人轨迹数据上训练。轨迹数据由“图像序列 语言指令 动作序列”组成也就是常说的一对一的训练样本。训练时通常把历史图像和动作也作为输入。为什么要历史信息因为单帧图像无法判断物体运动方向也无法处理机械臂手爪遮挡物体的常见情况。多帧输入可以给模型更好的时域感知。下面是一个简化伪代码# 伪代码VLA 训练数据构造 sample { prompt: 把红色杯子放到托盘中央, images: [frame_1, frame_2, frame_3], # 历史多帧 actions: [ {dx: 0.01, dy: 0.02, dz: -0.03, gripper: 1}, {dx: 0.01, dy: 0.02, dz: -0.03, gripper: 1} ] }注意动作序列需要做归一化否则不同量纲的动作分量会让模型训练不稳定。常见做法是按各维度的标准差缩放到适合的数值范围但具体实现要按模型仓库的说明为准。4. 三大具身智能架构解析4.1 OpenVLA开源 VLA 的标杆实现OpenVLA 是目前开源社区里非常有代表性的视觉语言动作模型。它基于一个 7B 参数的视觉语言模型底座通过海量互联网图文数据预训练再使用机器人示教数据微调建立了视觉输入、语言指令与动作输出之间的映射能力。OpenVLA 的一大特点是开放权重。无论你是研究机构还是个人开发者都能拿它在自己的机械臂、仿真环境或小车上做二次训练这大大降低了 VLA 的研究门槛。对于刚入门具身智能的同学OpenVLA 是最容易“跑通一个完整 VLA 链路”的开源选择。OpenVLA 的动作空间设计为离散 token。模型对一个动作向量的每一维都进行离散化将一个连续向量转成一串离散 token。这种做法的好处是训练时和语言模型天然兼容缺点是动作精度受离散化粒度限制实际部署时通常要做后处理平滑。使用 OpenVLA 时要注意它的推理延迟通常较高。公式上7B 模型在消费级显卡上做单帧推理往往需要数秒钟。如果机器人任务要求高频控制就需要在模型推理频率和执行频率之间做折中通常会在上位机规划层面加缓冲。4.2 Octo跨具身预训练策略Octo 是另一条技术路线的代表。它不强调“大规模语言推理”而是专注于“跨具身、跨任务”的机器人预训练策略。Octo 使用 Transformer 架构处理多模态输入包括视觉观测、任务描述、动作历史。它从多个真实机器人数据集和仿真数据集中学习通用的行为模式目标是让新机器人、新任务能够快速适配不需要从零开始训练。Octo 早期版本采用的是一种基于扩散模型的策略输出方式对整个动作序列进行去噪而不是逐 token 回归。这种方式在动作连续性和多峰行为上表现更好。它适合做机械臂操作策略但语言理解能力没有 VLM 底座那样强更多时候配合外部语言模型使用。4.3 π₀通用机器人大脑π₀在不同资料中也会写作 pi-zero是面向通用机器人大脑方向提出的架构它把语言模型训练中的大规模预训练思路迁移到了机器人动作空间中。π₀ 的核心理念是先构建一个通用的“视觉-语言-动作”底座用海量异构机器人数据做大规模预训练再针对具体下游任务做轻量微调。相比早期 VLAπ₀ 更强调泛化性和实时性。动作输出方面π₀ 通常输出连续的 action chunk也就是同时预测未来多步的动作从而减少推理频率提升控制稳定性。这一点在机器人实际控制中非常关键因为单步预测很容易产生抖动而多步预测可以让执行器轨迹更平滑。需要说明的是π₀ 相关的技术迭代较快不同时间公布的细节可能存在差异。这篇文章只讨论通用架构思想具体实现细节要以论文和开源仓库为准。4.4 三者对比维度OpenVLAOctoπ₀底座模型7B 视觉语言模型Transformer 策略模型视觉语言动作底座模型输出方式离散动作 token连续动作 / 扩散模型输出连续 action chunk语言能力强弱依赖外部模型中到强跨本体能力中强强开源程度开放权重开源部分开源 / 论文公开适用场景多模态指令操作多机器人策略预训练通用托底策略、复杂操作选择哪套架构关键看你的实际场景。如果想兼顾语言理解和操作先看 OpenVLA如果有多台不同构型机器人希望复用行为策略建议研究 Octo如果想追踪前沿机器人大脑方向π₀ 的思路必须了解。5. 本地运行 VLA 的完整示例5.1 环境准备在开始跑 VLA 之前先确认你的环境。操作系统方面推荐 Ubuntu 20.04 或 22.04。Python 版本建议 3.10 以上。PyTorch 版本建议使用 CUDA 12.x 对应的稳定版本。模型推理建议至少准备一块 16GB 显存以上的 GPU。如果你只有 CPU7B 模型虽然也能启动但推理速度会非常慢不推荐用于实时控制验证。如果是树莓派小车这类边缘设备情况要单独讨论。树莓派 4GB 版本适合跑基础控制、图像采集和轻量视觉模型如果希望在边缘端跑更接近 VLA 的轻量化模型建议直接上 8GB 版本并且优先考虑挂载 NPU 或 GPU 加速卡。即便如此7B 级别的 VLA 也很难在树莓派上实时运行通常的做法是树莓派负责传感器采集和电机控制大模型推理放在远端服务器。5.2 Python 端调用 OpenVLA 做推理下面给出一段基于 Hugging Facetransformers风格接口的 OpenVLA 推理示例。请重点理解流程而不是照抄每一行代码因为具体 API 会随版本变化。# 文件路径examples/vla_inference.py import torch from PIL import Image from transformers import AutoModelForVision2Seq, AutoProcessor from transformers.image_utils import load_image model_id openvla/openvla-7b processor AutoProcessor.from_pretrained(model_id) model AutoModelForVision2Seq.from_pretrained( model_id, torch_dtypetorch.bfloat16, device_mapauto ) image load_image(example_table.jpg) prompt 把红色杯子推到黑色托盘里。 inputs processor( textprompt, imagesimage, return_tensorspt, paddingTrue, truncationTrue ).to(model.device, dtypetorch.bfloat16) with torch.inference_mode(): output_ids model.generate(**inputs, max_new_tokens128) norm_actions processor.batch_decode(output_ids, skip_special_tokensTrue) print(归一化动作输出, norm_actions)这条代码要说明的核心点在模型输出的是归一化后的动作 token你需要根据你的机器人运动学范围做反归一化才能得到真实物理单位下的动作向量。这一步不同机器人差异很大是工程落地时最常踩坑的地方。实际部署中更推荐的模式是把它封装成一个动作服务# 文件路径examples/action_server.py class VLAActionService: def __init__(self, model_id: str openvla/openvla-7b): self.processor AutoProcessor.from_pretrained(model_id) self.model AutoModelForVision2Seq.from_pretrained( model_id, torch_dtypetorch.bfloat16, device_mapauto ) self.model.eval() def predict(self, prompt: str, image_path: str): image load_image(image_path) inputs self.processor( textprompt, imagesimage, return_tensorspt, paddingTrue, truncationTrue ).to(self.model.device, dtypetorch.bfloat16) with torch.inference_mode(): output_ids self.model.generate(**inputs, max_new_tokens128) return self.processor.batch_decode(output_ids, skip_special_tokensTrue)这样C 控制端可以通过 HTTP、ZMQ 或 ROS 服务来请求这个类拿到动作结果。5.3 C 端桥接层与 Linux 实时调度具身智能系统通常采用“大脑 小脑”架构。大脑负责 VLA 推理小脑负责实时电机控制。连接二者的桥接层要解决的最核心问题是“从模型推理结果到电机指令”的低延迟转发。下面给出一段 Linux 实时调度优先级的设置代码目的是让桥接线程获得较高的调度优先级减少控制指令传输抖动。// 文件路径bridge/scheduler_utils.cpp #include sched.h #include sys/mman.h #include unistd.h #include cstdio #include cerrno #include cstring bool setupRealtimeThread(int priority) { #ifdef _POSIX_PRIORITY_SCHEDULING // 锁定内存避免控制过程发生页缺失导致延迟 if (mlockall(MCL_CURRENT | MCL_FUTURE) ! 0) { perror(mlockall failed); // 非致命错误继续执行 } sched_param param; param.sched_priority priority; int ret sched_setscheduler(0, SCHED_FIFO, param); if (ret ! 0) { fprintf(stderr, sched_setscheduler failed: %s\n, strerror(errno)); return false; } printf(thread set to SCHED_FIFO, priority%d\n, priority); return true; #else printf(real-time scheduling not supported on this platform\n); return false; #endif }使用实时调度前需要注意SCHED_FIFO 是实时调度策略如果优先级设置过高会抢占系统的关键任务可能导致系统响应问题。建议先在测试环境验证并仅在真正需要低延迟控制的桥接线程中使用而不是把所有线程都设置为实时调度。桥接层完整的逻辑可以这样设计// 文件路径bridge/bridge_main.cpp // 流程概念示意非完整可编译工程 #include atomic #include thread #include scheduler_utils.cpp std::atomicbool running{true}; void frameCollector() { // 采集相机帧通过共享内存传给 Python 侧 } void actionReceiver() { // 接收 VLA 服务返回的动作向量 } void motorController() { // 将动作向量拆解为底盘速度 机械臂关节指令 } int main() { setupRealtimeThread(40); std::thread t1(frameCollector); std::thread t2(actionReceiver); std::thread t3(motorController); t1.join(); t2.join(); t3.join(); return 0; }注意scheduler_utils.cpp和bridge_main.cpp在真实工程中建议拆成头文件和源文件这里为了展示方便放在了一起。5.4 树莓派小车部署建议4GB 还是 8GB如果你有一台树莓派小车目标是把 VLA 落地到车上那么选型建议如下。如果只是一辆基础巡线车用树莓派 4GB 就够因为只需要跑 GPIO、电机驱动、图像采集和简单颜色识别。这类任务用不上 VLA传统视觉方案都能完成。如果你想在车端部署轻量 VLM用于物体识别、指令理解、简单路径规划那么建议选择树莓派 8GB 版本。部分蒸馏过的 VLM 可以勉强跑起来但也要经过量化、剪枝等优化。如果你计划让小车与 OpenVLA 或 π₀ 这类 VLA 模型配合最合理的架构是车端只做采集和控制模型推理放到 PC 服务器或者带有独立 GPU 的开发板。树莓派本身只承担“肢体”不承担“大脑”。总之在预算允许的情况下具身智能小车优先选择 8GB 版本。4GB 适合做纯运动控制和小尺寸模型实验8GB 能给你保留更多模型选择和扩展空间。6. 高频问题与排查清单6.1 常见问题表问题现象常见原因解决思路模型加载时报显存不足7B 模型所需显存超过当前 GPU使用 4bit 量化、半精度推理或换更大显存显卡输出动作明显超出机器人运动范围没有做反归一化根据机器人关节角度范围将归一化动作映射回物理量同样是“拿杯子”每次动作差异很大动作 token 离散化粒度太粗或多峰行为增加动作后处理平滑或采用连续动作输出架构推理延迟过高控制跟不上VLA 模型太大、推理频率太低降低推理频率使用 action chunk将高频控制交给小脑sched_setscheduler 返回权限错误未开启实时调度权限或容器环境限制检查 Linux 权限、容器的 privileged 模式、实时线程上限小车采集图像和推理端时间戳对不上没有统一时钟或没有加时间戳在帧数据中附加时间戳并在发送前校准延时模型在仿真里表现好真机表现差sim-to-real 差距增加真机数据微调、动作平滑、光线和位姿随机化6.2 选型建议业务什么时候选 VLM什么时候选 VLA如果你的任务只需要“看”比如物体计数、缺陷检测、场景描述直接用 VLM。如果你的任务需要“看懂并说出下一步做什么”比如“先拿 A再放 B”那么用 VLM 做任务拆解配合传统运动规划器即可。如果你的任务是从语言指令直接生成可执行动作并且希望机器人具备较强的泛化能力比如在未知物体和随机桌面上完成抓取放置那么需要引入 VLA。如果你的生产环境对实时性要求极高比如毫秒级响应那么现阶段 VLA 并不适合直接承担全部控制链路建议把 VLA 放在上层决策底层仍然保留实时控制算法。7. 工程实践与最佳实践建议7.1 数据清洗是高质量策略的前提具身智能大模型的训练效果很大程度上取决于演示数据的质量。很多初学者容易忽略数据清洗这一步直接收集一批遥操作数据就丢给训练脚本最后发现模型学到的是一些奇怪的行为。从具身智能数据清洗角度有几点需要优先关注。第一去除动作抖动严重的数据段。遥操作过程中操作者手抖、数据采集频率不稳定都会导致动作序列出现不连续的跳变这类数据会干扰模型学习平滑策略。第二统一图像分辨率和相机位姿。不同数据采集环境中图像分辨率、视角、曝光差异过大会导致模型学到错误的视觉先验。建议所有数据统一为同一分辨率并记录相机外参。第三维护语言指令的一致性。同一个任务指令不要来回换说法比如“拿起红色杯子”和“把红色杯子拿起来”可能属于同一意图但如果训练数据里两者对应完全不同的动作分布模型会困惑。第四对齐时间戳。图像帧、机械臂状态、动作指令之间必须严格对齐。一个常见坑是图像已经变化了但动作序列还停留在上一毫秒这会让模型学到滞后策略。7.2 大小脑桥接与实时性设计在具身智能的实际部署中我比较推荐把系统划分为大脑、小脑两个层面中间通过桥接层通信。大脑负责 VLA 推理输出低频动作目标频率通常在 1 到 10 Hz。小脑负责电机控制、逆解、避障、限位保护频率通常在 100 Hz 以上。桥接层则负责两者之间的协议转换。你在做桥接层时需要注意三点通信协议尽量轻量化例如使用 flatbuffers 而不是重复解析 JSON消息必须带时间戳方便两端对齐小脑侧必须做动作目标插值让电机运行轨迹平滑。在 Linux 实时环境里控制线程的调度策略和优先级设置非常关键。上面给出的sched_setscheduler示例只是基础实际工程还要关注 CPU 亲和性、中断绑核、内核PREEMPT_RT补丁等因素。但建议从简单开始先确保控制线程稳定运行再逐步优化实时性。7.3 安全与可回退机制任何涉及真实电机的具身智能项目都要设计安全边界。VLA 模型并不具备安全常识它可能因为视觉遮挡、异常光照或语言歧义而输出不安全动作。因此机械臂执行前必须增加位置限位、速度限位和力矩保护。如果模型输出的目标位置接近机械臂极限小脑应当拒绝执行而不是盲目跟随。同时系统要支持一键急停和策略回退。急停功能必须在最底层电机驱动实现不依赖大脑或小脑的决策线程。策略回退则是一旦 VLA 推理结果连续多帧异常系统自动切换到预设的安全姿态或人工接管模式。在真实生产环境里还要考虑模型服务的故障恢复。VLA 推理服务崩溃后机器人应该保持当前状态等待重启而不是直接失控。8. 学习路线与下一步如果你是从零开始学具身智能可以按下面这条路线逐步推进。第一步先把 VLM 跑通。选择一个轻量视觉语言模型在本地环境做一次图像问答理解多模态模型的输入输出结构。关键要理解视觉 token、语言 token 是怎么对齐的。第二步学习机器人数据格式。用真实机械臂或仿真环境采集一段遥操作数据理解图像、指令、动作三个模态的对应关系。这个阶段可以借助 URDF、ROS、gym 等工具。第三步选择一个开源 VLA 跑通推理。建议先下载 OpenVLA 的预训练权重用自己的图片和语言指令做一次动作推理对比不同输入下输出动作是否合理。第四步把 VLA 接入仿真环境。在 Isaac Sim 或 MuJoCo 里验证模型输出的动作是否能完成抓取发现端到端的链路问题。第五步在真实小车或机械臂上部署。先不做复杂模型而是用桥接层把图像采集、模型推理、电机控制串起来跑通一个简单的“走到红球前并停止”任务。第六步再思考如何提升泛化能力。包括采集更多多样化数据、做领域随机化、使用 action chunk 预测、引入跨本体预训练、尝试多模型融合等方向。随后可以去关注具身智能领域的数据引擎、仿真到真机的迁移、VLA 的轻量化部署、以及小脑层专用模型等细分方向。具身智能是一个系统工程早一天把第一套 demo 跑通就能更早理解真正的问题所在。如果这篇文章对你有帮助建议先收藏然后挑一个开源模型跑一次推理。动手实践比看十篇文章都有效。遇到具体报错时把你用的模型版本、显卡型号、显存大小和完整报错贴出来基本都能在开源社区找到答案。