5.2 多模态支持

5.2 多模态支持

本节导读：视觉语言模型（VLM）正在成为标配能力——图像理解、文档OCR问答、视频内容审核。本节讲清vLLM多模态推理的架构差异、部署方法、显存预算与吞吐优化，帮你把"能看图的模型"稳定跑起来。

学习目标

• 理解VLM推理与纯文本推理在架构与资源上的差异
• 掌握Qwen-VL、LLaVA等主流VLM的vLLM部署方法
• 学会控制多模态输入的显存与并发预算
• 能定位并解决VLM特有的性能问题

核心概念

VLM的组成：视觉编码器 + 语言模型

图像 → ViT视觉编码器 → 投影层(对齐到词嵌入空间) → LLM → 文本输出
​

与纯文本模型的关键差异：

1. 多出一个编码器：ViT约占模型体积5%~15%，显存与计算都需额外预算
2. 图像变token：一张图被切成patch序列，动辄数百至上千token。一张1080p截图经Qwen2-VL处理可能产生1500+ token——相当于一段长文
3. 预处理更重：图片解码、缩放、归一化在CPU侧完成，高并发时CPU可能先于GPU成为瓶颈

多模态版的PagedAttention

vLLM把图像token与文本token统一放进PagedAttention管理，前缀缓存同样生效——系统提示词的缓存命中率不受影响，因为图像token通常拼接在系统提示之后。

显存预算的三个旋钮

分步实战

步骤 1：部署Qwen2.5-VL

vllm serve Qwen/Qwen2.5-VL-7B-Instruct \
  --limit-mm-per-prompt image=4 \
  --max-model-len 32768
​

limit-mm-per-prompt 是VLM服务的第一道安全阀：不限制时一张含大量图片的请求可直接打爆KV池。

步骤 2：发起图文请求

import base64
from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY")
img = base64.b64encode(open("invoice.png", "rb").read()).decode()

resp = client.chat.completions.create(
    model="Qwen/Qwen2.5-VL-7B-Instruct",
    messages=[{
        "role": "user",
        "content": [
            {"type": "image_url", "image_url": {"url": f"data:image/png;base64,{img}"}},
            {"type": "text", "text": "提取发票上的金额、开票方与日期，输出JSON。"},
        ],
    }],
)
print(resp.choices[0].message.content)
​

步骤 3：控制图像token成本

视觉token数量≈图像分辨率的函数。分辨率下调一档，token数可降40%以上：

# 通过processor参数控制（以模型支持为准）
# 低精度场景（缩略图分类）：低分辨率 → 快
# 文档OCR场景：保持高分辨率 → 准
​

经验法则：屏幕截图/文档保持原生分辨率；照片理解类任务可整体缩到1024宽以内，精度损失通常可忽略。

步骤 4：视频输入（帧采样）

视频按"抽帧成多图"处理。帧数是成本主变量：

vllm serve Qwen/Qwen2.5-VL-7B-Instruct \
  --limit-mm-per-prompt image=16   # 16帧代表约1分钟内容
​

抽帧策略建议：1fps起步，检测类任务对运动敏感时提升到2fps，而不是盲目拉高。

步骤 5：观测与瓶颈定位

curl -s http://localhost:8000/metrics | grep -E \
  "num_requests_(running|waiting)|preemption"
​

• waiting堆积但CPU单核打满 → 预处理瓶颈，把图片预缩放到目标尺寸再发请求，或在网关侧做resize
• preemption频繁 → 图片token挤爆KV池，下调 limit-mm-per-prompt 或 max-model-len

完整示例：发票信息抽取服务

需求：单张发票图片→结构化JSON，峰值50并发。

vllm serve Qwen/Qwen2.5-VL-7B-Instruct-AWQ \
  --quantization awq \
  --limit-mm-per-prompt image=1 \
  --max-model-len 4096 \
  --enable-prefix-caching
​

设计要点：①单图业务把图片上限锁死为1，杜绝异常请求；②AWQ量化抵消视觉token带来的decode压力；③固定抽取模板前置，配合prefix caching让每张发票只付"图像token+问题"的计算成本；④网关侧预压缩图片到长边1280。该配置下单卡A10可稳定支撑50并发，P99 TTFT在2s内。

常见问题 FAQ

Q1：报错 "the number of image tokens exceeds the limit"？
图片产生的token数超过了 max-model-len 减去文本后的余量。解决：调大 max-model-len、限制图片分辨率，或降低单请求图片数。

Q2：VLM的吞吐为什么比同尺寸文本模型低？
两个原因：图像prefill的token量大（一张图≈数百至上千token），且ViT编码有额外计算。优化方向是分辨率控制与量化，而非单纯加并发。

Q3：多张图能分别引用吗（"比较图1和图2"）？
可以。按顺序传入多张图，提示词中用"第一张图/第二张图"引用，主流VLM均按位置对应。但注意每张图的token成本独立累加。

Q4：图像会参与前缀缓存吗？
系统提示与模板部分正常命中；图像token部分因每张图不同而无法跨请求复用。所以VLM服务的前缀缓存收益主要来自模板段，仍值得开启。

Q5：语音模型（ASR/TTS）vLLM支持吗？
语音逐步纳入统一多模态框架，具体模型支持列表随版本变化较快，以官方文档为准。目前社区最常见的还是视觉语言方向。

最佳实践与避坑

• 避坑一：客户端把原图（如4000×3000照片）直接base64上传。大图既拖慢传输又撑爆token预算，网关统一预缩放是VLM服务的标配组件；
• 避坑二：忽略 limit-mm-per-prompt 的默认行为。设得过宽时，一个恶意/异常请求就能触发OOM，把它当安全参数认真配置；
• 实践：为不同业务建"分辨率档位"（缩略图档/标准档/文档档），在网关按业务路由，避免一刀切；
• 实践：上线前用真实图片分布（尺寸、格式、质量）做压测，合成图片的压测结果会严重失真。

本节小结

多模态推理的工程要点在于"把图像当token管理"：用 limit-mm-per-prompt 管上限、用分辨率策略管成本、用量化与prefix caching保吞吐。VLM不是文本服务的简单外挂，而是需要独立预算的一等公民。下一节走向企业级——大规模生产部署方案。

延伸阅读

• 相关章节：3.1 批处理参数调优、3.4 量化推理优化、5.3 企业级部署方案
• vLLM·多模态文档