企业官网建设流程全解析

1. 为什么要在RK3588上跑本地大模型

1.1 边缘侧跑大模型的真实动机

把大模型塞进一块巴掌大的开发板，这件事在两年前还属于“想想就好”的范畴。但RK3588这颗芯片出来之后，情况变了。它自带6TOPS算力的NPU，配上8核CPU（4核A76+4核A55）和最高32GB内存的配置，已经具备了在端侧跑通中小参数对话模型的硬件基础。我最初动这个念头，是因为手上有个离线场景的需求：设备部署在没有稳定外网的环境里，但又需要具备自然语言交互能力。云端API方案首先被排除，延迟和可用性都不可控。于是开始研究在RK3588上做DeepSeek模型的本地部署。

这里说的“本地部署”，指的是把模型权重文件下载到开发板本地存储，通过推理框架加载后直接在板子上完成对话生成，整个过程不依赖任何外部网络请求。DeepSeek系列模型之所以适合这个场景，核心原因是它提供了多个参数规模的版本，其中1.5B到7B这个区间的模型，经过量化压缩后，刚好能塞进RK3588的内存和算力预算里。而且DeepSeek在中文对话上的表现，相比同参数量的其他开源模型有明显优势，这对于国内应用场景来说很关键。

适合读这篇内容的人，我大致分三类：一是手里已经有RK3588开发板，想找个实际项目练手的嵌入式开发者；二是做边缘计算产品，需要评估端侧AI对话可行性的方案工程师；三是对大模型本地部署感兴趣，想从低成本硬件入门的AI爱好者。不管你属于哪一类，接下来的内容都会从硬件准备、系统配置、模型选择、推理框架搭建到实际对话测试，一步步走完整个流程。

1.2 先搞清楚RK3588的算力账本

在动手之前，有必要先把RK3588的算力账算清楚。这颗芯片的NPU标称6TOPS，指的是INT8精度下的理论峰值算力。注意关键词：INT8和理论峰值。实际推理时，模型量化到INT8甚至INT4才能充分利用这个算力，如果用FP16跑，NPU的利用率会打折扣。另外6TOPS是NPU单独算力，CPU和GPU的算力是另外计算的。RK3588的Mali-G610 GPU虽然支持OpenCL，但在大模型推理上效率远不如NPU，所以我们的重点是把模型跑在NPU上。

内存方面，RK3588支持LPDDR4/4x/5，常见开发板配置有4GB、8GB、16GB、32GB几个档位。跑DeepSeek模型，我的建议是至少8GB起步，16GB会比较从容。以DeepSeek-R1-Distill-Qwen-1.5B为例，FP16精度下模型权重大约3GB，INT8量化后约1.5GB，INT4量化后不到1GB。加上推理时的KV Cache和系统占用，8GB内存跑1.5B模型是够的，但如果想跑7B模型，16GB内存是底线。

存储方面，eMMC的速度直接影响模型加载时间。我实测下来，一个1.5GB的模型文件从eMMC加载到内存大约需要15-20秒，如果放在SD卡上会更慢。所以建议把模型文件放在eMMC或者NVMe SSD上（部分开发板有M.2接口）。网络方面，虽然推理不需要联网，但下载模型权重和安装依赖包时需要稳定的网络连接，建议用有线网口而不是WiFi，速度更稳定。

2. 部署前的环境准备与系统配置

2.1 系统镜像选择与烧录

RK3588开发板出厂时通常预装了Android系统，但我们要跑大模型，Ubuntu是更合适的选择。目前RK3588的Ubuntu支持已经比较成熟，官方和社区都有维护的镜像。我推荐使用Ubuntu 22.04 LTS版本，原因是它的软件包生态最完善，Python版本和各类推理框架的兼容性最好。虽然网上有关于Ubuntu 26的讨论，但截至我写这篇内容时，RK3588平台上的Ubuntu 26支持还不够稳定，不建议在生产验证阶段使用。

烧录工具方面，瑞芯微官方的RKDevTool是标配。操作流程是：先用Type-C线连接开发板的OTG口和电脑，按住Recovery键再上电进入Loader模式，然后在RKDevTool中加载固件包，点击升级即可。这里有个细节需要注意：不同开发板的Recovery键位置不同，有的在板子正面，有的在背面，烧录前先确认好。另外，烧录完成后第一次启动会比较慢，因为系统要做分区扩展和初始化，耐心等3-5分钟。

系统启动后，第一件事是更新软件源和安装基础依赖。打开终端，依次执行：

