6TOPS算力驱动30亿参数LLM，米尔RK3576部署端侧多模态多轮对话

关键词：瑞芯微 RK3576、NPU（神经网络处理器）、端侧小语言模型（SLM）、多模态 LLM、边缘 AI 部署、开发板

当 GPT-4o 用毫秒级响应处理图文混合指令、Gemini-1.5-Pro 以百万 token 上下文 “消化” 长文档时，行业的目光正从云端算力竞赛转向一个更实际的命题：如何让智能 “落地”？—— 摆脱网络依赖、保护本地隐私、控制硬件成本，让设备真正具备 “看见并对话” 的离线智能，成为边缘 AI 突破的核心卡点。

2024 年，随着边缘 SoC 算力正式迈入 6 TOPS 门槛，瑞芯微 RK3576 给出了首个可量产的答案：一套完整的多模态交互对话解决方案。

如今，“端侧能否独立运行图文多轮对话” 已不再是技术疑问，而是工程实现问题。RK3576 通过硬件算力优化与软件栈协同，将视觉编码、语言推理、对话管理三大核心能力封装为可落地的工程方案，而本文将聚焦其多轮对话的部署全流程，拆解从模型加载到交互推理的每一个关键环节。

上一次我们详细讲解在RK3576上部署多模态模型的案例，这次将继续讲解多轮对话的部署流程。整体流程基于 rknn-llm 里的多轮对话案例^[1]。

本文目录

• 本文目录
• 一、引言
• 1.1 什么是多轮对话？
• 1.2 多轮对话系统鸟瞰：三颗“核心”协同驱动
• 1.3 核心逻辑：多轮对话的处理流程
• 二、工程化落地：从源码到部署的全流程
• 2.1 依赖环境
• 2.2 一键编译
• 2.3 端侧部署步骤
• 三、效果展示：图文多轮问答
• 四、二次开发与拓展方向
• 五、结论与未来发展方向

一、引言

1.1 什么是多轮对话？

多轮对话（Multi-Turn Dialogue）是指用户与智能系统通过多轮交互逐步明确需求、解决问题的对话形式。这种交互依赖对话历史的上下文连贯性，要求系统能够动态理解用户意图、维护对话状态并生成符合语境的回应。

本质是动态语境下的交互推理，其核心在于通过多轮信息交换逐步明确用户需求。例如，用户可能先询问 “附近有餐厅吗？”，系统回应后用户补充 “要适合家庭聚餐的”，系统需结合历史对话调整推荐策略。

这种交互模式与单轮问答的区别在于：

1.2 多轮对话系统鸟瞰：三颗“核心”协同驱动

RK3576 多模态交互对话方案基于 RKLLM 的核心运作，依赖于图像视觉编码器、大语言模型与对话管家这三大模块的协同配合，三者各司其职、无缝衔接，共同构建起完整的多模态对话能力。

1. 图像视觉编码器（Vision Encoder）

• 模型选择：采用 qwen2_5_vl_3b_vision_rk3576.rknn 模型（本文）。
• 核心作用：将输入图像压缩为视觉 token 如 256 个视觉 token，直接输入至大语言模型中，实现图像信息向语言模型可理解格式的转换。

2. 大语言模型（LLM Core）

• 模型选择：搭载 qwen2.5-vl-3b-w4a16_level1_rk3576.rkllm 模型，采用 W4A16 量化方案（本文）。
• 模型规模：参数规模达 30 亿，KV-Cache，为对话推理提供核心的语言理解与生成能力。

3. 对话管家（Dialogue Manager）

基于纯 C++实现，采用单线程事件循环机制，承担着对话流程的统筹调度工作，具体职责包括：

1.3 核心逻辑：多轮对话的处理流程

该方案的多模态多轮对话 demo，整体遵循“模型加载 → 图片预处理 → 用户交互 → 推理输出”的核心流程，支持图文一体的多模态对话，适配多轮问答、视觉问答等典型场景。

具体运行机制可拆解为以下步骤：

1. 模型初始化

首先加载大语言模型（LLM），并配置模型路径、max_new_tokens（生成内容最大 token 数）、max_context_len（最大上下文长度）、top_k、特殊 token 等关键参数；随后加载视觉编码模型（imgenc），为后续图片处理做好准备。

2. 图片处理与特征提取

读取输入图片后，先将其扩展为正方形并填充背景色以统一尺寸，再调整至模型要求的 392x392 分辨率，最后送入视觉编码模型进行处理，生成图片的 embedding 向量，完成图像特征的提取。

3. 多轮交互机制

