“大模型的参数量为什么那么大”——这个问题我刚接触大模型时也困扰了很久。那时候看到 GPT-3 有 1750 亿参数第一反应是“这数字也太夸张了”第二反应是“这么多参数到底在干什么”后来自己动手训练过小模型、看过 Transformer 源码、也买过消费级显卡尝试微调 7B 模型之后才算真正摸清参数量的门道。这篇文章我想用一整篇的篇幅把“参数量为什么大”这件事从原理到实战彻底讲透。内容包括参数量到底是怎么算出来的、为什么参数少了模型就不行、算力成本是怎么被参数量推高的、以及你手上刚好有一块显卡想跑大模型时怎么估算显存。无论你是刚入门的开发者、想本地部署大模型的玩家还是想系统学习大模型原理的研究者这篇都能给你一个相对完整的视角。1. 参数量到底指什么先建立一个直观的量级感1.1 参数量就是“神经网络里的旋钮数量”先问一个最基础的问题参数量到底是什么从工程角度看参数量就是神经网络里所有“权重”和“偏置”的总个数。每个权重就是连接两个神经元之间的一条“线”的粗细系数每个偏置就是给神经元加的一个常数偏移。模型训练的本质就是在一次次前向传播和反向传播里把这些权重从随机值一点一点调整到能让输出接近正确答案的数值。用个通俗类比参数量就像一台收音机上的旋钮数量。一个老式收音机只有音量、频率两个旋钮能做的事很有限。一个专业调音台可能有上百个推子、旋钮、开关每个推子控制一个频段或一路输入你能做出的混合效果就复杂得多。但当旋钮太多时你调音的工作量也上去了而且每个旋钮调到什么位置需要海量的“声音样本”来教你。大模型就是把“旋钮”做到了数亿、数十亿甚至数千亿个。每个旋钮都对应一个浮点数这些浮点数组合在一起构成了模型的记忆和推理能力。1.2 一个模型里到底有哪些参数拿目前几乎所有主流大模型都采用的 Transformer 架构来说参数量主要分布在几个核心部分嵌入层Embedding负责把 Token 映射成向量参数量 词表大小 × 隐藏维度多头注意力层由 Q、K、V 投影矩阵和输出投影矩阵构成前馈网络层FFN通常是两层线性变换加激活函数是参数量占比最大的一块层归一化LayerNorm每个层有少量缩放参数输出层有时和嵌入层共享参数有时独立其中前馈网络层往往占到了总参数量的三分之二左右。这也是为什么很多模型在压缩参数时优先拿 FFN 层开刀——因为它最“肥”。如果你打开一个 7B 模型的权重文件你会看到一组 PyTorch 张量比如model.layers.0.self_attn.q_proj.weight这样的名字。每个名字对应一个权重矩阵把所有这些矩阵的元素个数加起来就是该模型的总参数量。1.3 从百万到千亿各量级模型的能力边界参数量的量级认知很重要。这里列一个我实测或调研过的模型规模阶梯规模典型案例能力画像运行设备约1000万10MTinyBERT、蒸馏小模型能完成简单分类、抽取基本不具备生成能力CPU 即可约1亿100MBERT-base能做中等难度 NLP 任务理解能力有明显上限普通 GPU约10亿1BGPT-2 1.5B、TinyLlama能生成较连贯短文但内容逻辑性一般消费级显卡可推理约70亿7BLLaMA-2-7B、Qwen2.5-7B能进行较高质量对话、代码生成、数学推理需要约 14GB 以上显存约130亿13BLLaMA-2-13B比 7B 有明显提升尤其在复杂推理上需要 26GB 以上显存约700亿70BLLaMA-2-70B接近商用级能力多语言、长上下文、复杂指令均不错多卡部署或量化后大显存单卡约千亿以上GPT-3、LLaMA-405B涌现出少样本学习、思维链等高级能力大规模集群这里要特别提一句很多人以为参数量翻倍能力就翻倍这是误解。从 7B 升到 13B模型能力提升大约是 10%~20% 的体感但从 70B 升到 405B能明显感觉到“质变”——因为某些能力只有在规模足够大时才会“涌现”出来。2. 为什么必须这么大参数量与能力的底层关系2.1 参数越大能“记住”的模式越多大模型本质上是把海量文本中的统计规律压缩进了一堆权重里。Transformer 的每一个线性层本质上都在做一次“特征变换”——把输入的向量从一个空间映射到另一个空间映射的方式由权重矩阵决定。权重的自由度越高也就是参数量越大它能拟合的函数空间就越大能编码的“模式”就越多。举例来说模型要正确回答“法国的首都是哪里”它需要在内部某个位置编码这样一条知识一个叫“法国”的实体和一个叫“巴黎”的实体之间存在“首都”关系。这条知识在模型里并不是以查表形式存着的而是以权重矩阵的数值分布体现出来的。参数越多能存下的“事实性知识”就越多类似“法国首都巴黎”这样的关系才能容纳得足够广。OpenAI 的研究发现模型参数量和可存储的知识量之间近似呈线性关系。这意味着想多记住一倍的知识大约就需要多一倍的参数量。这是第一层逻辑容量决定记忆。2.2 表达能力需要“分层的抽象空间”如果你拆开一个大模型的注意力头会看到一个很有意思的现象浅层的头在学词性和语法比如“的”后面通常接名词中层的头在学句法结构和语义角色深层的头在学跨句的指代和逻辑关系。这种分层抽象的能力是层层叠加出来的。每一层都在前一层输出的基础上做更高一级的抽象每一层都需要自己的一组权重矩阵来完成这一步变换。层数越深、每层维度越宽能做的抽象级别就越高、越丰富。如果你把参数量砍到很小比如几百万模型可能只能学到词级别的共现规律连“主谓宾”都处理不利索。如果给到亿级以上模型能开始建模短语结构。再往上到百亿它就能处理跨段落的长程依赖、复杂指令跟随甚至多步推理。这个过程中每一个能力的出现都对应着某个尺寸上权重的“冗余度”终于足够覆盖对应模式的出现频率。2.3 缩放法则算力、数据、参数的三角平衡2020 年 OpenAI 发表的那篇《Scaling Laws for Neural Language Models》算是给大模型的“膨胀”提供了理论依据。核心结论就一句话模型性能与参数量、训练数据量、计算量之间服从幂律关系。用大白话说你希望模型的一点点提升需要的参数量增加是指数级的——想减少一半错误率可能需要 10 倍以上的参数。这在数学上呈现出明显的“边际递减”效应。所以当你看到 GPT-3 比 GPT-2 参数多了 100 倍但能力只是“好了一大截而不是好了 100 倍”时不用惊讶这就是缩放法则的常态。更重要的是这三个变量之间必须匹配。你只有 10 亿参数却投喂 1000 亿 Tokens数据量远大于模型容量模型根本“装不下”那么多知识反过来你有 70 亿参数却只喂了 1000 万 Tokens模型会严重欠拟合甚至连基础语法都学不扎实。业界现在有一个比较公认的经验法则每个参数大约需要对应 20~30 个 Token 的训练数据。7B 模型理想训练数据量大概是 1400 亿到 2100 亿 Tokens。这解释了为什么大模型需要海量语料——没有这些数据参数规模再大也是一堆“没学过东西的空壳”。3. 参数量是怎么算出来的一份可以照抄的计算手册3.1 公式拆解从嵌入层到输出层逐一计算这个部分纯理论但极其重要。如果你以后想判断一个新模型的参数量是否合理或者想估算训练/微调时的显存开销这个计算方法是基本技能。假设一个 Transformer 模型配置为隐藏维度 d_model层数 n_layers注意力头数 n_heads词表大小 vocab_size。嵌入层参数 vocab_size × d_model。比如 LLaMA 的词表是 32000d_model 是 4096那嵌入层参数 32000 × 4096 1.31 亿。这已经是一个不小的数字了。每一层 Transformer 块包含两部分注意力部分Q 投影矩阵 d_model × d_modelK 投影矩阵同尺寸V 投影矩阵同尺寸输出投影矩阵同尺寸。合计 4 × d_model²。前馈部分两个线性层第一层把 d_model 映射到 4 × d_modelLLaMA 还用了 SwiGLU 结构是三个矩阵但参数量本质类似第二层映射回来。合计 8 × d_model²。所以单层 Transformer 参数量约 12 × d_model²4 个注意力矩阵 8 个 FFN 矩阵再加上 LayerNorm 的参数可以忽略不计。总公式总参数量 ≈ vocab_size × d_model n_layers × 12 × d_model²拿 LLaMA-2-7B 举例词表 32000d_model 4096层数 32代入公式嵌入层32000 × 4096 1.31 亿每层12 × 4096² 12 × 1677万 2.01 亿32 层2.01 × 32 64.4 亿加上嵌入层约 65.7 亿再算上其他零碎参数正好接近官方公布的 6.7B。你看公式算出来的和官方数据基本吻合说明这套计算方法是可用的。3.2 为什么说 FFN 层是参数“大户”从上面的公式就能看出每层 12 × d_model² 中FFN 占了 8 份注意力只占 4 份。这意味着 FFN 层的参数量是注意力的两倍。这个比例在业界被称为“2:1 比例”。之所以这样设计是因为 FFN 层在 Transformer 中承载了大部分“记忆”功能——它把注意力层输出的上下文信息映射到更高维度的空间进行“展开”然后在那个高维空间里做非线性变换。你可以把 FFN 想象成一个“临时工作台”注意力层负责把相关信息找出来放到工作台上FFN 在高维空间里对信息进行加工重组。工作台越大也就是中间维度越宽能同时处理的信息组合就越多。所以如果你看到一个模型把 FFN 中间维度从 4 × d_model 扩到了 8 × d_model比如某些 MoE 模型的 expert 内部那它的参数量会显著上升但推理时因为只激活部分 expert计算量不一定跟着涨。这也是近年来 MoE 架构越来越流行的原因——参数量的“存储容量”大幅提升但“计算成本”控制住了。3.3 多模态模型为什么参数更多如果你研究过 LLaVA 这类多模态模型会发现它们的参数量比同规模纯文本模型多出一大截。原因很简单视觉编码器本身就是个不小的模型比如 CLIP ViT-L/14 有约 3 亿参数把图像特征映射到文本空间的投影层也需要额外参数如果模型还支持音频输入那就还要再挂一个音频编码器。多模态大模型的参数量是“叠加式”增长的语言主干 视觉塔 投影层 可能的其他模态编码器。这也是多模态模型训练和部署都更贵的原因。不过有一个技术细节值得注意很多多模态模型在训练时会冻结视觉塔的参数只训练投影层和语言主干。这样实际可训练的参数量远小于模型总参数量。所以你不能只看一个模型的“参数量”来判断微调成本还要看它支持哪些模块被解冻。4. 参数量大带来的现实成本显存、算力与训练开销4.1 推理时的显存是怎么被占满的先给一个可复用的经验公式模型权重显存GB≈ 参数量B× 字节数 / 1024。用 FP162 字节加载一个 7B 模型7 × 2 / 1024 ≈ 13.7GB。用 INT4 量化后7 × 0.5 / 1024 ≈ 3.4GB。但这只是权重本身。你还需要额外的 KV Cache 来存储注意力计算过程中的 Key 和 Value 向量。KV Cache 的大小取决于序列长度和层数KV Cache 大小 2K和V× n_layers × n_heads × head_dim × sequence_length × batch_size × 字节数用 7B 模型跑 4096 长度的序列32 层、32 头、每头 128 维FP16 下KV Cache ≈ 2 × 32 × 32 × 128 × 4096 × 2 约 2.1GB所以一个 7B 模型在 4096 上下文长度下完整推理需要13.7GB权重 2.1GBKV Cache≈ 15.8GB 显存。这正好解释了为什么 16GB 的显卡比如 4080跑 7B 模型“勉强够用但有点紧”。如果你继续把上下文拉长到 128K现在很多模型宣称的长上下文KV Cache 会变成2 × 32 × 32 × 128 × 131072 × 2 约 67GB。光 KV Cache 就远超权重。这就是长上下文部署这么“吃显存”的根源。为了解决这个问题社区搞出了各种 KV Cache 量化、GQA分组查询注意力、滑动窗口注意力等方法本质上都是在压缩这个 Cache 的占用。4.2 训练一个千亿模型的成本比你想象的更夸张训练大模型的显存需求远高于推理因为除了权重还要保存优化器状态AdamW 需要保存一阶动量和二阶动量各占一份权重大小的显存梯度一份权重大小的显存前向激活值取决于 batch size 和序列长度有一种业界常用的粗略估算用 FP16 训练一个模型实际显存需求大约是权重内存的 12~16 倍。拿 70B 模型算权重 FP16 约 140GB乘 12 倍就是 1.68TB。所以训练 70B 模型至少需要 8 张 A100-80G 再配合 ZeRO 分级优化才能勉强跑得动。算力消耗方面业内常用来衡量训练“算力账单”的公式计算量 FLOPs ≈ 6 × 参数量 × 训练 Token 数以 LLaMA-2-70B 为例训练 2 万亿 Tokens6 × 70e9 × 2e12 8.4e23 FLOPs单张 A100 的 FP16 算力约 3.12e13 FLOPs/s如果按大集群的 MFU模型浮点利用率30%~50% 算等效算力约 1e13 FLOPs/s。那么需要的时间8.4e23 / 1e13 ≈ 8.4e10 秒 ≈ 97000 天用 1000 张 A100 并行训练也要约 97 天。这个量级和 Meta 官方训练 LLaMA-2 的实际时间约三个月2048 卡基本吻合。我把这个账单压缩成了一张表方便对照模型规模训练 Token 数参考算力需求大致硬件投入1B2000 亿1.2e21 FLOPs几十张 A100数天7B2 万亿8.4e22 FLOPs上百张 A100数周70B2 万亿8.4e23 FLOPs上千张 A100数月看了这张表你就明白为什么大模型玩家越来越集中在少数有资金的机构。参数量是能力的来源也是烧钱的根源。4.3 本地部署大模型显存不够时怎么办聊完了训练回到个人开发者最关心的事本地部署大模型怎么选先给一个最基础的决策逻辑先算推理显存再选模型、选量化精度。我实际操作中的参考顺序是第一步确认目标显存上限。比如一块 24GB 的 RTX 4090或者 16GB 的笔记本 4080。第二步按显存反推可承受的模型规模。24GB 显存如果跑 FP16最多能放下 11B 权重加适量 KV Cache如果跑 INT4 量化可以放下 30B 左右。第三步结合任务类型选择。代码生成和复杂推理优先选大模型 INT4 量化日常对话和简单问答7B 的 FP16 反而比 14B 的 INT4 更稳。这里分享一个我踩过多次坑之后的经验8GB 显存跑 7B INT4 模型虽然能跑但极其勉强因为量化模型除了权重还需要一定计算缓冲区和 KV Cache实测中 8GB 会出现严重的显存碎片问题而 12GB 以上的显卡就会从容很多。所以我的建议很直接本地部署大模型显存 16GB 是一个比较舒适的最低门槛如果只有 8GB老老实实选 3B~4B 级别的模型。5. 参数量不是唯一指标权衡与避坑心得5.1 “参数越大越聪明”的误解与真相很多人看到模型发布时比参数量觉得“140B 比 32B 强所以参数越大越好”。这个理解不全面。参数量的确是一个重要的能力上限指标但模型的实际表现还受到训练数据质量、训练充分度、对齐程度RLHF/DPO 等、上下文长度、推理策略等多种因素影响。最典型的例子一个经过充分微调、指令数据质量极高的 13B 模型在特定垂直领域里的表现可能反超一个通用 70B 模型。还有一个必须被提到的点稀疏激活模型。比如 Mixtral-8x7B总参数约 47B但每次推理只激活两个专家模块实际计算量相当于 12B~13B 模型。它的实际效果介于 13B 和 70B 之间。这就是“参数量大但推理成本可控”的设计典范。所以评估一个大模型不能只看总参数量还要看激活参数量、上下文长度、量化精度、部署框架的算子优化程度等。5.2 微调时参数量带来的陷阱前阵子我自己做 Qwen2.5-7B 的领域微调遇到了一个非常典型的参数量陷阱。当时我机器只有一块 24G 的 3090心想 7B 模型 Lora 微调应该没问题结果一跑就 OOM。排查后发现问题不在 LoRA 本身的参数而在于反向传播时保存的前向激活值。序列长度设成 2048、batch size 设成 2激活值占用了 18GB 显存直接爆了。后来我把序列长度砍到 512、batch size 降到 1、梯度累积增加到 8才稳定运行。这里有两个经验长序列微调比想象中更吃显存因为注意力机制的显存开销是序列长度的平方梯度累积gradient accumulation是省显存最直接的手段它把大 batch 拆成多个小 batch 计算梯度后累积效果等同于大 batch但显存压力大幅降低如果你用的是 8B 参数级别的模型做全参数微调哪怕是 80G 的 A100 也力不从心几乎必须要上 DeepSpeed ZeRO-3 或 FSDP 这类分布式显存优化方案。5.3 如何选择适合自己场景的“参数量”最后给一个选型参考基于我自己的项目经验使用场景推荐规模原因单机 CPU 推理1B 以下CPU 推理速度慢太大模型让人失去耐心消费级 GPU8-12GB3B~7B INT4速度和显存平衡点消费级 GPU16-24GB7B~14B FP16 或 30B INT4中高质量生成需求企业级单卡A100 80G70B INT4 或 14B FP16高精度任务多卡集群70B 全精度追求极致能力选型时还要考虑模型生态比如 LLaMA 系列社区支持最丰富Qwen 系列中英文能力强且商用友好Mistral 系列推理效率高。这些和参数量无关但直接影响你用得顺不顺手。5.4 未来参数量会继续膨胀吗现在的趋势其实是“两头走”极致大的通用模型继续冲参数上限比如万亿级 MoE极致小的端侧模型在往“同参数下更强”的方向努力比如 Apple Intelligence 和各类小模型蒸馏方案。我个人的判断是未来参数量不会像前几年那样毫无节制地涨因为数据比参数更稀缺。业界现在很清楚当你把互联网上所有高质量文本都吃完之后再增加参数量带来的边际收益会迅速衰减。反倒是合成数据、多模态数据、推理数据这几块还有很大的挖掘空间。对普通开发者和爱好者来说理解参数量的意义不在于“追大”而在于“匹配”——匹配你的硬件、匹配你的任务、匹配你的预算。这才是这个知识真正的价值。我自己的亲身体会是第一次拿 30B INT4 模型在 24G 显卡上部署成功时那种“几百亿参数在自己机器上跑起来了”的爽感确实很强但实际用了两周之后发现日常帮我干活的还是 7B 和 13B 的小模型——它们响应快、显存占用低、迭代试错成本便宜。参数量大确实能解决复杂的难题但解决日常问题更重要的永远是效率、成本和可靠性这三者之间的平衡。最后给你留一个可以马上动手的练习拿开源模型库里的任意一个模型用文中的公式算一算它的理论参数量再和官方公布的数值对比误差通常在 5% 以内。算完你就真的知道“参数量”这三个字背后是什么了。
阅读完成 · 觉得有帮助?