Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

10.4.1 模型压缩与蒸馏(distillation)

学习导航

  • 本章主题:10.4.1 模型压缩与蒸馏(distillation)
  • 前置知识:建议先完成第 8-9 章训练相关内容。
  • 建议用时:59-79 分钟
  • 阅读顺序:先看概念框架,再看公式/代码,最后做自测。

在前面章节中,我们更多讨论了“怎么让 VLA 变强”;本节开始讨论另一面:怎么让它变“轻”、变“快”,但不变“傻”。模型压缩与知识蒸馏是目前在大模型落地中最成熟的一类技术路径。(MDPI)


10.4.1.1 压缩必要性

VLA 模型通常同时包含视觉 backbone、语言 backbone 和动作解码器三部分,很多工作使用数十亿参数量级的 Transformer 作为核心,例如 7B 规模的 OpenVLA、以及更大的 RT-2 系列。(arXiv) 这类模型在训练时可以依赖数据中心 GPU 集群,但在真实机器人上部署,就会遇到几个非常现实的问题:

+算力与能耗限制:移动机器人、机械臂控制箱上常见的是 Jetson、Coral TPU、嵌入式 CPU+小 GPU 等边缘设备,其功耗和峰值算力远低于服务器级 GPU。(ThinkRobotics.com) +时延约束:具身智能强调“感知–决策–控制”的闭环,闭环延迟需要控制在几十毫秒到百毫秒以内,否则机器人看到的永远是“过去的世界”,容易动作滞后甚至撞人。(MDPI) +存储与内存瓶颈:一个 7B 级别全精度模型单权重就需要数十 GB 存储,更不要说中间激活占用,对 8 GB~16 GB 内存的嵌入式平台来说几乎是灾难。(MDPI) +系统级共享资源:机器人还要运行 SLAM、运动规划、传感器驱动等模块,VLA 只是其中一员,不能“独占”全部资源。

综上,对于部署在机器人端的 VLA 来说,参数量、计算量和带宽都是必须正面面对的工程约束。模型压缩的目标,就是在尽量保持任务性能的前提下,系统性地降低模型复杂度。主流压缩手段可以概括为:剪枝(Pruning)、量化(Quantization)、低秩分解(Low-Rank Decomposition)、结构化轻量设计和知识蒸馏(Knowledge Distillation)。(SSRN)

【图 10-4-1 占位:绘制“模型大小–推理延迟–任务成功率”三者关系的示意图,展示压缩之后延迟明显下降,但成功率只略有下降的趋势曲线。】

在 VLA 场景下,知识蒸馏尤为重要,因为它不仅能“压缩参数”,更能“迁移大模型中已经学到的多模态知识和策略”,这是下一小节要重点展开的内容。(ACM Digital Library)


10.4.1.2 蒸馏方法

**知识蒸馏(Knowledge Distillation)**的典型形式是:用一个性能更强、规模更大的“教师模型(Teacher)”,去指导一个更小、更轻量的“学生模型(Student)”学习。学生不仅学习标注数据上的“正确答案”,还学习教师模型对各类候选答案的“偏好分布”,从而在小规模参数下尽量接近大模型性能。(ACM Digital Library)

从“学什么”的角度,常见蒸馏知识类型可以分为三类:(ACM Digital Library)

1.响应级(Response-based)蒸馏

  • 直接对齐教师和学生的输出分布,例如分类任务中的 softmax 概率、VLA 中动作 token 的概率分布。
  • 通常使用带温度的 KL 散度或交叉熵作为蒸馏损失,使学生模仿教师的“软标签”,而不是仅仅拟合 one-hot 的硬标签。 2.特征级(Feature-based)蒸馏
  • 对齐中间层特征,如视觉 encoder 最后一层的特征图、融合后的多模态表示、动作解码器中间隐藏状态等。
  • 通过 L2 损失、注意力矩阵对齐等方式,使学生在内部表征空间上接近教师,有利于迁移高层语义与多模态对齐能力。 3.关系级(Relation-based)蒸馏
  • 不直接约束特征本身,而约束样本之间、模态之间的关系,例如特征相似度矩阵、注意力图、token 间的相对关系等。
  • 对于 VLA 来说,可以蒸馏“视觉 token 与语言 token 之间的相关性模式”,帮助学生学会在图像和指令之间建立类似的注意力结构。

