http://www.gkong.com 2025-09-04 13:37 来源:米尔电子
当 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 端侧部署步骤
三、效果展示:图文多轮问答
四、二次开发与拓展方向
五、结论与未来发展方向
多轮对话(Multi-Turn Dialogue)是指用户与智能系统通过多轮交互逐步明确需求、解决问题的对话形式。这种交互依赖对话历史的上下文连贯性,要求系统能够动态理解用户意图、维护对话状态并生成符合语境的回应。
本质是动态语境下的交互推理,其核心在于通过多轮信息交换逐步明确用户需求。例如,用户可能先询问 “附近有餐厅吗?”,系统回应后用户补充 “要适合家庭聚餐的”,系统需结合历史对话调整推荐策略。
这种交互模式与单轮问答的区别在于:
RK3576 多模态交互对话方案基于 RKLLM 的核心运作,依赖于图像视觉编码器、大语言模型与对话管家这三大模块的协同配合,三者各司其职、无缝衔接,共同构建起完整的多模态对话能力。
多轮对话系统架构
基于纯 C++实现,采用单线程事件循环机制,承担着对话流程的统筹调度工作,具体职责包括:
该方案的多模态多轮对话 demo,整体遵循“模型加载 → 图片预处理 → 用户交互 → 推理输出”的核心流程,支持图文一体的多模态对话,适配多轮问答、视觉问答等典型场景。
具体运行机制可拆解为以下步骤:
首先加载大语言模型(LLM),并配置模型路径、max_new_tokens(生成内容最大 token 数)、max_context_len(最大上下文长度)、top_k、特殊 token 等关键参数;随后加载视觉编码模型(imgenc),为后续图片处理做好准备。
RK3576 平台运行多模态对话 Demo 的终端日志,显示视觉与语言模型成功加载,包含模型版本、硬件配置及张量信息,完成多模态交互前的初始化。
读取输入图片后,先将其扩展为正方形并填充背景色以统一尺寸,再调整至模型要求的 392x392 分辨率,最后送入视觉编码模型进行处理,生成图片的 embedding 向量,完成图像特征的提取。
程序会提供预设问题供用户选择(官方案例中也有输入序号,可以快速提问),同时支持用户自定义输入,核心交互逻辑通过以下机制实现:
模板示例如下:
<|im_start|>system
You are a helpful assistant.<|im_end|>
<|im_start|>user
{用户输入}<|im_end|>
<|im_start|>assistant
用户输入后,系统先判断输入中是否包含<image>标签:若包含,则将文本与图片 embedding 结合,启动多模态推理;若不包含,则进行纯文本推理。组装输入结构体并传递给模型后,推理结果将实时打印输出。
支持用户输入“exit”退出程序,此时系统会自动销毁已加载的模型,并释放占用的硬件资源,确保运行环境的整洁。
由于先前我们已经讲过环境的部署,如刷机、文件准备等,这里步骤只提出比较关键的。工程位于:rknn-llm/examples/Multimodal_Interactive_Dialogue_Demo,下面我们来逐步看下操作步骤。
方案的编译与运行需满足以下依赖条件
针对不同操作系统提供便捷的编译脚本,我们是 Linux 系统执行./build-linux.sh,编译结果如下:
产物目录为:
install/demo_Linux_aarch64/
├─ demo # 主程序可执行文件
└─ lib # 依赖动态库
通过 U 盘或者手机将编译好的产物文件、模型、图片上传到开发板上,然后在多轮对话的实例的目录下,执行以下命令:
cd /data/demo_Linux_aarch64
export LD_LIBRARY_PATH=./lib
./demo demo.jpg vision.rknn llm.rkllm 128 512
其中,部署命令需传入 5 个核心参数,分别对应:
以下面这张图片作为测试图片,选择下面这张图是因为,有人物、文字、物体、背景等。
测试图片2:图片背景是赛博风格
我们依次准备的问题如下:
每轮对话我都有截动态图,可以感受下体感速度。
rkllm 模型加载 6.7 秒
视觉编码 rknn 模型进行处理,生成图片的 embedding 向量,完成图像特征的提取,4.5 秒
可以明显感受到这两个过程是串行的,如果异步处理可以更快。
感受一下第一次出词的耗时
多轮对话1:这张图片上有哪些文字信息
第二次回答就非常快,有一个很短暂的等待时间
多轮对话2:图中电路板上的字是什么颜色
多轮对话3:图中女孩头发和衣服分别是什么颜色,问题基本回答正确,速度和正常阅读速度差不多
多轮对话3:图中女孩头发和衣服分别是什么颜色
多轮对话4:图中动漫角色看起来多大年龄
多轮对话4:图中动漫角色看起来多大年龄
记不住了,因为我们设置的rkllm_infer_params.keep_history = 1
代码中keep_history = 1是开启上下文记忆功能,即模型应记住前序对话中的关键信息,如 “女孩眼睛颜色”“背景颜色”,而 “记不住” 是记忆功能未生效的表现,原因可能除了超过历史上下文预设的阈值,有时还有可能是因为上下文长度超限(max_context_len=512),或者KV-Cache 清理机制误触发等。
多轮对话5:图中背景颜色和女孩眼睛颜色一样嘛
方案具备良好的可扩展性,便于开发者根据需求进行二次开发:
如果说 “大模型上云” 是 AI 的 “星辰大海”,那么 “多模态落地端侧” 就是 AI 的 “柴米油盐”—— 后者决定了智能技术能否真正渗透到智能家居、工业质检、穿戴设备等千万级场景中。RK3576 的多模态交互对话方案,其价值远不止 “实现了一项技术”,更在于提供了一套 “算力适配 - 工程封装 - 二次拓展” 的端侧 AI 落地范式。
从技术内核看,它通过 “视觉编码器 + LLM + 对话管家” 的模块化设计,平衡了推理性能与开发灵活性:W4A16 量化方案让 30 亿参数模型适配 6 TOPS 算力,KV-Cache 动态维护实现多轮对话效率跃升,单线程事件循环降低了资源占用 —— 这些细节不是技术炫技,而是直击端侧 “算力有限、场景碎片化” 的痛点。从工程落地看,一键编译脚本、清晰的参数配置、可复现的部署流程,让开发者无需深耕底层优化即可快速验证场景,大幅缩短了从技术原型到产品的周期。
展望未来,这套方案的演进将围绕三个方向深化:
当 RK3576 证明 “端侧能跑好转好多模态对话” 时,边缘 AI 的竞争已从 “能否实现” 转向 “如何更优”。而这套方案的真正意义,在于为行业提供了一块 “可复用的基石”—— 让更多开发者无需重复造轮子,只需聚焦场景创新,就能让 “离线智能” 从实验室走向量产货架,最终让 “AI 就在身边” 成为无需网络支撑的常态。