大语言模型和视觉语言模型技术指南：从 Transformer 到多模态系统，全景看懂主流路线

这两年，大家聊 AI，几乎绕不开两个词：LLM 和 VLM。

前者是大语言模型，负责“理解和生成文本”；后者更准确地说，很多时候已经不是单纯的视觉语言模型，而是更接近多模态大模型（MLLM），负责“把图像、文本，甚至视频、音频一起接进统一系统里”。

但很多人对这条技术线的理解，还是碎片化的。

有人知道 Transformer 很重要，但说不清它为什么能成为基础架构；有人知道 LLM 参数很大、上下文很长，却不知道这些参数到底意味着什么；也有人已经在部署 Qwen、Llama、Qwen-VL 或者 LLaVA，但对模型思想、工程约束、参数影响之间的关系并没有真正串起来。

这篇文章不展开到过细的公式推导，而是先做一件更重要的事：

把 LLM、VLM、MLLM 这条主线的整体地图搭起来。

我想回答的是这几个问题：

• Transformer 为什么会成为这一代模型的基础架构？
• LLM 和 VLM 到底是什么关系？
• 模型规模、上下文长度、图像分辨率这些参数，到底在影响什么？
• 真正部署时，本地、单机多卡、API 服务化各自意味着什么？
• 如果你要开始做这条线，学习顺序和工程顺序应该怎么排？

---

一、先把几个概念摆正：LLM、VLM、MLLM 到底是什么

如果只说一句最粗的定义：

• LLM（Large Language Model）：以文本 token 为核心建模对象的大模型
• VLM（Vision-Language Model）：同时处理视觉和语言信息的模型
• MLLM（Multimodal Large Language Model）：以语言模型为中心，接入图像、音频、视频等多种模态的大模型系统

严格来说，现在很多被叫作 VLM 的系统，其实更像 MLLM。

因为它们的核心不是“纯视觉理解模型”，而是：

• 前面接一个视觉编码器，把图像转成视觉 token 或视觉特征
• 中间做一个投影层 / 对齐模块，把视觉特征映射到语言模型能消费的表示空间
• 后面由一个 LLM 负责统一推理、对话、生成和任务执行

也就是说，今天主流路线并不是“重新造一个同时懂图像和文本的全新模型”，而更像是：

以 LLM 为认知中枢，把视觉能力外挂进来。

这条路线为什么成立？

因为语言模型已经在大规模预训练中学到了非常强的世界知识、任务迁移能力和指令跟随能力。相比从零训练一个全新的多模态巨型系统，把视觉模态接到成熟 LLM 上，性价比更高，也更容易复用已有生态。

---

二、为什么一切都从 Transformer 说起

如果看今天主流的 LLM、VLM、MLLM，它们虽然名字很多，但底层大都还是 Transformer 家族。

原因很简单：Transformer 把“序列建模”这件事做成了一个高度通用、可扩展、可并行训练的框架。

在 RNN 时代，模型的核心问题是顺序计算太重，长距离依赖难学，训练效率也上不去。

Transformer 的关键变化是把重点放到了 attention 上。

它不再强迫模型按时间步一个个传递状态，而是让当前位置直接去关注整段上下文里最相关的信息。

这样带来三个决定性优势：

• 并行性更强：训练时更适合 GPU / TPU 大规模并行
• 长距离依赖更容易建模：相关 token 可以直接建立联系
• 架构更通用：文本、图像 patch、音频帧，本质上都可以被表示成 token 序列

这最后一点尤其关键。

一旦“万物皆 token”，语言、图像、视频就都能被塞进同一种建模框架里。也正因为这样，Transformer 不只是催生了 LLM，也给 VLM/MLLM 提供了统一底座。

---

三、从文本 token 到图像 patch：多模态为什么能接进同一套框架

很多人第一次接触视觉语言模型时，会有个误解：

“图像和文本差别这么大，为什么能放进一个模型里？”

真正的关键，不是原始输入长得像不像，而是最终能不能被编码成统一的离散或连续表示序列。

在 LLM 里：

• 文本先经过 tokenizer
• 被切成 token id
• 再映射成 embedding

在 VLM 里：

