1. 从单模态到多模态为什么我们需要Vision Language Multi Image在AI模型部署和推理的领域里vLLM已经成为了一个绕不开的名字。它凭借其高效的PagedAttention内存管理和极致的推理吞吐量在纯文本大语言模型LLM的服务化部署上几乎成了事实上的标准。但如果你和我一样在实际业务中遇到的不仅仅是文字而是大量的图片、图表、截图甚至是多张图片需要模型去理解和关联那么你很快就会意识到标准的vLLM“套餐”似乎缺了点什么。这就是“Vision Language Multi Image”这个主题出现的背景。它不是一个全新的模型而是一个能力边界和工程实践的延伸。简单来说它要解决的核心问题是如何让一个原本擅长处理文本的vLLM服务高效、稳定地“看懂”并“理解”多张图片并基于这些图片内容进行对话或推理想象一下这些场景用户上传了一组产品不同角度的照片询问它们的差异分析师丢进来几张财务报表的截图要求模型总结趋势或者一个智能客服需要同时参考用户的问题描述和几张错误日志的截图来定位问题。这些需求都指向了多图理解Multi-Image Understanding和视觉语言Vision-Language的结合。然而把视觉模型和语言模型简单地“粘”在一起在vLLM的部署框架下会面临几个棘手的挑战输入结构的复杂性文本是序列而图片是二维张量。多张图片意味着输入从一维序列变成了一个结构化的列表每张图片还需要经过预处理如裁剪、归一化。计算资源的博弈视觉模型如CLIP的ViT编码器通常计算量巨大。如何在高并发的vLLM服务中高效调度GPU资源进行图片编码而不让视觉部分成为整个推理流水线的瓶颈内存管理的延伸vLLM的PagedAttention精妙地管理了文本生成过程中的KV Cache。但当输入包含图片特征时这些特征是否也需要被“分页”管理如何与现有的内存管理机制协同批处理Batching的优化vLLM的吞吐量优势很大程度上来自其先进的连续批处理Continuous Batching。当请求中夹杂着尺寸不一、数量不等的图片时如何实现高效的动态批处理避免因为等待某一张大图的编码而拖慢整个批次因此探讨“Vision Language Multi Image in vLLM”远不止是调用一个多模态API那么简单。它深入到服务端推理引擎的设计、计算图的重构、以及内存与算力的精细调度。接下来我们就拆解其中的核心环节。2. 架构核心视觉编码器与LLM的协同推理模式要实现多图视觉语言推理首先得明确系统的数据流。目前主流的多模态大模型如LLaVA、Qwen-VL通常采用一种“编码器-融合器-解码器”的范式。在vLLM的上下文中我们需要将这个范式适配到其高性能推理框架里。2.1 主流架构拆解从CLIP到Projector一个典型的流程如下视觉编码器Visual Encoder负责将每张输入图片转换成一个高维特征向量序列。最常用的基石是OpenAI的CLIP模型中的ViTVision Transformer。例如一张224x224的图片经过ViT-L/14模型会被转换成一系列特征token比如256个或576个。这里的核心在于这个编码过程是独立于LLM、且通常需要较大计算量的。特征投影层Feature Projector / Connector视觉特征和语言模型的特征空间并不对齐。因此需要一个轻量级的映射网络通常是一个或多个线性层或一个小的MLP将视觉特征序列的维度投影到LLM的文本嵌入空间。例如将ViT输出的768维特征投影到LLM的4096维嵌入空间。大语言模型LLM接收处理后的视觉特征token和文本指令token将它们视为一个连续的序列进行自回归生成输出回答。在单次推理中对于多张图片流程是每张图片独立通过视觉编码器 - 各自的特征序列通过同一个投影层 - 所有图片的特征token与文本token拼接形成一个超长的输入序列送给LLM。2.2 vLLM中的集成挑战与设计选择当把这个流程塞进vLLM时我们不能简单地把视觉编码器也放在vLLM的模型定义里。因为vLLM的优化如PagedAttention, Continuous Batching是围绕LLM的自注意力机制设计的。视觉编码器是独立的前置计算模块。因此常见的工程实践有两种模式模式一预处理与在线服务分离这是最简单直接的方式。单独部署一个视觉编码服务例如使用Triton Inference Server或简单的FastAPI封装ViT。vLLM服务在收到请求后先将图片URL或二进制数据发送给视觉编码服务获取到特征向量后再将其作为“特殊文本token”的嵌入拼接到输入中调用本地的vLLM引擎进行文本生成。优点架构清晰视觉编码和LLM推理可以独立扩缩容。视觉编码服务可以针对图片处理做专门优化如图像解码、批量编码。缺点引入了网络延迟和序列化/反序列化开销。对于需要低延迟的交互式应用多一次网络往返可能是不可接受的。此外特征数据在网络中传输也有带宽成本。模式二一体化引擎内嵌更激进的方式是修改vLLM引擎本身将视觉编码器作为模型的一部分尽管计算上是分离的。在加载模型时同时加载视觉编码器如CLIP-ViT和投影层的权重。在vLLM的Worker处理请求时在execute_model方法内部先调用视觉编码器子模块处理图片再将结果送入LLM。优点零拷贝延迟最低。可以利用vLLM内部的调度和资源管理理论上可以实现视觉编码与LLM计算的流水线重叠。缺点极大地增加了vLLM引擎的复杂性。需要管理两套差异巨大的计算图ViT的注意力与LLM的注意力批处理策略变得复杂。视觉编码部分可能无法直接受益于vLLM为LLM设计的高级优化如PagedAttention。我的经验与选择在追求极致端到端延迟的场景下如机器人实时问答我会倾向于模式二但需要投入大量定制开发。对于大多数高吞吐、异步处理的业务如批量分析用户上传的图片集模式一的分离架构更稳健也更容易维护和监控。一个折中的方案是在同一台物理机或Pod内部署视觉编码服务和vLLM服务通过Unix Domain Socket或共享内存通信来减少网络开销。3. 多图输入的表示与内存管理策略解决了“怎么算”的问题接下来是“怎么喂”的问题。如何将多张图片及其相关信息组织成vLLM能够高效处理的输入格式3.1 输入序列的构造Token化与拼接艺术文本LLM的输入是一维的token ID序列。对于多模态输入我们需要构造一个“多模态序列”。通常我们会引入特殊的“图 token”作为占位符。假设我们使用image作为一个图片占位符token。一段包含多图的指令可能被构造为“imageimage请比较这两张设计稿的配色风格。image另外请参考第三张图的布局。”在vLLM内部这个文本序列被转换成token IDs。关键的一步发生在嵌入层Embedding Layer。我们需要一个自定义的嵌入查找过程对于普通的文本token从词表嵌入矩阵中查找。对于image这个特殊token我们不使用预训练的嵌入向量而是用对应的图片特征向量经过投影层后来替换。如果一张图片对应多个特征tokenViT通常输出一个序列那么一个image占位符就需要被替换成这个特征序列。因此实际的输入LLM的嵌入序列是[img_feat_seq_1, img_feat_seq_2, text_embeddings_1, img_feat_seq_3, text_embeddings_2]。这个过程需要在vLLM的输入预处理阶段通常是在Worker中构造model_inputs时完成。实操中的一个重要细节image这个占位符本身在LLM的词表中需要有一个ID。通常我们会在微调多模态模型时在词表中预留出一定数量的“伪token”如img,im_patch_1到im_patch_N并让投影层学会将视觉特征映射到这些token的嵌入空间。在vLLM加载模型时这些token的嵌入权重会被我们计算出的真实特征覆盖或拼接。3.2 PagedAttention对视觉特征的适配vLLM的王牌是PagedAttention它将KV Cache分割成固定大小的块block像操作系统管理内存一样管理注意力缓存从而极大减少内存碎片支持超长序列。那么多图输入带来的视觉特征token是否也需要被纳入PagedAttention的管理呢答案是通常不需要但需要特殊处理。为什么不需要视觉特征token是作为输入序列的一部分在预填充prefill阶段一次性计算完成的。它们不参与自回归生成过程中的“被缓存和查询”。也就是说在生成第一个回答token时模型会基于所有视觉和文本token计算注意力。但在生成后续token时模型只需要关注之前生成的文本token和原始的视觉特征。视觉特征本身是静态的不会像文本KV Cache那样随着生成不断增长。需要处理什么虽然视觉特征不动态增长但它们在整个生成过程中都需要被访问。在vLLM的实现中我们需要确保这些视觉特征token的KV值在预填充阶段被计算后能够正确地保留在逻辑的“注意力上下文”中并且不会被PagedAttention的换入换出机制错误地丢弃。这通常意味着在vLLM的Attention层实现中需要对输入序列中标识为“图像特征”的位置进行标记确保它们的K和V被存储在一个持久化的、非分页的缓冲区中或者以某种方式固定在内存块内。一个常见的坑如果你直接使用未修改的vLLM去服务一个多模态模型可能会发现当输入序列很长包含多张大图特征时性能下降甚至出错。这可能是因为vLLM默认将所有输入token的KV都进行分页管理而大量静态的视觉特征token不必要的分页操作带来了开销。解决方案往往是为视觉特征实现一个非分页的、连续的KV缓存区域。4. 性能优化核心动态批处理与计算流水线对于在线服务吞吐量Throughput和延迟Latency是生命线。多图输入让这两个指标的优化变得更加复杂。4.1 多图动态批处理的挑战vLLM的连续批处理Continuous Batching之所以强大是因为它能让不同序列的生成过程交错进行GPU利用率高。但当批次中的请求包含图片时问题来了计算不平衡请求A有2张高分辨率图请求B只有1张小图。视觉编码阶段A的计算量远大于B。如果同步进行整个批次需要等待最慢的A完成编码才能进入LLM推理阶段造成GPU空闲Bubble。内存占用不一不同数量、不同分辨率的图片编码后的特征序列长度差异巨大。这给GPU显存的高效利用带来了挑战。优化策略一视觉编码阶段独立批处理将视觉编码器作为一个独立的计算单元为其实现自己的动态批处理队列。这个批处理器只关注图片数据可以贪婪地将尽可能多的图片直到达到显存或最大批量限制组成一个批次进行编码而不管它们来自哪个用户请求。编码完成后特征再分发回各自的请求上下文。这样能最大化视觉编码器的GPU利用率。优化策略二LLM阶段的序列组Sequence Group优化即使视觉特征准备好了进入LLM的序列长度也差异巨大。vLLM本身擅长处理变长序列但极端差异仍会影响效率。我们需要更智能的调度策略例如将长序列请求分组将包含多图长特征的请求尽量放在同一个批次中处理避免长序列拖累只含短文本的请求。预估与调度在请求入队时根据图片数量和历史数据预估其视觉编码时间和LLM处理时间尝试将计算量相近的请求调度到一起。4.2 计算与通信的重叠在一体化引擎模式二中我们可以设计流水线来隐藏视觉编码的延迟时间轴 - | 批次1视觉编码 | 批次1LLM预填充 | 批次1LLM生成 | ... | | 批次2视觉编码 | 批次2LLM预填充 | ...当LLM正在为批次1进行生成解码时GPU的算力可能未被完全占满特别是使用Tensor Parallelism时。此时我们可以利用空闲的SM流多处理器同时为批次2进行视觉编码。这需要精细的CUDA流Stream管理和内核Kernel并发控制。在分离式架构模式一中优化点在于网络和序列化。使用高效的二进制协议如gRPC with Protobuf传输特征数据甚至可以考虑对浮点特征进行有损压缩如FP16量化以减少传输量。在服务器内部让网络接收线程、特征反序列化线程与LLM推理线程并行工作。我的踩坑记录早期我们采用分离架构并且视觉编码服务返回的是JSON格式的基64编码特征。结果发现网络传输和JSON解析的时间竟然和视觉编码本身的时间差不多后来我们切换到gRPC直接传输float数组的二进制流端到端延迟直接下降了40%。另一个坑是在一体化引擎中如果没有正确设置CUDA流视觉编码的内核会与LLM的内核串行执行完全无法重叠。使用torch.cuda.Stream并确保中间结果使用record_stream()正确同步是解锁性能的关键。5. 实践指南从零搭建一个多图vLLM服务理论说了这么多我们来点实际的。假设我们要基于Qwen-VL-Chat模型和vLLM搭建一个支持多图输入的服务。这里以一体化引擎模式为例概述关键步骤。5.1 环境准备与模型准备首先你需要一个支持多模态的模型。以Qwen-VL为例它已经将视觉编码器CLIP-ViT、投影器和Qwen-7B语言模型集成在了一起。# 1. 安装依赖 (建议使用Python 3.9) pip install vllm torch transformers accelerate # 2. 下载模型 # 可以从ModelScope或Hugging Face下载Qwen-VL-Chat # 假设模型已下载至本地路径/path/to/qwen-vl-chat5.2 自定义vLLM模型加载与输入处理vLLM通过LLM类加载模型。对于多模态模型我们需要自定义一个MultiModalModel类继承自vLLM的基类并重写关键方法。# mm_vllm_worker.py (核心概念代码非完整可运行) import torch from torch import nn from vllm.model_executor.models import Model from vllm.model_executor.layers.linear import Linear from transformers import CLIPVisionModel, AutoProcessor class MultiModalModelForVLLM(Model): def __init__(self, model_path, **kwargs): super().__init__() # 1. 加载原始的多模态模型组件 from transformers import AutoModelForCausalLM self.llm AutoModelForCausalLM.from_pretrained(model_path, trust_remote_codeTrue) self.vision_model CLIPVisionModel.from_pretrained(model_path.subfolder(vision_model)) self.proj nn.Linear(vision_hidden_size, llm_hidden_size) # 投影层 self.processor AutoProcessor.from_pretrained(model_path) # 2. 将LLM的权重转移到vLLM兼容的格式 # 这里需要将self.llm的层如model.embed_tokens, model.layers, lm_head # 赋值给vLLM模型内部对应的属性这是一个繁琐但必要的过程。 # 通常需要参考vllm/model_executor/models/下的现有模型实现如llama.py。 # 3. 定义特殊的图像token id self.image_token_id self.llm.config.im_start_id # 假设模型配置中定义了 def image_encoder(self, pixel_values): 视觉编码器前向传播 with torch.no_grad(): # 推理时不需要梯度 vision_outputs self.vision_model(pixel_valuespixel_values) image_features vision_outputs.last_hidden_state # 可能取[CLS] token或全部序列特征取决于模型设计 projected_features self.proj(image_features) return projected_features def forward(self, input_ids, pixel_valuesNone, image_sizesNone, **kwargs): 重写forward方法这是vLLM Worker调用的核心。 input_ids: 包含文本和image占位符的token id序列。 pixel_values: 一个批次的图片像素值张量。 image_sizes: 每张图片对应的特征token数量列表用于在input_ids中定位替换位置。 # 1. 处理图片获取特征 if pixel_values is not None: image_features self.image_encoder(pixel_values) # [B*N_img, Seq_len, Hidden] # 2. 构造最终的输入嵌入 inputs_embeds self.llm.get_input_embeddings()(input_ids) # 先获取文本嵌入 # 关键步骤将inputs_embeds中对应image位置的部分替换为image_features # 这需要根据image_sizes和input_ids中image_token_id的位置进行复杂的切片和替换操作。 # 伪代码 # for each sample in batch: # find all positions of self.image_token_id in input_ids[sample] # replace the embedding at those positions with the corresponding image_features slice final_embeddings self._replace_image_tokens(inputs_embeds, input_ids, image_features, image_sizes) # 3. 将构造好的embeddings传入LLM进行后续计算 # 注意需要绕过原始的embedding lookup直接使用inputs_embeds。 # 调用vLLM内部处理transformer层的方法。 hidden_states final_embeddings for layer in self.llm.model.layers: hidden_states layer(hidden_states, **kwargs)[0] logits self.llm.lm_head(hidden_states) return logits def _replace_image_tokens(self, text_embeds, input_ids, image_features, image_sizes): # 实现具体的替换逻辑这是最核心的预处理步骤 # 涉及批量操作和索引计算代码较为复杂 pass5.3 构建推理API与服务接下来我们需要一个API层接收包含多图的请求调用我们自定义的模型。# app.py from fastapi import FastAPI, UploadFile from PIL import Image import io from vllm import SamplingParams from my_module.mm_vllm_worker import MultiModalModelForVLLM from vllm import LLMEngine, EngineArgs app FastAPI() # 初始化vLLM引擎指定我们自定义的模型类 engine_args EngineArgs( model/path/to/qwen-vl-chat, tokenizer/path/to/qwen-vl-chat, # ... 其他参数如tensor_parallel_size, gpu_memory_utilization等 # 关键指定自定义的模型类 model_loader_extra_config{model_class: MultiModalModelForVLLM} ) engine LLMEngine.from_engine_args(engine_args) app.post(/generate) async def generate(prompt: str, images: list[UploadFile]): # 1. 预处理图片 pixel_values_list [] image_token_positions [] # 记录image在prompt中的位置 processed_prompt prompt # 假设用户prompt中已包含image占位符我们需要解析它 # 更常见的做法是API定义图片顺序如images[0]对应第一个image for img_file in images: image_data await img_file.read() image Image.open(io.BytesIO(image_data)).convert(RGB) # 使用模型的processor处理图片 # processor会返回pixel_values等模型需要的输入 processed processor(imagesimage, return_tensorspt) pixel_values_list.append(processed[pixel_values]) # 将多张图片的pixel_values batch起来 pixel_values_batch torch.cat(pixel_values_list, dim0) # 2. 构造vLLM的请求 sampling_params SamplingParams(temperature0.8, top_p0.95, max_tokens512) # 我们需要将图片信息pixel_values_batch和文本prompt一起传递给engine # 这需要扩展vLLM的Request类或者通过extra参数传递。 # 这里是一个概念性展示实际需要修改vLLM源码或使用其较新的多模态支持如果已提供。 request_id freq-{uuid.uuid4()} engine.add_request( request_id, promptprocessed_prompt, sampling_paramssampling_params, # 如何传递pixel_values是一个关键可能需要修改vLLM内部数据结构。 extra_inputs{pixel_values: pixel_values_batch, image_sizes: [feat.shape[1] for feat in image_features]} ) # 3. 驱动引擎并获取结果 outputs [] while engine.has_unfinished_requests(): step_outputs engine.step() for output in step_outputs: if output.finished: outputs.append(output) # 返回最终生成的文本 return {response: outputs[0].outputs[0].text}重要提示上面的代码是高度简化的概念演示。实际上将多模态模型无缝集成到vLLM中需要深入修改vLLM的核心代码包括Request、Sequence、Worker和Model类以支持额外的多模态输入。社区已有一些相关项目如vllm-vision在尝试做这件事但成熟度需要评估。5.4 关键配置与性能调优参数即使跑通了流程不调优性能也上不去。以下是一些关键参数和经验值--tensor-parallel-size如果模型很大如70B需要使用张量并行。但视觉编码部分可能不支持需要确认。--gpu-memory-utilization多模态模型通常更耗显存。建议从0.9开始尝试如果遇到OOM内存不足再调低。需要为图片像素值和特征预留空间。--max-num-batched-tokensvLLM用于控制预填充阶段批大小的参数。多图输入会导致预填充序列很长可能需要适当调大此值但要注意显存。--max-model-len模型支持的最大上下文长度。多图特征会占用大量token务必确保此值足够大例如4张图可能就需要4096的上下文。视觉编码批大小如果采用分离式服务这是视觉编码服务的核心参数。需要根据图片分辨率和GPU显存测试最佳值如16, 32, 64。一个血泪教训我们曾经将--gpu-memory-utilization设为默认的0.9在纯文本场景下很稳定。但上线多模态服务后在同时处理多张高分辨率图片时频繁出现OOM。排查后发现图片预处理转为Tensor和视觉编码产生的中间变量没有计入vLLM的内存估算器。最终我们将其下调至0.7并为图片处理单独预留了显存缓冲区才稳定下来。6. 未来展望与进阶思考将多图视觉语言模型塞进vLLM这样的高性能推理引擎目前仍然是一个前沿的工程挑战。随着多模态应用爆发这个方向一定会快速发展。我认为接下来会有几个趋势框架原生支持vLLM官方很可能会逐步增加对多模态模型的一等公民支持。这需要定义一套标准的多模态输入接口并优化其调度器来公平地处理视觉和语言计算。更高效的视觉编码视觉编码是瓶颈。未来可能会有更多针对推理优化的轻量级视觉编码器或者将视觉特征提取“卸载”到专用硬件如NPU。动态分辨率与稀疏注意力不是所有图片都需要用最高分辨率编码。根据问题动态选择编码分辨率或者对视觉特征序列使用稀疏注意力可以大幅减少计算量和序列长度。统一的内存管理真正将视觉特征的缓存与文本KV Cache在PagedAttention框架下统一管理实现极致的内存利用。对于现在的我们来说理解其核心挑战——结构化输入处理、异构计算调度、内存系统扩展——并能在业务中根据延迟、吞吐和成本的需求在“分离式”和“一体化”架构中做出合理的选择和定制就已经能解决绝大多数实际问题了。这个过程充满挑战但当你看到服务能够流畅地分析一组复杂的图表并给出精准结论时那种成就感也是单文本模型无法比拟的。