sudo apt update && sudo apt upgrade -y sudo apt install -y python3-pip python3-dev cmake git wget curl sudo apt install -y libopenblas-dev libomp-dev

这些包后面编译推理框架时会用到。libopenblas提供CPU端的矩阵运算加速，libomp提供OpenMP多线程支持。虽然我们主要用NPU推理，但框架编译时这些依赖是必须的。

2.2 NPU驱动与RKNN Toolkit2安装

RK3588的NPU要通过RKNN Toolkit2来调用。这是瑞芯微官方提供的推理工具链，负责把训练好的模型转换成RKNN格式，然后在NPU上执行。安装RKNN Toolkit2有两个途径：一是通过pip安装预编译版本，二是从源码编译。我建议先用pip试试：

pip3 install rknn-toolkit2

如果pip安装失败或者版本不匹配，就需要从官方仓库下载对应的whl包手动安装。注意RKNN Toolkit2的版本要和板子上的NPU驱动版本匹配，版本不匹配会导致模型加载失败。查看NPU驱动版本的方法是：

cat /sys/kernel/debug/rknpu/version

这个命令会输出当前NPU驱动的版本号，比如“RKNPU driver version: 0.9.6”。然后去官方仓库找对应版本的rknn_toolkit2 whl包。安装完成后，用以下Python代码验证是否正常：

from rknnlite.api import RKNNLite rknn = RKNNLite() ret = rknn.load_rknn('test.rknn') print('Load ret:', ret)

如果输出“Load ret: 0”，说明环境配置成功。这里要提醒一点：RKNN Toolkit2在板子上运行时用的是rknnlite模块，而在PC端做模型转换时用的是完整的rknn模块，两者不要搞混。

2.3 内存与存储的优化配置

在跑大模型之前，建议对系统做一些优化。首先是调整swap分区，虽然swap会拖慢推理速度，但在内存紧张时可以防止进程被OOM Killer杀掉。建议设置2-4GB的swap：

sudo fallocate -l 4G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile

然后把swapfile写入/etc/fstab，让它开机自动挂载。其次是调整CPU调度策略，把CPU governor设为performance模式，避免推理时降频：

echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

这个设置对推理速度有5%-10%的影响，值得做。最后是清理不必要的后台服务，比如蓝牙、打印服务等，释放内存给模型用。用systemctl list-units可以查看当前运行的服务，把不需要的disable掉。

3. DeepSeek模型的选择与转换

3.1 哪个DeepSeek版本适合RK3588

DeepSeek家族模型不少，但并不是所有版本都适合在RK3588上跑。我们需要考虑三个约束：参数量、量化后的体积、以及NPU对算子类型的支持程度。目前经过实测，比较适合RK3588的DeepSeek模型有以下几个：

1.5B版本是甜点级选择，速度和效果平衡得最好。7B版本效果更好，但对内存要求高，而且推理速度会明显下降。如果你的板子是16GB内存，可以尝试7B版本；8GB内存的话，老老实实跑1.5B。另外要注意，DeepSeek-R1系列是推理模型，输出时会带思维链，实际对话体验和普通对话模型略有不同。如果只是做日常对话，DeepSeek-V2-Lite或者DeepSeek-R1-Distill-Qwen-1.5B都够用。

3.2 模型下载与格式转换

模型权重可以从HuggingFace或者ModelScope下载。考虑到网络因素，国内用户建议用ModelScope。以DeepSeek-R1-Distill-Qwen-1.5B为例：

git lfs install git clone https://www.modelscope.cn/deepseek-ai/DeepSeek-R1-Distill-Qwen-1.5B.git

下载完成后得到的是PyTorch格式的模型文件。要跑在NPU上，需要先转成ONNX格式，再转成RKNN格式。转换过程在PC端完成，因为RKNN Toolkit2的完整版只在x86 Linux上运行。转换脚本的核心逻辑是：

from rknn.api import RKNN rknn = RKNN() rknn.config(mean_values=[[0, 0, 0]], std_values=[[1, 1, 1]], target_platform='rk3588') rknn.load_onnx(model='deepseek-1.5b.onnx') rknn.build(do_quantization=True, dataset='./calibration.txt') rknn.export_rknn('deepseek-1.5b.rknn')

这里的关键是量化校准数据集。do_quantization=True时，RKNN会用校准数据集来统计激活值的分布，从而确定量化参数。校准数据集的质量直接影响量化后的精度损失。我的经验是准备100-200条中文对话样本作为校准数据，覆盖不同的句式长度和话题类型。如果校准数据太单一，量化后的模型在遇到没见过的句式时会出现明显的质量下降。

