DeepSeek V4 源码剖析

第20章 V4 在开源大模型版图里的位置

作者 杨艺韬 · 5,716 字 · 发布于 · 更新于

每个模型都是一张快照。所有快照连起来的轨迹，才是这个领域本身。

拆完 V4 的源码之后，我们要走出"放大镜"，回到地图——V4 在 2026 年开源大模型版图里到底处在什么位置？接下来 12-18 个月会怎样演进？

20.1 2026 年开源 LLM 版图

把 2026 年 4 月的主流开源 LLM 按"架构 / 上下文 / 训练栈"三个维度摆出来。

先说清楚这张表的出处：DeepSeek V4 Pro 那一行取自 config.json 与 README，Flash 那一行取自 README 与技术报告第 4.2.1 节（本专栏前 19 章逐条核过）；其余各行取自各家官方模型卡（Hugging Face / 官方文档，2026-09-25 查询），只列 V4 发布（2026-04-24）之前已经放出权重的版本，标「—」的格子本专栏未核——它们只用来给 V4 定位，要引用那些模型的规格请回到各自的官方模型卡。

模型 总参/激活 上下文 Attention MoE（路由专家 / 每 token 激活） 权重精度 协议
DeepSeek V4 Pro 1.6T / 49B 1M MLA 演进 + CSA/HCA 稀疏 + 滑窗 384 / top-6（+1 共享） FP4 + FP8 MIT
DeepSeek V4 Flash 284B / 13B 1M 同 Pro（前两层纯滑窗） 256 / top-6（+1 共享） FP4 + FP8 MIT
Kimi K2.6（月之暗面） 1T / 32B 256K MLA 384 / top-8 INT4（QAT） Modified MIT
GLM-5（智谱） 744B / 40B 约 200K（max_position_embeddings=202752） MLA + DSA（DeepSeek 稀疏注意力） 256 / top-8 BF16 MIT
Mistral Large 3 675B / 41B（含 2.5B 视觉编码器） 256K — 细粒度 MoE FP8 / NVFP4 / BF16 Apache 2.0
Qwen3.5-397B-A17B 397B / 17B 原生 256K（官方称可扩到约 1M） 3/4 层 Gated DeltaNet 线性注意力 + 1/4 层 Gated Attention 512 / 10（+1 共享） — Apache 2.0
Llama 4 Maverick 400B / 17B 1M — 128 路由专家 — Llama 4 Community License
Gemma 4 31B 30.7B（dense） 256K 1024 滑窗局部层与全局层交错 - — Apache 2.0

V4 有三条能从一手材料坐实的特征：

  • 1.6T MoE + 1M context + 稀疏 attention——config.json 里 num_hidden_layers=61 / n_routed_experts=384 / num_experts_per_tok=6 / max_position_embeddings=1048576，加上 README 的 CSA + HCA 混合注意力
  • FP4 expert + FP8 其余的混合精度——expert_dtype: "fp4" 与 quantization_config 里的 fp8 / e4m3 / ue8m0 / [128,128]
  • MIT 许可——仓库根目录的 LICENSE 是 MIT，README 写明"本仓库与模型权重均以 MIT License 授权"。同期旗舰里，GLM-5 同为 MIT，Kimi K2.6 是附加条款的 Modified MIT，Qwen3.5、Mistral Large 3、Gemma 4 为 Apache 2.0，Llama 4 则是 Meta 自己的社区许可（月活超 7 亿的使用方须另向 Meta 申请）

这三条让 V4 在"长上下文 + 成本敏感 + 自由商用"三重需求下位置很独特。至于"唯一"——开源版图变化太快，本专栏不下这种断言。

20.2 V4 在 2026 年开源 LLM 版图中的"坐标"

把 V4 Pro / V4 Flash 与 §20.1 表里的同期模型放到"上下文长度 × 总参数量"的二维坐标上（两轴都取对数：横轴 4K 到 1M，纵轴 1B 到 2T；上下文按各家标称的原生值）：