在机器人 VLA 场景中,还经常会用到两类“面向策略”的蒸馏变体:

+策略蒸馏(Policy Distillation):教师可以是一个使用 RL/IL 训练出来的高性能策略,学生学习在同样的状态输入下输出接近的动作分布,用于把多个任务或多个机器人上的策略压缩到一个统一学生模型中。 +多模态联合蒸馏:同时对视觉编码器、语言编码器和动作解码部分进行蒸馏,例如在视觉、语言和动作三个通道都加入蒸馏损失,保证学生不仅“会做”,还“看得懂、听得懂”。

【图 10-4-2 占位:教师–学生结构示意图。左侧为大 VLA,右侧为小 VLA,标注“输出蒸馏”“中间特征蒸馏”“注意力关系蒸馏”等不同连线。】


10.4.1.3 蒸馏过程

从工程视角出发,可以把一个 VLA 的蒸馏工程拆解为几个明确步骤:

1.确定教师模型与学生模型架构

  • 教师模型通常是已经在大规模数据上训练好的通用 VLA,例如一个 7B 级 OpenVLA 或更大的 RT-2 风格模型。(arXiv)
  • 学生模型采用更小的隐藏维度、更少的层数、更窄的多头注意力,甚至采用专门为嵌入式设计的轻量结构(如 MobileNet 样式视觉 encoder + 小型 Transformer 解码器)。 2.构建蒸馏数据集 +离线蒸馏:在已有的机器人示教数据(图像、语言指令、动作轨迹)上,额外调用教师模型生成输出分布和中间特征,作为蒸馏监督。 +在线/交互式蒸馏:在仿真环境中让教师与环境交互,教师执行策略、学生在旁“抄作业”;甚至可以采用多次 rollout,不断扩充训练集。 3.设计损失函数与权重 通常会将“任务损失”和“蒸馏损失”进行加权组合:

\[ L = \lambda_{\text{task}} L_{\text{task}} + \lambda_{\text{distill}} L_{\text{distill}} \]

  • \(L_{\text{task}}\):来自真实标签的监督损失,如动作 token 的交叉熵、任务成功/失败的 BCE 等。
  • \(L_{\text{distill}}\):包括输出分布的 KL 散度、特征对齐的 L2 损失、注意力矩阵对齐等。
  • 温度参数 \(\displaystyle T\) 通常会用来“软化”教师输出,让学生更容易学习类别或动作之间的细微偏好差异。(ACM Digital Library) 4.训练流程与策略
  • 先在蒸馏数据上进行若干轮“纯蒸馏训练”,使学生快速对齐教师的整体行为。
  • 再加入小批量真实环境数据或额外 BC/RL 微调,以防学生只会模仿教师的习惯,而无法适应真实机器人噪声和物理细节。
  • 若目标是量化部署(见 10.4.2),可直接在蒸馏过程中采用低精度学生模型(如 int8 仿真),进行“量化感知蒸馏”,让学生一开始就适应量化带来的噪声。(ResearchGate) 5.评估与安全验证
  • 在标准基准(如 VLA Bench 或实验室自建任务集)上对比教师与学生的任务成功率、泛化能力、失误类型。(CVF开放获取)
  • 在真实机器人上逐步“放权”:先低速、单任务、无人体场景测试,再逐步增加复杂度,确认蒸馏过程中没有引入危险行为或异常策略。

【图 10-4-3 占位:蒸馏流程时序图,从“数据采集/仿真 -> 教师打标签 -> 学生训练 -> 部署验证”的流程图。】

蒸馏在本章后面会与量化、边缘部署结合,构成“小模型 VLA”的主力技术路线,为机器人提供可负担的智能大脑。


10.4.2 Quantization(量化)与推理效率优化

如果说蒸馏是“换一个更小的脑袋”,那么量化就是“用更节省的数字来存储和运算同一个脑袋”。在当前软硬件生态下,量化几乎是所有边缘部署流水线的标配。(NVIDIA Developer)


10.4.2.1 模型量化

