简介：围绕安霸（Ambarella）芯片的汇总与对比文档，面向从事智能视觉、IP安防摄像头、车载视频记录与无人机影像方案的硬件选型、嵌入式开发及产品规划人员，帮助读者快速建立对安霸SoC产品谱系与应用边界的整体认识。压缩包内为1个PDF文件，大小约7.08MB，篇幅紧凑、便于检索和离线查阅，适合作为方案评估前的背景材料或团队内部技术分享的参考资料。目前已有656人学习，说明其在视觉处理芯片选型话题中具有一定关注度。PDF内容涵盖公司发展历程、全球研发与市场布局、低功耗高性能SoC在专业安防、家庭监控、运动与穿戴相机、无人机及前后装行车记录仪中的落地案例，并涉及AI处理器与视频处理器协同的架构思路、研发投入、制程进展和产品路线图。读者可据此梳理安霸芯片的定位差异、典型应用场景与迭代方向，为后续对比其他视觉SoC、判断方案适配性提供较完整的参考线索。

1. 七个型号摆在一张表上，第一眼就该看的那一列

CV22 和 H22 摆在询价单上只差两个字符，规格栏里都写着 16MP30、H.264/H.265，报价差一截。当年有个模拟项目按便宜的那颗定了板，样机回来接检测算法，帧率从 25 掉到 4——H22 没有 CVflow。这类翻车在视频 SoC 选型里重复率高得吓人，因为厂商标出来的参数长得太像，而真正决定能不能用的那一列，往往被埋在表格最右边。这份安霸芯片资料汇总与对比里最值钱的不是宣传页，是那张把 H2、H22、H32、CV22、CV28、CV25、CV2 七个型号塞进同一张对比表的产品页，以及后面 H2 的完整规格页。接下来按“怎么比、比什么、比完怎么验证”走一遍，目标很明确：让你在询价之前就把型号圈到两三个，而不是打完板再改。

2. 先分清 H 系列和 CV2x：七个型号一张表定生死

2.1 分界线只有一条：有没有 CVflow

把七颗片子摊开，最省时间的切法不是看分辨率、不是看核数，是看 CVflow 那一列填的是数字还是横杠。H2、H22、H32 这一列是空的，CV22、CV28、CV25、CV2 分别标着 15、4、2、1 eTOPS。这条线一划，两边的适用面就彻底分开了：H 系列本质是“把视频做到极致”的编码 SoC，图像前端、编码器、接口都给得很足；CV2x 是在同一个视频底座上加了一块 DNN/CV 加速器，把“看得清”变成“看得懂”。

很多人误以为 CV 系列就是“更强的 H 系列”，反过来买低端 CV 去替代高端 H，结果发现编码能力和接口数量掉了档。CV2 只有 2 核 A53、16-bit 内存，它虽然带 1 eTOPS 算力，但视频通路的规格是入门级；H22 没有算力，却有 4 核 A53、500MP/s 的 ISP 吞吐和 16MP30 的编码能力。这两颗不是替代关系，是两条岔路。

还有一个细节容易漏：资料里 CV2、CV22、CV25、CV28、H32 都标了硬件安全特性（security features in HW），H2 和 H22 的产品页里没有这一项。做联网 IP 摄像机、要做安全启动和密钥存储的方案，这一列比算力更早决定选型结果。常见的做法是：先按“要不要跑算法”分一次，再按“要不要联网、要不要硬件信任根”分一次，两刀下来剩下的型号通常不超过三个。

2.2 七个型号的关键参数横评

下面这张表按资料里产品对比页的顺序整理，把决定成败的几项拉到一起。分辨率口径参照 Roadmap 页，功耗是资料标注的典型上限，不是实测值。

这张表有两个地方必须盯住看。第一是 H32 的备注——资料明确写它是“CV25 去掉 CV”，意味着引脚、内存、ISP 与 CV25 同源，画板可以复用，软件砍掉算法栈就能降本，这是同系列里最省事的一次降配。第二是 CV2 的 2 核 A53，跑 Linux 加一套轻量算法是够的，但如果你要在上面再挂一路 Web 服务或者做本地录像索引，CPU 会先于算力成为瓶颈。

2.3 拿场景倒推：四个典型用法怎么落到具体型号

场景一，多路专业网络摄像机。这类产品要的是 ISP 吞吐、多传感器接入和编码质量，CV22 的 6 路 MIPI 加 600MP/s 是资料里唯一能扛多路 4K 的配置，代价是 5W 的功耗预算，外壳必须按金属结构设计。如果只做单路 4K 加一点轻量人形检测，CV25 更合适，360MP/s 够 4K30 加 HDR 余量，2W 功耗可以直接上塑壳。