3.3 量化精度与速度的权衡

量化是端侧部署绕不开的话题。RK3588的NPU对INT8和INT4都有支持，但两者的取舍不同。INT8量化后精度损失较小，通常只有1%-3%的下降，但模型体积是INT4的两倍。INT4量化后体积大幅缩小，但精度损失可能达到5%-10%，而且不是所有算子都支持INT4。

我的建议是：如果内存充足（16GB以上），优先用INT8，精度更有保障。如果内存紧张（8GB），用INT4，但要做好对话质量下降的心理准备。另外，混合量化也是个选择：对精度敏感的层用INT8，对精度不敏感的层用INT4。RKNN Toolkit2支持通过hybrid_quantization参数开启混合量化，但配置起来比较麻烦，需要对模型结构有深入了解。

还有一个容易被忽略的点：KV Cache的量化。对话模型推理时需要缓存历史token的Key和Value矩阵，这部分占用的内存会随着对话轮数增加而增长。如果KV Cache用FP16存储，跑多轮对话时内存会很快吃紧。把KV Cache也量化到INT8，可以节省一半内存，但对推理框架有额外要求。

4. 推理框架搭建与对话功能实现

4.1 基于RKNN的推理引擎搭建

模型转成RKNN格式后，下一步是在板子上搭建推理引擎。核心工作包括：加载RKNN模型、初始化NPU运行时、实现tokenizer、管理KV Cache、以及构建对话循环。RKNNLite的API比较简洁，加载模型和推理的代码大致如下：

from rknnlite.api import RKNNLite import numpy as np rknn = RKNNLite() rknn.load_rknn('deepseek-1.5b.rknn') rknn.init_runtime(core_mask=RKNNLite.NPU_CORE_0) # 构造输入 input_ids = np.array([[1, 234, 567, 890]], dtype=np.int64) outputs = rknn.inference(inputs=[input_ids])

但实际部署时远不止这么简单。DeepSeek模型是自回归生成的，每生成一个token都需要把之前的KV Cache作为输入传进去。RKNNLite的inference接口支持多输入，所以需要把input_ids、attention_mask、past_key_values等一起传入。这里有个坑：RKNN对动态shape的支持有限，如果每次输入的序列长度不同，需要重新编译模型或者做padding。我的做法是固定一个最大序列长度（比如512），不足的部分用padding补齐，这样只需要编译一次模型。

4.2 Tokenizer与对话模板处理

DeepSeek用的是自己的tokenizer，需要从模型目录加载tokenizer.json和tokenizer_config.json。在板子上可以用transformers库的AutoTokenizer，但transformers库比较重，会占用不少内存。如果内存紧张，可以用tokenizers库单独加载，体积小很多：

from tokenizers import Tokenizer tokenizer = Tokenizer.from_file('tokenizer.json')

对话模板方面，DeepSeek-R1系列有自己的chat template，格式是：

<|im_start|>user 你的问题<|im_end|> <|im_start|>assistant

如果模板用错了，模型输出会变得很奇怪，比如重复输出或者答非所问。这个模板定义在tokenizer_config.json的chat_template字段里，部署前先确认一下。另外，DeepSeek-R1是推理模型，输出中会包含<|thinking|>标签包裹的思维链内容。如果不需要展示思维链，可以在后处理时把标签之间的内容过滤掉。

4.3 对话循环与流式输出实现

对话循环的核心逻辑是：接收用户输入 -> 拼接对话模板 -> tokenize -> 推理生成 -> detokenize -> 输出。流式输出是指每生成一个token就立即显示，而不是等整句话生成完再显示。这对用户体验影响很大，尤其是RK3588上推理速度不快的情况下，流式输出能让用户感知到模型在“思考”。

实现流式输出的关键是维护一个生成状态机。每次推理只生成一个token，然后把新token追加到输入序列中，同时更新KV Cache。伪代码逻辑如下：

past_kv = None generated_ids = [] for _ in range(max_new_tokens): outputs = rknn.inference(inputs=[input_ids, past_kv]) next_token = sample(outputs.logits) if next_token == eos_token_id: break generated_ids.append(next_token) input_ids = np.array([[next_token]]) past_kv = outputs.past_kv print(tokenizer.decode([next_token]), end='', flush=True)

采样策略方面，可以用temperature+top_p的组合。temperature控制随机性，top_p控制候选集大小。对于对话场景，temperature=0.7、top_p=0.9是比较通用的配置。如果希望输出更稳定，可以把temperature降到0.3。

5. 性能调优与常见问题排查

