本文分享了高级工程师 Sebastian Raschka 的 LLM 架构研究方法论，强调从零实现大模型架构的价值在于深入理解其工作原理。文章探讨了当前 LLM 领域最核心的技术趋势——如何优化 KV Cache 以支持更长的上下文和复杂推理。Sebastian 提出了从技术报告、配置文件到代码实现的十二步架构理解流程，并以 Gemma 3 的 RMS Norm 调试案例揭示了细节差异的重要性。此外，文章还分析了 GQA、MLA、滑动窗口注意力等 KV Cache 优化技术，并展望了推理模型与 Agentic Loop 的未来趋势，最后给出了从入门到专家的 LLM 学习路径建议。

---

如果你真正动手从零实现一个大模型架构，你会发现代码不会说谎——它给出的答案是最真实、最诚实的。

实现架构从零开始，不是为了把它卖掉或者跑得更快，而是为了真正理解大模型的工作原理和设计选择背后的动机。

当前的注意力机制优化，本质上都是在解决同一个问题：如何让 KV Cache 变得更小，从而支持更长的上下文、更复杂的推理场景。

本期嘉宾是 Sebastian Raschka。他现任 Lightning AI 高级工程师，此前在威斯康星大学麦迪逊分校担任统计学教授十余年，是深度学习与机器学习领域备受尊敬的教育者和研究者。他著有《Build a Large Language Model (From Scratch)》一书，系统性地带领读者从头构建了一个 GPT 风格的大语言模型。新书《Build a Reasoning Model from Scratch》正在出版中，全书 528 页，涵盖推理 Scaling、强化学习与蒸馏等前沿主题。在这场分享中，Sebastian 展示了他多年积累的 LLM 架构研究方法论，并深入分析了当前 LLM 领域最核心的技术趋势。

什么是"在 Python 中运行 LLM"

很多人听到"在 Python 中运行 LLM"时，脑海中浮现的是纯 Python 代码在执行某种魔法。但 Sebastian 在分享开头就先澄清了一个常见误解：当他说"在 Python 中运行 LLM"时，实际指的是通过 PyTorch 这样的深度学习框架来调用 LLM 的能力，而非字面意义上的纯 Python 代码执行。

PyTorch 在这个场景下扮演的角色，本质上是 Python 与底层高性能计算代码之间的"粘合剂"。在 CPU 上运行时，PyTorch 底层调用的是 C++ 实现；在 NVIDIA GPU 上运行时，它通过 CUDA（一种类 C/C++ 的编程语言）与硬件通信；在 AMD GPU 上则是 ROCm；在苹果自研芯片上，则调用 Metal 后端。这意味着，开发者用 Python 语法写下的每一行代码，最终都会通过这些底层路径在硬件上高效执行。

除了 PyTorch，生态中还存在 JAX 和 MLX 等其他框架选择。Sebastian 指出，PyTorch 之所以成为 LLM 领域最流行的选择，很大程度上是因为它为实验阶段提供了快速迭代的能力。当研究者想验证一个新想法是否有效时，他们通常先用 PyTorch 实现，跑通训练流程并验证损失函数下降趋势，一旦对想法的有效性有了信心，再考虑切换到高度优化的纯 CUDA 实现以提升训练效率。这种工作流在当前大模型训练成本动辄数百万美元的背景下尤为重要——10% 的速度提升可能就意味着节省数百万美元的开销。

从零实现 LLM 架构的价值

Sebastian 花了这场分享中最长的篇幅来回答一个问题：从零实现 LLM 架构，究竟能学到什么？他认为，理解 LLM 架构的最好方式，不是阅读论文中的抽象架构图，而是亲手去实现它、调试它、与参考实现逐一对比每一层的输出。

一个值得深思的现实背景是：如今的 LLM 论文与早期学术论文相比，信息密度正在下降。Sebastian 分析说，当 LLM 主要来自企业实验室而非学术机构时，论文更像是一种"白皮书"，分享整体思路而非提供完整的架构细节。论文中通常包含与竞品的基准测试对比，但完整的架构实现细节往往缺失。这与十年前学术论文通常附有详尽技术细节的做法形成了鲜明对比。

然而，代码本身不会说谎。如果有人在 Hugging Face 上传了模型权重，并且这些权重与参考实现（例如 Hugging Face Transformers 库）完全兼容，那么通过逐一对比每一层的输出，开发者可以清晰地看到自己实现与标准实现之间的差异。这种"可验证的奖励"机制——类似于强化学习中根据可验证结果进行学习的思路——让架构理解变得严谨而深入。