• 图像先经过视觉编码器，比如 ViT
• 一张图被切成 patch
• 每个 patch 被编码成向量表示
• 再通过 projector 或 cross-attention 接到 LLM

所以从系统视角看：

• 文本变成文本 token 序列
• 图像变成视觉 token 序列
• 最终都喂进 Transformer 风格的统一推理链路

这也是为什么现在会频繁出现这些术语：

• image tokens
• visual embeddings
• projector
• cross-attention
• multimodal context

它们本质上都在解决同一个问题：

如何把“不是文字的东西”，变成语言模型能处理的上下文。

---

四、今天主流模型的大致分层

如果把当前主流系统粗略分层，可以分成下面几类。

1. 纯 LLM

代表思路：Llama、Qwen、Mistral、DeepSeek 等文本模型。

它们主要处理：

• 对话
• 写作
• 推理
• 代码生成
• 工具调用
• RAG 场景中的文本问答

核心输入是文本 token，部署时的重点通常是：

• 上下文长度
• 显存占用
• 推理吞吐
• 量化精度
• 并发能力

2. 视觉编码器 + LLM 的 VLM/MLLM

代表思路：LLaVA、Qwen-VL、MiniCPM-V、InternVL 等。

它们通常由三部分组成：

• vision encoder
• multimodal projector / adapter
• LLM backbone

这类系统的强项是：

• 图像问答
• OCR 增强理解
• 图表理解
• 文档解析
• GUI 理解
• 多图对话

部署时除了 LLM 的问题，还要多看：

• 图片分辨率
• 视觉 token 数量
• 预处理延迟
• 显存峰值
• 多图输入时的上下文膨胀

3. 面向复杂任务的系统化多模态应用

这类已经不只是单模型，而是完整系统。

例如：

• 文档理解系统：OCR + VLM + RAG + 表格解析
• 图表分析系统：视觉模型 + 代码执行 + 校验模块
• GUI Agent：截图理解 + action planning + tool use
• 多模态客服：图片输入 + 商品知识库 + 对话系统

这时候真正决定效果的，不只是模型本体，而是整个链路：

• 输入预处理
• 模型路由
• 检索增强
• 工具调用
• 结果校验
• 观测与回放

很多团队的问题不是“模型不够强”，而是把一个本应系统化处理的问题，错误地压缩成了“换个更大的模型试试”。

---

五、几个最重要的参数，到底在影响什么

这一节不追求穷尽，而是先把最常被提到、也最容易被误解的参数讲清楚。

1. 参数规模（Parameters）

比如 7B、14B、32B、72B。

它指的是模型可学习参数的大致数量级。

通常来说：

• 参数更多，表达能力和知识容量上限更高
• 但显存占用、推理延迟、部署成本也更高

不过要注意：

参数规模不是唯一指标。

训练数据质量、训练时长、架构细节、对齐方式，都会影响最终效果。

工程上更实用的理解是：

• 7B / 8B：适合本地实验、轻量部署、低成本服务
• 14B / 32B：常见于性能和成本平衡点
• 70B 级别以上：更适合高要求推理、多卡部署和高预算场景

2. 上下文长度（Context Length）

常见有 4K、8K、32K、128K，甚至更长。

它表示模型一次性能“看进去”的 token 上限。

上下文长度影响的是：

• 能放多少历史对话
• 能塞多少检索片段
• 能处理多长的文档
• 多图输入时还能剩下多少文本空间

但上下文变长不代表效果一定线性变好。

因为真实系统里还要考虑：

• 长上下文是否真的被训练过
• 注意力计算成本是否可承受
• KV cache 是否让显存暴涨
• 模型在超长上下文下是否仍然稳定

3. 图像分辨率（Image Resolution）

在 VLM 里，这是一个非常关键、但经常被忽略的参数。

例如：

• 224 × 224
• 448 × 448
• 768 × 768
• 更高分辨率 + tiling

分辨率越高，保留的细节通常越多，但也意味着：

• patch 数量更多
• 视觉 token 更多
• 推理更慢
• 显存占用更大

所以很多多模态系统的关键权衡其实是：

你到底是在追求更强的细节识别，还是更稳的在线吞吐？

4. Patch Size

如果视觉编码器用的是 ViT，常见会看到 patch size，比如 14、16。

直觉上可以这么理解：