**模型量化(Model Quantization)**指的是将模型中的权重和激活从高精度的浮点数(如 FP32)映射为低比特表示(如 FP16、INT8,甚至 4 bit),从而大幅降低存储和计算成本:(MDPI)

+存储节省:从 FP32 到 INT8,理论上权重存储可减为原来的 1/4,意味着在相同显存/内存条件下可以加载更大的模型,或者运行更多模型。 +计算加速:许多边缘硬件(如 Jetson Tensor Cores、Edge TPU)对低精度整数矩阵乘法做了专门优化,INT8 运算吞吐远高于 FP32。(NVIDIA Developer Forums) +带宽降低:更短的表示意味着从内存到计算单元的数据传输压力减轻,有助于提高整体吞吐。

量化本质上是在一个有限整数区间(如 \(([-128, 127])\))上,用一个线性比例因子(scale)和零点(zero-point)去近似原始的浮点范围。不同层、不同张量可以有不同的 scale/zero-point,以减小量化误差。(Hugging Face)

【图 10-4-4 占位:示意一维浮点分布被线性映射到 INT8 离散格点的示意图,标出 scale 与 zero-point。】

对于 VLA 这类 Transformer 模型,量化时还要考虑:

  • Embedding 层、输出 logits 层、LayerNorm 参数等通常更敏感,往往保留在 FP16/BF16,而对大部分线性层、注意力投影层做 INT8 量化,形成**混合精度(Mixed-Precision)**方案。(NVIDIA Developer)
  • 对视觉 backbone(CNN/ViT)则更容易采用静态 INT8 量化,因为特征分布相对稳定,硬件支持也更成熟。

10.4.2.2 量化方法

从“在训练流程中的位置”看,常用的量化策略可以分为三大类:(Hugging Face)

1.训练后量化(Post-Training Quantization, PTQ) 不再重新训练模型,只在训练完成的 FP32/FP16 模型基础上进行转换。 +动态量化(Dynamic Quantization) + 典型用法:权重在离线阶段量化为 INT8,激活在运行时根据当前 batch 的实际取值动态计算量化参数。 + 优点:不需要额外的“校准(calibration)”数据,适合 Transformer 和 RNN 等序列模型。(onnxruntime.ai) +静态量化(Static Quantization) + 在转换阶段使用一个小的代表性数据集,通过若干次前向推理统计各层激活的 min/max 或直方图分布,离线确定量化区间。 + 推理时权重和激活都使用固定的 INT8 区间,适合 CNN 和视觉 backbone,可获得更好的推理加速。(Google AI for Developers) 2.量化感知训练(Quantization-Aware Training, QAT) 当简单的 PTQ 带来的精度下降无法接受时,可以在训练阶段“模拟量化”:

  • 在前向中插入“假量化(fake quantization)”算子,把权重和激活“截断”为低比特表示,在反向传播时仍使用高精度更新。
  • 通过这种方式,模型在训练中逐渐适应量化噪声,最终在真实 INT8/INT4 部署时精度损失更小。(datature.com)
  • 对 VLA 这种长序列 Transformer,QAT 成本较高,但在关键组件(如动作解码器)上进行局部 QAT,往往能取得不错的折中。 3.混合精度与分层量化
  • 在 GPU 上常见的 FP16/BF16 + FP32 混合精度,本质上也是一种量化形式,只不过比特数仍然较高。(NVIDIA Developer)
  • 在更激进的方案里,可以对不同层使用不同 bit-width(如主干 INT8,部分线性层 INT4),甚至结合蒸馏,让低比特学生从高精度教师中学习对量化噪声不敏感的表示。

在工程实践中,一个较为稳妥的路线是:先做 FP16 混合精度 + 图优化,如果仍无法满足实时性,再尝试 INT8 PTQ,最后针对关键模块上 QAT 或更低比特。


10.4.2.3 推理优化

量化只是“瘦身”的一部分,要真正达到实时控制的要求,还需要一整套**推理优化(Inference Optimization)**手段,从模型图到系统调度都要动手术。(onnxruntime.ai)

