模型参数解密：7B、13B、70B、671B 到底意味着什么

《大模型知识与部署》系列 · No.03 / 35
适合人群：AI 工程师、后端开发、技术决策者
阅读时间：约 25 分钟

---

写在前面

在第 1 篇我们做了大模型生态全景，在第 2 篇我们拆解了 Transformer 的骨架。这一篇，我们来聊一个最常被问、最常被误解的话题：

模型参数量到底意味着什么？

如果你做大模型工程，下面这些对话你一定不陌生：

产品：「咱们用 7B 还是 13B？」
老板：「DeepSeek 那个 671B 听起来很猛，咱们能跑吗？」
运维：「这个 70B 单卡能跑吗？要几张 H100？」
算法：「这个场景 7B 够不够？要不要上 32B？」

每一个问题，背后都隐藏着对参数量与工程现实的对应关系的认知缺失。

很多人以为「参数量」就是一个简单的数字——7B、13B、70B 越大越好。但实际上：

• 同样是 70B，FP16 和 INT4 的显存差 4 倍
• 同样标着 671B，DeepSeek V3 真正激活的只有 37B
• 同样能跑 70B，A100 和 H100 的吞吐差 3-5 倍
• 小模型不一定弱——Qwen-3-32B 已经能干掉早期的 Llama-2-70B

读完这一篇，你将能回答：

1. 一个 N B 的模型，参数从哪里来？怎么估算？
2. 跑这个模型需要多少显存？训练呢？
3. 它需要多少算力？训练成本和推理成本怎么算？
4. 不同场景下，到底该选多大的模型？
5. Dense 和 MoE 的参数账，区别在哪里？

我们开始。

---

一、为什么「7B」是一个被简化的数字

1.1 一个混乱的现状

打开 HuggingFace，你会看到这样的命名：

meta-llama/Llama-3-8B
meta-llama/Llama-3-8B-Instruct
meta-llama/Llama-3-8B-Instruct-AWQ-INT4
Qwen/Qwen3-72B
Qwen/Qwen3-72B-MoE-A14B
deepseek-ai/DeepSeek-V3
deepseek-ai/DeepSeek-V3-Base

光看名字，你大概能猜到几个数字：8B、72B、A14B、V3。但每个数字背后的工程含义截然不同：

名字	实际意义
Llama-3-8B	8B 总参数 Dense 模型，FP16 推理时占 16 GB
Llama-3-8B-Instruct-AWQ-INT4	同样 8B，但 4-bit 量化后只占 5 GB
Qwen3-72B-MoE-A14B	72B 总参数，但每次只激活 14B（A=Activated）
DeepSeek-V3	671B 总参数，每次激活 37B

关键认知："参数量"是一个被简化的描述，它至少需要附带三个补充信息才有工程意义：

1. 架构类型：Dense 还是 MoE？激活参数是多少？
2. 数据精度：FP32 / FP16 / BF16 / INT8 / INT4？
3. 包含哪些参数：是否含 Embedding？是否含 LM Head？

1.2 这些问题为什么重要

抛开虚的，工程师真正关心的是：

给我一张 GPU（或一个集群），我能跑动什么规模的模型？吞吐和延迟是多少？训练这个模型要多少钱？

参数量是回答上面所有问题的第一个输入。但只看参数量是不够的——你还需要把它和：

• 显存（决定能不能跑）
• 算力（决定有多快）
• 上下文长度（决定能处理多长输入）
• 量化策略（决定占多少资源）

结合起来，才能得到一个可操作的工程答案。

这一篇我们就把这套账，一笔一笔算清楚。

---

二、参数量从哪里来：拆解大模型的「肚子」

2.1 一个 Transformer Block 的参数构成

回忆第 2 篇我们讲过的 Transformer Block 结构：

输入 x → LayerNorm → Self-Attention → ⊕ → LayerNorm → FFN → ⊕ → 输出

每个 Block 里有参数的地方就两处：Self-Attention 和 FFN（LayerNorm 的参数极少可以忽略）。

设隐藏维度为 d：

Self-Attention 的参数：

Q 投影矩阵：d × d
K 投影矩阵：d × d
V 投影矩阵：d × d
O 投影矩阵：d × d
─────────────────
合计：4d²

FFN 的参数（以 SwiGLU 为例，主流大模型用这个）：

