企业官网建设流程全解析

RK3576 + 4GB 内存：把 DeepSeek / Qwen / MiniCPM 本地集成到 MEDAI-V1，能做什么？技术可行性全分析

核心结论先说：在 MEDAI-V1（RK3576 + 4GB LPDDR4）上，1.5B 级别的 DeepSeek-R1-Distill-Qwen / Qwen2.5 文本大模型可以稳定落地（实测 7~11 tokens/s，占用约 1GB 内存）；3B 级别处于临界可行；MiniCPM3-4B 需要牺牲其他功能；7B 与 MiniCPM-V 8B 多模态在 4GB 上基本不可行。
真正的价值不在于"跑一个聊天机器人"，而在于把大模型变成设备的自然语言控制层与事件决策层。

摘要：一张表看清可行性

性能数据来源：FriendlyELEC NanoPi-M5（RK3576）官方 RKLLM 实测；九鼎创展 RK3576 移植实测；4GB 板卡实测 7.03 tokens/s。不同系统版本、NPU 频率、散热条件会有差异。

一、约束条件：先把"天花板"量清楚

做任何端侧大模型方案，第一步不是选模型，而是把硬件瓶颈量化。MEDAI-V1 的天花板由三块决定。

1.1 来自设备技术参数的已确认指标

1.2 来自 Rockchip 官方的芯片规格

1.3 三个硬约束

约束一：内存，而且不是"内存总量"，是"可用余量"

这是最容易被低估的一点。RK3576 是统一内存架构——CPU、GPU、NPU、VPU 共用同一片物理内存，NPU 没有独立显存。这意味着：

模型权重 + 系统常驻 + 视频采集/编码缓冲 + Web 服务，全都在抢同一块 4GB。

更关键的是：MEDAI-V1 本身就是一台正在实时编码 4K60 视频的设备，VPU 与编码器会长期占用相当可观的 CMA 连续内存。所以绝不能用"4GB - 模型大小"来倒推可行性，必须把整套业务链路的常驻开销算进去。

约束二：内存带宽，大模型推理是带宽敏感型任务

32-bit LPDDR4 的带宽有限，而自回归生成（decode）阶段每生成一个 token 都要把模型权重从内存搬进 NPU 一次。这也是为什么 RK3576 与 RK3588 同为 6 TOPS，RK3588（64-bit 内存）却明显更快——差距主要来自带宽而非算力。

对 MEDAI-V1 的现实影响：NPU 上的大模型推理，会与 4K60 视频编码争抢内存带宽，需要做好抽帧频率与推理并发的取舍。

约束三：功耗与散热

整机 <30W、金属外壳 320 克、内置风扇，标称工作温度 0~70℃。端侧大模型推理是持续负载。

二、内存预算：4GB 到底能装下什么

2.1 内存分配模型

4GB 物理内存（实际可用约 3.6~3.8GB） ├── 系统常驻：Kernel + 系统服务 + Web 后台服务 ≈ 0.5~0.7GB ├── 音视频链路：VPU/CMA 缓冲 + 编码器 + 5 路输入预监 ≈ 0.6~0.9GB ├── 已有 AI 能力：person 检测 + 手势识别模型 ≈ 0.2~0.4GB ├── RKLLM Runtime + 模型权重（1.5B w4a16）≈ 1.0~1.2GB ├── KV Cache（1K~2K 上下文）≈ 0.1~0.3GB └── 剩余安全余量 ≈ 0.5~1.0GB ← 必须为正，否则 OOM

2.2 各规模模型实测内存占用（RK3576 平台）

注：7B 的数据是在 8GB 内存 + 8GB swap 条件下测得的。有 4GB 板卡实测 deepseek-r1-distill-qwen-1.5b 为 7.03 tokens/s，与 8GB 板卡的 7.49 tokens/s 差距不大——说明 1.5B 级别在 4GB 上已经能跑满，瓶颈在算力/带宽而不在内存容量。

2.3 结论：三个可用区间

