EfficientNav: Towards On-Device Object-Goal Navigation with Navigation Map Caching and Retrieval¶
会议: NeurIPS 2025
arXiv: 2510.18546
代码: GitHub
领域: 机器人 / 导航 / 端侧部署
关键词: object-goal navigation, on-device LLM, KV cache优化, zero-shot导航, 边缘部署
一句话总结¶
通过离散内存缓存（KV cache分组独立计算+选择性加载）、注意力驱动聚类（LLM浅层attention指导分组）和语义感知检索（CLIP+背包问题适配不同内存预算），首次在Jetson Orin上用LLaMA-3.2-11b实现零样本ObjNav，比GPT-4基线提升11.1% SR且实时延迟降低6.7×。
研究背景与动机¶
- 领域现状: LLM驱动的零样本目标导航（ObjNav）已成主流——LLM作规划器，利用图导航地图的语义/空间信息决定子目标。但严重依赖GPT-4等云端大模型
- 云端部署问题: 通信延迟破坏实时性、隐私风险、计算成本极高——需要从云端迁移到端侧
- 端侧内存瓶颈: Jetson Orin仅32GB DRAM，模型权重+导航地图KV cache→随探索步数增长KV cache溢出。重算KV cache引入巨大prefilling延迟
- 小模型能力瓶颈: 直接用LLaMA-11b替代GPT-4，成功率显著下降。实验发现：随导航步数增加，小模型对正确子目标的注意力分数持续下降——无法从复杂冗余地图中聚焦关键信息
- 关键观察: 导航地图存在大量冗余；不同目标只需关注地图的不同子集；语义相关物体（oven和pot）应该聚在一起
- 核心idea: 三层优化——(1)分组计算KV cache实现选择性加载（解耦cache与顺序）；(2)用LLM注意力指导分组确保语义一致性；(3)CLIP驱动的语义检索+背包问题适配内存预算
方法详解¶
整体框架¶
RGB-D → Grounding DINO检测 → 图导航地图 → {离散缓存+注意力聚类+语义检索} → LLM规划器选择子目标 → 低层控制器导航
关键设计¶
- 离散内存缓存 (Discrete Memory Caching):
- 做什么: 将地图中的对象分组，每组独立计算KV cache，规划时仅选择部分组加载
- 核心思路: 分组独立计算→KV cache与组顺序解耦→选择不同组子集时可直接复用已缓存的KV cache。新检测对象追加到组尾部（因果注意力保证正确性），不改变已有cache。一次性加载选中组的cache到设备内存，避免解码过程中的频繁cache搬运
-
设计动机: 整体KV cache无法存入设备内存；重算太慢；频繁搬运延迟高——分组+选择性加载三管齐下
-
注意力驱动聚类 (Attention-based Memory Clustering):
- 做什么: 用LLM自身的浅层注意力权重指导物体分组
- 核心思路: 新检测物体送入LLM前1/10层，计算与已有组的平均注意力。超过阈值→归入已有组；否则→创建新组。语义相关物体（oven/pot）聚到一起，组内交叉注意力保留了语义关系
-
设计动机: 均匀分块忽略物体间语义关系；分组粒度太粗→KV cache大→可选组少→可能丢失关键信息。注意力驱动的自适应分组兼顾精度和粒度
-
语义感知检索 (Semantics-aware Memory Retrieval):
- 做什么: 根据当前目标动态选择相关组，裁剪冗余信息帮助小模型聚焦
- 核心思路: 用CLIP（仅100M参数）编码每组物体信息和目标，计算相似度作为组包含子目标的概率。建模为背包问题: \(\max \sum_i (P_i - threshold) \cdot x_i\) subject to \(\sum_i M_i \cdot x_i \leq M\), 适配不同设备内存预算
- 设计动机: 小模型无法从复杂地图中自行聚焦——主动裁剪冗余是"授人以渔"。CLIP轻量且延迟可忽略；背包问题公式化使方案适配任意设备
系统协作¶
小大模型协作模式: CLIP负责简单的组选择（100M、低延迟），LLM负责困难的子目标规划——任务分工匹配模型能力。
实验关键数据¶
主实验（HM3D benchmark）¶
| 方法 | Zero-shot | LLM | On-device | SR↑ | SPL↑ |
|---|---|---|---|---|---|
| InstructNav | ✓ | GPT-4V | ✗ | ~38 | ~18 |
| MapGPT | ✓ | GPT-4 | ✗ | ~40 | ~20 |
| EfficientNav | ✓ | LLaMA-11b | ✓ | +11.1% | +提升 |
延迟对比¶
| 指标 | GPT-4基线 | EfficientNav | 加速比 |
|---|---|---|---|
| 实时延迟 | 高 | 低 | 6.7× |
| 端到端延迟 | 高 | 低 | 4.7× |
关键发现¶
- 小模型+信息裁剪 > 大模型: LLaMA-11b + 语义检索的SR超过GPT-4基线11.1%——证明"少即是多"，精选信息比堆砌上下文更有效
- 三个模块互补且缺一不可: 去掉任一模块都导致SR下降或延迟增加
- 注意力聚类粒度自适应: 与固定分组相比，attention-based聚类能更好地保持组内语义一致性
- 背包问题适配不同设备: 通过调整内存预算M，方案可无缝迁移到不同硬件平台
- 相邻步骤cache复用率高: 两次规划间地图变化小，选中组大概率重合→cache命中率高→加载延迟进一步降低
亮点与洞察¶
- 系统层面的完整端侧解决方案 — 不仅优化模型还优化KV cache管理、内存分配、信息检索，是端侧LLM系统的范例
- "裁剪冗余"比"增加能力"更有效 — 与直觉相反，帮助小模型聚焦比换大模型更管用。这对所有长上下文LLM应用都有启示
- 背包问题建模优雅 — 将信息选择与内存约束统一为经典组合优化问题，既有理论美感又实用
局限性 / 可改进方向¶
- CLIP检索质量上限: CLIP的语义理解不如LLM，可能在复杂场景下错选组
- 分组后组间注意力丢失: 虽然聚类缓解，但仍存在信息损失
- 仅验证室内场景: 未测试室外大规模导航场景
- 固定阈值: 注意力聚类和语义检索的阈值需手动调优
- 改进思路: 可以用小LLM替代CLIP做组选择；可以引入组间轻量attention或summary token
相关工作与启发¶
- vs InstructNav/MapGPT: 这些方法依赖GPT-4云端推理，EfficientNav首次将零样本ObjNav移至端侧且SR更高
- vs 通用KV cache压缩: 通用方法（量化/蒸馏/剪枝）未考虑导航地图的语义结构，EfficientNav利用地图语义做针对性优化
- 启发: 三层优化范式（分组缓存+语义聚类+自适应检索）可推广到所有需要长上下文端侧LLM的场景
评分¶
- 新颖性: ⭐⭐⭐⭐ 三层KV cache优化的组合设计巧妙，背包问题建模新颖
- 实验充分度: ⭐⭐⭐⭐ HM3D上完整对比+延迟分析+消融，但缺少更多场景验证
- 写作质量: ⭐⭐⭐⭐ 问题分析清晰，系统设计层次分明
- 价值: ⭐⭐⭐⭐⭐ 首个端侧LLM ObjNav系统，对端侧AI agent有标杆意义 方案：
- 用轻量 CLIP 模型（~100M参数）编码各组信息和目标物体，计算语义相似度
- 将组选择建模为背包问题：最大化选中组与目标的相关性总和，约束为设备内存预算
- max Σ(P_i - threshold)·x_i, s.t. Σ M_i·x_i ≤ M
- P_i 为组 i 包含子目标的概率，M_i 为该组 KV cache 大小，M 为内存预算
- CLIP 推理延迟远低于 LLM，组选择开销可忽略
- 相邻规划步之间地图变化小 → cache 命中率高 → 进一步减少加载开销
实验设置与结果¶
评测环境¶
- 数据集：HM3D (Habitat-Matterport 3D)
- 平台：Habitat 仿真器，机器人执行 RGB-D 导航
- 硬件：NVIDIA A6000 GPU + Jetson AGX Orin
- 模型：LLaVA-7b/13b/34b, LLaMA-3.2-11b
主要对比结果¶
| 方法 | LLM | 成功率(SR) | SPL | 实时延迟 | 端到端延迟 |
|---|---|---|---|---|---|
| LFG (SOTA) | GPT-4 | 68.9 | 36.0 | 5.80s | 59.34s |
| EfficientNav-11b | LLaMA-11b | 74.2 | 39.5 | 0.35s | 12.70s |
| EfficientNav-34b | LLaVA-34b | 80.0 | 41.5 | 0.87s | 12.51s |
- vs GPT-4 基线：SR +11.1%，实时延迟降 6.7×，端到端延迟降 4.7×
- vs 原生 LLaVA-34b 规划器：SR +37.3%，SPL +20.5%
- vs vLLM 加速方案：实时延迟仍低 5.1-6.5×（vLLM 无法解决 prefilling 重计算瓶颈）
消融实验 (LLaVA-34b)¶
| 配置 | SR | SPL | 实时延迟 | 端到端延迟 |
|---|---|---|---|---|
| 原始规划器 | 42.7 | 21.0 | 5.63s | 55.32s |
| +离散缓存 | 43.1 | 21.0 | 2.42s | 36.94s |
| +注意力聚类 | 63.3 | 34.2 | 2.32s | 32.58s |
| +语义检索 | 80.0 | 41.5 | 0.87s | 12.51s |
- 注意力聚类贡献最大准确率提升（+20.2% SR），语义检索贡献最大延迟降低
延迟特性¶
- 传统方案随导航步数增加 prompt 长度线性增长 → 延迟线性上升
- EfficientNav 延迟在几步后趋于稳定——语义检索控制了给 LLM 的信息量上限
- Cache 命中率随内存预算增加快速趋近高水平，进一步减少加载开销
亮点与深度洞察¶
- 小模型 > 大模型的反直觉结果：通过信息裁剪让小 LLM 聚焦关键信息，反而比 GPT-4 处理全量冗余信息表现更好——信息并非越多越好
- 背包问题建模组选择：优雅地将内存约束下的信息选择转化为经典优化问题，可适配不同设备的内存预算
- KV cache 离散化的通用性：该设计不限于导航，适用于任何长上下文+增量更新的端侧 LLM 场景（如对话历史管理、流式文档理解）
- 系统思维：不是单点优化而是三个模块协同——缓存解决延迟、聚类保证质量、检索控制规模
局限性 / 可改进方向¶
- 系统三模块协调复杂度高，实现和超参调整难度大（阈值、分组粒度等）
- 仅在室内导航 (HM3D) 验证，户外/动态障碍物环境的泛化能力未知
- 离散缓存牺牲了组间交叉注意力，理论上存在信息损失（尽管实验表明影响可控）
- 依赖 Grounding DINO 检测质量，检测错误会传播到后续所有环节
评分¶
- 新颖性: ⭐⭐⭐⭐ KV cache 离散化+注意力聚类+语义检索的三层组合新颖实用
- 实验充分度: ⭐⭐⭐⭐ HM3D 完整对比+消融+延迟分析+cache命中率分析
- 系统完整性: ⭐⭐⭐⭐⭐ 从内存管理到信息检索到规划提升的完整系统设计
- 写作质量: ⭐⭐⭐⭐ 系统设计思路清晰，挑战-方案对应明确
- 价值: ⭐⭐⭐⭐⭐ 对端侧具身AI部署有重要实践意义，KV cache管理方案可泛化