企业官网建设流程全解析

去年在客户现场被问到：RK3588+RK1820这种组合，到底能不能跑嵌入式AI大模型？我当时的答复是：能，但模型选型和部署方式不对，照样白搭。真正把这两颗芯片放在一块儿调过一轮以后，我才敢说“端侧AI到底能做什么、不能做什么”这件事，值得好好写一份实战指南。这篇文章会把9个常见场景的模型选型思路、RKNN部署链路、端侧大模型和量化模型的落地经验全部摊开讲，适合正在做RK3588方案选型、嵌入式AI开发，或者想把大模型塞进边缘盒子里的工程师参考。

1. 为什么需要RK3588+RK1820这套组合

先聊一个经常被低估的问题：RK3588本身的NPU算力其实不差，6 TOPS的整数算力放两年前足够让很多视觉项目跑得飞起，但放到今天的大模型、多模态、高分辨率检测场景里，就明显吃力了。我见过太多项目在选型阶段只看了NPU的TOPS数字，结果真跑起来才发现瓶颈根本不在算力，而在内存带宽、模型驻留空间和算子支持范围上。RK1820这套AI协处理器方案，本质上就是为了补上这部分短板而出现的。

1.1 RK3588的算力构成与真实短板

RK3588的NPU是3核架构，官方标称6 TOPS，支持int4、int8、int16混合精度，单看数字确实不低。实际跑YOLOv8s这类目标检测模型，640×640输入、int8量化，在LPDDR4x 4266的板子上能做到50到80fps，这个成绩在端侧设备里非常能打。我手上这块方案板，跑YOLOv8n甚至能到80fps以上，连续跑半小时也不会出现明显降频，这说明RK3588的NPU做实时视觉任务，是靠谱的。

但一旦把任务从“感知”换到“生成”，情况就完全变了。以7B参数的大语言模型为例，int4量化后权重文件大约4GB，模型推理时每生成一个token，都要把大部分权重从DDR里重新过一遍，这个操作会被内存带宽死死卡住。RK3588常见搭配的LPDDR4x带宽大概在34GB/s左右，算下来跑7B模型大概只能出3到5个token/s，别说对话了，连流式输出都嫌慢。这就是RK3588最真实的瓶颈：不是算力不够，是数据和权重的搬运速度跟不上。

所以我在做方案评审时一直强调一句话：选RK3588还是选“RK3588+协处理器”，先别盯着TOPS看，要看你的模型是卷积为主还是Transformer为主，是单帧处理还是自回归生成。前者RK3588自己就能扛，后者才需要认真考虑RK1820这种算力扩展方案。

1.2 RK1820协处理器在方案里的角色划分

从目前公开的方案资料和板厂拿到的信息来看，RK1820的定位是面向端侧AI与边缘大模型场景的协处理器，通常通过高速总线与RK3588主控连接，形成“主控SoC+AI加速单元”的双芯片架构。它的核心价值不是简单叠加算力，而是把大模型推理、多模态特征提取这些重计算任务从RK3588身上卸下来，让RK3588安心干它擅长的事：跑Linux系统、管外设、做视频编解码、处理业务逻辑。

我习惯把这套组合理解成“项目经理+专家团队”的分工。RK3588是项目经理，负责调度、对接外部设备、处理各类杂务；RK1820是专家团队，只在遇到大模型这类高难度任务时才出手，而且一出就是全力。实际部署时，RK1820最好使用独立的内存通道，这样大模型的权重不会挤占RK3588系统内存的带宽，视频流、网络传输、外设中断这些日常负载才不会跟着遭殃。

当然，RK1820的具体算力规格、接口带宽、SDK开放程度目前还比较依赖方案商的实现，不同核心板之间的差异可能很大。我的建议是：做技术选型时，一定要拿到板厂关于协处理器推理runtime的明确承诺，比如是否支持RKNN统一抽象、是否开放int4量化算子、能否跑llama.cpp自定义后端，这些比芯片本身的名字重要得多。

1.3 一套落地系统的典型软硬件构成

把RK3588和RK1820放在同一块核心板上，软件层面大致是这样的结构：最底层是Linux内核与协处理器驱动，往上跑的是推理runtime层，再往上才是业务服务。我目前项目里跑得比较顺的组合是Debian系Linux + RKNN-Toolkit2做模型转换 + RKNN-Lite做板端推理，大模型部分用llama.cpp的量化版本跑，业务服务用Python和C++混编。

