Granite-4.1-3B-Base 小模型架构拆解：GQA、RoPE、SwiGLU与共享Embedding实战

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 GQA：KV Cache 的账要这么算

分组查询注意力的核心思想是把查询头分组，每组查询头共享一对键值头。假设模型有 32 个查询头，分成 8 组，那么键值头就只有 8 个，每组 4 个查询头共用一组 KV。这个设计的关键收益在推理阶段体现得最明显，因为自回归生成时每一步都要缓存之前所有 token 的键和值，KV Cache 的大小直接决定了你能开多大的批、跑多长的上下文。

来算一笔具体的账。假设隐藏维度是 3072，层数是 32 层，查询头 32 个，每个头维度 96（32 乘 96 等于 3072）。如果用标准 MHA，键值头也是 32 个，那么每层每 token 的 KV Cache 大小是 2（键和值）乘 32（头数）乘 96（头维度）乘 2（FP16 每参数 2 字节），等于 12288 字节，约 12KB。32 层就是每 token 约 384KB。如果你要处理 4096 个 token 的上下文，单条序列的 KV Cache 就是 1.5GB 左右。这个数字在批处理时会线性增长，开 8 个批就是 12GB，直接把消费级显卡吃满。

换成 GQA，8 个键值头的情况下，每层每 token 的 KV Cache 降到 2 乘 8 乘 96 乘 2，等于 3072 字节，约 3KB。32 层每 token 约 96KB，4096 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_dtype="auto") 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_dtype=torch.float16, device_map="auto") tokenizer = AutoTokenizer.from_pretrained(model_id) inputs = tokenizer(["测试文本"] * 4, return_tensors="pt", padding=True).to(model.device) with torch.no_grad(): out = model.generate(**inputs, max_new_tokens=128, do_sample=False) 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_tensors="pt", truncation=True, max_length=L).to(model.device) with torch.no_grad(): loss = model(**inputs, labels=inputs["input_ids"]).loss print(f"长度 {L}: 困惑度 {torch.exp(loss).item():.2f}")

如果困惑度在超过某个长度后急剧上升，说明原生外推能力到顶了，需要做位置插值或者调整rope_theta。调整的方法是把rope_theta按比例放大，比如从 10000 调到 500000，然后做少量继续预训练让模型适应新的频率分布。这个操作有风险，调不好会让短文本效果退化，所以一定要在调整前后都跑一遍短文本的评估做对比。

5. 常见问题与排查技巧实录

5.1 显存对不上账的排查顺序

显存问题是拆解和部署小模型时最高频的坑。我整理了一个排查顺序，按这个顺序走基本能定位到根因：

这张表里最容易被忽略的是最后一行。有些量化方案默认不量化嵌入层和输出头，因为这两块对精度敏感，但如果你共享了 Embedding，这两块是同一个矩阵，量化策略要特别处理，否则会出现量化后显存降幅不及预期的情况。

5.2 微调时哪些层不能乱动

基座模型微调有几个雷区。第一个是共享 Embedding 层，前面说过，学习率要单独调低或者冻结。第二个是 RoPE 相关的参数，这些通常不是可学习参数而是固定配置，但有些实现里会把频率基数做成可学习的，动它之前要想清楚，动了之后长文本能力可能整体偏移。第三个是层归一化的参数，小模型的归一化层对训练稳定性影响很大，微调时建议保持较小的学习率。

我的经验是，做领域微调时先冻结嵌入层和前几层，只调中间和后面的层，跑一轮看效果，如果效果不够再逐步放开。这个策略在小模型上尤其有效，因为小模型的表征容量有限，乱调底层容易把预训练学到的通用表示破坏掉，而通用表示恰恰是小模型最宝贵的资产。

5.3 长文本效果断崖的定位方法

长文本效果突然变差，先别急着改架构，按这个顺序查：第一步确认输入长度是否超过了模型的原生训练长度，超过之后效果下降是正常的，需要外推手段；第二步检查位置编码的实现是否和训练时一致，特别是配对方式和基数；第三步看注意力掩码是否正确，padding 位置有没有被错误地参与注意力计算。这三步查完，大部分长文本问题都能定位。

我遇到过一个典型案例：某同学反馈模型在 2048 长度以上输出重复，排查发现是他自己改的推理脚本里位置索引从 0 开始重新计数了，导致 RoPE 的旋转角度错位。这种问题不看代码根本发现不了，因为模型不报错，只是输出质量下降。所以我的建议是，任何涉及位置编码的自定义改动，都要拿标准实现做逐位对比，确认输出一致再往下走。

5.4 量化部署的精度损失评估

小模型量化要格外小心，因为参数量本来就少，量化损失的相对影响更大。我的做法是准备一组覆盖不同任务类型的评估样本，量化前后各跑一遍，对比困惑度和任务准确率。INT8 量化通常损失很小，可以放心用；INT4 量化要看具体方案，有些方案在三十亿参数上损失明显，需要逐层分析敏感度，把敏感层保留高精度。

评估的时候不要只看平均指标，要看分布。我见过平均困惑度只涨了 2%，但某些特定类型的输入困惑度涨了 30% 的情况，这种模型上线后会在特定场景翻车。所以评估集要覆盖你的实际业务场景，宁可多花半天做评估，也别上线后被动救火。

6. 拆解之后能拿来做什么

把架构拆明白之后，很多之前模糊的事情会变得清晰。比如你想做长上下文扩展，知道 RoPE 的基数和配对方式，就知道该调哪个参数、调多少；你想做端侧部署，知道 GQA 的组数和 KV Cache 的计算方式，就能精确推算目标设备的可行性；你想做领域微调，知道共享 Embedding 的结构，就知道该冻结哪些层、学习率怎么设。

我个人在实际操作中的体会是，拆解模型这件事的收益不在于拆解本身，而在于拆完之后你对模型行为的预判能力。以前遇到效果问题只能试错，现在能根据架构定位到大概率的根因，排查效率完全不是一个量级。最后分享一个小技巧：把你拆解过的每个模型的配置和实测数据整理成一张表，积累十几个模型之后，你会对“什么量级的模型该有什么样的架构配置”形成直觉，拿到新模型扫一眼配置就能判断它大概能跑多快、适合什么场景，这个直觉在选型和方案设计时非常值钱。