1.图级与算子级优化

  • 利用 TensorRT、ONNX Runtime、TVM 等工具进行图优化:算子融合(如 Conv+BN+ReLU)、常量折叠、消除冗余分支等。(onnxruntime.ai)
  • 针对特定硬件选择高效 kernel,例如在 Jetson 上启用 Tensor Cores 的 FP16/INT8 kernel,在 Edge TPU 上使用 TFLite 编译器生成专用计算图。(NVIDIA Developer Forums) 2.输入输出与批处理策略
  • 机器人控制多为 batch=1 的在线模式,但同一时刻可以并行处理多路传感或多步规划,需合理设计异步队列。
  • 适当降低图像分辨率、缩短语言上下文长度、限制历史轨迹长度,都可以有效减小 VLA 的序列长度和计算量。 3.系统级调度与并行
  • 将视觉预处理、VLA 推理和低层控制放在不同线程/进程,用共享内存或零拷贝(zero-copy)减少数据复制开销。
  • 使用优先级队列,对时延敏感的控制循环(例如避障)给予更高优先级,大模型推理则在后台或较低频率运行。(MDPI) 4.缓存与重用
  • 对语言指令等不变部分,可以预先编码缓存,仅对每一帧变化的视觉和状态信息重新计算。
  • 对长 horizon 任务,可采用增量注意力缓存(KV cache),在每一步仅对新 token 做注意力计算,减少平方级开销(具体细节可回顾 Transformer 部分的复杂度分析)。

【图 10-4-5 占位:机器人系统推理流水线示意图,从“相机帧 -> 预处理 -> VLA 推理 -> 控制命令”,标注在哪些位置做量化、在哪些位置使用推理引擎优化。】

通过“蒸馏 + 量化 + 推理优化”三板斧,往往可以把一个原本只能在服务器跑的 VLA,压缩到可以在 Jetson 级别硬件上达到 10 Hz 以上的闭环频率,为后面的边缘部署打下基础。(MDPI)


10.4.3 边缘设备上的部署实践要点

前两小节更多聚焦于“模型本身怎么变小、变快”,这一节转到系统工程视角:在真实边缘硬件上,如何把一个 VLA 模型稳稳当当地跑起来


10.4.3.1 硬件选型

边缘部署的硬件选型,本质上是在性能、功耗、成本、开发便利性之间做多目标折中。可以粗略分为以下几类:(ThinkRobotics.com)

1.嵌入式 GPU 平台(如 NVIDIA Jetson 系列)

  • 优点:CUDA 生态成熟、TensorRT 支持良好,适合运行 CNN、Transformer、VLM/VLA 等通用深度模型。
  • 典型应用:中高性能移动机器人、机械臂控制柜。(Ultralytics Docs) 2.专用 NPU / Edge TPU 加速器(如 Google Coral TPU)
  • 优点:功耗极低、对 INT8 推理高度优化,适合部署压缩后的 CNN/VLM 和小型 VLA。(ResearchGate)
  • 不足:模型需转换为特定格式(如 TFLite),对模型结构限制较多(不支持某些算子或动态控制流)。 3.CPU + 小 GPU / VPU 组合
  • 如树莓派 + USB 加速器(Movidius NCS 等),适用于简化版本政策或只在云端运行大模型、边缘执行轻量策略的场景。 4.FPGA / 定制 ASIC
  • 对大规模量产、极致能效的商用机器人有吸引力,但开发成本高、迭代慢,目前更偏向产业界工程化方案。

对于具身智能研究者来说,常见实践路线是:实验阶段用桌面 GPU,原型部署用 Jetson,极低功耗产品再考虑 NPU/TPU/FPGA。在选型时要结合上一节的压缩方案估算:目标模型在目标硬件上的推理时延、峰值内存占用和长期散热能力

【图 10-4-6 占位:表格形式对比 Jetson、Coral TPU、CPU+GPU 方案的算力(TOPS)、功耗、生态支持等参数。】


10.4.3.2 内存管理

即使选对了硬件,如果内存管理不到位,VLA 也可能在关键时刻因为 OOM(Out of Memory)直接崩溃。以下是边缘部署时需要重点关注的方面:(onnxruntime.ai)