W_gate：d × d_ff
W_up：d × d_ff
W_down：d_ff × d
─────────────────
合计：3 × d × d_ff

实际工程上 d_ff ≈ 8/3 × d（Llama 系列）或者 d_ff = 4d（早期 GPT），所以 FFN 部分大致 8d² 到 12d²。

单层合计：约 4d² + 8d² = 12d² ~ 16d²

2.2 整个模型的参数预算

加上 Embedding 和 LM Head（输入和输出的词表映射），一个 L 层、隐藏维度 d、词表大小 V 的 Dense 模型，参数估算公式：

N ≈ L × (12 ~ 16) × d² + 2 × V × d
                                                        
   ↑─── Transformer Blocks ───↑   ↑── Embedding ──↑

我们用这个公式验证几个真实模型：

Llama-3-8B：

• L = 32, d = 4096, V ≈ 128K, FFN 是 SwiGLU（d_ff = 14336）

每层 attention 参数（GQA, 8 KV heads）：

• Q: 4096 × 4096 ≈ 16.8M
• K: 4096 × 1024 ≈ 4.2M（GQA 把 KV head 数减少了）
• V: 同 K
• O: 4096 × 4096 ≈ 16.8M
• 合计：≈ 42M

每层 FFN：

• 3 × 4096 × 14336 ≈ 176M

每层合计：≈ 218M
32 层：≈ 7 B
加 Embedding (128K × 4096) + LM Head ≈ 1 B
总计：≈ 8 B ✓

Llama-3-70B：

• L = 80, d = 8192, num_heads = 64, kv_heads = 8

每层 attention ≈ 134M
每层 FFN（d_ff = 28672）≈ 704M
每层合计 ≈ 838M
80 层 ≈ 67 B
加 Embedding 等 ≈ 3 B
总计：≈ 70 B ✓

DeepSeek-V3（MoE）：

• L = 61, d = 7168, 256 个专家（每个 token 激活 8 个）
• 单个专家 FFN ≈ 2048 维度的小 FFN

这就涉及到一个新概念了——Dense 和 MoE 的参数账要分两本。

2.3 Dense vs MoE：参数账分两本

回忆第 2 篇我们提到的：FFN 占了 Dense 模型 70% 以上的参数。MoE 的核心思想是：

把一个巨大的 FFN，拆成 N 个小 FFN（叫"专家"），每个 token 只激活其中几个。

Dense 模型（如 Llama-3-70B）：

• 总参数 = 激活参数 = 70B
• 每个 token 走过所有参数

MoE 模型（如 DeepSeek-V3）：

• 总参数 = 所有专家 + 共享层 = 671B
• 激活参数 = 每个 token 实际用到的 ≈ 37B
• 每个 token 只走过部分专家

工程上为什么这样设计？

• 模型容量 ≈ 总参数（决定知识储量）
• 推理算力 ≈ 激活参数（决定计算量）
• 结论：MoE 让你用"小模型的推理成本"换"大模型的知识储量"

但它不是免费午餐：

视角	Dense 70B	MoE 671B/A37B
推理算力	高（全参数过一遍）	低（只激活 37B）
推理显存	中（140 GB FP16）	高（1.3 TB FP16，要装全部专家）
部署门槛	中（2 张 H100 够用）	高（需要 8+ H100 集群）
训练复杂度	低	高（路由算法、专家负载均衡）

👉 MoE 的工程细节、专家路由、负载均衡，详见 系列第 31 篇：MoE 架构深度解析。

2.4 一张表看清主流模型

我们把主流模型放在一起，方便建立"参数→规模"的直觉：

模型	类型	总参数	激活参数	层数 L	隐藏维度 d	用途
Qwen3-0.6B	Dense	0.6B	0.6B	28	1024	端侧
Phi-4	Dense	3.8B	3.8B	32	3072	端侧/笔记本
Llama-3-8B	Dense	8B	8B	32	4096	单卡推理
Qwen3-14B	Dense	14B	14B	40	5120	单卡推理
Qwen3-32B	Dense	32B	32B	64	5120	单卡 H100
Llama-3-70B	Dense	70B	70B	80	8192	双卡 H100
Mixtral 8x22B	MoE	141B	39B	56	6144	中型集群
Qwen3-A22B-MoE	MoE	235B	22B	94	5120	中型集群
DeepSeek-V3	MoE	671B	37B	61	7168	大型集群