场景二，电池供电的运动相机、穿戴设备。这类产品第一约束是功耗，第二是体积，ISP 再强，热压不住都是白搭。H32 和 CV2 的 1.5W 档是这条线的入口，H32 没有 CV、换成 4 核 A53，适合纯拍摄；CV2 多给 1 eTOPS，用来做实时跟踪或者画面稳定增强。

场景三，行车记录仪与后装录像设备。要的是 4Kp60、宽动态和长时间工作的热可靠性，H2 几乎是资料里为这个场景量身定做的：14nm、4Kp60 编码、< 1.7W 的整芯片功耗、HDMI 2.0 输出，一套下来外壳不用开风扇孔。H22 是它的降本版本，代价是 ISP 从 600 掉到 500 MP/s、内存从 64-bit 掉到 32-bit，4Kp60 加多帧 HDR 时要重新算带宽。

场景四，带视觉算法的无人机与机器人。CV22 的 15 eTOPS 是资料里唯一能同时跑多路高分辨率检测的档位，但 5W 对飞行平台是硬账，电池和散热都要重算。反过来 CV28 的 4 eTOPS 配 600MP/s ISP，在 8MP30 的输入下跑单模型检测，性价比比 CV22 高得多——它把 ISP 给足了，把分辨率降下来换功耗。

3. 参数逐项抠：ISP 吞吐、内存位宽、功耗三把硬尺子

3.1 ISP 吞吐从 240 到 600 MP/s，差的是能不能同时开 HDR

MP/s 这个单位很多人扫一眼就过去了，它其实是“每秒能处理多少百万像素”，直接决定你能开几路、开多高帧率、还能不能叠多曝光 HDR。按 4K（3840×2160，约 8.3MP）算，单路 4K30 要吃掉约 249 MP/s，4K60 要约 498 MP/s，1080p30 只要约 62 MP/s。

代入表里的数字就很有画面感：240 MP/s 的 H32 和 CV2，做一路 4K30 已经接近吃满，HDR 多曝光叠加时的余量非常小；360 MP/s 的 CV25 做 4K30 加 HDR 比较从容；600 MP/s 的 H2、CV22、CV28 才真正有余量去谈 4K60 或者多路。

这里有个工程上的估算习惯：line-interleaved 多曝光 HDR 不是简单乘 2，行交织只增加部分前端处理开销，实际按 1.3 到 1.6 倍估比较接近。也就是说 H2 标 600 MP/s，跑 4K60 HDR 时已经不太适合再叠一个高帧率慢动作通道。资料里 H2 页写的是“1 GP/s 图像引擎”，对比页写的是“600 MP/s ISP 吞吐”，两个口径并存——这不是矛盾，是图像引擎原始处理能力和 ISP 有效输出吞吐的区别。选型时按对比页那个更保守的数字算，别拿 1 GP/s 去顶。

3.2 内存位宽 16/32/64-bit 决定你能开几路、跑多高码率

这一列是我见过最多人忽略、也最容易翻车的一列。视频 SoC 的带宽账很好算：4K60 的 YUV420 8bit 原始数据是 3840×2160×1.5×60 ≈ 746 MB/s，编码器要读原始帧、读参考帧、写重建帧，实际占用按 3 到 4 倍估，也就是 2.2 到 3 GB/s；再加上 ISP 写、显示读、CPU 和算法访问，整颗片子的峰值需求会顶到 5 GB/s 上下。

对照内存接口的理论峰值：16-bit DDR4-2400 约 4.8 GB/s，32-bit DDR4-2400 约 9.6 GB/s，32-bit LPDDR4x-3733 约 14.9 GB/s，64-bit LPDDR4x-3733 约 29.9 GB/s。理论峰值打个五到七折才是可持续带宽，视频通路是连续大块读写，开销比随机访问小，但刷新和切换仍然要吃一口。

结果就非常清楚了：16-bit 的 CV2 和 H32 去跑 4K60 是在赌命，而资料给它们的定位本来就是 8MP30；32-bit 的 H22、CV25、CV28 跑 8MP30 到 16MP30 是舒服区间；64-bit 的 H2 和 CV22 才有资格谈 4Kp60 加算法并行。H22 还要额外注意一点，它同时支持 DDR3、LPDDR3、LPDDR4 三种内存，选最便宜的 DDR3 时峰值带宽只有 LPDDR4 的一半左右，高分辨率下的余量会被吃掉，BOM 省下来的钱可能要用帧率还回去。

3.3 功耗四档对应四种结构：从塑壳到散热片