硬件层面，除了核心板本身，内存容量建议直接上16GB甚至32GB。原因很直白：RK3588跑系统、跑视觉模型、跑中间件，内存本来就有基础消耗，如果再叠加一个4GB以上的大模型权重驻留，8GB板子很容易OOM。存储也要注意，模型文件和推理日志加起来动不动几十GB，最好选带eMMC加NVMe SSD接口的底板。还有就是散热，RK3588全核满载加协处理器同时工作，发热量不容忽视，被动散热方案在长期高负载下大概率会触发降频。

这套组合最适合的设备形态是边缘计算盒子、工业AI控制器、服务机器人主机这类对功耗相对宽容、对实时性和本地数据安全要求高的场景。如果是便携式电池设备，还是得重新评估功耗预算，RK1820这一类协处理器满负荷跑大模型时，功耗不是小数目。

2. 9大模型选型矩阵：按场景需求做减法

模型选型是嵌入式AI项目里最容易被带偏的一步。很多团队一开始就奔着“效果最好”去，把mAP、BLEU指标拉满，结果模型到了端侧要么跑不动，要么帧率惨不忍睹。我在实际项目里的做法刚好相反：先定设备资源上限，再倒推模型选型。RK3588+RK1820这套组合虽然比单RK3588宽裕不少，但也没宽裕到可以挥霍的程度，所以做减法才是关键。

2.1 一张表看清9个模型方向

下面这张表是我在多个项目里沉淀下来的推荐矩阵，按“场景→推荐模型→量化格式→参考性能→适用设备”排列，覆盖了目前RK3588方案上最常见的9类AI应用。性能数据来自不同板卡和不同SDK版本的实测或方案商反馈，具体以你的硬件环境为准，但选型方向可以放心参考。

这张表最重要的信息不是哪个模型第一名，而是“每个位置都留了余量”。比如目标检测选了YOLOv8n而不是YOLOv8s，理由是RK3588的NPU跑s版本时CPU后处理压力已经上来，如果想同时跑多个模型，n版本才有余量。

2.2 实时视觉类怎么选：YOLO、姿态与分割

实时检测这个赛道现在几乎就是YOLO系列的天下，但YOLO版本选哪个很有讲究。YOLOv5s至今仍有大量工业项目在用，主要是生态成熟、RKNN转换踩坑少；YOLOv8n/s和YOLO11n在精度和推理速度上更均衡。从部署角度，我更推荐先在YOLOv8n上做精度验证，如果指标不够再升级到s版本，而不是反过来。因为端侧项目的精度瓶颈往往不在模型容量，而在数据质量和量化校准，这个后面展开说。

姿态估计我首推MoveNet，尤其是Thunder版本。它的输出是17个关键点，结构简单，模型只有几十MB，RK3588跑起来非常轻松。健身镜这类产品需要实时性，MoveNet的精度虽然在遮挡场景下一般，但胜在稳定、不挑硬件。如果对精度要求高，Lite-HRNet是更好的选择，但参数和计算量会明显上升，部署时要做好帧率预期管理。

语义分割在这个算力级别上最怕的是模型太大导致内存爆炸。PIDNet-S是最适合RK3588的轻量分割模型之一，它在cityscapes类数据集上效果不错，int8量化后跑512×512输入能稳在25fps左右。DeepLabV3-Lite也可以，但需要留意膨胀卷积在RKNN工具链上的算子支持情况，部分版本转换时会弹出不支持的算子，这个要提前试一遍。

2.3 语音与文本类：ASR、OCR怎么选

语音识别在RK3588上跑，传统KWS唤醒词模型完全没有压力，真正有挑战的是端侧流式ASR。我推荐SenseVoice-Small，它对中文、英文、粤语的支持都不错，模型量级在几百MB以内，int8量化后可以做到实时率大于5，也就是说1秒音频只需要200毫秒左右处理完。Whisper-tiny也可以，但它在NPU上能加速的主要是编码器部分，解码部分还得靠CPU，所以整体延迟会偏高，适合对实时性要求不高的离线转写场景。