记住几个锚点数字——以后看到任何模型，先用这张表对照：

• 7-8B：边缘/单卡级别
• 13-14B：中型单卡
• 30-32B：单 H100 极限
• 70B：双卡 H100 起步
• 200B+ MoE：进入集群部署

---

三、参数对应的工程账：显存、算力、成本

理解了参数从哪来，下面进入工程师最关心的部分——这些参数实际"吃"多少资源。

3.1 显存账：能不能跑的根本问题

部署一个大模型时，显存被四部分吃掉：

推理显存 = 模型权重 + KV Cache + 激活值 + 框架 Buffer
训练显存 = 模型权重 + 梯度 + 优化器状态 + 激活值 + KV Cache

模型权重：直接乘 dtype 大小

不同精度的"字节单价"：

精度	每参数字节数	备注
FP32	4	训练时常用，推理几乎不用
FP16 / BF16	2	标准推理精度
INT8 / FP8	1	主流量化精度
INT4 / NF4	0.5	极限压缩，端侧常用

模型权重显存 = 参数量 × 每参数字节数

举例（FP16）：

模型	参数量	FP16 显存	INT8 显存	INT4 显存
Llama-3-8B	8B	16 GB	8 GB	4 GB
Llama-3-70B	70B	140 GB	70 GB	35 GB
DeepSeek-V3	671B	1342 GB	671 GB	336 GB

⚠️ MoE 模型的显存陷阱
DeepSeek-V3 虽然只激活 37B 参数，但推理时所有专家的权重都必须在显存里（你不知道下一个 token 会路由到哪些专家）。所以 671B 占 1.3 TB（FP16）跑不掉。

KV Cache：上下文越长，吃得越凶

第 2 篇推导过的公式：

KV_cache = 2 × batch × seq_len × num_layers × num_kv_heads × head_dim × dtype_size

以 Llama-3-70B、batch=1、上下文 32K、FP16 为例：

2 × 1 × 32768 × 80 × 8 × 128 × 2 ≈ 10.7 GB

如果 batch 提到 8，就是 85.6 GB——比模型权重显存（70B INT8 = 70 GB）还多。

这就是为什么所有推理框架都把 KV Cache 量化（FP8 / INT8） 当作重要优化。

训练显存：更复杂

训练时除了权重和激活值，还有 梯度 和 优化器状态：

权重 (FP16):       N × 2 bytes
梯度 (FP16):       N × 2 bytes
优化器状态 (AdamW): N × 8 bytes (两组 moments × FP32)
激活值:            和 batch、seq_len 强相关
────────────────────────────────
合计 ≈ 12N + 激活值

对一个 70B 模型，光这三部分就要 70 × 12 = 840 GB——远超任何单卡。所以训练 LLM 必须分布式（ZeRO / FSDP / TP / PP），具体见 系列第 6 篇：预训练全流程 和 第 20 篇：分布式推理。

一张显存总览表

单 H100（80 GB）能跑什么（FP16 推理 + KV Cache, batch=4, seq=4K）：

模型	权重	KV Cache	合计	H100-80G 能跑？
Llama-3-8B	16 GB	1.3 GB	~18 GB	✓ 富余
Qwen3-32B	64 GB	6 GB	~72 GB	✓ 紧张
Llama-3-70B FP16	140 GB	11 GB	~152 GB	✗ 需要 2 张
Llama-3-70B INT8	70 GB	6 GB	~78 GB	✓ 极限
Llama-3-70B INT4	35 GB	6 GB	~42 GB	✓ 富余
DeepSeek-V3 INT8	671 GB	较大	>700 GB	✗ 需要 8-16 卡

3.2 算力账：要多快、训多久

推理算力：每生成一个 token 多少 FLOPS

工程上有一个粗略但好用的公式：

推理 FLOPS / token ≈ 2 × N_active

其中 N_active 是激活参数。这个公式忽略了 attention 的 O(seq²) 部分，但 prompt 不超长时基本够用。

举几个数字（每生成 1 个 token 的 FLOPS）：

• Llama-3-8B：2 × 8B = 16 GFLOPS
• Llama-3-70B：2 × 70B = 140 GFLOPS
• DeepSeek-V3：2 × 37B = 74 GFLOPS（注意是激活参数）

H100 SXM 的算力：约 989 TFLOPS（FP16）。理论上一秒能算：

