如果说 2023-2024 是 LLM 走向成熟的两年，那 2025-2026 就是多模态走向标配的两年：

• GPT-4o 端到端语音（2024）→ GPT-5 全模态（2025）

• Claude 3 视觉 → Claude 4 实时图像理解

• Gemini 1.5 长视频 → Gemini 2.5 视频生成

• Qwen-VL → Qwen3-VL → Qwen3-Omni

• DeepSeek-VL → DeepSeek-Vision3

多模态已经从"加分项"变成"必选项"。

如果你做过相关工作，下面这些问题应该不陌生：

• VLM（Vision Language Model）和普通 LLM 部署有什么区别？

• 怎么让 vLLM 跑视觉模型？

• 语音识别用 Whisper 还是 Paraformer？延迟怎么压？

• 视频理解（1 小时视频）实际能用吗？token 消耗多少？

• GPT-4o 那种实时语音对话怎么实现？

读完本文你将能：

1. 区分 VLM、ASR、TTS、Video-LLM 各自的架构和部署难点

2. 用 vLLM / SGLang 部署主流 VLM

3. 搭建语音对话 pipeline（ASR + LLM + TTS）

4. 处理视频理解的 token 爆炸问题

5. 评估端到端多模态模型（如 GPT-4o-realtime）的工程成本

我们开始。

一、多模态的「四大场景」

1.1 应用版图

本篇聚焦理解类（输入多模态、输出文字）——这是 LLM 工程师最常做的。

1.2 多模态的工程挑战

1. 输入预处理重 ── 图像 / 音频 / 视频解码 2. Token 量爆炸 ── 1 张图 ≈ 几百-几千 token 3. 显存压力大 ── KV Cache 跟着膨胀 4. 推理框架支持参差 ── 不是所有都支持 5. 延迟难控 ── 多模态 prefill 慢

下面分模态深入。

二、视觉语言模型（VLM）

2.1 VLM 架构速通

主流 VLM 的架构都是ViT + Projector + LLM：

图像 ↓ ViT（视觉编码器）── 把图像切成 patch，每个 patch 一个 token ↓ Projector（投影层）── 把视觉 token 映射到 LLM 的 embedding 空间 ↓ 拼接 + 文本 token ↓ LLM（标准 Transformer）── 正常生成

关键认知：

从 LLM 视角看，图像就是「一段特殊的 token 序列」。

所以 LLM 的所有能力（in-context learning、Tool Use、推理）都能"白嫖"到多模态——这是 VLM 路线赢得行业认同的核心原因。

2.2 主流 VLM 横评（2026.05）

中文场景：Qwen3-VL是当之无愧的开源王者。

2.3 视觉 Token 消耗

这是部署 VLM 时最常踩的坑——图像 token 远超想象：

举例：

用户上传 10 张 4K 图片，问"分析这些图" token 消耗：~30,000 token（光是视觉部分） 如果还有几段长 prompt + RAG 上下文 → 上下文很快爆炸

优化建议：

• 主动指定较低分辨率（API 大都支持）

• 业务允许的话先压缩图片

• 监控每次请求的视觉 token 数

2.4 用 vLLM 部署 VLM

vLLM 0.6+ 全面支持主流 VLM：

# 部署 Qwen2.5-VL-32B vllm serve Qwen/Qwen2.5-VL-32B-Instruct \ --tensor-parallel-size 4 \ --max-model-len 32768 \ --gpu-memory-utilization 0.92 \ --limit-mm-per-prompt image=10 \ # 单 prompt 最多 10 张图 --port 8000

关键参数：

• --limit-mm-per-prompt：限制多模态输入数量

• 别的参数和 LLM 部署一致

调用：

from openai import OpenAI client = OpenAI(base_url="http://localhost:8000/v1", api_key="dummy") response = client.chat.completions.create( model="Qwen/Qwen2.5-VL-32B-Instruct", messages=[{ "role": "user", "content": [ {"type": "text", "text": "这张图里有什么？"}, {"type": "image_url", "image_url": {"url": "data:image/jpeg;base64,..."}} ] }] )

完全 OpenAI Vision 兼容协议（第 19 篇讲过）。

2.5 VLM 部署的 5 个坑

2.5.1 坑 1：图片预处理不一致

症状：训练用 1024×1024 但推理传 4K，效果异常。

对策：

• 看模型的image_size配置

• 客户端预处理统一

2.5.2 坑 2：批处理的尴尬

