在边缘端落地大模型RK3588 是近两年最热门的平台之一NPU 算力可用、生态逐步完善、硬件成本可控。很多开发者真正关心的不是“能不能跑”而是能否形成一条稳定、可复现、可交付的部署链路。本文就围绕这个目标给出一套完整方案模型准备 → RKLLM 转换 → 板端推理服务 → 局域网 Web 浏览与对话重点说明DeepSeek-R1 原始大模型参数规模极大不可能直接部署在 RK3588。本文采用的是DeepSeek-R1-Distill系列如 1.5B/7B进行端侧部署实践这才是工程上可落地的路径。一、整体架构先看懂你到底在部署什么把流程画成一句话就是在 x86 主机完成模型转换HF/PyTorch → RKLLM 可执行格式→ 拷贝到 RK3588 板卡 → 板端运行推理服务 → 局域网浏览器访问 WebUI。建议拆成 4 层模型层DeepSeek-R1-Distill推荐先 1.5B转换层RKLLM Toolkit量化、编译、导出推理层RK3588 板端 RuntimeNPU/CPU 协同应用层Flask/FastAPI Gradio/OpenWeb 前端LAN 访问这样拆分的好处是后续升级模型、替换前端、增加 API 都不需要推翻重来。二、硬件与软件准备清单开工前务必确认1硬件建议RK3588 开发板建议 16GB 内存版本8GB 也能跑但更紧张稳定散热风扇/散热片千兆网口或稳定 Wi-Fi局域网访问更顺TF 卡或 eMMC/SSD建议预留 20GB2主机环境模型转换用Ubuntu 20.04 / 22.04x86_64Python 3.10Git、pip、conda可选Rockchip 官方 RKLLM Toolkit以官方发布版本为准3板端环境官方推荐 Linux 镜像带 NPU 驱动版本对应版本的 runtime 库与转换工具版本严格匹配Python3若你用 Python 包装服务经验结论90% 的“跑不起来”都来自版本不匹配特别是 toolkit、runtime、内核驱动三者不一致。三、模型选择策略别直接上“最大”先跑通最关键DeepSeek-R1 在边缘端部署必须遵循“先小后大”首选DeepSeek-R1-Distill-Qwen-1.5B进阶DeepSeek-R1-Distill-Qwen-7B对内存和速度要求明显更高为什么推荐 1.5B 起步转换成功率高板端首 token 延迟更可控便于先打通 API Web 全流程后续升级 7B 只需替换模型和参数不改架构四、RKLLM 转换实战在 x86 主机上完成以下命令是通用范式不同版本参数名可能略有差异请以你下载的官方示例脚本为准。1创建环境并安装工具链bashconda create -n rkllm python3.10 -y conda activate rkllm pip install -U pip # 安装 RKLLM toolkit本地whl或官方源 pip install rkllm_toolkit-*.whl2下载模型HF 目录结构保持完整bashmkdir -p ~/models/deepseek_r1_1p5b # 将 tokenizer、config、safetensors 等文件完整放入该目录3编写转换脚本示意python# convert_deepseek_r1.py from rkllm.api import RKLLMModel model RKLLMModel( model_path~/models/deepseek_r1_1p5b, model_typeqwen2, # Distill 基于Qwen系时常用该类型 targetrk3588, quant_typew4a16, # 常见端侧平衡方案 max_context_len4096 ) model.build() model.export(./output/deepseek_r1_1p5b_w4a16.rkllm) print(export done)4执行转换bashpython convert_deepseek_r1.py成功后会得到类似deepseek_r1_1p5b_w4a16.rkllm5转换阶段排错重点报算子不支持模型架构参数与model_type填写不一致报内存不足主机内存不够或 context 设置太高导出成功但板端崩溃通常是 runtime 版本不匹配五、板端部署把模型真正跑起来1文件拷贝到 RK3588bashscp ./output/deepseek_r1_1p5b_w4a16.rkllm rootrk3588_ip:/opt/rkllm/models/同时拷贝你当前版本对应的librkllm_runtime.so或相关 runtime 库示例推理程序C/Python2检查 NPU 与驱动状态在板端执行bashdmesg | grep -i rknpu看到正常初始化日志再继续。3先跑官方 demo极其重要不要一上来就套 WebUI先确保纯推理可用。bashcd /opt/rkllm/demo ./rkllm_demo --model /opt/rkllm/models/deepseek_r1_1p5b_w4a16.rkllm输入简单提示词测试“你好请介绍一下你自己”“用三句话解释什么是边缘计算”若能稳定输出再进入服务化阶段。六、封装 API 服务为 Web 前端提供标准入口推荐做一个轻量 APIFastAPI/Flask 均可核心思想是POST /chat传入 messages返回模型回复GET /health健康检查可选/stream做流式输出示意伪代码pythonfrom fastapi import FastAPI app FastAPI() app.get(/health) def health(): return {status: ok} app.post(/chat) def chat(req: dict): prompt req.get(prompt, ) # 调用 rkllm runtime 推理 answer infer_with_rkllm(prompt) return {answer: answer}启动bashuvicorn app:app --host 0.0.0.0 --port 8080局域网内其他设备可访问http://rk3588_ip:8080/health七、局域网 Web 浏览让同网段设备直接对话你有两种方式方式 AGradio最轻量推荐先用pythonimport gradio as gr import requests API http://127.0.0.1:8080/chat def chat_fn(text): r requests.post(API, json{prompt: text}, timeout120) return r.json()[answer] demo gr.Interface(fnchat_fn, inputstext, outputstext, titleDeepSeek R1 on RK3588) demo.launch(server_name0.0.0.0, server_port7860)启动后在局域网浏览器访问http://rk3588_ip:7860方式 BOpen WebUI功能多但更重如果板端资源紧张可把 Open WebUI 放在另一台 PC/服务器只把 API 指向 RK3588这样体验更稳。八、性能调优让 RK3588 不只是“能跑”1上下文长度别盲目拉满先 2048再看资源逐步升到 4096context 太大直接拖慢首 token 和整体吞吐2量化优先级w4a16常是速度与质量平衡点如果你只求速度可尝试更激进量化视工具链支持3线程与并发单实例先调到稳定再考虑并发RK3588 适合“低并发、稳定长跑”不适合高 QPS 压测思路4散热与电源长时间推理必须主动散热温度过高会降频体感就是“越跑越慢”九、常见坑位与排障手册坑1模型转换成功板端一加载就退出runtime 与 toolkit 版本不一致板端库文件路径没配置LD_LIBRARY_PATH坑2能回答但乱码或中文异常tokenizer 文件不匹配prompt 模板未按模型指令格式构造Instruct 模型尤其明显坑3WebUI 打得开但对话超时API 没启动或被防火墙拦截单次输入太长导致推理超时建议先限制最大输入长度和输出 token坑4局域网无法访问你把服务绑在127.0.0.1应改为0.0.0.0板端防火墙未放通 7860/8080访问设备与板卡不在同一网段十、生产化建议从 Demo 到可交付当你要把这套系统交给团队使用建议加上这几项Nginx 反代统一入口80/443API 鉴权Token/JWT日志与监控响应时延、错误率、温度模型与服务分版本管理可回滚异常自动拉起systemd/supervisor一个实用原则先让服务“持续可用”再追求“极限性能”。结语“DeepSeek R1 部署到 RK3588”真正可落地的路径不是追求一次性跑最大模型而是走一条可迭代的工程链路用 Distill 小模型打通转换与运行用 RKLLM 建立稳定的板端推理能力用 API WebUI 完成局域网可访问应用最后通过版本、监控、反代把它变成可维护系统如果你按本文步骤执行基本可以在 1~2 天内完成从“模型文件”到“局域网网页可聊天”的完整闭环。后续你要做的只是持续优化模型、提示词和业务流程而不是反复填环境坑。