程序会提供预设问题供用户选择（官方案例中也有输入序号，可以快速提问），同时支持用户自定义输入，核心交互逻辑通过以下机制实现：

模板示例如下：

<|im_start|>system
You are a helpful assistant.<|im_end|>
<|im_start|>user
{用户输入}<|im_end|>
<|im_start|>assistant

4. 推理与输出

用户输入后，系统先判断输入中是否包含<image>标签：若包含，则将文本与图片 embedding 结合，启动多模态推理；若不包含，则进行纯文本推理。组装输入结构体并传递给模型后，推理结果将实时打印输出。

5. 退出与资源释放

支持用户输入“exit”退出程序，此时系统会自动销毁已加载的模型，并释放占用的硬件资源，确保运行环境的整洁。

二、工程化落地：从源码到部署的全流程

由于先前我们已经讲过环境的部署，如刷机、文件准备等，这里步骤只提出比较关键的。工程位于：rknn-llm/examples/Multimodal_Interactive_Dialogue_Demo，下面我们来逐步看下操作步骤。

2.1 依赖环境

方案的编译与运行需满足以下依赖条件

• 图像处理：OpenCV ≥ 4.5
• 视觉模型运行：RKNNRT ≥ 1.6
• 语言模型运行：RKLLMRT ≥ 0.9

2.2 一键编译

针对不同操作系统提供便捷的编译脚本，我们是 Linux 系统执行./build-linux.sh，编译结果如下：

产物目录为：

install/demo_Linux_aarch64/
├─ demo        # 主程序可执行文件
└─ lib         # 依赖动态库

2.3 端侧部署步骤

通过 U 盘或者手机将编译好的产物文件、模型、图片上传到开发板上，然后在多轮对话的实例的目录下，执行以下命令：

cd /data/demo_Linux_aarch64
export LD_LIBRARY_PATH=./lib
./demo demo.jpg vision.rknn llm.rkllm 128 512

其中，部署命令需传入 5 个核心参数，分别对应：

三、效果展示：图文多轮问答

以下面这张图片作为测试图片，选择下面这张图是因为，有人物、文字、物体、背景等。

我们依次准备的问题如下：

每轮对话我都有截动态图，可以感受下体感速度。

可以明显感受到这两个过程是串行的，如果异步处理可以更快。

多轮对话1：这张图片上有哪些文字信息

多轮对话2：图中电路板上的字是什么颜色

多轮对话3：图中女孩头发和衣服分别是什么颜色

多轮对话4：图中动漫角色看起来多大年龄

多轮对话5：图中背景颜色和女孩眼睛颜色一样嘛

代码中keep_history = 1是开启上下文记忆功能，即模型应记住前序对话中的关键信息，如 “女孩眼睛颜色”“背景颜色”，而 “记不住” 是记忆功能未生效的表现，原因可能除了超过历史上下文预设的阈值，有时还有可能是因为上下文长度超限（max_context_len=512），或者KV-Cache 清理机制误触发等。

四、二次开发与拓展方向

方案具备良好的可扩展性，便于开发者根据需求进行二次开发：

五、结论与未来发展方向

如果说 “大模型上云” 是 AI 的 “星辰大海”，那么 “多模态落地端侧” 就是 AI 的 “柴米油盐”—— 后者决定了智能技术能否真正渗透到智能家居、工业质检、穿戴设备等千万级场景中。RK3576 的多模态交互对话方案，其价值远不止 “实现了一项技术”，更在于提供了一套 “算力适配 - 工程封装 - 二次拓展” 的端侧 AI 落地范式。

从技术内核看，它通过 “视觉编码器 + LLM + 对话管家” 的模块化设计，平衡了推理性能与开发灵活性：W4A16 量化方案让 30 亿参数模型适配 6 TOPS 算力，KV-Cache 动态维护实现多轮对话效率跃升，单线程事件循环降低了资源占用 —— 这些细节不是技术炫技，而是直击端侧 “算力有限、场景碎片化” 的痛点。从工程落地看，一键编译脚本、清晰的参数配置、可复现的部署流程，让开发者无需深耕底层优化即可快速验证场景，大幅缩短了从技术原型到产品的周期。

展望未来，这套方案的演进将围绕三个方向深化：

当 RK3576 证明 “端侧能跑好转好多模态对话” 时，边缘 AI 的竞争已从 “能否实现” 转向 “如何更优”。而这套方案的真正意义，在于为行业提供了一块 “可复用的基石”—— 让更多开发者无需重复造轮子，只需聚焦场景创新，就能让 “离线智能” 从实验室走向量产货架，最终让 “AI 就在身边” 成为无需网络支撑的常态。

参考资料