• Llama-3-70B：989T / 140G ≈ 7000 tokens/s（单序列峰值）
• DeepSeek-V3：989T / 74G ≈ 13000 tokens/s

但实际部署受 显存带宽（不是算力）限制，因为推理是 memory-bound：

实际推理速度 ≈ 显存带宽 / 模型权重大小

H100 显存带宽 ≈ 3.35 TB/s，跑 Llama-3-70B INT8（70 GB）：

3.35 TB/s / 70 GB ≈ 48 tokens/s（单序列）

这就是为什么并发批处理（Continuous Batching）至关重要——多个请求共享一次权重读取，能把 GPU 利用率从 5% 拉到 80%+。

👉 详见 系列第 11 篇：推理加速三板斧。

训练算力：经典公式 6ND

Chinchilla 论文给出了训练总算力的估算：

训练 FLOPS ≈ 6 × N × D

其中：

• N：模型参数量
• D：训练 token 数

经验法则（Chinchilla 定律）：当算力固定时，最优的 D ≈ 20 × N。

举例：

• Llama-3-70B 训练用了 15 T tokens
• 训练 FLOPS ≈ 6 × 70B × 15T = 6.3 × 10²⁴ FLOPS = 6.3 ZFLOPS

一张 H100 SXM 一年算力 ≈ 989 TFLOPS × 86400 × 365 × 0.4（利用率）≈ 1.25 × 10²² FLOPS

所以训练 Llama-3-70B 需要 约 500 张 H100 跑一年——和官方公开的数字（~6.4 M H100 小时 ≈ 730 卡年）量级吻合。

3.3 成本账：训练 vs 推理

训练成本

把 GPU 小时 × 单价就能估算：

项目	GPU 小时	单卡价格（市场租赁）	训练成本
Llama-3-70B	~6.4M H100 小时	$2/小时	~$13M
DeepSeek-V3	~2.8M H800 小时	$2/小时	$5.6M ⭐
GPT-4	估算 ~50M H100 小时	$2/小时	~$100M+

DeepSeek V3 的 557 万美元 之所以震撼，是因为它用相对较少的算力做出了顶级效果——核心靠的是 MoE 架构 + 算法优化。

👉 详见 系列第 6 篇：预训练全流程。

推理成本

主流 API 单价（每 100 万 token，2026 年 5 月参考）：

模型	输入	输出	备注
Claude Opus 4.7	$15	$75	顶级
GPT-5	$10	$40	旗舰
Claude Sonnet 4.6	$3	$15	平衡
Gemini 2.5 Pro	$2.5	$10	长上下文便宜
Gemini 2.5 Flash	$0.15	$0.6	廉价大流量
DeepSeek V3 API	$0.27	$1.1	极致性价比
自部署 Llama-3-70B INT8	~$0.5	~$2	含 GPU 折旧

一个关键判断：如果你的业务量已经稳定，且月度 API 账单 > $5K，自部署开源模型几乎一定能省钱。具体的 TCO 测算见 系列第 25 篇。

---

四、选型决策：什么场景用什么规模

讲了一堆数字，最终落到工程师最常做的事——选型。

4.1 按显卡来选

给定你手头有的卡，能跑多大模型（INT8 推理为基准）：

显卡	显存	推荐最大模型	备注
RTX 4090	24 GB	14B (INT4) / 7B (FP16)	个人开发
RTX 5090	32 GB	32B (INT4) / 14B (FP16)	个人/小团队
A10 / L40	24-48 GB	8-14B	中小企业
A100 40G	40 GB	32B (INT4)	历史选项
A100 80G	80 GB	70B (INT8)	主流单卡
H100 80G	80 GB	70B (INT8)	性能更高
H200 141G	141 GB	70B FP16 / 110B INT8	长上下文友好
H100 × 8	640 GB	DeepSeek-V3 INT8	中等集群
H100 × 16	1280 GB	DeepSeek-V3 FP16	大型集群

👉 GPU 详细对比见 系列第 21 篇：GPU 选型指南。

4.2 按业务场景来选

场景	推荐规模	典型选择
端侧/移动	0.5B - 3B	Qwen3-0.6B、Phi-4
本地开发	7B - 14B	Llama-3-8B、Qwen3-14B
轻量企业服务	14B - 32B	Qwen3-32B、Mixtral 8x7B
生产级 ToC	32B - 70B	Llama-3-70B、Qwen3-72B
高质量生成	70B+ Dense / MoE	Qwen3-MoE、闭源 API
高并发 / 极致成本	MoE 200B+	DeepSeek-V3

