算法系统协同优化,vivo与港中文推出BlueLM-V-3B,手机秒变AI专家

B站影视 2024-11-29 15:40 1

摘要:AIxiv专栏是机器之心发布学术、技术内容的栏目。过去数年,机器之心AIxiv专栏接收报道了2000多篇内容,覆盖全球各大高校与企业的顶级实验室,有效促进了学术交流与传播。如果您有优秀的工作想要分享,欢迎投稿或者联系报道。投稿邮箱:liyazhou@jiqiz

AIxiv专栏是机器之心发布学术、技术内容的栏目。过去数年,机器之心AIxiv专栏接收报道了2000多篇内容,覆盖全球各大高校与企业的顶级实验室,有效促进了学术交流与传播。如果您有优秀的工作想要分享,欢迎投稿或者联系报道。投稿邮箱:liyazhou@jiqizhixin.com;zhaoyunfeng@jiqizhixin.com

BlueLM-V-3B 是一款由 vivo AI 研究院与香港中文大学联合研发的端侧多模态模型。该模型现已完成对天玑 9300 和 9400 芯片的初步适配,未来将逐步推出手机端应用,为用户带来更智能、更便捷的体验。

近年来,多模态大语言模型(MLLM)的迅猛发展,为我们的日常生活带来了无限可能。手机作为我们形影不离的「智能伴侣」,无疑是 MLLM 最理想的落地平台。它能够将强大的 AI 能力,无缝融入我们的日常任务,让科技真正服务于生活。

然而,要将 MLLM 部署到手机上,并非易事。内存大小和计算能力的限制,就像两座大山,横亘在 MLLM 与手机之间。未经优化的模型,难以在手机上实现流畅、实时的处理,更遑论为用户带来良好的体验。

论文地址:https://arxiv.org/abs/2411.10640

为了攻克这一难题,vivo AI 全球研究院和香港中文大学多媒体实验室共同推出了 BlueLM-V-3B。这是一款专为移动平台量身打造的 MLLM,采用了算法与系统协同设计的创新理念,重新设计了主流 MLLM 的动态分辨率方案,并针对手机硬件特性进行了深度系统优化,从而实现了在手机上高效、流畅地运行 MLLM。

BlueLM-V-3B 具有以下几个显著特点:

算法与系统协同优化

研究团队分析了经典 MLLM 使用的动态分辨率方案,发现了图像过度放大的问题,并提出了针对性的解决方案。

此外,他们还针对硬件感知部署进行了一系列系统设计和优化,使 MLLM 在移动设备上能够更高效地进行推理,充分发挥硬件潜力。

卓越的模型性能

BlueLM-V-3B 在性能上表现出色,在参数规模相似的模型中达到了 SOTA 水平(例如,在 OpenCompass 基准测试中取得了 66.1 的高分)。

更令人惊喜的是,BlueLM-V-3B 甚至超越了一系列参数规模更大的 MLLM(例如,MiniCPM-V-2.6、InternVL2-8B),展现了其强大的实力。

高效的移动端部署

BlueLM-V-3B 在移动端部署方面同样表现优异。以联发科天玑 9300 处理器为例,其内存需求仅为 2.2GB,能够在约 2.1 秒内完成对 768×1536 分辨率图像的编码,并实现 24.4token/s 的 token 输出速度。

这意味着,用户可以在手机上享受到流畅、高效的 MLLM 体验,而无需担心算力瓶颈。

BlueLM-V-3B 设计思路

模型主体结构

BlueLM-V-3B 延续了传统的 LLaVA 架构,包括视觉编码器 SigLIP-400M,MLP 线性映射层,以及大语言模型 BlueLM-3B。

为了更好地处理高分辨率图片,和主流 MLLM 一样,BlueLM-V-3B 采用了动态分辨率方案,并针对 InternVL 1.5 和 LLaVA-NeXT 中存在的图像过度放大问题进行了改进。

此外,为了应对手机 NPU 在处理长输入 token 时的性能限制,BlueLM-V-3B 还引入了 token 降采样的方案,以确保模型在移动设备上的顺利部署。

动态分辨率

算法改进:

为了提升多模态模型应对高分辨率图片的能力,主流的 MLLM 往往采用动态分辨率的方案进行图片的放缩和裁切。该团队发现主流动态分辨率方案,如 LLaVA-NeXT 和 INTernVL 1.5 往往伴随图片过度放大。

传统的动态分辨率方案往往会选择一个分辨率(如 384x384)作为基准尺寸,并选择合适的长宽比对图像进行缩放。

对于 LLaVA-NeXT,给定一个分辨率为 394×390 的图像,它会选择 2:2 的图片比例,然后将原始图像调整并填充至 768×768(放大 4 倍)。

对于 InternVL1.5,给定一个分辨率为 380×76 的图像,它会选择 5:1 的比例,直接将原始图像调整至 1920×384(放大 25 倍)。

