内存不够的机器人，地图该丢哪一帧

巡检机器人走到三层走廊尽头，准备开门进机房，这时它要同时干两件事：跑一个语言模型理解"去配电柜看看"，维护一张稠密的三维地图别撞墙。两块内存共享一个上限。过去这个上限是按关键帧数量设的——存五百帧就删最老的——听起来合理，直到某天那五百帧里全是贴着墙拍的近景，一帧就吃掉过去十帧的空间。

一、发生了什么

10 月 24 日的这篇论文（编号 2610.33574）指出的是两个被搞混的量：帧数和内存。关键帧数量有上限，不等于内存占用有上限，因为每帧占多少取决于它带的东西。它同时指出"准入单位"也不对——按位姿周围一个球、按固定格子、或者按图里最近的几个邻居来选帧，都会连带换进换出一些根本用不到的局部地图。

它的第一个决定是直接按字节数约束常驻地图，并且让每次准入的代价在读取数据之前就已知：每帧的常驻大小离线算好，跟着地图一起存。第二个决定是把准入和释放的单位换成房间和走廊这种语义空间单元——机器人攥住自己所在的区域和即将进入的区域，走过的区域整体释放。每次准入前先量总量、腾地方、再读，所以预算永远不超。

实验在两块 NVIDIA Jetson 板上跑。带预算的方案每一次都守住了上限，模型吞吐最多损失 0.8%；不带的话，操作系统会直接杀掉模型进程或者地图进程。在守预算的前提下，按语义区域换图比按几何划分换图多定位到 6 到 9 个百分点的查询帧，大约是某个常用开源建图方案检索量的两倍，同时绝对轨迹误差更低。

二、跟你有什么关系

做边缘部署的：这台机器上跑的从来不止一个模型。你的内存预算该给"整机"做，而不是给每个模块各分一份。

做建图的：按帧数淘汰是最常见的写法，也是最容易在现场翻车的一行代码。改成按实测字节数，改动量不大。

做产品定义的：0.8% 的吞吐损失换"不崩"，这个交换在巡检、配送这类连续作业场景里几乎不用犹豫。

三、怎么判断

1. 先量一帧有多大。在你的场景里各拍一组近景、远景、纹理密集的帧，算常驻大小的分布。如果最大最小差三倍以上，按帧数管就是错的。
2. 划语义单元。楼宇场景用房间和走廊，仓库用巷道和货位区。划分标准是"机器人一次作业会连续经过的区域"，不是几何形状。
3. 做一次故意超配的压测。把语言模型的上下文拉满，看地图会不会被系统回收。跑通这一条，才算守住了预算。

四、三个别信的说法

「换个更大的内存就够了。」 论文的前提就是同一台设备上两个系统共享内存，扩内存只是把崩溃推后。而且这是嵌入式板子，功耗和成本都不允许随意加。

「语义分区一定比几何分区好。」 论文给的是 6 到 9 个百分点的差距，还加了"在被评估的这些环境里"这个限定。如果你的场地是开阔厂房、没有明确的房间边界，语义单元的划分本身就会失效。

「吞吐只掉 0.8%，可以忽略。」 这是地图这一侧的损失。整机延迟还要算上腾挪内存时的抖动——每次准入都要先测量再释放，短时峰值的表现比平均值更值得看。

五、一句话结论

机器人的内存问题不是"删哪一帧"，而是"用哪把尺子量"——先换尺子，再换策略。

信息来源

• arXiv 论文页：内存受限机器人上的关键帧管理（2026-10-24）

功能与价格以官方公告为准。本文写于 2026 年 10 月 27 日。