面包屑图标 当前位置: 首页
AI资讯
热点详情

多模态视觉理解大模型推理优化策略

AI热点日报
AI热点日报时间:2026-07-06
热点解读

针对多模态视觉理解大模型推理性能瓶颈,采用图像预处理库替换、ViT模块接入TensorRT与CudaGraph加速、降低图像Token数以及引入PrefixCache复用KV缓存等策略,显著提升吞吐量并降低延迟,为大规模部署提供可行方案。

多模态视觉理解大模型性能优化实战教程

多模态视觉理解大模型(VLM)是当前人工智能领域的重要突破,它将语言与视觉模态深度融合,能够完成图像识别、内容推理、复杂问题解答等任务。然而,其推理性能瓶颈导致部署成本高昂,严重阻碍了大规模应用。本文基于58同城多模态视觉理解项目的实际优化经验,系统介绍从图像预处理、ViT模块加速、Token化处理到量化部署等六大核心优化策略,帮助你显著提升模型吞吐量并降低延迟。

一、背景与挑战

大模型时代,基于Transformer架构的多模态视觉理解大模型(VLM)在全球范围内引发深度技术关注。其主要创新在于将语言和视觉两种模态进行有效对齐,不仅能做基本图像识别,还能执行基于视觉输入的动态内容推理和复杂问题解答。应用场景包括房内家具家电识别、涉黄涉爆检测、商家店铺门头识别等,相比传统模型效果更优。

然而,多模态视觉理解大模型的推理性能比传统模型低,导致整体成本高,严重阻碍了推广。提高推理性能成为研究重点。我们作为多模态大模型技术部门,负责模型研发、推理优化和推广,在58的多模态视觉理解项目场景中,对推理框架和模型进行优化,使用多种方法提高了推理性能。

二、应用场景分析

在58的多模态视觉理解项目中,都是后台提交任务对图片进行推理,没有与用户进行实时对话的场景,因此目前性能优化的重点是批量输出场景。主要分为两类:

场景一:长Token输入、短Token输出(占比98%以上)

多模态视觉大模型输入的是提示词+图片,输入Token通常较长,但在58的场景内,98%以上的推理场景输出Token很短,通常在5个Token以内。例如在信安定制数据治理项目中,输出Token只有“是”或者“否”。我们重点对这种场景进行性能优化。

场景二:长Token输入、长Token输出(占比约2%)

例如给一张简历的PDF图片,让大模型识别图片中的内容,输出的Token一般是几百个以上。这种场景占比很少,不是性能优化的重点方向。

三、核心性能指标

VLM推理服务重点关注两个指标:吞吐量时延

  • 吞吐量:主要从系统角度衡量,即单位时间内能处理的Tokens数量。由于我们的主要场景是长输入Token、短输出Token,所以吞吐量以单位时间内能处理的请求数作为衡量指标,即模型推理的QPM(Queries Per Minute)。
  • 时延:主要从用户视角衡量,即用户平均收到每个Token所需的时间。计算方法为用户从发出请求到收到完整响应的时间除以生成序列长度。一般来讲,当时延不大于 50 ms/token 时,用户使用体验会比较流畅。

由于我们的场景都是批量输出,没有流式输出,所以我们重点关注的性能指标是吞吐量

四、六大优化策略

4.1 图像预处理优化

在多模态推理中,Vision Transformer (ViT) 是关键的模块,图像预处理是将图像转换为适合ViT模型输入数据的过程,主要包括图像颜色空间转换、尺寸调整(Resize)、划分图像块(Patch Partitioning)、归一化(Normalize)等。在LMDeploy框架中,图像预处理通过PIL(Pillow)的Image模块在CPU上处理,图像Resize及Partition过程效率较低,耗时占整个ViT过程的20%以上

为了提升系统吞吐能力,我们分别使用Pillow与OpenCV进行预处理测试,具体环境如下:

  • CPU: Intel(R) Xeon(R) Silver 4410Y
  • Python 3.10.12
  • Pillow 10.2.0
  • opencv_python 4.8.1.78
  • 2000张不同分辨率图像