OCR在嵌入式设备上通常拆成“文本检测+文本识别”两个模型串联跑。PaddleOCR-mobile的det和rec模型都做了轻量化，RK3588单帧检测大约100ms，识别另加100ms左右，整条链路200到300ms的延迟，对大多数扫码、录单、铭牌采集场景够用。RapidOCR的优势是不依赖Paddle框架，部署更清爽，精度和PaddleOCR-mobile接近。要注意的是OCR的精度非常依赖图像预处理，打个光、调个角度，效果差距远超模型本身的差距。

2.4 多模态与检索类：潜力最大也最需要谨慎

多模态检索是RK1820这类协处理器进入视野后最值得关注的方向。MobileCLIP-S能把图片和文本映射到同一个向量空间，实现“拍一张图，找相似产品”“用一句话描述，匹配图像”这类功能。模型本身不算大，但图片预处理、文本编码、向量检索这几步加起来延迟不低，放在RK3588单芯上跑会比较吃力，配合RK1820后可以明显改善。

这类模型的部署坑主要在“框架依赖”。很多多模态模型用的是transformers库，算子组合复杂，RKNN工具链不一定全部支持。我的经验是：先跑通PyTorch上的FP32版本，再逐步替换支持度最高的子模块，最后才做完整量化。跳过这一步直接量化，大概率会碰到精度崩盘还不容易定位。如果项目周期紧张，建议优先考虑MiniCPM-V这类专门为端侧优化的多模态模型，它们的校测和部署经验更接近实际工程。

3. 从ONNX到RKNN：整套部署链路与量化实操

模型选型做完，接下来就是真正的硬功夫：把PyTorch或者TensorFlow训练好的模型，转换成能在RK3588/RK1820上高效运行的RKNN格式。这条链路我走通了不止一遍，但每次还是会遇到幺蛾子。这里把标准流程和最容易出问题的点拆开讲。

3.1 RKNN-Toolkit2转换流程与关键参数

RKNN-Toolkit2是瑞芯微官方提供的模型转换和仿真工具，目前一般跑在x86的Ubuntu主机上。转换流程本身不复杂，但因为涉及ONNX导出、算子映射、量化校准三个步骤，每一步都可能埋雷。

from rknn.api import RKNN rknn = RKNN() # 配置均值方差、目标平台 rknn.config( mean_values=[[0, 0, 0]], std_values=[[255, 255, 255]], target_platform='rk3588' ) # 加载ONNX模型，注意输入尺寸 rknn.load_onnx( model='yolov8n.onnx', input_size_list=[[1, 3, 640, 640]] ) # 构建RKNN模型，这里决定是否量化 rknn.build(do_quantization=True, dataset='dataset.txt') # 导出 rknn.export_rknn('yolov8n.rknn')

这段代码看起来简单，但有两个点必须提醒。第一，dataset.txt里放的校准图片路径不能随便挑几张网上图片，必须贴近真实场景。我见过一个车牌识别项目，校准图全是白天场景，结果夜间模型精度直接掉了15个点。第二，mean_values和std_values必须和训练时完全一致，否则等于把输入分布悄悄改了，模型精度必然受影响。这两个参数看似基础，却是转化掉点最常见的人为原因。

3.2 量化校准：决定模型命运的一步

int8量化是嵌入式AI部署的核心，也是精度抖动的主要来源。RKNN-Toolkit2支持普通量化和混合量化，普通量化就是把所有权重和激活都压到int8，速度快但精度损失可能大；混合量化则让敏感层保持float16或float32，精度更好，但推理性能和内存占用会受影响。

做量化校准最省事的做法是收集200到500张真实场景图，覆盖不同光照、角度、遮挡情况，把它们整理成dataset.txt的路径列表。校准集越接近真实推理分布，量化后的精度损失越小。这一步偷懒的结果通常很惨，我甚至遇到过同一个模型两次量化，精度差8个点的极端情况。

量化后一定要用rknn.accuracy_analysis这个工具跑一遍逐层精度分析，它能告诉你是哪个算子切到int8后掉点最严重。看到瓶颈层后，要么把这层加入混合量化白名单，要么回到训练阶段调整模型结构。这里有个小技巧：如果量化后掉点集中在某个激活层，在该层后面插入一个BN层重新训练几轮，往往能让量化误差明显下降，这是我在一个分割项目里试出来的偏方。

3.3 板端推理API选择：Python vs C

RKNN模型导出后，在板端推理有两种主流方式：Python API（RKNN-Lite）和C API。Python API适合快速验证、原型开发、和业务逻辑解耦程度高的场景。代码非常简洁，初始化后直接inference就行：