1.预算与分析

  • 将运行时内存拆解为:模型权重(常驻)、中间激活(临时)、输入输出缓存、系统与其他进程占用。
  • 使用框架提供的 profile 工具(如 TensorRT profiler、onnxruntime profiling)测真实峰值,而不是仅凭理论估算。 2.控制模型内存占用
  • 利用前面介绍的量化减小权重体积,选择合适的最大序列长度(图像 patch 数、语言 token 数、历史步数)。
  • 对视觉 backbone,减少特征通道数、采用分辨率自适应(近处高分辨率、远处低分辨率)策略。 3.运行时内存复用与分配策略
  • 启用框架的内存池/缓存机制,避免频繁 malloc/free 带来的碎片化。
  • 定期监控内存碎片率,在多次加载/卸载模型的场景中考虑进程级重启或使用“模型常驻 + 动态配置”架构。 4.多进程/多节点协同
  • 对于计算负载较大的视觉和 VLA,可以单独放在一个“推理节点”中,通过 ROS topic / RPC 接口服务其他模块,清晰隔离内存与错误边界。

10.4.3.3 运行监控

任何长期在线的机器人系统,都必须具备一定程度的运行监控与自诊断能力,否则一旦模型在部署后出现性能衰退或异常行为,很难定位问题。(MDPI)

监控主要包括三个层面:

1.资源层监控

  • CPU/GPU/NPU 利用率、内存/显存占用、设备温度、电池电量与电流等。
  • 典型工具:Jetson 上的 tegrastats、Linux 上的 top/htop、厂家提供的 SDK API。 2.性能指标监控
  • 每次 VLA 推理的时延分布(平均值、P95、P99)、吞吐(每秒处理的观测步数)。
  • 离线评测到的任务成功率与在线实际成功率的差异,用于监控“性能漂移”。 3.行为与安全监控
  • 记录发生紧急停止、碰撞检测触发、动作超限的次数和上下文数据(视觉帧、状态、指令)。
  • 建立简单的异常检测规则,如在短时间内连续多次发生动作规划失败或传感器异常,触发退避策略或人工介入。

【图 10-4-7 占位:一个简单监控面板示意图,包含 CPU/GPU 利用率、推理时延曲线、任务成功率趋势以及安全事件计数。】

在有了这套监控基础之后,团队才能在后续迭代中量化地评估不同压缩策略、不同硬件平台对整体系统行为的影响,而不是依靠主观体验。


10.4.4 小模型 VLA 与大模型 VLA 的协同(如规划–执行分离)

随着 OpenVLA、RT-2 等大型 VLA 的出现,一个现实问题是:这些模型很强,但不一定适合直接“塞进”机器人里。越来越多的系统开始采用“小模型 + 大模型”的协同架构,将规划与执行、推理与控制分层。(维基百科)


10.4.4.1 分级规划执行

一种自然的架构是**“大模型做高层规划,小模型做低层执行”**:

+大模型 VLA / VLM + LLM(云端或高性能本地工作站)

  • 负责理解复杂自然语言任务、检索世界知识、推理长时序计划(例如完成一个“整理房间”的多步骤任务)。
  • 可以基于互联网上的大规模图文数据和机器人数据进行训练,具有更强的泛化和推理能力,例如 RT-2 将 web 视觉–语言知识迁移到机器人动作中。(arXiv) +小模型 VLA(部署在机器人本体)
  • 负责将高层计划分解为连续的控制动作,如抓取、放置、移动、避障等,在几十 Hz 的频率下闭环控制。
  • 通过前文介绍的蒸馏与压缩,从大模型继承视觉–语言–动作对齐能力,但参数量和延迟显著下降。

具体流程上,大模型输出的可以是:

  • 语言化的分步指令(如“先把红色杯子放到桌子右侧,再关灯”);
  • 结构化的任务图(task graph),包含一系列子任务、先后约束与条件分支;
  • 关键子目标(sub-goals),如中间位姿、关键物体状态(“杯子在架子上”“杯子在桌上”)。

小模型 VLA 则在每个子任务内,通过自身感知与控制实现局部闭环。这样,大模型只需低频运行(例如 0.1–1 Hz 做一次整体再规划),而小模型负责高频反馈控制。