更重要的是，Sebastian 强调了一个被很多人忽视的观点：如果你把一切都自动化了，你同时也自动化了学习的过程。他认为，亲手做一遍这个过程，虽然耗时，但对于真正理解 LLM 的工作原理来说，是无可替代的。

Sebastian 的十二步架构理解流程

在演讲中，Sebastian 展示了他个人在面对一个新模型发布时的完整工作流程，这套流程包含十二个步骤，每一步都蕴含着深刻的学习方法论。

整个流程从发现新模型开始。通常，Sebastian 会在社交媒体或博客上注意到一个新的开源模型发布，比如 Google 的 Gemma 3（他选择的是 270M 参数的版本，因为它足够小，能在几乎任何电脑上运行）。他首先会找到对应的技术报告阅读——技术报告的价值在于，它通常包含了某些设计选择背后的动机，这些信息在代码中是看不到的。

接下来，他会上 Hugging Face 的模型页面查看模型卡片（Model Card），这是一个详细的 README 文件，包含了基准测试信息和关键代码选择的说明。然后，他会下载 config.json 配置文件，这个 JSON 文件中包含了大量有价值的架构信息：比如使用了哪种激活函数（ Gemma 3 使用了 GLU 激活）、是否使用了滑动窗口注意力（5 层滑动窗口注意力 + 1 层全局注意力交替的组合）等。

拿到这些信息后，Sebastian 并不是直接跳到代码。他会找一个之前已经研究过的相近架构（例如从 Quen 2 到 Gemma 3），将两者的配置并排对比，找出哪些部分发生了变化，然后据此更新他的架构图。这个过程帮助他在动手写代码之前，就对整个架构有一个全局性的认识。

代码实现阶段，他会在之前实现的基础上进行修改——比如把激活函数从 SwiGLU 换成新的 GLU 变体。然后，他会在随机初始化的权重上运行模型生成文本，并与参考实现逐层对比输出。如果两者不匹配（这几乎是必然会发生的事情），他就会开始一场"复活节彩蛋寻宝"式的调试之旅——在 Transformers 库的复杂代码中追踪每一条线索，从模块化的 Gemma 3 实现文件一直追溯到最底层的 RMS Norm 实现。

Gemma RMS Norm 案例：细节中的魔鬼

Sebastian 详细展示了一个具体的调试案例，这个案例揭示了从零实现过程中能发现的、仅靠读论文永远无法获得的深层洞察。

当他在对比 Gemma 3 与参考实现时，发现在第一个 Transformer 块的输入层归一化（pre-Norm）处，就已经出现了明显的数值偏差——均值偏差 0.88，最大值偏差 2.3。这个偏差虽不算巨大，但足以导致整个网络最终的输出完全崩溃，生成出一堆不知所云的随机 token。

经过追踪，他发现问题出在对 RMS Norm（均方根归一化）的理解上。标准的 RMS Norm 实现中有一个可学习参数 γ，初始化为 1，实际计算为 RMS 乘以 γ。而 Gemma 的 RMS Norm 实现则不同：它使用了 1 + s 这个项，其中 s 初始化为 0。这意味着在初始化时，两种实现给出完全相同的结果，但随着训练的进行，Gemma 的版本将学习参数中心化在零点附近。

这个细节为什么重要？Sebastian 解释道，在深度学习中，参数以零为中心通常能让 Adam 等优化器更稳定地工作。这不是理论上的推测，而是 Gemma 团队在实践中发现的一种训练稳定性技巧。如果不是亲自从零实现并与参考实现逐一对比，你很难意识到这个隐藏在代码深处的细微差别。

修复这个实现后，Sebastian 再次运行验证工具，确认两层之间的输出现在完全一致了。随后他用预训练权重加载整个模型，输入一个简单提示并生成了连贯的文本回复——这才是真正的成功标志。他还会额外用 Hugging Face Transformers 库的模型做一次并行验证，确保两者生成的文本完全相同（即使存在微小的浮点舍入差异，也在可接受范围内）。

当前 LLM 架构最核心的工程挑战

通过长期追踪 50 多个 LLM 架构的演进，Sebastian 总结出了当前整个领域最关注的核心工程挑战：如何在保证模型质量的前提下，尽可能压缩 KV Cache 的内存占用。

要理解这个问题，首先要明白 KV Cache 是什么。在 LLM 推理过程中，每生成一个 token，都需要执行一次自注意力计算。计算过程中需要用到 Query（查询）、Key（键）和 Value（值）这三个矩阵。在自回归生成的框架下，已生成 token 的 Key 和 Value 在之后的每一步都会被反复复用——与其每次重新计算，不如将它们缓存起来，这就是 KV Cache。问题在于，当上下文变得越来越长时（比如现在的推理模型需要输出大量中间思考步骤，或者 Agent 应用需要将整个代码仓库的信息提供给模型），KV Cache 的内存占用会急剧膨胀，甚至成为制约推理效率的主要瓶颈。