from rknnlite.api import RKNNLite rknn_lite = RKNNLite() rknn_lite.load_rknn('yolov8n.rknn') rknn_lite.init_runtime(core_mask=RKNNLite.NPU_CORE_AUTO) outputs = rknn_lite.inference(inputs=[img])

C API则适合对性能、内存控制有要求的正式产品，尤其是在多线程环境下，C的零拷贝特性和显式内存管理能省下不少开销。实际项目中我通常这样分：原型阶段用Python，明确性能瓶颈后把热点模块用C重写。Python版本多线程调用时存在GIL竞争，而NPU推理本身会阻塞线程，处理不当容易跑不满CPU，导致整个流水线效率下降。

另外，RK3588的NPU支持3核独立调度，NPU_CORE_AUTO会自动均衡，但在多模型并发场景下建议手动指定核心，比如实时检测模型占NPU核心0和1，大模型推理占核心2，这样能避免相互干扰。这也是后面第6部分会详细展开的异构调度思路。

4. 端侧大模型部署：Ollama、llama.cpp与量化模型的组合拳

端侧大模型是RK3588+RK1820这套组合最让人兴奋的应用方向。网上天天有人在问“xxx模型能不能本地部署”，也确实越来越多模型被验证可以在嵌入式设备上跑起来，但“能跑”和“能商用”之间隔着一整条工程化的鸿沟。这一章把从模型参数选型到部署工具链的完整路线理清楚。

4.1 参数级别与内存带宽的关系

端侧部署大模型，第一件事就是计算“内存账”。模型选多大参数，直接决定它能进哪一档设备：

这里为什么强调int4？因为int8量化下7B模型权重就有7GB，光驻留就压垮大部分嵌入式设备的DDR。而int4量化在3B到4B参数级别几乎是必须的，GGUF格式的Q4_K_M是目前端侧大模型的主流量化方案，它在精度和显存占用之间取得了很好的平衡。我自己跑过Qwen2.5-3B-Instruct和DeepSeek-R1-Distill-Qwen-1.5B，前者对话质量高一些但延迟略大，后者更轻快，适合追求响应速度的场景。

4.2 llama.cpp与Ollama的部署实操

端侧大模型的推理引擎，目前社区公认度最高的是llama.cpp和基于它构建的Ollama。llama.cpp的优势是轻量、可定制性强，能把GGUF模型利用到极致；Ollama则封装得更完善，一行命令就能拉起模型服务。在RK3588板子上，我推荐的路线是先用Docker方式跑Ollama，把模型目录挂载出来，这样升级模型版本和备份都很方便：

docker run -d --name ollama \ --restart=always \ -v /mnt/ollama:/root/.ollama \ -p 11434:11434 \ ollama/ollama # 拉取并运行3B级模型 ollama run qwen2.5:3b

Ollama会默认按CPU模式跑，对RK3588来说这是最稳的路径。如果你希望让NPU协处理器参与大模型推理，就得额外留意板厂SDK有没有开放llama.cpp的RKNN后端接入。这个领域发展很快，不同方案商的支持程度差异很大，有的已经能让小模型的部分算子卸载到NPU，但大多数还处于早期验证阶段。我的建议是先把CPU路径跑稳定，再逐步尝试NPU卸载，不要一上来就押注全链路加速。

4.3 模型精简技巧：从7B到可用的2B

很多时候项目需求听起来需要7B模型，但分析清楚真实任务后，1.5B到3B完全够用。做模型精简不单单是换小模型，更是一套系统的蒸馏和裁剪工程。我在一个离线知识问答项目里，最初客户指定要7B模型，跑一轮压力测试后发现响应太慢，根本不可用。后来我们把任务拆成“意图识别+段落检索+摘要生成”，摘要生成只负责几百字的输出，用DeepSeek-R1-Distill-Qwen-1.5B就能满足，整套系统的token/s提升了3倍，回答质量客户完全接受。

另外一个很实用的技巧是控制上下文长度。嵌入式设备上跑大模型，不要动不动就开8K或者32K上下文，每增加一个token的KV cache都要占用额外内存。很多场景把上下文限制在2K以内，模型可用性和稳定性都会有明显提升。对会话历史的处理，优先做摘要压缩而不是无限堆积原文。

4.4 场景化功能延伸：语音助手与知识库问答

