VLA 动作预测在具身智能里已经是高频词但很多项目把 VLA 与 LLM 直接画等号。TurboVLA 用 0.2B 参数在 RTX 4090 上跑到 32Hz 在线动作预测正好把这个误区摆到台面上动作预测不等于必须经过几十B甚至上百B的 LLM。文章围绕一张图、一段指令、一个动作头的链路拆解 VLA 为什么默认绑定了 LLM、轻量模型如何绕开它、以及在一台 RTX 4090 上把推理频率做到 32Hz 的工程路径。这里先给结论动作预测的本质是从“视觉观测 语言指令”到“控制动作”的条件映射。LLM 是这类映射的一种实现方式不是唯一实现方式。TurboVLA 走的是一条更接近传统机器人策略的路线用小参数模型压缩视觉和语言特征直接产出动作。它的参数规模只有 0.2B单看部署体积和推理延迟明显更适合在线闭环控制。1. 先搞清楚 VLA 动作预测为什么常用 LLM1.1 VLA 的任务链路VLA 全称 Vision-Language-Action视觉-语言-动作模型。输入通常是相机图像或者视频片段再加上一条自然语言指令例如“把左侧的红色方块放到托盘里”。输出是一段动作序列可能是机械臂末端位姿、关节角度、速度指令也可能是机器人底盘线速度与角速度。动作预测在具身智能里的地位很特殊。它不像图像分类那样只输出一个类别也不像文本生成那样只输出 token 序列。它需要连续、实时、可落地的控制信号。也就是说网络不仅要“知道”应该做什么还要在硬实时限制内给出低延迟的动作。这条链路在传统机器人流程里被拆成感知、规划、控制。感知负责识别物体规划负责生成轨迹控制负责跟踪执行。VLA 想做的事情是把感知和规划压缩成一个端到端网络让图像和指令直接映射到动作。这样做的收益是省去大量手写规则也能利用预训练视觉模型和语言模型的知识。1.2 LLM 在 VLA 中扮演什么角色很多 VLA 会把一个 LLM 作为骨干网络。原因是语言指令具有开放性机器人需要理解“把红色方块放过去”和“把那个红色的东西移到另一边”这种同义表达。LLM 经过大规模语料预训练具备很好的语义对齐能力可以直接把指令变成 token 序列再与视觉 token 一起融合输出文本形式的动作 token 或者数值动作参数。这种设计在 benchmark 上效果很好尤其是需要开放词表、多步推理、复杂语义消解的任务。LLM 的注意力机制可以在长上下文里把图像、历史状态和指令关联起来。因此早期 VLA 论文几乎都会选择 7B、13B 甚至更大的语言模型作为推理主干。从工程视角看这种架构也能复用成熟的 LLM 推理栈。图像编码器输出 vision token文本 tokenizer 输出 text token拼在一起送进 transformer decoder最后接动作头。训练时可以用现成的语言建模监督推理时可以用 vLLM、TensorRT-LLM、llama.cpp 等工具加速。1.3 大 LLM 在在线动作预测里的代价在线动作预测和离线生成有本质区别。离线场景可以接受几百毫秒延迟在线闭环控制必须匹配机器人的控制频率。以常见的 30Hz 控制周期为例每周期只有 33ms。这个时间要覆盖相机曝光、图像传输、预处理、模型推理、后处理、通信下发。留给模型推理的时间通常不到 25ms。7B 模型在 FP16 下权重约 14GB即使能放进 24GB 显存单次 forward 往往也要 40ms 以上。若用 batch size 1 再叠加 Python 调度和预处理很容易超过 100ms。算上 KV cache、视觉编码器和动作头显存压力也很大。更不要说 70B 级别模型单卡基本无法部署需要多卡或分布式延迟会进一步放大。这就是 TurboVLA 这类轻量模型出现的原因不是要替代所有 LLM-based VLA而是解决“在线动作预测需要实时响应”这一工程痛点。当任务空间是有限闭集、指令模板相对固定、环境变化可控时0.2B 参数足以完成从观测到动作的映射。注意如果机器人任务需要开放世界的常识推理比如用户随意说“把地面上最奇怪的东西拿开”轻量模型会非常吃力。轻量 VLA 的适用前提是任务边界清晰指令可以被模板化和蒸馏。1.4 关键判断动作预测需要的是条件映射不是语言生成很多团队设计 VLA 时习惯性先选 LLM是因为“VLA 里的 L 是 Language Model”。但仔细看动作预测的目标大部分场景并不要求模型生成自然语言只要求从指令中抽出约束条件抓哪个物体、放到哪里、避开什么。这些约束可以编码成低维向量不需要以 token 形式一步步生成。所以轻量 VLA 的核心改动是用一个小文本编码器替代 LLM 的生成式解码器。模型只在特征空间对齐视觉和语言不经过“逐个 token 输出”的过程。少掉的这一大段解码计算正是 32Hz 能跑起来的关键。2. TurboVLA 的轻量思路0.2B 参数如何撑起动作预测2.1 从“大模型当大脑”到“小模型当策略头”TurboVLA 的路线可以理解成把 VLA 拆成“眼睛 小脑 动作肌”。视觉编码器负责提取图像特征文本编码器负责提取指令特征融合层负责对齐最后的动作头输出连续动作。整个网络不生成文本 token因此没有自回归解码过程。这是一种典型的非自回归策略模型延迟天然比 LLM 低。这里要说明TurboVLA 没有公开详尽的网络结构文档时下面描述的是复现轻量 VLA 的通用模块。实际模型可能调整了视觉编码器大小、融合层深度、动作头维度但整体思路是一致的把预算集中在特征融合和动作预测上而不是放在语言生成上。0.2B 参数在今天的视觉模型里算很小。一个 ViT-L 大约 300M 参数加上小型文本编码器和一个 transformer 融合层正好接近这个规模。视觉 backbone 可以预训练文本编码器可以用小型 sentence 模型或轻量 BERT动作头通常只有几百万参数。这种组合在推理时不会产生巨大计算量也因此能在 RTX 4090 上跑出高频率。2.2 模块分配视觉、文本、融合与动作头一个可运行的轻量 VLA 推理结构大致如下视觉编码器输入 224x224 或更高分辨率图像输出空间特征图。文本编码器输入指令文本输出一个指令 embedding或者一小段 token 特征。融合模块将视觉特征和文本特征通过 cross-attention 或 concatenation 结合。动作头从融合特征回归动作向量例如 7 维关节角度、6 维位姿、速度等。参数分配通常视觉编码器占大头融合 transformer 占一部分文本编码器和动作头较小。这样做的好处是视觉特征可以复用通用预训练权重不需要像 LLM-based VLA 那样完整跑一遍大语言模型解码器。训练时可以用大 VLA 模型蒸馏出伪标签也可以用真实机器人轨迹数据做行为克隆Behavior Cloning。如果数据量充足直接端到端监督学习就能收敛。由于输出不是 token 而是连续向量训练损失可以选择 L1 平滑损失或 MSE也可以配合动作分桶离散化变成分类问题。2.3 为什么 0.2B 也能有不错的语义理解小模型能完成语义指令理解听起来反直觉。关键在于任务边界。工业分拣、桌面抓取、固定工作区操作这些场景语言指令往往来自固定的命令集例如“抓红色方块”“把杯子放到盘子上”“按下开关”。这类指令没有开放世界的复杂指代一个轻量文本编码器就能提取出“目标物体”“目标位置”这两个必要约束。如果让 0.2B 模型去处理随机口语、长对话、多轮指代它一定不如 7B 模型。但 TurboVLA 的目标是动作预测不是通用对话。它只需要理解当前这一条指令并把指令中的语义约束和视觉特征对齐。把不需要的能力去掉模型自然可以做得小。此外0.2B 模型可以结合工程手段弥补能力不足。比如使用固定的指令模板把“红色方块”解析成属性标记或者用少量提示词嵌入让文本编码器只关注颜色、类别、位置三个槽位。这些手段在真实机器人项目里非常常见并不影响 VLA 的端到端特性。2.4 与 LLM-based VLA 的架构差异对比维度LLM-based VLATurboVLA 这类轻量 VLA语言模块7B 及以上 LLM轻量文本编码器输出形式动作 token 或语言动作连续动作向量是否自回归生成通常是否参数量数 B 到上百 B0.2B 级别单帧推理延迟高通常数十毫秒起步低可压缩到几毫秒到二三十毫秒部署设备需要大显存 GPU单张消费级显卡即可开放语义理解强有限依赖指令模板在线闭环控制困难更容易满足 30Hz 周期这张表不是要证明一个方案优于另一个。两者的取舍在于“能力”和“时延”之间的平衡。TurboVLA 选择了牺牲开放语义换取在线动作预测的实时性。3. 在 RTX 4090 上把推理预算压到 33ms 以内3.1 32Hz 到底意味着多紧张32Hz 对应每帧 31.25ms。在机器人控制里这个频率不仅要跑模型推理还要包含一整套感知到控制的流程。按常见预算拆分相机采集和传输可能需要 3-5ms图像预处理需要 1-3ms模型推理需要 15-25ms后处理和动作平滑需要 1-2ms通信下发需要 1-3ms。这样算下来已经没有多少余量。很多团队在实验室里测模型 forward 时间觉得 30Hz 没什么问题。等接入真实机器人后频率立刻掉到 10Hz原因就是没有把整条流水线纳入计时。TurboVLA 能在 RTX 4090 上跑出 32Hz说明它至少已经从模型、推理框架、调度方式三个层面做了优化而不只是模型参数量小。3.2 环境要求和版本建议要复现或者验证轻量 VLA 的在线动作预测建议准备如下环境项目推荐配置说明GPURTX 4090 或同级别 24GB 显卡显存不是瓶颈性能充裕操作系统Ubuntu 22.04 或 Windows 11生产环境优先 LinuxCUDACUDA 12.1 或更高对接 PyTorch 和 TensorRTPythonPython 3.10 或 3.11兼顾 PyTorch 兼容性PyTorch2.1 及以上支持 CUDA Graph 和编译优化推理框架TensorRT 8.6 以上或 ONNX Runtime GPU需要进一步压延迟时使用相机RGB 工业相机或 USB 相机需要配合 V4L2 / OpenCV这里没有写死版本因为不同 PyTorch 版本对应的 CUDA 版本不同。落地前先确认本机 CUDA 驱动版本再装对应 PyTorch避免后面出现 “CUDA driver too old” 这类基础问题。3.3 模型推理优化为什么小模型还要做 TensorRT0.2B 模型在 PyTorch 的 eager 模式下单次 forward 可能也能跑到 20ms 到 30ms但离稳定的 32Hz 有风险。原因是 PyTorch 默认有大量 kernel 启动开销和 Python 操作特别是 batch size 1 时GPU 利用率并不高。这时真正的瓶颈往往不是浮点运算量而是 kernel launch 和 tensor 拷贝。TensorRT 会把网络编译成优化好的 kernel 图减少层间调度和临时显存分配。对结构化固定的小模型来说收益非常明显有可能把推理时间从 25ms 降到 10ms 以内。CUDA Graph 也能在 PyTorch 里达到类似效果把一系列 kernel 捕获成一张图降低 launch 开销。实际选择时可以先用 PyTorch eager 模式跑通功能再用 torch.compile 或 CUDA Graph 查看收益最后才考虑用 TensorRT 导出。一步到位上 TensorRT 的风险是导出过程遇到不支持算子排错成本高。3.4 在线流水线设计在线动作预测的推理循环不能写成“图像来了才开始算”的同步模式。推荐使用生产者-消费者结构相机线程负责取帧预处理线程负责图像缩放和归一化推理线程负责模型 forward控制线程负责下发动作。多线程之间通过队列或缓存数组传递数据避免图像数据反复拷贝。CPU 和 GPU 之间可以使用 pinned memory 和异步 H2D 拷贝。图像预处理尽量在 GPU 上完成例如使用 Torch 的 resize 或 TensorRT 内置 preprocess 层。Python 的全局解释锁会影响多线程性能必要时用 multiprocessing 或者把推理放到 C 封装里。注意32Hz 是端到端频率不是模型 forward 频率。验证时必须给完整流水线加时间戳统计连续多帧的帧间隔而不是只测一次 model.forward() 的耗时。4. 最小在线推理循环从相机帧到动作指令4.1 一个可运行的工程结构下面的结构用于演示轻量 VLA 在线动作预测的框架不限定为 TurboVLA 官方实现。实际项目可以按自己的模型接口替换。turbovla-demo/ ├── config.yaml ├── model.py ├── inference.py ├── smoother.py ├── utils.py └── weights/ └── turbovla_0_2b.ptconfig.yaml保存模型路径、图像尺寸、指令模板、控制频率等参数。model.py定义网络结构。inference.py是主入口负责启动相机线程和推理循环。smoother.py对动作输出做低通滤波和限幅。weights/存放模型权重实际部署时不要把模型文件提交到代码仓库。这个结构足够小也方便后面加入 C 推理模块或 TensorRT engine。4.2 配置文件与模型加载配置文件的作用是把环境相关的参数从代码中分离出来。调整图像尺寸或控制频率时不需要改动 Python 代码。model: weight_path: weights/turbovla_0_2b.pt image_size: 224 fp16: true use_cuda_graph: true instruction: template: move the {object} to the {placeholder} object: red cube placeholder: tray robot: action_dim: 7 control_freq: 30 action_scale: [1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0] camera: device_id: 0 width: 640 height: 480加载模型时有一个容易忽视的点权重文件里的 key 要和网络结构完全对上。很多 VLA 推理报错来自预训练权重保存了module.前缀而加载时没有做strip_prefix。建议加载后先打印模型参数数量核对是否接近 0.2B再测试一个假输入。import torch from model import TurboVLA model TurboVLA.from_config(config.yaml) state torch.load(weights/turbovla_0_2b.pt, map_locationcpu) if all(k.startswith(module.) for k in state.keys()): state {k[len(module.):]: v for k, v in state.items()} model.load_state_dict(state) model.half().cuda().eval()如果加载后 forward 报 shape 不匹配优先检查输入图像尺寸和指令编码维度这是最常见的两类错误。4.3 推理循环代码在线推理循环的核心是控制帧间隔。下面这段代码用固定频率控制循环并统计端到端延迟。import time import cv2 import torch import numpy as np from smoother import ActionSmoother from utils import preprocess_frame, encode_instruction model TurboVLA.from_config(config.yaml).cuda().eval() model.half() cap cv2.VideoCapture(0) cap.set(cv2.CAP_PROP_FRAME_WIDTH, 640) cap.set(cv2.CAP_PROP_FRAME_HEIGHT, 480) smoother ActionSmoother(alpha0.4) instr_feat encode_instruction(move the red cube to the tray).cuda() period 1.0 / 30.0 next_cycle time.perf_counter() fps_buffer [] with torch.inference_mode(): while True: ret, frame cap.read() if not ret: continue start time.perf_counter() frame_rgb cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) obs preprocess_frame(frame_rgb, size224).cuda() action model.predict(obs, instr_feat) action smoother.filter(action.cpu().numpy()) action np.clip(action, -1.0, 1.0) # 在这里把 action 发送给机器人控制器 dt time.perf_counter() - start fps_buffer.append(dt) if len(fps_buffer) 60: avg_dt np.mean(fps_buffer) print(favg latency: {avg_dt * 1000:.1f} ms, fps: {1.0 / avg_dt:.1f}) fps_buffer.clear() next_cycle period sleep_time next_cycle - time.perf_counter() if sleep_time 0: time.sleep(sleep_time)这段代码有两个要点。一是用torch.inference_mode()替代torch.no_grad()关闭梯度跟踪减少内存开销。二是固定频率循环用next_cycle累加而不是每次用time.sleep(period)从零开始这样能避免误差堆积。4.4 动作平滑与安全过滤低延迟模型容易输出高频抖动尤其是在真实机器人上动作序列含有噪声。一个简单的一阶低通滤波器就能改善大部分问题。class ActionSmoother: def __init__(self, alpha0.4, action_dim7): self.alpha alpha self.smooth np.zeros(action_dim, dtypenp.float32) def filter(self, action): self.smooth self.alpha * action (1.0 - self.alpha) * self.smooth return self.smooth.copy()alpha 越大输出越跟手但越抖动alpha 越小输出越平滑但滞后越明显。推荐开始时设 0.4再根据机器人实际表现调整。除了滤波还应该做 NaN/Inf 检查一旦发现异常就停止下发避免机械臂执行错误指令。4.5 验证是否真的跑到 32Hz验证方法不是看打印出的单次 forward 耗时而是统计连续 5 秒到 10 秒的真实帧间隔。比较好的做法是在相机帧进入循环和动作下发完成时分别记录时间戳计算中位数和 95 分位延迟。如果平均延迟是 28ms但 95 分位到了 60ms说明存在周期性卡顿比如相机的帧缓冲抖动或 CUDA graph 重建。在线控制关注的不只是平均频率更关注最大抖动因为任何一帧超时都会导致控制周期跳变影响机器人稳定性。5. 关键参数与性能调优精度、batch、CUDA Graph 怎么选5.1 FP16、BF16、INT8 的取舍0.2B 模型在 FP32 下就能跑但为了延迟优化通常使用半精度或量化。FP16 和 BF16 都能减半显存提升访存效率但两者数字范围不同。FP16 在小数值场景容易出现精度溢出BF16 保留更大动态范围。如果模型训练时用的是