• patch 越小，切得越细，保留局部细节更丰富
• 但 token 数量也更大，计算成本更高

比如同样一张图，patch size 从 16 减小到 14，视觉 token 数量就会上升，后续上下文占用和推理开销也会跟着变。

5. 量化位宽（Quantization Bit）

常见有 FP16、BF16、INT8、4bit。

它直接影响：

• 模型权重占用
• 推理显存需求
• 部署成本
• 一部分任务上的精度损失

实战里可以粗略理解成：

• FP16 / BF16：精度更稳，适合训练或高质量推理
• INT8：折中方案，常用于服务化优化
• 4bit：适合本地部署和低资源机器，但精度和稳定性要具体测试

6. 生成参数

最常见的是：

• temperature
• top-k
• top-p
• max tokens
• repetition penalty

这些参数更多影响“生成风格和采样行为”，而不是模型底层能力。

一个很实用的经验是：

• 做事实型问答、RAG、工具调用时，temperature 往往要低
• 做创意写作、开放生成时，temperature 可以高一些
• max tokens 既决定输出上限，也直接影响响应时延和成本

后面单独写推理参数时，我们再展开。

---

六、从研究到部署：真实系统里到底怎么选模型

如果只看论文榜单，很容易以为选模型就是“谁分高选谁”。

但真正部署时，排序标准完全不一样。

更现实的问题通常是：

• 你是本地部署，还是云上 API？
• 你要的是单轮高质量，还是高并发低延迟？
• 你面对的是文本任务，还是文档/图像任务？
• 你是 demo，还是生产系统？

所以我更建议按部署场景来选。

1. 本地个人实验 / 单机开发

典型特点：

• 显存有限
• 更看重部署简单
• 可以接受一定程度量化损失

常见方案：

• 7B~14B 量化模型
• Ollama、LM Studio、llama.cpp、vLLM（轻量试验）
• 对 VLM 则优先选较轻的多模态版本

这类场景最关键的不是极限效果，而是：

• 能不能稳定跑起来
• 响应速度能不能接受
• 是否方便切模型做对比

2. 团队内部服务 / 单机多卡

典型特点：

• 开始关心吞吐
• 开始有多用户并发
• 需要统一 API

常见方案：

• 14B~32B 或更大模型
• vLLM、SGLang、TGI 等推理框架
• 结合 tensor parallel、continuous batching、KV cache 优化

这类场景开始要认真看这些指标：

• TTFT（首 token 延迟）
• tokens/s
• 并发数
• GPU 显存峰值
• batch 合并效果

3. 生产级服务

典型特点：

• 稳定性比极限分数更重要
• 需要观测、限流、回滚、灰度发布
• 通常会做模型分层和任务路由

这时候一个成熟方案往往不是“一个最大模型打天下”，而是：

• 小模型处理高频简单请求
• 大模型处理复杂请求
• 检索、工具、规则模块一起承担部分任务
• 多模态链路按需触发，而不是每次都走最重模型

换句话说，部署本身就是模型能力的一部分。

如果部署策略错了，再强的模型也会被用废。

---

七、一个最容易被忽略的现实：VLM 的部署难度通常高于 LLM

很多人第一次从 LLM 转向 VLM，会低估工程复杂度。

因为在纯文本任务里，输入相对规整，系统瓶颈主要在 token 推理。

但到了 VLM，系统复杂度会明显上升：

• 图片解码和预处理要耗时
• 高分辨率会迅速放大视觉 token 数量
• 多图输入会压缩文本上下文空间
• OCR、图表、文档任务对分辨率和裁剪策略非常敏感
• 不同图片尺寸会导致吞吐波动更明显

所以 VLM 部署时，真正重要的问题通常不是“支不支持看图”，而是：

• 支持到什么分辨率最稳
• 多图时延是否还能接受
• 图片预处理链路是否可控
• 输入异常时有没有兜底
• 图像理解失败后是否能回退到 OCR + 文本链路

如果这些问题没想清楚，很多多模态 demo 一上线上就会出现两种结果：

• 要么慢得无法用
• 要么效果波动很大，用户完全不知道什么时候能信

---

八、如果你现在开始学这条线，我建议按这个顺序来

很多人一上来就想学最热的多模态模型，但我其实不建议这样。

