在嵌入式 AI 产品选型的时候,我最常被问到的一个问题就是:“我就想做个带摄像头的智能小设备,成本要低,功耗要低,但还得能跑得动轻量级神经网络,到底该用哪颗芯片?”以前我一般会推荐带 NPU 的 ARM 方案,但现在再有人问,我通常会先反问一句:“你试过 RISC-V 和 ARM 混在一起用的芯片吗?”我说的就是 SOPHGO 的 SG2000 和 SG2002。这两颗芯片很有意思,它们把 ARM Cortex-A53、双核 RISC-V C906 和一个算力不大但够用的 TPU 塞进了同一颗 SoC 里,这种异构架构在实际项目里带来的好处,远远不止“多几个核”这么简单。这篇文章我不会去复读芯片手册,而是想从实际做产品、跑 demo、写代码的角度,把 SG2000/SG2002 这套异构架构到底是怎么回事、为什么 SOPHGO 要这么设计、以及你在自己的项目里怎么把这几颗核“物尽其用”讲清楚。如果你正准备做智能门锁、低功耗可视门铃、工业视觉小盒子、或者只想低成本入门 AI SoC 开发,这篇内容应该能帮你省下不少自己摸索的时间。1. 内容整体设计与思路拆解1.1 异构不是噱头,是成本和功耗逼出来的解决方案先聊一个很多人会忽略的背景。现在的智能硬件有个很尴尬的处境:如果只上 MCU,算力不够,跑不动哪怕是最小的图像分类模型;如果直接上手机那种应用级 SoC,性能和生态确实没问题,但成本、功耗、开发复杂度全上来了,做个小批量产品根本扛不住。SG2000/SG2002 其实就是在中间这个夹缝里杀出来的方案。它的核心思路特别务实:把不同擅长的处理器核心组合在一起,让每颗核干自己最擅长的事。C906 大核负责跑 Linux 系统和复杂的业务逻辑,C906M 小核可以跑 RTOS 做低功耗实时任务,而 Cortex-A53 这颗核则作为“第二大脑”,在需要跑更重负载的 Linux 应用时顶上。再加上一颗专门为轻量级神经网络设计的 TPU,整个系统就形成了“主控 副控 加速器”的完整闭环。我用一个生活化的类比来解释:一个大公司里,不能所有人都做同一件事。得有项目经理(C906 大核)总览全局,处理需要复杂判断的任务;得有值班前台(C906M 小核)在夜间低功耗模式下处理简单响应;还得有外聘的资深顾问(A53)在重大项目时加入支援;最后,那些重复性高、计算量大的数据运算,交给专用工具(TPU)来做,效率最高。SoC 里的异构架构,本质就是这个逻辑。这种设计最直接的红利体现在两个维度:一是动态功耗控制可以做得非常细,系统空闲时切到小核 RTOS 模式,整机功耗可以压到毫瓦级别;二是成本控制空间大,因为你不需要为了一个偶尔要用的高性能场景,去为整颗芯片的强悍性能买单。1.2 SG2000 和 SG2002 选哪个,先搞清楚算力差异SG2000 和 SG2002 在命名上看着像亲兄弟,但实际选型时有一个非常关键的差异:TPU 的算力。SG2000 的 TPU 算力是 0.5 TOPS,而 SG2002 直接翻倍到了 1 TOPS。别小看这 0.5 的差距,在实际跑模型的时候,这往往决定了你是能流畅跑一个稍微复杂点的检测模型,还是只能老老实实跑轻量分类模型。除了算力,两颗芯片在封装、内存配置、接口丰富度上也有些细微差别。SG2002 很多时候被用在需要更高图像处理能力的场景,比如带屏幕的人脸识别门锁、智能猫眼;而 SG2000 则更适合成本极度敏感、功能相对单一的 IoT 产品。从我接触的不少方案商的情况来看,他们的选型逻辑基本都是:SG2002 跑 0.5 TOPS 以上的模型,或者要同时跑多个模型;SG2000 则用在只跑单个分类模型、逻辑不复杂的场景。这里还有个隐藏点,两颗芯片的硬件引脚设计得比较接近,意味着你画一版 PCB,可以在 SG2000 和 SG2002 之间做兼容设计,先用小算力版本验证市场,需要升级再替换芯片。这对做产品的朋友来说,是一个非常友好的产品迭代策略。2. 核心细节解析与实操要点2.1 三核全家桶:C906 大核、C906M 小核与 Cortex-A53 的明确分工很多人第一次看 SG2000/SG2002 的框图和 datasheet,会被绕晕,因为它的主控组合确实不像传统芯片那么“一眼懂”。我把它抽离成三个角色来看,就会清晰很多。首先是 C906 大核,它默认运行 Linux 系统,主频通常在 1GHz 左右(实际以官方配置为准),这颗核相当于系统的“大脑中枢”,跑文件系统、网络协议栈、外设驱动、应用主逻辑等。你在 SDK 里做的绝大部分开发工作,都是在这颗核上完成的。其次是 C906M 小核,它可以独立运行 RTOS,也可以和大核通信协同工作。这颗小核的最大意义在于低功耗场景:比如电池供电的智能门锁,平时大核休眠,C906M 保持常开,负责监听传感器、按键唤醒、低功耗图像采集等任务。等需要复杂处理时,再唤醒大核。最后是 Cortex-A53,这颗 ARM 核在很多 SG2002 参考设计里是可以单独跑 Linux 的。它存在的意义不只是“多一个核”,而是让这颗 SoC 可以兼容 ARM 软件生态。有些客户手上的算法库、第三方 SDK 只提供 ARM 版本,没法在 RISC-V 上重新编译,这时候就可以直接跑在 A53 上。这种“一颗芯片,两套软件生态”的做法,在解决实际项目兼容性问题上,简直是杀手锏。2.2 TPU 算力虽小,但跑轻量级模型绰绰有余SG2000/SG2002 内置的 TPU 是 SOPHGO 自研的 IP,官方工具链叫 TPU-MLIR,支持将 PyTorch、ONNX、TFLite 等格式的网络模型转换成能在 TPU 上跑的格式。很多人一看到“0.5 TOPS / 1 TOPS”这个数字就觉得太小,但实际上,对于 256x256 或者 320x320 输入分辨率的分类网络、小型检测网络,这个算力是够用的。我实测过的经验是:像 MobileNetV1、MobileNetV2、EfficientNet-Lite 这类轻量级分类模型,在 SG2002 的 TPU 上跑,单次推理速度能达到几十毫秒级别,这在智能门锁、人脸识别门禁这类应用里完全足够。对于 YOLOv5n、YOLOv8n 这类小型检测模型,在合理裁剪输入尺寸和通道数的前提下,也能跑到每秒 5 到 10 帧的水平,做简单的区域入侵检测、移动侦测是没问题的。但你要有个清醒的认识:TPU 不是万能的。结构太复杂、算子太冷门(比如某些动态 shape 的模型、特殊激活函数的模型)在转换时很容易报错或者性能不佳。所以选模型时尽量选择算子通用、结构标准的主流网络,会省掉大量转换和调优的时间。2.3 DDR 选择与启动方式,直接影响你的开发体验SG2000/SG2002 支持内置 DDR 的封装形式,也支持外挂 DDR 的方案。内置 DDR 的优势是 PCB 布线简单、体积小、信号完整性容易保证,非常适合产品快速落地;外挂 DDR 则更灵活,容量选择空间大,适合需要大内存跑复杂应用的场景。启动方式上,这两颗芯片支持从 SD 卡启动、从 SPI Flash 启动、从 USB 烧录启动等多种方式。开发阶段最推荐的是 SD 卡启动,因为可以随时替换 rootfs,迭代速度快;量产阶段则用 SPI Flash 或 eMMC 启动,可靠性更高。这里有个实操细节:如果你用的是 SG2002 的官方开发板,默认的 microSD 卡槽和 USB 烧录口布局,我在实际使用中发现按着 BOOT 键再上电,进入 USB 烧录模式的成功率是最高的,这个操作在官方文档里写得比较隐晦,很多新手在这里卡住。3. 实操过程与核心环节实现3.1 搭建开发环境:从拿到开发板到串口跑起 Linux下面我以一个实际的 SG2002 开发板为例,把你需要做的操作完整捋一遍。第一步,安装交叉编译工具链。SOPHGO 为 SG2000/SG2002 提供了基于 RISC-V 的交叉编译器,通常在 SDK 里已经预置好了工具链的路径。我建议你直接在 SDK 目录下做全部开发,不要自己单独装一套,这样可以避免 GCC 版本不匹配导致的奇怪问题。SDK 的获取方式是官方 GitHub 仓库或者官网下载中心,拿到后解压,你会看到一个名字类似于toolchain的目录,交叉编译器的前缀一般是riscv64-unknown-linux-gnu-或者riscv64-linux-musl-,这取决于你用的是 glibc 版还是 musl 版的 rootfs。第二步,编译固件。进入 SDK 根目录,执行 SDK 提供的编译脚本,比如./build.sh或者在 menuconfig 里选择好目标板配置。第一次编译时间会比较长,如果网络环境不好,拉取依赖包时还容易失败,所以我个人的习惯是先跑一次make让 SDK 把必要依赖都下载好,然后再执行完整编译。如果中途出错,优先检查网络代理和磁盘空间,这两个是排在第一位的怀疑对象。第三步,烧录与启动。把编译生成的sdcard.img(或类似名字的镜像文件)通过工具写入 SD 卡。在 Linux 下我习惯用dd命令,在 Windows 下就按官方推荐用 BalenaEtcher。写入完成后,把 SD 卡插入开发板,连接串口线(一般是 3.3V TTL 电平,波特率 115200),给板上电。串口终端里如果能看到 U-Boot 的启动日志,随后进入 Linux 登录提示符,那就说明环境已经通了。# 在 Linux 主机上写入 SD 卡(注意确认设备名,别写错盘) sudo dd ifsdcard.img of/dev/sdX bs4M statusprogress sync3.2 上手体验三核切换:大核、小核与 A53 的自由调度环境跑通后,我强烈建议你做的第一件事,不是写业务代码,而是体验一下这套异构系统是怎么在多核心之间切换的。从 Linux 系统里,你可以通过cat /proc/cpuinfo查看当前核心的状态。SG2002 的 Linux 侧默认会看到 2 个 CPU 核心(一个 C906 和一个 A53),而 C906M 小核默认运行 RTOS,不会在/proc/cpuinfo里出现。这就引出一个关键点:如果你想在 Linux 下同时使用 ARM 核和 RISC-V 核,需要认真阅读官方关于 AMP(非对称多处理)模式的文档,它描述了如何给 A53 核单独加载一份 Linux 内核或应用程序镜像。我自己做过一个简单的测试:在 SG2002 上同时启动一个 RISC-V Linux 和一个 ARM Linux,两个系统各自运行 Web 服务,然后通过以太网互相访问。虽然两个核跑的是不同架构的代码,但它们在硬件层面通过共享内存或 virtio 机制通信,这让我觉得这颗芯片的“双脑”模式已经超出了单纯堆核的范畴,更像是一个可以灵活组合的系统级方案。不过要提醒你,AMP 模式的配置和使用相比单核 Linux 要复杂不少,需要手动管理内存隔离、中断分配、设备树配置等。如果你的项目不需要同时使用两套生态,直接跑默认的 RISC-V Linux 或者 ARM Linux 单系统就行了,不必为花活增加复杂度。3.3 跑通你的第一个 TPU 模型:从 ONNX 转换到推理部署这是把 SG2002 价值发挥到最大的关键一步。我拿一个分类模型举例,带你走一遍完整流程。首先,在电脑上用 PyTorch 训练或者导出一个人脸检测、物体分类的模型,输出为 ONNX 格式。然后用 SOPHGO 提供的模型转换工具链(TPU-MLIR)进行转换。转换过程一般分两步:第一步,把 ONNX 模型转换成中间表示格式(mlir);第二步,通过 tpu-mlir 的编译器把中间表示转换成可以在 TPU 上运行的.bmodel文件。# 假设你已经安装好 tpu-mlir 环境,且 PYTHONPATH 指向脚本目录 # 第一步:ONNX - MLIR model_transform.py \ --model_name mobilenet_v2 \ --model_def mobilenet_v2.onnx \ --input_shapes [[1,3,224,224]] \ --pixel_format bgr \ --mean 103.94,116.78,123.68 \ --scale 0.017,0.017,0.017 \ --output_names output \ --mlir mobilenet_v2.mlir # 第二步:MLIR - BMODEL(这里以以 int8 量化为例) model_deploy.py \ --mlir mobilenet_v2.mlir \ --quantize INT8 \ --calibration_table mobilenet_v2_calibration_table \ --chip sg2002 \ --tolerance 0.95 \ --model mobilenet_v2_sg2002.bmodel这里有几个非常值得注意的细节。一是预处理参数必须和训练时保持一致,mean 和 scale 填错会直接影响推理精度,而且这种错误很难通过日志直接看出来。二是--chip参数要填对,如果你拿的是 SG2000,填成 sg2002 虽然能转换成功,但运行时报错或者性能异常的风险会增加。三是 int8 量化需要准备校准数据集,校准数据集最好覆盖实际使用场景的分布,不能随便找几张别的图片凑数。转换完成后,把.bmodel文件拷贝到开发板上。程序运行时,通过 SOPHGO 提供的libsophgo运行时库或者 Python API 加载 bmodel 进行推理。官方 SDK 里通常有 C/C 和 Python 两套示例代码,我建议你从 Python 示例开始验证模型效果,确认无误后再用 C/C 版本做产品化集成。3.4 摄像头 推理:一个最典型的端侧视觉应用骨架跑通单张图片推理后,下一步就是接摄像头做实时视觉应用。SG2000/SG2002 集成了 MIPI-CSI 接口,可以接各种 MIPI 摄像头模组,也支持 USB 摄像头(需要额外的 USB 控制器资源)。我的建议是直接用官方 SDK 提供的 V4L2 接口示例开发,采集帧数据后送入 TPU 推理。这里有个性能优化的小技巧:不要让采集、推理、显示串行执行,而是用多线程或者双缓冲机制,让采集线程和推理线程并行。实测下来,在 640x480 分辨率下,把采集和推理做成流水线,整体帧率能提升 30% 以上。// 伪代码示意——双缓冲采集与推理 while (1) { buf_id dequeue_buffer(); // 从驱动取一帧 if (last_buf_id 0) { enqueue_buffer(last_buf_id); // 上一帧还回去继续采集 } rv tpu_inference(buf[buf_id]); // 对当前帧做推理 handle_result(rv); last_buf_id buf_id; // 保留当前帧,下一轮再还 }双缓冲的思路本质上就是“空间换时间”,避免等一帧采集完成后再开始推理,让两个硬件模块始终处于忙碌状态。这么做还有一个额外好处:推理耗时抖动不会直接影响到采集帧率,画面会稳定很多。4. 常见问题与排查技巧实录4.1 镜像烧录与启动阶段的“玄学”问题说几个我在开发 SG2000/SG2002 时真实踩过的坑。第一个是 SD 卡启动失败,卡在 U-Boot 阶段没有任何输出。这种情况十有八九是 SD 卡本身兼容性问题。这两颗芯片对 SD 卡比较挑剔,一些劣质卡或者过老的山寨卡在高速模式下会直接“失联”。解决办法是换一张知名品牌的 Class 10 卡,或者把 U-Boot 环境变量里的 SD 相关高速模式关闭。第二个是串口乱码。刚接好串口,终端里出现一堆乱码,很多人第一反应是接线接触不良,其实绝大多数情况是波特率不对。SG2000/SG2002 的开发板串口,我遇到过默认 115200 和 921600 两种版本,先看清楚开发板丝印或者文档说明,再连终端,能省很多折腾。第三个是 USB 烧录模式反复失败。前面提到过,按 BOOT 键上电进入烧录模式。但有个细节是:你得先按住 BOOT 键不要松开,然后再插 USB 线,等主机端识别到 USB 设备后再松手。顺序反了,进不了烧录模式。这个问题在官方社区里经常有人问,我自己也试了几次才熟练。4.2 TPU 推理结果不对,排查思路比换模型更重要如果你转换完模型,推理结果完全不对(比如分类结果一直固定在某个类别),不要急着怀疑芯片坏了或者工具链出 bug。按照我排查问题的习惯,优先级最高的检查项是:输入图像的预处理是否和转换时一致。包括尺寸缩放算法(是 bilinear 还是 nearest)、颜色通道顺序(BGR 还是 RGB)、均值方差的数值和顺序。这三项只要有一项不对,模型输出就会“疯掉”。其次是检查模型输入的张量形状。你在model_transform.py里设置的input_shapes是[1,3,224,224](NCHW 排布),那你在应用程序里送入 TPU 的数据也必须是同样的 shape 和排布。很多人在 OpenCV 里默认拿到的是 HWC 排布,不转成 CHW 就直接喂数据,结果必然出错。还有一个容易被忽略的点:TPU 推理输出的数据格式和模型定义有关。分类模型输出的是一个概率向量,检测模型输出的是 [x1,y1,x2,y2,score,class_id] 之类的结果块,你需要做相应的后处理才能解析出可读结果。官方示例代码里一般都有完整后处理,不要自己发明解析逻辑。4.3 功耗调优:让设备在“常态待机,瞬间响应”之间切换SG2000/SG2002 的异构多核架构,在功耗调优上给了你非常大的操作空间。我的经验是,如果产品是电池供电,一定要利用好 C906M 小核的低功耗常开能力。具体操作上,SG2000/SG2002 的 SDK 提供了电源管理框架,你可以配置大核在无任务时进入 suspend 或 idle 状态,同时让 C906M 小核保持运行,专门监听 GPIO 唤醒事件。从待机到完全唤醒,如果配置得当,整个转换过程可以控制在百毫秒级别,而待机功耗能压到非常低。这个方案比单纯让大核跑着“死等”功耗要低一个数量级,也是很多智能门锁产品愿意选这颗芯片的原因。我这里想特别提醒一点:官方文档里的功耗数据,通常是在特定测试条件、特定固件版本下测出来的。你在自己的板子上,功耗表现受 DDR 频率、外设供电、GPIO 上下拉、甚至 rootfs 里跑的服务影响非常大。所以调功耗不能只看芯片,要从整个板级系统去考虑。5. 典型应用场景与影响范围分析5.1 消费电子场景:智能门锁、猫眼与可视门铃这类产品是 SG2000/SG2002 最典型的“根据地”。需求高度一致:本地人脸识别、低功耗待机、快速唤醒、隐私安全(不上云)。我接触过的一个智能猫眼参考设计,就是 SG2002 跑人脸检测与活体分类,平时 C906M 小核监听 PIR 传感器,有人靠近时再唤醒大核和 TPU,从检测到人脸框出画面,整个过程在几百毫秒内完成。这个体验已经能够和不少中高端智能门锁相媲美,但芯片成本却低了一大截。另外,由于 AI 推理完全在本地 TPU 完成,不需要把图像传到云端,在用户隐私敏感度越来越高的背景下,这个本地化方案的价值还会持续上升。5.2 泛工业场景:轻量视觉检测与边缘计算盒子在工业质检、生产状态监控这类场景里,设备通常需要连续运行,对功耗不像电池设备那么敏感,但对稳定性和实时性有要求。用 SG2002 可以做一个非常迷你的视觉检测盒子,接两路摄像头,通过 TPU 跑缺陷分类或简单目标检测,检测结果通过网口或串口上报给 PLC 或 MES 系统。这类场景还有一个隐藏需求是软件可维护性。因为现场设备基本不给你机会拆机重刷系统,所以远程升级能力很重要。SG2000/SG2002 支持从 SD 卡、eMMC 启动,可以设计一套双分区 A/B 升级机制,在线升级失败还能回滚,这在产品化时是很重要的加分项。5.3 极客与教育场景:低成本学习 AI SoC 开发最后聊聊创作者和教育市场。SG2000/SG2002 的开发板和 SDK 门槛其实不高,但可玩性很强。双核 RISC-V ARM A53 TPU 的组合,意味着你可以在上面同时学习嵌入式 Linux、RTOS、异构多核通信、模型转换、AI 推理等等一大堆技能。对学生和极客来说,这是一颗性价比极高的“练手芯片”。我见过有人拿 SG2002 做掌上翻译相机,有人拿它做 AI 语音交互小助手,还有人把它接进机器人项目做视觉巡线。这些都是很好的实践方向。当然,学习过程中也要耐得住性子,尤其是模型转换和异构核通信这两个环节,刚开始可能会比较吃力,但一旦打通,你对“软硬结合”的理解会拔高一个层次。6. 个人经验总结与下一步扩展思路如果你正在评估 SG2000/SG2002,我给的最直接的建议是:别光看 datasheet 上的峰值性能,一定要拿你自己的模型和数据,在官方开发板上实地跑一遍。因为做 AI SoC 选型的核心,不是单纯比算力,而是看“你的模型 你的工具链 你的产品功耗约束”三者能不能在一个可接受的成本框架里同时满足。SG2000/SG2002 的最大魅力,恰好就是在这三者之间找到了一个目前市面上还比较少见的平衡点。按照我个人的实际使用体验,真正让我对这两颗芯片产生好感的,不是某个单一指标的惊艳,而是“异构”这两个字在各种场景里都实实在在地转化成了产品优势:低功耗时有小核顶着,高负载时有 A53 和 TPU 顶着,生态不兼容时有双架构兜底。这种设计哲学,在家电智能化、工业轻量视觉改造这类预算敏感但需求多样的项目里,很难不让人心动。最后再分享一个后续可以继续深挖的方向:如果你玩熟了单芯片的异构调度,可以试着通过以太网把多颗 SG2000/SG2002 组成一个小型分布式算力集群,各自负责不同的算法模型,比如一颗跑人脸检测、一颗跑活体识别、一颗跑语音唤醒。这种多芯片协同的玩法,虽然比不上大算力服务器,但在成本极其有限的项目里,算是一种很有意思的“算力众筹”思路。希望这篇文章能帮你把 SG2000/SG2002 的路走得更顺一点。