三、三大模型家族适配性分析

3.1 DeepSeek —— 强在推理，适合"决策层"

可用型号：DeepSeek-R1-Distill-Qwen-1.5B（推荐）、DeepSeek-R1-Distill-Qwen-7B（4GB 不可行）

特点：

• R1 蒸馏版本把 DeepSeek-R1 的思维链推理能力蒸馏进小模型，在数学、逻辑、代码类任务上明显强于同参数量的普通 instruct 模型；
• 代价是输出带<think>思考过程，首字延迟更高、输出 token 更多，在 8~11 tokens/s 的平台上"等答案"的体感会更明显。

实测数据：

适配结论：✅推荐作为"设备决策大脑"——用于自然语言指令解析、事件研判、运维问答。但不建议让它做高频实时对话，可通过限制思考长度、关闭长思维链来提速。

工程提示：DeepSeek-R1 蒸馏版默认会输出较长思考过程。若要用于交互，建议在 system prompt 中约束输出长度，或在后处理阶段只取最终结论段落。

3.2 Qwen —— 综合最稳，适合"通用层"

可用型号：Qwen2.5-0.5B / 1.5B / 3B；RKLLM v1.2.0 起已支持 Qwen3 系列

特点：

• 中文能力强、指令跟随稳定、生态最完善，社区已有大量现成转换好的 .rkllm 文件可直接下载使用，落地成本最低；
• 1.5B 与 3B 是 RK3576 上的两个甜点位：1.5B 约 1.01GB / 11.2 tokens/s，3B 约 1.78GB / 8.2 tokens/s。

实测数据（NanoPi-M5 = RK3576）：

适配结论：✅推荐作为"通用对话主力"。若产品面向交互体验，优先 1.5B；若偏重文案质量且能接受 8 tokens/s，可上 3B 并做服务裁剪。

组合建议（最实用）：Qwen2.5-1.5B 负责高频对话与文案，DeepSeek-R1-Distill-1.5B 负责低频推理与决策。两者同为 1.5B、内存相当，可做成"快模式 / 深思模式"切换。

3.3 MiniCPM —— 多模态能力突出，但 4GB 装不下

型号与构成：

MiniCPM-V-2.6 的能力确实强（OCRBench 表现超越 GPT-4V 等专有模型，支持单图/多图/视频理解，1.8M 像素图像仅产出 640 个视觉 token），但8B 参数即使 INT4 量化也远超 4GB 内存。社区虽有 RK3576 端口，但存在已知限制：

• 视觉编码器与 LLM无法同时加载，需先卸载视觉编码器再加载 LLM，多次推理要反复装卸，非常慢；
• 同进程加载会触发段错误，需用多进程规避；
• 整个会话只能加载一张图片，不支持多图与多轮。

适配结论：❌MiniCPM-V 系列在 MEDAI-V1（4GB）上不具备工程可用性。若一定要上多模态，可行路径有两条：

1. 换平台：RK3588 + 16GB/32GB 机型承载 MiniCPM-V-2.6；
2. 拆链路（推荐）：用「轻量视觉模型（检测 / 分类 / OCR，RKNN 部署）+ 文本 LLM（RKLLM 部署）」组合，把"看懂画面"拆解成"先提取结构化信息，再由 LLM 组织语言"——内存可控、延迟可控，且工程上更稳。

3.4 横向对比与推荐

四、技术路线：怎么把模型装进去

4.1 工具链全景

Rockchip 官方提供了两套互补的工具链，对应 MEDAI-V1 上的两类 AI 任务：

版本要求：RKLLM-Toolkit v1.1.0+（多模态需 v1.1.2+，建议用最新 v1.2.x）；RKNN-Toolkit2 v2.1.0+（视觉编码器转换建议 v2.2.0+）。

4.2 文本大模型（LLM）转换流程

在PC 端（Ubuntu 20.04/22.04 + Conda）完成，不在板子上跑转换：