图1:Pillow与OpenCV预处理耗时对比

使用OpenCV可以极大减少图像预处理的耗时,平均处理单张图片的耗时由23.67ms减少到12.03ms,性能提升49.18%。但在Resize过程中,虽然两个处理库的插值方式均使用BICUBIC,当图像进行下采样时效果存在明显差异,使用OpenCV处理的图像出现波纹。

图2:Pillow与OpenCV效果对比

通过对比源码实现,发现二者在插值与边界处理实现上有所差异:

  • 插值计算方式:二者均使用4x4卷积核进行插值计算,OpenCV直接使用三次多项式公式计算每个像素权重,并对周围16个像素加权平均;而Pillow将三次卷积操作分解为两个一维卷积,先水平方向卷积,再垂直方向卷积。
  • 边界处理:OpenCV提供多种边界处理方式(如BORDER_REPLICATE、BORDER_REFLECT、BORDER_WRAP等);Pillow通常使用边界复制方式,即边缘像素值被复制到图像外部,以避免边缘出现伪影。

小提示:OpenCV文档建议:缩小时使用INTER_AREA插值,放大时使用INTER_CUBIC(速度慢但效果好)或INTER_LINEAR(更快但效果尚可)。我们根据图像采样动态调整插值方式:降采样用INTER_AREA,上采样用INTER_CUBIC。调整后效果如下:

图3:OpenCV优化前后与Pillow效果对比

常见问题:为什么OpenCV下采样会出现波纹?
答:因为OpenCV的BICUBIC插值在边界处理和权重计算上与Pillow存在差异,导致下采样时产生伪影。使用INTER_AREA可避免此问题,因为INTER_AREA基于区域像素平均,更适合缩小图像。

4.2 ViT模块支持TensorRT

ViT模块是多模态推理框架中必不可少的组成模块,主要负责图像处理及编码工作 ViT模块的处理速度直接影响整个框架的推理效率。我们对ViT模块的耗时进行了分块分析:

图4: vision 模型推理耗时及内存占用情况

内存拷贝逻辑代码截图:

图5: LMdeploy VIT阶段内存拷贝代码截图

经过验证,内存拷贝耗时主要是等待GPU异步处理结果,所以实际主要耗时模块为图像预处理及特征提取两部分。具体定位步骤如下:

  • 内存拷贝逻辑修改:取消结果拷贝至CPU的操作(lmdeploy/vl/engine.py、lmdeploy/serve/vl_async_engine.py、lmdeploy/pytorch/message.py)。
  • 异常分析:逻辑调整后推理结果异常。在vl/engine.py forward增加输出结果日志后推理正常,验证日志起到同步等待作用。使用torch.cuda.synchronize()sleep可复现正确结果。

定位到ViT中extract_feature为主要耗时模块。为了进一步提升效率,我们借鉴TensorRT-LLM的推理加速方案——TensorRT。TensorRT是NVIDIA的高性能深度学习推理优化器,可为深度学习应用提供低延迟、高吞吐率的部署推理。

图6: Tensorrt优化过程图

对ViT模块进行TensorRT改造包含模型转换、模型优化和推理部署三个阶段。本文以ONNX为例:

1. 模型转换

图7: ONNX模型转换代码截图

导出ONNX时可能遇到不支持的算子,如导出快速傅里叶变换(FFT)和快速傅里叶逆变换(IFFT)时会报错:

Exporting the operator 'aten::fft_rfftn' to ONNX opset version 17 is not supported

此时需要调整模型网络结构或自定义算子。另外,部分多模态模型的ViT使用了FlashAttention2进行注意力加速,而flash_attn_func是独立内核实现,导致导出器无法捕获计算图,出现如下警告:

/usr/local/lib/python3.10/dist-packages/flash_attn/flash_attn_interface.py:90: TracerWarning: Converting a tensor to a Python boolean might cause the trace to be incorrect. We can't record the data flow of Python values, so this value will be treated as a constant in the future. This means that the trace might not generalize to other inputs!

