RK3568 vs RK3576 vs RK3588：机器人主控选型深度对比与量产避坑指南

1. 被反复追问的选型难题：这三颗主控到底怎么定

这几个月，我微信上被问得最多的问题之一，就是“RK3568、RK3576、RK3588 到底怎么选”。问的人有做AGV底盘的，有做机械臂控制器的，有做服务机器人整机的，也有做工业视觉检测设备的。大家的问题出奇一致：规格表看下来，三颗都是瑞芯微家的，都带NPU，都支持多路摄像头，价格也都有梯度，可真到自己产品上，反而不知道该花哪个钱。

这个纠结我太理解了。机器人产品和消费电子不一样，主控选型一旦定了，后续的载板设计、驱动适配、算法移植、量产测试全都压在这颗芯片上。中途换主控的成本极高，轻则重新画板，重则整个软件栈重来一遍。再加上机器人的产品生命周期普遍在五到十年，主控选错，后面几年都会很痛苦。

另一个现实是，瑞芯微这三颗芯片刚好卡在了机器人主控的三个典型档位上。RK3568 是性价比路线，适合轻量级控制和人机交互；RK3576 是中间力量，CPU 架构升级明显，NPU 提升到 6TOPS 级别，适合需要边缘AI推理的中端产品；RK3588 是目前的旗舰，无论 CPU 大核、NPU 算力、视频编解码能力还是接口丰富程度，都指向高端机器人场景。选型难，不是因为它们不够好，而是因为每一颗都有自己的强项和短板，关键看你的机器人到底要干多少活。

这篇文章不打算只贴规格书。我结合瑞迅科技在机器人行业大量量产项目的实测数据和踩坑记录，把三颗主控从芯片架构、接口资源、实际功耗、AI推理能力到量产落地过程中的典型问题，一条条拆开讲清楚。无论你是刚开始立项，还是已经画完板子在调试，这篇内容应该都能帮你省下一笔不小的学费。

2. 底牌对比：CPU、NPU 和接口资源上的真实差距

很多厂商选型时只看核心数和TOPS，这是个很容易走偏的习惯。核心数一样，架构不同，性能能差出一倍以上；TOPS口径不同，实际跑起模型来可能差出三倍。先把三颗芯片的关键硬件配置放在一张表里，再逐个展开说。

2.1 CPU 架构代差，比纸面参数更重要

RK3568 用的是四颗 Cortex-A55，这是ARM的能效核，日常跑 Linux、Qt 界面、Modbus 通讯、简单的运动控制算法问题不大，但遇到复杂的路径规划、SLAM 建图、图像预处理这类计算密集任务，会明显吃力。A55 强在省电，弱在单核性能，这一点在任何跑分软件里都体现得很直白。

RK3576 升级到四颗 Cortex-A72 加四颗 A53 的组合，A72 是当年的高性能大核，单核性能比 A55 提升非常明显。实际测试中，同样是跑 Qt HMI 的界面刷新和动画，RK3576 的流畅度比 RK3568 好一个档次。如果产品需要做导航、做视觉跟随、做实时路径规划，RK3576 的 CPU 余量能让你少掉很多头发。

RK3588 直接上了四颗 A76 大核。A76 相比 A72 又是跨代提升，单核性能大概能再翻一倍左右。在机器人场景里，这种提升意味着什么？意味着你可以把 SLAM 的主线程、感知模块、决策模块和 UI 分别跑到不同的大核上，相互不打架。我们测过，在 RK3588 上同时跑导航、8 路视频解码和 NPU 推理，系统负载仍然有富余，这是 3568 和 3576 很难做到的。

2.2 NPU 算力的口径问题：6TOPS 和 6TOPS 不是一回事

三颗芯片里，RK3576 和 RK3588 的 NPU 标称都是 6TOPS，但实际用起来差别不小。RK3588 的 NPU 是三核设计，支持 INT4、INT8、FP16 混合精度，调度更灵活；RK3576 是单核 NPU，同样是 6TOPS INT8，但在多模型并发和混合精度场景下，灵活性不如 RK3588。

这里有个很多团队会踩的坑：只看标称 TOPS，以为两颗芯片 AI 能力差不多，结果把 RK3576 的板子做出来，跑 YOLOv5s 时延 38ms，换到 RK3588 上只要 22ms，这才发现差距不在算力总量，而在算力的调度方式和实际利用率。所以我一直强调，TOPS 是纸面参数，必须在真实模型上验证推理时延和帧率，否则后面算法团队会找你拼命。

