VLAVision-Language-Action模型这两年在学术圈的热度不用我多说从RT-1、RT-2到开源的OpenVLA、π0大家讨论的都是怎么把视觉、语言、动作塞进一个Transformer里。但真正落到工程侧问题就变得非常具体一个动辄几十亿参数的模型怎么塞进一个功耗十几瓦、成本几百块的嵌入式板子上还要保证推理延迟在可接受范围内我最近在折腾瑞迅科技基于RK3588和RK3576的双芯方案把VLA动作策略模型往端侧搬踩了不少坑也摸出了一些门道。这篇就把整个思路、选型逻辑、部署链路和实测数据摊开讲给同样在做端侧具身智能硬件落地的朋友一个参考。1. 为什么VLA模型端侧部署是个硬骨头1.1 VLA模型到底是一个模型还是两个模型这个问题在社区里被问烂了我先把概念理清楚因为它直接决定了你的部署架构。严格来说VLA是一个统一的策略模型但它的内部结构通常可以拆成三个功能模块视觉编码器Vision Encoder、语言理解与融合主干LLM Backbone、动作解码头Action Head。以OpenVLA为例它的骨架是Llama-2 7B视觉侧接了SigLIP和DINOv2两个编码器动作头则是一个把连续动作离散化成token的预测层。所以从模型文件角度看它是一个整体但从计算图角度看它是多个子网络拼接的复合体。为什么这个区分很重要因为在端侧部署时你几乎不可能把整个7B模型原封不动地跑在NPU上。RK3588的NPU算力是6 TOPSINT8RK3576是6 TOPS但架构更新两者都扛不住7B模型的全量推理。所以实际做法是分而治之视觉编码器量化后跑NPU语言主干做蒸馏或量化后跑NPU/CPU混合动作头用CPU做后处理。这就意味着你在部署时面对的不是一个模型而是一组需要协同调度的子模型。提示如果你看到有人说VLA就是一个模型他大概率是从训练视角说的如果你看到有人说VLA要拆成好几个模型部署那是从工程视角说的。两个说法都对只是语境不同。1.2 端侧部署的三个核心矛盾我在实际项目中总结下来VLA端侧部署绕不开三对矛盾算力与精度的矛盾。VLA模型对视觉特征的细粒度要求很高尤其是涉及抓取、放置这类需要空间精度的任务。你把视觉编码器量化到INT8精度掉得可能不多但动作输出的抖动会明显增大。我实测过SigLIP在FP16下动作成功率比INT8高约8个百分点这个差距在精细操作里是致命的。内存带宽与延迟的矛盾。RK3588是LPDDR4/4X/5RK3576是LPDDR5带宽差不少。VLA推理时视觉token和语言token的注意力计算是带宽杀手。你如果把模型全塞进NPUNPU和CPU之间的数据搬运会成为瓶颈如果全放CPU算力又不够。所以双芯架构的价值就体现出来了——一颗芯片专门跑视觉前端另一颗跑语言和动作通过高速总线交换中间特征。功耗与散热的矛盾。端侧设备很多是电池供电或者无风扇设计RK3588满载功耗能到8W以上RK3576稍好但也不低。VLA推理是持续负载不是突发负载散热设计必须按持续功耗来算。我见过有人用RK3588做手持设备跑VLA不到十分钟就降频动作延迟从80ms飙到300ms体验直接崩了。1.3 双芯架构不是两颗芯片简单叠加瑞迅科技这套RK3588RK3576的方案我一开始以为就是把两个芯片焊在一块板子上各跑各的。实际用下来才发现它的核心价值在于任务分工和流水线并行。RK3588的优势是接口丰富、NPU生态成熟、支持多路MIPI输入适合做视觉前端——接摄像头、做图像预处理、跑视觉编码器。RK3576的优势是能效比更好、LPDDR5带宽更高、CPU架构更新4×A724×A53 vs RK3588的4×A764×A55适合做语言推理和动作解码。两者通过PCIe或高速SPI互联中间特征用共享内存或DMA搬运。这种分工的逻辑是视觉编码是宽而浅的计算token数量多但每token计算量相对小适合RK3588的多核NPU并行语言推理是窄而深的计算层数多、注意力矩阵大适合RK3576的高带宽内存和能效核心。实测下来这种分工比单颗RK3588跑全流程延迟低约35%功耗低约20%。2. RK3588与RK3576的硬件底座怎么选、怎么搭2.1 两颗芯片的关键参数对比选型不能只看算力数字我把实际部署中真正影响VLA推理的参数拉出来对比参数项RK3588RK3576对VLA部署的影响NPU算力6 TOPS INT86 TOPS INT8纸面相同但RK3576的NPU架构更新对Transformer类算子支持更好CPU4×A76 4×A554×A72 4×A53RK3588单核性能强适合做预处理调度RK3576能效好适合持续推理内存LPDDR4/4X/5LPDDR5RK3576带宽优势明显注意力计算受益大MIPI输入最多6路最多4路多摄像头场景RK3588更灵活视频编码8K30fps4K60fps如果需要回传视频流RK3588更强典型功耗5-8W3-5W双芯合计功耗要按持续负载算从表里能看出来RK3588不是更强而是接口更全、单核更快RK3576不是更弱而是能效更好、内存更快。双芯方案的本质是让每颗芯片干自己最擅长的事。2.2 视觉前端为什么放在RK3588VLA的视觉输入通常是多路摄像头比如头部一个广角、手腕一个近景。RK3588支持最多6路MIPI输入可以同时接多颗摄像头而且它的ISP图像信号处理器对1080i这类隔行信号的处理很成熟——社区里有人问RK3588 MIPI输入1080i信号怎么配其实就是要在设备树里把MIPI CSI的data-lanes和clock-mode配对隔行信号需要额外的deinterlace处理RK3588的VICAP模块可以直接做。视觉编码器我推荐用SigLIP的量化版本输入分辨率224×224或384×384。RK3588的NPU对卷积和ViT类算子支持都不错用RKNN-Toolkit2转换后SigLIP-Base在INT8下推理约15msFP16约28ms。如果你用DINOv2延迟会高一些因为它的注意力窗口更大。注意RK3588的NPU对动态shape支持有限VLA的视觉输入如果分辨率可变建议在预处理阶段统一resize到固定尺寸否则每次推理都要重新编译模型延迟不可控。2.3 语言与动作模块为什么放在RK3576语言主干是VLA里最吃内存带宽的部分。以一个小型化的VLA策略模型为例语言侧可能是1B-3B参数的Transformer注意力矩阵在序列长度512时就是512×512每层都要读写。RK3576的LPDDR5带宽比RK3588的LPDDR4X高约50%这在注意力计算上是实打实的优势。动作解码头通常不大几层MLP或者一个小型Transformer但它对延迟敏感。RK3576的A72核心跑动作解码配合NPU做矩阵乘端到端可以控制在20ms以内。而且RK3576的功耗低适合长时间持续推理不会像RK3588那样容易触发温控降频。2.4 双芯互联的三种方案与实测选择两颗芯片怎么连我试过三种方案一PCIe Gen3 x2。带宽最高理论8GT/s实际有效带宽约1.5GB/s。适合传输大块特征图比如视觉编码器输出的token序列。缺点是PCIe初始化复杂设备树配置容易出错而且功耗略高。方案二高速SPI。带宽约50MB/s适合传小量控制指令和状态同步不适合传特征。优点是简单稳定几乎不会出兼容性问题。方案三共享内存DMA。如果两颗芯片在同一块板子上可以通过共享DDR区域做数据交换DMA搬运不占CPU。带宽取决于内存控制器实测约800MB/s。这是我最推荐的方案延迟低、功耗低、编程模型简单。最终我选的是共享内存为主、SPI为辅视觉token通过共享内存传给RK3576控制指令和心跳通过SPI同步。这样既保证了带宽又保证了可靠性。3. 从PyTorch到RKNNVLA模型端侧转换的完整链路3.1 模型拆分与导出策略把VLA拆成可部署的子模块是整个链路里最考验功力的一步。我的做法是视觉编码器单独导出。把SigLIP或DINOv2从VLA里剥出来输入固定为[1, 3, 224, 224]输出视觉token。用torch.onnx.export导出ONNXopset选13或14。语言主干做量化感知训练或训练后量化。如果原始模型是7B先做蒸馏到1B-3B再导出。导出时把KV Cache的处理逻辑固化因为端侧推理通常是单步解码不需要动态cache。动作头单独导出。动作头通常依赖语言主干的最后一层hidden state所以导出时要确保接口对齐。我一般把动作头做成一个独立ONNX输入是hidden state输出是动作向量。提示导出ONNX时一定要用torch.onnx.export的dynamic_axes参数把batch维度固定为1否则RKNN转换时会报shape不匹配。VLA端侧推理基本都是batch1没必要留动态维度。3.2 RKNN-Toolkit2转换中的算子坑RKNN-Toolkit2对Transformer类算子的支持在持续改进但仍有几个坑LayerNorm的epsilon。PyTorch默认是1e-5RKNN转换时如果epsilon太小量化后数值不稳定。我一般把epsilon改成1e-3再导出精度损失可接受但稳定性大幅提升。GELU激活。RKNN对GELU的支持分版本有些版本只支持tanh近似。如果你的模型用的是精确GELU转换后精度会掉。解决办法是在导出前把GELU换成tanh近似版本或者用ReLU替代做微调。Softmax的温度。注意力里的Softmax如果温度系数不是1RKNN量化后容易溢出。建议在导出前把温度系数吸收进QK的缩放里保持Softmax输入在合理范围。多输入模型的输入顺序。VLA拆分后往往有多个输入视觉token、语言token、位置编码RKNN转换时输入顺序必须和推理时一致否则结果全错。我习惯在ONNX里给每个输入命名转换后用rknn.inputs确认顺序。3.3 量化校准集怎么选量化校准集的选择直接决定INT8模型的精度。我的经验是视觉编码器用实际场景的图片至少500张覆盖不同光照、角度、遮挡情况。不要用ImageNet分布不匹配。语言主干用实际任务指令的文本至少200条覆盖不同句式和长度。动作头用实际动作序列至少1000步覆盖不同动作幅度。校准集的数据要预处理成和推理时完全一致的格式包括归一化参数、resize方式、padding策略。我见过有人校准集用RGB推理时用BGR精度直接崩掉。3.4 转换后的精度验证方法转换完不能直接上板子跑要先在PC上做数值对比import numpy as np import onnxruntime as ort from rknn.api import RKNN # 加载ONNX和RKNN onnx_sess ort.InferenceSession(vision_encoder.onnx) rknn RKNN() rknn.load_rknn(vision_encoder.rknn) # 准备同一组输入 input_data np.random.randn(1, 3, 224, 224).astype(np.float32) # ONNX推理 onnx_out onnx_sess.run(None, {input: input_data})[0] # RKNN推理模拟模式 rknn.init_runtime(targetNone) rknn_out rknn.inference(inputs[input_data])[0] # 对比 diff np.abs(onnx_out - rknn_out) print(f最大绝对误差: {diff.max():.6f}) print(f平均绝对误差: {diff.mean():.6f}) print(f余弦相似度: {np.dot(onnx_out.flatten(), rknn_out.flatten()) / (np.linalg.norm(onnx_out) * np.linalg.norm(rknn_out)):.6f})余弦相似度低于0.99就要警惕低于0.95基本不能用。我一般要求视觉编码器余弦相似度0.995语言主干0.99动作头0.98。4. 端侧推理引擎的调度设计让双芯真正跑起来4.1 推理流水线的阶段划分VLA推理可以拆成四个阶段图像采集与预处理、视觉编码、语言-动作联合推理、动作后处理与下发。在双芯架构下我的划分是RK3588侧图像采集MIPI CSI、ISP处理、resize/归一化、视觉编码器推理。RK3576侧接收视觉token、语言主干推理、动作头推理、动作平滑与下发。共享内存视觉token缓冲区双缓冲设计避免读写冲突。流水线的关键是让两颗芯片的推理重叠。当RK3576在跑第N帧的语言推理时RK3588已经在采集和处理第N1帧的图像了。这样端到端延迟不是两段之和而是最大值加上少量同步开销。4.2 共享内存的双缓冲与同步机制双缓冲的实现不复杂但细节容易出错。我用的是// 共享内存结构 typedef struct { volatile int write_idx; // 当前写入缓冲区 volatile int read_idx; // 当前读取缓冲区 volatile int frame_id; // 帧序号 float vision_tokens[2][TOKEN_NUM][TOKEN_DIM]; // 双缓冲 } SharedBuffer;RK3588写完一个缓冲区后更新write_idx和frame_id然后通过SPI发一个中断给RK3576。RK3576收到中断后读取write_idx对应的缓冲区处理完更新read_idx。注意共享内存的缓存一致性是个大坑。RK3588和RK3576如果都有cache写完后必须做cache flush读之前必须做cache invalidate。我一开始没做结果RK3576读到的全是旧数据排查了一整天才发现。4.3 延迟预算与实时性保障VLA端侧部署的延迟预算通常是100ms以内10Hz控制频率。我的实测分配是阶段耗时说明图像采集与预处理8msMIPI采集VICAP处理resize视觉编码15msSigLIP-Base INT8特征传输3ms共享内存DMA语言主干35ms1.5B模型INT8序列长度256动作头8msMLP后处理动作下发2msCAN/串口同步开销5ms中断调度合计76ms留有余量这个延迟在抓取、放置这类任务里够用但如果是高速动态任务比如接球还需要进一步优化。优化方向主要是减少语言主干的序列长度、用更小的模型、或者把动作头也放到NPU上。4.4 温控与降频的应对策略RK3588满载跑视觉编码温度上升很快。我的应对策略是动态调频根据温度调整NPU频率温度低于60度跑满频60-75度降一档75度以上降两档。任务迁移如果RK3588温度过高把部分视觉预处理任务迁移到RK3576的CPU上。散热设计必须加散热片有条件加小风扇。无风扇设计的话RK3588的持续功耗要控制在4W以内。我实测过加散热片后RK3588可以稳定跑在6W不降频不加散热片5分钟就降频。5. 实测数据与踩坑复盘5.1 不同量化策略下的精度-延迟权衡我对比了三种量化策略在同一个VLA任务上的表现策略视觉编码语言主干动作头成功率端到端延迟全FP16FP16FP16FP1692%210ms混合量化INT8FP16FP1689%145ms全INT8INT8INT8INT881%76ms全INT8延迟最低但成功率掉了11个百分点。混合量化是个折中视觉用INT8精度损失小语言和动作保持FP16精度敏感。实际项目中我推荐混合量化除非你对延迟极其敏感。5.2 视觉编码器分辨率对动作精度的影响VLA的动作精度对视觉分辨率很敏感。我测试了224、336、384三种输入224延迟15ms抓取成功率78%336延迟28ms抓取成功率86%384延迟42ms抓取成功率89%384比224成功率高了11个百分点但延迟翻了近三倍。我的建议是如果任务对空间精度要求高比如插孔、拧螺丝用384如果是粗放抓取224够用。5.3 双芯通信的稳定性问题排查双芯通信我遇到过两个典型问题问题一SPI中断丢失。RK3576在高负载时SPI中断响应不及时导致帧同步错乱。解决办法是把SPI中断优先级提到最高并且在RK3588侧加超时重传机制。问题二共享内存数据撕裂。RK3588写共享内存时RK3576同时读读到半新半旧的数据。解决办法是严格双缓冲内存屏障写完一个缓冲区再切换索引读的时候先读索引再读数据。5.4 从烧写到部署的完整流程清单最后给一个可复现的流程清单系统烧写RK3588和RK3576分别烧写Ubuntu 20.04或22.04用瑞迅提供的烧录工具打补丁设备树、NPU驱动、MIPI配置。环境配置安装RKNN-Toolkit2、RKNPU2运行时、OpenCV、FFmpeg如果需要推流。模型转换按第3节的链路把VLA拆成三个ONNX分别转RKNN做精度验证。共享内存配置在设备树里预留共享内存区域两颗芯片的地址要一致。推理程序部署RK3588跑视觉前端程序RK3576跑语言-动作程序通过SPI同步。联调测试先跑单帧确认数据流正确再跑连续帧测延迟和稳定性最后跑实际任务统计成功率。温控调优根据实测温度调整调频策略和散热方案。提示RK3588烧写Ubuntu 20.04时如果遇到MIPI屏幕不亮检查设备树里的panel-init-sequence和disp_timings不同屏幕参数不一样瑞迅的BSP里通常有参考配置。这套方案我前后调了大概两个月从最开始的单芯跑不动到双芯流水线跑通再到精度和延迟调优中间踩的坑基本都写在这了。VLA端侧部署没有银弹核心就是理解模型结构、匹配硬件特性、做好任务分工。RK3588RK3576的双芯架构不是唯一解但在当前端侧算力条件下它是一个性价比很高的选择。如果你也在做类似的事情希望这篇能帮你少走点弯路。