更稳的顺序是：

第一步：先把 LLM 的底层骨架学明白

最起码要理解：

• Transformer 基本结构
• tokenizer 在干什么
• 预训练和指令微调的区别
• 推理阶段的 sampling 参数是什么意思
• context length、KV cache、量化大概在影响什么

如果这一步没打稳，后面看多模态模型时很容易只剩“记名词”。

第二步：再看系统层组件

包括：

• RAG
• tool use / function calling
• agent orchestration
• serving framework
• observability

因为真实应用里，模型很少单独存在。

第三步：再进入 VLM / MLLM

这时重点看：

• vision encoder 怎么工作
• projector / adapter 在做什么
• 图像 token 怎么接进 LLM
• 分辨率、patch、multi-image 为什么会影响成本和效果

这样学，会比一开始直接冲着某个爆款模型的论文细节更扎实。

---

九、一个实用的参数认知框架：别只记数字，要记“资源账”

我更建议把参数分成三类来理解。

1. 能力参数

例如：

• 参数规模
• 训练数据规模
• 上下文长度上限
• 是否支持图像 / 多图 / 视频

这些参数影响的是能力边界。

2. 成本参数

例如：

• 显存占用
• 量化位宽
• batch size
• 图像分辨率
• tensor parallel 数量

这些参数决定你要付出多少资源代价。

3. 行为参数

例如：

• temperature
• top-p
• max tokens
• repetition penalty
• tool choice / max steps

这些参数影响的是模型在具体任务里的输出行为。

很多部署事故，本质上都是把这三类参数混在一起看了。

比如：

• 拿行为参数去弥补能力不足
• 拿更大模型去掩盖系统设计问题
• 盲目拉高上下文和分辨率，却没算清显存和延迟

真正成熟的做法，不是“把参数都开大”，而是：

知道每个参数到底在买什么，又在牺牲什么。

---

十、给工程落地一个最小可执行建议

如果你现在就想开始做一个 LLM/VLM 项目，我建议先别追求一步到位。

一个更稳的起步组合是：

纯文本任务

• 先选一个 7B~14B 级别、生态成熟的指令模型
• 先跑通本地或内网 API
• 先测三件事：延迟、稳定性、任务命中率
• 如果知识不足，再补 RAG；如果动作不足，再补 tool use

图文任务

• 先明确任务到底是 OCR、图表理解、文档问答，还是开放图像问答
• 不要一开始就上最高分辨率
• 先做单图基线，再做多图
• 先测图片预处理耗时和显存峰值，再谈线上并发

服务化阶段

优先建立下面这些观测项：

• 请求长度分布
• 图片分辨率分布
• TTFT
• tokens/s
• GPU 占用
• 错误类型统计
• 幻觉 / 失败案例回放

因为没有观测，就没有真正的优化。

---

十一、这条技术线接下来该怎么读

从下一篇开始，这个系列会按顺序继续拆。

后面会重点展开这些问题：

• Transformer 的核心模块和关键参数怎么理解
• 预训练、SFT、RLHF、DPO 到底怎么串起来
• 长上下文、RoPE、KV cache 为什么直接影响部署
• LoRA、QLoRA、量化、本地部署应该怎么选
• VLM 里的视觉编码器、projector、多图机制到底怎么工作
• 从 benchmark 到业务指标，模型评测应该怎么看

如果你把今天这篇看成“地图”，那后面的文章就是把地图上的每一块逐步拆开。

---

十二、最后总结：别把 LLM 和 VLM 看成两个世界

如果只看表面，LLM 是文本，VLM 是图像，像是两条线。

但从技术演进看，它们其实是一条连续主线：

• Transformer 提供统一的序列建模底座
• LLM 提供强大的语言理解、知识压缩和任务迁移能力
• VLM / MLLM 则是在这个底座上，把视觉等模态逐步接进来

所以理解这条线，最重要的不是背多少模型名字，而是抓住三个核心问题：

• 模型思想：为什么结构会这样设计
• 工程部署：怎样把能力稳定释放出来
• 参数含义：每个关键参数到底影响什么

当这三件事串起来，你对 LLM 和 VLM 的理解，才会从“知道一些名词”，变成“真的能做系统”。