devgo.cn核心观点
- 理解新发布的开源模型，工作流的起点是官方技术报告，但 2026 年的论文往往没有过去详细——尤其工业实验室的开源模型。
- 更可靠的来源是「会运行的代码不会说谎」：只要权重在 Hugging Face Model Hub、模型被 transformers 支持，直接检查 config 文件与参考实现就能拿到架构细节。
- 流程主线是「从 config 文件与代码到架构洞察」：配置揭示嵌入维度、层数、注意力变体、MoE 路由等关键参数，参考实现给出精确计算过程。
- 这是刻意的手工流程——目标是学会理解架构，而不是自动化抓取；亲手过几个模型仍是学习 LLM 架构最好的练习之一。
内容精讲
面对层出不穷的开源权重模型，怎么快速、准确、不靠猜地理解一个新模型的架构？这套工作流把答案收敛为一条主线：从官方技术报告开始，但不要停在报告上——因为 2026 年的论文通常比过去更简略，尤其是工业实验室发布的开源模型。真正可靠的抓手是 Hugging Face Model Hub 上的权重与 transformers 库里的参考实现。
**为什么代码比论文可靠。** 论文描述的是「设计意图」，可能滞后、可能美化、可能含糊；而能跑的参考实现是「实际发生的事」——config 文件里的每个数字和代码里的每个计算都对应模型的真实结构。「working code doesn't lie」，这是整个工作流的信念基础。当然这个流程只适用于开源权重模型：ChatGPT、Claude、Gemini 这类闭源模型权重与细节不可得，无从谈起。
**config 文件里有什么。** 一个 transformers config.json 通常直接暴露：嵌入维度、层数、注意力头数与头维度、KV cache 相关的注意力变体（MHA/GQA/MLA 等）、MoE 的路由配置（专家数、激活参数）、激活函数、滑动窗口设置、rope 配置。这些参数合在一起，已经能画出架构图的 80%。比如一个 config 里出现 `num_experts` 与 `num_experts_per_token`，马上就知道这是 MoE 模型、每 token 激活多少个专家；看到 `sliding_window` 就知道用了滑动窗口注意力。
**参考实现补上剩余环节。** config 给「参数」，参考实现给「过程」：注意力计算是标准 MHA 还是 MLA？KV cache 怎么组织？MoE 路由在计算图里怎么落位？推理时的形状推导是什么？代码逐行读过去，架构图中的每个框就都有了精确的含义。对画架构示意图的人来说，这也是为什么这些图总是从 config + 代码里「长」出来，而不是从论文的文字描述里「译」出来。
**为什么故意手工。** 这套流程完全可以部分自动化——写脚本解析 config、自动生成图。但目标是「学习架构」，亲手过几个模型的价值无法被自动化替代：你在读 config 时被迫思考每个参数的意义、在翻代码时被迫理解每个张量的形状流转，这种主动认知恰恰是自动化会剥夺的部分。所以它被刻意设计成「有引导的手工劳动」。
**适用边界与实战建议。** 适合所有开源权重模型，闭源不适用；适合想在架构层面建立判断力的学习者、画模型对比图的作者、以及需要确认「某个新模型到底用了什么机制」的工程师。推荐路径：先读论文抓大意，再开 config 对关键数字，再到参考实现里验证那些「看起来不太对」的地方——通常那里藏着最有价值的设计。
阅读价值
对 LLM 学习者与研究者，这是一套可复现的架构拆解方法，从 config 到实现的路径能让「读新模型」从玄学变成流程；对工程团队，它也提供了一个评估候选模型时的标准动作：在信任任何基准与宣传之前，先检查它的真实结构。
内容与图片版权归原作者所有 · 原文: https://magazine.sebastianraschka.com/p/workflow-for-understanding-llms