quadrantChart
  title 2026 年 4 月开源 LLM 坐标（上下文 × 总参数量）
  x-axis "4K (log)" --> "1M"
  y-axis "1B (log)" --> "2T"
  quadrant-1 "大参数 + 长上下文"
  quadrant-2 "大参数 + 较短上下文"
  quadrant-3 "小参数 + 较短上下文"
  quadrant-4 "小参数 + 长上下文"
  "DeepSeek V4 Pro": [0.97, 0.97]
  "DeepSeek V4 Flash": [0.97, 0.74]
  "Kimi K2.6": [0.75, 0.91]
  "GLM-5": [0.71, 0.87]
  "Mistral Large 3": [0.75, 0.86]
  "Llama 4 Maverick": [0.97, 0.79]
  "Qwen3.5-397B": [0.75, 0.78]
  "Gemma 4 31B": [0.75, 0.45]

V4 Pro 在右上角：同期放出权重的模型里总参数最大，上下文也是原生 1M。Llama 4 Maverick 同样标称 1M，但总参 400B；Qwen3.5 原生 256K、官方称可扩到约 1M；Kimi K2.6、GLM-5、Mistral Large 3 这几个大 MoE 的上下文在 200K-256K 一档。

这张坐标图给"什么场景选 V4"提供了一个粗略的判断：需求落在 256K 以上的长上下文时，V4 是少数原生支持 1M 的可下载选择；上下文需求不长时，可选的开源模型多得多。

20.3 V4 vs Qwen3.5 / Llama 4 / Gemma 4 选型对比

把 V4 与几个同期开源模型按场景做选型对比（规格取自 §20.1 的官方模型卡与 V4 README；本专栏没有做横向实测）：

长文档分析（200K-1M context）

指标 V4 Pro Qwen3.5-397B-A17B Llama 4 Maverick Gemma 4 31B
1M context 支持 ✅ 原生 原生 256K，官方称可扩到约 1M ✅ 标称 1M ❌（256K）
长上下文的 KV cache 1M 下约 9.6 GiB / 序列（含 Indexer，第 15 章 §15.13 算过） 只有 1/4 的 Gated Attention 层随长度增长，其余线性注意力层是定长状态 本专栏未核 滑窗局部层只存 1024 窗口，全局层随长度增长
部署门槛 Pro 需 8 卡 H200 起（H100 装不下，见第 19 章 §19.7）、Flash 单节点 8 卡 多卡（397B 总参） 多卡（400B 总参） 单张大显存卡量级（31B dense）
单 token 激活参数 49B（README：1M 下单 token FLOPs 为 V3.2 的 27%） 17B 17B 30.7B（dense 全激活）
定位 1M 长文 长上下文 + 多模态 Llama 生态、1M 上下文 单卡部署

推理与代码任务（<128K context）

V4 / Qwen3.5 / Llama 4 / Mistral 在 128K 以内都能用，选型主要看：

  • 成本结构：V4 的激活参数（Pro 49B / Flash 13B）远小于总参数，KV cache 又被压缩与稀疏化——长上下文场景下这个优势最明显；短上下文下它与其他 MoE 的差距要小得多（具体单价请查各家官方定价页，本专栏不给数字）
  • 语言覆盖：各家训练语料的侧重不同，中文场景请以各自公开的中文 benchmark 为准（V4 README 列有 Chinese-SimpleQA），本专栏不做横评
  • 推理模式：V4 提供 Non-Think / Think High / Think Max 三档（README），Qwen3 系列同样区分思考与非思考模式；推理能力的高下请看各家公布的 benchmark

实时对话与端侧

V4 在这个领域不是首选——尺寸太大，Flash 也仍需多卡。Gemma 4 的 E2B / E4B、Qwen3.5 的小尺寸这类模型是更合适的选择。

20.4 V4 对商业模式的冲击

V4 的发布可能对下面几个商业模式产生冲击（本节是本专栏的判断，不是已发生的统计事实）：

闭源 LLM API 服务

V4 的 README 里没有定价信息——本专栏不给具体的 token 单价，那需要查官方定价页，而且会随时间变动。

能从架构讲清楚的是成本结构：推理算力大致与激活参数成正比（V4-Pro 是 49B，Flash 是 13B），长上下文的成本则被 KV cache 主导——而 README 给的官方数字是 1M 上下文下 V4-Pro 相比 DeepSeek-V3.2 只需 27% 的单 token 推理 FLOPs 与 10% 的 KV cache。这两条决定了：

  • 长文档处理类产品（合同分析、研究报告生成）受益最大——它们的成本正好卡在 KV cache 上
  • 短对话产品的成本差异要小得多——那里 KV cache 本来就不是瓶颈
  • 对延迟极敏感的产品（实时对话、客服）仍然倾向闭源 API（更稳定的延迟保证，而且自建 V4 Pro 的门槛见第 19 章）

