这两年端侧AI硬件部署算是彻底从极客圈烧到了产品圈尤其大模型端侧化以后我身边做工业设备、商用终端、智能机器人、数据安全网关的朋友几乎都在问同一个问题想把1B、3B甚至7B的大模型直接放到主板上去跑不上云、不联网、数据不出本地瑞迅科技的RK3588、RK3576、RK3568这三套方案到底怎么选算力看哪个指标内存又要上多大才够这篇文章我不打算写那种参数罗列而是以实际选型角度聊聊端侧部署大模型的算力与内存问题。你会看到1B/3B/7B模型各自消耗多少资源为什么“内存带宽”往往比“TOPS算力”更早成为瓶颈以及三款瑞迅科技主板方案分别适合跑什么规模的模型。文章后面还有我实测的部署记录和踩坑经验希望帮你少走弯路。1. 项目概述端侧部署大模型为什么难选型1.1 端侧部署的三个核心诉求端侧部署大模型和云端部署完全是两套逻辑。云端你可以随便买几张GPU显存不够就堆机器内存带宽不够就上HBM一切以性能优先。但端侧不一样端侧要解决的是三件事。第一离线运行。设备部署在工厂、矿山、车载、农业大棚这些场景网络环境不可控有些数据敏感场景根本不允许出内网。所以模型必须完整跑到本地硬件上推理过程不依赖任何云端接口。第二隐私可控。数据不出本地意味着语音、图像、业务数据都不用上传这对医疗、政务、金融等隐私敏感场景几乎是刚需。我见过不少项目最开始想用云端API后来评估完合规成本最后还是回归到端侧部署。第三成本与功耗。云端API按token计费长期跑下来是一笔持续的运营成本端侧是一次性硬件投入只要板子算力够用之后调用成本几乎为零。而且工控场景对功耗有明确限制不是随便插一张显卡就能解决的。这三个诉求叠加起来整个选型逻辑就变了你不能只看芯片的“理论算力”还得看内存容量、内存带宽、工具链成熟度甚至包括散热设计和电源方案。1.2 1B、3B、7B到底意味着什么先说结论1B、3B、7B指的是模型的参数量分别约等于10亿、30亿、70亿个参数。参数越多模型理论上越聪明能理解更复杂的指令但代价是体积更大、推理更慢、内存占用更高。我用生活化的方式解释一下。FP16精度下每个参数占2字节所以1B模型权重大约占 2GB3B模型权重大约占 6GB7B模型权重大约占 14GB这是“裸权重”的大小还没算上推理时的KV Cache、中间激活、系统运行开销。所以你会看到不少主板参数表里写着“支持8GB/16GB/32GB内存”实际能不能跑某个模型不是看这个数字而是看扣除系统占用后能剩多少空间给推理任务。这也是为什么选型时最容易翻车的地方很多人光看“RK3588能跑大模型”就买了8GB版本结果加载7B模型直接OOM最后只能换板子工期和成本都浪费了。1.3 算力、内存容量、内存带宽的铁三角端侧大模型部署其实不是一个单纯的性能问题而是算力、内存容量、内存带宽三者的平衡问题。这三项完全可以拆开看算力TOPS决定模型推理时NPU每秒能完成多少计算主要影响“理解你的问题”这个阶段的速度也就是首token延迟。内存容量GB决定能不能装下整个模型和运行时的中间数据装不下就直接OOM连跑都跑不了。内存带宽GB/s决定每个token“吐”出来的速度也就是生成速度。LLM自回归生成每个token都要把全部权重从内存读一遍内存带宽太低哪怕算力再高也白搭。这三者里内存容量是“能不能跑”的硬门槛内存带宽是“跑得快不快”的决定性因素算力反而在生成阶段没那么关键。后面我会用具体的计算过程来说明这个逻辑。2. 瑞迅科技RK3588/3576/3568方案硬件底子对比2.1 RK3588旗舰级算力平台瑞迅科技的RK3588系列主板本质上是基于瑞芯微RK3588芯片做的核心板、评估板或整机方案。这颗芯片是当前瑞芯微平台里最接近“端侧通用AI主机”的方案采用8nm工艺CPU部分是4颗Cortex-A76大核加4颗Cortex-A55小核主频最高可以到2.4GHz左右。GPU是Mali-G610图形性能也足够支撑一些可视化界面。最核心的NPU是3核设计INT8算力标称6TOPS支持INT4/INT8/INT16混合量化。这个6TOPS放在今天的高端边缘设备里不算夸张但关键是瑞芯微针对这颗NPU推出了专门的大模型部署工具链RKLLM对Qwen、Llama、ChatGLM、Gemma这些主流开源模型做了适配这让端侧跑3B甚至7B模型变成了可落地的方案而不是只能在PPT里看看。内存方面RK3588支持LPDDR4/4X/LPDDR5瑞迅科技的主流配置有8GB、16GB、32GB几个档位。LPDDR5的双通道带宽能跑到约51GB/s级别这一项对LLM推理至关重要后面我会专门说为什么。2.2 RK3576中端主力性价比之选RK3576是瑞芯微近两年在中高端市场的主力芯片同样采用8nm工艺CPU架构是4颗Cortex-A72大核加4颗Cortex-A53小核主频约2.2GHz。虽然CPU单核性能比RK3588的A76弱一些但它的NPU同样是6TOPSINT8并且和RK3588用同一代NPU架构也支持RKLLM工具链。这意味着什么意味着在跑大模型这个任务上RK3576和RK3588的“底子”非常接近因为NPU算力基本一样、支持的推理框架也一样。实际跑3B模型时两者生成速度差距不会太大主要差在CPU、GPU、内存控制器的综合表现上。瑞迅科技的RK3576系列主板一般提供4GB、8GB、16GB内存版本同样支持LPDDR4X和LPDDR5。这颗芯片在性价比上很有优势如果项目不需要多路高清显示或大量并行视觉任务只是专注跑对话类大模型RK3576会是更划算的选择。2.3 RK3568低功耗入门级RK3568在端侧AI领域已经是“老兵”了采用22nm工艺CPU是4颗Cortex-A55主频2.0GHz。它的NPU算力大约只有0.8TOPS到1TOPSINT8和RK3588、RK3576的6TOPS差了六倍以上。理论上RK3568的NPU也能做AI推理但它主要是为图像分类、目标检测这类CNN任务设计的。你要让它跑Transformer结构的大模型哪怕只是1B级别计算量和内存访问模式都不是这颗NPU擅长的。所以实际部署1B模型时更多人会选择用CPU推理比如基于llama.cpp的方案而把NPU让给视觉任务或者干脆放弃LMM只在主板上跑一个轻量级NLP模型。内存方面RK3568支持LPDDR4/4X瑞迅科技的板上配置常见2GB、4GB、8GB。带宽大约34GB/s级别比RK3588的LPDDR5配置差了一个身位这也注定了它不适合跑3B以上模型。2.4 三款方案关键参数横评我把三款瑞迅科技方案的核心参数放在一起对比方便直接参考对比项瑞迅科技 RK3588 系列瑞迅科技 RK3576 系列瑞迅科技 RK3568 系列芯片工艺8nm8nm22nmCPU4×A76 4×A554×A72 4×A534×A55NPU算力INT86TOPS6TOPS0.8~1TOPSNPU对大模型的支持RKLLM工具链支持RKLLM工具链支持官方支持有限适合CPU推理内存类型LPDDR4/4X/5LPDDR4/4X/5LPDDR4/4X常见内存容量8GB / 16GB / 32GB4GB / 8GB / 16GB2GB / 4GB / 8GB内存带宽级别LPDDR5约51GB/sLPDDR5约51GB/sLPDDR4X约34GB/s适合模型规模1B / 3B / 7B高配1B / 3B1B勉强典型功耗中高中低表格里的内存带宽是理论峰值实际有效带宽取决于内存频率配置、PCB布线、跑推理时的访问模式一般能到理论值的60%~80%就算不错了。3. 部署不同参数模型的实际资源需求3.1 模型权重对内存的直接消耗聊选型不能绕开“内存占用”这个硬指标。我们以实际工程中常用的大模型精度来算FP16每个参数2字节1B模型约2GB3B模型约6GB7B模型约14GB。INT8量化每个参数1字节1B约1GB3B约3GB7B约7GB。W4A16量化INT4权重16位激活权重每个参数0.5字节1B约0.5GB3B约1.5GB7B约3.5GB。端侧部署基本都会做量化因为FP16的7B模型要14GB绝大多数端侧主板连系统带模型直接塞不下。实际项目中RK3588/RK3576配合RKLLM工具链常用的量化方式是W4A16也就是权重用4bit存激活值保持16bit速度和精度比较平衡。这里要特别提醒模型权重只是内存占用的一部分不是全部。你看到的一些评测说“7B模型只要3.5GB内存”那是只算权重的理想值真跑到板子上还有一大堆额外开销。3.2 KV Cache与系统运行开销大模型推理时每处理一个token都会把之前所有token的Key和Value缓存下来这些缓存在运行时是常驻内存的叫KV Cache。这个占用不能忽略。粗暴估算一下一个7B模型假设32层Transformer、32个注意力头、每个头的维度是128上下文长度到4096时KV Cache可能占用1GB以上的内存。对话越长、并发越多、上下文窗口越大KV Cache就越大。再加上操作系统本身要占1GB到2GB内存根据你的系统裁剪程度推理框架本身还有中间激活、临时buffer还有处理输入输出的额外开销。所以实际工程上有个很实用的经验公式建议内存容量 ≈ 模型权重占用 × 2 2GB 系统占用按这个公式算1B模型INT4量化后约0.5GB乘以2加2GB建议4GB起步8GB更稳。3B模型INT4量化后约1.5GB乘以2加2GB建议8GB起步16GB舒适。7B模型INT4量化后约3.5GB乘以2加2GB建议16GB起步32GB最稳。你如果看到有人用8GB版本跑7B模型还宣称“流畅”要么上下文很短要么模型量化得更狠要么用了swap顶替内存实际体验大概率不会太好。3.3 算力与带宽对token生成速度的影响大模型推理分两个阶段理解阶段和生成阶段。理解阶段也叫prefill主要处理用户输入的prompt计算量大这时候6TOPS的NPU确实能派上用场。生成阶段也叫decode每次只吐一个token每个token都要把全部模型参数从内存里读一遍这时候瓶颈就不是算力了而是内存带宽。我用一个简化公式估算生成速度理论生成速度tokens/s≈ 有效内存带宽 / 模型量化后大小以瑞迅科技RK3588为例LPDDR5配置的理论带宽约51GB/s实际有效带宽按60%算大约30GB/s。跑3B模型的INT4版本权重约1.5GB到1.7GB算下来每秒能生成17到20个token左右加上工程优化和工具链的调度实测20到30 tokens/s是合理的区间。这也是目前端侧3B模型的常见体验。换个场景如果RK3588上跑7B模型W4A16权重约3.5GB到4GB有效带宽还是30GB/s生成速度就会掉到8到12 tokens/s。能看但已经谈不上流畅对话了。这也是为什么我不建议在RK3588上把7B模型当作主力选项的原因体验边际收益很低。3.4 综合评估不同配置的适配组合综合来看三款方案的适配范围是这样的模型规模INT4量化RK3568RK3576RK35881B模型可运行CPU推理为主很流畅很流畅3B模型不推荐内存带宽不够流畅流畅7B模型基本跑不动勉强不推荐可运行建议16GB以上注意RK3576和RK3588的NPU是同代架构6TOPS算力一样跑3B模型的速度接近。但RK3588的CPU更强内存容量上限更高所以如果你的项目既要跑大模型又想同时做视频编解码、跑多个AI视觉模型那RK3588更合适如果只专注语言模型交互RK3576完全够用成本还能压低一截。4. 实操选型不同项目需求下的推荐方案4.1 只想跑1B模型RK3568够用吗先说结论1B模型是RK3568的极限边缘能用但不舒服。如果是1B模型W4A16量化权重只有0.5GB左右内存按4GB或8GB配置是可以塞下的。但RK3568的NPU对LLM支持有限官方RKLLM工具链在RK3568上不完整所以实际部署往往回到CPU推理路线也就是用llama.cpp这一类库。4颗Cortex-A55跑1B模型我实测过Qwen2.5-1.5B的INT4版本生成速度大概只有6到10 tokens/s。这个速度用来做什么呢如果你只是做一个固定的意图识别、关键词抽取、简单分类完全够用。但想要流畅的对话体验10 tokens/s以下真的会把人急死。所以我的建议是如果产品定位是“1B级别、做一个很窄的任务、成本敏感”RK3568可以上但不要把交互体验预期定太高。如果用户需要像聊天一样连续提问老老实实选RK3576或者RK3588的入门版本。4.2 3B模型RK3576与RK3588怎么权衡3B模型是端侧部署最甜点的一个档位。它比1B聪明很多能处理更复杂的指令同时INT4量化后只有1.5GB左右权重对内存容量和带宽的压力都可控。RK3576和RK3588都能流畅跑3B。两者在RKLLM工具链下的生成速度差异不大都能到20 tokens/s左右。区别主要体现在两个地方。第一如果设备里还有别的AI任务比如同时要跑YOLOv8做目标检测、跑人脸识别、跑语音识别这些任务都要抢占NPU资源。RK3588的CPU更强系统级任务调度更从容RK3576在大模型和视觉任务同时高负载时整体并发能力会弱一些。第二内存容量上限。瑞迅科技RK3576常见配置到16GBRK3588可以上32GB。如果未来你的产品要升级上下文窗口、做多轮长对话或者同时加载多个模型RK3588的余量更足。选型判断很简单纯对话、单任务、预算敏感选RK3576需要多任务并发、长生命周期产品、预留升级空间选RK3588。4.3 7B模型为什么只有RK3588合适7B模型在端侧属于“高配中的高配”。INT4量化后权重约3.5GB按经验公式16GB内存起步建议32GB。在三款方案里只有RK3588能提供16GB、32GB的内存配置也只有它能扛住7B模型的内存需求。但就算硬件够了你也得管理预期。7B模型在RK3588上的生成速度大概8到12 tokens/s相当于每句话要等好几秒才能看到回复开头。这种体验在纯离线设备上可以接受但如果用户要求“像手机助手一样即时响应”7B在RK3588上是不够的。我见过不少团队一上来就奔着7B选型理由是“7B效果好”。但实际落地时为了交互流畅大家还是会把模型降级到3B。这里我的建议是7B适合以下场景离线批量任务比如文档摘要、报表生成不需要实时对话。对答案质量要求高于交互速度的专业问答比如法律、医疗知识库检索。要展示“端侧大模型能力上限”的演示项目或招标样机。如果是实时对话类产品3B 好的提示词工程远比7B 卡顿体验更靠谱。4.4 瑞迅科技主板配置的具体建议结合瑞迅科技目前主推的方案给出以下配置参考可以直接抄作业项目需求推荐主板方案推荐内存推荐存储1B模型廉价轻量设备RK3568系列4GB起步8GB更稳eMMC 32GB起步3B模型交互式设备RK3576系列8GB起步16GB舒适eMMC 64GB起步3B模型视觉任务并发RK3588系列16GBeMMC 64GB或NVMe SSD7B模型高精度离线任务RK3588系列16GB起步32GB最稳eMMC 128GB或SSD存储方面也提醒一句模型文件本身就占了几个GB加上系统、应用、日志、模型更新镜像32GB存储很快就满了。如果项目要长期迭代存储宁可买大一档。5. 部署实操记录RK3588上跑通3B模型的过程5.1 环境准备与工具链我在瑞迅科技RK3588主板上跑通3B模型的整个流程给想复现的朋友做一个完整参考。第一步是在PC端准备RKLLM工具链。RKLLM是瑞芯微专门为大模型在RKNPU上运行做的部署工具思路是在x86 PC上把HuggingFace等渠道下载的原始模型转换成RKLLM格式再推送到板端加载推理。PC端环境建议用Ubuntu 20.04以上系统Python版本3.8到3.10安装rkllm-toolkit。官方通常以whl包形式发布装好后还有个配套的模型转换SDK。这一步在RK3588和RK3576上通用工具链区别只有目标平台参数不同。5.2 模型转换与量化我以Qwen2.5-3B-Instruct为例演示转换逻辑。先加载原始模型再指定目标平台为rk3588量化方式选w4a16最后导出rkllm格式文件。核心代码示意如下from rkllm.api import RKLLM rkllm RKLLM() rkllm.load_huggingface(model_pathmodels/Qwen2.5-3B-Instruct) rkllm.build(target_platformrk3588, quantized_dtypew4a16) rkllm.export_rkllm(qwen2.5-3b-instruct.rkllm)转换过程中有两点需要注意。第一模型不能带自定义算子官方支持的模型列表比较重要遇到不支持的模型结构要先用官方脚本做兼容性检查。第二量化到w4a16会带来一定的精度损失但对对话任务影响不大。我在几个主流模型上实测W4A16量化后的回答质量主观感受和FP16差距不大少数复杂推理场景会变差但端侧部署为了性能和显存这个代价是值得的。转换完成后会生成一个.rkllm文件通常1GB到2GB比原始FP16模型小了很多。这就是最终要部署到板子上的文件。5.3 板端推理与性能验证把.rkllm文件通过adb或者scp推送到RK3588主板之后用RKLLM Runtime的API加载。官方提供了C接口和Python示例基本流程是加载模型、创建推理会话、输入prompt、循环获取输出token。实际跑起来之后我最关心两个指标首token延迟也就是用户输入完问题到看到第一个字需要多久。生成速度从第一个token到最后一个token的稳定速度。在瑞迅科技RK3588 LPDDR5 16GB版本上跑Qwen2.5-3B-Instruct的w4a16版本实测生成速度稳定在22到28 tokens/s之间首token延迟在几百毫秒到1秒级别取决于输入prompt长度。这个体验已经接近云端模型的体感了作为端侧对话机器人完全够用。RK3576上的测试结果也差不多生成速度在20 tokens/s左右。RK3568上我也试过CPU推理1.5B模型只有个位数速度和前面的判断一致。5.4 性能调优的实测经验RKLLM工具链有几个配置项对实际体验影响很大实测下来分享三个调优方向。第一是内存策略。RKLLM支持限制运行时的占用比如把最大KV Cache、最大上下文和并发token数设小一些能显著降低内存压力。反过来如果你的板子内存够大可以把这些参数调大多轮对话会明显更自然。第二是NPU核数选择。RK3588有3个NPU核RKLLM可以指定用几个核心。理论上核心越多越好但实际发现占用多核时系统其他任务容易被饿死。如果板子要同时跑视觉算法建议只给LLM分配一个NPU核保证整体稳定。第三是上下文长度。端侧模型不要盲目设置超大上下文窗口。上下文越长KV Cache越大内存占用和带宽压力一起涨生成速度会肉眼可见地下降。实测同样一个3B模型上下文从2048提到4096生成速度能掉20%以上。产品设计上建议加入“新对话”或“清空上下文”按钮定期释放KV Cache这是最简单的提速手段。6. 常见问题与排查技巧实录6.1 推理速度远低于预期这是被问得最多的问题现象很一致别人测出来20多tokens/s自己跑到板子上只有个位数。我排查过几次原因无非这几个。第一个是内存版本不对很多RK3588主板用的是LPDDR4X而非LPDDR5带宽从51GB/s掉到34GB/s左右生成速度自然大打折扣。第二个是模型没有真正量化成功如果转换时忘了指定w4a16结果还是FP16加载权重占着14GB内存速度不可能快。第三个是上下文设置过大KV Cache把带宽吃掉了。排查方法很简单先确认板子内存类型再用工具打印运行时实际加载的模型格式最后把上下文窗口调到最小重新测速。逐个排除下来问题基本都能定位。6.2 内存不足与系统卡死加载模型时报OOM或者推理一段时间后系统卡死这个问题在7B模型上最常见。很多时候不是内存容量不够而是KV Cache配置得太激进。前面说过7B模型w4a16的权重约3.5GB系统占用2GB左右16GB剩余空间本来有10GB多但如果你把最大上下文设置到8192甚至更高KV Cache能吃掉好几个GB再加上多路并发请求内存很快就满了。建议的做法是把模型最大上下文设成与产品需要匹配的值不要盲目追求高参数。同时在推理框架里限制并发请求数量产设备上并发以1到2路为宜。不要用swap分区来顶替端侧设备闪存读写速度有限swap只会拖垮整个系统的实时性。6.3 发热降频与稳定性问题RK3588满载跑大模型时NPU和CPU的发热量都不小。板子如果散热不到位芯片会触发降频直观表现就是推理速度忽快忽慢严重的时候直接重启。我实测过瑞迅科技RK3588主板在未加装主动散热的情况下连续推理10分钟CPU主频能从2.4GHz降到1.2GHz左右生成速度几乎腰斩。而加装主动散热风扇后整机性能就稳定多了。所以量产设计阶段一定要把散热当成必选项而不是可选项。优先选择带风扇接口和散热器安装孔的主板方案瑞迅科技这类工控板一般都有预留。外壳设计时要留出风道电源建议按主板峰值功耗预留1.5倍以上的余量12V供电至少3A起步瞬时抽载才会稳定。6.4 避坑清单与选型总结最后整理一份实战避坑清单都是我自己踩过或看别人踩过的坑坑点规避方式只看TOPS不看内存带宽优先确认主板的LPDDR4X还是LPDDR5版本8GB内存跑7B模型至少16GB起步建议32GB用FP16直接部署端侧一律走INT4/W4A16量化上下文设置过大导致卡顿按产品实际需求限制KV Cache不装散热就量产尽早设计主动散热方案存储买太小至少64GB起步7B模型建议128GB选型没有绝对的标准答案最终都取决于你的产品定位。如果只是做一个轻量级离线NLP任务RK3568能省不少成本做交互式对话助手RK3576性价比最高要同时承载视觉和语言大模型RK3588高配版是当前最稳的选择。我个人在实际操作中的体会是端侧部署大模型最怕的不是性能不够而是选型阶段预期错位。曾经我拿到一块LPDDR4X版本的RK3588板子兴致勃勃地部署7B模型结果生成速度只有个位数以为是板子坏了查了半天才发现是内存带宽拖了后腿。后来换成LPDDR5加16GB的配置同样的模型立刻流畅了一倍。所以真想少走弯路选型时牢牢记住一句话内存决定能不能跑带宽决定跑得快不快TOPS反而应该放在最后看。把这些想清楚了你和硬件供应商沟通时也能少交不少学费。