大模型部署完成后，真正能让产品落地的场景通常还要叠加其他AI能力。我做得最多的是两类：语音助手和本地知识库问答。语音助手的完整链路是“唤醒词→ASR→大模型→TTS”，其中ASR和TTS都可以用RK3588的NPU加速，大模型跑在RK1820或者CPU，链路延迟要做到500ms以内的体验，还是很有挑战的。

知识库问答则更适合用RAG架构：先把文档切块、向量化、存入向量库，用户提问时先向量检索再丢给大模型生成答案。这里向量化模型（比如bge-small-zh）体积小、推理快，非常适合跑在RK3588的NPU上，而大模型只需要处理检索结果和生成最终回答，计算压力小很多。编排层我推荐用Dify这类开源应用平台，它们对Ollama、向量库、多Agent工作流都有现成支持，能把一个大模型项目快速做成可交付的产品原型。

5. 9大模型场景的落地细节与踩坑记录

前面讲的都是方法和链路，这一章是实打实的“事故现场”。每个场景单独跑通是一回事，把它们装进同一个设备里、保证长期稳定运行是另一回事。我把自己在项目中反复踩过的坑总结成三类，希望你能绕开。

5.1 实时视觉类：检测框抖动、多线程调度与NMS开销

目标检测模型跑起来容易，跑稳很难。最常见的问题是检测框抖动，尤其在做安防和工业检测时，模型对相邻帧的预测框坐标会有几像素的波动，直接展示给客户看会显得很不专业。对策无非几种：增加置信度阈值、做时间维度的低通滤波、或者在输出层做轻量级跟踪关联。不要指望模型本身能在帧间完全稳定，端侧算力有限，必须在后处理上想办法。

另一个大坑是CPU后处理占用。YOLO模型在NPU上推理很快，但输出解码、NMS、坐标映射都要在CPU上完成，如果业务主线程还要处理视频流、UI绘制，就会出现“NPU等CPU”的情况，整体帧率反而被后处理拖垮。我建议把后处理放到独立线程，并尽量使用零拷贝方式读取NPU输出，避免反复复制大数组。如果发现NMS成为瓶颈，优先检查是不是类别数设置过大或者锚框数量过多，这两个参数通常可以按场景压缩。

RK3588的NPU多核调度同样值得注意。跑多个视觉模型时，如果不加区分地交给NPU_CORE_AUTO，大模型或高分辨率检测任务可能会占用全部核心，把最关键的实时模块挤到无核可用。官方支持手动指定核心号，这个一定要用起来，宁可让非实时任务排队，也要保证核心视觉任务有固定算力。

5.2 语音与OCR：端点检测、长文本识别与图像预处理

语音识别项目看起来只是把音频丢给ASR模型，实际上真正决定体验的是前端信号处理。麦克风采到的音频如果不做端点检测，环境噪声会不断触发识别，大模型也会频繁被唤醒，设备功耗直接拉满。我最初在门禁项目里没有做VAD，结果一天下来“无声会话”占了总调用量的一半。后来加了基于能量和过零率的轻量VAD，误触发率下降了90%以上。

OCR场景里，我最想强调的还是图像预处理。工业场景中的设备铭牌往往有反光、遮挡、斜拍的问题，直接送进PaddleOCR的效果惨不忍睹。正确做法是先用传统图像处理手段做矫正：灰度化、对比度拉伸、透视变换、背景抑制。这些操作在OpenCV里都有现成函数，消耗CPU资源也不多。记住一个原则：OCR模型的精度上限，在你按下快门的瞬间就已经决定了，后处理只能救急不能救命。

5.3 大模型场景：OOM、swap拖慢与并发保护

端侧大模型部署，最怕的就是内存不够用。我踩过最痛的一个坑是：Ollama启动时检测到系统还有几GB空闲内存，于是把模型全部加载进去，结果开着摄像头检测的视觉服务突然申请内存，触发了OOM Killer，把Ollama进程杀掉了。这个问题很隐蔽，因为不是一开机就爆，而是运行一段时间才出现。解决办法是给Ollama设置显存/内存上限，并错开模型加载时间，比如视觉服务启动完成后再加载LLM模型。

另一个很常见的误区是依赖swap。有些文档建议内存不够就开swap，这在桌面上是应急良方，但在嵌入式设备上是大忌。SD卡或eMMC的读写速度比DDR慢几个数量级，swap一旦被触发，模型生成速度会掉到不可用的程度，还可能加速Flash磨损。如果你的板子显示内存剩余不多，正确的做法是换更小的模型，而不是开swap。