VLM 的 batch 不像 LLM 友好——不同图片预处理时间差异巨大。

对策：

• 客户端把图缩到固定尺寸

• 服务端用 vLLM 自动批处理

2.5.3 坑 3：显存涨幅超预期

VLM 显存 ≈ LLM 显存 × 1.3（ViT + Projector + 图像 KV）。

对策：

• KV Cache 量化

• 限制并发图片数

2.5.4 坑 4：长视频 / 长 PDF

PDF 转图 100 页 = 100 张图 ≈ 几万 token 一次性来。

对策：

• 分批处理（每次 5-10 页）

• 优先用文本提取（OCR + 文字模型）

2.5.5 坑 5：中英文 OCR 不均衡

很多开源 VLM 英文 OCR 强，中文一般。

对策：

• 中文场景优先 Qwen-VL / InternVL

• 重要场景接 PaddleOCR 等专门工具补强

三、语音模型：ASR + TTS

3.1 语音对话的标准 Pipeline

用户说话 ──→ ASR（语音→文字） ↓ LLM 推理 ↓ TTS（文字→语音） ──→ 播放

这是 2024 年大多数"语音助手"的实现方式——三段式。但有明显问题：

• 延迟累加（每段 200-500ms，总计 1-2s）

• 不能处理情感、语调、打断

• 不能做"嗯嗯"等填充音

2024 末 OpenAI 推出GPT-4o realtime，开创了端到端语音模型新范式。

3.2 ASR（Automatic Speech Recognition）

主流 ASR：

实战推荐：

• 中文：SenseVoice 或 Paraformer

• 多语言：Whisper-turbo

• 极致质量：GPT-4o API

部署 SenseVoice