5.1 推理速度优化实战

RK3588上跑1.5B模型，初始速度大概在5-8 tokens/s。经过优化后可以提升到10-15 tokens/s。优化手段主要有以下几个：

第一，启用NPU多核。RK3588的NPU有三个核心，可以通过core_mask参数指定使用哪些核心。对于大模型推理，建议用RKNNLite.NPU_CORE_0_1_2开启全部三个核心，速度能提升30%左右。但要注意，多核推理需要模型支持并行，不是所有模型都能受益。

第二，调整CPU亲和性。推理过程中有一部分算子在CPU上执行（比如LayerNorm、Softmax等），把这些算子绑定到大核（A76）上执行，避免被调度到小核。可以用taskset命令绑定：

taskset -c 4-7 python3 chat.py

这里4-7对应的是A76大核的CPU编号，具体编号可以用lscpu查看。

第三，减少内存拷贝。RKNN推理时，输入数据需要从CPU内存拷贝到NPU内存，输出再拷贝回来。如果输入输出数据量大，拷贝开销不可忽略。优化方法是尽量用零拷贝接口，或者把多次推理合并成一次批量推理。

第四，模型层面的优化。比如把attention层的计算合并，减少算子数量；或者用FlashAttention替代标准attention，减少内存访问。不过这些优化需要对模型结构做修改，门槛较高。

5.2 常见报错与解决方法

部署过程中遇到的报错五花八门，我整理了几个高频问题：

其中“Unsupport op type”是最常见的。RK3588的NPU对算子支持有限，像一些自定义的激活函数、特殊的attention变体，都可能不支持。解决方法是先用ONNX Simplifier做图优化，把能合并的算子合并，能消除的消除。如果还有不支持的算子，就需要用CPU fallback，把这部分算子放到CPU上执行。RKNN Toolkit2支持通过custom_op参数指定CPU fallback的算子。

5.3 实操避坑经验汇总

最后分享几个我在实操中踩过的坑，都是文档里不会写的：

第一个坑：模型转换时的校准数据集不能太少。我一开始只用了20条样本做校准，结果量化后的模型在遇到长句子时输出乱码。后来增加到200条，问题解决。校准数据的多样性比数量更重要，要覆盖短句、长句、问句、陈述句等不同形式。

第二个坑：板子上的Python版本要和PC端一致。我在PC上用Python 3.10转换的模型，板子上是Python 3.8，结果rknnlite加载时报版本不兼容。后来统一用3.8才解决。建议在PC端用虚拟环境，版本和板子保持一致。

第三个坑：散热问题。RK3588跑大模型时NPU满载，发热量不小。如果开发板没有散热片，连续跑10分钟以上会触发降频，推理速度直接腰斩。建议加装散热片或者小风扇，成本不高但效果明显。

第四个坑：电源要够。RK3588满载功耗可以到10W以上，如果用的电源适配器功率不够，会出现板子重启或者NPU初始化失败。建议用5V/3A以上的电源，最好带独立供电的USB Hub。

第五个坑：不要用SD卡跑模型。SD卡的读取速度远低于eMMC，模型加载时间会从20秒变成2分钟。而且SD卡的稳定性不如eMMC，长时间读写容易出错。如果板子支持NVMe SSD，把模型放在SSD上是最优解。

5.4 对话效果调优与扩展方向

模型跑起来之后，对话效果调优是下一步。几个实用的调优方向：一是调整system prompt，给模型设定一个明确的角色和回答风格，能显著提升对话质量。二是调整重复惩罚参数（repetition_penalty），DeepSeek模型有时会陷入重复循环，把repetition_penalty设为1.1-1.2可以有效缓解。三是限制max_new_tokens，避免模型生成过长的无用内容。

扩展方向方面，如果想让对话系统具备联网搜索能力，可以在本地部署一个轻量级的检索模块，把检索结果作为上下文拼接到prompt里。如果想让模型支持多轮复杂对话，可以引入对话历史管理，把之前的对话摘要压缩后作为上下文。另外，RK3588支持多路NPU并行，如果板子上同时跑多个模型（比如一个对话模型加一个视觉模型），可以通过core_mask分配不同的NPU核心，实现并行推理。

我在实际使用中发现，1.5B模型在RK3588上的对话体验已经可以满足基本的问答需求，但复杂推理任务还是力不从心。如果对效果要求高，建议上7B模型配16GB内存，或者考虑用多块RK3588做分布式推理。这个方向后续还可以继续折腾，比如尝试用RK3588的GPU做部分算子的加速，或者探索更激进的量化方案。