1. 从一次深夜debug聊起：模型架构到底在研究什么
凌晨两点，我盯着训练日志里那条死活不收敛的loss曲线，第17次调整学习率预热步数。旁边同事凑过来看了一眼说：“你这模型结构是不是有问题？”那一刻我突然意识到，做模型架构研究这些年，最折磨人的从来不是写代码，而是在无数个看似合理的方案里，找到那个真正work的组合。
这篇碎碎念，我想把过去几年在模型架构、LLM、Transformer、Scaling Law这些关键词背后踩过的坑、想明白的道理、以及那些“当时要是有人告诉我就好了”的经验，一次性倒出来。如果你正在跑自己的第一个Transformer、正在纠结注意力头数怎么设、正在被Scaling Law的公式搞得一头雾水，或者只是想知道大模型架构研究到底在干什么，那这些内容应该能帮你省下不少试错时间。
先说清楚定位：这不是一篇教科书式的架构综述，不会从RNN一路讲到Mamba。这是一份从业者视角的架构研究笔记，重点放在“为什么这么设计”“实际跑起来会遇到什么”“哪些参数真正重要”这些工程和研究交界处的问题上。适合已经了解Transformer基本概念、但一动手就发现细节全是坑的读者。如果你还没写过attention，建议先手撸一遍再来看，效果会好很多。
2. 架构设计的核心矛盾：表达能力与训练可行性的拉锯战
2.1 为什么是Transformer赢了：一个工程视角的解释
2017年那篇Attention Is All You Need出来的时候，我在做序列标注，第一反应是“这不就是把RNN的循环拆成了矩阵乘法吗”。但真正跑起来才发现，这个“拆”字背后是训练并行度的质变。RNN的时序依赖意味着你第t步必须等第t-1步算完，GPU利用率惨不忍睹。Transformer把整个序列一次性铺开做注意力，虽然计算复杂度从O(n)变成了O(n²)，但在GPU上，矩阵乘法的并行效率把理论复杂度的劣势直接碾过去了。
这里有个很多人忽略的点：Transformer的胜利本质上是硬件友好性的胜利。注意力机制的核心运算就是QK^T和softmax后的加权求和，全是稠密矩阵乘法，这正是GPU最擅长的。相比之下，RNN的循环结构在GPU上要做大量的kernel launch和同步，实际吞吐量差了一个数量级。所以当你看到后来各种“Transformer杀手”的论文时，先问一个问题：它的核心运算在现有硬件上能不能高效并行？如果答案是否定的，那基本可以不用往下看了。
2.2 注意力头数不是越多越好：一个实测出来的经验公式
刚开始跑Transformer的时候，我迷信“头数越多表达能力越强”，把d_model=512的模型设了16个头，每个头维度只有32。结果训练loss震荡得厉害，调了好久才发现问题。后来做了几组对照实验，总结出一个经验：每个注意力头的维度最好不要低于64。原因很简单，softmax之后的加权求和本质上是在做一种“软检索”，如果每个头的维度太低，Q和K的内积空间太小，注意力分布会变得非常尖锐或者非常平坦，很难学到有意义的模式。
具体来说，如果你用d_model=768，那8到12个头是比较舒服的区间。头数太少（比如4个），每个头要处理的信息太多，注意力会变得“糊”；头数太多（比如16个以上），每个头的维度被压到48以下，注意力分布的质量会明显下降。当然这不是铁律，但作为一个起点，按这个来设至少不会一开始就翻车。
2.3 位置编码的选择：正弦 vs 可学习 vs RoPE
位置编码这块我踩的坑最多。最早用正弦位置编码，觉得“无参数、可外推”很优雅。但实际做长文本任务时发现，正弦编码在训练长度之外的表现确实会退化，而且退化方式很难预测。后来换成可学习的位置嵌入，短文本任务上效果确实好了一点，但一旦推理长度超过训练长度就直接崩了，因为超出范围的position embedding根本没被训练过。
RoPE（旋转位置编码）是这几年我觉得最实用的方案。它的核心思想是把位置信息编码成旋转矩阵，通过旋转Q和K向量来注入位置信息。好处是相对位置关系天然被编码，而且理论上可以外推到更长的序列。我实测下来，用RoPE的模型在训练长度2倍以内的外推表现明显好于可学习嵌入，配合NTK-aware的插值方法还能再往外推一些。如果你在做需要处理变长序列的LLM，RoPE基本是默认选择了。
3. 参数计算与Scaling Law：那些论文里不会告诉你的细节
3.1 参数量到底怎么算：一个容易算错的账
很多人第一次算Transformer参数量的时候都会漏掉一些东西。以标准Decoder-only的LLM为例，每层的参数量大致是：
- 自注意力部分：Q、K、V、O四个投影矩阵，每个是d_model × d_model，共4d²
- FFN部分：通常中间维度是4d，所以是两个矩阵d × 4d和4d × d，共8d²
- LayerNorm：每个2d，两个LayerNorm共4d
所以每层大约是12d² + 4d。对于一个d_model=768、12层的模型，参数量大约是12 × 12 × 768² ≈ 85M。但实际模型还会加上embedding层（vocab_size × d_model）和最后的输出投影（通常和embedding共享权重）。如果vocab_size=50000，embedding就是50000 × 768 ≈ 38M。所以总参数量大概在123M左右。
这里有个坑：很多人算参数量时忘了embedding层，或者忘了输出投影。在做Scaling Law拟合的时候，这个误差会直接影响你的结论。我建议直接用sum(p.numel() for p in model.parameters())来数，别手算。
3.2 Scaling Law的实用解读：不是让你无脑堆参数
Scaling Law的核心结论是：模型性能（用loss衡量）和参数量N、数据量D、计算量C之间存在幂律关系。Chinchilla那篇论文给出了一个很实用的结论：在给定计算预算下，参数量和训练token数应该大致按1:20的比例增长。也就是说，一个10B参数的模型，大概需要200B token的训练数据。
但这里有个实际工程中经常被忽略的问题：数据质量的影响可能比数量更大。我做过一组对比，同样的模型结构，用经过严格清洗和去重的数据训练，比用原始爬取数据训练，在相同token数下loss能低0.1到0.2。这个差距在Scaling Law的框架下，相当于参数量翻倍的效果。所以如果你资源有限，与其盲目堆数据量，不如先把数据质量提上去。
另一个经验是：小模型上的Scaling Law拟合结果，不一定能直接外推到大模型。我在1B以下模型上拟合的曲线，外推到7B时预测的loss比实际低了大概0.05。原因可能是小模型和大模型的最优超参数（学习率、batch size、warmup步数）不一样。所以做Scaling预测时，最好至少在两个数量级上验证一下。
3.3 计算量估算：FLOPs和实际训练时间的关系
理论FLOPs和实际训练时间之间有一个“MFU（Model FLOPs Utilization）”的概念。对于Transformer，前向+反向的总FLOPs大约是6ND，其中N是参数量，D是token数。但实际训练时，GPU的有效利用率通常只有30%到50%。也就是说，如果你有100张A100，每张312 TFLOPS（bf16），理论峰值是31.2 PFLOPS，但实际能跑到10到15 PFLOPS就不错了。
影响MFU的因素很多：batch size太小会导致kernel launch开销占比高；序列长度太长会导致attention的O(n²)部分成为瓶颈；通信开销在分布式训练中也不可忽略。我的一般经验是：当batch size（token数）达到1M以上时，MFU能到40%左右；如果只有100K，可能只有20%到30%。所以做训练计划时，别按理论峰值算时间，按30%到40%估比较靠谱。
4. 实操中的架构选择：从手写Transformer到LLM微调
4.1 手写Transformer时最容易出错的三个地方
第一次手写Transformer，我建议你重点检查这三个地方，它们是我见过最多的bug来源：
第一，attention mask的方向。Decoder-only的因果mask是一个下三角矩阵，但很多人会把上三角和下三角搞反。一个简单的检查方法：mask之后，位置i只能attend到位置0到i。如果你发现模型在生成时“偷看”了后面的token，大概率是mask反了。
第二，LayerNorm的位置。Post-LN（原始Transformer）和Pre-LN（GPT系列）的训练稳定性差别很大。Post-LN在深层模型上需要很小心地调warmup，否则容易梯度爆炸。Pre-LN则稳定得多，但最终性能可能略低。我的建议是：除非你有明确理由用Post-LN，否则默认用Pre-LN，能省掉很多调参的麻烦。
第三，残差连接的初始化。GPT-2的论文里提到，残差层的初始化应该按1/√N缩放，其中N是残差层数。这个细节对深层模型的训练稳定性影响很大。如果你发现模型训练初期loss突然飙升，可以检查一下残差初始化。
4.2 从零训练 vs 微调：一个成本收益的决策框架
经常有人问我：我想做一个特定领域的LLM，是从零训练还是微调现有模型？我的回答取决于三个因素：数据量、算力预算、领域差异度。
如果你有超过100B token的领域数据，并且算力预算在百万美元级别，那可以考虑从零训练一个中等规模的模型。但说实话，大多数场景下，微调一个7B到13B的开源模型，效果已经足够好，成本只有从零训练的百分之一甚至千分之一。
领域差异度也很关键。如果目标领域和预训练数据分布差异很大（比如非常专业的医学或法律文本），微调可能需要更多的数据才能“扭转”模型的先验。但如果只是想让模型适应某种输出格式或风格，LoRA微调几百条数据就能见效。
我自己的经验是：先用LoRA在少量数据上试一版，看看效果天花板在哪里。如果LoRA能达到业务要求的80%，那剩下的20%可能不值得花10倍成本去追。如果LoRA完全不行，再考虑全量微调或从零训练。
4.3 多模态架构的现状：视觉编码器怎么接进LLM
多模态这块，目前主流的做法是用一个视觉编码器（比如ViT或Swin Transformer）提取图像特征，然后通过一个投影层（通常是MLP或Q-Former）把视觉特征映射到LLM的embedding空间。这里的关键设计决策是：视觉token和文本token怎么对齐。
简单粗暴的做法是把视觉特征直接拼在文本embedding前面，让LLM自己学。但这样视觉token数量往往很多（一张图可能几百个patch），会挤占文本的上下文长度。更精细的做法是用Q-Former或Perceiver Resampler把视觉特征压缩成固定数量的query token（比如32或64个），这样既保留了关键信息，又控制了序列长度。
我实测下来，压缩到64个token左右是一个比较好的平衡点。再少的话，细粒度视觉信息（比如小字、细节纹理）会丢失；再多的话，对文本任务的干扰会变大。当然这取决于你的具体任务，如果是OCR密集的场景，可能需要保留更多视觉token。
5. 常见问题与排查技巧实录
5.1 训练不收敛：从loss曲线读出问题
Loss曲线是模型训练最重要的诊断工具。我一般会关注这几个模式：
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| loss震荡剧烈 | 学习率太大或batch size太小 | 降低学习率，增大batch size，检查梯度裁剪 |
| loss下降后突然飙升 | 梯度爆炸或数据中有异常样本 | 检查梯度范数，排查数据质量 |
| loss几乎不降 | 学习率太小或模型初始化有问题 | 调大学习率，检查初始化，确认mask方向 |
| 训练loss降但验证loss升 | 过拟合 | 增加数据，加dropout，减小模型 |
我遇到最多的是第一种：loss震荡。十有八九是学习率设大了。Transformer对学习率很敏感，尤其是Post-LN结构。我的经验是：先用一个很小的学习率（比如1e-5）跑几百步，确认loss在稳定下降，再逐步调大。别一上来就设1e-3，那是给自己找麻烦。
5.2 显存不够用：几个立竿见影的优化手段
显存不够是训练大模型时的家常便饭。除了买更大的卡，这几个方法能帮你省不少显存：
梯度检查点（Gradient Checkpointing）：用计算换显存，把中间激活值不保存，反向时重新算。能省30%到50%的显存，代价是训练速度慢20%左右。对于大模型，这个交换通常是值得的。
混合精度训练（AMP）：用bf16或fp16做前向和反向，fp32做参数更新。能省将近一半显存，而且速度更快。bf16比fp16更稳定，不容易出现梯度下溢，推荐优先用bf16。
ZeRO优化器：DeepSpeed的ZeRO Stage 2或3能把优化器状态和梯度分片到多张卡上，显存占用能降到原来的1/N。但通信开销会增加，适合卡多但单卡显存小的情况。
FlashAttention：这个必须单独提。它通过分块计算attention，避免了显式的n×n注意力矩阵，显存占用从O(n²)降到O(n)，而且速度还更快。现在基本是标配了，如果你还在用朴素attention，赶紧换。
5.3 推理速度慢：从架构层面找原因
推理速度慢，很多时候不是硬件问题，而是架构或实现问题。几个常见的瓶颈：
KV Cache没开：自回归生成时，每次都要重新计算所有历史token的K和V，这是巨大的浪费。KV Cache把历史K和V存下来，每次只算新token的，速度能提升几倍到几十倍。如果你发现生成速度随序列长度线性下降，大概率是没开KV Cache。
Attention实现不够优化：朴素的attention实现有很多不必要的内存读写。FlashAttention和PagedAttention（vLLM用的）能大幅提升推理吞吐。尤其是PagedAttention，通过分页管理KV Cache，显存利用率能到90%以上。
模型并行策略不当：如果模型太大单卡放不下，需要做张量并行或流水线并行。但并行策略选不好，通信开销会吃掉大部分收益。一般来说，张量并行适合单机多卡（NVLink带宽高），流水线并行适合多机多卡。如果搞反了，性能会差很多。
6. 一些关于AGI和模型架构未来的个人看法
聊到AGI，我其实挺谨慎的。现在的大模型在语言任务上确实很强，但离“通用”还有距离。一个明显的短板是持续学习：模型训练完之后就固定了，没法像人一样从交互中不断更新知识。另一个是推理的可靠性：模型有时候会“自信地胡说八道”，这在需要高可靠性的场景里是致命的。
从架构角度看，我觉得未来可能有几个方向值得关注。一是稀疏化：MoE（混合专家）已经在做了，但如何高效地路由和训练还是个开放问题。二是记忆机制：给模型加一个可读写的长期记忆，而不是把所有知识都压缩在参数里。三是多模态的深度融合：现在的多模态大多是“视觉编码器+LLM”的拼接，未来可能需要更统一的架构。
但这些方向都有一个共同的前提：算力和数据。没有足够的算力，再好的架构也训不出来；没有高质量的数据，再大的模型也学不到真东西。所以如果你在做架构研究，别忘了同时关注数据和算力这两个“隐形变量”。
最后分享一个我自己的习惯：每次看到一个新的架构论文，我会先问三个问题——它解决了什么现有架构解决不了的问题？它的核心运算在GPU上高效吗？它的参数量和计算量在可接受范围内吗？这三个问题能过滤掉大部分“看起来很美但跑不起来”的方案。架构研究不是追新，而是在表达能力、训练可行性、推理效率之间找平衡。这个平衡点会随着硬件和数据的变化而移动，但寻找平衡的方法论是不变的。
