2. EyeQ芯片平台认知

在Mobileye EyeQ智能驾驶项目的工程交付中，芯片平台选型是决定系统能力上限、软件架构和传感器配置的起点。EyeQ4、EyeQ5、EyeQ6三代芯片并非简单的性能递增关系，而是在架构理念、算力组织方式、传感器接入能力和安全设计上存在明显代际差异。理解这些差异，才能在实际项目中做出合理的平台选择，而不是仅凭TOPS数字判断优劣。

一、三代芯片的架构演进逻辑

EyeQ4采用28nm CMOS工艺，内部集成约40个专用硬件加速器（ASIC/VLIW协处理器），包括视觉处理、深度神经网络、图像信号处理等专用单元。其设计思路是“专用硬件承担固定任务”，CPU（MIPS核心）主要负责调度和控制，不承担大规模计算。这种架构功耗极低（典型2.5～3W），但灵活性有限，算法更新空间受硬件加速器能力约束。

EyeQ5升级到7nm FinFET工艺，架构上引入异构计算理念：8个MIPS I-class CPU核心负责通用计算与任务调度，同时集成18个Mobileye专有加速器，涵盖CNN、DSP、视觉预处理等。与EyeQ4相比，EyeQ5的CPU可编程能力显著增强，允许OEM和Tier1在芯片上部署部分自研算法，而不必完全依赖Mobileye的黑盒输出。典型功耗约10～15W，需主动散热设计。

EyeQ6系列进一步分化为EyeQ6L（Lite）和EyeQ6H（High）两个方向。EyeQ6L面向入门级ADAS，强调成本与能效，可视为EyeQ4的架构升级替代；EyeQ6H面向高阶智能驾驶，采用多芯片级联或单芯片多核架构，算力大幅提升，支持更复杂的BEV感知、多传感器融合和部分城区NOA功能。EyeQ6在制程上推进到5nm甚至更先进节点，功耗管理更加精细。

二、算力特性的真实含义

工程中常说的“算力”需要区分三个层面：标称TOPS、有效利用率和任务适配度。EyeQ4标称约2.5 TOPS，但由于其加速器高度专用，运行Mobileye自家视觉算法时有效利用率很高，实际感知效果可满足L2 ADAS需求；但若试图运行非适配的第三方网络，效率会大幅下降。EyeQ5标称约24 TOPS，CPU可编程性提升后，对非Mobileye算法的兼容性明显改善，但实际部署时仍需考虑加速器对算子类型的支持范围。

EyeQ6H的算力提升不仅体现在TOPS数字上，更关键的是内存带宽和片间互联能力。高阶智驾中BEV+Transformer类模型对内存带宽的需求往往比纯算力更先成为瓶颈。选型时若只对比TOPS而忽略内存带宽、缓存层级和加速器算子覆盖，容易在后期集成中出现“算力够但跑不动”的情况。

三、传感器接口与配置约束

EyeQ4通常支持4路MIPI CSI-2输入，常见配置为1颗前视摄像头（120°广角+30°窄角组合）或三目方案。由于接口数量和带宽限制，EyeQ4方案一般不含激光雷达或高分辨率环视摄像头。EyeQ5的MIPI接口数量和单路带宽均有提升，可接入更多摄像头并支持雷达数据通过CAN-FD或以太网输入，适合5R1V、5R5V等融合方案。

EyeQ6在接口上进一步扩展，支持更高像素摄像头和更高速率的数据输入，为激光雷达、4D毫米波雷达的原始数据或目标级数据接入预留了通道。实际项目中，传感器接口的可用数量、单路最大分辨率/帧率、以及是否支持硬件时间戳同步，是配置摄像头和雷达时必须逐项核对的参数。

四、选型依据与决策要点

平台选型不是“越新越好”，而是匹配项目功能定义、成本目标和开发周期。以下决策表可作为工程初期的选型参考：

五、实际选型中的常见误区

第一个误区是只看TOPS。某项目需要运行BEV感知模型，初步估算需要20 TOPS以上算力，于是直接选择EyeQ5。但实际部署时发现该模型的部分算子（如可变形卷积）在EyeQ5加速器上支持不完善，回退到CPU执行后帧率无法满足要求。这说明算力数字必须结合算子覆盖度一起评估。

第二个误区是忽略接口带宽。多路高分辨率摄像头同时输入时，MIPI总带宽可能成为瓶颈。例如4路8MP摄像头@30fps，每路约2Gbps，合计8Gbps，若芯片MIPI总带宽不足或分配不当，会出现丢帧或降分辨率。选型阶段应计算传感器总数据率并与芯片接口规格比对。

第三个误区是低估散热设计。EyeQ5和EyeQ6H的功耗显著高于EyeQ4，若沿用EyeQ4的被动散热方案，芯片会因过热降频，导致实际算力低于标称值。工程中应在结构设计早期就确认散热方案，并在热仿真中验证芯片结温不超过规格上限。

综合来看，EyeQ4、EyeQ5、EyeQ6分别对应不同的功能层级和工程约束。理解架构差异、算力真实含义、接口限制和选型误区，才能在项目启动阶段做出经得起后期集成考验的平台决策。