从纯文本到图文音视频，理解多模态模型的架构和部署挑战。
前置知识
建议先阅读 Transformer 架构概述 和 大语言模型训练流程。
什么是多模态
单模态：只处理一种输入（通常是文本） 多模态：同时处理多种输入（文本 + 图像 + 音频 + 视频）
典型应用场景
技术演进路线
三种多模态架构
架构一：冻结视觉编码器 + 投影层（LLaVA 系列）
工作流程：
部署特点：
关键洞察：视觉编码器的开销通常 < 5ms，远小于 LLM 的推理时间。所以多模态的推理瓶颈仍然是 LLM 部分。
架构二：多模态 MoE
架构三：原生多模态（GPT-4o / Claude 4 / Gemini 3 等）
不再拼接，而是从预训练阶段就混合多模态数据
优点：模态间对齐更好 缺点：训练成本极高，部署显存需求更大
视觉 Token 化详解
图片如何变成 token？
输入图片: 224×224×3 ↓ Vision Encoder (ViT): - 切分为 patch: 14×14 → (224/14)^2 = 256 个 patch - 每个 patch → embedding (1024 维) - 输出: [256, 1024] ↓ Linear Projection: - 将 1024 维投影到 LLM 的 hidden size (如 4096) - 输出: [256, 4096] — 等同于 256 个 token 的 embedding ↓ 拼接到文本 prompt 前: [img_token_1, ..., img_token_256, text_token_1, ...]
视觉 token 对推理的影响
结论：多张图片会显著增加 KV Cache 大小，进而增加推理延迟和显存需求。
高分辨率处理策略
解决方案： 1. 动态分辨率：根据内容复杂度自适应选择分辨率 2. Patch 合并：将相邻 patch 合并为一个 token 3. 多级编码：先全局粗编码，再局部细编码 4. 按需编码：只编码用户关注的区域
多模态模型的部署挑战
1. 显存需求增加
7B LLM + CLIP ViT-L： LLM 权重（INT8）：7GB Vision Encoder：0.6GB KV Cache（含视觉 token）：额外 ~20%
总显存增加约 25-30%
2. 首 token 延迟
纯文本请求： Prefill → 首 token（~100ms）
多模态请求： Vision Encode → 投影 → Prefill → 首 token（~150ms） 增加了视觉编码的固定开销
3. Batch 大小限制
视觉 token 占用 KV Cache 空间 → 同样显存下，多模态请求的 batch_size 更小 → 吞吐下降
4. 多模态流式输出
纯文本流式：每个 token 独立输出 多模态流式：可能需要同时输出文本和图片 → 需要支持图片编码和传输 → 前端需要支持图片渲染
生产环境部署架构
优化策略
主流多模态模型对比
面试视角
Q: "多模态模型和纯文本模型的推理性能有什么差异？"
回答框架：
Q: "多模态模型的 KV Cache 怎么计算？"
KV Cache = 文本 KV + 视觉 KV
文本 KV = 2 × layers × batch × seq_len × kv_heads × head_dim × 2 视觉 KV = 2 × layers × batch × num_patches × kv_heads × head_dim × 2
总 KV Cache = 文本 KV + 视觉 KV
Q: "多模态部署中最容易优化的点是什么？"
学习助手
