★ FEATURED ARTICLE 1. 为什么值得把一个小模型的架构掰开来看Granite-4.1-3B-Base 这个标题里最容易被忽略的信息其实是“3B”和“Base”这两个词。3B 意味着它是一颗参数量在三十亿级别的小模型Base 意味着它没有经过指令微调是一个纯粹的基座模型。很多人拿到这类模型的第一反应是直接跑推理看效果但我更建议先花半小时把它的结构拆开看一遍——因为小模型的架构取舍和大模型完全不是一回事三十亿参数这个量级上每一个设计选择都直接决定了它能不能在你的设备上跑起来、跑得多快、显存占用多少。我接触过不少做端侧部署和私有化落地的团队他们最常踩的坑就是拿着大模型的经验去套小模型结果发现显存算不对、推理速度对不上、微调效果不达预期。Granite-4.1-3B-Base 这个模型之所以值得单独拿出来讲是因为它把当前小模型架构里几个最主流的技术点凑齐了GQA分组查询注意力、RoPE旋转位置编码、SwiGLU门控激活函数以及共享 Embedding输入输出词嵌入共享。这四个东西单独拎出来都不新鲜但它们在三十亿参数这个尺度上怎么组合、为什么这么组合里面的门道比想象中多。这篇文章适合三类人看第一类是准备在本地或边缘设备上部署小模型的工程师你需要搞清楚显存和算力的账怎么算第二类是想自己动手微调基座模型的人你得知道哪些层可以动、哪些层动了会出问题第三类是对 Transformer 架构有兴趣、想通过一个具体模型把 GQA、RoPE、SwiGLU 这些概念真正吃透的读者。我会尽量用生活化的类比把原理讲清楚同时给出可以直接抄作业的参数计算和实操步骤不堆砌公式但该算的账一笔都不会少。2. 整体架构设计与取舍逻辑拆解2.1 三十亿参数这个尺度决定了什么先把这个模型的体量感建立起来。三十亿参数如果用 FP16 存储光权重就要占大约 6GB 显存如果用 INT8 量化压到 3GB 左右INT4 的话能到 1.5GB 上下。这个数字意味着它可以在消费级显卡上跑甚至在一些内存大一点的移动设备上做量化部署也有戏。但参数量只是结果真正决定这个结果的是架构层面的几个关键决策。Granite-4.1-3B-Base 采用的是标准的 decoder-only Transformer 结构也就是和 GPT 系列同源的自回归架构。它没有用 encoder-decoder没有用 MoE混合专家也没有搞什么花哨的稀疏注意力。这个选择本身就很有信息量在三十亿这个量级上MoE 的专家路由开销和负载均衡问题带来的复杂度往往抵消不了它带来的容量增益老老实实用稠密结构反而是更稳的选择。稠密结构的好处是推理行为可预测、显存占用线性、微调时梯度传播路径清晰对于基座模型来说这些都是加分项。层数方面这个量级的模型通常在 28 到 40 层之间隐藏维度在 2560 到 3200 左右注意力头数在 20 到 32 之间。具体数字不同版本可能有微调但量级就在这个区间。我下面讲原理时会用一组典型的配置来举例你在实际拆解自己手上的模型时把配置文件里的对应字段替换掉就行。2.2 四个核心技术点是怎么咬合的这四个技术点不是孤立存在的它们各自解决不同维度的问题组合在一起才构成了这个模型的完整画像。我用一个类比来串把模型想象成一条流水线GQA 管的是“多少个工人同时看同一份图纸”RoPE 管的是“工人在流水线上的站位怎么标记”SwiGLU 管的是“每个工位上的加工动作怎么做”共享 Embedding 管的是“入口和出口用不用同一套标签系统”。GQA 解决的是推理时 KV Cache 显存爆炸的问题。标准的多头注意力MHA里每个查询头都有自己独立的键和值头KV Cache 的大小和头数成正比。GQA 让多个查询头共享同一组键值头直接把 KV Cache 压下来。RoPE 解决的是位置信息的编码方式它通过旋转矩阵把位置信息注入到查询和键的向量里好处是相对位置关系天然可外推对长文本更友好。SwiGLU 是前馈网络里的激活函数设计用门控机制让信息流动更可控在同等参数量下通常比 ReLU 或 GELU 表现更好。共享 Embedding 则是把输入端的词嵌入矩阵和输出端的投影矩阵绑在一起省下一大块参数。这四个选择放在三十亿参数这个尺度上逻辑非常自洽参数量本来就紧张每一块都要花在刀刃上。共享 Embedding 省参数GQA 省显存SwiGLU 在同等参数下提效果RoPE 让位置编码不占额外参数还能外推。整套设计透着一股“精打细算”的味道这正是小模型架构的精髓所在。2.3 为什么不用其他方案有人可能会问为什么不用 MLA多头潜在注意力为什么不用 ALiBi 位置编码为什么不用 GeGLU这些方案不是不好而是在这个量级上性价比不划算。MLA 的压缩效果确实强但它引入了额外的投影矩阵和复杂的推理逻辑在三十亿参数上省下来的那点 KV Cache 相对于增加的实现复杂度来说不划算。ALiBi 实现简单但在长文本外推的稳定性上不如 RoPE 成熟生态支持也差一些。GeGLU 和 SwiGLU 效果接近但 SwiGLU 在实践中被验证得更充分社区实现和优化更到位。这里我想强调一个经验看一个小模型的架构不要只看它用了什么更要看它没用什么。没用 MoE 说明追求推理确定性没用稀疏注意力说明追求实现简洁没用复杂的归一化方案说明追求训练稳定性。这些“没用”背后都是工程上的权衡理解了这些权衡你才能预判这个模型在你的场景里会不会出问题。3. 核心组件原理与参数细节解析3.1 GQAKV Cache 的账要这么算分组查询注意力的核心思想是把查询头分组每组查询头共享一对键值头。假设模型有 32 个查询头分成 8 组那么键值头就只有 8 个每组 4 个查询头共用一组 KV。这个设计的关键收益在推理阶段体现得最明显因为自回归生成时每一步都要缓存之前所有 token 的键和值KV Cache 的大小直接决定了你能开多大的批、跑多长的上下文。来算一笔具体的账。假设隐藏维度是 3072层数是 32 层查询头 32 个每个头维度 9632 乘 96 等于 3072。如果用标准 MHA键值头也是 32 个那么每层每 token 的 KV Cache 大小是 2键和值乘 32头数乘 96头维度乘 2FP16 每参数 2 字节等于 12288 字节约 12KB。32 层就是每 token 约 384KB。如果你要处理 4096 个 token 的上下文单条序列的 KV Cache 就是 1.5GB 左右。这个数字在批处理时会线性增长开 8 个批就是 12GB直接把消费级显卡吃满。换成 GQA8 个键值头的情况下每层每 token 的 KV Cache 降到 2 乘 8 乘 96 乘 2等于 3072 字节约 3KB。32 层每 token 约 96KB4096 token 的上下文单序列只要 384MB 左右。同样的显存预算下你能开的批大小直接翻了四倍。这就是 GQA 在小模型上必须用的原因——不是因为它先进而是因为不用它推理成本根本压不下来。实操中有一个细节要注意GQA 的组数选择不是随意的查询头数必须能被组数整除而且组数太少会损失表达能力组数太多又省不下显存。常见的配置是查询头 32 个、键值头 8 个比例 4 比 1这个比例在效果和效率之间平衡得比较好。你在拆解模型时去配置文件里找num_attention_heads和num_key_value_heads这两个字段后者除以前者就是共享比例这个比例直接决定了 KV Cache 的压缩倍数。注意有些实现里键值头数等于查询头数时就是标准 MHA等于 1 时就是 MQA多查询注意力。GQA 是这两者之间的连续谱拆解时先确认这个比例再算显存账。3.2 RoPE位置信息是怎么“转”进去的旋转位置编码的思路很巧妙它不去额外学习位置向量而是把查询和键的向量按维度两两配对然后根据位置索引对这些配对做旋转。位置越靠后旋转的角度越大两个 token 之间的相对位置就体现在它们旋转角度的差值上。这个设计的精妙之处在于注意力计算的是查询和键的点积而旋转后的点积只依赖于两个位置的差值相对位置信息天然被编码进去了。用生活化的类比想象每个 token 是一根指针位置决定了指针的旋转角度。两个 token 做注意力计算时看的是两根指针的夹角而这个夹角只跟它们的相对位置有关跟绝对位置无关。这就是为什么 RoPE 在长文本外推上表现好——模型学到的是相对关系遇到比训练时更长的序列相对关系的模式依然成立。具体实现上旋转的频率基数是关键参数通常记作rope_theta常见取值是 10000有些模型为了支持更长上下文会调到 500000 甚至更高。基数越大低频维度的旋转越慢能覆盖的位置范围越广。你在拆解时要去配置里找这个值它直接决定了模型的原生长度能力。另外要注意 RoPE 的应用位置标准做法是只对查询和键应用值不参与旋转这个细节在阅读实现代码时容易看漏。还有一个实操要点RoPE 的维度配对方式在不同实现里可能有差异有的是相邻维度配对第 0 和第 1 维、第 2 和第 3 维有的是前后半段配对第 0 和第 d/2 维。这两种方式在数学上等价但如果你要自己做位置插值或者改长上下文必须搞清楚用的是哪种否则改出来的结果会完全错乱。我见过有人直接套用别人的长上下文扩展脚本结果模型输出全是乱码排查半天发现就是配对方式没对上。3.3 SwiGLU门控机制到底门控了什么SwiGLU 是前馈网络里的一种激活设计标准的前馈网络是两层线性变换中间夹一个激活函数而 SwiGLU 把第一层线性变换拆成两路一路过激活函数另一路不过然后两路逐元素相乘再进第二层线性变换。这个“一路当门、一路当内容”的结构就是门控的核心。为什么门控有用你可以把它理解成一种动态的特征筛选机制。激活函数那一路输出的值在 0 到 1 附近波动相当于给内容那一路的每个维度打了一个权重重要的维度放大不重要的维度压制。这种逐元素的动态调节比固定的激活函数灵活得多在同等参数量下通常能带来更好的效果。但 SwiGLU 有一个代价它多了一路线性变换参数量比标准前馈网络多了大约 50%。所以在小模型上用它必须相应地把前馈网络的中间维度调小才能把总参数量控制在预算内。常见的做法是把中间维度设成隐藏维度的 2.67 倍左右也就是 8/3而不是标准前馈网络的 4 倍。这个 8/3 不是拍脑袋来的它是让 SwiGLU 的参数量和标准 4 倍前馈网络持平的解。你在拆解时去配置里找intermediate_size拿它除以隐藏维度如果结果在 2.5 到 2.8 之间基本可以确认是 SwiGLU 配合调小中间维度的方案。提示有些模型配置里会直接写hidden_act字段值是silu或swish时配合门控结构就是 SwiGLU。如果值是gelu或relu那就是标准前馈网络中间维度通常会是 4 倍。3.4 共享 Embedding省下来的参数去哪了共享 Embedding 指的是输入端的词嵌入矩阵和输出端的语言模型头lm_head共用同一个权重矩阵。词嵌入矩阵的形状是词表大小乘以隐藏维度假设词表是 5 万隐藏维度 3072这个矩阵就是 1.5 亿参数左右。不共享的话输入端一份、输出端一份就是 3 亿参数。共享之后省下 1.5 亿对于三十亿参数的模型来说这是 5% 的参数节省相当可观。省下来的参数不是凭空消失了而是可以重新分配到更需要的层上比如多加几层或者把中间维度调大一点。这就是小模型架构设计的典型思路在总预算固定的前提下把参数从冗余的地方挪到能提升效果的地方。共享 Embedding 还有一个隐性好处输入和输出用同一套语义空间词嵌入学到的表示在两端保持一致训练时梯度从两个方向汇聚到同一个矩阵上相当于给这个矩阵加了更强的训练信号。实践中不少小模型都采用这个方案效果上没有明显损失参数效率却实打实提升了。但这里有个坑要注意共享 Embedding 在微调时如果学习率设置不当容易出现嵌入矩阵被输出端梯度主导的情况导致输入端表示退化。我的经验是微调时给嵌入层单独设一个较小的学习率或者干脆冻结嵌入层只调后面的层具体怎么选取决于你的任务和词表覆盖情况。如果你的任务涉及大量领域专有词汇词表覆盖不好那嵌入层还是要放开调的但学习率要比其他层低一个量级。4. 实操拆解流程与关键环节实现4.1 拿到模型先看配置文件拆解任何模型的第一步都是读配置文件config.json里藏着所有架构秘密。我通常按这个顺序看先看model_type确认架构族再看num_hidden_layers、hidden_size、num_attention_heads、num_key_value_heads、intermediate_size这几个核心字段然后看rope_theta、hidden_act、tie_word_embeddings这几个决定细节的字段。tie_word_embeddings这个字段直接告诉你是否共享 Embedding值是true就是共享false就是不共享。这个字段经常被忽略但它在算参数量时影响很大。我建议你拿到模型后先手动算一遍参数量和官方公布的数字对一下对不上就说明有字段理解错了这时候回去逐个核对比盲目跑推理有效得多。参数量估算的粗略公式是每层参数量约等于注意力部分加前馈部分注意力部分是 4 乘隐藏维度乘隐藏维度查询、键、值、输出四个投影GQA 下键值投影会小一些前馈部分是 3 乘隐藏维度乘中间维度SwiGLU 三路投影再乘层数加上嵌入层参数。这个公式算出来是近似值误差在几个百分点以内足够你判断显存预算了。4.2 用代码把每一层拆开验证光看配置还不够我习惯用代码把模型实例化出来逐层打印形状做验证。下面这段代码可以直接跑前提是你已经装好了对应的模型加载库from transformers import AutoConfig, AutoModelForCausalLM model_id your-local-path config AutoConfig.from_pretrained(model_id) print(层数:, config.num_hidden_layers) print(隐藏维度:, config.hidden_size) print(查询头:, config.num_attention_heads) print(键值头:, config.num_key_value_heads) print(中间维度:, config.intermediate_size) print(RoPE基数:, getattr(config, rope_theta, 10000)) print(共享Embedding:, config.tie_word_embeddings) model AutoModelForCausalLM.from_pretrained(model_id, torch_dtypeauto) total sum(p.numel() for p in model.parameters()) print(总参数量:, total / 1e9, B) for name, param in model.named_parameters(): if layers.0. in name: print(name, tuple(param.shape))跑完这段你会看到第一层的所有参数形状。重点看三个地方查询投影和键值投影的形状差异这验证 GQA 的组数前馈网络三路投影的形状这验证 SwiGLU 结构嵌入层和输出头是否指向同一个张量这验证共享 Embedding。我实测下来这一步花不了五分钟但能避免后面几个小时的瞎猜。4.3 KV Cache 显存实测与批大小推算理论算完要实测验证。用下面的思路做一次小规模推理观察显存占用随序列长度和批大小的变化import torch from transformers import AutoModelForCausalLM, AutoTokenizer model AutoModelForCausalLM.from_pretrained(model_id, torch_dtypetorch.float16, device_mapauto) tokenizer AutoTokenizer.from_pretrained(model_id) inputs tokenizer([测试文本] * 4, return_tensorspt, paddingTrue).to(model.device) with torch.no_grad(): out model.generate(**inputs, max_new_tokens128, do_sampleFalse) print(峰值显存:, torch.cuda.max_memory_allocated() / 1e9, GB)把批大小从 1 逐步加到 8、16记录峰值显存你就能画出显存随批大小增长的曲线。这条曲线的斜率就是每增加一个批带来的额外 KV Cache 开销拿它和理论计算值对比偏差超过 20% 就说明有额外开销没算进去常见原因是框架的缓存分配策略或者注意力实现的临时缓冲区。基于实测数据推算你的部署方案假设你的显卡有 16GB 显存模型权重 FP16 占 6GB留给 KV Cache 和激活值的大约 8GB按每 token 每序列 96KB 算4096 上下文下单序列 384MB理论上能开 20 个批但实际要留出激活值和临时缓冲的余量稳妥起见开 8 到 12 个批比较合适。这个推算过程比拍脑袋定批大小靠谱得多。4.4 位置编码外推的实操验证RoPE 的外推能力要实测。构造一组长度递增的输入观察模型在超过原生长度后的困惑度变化lengths [512, 1024, 2048, 4096, 8192] for L in lengths: text 这是一段用于测试长上下文外推的文本。 * (L // 10) inputs tokenizer(text, return_tensorspt, truncationTrue, max_lengthL).to(model.device) with torch.no_grad(): loss model(**inputs, labelsinputs[input_ids]).loss print(f长度 {L}: 困惑度 {torch.exp(loss).item():.2f})如果困惑度在超过某个长度后急剧上升说明原生外推能力到顶了需要做位置插值或者调整rope_theta。调整的方法是把rope_theta按比例放大比如从 10000 调到 500000然后做少量继续预训练让模型适应新的频率分布。这个操作有风险调不好会让短文本效果退化所以一定要在调整前后都跑一遍短文本的评估做对比。5. 常见问题与排查技巧实录5.1 显存对不上账的排查顺序显存问题是拆解和部署小模型时最高频的坑。我整理了一个排查顺序按这个顺序走基本能定位到根因现象可能原因排查方法加载就 OOM权重精度不对检查是否误用 FP32 加载改成 FP16 或量化推理中 OOMKV Cache 超预算降低批大小或上下文长度实测每 token 开销显存缓慢增长缓存未释放检查是否在循环里累积了计算图加 no_grad批大小翻倍显存翻三倍注意力实现低效换用优化过的注意力实现检查是否走了慢路径量化后显存没降量化只作用于部分层检查量化配置确认嵌入层和输出头是否被量化这张表里最容易被忽略的是最后一行。有些量化方案默认不量化嵌入层和输出头因为这两块对精度敏感但如果你共享了 Embedding这两块是同一个矩阵量化策略要特别处理否则会出现量化后显存降幅不及预期的情况。5.2 微调时哪些层不能乱动基座模型微调有几个雷区。第一个是共享 Embedding 层前面说过学习率要单独调低或者冻结。第二个是 RoPE 相关的参数这些通常不是可学习参数而是固定配置但有些实现里会把频率基数做成可学习的动它之前要想清楚动了之后长文本能力可能整体偏移。第三个是层归一化的参数小模型的归一化层对训练稳定性影响很大微调时建议保持较小的学习率。我的经验是做领域微调时先冻结嵌入层和前几层只调中间和后面的层跑一轮看效果如果效果不够再逐步放开。这个策略在小模型上尤其有效因为小模型的表征容量有限乱调底层容易把预训练学到的通用表示破坏掉而通用表示恰恰是小模型最宝贵的资产。5.3 长文本效果断崖的定位方法长文本效果突然变差先别急着改架构按这个顺序查第一步确认输入长度是否超过了模型的原生训练长度超过之后效果下降是正常的需要外推手段第二步检查位置编码的实现是否和训练时一致特别是配对方式和基数第三步看注意力掩码是否正确padding 位置有没有被错误地参与注意力计算。这三步查完大部分长文本问题都能定位。我遇到过一个典型案例某同学反馈模型在 2048 长度以上输出重复排查发现是他自己改的推理脚本里位置索引从 0 开始重新计数了导致 RoPE 的旋转角度错位。这种问题不看代码根本发现不了因为模型不报错只是输出质量下降。所以我的建议是任何涉及位置编码的自定义改动都要拿标准实现做逐位对比确认输出一致再往下走。5.4 量化部署的精度损失评估小模型量化要格外小心因为参数量本来就少量化损失的相对影响更大。我的做法是准备一组覆盖不同任务类型的评估样本量化前后各跑一遍对比困惑度和任务准确率。INT8 量化通常损失很小可以放心用INT4 量化要看具体方案有些方案在三十亿参数上损失明显需要逐层分析敏感度把敏感层保留高精度。评估的时候不要只看平均指标要看分布。我见过平均困惑度只涨了 2%但某些特定类型的输入困惑度涨了 30% 的情况这种模型上线后会在特定场景翻车。所以评估集要覆盖你的实际业务场景宁可多花半天做评估也别上线后被动救火。6. 拆解之后能拿来做什么把架构拆明白之后很多之前模糊的事情会变得清晰。比如你想做长上下文扩展知道 RoPE 的基数和配对方式就知道该调哪个参数、调多少你想做端侧部署知道 GQA 的组数和 KV Cache 的计算方式就能精确推算目标设备的可行性你想做领域微调知道共享 Embedding 的结构就知道该冻结哪些层、学习率怎么设。我个人在实际操作中的体会是拆解模型这件事的收益不在于拆解本身而在于拆完之后你对模型行为的预判能力。以前遇到效果问题只能试错现在能根据架构定位到大概率的根因排查效率完全不是一个量级。最后分享一个小技巧把你拆解过的每个模型的配置和实测数据整理成一张表积累十几个模型之后你会对“什么量级的模型该有什么样的架构配置”形成直觉拿到新模型扫一眼配置就能判断它大概能跑多快、适合什么场景这个直觉在选型和方案设计时非常值钱。
阅读完成 · 觉得有帮助？