4.3 选型时的三大常见误区

误区 1：「参数越多效果越好」

事实：参数量决定能力上限，但实际效果还看：

• 训练数据质量与规模
• 对齐与微调质量
• 评测任务的匹配度

举例：Qwen3-32B 在中文任务上经常超过 Llama-3-70B。

误区 2：「小模型不行」

事实：

• Phi-4 (3.8B) 在数学任务上超过早期 Llama-2-70B
• Qwen3-0.6B 在端侧能跑出 30 tokens/s
• 小模型 + 针对性微调 在垂直场景常常比大模型通用更好

误区 3：「MoE 一定省」

事实：

• 推理算力省（激活参数小）
• 显存反而大（要装全部专家）
• 路由开销和 专家负载不均衡 是新的工程难点

MoE 适合什么场景？ 高并发服务端、有大集群、能接受复杂部署。
不适合什么？ 单卡部署、低并发、需要极简运维的场景。

---

五、扩展话题：参数效率与未来趋势

5.1 量化：让"参数"瘦身

参数量本身没变，但实际占用资源可以大幅缩减：

量化方法	比特数	显存占用	效果损失	当下地位
FP16 / BF16	16	1×	基线	标准
FP8	8	0.5×	极小	H100+ 推荐
INT8 (W8A16)	8	0.5×	极小	生产主流
AWQ INT4	4	0.25×	小	端侧首选
GPTQ INT4	4	0.25×	小	服务端
INT2 / 1.58bit	2	0.125×	较大	实验性

👉 详见 系列第 12 篇：量化压缩实战。

5.2 蒸馏：把大模型的能力"装进"小模型

经典思路：用大模型生成数据 / 软标签，训练一个小模型。

典型案例：

• DeepSeek-R1-Distill-Llama-8B：把 R1 的推理能力蒸馏到 8B
• Phi 系列：用 GPT-4 合成"教科书级数据"训练 3.8B

工程意义：让端侧也能用上前沿能力。

5.3 推理时 Scaling：把算力转到"推理"

2024 年 9 月 OpenAI o1 之后，行业出现了一个新方向：

不再无止境扩参数，而是让模型在推理时"多想几步"。

这就是 Test-Time Scaling——参数量不变，但生成时让模型先输出大段"思考链"再给答案。延迟换效果。

这意味着未来：

• 训练算力增长放缓
• 推理算力大幅上升
• 参数量不再是唯一指标，"推理预算"成为新维度

👉 详见 系列第 32 篇：推理模型原理。

5.4 端侧大模型的崛起

2026 年的另一个趋势是端侧大模型。靠的是：

• 小模型架构创新（Phi、Gemma 系列）
• 极致量化（INT4 / INT2）
• 端侧推理框架（llama.cpp / MLX / MNN）

最近的 Qwen3-1.7B 已经可以在 iPhone 上跑 30 tokens/s，端侧大模型时代正在到来。

👉 详见 系列第 33 篇：端侧大模型。

---

结语：把参数翻译成工程语言

读完本文，下次再看到一个新模型，你应该可以快速回答这套问题：

1. 总参数 / 激活参数 多少？是 Dense 还是 MoE？
2. FP16 / INT8 / INT4 各占多少显存？
3. 能不能放进我手里的卡？需要几张？
4. 大致推理算力是多少？吞吐期望是多少？
5. 训练这个模型大概多少钱？
6. 业务场景是否真的需要这个规模？

把每个数字都"翻译成工程语言"——这是大模型工程师区别于"会用 API 的开发者"的核心能力之一。

接下来：

• 下一篇（第 4 篇）：Tokenizer 那些事——BPE、SentencePiece、中文分词的爱恨情仇。你会发现"参数量"之外还有一个"Token 量"，它直接影响输入/输出成本。
• 再往后我们会进入上下文窗口（第 5 篇）、预训练（第 6 篇）、微调（第 7 篇）等更工程化的话题。

我们下篇见。

---

📮 关于「码海寻道」
这里是一个聚焦 AI 工程化、大模型部署、后端架构实战的技术专栏。
写最一线的踩坑经验，做最务实的技术拆解。

如果这篇文章对你有启发，欢迎点赞、转发、关注。我们下篇见。