这种放大并不一定丰富了图像信息,但会导致更多的图像切块,从而增加图像 token 的数量,增加移动设备上的部署难度。

鉴于此,BlueLM-V-3B 基于 LLaVA-NeXT 设计了一种宽松的长宽比选择算法,综合考虑了放缩后图片的有效信息分辨率以及浪费的空间,有效提高了图片信息的利用率,减少了部署时的图片 token 长度,降低图片的处理延时。

硬件感知的系统设计

图像并行编码:经过动态分辨率处理后,图像被分为多个局部切块以及一张全局缩略图切块。为了加速部署推理,BlueLM-V-3B 采用并行策略来利用 NPU 的计算能力。

与高级语言(例如 Python)不同,硬件加速设计需要对计算资源进行底层控制,例如内存布局和基于寄存器大小的计算优化。

由于 NPU 的计算能力有限,所有图片切块无法同时有效处理;相反,BlueLM-V-3B 一次处理固定数量的切块,以获得并行处理和硬件性能的平衡。

流水线并行处理:在模型推理过程中,BlueLM-V-3B 实现了流水线并行方案,以优化图像切块的编码效率。

具体而言,对于从单个图像中提取的不同切块,BlueLM-V-3B 为 SigLIP 视觉嵌入模块的 Conv2D 层和 ViT 层设计了流水线并行方案。这种方法有效地隐藏了 Conv2D 操作的执行延迟,提升了整体处理速度。

Token 降采样

基础算法:

虽然 BlueLM-V-3B 设计了一种宽松的长宽比选择算法来降低部署过程中图片 token 的数量,但动态分辨率带来的图片 token 数量依然很多。

为此,BlueLM-V-3B 采用了 VILA 提出的 token 数量下采样方案,将每 2×2 个图像 token 合并为一个 token,并采用一个线性层做信息融合,降低了部署难度。

系统设计:

分块计算输入 token:在 LLM 推理过程中,传统 GPU 通过并行计算技术同时处理所有输入 token 以加速计算。然而,由于图像 token 长度较长、上下文信息复杂以及 NPU 计算能力有限,导致并行处理效率低下。逐个 token 的顺序处理也不是最佳选择。

因此,BlueLM-V-3B 在移动设备上采用了分块策略,每次迭代并行处理 128 个输入 token(t128),然后合并结果,以在并行处理与 NPU 计算资源之间实现平衡。

模型量化和总体推理框架

模型量化:

混合参数精度:BlueLM-V-3B 通过混合精度量化降低内存使用并提升推理速度。权重方面,SigLIP 和 MLP 线性映射层采用 INT8 精度,LLM 则使用 INT4 精度,平衡了计算效率与模型精度。

由于激活值对量化更敏感,LLM 的激活使用 INT16 精度,SigLIP 及映射层的激活则使用 FP16,以确保模型性能。推理过程中,KV 缓存采用 INT8 精度存储。

解耦图像编码与指令处理:

为了提高部署效率,BlueLM-V-3B 将图像处理与用户输入解耦。在模型初始化时,ViT 和 LLM 模型同时加载到内存中。用户上传图像时,由于 MLLM 在本地部署,上传几乎没有延迟。图像上传后,ViT 立即开始处理,用户可以同时输入指令;对于音频指令,BlueLM-V-3B 会先将其转换为文本。

图像处理完成后,用户的命令提交给 LLM 生成响应,ViT 可以从内存中释放。这种并行处理减少了第一个 token 生成的等待时间,提高了响应速度,并将 BlueLM-V-3B 的峰值内存使用限制在 2.2GB。

BlueLM-V-3B 的训练过程

训练流程

BlueLM-V-3B 从 BlueLM-3B 语言模型开始分两个阶段进行训练。在第一阶段,预训练线性映射层,同时保持 ViT 和 LLM 冻结。在第二阶段,使用大量的图像 - 文本对对模型进行全面微调。

训练数据

第一阶段:

第一阶段旨在赋予模型基本的多模态能力。在这一阶段,该团队利用开源数据集,创建了一个由 250 万条图像 - 文本对组成的综合预训练数据集,这些数据集来自 LLaVA、ShareGPT4V 和 ALLaVA。

第二阶段:

在这一阶段,研究团队精心构建了一个包含 6亿+ 条图像 - 文本对的数据集,其中包括开源数据集和内部数据集。该数据集涵盖了各种下游任务和多样化的数据类型,如图像描述、视觉问答、文本图片识别和纯文本数据。

除了开源数据集,他们还加入了大量内部数据以增强模型的能力。比如,从各种网站上爬取了大量的纯文本数据和图像 - 文本对。对于不同的数据类别,如 PDF、公式、图表、解题数据、多语种数据,团队还手动渲染并创建了大量的图像-文本对,以丰富训练数据的多样性。