# 1. 准备环境conda create-nRKLLM-Toolkitpython=3.8-yconda activate RKLLM-Toolkit pipinstallnumpy==1.21.6protobuf==3.20.0 pipinstallrkllm_toolkit-1.2.x-cp38-cp38-linux_x86_64.whl --force-reinstall# 2. 获取工具链与模型gitclone https://github.com/airockchip/rknn-llmgitclone https://huggingface.co/deepseek-ai/DeepSeek-R1-Distill-Qwen-1.5B# 3. 生成量化校准数据cdrknn-llm/examples/rkllm_api_demo/export python generate_data_quant.py-m/path/to/DeepSeek-R1-Distill-Qwen-1.5B# 4. 转换为 RKLLM 格式（目标平台必须选 rk3576）python export_rkllm.py\--model_path/path/to/DeepSeek-R1-Distill-Qwen-1.5B\--target_platformrk3576\--quantized_dtypew4a16\--quantized_algorithmgrq\--num_npu_core2\--max_context2048

板端部署与验证：

# 设置 NPU 频率为性能模式cdrknn-llm/scripts&&./fix_freq_rk3576.sh# 运行推理（taskset 绑定大核，避免小核拖慢）exportLD_LIBRARY_PATH=/path/to/rkllm-runtime/Linux/librkllm_api/aarch64:$LD_LIBRARY_PATHexportRKLLM_LOG_LEVEL=1# 打印性能与内存占用，务必开启用于调优taskset f0 ./llm_demo DeepSeek-R1-Distill-Qwen-1.5B_W4A16_RK3576.rkllm20484096

关键提醒 1：--target_platform必须与实际芯片严格一致。为 RK3588 转换的模型不能在 RK3576 上运行，反之亦然。

关键提醒 2：量化精度选择上，优先 w4a16（尤其是带 group 的 w4a16_g128）而非 w8a8。社区实测 w8a8 量化存在明显的精度损失，而 w4a16 在体积与精度之间平衡更好。

关键提醒 3：RKLLM_LOG_LEVEL=1会输出每次推理的内存占用与耗时，是 4GB 平台上调参的必备手段。

4.3 多模态（VLM）转换流程

多模态模型需要两份产物：视觉编码器.rknn+ 语言模型.rkllm。

┌─────────────────┐ │ MiniCPM-V-2.6 │ │ (HF 原始模型) │ └────────┬────────┘ │ 拆分 ┌────┴─────┐ ▼ ▼ 视觉编码器 语言模型(Qwen2-7B) │ │ │ ONNX 导出 │ RKLLM 转换 ▼ ▼ vision_encoder qwen.rkllm .onnx (w4a16) │ │ RKNN-Toolkit2 ▼ vision_encoder.rknn │ └──────┬───────┘ ▼ RKLLM Runtime（多模态输入） RKLLM_INPUT_MULTIMODAL prompt + image_embed

推理侧用 embedding 方式把视觉特征喂给 LLM：

# 视觉编码器出图嵌入image_embeddings=vision_encoder.inference(inputs=[img.astype(np.float32)],data_type="float32",data_format="nhwc")[0]# 构造多模态输入rkllm_input=create_rkllm_input(RKLLMInputType.RKLLM_INPUT_MULTIMODAL,prompt=prompt,image_embed=image_embeddings.astype(np.float32))

为什么 MiniCPM-V 在 4GB 上不可行：视觉编码器（SigLIP-400M，约 0.4GB）+ 语言模型（Qwen2-7B，INT4 约 3.5~4GB）必须同时驻留内存，总计超过 4GB。社区的解决办法是"分时加载"——先跑视觉编码器拿到 embedding 再卸载、然后加载 LLM——每次推理都要装卸一遍，延迟从毫秒级劣化到秒级甚至十秒级，且无法多轮对话。

4.4 系统集成架构