表里的功耗数字分四档：< 1.5W、< 2W、< 3.5W、< 5W。这不是给采购看的，是给结构工程师看的。1.5W 以内可以做成完全密封的塑壳，靠自然对流；2W 到 3.5W 需要金属外壳做导热面，内部加导热垫把 SoC 热量导到壳体；接近 5W 的 CV22 基本要散热片加风道，产品形态会从“小方块”变成“带鳍片的盒子”。

常见的误判是拿资料上的典型功耗当整机功耗。SoC 的 3.5W 之外还有 sensor、DDR、Wi-Fi 模组、PoE 转换损耗，专业摄像机整机做到 8W 到 12W 很普通。反推的时候我一般这么算：SoC 标称值乘 1.2 作为设计余量，再加上外围器件的实测值，最后留 20% 的壳体散热能力。H2 页面上那句“4Kp60 under 1.7W”之所以值得单独标出来，就是因为它把整颗片子压进了塑壳可做的范围，这对消费类产品是决定性优势。

3.4 CVflow 的 1/2/4/15 eTOPS 到底能跑什么算法

eTOPS 是 8bit 有效算力的口径，跟 GPU 的 TFLOPS 不能直接换算，跟实际帧率更不能直接换算。按经验，1 eTOPS 这一档适合跑轻量检测网络（MobileNet 级别的 SSD 变体），1080p 输入下能做到十几帧；2 eTOPS 的 CV25 能在这个基础上加一路跟踪或者做人形分类；4 eTOPS 的 CV28 可以把输入提到 4MP 到 8MP，同时跑检测加属性识别；15 eTOPS 的 CV22 才是多算法并行的档位，4K 输入下做人车检测再叠一路行为分析还有余量。

判断依据不在算力数字本身，在“模型乘输入分辨率”这个乘积上。同一个模型，输入从 1080p 换到 4K，算力需求差不多翻四倍。所以 CV22 的 15 eTOPS 要配它的 600MP/s ISP 和 64-bit 内存才成立，单独看算力会得出“CV22 是 CV25 的七倍多”这种错误结论——它实际能做的事，大概是把 4K 输入下的多算法并行变成可能，而不是把 1080p 的帧率翻七倍。

4. H2 单独拎出来看：4Kp60 压进 1.7W 的账怎么算

4.1 图像前端：1GP/s、MCTF 和硬件 3D EIS

H2 的规格页写得比对比表细得多，值得单独拆。工艺是 14nm 低功耗架构，图像引擎 1 GP/s，带运动补偿时域滤波（MCTF）、4Kp60 HDR、硬件加速 3D 电子防抖。MCTF 这项在暗光场景里很关键，它靠多帧时域信息降噪，比单帧空域降噪更不容易糊细节，代价是要吃掉帧缓存和带宽——这也是为什么 H2 必须配 64-bit 内存，16-bit 的带宽根本喂不动时域滤波。

硬件 3D EIS 是另一个容易被低估的点。软件防抖要占 CPU 和带宽，裁切比例和延迟都不好控；硬件做 EIS 意味着防抖这块不占 CPU 预算，对运动相机、穿戴设备这种 CPU 本来就紧张的产品是刚需。传感器接口给的是 SLVS-EC、SLVS、HiSPi、MIPI 四种，支持多传感器输入和行交织 HDR，说明它在设计上是奔着多 sensor 方案去的，不是只服务单摄。

4.2 编码与接口清单：H.265 4Kp60、HDMI 2.0、USB 3.0

视频引擎这边，H.265/HEVC 支持 4Kp60 和 1080p240，H.264/AVC 支持 4Kp60 及以上，10bit 编码只在 HEVC 下有效。1080p240 这个档位是给慢动作留的，做运动相机产品线的人看到这一行基本就懂了——高帧率慢动作是这类产品最核心的卖点之一，而很多同价位片子只给到 1080p120。

接口清单也挺完整：HDMI 2.0 输出 4Kp60、USB 3.0、DSI 串行显示、SD3 UHS1、UART/SPI/I2C、串行音频与数字麦克风。HDMI 2.0 直接出 4Kp60 意味着它可以做带屏设备或者直连电视回放，不需要外挂转换芯片；USB 3.0 意味着可以外接存储或者做 UVC 输出。这两项决定了产品的形态上限，如果片子只有 USB 2.0，那 4K 视频的导出速度会成为用户体验的硬伤。

CPU 是四核 Cortex-A53，带 NEON 和 FPU，支持 32 位或 64 位，主频在规格页标 1.2GHz，而对比页标 756MHz。这个差异我一般当成两档工作模式来看：满载和低功耗场景下的不同工作点。选型算力预算时按低值算更保险，尤其是做常电待机或者电池产品，实际跑不到标称峰值。

4.3 别踩 H2 的边界：它不适合什么