【图 10-4-8 占位:层级架构图,上层“大模型”接收人类语言指令并输出子任务序列,下层“小模型 VLA”连接机器人,执行每个子任务。】


10.4.4.2 信息传递

大小模型之间的信息传递形式,直接决定了系统的灵活性与工程复杂度。常见的几种接口设计包括:

1.以语言为接口

  • 大模型输出自然语言或受限模板语言(如 DSL),小模型再对其进行解析。
  • 优点是通用性强、易于人类 debugging;缺点是需要保证小模型对语言的解析鲁棒性。 2.以符号 / 结构化状态为接口
  • 大模型输出结构化的任务描述,如 JSON 形式的 {"action": "pick", "object": "red_mug", "target": "table_right"}
  • 小模型根据这些参数在自己的感知空间中查找对应目标(如在图像中找 red_mug),并规划动作。 3.以高维嵌入 / 潜变量为接口
  • 大模型输出某种“目标嵌入”(goal embedding),小模型通过训练好的策略将当前状态推向这个目标嵌入。
  • 这种方式更接近端到端学习,但可解释性较弱,多用于研究型系统。

信息传递还涉及反馈通道

  • 小模型需要向大模型汇报子任务执行状态(成功/失败、耗时、遇到的障碍),大模型据此更新整体计划。
  • 为了降低带宽与隐私风险,通常不会传输原始视频帧,而是传输压缩后的特征、关键检测结果或语言化的场景描述。(MDPI)

10.4.4.3 优势互补

“小模型 VLA + 大模型 VLA”的协同,本质上是对单一大模型直接部署的现实折中,它带来的优势包括:

+性能与资源的分工

  • 大模型负责认知层面的“想”(理解复杂指令、做长程规划);
  • 小模型负责控制层面的“做”(考虑传感噪声、动力学约束、实时安全)。 +在线学习与自适应的空间
  • 小模型可以在部署过程中通过少量在线数据微调(例如适应新的照明环境或新机器人),而大模型保持相对稳定,避免每次环境变化都要大规模重训。 +安全与可靠性
  • 在网络中断或大模型不可用时,小模型仍可执行基础技能(如紧急制动、保持静止、简单避障)。
  • 规划–执行分离也便于在执行层加入更多物理安全约束和形式化验证,而不必对整个巨型大模型做不可行的形式验证。

【图 10-4-9 占位:比较单一大 VLA 与“大+小”协同架构的示意图,展示在性能、时延和安全性三方面的对比雷达图。】

在长期发展视角下,随着硬件继续进步,未来某些机器人平台可能直接搭载中大型 VLA;但在可预见的一段时间内,“云端/服务器大模型 + 端侧小模型”会是非常现实、工程上可行的一条路径。本节介绍的蒸馏、量化、边缘部署与协同架构,也构成了从“VLA 论文”走向“VLA 产品”的关键工程桥梁。

本章小结与自测

三行小结

  1. 本章面向部署与评测,关注系统级约束。
  2. 重点是延迟、安全与鲁棒性设计。
  3. 学完后应能写出可执行的评测协议。

检查题

  1. 用你自己的话总结本章最核心的一个公式/机制。
  2. 给出一个“如果要落地到项目里,你会怎么用”的具体例子。

常见误区

  1. 离线评测通过就直接上机。
  2. 缺少异常回退路径。
  3. 忽略部署时延预算。

公式到代码(最小示例)

runs = [
    {"success": 1, "latency_ms": 82},
    {"success": 0, "latency_ms": 95},
    {"success": 1, "latency_ms": 76},
]
sr = sum(r["success"] for r in runs) / len(runs)
lat = sum(r["latency_ms"] for r in runs) / len(runs)
print({"success_rate": round(sr, 3), "avg_latency": round(lat, 1)})

本章外部参考(集中)

  1. MDPI
  2. arXiv
  3. ThinkRobotics.com
  4. MDPI
  5. SSRN
  6. ACM Digital Library
  7. ResearchGate
  8. CVF开放获取
  9. NVIDIA Developer
  10. NVIDIA Developer Forums
  11. Hugging Face
  12. onnxruntime.ai
  13. 本章其余链接可在正文中按上下文继续查阅。