注意 README 那个对比的基准是 DeepSeek-V3.2，不是 V3——引用时别写错代次。

模型代理 API（中转）

之前依赖"OpenRouter / 多模型聚合 API" 的产品，现在可以直接对接 V4 ——绕过中间层，进一步降本。

训练即服务

V4 公开的是训练方法（Muon + GRPO + on-policy 蒸馏等写在技术报告里）与推理代码、权重，训练代码本身并没有开源；方法公开能降低"自训类似规模模型"的摸索成本，但 33T tokens（Pro；Flash 为 32T）的数据 + 训练算力仍是巨大壁垒——大多数公司仍会选择 fine-tune V4 而非 from-scratch 训练。

长上下文专用模型

之前那种"为长上下文任务单独训一个模型"的做法，价值在下降——V4 的 1M 上下文已经覆盖大部分场景，而且它的长上下文成本曲线比 dense 模型平坦得多。

20.5 V4 推动的 4 个研究方向

V4 的推理源码、权重与技术报告公开后，本专栏预计会推动几个研究方向加速（以下均为预测）：

方向 1：稀疏 attention 的进一步优化

V4 的 Indexer + sparse_attn 是 1.6T 规模的工业实证。预计 12 个月内会有：

  • 更高效的 score net（替代 V4 的 Indexer）
  • 自适应 ratio（运行时根据 prompt 调 compress_ratio）
  • 与 Mamba/SSM 的混合架构

方向 2：FP4 / 更低精度训练

V4 把 FP4 expert 推到了 1.6T 规模并放出可下载的权重（FP4 QAT 只在后训练引入，预训练仍是 FP8 混合精度，技术报告第 3.4 节）。预计后续会有：

  • 全 FP4 训练（不只是 expert）
  • FP3 / FP2 训练的可行性研究
  • 更激进的 ue6m0 / ue4m0 scale 格式

方向 3：Hyper-Connections 的拓展

V4 用的是约束版 mHC（技术报告第 2.2 节），hc_mult=4。预计后续工作会探索：

  • 更高 hc_mult（8 / 16）的可行性
  • HC 在不同规模上的收益曲线（原版 HC 论文的主要实验在 1B、7B 级模型上，V4 把约束版 mHC 用到了 1.6T，中间规模的对比还缺公开数据，见第 10 章 §10.14）
  • 与其他残差变体（Highway / DenseNet）的混合

方向 4：多领域专家 + 蒸馏 pipeline

V4 的两阶段后训练（领域专家独立培养 + on-policy 蒸馏合并）可以看作 R1 路线的一般化。这里的"专家"是独立训练的完整模型，不是 MoE 层里的 routed expert。预计这种做法会被复制到：

  • 多语言专家（每种语言单独培养一个专家模型）
  • 多模态专家（文本 / 视觉 / 音频）
  • 多任务专家（聊天 / 推理 / 工具使用）

预计每个方向都会催生新的开源模型，V4 是它们共同的参照之一。

20.6 V5 可能的方向（推测）

基于 V2 → V3 → V3.2 → V4 的演进规律，对 V5 做一个有依据的推测——只是推测，作者没有任何内部信息：

推测 1：原生多模态

V4 是纯文本。下一代很可能加视觉 / 音频编码器——继承 V4 的 1.6T MoE backbone，前面接专门的视觉 tokenizer（类似 Qwen-VL 模式）。

推测 2：Mamba/SSM 混合

V4 已经把 Compressor 做得像"非 recurrent 状态压缩"。V5 可能正式引入 SSM 层——某些层走 Mamba2，某些层走 V4 attention，混合架构。

推测 3：3M / 10M context

V4 的 1M context 在 float32 精度下接近极限。V5 可能：

  • 用 float64 计算 freqs_cis 支持 10M
  • 引入"层级 KV"（更多 ratio 层级，比如 1024 倍压缩）
  • 探索"按需检索 KV"（不存全部 KV，按需从外部检索）

推测 4：FP4 全栈训练 + 更激进精度

V4 是 FP4 expert + FP8 linear。V5 可能：

  • 全 FP4（包括 linear / attention）
  • 引入 FP6（精度与显存的折中）
  • 与 NVIDIA 下一代硬件（B300 ?）的原生 FP4 / FP6 指令深度集成