因此,我们对Attention模块进行调整,使用PyTorch内部实现的缩放点积注意力(Scaled Dot-Product Attention, SDPA),如下:

图8: 缩放点积注意力(SDPA)代码截图

至此模型可成功转换成ONNX格式。

2. 模型优化

该阶段完成层间融合、精度校准等,输出针对特定GPU平台和网络模型优化的TensorRT模型,可序列化存储为TensorRT plan文件。

图9: Tensorrt模型优化及系列化流程图

3. 推理部署

图10: Tensorrt部署及推理流程图

部署阶段将plan文件反序列化,创建runtime engine,输入图像数据,输出推理结果。

4. 推理效率

经过TRT加速后,ViT模块feature_extract速度缩减约45%(不包含图片预处理),耗时占比从60%减少至45.36%,整体推理耗时减少约70ms

常见问题:TensorRT转换时遇到不支持的算子怎么办?
答:可以尝试更换算子实现(如用SDPA替代FlashAttention2),或者自定义ONNX算子。若涉及FFT等操作,需调整网络结构避免使用。

4.3 ViT模块支持CudaGraph

推理框架lmdeploy在0.6.0版本引入了CUDA Graph,提升了近30%的推理性能。但当时只在语言模型中引入。为了进一步提升速度,我们在ViT模块中也引入了CUDA Graphs。CUDA Graphs通过录制(capture)和重放(replay)CUDA操作,减少CPU到GPU的调度开销,提高执行效率。

图11: CUDA Graphs性能优势图

实现步骤:使用torch.cuda.CUDAGraph创建图,用torch.cuda.graph()录制ViT推理过程,推理时通过CUDAGraph.play()重放。

注意:CUDA Graphs不支持动态控制流(如条件语句和循环),且输入张量形状须在图创建时固定。而ViT模块输入形状为 [batch_size, channel, width, height],其中batch_size可变。我们在框架内部维护了Graphs Pool,推理时根据batch_size索引至相应的graph,再执行重放操作。

增加CUDA Graphs后,ViT模块平均耗时减少约30ms。但构建graphs会占用额外显存,需综合衡量业务场景及硬件资源。

常见问题:CUDA Graphs是否适用于动态batch场景?
答:不直接适用,因为图创建时形状须固定。但可以通过构建多个不同batch_size的Graphs Pool来解决,每个batch_size对应一个图。

4.4 图像Token化处理

输入Token的长度对推理耗时影响很大,多模态模型中图像部分占据很大比例Token数。降低图像转换的Token数可提升推理性能。

图12: Token数和推理耗时基本成正比

图像Token数计算流程:

  1. 根据图像宽高比和分辨率大小将原图拆分成若干个448x448的patch,拆分原则是尽量保持图像不失真。拆分代码(以InternVL2-8B为例):

图13: VLLM中InternVL2-8B模型拆图代码截图

基本流程:给定动态拆分阈值范围,穷举所有可能目标比例,根据原图比例匹配最佳拆分规则。图示中会被拆分成6个patch块和一张缩略图。

