地平线征程6M官宣大规模量产上车城区NOA是如何一步步杀入10万级主流市场的在智能驾驶行业待久了你会发现一个特别明显的趋势高阶智驾不再只是 20 万、30 万以上新势力车型的“专属标签”越来越多的 10 万级家用车开始把“城区 NOA”写进配置单。而最近地平线征程 6M 官宣大规模量产上车又把“城区 NOA 下探到 10 万级主流市场”这个话题推到了风口浪尖。很多开发者朋友可能更熟悉的是征程 5、Orin、Orin-X 这一代大算力芯片对于征程 6 系列中的 6M 定位、架构差异、以及为什么它能带动城区 NOA 普及反而了解不多。这篇文章我想结合地平线征程 6M 量产上车的行业背景从芯片架构、智驾技术栈、量产落地和成本控制几个维度完整拆解一下城区 NOA 为什么能走进 10 万级市场以及征程 6M 在这中间扮演了什么样的角色。不管你是智能驾驶行业的算法工程师、做域控制器嵌入式的开发还是单纯关注汽车智能化趋势的产品经理这篇文章都能帮你把“征程 6M”和“城区 NOA 下探”这两件事的整体逻辑理清楚。1. 背景与核心概念征程 6M 是什么城区 NOA 又是什么1.1 征程 6M 的定位中阶智驾计算方案先来回答一个最基础的问题地平线征程 6M 是什么地平线征程系列是地平线推出的车载智能计算方案目前已经覆盖了从低阶辅助驾驶到高阶智能驾驶的多个算力区间。征程 6 是一个比较完整的家族系列里面包含征程 6B、征程 6M、征程 6H 等不同型号。这里的“M”并不是“Mini”的意思而是面向中阶主流智驾市场的主力型号。按照行业内的普遍理解征程 6M 的算力并不像 Orin-X 或征程 6H 那样夸张但它最大的特点是性价比和量产成熟度。它能够在满足城区 NOA 计算需求的前提下把整个域控制器的 BOM 成本控制在车企能够接受的范围内。用一句话概括征程 6M 就是为“让更多普通家用车用上城区 NOA”而生的计算平台。这里需要区分一下征程 6 系列不同型号的定位征程 6B主打低阶辅助驾驶比如基础的 L2 级功能。征程 6M面向中阶智驾支持城区 NOA是本文讨论的重点。征程 6H面向高阶智驾算力更高支持更复杂的城区场景和更多传感器接入。可以说征程 6M 是地平线在“智驾平权”战略下非常关键的一颗棋子。1.2 城区 NOA 到底是什么NOA 的全称是 Navigate on Autopilot中文可以理解为“领航辅助驾驶”。按照行驶场景不同可以细分为高速 NOA 和城区 NOA。高速 NOA 大家已经很熟悉了在高速公路或者城市快速路上车辆可以实现自动变道、自动超车、自动上下匝道等操作驾驶员只需要保持监督即可。城区 NOA 则要复杂得多。它指的是车辆在城市普通道路包括城市主干道、次干道、支路等上根据导航路径实现自动加减速、变道、转弯、绕行、通过红绿灯路口、避让行人和非机动车等一系列操作。为什么城区 NOA 比高速 NOA 难这么多因为城市道路的不确定性太大交通参与者种类多行人、自行车、电动车、三轮车、公交车、大型货车混杂。道路结构复杂路口形状不规则车道线可能磨损或缺失还有施工改道。交通规则多样化不同城市的红绿灯样式、待转区规则、公交车道限行规则都不完全一样。长尾场景多路边停车开门、前车突然加塞、交警现场指挥等这些场景几乎无法穷举。正是这些复杂因素导致城区 NOA 对芯片算力、算法模型、传感器配置和工程迭代能力都提出了很高的要求。1.3 为什么征程 6M 量产上车这件事值得关注过去一辆车要实现城区 NOA通常需要大算力芯片比如 Orin-X单片算力高达 254 TOPS外加激光雷达、高精地图等昂贵配置。整套系统成本可能高达数万元因此只有 30 万以上的高端车型才愿意搭载。而征程 6M 官宣大规模量产上车意味着城区 NOA 的硬件成本可以被压到一个新台阶让 10 万级的主流家用车也有机会搭载这一功能。这件事的本质是“高性能计算平台成本下探”与“算法工程化能力提升”共同推动的行业拐点。对于消费者来说10 万级车型也能拥有城区 NOA意味着智能驾驶开始从“少数人的尝鲜”变成“大众化的刚需功能”对于从业者来说这意味着整个智驾供应链的格局正在发生深刻变化。2. 环境准备与版本说明从开发者视角看征程 6M虽然普通消费者关注的是“哪款车能用上城区 NOA”但作为技术向的文章我们有必要从开发者视角出发看看征程 6M 作为一个计算平台到底需要什么样的开发环境和工具链。2.1 芯片平台基本参数关于征程 6M 的具体参数地平线官方在不同场合有过披露但最终以官方最新发布为准。从行业公开信息来看征程 6M 的主要特点包括面向中阶智驾市场算力比征程 5 有一定提升但功耗控制更优。支持 BEVBirds Eye View鸟瞰视角感知算法能够支持城区 NOA 的核心感知需求。配套地平线自研的 BPUBrain Processing Unit架构专门优化神经网络推理计算。支持多传感器接入包括摄像头、毫米波雷达等部分方案甚至可以在不使用激光雷达的情况下实现城区 NOA。2.2 开发环境与工具链对于算法工程师和嵌入式开发工程师来说真正关心的是在征程 6M 上做开发需要哪些工具和流程地平线为征程系列提供的开发工具链核心组件包括组件说明芯片 SDK提供底层驱动、运行时环境和算子库模型编译工具将 PyTorch / ONNX 等模型转换为芯片可执行的格式仿真器 / 调试工具在没有实车或开发板的情况下进行算法验证参考算法地平线提供的感知、融合、预测等参考算法模块开发征程 6M 上的算法大致流程如下在 PyTorch 等框架中完成模型训练和验证。使用地平线提供的模型转换工具将训练好的模型转换成芯片支持的格式。在仿真环境中进行性能评估和精度验证。部署到域控制器硬件上配合实车进行测试和调优。需要强调的是征程 6M 的算力是“够用”而不是“堆料”所以在算法部署时非常看重模型效率。同样一个 BEV 感知模型如何在保证精度的前提下把计算量压下来直接决定了最终效果的上限。这也是为什么地平线一直在强调“软硬协同设计”的原因。2.3 版本与适配提醒由于车载芯片的软件工具链迭代速度很快实际开发时一定要以地平线官方发布的 SDK 版本为准。不同版本的编译器对模型算子支持度可能有差异升级 SDK 时也需要重新验证算法性能和精度。如果你打算在征程 6M 上做项目建议先做两件事确认目标算法模型中用到的算子是否被当前工具链完整支持。提前用仿真工具估算模型在芯片上的推理延迟避免后期因为性能不达标而重构模型。3. 核心科技拆解征程 6M 和城区 NOA 背后的技术逻辑3.1 BEV 感知架构城区 NOA 的技术基石要理解城区 NOA首先必须理解 BEV 感知。传统自动驾驶感知是在“摄像头视角”下分别做目标检测然后通过后处理把多个视角的目标融合到一个世界坐标系中。这种方式在处理城区复杂场景时很容易出现漏检、误检尤其是目标被遮挡或者跨摄像头切换时。BEV 感知的思路则不同它通过神经网络把多个摄像头的图像特征直接转换到“鸟瞰视角”的俯视图空间在统一的 BEV 特征图上完成目标检测、车道线识别、可行驶区域分割等任务。这么做的好处非常明显多摄像头特征在 BEV 空间自然对齐不需要复杂的后处理融合。对遮挡目标的感知更鲁棒因为 BEV 特征是基于多视角信息构建的。下游的预测、规划模块可以直接在 BEV 空间上工作减少了坐标变换误差。征程 6M 对 BEV 感知的高效支持是它能够跑通城区 NOA 的关键原因之一。相比传统的前视单目方案BEV 方案更适应城区路口的复杂交通参与者和不规则道路结构。3.2 Transformer 与 Attention 机制在智驾中的应用除了 BEV另一个绕不开的技术是 Transformer。近几年 Transformer 架构在自然语言处理和视觉领域都取得了巨大成功自动驾驶感知也不例外。在城区 NOA 场景中Transformer 主要用于时序融合将多帧图像特征进行时序建模提升对动态目标的运动预测能力。跨模态融合将摄像头图像特征和雷达点云特征进行融合。端到端感知直接输入多摄像头图像输出 BEV 特征和结构化障碍物信息。不过 Transformer 模型的计算量通常比传统 CNN 大不少。征程 6M 在 BPU 架构设计上对 Transformer 中的 Attention 算子做了专门优化这也是为什么它能在有限算力下跑起复杂的 BEV Transformer 感知模型。3.3 城区 NOA 的功能模块全景完整的城区 NOA 系统并不仅仅是一个感知模型它通常包含以下几个主要模块模块核心功能技术挑战感知模块检测车辆、行人、骑行者、车道线、交通标志、可行驶区域长尾场景多恶劣天气鲁棒性预测模块预测周围交通参与者的未来轨迹交互行为复杂不确定性高规划模块生成车辆行驶轨迹包括变道、绕行、转弯需要考虑安全性、舒适性和交通规则控制模块将规划轨迹转化为方向盘、油门、刹车指令控制精度和车辆动力学匹配定位模块估计车辆在高精地图或导航地图中的位置城市高楼遮挡 GPS需要多源融合定位征程 6M 作为计算平台需要在这一整套流程中完成大量并行计算任务。也就是说它不仅仅要跑感知模型还需要为预测、规划、定位等模块预留算力。这就解释了为什么芯片算力不能只看峰值 TOPS还要看实际可用的有效算力和调度能力。3.4 征程 6M 的软硬协同设计地平线一直强调“软硬协同”意思是芯片架构和算法设计不是各自独立的而是在设计阶段就互相配合。举个例子如果算法工程师发现 BEV 感知模型中某个算子频繁出现芯片设计时就可以为这个算子做专门的硬件加速单元从而大幅提升计算效率。同样如果芯片架构已经固化了某些计算模式算法工程师在写模型时也可以主动调整网络结构让模型更好地利用硬件能力。征程 6M 的 BPU 架构正是这种思路的产物。它不是为了跑通用 AI 计算而设计的而是为了高效跑智能驾驶场景中的典型模型而优化。这种“软硬协同”带来的结果是在相同 TOPS 数下征程 6M 跑智驾模型的效率可能高于一些通用 AI 芯片。4. 完整实战案例模拟征程 6M 上 BEV 感知模型的开发优化流程这一节我们把视角切换到开发者以“在征程 6M 平台上部署一个简化版 BEV 目标检测模型”为例子演示从 PyTorch 模型到芯片部署的核心流程。注意这不是完整可运行生产代码而是演示核心思路具体 API 和工具链版本以官方文档为准。4.1 定义输入输出BEV 感知模型的典型输入是多路环视摄像头图像输出是 BEV 空间中的 3D 目标框。假设我们有 6 路摄像头每路图像分辨率经过预处理后为 640×360我们需要输出 200×200 的 BEV 栅格空间中的目标检测结果。4.2 简化版 BEV 感知模型为了理解在征程 6M 上跑 BEV 模型的基本范式我们先写一个简化版 BEV 感知模型的核心片段。这个模型做了极大简化仅用于流程展示# 简化版 BEV 感知模型示例仅供理解流程不可直接用于生产 import torch import torch.nn as nn class SimpleBEVBackbone(nn.Module): 简化版 BEV Backbone 输入多摄像头图像特征通过简单特征投影方式生成 BEV 特征图。 实际量产方案中通常会使用更复杂的视角转换模块。 def __init__(self, in_channels64, bev_size(200, 200)): super().__init__() # 将图像特征编码为 BEV 空间的简化卷积层 self.shared_encoder nn.Sequential( nn.Conv2d(in_channels, 64, kernel_size3, padding1), nn.BatchNorm2d(64), nn.ReLU(inplaceTrue), ) self.bev_decoder nn.Sequential( nn.Conv2d(64, 64, kernel_size3, padding1), nn.ReLU(inplaceTrue), ) def forward(self, multi_cam_features): # multi_cam_features: list of tensors, each shape [B, C, H, W] encoded [self.shared_encoder(f) for f in multi_cam_features] # 简化对多个摄像头特征直接求和实际项目中需要通过 IPM 或 transformer # 将特征投影到统一 BEV 空间 bev_feature torch.stack(encoded).sum(dim0) bev_feature self.bev_decoder(bev_feature) return bev_feature class SimpleBEVDetector(nn.Module): 在 BEV 特征上做目标检测的简化模块。 实际项目中会包含分类头、回归头以及后处理逻辑。 def __init__(self, num_classes3): super().__init__() self.cls_head nn.Conv2d(64, num_classes, kernel_size1) def forward(self, bev_feature): cls_pred self.cls_head(bev_feature) return cls_pred这段代码的核心目的是展示 BEV 模型的基本结构先对每个摄像头的图像特征做编码然后在统一的 BEV 空间做特征融合最后接检测头输出目标类别。真实量产方案中多摄像头特征到 BEV 空间的投影通常需要使用 IPM逆透视变换或者基于 Transformer 的交叉注意力机制计算量更大精度也更高。4.3 模型量化和转换思路在征程 6M 上部署模型不能直接把 PyTorch 的权重文件丢上去而是需要经过模型转换和量化。核心流程如下# 伪代码/简化命令具体以地平线工具链为准 # 1. 将 PyTorch 模型导出为 ONNX python export_onnx.py --checkpoint model.pth --output model.onnx # 2. 使用地平线模型转换工具进行编译和量化 # hb_compile 是地平线工具链中的命令行工具名称仅为示例 hb_compile --model model.onnx \ --input-shape 6x3x360x640 \ --output model.hbm \ --calibration-dataset calib_data量化是一个非常重要的环节。征程 6M 为了提升计算效率通常会使用 INT8 量化来减少计算量和内存带宽。但量化会带来一定的精度损失因此需要准备一个有代表性的校准数据集尽可能覆盖各种场景。4.4 性能调优建议部署到征程 6M 后如果发现模型推理延迟不达标可以从以下几个角度优化减少输入分辨率在精度可接受的前提下把摄像头输入从 1280×720 降到 960×540 或 640×360能显著降低计算量。精简 Backbone使用轻量化网络结构如 MobileNet 风格的 block替换重型 Backbone。算子融合部分模型转换工具会自动完成 ConvBNReLU 的算子融合但也可以手动调整网络结构帮助工具链做优化。多线程流水线在征程 6M 上可以将感知、预测、规划放到不同计算流水线上通过异步调度降低端到端延迟。5. 城区 NOA 下探到 10 万级市场的关键因素征程 6M 量产上车不是孤立事件它的背后是“城区 NOA 从高端走向主流”的行业趋势。为什么这件事偏偏在 2024 到 2025 年这个时间点发生了我认为有几个核心因素。5.1 成本控制去掉激光雷达纯视觉方案崛起早期城区 NOA 方案几乎都依赖激光雷达因为激光雷达可以提供精确的距离信息降低感知难度。但激光雷达的成本在过去几年虽然大幅下降仍然在千元到数千元级别对于 10 万级车型来说依然是一笔不小的负担。征程 6M 量产的背后意味着纯视觉或“摄像头 毫米波雷达”方案已经能够胜任城区 NOA 的大部分场景。去掉激光雷达后整套系统的硬件成本可以下降一个数量级这才让 10 万级车型有搭载的可能。当然这并不意味着激光雷达没有价值。在极端天气、夜间逆光等场景下激光雷达仍然有不可替代的优势。但在“够用就好”的主流车型上纯视觉方案的性价比优势非常明显。5.2 算法效率提升用更少的算力干更多的事芯片算力提升是一方面算法效率提升是另一方面。过去几年BEVTransformer 方案的成熟让模型可以在相同算力条件下实现更好的感知效果。与此同时模型蒸馏、量化、剪枝等模型压缩技术的应用也越来越广泛。算法工程师可以在高算力平台上训练超大模型然后通过知识蒸馏的方式将大模型的能力“压缩”到一个小模型中部署到征程 6M 这样的中阶算力平台上。可以这么说征程 6M 在硬件上定义了“10 万级车型算力基线”而算法效率的提升则让这个基线之上能够跑起足够好的城区 NOA。5.3 数据闭环和仿真能力的成熟城区 NOA 落地最难的不是写代码而是解决长尾问题。城市道路场景千变万化靠人工标注和实车路测根本覆盖不过来。所以真正让城区 NOA 能够规模化的是数据闭环体系的成熟量产车在路上行驶时会不断回传遇到的长尾场景数据工程师筛选这些数据重新训练模型再通过仿真验证模型效果最后通过 OTA 推送到用户车辆上。征程 6M 作为量产芯片量大之后可以带来海量的真实道路数据这反过来又促进了算法的迭代。可以说征程 6M 的量产不只是卖芯片它为整个地平线智驾生态提供了数据飞轮。5.4 工程化能力芯片 工具链 参考方案最后一点也是很多芯片公司最难做到的一点完整的工程化能力。车企选择智能驾驶芯片时不只看算力还要看工具链是否成熟能不能快速完成模型移植。参考方案是否完整能不能直接拿来改。技术支持是否及时有没有完整的文档和示例代码。地平线通过多年的量产经验积累在工具链和参考方案方面相对成熟。征程 6M 能够快速在多家车企大规模上车靠的不只是芯片本身而是整个围绕芯片的工具链和服务体系。6. 常见问题与排查思路车企和开发者视角6.1 从开发者视角看常见问题问题现象常见原因解决思路模型编译失败使用了工具链不支持的算子查看算子支持列表替换为支持算子或手写自定义算子量化后精度下降明显校准数据集与真实场景分布不一致扩充校准集覆盖不同天气、光线、城市场景端到端延迟过高模型计算量过大或未做多线程调度降低输入分辨率精简模型结构优化流水线调度多摄像头时间戳不同步相机硬件触发信号未对齐使用硬件同步信号确保各摄像头采集时间一致性6.2 从车企视角看常见问题问题现象常见原因解决思路城区 NOA 在特定城市表现差该城市场景在训练数据中覆盖不足补充当地数据做针对性模型迭代系统误刹车/漏检感知模型对长尾场景泛化不足建立数据闭环持续挖掘和训练长尾场景用户对 NOA 接管率不满意城区 NOA 能力边界不够清晰做好用户预期管理明确功能边界和适用场景域控散热和功耗超标芯片 外围器件整体功耗过高优化电源管理策略降频或调整任务调度7. 最佳实践与工程建议7.1 对算法工程师的建议在征程 6M 这类中阶算力平台上做城区 NOA 算法和在高算力平台上做研究是完全不同的思路。首先要把“算力预算”作为模型设计的第一约束。从一开始就明确感知模型、预测模型各分配多少算力。不要先设计一个超大模型再想办法压缩而是在设计之初就选择轻量化的网络结构。其次要重视量化感知训练。INT8 量化会带来精度损失如果在训练阶段不加入量化感知部署阶段很容易出现精度崩塌。建议在训练时使用 QAT量化感知训练让模型参数在训练过程中适配低比特量化的计算方式。最后要建立完整的评测体系。城区 NOA 的算法效果不能只看公开数据集指标必须在自己的测试场景集上进行验证。特别是要对长尾场景建立专项测试集比如逆光、雨天、夜间、施工路段、无车道线路口等。7.2 对嵌入式开发工程师的建议征程 6M 的量产方案是多芯片、多传感器协同的复杂系统嵌入式软件层面的工程能力直接影响系统稳定性。建议重点关注下面几点第一做好多传感器时间同步。城区 NOA 对传感器时间同步要求极高如果摄像头和毫米波雷达的时间戳偏差过大融合后的感知结果会出现目标位置错位。需要使用硬件信号同步机制并在软件层面对齐时间戳。第二警惕资源争抢问题。征程 6M 上同时运行着感知、预测、规划、控制等多个模块如果某个模块出现 CPU 或内存占用尖峰可能会影响其他模块的实时性。建议对计算资源做分区隔离并设置优先级。第三重视日志和故障记录。量产车在用户手中会遇到各种极端情况需要完善的日志记录机制将传感器状态、算法输出和控制器指令都记录下来方便售后问题回溯。7.3 对产品经理和决策者的建议对于车企产品经理来说看待征程 6M 带来的城区 NOA 下探机会需要注意几点不要为了“标配城区 NOA”而牺牲安全底线。10 万级车型的传感器配置和算力平台都有上限必须明确城区 NOA 的功能边界比如在恶劣天气、无车道线道路、复杂施工路段等场景下要及时退出或降低功能等级。要做好用户预期管理。城区 NOA 不是全自动驾驶用户在体验过程中仍然需要保持注意力。产品包装上不能过度宣传“自动驾驶”否则一旦发生事故品牌将面临严重的信任危机。此外要注意智驾系统的持续迭代成本。硬件上车只是开始后续的数据采集、模型训练、OTA 推送都需要持续投入。如果只把点子芯片卖点而不建立数据闭环体系城区 NOA 的用户体验很快就会落后于竞争对手。8. 总结与下一步学习方向2025 年的智能驾驶行业城区 NOA 正在经历一个从“高端尝鲜”到“主流标配”的关键转折。地平线征程 6M 官宣大规模量产上车标志着这一转折正在 10 万级主流汽车市场真实发生。这背后不只是一颗芯片的算力提升更是 BEV 感知、Transformer 模型、数据闭环、工具链工程化、成本控制等多个维度共同进步的结果。对于智驾从业者来说理解征程 6M 和城区 NOA 的落地方案不能只看芯片参数表而要理解整套系统的架构设计和工程取舍。下一步如果你想继续深入学习建议从以下几个方向入手学习 BEV 感知的前沿论文理解从图像空间到 BEV 空间的几种主流特征转换方式。研究量产智驾的传感器配置方案比较纯视觉和“摄像头 毫米波雷达”在不同场景下的优劣。深入了解模型量化、知识蒸馏等模型压缩技术这些是中阶算力平台上部署算法的关键能力。关注地平线工具链和开发者文档尝试在仿真环境中跑通一个完整的感知模型部署流程。从行业趋势来看未来两年 10 万级车型搭载城区 NOA 会越来越普遍征程 6M 只是这条道路上的一个阶段性标志。作为开发者或行业关注者现在开始积累中阶算力平台上的智驾开发经验是个不错的时间点。 地平线征程6M量产上车，城区NOA如何下探10万级市场？
地平线征程6M官宣大规模量产上车城区NOA是如何一步步杀入10万级主流市场的在智能驾驶行业待久了你会发现一个特别明显的趋势高阶智驾不再只是 20 万、30 万以上新势力车型的“专属标签”越来越多的 10 万级家用车开始把“城区 NOA”写进配置单。而最近地平线征程 6M 官宣大规模量产上车又把“城区 NOA 下探到 10 万级主流市场”这个话题推到了风口浪尖。很多开发者朋友可能更熟悉的是征程 5、Orin、Orin-X 这一代大算力芯片对于征程 6 系列中的 6M 定位、架构差异、以及为什么它能带动城区 NOA 普及反而了解不多。这篇文章我想结合地平线征程 6M 量产上车的行业背景从芯片架构、智驾技术栈、量产落地和成本控制几个维度完整拆解一下城区 NOA 为什么能走进 10 万级市场以及征程 6M 在这中间扮演了什么样的角色。不管你是智能驾驶行业的算法工程师、做域控制器嵌入式的开发还是单纯关注汽车智能化趋势的产品经理这篇文章都能帮你把“征程 6M”和“城区 NOA 下探”这两件事的整体逻辑理清楚。1. 背景与核心概念征程 6M 是什么城区 NOA 又是什么1.1 征程 6M 的定位中阶智驾计算方案先来回答一个最基础的问题地平线征程 6M 是什么地平线征程系列是地平线推出的车载智能计算方案目前已经覆盖了从低阶辅助驾驶到高阶智能驾驶的多个算力区间。征程 6 是一个比较完整的家族系列里面包含征程 6B、征程 6M、征程 6H 等不同型号。这里的“M”并不是“Mini”的意思而是面向中阶主流智驾市场的主力型号。按照行业内的普遍理解征程 6M 的算力并不像 Orin-X 或征程 6H 那样夸张但它最大的特点是性价比和量产成熟度。它能够在满足城区 NOA 计算需求的前提下把整个域控制器的 BOM 成本控制在车企能够接受的范围内。用一句话概括征程 6M 就是为“让更多普通家用车用上城区 NOA”而生的计算平台。这里需要区分一下征程 6 系列不同型号的定位征程 6B主打低阶辅助驾驶比如基础的 L2 级功能。征程 6M面向中阶智驾支持城区 NOA是本文讨论的重点。征程 6H面向高阶智驾算力更高支持更复杂的城区场景和更多传感器接入。可以说征程 6M 是地平线在“智驾平权”战略下非常关键的一颗棋子。1.2 城区 NOA 到底是什么NOA 的全称是 Navigate on Autopilot中文可以理解为“领航辅助驾驶”。按照行驶场景不同可以细分为高速 NOA 和城区 NOA。高速 NOA 大家已经很熟悉了在高速公路或者城市快速路上车辆可以实现自动变道、自动超车、自动上下匝道等操作驾驶员只需要保持监督即可。城区 NOA 则要复杂得多。它指的是车辆在城市普通道路包括城市主干道、次干道、支路等上根据导航路径实现自动加减速、变道、转弯、绕行、通过红绿灯路口、避让行人和非机动车等一系列操作。为什么城区 NOA 比高速 NOA 难这么多因为城市道路的不确定性太大交通参与者种类多行人、自行车、电动车、三轮车、公交车、大型货车混杂。道路结构复杂路口形状不规则车道线可能磨损或缺失还有施工改道。交通规则多样化不同城市的红绿灯样式、待转区规则、公交车道限行规则都不完全一样。长尾场景多路边停车开门、前车突然加塞、交警现场指挥等这些场景几乎无法穷举。正是这些复杂因素导致城区 NOA 对芯片算力、算法模型、传感器配置和工程迭代能力都提出了很高的要求。1.3 为什么征程 6M 量产上车这件事值得关注过去一辆车要实现城区 NOA通常需要大算力芯片比如 Orin-X单片算力高达 254 TOPS外加激光雷达、高精地图等昂贵配置。整套系统成本可能高达数万元因此只有 30 万以上的高端车型才愿意搭载。而征程 6M 官宣大规模量产上车意味着城区 NOA 的硬件成本可以被压到一个新台阶让 10 万级的主流家用车也有机会搭载这一功能。这件事的本质是“高性能计算平台成本下探”与“算法工程化能力提升”共同推动的行业拐点。对于消费者来说10 万级车型也能拥有城区 NOA意味着智能驾驶开始从“少数人的尝鲜”变成“大众化的刚需功能”对于从业者来说这意味着整个智驾供应链的格局正在发生深刻变化。2. 环境准备与版本说明从开发者视角看征程 6M虽然普通消费者关注的是“哪款车能用上城区 NOA”但作为技术向的文章我们有必要从开发者视角出发看看征程 6M 作为一个计算平台到底需要什么样的开发环境和工具链。2.1 芯片平台基本参数关于征程 6M 的具体参数地平线官方在不同场合有过披露但最终以官方最新发布为准。从行业公开信息来看征程 6M 的主要特点包括面向中阶智驾市场算力比征程 5 有一定提升但功耗控制更优。支持 BEVBirds Eye View鸟瞰视角感知算法能够支持城区 NOA 的核心感知需求。配套地平线自研的 BPUBrain Processing Unit架构专门优化神经网络推理计算。支持多传感器接入包括摄像头、毫米波雷达等部分方案甚至可以在不使用激光雷达的情况下实现城区 NOA。2.2 开发环境与工具链对于算法工程师和嵌入式开发工程师来说真正关心的是在征程 6M 上做开发需要哪些工具和流程地平线为征程系列提供的开发工具链核心组件包括组件说明芯片 SDK提供底层驱动、运行时环境和算子库模型编译工具将 PyTorch / ONNX 等模型转换为芯片可执行的格式仿真器 / 调试工具在没有实车或开发板的情况下进行算法验证参考算法地平线提供的感知、融合、预测等参考算法模块开发征程 6M 上的算法大致流程如下在 PyTorch 等框架中完成模型训练和验证。使用地平线提供的模型转换工具将训练好的模型转换成芯片支持的格式。在仿真环境中进行性能评估和精度验证。部署到域控制器硬件上配合实车进行测试和调优。需要强调的是征程 6M 的算力是“够用”而不是“堆料”所以在算法部署时非常看重模型效率。同样一个 BEV 感知模型如何在保证精度的前提下把计算量压下来直接决定了最终效果的上限。这也是为什么地平线一直在强调“软硬协同设计”的原因。2.3 版本与适配提醒由于车载芯片的软件工具链迭代速度很快实际开发时一定要以地平线官方发布的 SDK 版本为准。不同版本的编译器对模型算子支持度可能有差异升级 SDK 时也需要重新验证算法性能和精度。如果你打算在征程 6M 上做项目建议先做两件事确认目标算法模型中用到的算子是否被当前工具链完整支持。提前用仿真工具估算模型在芯片上的推理延迟避免后期因为性能不达标而重构模型。3. 核心科技拆解征程 6M 和城区 NOA 背后的技术逻辑3.1 BEV 感知架构城区 NOA 的技术基石要理解城区 NOA首先必须理解 BEV 感知。传统自动驾驶感知是在“摄像头视角”下分别做目标检测然后通过后处理把多个视角的目标融合到一个世界坐标系中。这种方式在处理城区复杂场景时很容易出现漏检、误检尤其是目标被遮挡或者跨摄像头切换时。BEV 感知的思路则不同它通过神经网络把多个摄像头的图像特征直接转换到“鸟瞰视角”的俯视图空间在统一的 BEV 特征图上完成目标检测、车道线识别、可行驶区域分割等任务。这么做的好处非常明显多摄像头特征在 BEV 空间自然对齐不需要复杂的后处理融合。对遮挡目标的感知更鲁棒因为 BEV 特征是基于多视角信息构建的。下游的预测、规划模块可以直接在 BEV 空间上工作减少了坐标变换误差。征程 6M 对 BEV 感知的高效支持是它能够跑通城区 NOA 的关键原因之一。相比传统的前视单目方案BEV 方案更适应城区路口的复杂交通参与者和不规则道路结构。3.2 Transformer 与 Attention 机制在智驾中的应用除了 BEV另一个绕不开的技术是 Transformer。近几年 Transformer 架构在自然语言处理和视觉领域都取得了巨大成功自动驾驶感知也不例外。在城区 NOA 场景中Transformer 主要用于时序融合将多帧图像特征进行时序建模提升对动态目标的运动预测能力。跨模态融合将摄像头图像特征和雷达点云特征进行融合。端到端感知直接输入多摄像头图像输出 BEV 特征和结构化障碍物信息。不过 Transformer 模型的计算量通常比传统 CNN 大不少。征程 6M 在 BPU 架构设计上对 Transformer 中的 Attention 算子做了专门优化这也是为什么它能在有限算力下跑起复杂的 BEV Transformer 感知模型。3.3 城区 NOA 的功能模块全景完整的城区 NOA 系统并不仅仅是一个感知模型它通常包含以下几个主要模块模块核心功能技术挑战感知模块检测车辆、行人、骑行者、车道线、交通标志、可行驶区域长尾场景多恶劣天气鲁棒性预测模块预测周围交通参与者的未来轨迹交互行为复杂不确定性高规划模块生成车辆行驶轨迹包括变道、绕行、转弯需要考虑安全性、舒适性和交通规则控制模块将规划轨迹转化为方向盘、油门、刹车指令控制精度和车辆动力学匹配定位模块估计车辆在高精地图或导航地图中的位置城市高楼遮挡 GPS需要多源融合定位征程 6M 作为计算平台需要在这一整套流程中完成大量并行计算任务。也就是说它不仅仅要跑感知模型还需要为预测、规划、定位等模块预留算力。这就解释了为什么芯片算力不能只看峰值 TOPS还要看实际可用的有效算力和调度能力。3.4 征程 6M 的软硬协同设计地平线一直强调“软硬协同”意思是芯片架构和算法设计不是各自独立的而是在设计阶段就互相配合。举个例子如果算法工程师发现 BEV 感知模型中某个算子频繁出现芯片设计时就可以为这个算子做专门的硬件加速单元从而大幅提升计算效率。同样如果芯片架构已经固化了某些计算模式算法工程师在写模型时也可以主动调整网络结构让模型更好地利用硬件能力。征程 6M 的 BPU 架构正是这种思路的产物。它不是为了跑通用 AI 计算而设计的而是为了高效跑智能驾驶场景中的典型模型而优化。这种“软硬协同”带来的结果是在相同 TOPS 数下征程 6M 跑智驾模型的效率可能高于一些通用 AI 芯片。4. 完整实战案例模拟征程 6M 上 BEV 感知模型的开发优化流程这一节我们把视角切换到开发者以“在征程 6M 平台上部署一个简化版 BEV 目标检测模型”为例子演示从 PyTorch 模型到芯片部署的核心流程。注意这不是完整可运行生产代码而是演示核心思路具体 API 和工具链版本以官方文档为准。4.1 定义输入输出BEV 感知模型的典型输入是多路环视摄像头图像输出是 BEV 空间中的 3D 目标框。假设我们有 6 路摄像头每路图像分辨率经过预处理后为 640×360我们需要输出 200×200 的 BEV 栅格空间中的目标检测结果。4.2 简化版 BEV 感知模型为了理解在征程 6M 上跑 BEV 模型的基本范式我们先写一个简化版 BEV 感知模型的核心片段。这个模型做了极大简化仅用于流程展示# 简化版 BEV 感知模型示例仅供理解流程不可直接用于生产 import torch import torch.nn as nn class SimpleBEVBackbone(nn.Module): 简化版 BEV Backbone 输入多摄像头图像特征通过简单特征投影方式生成 BEV 特征图。 实际量产方案中通常会使用更复杂的视角转换模块。 def __init__(self, in_channels64, bev_size(200, 200)): super().__init__() # 将图像特征编码为 BEV 空间的简化卷积层 self.shared_encoder nn.Sequential( nn.Conv2d(in_channels, 64, kernel_size3, padding1), nn.BatchNorm2d(64), nn.ReLU(inplaceTrue), ) self.bev_decoder nn.Sequential( nn.Conv2d(64, 64, kernel_size3, padding1), nn.ReLU(inplaceTrue), ) def forward(self, multi_cam_features): # multi_cam_features: list of tensors, each shape [B, C, H, W] encoded [self.shared_encoder(f) for f in multi_cam_features] # 简化对多个摄像头特征直接求和实际项目中需要通过 IPM 或 transformer # 将特征投影到统一 BEV 空间 bev_feature torch.stack(encoded).sum(dim0) bev_feature self.bev_decoder(bev_feature) return bev_feature class SimpleBEVDetector(nn.Module): 在 BEV 特征上做目标检测的简化模块。 实际项目中会包含分类头、回归头以及后处理逻辑。 def __init__(self, num_classes3): super().__init__() self.cls_head nn.Conv2d(64, num_classes, kernel_size1) def forward(self, bev_feature): cls_pred self.cls_head(bev_feature) return cls_pred这段代码的核心目的是展示 BEV 模型的基本结构先对每个摄像头的图像特征做编码然后在统一的 BEV 空间做特征融合最后接检测头输出目标类别。真实量产方案中多摄像头特征到 BEV 空间的投影通常需要使用 IPM逆透视变换或者基于 Transformer 的交叉注意力机制计算量更大精度也更高。4.3 模型量化和转换思路在征程 6M 上部署模型不能直接把 PyTorch 的权重文件丢上去而是需要经过模型转换和量化。核心流程如下# 伪代码/简化命令具体以地平线工具链为准 # 1. 将 PyTorch 模型导出为 ONNX python export_onnx.py --checkpoint model.pth --output model.onnx # 2. 使用地平线模型转换工具进行编译和量化 # hb_compile 是地平线工具链中的命令行工具名称仅为示例 hb_compile --model model.onnx \ --input-shape 6x3x360x640 \ --output model.hbm \ --calibration-dataset calib_data量化是一个非常重要的环节。征程 6M 为了提升计算效率通常会使用 INT8 量化来减少计算量和内存带宽。但量化会带来一定的精度损失因此需要准备一个有代表性的校准数据集尽可能覆盖各种场景。4.4 性能调优建议部署到征程 6M 后如果发现模型推理延迟不达标可以从以下几个角度优化减少输入分辨率在精度可接受的前提下把摄像头输入从 1280×720 降到 960×540 或 640×360能显著降低计算量。精简 Backbone使用轻量化网络结构如 MobileNet 风格的 block替换重型 Backbone。算子融合部分模型转换工具会自动完成 ConvBNReLU 的算子融合但也可以手动调整网络结构帮助工具链做优化。多线程流水线在征程 6M 上可以将感知、预测、规划放到不同计算流水线上通过异步调度降低端到端延迟。5. 城区 NOA 下探到 10 万级市场的关键因素征程 6M 量产上车不是孤立事件它的背后是“城区 NOA 从高端走向主流”的行业趋势。为什么这件事偏偏在 2024 到 2025 年这个时间点发生了我认为有几个核心因素。5.1 成本控制去掉激光雷达纯视觉方案崛起早期城区 NOA 方案几乎都依赖激光雷达因为激光雷达可以提供精确的距离信息降低感知难度。但激光雷达的成本在过去几年虽然大幅下降仍然在千元到数千元级别对于 10 万级车型来说依然是一笔不小的负担。征程 6M 量产的背后意味着纯视觉或“摄像头 毫米波雷达”方案已经能够胜任城区 NOA 的大部分场景。去掉激光雷达后整套系统的硬件成本可以下降一个数量级这才让 10 万级车型有搭载的可能。当然这并不意味着激光雷达没有价值。在极端天气、夜间逆光等场景下激光雷达仍然有不可替代的优势。但在“够用就好”的主流车型上纯视觉方案的性价比优势非常明显。5.2 算法效率提升用更少的算力干更多的事芯片算力提升是一方面算法效率提升是另一方面。过去几年BEVTransformer 方案的成熟让模型可以在相同算力条件下实现更好的感知效果。与此同时模型蒸馏、量化、剪枝等模型压缩技术的应用也越来越广泛。算法工程师可以在高算力平台上训练超大模型然后通过知识蒸馏的方式将大模型的能力“压缩”到一个小模型中部署到征程 6M 这样的中阶算力平台上。可以这么说征程 6M 在硬件上定义了“10 万级车型算力基线”而算法效率的提升则让这个基线之上能够跑起足够好的城区 NOA。5.3 数据闭环和仿真能力的成熟城区 NOA 落地最难的不是写代码而是解决长尾问题。城市道路场景千变万化靠人工标注和实车路测根本覆盖不过来。所以真正让城区 NOA 能够规模化的是数据闭环体系的成熟量产车在路上行驶时会不断回传遇到的长尾场景数据工程师筛选这些数据重新训练模型再通过仿真验证模型效果最后通过 OTA 推送到用户车辆上。征程 6M 作为量产芯片量大之后可以带来海量的真实道路数据这反过来又促进了算法的迭代。可以说征程 6M 的量产不只是卖芯片它为整个地平线智驾生态提供了数据飞轮。5.4 工程化能力芯片 工具链 参考方案最后一点也是很多芯片公司最难做到的一点完整的工程化能力。车企选择智能驾驶芯片时不只看算力还要看工具链是否成熟能不能快速完成模型移植。参考方案是否完整能不能直接拿来改。技术支持是否及时有没有完整的文档和示例代码。地平线通过多年的量产经验积累在工具链和参考方案方面相对成熟。征程 6M 能够快速在多家车企大规模上车靠的不只是芯片本身而是整个围绕芯片的工具链和服务体系。6. 常见问题与排查思路车企和开发者视角6.1 从开发者视角看常见问题问题现象常见原因解决思路模型编译失败使用了工具链不支持的算子查看算子支持列表替换为支持算子或手写自定义算子量化后精度下降明显校准数据集与真实场景分布不一致扩充校准集覆盖不同天气、光线、城市场景端到端延迟过高模型计算量过大或未做多线程调度降低输入分辨率精简模型结构优化流水线调度多摄像头时间戳不同步相机硬件触发信号未对齐使用硬件同步信号确保各摄像头采集时间一致性6.2 从车企视角看常见问题问题现象常见原因解决思路城区 NOA 在特定城市表现差该城市场景在训练数据中覆盖不足补充当地数据做针对性模型迭代系统误刹车/漏检感知模型对长尾场景泛化不足建立数据闭环持续挖掘和训练长尾场景用户对 NOA 接管率不满意城区 NOA 能力边界不够清晰做好用户预期管理明确功能边界和适用场景域控散热和功耗超标芯片 外围器件整体功耗过高优化电源管理策略降频或调整任务调度7. 最佳实践与工程建议7.1 对算法工程师的建议在征程 6M 这类中阶算力平台上做城区 NOA 算法和在高算力平台上做研究是完全不同的思路。首先要把“算力预算”作为模型设计的第一约束。从一开始就明确感知模型、预测模型各分配多少算力。不要先设计一个超大模型再想办法压缩而是在设计之初就选择轻量化的网络结构。其次要重视量化感知训练。INT8 量化会带来精度损失如果在训练阶段不加入量化感知部署阶段很容易出现精度崩塌。建议在训练时使用 QAT量化感知训练让模型参数在训练过程中适配低比特量化的计算方式。最后要建立完整的评测体系。城区 NOA 的算法效果不能只看公开数据集指标必须在自己的测试场景集上进行验证。特别是要对长尾场景建立专项测试集比如逆光、雨天、夜间、施工路段、无车道线路口等。7.2 对嵌入式开发工程师的建议征程 6M 的量产方案是多芯片、多传感器协同的复杂系统嵌入式软件层面的工程能力直接影响系统稳定性。建议重点关注下面几点第一做好多传感器时间同步。城区 NOA 对传感器时间同步要求极高如果摄像头和毫米波雷达的时间戳偏差过大融合后的感知结果会出现目标位置错位。需要使用硬件信号同步机制并在软件层面对齐时间戳。第二警惕资源争抢问题。征程 6M 上同时运行着感知、预测、规划、控制等多个模块如果某个模块出现 CPU 或内存占用尖峰可能会影响其他模块的实时性。建议对计算资源做分区隔离并设置优先级。第三重视日志和故障记录。量产车在用户手中会遇到各种极端情况需要完善的日志记录机制将传感器状态、算法输出和控制器指令都记录下来方便售后问题回溯。7.3 对产品经理和决策者的建议对于车企产品经理来说看待征程 6M 带来的城区 NOA 下探机会需要注意几点不要为了“标配城区 NOA”而牺牲安全底线。10 万级车型的传感器配置和算力平台都有上限必须明确城区 NOA 的功能边界比如在恶劣天气、无车道线道路、复杂施工路段等场景下要及时退出或降低功能等级。要做好用户预期管理。城区 NOA 不是全自动驾驶用户在体验过程中仍然需要保持注意力。产品包装上不能过度宣传“自动驾驶”否则一旦发生事故品牌将面临严重的信任危机。此外要注意智驾系统的持续迭代成本。硬件上车只是开始后续的数据采集、模型训练、OTA 推送都需要持续投入。如果只把点子芯片卖点而不建立数据闭环体系城区 NOA 的用户体验很快就会落后于竞争对手。8. 总结与下一步学习方向2025 年的智能驾驶行业城区 NOA 正在经历一个从“高端尝鲜”到“主流标配”的关键转折。地平线征程 6M 官宣大规模量产上车标志着这一转折正在 10 万级主流汽车市场真实发生。这背后不只是一颗芯片的算力提升更是 BEV 感知、Transformer 模型、数据闭环、工具链工程化、成本控制等多个维度共同进步的结果。对于智驾从业者来说理解征程 6M 和城区 NOA 的落地方案不能只看芯片参数表而要理解整套系统的架构设计和工程取舍。下一步如果你想继续深入学习建议从以下几个方向入手学习 BEV 感知的前沿论文理解从图像空间到 BEV 空间的几种主流特征转换方式。研究量产智驾的传感器配置方案比较纯视觉和“摄像头 毫米波雷达”在不同场景下的优劣。深入了解模型量化、知识蒸馏等模型压缩技术这些是中阶算力平台上部署算法的关键能力。关注地平线工具链和开发者文档尝试在仿真环境中跑通一个完整的感知模型部署流程。从行业趋势来看未来两年 10 万级车型搭载城区 NOA 会越来越普遍征程 6M 只是这条道路上的一个阶段性标志。作为开发者或行业关注者现在开始积累中阶算力平台上的智驾开发经验是个不错的时间点。