模型理解

层级	看什么	目的
1	模型定位	它是干嘛的
2	模型规模	多大、Dense 还是 MoE
3	能力类型	推理？翻译？代码？多模态？
4	架构设计	Transformer? MoE? MLA? Mamba?
5	训练数据	用什么数据喂出来的
6	推理部署	吃多少显存、支持哪些量化
7	Benchmark	实际强在哪
8	工程生态	vLLM/SGLang/GGUF/LoRA 是否支持

---

你列的这三个点（2 模型规模、4 架构设计、8 工程生态）其实是理解一个开源大模型“能不能用、好不好训、值不值得部署”的核心。

很多人只看参数量，但真正决定：

• 推理成本
• 显存需求
• 并发能力
• 长上下文能力
• 微调难度
• 工程兼容性

的，实际上是 架构 + 工程生态。

下面我按“底层逻辑 → 关键概念 → 实际影响 → 怎么看模型”的方式展开。

---

2. 模型规模（Model Scale）

很多人以为：

“70B 一定比 7B 强”

其实并不一定。

现在必须区分：

维度	含义
参数总量（Total Params）	模型一共有多少参数
激活参数（Active Params）	每次推理真正参与计算的参数
Dense / MoE	是否所有参数都参与计算
上下文长度	能处理多少 token
KV Cache 大小	推理时真正吃显存的大头

---

一、Dense 模型

例如：

• Meta 的 Llama 3 70B
• Qwen 的 Qwen2.5-72B

Dense：

所有参数每次推理都会参与计算。

---

Dense 的结构

比如：

输入
 ↓
Transformer Layer 1
 ↓
Transformer Layer 2
 ↓
...
 ↓
输出

每层里的参数全部参与。

所以：

70B Dense
≈
每个 token 都要计算 700 亿参数

---

Dense 的特点

优点

1. 稳定

训练简单。

推理行为稳定。

不容易出现：

• 专家失衡
• routing 崩溃
• token 偏科

---

2. 工程兼容性最好

几乎：

• vLLM
• SGLang
• TensorRT-LLM
• llama.cpp
• GGUF

全部支持。

---

3. 微调容易

LoRA 非常成熟。

因为：

所有层都会参与训练

不会遇到：

专家层到底训哪个？

的问题。

---

Dense 的缺点

最大问题：

推理成本极高

因为：

所有参数都要算

---

举例

72B Dense

虽然模型“只有”72B。

但：

• 显存巨大
• 算力消耗巨大
• KV Cache 巨大

部署成本非常高。

---

二、MoE（Mixture of Experts）

这是现在最重要的方向。

例如：

• DeepSeek 的 DeepSeek-V3
• Mistral AI 的 Mixtral 8x7B

---

MoE 的核心思想

不是：

所有参数都算

而是：

只激活部分专家

---

类比

Dense：

全公司一起干活

MoE：

根据任务找专家

例如：

• 写代码 → code expert
• 中文 → chinese expert
• 数学 → reasoning expert

---

MoE 结构

简化理解：

输入 token
   ↓
Router（路由器）
   ↓
选择 Top-K Experts
   ↓
只计算这几个专家

---

关键概念

1. Total Params

总参数。

例如：

DeepSeek-V3
671B total params

---

2. Active Params

真正参与计算的。

例如：

每次只激活 37B

所以：

671B 的能力
≈
37B 的推理成本

这就是 MoE 的革命性。

---

为什么 MoE 强？

因为：

参数容量巨大
+
推理成本较低

Dense 不可能无限扩大。

因为：

计算量线性爆炸

但 MoE 可以：

参数继续扩
但激活量不变

---

为什么 DeepSeek 很震撼？

因为它实现了：

超大参数
+
相对低推理成本

这是 Dense 做不到的。

---

MoE 的问题

1. 工程复杂

最大问题：

专家并行

不同 GPU 上有不同 expert。

于是：

token 要跨卡通信

这会导致：

• all-to-all 通信
• NVLink 压力
• RDMA 压力

---

2. 推理框架支持复杂

很多框架：

• Dense 很成熟
• MoE 不成熟

尤其：

• expert parallel
• dynamic routing
• load balancing

很难。

---

3. 微调复杂

LoRA 不一定知道：

该训哪些 expert

---

怎么看 MoE 模型？

重点看：

指标	含义
Total Params	总容量
Active Params	真正推理成本
Experts 数量	专家个数
Top-K	每次激活几个专家
Shared Expert	是否有共享专家
Routed Expert	动态专家

---

三、为什么“7B 打不过 32B”已经不成立？

因为：

现在：

• 数据质量
• 架构
• tokenizer
• RL
• 蒸馏

影响更大。

例如：

• 新 7B 可能打过
• 老 34B

---

四、KV Cache 才是真正显存大户

很多人误以为：

参数 = 显存

其实长上下文下：

KV Cache 才是显存怪兽

---

KV Cache 是什么

Transformer 推理时：

每个 token 的：

• Key
• Value

都会缓存。

上下文越长：

缓存越大

---

为什么 128K 很贵？

因为：

KV Cache：

随上下文线性增长

例如：

8K → 128K
显存可能爆炸 16 倍

所以：

很多模型虽然支持：

128K

但：

根本跑不起

---

4. 架构设计（Architecture）

这是模型的“内功”。

真正决定：

• 长文本能力
• 推理速度
• 显存占用
• 训练稳定性