推测 5：在线学习 / 持续预训练

V4 是"训完一次就发布"。V5 可能引入：

  • 持续预训练（持续学新数据）
  • 在线 fine-tune（用户反馈实时纳入）
  • federated 训练（多方共训不分享原始数据）

这些都是纯推测——读者请保持适度怀疑。

20.7 V4 之前的 DeepSeek 模型谱系

把 V2 → V3 → V3.2-Exp → V4 这条谱系用 timeline 画出来：

timeline
  title DeepSeek 模型谱系（2024-2026）
  2024-05 : DeepSeek V2 (236B/21B) - MLA + DeepSeekMoE 奠基
  2024-12 : DeepSeek V3 (671B/37B) - 256 expert + FP8 训练
  2025-01 : DeepSeek R1 - 长链推理 + GRPO
  2025-09 : DeepSeek V3.2-Exp - DSA 稀疏注意力实验
  2025-12 : DeepSeek V3.2 - 正式版（V4 README 的对比基线）
  2026-04 : DeepSeek V4 Pro/Flash (1.6T/49B) - HC + 稀疏 + FP4

每代之间的"工程跳跃"：

  • V2 → V3：routed expert 从 160 加到 256（第 1 章 §1.2.2 的谱系是 DeepSeekMoE-16B 的 64 → V2 的 160 → V3 的 256 → V4 的 384）+ FP8 训练栈成熟
  • V3 → R1：训练目标从"通用"到"推理专长"
  • R1 → V3.2-Exp：把推理能力的训练经验回流到 base 模型 + 稀疏注意力试验
  • V3.2-Exp → V4：把所有累积的"稀疏 / FP4 / HC / 多领域后训练" 一次性集成

理解这条演进让你预测 V5 的方向——大概率是"V4 + 视觉模态 + 多模态 SFT/RL + 更长上下文"。

20.8 中国 AI 开源运动的时代位置

V4 不只是一个模型——它是中国 AI 开源运动的一个里程碑。把它放在更大的时代脉络看：

时间 事件 时代意义
2023 年 Llama 2 开源 西方开源开始转向"商业可用"
2024 年 4 Llama 3 8B / 70B 开放权重
2024 年 5 DeepSeek V2 MLA + DeepSeekMoE，236B MoE 开源
2024 年 12 DeepSeek V3 671B MoE + FP8 训练栈
2025 年 1 DeepSeek R1 长链推理开源震撼
2025 年 9 DeepSeek V3.2-Exp 稀疏 attention 工业化预热
2026 年 4 DeepSeek V4 Pro/Flash 1.6T MoE + 1M，权重与推理代码 MIT 开源

V4 延续了 DeepSeek 自 R1（2025 年 1 月）起权重与代码均用 MIT 许可的做法，并把它用到了 1.6T 这一档。这种开放路线对全球 AI 生态的长期影响——超出本专栏技术范围，但值得每个关心 AI 的人持续观察。

20.9 给读者的"读完本专栏之后做什么"

读完这个专栏的 20 章，你已经具备本专栏前言里承诺的 5 项能力（见前言第七节）。接下来的具体行动建议：

短期（接下来 1-4 周）：

  1. 把 V4 的 inference/model.py 完整读一遍，对照本专栏的章节标记每段代码的位置
  2. 跑一遍本专栏的 19 个动手实验，验证你对源码的理解
  3. 在 vLLM / SGLang 仓库里搜 "DeepseekV4"，跟踪最新 PR 进展

中期（1-3 个月）：

  1. 用 V4 部署一个小型项目（个人长文档分析、代码助手等），积累生产经验
  2. 关注 V4 正式版（GA）发布——届时本专栏会在对应章节补注 GA 与 Preview 的差异（见前言第十一节）
  3. 阅读本专栏引用的延伸论文中你最感兴趣的 5-10 篇

长期（3-12 个月）：

  1. 跟进 V5 / V6 的发布——用本专栏学到的"读源码"方法论快速吃透新版本
  2. 关注 V4 推动的 4 个研究方向（§20.5），选 1-2 个深入
  3. 把"读源码"的能力迁移到其他领域——本专栏的方法论不限于 V4

20.10 章末：把一切串起来

V4 的故事可以浓缩成一句话：