RK3568 的 1TOPS 算力，说实话，做轻量级模型勉强够用。比如跑一个简单的二维码识别、人脸检测，或者工业上的缺陷分类，可以接受。但想跑 YOLOv5s 实时检测，640 分辨率下推理时延大概在 110ms 以上，帧率不到 10FPS，实际应用体验会很吃力。

2.3 视频编解码能力决定远程监控和巡检功能的边界

机器人厂商很容易忽略视频编解码，但这是远程运维和巡检类机器人最核心的能力。RK3568 支持 4K 60fps 解码和 4K 编码，对大多数机器人来说够用了。RK3576 的解码能力升级到 8K，编码仍是 4K。真正拉开差距的是 RK3588，支持 8K 30fps 编解码，在同等码率设置下，可以同时处理更多路视频流。

瑞迅科技实测的数据是：RK3568 在 H.264 编码下稳定推 4 路 1080p30 流，RK3576 能做到 8 路，RK3588 可以做到 16 路以上。意思是，如果你的机器人要带多路摄像头做巡检记录或远程操控，RK3588 是唯一能扛住高路数并发编码的选择。

2.4 接口资源的完整度，直接决定载板设计工作量

三颗芯片的外设接口有很大差异。简单列一下：

• RK3568：PCIe 3.0、双千兆以太网、SATA 3.0、USB 3.0、多路 UART/CAN/I2C/SPI，MIPI CSI 数量有限，一般够 2 路摄像头。
• RK3576：在 3568 基础上增加了更多 PCIe 通道和更丰富的 MIPI 接口，适合需要挂多路摄像头或高速采集卡的中端产品。
• RK3588：接口最全，支持 PCIe 3.0 多通道、双千兆 GMAC、多路 MIPI CSI 和 DSI、SATA、USB 3.1 等，做高端机器人几乎不用外扩接口芯片。

一个容易被忽视的点是 CAN 和 UART 的数量。机器人底盘、机械臂关节、各类传感器大量使用 CAN，有的底盘还要接多个独立 CAN 总线做网段隔离。选型时务必把自己产品的接口矩阵列出来，一项项核对，否则接口不够，载板上就要加扩展芯片，成本、面积、稳定性都是麻烦。

2.5 功耗和散热：决定你的壳子里要不要加风扇

RK3568 整板典型功耗在 3W 左右，做个被动散热就能压住，非常适合对噪音和防尘有要求的机器人。RK3576 的功耗略高，但 8nm 工艺带来的优势让它在中负载下依然能靠散热片压住，只有长时间满载才需要风扇辅助。RK3588 在最坏情况下功耗能冲到 10W 以上，基本要标配主动散热，除非你的外壳散热面积做得非常大。

很多做室内服务机器人的厂商，对噪音很敏感。选 RK3588 就得认真设计风扇策略，转速多少、什么时候开启、怎么避免高频噪音。如果产品本身对噪音和防尘要求严格，而算力需求又没有高到必须上 RK3588，那 RK3576 是一个比 3588 更稳妥的折中选项。

3. 选型评估：先别急着数TOPS，从产品需求倒推主控决策

我收到过不少需求，上来就问“RK3588 能不能跑 YOLOv8”，但问到机器人具体什么形态、要接多少传感器、要跑多复杂的算法、工作环境温度是多少，对方往往答不上来。这其实暴露了一个问题：选型不是从芯片开始的，而是从产品需求倒推的。

3.1 先列功能清单，再做接口矩阵和算力测算

正确的做法是，先把自己产品的功能清单写全。比如一台巡检机器人，可能需要：双摄像头（可见光+热成像）、激光雷达、超声波传感器、惯性测量单元、语音播报、4G/5G 通讯、远程视频推流、本地人脸识别或表计识别，可能还要接一个机械臂做操作。这些功能每一项都要落到具体的接口和算力上。

接口层面，数一遍需要多少路 MIPI CSI、以太网口、USB、串口、CAN。算力层面，把算法模型在 PC 上跑一遍，看单帧推理时延要求，再估算目标平台的 NPU 利用率。宁可留 30% 以上的算力余量，也别把 NPU 跑到 90% 以上，因为系统还有 CPU 参与前后处理，还有别的任务要抢资源。