除了进行图像渲染外,研究团队还使用 GPT-4o 和 Gemini Pro 构造和修改图片描述及视觉问答对。开源与专有数据的结合显著提升了模型的能力,使其能从多样化的示例中学习,并在多种任务和模态上提升性能。

实验结果

宽松的长宽比选择算法

部署效率:

该团队在 LLaVA 665k 训练集上验证了改进方案是否能降低部署成本。为公平对比,他们将 LLaVA-NeXT、InternVL 1.5 和改进方案的最大分块数均设置为 9。

与 LLaVA-NeXT 相比,提出的方法在 2.9 万个样例中选择了更小的长宽比;而在与 InternVL 1.5 的比较中,在 52.3 万个样例中采用了更小的长宽比,在 2.5 万个样例中选择了更大的长宽比。这显著提升了 NPU 上的推理效率。

测评集性能:

研究团队在 MiniCPM-2B 和 BlueLM-3B(均为 2.7B 参数量)两个模型上进行实验,利用 LLaVA 558k 进行第一阶段训练,用 LLaVA 665k 进行第二阶段训练。比较 LLaVA-NeXT、InternVL 1.5 和改进方案在测评集上的性能表现。

由于 3B 模型的学习速度较慢,每个阶段训两轮。该团队统计了在多个常用测评集上的结果。

可以看到新设计的动态分辨率方案不仅降低了部署成本,还提升了测评集上的准确率。

不同测评集上的准确率比较

OpenCompass 测评集:

下图展示了全量微调完的 BlueLM-V-3B 模型在 OpenCompass 测评集上的精度表现,并和总参数量小于等于 10B 的模型进行比较。

可以看到,BlueLM-V-3B 模型在 4 个测试项目中取得最高分,并在均分上排名第二。这展示了 BlueLM-V-3B 模型的强劲性能。

文本数据集 / OCR 能力:

下图是 BlueLM-V-3B 与参数量相近的多模态模型在 TextVQA,DocVQA 以及多语种多模态数据集 MTVQA 上的评测结果。

可以看到,在 OCR 相关任务上,BlueLM-V-3B 取得了非常有竞争力的成绩,并在多语言测评中远超主流的多模态模型。

BlueLM-V-3B 部署效率

团队汇报了在搭载天玑 9300 处理器的 vivo X100 手机上的部署结果。

图像并行编码:

实验中,采用了 2:4 的分块方案(对手机屏幕的处理采用 2:4 方案),共有 2x4=8 个局部分块和一个全局分块。该团队测试了同时处理 1 块、2 块、4 块、6 块图像切块的 NPU 处理延时。

可以看到,同时处理 4 个切块的总延时最低,仅为 1.9 秒。

流水线并行处理:

该团队设计了对 SigLIP 模型的 Conv2D 和 ViT 部分在 CPU 和 NPU 上的流水线并行,并测试了 2:4 分块方案下的部署效率。如上文流水线管线所示,可以掩盖 200 毫秒的 Conv2D 的处理延时。

分块计算输入 token:

该团队在 NPU 上采用了一种分块处理策略,每次迭代并行处理 128 个输入 token(t128),以平衡并行处理与 NPU 性能。在此展示并行处理不同数量输入 token 时的 LLM 首词延时:t32、t128、t512 和 t2048。

论文中还列出了输出 token 的生成速度,其中仅显示了 t1 的情况,因为 LLM 在输出时一次处理一个 token。输入 token 长度被固定为 2048,KV 缓存长度被设置为 2048。

可以看到,t128/t1 实现了最低的延迟和最快的生成速度。

和 MiniCPM-V 对比:

该团队对 BlueLM-V-3B 与 MiniCPM-V 论文中提供的统计数据进行了直接比较。MiniCPM-V 论文仅报告了 8B 参数量的 MiniCPM-V 2.5 模型在天玑 9300 芯片的 CPU 上使用 llama.cpp 部署的情况。BlueLM-V-3B 团队使用分辨率为 768×1536 的图像,固定输入 token 长度为 2048,并将 KV 缓存长度设为 2048。

MiniCPM-V 将模型加载时间也计入了延迟。对于 BlueLM-V-3B,在系统初始化阶段,同时加载 ViT 和 LLM 的时间仅为 0.47 秒。结果显示,BlueLM-V-3B 因其较小的参数量和优秀的系统设计,在延迟和 token 吞吐量上更具优势。

总结

在 BlueLM-V-3B 的开发过程中,vivo 和港中文团队在确保良好用户体验的同时,注重算法 - 系统协同设计和硬件感知优化。据实验与统计分析显示,BlueLM-V-3B 在移动设备上表现出色,性能强劲且部署高效。

未来,该团队将继续致力于提升端侧模型的可扩展性,并探索先进算法,持续优化性能与可用性,以适应更多的手机设备。

来源:机器之心Pro一点号

相关推荐