"用稀疏注意力 + 超连接 + FP4 expert + Muon 优化器，把 1.6T MoE 做到 1M 上下文下只需 V3.2 的 27% 推理 FLOPs 与 10% KV cache——然后 MIT 开源给所有人。"

但这句话要展开成 20 章源码剖析，是因为每一个工程决策的背后都有几代模型踩过的坑、几种替代方案的取舍、几张并行图谱的协调。

这个专栏的目标不是让你"记住 V4 的所有细节"——而是让你学会读 V4 的源码：知道哪些细节重要，哪些细节是历史包袱，哪些细节会在 V5 中被取代。

LLM 演进的速度远超任何技术领域。读完这个专栏，你会发现 V5 / V6 / V7 出来时，读源码的方法是一样的——只是地图换了几个标记点。

"The architecture changes. The reading skill is forever."

写到这里，杨艺韬讲堂《DeepSeek V4 源码剖析》全专栏完。

20.11 全专栏延伸阅读总目录

把全专栏 20 章引用的关键资料汇总——按主题分类：

V4 核心仓库：

  • huggingface.co/deepseek-ai/DeepSeek-V4-Pro — 模型权重 + 源码 + 技术报告
  • github.com/deepseek-ai/FlashMLA — 稀疏 MLA kernel（flash_mla_sparse_fwd）
  • github.com/deepseek-ai/DeepGEMM — FP4/FP8 GEMM，以及技术报告第 3.1 节那套融合 EP 方案的开源实现 MegaMoE
  • github.com/deepseek-ai/DeepEP — MoE all-to-all 通信库（2025 年 2 月开源，早于 V4，服务 V3/R1）

DeepSeek 系列论文：

核心论文：

杨艺韬讲堂相关专栏：

20.12 V4 与"小模型死亡论"的对话

V4 之前几年里有一种说法："小模型快死了——大模型 + 蒸馏会让 7B / 13B 这种规模无法竞争"。V4 出来后这个说法部分被强化、部分被证伪。

部分被强化：

小模型最大的卖点一直是"便宜"。但 MoE 让"便宜"这件事脱钩于总参数量——决定推理成本的是激活参数，V4-Flash 的 13B 激活已经落在小模型的量级上，能力却完全不是一个层级。这意味着小模型的价格优势被严重削弱：同样的单 token 算力预算，用一个 13B 激活的 MoE 比用一个 13B 的 dense 模型划算得多（只算算力；显存上 284B 总参仍要多卡装下）。

部分被证伪：

被证伪的是"小就没有竞争力"这半句：V4 Flash（284B / 13B 激活）说明了"模型大小 ≠ 推理成本"。Flash 的激活参数与 13B dense 模型相当，Base 版却在一大批基准上超过了总参与激活都更大的 V3.2-Base（技术报告第 4.3.2 节）——MoE 让"小激活参数 = 高能力"成为可能。这强化了"未来主流是 MoE 而非 dense" 的趋势。

真正的影响：

小模型不会死，但非 MoE 小模型会变得边缘。未来的主流模型形态是：

  • 旗舰：1T+ MoE（V4 Pro 这一档）
  • 主力：200-500B MoE，13-30B 激活（V4 Flash 这一档）
  • 端侧：3-10B dense（手机、笔记本、边缘）

中间档（30-100B dense）很可能会被 MoE 模型挤压（这是预测）——它们每个 token 的激活参数比 V4 Flash 还多，单 token 算力更贵。

对开源生态的影响：

本专栏预计 Hugging Face 上 30-70B dense 模型会逐渐被 MoE 替代。Llama 4 / Qwen3 已经在向这个方向走——它们的旗舰都是 MoE。V4 是这个趋势的"提前到达"——证明 1.6T MoE 不只是研究品，而是可部署的生产系统。

20.13 给"准备进 LLM 领域的开发者" 的一句话

如果你刚开始进 LLM 领域，读到这个专栏的最后一页时，给一个最实用的建议：

读透一份好的源码剖析，比读一堆博客有用。

V4 的开源推理代码 + 完整技术报告 + DeepSeek 开源的三个工程仓库（FlashMLA / DeepGEMM / DeepEP，其中 DeepEP 早在 V3 时期就已开源），都是一手材料。任何博客 / 视频教程都是从这些一手材料里"二手"出来的——你直接读源码，就站在了离真相最近的位置。

这个专栏的目的不是替代源码——而是给你一份"读源码的地图"。读完地图后，你应该能独立打开 inference/model.py，从第一行读到最后一行，每一行都能联系到本专栏的某个章节。