3.2 不同机器人类别的典型负载参考

我按照瑞迅科技服务过的客户项目，给几个粗略的选型画像：

3.3 主控价格只是BOM的一角，别忽略周边成本

选型时还要算一笔账：主控芯片的价格、配套的内存和存储价格、载板的 PCB 层数、散热模组成本、结构件成本，甚至生产测试时间。RK3588 相比 RK3576，主控价格高出不少，配套的 LPDDR5 和更大容量存储也会更贵，电源方案的复杂度和散热设计成本也跟着上去了。整机 BOM 算下来，差异可能不止主控差价本身。

如果产品定位是中低端，卖点是续航和价格，用 RK3588 只会拉高整机成本，让产品在市场上很被动。反过来，高端视觉导航机器人如果用 RK3568，算力受不了，开发团队天天优化模型也不是长久之计。

3.4 软件生态也要列入决策

芯片底子再好，工具链跟不上也白搭。瑞芯微目前的 RKNN 工具链已经相对成熟，RKNN-Toolkit2 支持 PyTorch、ONNX、TensorFlow、Caffe 等主流框架的模型转换，也支持 RK3588 上跑 YOLOv8 这类新模型。但工具链的成熟度在三颗芯片上并不是完全一样的，RK3588 和 RK3568 的社区资料明显多于 RK3576。如果你团队里的算法工程师习惯在网上找现成案例，选 3588 或 3568 的查资料体验会好很多，RK3576 相对新一些，很多问题要靠自己试。

操作系统方面，三颗芯片都能跑 Debian/Ubuntu，RK3568 和 RK3588 还有大量 Buildroot 和 Android 的现成适配，设备树修改、驱动移植案例非常多。RK3576 的适配资料正在快速补齐，但现阶段遇到冷门外设的驱动问题，可能需要更多时间排查。

4. 瑞迅实测：机器人典型负载下三平台的表现差异

规格参数说再多，不如实际跑一轮数据。瑞迅科技在过去半年里用统一规范的测试方法，对 RK3568、RK3576、RK3588 三个平台做了多轮对比测试。这里把与机器人应用最相关的几项数据分享出来，顺带说说我的解读。

4.1 测试条件说明

三个平台都采用瑞迅科技的标准机器人载板，内存和存储容量按各平台主流配置（RK3568 配 4GB LPDDR4，RK3576 配 8GB LPDDR4X，RK3588 配 8GB LPDDR5），散热方案统一使用相同尺寸的铝制散热片加可调速风扇，系统都跑瑞迅定制的 Debian 12，内核版本保持一致。测试场景分两部分：基准性能部分在室温 25℃ 的实验室进行；长时间稳定性部分在带外壳的整机状态下跑 72 小时。

4.2 实测数据：CPU基准、AI推理、视频编码、功耗温升

4.3 逐项解读：数据背后隐藏的工程含义

CPU 跑分这一项，RK3588 相比 RK3576 差不多翻倍，而 RK3576 相比 RK3568 也翻倍。这个差距在实际体验里非常明显，尤其是机械臂的运动规划、AMR 的路径搜索、复杂 UI 的渲染。如果你的算法团队是在 x86 上开发验证的，移植到 ARM 平台后性能预期可以按这个跑分差距来粗略估算。

AI 推理这部分，RK3576 和 RK3588 虽然 NPU 都是 6TOPS，但 YOLOv5s 的推理时延差距有 42%。原因在于 RK3588 的三核 NPU 可以更好地把模型的分支计算拆分到不同核上，而 RK3576 的单核 NPU 只能顺序执行。如果你的产品要跑较大的检测模型，或者要同时跑多个模型，RK3588 和 RK3576 的差距会比纸面 TOPS 更能反映真实体验。

视频编码路数差距最直观。巡检机器人、安防机器人往往要同时推多路视频到后端平台，这里的编码能力直接决定产品能支持的摄像头数量。实测下来，RK3588 在 16 路 1080p30 编码时码率依然稳定，CPU 占用也不算离谱，确实适合视频密集型场景。

功耗和温度的数据，要结合机器人外壳的实际条件来看。RK3588 满载 81℃ 是在带主动散热外壳条件下的数值，如果你的外壳是全封闭塑胶壳且没有风扇位，这个温度会更高，元器件老化和热漂移问题也会更明显。RK3568 和 RK3576 在被动散热外壳下都能压到 70℃ 以下，这是很多室内机器人选择中端芯片的真正原因。

