【学习笔记】模型参数解密：7B、13B、70B、671B 到底意味着什么（3/35）
在第 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
读完这一篇，你将能回答：
-
一个 N B 的模型，参数从哪里来？怎么估算？
-
跑这个模型需要多少显存？训练呢？
-
它需要多少算力？训练成本和推理成本怎么算？
-
不同场景下，到底该选多大的模型？
-
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 |
关键认知："参数量"是一个被简化的描述，它至少需要附带三个补充信息才有工程意义：
-
架构类型：Dense 还是 MoE？激活参数是多少？
-
数据精度：FP32 / FP16 / BF16 / INT8 / INT4？
-
包含哪些参数：是否含 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 Cache3.1.1 模型权重：直接乘 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）跑不掉。
3.1.2 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） 当作重要优化。
3.1.3 训练显存：更复杂
训练时除了权重和激活值，还有 梯度 和 优化器状态：
权重 (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 篇：分布式推理。
3.1.4 一张显存总览表
单 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 算力账：要多快、训多久
3.2.1 推理算力：每生成一个 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 篇：推理加速三板斧。
3.2.2 训练算力：经典公式 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 推理
3.3.1 训练成本
把 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 篇：预训练全流程。
3.3.2 推理成本
主流 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 篇：端侧大模型。
六、结语：把参数翻译成工程语言
读完本文，下次再看到一个新模型，你应该可以快速回答这套问题：
-
总参数 / 激活参数 多少？是 Dense 还是 MoE？
-
FP16 / INT8 / INT4 各占多少显存？
-
能不能放进我手里的卡？需要几张？
-
大致推理算力是多少？吞吐期望是多少？
-
训练这个模型大概多少钱？
-
业务场景是否真的需要这个规模？
把每个数字都"翻译成工程语言"——这是大模型工程师区别于"会用 API 的开发者"的核心能力之一。
参考文献：
免费领 200 小时云算力，进群参与显卡、AI PC 幸运抽奖
更多推荐
6
0- 0
已为社区贡献6条内容
所有评论(0)