┌──────────────────────────────────────────────────────────────┐ │ Web 后台（现有管理系统） │ │ 智能引擎 / 智能配置 / 智能切换 / 系统状态 │ └───────────────────────┬────────────────────────────────────┘ │ WebSocket / HTTP API ┌───────────────────────▼────────────────────────────────────┐ │ AI 编排层（新增） │ │ 意图识别 → Function Calling → 设备 API → 结果回填 │ │ · 事件总线（检测结果 / 手势事件 / 系统告警） │ │ · 上下文与记忆管理（控制 token 长度） │ └──────┬──────────────────────────────┬──────────────────────┘ │ │ ┌──────▼───────────┐ ┌───────▼──────────┐ │ RKLLM Runtime │ │ RKNN Runtime │ │ · Qwen2.5-1.5B │ │ · person 检测 │ │ · DeepSeek-R1- │ │ · 手势识别 │ │ Distill-1.5B │ │ · OCR / 分类 │ │ （对话 / 决策） │ │ （感知） │ └──────┬───────────┘ └───────┬──────────┘ │ │ └───────────┬───────────────────┘ ▼ RK3576 NPU（6 TOPS，双核） · core0：常驻视觉模型（高频、低延迟） · core1：按需加载 LLM（低频、容忍延迟） │ ┌───────────┴───────────┐ ▼ ▼ VPU / 编码器 系统内存 （4K60 硬编码） （32-bit LPDDR4 4GB）

架构要点：

1. 音视频编码走 VPU 硬编码，不占 NPU——这是 MEDAI-V1 最大的优势，编码链路与 AI 推理在硬件上是解耦的；
2. NPU 双核分工：高频视觉任务（检测/手势）固定在 core0 常驻，LLM 按需在 core1 加载，避免互相挤占；
3. 编排层是价值核心：大模型不直接"看视频"，而是消费视觉模型输出的结构化事件，再决定"切哪个源、要不要开播、怎么告警"；
4. 接口复用现有后台：推理结果通过 WebSocket 推送即可复用到已有的「智能引擎」页面，前端改动小。

4.5 关键优化手段

五、能实现哪些功能：分四档看

🟢 Tier A：文本智能（立即可行，风险低）

A2 是最值得做的：设备后台的参数本来就多（编码、GOP、帧率、5 路推流、NDI、绿幕、叠加模式……），用户要翻很多层菜单。用自然语言直接说：

“把分辨率设成 1080P、码率高清、开启第 1 路和第 2 路推流，再打开绿幕”

由 LLM 解析成一组 API 调用，可以大幅降低使用门槛——这是端侧大模型在设备上最有说服力的落地形态，而且不依赖云端、现场断网也能用。

🟡 Tier B：视觉智能（可行，需额外模型）

🟠 Tier C：多模态理解（受限，需取舍）

这里有个重要认知：很多看起来需要多模态大模型的任务，用"轻量视觉模型 + 文本 LLM"就能做到 80 分，而且成本只有 1/10。真正的开放式视觉问答才需要 8B 级 VLM，那是 RK3588/16GB 的活。

拆解思路：视觉模型负责"看见"（输出结构化标签：几个人、什么物体、什么动作、OCR 文字），LLM 负责"说话"（把标签组织成自然语言）。各司其职，内存可控。

🔴 Tier D：明确不可行（诚实说明）

六、风险与边界

特别强调"误操作风险"：当大模型拿到设备控制能力后，一次误解析就可能把正在直播的推流关掉或改掉网络配置。工程上必须做到：高权限操作二次确认 + 可回滚 + 操作日志审计，不能让 LLM 无约束地直接调用所有 API。

七、落地路线图

Phase 0 打通跑通（1~2 周）

• PC 端搭建 RKLLM-Toolkit 环境（Ubuntu + Conda + Python 3.8）
• 下载 Qwen2.5-1.5B-Instruct 与 DeepSeek-R1-Distill-Qwen-1.5B
• 完成 w4a16 / w4a16_g128 量化转换，产出.rkllm
• 板端librkllmrt.so+llm_demo跑通
• 验收：板端实测生成速度 ≥7 tokens/s，内存占用 ≤1.2GB

Phase 1 接入后台（2~3 周）