5. 量产阶段躲不开的六个深坑，提前帮你排雷

芯片选型定了，板子画好了，系统能跑了，真正的考验才刚刚开始。量产和样品是两个世界，很多问题在实验室里根本看不出来。这一节把瑞迅科技在 RK3568、RK3576、RK3588 量产项目中遇到的典型问题逐个拆解，附上排查方法和解决方案。

5.1 RKNN 算子兼容性：模型训练环境和板端推理环境可能脱节

问题现象：算法团队用 PyTorch 训练好的 YOLOv8 模型，在 PC 上转成 RKNN 格式后，加载到板端推理，结果发现某些层被 CPU 回退执行，时延暴涨，甚至直接报算子不支持的错误。

排查思路：首先确认 RKNN-Toolkit2 和板端 RKNN Runtime 的版本是否匹配，最简单的方法是在 PC 模拟环境下先跑一遍推理，观察哪些层没有落到 NPU 上。其次，检查模型里是否用了比较新的算子，比如某些注意力机制模块、动态 shape 操作、自定义激活函数，这些算子 NPU 支持度往往滞后。

经验建议：从算法选型阶段就要考虑 RKNN 算子兼容问题。YOLOv8 这类主流模型已经有成熟支持，但如果你用了新发表的网络结构，先在 RKNN-Toolkit2 的算子支持列表里逐项核对，再去训练，否则训完才发现 NPU 不支持，返工成本非常高。瑞迅科技内部的习惯是，任何新模型先在 RK3588 开发板上跑通一遍，再谈优化，这个顺序不能乱。

5.2 MIPI CSI 摄像头调试：设备树只是开始，电源时序更坑

问题现象：摄像头在 RK3568 平台无法正常出图，dmesg 里反复报 sensor 初始化失败。我们遇到过 OV5695 的调试，整整花了两天才定位到问题不是 I2C 地址错误，而是供电时序不对。

排查思路：MIPI 摄像头出图依赖完整的链路，包括供电、时钟、I2C 配置、MIPI 物理层协商、ISP 初始化。遇到不出图，先查供电脚电压是否在 sensor 数据手册范围内，再查 MCLK 时钟频率和波形，然后用示波器量 RESET 和 PWDN 引脚的时序关系。很多时候 sensor 的 reset 拉低时间不够，或者上电顺序反了，都会导致 I2C 读写失败。设备树里的寄存器配置只是最表层的问题。

经验建议：画载板的时候，给 MIPI 摄像头的供电、时钟和复位引脚预留测试点，Software 调试时用示波器抓时序。另外 RK3588 的 MIPI CSI 接口更多，走线要求也更高，建议 MIPI 差分对做等长和阻抗控制，否则高速信号下会有花屏或丢帧问题。

5.3 以太网 PHY 的 25MHz 参考时钟方向配置

问题现象：RK3568 平台调试双千兆网口时，其中一个网口 link 不稳定，时通时断，抓包能看到大量丢包。排查到最后才发现是 PHY 芯片的参考时钟方向配置错了，RMII 接口的 eth0_refclko_25m 信号方向不对，导致 PHY 内部时钟同步异常。

排查思路：RK 平台的 GMAC 支持多种时钟模式：PHY 提供时钟给 MAC、MAC 提供时钟给 PHY、或者外部晶振提供时钟。要仔细看原理图上 25MHz 参考时钟是谁输出的，然后在设备树的 mac 节点里配置对应的 clock-phandle 和 tx/rx 延迟。很多人上来就复制参考设计的设备树，没意识到自己的 PHY 型号和参考设计不一样，时钟方向也对不上，网上确实有大量 rk3568 eth0_refclko_25m 相关的提问。

经验建议：画原理图前先确认 PHY 芯片的参考时钟走线方向。市面上常见的 RTL8211F、YT8531、IP101GRI 对时钟模式的要求不完全一样，不能无脑抄同一个设备树配置。调试网络问题时，先用 ethtool 看 link 状态和速率协商，再查时钟，这个顺序能省很多时间。

5.4 PWM 风扇调速与转速读取的坑

问题现象：RK3588 平台做风扇控制，PWM 调速正常，但读取风扇转速始终为 0。风扇明明是四线的，接的也是 TACH 引脚，为什么读不到转速？