在这个背景下，Sebastian 详细拆解了当前主流的几种 KV Cache 优化技术。

第一种是 Group Query Attention（GQA，分组查询注意力）。这是 Llama 2 引入的技术，核心思想是在多头注意力的多个 Query 之间共享同一组 Key 和 Value。比如原本有 4 个 Query 头和 4 组 K-V 头，现在改为 4 个 Query 头共享 2 组 K-V 头，KV Cache 的大小立刻减半。代价是这种共享是一种近似，信息密度会有所下降，但实际使用中效果通常可以接受。GQA 的优势在于实现相对简单，因此被大量主流模型采用，包括 Llama 3、Quen 3、Gemma 4 等。

第二种是 Multi-Latent Attention（MLA，多潜在注意力），由 DeepSeek 架构首先提出。与 GQA 直接共享 K-V 不同，MLA 引入了一个"压缩"的概念：先通过一个下投影矩阵将 Key 和 Value 压缩到一个更小的潜在空间，再进行共享；在推理时再通过上投影恢复。这个思路类似于将一个高分辨率的图像压缩成 JPEG 后存储，使用时再解压——信息损失更少，但实现复杂度更高。Sebastian 提到，MLA 在大参数规模（例如 100B 以上）的模型上通常能取得比 GQA 更好的效果，但在小模型上，GQA 可能已经足够好。

第三种是滑动窗口注意力（Sliding Window Attention）。在传统自注意力中，每个 token 可以attend到之前所有 token 的 Key 和 Value。但在滑动窗口机制下，每个 token 只能看到最近 N 个 token（比如 256 个），超出窗口范围的 token 对应的 K-V 可以直接丢弃，从而节省大量内存。Gemma 4 就采用了这种策略，并配合 5:1 的滑动窗口层与全局层交替比例，确保重要信息不会被完全遗忘。

第四种是 DeepSeek 提出的 Sparse Attention（稀疏注意力）。这是滑动窗口注意力的进阶版——不是简单地固定一个窗口大小，而是通过一个可学习的选择模块，在训练过程中自动决定每个 token 应该attend到过去哪些位置。这种"智能选择"通常比简单固定窗口能更好地保留关键信息。

第五种是 Mamba 2 等状态空间模型（SSM）层对注意力层的替代。状态空间模型是另一种架构范式，它的优势在于完全不依赖 KV Cache——计算成本是线性而非二次的。Intel Neotron 3 等模型已经在部分层中用 Mamba 2 替代了传统的注意力层。

第六种则是对 KV Cache 本身进行量化压缩——将原本用 16 位浮点数表示的 Key-Value 张量压缩到更低精度，从而在数值上实现 5 倍左右的压缩率。Sebastian 特别提到，TPU（Google 自研的 TPU 处理器）因为对内存带宽的高需求，采用了这种技术，甚至一度导致了内存芯片供应商股价的波动。

推理模型与 Agentic Loop：2026 年的热点

在讨论完 KV Cache 优化这一核心工程挑战后，Sebastian 进一步将视野扩展到了整个 LLM 应用层当前的演进方向。

首先是推理模型（Reasoning Models）的兴起。Sebastian 指出，大约从 2024 年底开始，“推理模型"这个概念变得炙手可热。与传统的 chatbot 直接给出答案不同，推理模型会先生成一段"思考轨迹”（thinking trace）——也就是大量的中间推理步骤，然后再给出最终答案。这种方式在处理复杂数学题、编程题等需要多步推理的问题时，显著提高了正确率。然而，这种能力是有代价的：思考轨迹本身就构成了超长的上下文，这意味着 KV Cache 的压力成倍增加。这也正是前面提到的各种 KV Cache 优化技术变得如此紧迫的根本原因——没有这些优化，推理模型的推理成本将是难以承受的。

更深一层的趋势是 Agentic Loop（Agent 循环）正在成为 2026 年最热门的应用范式。Sebastian 以自己搭建的一个小型编程 Agent 为例来说明这个概念。在传统 chat 界面中，用户输入一段文字，模型输出一个回复，交互就此结束。而在 Agent 模式下，模型被嵌入到一个循环的控制框架中：首先模型会"感知"当前的执行环境（比如扫描一个代码仓库），然后"决策"要调用哪个工具（比如执行一条 bash 命令或创建一个新文件），接着"执行"该操作并观察结果，再将结果反馈给模型进行下一轮推理。这个循环持续进行，直到任务完成。

