大模型学习笔记 04：从 Transformer 到 LLaMA，架构选择会改变什么

看到不同模型的架构表时，大家通常先问“哪个更强”。但我读这一节时更强烈的感觉是：架构其实是一组工程取舍，表达能力、训练稳定性、推理速度、显存和长上下文，很难同时做到极致。

先看解码器模型的骨架

自回归语言模型通常堆叠多层 Transformer 解码器。每层用因果自注意力读取已出现的 token，再通过前馈网络变换表示；最后输出词表上的概率分布。文本与位置表示进入网络，经过重复的模块，得到下一个 token 的预测。

书中以 LLaMA 为例介绍了 RMSNorm、SwiGLU 和旋转位置编码 RoPE 等设计。它们不是“换一个名字就更聪明”，而是分别涉及归一化计算、非线性变换和位置信息表达。不同组合影响训练性质与推理表现，需要在具体模型、数据和硬件下验证。

为什么模型结构会影响部署

注意力在推理时需要保存历史 token 的 Key、Value。上下文越长、并发请求越多，KV Cache 越占显存。多头注意力中，每个头都维护自己的 K/V；多查询注意力和分组查询注意力通过共享部分 K/V，减少缓存压力，但可能改变表达能力与效果。

多头注意力：每个 Query 头有自己的 K/V
分组查询：多个 Query 头共享一组 K/V
多查询注意力：所有 Query 头共享一组 K/V

这说明推理成本并非只由参数量决定。上下文长度、KV 头数、批处理方式、缓存精度和服务并发都会影响内存预算。

比较架构时，别只看参数量

比较模型时至少记录：任务集、上下文长度、量化方式、硬件、推理框架、吞吐和延迟。只比较参数量或某个榜单分数，可能会漏掉真正影响部署的条件。书中呈现的是当时模型架构演进的一部分，今天的模型还会采用新的位置编码、注意力和专家混合设计，具体细节应查对应模型卡和论文。

所以我现在比较架构时，会先写清楚自己的瓶颈：是质量不够、显存不够、延迟太高，还是成本超预算？架构名词本身没有脱离使用条件的“最优解”。

比如同样是聊天服务，单次请求很长、并发又高时，KV Cache 的大小就会成为重要因素；如果主要是短文本分类，缓存和长上下文可能都不是重点。架构选择最终要落到工作负载上，而不是只看论文图里的模块是否新。

书中讲到的 LLaMA 结构很适合作为一张历史坐标。RMSNorm、SwiGLU、RoPE 和注意力变体，分别在稳定性、非线性表达、位置信息和缓存成本上做了取舍。今天的模型还会继续变化，但读架构时可以沿用这个思路：每个模块为什么出现，它缓解了哪个瓶颈，又引入了什么新的约束。

模型架构还会影响微调方式。某些层更适合注入 LoRA，某些结构在量化后误差更敏感；上下文长度和注意力头的配置，也会影响推理时的 KV Cache。训练、微调和部署并不是三件互不相干的事情，架构会把它们串在一起。

如果只是调用云端模型，不需要每天研究每一层的结构。但当你要在本地部署、选择量化方案或解释显存预算时，至少要能看懂模型卡里的层数、隐藏维度、注意力头和上下文配置。否则很多容量和成本问题只能靠试错。

参考：《大规模语言模型：从理论到实践》，第 2 章 2.3 节，PDF 第 43-56 页。本文为学习整理与独立阐释。