去年在客户现场被问到RK3588RK1820这种组合到底能不能跑嵌入式AI大模型我当时的答复是能但模型选型和部署方式不对照样白搭。真正把这两颗芯片放在一块儿调过一轮以后我才敢说“端侧AI到底能做什么、不能做什么”这件事值得好好写一份实战指南。这篇文章会把9个常见场景的模型选型思路、RKNN部署链路、端侧大模型和量化模型的落地经验全部摊开讲适合正在做RK3588方案选型、嵌入式AI开发或者想把大模型塞进边缘盒子里的工程师参考。1. 为什么需要RK3588RK1820这套组合先聊一个经常被低估的问题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主控连接形成“主控SoCAI加速单元”的双芯片架构。它的核心价值不是简单叠加算力而是把大模型推理、多模态特征提取这些重计算任务从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指标拉满结果模型到了端侧要么跑不动要么帧率惨不忍睹。我在实际项目里的做法刚好相反先定设备资源上限再倒推模型选型。RK3588RK1820这套组合虽然比单RK3588宽裕不少但也没宽裕到可以挥霍的程度所以做减法才是关键。2.1 一张表看清9个模型方向下面这张表是我在多个项目里沉淀下来的推荐矩阵按“场景→推荐模型→量化格式→参考性能→适用设备”排列覆盖了目前RK3588方案上最常见的9类AI应用。性能数据来自不同板卡和不同SDK版本的实测或方案商反馈具体以你的硬件环境为准但选型方向可以放心参考。场景推荐模型量化格式参考性能适用产品实时目标检测YOLOv8n / YOLOv8s / YOLO11nint850-80fps 640×640安防摄像头、工业巡检、机器人人脸检测与识别RetinaFace-Mobile MobileFaceNetint880fps以上检测识别延迟50ms门禁机、考勤终端、支付设备2D姿态估计MoveNet / Lite-HRNetint840-70fps 256×256健身镜、体感交互、康复设备语义分割PIDNet-S / DeepLabV3-Liteint820-35fps 512×512自动驾驶小车、园林机器人、影像分析语音识别SenseVoice-Small / Whisper-tinyint8实时率5会议记录、语音指令、本地字幕端侧大语言模型Qwen2.5-3B-Instruct / DeepSeek-R1-Distill-1.5Bint4 GGUF3-10 token/s语音助手、本地知识问答、离线对话OCR文字识别PaddleOCR-mobile / RapidOCRint8200-400ms/页票据识别、车牌识别、设备铭牌采集工业异常检测STFPM / PatchCore轻量化int820-50ms/图表面缺陷检测、PCB质检多模态图文检索MobileCLIP-S / 轻量VQA模型int8/int41-3s/次图像检索、视觉问答、智能相册这张表最重要的信息不是哪个模型第一名而是“每个位置都留了余量”。比如目标检测选了YOLOv8n而不是YOLOv8s理由是RK3588的NPU跑s版本时CPU后处理压力已经上来如果想同时跑多个模型n版本才有余量。2.2 实时视觉类怎么选YOLO、姿态与分割实时检测这个赛道现在几乎就是YOLO系列的天下但YOLO版本选哪个很有讲究。YOLOv5s至今仍有大量工业项目在用主要是生态成熟、RKNN转换踩坑少YOLOv8n/s和YOLO11n在精度和推理速度上更均衡。从部署角度我更推荐先在YOLOv8n上做精度验证如果指标不够再升级到s版本而不是反过来。因为端侧项目的精度瓶颈往往不在模型容量而在数据质量和量化校准这个后面展开说。姿态估计我首推MoveNet尤其是Thunder版本。它的输出是17个关键点结构简单模型只有几十MBRK3588跑起来非常轻松。健身镜这类产品需要实时性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_platformrk3588 ) # 加载ONNX模型注意输入尺寸 rknn.load_onnx( modelyolov8n.onnx, input_size_list[[1, 3, 640, 640]] ) # 构建RKNN模型这里决定是否量化 rknn.build(do_quantizationTrue, datasetdataset.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 CRKNN模型导出后在板端推理有两种主流方式Python APIRKNN-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_maskRKNNLite.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与量化模型的组合拳端侧大模型是RK3588RK1820这套组合最让人兴奋的应用方向。网上天天有人在问“xxx模型能不能本地部署”也确实越来越多模型被验证可以在嵌入式设备上跑起来但“能跑”和“能商用”之间隔着一整条工程化的鸿沟。这一章把从模型参数选型到部署工具链的完整路线理清楚。4.1 参数级别与内存带宽的关系端侧部署大模型第一件事就是计算“内存账”。模型选多大参数直接决定它能进哪一档设备模型参数规模int4量化后权重大小最低内存要求适合场景0.5B-1.5B0.4-1GB4-8GB简单对话、命名实体提取、意图分类3B-4B2-3GB8-16GB语音助手、客服问答、知识库生成7B-8B4-5GB16-32GB长文本摘要、复杂推理、多轮对话这里为什么强调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 \ --restartalways \ -v /mnt/ollama:/root/.ollama \ -p 11434:11434 \ ollama/ollama # 拉取并运行3B级模型 ollama run qwen2.5:3bOllama会默认按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又只能干瞪眼。解决这个问题的关键是把任务流水线化让两者尽量同时忙碌。我常用的做法是双缓冲加异步回调视频帧采集线程把帧放入缓冲ANPU推理线程从缓冲A取帧并推理推理完成后把结果放入缓冲B后处理线程从缓冲B取结果并做NMS、绘制。当NPU在处理第N帧时CPU同时在后处理第N-1帧采集线程在准备第N1帧。三路并行整体吞吐量至少提升40%。如果把RK1820也纳入调度思路是一样的重计算任务放给协处理器主控CPU保持轻载专门做控制和业务逻辑。6.3 功耗约束下的实测调优经验最后说说功耗。RK3588跑满全核的功耗其实不低再加上RK1820协处理器工作时的功耗整个系统的供电和散热设计必须提前规划。我在机器人项目里测试过双芯片同时高负载运行时整机功耗轻松突破20W这对电池供电的设备来说几乎是灾难。如果你的产品对功耗有严格约束可以从三个方向调优。第一动态调频只在检测到目标或收到指令时才把NPU频率和协处理器拉满空闲时回到低功耗模式第二模型分级白天用高精度模型夜间或低功耗模式自动切换到更轻量的模型牺牲一点精度换续航第三频率上限设置在系统层面限制NPU最高频率降低峰值功耗和发热。这些策略看起来朴素但产线上一旦遇到散热模具不合理的问题往往就是靠这些软手段救回来的。就我个人而言调了这么多板子和模型之后最大的体会是RK3588和RK1820这套组合价值不在于“算力翻倍”这种简单叙事而在于它逼着你去思考任务分层——该让NPU干的、该让CPU干的、该交给协处理器的分得越清楚系统越稳定。如果你正在做类似的方案选型或部署优化建议先把模型跑进内存把每一帧的延迟和每一瓦的功耗都量化出来再做决策。另外有个小建议无论你选哪家板卡方案SDK和runtime的版本在你项目启动前就要锁定最好连代码带工具链一起做版本管理不然协处理器接口一旦更新你整个上层应用都得跟着返工。 
长河君 · 2026/9/24 11:36:28 · 阅读 1.2k RK3588+RK1820嵌入式AI大模型实战：模型选型与RKNN部署指南
去年在客户现场被问到RK3588RK1820这种组合到底能不能跑嵌入式AI大模型我当时的答复是能但模型选型和部署方式不对照样白搭。真正把这两颗芯片放在一块儿调过一轮以后我才敢说“端侧AI到底能做什么、不能做什么”这件事值得好好写一份实战指南。这篇文章会把9个常见场景的模型选型思路、RKNN部署链路、端侧大模型和量化模型的落地经验全部摊开讲适合正在做RK3588方案选型、嵌入式AI开发或者想把大模型塞进边缘盒子里的工程师参考。1. 为什么需要RK3588RK1820这套组合先聊一个经常被低估的问题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主控连接形成“主控SoCAI加速单元”的双芯片架构。它的核心价值不是简单叠加算力而是把大模型推理、多模态特征提取这些重计算任务从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指标拉满结果模型到了端侧要么跑不动要么帧率惨不忍睹。我在实际项目里的做法刚好相反先定设备资源上限再倒推模型选型。RK3588RK1820这套组合虽然比单RK3588宽裕不少但也没宽裕到可以挥霍的程度所以做减法才是关键。2.1 一张表看清9个模型方向下面这张表是我在多个项目里沉淀下来的推荐矩阵按“场景→推荐模型→量化格式→参考性能→适用设备”排列覆盖了目前RK3588方案上最常见的9类AI应用。性能数据来自不同板卡和不同SDK版本的实测或方案商反馈具体以你的硬件环境为准但选型方向可以放心参考。场景推荐模型量化格式参考性能适用产品实时目标检测YOLOv8n / YOLOv8s / YOLO11nint850-80fps 640×640安防摄像头、工业巡检、机器人人脸检测与识别RetinaFace-Mobile MobileFaceNetint880fps以上检测识别延迟50ms门禁机、考勤终端、支付设备2D姿态估计MoveNet / Lite-HRNetint840-70fps 256×256健身镜、体感交互、康复设备语义分割PIDNet-S / DeepLabV3-Liteint820-35fps 512×512自动驾驶小车、园林机器人、影像分析语音识别SenseVoice-Small / Whisper-tinyint8实时率5会议记录、语音指令、本地字幕端侧大语言模型Qwen2.5-3B-Instruct / DeepSeek-R1-Distill-1.5Bint4 GGUF3-10 token/s语音助手、本地知识问答、离线对话OCR文字识别PaddleOCR-mobile / RapidOCRint8200-400ms/页票据识别、车牌识别、设备铭牌采集工业异常检测STFPM / PatchCore轻量化int820-50ms/图表面缺陷检测、PCB质检多模态图文检索MobileCLIP-S / 轻量VQA模型int8/int41-3s/次图像检索、视觉问答、智能相册这张表最重要的信息不是哪个模型第一名而是“每个位置都留了余量”。比如目标检测选了YOLOv8n而不是YOLOv8s理由是RK3588的NPU跑s版本时CPU后处理压力已经上来如果想同时跑多个模型n版本才有余量。2.2 实时视觉类怎么选YOLO、姿态与分割实时检测这个赛道现在几乎就是YOLO系列的天下但YOLO版本选哪个很有讲究。YOLOv5s至今仍有大量工业项目在用主要是生态成熟、RKNN转换踩坑少YOLOv8n/s和YOLO11n在精度和推理速度上更均衡。从部署角度我更推荐先在YOLOv8n上做精度验证如果指标不够再升级到s版本而不是反过来。因为端侧项目的精度瓶颈往往不在模型容量而在数据质量和量化校准这个后面展开说。姿态估计我首推MoveNet尤其是Thunder版本。它的输出是17个关键点结构简单模型只有几十MBRK3588跑起来非常轻松。健身镜这类产品需要实时性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_platformrk3588 ) # 加载ONNX模型注意输入尺寸 rknn.load_onnx( modelyolov8n.onnx, input_size_list[[1, 3, 640, 640]] ) # 构建RKNN模型这里决定是否量化 rknn.build(do_quantizationTrue, datasetdataset.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 CRKNN模型导出后在板端推理有两种主流方式Python APIRKNN-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_maskRKNNLite.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与量化模型的组合拳端侧大模型是RK3588RK1820这套组合最让人兴奋的应用方向。网上天天有人在问“xxx模型能不能本地部署”也确实越来越多模型被验证可以在嵌入式设备上跑起来但“能跑”和“能商用”之间隔着一整条工程化的鸿沟。这一章把从模型参数选型到部署工具链的完整路线理清楚。4.1 参数级别与内存带宽的关系端侧部署大模型第一件事就是计算“内存账”。模型选多大参数直接决定它能进哪一档设备模型参数规模int4量化后权重大小最低内存要求适合场景0.5B-1.5B0.4-1GB4-8GB简单对话、命名实体提取、意图分类3B-4B2-3GB8-16GB语音助手、客服问答、知识库生成7B-8B4-5GB16-32GB长文本摘要、复杂推理、多轮对话这里为什么强调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 \ --restartalways \ -v /mnt/ollama:/root/.ollama \ -p 11434:11434 \ ollama/ollama # 拉取并运行3B级模型 ollama run qwen2.5:3bOllama会默认按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又只能干瞪眼。解决这个问题的关键是把任务流水线化让两者尽量同时忙碌。我常用的做法是双缓冲加异步回调视频帧采集线程把帧放入缓冲ANPU推理线程从缓冲A取帧并推理推理完成后把结果放入缓冲B后处理线程从缓冲B取结果并做NMS、绘制。当NPU在处理第N帧时CPU同时在后处理第N-1帧采集线程在准备第N1帧。三路并行整体吞吐量至少提升40%。如果把RK1820也纳入调度思路是一样的重计算任务放给协处理器主控CPU保持轻载专门做控制和业务逻辑。6.3 功耗约束下的实测调优经验最后说说功耗。RK3588跑满全核的功耗其实不低再加上RK1820协处理器工作时的功耗整个系统的供电和散热设计必须提前规划。我在机器人项目里测试过双芯片同时高负载运行时整机功耗轻松突破20W这对电池供电的设备来说几乎是灾难。如果你的产品对功耗有严格约束可以从三个方向调优。第一动态调频只在检测到目标或收到指令时才把NPU频率和协处理器拉满空闲时回到低功耗模式第二模型分级白天用高精度模型夜间或低功耗模式自动切换到更轻量的模型牺牲一点精度换续航第三频率上限设置在系统层面限制NPU最高频率降低峰值功耗和发热。这些策略看起来朴素但产线上一旦遇到散热模具不合理的问题往往就是靠这些软手段救回来的。就我个人而言调了这么多板子和模型之后最大的体会是RK3588和RK1820这套组合价值不在于“算力翻倍”这种简单叙事而在于它逼着你去思考任务分层——该让NPU干的、该让CPU干的、该交给协处理器的分得越清楚系统越稳定。如果你正在做类似的方案选型或部署优化建议先把模型跑进内存把每一帧的延迟和每一瓦的功耗都量化出来再做决策。另外有个小建议无论你选哪家板卡方案SDK和runtime的版本在你项目启动前就要锁定最好连代码带工具链一起做版本管理不然协处理器接口一旦更新你整个上层应用都得跟着返工。