---

一、Transformer

所有现代 LLM 的祖宗。

论文：

Transformer

---

Transformer 核心

最核心：

Attention

本质：

让 token 互相查看

---

致命问题

Attention 复杂度：

O(n²)

上下文翻倍：

计算暴涨。

---

二、MLA（Multi-head Latent Attention）

DeepSeek 爆火的重要原因之一。

例如：

• DeepSeek-V2
• DeepSeek-V3

---

MLA 解决什么问题？

核心：

减少 KV Cache

---

为什么重要？

因为：

长上下文时代：

KV Cache > 模型参数

尤其：

• 128K
• 1M context

根本扛不住。

---

MLA 的思想

传统 Attention：

每个 head
都保存完整 KV

MLA：

先压缩到 latent space

类似：

高维 → 低维

---

效果

DeepSeek 的论文核心之一：

KV Cache 大幅降低

所以：

同样显存：

• 能跑更长上下文
• 更高并发

---

三、Mamba

Mamba 是另一条路线。

不是 Transformer 系。

Mamba

---

Mamba 核心思想

不用 Attention。

而是：

状态空间模型（SSM）

---

为什么有人研究它？

因为：

Transformer 的 Attention：

O(n²)

太贵。

Mamba：

接近 O(n)

长文本理论上极强。

---

Mamba 的问题

1. 生态差

很多：

• CUDA kernel
• 推理框架
• FlashAttention

都围绕 Transformer。

---

2. 能力不稳定

目前：

• reasoning
• instruction following

还没完全证明超越 Transformer。

---

四、Hybrid 架构

现在很多模型：

Transformer + Mamba

混合。

目的：

兼顾：
- 长文本
- 推理能力

---

五、GQA / MQA

这是“Attention 优化”。

---

Multi-Head Attention

传统：

每个 query
都有独立 KV

很贵。

---

MQA

多个 query：

共享 KV

大幅降低：

• KV Cache
• 显存

但能力可能下降。

---

GQA

Grouped Query Attention。

折中方案。

现在主流：

• Llama 3
• Qwen2

大量使用。

---

8. 工程生态（最容易被低估）

很多模型：

论文很强。

但：

根本不好部署

---

一、vLLM

现在事实标准。

vLLM

---

vLLM 为什么重要？

核心技术：

PagedAttention

解决：

KV Cache 碎片化

---

没有 vLLM 的时代

GPU 显存浪费严重。

因为：

不同请求长度不同。

KV Cache 无法高效复用。

---

vLLM 的价值

让：

吞吐量暴增

尤其：

• 多用户
• 高并发

场景。

---

为什么很多模型先看：

是否支持 vLLM

因为：

不支持 = 很难生产部署

---

二、SGLang

SGLang

---

SGLang 强在哪？

重点：

推理编排

不是单纯推理。

---

它适合：

• Agent
• Tool Calling
• Structured Output
• 多轮推理

---

为什么它火？

因为：

LLM 已经不是：

单轮聊天

而是：

复杂推理流程

---

三、GGUF

GGUF：

llama.cpp 的模型格式

llama.cpp

---

为什么 GGUF 重要？

因为：

消费级部署

---

它解决：

1. CPU 推理

没有 GPU 也能跑。

---

2. Mac 部署

Apple Silicon 神器。

---

3. 量化

例如：

• Q2
• Q4
• Q5
• Q8

---

量化本质

例如：

FP16：

16 bit

Q4：

4 bit

显存：

直接降低 75%

---

为什么 Ollama 能火？

因为：

背后：

llama.cpp + GGUF

生态。

---

四、LoRA

LoRA 是：

低成本微调

Low-Rank Adaptation

---

为什么 LoRA 革命性？

以前：

全量微调

要：

• 巨大显存
• 巨大数据

---

LoRA：

只训练小矩阵

于是：

7B 模型
单卡也能微调

---

五、AWQ / GPTQ / FP8

这是量化生态。

---

GPTQ

老牌量化。

优点：

• 兼容性强

缺点：

• 精度损失较大

---

AWQ

现在热门。

核心：

保护重要权重

效果通常比 GPTQ 好。

---

FP8

未来方向。

例如：

• NVIDIA 的 H100
• Blackwell

都非常强调 FP8。

---

六、为什么“生态支持”比 Benchmark 更重要？

因为：

很多模型：

榜单很强

但：

• vLLM 不支持
• TensorRT 不支持
• 没有量化
• 没有 GGUF
• 没有 LoRA

结果：

根本没人用

---

七、现在看模型最重要的思维方式

不要只看：

参数量

而要看：

能力 / 成本比

真正重要的是：

维度	本质
Dense vs MoE	推理成本
MLA/GQA	KV Cache
Context	长文本能力
vLLM/SGLang	生产可用性
GGUF	消费级部署
LoRA	微调生态
Quantization	显存成本

---

最后给你一个“读模型”的真实顺序

我实际会按这个顺序看：

顺序	看什么	真正目的
1	Dense / MoE	推理成本
2	Active Params	实际吃卡
3	Attention 架构	KV Cache 大小
4	Context Length	长文本能力
5	是否支持 vLLM	能否生产部署
6	是否有 GGUF	能否本地跑
7	是否支持 LoRA	能否低成本微调
8	Benchmark	最后才看排行榜

因为：

部署不了的模型
≈
不存在