排查思路：风扇的转速反馈引脚输出的是开漏脉冲信号，一般需要上拉电阻。如果载板上 TACH 引脚没加上拉，或者上拉电阻选的太大，脉冲幅度不够，PWM capture 模块检测不到有效边沿，转速自然就是 0。另外 RK3588 上的 PWM capture 和 PWM 输出是独立的通道，不是任意 PWM 引脚都能做输入捕获，必须确认硬件上接的是支持 capture 的引脚。

经验建议：设计载板时给风扇 TACH 引脚加 4.7kΩ 到 10kΩ 上拉，靠近主控端放一个小电容滤波。软件层面，用 debugfs 或 ioctl 直接读 PWM capture 的原始计数值，确认底层是否有信号，再往上做转速换算，这样可以快速区分硬件问题还是软件问题。很多 RK3588 开发板的设备树例程里，pwm-fan 节点的参数也需要根据实际风扇参数调整，否则调速曲线会很突兀。

5.5 烧录与启动流程：Maskrom 进不去比什么都焦虑

问题现象：开发阶段刷机变砖，RK3588 板子插上 USB Type-C 线，电脑上没有任何反应，进不了 Maskrom 模式，U-Boot 也进不去。

排查思路：RK 芯片进入 Maskrom 的常规流程是先按住板上的 Maskrom 键或 Recovery 键，再插 USB Type-C 线上电，系统会进入下载模式。进不去有几个常见原因：第一，线材问题，很多 USB 线只支持充电不支持数据传输；第二，驱动问题，Windows 上没装 RK 驱动，Linux 上没有 rkdeveloptool；第三，硬件上 Type-C 的 CC 引脚和 USB 数据脚没接对。

经验建议：量产开发团队一定要有一套稳定的烧录流程，并且把烧录遇到的问题整理成文档。瑞迅科技推荐的流程是：在 U-Boot 阶段先通过串口确认启动到了哪一步，再决定是进 Maskrom 还是用 recovery 方式刷机。miniloader.bin 和 U-Boot 的版本要配套，混用版本经常会导致烧录到一半失败。还有一点很重要：批量生产时，烧录工装和线材质量要统一，产线上因为线材问题导致的刷机失败率会比你想象的高。

5.6 eMMC 与日志寿命：频繁写日志会提前杀死你的存储

问题现象：一款巡检机器人设备运行几个月后，系统越来越卡，最终无法启动。检查发现 eMMC 的寿命耗尽，坏块数量爆表。

排查思路：机器人在运行过程中，日志系统、数据库、算法缓存都在频繁写 eMMC。尤其是长时间运行的设备，如果日志没有做滚动清理，或者频繁做掉电写入，eMMC 的 P/E 周期很快就会被吃完。我们遇到过某个项目把图像缩略图缓存直接写到 eMMC，一天能写几十 GB，两个月就把 eMMC 写穿了。

经验建议：所有频繁写入的数据，优先放到内存文件系统（tmpfs）或外接 SSD/U 盘。如果必须落地到 eMMC，做两层保护：一是文件系统层面，使用适合 Flash 的日志型文件系统，并开启垃圾回收和磨损均衡策略；二是应用层面，日志必须按大小和日期滚动，严格控制写频率。eMMC 选型也别只看容量，要看 endurance 等级，工业级 eMMC 和消费级 eMMC 的寿命可以差出数倍。

6. 三档机器人产品参考配置单与升级路径

选型最终要落到具体的产品线上。结合前面的分析和实测数据，下面给出三档典型机器人产品的参考配置单，并说明配置理由。这里以瑞迅科技的量产方案为原型，你可以在这个框架上按自己产品的实际情况调整。

6.1 入门级配送/轻载 AMR 底盘

适合产品：园区配送机器人、轻型 AGV、简易 AMR 底盘。核心诉求是成本可控、接口够用、长时间运行稳定。

推荐配置：RK3568 主控，4GB LPDDR4 + 32GB eMMC，双千兆网口，4 路 USB 3.0，2 路 CAN，可选 1 路 MIPI CSI 摄像头，适配 7 寸以下 HMI 屏幕，被动散热或低速无刷风扇。

