轨迹预测算法嵌入式部署:从模型原理到车规级芯片的优化实践 1. 项目概述从算法到芯片轨迹预测的落地之困在自动驾驶和高级驾驶辅助系统ADAS的研发一线摸爬滚打了十几年我深刻体会到一个算法从论文里的漂亮曲线到最终在车规级芯片上稳定、实时地跑起来中间隔着的可能不止一个太平洋。轨迹预测Trajectory Prediction, TP就是这样一个典型领域。它的核心任务听起来很直观给定一辆车过去几秒的轨迹结合地图、周围车辆等信息预测它未来几秒会怎么走。但就是这个“猜一猜”的动作背后是感知、决策、控制整个链条的基石。一个不准的预测轻则让乘员感到顿挫不适重则可能引发安全事故。近年来基于深度学习的轨迹预测模型在公开数据集上刷榜的成绩令人眼花缭乱minADE、minFDE这些指标被不断刷新。然而当我们这些做工程落地的工程师兴冲冲地把最新的SOTA模型往车载嵌入式平台上移植时往往会遭遇“理想很丰满现实很骨感”的窘境。动辄几百兆的模型体积、每秒数十G的算力需求FLOPs在实验室的V100、A100显卡上跑得飞快一旦放到算力、内存、功耗都严格受限的车规级芯片如英伟达的Jetson系列、地平线的征程系列、TI的TDA4等上推理延迟Latency可能直接飙升到几百毫秒完全无法满足ADAS系统100毫秒甚至50毫秒的端到端响应要求。因此这篇综述我想换个角度来写。我们不只谈哪个算法在Argoverse数据集上又提升了零点几个百分点更要深入探讨这些算法到底是怎么工作的它们的计算瓶颈在哪里当我们要把它们塞进一个功耗几十瓦、算力几十TOPS的嵌入式盒子时需要做哪些权衡和改造本文将从算法原理的分类梳理出发结合我们团队在高低性能硬件平台上的实测数据为你拆解单车辆轨迹预测从算法到嵌入式部署的全链路挑战与实践心得。2. 轨迹预测的核心思路与算法流派深度解析轨迹预测不是一个单一的技术而是一个融合了运动学、行为学、深度学习等多个学科的交叉领域。不同的方法基于不同的假设和对问题的理解。要理解后续的部署挑战必须先吃透这些核心思路。2.1 问题定义与核心挑战首先明确一下我们讨论的范畴单车辆轨迹预测。这意味着在每一个预测时刻我们只关心一个特定“目标车辆”Vehicle of Interest, VoI的未来路径。这个VoI可以是自车Ego Vehicle也可以是周围的任意一辆车。输入通常是该车辆过去T_obs秒例如2秒的历史状态序列包括位置、速度、加速度、航向角等。输出则是未来T_pred秒例如3秒的预测轨迹。输出可以是单模态一条最可能的轨迹或多模态多条可能轨迹及其概率。这个任务面临几个核心挑战不确定性司机意图具有内在不确定性。在路口他可能直行、左转或右转。交互性车辆轨迹受到周围车辆、行人行为的强烈影响。环境约束道路结构车道线、路口、交通规则严格限制了车辆的可行区域。实时性预测必须在极短时间内完成通常30ms以满足下游规划与控制模块的需求。资源约束车载计算平台的内存、算力、功耗都是宝贵的稀缺资源。2.2 算法分类学一张地图看清所有流派学术界对轨迹预测算法的分类有很多维度。我比较认同一种结合了输出类型、环境类型和建模方法的三维分类法这能更清晰地看到方法的适用场景和特点。1. 按输出类型分单模态预测输出一条轨迹。常见于物理模型和部分早期学习模型。优点是确定性强计算快缺点是无法表达不确定性。多模态预测输出K条轨迹及其概率。这是当前深度学习模型的主流能更好地捕捉未来发展的多种可能性。评估时常用minADE_k与真值最接近那条轨迹的平均误差和minFDE_k最终点的误差。2. 按适用环境分高速公路场景相对结构化车辆行为以跟驰、换道为主。基于车道和驾驶意图Maneuver的方法在这里表现很好。城市道路场景复杂有交叉口、行人、非机动车交互频繁。需要更强的交互建模和环境理解能力。混合/未指定很多通用模型旨在适应多种环境。3. 按核心建模方法分这是理解算法本质的关键2.2.1 基于物理模型的方法简单、快速、但“短视”这类方法将车辆视为一个物理实体用运动学或动力学方程来外推其未来状态。核心原理假设车辆在短时间内保持某种运动模式。例如恒定速度模型假设速度不变轨迹是一条直线。恒定加速度模型假设加速度不变。恒定转率和速度模型适用于弯道假设角速度不变。为什么用它最大的优势是速度快、可解释性强、几乎零计算成本。一个卡尔曼滤波KF配合CV/CA模型在CPU上微秒级就能完成预测。致命缺点无法处理交互和意图。它只能预测“如果司机什么都不做”的轨迹一旦司机有变道、转弯意图预测会迅速偏离。因此它通常只用于短时1秒预测或作为更复杂模型的初始化或补充。实操心得在资源极度受限的ECU上物理模型依然是可靠的保底方案。我们常在系统中设置一个并行运行的物理模型预测器当深度学习模型因某些原因如输入异常失效或延迟过高时立即切换至物理模型的预测结果保证系统功能降级Fail-operational而非失效Fail-safe。2.2.2 基于交互的方法理解“社会关系”这类方法认为车辆的轨迹主要受周围其他交通参与者的影响。核心是建模车辆之间的“社会”交互。核心原理将交通场景建模为一个图Graph或利用注意力机制Attention。图神经网络GNN方法将每辆车视为图中的一个节点车辆之间的空间关系如距离、相对速度构成边。通过图卷积网络来聚合邻居信息从而让目标车辆“感知”到周围车辆对其的影响。代表工作如VectorNet、LaneGCN也结合了车道信息。注意力机制方法使用Transformer架构中的自注意力或交叉注意力模块。模型自动学习在历史轨迹中哪些时刻、哪些周围车辆的信息对预测当前车辆未来轨迹更重要。代表工作如AutoBots、MTP。为什么用它能有效处理车辆间的博弈如切入cut-in、让行等复杂交互行为在城市道路场景中优势明显。计算瓶颈交互建模是计算大户。对于GNN构建图、进行多轮消息传递需要大量内存访问和计算。对于Attention其计算复杂度与序列长度的平方成正比当场景中车辆很多时N辆车计算量会急剧增加O(N^2)。2.2.3 基于驾驶意图的方法预测“想法”这类方法认为司机的离散驾驶意图如左换道、右换道、车道保持是决定未来连续轨迹的关键。先分类意图再基于意图生成轨迹。核心原理通常是一个两阶段管道。意图识别将历史轨迹编码后通过一个分类网络如Softmax输出属于各个意图类别的概率。这可以看作是一个行为克隆问题。条件轨迹生成根据识别出的意图或所有意图的概率分布使用解码器如LSTM、MLP生成对应的一条或多条轨迹。Maneuver-LSTM是这类方法的典型。为什么用它非常符合人类驾驶的决策逻辑——先决定要做什么再执行。在高速公路这种意图相对明确换道、跟车的场景下效果很好。实操难点意图标签的获取和定义是老大难问题。很多公开数据集如NGSIM有相对清晰的车道线可以定义“车道保持”、“左换道”、“右换道”等意图。但在复杂的城市道路尤其是在没有清晰车道线的区域意图的定义变得模糊。此外意图分类的错误会直接导致轨迹生成的失败错误会传播。2.2.4 基于车道的方法跟着“路”走这类方法假设车辆的轨迹会紧密贴合车道结构。它强烈依赖高精地图HD Map提供的车道中心线、连接关系等信息。核心原理将车道网络向量化Vectorize成一系列折线Polylines或构建成车道图Lane Graph。预测时模型会学习车辆与这些车道元素的关联并最终将预测轨迹“锚定”在相关的车道上。LaneGCN是这方面的开创性工作它构建了复杂的Actor-to-Lane, Lane-to-Lane等图网络来融合车辆和车道信息。为什么用它生成的轨迹具有极高的道路合理性几乎不会预测出开到绿化带或逆行的情况。对于结构化道路高速、城市主干道的预测精度提升很大。部署挑战重度依赖高精地图。这不仅意味着需要额外的地图存储和内存开销更关键的是地图的实时更新、局部缺失如施工处理都是工程难题。此外构建和编码车道图本身也是一笔不小的计算开销。2.2.5 混合方法博采众长显然没有一种方法是完美的。因此最新的研究趋势是混合模型试图结合上述多种方法的优势。物理意图混合例如IMM交互式多模型滤波同时运行一个物理模型如CTRA和一个意图模型根据实时观测的概率动态调整两个模型的权重融合输出。短期靠物理长期靠意图。车道交互混合这几乎是当前SOTA模型的标配。如LaneGCN、VectorNet既用车道图约束轨迹的空间合理性又用GNN或Attention建模车辆交互。实操选择混合模型通常意味着更大的模型容量和更复杂的计算图。在部署时需要仔细分析每个模块的计算占比看是否有轻量化或拆解的可能。例如车道编码部分是否可以提前离线计算或缓存3. 从论文指标到嵌入式指标重新定义评估体系在学术界大家比拼的是在Argoverse、nuScenes等测试集上的minADE、minFDE、Miss Rate。但在嵌入式部署的语境下我们必须建立一套新的评估维度我称之为“嵌入式可行性”三角精度Accuracy、速度Latency、效率Efficiency。3.1 算法精度指标不只是看“误差”对于部署我们不仅要看平均误差更要关注极端情况和一致性。minFDE_k(最终位移误差)这可能是最重要的安全指标。它衡量的是预测终点与真实终点的距离。一个大的minFDE可能意味着模型完全误判了车辆的最终意图如该左转却预测直行这对规划器是灾难性的。Miss Rate(漏检率)预测轨迹的终点与真实终点距离超过某个阈值如2米的比例。它直接反映了模型“完全预测错”的频率。Drivable Area Compliance (DAC)(可行驶区域合规率)预测轨迹的点有多少百分比落在高精地图定义的可行驶区域内。这是一个强安全约束指标。即使轨迹误差不大但如果轨迹穿过了隔离带或路沿也是不可接受的。部署时我们甚至会对DAC不达标的模型一票否决。Kernel Density Estimation (KDE) based NLL对于多模态预测我们还要评估其预测出的概率分布是否“校准”得好。NLL越低说明模型对自己的预测越“自信且正确”。一个校准不好的模型其输出的概率无法被下游的风险评估模块可靠使用。3.2 模型复杂度指标算力与内存的“体检报告”这是连接算法和硬件的桥梁。在考虑部署前必须给模型做一次全面的“体检”。参数量模型的总参数个数。直接决定了模型文件的大小和加载到内存后的静态占用。例如一个1亿参数的FP32模型大约占用400MB内存。这对于只有几GB内存的嵌入式平台是巨大的压力。模型大小存储模型权重的文件体积。与参数量和精度FP32, FP16, INT8有关。计算量FLOPs (浮点运算次数)完成一次前向推理所需的浮点运算总数。是衡量理论计算成本的核心指标。MACs (乘加运算次数)在硬件层面乘加运算Multiply-Accumulate是最常见的操作MACs通常约为FLOPs的一半。芯片的算力如TOPS, Tera Operations Per Second往往针对INT8或FP16的MACs而言。激活值内存运行时中间特征图Activation所占用的内存。这对于拥有大分辨率输入或深层网络的模型可能成为瓶颈甚至比模型权重本身占用更多内存。注意FLOPs低不等于推理快。它只反映了计算量但最终速度还严重依赖于内存带宽、算子优化程度、硬件并行度等因素。一个FLOPs低的模型如果其计算模式无法充分利用硬件的并行计算单元如GPU的SM、NPU的Tensor Core也可能跑得很慢。3.3 计算性能指标真实的“端到端”延迟这是嵌入式部署的生命线。很多论文只汇报“推理时间”Inference Time这是极具误导性的。 一个完整的轨迹预测模块在车上的处理流程如下[传感器数据] - [数据预处理] - [CPU内存] - [CPU-GPU/NPU 数据搬运] - [模型推理] - [GPU/NPU-CPU 数据搬运] - [后处理] - [输出]因此我们必须测量以下几个部分的时间在Batch Size1的情况下预处理时间将原始的传感器数据如目标列表、车道线转换成模型所需的输入张量。这可能包括坐标转换、归一化、向量化地图、构建图结构等。这部分往往在CPU上执行且容易被忽略但可能是瓶颈例如为每辆车构建一个复杂的社交图Social Graph就需要不小的CPU算力。数据搬运时间H2D D2H将预处理好的数据从主机内存Host/CPU搬运到设备内存Device/GPU/NPU以及将推理结果搬运回来。通过PCIe总线搬运数据是有延迟的对于小尺寸数据这个延迟可能比推理本身还高。推理时间模型在加速器上的前向传播时间。总处理时间以上所有时间的总和。这才是决定你的模块能否满足30ms Deadline的关键指标。在我们的测试中一个模型在高端GPU上总处理时间可能是15ms但放到嵌入式Jetson上预处理和搬运时间可能变化不大但推理时间可能翻好几倍总时间轻松突破100ms。4. 主流模型实战评估与嵌入式性能拆解纸上得来终觉浅。我们选取了四类方法中的代表性模型在**高性能平台NVIDIA RTX 6000 Ada和嵌入式平台NVIDIA Jetson AGX Orin**上进行了从训练到推理的完整评估。所有模型均在Argoverse 1数据集上复现和评估。4.1 模型选型与特点分析我们选择了以下四个具有代表性的开源模型物理模型代表恒定速度卡尔曼滤波 (CVKF)作为基线简单快速。交互模型代表无地图CRAT-Pred基于晶体图卷积网络轻量且专注于车辆间交互。交互模型代表有地图AutoBots基于Transformer使用向量化地图一次前向生成多模态轨迹。车道模型代表LaneGCN基于车道图卷积网络深度融合车道拓扑与车辆交互是许多后续工作的基石。模型核心方法地图依赖输出模态核心优势潜在计算瓶颈CVKF物理运动学否单模态极快可解释零训练精度低仅短期有效CRAT-Pred图神经网络 (GNN)否多模态轻量(参数量少)专注交互图构建与消息传递AutoBotsTransformer (注意力)是 (向量化)多模态并行解码推理快精度高注意力计算(O(N^2))地图预处理LaneGCN车道图卷积网络是 (高精地图)多模态轨迹道路合理性极佳模型巨大多阶段GNN计算复杂4.2 高性能平台RTX 6000上的表现我们在RTX 6000上训练并评估了上述学习模型。物理模型因其非学习特性直接使用公式计算。4.2.1 算法精度对比模型minADE₆ (米) ↓minFDE₆ (米) ↓MR₆ (%) ↓DAC₆ (%) ↑LaneGCN1.152.6111.5498.91AutoBots1.212.6312.4899.17CRAT-Pred1.393.0420.2896.76CVKF3.026.8445.6789.32结果解读精度王者LaneGCN在位移误差minADE/minFDE和漏检率MR上全面领先证明了深度融合车道信息对提升预测精度的决定性作用。其轨迹最贴合真实情况。实用之选AutoBots精度与LaneGCN非常接近且在可行驶区域合规率DAC上略胜一筹说明其生成的轨迹道路合理性极好。这对于安全至关重要。轻量化的代价CRAT-Pred作为轻量级模型精度上有明显差距尤其是MR较高意味着它“完全预测错”的情况更多。物理模型的局限CVKF的精度与学习模型有数量级差距仅能作为保底或短时参考。4.2.2 模型复杂度与计算性能模型参数量模型大小 (MB)FLOPs (G)预处理时间 (ms)推理时间 (ms)总处理时间 (ms)CRAT-Pred0.51M2.11.21.21.53.96AutoBots1.48M5.93.815.84.123.62LaneGCN3.67M14.7~15.0*10.55.217.99CVKF--可忽略0.93 (估计)~0.01~0.94注LaneGCN的FLOPs引自原论文估算。结果解读与实操心得“快”的真相CRAT-Pred的总处理时间仅3.96ms遥遥领先。这不仅得益于其小模型0.51M参数更关键的是其无地图依赖预处理非常简单主要是构建车辆交互图CPU负担小。这给了我们一个关键启示预处理开销是嵌入式部署的隐形杀手。地图的代价AutoBots和LaneGCN的预处理时间10-16ms占了总时间的大头。这部分时间主要消耗在CPU上进行高精地图的向量化、车道图构建、坐标转换等操作。在嵌入式CPU性能较弱的情况下这个时间可能会进一步膨胀。推理时间并非瓶颈在强大的RTX 6000上即使像LaneGCN这样的庞然大物纯GPU推理也只需5.2ms。真正的挑战在于如何将庞大的计算图高效地映射到嵌入式NPU/GPU上以及如何处理数据搬运和预处理。物理模型的效率碾压CVKF的总时间在1ms以内展现了规则模型在效率上的绝对优势。4.3 嵌入式平台Jetson AGX Orin上的性能滑坡我们将训练好的AutoBots和CRAT-Pred模型因其精度-效率权衡较好移植到Jetson AGX Orin32GB版本功耗约30W上进行推理测试。结果令人深思。4.3.1 算法精度保持不变这是好消息。只要推理框架如TensorRT, ONNX Runtime的算子实现正确且量化等优化没有引入过大误差模型在嵌入式平台上的输出精度与高性能GPU上基本一致。这保证了功能的有效性。4.3.2 计算性能的“断崖式”下跌模型平台预处理时间 (ms)推理时间 (ms)总处理时间 (ms)CRAT-PredRTX 60001.21.53.96CRAT-PredJetson Orin1.815.320.08AutoBotsRTX 600015.84.123.62AutoBotsJetson Orin16.579.298.94关键发现与深度分析推理时间急剧增加CRAT-Pred的推理时间从1.5ms暴增至15.3ms增长约10倍AutoBots则从4.1ms增至79.2ms增长超过19倍。这直观地反映了嵌入式GPUOrin的GPU算力约5-10 TFLOPS与数据中心GPURTX 6000约90 TFLOPS之间的巨大算力鸿沟。预处理时间相对稳定预处理主要在CPU上运行Jetson Orin的CPU性能尚可因此这部分时间增长不大约0.5-0.7ms。这反过来说明对于AutoBots这类模型在Orin上预处理已不再是主要瓶颈推理本身成了瓶颈。总时间超标AutoBots的总处理时间接近100ms远超我们设定的30ms安全线。这意味着即使使用当前顶级的车载嵌入式计算平台直接部署未经优化的SOTA模型也可能无法满足实时性要求。CRAT-Pred的20.08ms则勉强踩在线上但考虑到系统还有其他任务感知、定位、规划留给TP的预算可能更少。内存带宽与功耗限制除了纯算力嵌入式平台的内存带宽通常也远低于服务器显卡。像LaneGCN这样模型大、激活值也大的模型在Jetson上可能会因为频繁的内存访问而严重受限。此外持续的峰值算力运行也会导致芯片升温、触发降频从而进一步降低性能。5. 嵌入式部署优化实战让算法在芯片上“飞”起来面对性能滑坡我们不能坐以待毙。下面结合我们的实战经验分享一套从算法选型到底层优化的全链路部署策略。5.1 算法层面的优化设计之初就要考虑部署1. 模型轻量化与神经网络架构搜索选择高效算子用深度可分离卷积Depthwise Separable Conv替代标准卷积用循环门控单元GRU或时域卷积网络TCN替代计算更复杂的LSTM。DeepTrack论文就通过用TCN替代LSTM显著降低了计算量。精简网络结构减少Transformer的层数、注意力头数降低GNN的消息传递步数。可以通过神经网络架构搜索NAS针对目标硬件如Jetson Orin的GPU微架构搜索出精度-速度权衡最优的子网络。知识蒸馏用一个大模型教师模型指导一个小模型学生模型训练让小模型学到教师模型的“知识”从而在参数量大幅减少的情况下保持较高精度。2. 输入与表示的优化简化交互建模不是所有车辆都需要精细交互。可以设置一个距离或时域阈值只对“关键”周围车辆进行精细建模其余车辆用简单聚合如均值池化处理。向量化 vs 栅格化尽量使用向量化表示如折线、点序列而非栅格化图像BEV。后者会引入大量不必要的计算和内存开销。VectorNet的成功已经证明了向量化的高效性。预处理离线化尽可能将不依赖实时数据的预处理步骤如高精地图的静态特征提取离线计算并缓存。在车上运行时只需进行轻量的实时数据关联和坐标转换。5.2 系统与框架层面的优化1. 模型量化这是嵌入式部署性价比最高的优化手段没有之一。动态范围量化Post-Training Quantization, PTQ训练完成后将FP32模型直接量化为INT8。通常会有少量精度损失1-2%但能带来2-4倍的推理加速和4倍的内存节省。需要使用校准数据集来确定每一层激活值的动态范围。量化感知训练Quantization-Aware Training, QAT在训练过程中模拟量化操作让模型权重适应低精度表示。这能最大程度减少量化带来的精度损失通常能实现几乎无损的INT8量化。实操坑点Transformer模型中的Softmax、LayerNorm等算子对量化敏感需要框架如TensorRT的特殊支持或使用混合精度部分层保持FP16。2. 算子融合与图优化深度学习框架PyTorch, TensorFX生成的初始计算图通常包含许多细粒度算子导致频繁的内核启动和内存读写。使用专用推理引擎NVIDIA TensorRT或ONNX Runtime会自动进行大量的图优化包括算子融合将连续的Conv、BatchNorm、ReLU融合成一个单一的“CBR”算子大幅减少内存访问。常量折叠将计算图中可以预先计算的节点结果固定下来。内存复用智能地安排内存生命周期减少动态内存分配。定制化内核对于模型中的热点算子如自定义的注意力机制、图卷积可以手写CUDA或利用硬件厂商提供的专用库如NVIDIA的cuDNN, cuBLAS进行极致优化。3. 流水线与异步处理CPU-GPU/NPU流水线将预处理CPU、数据搬运PCIe、推理GPU/NPU、后处理CPU这几个阶段流水线化。当第N帧在GPU上推理时第N1帧可以在CPU上预处理。这能有效隐藏部分延迟。异步执行使用CUDA Streams或类似的异步编程模型让数据搬运和计算重叠进行最大化硬件利用率。5.3 针对特定模型的优化案例以CRAT-Pred和AutoBots为例针对 CRAT-Pred (GNN-based)图稀疏化车辆交互图通常是稀疏的。使用稀疏矩阵格式如CSR存储和计算可以大幅减少不必要的计算和内存。固定图大小为最坏情况最大车辆数分配固定内存避免运行时动态分配带来的开销和碎片。量化GNN中的聚合操作求和、求平均对量化相对友好可以尝试激进地量化到INT8。针对 AutoBots (Transformer-based)Flash Attention使用优化后的注意力算法降低计算复杂度和内存占用。键值缓存对于自回归解码如果使用缓存之前时间步的Key和Value避免重复计算。INT8 QATTransformer的线性层和注意力计算非常适合量化通过QAT通常能获得很好的INT8精度。简化位置编码探索更轻量的位置编码方式或甚至移除对预测性能影响不大的位置编码。6. 总结与展望走向实用化的轨迹预测回顾整个探索过程轨迹预测从算法创新到嵌入式落地是一条充满挑战但必须走通的路。我们的评估清晰地表明没有免费的午餐更高的预测精度如LaneGCN几乎总是以更高的计算复杂度为代价。在嵌入式部署中我们必须在精度、延迟、功耗之间做出艰难权衡。预处理是隐形瓶颈对于依赖高精地图的模型地图数据的实时处理、向量化、图构建等CPU端操作其耗时可能不亚于甚至超过GPU推理本身。算法设计应尽可能向“无地图”或“轻地图”方向演进。轻量化是必由之路CRAT-Pred这类轻量、专注核心问题如交互的模型在嵌入式平台上展现出更好的潜力。未来的研究应更注重效率优先的模型设计而不仅仅是刷榜精度。软硬协同优化是终极方案不能只盯着算法论文。必须深入了解目标硬件如Jetson Orin的Ampere架构、地平线征程5的BPU的特性利用其提供的专用指令、内存层次和计算单元通过量化、算子融合、流水线等工程手段将算法性能“压榨”到极致。未来的方向我个人认为会集中在以下几点面向芯片的模型设计Hardware-Aware NAS在设计阶段就将目标硬件的约束算力、内存、带宽作为优化目标的一部分。多任务学习与模型瘦身让轨迹预测模型与感知如目标检测、跟踪、定位任务共享主干网络特征减少总体计算负担。不确定性量化与安全边界对于嵌入式系统不仅要输出轨迹还要输出可靠的不确定性估计。下游的规划模块可以根据不确定性的大小来调整行为的激进/保守程度这是实现功能安全ISO 26262的关键。持续学习与场景适配如何让部署在车辆上的模型能够安全、高效地利用实际行驶数据对长尾场景Corner Cases进行持续优化也是一个重要的工程课题。轨迹预测的嵌入式部署是一场算法工程师与硬件工程师的共舞。只有双方深度协作理解彼此的约束与语言才能将实验室里的智能真正转化为道路上安全、可靠、实时的驾驶决策。这条路很长但每解决一个实际问题都让我们离真正的自动驾驶更近一步。