1. 为什么要在RK3588上折腾大模型手里有一块RK3588的开发板8核CPU加6TOPS算力的NPU跑个YOLOv8做目标检测绰绰有余但看着桌面上那台嗡嗡作响的台式机在跑DeepSeek总想着能不能把这块板子也利用起来。RK3588这颗芯片在边缘计算圈子里热度一直不低瑞芯微的生态这两年在Linux支持上也越来越完善尤其是NPU相关的RKNN工具链更新挺勤快。但真要把DeepSeek这种量级的大模型塞进去跑起来光靠CPU推理那体验基本没法看必须得把NPU用上。这篇文章主要聊的就是在RK3588上部署DeepSeek大模型的完整思路重点对比两条技术路线一条是基于Ollama的通用方案另一条是走RKLLM工具链的NPU加速方案。前者胜在生态成熟、上手快后者才是真正发挥硬件性能的正道。我会把两种方案的选型逻辑、实操步骤、踩过的坑都摊开来讲适合手里有RK3588板子、想跑本地大模型但又被各种工具链折腾得够呛的开发者参考。不管你是刚拿到板子的新手还是已经在上面跑过YOLOv8想进一步压榨NPU性能的老手应该都能从下面的内容里找到能直接抄作业的部分。2. 方案选型Ollama还是RKLLM2.1 两条路线的本质区别先把结论摆在前面如果你只是想快速验证DeepSeek在RK3588上能不能跑通用Ollama最省事但如果你追求的是推理速度和实际可用性RKLLM是唯一的选择。这两条路线的差异不是简单的工具不同而是底层计算路径完全不一样。Ollama本质上是一个模型管理和推理调度的框架它底层依赖的是llama.cpp这类推理引擎。在RK3588上跑Ollama默认走的是CPU推理ARM Cortex-A76和A55的大小核架构跑7B级别的模型token生成速度大概在每秒1到3个token之间基本属于能跑但没法用的状态。Ollama本身并不直接支持RK3588的NPU它没有针对瑞芯微NPU的backend。RKLLM则是瑞芯微官方推出的专门针对RK3588系列芯片的大模型推理工具链。它把模型转换成RKNN格式通过NPU做矩阵运算加速同时利用CPU做调度和前后处理。实测下来7B模型在RK3588的NPU上跑token生成速度能到每秒10到15个token比纯CPU推理快了将近一个数量级。这个差距在交互式对话场景里就是能用和不能用的分界线。2.2 什么场景选什么方案选型这件事得看具体需求不能一刀切。我整理了一个简单的对照表方便你根据自己的情况做判断对比维度Ollama方案RKLLM方案部署难度低几条命令搞定中高需要交叉编译和模型转换推理速度1-3 token/s10-15 token/s模型格式GGUFRKNNNPU利用率不支持充分利用生态成熟度高社区活跃中官方文档为主适合场景功能验证、轻量测试实际产品、边缘推理内存占用较高优化后较低如果你手头只有一块板子想先跑起来看看效果Ollama是合理的起点。但如果你是要做产品原型或者需要实时交互直接上RKLLM别在Ollama上浪费太多时间。我自己的做法是先用Ollama验证模型效果和基本流程确认没问题后再切到RKLLM做性能优化。2.3 硬件和系统准备RK3588开发板的型号很多我手头用的是带8GB内存的版本。这里有个硬性要求跑7B模型至少需要8GB内存跑1.5B或3B的小模型4GB也能凑合但体验会打折扣。存储方面建议用eMMC或者高速TF卡系统盘至少留出16GB空间模型文件本身就要占好几个GB。系统层面官方推荐的Ubuntu 20.04或者22.04都行。我试过Ubuntu 20.04.5的根文件系统驱动适配比较完善。如果你用的是其他版本注意检查内核版本NPU驱动对内核有要求太新的内核可能反而会有兼容性问题。网络配置方面建议板子通过有线网口连接方便后续下载模型和传输文件。注意烧写系统后先检查磁盘空间有些默认镜像根分区只分配了几个GB跑大模型之前务必扩容否则模型还没下载完磁盘就满了。3. Ollama方案实操从安装到跑通DeepSeek3.1 在RK3588上安装OllamaOllama官方提供的安装脚本默认是x86_64架构的RK3588是aarch64直接跑官方脚本会报架构不匹配。所以得走源码编译或者找ARM64的预编译包。我试过两种方式源码编译虽然慢但最稳妥。先装依赖sudo apt update sudo apt install -y build-essential cmake git golang然后拉源码编译git clone https://github.com/ollama/ollama.git cd ollama go generate ./... go build .编译过程在RK3588上大概要十几分钟取决于你的散热条件。编译完成后会生成一个ollama可执行文件把它复制到/usr/local/bin/下面然后创建systemd服务sudo cp ollama /usr/local/bin/ sudo useradd -r -s /bin/false ollama sudo mkdir -p /usr/share/ollama/.ollama sudo chown ollama:ollama /usr/share/ollama/.ollama服务文件内容如下[Unit] DescriptionOllama Service Afternetwork-online.target [Service] ExecStart/usr/local/bin/ollama serve Userollama Groupollama Restartalways RestartSec3 EnvironmentOLLAMA_HOST0.0.0.0 [Install] WantedBymulti-user.target启用并启动服务sudo systemctl daemon-reload sudo systemctl enable ollama sudo systemctl start ollama3.2 模型下载与国内镜像配置Ollama默认从官方registry拉模型国内下载速度很不稳定经常断连。解决办法是配置镜像源。Ollama支持通过环境变量指定registry地址在服务文件里加一行EnvironmentOLLAMA_REGISTRYhttps://your-mirror.example.com不过更实际的做法是手动下载GGUF格式的模型文件然后用Modelfile导入。DeepSeek官方在HuggingFace上放出了多个版本的GGUF量化模型推荐用Q4_K_M量化级别在精度和体积之间平衡得比较好。7B的Q4_K_M大概4GB左右下载下来之后创建一个ModelfileFROM ./deepseek-7b-q4_k_m.gguf PARAMETER temperature 0.7 PARAMETER top_p 0.9 PARAMETER num_ctx 4096然后导入ollama create deepseek-local -f Modelfile导入完成后直接跑ollama run deepseek-local3.3 Ollama方案的性能实测与局限在RK3588上用Ollama跑DeepSeek 7B Q4_K_M实测数据如下首次加载模型耗时约45秒之后常驻内存。生成速度方面短回复50 token以内大概每秒2到3个token长回复会降到每秒1到2个token。内存占用在5.5GB左右加上系统本身的开销8GB内存基本吃满。这个性能用来做简单的问答验证还行但要做多轮对话或者长文本生成等待时间会让人抓狂。而且Ollama在RK3588上跑的时候CPU占用率很高四个A76大核基本跑满板子发热明显长时间运行需要加散热片或者小风扇。实操心得如果非要用Ollama方案建议把num_ctx调小到2048能省不少内存生成速度也会略有提升。另外记得在BIOS或者内核参数里把CPU governor设成performance模式默认的ondemand调度在大模型推理时会有明显的频率切换延迟。4. RKLLM方案真正发挥NPU算力4.1 RKLLM工具链的获取与安装RKLLM是瑞芯微官方的大模型推理框架代码托管在GitHub的rknn-llm仓库里。整个工具链分两部分一部分是运行在x86主机上的模型转换工具另一部分是运行在RK3588上的推理运行时库。先在x86主机上克隆仓库git clone https://github.com/airockchip/rknn-llm.git cd rknn-llm仓库里有个examples目录里面包含了模型转换的脚本和推理demo。模型转换工具在rkllm-toolkit目录下通过pip安装pip install rkllm-toolkit/rkllm_toolkit-1.1.0-cp38-cp38-linux_x86_64.whl运行时库在rkllm-runtime目录下需要交叉编译或者直接在板子上编译。我选择在板子上直接编译先把runtime目录拷贝到RK3588上scp -r rkllm-runtime userrk3588:/home/user/然后在板子上编译cd rkllm-runtime mkdir build cd build cmake .. make -j8编译完成后会生成librkllmrt.so和相关的头文件把这些装到系统路径下sudo cp librkllmrt.so /usr/lib/ sudo cp rkllm.h /usr/include/4.2 DeepSeek模型转换全流程模型转换是整个流程里最容易出问题的环节。RKLLM目前支持HuggingFace格式的模型需要先把DeepSeek的原始模型下载到本地。以DeepSeek-R1-Distill-Qwen-1.5B为例这个模型体积小、速度快适合在RK3588上做快速验证。下载模型git lfs install git clone https://huggingface.co/deepseek-ai/DeepSeek-R1-Distill-Qwen-1.5B转换脚本的核心逻辑是加载HuggingFace模型导出ONNX再转成RKNN格式。RKLLM toolkit提供了封装好的接口写一个转换脚本from rkllm.api import RKLLM modelpath ./DeepSeek-R1-Distill-Qwen-1.5B llm RKLLM() ret llm.load_huggingface(modelmodelpath) if ret ! 0: print(Load model failed!) exit(ret) ret llm.build( do_quantizationTrue, optimization_level1, quantized_dtypew8a8, target_platformrk3588 ) if ret ! 0: print(Build model failed!) exit(ret) ret llm.export_rkllm(./deepseek-1.5b-w8a8.rkllm) if ret ! 0: print(Export model failed!) exit(ret)这里有几个关键参数需要解释。do_quantization开启量化RK3588的NPU对INT8量化支持最好w8a8表示权重和激活都量化到8位。optimization_level控制优化等级1是默认值追求极致速度可以调到2但可能会损失一些精度。target_platform必须指定为rk3588否则生成的模型无法在板子上加载。转换过程在x86主机上跑1.5B模型大概需要10到15分钟7B模型要一个小时以上。转换完成后会生成一个.rkllm文件把它拷贝到板子上。4.3 板端推理代码编写与运行RKLLM的推理接口是C/C的官方提供了Python binding但C版本性能更好。先看一个最简化的推理示例#include stdio.h #include string.h #include rkllm.h LLMHandle handle nullptr; void callback(RKLLMResult* result, void* userdata, LLMCallState state) { if (state RKLLM_RUN_NORMAL) { printf(%s, result-text); } else if (state RKLLM_RUN_FINISH) { printf(\n); } } int main() { RKLLMParam param rkllm_createDefaultParam(); param.model_path ./deepseek-1.5b-w8a8.rkllm; param.top_k 1; param.top_p 0.95; param.temperature 0.8; param.repeat_penalty 1.1; param.max_new_tokens 512; param.max_context_len 2048; int ret rkllm_init(handle, param, callback); if (ret ! 0) { printf(rkllm init failed\n); return -1; } const char* prompt 你好请介绍一下你自己。; rkllm_run(handle, prompt, nullptr); rkllm_destroy(handle); return 0; }编译命令g -o demo demo.cpp -lrkllmrt -lpthread运行前确保NPU驱动已经加载ls /dev/rknpu*如果看到rknpu设备节点说明驱动正常。运行demo./demo4.4 性能调优与参数配置RKLLM的性能调优空间比Ollama大得多几个关键参数直接影响推理速度参数推荐值说明max_context_len2048上下文长度越大内存占用越高max_new_tokens512单次生成最大token数top_k1贪心解码速度最快top_p0.95核采样阈值temperature0.8控制随机性repeat_penalty1.1重复惩罚实测下来1.5B模型在RK3588 NPU上跑w8a8量化后生成速度能到每秒20到25个token7B模型大概每秒10到12个token。这个速度做本地对话助手已经够用了。注意RKLLM的NPU推理对内存带宽比较敏感建议把模型文件放在eMMC或者NVMe上不要放在低速TF卡里否则加载和推理速度都会受影响。5. 常见问题与排查技巧实录5.1 Ollama相关高频问题问题一ollama serve启动后无法访问这个多半是防火墙或者监听地址的问题。检查服务文件里的OLLAMA_HOST是否设成了0.0.0.0如果只监听127.0.0.1外部访问不了。另外确认11434端口没有被占用sudo netstat -tlnp | grep 11434问题二模型下载到一半断了Ollama的下载不支持断点续传断了就得重来。解决办法是用手动下载GGUF文件的方式用wget或者curl下载支持断点续传wget -c https://huggingface.co/.../model.gguf问题三推理时内存不足被OOM kill8GB内存跑7B模型确实紧张。可以尝试用更小的量化级别比如Q3_K_S或者换1.5B的模型。另外检查有没有其他进程占用内存把不必要的服务停掉。5.2 RKLLM相关高频问题问题一模型转换时报错“Unsupported operator”RKLLM对某些算子支持不完善尤其是自定义算子。解决办法是升级RKLLM toolkit到最新版本或者换一个模型架构。DeepSeek的蒸馏版本基于Qwen或者Llama架构兼容性比较好。问题二板端加载模型时报“rkllm init failed”先检查NPU驱动版本和RKLLM runtime版本是否匹配。用dmesg看内核日志dmesg | grep -i rknpu如果驱动版本太旧需要更新内核或者单独编译NPU驱动模块。问题三推理速度远低于预期检查CPU governor设置确保是performance模式。另外确认模型文件放在高速存储上NPU推理需要频繁读取模型权重存储速度直接影响性能。还有一点RKLLM默认可能没有开满NPU的核心数可以在param里设置npu_core_num参数。5.3 通用避坑清单问题现象可能原因解决方向系统盘空间不足默认分区太小重新分区或挂载外部存储板子过热降频散热不足加散热片或风扇模型加载慢存储速度慢换eMMC或NVMe推理结果乱码量化精度损失换更高精度量化NPU设备找不到驱动未加载检查内核模块实操心得RK3588的NPU驱动在系统启动时加载如果手动编译了内核记得把rknpu模块一起编译进去。另外NPU和GPU共享内存带宽如果同时跑图形界面和NPU推理性能会互相影响建议跑大模型时关掉桌面环境用命令行模式。6. 两条路线的融合与扩展思路实际项目中Ollama和RKLLM并不是非此即彼的关系。我目前的用法是用Ollama做模型管理和快速切换用RKLLM做实际推理。具体做法是写一个简单的调度层根据请求类型决定走哪条路径。对于延迟不敏感的批处理任务走Ollama的CPU推理对于实时交互请求走RKLLM的NPU加速。这个调度层可以用Python写通过subprocess调用RKLLM的C可执行文件或者直接用RKLLM的Python binding。Ollama那边通过REST API调用两者对上层提供统一的接口。这样既保留了Ollama的生态优势又发挥了NPU的性能。后续还可以考虑模型蒸馏和量化感知训练针对RK3588的NPU特性做进一步优化。瑞芯微的RKNN工具链支持自定义算子如果遇到不支持的算子可以自己实现NPU版本。这块门槛比较高但收益也大适合有深入优化需求的场景。另外RK3588支持多核NPU理论上可以并行跑多个小模型。我试过同时加载两个1.5B模型分别占用不同的NPU核心推理速度基本没有互相影响。这个特性在多模型场景下很有价值比如一个模型做意图识别另一个做内容生成。最后分享一个我在实际部署中总结的小技巧模型文件尽量用只读方式挂载避免意外写入导致文件损坏。RKLLM的模型文件比较大一旦损坏重新转换很费时间。可以在fstab里加noatime和ro选项提升读取性能的同时保护文件。