H2 没有 CVflow，这是它最硬的边界。任何需要跑神经网络检测的产品，选它都是给后面埋雷，要么外挂一颗加速器（增加成本、功耗、PCB 面积），要么把算法砍到跑不动的水准。资料里 CV2x 系列和 H32 都标了硬件安全特性，而 H2 的产品页没提这一项，做联网产品、需要安全启动和密钥保护的方案，这一项的缺失要在方案阶段就想好怎么补，别等到做认证才发现。

第二个边界是内存类型。H2 支持的是 LPDDR3/DDR3/DDR3L，不是 LPDDR4x。LPDDR3 的供应面这两年在收窄，做长生命周期产品（比如车载后装、工业设备）时，物料延续性要提前和供应链确认。这一点在资料里不会写，但它是选型会上一定会被问到的问题，我一般把它列在“技术评审之外的风险”那一栏单独过一遍。

第三个边界是定位。H2 是消费类和行业类的高端编码芯片，不是车规产品。资料里车规相关的部分是另一条线在讲，别把消费级的型号往车规项目里套，温度等级、寿命、认证流程全都不一样。

5. 选型避坑：五条把我卡住的细节

5.1 参数口径上的三个坑

现象一：按对比页选了一颗 ISP 600MP/s 的片子，实测 4K60 加 HDR 掉帧。原因是把“图像引擎处理能力”和“ISP 有效吞吐”混用了，H2 页面上 1 GP/s 是引擎口径，对比页 600 MP/s 是有效输出口径，多曝光叠加后实际需求会翻上去。解决办法很简单，选型时统一用更保守的那个数字做预算，HDR 场景再乘 1.3 到 1.6 的系数，别拿大数去顶。

现象二：两款型号分辨率标注一样，实际能接的 sensor 数量差一倍。原因是只看了“16MP30”这类编码能力，没看 MIPI 通道数。H22 是 2 路 CSI-2，CV22 是 6 路，两者的产品形态完全不同。解决办法是把输入通道数放在表格第一列，先按 sensor 数量筛一遍，再谈其他。

现象三：Roadmap 页和产品对比页的数据对不上，比如某型号在 Roadmap 上标 3x VIN，在对比页标 2x MIPI。原因是两页的统计口径和更新时间不同，Roadmap 更偏规划，对比页更偏量产规格。解决办法是以型号单页规格为准，冲突项直接找 FAE 确认，别自己拍。

5.2 硬件落地上的两个坑

现象四：样机在小批量时一切正常，量产批次出现高低温下偶发花屏。原因是内存时序余量按标称峰值调的，没留降额空间，尤其是选了 DDR3 而不是 LPDDR4 的配置，高温下时序窗口收窄。解决办法是在设计阶段就按最差内存颗粒调参，把余量打进时序表，别用“能跑就行”的配置过验证。

现象五：型号后缀没对齐，拿到的样品和设计文档不是同一版硅。资料里 H22 带 A12 后缀这类标记，代表的是硅片修订版本，不同版本的外设行为可能有细微差异。解决办法是在询价和打样阶段把完整型号（含后缀）写进 BOM 和原理图标题栏，收到样品先核对丝印，再开始调试。这条坑不花钱，只花时间，但一旦踩上，排查成本极高。

6. 一周验证路径：从资料到能拍板的选型结论

资料看完到真正能拍板，中间还差一轮验证。我一般按五天到一周排：

第三天那步最容易被跳过，但它经常直接否掉型号。一个 5W 的方案放进 60×60mm 的塑壳里，前期算得再漂亮，结构评审也会被打回来。反过来，如果结构先告诉你只能做无风扇密闭壳，那 CV22 这条线当天就可以划掉，省下来的时间够把 CV25 的算法预算重新算一遍。

最后一步的实测，重点不是跑分，是跑你自己的那条链路：把你的 sensor、你的分辨率、你的码率配置、你的算法模型都放上去，测三件事——满负载下的持续帧率、满载半小时后的壳温、以及内存占用到 80% 时会不会开始丢帧。资料上的数字是上限，实测出来的才是你能写进规格书的数字。

回过头看，我踩过最贵的一个坑不是选错了算力档，是没在第一天就把“要不要联网、要不要硬件安全特性”问清楚，方案定完才发现要补安全芯片，PCB 重画一版，项目周期直接推了三周。从那以后我每次开选型会，第一页 PPT 只放三列：CVflow 有无、内存位宽、有没有硬件安全特性，先把这三列填完再谈别的。这份资料的价值也在这里——它把七个型号放在同一张表上，让你能在半小时内填完这三列，而不是翻七份规格书。希望帮到你。

本文还有配套的精品资源，点击获取