为了支撑这种 Agentic Loop，需要一系列工程基础设施的配合：实时的仓库上下文注入（让模型能够看到当前代码库的状态）、提示缓存（避免每轮都重新计算不变的上下文）、工具调用接口、短期记忆管理等。这些组件共同构成了一个完整的 Agentic Harness。Sebastian 强调，这些基础设施的完善程度，在很大程度上决定了 Agent 应用的实际可用性。

从入门到专家的学习路径

演讲的后半部分，Sebastian 分享了他认为最有效的 LLM 学习路径，按深度分为四个层级。

入门级的核心资源是 nanoGPT 和 minGPT。nanoGPT 是 Andrej Karpathy 创建的一个极简 GPT 实现，代码清晰易懂，整个模型的核心逻辑可以放在几百行 Python/PyTorch 代码中。对于想要真正理解 GPT 工作原理的初学者来说，从头读懂 nanoGPT 的每一行代码，并尝试自己实现一遍，是最好的起步方式。

进阶级可以转向 lit-LLaMA 项目。LLaMA 架构是目前开源模型中使用最广泛的架构之一，lit-LLaMA 提供了 LLaMA 的完整实现，相比 nanoGPT 增加了 RoPE 位置编码等更复杂的机制。此外，还可以尝试用 LLaMA 架构配合小规模参数（70M 到 1B）模型，在自己的数据集上跑一遍预训练流程。

到了专业级，Sebastian 推荐使用已经高度优化好的生产级库来完成真实项目。Transformers 库是最成熟的选择，拥有详尽的文档和广泛的社区支持；TorchTitan 是 PyTorch 官方团队维护的预训练库，专注于多 GPU 分布式训练的高效实现；TRL（TinyReinforcement Learning）则专注于基于人类反馈的强化学习（RLHF）和各种后训练技术。这些库经过了大量工程优化，适合用于实际的 LLM 应用开发和微调。

专家级则是真正的大模型预训练。这个层级的成本极高——训练一个具有数十亿参数的大模型需要数百甚至数千 GPU 的算力支撑。Sebastian 提到了一些在预训练层面相对透明的公司和项目：Meta 的 LLaMA 系列（模型权重已开源，但训练代码不完全开源）、Mistral（社区口碑极佳的法国 AI 公司）、Intel 的 Neotron 3（提供了非常详细的训练代码）等。他特别指出，在 expert 级别之前打下的扎实基础非常重要——如果能在小模型上把架构细节理解透彻，再去看大模型的训练代码，就会有一种"原来如此"的通透感。

新书《Build a Reasoning Model from Scratch》

演讲临近尾声时，Sebastian 分享了他的最新著作《Build a Reasoning Model from Scratch》。这本书由 Manning 出版社发行，全书约 528 页，是他历时一年半以上完成的最为雄心勃勃的写作项目。

书中涵盖了当前 LLM 研究中最前沿的几个主题：推理 Scaling（如何通过延长推理时的计算来提升模型性能，类似于 o1/o3 模型背后的技术）、强化学习在 LLM 后训练中的应用，以及模型蒸馏（如何将大模型的能力压缩到小模型中）。Sebastian 透露，书中包含数百个精心设计的实验，每一个实验都配有详细的代码和图表，帮助读者理解这些前沿技术背后的核心原理。

这本书目前已经在 Manning 官网开放预购，电子版可以提前阅读"预发布版本"（MEAP）。Sebastian 表示，虽然排版和配色还不是最终版本，但内容已经完整，对于想要系统学习推理模型背后技术的读者来说，这是一份不可多得的深度学习资源。

结语

整场分享的核心信息，或许可以归结为一句话：动手实现，才是理解大模型的唯一正道。Sebastian Raschka 通过他个人多年积累的研究方法论，展示了如何从技术报告、配置文件、代码实现和参考对比四个维度，层层剥开每一个 LLM 架构的内部奥秘。无论是 KV Cache 优化的工程考量、Gemma RMS Norm 的细节洞察，还是从入门到专家的完整学习路径，这场分享都为 AI 研究者和工程师提供了一条可操作的深度学习进阶路线图。在大模型日新月异的当下，唯有深入理解底层原理，才能在这一轮技术浪潮中保持真正的竞争力。

---

假如你从2026年开始学大模型，按这个步骤走准能稳步进阶。

接下来告诉你一条最快的邪修路线，

3个月即可成为模型大师，薪资直接起飞。

阶段1:大模型基础

阶段2:RAG应用开发工程

阶段3:大模型Agent应用架构

阶段4:大模型微调与私有化部署

配套文档资源+全套AI 大模型 学习资料，朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】👇👇

配套文档资源+全套AI 大模型 学习资料，朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】👇👇