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

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

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

 RK3576 多模态纯文字：自我介绍

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

 RK3576 多轮对话：基于历史回答图中女孩头发和衣服分别是什么颜色

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

RK3576 工作状态

本文目录

一、引言

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++实现，采用单线程事件循环机制，承担着对话流程的统筹调度工作，具体职责包括：

• 多轮对话的 KV-Cache 维护与手动清除；

• Prompt 模板的动态渲染；

• 用户输入的解析处理与推理结果的回显展示。

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

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

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

1. 模型初始化

   
   

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

 RK3576 平台运行多模态对话 Demo 的终端日志，显示视觉与语言模型成功加载，包含模型版本、硬件配置及张量信息，完成多模态交互前的初始化。

2. 图片处理与特征提取

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

3. 多轮交互机制

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

• 上下文记忆

• 通过设置rkllm_infer_params.keep_history = 1，开启上下文记忆功能，KV-Cache 在显存中持续追加存储，每轮对话仅计算新增 token，大幅提升推理效率。使模型能关联多轮对话内容；

• 若设为 0，则每轮对话独立，不保留历史信息，详见src/main.cpp。

• 历史缓存清空：当用户输入“clear”时，系统调用rkllm_clear_kv_cache(llmHandle, 1, nullptr, nullptr)，清空模型的 KV 缓存，重置对话上下文。

• Prompt 工程：动态定义模型“人设”：采用三段式 Prompt 模板，通过rkllm_set_chat_template()动态注入模型，无需重新训练即可切换人设，支持中英文双语系统提示。

模板示例如下：

You are a helpful assistant.

{用户输入}

4. 推理与输出

用户输入后，系统先判断输入中是否包含

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 个核心参数，分别对应：

• image_path：输入图片路径

• encoder_model_path：视觉编码模型路径

• llm_model_path：大语言模型路径

• max_new_tokens：每轮生成的最大 token 数（控制回答长度，避免溢出）

• max_context_len：最大上下文长度（限制历史对话+当前输入总长度，防止显存占用过高）

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

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

 测试图片2：图片背景是赛博风格

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

1. 这张图片上有哪些文字信息

2. 图中电路板上的字是什么颜色

3. 图中女孩头发和衣服分别是什么颜色

4. 图中动漫角色看起来多大年龄

5. 图中背景颜色和女孩眼睛颜色一样嘛

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

 rkllm 模型加载 6.7 秒 视觉编码 rknn 模型进行处理，生成图片的 embedding 向量，完成图像特征的提取，4.5 秒

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

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

 感受一下第一次出词的耗时

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

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

 第二次回答就非常快，有一个很短暂的等待时间

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

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

 多轮对话3：图中女孩头发和衣服分别是什么颜色，问题基本回答正确，速度和正常阅读速度差不多 多轮对话3：图中女孩头发和衣服分别是什么颜色

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

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

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

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

 记不住了，因为我们设置的rkllm_infer_params.keep_history = 1

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

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

下面是测试过程中的演示完整视频：

，时长01:27

四、二次开发与拓展方向

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

1. 替换视觉骨干：修改image_enc.cc文件，将输入分辨率调整为与模型匹配的大小，原因是这些参数与模型的固有结构设计和输入处理逻辑强绑定，直接影响特征提取的正确性和数据传递的一致性。不同的 Qwen2-VL 模型（2B 和 7B）需要代码中指定IMAGE_HEIGHT、IMAGE_WIDTH及EMBED_SIZE；

   
   

2. 微调 LLM 模型：借助 RKLLM 工具链的 LoRA-INT4 量化支持，在 24 GB 显存的 PC 上，30 分钟内可完成 2 亿参数模型的增量训练；

3. 接入语音能力：在main.cpp中集成 VAD（语音活动检测）+ ASR（语音识别，如 Whisper-Tiny INT8）模块，将语音转换为文本后接入现有推理流水线，实现“看图说话+语音问答”的融合交互。

五、结论与未来发展方向

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

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

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

• 其一，算力效率再突破—— 通过异步模型加载、NPU 与 CPU 协同调度，进一步压缩首轮推理延迟，适配对响应速度敏感的车载、医疗等场景；

• 其二，多模态融合再升级—— 在图文基础上集成语音、传感器数据，实现 “看 + 听 + 感知” 的跨模态对话；

• 其三，生态适配再拓展—— 支持更多开源多模态模型的快速移植，形成 “芯片 - 工具链 - 模型” 的协同生态。

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