端侧 AI Infra：VLM 推理优化与软硬件协同

在机器人、自动驾驶和无人机系统中，多模态模型的价值不只取决于回答是否准确，还取决于它能否在规定时间内稳定地产生动作。一个模型即使离线评测很好，如果首 Token 延迟过高、设备持续运行后降频，或者一次异常会沿着规划链路扩散，仍然很难成为可用的产品能力。

端侧 AI Infra 的核心工作，就是把模型、运行时、芯片、数据搬运和业务安全约束放到同一个系统里分析。本文以一次面向端侧推理的技术分享为基础，整理一套可迁移的分析框架；其中的时间和收益数字是典型示例，不能直接视为所有硬件和模型的固定结论。

一、先定义目标：端到端时延，而不是单点速度

机器人控制通常以固定频率接收和处理输入。假设系统需要以 10 Hz 工作，那么从图像采集、预处理、模型推理到动作下发的端到端时间就需要控制在约 100 毫秒以内。更高频的控制回路还会提出更严格的要求。

一次 VLM 请求可以拆成：

flowchart LR
    A[图像与指令输入] --> B[图像采集与预处理]
    B --> C[Vision Encoder]
    C --> D[Projector]
    D --> E[LLM Prefill]
    E --> F[Decode]
    F --> G[后处理与类别映射]
    G --> H[规划与动作下发]

在未充分优化的系统中，视觉编码、Prefill、数据搬运和后处理都可能成为瓶颈。不能只看到某个算子加速了 40%，就直接认为端到端也提升了 40%。如果该算子只占总耗时的 20%，系统整体收益可能只有几个百分点。

因此第一步永远是建立基线：记录输入分辨率、视觉 Token 数、Prefill 和 Decode 时间、峰值内存、设备温度、频率、吞吐、错误率以及不同场景下的精度。

二、VLM 的瓶颈与纯文本 LLM 不同

纯文本 LLM 的输入 Token 数通常相对可控，优化重点经常落在 Decode、KV Cache 管理、投机解码和批处理上。VLM 则多了一段视觉输入链路：图像需要被切分成 Patch，经 Vision Encoder 提取特征，再由 Projector 映射到语言模型能够处理的表示空间。

一张图片可能对应数百甚至上千个视觉 Token，而用户指令只有几个到几十个文本 Token。因此在 VLM 中，输入侧的视觉编码和 Prefill 往往比 Decode 更值得优先优化：

• 图像分辨率越高，视觉 Token 通常越多；
• 视觉 Token 越多，Encoder 和 Prefill 的计算与显存访问压力越大；
• 端侧设备还要承担图像格式转换、内存复制和 CPU/NPU/GPU 之间的数据传输；
• 文本侧已经很短时，继续优化文本 Token 的收益通常有限。

这也是为什么不能把纯 LLM 的优化方案原样搬到多模态模型上。相同的模型结构，在不同输入模态下，时间分布可能完全不同。

三、五类常见优化：收益和代价必须一起评估

1. 视觉 Token 裁剪与稀疏化

最直接的思路是去掉与当前任务关系较弱的背景 Token，只保留与问题相关的区域。常见路线包括：

• 固定池化或卷积降采样；
• 基于余弦相似度等指标合并相似 Token；
• 根据 Attention 分数筛选 Token；
• 根据当前 Query 选择与问题相关的视觉区域；
• 使用额外的小模型预测应该保留哪些 Token。

固定池化简单、容易部署，但压缩比例不够灵活；相似度方法不需要额外训练，工程落地相对直接，但复杂场景下可能误删小目标；Attention 或 Query 驱动的方法通常更精细，却增加了计算和算子开发成本。

实际系统不应盲目追求极限压缩。保留一定冗余，换取跨场景鲁棒性，通常比在少量样例上把 Token 压到极低更可靠。小目标、文字和安全相关区域尤其需要独立评估。

2. 跨帧 KV Cache 复用

机器人和车辆接收的是连续视频帧，相邻帧往往只有局部区域发生变化。如果每一帧都从头进行视觉编码和 Prefill，会重复计算大量相同信息。

可以先判断相邻帧的相似程度：静态区域直接复用，变化区域重新计算，或者在相似度达到阈值时跳过部分视觉处理。该方法在慢速、静态场景中通常更有价值；快速运动、镜头切换和遮挡严重的场景则可能收益有限。

它的关键不是“永远复用上一帧”，而是建立可靠的变化检测、失效条件和回退机制。错误复用会把上一帧的错误状态带入当前决策，安全系统必须允许快速重新计算。

3. 量化：同时看计算、带宽和精度

量化把高位宽表示转换成更低位宽表示，减少模型权重、激活或中间结果的存储和搬运成本。端侧场景常见的方向包括 INT8、INT4 以及混合精度方案。

量化收益不一定来自算力本身，也可能主要来自：

• 权重和激活占用更少内存；
• DRAM 与加速器之间的数据搬运量减少；
• 量化算子更适配目标 NPU/GPU；
• 峰值内存下降后，可以容纳更长上下文或更多并发。

视觉 Encoder 位于输入侧，过早做激进压缩容易损失关键视觉信息；语言模型的权重和激活则可以按层、按模块采用不同精度。哪些层可以量化、哪些层需要保留更高精度，必须由目标任务的精度和安全约束决定。

