Sebastian Raschka 在他的 Ahead of AI Newsletter 里记录了自己理解新 LLM 架构的完整工作流。这是 LLM Architecture Gallery 背后那些架构示意图的来源，也是他在《从零构建大型语言模型》写作过程中磨练出的方法论。
从技术报告开始，但不依赖它
理解新架构的第一步通常是阅读官方技术报告或论文。但 Raschka 坦率地提到了一个近年来越来越明显的问题：工业界发布的开权重模型技术报告，整体质量在下滑。
两年前，大多数主流模型的技术报告会详细描述架构的每一个组件——注意力机制的变体、位置编码的实现方式、层归一化的位置、词汇表大小和 tokenizer 的选择。这些信息足够让人从零复现。
现在的情况不同了：很多报告只包含高层次的描述，省略了大量实现细节，有时候写得模糊到难以判断"这个模型到底用的是哪种注意力机制变体"。更麻烦的是，报告里写的和实际代码里实现的有时会不一致。
代码是最准确的文档
面对这个问题，Raschka 的第二步是直接读模型代码。Hugging Face 上的模型实现往往是最准确的参考：
- 代码是实际运行的，不存在"写的和做的不一样"
- Hugging Face 的
modeling_*.py文件通常结构清晰，注释完整 - 可以直接运行并观察各层输出的形状变化，验证自己的理解
对于重要模型，Raschka 会逐层读完整个前向传播流程，把每个组件（embedding、attention、MLP、归一化层）的实现细节记录下来。
画图：用可视化检验理解
读完报告和代码之后，Raschka 的第三步是动手画架构图。这不只是为了输出内容——这个过程本身是理解的检验。
当你尝试把一个架构从文字/代码转化成可视化时，你会遇到很多报告里含糊带过的问题：这层归一化是 Pre-Norm 还是 Post-Norm？位置编码应用在 Query 还是 Query 和 Key 都有？残差连接绕过哪几层？
能画出来的理解和能背出来的理解是不同层次的。如果画图过程中某个地方不确定，往往意味着对这个组件的理解还不到位，需要回去重读代码或报告。
Raschka 维护了一个 LLM Architecture Gallery，记录了他分析过的主流模型架构，这些图都是通过这个工作流生成的。
对比：理解设计选择的动机
第四步是横向对比。一个架构设计选择通常不是孤立的，它是在特定历史背景下相对于其他选择做出的。
比如：Grouped Query Attention（GQA）在什么时候出现的？为什么它在某些模型里取代了 Multi-Head Attention？这需要对比同期的其他模型，理解当时 inference 效率和内存占用的瓶颈是什么。
这种横向对比让你从"这个模型用了 GQA"的知识，升级到"这类任务/规模下，GQA 比 MHA 在什么维度上更合适"的判断。
给研究者和工程师的建议
Raschka 在文章末尾总结了几点实用建议：
不要过度依赖技术报告：尤其是最近两年工业界发布的模型，报告质量参差不齐，代码才是真实的实现。
Hugging Face 代码是第一手资料：大多数主流模型的 HF 实现经过大量用户验证，可以信赖。
自己动手画图：不需要专业工具，能在纸上或白板上画清楚就足够了。画图过程暴露的疑问往往是理解最深入的地方。
做笔记时记录"为什么"而不只是"是什么"：这个模型选择 RMSNorm 而不是 LayerNorm，原因是什么？记录设计选择背后的动机，比记录选择本身更有长期价值。