做过 VLA视觉-语言-动作模型端侧部署的朋友应该都遇到过这样一个尴尬场景模型在服务器上跑得好好的拿回机械臂或移动底盘上一测延迟直接冲到 300ms 以上。控制回路要求 50ms 一个周期你跑出 300ms机械臂的动作看起来就像开了慢放——而且不是简单的慢是“看一眼、想一下、再动一下”的卡顿感。调整 PID 参数解决不了这个问题因为问题根本不是控制算法而是推理延迟。这篇文章就把 VLA 端侧部署的延迟问题彻底拆开。我会从延迟到底消耗在哪些环节讲起然后逐类展开六类我实际验证过有效的手段模型压缩、算子融合与编译优化、异构调度、异步流水线、动态推理控制、缓存复算。每一类我都会给出为什么有效、怎么做、以及哪些场景下收益最大。如果你正在做机器人操作、端侧智能体或者任何 VLA 推理加速相关的工作这篇文章应该能让你的延迟优化路径清晰很多。1. VLA 延迟从哪来先搞清楚时间到底花在哪一步我在第一次拿到 VLA 模型的端侧延迟数据时第一反应是怀疑工具统计错了。因为它长得和普通的视觉模型完全不同不是那种单一的“前向推理”耗时而是一段明显可分三个阶段的时间曲线。后来把 profiling 数据一条条拉出来看才真正明白 VLA 的时间开销结构。1.1 VLA 的“三段式”推理链路绝大多数 VLA 模型的结构分为三个部分视觉编码器通常是 ViT 系列、大语言模型主干LMM Backbone以及动作解码头Action Head。一条推理请求从图像进入视觉编码器开始到自回归生成完最后一个 token再到动作头算出连续控制量是一个很长的链路。以我常用的一个 2B 参数级 VLA 为例一次完整推理的延迟构成大致是视觉编码阶段图像切 patch、ViT 前向计算产生视觉 token大概占总延迟的 15%-20%预填充阶段Prefill把视觉 token 和文本/指令 token 一起喂给 LLM 主干做首轮前向产出第一个动作 token这是大头通常占 40%-50%自回归生成阶段Decode逐个产出余下的动作 token如果动作 token 序列有 8-12 个这一步占比约 30%-40%看到这组数据你应该已经意识到一个很关键的问题VLA 的延迟不是一个可以靠单一“模型加速”解决的简单指标。压缩视觉编码器只能管住 20% 的开销真正的大头在预填充和自回归生成而这两块恰恰是 LLM 推理优化的核心战场。1.2 端侧和云端的一个本质差别内存带宽同样一个 VLA 模型在 A100 上可能跑得很流畅换到端侧芯片立刻露馅除了峰值算力还有一个隐藏瓶颈是内存带宽。自回归 Decode 阶段每个 token 的生成都需要扫描一遍模型参数这是一个典型的 memory-bound 过程。A100 的内存带宽超过 2TB/s而端侧常见的 NPU、GPU 或者旗舰级 SoC 的内存带宽往往只有几十到一百多 GB/s差了整整一个数量级。换句话说哪怕端侧芯片的 TOPS 数据标得再好看只要模型权重没有压到足够小Decode 阶段就会卡在内存搬运上。这也是为什么我在做端侧 VLA 部署时第一步永远是模型压缩——先把权重体积压下来因为内存带宽这个物理瓶颈直接决定了后面的优化空间。1.3 延迟需求的等级划分不同应用场景对 VLA 延迟的需求差异极大。做桌面级的抓取演示300ms 延迟也能凑合但做动态物体的实时跟随、搭建产线上的高速分拣控制周期就要求 50ms 甚至更低。端侧部署前先把自己的延迟预算定清楚我一般分为三档休闲级200-300ms静态物体的抓放操作足够开发难度最低操作级80-120ms机械臂可以做基础的动态轨迹跟踪需要做一到两类优化伺服级30-50ms高速操作或闭环控制需要组合拳对大多数项目来说先把目标定在 80ms 左右是比较合理的起点。下面这六类手段组合使用完全可以做到。2. 手段一量化、剪枝与蒸馏 —— 把模型压到腰围一半再谈优化前面说了VLA 端侧部署的底层约束是内存带宽所以第一板斧就是把模型“做小”。这看起来是老生常谈但 VLA 模型和普通大模型在压缩上有几个非常容易踩坑的特殊点。2.1 量化VLA 的视觉编码器对量化更敏感量化几乎是端侧部署必做的操作VLA 也不例外。我实测过 INT8 权重量化和 W8A8 动态量化在 2B VLA 模型上的困惑度变化和最终控制精度影响有非常明显的差异。先说结论LLM 主干部分做 INT8 量化后动作 token 的预测偏差很小但视觉编码器一旦量化到 INT8视觉 token 的质量会肉眼可见地下降机械臂的抓取成功率掉得很明显。原因在于视觉编码器的输出会直接成为 LLM 的输入 embedding量化误差在这里会被自回归过程不断放大不像文本生成那样有容错空间。所以我在项目中把量化策略做了拆分视觉编码器保持 FP16 或者只做 W8A8 动态量化权重 INT8、激活 FP16LLM 主干和动作头做 INT8 静态量化。如果设备支持 INT4 量化且对精度损失有容忍度可以把 LLM 主干压到 INT4但视觉编码器我建议保守处理。这里提供一个我在项目中验证过的量化配置参考模块推荐量化方案延迟收益精度影响视觉编码器FP16 或 W8A8 动态量化较小但稳定几乎无损LLM 主干INT8 静态量化 / INT4 结合 GPTQ显著Decode 加速 1.6-2 倍可控动作解码头保持与 LLM 一致的量化跟随主干注意末端层用 FP162.2 剪枝VLA 的结构适合结构化剪枝VLA 模型的关键特征是存在大量“冗余视觉 token”的处理路径。视觉编码器会把一整个图像切分成几十上百个 patch token这些 token 经过 LLM 计算时很多其实对最终动作输出没有贡献。基于这个特性对 LLM 主干做结构化剪枝时可以重点剪掉与视觉 token 交互较弱的层或者注意力头。当然剪枝之后通常要配合一次蒸馏来恢复精度。我试过把 2B 模型剪掉 20% 的参数再让原始大模型输出做蒸馏动作成功率的回落在 2% 以内。相比直接用一个从头训练的小模型这种“剪枝蒸馏”的方案在端侧部署中更实用因为你不需要重新收集大量动作轨迹数据只需要用原模型产生伪标签。2.3 蒸馏用大模型蒸馏一个小模型如果项目允许直接把原 VLA 模型蒸馏成 0.5B-1B 的轻量模型是收益最大的一招。VLA 蒸馏有个特别好的条件动作空间的连续性比语言空间高很多蒸馏时不需要像文本生成那样逐字比对概率分布只需要让小模型输出的动作向量通常是连续值逼近大模型的输出。实际操作中我用 L1 Loss 余弦相似度做动作输出的蒸馏约束效果比直接模仿 logits 更稳因为连续动作的尺度差异会影响收敛。蒸馏后的小模型延迟可以直接降到原模型的 30%-40%而且由于参数量小了后续所有编译优化、缓存策略的收益都会被放大。2.4 压缩手段的收益边界模型压缩不是万能的。当你把 VLA 压缩到一定程度后继续压缩的收益会急剧衰减而精度损失会加速上升。我的经验判断是INT8 是端侧 VLA 的甜点位INT4 留给极缺带宽的设备备选剪枝控制在 20%-30% 以内蒸馏后模型参数不要低于原模型的 40%否则动作精度很难保持。3. 手段二算子融合与编译优化 —— 编译器做的“提前批”模型压完第二件事是让计算过程本身变快。这里我说的不是改模型结构而是通过推理引擎和编译器的力量把计算图中的冗余操作消掉、把能并行的算子合并起来。很多人以为端侧推理就是拿 PyTorch 导出 ONNX 再喂进引擎实际上差得远。3.1 端侧 VLA 推理引擎的选型逻辑端侧可用的推理引擎不少TensorRTNVIDIA 平台、TensorRT LLM带自研优化的大模型推理、MNN、NCNN、TFLite以及各家芯片厂商的 NPU SDK。选型时我主要看三个标准是否支持动态形状因为 VLA 的视觉 token 数量可能因输入图像尺寸变化、是否内置大模型 Decode 优化、以及是否方便和摄像头采集链路对接。在 Android/嵌入式 Linux 平台上我目前的主力方案是LLM 部分用 TensorRT LLM 或 llama.cpp 这类有 Decode 优化的引擎视觉编码器用传统 CNN 友好的 MNN 或 NCNN 加速。这样分开跑虽然工程上要维护两套接口但每一段都踩在最成熟的工具链上整体稳定性和速度都优于用一个“万能引擎”硬跑。3.2 算子融合把十个小动作合并成一个大动作算子融合是编译优化中最容易理解、收益也最直接的手段。一个典型的例子LayerNorm 后面跟着量化、再跟着 MatMul原本每一步都要从内存中读一遍激活值。融合之后三步变成一步中间激活根本不落内存省掉的不只是三次读写的耗时还有多次内核启动的开销。在 VLA 模型里注意力层的融合收益尤其明显。QKV 投影、多头注意力、输出投影、残差连接这四个操作融合优化和非融合版本能差出 30% 的整体推理时间。大部分成熟引擎会自动做这种融合但你需要确认自己的模型导出时是否开启了对应开关。我在排查一个性能问题时发现仅仅是 ONNX 导出时未设置opset17以上导致某些注意力算子没有被融合最终推理延迟比预期高了近一半。3.3 动态形状与静态形状的取舍VLA 模型的视觉 token 数量在很多实现里是固定的比如固定 256 个 patch token这时可以手动将计算图固定为静态形状让编译器做更激进的内存布局优化。但如果你的输入图像分辨率可变或者支持多分辨率输入就必须保留动态形状。动态形状对推理引擎的压力很大特别是 NPU 场景很多芯片的 NPU 驱动在动态形状下的性能表现非常差。我现在的做法是固定输入分辨率做一个简单的预处理把任意摄像头画面 resize 到统一尺寸然后让推理引擎以静态形状运行。实测下来固定形状可以让视觉编码器在 NPU 上的推理速度提升 20% 以上。3.4 跨阶段融合视觉编码器和 LLM 的联动优化还有一个很多团队会忽略的点视觉编码器和 LLM 主干之间存在一个从 ViT 输出到 embedding 拼接的转换过程。这部分通常包含 reshape、permute、concat 等操作消耗不大但对内存布局影响很大。把这些操作合并进视觉编码器的输出阶段避免在内存里产生一份完全独立的中间张量可以减少一次较大的 memcpy 开销。在 2B 模型上这部分只有几毫秒但在 50ms 延迟目标的控制回路里几毫秒就是巨大的余量。4. 手段三异构调度 —— NPU 和 CPU 怎么分活才不打架端侧主控芯片上通常不只有一块计算单元。旗舰级 SoC 通常包含 CPU、GPU、NPU、DSP部分芯片还有独立的硬件视频编解码单元。VLA 推理天然适合异构拆分因为它的三个子模块对计算单元的需求完全不同。4.1 视觉编码器该放哪NPU 还是 GPU我在两类平台上分别做过对比一类是高通骁龙平台Adreno GPU Hexagon NPU一类是瑞芯微 RK3588Mali GPU 自研 NPU。结论出奇一致视觉编码器放 NPU 收益最大。原因很简单ViT 的前向计算包含大量卷积和矩阵操作NPU 的定点算力通常远高于 GPU 的浮点算力而且 NPU 的功耗控制更好不会像 GPU 那样一调用就拉高整机温度。另外NPU 在处理固定形状输入时的资源利用率高只要形状固定NPU 基本能把所有算力单元吃满。需要注意的坑是各家的 NPU 工具链对 ViT 中的某些操作支持度不一致。比如部分 NPU 对 softmax 的实现有问题或者对 attention 中二维矩阵乘法的优化不足这时需要把视觉编码器切回 GPU。我的建议是不要一上来就迁到 NPU先用性能剖析工具看 ViT 图里的算子清单确认所有算子在目标 NPU 上都有高效内核再迁移。4.2 LLM 主干放哪CPU 是大模型的底线选择LLM 主干的 Decode 阶段是 memory-bound这种情况下 CPU 的 L2/L3 缓存和内存控制器往往表现得意外的好尤其是当模型被量化到 INT8 之后纯粹靠 CPU 的 SIMD 指令也能跑出不错的速度。我在 RK3588 平台实测2B 模型 INT8 量化后纯 CPU 推理的 Decode 速度可以做到每 token 8-12ms完全够用。而如果强行把 LLM 塞进 NPU反而会因为内存带宽争抢导致整体延迟劣化——因为你还在用同一个 NPU 跑视觉编码器两边一抢带宽谁都快不起来。所以异构调度的核心原则是不同模块放到不同计算单元上并且让它们之间不要争抢关键资源。比如视觉编码器放 NPULLM 放 CPU动作头继续保持和 LLM 同单元这样视觉编码和 LLM 生成在时间上是交错的互不干扰。4.3 多设备协同的调度细节异构调度不是一句“模型 A 放 NPU、模型 B 放 CPU”就完事了还要考虑设备之间的数据搬运。NPU 计算完成后得到的是 NPU 内存空间里的中间张量把它搬运到 CPU 的内存再喂给 LLM这个 PCIe/总线拷贝的耗时经常被低估。在 RK3588 上NPU 输出到 CPU 内存的一次大块拷贝可能吃掉 2-5ms。解决方法是尽量让视觉编码器的输出张量保持在共享内存区域或者使用芯片厂商提供的零拷贝接口。瑞芯微的 rknn 工具链支持 zero copy 模式高通也有类似的 API只要把输入输出内存注册进推理引擎就能避开显式 memcpy。5. 手段四异步流水线与双缓冲 —— 让硬件永远有活干如果你的 VLA 推理是“采集图像 → 推理 → 发送动作 → 等待 → 再采集”那延迟必然高得吓人。因为每一步都是串行的采集阶段计算单元在空转推理阶段采集单元在空转。异步流水线把这几段彻底错开让摄像头采集、预处理、推理、动作输出像工厂流水线一样各干各的。5.1 双缓冲让图像采集和推理重叠双缓冲是最常用的手法一块缓冲区用于摄像头 DMA 采集当前帧另一块缓冲区交给推理引擎处理上一帧。当摄像头把新帧写入空闲缓冲区时推理引擎同时处理着上一帧。这样采集的耗时完全被推理时间掩盖对最终延迟的影响降为零。实际实现时要留意摄像头驱动是否支持多 buffer 队列V4L2 的 mmap 多队列模式以及图像格式转换是否也放在异步线程里。我在项目中把 YUV 到 RGB 的转换从主循环摘出去放到了采集线程中顺手让整体推理延迟又降了 3-4ms。这类操作单个看很小但积少成多往往是最终达到控制周期指标的关键。5.2 控制回路不等待推理结果更激进的流水线设计是控制回路不阻塞在 VLA 推理结果上。比如机械臂的轨迹插补可以先根据上一帧 VLA 输出的动作指令插值出接下来几个控制周期每周期 10ms的期望轨迹。VLA 推理结果在这个时间段内到达下一轮轨迹再基于新指令插值。这样 VLA 延迟即使有 100ms控制回路照样能保持 10ms 周期的稳定运行。这种思路看似简单但工程上要求动作输出必须平滑——直接用硬切会抖动。我的做法是在轨迹插值器里加一个小型滤波器对新旧指令做平滑过渡过渡时间大约 50-100ms既能保证响应速度又不至于抖动。5.3 批处理与帧聚合的边界有些推理引擎在批量输入下效率更高尤其是视觉编码器的 NPU 推理批量处理可能比单帧处理快 30%。但在 VLA 场景里不建议为了批量而批量因为控制任务的实时性优先。只有在机器人多传感器场景比如多摄像头融合输入时自然产生的多帧批次可以合并推理否则宁可牺牲一点吞吐换确定性延迟。6. 手段五动态推理控制 —— 无关视觉 token 直接跳掉这一招是我认为最有“技术含量”的加速手段因为它涉及的不是工程层面而是模型行为的动态感知。VLA 模型在自回归生成动作 token 时并不需要每次都看全所有的视觉 token也不需要在每一步都跑满整个网络。6.1 自适应视觉 token 数量裁剪前面提过图像切分会产生大量 patch token但很多 token 对应的是图像背景、桌面纹理这类对动作决策毫无帮助的内容。静态压缩的方法是把视觉 token 固定减到 N 个但更好的做法是动态决定每帧图像需要保留多少 token。方法上可以用注意力得分作为 token 重要性的指示注意力得分低的 token对后续生成的贡献小可以直接丢弃。在动作决策前先跑一次轻量的视觉 token 评分然后只保留 Top-K 的重要 token 送给 LLM。这里 K 的选择可以动态变化如果画面里目标物体很小、分布散就多保留一些如果场景干净就只保留 1/3-1/2 的 token。我在实际项目里用这个策略后视觉 token 从 256 降到 96LLM 预填充时间直接腰斩而动作成功率只掉了 1 个点。延迟收益如此明显的原因在于预填充的时间复杂度很大程度上取决于输入的 token 数量——token 数量减少一半预填充开销大约是原来的 60% 左右。6.2 自回归的提前终止与动态步数VLA 的动作 token 序列通常是固定长度的比如总是生成 10 个 token。但如果模型结构的动作头支持概率输出一个优化的做法是引入“置信度阈值”当已经生成的动作 token 足以让动作解码器输出高置信度的控制量时剩余 token 可以直接跳过。这个思路需要改动模型的生成逻辑比较复杂我目前只在部分自研 VLA 结构上实现过。更简单但同样有效的替代方案是用一个轻量分类器判断当前 token 序列是否已经形成稳定动作触发提前终止。两步 token 加上动作头已经能推出接近最终期望的动作时裁掉后 4-5 个 token 的生成并不会影响控制效果却能省下 Decode 阶段的很大一块时间。6.3 计算图的条件分支选择推理路径更进一步可以在推理引擎层面做条件分支。比如根据视觉 token 数量动态选择不同计算图版本完整的图、中等 token 数的精简图、小 token 数的极简图。运行时根据预测结果 select 对应计算图。这要求在编译期就准备好多份图工程上稍微麻烦但可以保证动态裁剪策略和引擎的静态形状优化兼容。这实际上把 6.1 的策略和编译优化又结合了起来不是把所有 token 塞进同一张图然后把多余输入置零而是直接按实际 token 数选一条编译好的最短路径性能最优。7. 手段六缓存复算路径 —— 同一个场景下不做一个重复动作最后一个手段也是最容易被忽略的很大一部分 VLA 推理是在重复计算完全相同的输入。在机器人的操作场景里摄像头对准一个相对固定的工作区连续帧之间的差异通常非常小。如果我们能跨帧复用部分计算结果延迟优化空间就非常可观。7.1 视觉特征缓存场景不变视觉特征不变当 VLA 不是全比例在线学习场景时视觉编码器的输出即图像 token 的特征向量在场景相对稳定的情况下逐帧变化极小。如果你知道控制回路里目标物体基本不动或者只发生了轻微移动就可以直接缓存上一帧的视觉特征跳过视觉编码器的计算把原本 15%-50% 的预填充时间省掉。但是这里有一个大坑缓存过期检测。机器人操作时手会移动、物体位置会变化视觉特征缓存必须配合一个过期机制。我在项目中用的方案是计算当前帧与缓存帧的像素差异度用一个轻量的感知哈希pHash做快速比较差异超过阈值就刷新缓存。这样可以确保缓存命中时视觉特征仍然能反映真实场景。缓存视觉特征后最大的延迟收益不是视觉编码器的耗时而是预填充阶段内存带宽的释放——因为视觉 token 不再需要重新计算。7.2 提示与指令缓存VLA 模型的推理通常会拼接一条指令/提示文本比如“pick up the red cup”。如果指令不变这部分的 token embedding 也可以在会话期间缓存。这个操作非常简单很多人却一直没做——可能是觉得文本指令一两条 token 而已没什么影响但积少成多指令 token 达到 10-20 个时预填充阶段的时间占比会明显提升。配合 7.1 的视觉缓存预填充阶段甚至可以做到完全跳过视觉特征从缓存读、指令 embedding 从缓存读LLM 直接进入生成阶段。7.3 动作预测的“热点缓存”另一个缓存维度是动作决策本身。在机器人操作中如果执行的是循环往复的任务比如往返抓取会出现大量重复的动作决策。这时可以用 action cache 直接命中当视觉特征和指令都命中了缓存直接把上次的动作输出也一并返回跳过整个 LLM 生成过程。这个设计的难点是安全边际。动作缓存必须有限寿命比如 100-200ms 内有效超过后必须重新推理。同时要结合当前控制状态做校验——如果机械臂当前角度与缓存时刻差异过大动作输出必须重算。我们在桌面上料任务中测试动作缓存命中率可以达到 40%-60%整个控制链路的平均延迟下降 20% 左右。8. 组合使用与实测数据六类手段叠加的效果前面六类手段单独讲了很多但实际项目中它们必须组合使用。下面的数据来自我在一个 2B 参数 VLA 模型上的端侧部署实测平台是高通骁龙 8 Gen 3 平台端侧 AI 硬件部署的常见选择之一模型经过 INT8 量化。基线无任何优化VLA 一次完整推理约 320ms。优化手段叠加后延迟相对基线收益INT8 量化 算子融合约 168ms-47%视觉编码器放 NPU、LLM 放 CPU约 108ms-66%异步流水线 双缓冲约 82ms-74%动态视觉 token 裁剪约 63ms-80%视觉特征缓存约 45ms-86%从这个趋势可以清楚看到单靠任何一类手段都很难把延迟打下来但多类叠加后320ms 到 45ms 是完全可以做到的。其中异步流水线和动态裁剪的边际收益特别大。组合优化时也要注意副作用。我在项目里曾经同时开启动作缓存和动态 token 裁剪结果在频繁更换任务的场景中视觉特征缓存刷新不及时导致动作精度波动。最后加了“仅当目标物体偏移量小于阈值才允许命中缓存”的条件问题才解决。组合优化的原则是保证每个缓存的命中条件都足够保守宁可偶尔不命中不要命中后给出错误动作。8.1 实测中的工具链和注意事项工程落地时我建议这几件事提前准备好性能剖析工具不要手动打时间戳直接用 perfetto、TensorRT Profiler 或芯片厂商的 profiling 工具逐算子记录耗时延迟抖动分析端侧系统受 CPU 调频、GPU 抢占影响延迟分布往往不是正态分布除了 P50还要看 P95/P99稳定性测试至少跑 30 分钟连续推理观察是否因为热降频导致推理速度下降模型精度回归每次压缩或优化后都要跑一批标准动作测试集记录成功率变化最容易翻车的地方是在开发板上测得优化效果很好换到量产板子上效果缩水。原因常常是量产板的 NPU 驱动版本和开发板不一致或者 CPU 调度策略被系统服务抢占。建议在最终目标硬件上多做几轮环境验证。8.2 经验教训与避坑清单最后分享几条我踩坑后总结出的经验量化前先确认动作头的数值范围。VLA 的动作头输出的是连续值如果直接对它做均匀量化可能导致大量精度损失。先把动作范围映射到合理的浮点区间再做量化缩放动作精度能保持得更好。NPU 上跑 VLA 的注意力层要特别注意数值溢出。很多 NPU 的定点数范围有限注意力分数经过 softmax 后如果再乘上 V 矩阵容易出现中间结果溢出。处理方式是在计算图中手动插入一个缩放层。动态裁剪不是免费的。增加一个注意力得分评分器本身也有少量计算开销在输入帧极小时比如 token 数只有 30-40评分器的开销可能超过裁剪的收益。需要对小输入做阈值保护。缓存策略要配合安全机制。这是最重要的一条任何形式的缓存命中都必须能被用户命令或传感器异常信号强制旁路。机器人系统的安全优先级永远高于推理性能宁可慢不能错。写在最后VLA 端侧部署的延迟优化本质上是一场“计算拆解”的攻坚战。从模型压缩到编译优化再到异构调度、异步流水线、动态控制和缓存复算六类手段各有侧重点又互相牵连。我个人的体会是不要指望某一招能一步到位真正可靠的是先搭建一个延迟分析框架把每一类手段的收益量化出来再按延迟目标的差距逐项补齐。每做完一个优化就回到实际控制循环里跑一遍看看端到端的动作效果是否真的改善。毕竟延迟数字漂亮不算成功机械臂能稳、准、快地完成动作才算落地。