1. 为什么要在RK3588上折腾大模型本地部署手里有一块RK3588的开发板6TOPS的NPU算力摆在那里如果只拿来跑跑YOLOv8或者做做视频解码说实话有点浪费。去年DeepSeek系列模型开源之后推理能力在中小参数级别里算是相当能打的尤其是DeepSeek-R1的蒸馏版本1.5B到7B的参数规模放在边缘端做本地推理完全可行。我前后花了大概三周时间在RK3588上把Ollama和RKLLM两条路线都跑通了踩了不少坑也积累了一些实测数据这里做个完整的梳理。先说清楚这个项目解决什么问题。核心需求是在RK3588开发板上实现DeepSeek大模型的本地推理不依赖云端API数据不出设备同时尽量利用NPU加速而不是纯CPU硬扛。适合谁看如果你手里有RK3588板子想跑本地大模型做智能问答、文档摘要、代码辅助这类应用或者你正在评估边缘端AI推理方案这篇内容应该能帮你省下不少试错时间。两条路线各有侧重。Ollama路线胜在生态成熟、模型管理方便、上手快但默认走CPU推理RK3588的八核A76/A55跑7B模型大概每秒出3到5个token能用但不算快。RKLLM路线是瑞芯微官方推出的NPU推理框架能把模型转成RKNN格式跑在NPU上速度提升明显但工具链配置麻烦模型转换有坑。我的建议是两条路线都了解根据实际场景选。注意RK3588的NPU对LLM的支持有版本要求RKLLM工具链需要配合特定的NPU驱动版本建议先把板子的固件和驱动更新到较新版本再动手。2. 硬件与系统环境准备2.1 板子选型与基础配置确认RK3588开发板市面上有不少选择核心芯片是一样的但外围配置差异会影响使用体验。最关键的是内存容量跑大模型建议至少8GB起步16GB更稳妥。我手头这块是16GB LPDDR4x的版本跑7B的INT4量化模型大概占用4到5GB内存加上系统本身的开销8GB版本会比较紧张。存储方面eMMC容量普遍偏小建议用NVMe SSD或者高速TF卡来存放模型文件。一个7B的INT4量化模型大概3.5到4GB加上Ollama的运行时和系统文件32GB起步比较合理。我一开始用16GB的eMMC烧完Ubuntu 20.04之后剩余空间不到8GB装完Ollama和一个小模型就满了后来换了128GB的NVMe才舒服。系统方面官方推荐Ubuntu 20.04或者22.04。我实测下来22.04的兼容性更好一些内核版本建议5.10以上。如果你拿到的是刚烧写的系统第一件事是检查磁盘空间和NPU驱动版本# 查看磁盘空间 df -h # 查看NPU驱动版本 cat /sys/kernel/debug/rknpu/version # 查看内核版本 uname -aNPU驱动版本很关键RKLLM要求驱动版本在0.9.6以上如果低于这个版本需要先更新固件。更新固件的方法参考板子厂商的文档不同厂商的烧录工具不太一样这里不展开。2.2 系统优化与依赖安装刚烧写的系统通常需要做一些基础优化。首先是换源国内访问默认源速度慢换成国内镜像源能省不少时间。然后是安装基础依赖sudo apt update sudo apt install -y build-essential cmake git wget curl python3-pip sudo apt install -y libopenblas-dev libblas-dev liblapack-dev如果你打算用Ollama还需要确认系统支持AVX指令集。RK3588的A76核心支持ARMv8.2的SIMD指令但Ollama的预编译包主要是针对x86的ARM64版本需要从源码编译或者找社区维护的ARM64包。这一点后面会详细说。磁盘空间不足是新手最容易遇到的问题。我建议在烧写系统的时候就规划好分区把根分区留大一些或者干脆把模型文件放在外挂存储上通过软链接的方式让Ollama和RKLLM访问。具体做法# 假设外挂存储挂载在 /mnt/nvme mkdir -p /mnt/nvme/ollama_models ln -s /mnt/nvme/ollama_models ~/.ollama/models提示软链接的方式对Ollama有效但RKLLM的模型路径需要在配置文件里显式指定不能靠软链接糊弄过去。3. Ollama路线快速上手与CPU推理优化3.1 Ollama在ARM64上的安装方法Ollama官方提供了Linux的安装脚本但默认下载的是x86_64的二进制包。在RK3588这种ARM64平台上直接跑安装脚本会报格式错误。解决办法有两个一是从源码编译二是找社区维护的ARM64版本。源码编译的步骤不算复杂但耗时较长在RK3588上大概需要40分钟到1小时# 安装Go语言环境 wget https://go.dev/dl/go1.22.0.linux-arm64.tar.gz sudo tar -C /usr/local -xzf go1.22.0.linux-arm64.tar.gz export PATH$PATH:/usr/local/go/bin # 克隆Ollama源码 git clone https://github.com/ollama/ollama.git cd ollama # 编译 go generate ./... go build -o ollama . # 安装 sudo cp ollama /usr/local/bin/编译过程中可能会遇到依赖缺失的问题主要是llama.cpp相关的C依赖。如果报错提示找不到某个头文件用apt安装对应的dev包即可。编译完成后启动Ollama服务ollama serve 然后验证是否正常运行ollama --version如果能看到版本号输出说明安装成功。接下来就可以拉取模型了。3.2 模型选择与国内镜像加速Ollama默认从官方仓库拉取模型国内网络环境下速度可能很慢一个4GB的模型拉半小时是常事。解决办法是配置国内镜像源。目前比较稳定的做法是设置环境变量export OLLAMA_HOST0.0.0.0 export OLLAMA_MODELS/mnt/nvme/ollama_models然后在拉取模型时指定镜像地址。不过Ollama的镜像源支持不如Docker那么成熟更可靠的办法是手动下载模型文件再导入。以DeepSeek-R1的1.5B蒸馏版为例# 从国内镜像站下载GGUF格式的模型文件 wget https://modelscope.cn/models/.../deepseek-r1-1.5b-q4.gguf # 创建Modelfile cat Modelfile EOF FROM ./deepseek-r1-1.5b-q4.gguf PARAMETER temperature 0.7 PARAMETER top_p 0.9 SYSTEM 你是一个有用的AI助手。 EOF # 导入模型 ollama create deepseek-r1-1.5b -f Modelfile模型选择上RK3588的CPU性能有限建议从1.5B或3B的模型开始试。7B的模型在CPU上跑推理速度大概每秒3到5个token做简单的问答还行长文本生成就比较煎熬了。1.5B的模型速度能到每秒10到15个token体验好很多。模型规格量化方式内存占用CPU推理速度适用场景DeepSeek-R1-1.5BQ4_K_M~1.2GB10-15 tok/s简单问答、文本分类DeepSeek-R1-3BQ4_K_M~2.2GB6-8 tok/s中等复杂度问答DeepSeek-R1-7BQ4_K_M~4.5GB3-5 tok/s复杂推理、代码辅助DeepSeek-R1-7BQ8_0~8GB1-2 tok/s不推荐在RK3588上跑3.3 CPU推理的性能调优技巧Ollama在ARM64上默认会使用所有可用的CPU核心但RK3588是大小核架构4个A76大核加4个A55小核。如果任务被调度到小核上性能会明显下降。可以通过taskset命令绑定大核# 查看CPU核心编号 lscpu # 绑定到A76大核通常是CPU 4-7 taskset -c 4-7 ollama serve另一个优化点是调整线程数。Ollama默认的线程数是CPU核心数但在大小核架构上设置成4只用大核往往比8全部核心更快因为避免了核心间任务迁移的开销。可以在启动时指定OLLAMA_NUM_THREADS4 ollama serve内存带宽也是瓶颈。RK3588的内存带宽大概在10GB/s左右跑7B模型时内存带宽基本跑满。如果同时跑其他内存密集型任务推理速度会明显下降。建议在跑大模型时关掉不必要的后台服务。实操心得我在测试时发现把Ollama的模型文件放在NVMe SSD上比放在eMMC上模型加载速度快了将近3倍。eMMC的随机读取性能太差了模型加载时会有明显的卡顿。4. RKLLM路线NPU加速的完整实现4.1 RKLLM工具链的获取与安装RKLLM是瑞芯微官方推出的NPU推理框架专门针对RK3588等芯片优化。工具链包括模型转换工具和运行时库两部分。模型转换工具跑在x86主机上运行时库跑在RK3588上。首先在x86主机上获取RKLLM工具链。瑞芯微的开发者网站提供了下载文件通常是一个压缩包解压后包含转换工具和示例代码# 解压工具链 tar -xzf rkllm_toolkit.tar.gz cd rkllm_toolkit # 安装Python依赖 pip install -r requirements.txt转换工具的核心是一个Python脚本叫rkllm_converter.py或者类似的名字。它接受HuggingFace格式的模型作为输入输出RKNN格式的模型文件。支持的模型架构包括Llama、Qwen、ChatGLM等DeepSeek-R1的蒸馏版是基于Qwen或Llama架构的所以可以直接转换。在RK3588端需要安装RKLLM的运行时库# 拷贝运行时库到板子 scp -r rkllm_runtime/ userrk3588:/home/user/ # 在板子上安装 cd rkllm_runtime sudo cp lib/librkllmrt.so /usr/lib/ sudo cp include/rkllm.h /usr/include/运行时库的版本要和NPU驱动版本匹配不匹配的话会报错。我遇到过驱动版本0.9.2配RKLLM 1.0.0的运行时加载模型时直接段错误升级驱动后解决。4.2 模型转换的关键参数与实操模型转换是整个流程里最容易出问题的环节。以DeepSeek-R1-Distill-Qwen-1.5B为例转换命令大概长这样python rkllm_converter.py \ --model_path ./DeepSeek-R1-Distill-Qwen-1.5B \ --output_path ./deepseek-r1-1.5b.rkllm \ --quantized_dtype w4a16 \ --target_platform rk3588 \ --max_context 4096几个关键参数需要解释一下。quantized_dtype指定量化方式w4a16表示权重4bit量化、激活16bit这是精度和速度比较平衡的选择。w8a8精度更高但速度慢一些w4a16在RK3588上实测速度能快30%左右。max_context指定最大上下文长度设置得越大占用的内存越多4096对于大多数场景够用了。转换过程中可能会遇到几个典型问题。一是模型架构不支持RKLLM对某些自定义的模型结构支持不好需要手动修改模型代码。二是量化校准数据的问题w4a16量化需要校准数据集工具链自带了一个默认的校准集但如果你的应用场景比较特殊最好用自己的数据做校准。转换完成后把生成的.rkllm文件拷贝到RK3588上就可以用运行时库加载了。官方提供了一个C的示例程序cd examples mkdir build cd build cmake .. make ./rkllm_demo ../deepseek-r1-1.5b.rkllm如果一切正常你会看到模型加载成功的信息然后就可以输入prompt进行推理了。4.3 NPU推理性能实测与对比NPU加速的效果到底怎么样直接看数据。我在同一块RK3588上对比了Ollama CPU推理和RKLLM NPU推理的速度模型推理方式首token延迟生成速度内存占用DeepSeek-R1-1.5BOllama CPU~800ms12 tok/s1.5GBDeepSeek-R1-1.5BRKLLM NPU~300ms28 tok/s1.2GBDeepSeek-R1-7BOllama CPU~2500ms4 tok/s5GBDeepSeek-R1-7BRKLLM NPU~900ms11 tok/s4.2GB数据很直观NPU加速后1.5B模型的速度翻了一倍多7B模型从几乎不可用变成了勉强可用。首token延迟的改善也很明显这对交互式应用来说很重要。不过NPU也不是没有代价。RKLLM的运行时库对内存的管理比较激进加载7B模型时内存占用虽然比CPU推理低但峰值内存会冲到6GB以上8GB版本的板子可能会触发OOM。另外NPU推理的精度损失比CPU推理略大一些w4a16量化后模型在复杂推理任务上的表现会有轻微下降简单问答基本无感。注意RKLLM目前对多轮对话的支持还不够完善上下文管理需要自己在应用层实现。如果做多轮对话应用建议把历史对话拼接成新的prompt重新推理而不是依赖框架的上下文缓存。5. 两条路线的选型建议与混合方案5.1 什么场景选Ollama什么场景选RKLLMOllama的优势在于生态。模型管理、API接口、多模型切换这些功能都是现成的社区支持也好遇到问题容易找到答案。如果你的应用需要频繁切换模型或者需要和现有的Ollama生态工具链集成那Ollama是更省心的选择。CPU推理的速度虽然不如NPU但1.5B模型12 tok/s的速度做简单的问答和文本处理已经够用了。RKLLM的优势在于性能和功耗。NPU推理时CPU占用率很低整板功耗比CPU推理低30%左右这对散热受限的嵌入式场景很重要。如果你的应用对推理速度有要求或者需要长时间连续推理RKLLM是更好的选择。但要做好心理准备工具链的坑比较多模型转换、版本匹配、内存管理都需要花时间调试。我的建议是先用Ollama快速验证应用逻辑确认模型效果满足需求后再切换到RKLLM做性能优化。这样可以把模型效果验证和性能优化两个阶段分开降低调试复杂度。5.2 混合部署的可行性分析有没有可能两条路线混着用技术上可行但实际意义不大。Ollama和RKLLM的模型格式不兼容同一个模型需要维护两份文件存储开销翻倍。而且两个运行时同时加载模型会争抢内存RK3588的内存本来就不宽裕。不过有一种场景可以考虑混合用RKLLM跑主模型做推理用Ollama跑一个小模型做辅助任务比如意图识别或者文本分类。这种场景下两个模型的规模都不大内存压力可控。但实现复杂度较高需要自己写调度逻辑除非有明确的需求否则不建议折腾。5.3 实际项目中的部署架构如果要把这个方案落地到实际产品里我建议的架构是这样的底层用RKLLM做NPU推理上层用一个轻量的HTTP服务包装成API对外提供OpenAI兼容的接口。这样前端应用可以无缝切换不需要关心底层用的是Ollama还是RKLLM。服务层可以用Python的FastAPI或者C的crow框架实现核心逻辑就是接收请求、调用RKLLM的推理接口、返回结果。RKLLM的C接口用起来比较繁琐可以封装成Python扩展或者直接用subprocess调用官方的demo程序。# 简化的FastAPI包装示例 from fastapi import FastAPI import subprocess import json app FastAPI() app.post(/v1/chat/completions) async def chat(request: dict): prompt request[messages][-1][content] # 调用RKLLM推理 result subprocess.run( [./rkllm_demo, model.rkllm, prompt], capture_outputTrue, textTrue ) return {choices: [{message: {content: result.stdout}}]}这个方案的好处是解耦推理引擎可以替换前端应用不用改。坏处是subprocess调用有进程创建的开销高频请求场景下性能会受影响。更好的做法是用RKLLM的C接口直接集成到服务里但这需要一定的C开发能力。6. 常见问题排查与避坑指南6.1 模型加载失败与内存不足的排查模型加载失败是最常见的问题表现通常是程序直接退出或者报段错误。排查思路按这个顺序来先确认模型文件完整用md5sum校验一下再确认运行时库版本和NPU驱动版本匹配最后检查内存是否足够。内存不足的表现比较隐蔽有时候不会直接报OOM而是加载到一半卡住。可以用free -h和dmesg | tail查看系统日志。如果看到OOM killer的记录那就是内存不够了。解决办法要么换更小的模型要么增加swap空间# 创建4GB的swap文件 sudo fallocate -l 4G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile不过swap对推理速度的影响很大NPU推理时如果频繁换页速度会掉到不如CPU推理。所以swap只能作为应急手段长期方案还是加内存或者换小模型。6.2 推理速度不达预期的调优思路推理速度慢的原因可能有很多按可能性排序一是模型没有跑在NPU上二是CPU频率被限制三是散热导致降频。确认模型是否跑在NPU上可以查看NPU的利用率cat /sys/kernel/debug/rknpu/load如果NPU利用率接近0说明推理跑在CPU上需要检查RKLLM的配置。CPU频率可以用cpufreq-info查看如果频率被限制在1GHz以下需要调整governorsudo cpufreq-set -g performance散热问题在长时间推理时比较明显。RK3588的TDP大概在5W左右被动散热下连续跑10分钟就会降频。加个风扇或者散热片能明显改善。6.3 常见问题速查表问题现象可能原因排查方法解决方案模型加载段错误运行时库与驱动版本不匹配查看dmesg日志升级NPU驱动或降级运行时库推理速度极慢模型跑在CPU上查看NPU利用率检查RKLLM配置确认NPU启用生成结果乱码量化精度过低对比不同量化版本换w8a8量化或提高校准质量内存不足OOM模型太大或内存泄漏free -h查看内存换小模型或增加swap多轮对话丢失上下文RKLLM上下文管理限制检查prompt拼接逻辑应用层手动管理对话历史首次推理特别慢模型加载和预热观察首次和后续推理差异预热一次后再对外服务实操心得RKLLM的模型转换工具对Python版本有要求我试过Python 3.8和3.10都能跑但3.11以上会有依赖冲突。建议用conda创建一个独立的Python 3.10环境来做转换避免污染系统环境。7. 性能优化的进阶方向7.1 模型量化策略的深入调整w4a16量化是默认选项但不是唯一选项。如果你的应用对精度要求高可以试试w8a8量化速度会慢一些但精度损失更小。RKLLM还支持混合量化对模型的不同层使用不同的量化精度比如注意力层用w8a8FFN层用w4a16。这需要修改转换脚本里的量化配置对模型结构有一定了解。校准数据集的选择也很关键。默认的校准集是通用语料如果你的应用场景比较垂直比如法律或者医疗用领域数据做校准能明显提升量化后的精度。校准集的规模不用很大几百条样本就够了但质量要高。7.2 多模型并行与任务调度RK3588只有一个NPU多模型并行只能分时复用。如果同时加载多个模型内存会是个大问题。更实际的做法是模型按需加载用完就卸载。RKLLM的运行时支持动态加载和卸载模型但频繁加载卸载会有开销需要根据请求频率做权衡。任务调度方面可以用优先级队列来管理推理请求。高优先级的请求先处理低优先级的排队。RKLLM的推理是阻塞式的一个请求处理完才能处理下一个所以调度逻辑要在应用层实现。7.3 与向量数据库结合的RAG方案本地大模型做RAG是个很实用的方向。RK3588上可以跑一个轻量的向量数据库比如ChromaDB或者FAISS把文档向量化后存在本地。用户提问时先检索相关文档再把文档和问题一起送给大模型推理。这个方案的难点在于向量化模型的选择。RK3588的NPU可以跑一些小的embedding模型比如bge-small或者m3e-small速度很快。但向量数据库的检索是CPU密集型的和NPU推理会争抢资源。建议把检索和推理分时进行或者用多线程做流水线。整个RAG流程在RK3588上跑从提问到出结果大概需要2到3秒其中检索占0.5秒推理占2秒左右。这个延迟对于本地知识库问答来说是可以接受的。最后分享一个我在调试过程中总结的小技巧RKLLM的日志输出比较简略出问题时不容易定位。可以在编译运行时库的时候打开debug选项或者在代码里加一些打印。另外瑞芯微的开发者社区里有不少人在折腾RK3588跑大模型遇到奇怪的问题可以去搜搜看大概率有人已经踩过同样的坑了。