这是技术的复利——一旦你能直接读源码，每一个新模型（V5 / V6 / Llama 5 / Qwen 4）上手都会快得多。

20.14 V4 给"未读源码就用 LLM"的工程师的一句话

最后一段写给那些"用 LLM 但从来没读过 LLM 源码"的工程师——这部分人是开发者社区的多数，是这个专栏可能间接影响的读者。

如果你属于这类人——会调 OpenAI API、会写 prompt、知道 RAG 是什么、用过 LangChain，但从来没真正打开过任何 LLM 模型的源码——你可能想问：我有必要读 V4 源码吗？

我的回答是：不一定要全读，但应该至少读一遍 inference/model.py。

理由：

LLM 不是"魔法"。V4 的参考推理代码 inference/model.py 只有 827 行 Python（kernel 另在 inference/kernel.py，用 TileLang 写）。你每次调 ChatGPT API、写 RAG 流程、做 fine-tune，背后都是这类代码在跑。你不读这些代码不会让产品做不出来——但你永远停留在"用别人的工具" 的层次。

读完一遍 inference/model.py（哪怕只是粗读，理解 80% 也够），你会获得几个具体能力：

  • 看到任何 LLM 论文，能立刻知道它在源码哪个位置改动
  • 评估 LLM 公司的"声称"（"我们的模型比 V4 快 2 倍"）时有判断基础
  • 设计产品功能时知道"哪些是 LLM 容易做、哪些是 LLM 难做"
  • 跟 LLM 工程师交流时有共同语言，不会被术语云遮蔽

这种能力对任何长期在 AI 领域工作的工程师 都是基础。读不读 V4 是个人选择——但如果你打算在 AI 领域工作 5 年以上，强烈建议你读。

这个专栏是"读 V4 的导览"。读完导览后真正打开 inference/model.py，你会发现它出乎意料地清晰——因为你已经知道每一段在做什么、为什么这样做。

20.15 给"做 AI 创业" 的开发者一句

读这个专栏的另一类读者是"做 AI 创业 / 副业产品" 的开发者。给这类读者一句具体建议：

在 V4 时代，不要从训练大模型开始。

历史上每个新硬件 / 新模型时代都有人想"做下一个 OpenAI"——绝大多数都失败了。资本、数据、算力、团队任何一个短板都让这种创业失败。

V4 的开源（MIT 许可）让 AI 创业的"基础原料"几乎免费——你直接用 V4 / Qwen3 / Llama 4 这些开源模型，跳过训练阶段。这意味着：

  • 不要训练：投资回报远远不够
  • 专注产品：你的优势在哪个领域、哪些用户、什么 workflow
  • fine-tune 而不是 from-scratch：如果你确实需要垂类模型，在合适尺寸的开源模型上做 LoRA fine-tune，成本比从头训练低几个数量级
  • 多模型并存：选 V4 用于长 context、选 Qwen3 / Llama 4 / Gemma 用于短 context、自己搭路由器

具体到产品形态：

  • 法律 / 合同分析：V4 + RAG + 行业知识库 → 有市场
  • 个人助理 / 日记 / 记账：V4 / Flash 太大，选小模型 + 端侧
  • 代码 IDE 插件：V4 的 1M context 适合仓库级理解
  • 长文档处理：V4 的 1M context 是优势（V4 是纯文本模型，视频、音频要先转成文字）
  • 实时聊天：V4 不是首选，选小模型 + 高并发

V4 不会让你的产品自动赢——但它把"让你的产品成为可能" 的门槛大幅降低了。

20.16 全专栏最后一段

做一个"V4 源码剖析"专栏，在 V4 发布第 4 天就动笔，写到第 20 章。这个专栏不会是关于 V4 的最完整资料——技术报告 + 公开 PR + 社区分析最终都会比它更全。

但这个专栏想做的是另一件事：把 V4 当成读源码的训练场，讲方法论而不是知识点——知识点会随版本过时，怎么读懂一个陌生的大型开源项目不会。

如果你读完这 20 章，能在面对下一代开源 LLM 的源码时，第一反应是打开 model.py 而不是搜索博客 ——这个专栏的全部目的就达成了。

写于 2026 年 4 月 28 日，杭州。

——杨艺韬

全专栏完。下一个专栏见。