智驾行业这几年,最不缺的词就是算力。从英伟达Orin到Thor,从Mobileye EyeQ系列到高通Snapdragon Ride,动辄几百甚至上千TOPS的发布会参数,把整个行业卷成了一台“算力军备竞赛”。可你要是真的蹲在项目一线,盯着这些芯片参数和Demo跑分,大概率会发现一个残酷的事实:算力再高,跑不通量产就是一堆硅片。真正决定一套智驾平台能不能上车、能不能在corner case里兜住底、能不能持续迭代的,往往是芯片背后的计算架构、控制策略和数据闭环逻辑。而这些东西,翻产品发布会是看不到的,得去翻专利。
专利这个东西很有意思。它不像论文那样追求“看起来正确”,也不像发布会那样追求“听起来厉害”。专利的本质是工程和商业的合约物,里面写的是一个团队真正打算怎么解决某个问题、用什么结构替代什么结构、在哪一层做冗余、在哪一段做裁断。你如果把智驾头部玩家近几年公开的专利串起来,会发现一条特别清晰的暗线:从算力竞赛,到架构进化。这篇文章,我就想结合专利视角,把这几年智驾计算平台与控制决策领域的底层逻辑拆一遍,聊聊为什么堆算力堆不出城市NOA,为什么控制决策从规则时代慢慢被卷入AI原生,以及“架构”这两个字背后到底藏了哪些专利技术点。
1. 算力竞赛的表象与底层逻辑
1.1 数据背后的“物理课”:TOPS到底在衡量什么
很多人一看到TOPS就肾上腺素飙升,觉得240和508差一倍,系统就一定强一倍。这个理解,在工程上是不成立的。TOPS全称是Tera Operations Per Second,也就是每秒万亿次操作。但注意,这里的“操作”指的是定点整数运算,通常在INT8数据精度下定义。问题在于,一个卷积层的计算如果经过量化、稀疏化、剪枝之后,实际有效算力和标称算力能差出好几个量级。比如某芯片标称256 TOPS,如果编译器对稀疏权重的支持好,实际跑稀疏网络时可能等效翻倍;反过来,如果芯片固件里对某种数据类型支持不好,跑FP16又跑不出标称值。所以算力数字只是一个上限值,真正的有效吞吐,取决于算法部署时的量化策略、算子库覆盖度、内存带宽和片上缓存。
我从专利和经验两个角度给新入行的人一个建议:看计算平台,先别看TOPS,先看三件事。第一件是MAC阵列的配置和位宽支持,这决定了芯片在CNN、Transformer等主流模型上的效率天花板;第二件是SoC的整体总线架构和内存子系统,很多标称算力高的芯片,实际被片外带宽卡脖子,数据处理不过来,算力只能空闲;第三件是工具链的成熟度,编译器能不能把常用算子吃干榨净,直接决定你的AI框架能不能跑出好看的实时性。这几点,在很多计算平台的专利说明书里都有体现,只是被堆叠在“一种数据处理装置”“一种多核调度方法”这类抽象标题下面,需要花力气去扒。
1.2 从参数表到传感器端:算力需求从哪来
那算力需求到底是谁带出来的?不是PPT,是传感器和算法。摄像头从1个变成8个、11个,像素从120万升到800万,每秒涌入的数据量暴涨;激光雷达从16线到128线,点云数量级翻了几十倍;再叠加BEV(鸟瞰视角)感知、Occupancy占用网络、端到端模型的引入,每一帧需要的算力开支呈指数级上升。我拿一个实际项目数据做参考:一个传统的前视摄像头方案,大概只需要几TOPS的有效算力;一套覆盖360度视角的感知方案,加上预测和规划,基本就要达到几十TOPS;如果再把Transformer-based BEV和端到端模型全部跑起来,那跨入200 TOPS就是板上钉钉的事。
算力竞赛由此被层层推高。但很多人忽略了一点:算力越高,功耗和散热越难解决。车载环境要求整板功耗控制在几百瓦以内,还得过浪涌、过EMC、过振动,这和机房里的服务器完全是两码事。所以从专利文献里你会看到越来越密集地出现“基于水冷散热”“多节点同步功耗管理”“异构计算单元的负载均衡”这类技术,本质上都是在有限的功耗和热约束下,把算力用得更聪明。与其说大家在比算力绝对值,不如说在比单位功耗下的有效算力,也就是能效比。这已经不是一个单纯的芯片厂问题,而是一个系统级架构问题。
2. 专利样本里的技术演进脉络
2.1 为什么专利是可靠的观测窗口
要理解智驾计算平台的真实走向,光看ASIC发布会和官网白皮书是不够的,因为那些内容天然是市场导向、高度包装过的。而专利是另外一种产物:它必须写清楚技术方案、技术效果和权利要求边界,是为了应对法律审查和竞争对手狙击而存在的工程文档。恰恰因为专利有相对严谨的文本结构,它才成为技术演进的最好资料切片。想搞清楚“某厂是不是真的要转端到端”,与其看他们高管们在媒体上放的口号,不如检索他们最近一年递交的申请里,到底出现了多少“特征融合”“多任务训练”“数据回环”相关的权利要求。
专利还有个好处:时间线清晰。每一个专利申请日、公开日、优先权日都在文本上摆着,你可以按照时间轴还原出某个团队的技术路线变迁。比如看到一个厂商早期专利大量围绕“多传感器标定与融合”,中期集中在“路径规划与决策仲裁”,近两年开始频繁出现“模型部署加速”和“车云协同训练”,基本就能推断出这家公司的资源在往哪儿投。这可比看融资消息可靠多了。
2.2 申请趋势与关键词聚类分析
从更宏观的维度看,智驾专利的关键词聚类在近几年出现了明显迁移。早期的大量专利集中在感知层:图像识别、目标检测、车道线分割、光流计算,那是一个“先让车看懂世界”的阶段;到了中期,随着多传感器方案铺开,专利重心就转向“信息融合”“对齐”“联合标定”,尽量把异构传感器数据揉在一个统一坐标系里;再往后,规划决策类专利明显增多,比如路径生成、车速规划、预测轨迹关联、博弈决策等;到了最近两三年,检索结果里开始频繁出现“端到端”“BEV”“占用网格”“数据闭环”等概念,并且很多专利的权利要求不再限定某个具体的传感器型号或芯片平台,开始出现大量的“计算单元”“存储介质”“神经网络模型”这类上位化的描述。
这个迁移说明了两件事。一是行业从工程规则驱动,转向了数据与算法驱动,控制决策的权重正在上升;二是专利的布局重心,正在从算法本身迁移到算法的工程化使用方式,比如如何把模型装进车载域控,如何在受限算力下完成实时推理,如何用离线场景库去验证在线模型。换句话说,算力竞赛的内核,正从“谁的芯片强”变成“谁的架构能更快承接新算法”。
2.3 三组典型专利样本:从芯片到系统再到数据
我挑几类比较有代表性的专利样本来拆解一下,大家在检索时也可以按这个思路去对标。
第一类是跨域融合计算平台。这类专利通常描述一种支持多个功能域(智能驾驶域、座舱域、车身域)共用计算资源的硬件架构,核心手段是硬件虚拟化、资源池化、基于优先级的资源分配。申请这类专利的主体,既有芯片公司,也有系统集成商和整车厂。它解决的问题是“算力闲时浪费”和“硬件冗杂”——过去每域一套控制器,算力没法互济,现在用一颗大算力芯片把几个域拉通,让计算平台整体负载更均衡。
第二类是主备冗余与安全控制。代表性权利项会描述“系统包括第一计算单元与第二计算单元,在第一计算单元运行主控制逻辑,第二计算单元运行独立监控逻辑,当两者输出不一致时,系统判定故障并采取降级策略”。这类专利是整个智驾控制决策领域最底层的基石,因为所有的新奇算法最终都必须落在一个能保证功能安全的框架里。L2+以上系统几乎绕不开这类设计,只是实现形式各不相同:有的走双芯片,有的走单芯片内双核锁步,有的走三模冗余投票。
第三类是数据闭环与场景挖掘。这类专利不那么吸引眼球,但我觉得才是智驾长期能力的分水岭。核心技术要素包括:车端检测到特殊场景后自动触发数据采集、脱敏、上传,云端对海量数据进行场景标注、目标再识别、模型再训练,然后通过OTA把新模型回灌到车端。有个专利甚至把“用户反馈信息”纳入了数据闭环的输入,比如车主手动接管后,系统会记录接管前后的传感器数据作为一个训练样本,这种设计带着非常强的工程“土法炼钢”气质,但恰恰是它让算法能持续地被真实世界刁难,而不是只活在开源的测试集里。
3. 控制决策:从规则为王到AI原生的架构演替
3.1 规则时代:状态机、决策树与可解释性
老一代的智驾控制决策,基本就是在有限状态机(Finite State Machine, FSM)里写规则。针对巡航、跟车、变道、超车、进匝道、出匝道等场景,每个状态预置一组触发条件和动作,再用大量的if-else逻辑把状态串起来。优点是简单直观、可解释性强、好测试,出了问题能定位是哪个条件分支写错了;缺点是状态爆炸,真实交通流的组合情况是天文数字,规则写到最后,团队自己都数不清有多少分支。
这个时代的专利,写出来的权利要求经常长这样:一种车辆纵向控制方法,其特征在于根据前车距离、相对速度、自车速度与预设安全距离的比较结果,决定采用加速、匀速还是减速控制策略。这种权利要求的特征非常依赖“阈值”和“条件判断”,边界很清晰,但也非常容易被绕开。到了后期,大家开始使用更复杂的决策树结构、马尔可夫决策过程(MDP)甚至部分可观测马尔可夫决策过程(POMDP),本质上都在做同一件事:给机器的“决策”找一个更坚固的数学模型,支撑复杂路口的博弈判断。
3.2 学习算法渗透:决策模块的“黑盒化”进程
随着深度学习在感知层的红利挖得差不多了,行业里自然有人开始动决策层的脑筋。一开始大家都是小步试水,只让模型去预测一个小模块,比如用神经网络替代“可行驶区域判定”里的阈值逻辑,或者用学习式方法做“意图预测”。后来BEV架构逐渐成熟,车辆周围的所有障碍物、车道线、可行驶空间都被投影到统一的鸟瞰视角特征空间,这让决策模块的输入变得非常规整,于是才有条件去尝试更大规模的learning-based planning。
在这个渗透过程中,控制决策专利的关注点发生了很重要的变化:早期的专利喜欢写具体的规则边界条件,中期的专利转向写“如何构建训练样本”“如何设计损失函数”“如何融合多模态特征”,到了端到端阶段,连“决策模块”这个词都很少出现了,取而代之的是“多任务头”“联合训练”“蒸馏”。这说明控制决策这件事,正在从“显式的逻辑链条”变成“隐式的网络容量”,从算法的可读性转向数据的正确性评估。你在专利库里会看到越来越多关于“模拟器生成对抗样本”“大规模回放测试”“轨迹评估指标”的专利,它们承担的角色,相当于替黑盒模型补上了“质检员”。
3.3 端到端路线:控制决策走向隐式表达
端到端这个词这几年快被说烂了,但真正落地的人都知道,端到端不等于把感知、预测、规划全部揉进一个超大的网络就完事了。从专利角度来看,完全端到端模型很难直接申请专利,因为“一个输入、一个输出”的通用网络结构,早就被前人的框架覆盖得死死的,新颖性和创造性都不太好论证。所以你会看到,实际申请的端到端相关专利,切入点反而很具体:有的从输入特征构建下手,例如如何将多帧图像、历史轨迹、高精地图进行token化;有的从模型结构下手,例如设置多个解码头来分别输出轨迹和交互概率;有的从训练逻辑下手,例如利用分层一致性损失函数来约束学生模型与教师模型的输出分布。
这种“把黑盒掰开揉碎来找创新点”的写法,恰好说明了控制决策在端到端范式下的真实状态:功能仍然在那里,只是从分散的模块函数,变成了数据流动过程中在不同层级形成的隐式决策。过去我们还能通过看代码判断“这个路口该不该让行”,现在只能通过设计训练策略和评测方案去间接约束系统的行为。我觉得这不仅是技术架构的变化,也是工程管理方式的变化——测试团队的角色,正在从“验证逻辑”转向“验证数据分布质量”。
3.4 安全兜底:降级接管与最小风险策略
智驾的决策系统,再炫再准,也躲不了一个核心诉求:不安全的时候怎么收场?这也是控制决策专利里最有分量的一个板块。几乎每一家布局智驾的公司,都会申请大量关于“降级策略”的专利。典型的权利项可能这样写:在目标检测置信度低于阈值时,由第一控制模式切换至第二控制模式,第二控制模式包括保持当前车道行驶至安全区域停车等。再比如:当驾驶员接管信号被检测到时,系统逐步退出自动控制,并在退出过程中维持基础的安全距离。
这类专利表面看着朴素,实际工程上极其关键。因为L2+系统最大的职业瓶颈就是“系统性接管边界”到底画在哪:接得太早,用户体验差;接得太晚,安全事故风险大。所以安全兜底相关的专利一直在进化,从简单的“超时提醒驾驶员”到“根据驾驶员疲劳状态、分心程度和环境风险动态调整提醒策略”,再到“在检测到驾驶员未响应时自动执行最小风险策略(Minimal Risk Condition, MRC)并申请降级”。这些技术路线,本质上都是在用不同的架构手段处理同一个问题:人与机器、规则与模型、安全与体验之间的平衡。
4. 架构进化的四条主线
4.1 SoC整合与域控制器融合
你要是把专利的时间线拉长,会发现一个特别明显的变化:过去专利里出现的硬件单元比较碎,什么摄像头控制器、雷达控制器、网关控制器、仪表盘控制器,一抓一把;近几年则明显向SoC+域控制器的方向收敛,一颗大芯片上塞进CPU、GPU、NPU、MCU,通过片内高速总线完成数据交换,外部只留电源、收发器和少量接口。这种硬件架构的好处是降低了线束和控制器数量,提高了数据共享效率。但代价是芯片内部要处理极其复杂的资源隔离和优先级调度,稍微处理不好,一个突然高负载的感知任务就能把规划任务拖死。因此我建议如果是做系统架构的同事,去检索专利时重点看“多任务调度”“中断管理”“服务质量保障”这几个词下最新的申请,它们往往藏着各家SoC域控设计方案中最核心的护城河。
4.2 软件架构的系统性重构:中间件与确定性调度
硬件架构变了,软件架构不可能不变。早期的车载软件是典型的嵌入式单体应用,一针一线地和硬件绑定。如今为了支撑多个功能域在一个计算平台上运行,中间件(Middleware)和SOA风格的软件架构逐渐成为专利热点。相关专利会描述基于服务发现的通信机制、基于时间同步的数据分发策略、以及基于数据优先级的中断调度方法。整个体系的目标,就是让上层APP能像后端微服务一样独立迭代、独立升级,而不必每次改动都重新刷写整个控制器。
这个部分我提一句:在做专利检索时,千万别只盯着“自动驾驶”分类号,还得去搜“G06F9/50”(资源分配)、“G06F9/54”(进程间通信)、“H04L67/12”(车联网协议)等分类号。许多真正硬核的架构级创新,就藏在这些底层的计算和通信专利里,它们不像自动驾驶应用层专利那样名声大噪,但恰恰决定了系统能不能在多任务、高负载下保持确定性。
4.3 数据闭环与云端协同
当汽车逐渐变成数据终端之后,车端算力再强,也覆盖不了所有的训练和验证需求。于是云端和车端的协同架构成为智驾系统绕不开的一环。这方面专利通常描述的是一种分层系统:车端负责数据采集、场景识别、轻量级推理,云端负责大规模训练、仿真回放、模型版本管理,车云之间通过高效数据压缩和断点续传机制同步。比较前沿的还会涉及联邦学习、差分隐私、数据脱敏等,来应对数据安全和隐私合规的约束。
这一条线对整车厂和Tier 1的意义尤其大,因为它是智驾系统能否“越开越聪明”的关键。你可以没有一张自研芯片,但如果你没有一套稳健的数据闭环系统,你的算法迭代速度迟早会被拖垮。很多新势力能快速赶上老牌Tier 1,靠的未必是算法论文上比对方多刷了几个点,而恰恰是数据闭环的工程效率碾压。
4.4 安全性架构与合规性内置
架构进化的最后一条线,是安全性从“后补”变成“内置”。早期很多功能是先开发、后安全评测,功能安全、预期功能安全(SOTIF)和网络安全都是事后加的事。现在专利里越来越多地把安全机制前置到架构设计里:比如在一个计算平台专利中直接声明“包括处理器单元、安全岛(Safety Island)和外部安全监控单元,用于在处理器异常时执行安全操作”,这已经不是某个追加软件功能,而是芯片和系统架构自带的属性。实际上,芯片里的Safety Island、锁步核、错误检测与纠正(ECC)、以及对应的任务级监控逻辑,已经成为高端智驾SoC的标配。
这部分对整个行业的启示可能最扎心:安全不是靠某一个大系统包打天下,而是贯穿在每一个数据处理链路里的一种“横向架构”。你在专利文本里看到“Safety Island”这个词出现的频次,基本可以反推出这家公司对功能安全的认真程度。如果一家企业的专利里通篇都是漂亮的算法效果图,却一个安全兜底的细节都没有,那大概率还处在Demo阶段。
5. 如何用专利做智驾技术雷达与竞品分析
5.1 检索策略:别再用单个关键词蛮搜了
很多刚接触专利检索的人喜欢直接拿“自动驾驶”或“智能驾驶”这种大词去搜,结果检索出几万条记录,看得头昏脑涨。我个人的做法是先用分类号搭一个“底仓”:G05D1/00(车辆驾驶控制)、B60W30/00(车辆驾驶辅助系统)、G06N3/00(神经网络)这几个主分类号一定要进去;然后再叠加目标公司的申请人字段,通过“公司名+分类号”的方式快速过滤。紧接着,用关键词从粗到细层层收窄,先搜“计算平台”“域控制器”,再搜“多核”“资源调度”“隔离”,最后用“端到端”“BEV”“占用网络”这类新词精准圈层。另外还有一个技巧:做引用分析。找到一篇核心对标专利后,看看它引用了哪些早期专利、哪些后续专利引用了它,这样可以快速画出一张技术继承树,看出一个技术方向的前后脉络。
5.2 把专利情报翻译成工程决策
专利分析最有价值的产出,不是一份满是图表的数据报告,而是几个能指导研发决策的判断。比如:某对手最近连续申请了“双芯片协同决策”的专利,那说明他们可能在下一代产品中切换为双域控方案;某头部公司开始布局“场景检索与自动标注”专利,那说明他们的数据闭环团队在重点攻坚corner case挖掘,算法能力可能很快就会有一次明显跃升。
想做出这种判断,除了多读专利,还需要对工程实践有体感。专利是文字,文字背后的商业意图和技术代价,只有做过系统、调过模型、路测刷过车的人才能真正读出味道。所以我建议技术团队把专利阅读嵌入到日常研发流程里,比如每两周组织一次“专利茶话会”,挑3~5篇新公开的专利,讨论它们的权利要求能绕开吗、能够落地吗、是否值得预研。这个过程本身的价值,可能比现成的分析报告还大。
5.3 常见误区:别被专利文本绕进去
最后说几个我在读专利过程中踩过的坑。第一个误区是把专利等同产品。专利很多是防御性申请,公开的技术方案未必真的上车,也可能只是“占坑”,不能因为看到某篇专利就断定某家公司已经量产该技术。第二个误区是忽略法律状态只读说明书。有些专利已经失效或驳回,参考价值大打折扣,先看著录项里的法律状态和同族数量,再决定投入多少精力去细读。第三个误区是只读中文专利不看PCT。很多国际公司的核心专利是通过PCT途径进入国内的,中文本翻译质量参差不齐,关键权利要求最好对照英文原文或权项法条,否则很容易理解跑偏。
我个人习惯是把专利分析当成一种低成本的技术对拍手段。真正要判断一个技术路线有没有前途,光看一两篇专利不够,但看一百篇之后,行业共识和分歧会自然浮出水面。智驾这个行业,从来不是靠单点黑科技赢的,而是靠整体的架构演进和工程迭代。计算平台和控制决策也许还能再算上很长一段时间的军备竞赛,但决定终局的,一定是谁能在功耗、算力、数据、安全和体验之间找到更优雅的架构平衡。
说到这儿,其实已经把我近两年看专利时最有感触的东西都聊得差不多了。我自己的一个强烈体感是:专利分析这件事,越早做越有优势。等到竞品都量产了再去拆机对标,慢的不是一点半点;而在对方专利公开的第一时间就读懂他们想干什么,至少能在架构选型和资源投入上,提前几个月就调整好姿势。对智驾这种大工程来说,几个月的时间差,很多时候就是一代产品的胜负手。