图14: InternVL模型整体框架图

  1. 一个448x448的patch生成的Token数计算方式
    image_tokens_per_patch = (force_image_size // patch_size)**2 * (downsample_ratio**2)
    其中force_image_size=448, patch_size=14, downsample_ratio=0.5,计算后结果为256。不同模型值可能不同。
  2. 示例:分辨率为896x1344的图像,拆分成2x3=6个patch,再加一张缩略图(可选),最终堆叠形状[7,3,448,448],图像转换Token数为7*256=1792。

部署到线上时,单卡吞吐量上不去,其中一个原因是拆图规则导致拆分后图片数量较多。如分辨率612x464,最合适宽高比是 (4,3),按模型规则图像将被拆分成[13,3,448,448],Token数达3328,加上prompt总Token数超过3400,导致无法做更大batch推理。

优化思路:降低图像总Token数。官方的代码对低分辨率图像存在冗余,例如480x360也会转换成3328个Token。我们保持图像内容不拉伸,调整宽高比以适应ViT要求。优化后,480x320图像只转换成512个Token,推理时能做到更大batch处理。在实际落地场景中,吞吐量提升约1倍

常见问题:调整宽高比会导致图像失真吗?
答:我们的目标是保持内容不拉伸,通过调整宽高比(如裁剪或padding)使图像适配ViT的网格划分。只要比例调整合理,对最终识别效果影响很小,但显著降低Token数。

4.5 PrefixCache在多模态模型里的应用

在PagedAttention中,KV Cache只在一个请求内复用,没有跨请求复用。长prompt场景下,不同请求中prompt可能相同,KV Cache计算重复。如果能将prompt的KV Cache保存下来给后续请求复用,将极大降低首Token耗时。

在LLM模型中,PrefixCache分两个阶段:

  • 第一阶段:prompt第一次推理时,按block_size(通常64)对input tokens从前往后分块,计算每个分块的hash作为唯一标识,每个分块的token_id作为key缓存。不足block_size长度的块不缓存。
  • 第二阶段:新prompt推理时,进行prefix cache matching,命中则直接复用KVCache,只计算未命中部分的input tokens。

多模态模型的特点是一次任务的输入tokens由文本+图片组成(system+image+prompt)。在计算prefix cache时,image对应的是padding tokens,不同图片可能匹配到同一个prefix上,导致推理结果错误。

解决方案:在input tokens中对image进行范围标记,计算prefix cache时不对image token进行KVCache,只cache image之前的部分;在prefix cache matching时,保证image token不会被复用。经实验验证,修改后推理结果正确。

注意:Prefix Caching只节省prefill阶段的耗时(降低TTFT),不能节省解码阶段耗时(TPOT)。如果请求主要耗时在解码阶段(如prompt很短而completion很长),或多个请求的prompt没有公共前缀,则Prefix Caching收益不大。

常见问题:如何标记image token范围?
答:在预处理阶段记录image token在输入序列中的起始和结束索引,在prefix cache匹配时跳过这些位置的缓存匹配。

4.6 模型量化

量化是降低模型参数精度(浮点数转整数或定点数)以压缩模型、减少显存消耗的技术,在某些低精度运算较快的处理器上可提升推理速度。量化对象可以是权重、激活、KV Cache和梯度;形式分为线性量化(对称/非对称)和非线性量化;根据阶段分为量化感知训练、量化感知微调、训练后量化。

我们现阶段使用AWQGPTQ,两者都属于训练后量化,针对权重线性量化:AWQ采用对称量化,GPTQ采用非对称量化。

  • AWQ(Activation-aware Weight Quantization):原理是权重不是同等重要,保留1%的显著权重可大幅减少量化误差。通过激活感知方法,考虑更大激活幅度对应更重要的权重通道,逐通道确定最佳缩放因子。
  • GPTQ(Generative Pretrained Transformer Quantization):对模型每一层(线性层或卷积层)单独处理,利用二阶偏导Hessian矩阵的逆指导权重调整,最小化量化误差。将权重矩阵分成子矩阵(block),逐个量化并调整同一子块内其他权重。量化误差依赖高质量校准数据。

整体上,AWQ算法更直接,对校准数据依赖小;GPTQ更容易获得好效果,但算法复杂,对校准数据依赖大。实际需根据场景选用。

测试中,AWQ和GPTQ均采用w4A16量化策略(权重4bit,激活16bit)。在RTX4090下使用vllm,设置最优batch,结果如下:

单个请求延时对比:

图15: 原始模型和量化模型的推理耗时比较

分析:在4090下,大batch计算时使用gemm内核,反量化时间增加,速度不如原精度;使用marlin内核有所优化,但大batch下不明显。低batch时原精度最慢,gemm和marlin差别不大,都比原精度大幅提高。原因:gemm在低batch下有内核优化(如代码所示)。

图16: VLLM中awq量化模型mul计算逻辑代码

吞吐量对比:

图17: 原始模型和量化模型的吞吐量比较

对于短输出,吞吐量没有优化甚至下降,因为主要耗时在prefill(大batch计算),反量化开销导致吞吐下降。对于长输出,decode阶段占比高,内核优化明显,综合吞吐量上升。

总结:W4A16量化一定能节省显存,但推理性能需根据任务特点、硬件环境调整部署参数才能达到最优,并非量化后整体性能一定优于未量化模型。

常见问题:AWQ和GPTQ哪个更好?
答:没有绝对的好坏。AWQ更简单、依赖校准数据少,适合快速部署;GPTQ量化效果可能更优但算法复杂,且依赖高质量校准数据。建议根据实际任务测试选择。

五、优化效果数据

  • 评测模型:InternVL2-8B
  • 数据集:信安群租房检测4524张图片
  • 提示词:图中有3张以上的床,或者是有双层床,请直接给出是或者否,然后给出详细的解释。注意1张双层床有2张床
  • 输出Token数量:max_tokens=1
  • GPU: RTX4090
  • 对比框架:LMDeploy-0.6.0
  • 优化框架:LMDeploy-0.6.0优化版本
  • 吞吐量指标:单位时间内处理的请求数(QPM)

图18: LMDeploy-0.6.0优化前后召回率和吞吐量比较

LMDeploy-0.6.0优化版本在推理效果不受影响的情况下,吞吐量提升到LMDeploy-0.6.0版本的3.05倍

结语

本教程系统梳理了多模态视觉理解大模型在58同城落地过程中的六大性能优化实践,涵盖图像预处理、ViT模块加速、Token压缩、缓存复用及模型量化等核心技术。每项优化都经过实际验证,并给出了效果数据和常见问题解答。希望这些经验能帮助你在自己的项目中快速提升多模态模型的推理性能,降低部署成本,推动AI应用落地。

热点追踪提示词
你是一名 AI 行业编辑,请围绕下面这条热点输出一份资讯解读:
热点:多模态视觉理解大模型推理优化策略要求:
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题
来源:https://www.53ai.com/news/MultimodalLargeModel/2025041115872.html
ai 人工智能

游乐网为非赢利性网站,所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系youleyoucom@outlook.com。

相关热点
AI热点2026-07-06 20:47
百度官方出品度加剪辑口播自媒体必备工具

度加剪辑是百度官方出品的剪辑工具,面向口播自媒体创作者。支持视频剪辑、智能识别字幕,并与百度网盘打通,可快速导入素材。适用于泛知识类创作者制作高质量视频,覆盖从素材导入到成品输出的完整流程。

AI热点2026-07-06 20:46
基于AI的智能在线个性化锻炼计划生成工具 Workout Master

WorkoutMaster是一款基于AI的个性化锻炼计划生成工具,能根据用户目标、偏好及历史训练记录,动态输出专属方案,并实时自适应调整负重、组次等参数。支持定制目标与器械偏好,借助机器学习持续优化,随时随地即可接入使用,确保训练高效安全。

AI热点2026-07-06 20:46
Calorielens AI智能实时拍照分析餐点照片卡路里追踪应用

Calorielens是一款利用AI分析餐食照片的卡路里追踪应用。用户只需拍照,AI即可自动识别食物种类和分量并估算卡路里,省去手动输入步骤。应用还提供历史记录追踪功能,帮助把握热量趋势。AI估算精度可满足日常健康管理需求。

AI热点2026-07-06 20:46
百度旗下首个AI互动式搜索APP简单搜索

百度旗下“简单搜索”AI搜索引擎集成语音、图像、多媒体搜索及实时翻译,支持多模态交互与智能推荐。基于大模型技术,用户可通过对话式交互直接获取精准答案,适用于学习、旅行、生活、职业发展等场景,高效满足信息需求。

延伸阅读