• 封装推理服务（常驻进程 + 本地 HTTP/WebSocket 接口）
• 现有「智能引擎」页面对接流式输出
• 加入 NPU 提频、CPU 绑核、并发排队
• 验收：Web 页面可正常多轮对话，响应稳定无 OOM

Phase 2 能力升级（3~6 周）

• Function Calling：自然语言配置设备（最高价值功能）
• 接入本地 ASR / TTS，实现语音交互
• 视觉标签化 → LLM 生成直播摘要与事件描述
• 验收：语音/文本指令可正确驱动设备配置，关键操作有二次确认

Phase 3 稳定性与量产（6 周+）

• 72 小时满负载压力测试（编码 + 推理并发）
• 高低温测试、散热方案定型
• zram / 内存水位监控与自动降级策略
• 模型预置到 eMMC，支持 OTA 更新
• 验收：连续运行无重启、无内存泄漏、温度在阈值内

八、最终推荐配置

一句话总结选型：

MEDAI-V1 的端侧 AI 定位应该是"轻量感知 + 语言交互 + 辅助决策"，而不是"端侧通用大模型"。把 1.5B 级模型用在自然语言控制、智能导播决策、事件摘要上，体验与价值最高；一旦想上 7B 或多模态，就应该考虑 RK3588 / 16GB 以上的平台，而不是在 4GB 上硬塞。

九、FAQ

Q1：4GB 内存跑 1.5B 模型，和 8GB 板子差多少？
不大。实测 4GB 板 7.03 tokens/s、8GB 板 7.49 tokens/s，差距在个位数百分比——说明 1.5B 级别的瓶颈是算力/带宽而非内存容量，4GB 完全够用。

Q2：能不能两个模型同时加载（一个对话、一个决策）？
内存上可以（各 1GB），但 NPU 带宽会被分摊，速度下降明显。建议二选一常驻 + 按需切换，或用双核把视觉模型与 LLM 分开。

Q3：7B 模型加 swap 能不能凑合用？
实测 8GB swap 下约 1.89 tokens/s，且延迟抖动极大，不具备交互可用性。不推荐。

Q4：MiniCPM-V 真的完全不能用吗？
完整版不行（8B）。但它的思路可以用——把视觉编码器换成轻量 CNN/CLIP，语言模型换成 1.5B，就是 MEDAI-V1 上更现实的多模态方案。

Q5：模型文件放哪里？eMMC 32GB 够吗？
够。1.5B w4a16 模型文件约 1~2GB，放在 eMMC 即可；录制视频走 TF 卡 / U 盘，互不干扰。

Q6：跑大模型会不会影响 4K60 编码？
编码走 VPU 硬编码，不占 NPU 算力，但会争抢内存带宽。做好抽帧降频与错峰调度，影响可控；极端场景可临时降编码档位。

Q7：能不能在设备上微调模型？
不能。4GB 内存、无独立显存，训练/微调不可行。正确做法是PC 端微调完成后再转换部署。

结语

RK3576 + 4GB 的组合，在端侧大模型这件事上有一个非常清晰的甜蜜点：1.5B 级模型、w4a16 量化、2K 上下文、内存占用约 1GB、生成速度约 8~12 tokens/s。

对 MEDAI-V1 而言，最有价值的落地方向不是再造一个聊天窗口，而是三件事：

1. 自然语言即配置——用说话代替翻菜单；
2. 事件驱动的智能导播——让设备自己判断何时切源、何时开播、何时告警；
3. 视觉 + 语言的组合能力——轻量视觉模型"看见"，文本 LLM"表达"，以极低成本逼近多模态效果。

守住 4GB 的内存边界，把大模型放在"决策层"而不是"感知层"，是在这台设备上做端侧 AI 最稳妥、也最专业的选择。

MEDAI-V1 端侧大模型集成可行性分析 V1.0
性能数据来源：Rockchip 官方规格、FriendlyELEC NanoPi-M5 实测、厂商 RK3576 移植实测