工程上还要区分 PTQ 和 QAT：前者改造成本较低，但可能带来精度下降；后者在训练阶段模拟量化误差，通常更容易恢复精度，却需要算法团队重新参与训练。

4. 异构切分

端侧芯片通常同时包含 CPU、GPU、NPU、内存和专用加速单元。可以把更适合矩阵计算的视觉编码放到 NPU，把显存和带宽需求更高的语言模型放到 GPU，或者将 Prefill 与 Decode 放到不同执行单元。

理想情况下，视觉编码和语言模型可以并行执行：

sequenceDiagram
    participant CPU as CPU调度
    participant NPU as NPU
    participant GPU as GPU
    CPU->>NPU: 提交图像编码
    CPU->>GPU: 准备文本与缓存
    NPU-->>CPU: 返回视觉特征
    CPU->>GPU: 传入视觉特征
    GPU-->>CPU: 返回模型输出
    CPU->>CPU: 后处理与动作下发

但异构切分会引入数据搬运、同步和格式转换成本。如果并行节省 40 毫秒，却因为跨设备搬运增加 50 毫秒，端到端结果反而会变差。量化、内存布局、流水线和异步队列应该联合设计，而不是分别优化。

5. 流水线并行

流水线可以让下一帧在前一帧的后续阶段执行时提前进入前处理或视觉编码阶段，减少设备空闲时间。它首先改善的是吞吐，而不一定降低单帧端到端延迟。

需要区分两个指标：

• 延迟：单个输入从开始到完成需要多久；
• 吞吐：单位时间能够处理多少帧或多少个动作。

自动驾驶、机器人高速分拣等场景可能同时关心两者。流水线设计还要考虑队列堆积、帧过期、取消和异常恢复，否则吞吐提高后反而会把旧帧动作发送到当前场景。

四、端侧部署中的隐藏瓶颈：数据搬运和热稳定性

很多模型实验只测 GPU 或 NPU 的 kernel 时间，上板之后才发现图像搬运和格式转换占据了大量时间。典型链路可能是：

flowchart TD
    A[摄像头帧] --> B[CPU图像预处理]
    B --> C[DRAM]
    C --> D[NPU视觉编码]
    D --> E[中间特征搬运]
    E --> F[GPU或NPU语言模型]
    F --> G[CPU后处理]
    G --> H[控制模块]

因此需要在 profiling 中同时观察计算时间、内存带宽、复制次数、同步点和队列等待时间。减少一次复制、改进内存复用、采用异步流水和降低中间特征位宽，有时比继续优化一个已经很快的算子更有价值。

稳定性也不能等到上线后再补。端侧设备长时间运行可能因温度上升而降频，导致原本满足要求的模型逐渐超时。系统应持续监控温度、频率、功耗、帧率、超时和异常输出，并准备降级策略，例如切换到轻量模型、降低输入分辨率或回退到传统控制网络。

五、为什么需要“快系统 + 慢系统”

复杂模型在端侧不一定能够承担每一个高频控制回路。机器人和自动驾驶系统常见的架构是：

• 快系统负责低延迟、重复性高、可验证的基础动作；
• 慢系统使用 VLM 或更大的模型处理复杂场景理解和高阶决策；
• 中间层把高阶意图转成可执行的策略；
• 底层控制模块保证动作安全和稳定。

flowchart TB
    A[传感器与用户指令] --> B[快系统：高频感知与控制]
    A --> C[慢系统：复杂场景理解]
    C --> D[高阶意图与轨迹]
    D --> E[策略层校验]
    B --> E
    E --> F[底层控制与安全兜底]

端云协同也是类似思路：端侧承担实时反馈、隐私和断网兜底，云侧承担更复杂的推理、训练和数据分析。随着端侧芯片算力提升，更多模型会向端侧迁移，但这并不意味着云侧失去价值，而是系统边界会持续重新划分。

六、把端侧推理项目讲清楚

一个有说服力的项目复盘，不是罗列“用了量化、剪枝和异构部署”，而是回答以下问题：

1. 原始 Baseline 是什么，输入和硬件条件是什么？
2. 通过 profiling 找到的最大瓶颈是什么？
3. 为什么选择 Token 裁剪、量化或异构切分，而不是其他方案？
4. 优化前后的延迟、吞吐、内存和功耗如何变化？
5. 精度下降发生在哪些类别或场景，业务是否可以接受？
6. 目标芯片的工具链有哪些限制，哪些算子无法下沉？
7. 长时间运行是否降频，异常输出如何检测和恢复？
8. 方案的适用边界是什么，下一步还要验证什么？

这套表达方式比单独强调一个加速百分比更接近真实工程，也能体现从模型到硬件、从实验到系统的完整思维。

结语

端侧 AI Infra 的核心不是把一个模型“跑起来”，而是让它在真实设备、真实数据和真实约束下持续稳定地工作。有效的优化通常遵循这样的顺序：

建立端到端基线 → 拆解时间和资源 → 优先处理最大瓶颈 → 同时评估精度与稳定性 → 做软硬件协同 → 用真实场景回归验证。

对于学习者而言，不必一开始就拥有机器人或自动驾驶硬件。单卡 GPU 也可以先完成模型部署、Token 压缩、量化、profiling 和流水线实验。关键是保留完整的测量、对照和复盘证据，而不是只展示一个看起来漂亮的结果。