大模型服务还必须有并发保护。Ollama虽然支持多请求排队，但多个用户同时请求时，每个请求都会复制一份上下文，内存成倍上涨。我在做设备端服务时，通常只在Ollama前面加一层极简的请求队列，同一时间只处理一个生成任务，剩下全部排队。这样虽然牺牲了一定的并发能力，但换来了稳定的延迟和可控的内存，对产品交付来说才是最实际的。

6. 性能调优三板斧：算力、带宽、异构调度

模型能跑和跑得好，中间隔着一整套调优方法论。我在RK3588各类板卡上做过的调优，归纳起来就是三件事：把DDR频率调到合理位置、把各处理器之间的任务分配理顺、把功耗控制在自己可控的范围内。这三件事看起来平淡无奇，但每一步实操细节都会影响最终效果。

6.1 DDR频率与内存通道配置的影响

内存带宽在RK3588平台上的重要性，前面已经反复强调过。实际调优时，第一件事就是确认板卡上DDR跑在什么频率。很多量产板为了稳定，默认把内存频率设得比较保守，这会直接限制NPU读取权重和特征图的速度。我见过同一块核心板，把LPDDR4x从2133MHz调到4266MHz后，YOLOv8s的推理帧率居然提升了接近30%，这个提升纯粹来自带宽释放。

当然，调DDR频率不是越高越好。频率拉上去后，内存控制器和颗粒的发热会显著增加，如果散热条件不好，跑高温压力测试时会触发降频，性能反而比稳定频率更差。我的建议是：先默认频率跑完整测试，再逐步升频，每一步都跑持续负载测试，找到“性能提升明显但温升可控”的临界点。很多板厂在设计阶段已经调好了最优频率，如果没把握，直接联系FAE拿推荐配置最省事。

6.2 NPU与CPU协同：流水线式任务分发

嵌入式AI系统的性能天花板，往往不是某个处理器算力不够，而是各处理器之间配合不好。NPU做推理时，CPU经常会空闲等待；CPU做后处理时，NPU又只能干瞪眼。解决这个问题的关键是把任务流水线化，让两者尽量同时忙碌。

我常用的做法是双缓冲加异步回调：视频帧采集线程把帧放入缓冲A，NPU推理线程从缓冲A取帧并推理，推理完成后把结果放入缓冲B，后处理线程从缓冲B取结果并做NMS、绘制。当NPU在处理第N帧时，CPU同时在后处理第N-1帧，采集线程在准备第N+1帧。三路并行，整体吞吐量至少提升40%。如果把RK1820也纳入调度，思路是一样的：重计算任务放给协处理器，主控CPU保持轻载，专门做控制和业务逻辑。

6.3 功耗约束下的实测调优经验

最后说说功耗。RK3588跑满全核的功耗其实不低，再加上RK1820协处理器工作时的功耗，整个系统的供电和散热设计必须提前规划。我在机器人项目里测试过，双芯片同时高负载运行时，整机功耗轻松突破20W，这对电池供电的设备来说几乎是灾难。

如果你的产品对功耗有严格约束，可以从三个方向调优。第一，动态调频，只在检测到目标或收到指令时才把NPU频率和协处理器拉满，空闲时回到低功耗模式；第二，模型分级，白天用高精度模型，夜间或低功耗模式自动切换到更轻量的模型，牺牲一点精度换续航；第三，频率上限设置，在系统层面限制NPU最高频率，降低峰值功耗和发热。这些策略看起来朴素，但产线上一旦遇到散热模具不合理的问题，往往就是靠这些软手段救回来的。

就我个人而言，调了这么多板子和模型之后最大的体会是：RK3588和RK1820这套组合，价值不在于“算力翻倍”这种简单叙事，而在于它逼着你去思考任务分层——该让NPU干的、该让CPU干的、该交给协处理器的，分得越清楚，系统越稳定。如果你正在做类似的方案选型或部署优化，建议先把模型跑进内存，把每一帧的延迟和每一瓦的功耗都量化出来，再做决策。另外有个小建议：无论你选哪家板卡方案，SDK和runtime的版本在你项目启动前就要锁定，最好连代码带工具链一起做版本管理，不然协处理器接口一旦更新，你整个上层应用都得跟着返工。