配置理由：这类机器人主要做二维码导航或磁条导航，CPU 跑运动控制算法绰绰有余，NPU 用来做轻量级避障或 QR 识别也够了。功耗低，电池续航压力小，整机 BOM 成本能被压得很低，适合走量。如果你的产品后续要加更复杂的视觉功能，建议在载板上预留 PCIe 或 USB 接口，方便外接算力棒或协处理板。

6.2 中端服务/导览机器人

适合产品：餐厅送餐机器人、商场导览机器人、病房配送机器人。核心诉求是界面流畅、避障效果好、语音交互响应快、噪音低。

推荐配置：RK3576 主控，8GB LPDDR4X + 64GB eMMC，双千兆网口，2~4 路 MIPI CSI 摄像头，2 路 CAN，大尺寸触摸屏，被动散热加强散热片，可选无音风扇。

配置理由：RK3576 的 A72 大核跑 Qt/Flutter 类 HMI 很流畅，6TOPS 的 NPU 跑人体检测、语义分割、避障模型比 RK3568 轻松太多。相比 RK3588，它的功耗和散热压力小，室内安静环境下更容易设计出无感散热方案。这个档位是 RK3576 最舒适的区域，比 3588 便宜，比 3568 强不少，卡位非常准。

6.3 高端巡检/视觉导航机器人

适合产品：电力巡检机器人、安防巡逻机器人、复合机器人、机械臂视觉伺服工作站。核心诉求是算力强、多路视频、AI 模型并发、扩展接口丰富。

推荐配置：RK3588 主控，8GB 或 16GB LPDDR5 + 128GB eMMC，双千兆网口，多路 MIPI CSI 摄像头，PCIe 接口（挂激光雷达采集卡或 SSD），多路 CAN/UART，主动散热风扇，独立电源模块。

配置理由：RK3588 的 CPU 和 NPU 组合能同时处理导航、感知、决策和多路视频编码。16 路 1080p 编码能力意味着可以接入十几个摄像头做巡检记录。接口资源丰富，基本不需要外扩主控板，系统集成度更高。这类产品的客户对价格不敏感，但对长时间稳定运行和功能完整性要求极高，RK3588 是目前瑞芯微阵营里最稳妥的选择。

6.4 从 RK3568 向上升级的三个移植要点

很多团队先拿 RK3568 做原型验证，后期发现算力不够，想升级到 RK3576 或 RK3588。这里提醒三个移植重点：

第一，管脚兼容性。RK3568 和 RK3588 的管脚不是简单 pin-to-pin 兼容，直接替换芯片不现实。最省事的方式是选择管脚兼容设计的核心板方案，瑞迅科技的 RK3568 和 RK3576 核心板在管脚定义上做了兼容设计，升级时可以沿用同一套载板。如果是从 RK3576 升级到 RK3588，受限于电源和 DDR 通道数量差异，载板改动会比较大，前期选型时就要考虑清楚。

第二，设备树和驱动。三颗芯片的设备树结构差异明显，外设节点兼容但参数不同。升级后不能直接沿用旧设备树，需要根据芯片手册重新核对 DDR 频率、电源域、时钟树、MIPI 通道映射等配置。我们踩过 RK3576 的坑，直接把 3568 的设备树改了几行就跑，结果摄像头数据错乱，查了很久才发现是 MIPI CSI 的通道映射不同。

第三，软件栈和 AI 工具链。RKNN Runtime 的版本更新会影响已转换模型的兼容性，升级主控平台时，算法模型需要重新转换和验证。尤其要注意 RK3576 的 NPU 工具链版本和 RK3568 不完全一致，模型在 3568 上转换的 rknn 文件，放到 3576 上不一定能直接跑，需要重新导出。

最后分享一点我的真实体会

做机器人主控选型这些年，最大的感受是：选型本质上不是在选芯片，而是在选“未来三到五年的开发和生产体验”。RK3568、RK3576、RK3588 这三颗芯片，没有绝对的谁好谁差，只有适不适合你的产品。我见过不少团队在选型阶段纠结很久，最后发现真正的问题不是芯片性能不够，而是对产品的功能边界没想清楚。建议立项时就把功能清单、接口矩阵、算力预算法、工作环境约束写进需求文档，然后拿着文档去和方案商聊，这样比自己对着规格书猜高效得多。还有一个小建议，如果条件允许，把三颗芯片的评估板都拿到手，用自己真实的算法和负载跑一轮，比看任何评测文章都靠谱。选型会议开十次，不如实测数据跑一天。