from funasr import AutoModel model = AutoModel( model="iic/SenseVoiceSmall", trust_remote_code=True, device="cuda:0", ) result = model.generate( input="audio.wav", cache={}, language="auto", # 自动识别语言 use_itn=True, # 自动标点 + 数字归一化 ) print(result[0]["text"])

实测延迟（5 秒音频）：~120ms（流式可降到 ~50ms）。

3.3 TTS（Text-to-Speech）

主流 TTS：

当下开源王者：CosyVoice 2——支持 zero-shot 声音克隆、多语言、情感控制。

from cosyvoice.cli.cosyvoice import CosyVoice2 model = CosyVoice2("pretrained_models/CosyVoice2-0.5B") # Zero-shot 声音克隆 audio = model.inference_zero_shot( "你好，欢迎使用语音助手", "这是一段参考音频", "ref_audio.wav" )

3.4 端到端语音对话（GPT-4o 式）

GPT-4o realtime 不走 ASR-LLM-TTS 三段式，而是直接 audio in → audio out：

音频输入 → audio tokens → 同一个 Transformer → audio tokens → 音频输出

优势：

• 延迟超低（< 320ms）

• 保留情感、语调

• 可被打断

• 听得懂"嗯"、"啊"等填充音

开源跟进：

• Qwen3-Omni：阿里 2026 推出，全模态 + 端到端

• GLM-4-Voice：智谱端到端语音

• Step-Audio：阶跃星辰

部署 Qwen3-Omni

vllm serve Qwen/Qwen3-Omni-7B \ --tensor-parallel-size 2 \ --enable-audio-output \ # 启用音频输出 --max-model-len 16384

调用流式：

# WebSocket 实时双向音频流 # 客户端持续推送 audio chunk # 服务端持续返回 audio chunk

实测延迟：300-500ms（接近 GPT-4o）。

3.5 语音业务的工程化

完整语音助手架构：

浏览器/移动端 ↓ WebRTC / WebSocket 语音网关（FastAPI + WebSocket） ├── VAD（语音活动检测，判断说没说话） ├── ASR（流式） ├── LLM（vLLM + 流式输出） └── TTS（流式合成） ↓ 返回音频流

关键技术点：

• VAD：用 Silero VAD 等模型识别说话开始/结束

• 流式 ASR：边录边识别，不等说完

• 流式 TTS：LLM 边输出文字边合成语音

• 打断处理：用户说话时立即停 TTS

四、视频理解

4.1 视频的 Token 灾难

视频 = 一系列图像帧。

1 分钟视频（30 FPS）= 1800 帧 每帧 ~500 token = 90 万 token 完了，连 1M 上下文都装不下。

所以视频理解必须抽帧 / 压缩。

4.2 主流抽帧策略

实操推荐：

• 短视频（< 1 分钟）：1 FPS

• 中等视频（1-30 分钟）：0.5 FPS 或固定 100 帧

• 长视频（> 30 分钟）：固定 200 帧均匀抽

4.3 主流 Video-LLM

4.4 部署示例

# 用 Qwen2.5-VL 处理视频 from qwen_vl_utils import process_vision_info messages = [{ "role": "user", "content": [ {"type": "video", "video": "path/to/video.mp4", "fps": 1.0}, {"type": "text", "text": "总结这个视频的内容"} ] }] # qwen_vl_utils 自动抽帧并转 token image_inputs, video_inputs = process_vision_info(messages) response = client.chat.completions.create( model="Qwen/Qwen2.5-VL-32B-Instruct", messages=messages, )

4.5 视频业务场景

五、统一多模态：未来已来

5.1 全模态模型

2025-2026 的明星：

关键认知：

未来的「LLM」会消失——只有「多模态基础模型」。

5.2 一个统一模型 vs 多个专用模型

结论：业务简单用统一，业务专业用专用。混合也很常见。

5.3 Computer Use 与 Browser Use

2024 末 Anthropic 推出Computer Use——让 Claude 直接看屏幕 + 操作鼠标键盘。

LLM 看屏幕截图（VLM 能力） ↓ 理解界面 ↓ 决定操作（click x,y / type "hello"） ↓ 执行 ↓ 看新截图 ↓ ...

这是多模态 + Tool Use + Agent的终极组合，让 LLM 能用任何 GUI 软件。

主流方案：

• Anthropic Computer Use

• OpenAI Operator（2025）

• 开源 Browser-use / Skyvern

部署复杂度极高——需要虚拟机 + 屏幕截图 + 输入控制 + 安全沙箱。

六、生产实战：多模态客服 Demo

把前面的技术整合，做一个生产级多模态客服：

用户上传：图片（产品照） + 语音（描述问题） ↓ ASR 识别语音 ↓ VLM 分析图片（识别产品 + 缺陷） ↓ RAG 检索：产品手册 + 历史工单 ↓ LLM 生成回复 + 解决方案 ↓ TTS 转语音回复

完整代码骨架：

async defmultimodal_customer_service(audio: bytes, image: bytes): # 1. ASR text = await asr_model.transcribe(audio) # 2. VLM 分析图片 image_analysis = await vlm.analyze(image, prompt="识别产品和问题") # 3. RAG docs = await rag.search(f"{text} {image_analysis}") # 4. LLM 生成 response = await llm.generate( system="你是客服专家", messages=[{"role": "user", "content": f""" 用户语音问题：{text} 图片分析：{image_analysis} 相关文档：{docs} """}], ) # 5. TTS audio_response = await tts.synthesize(response) return { "text_response": response, "audio_response": audio_response, "image_analysis": image_analysis, }

资源预估

跑这套服务需要：

月 TCO：约 ¥120K。

七、避坑

7.1 坑 1：图片 token 失控

对策：监控每请求 token 数，对超出的请求自动降采样。

7.2 坑 2：长视频默认抽帧太多

对策：业务侧主动设抽帧数（如最多 50 帧）。

7.3 坑 3：音频文件格式杂

对策：客户端统一转 PCM 16kHz mono。

7.4 坑 4：语音延迟超预期

对策：

• 用流式 ASR / TTS

• 优化 LLM prefill 速度

• 用端到端语音模型（GPT-4o-realtime / Qwen3-Omni）

7.5 坑 5：多模态 RAG 检索效果差

对策：

• 用专门的多模态 embedding（如 CLIP / Visualized BGE）

• 图像和文本各自索引 + 融合排序

7.6 坑 6：评估方法不对

对策：

• 文本任务：BLEU / ROUGE / GPT-4 as judge

• 视觉任务：MMBench / MMMU / 自建业务评测集

• 语音任务：WER（识别）/ MOS（合成）

八、结语：多模态是 LLM 工程的「下一波」

读完本文你应该明白：

• VLM 本质是 ViT + Projector + LLM——可以用 vLLM 部署

• 图像 token 远超想象——监控每请求 token 数

• 语音三段式（ASR-LLM-TTS）是主流，端到端是未来

• 视频必须抽帧——1 FPS 是甜蜜点

• GPT-4o / Gemini 2.5 / Qwen3-Omni开启全模态新时代

• Computer Use是多模态 + Tool Use + Agent 的终极融合

参考文献：

多模态部署：VLM、语音、视频理解