做机器人开发的朋友最近大概率都被 VLAVision-Language-Action Model视觉-语言-动作模型刷屏了。但很多团队聊了一圈之后反而更焦虑主流方案动辄 7B、13B 参数起步底层还挂着一个 LLM想跑起来就要多卡集群。折腾两周模型终于能出动作了一回放速度发现只有 5Hz连一个基础的速度闭环都稳不住。于是不少人得出一个结论VLA 是富哥的玩具小团队碰不得。这个判断有一半是对的但另一半需要重新审视。VLA 动作预测必须经过 LLM 吗答案是否定的。VLA 是一种学习范式而不是某个模型的专属称号。LLM 只是构建 VLA 的一种底座选择不是必经之路。TurboVLA 的出现恰好把这个事实摆在了台面上0.2B 参数单张 RTX 4090 能跑出 32Hz 在线动作预测。这篇博客我想认真拆一下这件事它背后涉及 VLA 的架构判断、动作预测到底需要什么、以及一个普通开发者怎么基于轻量 VLA 搭一套可验证的本地推理环境。1. 先搞清楚 VLA 到底在解决什么问题很多人第一次接触 VLA 时习惯把它理解成“能看图的 LLM 机器人版”。这个类比有帮助但也容易误导。传统机器人控制链路是感知、规划、控制三段式视觉模块负责识别物体路径规划模块负责算轨迹控制模块负责把轨迹转成关节指令。每段独立开发、独立调试接口要人工对齐数据在模块之间流转时还会丢信息。尤其是遇到开放场景比如桌面上的物体位置变了、光照变了、指令换了一种说法传统模块化系统很容易碎掉。VLA 做的事情是把“看”“想”“动”压缩进一个端到端的映射输入是图像可能还有语言指令输出是动作序列。它不区分感知模块和规划模块而是直接从大量“图像-指令-动作”数据里学出那个映射函数。这意味着 VLA 的核心价值不是会说漂亮话而是能把视觉观察和动作输出之间的依赖关系学出来。这个依赖关系在数学上就是一个高频函数每一帧图像进来模型要尽快给出当前这一步的动作。那么问题就来了为了让这个函数变成可用的机器人策略我们真的需要一个几十亿参数、基于自回归文本生成的大语言模型吗2. “必须经过 LLM”这个印象是怎么形成的先承认一个事实目前很多头部 VLA 工作确实是以 LLM 为底座的。比如把视觉 token 和文本指令 token 一起喂给一个预训练语言模型然后在模型输出端接一个动作头把动作表示成 discrete token 或者连续向量。这类方案的好处很明显LLM 带来了强大的常识推理、指令泛化和多模态对齐能力模型对指令的理解更“聪明”。但这里有一个容易忽略的细节架构选择是因为好用不是因为必需。VLA 的数学定义是“图像、语言到动作的映射”它没有规定中间必须发生一次自回归文本生成。LLM 在 VLA 中更准确的角色是“高层的任务理解和规划器”而不是“每一帧动作必须经过的隧道”。在真实机器人系统里这两件事的频率要求完全不同层级典型频率承担任务适合的模型任务规划层0.1 - 1 Hz理解指令、拆解子目标、处理异常LLM、VLM动作执行层10 - 100 Hz根据当前观测输出关节速度/位置增量轻量策略模型、VLA 轻量版底层控制层100 - 1000 Hz伺服控制、电流环、力矩环PID、MPC、状态机如果把动作执行层也塞进一个 7B 的 LLM 里每次推理几秒钟机器人基本就是“想一下动一下再想一下”。这不是控制这是抽帧动画。所以更合理的设计是分层LLM 负责低频的任务拆解和语义理解轻量 VLA 负责高频的感知-动作映射。TurboVLA 的定位正是后者。3. TurboVLA 的 0.2B 参数到底意味着什么0.2B 参数是什么概念对比一下就清楚了。常见的多模态大模型动辄 7B、13B甚至 70B一个 7B 模型用 FP16 存储光权重就要占 14GB 显存推理时还要算 KV cache、中间激活值一张 24GB 的 RTX 4090 勉强能跑但稍微加长输入序列或者加大 batch立刻逼近显存上限。而 0.2B 模型FP16 权重只有 400MB 左右即便加上中间激活也能非常从容地放进一张消费级显卡。这直接改变了部署方式不需要多卡不需要 A100不需要分布式推理框架。参数变少推理延迟自然也会下降。对一个只有 2 亿参数左右的动作预测模型来说单帧前向推理只需要几毫秒到十几毫秒量级这取决于视觉编码器的尺寸和输入分辨率。这也是 32Hz 在线动作预测能成立的前提。但我要强调一下0.2B 参数不是万能的。它在常识推理、复杂任务分解这些高维语言能力上肯定比不过 7B、13B 的大模型。它的优势区间是动作预测本身输入清晰、输出维度确定、任务边界相对收敛。换句话讲TurboVLA 走的是“好钢用在刀刃上”的路线把计算资源全部留给感知-动作映射而不是花在开放世界的语言生成上。4. RTX 4090 上跑 32Hz 在线动作预测这个数字怎么理解先解释一下“在线动作预测”。它指的是模型在真实运行过程中每采集到一帧图像就立即输出一个动作而不是读取一整段视频后离线批量预测。在线推理对延迟极其敏感因为机器人的执行是实时的晚一秒或者掉一帧控制效果就会劣化。32Hz换算一下就是每帧动作预测的平均时间约 31ms。这个数字放在机器人控制里是什么水平很多轻量机械臂的关节速度环在 100Hz 到 1000Hz但那是底层伺服控制的频率。在策略层面一个视觉引导的抓取动作10Hz 以上基本就能让整个控制环路稳定工作30Hz 左右已经能实现比较连贯的在线跟踪。所以 32Hz 不是“勉强能跑”而是“有一定控制余量”。还有一点值得注意RTX 4090 只是一张桌面级显卡。对于实验室验证和算法研发来说这意味着你不需要申请服务器资源用自己的开发机就能完成 VLA 策略的部署和测试。这是把 VLA 从“大厂论文”往“普通开发者实践”推进了一步。当然也需要冷静看待。RTX 4090 功耗较高也不是机器人本体上能长期携带的硬件。从 4090 到边缘设备仍然有量化、蒸馏、算子裁剪等一堆工程问题要处理。但至少第一步的验证门槛已经被降到很低了。5. 轻量 VLA 的本地环境准备如果你也想验证一下“不经过 LLM 的动作预测模型”可以按下面这套思路搭一个最小环境。TurboVLA 的具体仓库地址和模型权重建议以官方文档为准这里重点讲通用的准备工作以及每一步为什么需要。5.1 硬件与驱动确认建议环境是NVIDIA 显卡显存至少 8GB这是轻量模型的底线0.2B 模型更宽松驱动版本要支持 CUDA 12.x。可以先跑一条命令确认nvidia-smi重点看两个信息驱动版本是否较新以及显存大小是否足够。如果nvidia-smi都跑不起来先解决驱动问题。然后确认 PyTorch 的 CUDA 是否可用import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))如果输出False说明 PyTorch 的 CUDA 版本和驱动不匹配需要重装对应 CUDA 版本的 PyTorch。5.2 创建独立 Python 环境实操经验不要直接往系统 Python 里装深度学习依赖很容易污染其他项目。建议用 conda 或 venv 建独立环境conda create -n vla_test python3.10 -y conda activate vla_test pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121 pip install transformers4.40 pillow numpy fastapi uvicorn这里transformers不是必需的取决于模型仓库是否基于 Hugging Face 格式。如果模型自己带推理脚本可以不装。fastapi和uvicorn是为了后面的 HTTP 部署验证。5.3 准备测试图片和指令在线动作预测需要一个图片输入和一条指令。建议从现实世界随手拍一张桌子、一个物体的照片或者从机器人数据集里导出一帧观测图。关键是图片要能代表真实部署场景不要用纯色图否则模型输出的动作没有参考意义。我习惯把测试素材固定在一个目录里方便反复验证mkdir -p test_data # 将测试图片命名为 obs.jpg放在 test_data 目录下6. 最小推理示例加载轻量 VLA 模型并输出动作下面这段代码是一个“通用结构示意”。如果你使用的模型仓库提供了官方推理接口优先用官方接口如果没有可以参考这套逻辑理解 VLA 推理的大致流程。# demo_predict.py # 演示用代码具体模型加载方式以对应仓库 README 为准 import torch from PIL import Image # 假设模型仓库提供了一个统一的预测器入口 from vla_sdk import create_vla_predictor # 加载模型bfloat16 可以降低显存占用 predictor create_vla_predictor( model_pathTurboVLA-0.2B, devicecuda, dtypetorch.bfloat16, ) # 读取观测图像 image Image.open(test_data/obs.jpg).convert(RGB) # 自然语言指令 instruction move forward 0.3 meters # 推理输入图像 指令输出动作向量 action predictor.predict(image, instruction) # 通常动作向量可能是六维末端位姿增量 # 也可能是关节位置增量具体维度看模型设计 print(action dimension:, len(action)) print(action value:, action.tolist())这个流程有几个关键点第一图像必须转为 RGB 且保持模型训练时的输入分辨率。很多模型内部会做 resize 和归一化但外部传入的通道顺序错误会导致效果严重劣化。第二指令不要写得太长、太复杂。轻量模型的指令理解能力有限最稳妥的做法是使用和训练集一致的简短祈使句比如“pick up the red cup”比“请帮我把那个红色的杯子从桌面上拿起来然后放到旁边的托盘里”要可靠得多。第三输出的动作向量含义取决于模型训练时的定义。有的模型输出末端位姿增量有的输出关节速度有的输出动作 token。使用前一定要阅读仓库说明否则拿到一串数字也不知道怎么发送给机器人。7. 性能测试验证推理延迟和频率跑通推理只是第一步。标题里提到的 32Hz要验证起来也很直接多次推理取平均延迟然后换算成频率。下面这段脚本可以复用。# benchmark_latency.py import time import numpy as np import torch from PIL import Image from vla_sdk import create_vla_predictor predictor create_vla_predictor( model_pathTurboVLA-0.2B, devicecuda, dtypetorch.bfloat16, ) # 用固定输入做基准测试 image Image.fromarray(np.random.randint(0, 255, (480, 640, 3), dtypenp.uint8)) instruction pick up the red cup # 预热CUDA 第一次推理会包含 kernel 编译结果不准确 for _ in range(10): predictor.predict(image, instruction) # 正式计时 runs 100 torch.cuda.synchronize() start time.perf_counter() for _ in range(runs): predictor.predict(image, instruction) torch.cuda.synchronize() avg_ms (time.perf_counter() - start) / runs * 1000 print(favg latency {avg_ms:.1f} ms) print(ffps {1000.0 / avg_ms:.1f} Hz)判断标准很简单如果平均延迟在 30ms 左右那就是 30Hz 量级。如果差得很远先检查是否误用了 FP32 推理或者是否在 CPU 上运行。另外第一次推理一定比后续慢这是正常的预热几次再测更公平。这里再提醒一个容易被忽略的点模型推理延迟和控制环端到端延迟是两回事。端到端延迟还包括相机采集时间、图像预处理时间、网络传输时间、动作下发时间。所以即使模型本身只有 30ms整个控制回路也可能有 50 到 100ms 的延迟。做真机部署时要对这个增量有心理预期。8. 把 VLA 动作预测部署成 HTTP 服务在实验室环境里直接调 Python 接口没问题。但真机部署时模型推理往往跑在一个独立进程里控制程序跑在另一个进程里两者需要通信。最常见的方式是提供一个 HTTP 服务。# server.py import io from fastapi import FastAPI, File, Form, UploadFile from PIL import Image from vla_sdk import create_vla_predictor app FastAPI() predictor create_vla_predictor( model_pathTurboVLA-0.2B, devicecuda, dtypetorch.bfloat16, ) app.post(/predict) async def predict( image: UploadFile File(...), instruction: str Form(...), ): # 读入图像 img_bytes await image.read() pil_image Image.open(io.BytesIO(img_bytes)).convert(RGB) # 推理 action predictor.predict(pil_image, instruction) return {action: action.tolist()}启动服务uvicorn server:app --host 0.0.0.0 --port 8000用 curl 验证curl -X POST http://127.0.0.1:8000/predict \ -F imagetest_data/obs.jpg \ -F instructionmove forward 0.3 meters预期会看到一个 JSON 返回里面是动作向量{ action: [0.05, 0.0, 0.3, 0.0, 0.0, 0.0] }这个服务的最大价值是把模型推理与控制程序解耦。控制程序只管发图片、收动作不管模型是怎么加载的。后面想换模型、加量化、加缓存都不需要改动控制侧代码。不过要注意HTTP 的序列化和传输本身有开销。如果控制频率要求很高不建议走 HTTP可以改用 gRPC 或者共享内存。HTTP 更适合开发验证和低频任务级调用。9. 常见问题与排查思路9.1 推理速度远低于标称的 32Hz问题现象可能原因排查方式解决方案推理帧率只有 5-10Hz模型跑在 CPU 上查看torch.cuda.is_available()和设备名称确保模型加载到 CUDA 设备推理帧率只有 5-10Hz使用了 FP32 或未开推理模式检查推理代码是否有model.eval()改用 bfloat16/float16并开启torch.inference_mode()推理帧率波动大输入图片分辨率过大预处理耗时查看是否在循环里做了 resize预处理与推理并行或提前缓存前几次推理很慢CUDA kernel 编译观察预热后的延迟先跑 10-20 次预热再计时9.2 模型输出动作不稳定或明显错误问题现象可能原因排查方式解决方案动作向量剧烈跳动图像输入与训练分布不一致检查图片尺寸、颜色通道、拍摄角度统一输入预处理流程相同的输入得到不同结果模型处于训练模式或采样策略随机检查是否调用了model.eval()推理时固定随机种子对长指令理解差轻量模型的指令能力有限尝试不同类型指令使用简短、训练集风格的指令模板9.3 真机部署时的安全问题这部分必须单独强调。任何动作预测模型在真正接到机器人上之前都要经过仿真验证并且设计安全机制。首次上真机时建议把速度上限调低、设置关节限位、准备好急停开关。不要在没有任何安全措施的情况下直接跑最大速度测试。这不是保守这是负责任。10. 工程建议从“能跑”到“能落地”如果你已经用 TurboVLA 这类轻量模型跑通了推理接下来更值得思考的是怎么把它做扎实。第一输入对齐要固定成标准流程。从相机采集到喂给模型的每一步包括分辨率、裁剪方式、色彩空间、归一化参数都要写成一个稳定模块不能被调试代码随意改动。输入不一致模型效果就别谈。第二指令模板要收敛。轻量模型不是聊天机器人不要指望它能理解自由文本。把指令集设计成有限的模板配合一个简单的槽位解析稳定性会显著提升。第三动作空间要和你真实的机器人匹配。模型输出的动作向量需要经过安全映射才能发给底层控制器比如限制最大线速度、角速度做平滑滤波加入笛卡尔空间限位。很多做 VLA 的团队把精力全放在模型精度上却忽略了最后这一层安全过滤这是真机部署的大忌。第四数据闭环比模型结构更值钱。0.2B 模型在单个任务上不一定输给 7B 模型前提是它见过足够多、足够多样的该任务数据。如果你的机器人场景相对固定与其盲目追捧大参数模型不如花时间采集数据、标注动作、做数据增强。VLA 的泛化能力很大程度来自数据分布而不只是参数数量。第五不要一上来就追求端到端。轻量 VLA 可以先在“视觉伺服从”这类闭环场景中验证比如目标跟踪、位置保持。这类场景动作空间简单、风险低跑通后再扩展到抓取、移动操作等复杂任务。渐进式落地比一步到位更有效。11. 总结与下一步方向回到标题里的问题VLA 动作预测必须经过 LLM 吗答案已经很清楚——不一定。LLM 是增强 VLA 理解和推理能力的重要组件不是动作预测的硬前提。TurboVLA 用 0.2B 参数在 RTX 4090 上跑出 32Hz 在线动作预测证明了“轻量、高频、本地可部署”这条路径的真实性。对一般开发者来说这带来一个很实际的机会你可以用一张消费级显卡完成 VLA 策略的完整闭环实验。模型加载、推理、性能测试、HTTP 服务化这些步骤在本地就能全部跑通。接下来值得关注的方向有几个一是轻量模型的指令跟随能力还能提升多少二是动作预测模型与 LLM 高层规划器如何低成本协同三是量化到 INT8/INT4 之后边缘设备上的实时性表现。如果你正好在做机器人项目我建议不要只盯大模型先把手上的轻量 VLA 跑出一个稳定的在线控制闭环。这比追赶参数规模更接近“能落地”。 VLA 动作预测必须经过 LLM 吗？轻量模型 32Hz 部署实践
做机器人开发的朋友最近大概率都被 VLAVision-Language-Action Model视觉-语言-动作模型刷屏了。但很多团队聊了一圈之后反而更焦虑主流方案动辄 7B、13B 参数起步底层还挂着一个 LLM想跑起来就要多卡集群。折腾两周模型终于能出动作了一回放速度发现只有 5Hz连一个基础的速度闭环都稳不住。于是不少人得出一个结论VLA 是富哥的玩具小团队碰不得。这个判断有一半是对的但另一半需要重新审视。VLA 动作预测必须经过 LLM 吗答案是否定的。VLA 是一种学习范式而不是某个模型的专属称号。LLM 只是构建 VLA 的一种底座选择不是必经之路。TurboVLA 的出现恰好把这个事实摆在了台面上0.2B 参数单张 RTX 4090 能跑出 32Hz 在线动作预测。这篇博客我想认真拆一下这件事它背后涉及 VLA 的架构判断、动作预测到底需要什么、以及一个普通开发者怎么基于轻量 VLA 搭一套可验证的本地推理环境。1. 先搞清楚 VLA 到底在解决什么问题很多人第一次接触 VLA 时习惯把它理解成“能看图的 LLM 机器人版”。这个类比有帮助但也容易误导。传统机器人控制链路是感知、规划、控制三段式视觉模块负责识别物体路径规划模块负责算轨迹控制模块负责把轨迹转成关节指令。每段独立开发、独立调试接口要人工对齐数据在模块之间流转时还会丢信息。尤其是遇到开放场景比如桌面上的物体位置变了、光照变了、指令换了一种说法传统模块化系统很容易碎掉。VLA 做的事情是把“看”“想”“动”压缩进一个端到端的映射输入是图像可能还有语言指令输出是动作序列。它不区分感知模块和规划模块而是直接从大量“图像-指令-动作”数据里学出那个映射函数。这意味着 VLA 的核心价值不是会说漂亮话而是能把视觉观察和动作输出之间的依赖关系学出来。这个依赖关系在数学上就是一个高频函数每一帧图像进来模型要尽快给出当前这一步的动作。那么问题就来了为了让这个函数变成可用的机器人策略我们真的需要一个几十亿参数、基于自回归文本生成的大语言模型吗2. “必须经过 LLM”这个印象是怎么形成的先承认一个事实目前很多头部 VLA 工作确实是以 LLM 为底座的。比如把视觉 token 和文本指令 token 一起喂给一个预训练语言模型然后在模型输出端接一个动作头把动作表示成 discrete token 或者连续向量。这类方案的好处很明显LLM 带来了强大的常识推理、指令泛化和多模态对齐能力模型对指令的理解更“聪明”。但这里有一个容易忽略的细节架构选择是因为好用不是因为必需。VLA 的数学定义是“图像、语言到动作的映射”它没有规定中间必须发生一次自回归文本生成。LLM 在 VLA 中更准确的角色是“高层的任务理解和规划器”而不是“每一帧动作必须经过的隧道”。在真实机器人系统里这两件事的频率要求完全不同层级典型频率承担任务适合的模型任务规划层0.1 - 1 Hz理解指令、拆解子目标、处理异常LLM、VLM动作执行层10 - 100 Hz根据当前观测输出关节速度/位置增量轻量策略模型、VLA 轻量版底层控制层100 - 1000 Hz伺服控制、电流环、力矩环PID、MPC、状态机如果把动作执行层也塞进一个 7B 的 LLM 里每次推理几秒钟机器人基本就是“想一下动一下再想一下”。这不是控制这是抽帧动画。所以更合理的设计是分层LLM 负责低频的任务拆解和语义理解轻量 VLA 负责高频的感知-动作映射。TurboVLA 的定位正是后者。3. TurboVLA 的 0.2B 参数到底意味着什么0.2B 参数是什么概念对比一下就清楚了。常见的多模态大模型动辄 7B、13B甚至 70B一个 7B 模型用 FP16 存储光权重就要占 14GB 显存推理时还要算 KV cache、中间激活值一张 24GB 的 RTX 4090 勉强能跑但稍微加长输入序列或者加大 batch立刻逼近显存上限。而 0.2B 模型FP16 权重只有 400MB 左右即便加上中间激活也能非常从容地放进一张消费级显卡。这直接改变了部署方式不需要多卡不需要 A100不需要分布式推理框架。参数变少推理延迟自然也会下降。对一个只有 2 亿参数左右的动作预测模型来说单帧前向推理只需要几毫秒到十几毫秒量级这取决于视觉编码器的尺寸和输入分辨率。这也是 32Hz 在线动作预测能成立的前提。但我要强调一下0.2B 参数不是万能的。它在常识推理、复杂任务分解这些高维语言能力上肯定比不过 7B、13B 的大模型。它的优势区间是动作预测本身输入清晰、输出维度确定、任务边界相对收敛。换句话讲TurboVLA 走的是“好钢用在刀刃上”的路线把计算资源全部留给感知-动作映射而不是花在开放世界的语言生成上。4. RTX 4090 上跑 32Hz 在线动作预测这个数字怎么理解先解释一下“在线动作预测”。它指的是模型在真实运行过程中每采集到一帧图像就立即输出一个动作而不是读取一整段视频后离线批量预测。在线推理对延迟极其敏感因为机器人的执行是实时的晚一秒或者掉一帧控制效果就会劣化。32Hz换算一下就是每帧动作预测的平均时间约 31ms。这个数字放在机器人控制里是什么水平很多轻量机械臂的关节速度环在 100Hz 到 1000Hz但那是底层伺服控制的频率。在策略层面一个视觉引导的抓取动作10Hz 以上基本就能让整个控制环路稳定工作30Hz 左右已经能实现比较连贯的在线跟踪。所以 32Hz 不是“勉强能跑”而是“有一定控制余量”。还有一点值得注意RTX 4090 只是一张桌面级显卡。对于实验室验证和算法研发来说这意味着你不需要申请服务器资源用自己的开发机就能完成 VLA 策略的部署和测试。这是把 VLA 从“大厂论文”往“普通开发者实践”推进了一步。当然也需要冷静看待。RTX 4090 功耗较高也不是机器人本体上能长期携带的硬件。从 4090 到边缘设备仍然有量化、蒸馏、算子裁剪等一堆工程问题要处理。但至少第一步的验证门槛已经被降到很低了。5. 轻量 VLA 的本地环境准备如果你也想验证一下“不经过 LLM 的动作预测模型”可以按下面这套思路搭一个最小环境。TurboVLA 的具体仓库地址和模型权重建议以官方文档为准这里重点讲通用的准备工作以及每一步为什么需要。5.1 硬件与驱动确认建议环境是NVIDIA 显卡显存至少 8GB这是轻量模型的底线0.2B 模型更宽松驱动版本要支持 CUDA 12.x。可以先跑一条命令确认nvidia-smi重点看两个信息驱动版本是否较新以及显存大小是否足够。如果nvidia-smi都跑不起来先解决驱动问题。然后确认 PyTorch 的 CUDA 是否可用import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))如果输出False说明 PyTorch 的 CUDA 版本和驱动不匹配需要重装对应 CUDA 版本的 PyTorch。5.2 创建独立 Python 环境实操经验不要直接往系统 Python 里装深度学习依赖很容易污染其他项目。建议用 conda 或 venv 建独立环境conda create -n vla_test python3.10 -y conda activate vla_test pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121 pip install transformers4.40 pillow numpy fastapi uvicorn这里transformers不是必需的取决于模型仓库是否基于 Hugging Face 格式。如果模型自己带推理脚本可以不装。fastapi和uvicorn是为了后面的 HTTP 部署验证。5.3 准备测试图片和指令在线动作预测需要一个图片输入和一条指令。建议从现实世界随手拍一张桌子、一个物体的照片或者从机器人数据集里导出一帧观测图。关键是图片要能代表真实部署场景不要用纯色图否则模型输出的动作没有参考意义。我习惯把测试素材固定在一个目录里方便反复验证mkdir -p test_data # 将测试图片命名为 obs.jpg放在 test_data 目录下6. 最小推理示例加载轻量 VLA 模型并输出动作下面这段代码是一个“通用结构示意”。如果你使用的模型仓库提供了官方推理接口优先用官方接口如果没有可以参考这套逻辑理解 VLA 推理的大致流程。# demo_predict.py # 演示用代码具体模型加载方式以对应仓库 README 为准 import torch from PIL import Image # 假设模型仓库提供了一个统一的预测器入口 from vla_sdk import create_vla_predictor # 加载模型bfloat16 可以降低显存占用 predictor create_vla_predictor( model_pathTurboVLA-0.2B, devicecuda, dtypetorch.bfloat16, ) # 读取观测图像 image Image.open(test_data/obs.jpg).convert(RGB) # 自然语言指令 instruction move forward 0.3 meters # 推理输入图像 指令输出动作向量 action predictor.predict(image, instruction) # 通常动作向量可能是六维末端位姿增量 # 也可能是关节位置增量具体维度看模型设计 print(action dimension:, len(action)) print(action value:, action.tolist())这个流程有几个关键点第一图像必须转为 RGB 且保持模型训练时的输入分辨率。很多模型内部会做 resize 和归一化但外部传入的通道顺序错误会导致效果严重劣化。第二指令不要写得太长、太复杂。轻量模型的指令理解能力有限最稳妥的做法是使用和训练集一致的简短祈使句比如“pick up the red cup”比“请帮我把那个红色的杯子从桌面上拿起来然后放到旁边的托盘里”要可靠得多。第三输出的动作向量含义取决于模型训练时的定义。有的模型输出末端位姿增量有的输出关节速度有的输出动作 token。使用前一定要阅读仓库说明否则拿到一串数字也不知道怎么发送给机器人。7. 性能测试验证推理延迟和频率跑通推理只是第一步。标题里提到的 32Hz要验证起来也很直接多次推理取平均延迟然后换算成频率。下面这段脚本可以复用。# benchmark_latency.py import time import numpy as np import torch from PIL import Image from vla_sdk import create_vla_predictor predictor create_vla_predictor( model_pathTurboVLA-0.2B, devicecuda, dtypetorch.bfloat16, ) # 用固定输入做基准测试 image Image.fromarray(np.random.randint(0, 255, (480, 640, 3), dtypenp.uint8)) instruction pick up the red cup # 预热CUDA 第一次推理会包含 kernel 编译结果不准确 for _ in range(10): predictor.predict(image, instruction) # 正式计时 runs 100 torch.cuda.synchronize() start time.perf_counter() for _ in range(runs): predictor.predict(image, instruction) torch.cuda.synchronize() avg_ms (time.perf_counter() - start) / runs * 1000 print(favg latency {avg_ms:.1f} ms) print(ffps {1000.0 / avg_ms:.1f} Hz)判断标准很简单如果平均延迟在 30ms 左右那就是 30Hz 量级。如果差得很远先检查是否误用了 FP32 推理或者是否在 CPU 上运行。另外第一次推理一定比后续慢这是正常的预热几次再测更公平。这里再提醒一个容易被忽略的点模型推理延迟和控制环端到端延迟是两回事。端到端延迟还包括相机采集时间、图像预处理时间、网络传输时间、动作下发时间。所以即使模型本身只有 30ms整个控制回路也可能有 50 到 100ms 的延迟。做真机部署时要对这个增量有心理预期。8. 把 VLA 动作预测部署成 HTTP 服务在实验室环境里直接调 Python 接口没问题。但真机部署时模型推理往往跑在一个独立进程里控制程序跑在另一个进程里两者需要通信。最常见的方式是提供一个 HTTP 服务。# server.py import io from fastapi import FastAPI, File, Form, UploadFile from PIL import Image from vla_sdk import create_vla_predictor app FastAPI() predictor create_vla_predictor( model_pathTurboVLA-0.2B, devicecuda, dtypetorch.bfloat16, ) app.post(/predict) async def predict( image: UploadFile File(...), instruction: str Form(...), ): # 读入图像 img_bytes await image.read() pil_image Image.open(io.BytesIO(img_bytes)).convert(RGB) # 推理 action predictor.predict(pil_image, instruction) return {action: action.tolist()}启动服务uvicorn server:app --host 0.0.0.0 --port 8000用 curl 验证curl -X POST http://127.0.0.1:8000/predict \ -F imagetest_data/obs.jpg \ -F instructionmove forward 0.3 meters预期会看到一个 JSON 返回里面是动作向量{ action: [0.05, 0.0, 0.3, 0.0, 0.0, 0.0] }这个服务的最大价值是把模型推理与控制程序解耦。控制程序只管发图片、收动作不管模型是怎么加载的。后面想换模型、加量化、加缓存都不需要改动控制侧代码。不过要注意HTTP 的序列化和传输本身有开销。如果控制频率要求很高不建议走 HTTP可以改用 gRPC 或者共享内存。HTTP 更适合开发验证和低频任务级调用。9. 常见问题与排查思路9.1 推理速度远低于标称的 32Hz问题现象可能原因排查方式解决方案推理帧率只有 5-10Hz模型跑在 CPU 上查看torch.cuda.is_available()和设备名称确保模型加载到 CUDA 设备推理帧率只有 5-10Hz使用了 FP32 或未开推理模式检查推理代码是否有model.eval()改用 bfloat16/float16并开启torch.inference_mode()推理帧率波动大输入图片分辨率过大预处理耗时查看是否在循环里做了 resize预处理与推理并行或提前缓存前几次推理很慢CUDA kernel 编译观察预热后的延迟先跑 10-20 次预热再计时9.2 模型输出动作不稳定或明显错误问题现象可能原因排查方式解决方案动作向量剧烈跳动图像输入与训练分布不一致检查图片尺寸、颜色通道、拍摄角度统一输入预处理流程相同的输入得到不同结果模型处于训练模式或采样策略随机检查是否调用了model.eval()推理时固定随机种子对长指令理解差轻量模型的指令能力有限尝试不同类型指令使用简短、训练集风格的指令模板9.3 真机部署时的安全问题这部分必须单独强调。任何动作预测模型在真正接到机器人上之前都要经过仿真验证并且设计安全机制。首次上真机时建议把速度上限调低、设置关节限位、准备好急停开关。不要在没有任何安全措施的情况下直接跑最大速度测试。这不是保守这是负责任。10. 工程建议从“能跑”到“能落地”如果你已经用 TurboVLA 这类轻量模型跑通了推理接下来更值得思考的是怎么把它做扎实。第一输入对齐要固定成标准流程。从相机采集到喂给模型的每一步包括分辨率、裁剪方式、色彩空间、归一化参数都要写成一个稳定模块不能被调试代码随意改动。输入不一致模型效果就别谈。第二指令模板要收敛。轻量模型不是聊天机器人不要指望它能理解自由文本。把指令集设计成有限的模板配合一个简单的槽位解析稳定性会显著提升。第三动作空间要和你真实的机器人匹配。模型输出的动作向量需要经过安全映射才能发给底层控制器比如限制最大线速度、角速度做平滑滤波加入笛卡尔空间限位。很多做 VLA 的团队把精力全放在模型精度上却忽略了最后这一层安全过滤这是真机部署的大忌。第四数据闭环比模型结构更值钱。0.2B 模型在单个任务上不一定输给 7B 模型前提是它见过足够多、足够多样的该任务数据。如果你的机器人场景相对固定与其盲目追捧大参数模型不如花时间采集数据、标注动作、做数据增强。VLA 的泛化能力很大程度来自数据分布而不只是参数数量。第五不要一上来就追求端到端。轻量 VLA 可以先在“视觉伺服从”这类闭环场景中验证比如目标跟踪、位置保持。这类场景动作空间简单、风险低跑通后再扩展到抓取、移动操作等复杂任务。渐进式落地比一步到位更有效。11. 总结与下一步方向回到标题里的问题VLA 动作预测必须经过 LLM 吗答案已经很清楚——不一定。LLM 是增强 VLA 理解和推理能力的重要组件不是动作预测的硬前提。TurboVLA 用 0.2B 参数在 RTX 4090 上跑出 32Hz 在线动作预测证明了“轻量、高频、本地可部署”这条路径的真实性。对一般开发者来说这带来一个很实际的机会你可以用一张消费级显卡完成 VLA 策略的完整闭环实验。模型加载、推理、性能测试、HTTP 服务化这些步骤在本地就能全部跑通。接下来值得关注的方向有几个一是轻量模型的指令跟随能力还能提升多少二是动作预测模型与 LLM 高层规划器如何低成本协同三是量化到 INT8/INT4 之后边缘设备上的实时性表现。如果你正好在做机器人项目我建议不要只盯大模型先把手上的轻量 VLA 跑出一个稳定的在线控制闭环。这比追赶参数规模更接近“能落地”。