第一次看到 “Driving on Memory” 这个名字很多人第一反应是“车开着开着把记忆翻出来用”。如果只从名字看它不太像传统意义上那种“输入图像、输出结果”的模型更像是在讲自动驾驶系统里一个长期被低估的问题模型怎么记住过去。把这句话往工程方向拆会发现它同时踩中两条技术线。第一条是算法侧让车辆把之前走过的路线、见过的红绿灯状态、做过的决策变成可查询的上下文而不是每一帧都从零开始理解。第二条是工程侧训练和部署这类模型时内存和显存会不会在长序列、多传感器、批量任务中被不断吃光最终报出 OOM 或者内存访问冲突。这次我们不假装推荐某个“拿过来双击就能跑”的一键整合包而是把这个方向拆成能落地的技术框架记忆模块的结构、多传感器数据怎么补、本地环境怎么搭、功能怎么验证、内存和显存故障怎么查。如果你正在做自动驾驶感知、端到端驾驶模型或者给驾驶模型做数据闭环这篇文章可以直接收藏。1. Driving on Memory 核心能力速览为了让读者先快速判断这个方向值不值得深入下面按“一个驾驶记忆系统通常具备什么能力”的维度整理。注意这里不是某个具体开源仓库的实测参数因为该类项目通常以研究代码或内部框架存在版本差异很大实际能力以你拉到的仓库 README 和 config 为准。能力项常见实现方式依赖尺度典型输出短时场景记忆缓存最近 N 帧特征叠加时间编码帧数、特征维度、显存占用相关当前场景的上下文向量长时路线记忆把历史轨迹和关键事件写入向量库按查询召回库规模、索引方式、磁盘空间相关相似路线/相似场景的历史经验多传感器记忆对齐Camera、LiDAR、Radar 数据在统一坐标系下缓存标定参数、时间同步机制对齐后的多模态片段决策回放保存推理时的动作、置信度、路权判断日志系统批量跑测时占用磁盘可复盘的行为序列数据合成补充用仿真或生成模型合成新场景扩展记忆覆盖CPU/GPU 算力、渲染资源新的训练样本内存与显存管理缓存淘汰、分批加载、显存监控内存/显存限制稳定的长时间运行状态上表的逻辑是Driving on Memory 不是一个单一能力而是一个“记忆获取 — 存储 — 检索 — 回放”闭环。要做落地得先明确你要做的是短期上下文还是跨场景的长期经验。2. 这个方向到底解决什么问题传统自动驾驶模块大多是“无状态”的。每一帧图像进来目标检测、轨迹预测、规划模块各自计算一次帧与帧之间没有真正意义上的“记忆”。好处是实现简单坏处也很明显模型在同一个路口反复经过时每次都要重新判断遇到施工改道这类临时事件只要当前帧没看得足够清楚下一秒就可能把刚才的信息丢掉。Driving on Memory 想解决的问题就是把“状态”加回驾驶系统里。工程上可以拆成三层第一层是短期上下文。车辆通过路口时只需要记住过去 3 到 10 秒内其他交通参与者的运动趋势就能更好地判断谁要让行。这类记忆不需要长期保存本质上是一个滑动窗口缓存。第二层是长期语义记忆。某个路段在早高峰经常拥堵某个建筑门口经常有车辆突然汇入这些规律不可能从单一帧里学到需要系统把多次经过该区域获得的信息沉淀下来。实现方式可以是显式的场景特征库也可以是大模型 Memory Bank。第三层是决策经验记忆。端到端模型训练时如果能把专家驾驶的完整轨迹存下来在遇到相似场景时直接作为先验条件引导生成能明显减少因为视频帧被裁剪而丢失的上下文。从数据角度看还有一个容易被忽略的问题真实路采数据不可能覆盖所有场景。为了给记忆系统提供充足的“经验”很多团队开始引入多传感器一致的数据合成。这类做法的思路是用算法生成带标注的驾驶场景让模型在虚拟数据里先建立对长尾场景的记忆再回到真实场景中微调。近期一些相关工作把重点放在 cross-modality consistent multi-sensor data synthesis也就是“让多个传感器看到完全一致的同一个世界”而不是各传感器各生成各的导致物体位置对不上。只有传感器数据在空间和时间上对齐生成出的记忆样本才可用于后续训练。3. 记忆模块的系统结构与数据流要把 Driving on Memory 落地不能只把它理解成一个“Memory 文件夹”。下面这套结构是多模态驾驶模型里比较通用的参考架构具体组件命名可以跟着项目走但数据流基本是一致的。Raw Sensor Input (Camera / LiDAR / Radar / IMU / GNSS) ↓ Perception Feature Extractor (检测、跟踪、BEV 特征或多模态 token) ↓ Memory Encoder (把当前帧特征压缩成可写的记忆单元) ↓ Memory Store (短期工作记忆 / 长期经验库 / 场景缓存) ↓ Memory Retriever (根据当前状态查询相关历史记忆) ↓ Decision Planning Module (把当前输入和召回的记忆一起送入规划器)3.1 短期工作记忆短期工作记忆通常用一个环形缓冲区实现。系统只保留最近 N 帧的特征当新的特征进入时最老的一帧被覆盖。选择 N 时要注意时间跨度和实际耗时之间的平衡范围太短模型记不住障碍物被遮挡后的运动范围太长显存占用就会随帧数线性上升。3.2 长期记忆与向量检索长期记忆一般不会直接把原始图像塞进数据库而是把模型提取出的特征向量、语义描述、时间戳和地理位置一起写入。查询的时候系统先用车端当前位置和当前场景特征生成 query再从库里召回 Top-K 条最相似的记忆。示例逻辑如下class MemoryStore: def __init__(self, top_k5): self.memory_bank [] self.top_k top_k def write(self, location_id, scene_vector, action): item { location_id: location_id, vector: scene_vector, action: action, timestamp: time.time(), } self.memory_bank.append(item) def recall(self, current_vector, location_idNone): candidates self.memory_bank if location_id is not None: candidates [m for m in candidates if m[location_id] location_id] scored sorted( candidates, keylambda m: cosine_similarity(m[vector], current_vector), reverseTrue ) return scored[:self.top_k]这段代码只是演示记忆写入和查询的关系不是某个项目的真实 API。生产环境里短期记忆可能直接放在 GPU 显存里长期记忆则用独立向量数据库管理避免检索过程占用推理显存。3.3 记忆刷新与过期策略驾驶场景中最怕“错误记忆”一直不更新。比如某个路段今天临时封闭如果模型因为昨天的记忆而坚持原路线就会出问题。所以记忆模块一定要有时效性设计短期记忆执行 FIFO长期记忆要有写入时间和置信度一旦当前传感器观测到与旧记忆明显冲突就要用新观测覆盖旧记忆而不是简单追加。4. 真实数据不足时多传感器数据合成怎么补自动驾驶要“记住”的场景几乎是无限的但真实路采数据的获取成本很高而且很多极端场景很难安全地实车采集。这个背景下多传感器数据合成成了 Driving on Memory 方向的重要上游能力。我前面提到的 X-Drive 这类工作代表的是“跨模态一致的多传感器数据合成”思路。它强调几个核心点第一空间一致。车辆周围有一个真实的三维世界摄像头看到的 RGB 图像、LiDAR 扫描出的点云、Radar 返回的目标位置必须来自同一个占据空间。如果摄像头在左边看到一辆车LiDAR 点云里也必须在相同位置出现这辆车而不是各渲染各的。第二时间一致。多个传感器在每一帧都要精确同步。不能用一秒前的位置和当前帧的 RGB 图强行拼成一个训练样本否则模型学到的是错误的空间关系。第三标注一致。合成数据最大的价值是“免费标注”。如果生成器内部已经包含了物体的三维位置和类别那么训练时需要的 3D Box、车道线、轨迹都可以直接导出。这样模型就能在合成场景里建立足够丰富的“记忆”再通过真实数据验证。工程上做这类数据合成通常要经过以下流程# 前置依赖 # - 3D 场景文件或地图数据 # - 传感器标定文件内外参 # - GNSS/IMU 轨迹文件 # - 渲染或生成服务 # 大致流程 1 加载场景和车辆轨迹 2 在关键帧位置生成多传感器观测 3 做传感器两两之间的投影/对齐检查 4 导出 RGB、LiDAR、Radar、标注文件 5 抽样人工检查一致性需要注意的是传感器标定文件不一致是这类任务最常见的错误来源。摄像头像素坐标和 LiDAR 点云坐标如果没有做外参对齐生成出的数据看起来没问题训练时 loss 会非常不稳定。5. 本地验证环境准备与启动方式想实际验证一个 Driving on Memory 类项目先不要追求跑完整训练。正确的顺序是“小模型 小场景 单机环境跑通推理再逐步扩大”。下面给的是一套通用环境准备流程具体版本号要以你拉到的代码仓库为准。5.1 硬件与系统检查开始前先查这几项GPU训练阶段优先看有没有 NVIDIA 显卡显存大小直接决定 batch size 和记忆长度。CPU 与内存数据合成和数据加载都很吃内存长序列任务建议 32GB 以上内存实际以数据集大小为准。磁盘先预留训练数据、生成数据、模型权重和日志四份空间。系统多数项目默认支持 LinuxWindows 上尽量用 WSL2 或 Docker。# 查看显卡可用情况 nvidia-smi # 查看内存 free -h # 查看磁盘 df -h5.2 创建独立环境不管项目基于 PyTorch 还是 TensorFlow都建议先建独立环境不要直接装在系统 Python 里。conda create -n driving_memory python3.10 -y conda activate driving_memory pip install -U pip如果你的项目用的是特定 CUDA 版本记得去项目文档里找对应的 PyTorch 安装命令不要用默认命令覆盖。5.3 加载代码与模型权重研究类项目通常包含以下代码结构configs/ # 模型和数据配置 docs/ # README 和说明 models/ # 网络结构 tools/ # 训练/测试/可视化脚本 data/ # 数据集软链接目录 scripts/ # 启动脚本把代码克隆到本地后先看 README 里有没有 pretrained weights 的下载地址。权重文件宁可放在独立目录统一管理也不要直接放代码库里避免 git 目录越来越大。5.4 启动一个最小验证如果项目支持命令行推理通常会有类似下面的入口脚本# 以仓库实际文件名和参数为准 python tools/test.py \ --config configs/example.py \ --checkpoint ./pretrained/example.pth \ --input ./sample_scenes/sample_01 \ --save-memory注意具体参数名一定是项目提供的不要强行套用。看到一个陌生项目先在 tools 目录下用--help看参数列表比盲记命令更可靠。6. 功能测试与效果验证没有统一数据集的情况下我们可以围绕“记忆是否真的起作用”来设计测试。下面给出三组可操作验证方案。6.1 同一路段重复推理一致性测试测试目的是判断模型有没有把历史信息利用起来。输入同一段连续驾驶片段第一次推理时清空记忆第二次推理时保留上一次的记忆对比两次规划轨迹的差异。预期结果没有记忆的模型每帧输出波动可能较大。有记忆的模型在障碍物被短暂遮挡、红绿灯切换时能保持相对稳定的决策。判断成功的关键指标是轨迹抖动幅度减小而不是完全一模一样。6.2 多传感器数据一致性测试如果你验证的是数据合成管线需要重点检查同一物体在相机图像和 LiDAR 点云中的对齐程度。# 示例把 LiDAR 3D 点投影到图像上 import numpy as np # 假设已经读取外参和相机内参 points_lidar np.array([[x, y, z, 1.0], ...]) # 形状 (N, 4) # 使用外参矩阵 T_lidar_to_camera 转换 points_camera (T_lidar_to_camera points_lidar.T).T # 相机坐标系去齐次 points_camera points_camera[:, :3] / points_camera[:, 2:3] # 使用内参矩阵 K 投影到像素平面 uv (K points_camera.T).T[:, :2]如果投影后的 3D 点落在对应目标的 2D Box 内基本可以认为传感器空间对齐满足要求。误差较大时先检查坐标系是“LiDAR to Camera”还是“Camera to LiDAR”两个方向写反是最常见的坑。6.3 长序列批量跑测稳定性测试记忆系统最容易在长时间序列里出问题。准备一个包含多个连续场景片段的目录批量执行推理同时记录每一轮的显存占用和内存变化。# 通用批量测试伪命令 for scene in data/scenes/*; do echo Processing $scene python tools/infer.py \ --input $scene \ --output result_$(basename $scene) nvidia-smi --query-gpumemory.used --formatcsv done这类测试的目的不是看单帧效果而是看运行 100 轮后显存占用是否持续上涨。如果显存使用量一条直线往上走说明记忆缓冲或特征缓存没有被正确释放这是内存泄漏的典型信号。7. 接口 API 与批量任务研究项目如果想要接到实际工具链里通常不会只跑命令行而是把记忆写入、查询、清空能力封装成服务。虽然我没法给出某个仓库的真实请求体但一套通用 API 设计可以参考。7.1 通用服务启动方式# 如果项目提供了 server 入口可能是这种形式 python tools/serve.py --host 0.0.0.0 --port 8080启动后先访问/health或/docs确认服务在线再去调具体接口。接口地址、参数名必须以项目文档为准不要照抄下面示例。7.2 写入记忆请求示例import requests url http://127.0.0.1:8080/memory/write payload { scene_id: city_block_001, frame_ids: [100, 101, 102, 103, 104], embedding: [0.01, 0.02, 0.03], # 实际维度可能很高 action_sequence: brake_and_lane_keep, timestamp: 1700000000 } response requests.post(url, jsonpayload, timeout10) print(response.status_code, response.json())7.3 查询记忆请求示例import requests url http://127.0.0.1:8080/memory/query payload { embedding: [0.01, 0.02, 0.03], top_k: 3, location_id: city_block_001 } response requests.post(url, jsonpayload, timeout10) results response.json() for hit in results.get(hits, []): print(hit[scene_id], hit[score])实际项目中embedding 往往是千维以上查询前要做归一化。如果请求频率高可以用 batch 接口一次查询多条记忆降低网络往返开销。7.4 批量任务设计建议批量任务最容易犯的错误是“一个进程串行跑所有场景”。场景短还好场景一旦变长中间任何错误都可能让整个任务失败。更稳妥的做法是设计任务队列输入目录 → 扫描任务列表 → 逐个写入消息队列 → 多个 worker 消费 → 输出结果和日志每次只处理三个大场景完成后检查显存峰值和日志错误再继续跑下一批。不要一次性把所有场景加载进内存。8. 资源占用与内存隐患排查“Memory”在自动驾驶项目里还有另一层含义那就是操作系统的内存与显卡显存。很多项目不是模型效果不行而是跑到一半崩了。报错通常是这几类报错类型通常原因观察方式CUDA out of memory显存不足以容纳 batch 和记忆缓存nvidia-smi -l 1OutOfMemoryError: insufficient memory数据加载阶段申请内存过大free -hnative memory allocation failedPython/C 扩展申请堆内存失败查看进程 RSS0xc0000005 / memory access violationC 扩展访问非法内存地址查看崩溃堆栈process exited with code 3221225477Windows 下内存访问违规常见退出码在 Debug 模式重跑排查思路是固定顺序先看显存是否打满再看系统内存是否打满最后看 C 扩展有没有越界访问。# 持续观察 GPU watch -n 1 nvidia-smi # 观察进程内存 top -p pid # 查看单进程内存详情 cat /proc/pid/status | grep VmRSS降低资源占用有几个实用手段减少 memory buffer 的长度不要默认保留全部帧。使用混合精度训练和推理能明显降低显存占用。长期记忆检索从 GPU 挪到 CPU 或独立向量库。批量任务分片跑每个进程处理少量场景后重启。若出现 0xc0000005优先检查是否有自定义 C 算子并考虑降低num_workers。9. Driving on Memory 常见问题与排查方法问题现象可能原因排查方式解决方案启动后进程闪退无 Python traceback依赖冲突或底层算子崩溃在命令行加--gpus0缩小问题范围重建环境并固定依赖版本显存占用随时间持续上涨特征缓存未释放或 memory bank 无限增长隔 100 帧记录一次显存给记忆模块加容量上限和淘汰策略查询出来的记忆和当前场景严重不符向量检索缺少地理坐标过滤打印 query 向量和返回记忆的时间戳增加 location_id、时间范围过滤多传感器合成结果对不齐外参矩阵方向错误或时间戳不同步手动投影一个点验证检查标定文件统一时间戳训练 loss 正常但规划结果震荡长期记忆覆盖了当前最新观测查看召回记忆的时间顺序提高当前帧特征在融合时的权重批量任务跑到中途 OOM单个 work 持有太多历史记忆查看内存曲线调整 batch 大小并分批处理API 请求极慢查询时对全量向量库线性扫描观察服务端日志耗时使用向量索引或增加过滤条件CPU 推理太慢模型未量化且记忆检索也占用 CPU分别测试推理与检索耗时工程部署时考虑 TensorRT 或量化以上问题大多不只在单一项目中出现只要你开始接触带记忆模块的驾驶系统大概率会先撞到其中一两个。10. 最佳实践与合规使用建议从工程角度看做 Driving on Memory 类项目时有几条经验可以提前套用。第一不要一上来就做“全场景长期记忆”。第一次把记忆模块接入驾驶系统先固定一条路线、一个路口、一段 10 分钟的数据。验证记忆确实能够改善决策后再逐步扩大场景覆盖。这样出现问题的时候你知道问题大概率出在记忆设计而不是模型主干。第二模型文件、输入素材、输出结果和日志分开目录管理。记忆库本身也可以看成一个特殊的数据资产要定期备份和清理。长期记忆库一旦膨胀到几十个 G检索效率会明显下降而且很难定位哪条历史记忆是错的。第三给记忆系统设计显式的过期和覆盖机制。驾驶场景中环境变化非常快一个昨天成立的交规经验今天可能因为道路施工而不再成立。记忆模块必须以当前传感器的观测为准而不是以历史记忆为准。第四涉及真实路测数据时要严格遵守授权范围。道路影像、行人面部、车牌、地图数据都可能涉及隐私和合规要求。凡是使用真实采集数据训练或验证的系统都要确认数据来源和用途已经过合法授权。合成数据虽然降低了隐私风险但如果仿真场景包含特定道路和真实建筑的结构仍然要注意地图合规问题。第五任何记忆能力都不能替代安全兜底。驾驶系统最终要遵守交通规则在不确定性较高时要选择保守策略。记忆只能提供先验不能成为“盲目相信过去”的理由。11. 总结先跑通哪一步Driving on Memory 这个方向的本质是让自动驾驶系统从“单帧静态感知”走向“多帧持续理解”。它既包括模型层面的场景记忆和路线经验也包括工程层面的内存、显存、数据合成和接口设计。如果你刚接触这个方向第一步不是去复现某个庞大的端到端模型而是先搭建一个最小闭环用已有的感知模型提取特征写入一个带时效性的记忆库再在第二段相似场景里查询并比较决策差异。跑通这个流程后再去考虑多传感器一致性、批量任务队列和长时记忆索引。最容易踩的坑其实不是模型结构而是记忆缓存没有上限。长期跑下去显存、内存、接口耗时都会一起失控。与其追求一步到位不如先让系统在 10 分钟的数据上稳定运行再谈更大规模的探索。建议先把“驾驶记忆”当成一类需要系统设计和持续调优的能力来对待而不是找一个现成模型直接替换。小场景跑稳、日志记全、显存观察到位这条路才算真正打开。