前言：1.6 万亿参数的工程美学

"Architecture is the thoughtful making of space." —— Louis Kahn

当一个 1.6 万亿参数的稀疏 MoE，在 1M token 上下文里，把单 token 推理 FLOPs 压到上一代的 27%，把 KV cache 压到 10%——这不是参数的胜利，是空间的胜利。

一、序幕：2026 年 4 月 24 日凌晨的那次推送

2026 年 4 月 24 日凌晨，杭州西溪园区某栋安静的办公楼里，DeepSeek 的工程师们把一个被命名为 DeepSeek-V4 的预览版模型推到了 Hugging Face 上。

凌晨四点，仓库 deepseek-ai/DeepSeek-V4-Pro 出现了第一条 commit。仓库里悄悄躺着六类文件——

DeepSeek-V4-Pro/
├── README.md                       # 13.2 KB，模型卡 + BibTeX
├── DeepSeek_V4.pdf                 # 4.48 MB，技术报告
├── LICENSE                         # 1.08 KB，MIT
├── config.json                     # 1.83 KB，架构配置
├── generation_config.json          # 170 B，推理默认值
├── inference/
│   └── model.py                    # ~800 行，完整推理实现
├── encoding/                       # 提示编码与 chat template
│   └── encoding_dsv4.py
└── model-{00001..00064}-of-00064.safetensors  # 64 个权重分片，总 865 GB（FP4 + FP8）

这是一份克制到近乎吝啬的发布：

• 没有花哨的 demo 站点
• 没有 50 页的 prompting guide
• 模型卡只列了一张 BibTeX 和三组关键数字
• 整个推理流程压在一个 inference/model.py 里，没有任何抽象层

但这份吝啬，给真正想懂 LLM 内核的人留下了世界上最干净的一份阅读材料。

而恰恰是这种"克制"——一份可以一口气读完的源码 + 一份技术报告 + 一组配置文件——决定了这本书能成立。

一·补：V4 发布后的开源生态三条传导路径

V4 的影响力发布后沿着三条独立路径扩散——每一条都是可以观察到的公开事实，不需要任何内部资料：

第一条路径：推理引擎集成

V4 模型卡在 HuggingFace 上一个月内累计下载量达到 137,784 次（HF 页面统计），是 V3 系列发布同期可观测下载量的数倍。下游推理引擎（vLLM / SGLang / TensorRT-LLM 等）需要为 DeepseekV4ForCausalLM 这个新 architecture 适配 KV cache 结构、稀疏 kernel、路由器等组件——这是引擎社区在 V4 发布后的主要工作。这条路径上的关键词是"怎么把 V4 跑起来"。

第二条路径：价格基线下移

V4 Pro 的官方 API 单价是 $0.145 / M input + $3.48 / M output，V4 Flash 是 $0.14 / M input + $0.28 / M output（来自官方 API 文档）。这个价格组合把"开源 + 1M 上下文 + 接近 frontier 模型质量"的最低单价基线一次性大幅下移。这条路径上的关键词是"价格塌陷"——任何依赖闭源 LLM 的产品都需要重新评估"该不该把后端从闭源切到 V4"。

第三条路径：研究社区的可复现性

V4 把技术报告 + 完整源码 + 完整权重 + 配套 kernel 仓库（FlashMLA / DeepGEMM / DeepEP） 一起开源在 MIT 许可下。这意味着研究社区可以完整复现它的训练栈与推理栈，对 Hyper-Connections / sqrtsoftplus / FP4 expert 等设计做独立验证。这条路径上的关键词是"研究可复现"——开源的真正力量不只在于"用"，更在于"可以被任何人挑刺与改造"。

这三条路径合起来，决定了 V4 不只是一次模型发布，更是一次开源生态的版本号 +1——所有跟 LLM 相关的工程决策、研究选题、商业模式，都需要把 V4 加入坐标系才能继续走。

二、三组数字：V4 真正颠覆了什么

打开 README.md，模型卡的开头写着三组数字。它们看起来像是营销话术，但只要你顺着源码读完一遍，就会发现它们是结构性突破的客观刻度：

flowchart LR
  V32["DeepSeek-V3.2 基准<br/>(1M context)"]:::base
  V4Flops["V4 推理 FLOPs<br/><b>= 27% × V3.2</b>"]:::win
  V4KV["V4 KV Cache<br/><b>= 10% × V3.2</b>"]:::win
  V4Price["V4 Pro Decode 价格<br/><b>= 大约 V3.2 的 1/3</b>"]:::win

  V32 -->|混合注意力 CSA + HCA| V4Flops
  V32 -->|Compressor + Indexer + sparse_attn| V4KV
  V32 -->|FP4 experts + FP8 linear + Muon 训练栈| V4Price

  classDef base fill:#1f2937,stroke:#475569,color:#e2e8f0;
  classDef win fill:#312e81,stroke:#6366f1,color:#fafafa;

第一组数字，关乎可以负担——之前要 8 张 H800 才能塞下的 1M 上下文推理，现在 2-3 张就行； 第二组数字，关乎可以扩展——KV 的 10% 不是简单加压缩，而是把序列从"线性 KV 增长"改造成"分层稀疏 KV"； 第三组数字，关乎可以普及——一个对标 GPT-5.5 / Claude Opus 4.7 的开源模型，把 token 价格压到了不到对手的三分之一。

后两组数字本质上来自前一组：FLOPs 降下来 → KV 降下来 → 显存利用率提高 → 单卡并发提高 → 单 token 成本下来。一切的源头，都是那条"混合注意力"流水线——也就是 V4 在源码层面真正动了大手术的地方。

这本书会一行行带你看，那条流水线长什么样，每一段为什么要这么写。

二·补 在 V4 发布第 4 天就动笔，是不是太急了

写一本"V4 源码剖析"在 V4 发布第 4 天动笔，会有几个明显的风险：

• 正式版还没发布——Preview 与 GA 之间的代码可能微调
• 生态适配还没完成——vLLM / SGLang / TensorRT-LLM 的支持还在路上
• 社区共识还在形成——独立研究者对 V4 各处设计的分析还没充分展开

但选择"现在写"，是基于三个判断：

1. 越早写、越能保住读者的"第一手感"——V4 发布后 1-2 个月，市面会涌现大量二手解读。这些解读里多数是"读了别的解读之后写的解读"，第一手的源码视角反而被稀释。在第一手材料还在 HF 仓库 main 分支的此刻动笔，能把"原始源码"这一手感传递给读者。
2. GA 与 Preview 的差异，可以用版本号注释处理——本书每一处源码引用都标注了 commit hash 与 HF revision。如果 GA 版本与 Preview 有差异，本书会在对应章节加一个版本号注释，而不是推倒重来。这是工程上可以承受的代价。
3. V4 的"反常识"设计在源码里都已经定型——HC、Compressor、Indexer、grouped O、FP4 expert 这些核心设计在 Preview 版的源码里已经写死。后续无论 GA 还是社区适配，这些核心都不会变。这本书写的就是这些核心。

换句话说——这本书赌的是"V4 的核心设计已经稳定"，而不是"V4 的所有数字都已经稳定"。前者比后者重要得多。

二·补·补 为什么"800 行源码"是黄金标准

很多大模型框架的代码量动辄数十万行——HuggingFace transformers 主仓库 60 万+ 行、vLLM 主仓库 30 万+ 行、Megatron-LM 也有 10 万+ 行。但 DeepSeek-V4 的全部推理实现只有约 800 行——压在 inference/model.py 一个文件里。

这种"小而完整"对学习者来说是稀缺的：

• 可以一次读完：800 行是一个有耐心的工程师两个晚上能读透的量
• 没有抽象层逃避：所有的 dispatch 都明面写在调用点，不用穿越 5 层基类才能找到真实计算逻辑
• 没有遗留补丁：作为 2026 年新发布的代码，没有"为了兼容 2018 年某个 GPU 而留的 hack"
• 没有测试 / utils 噪音：纯粹的模型定义，无 train loop、无评估代码、无序列化代码

类比一下：读 Linux kernel 的网络栈需要先理解 kernel 整体架构，读 PostgreSQL 的查询规划器需要先吃透整个 PG 编译流程；但读 V4 的推理实现，直接打开文件就行。

这种黄金标准在历史上能找到几个对应物：

• Karpathy 的 nanoGPT（300 行讲 GPT）
• llama2.c（700 行讲 Llama2 的 C 实现）
• 早期版本的 PyTorch（核心几千行）

V4 把 1.6T MoE 的推理压在 800 行的同一类作品里。这本书所做的，就是带你一行一行读这 800 行——告诉你每一行背后的设计选择、它的上下游、它在前作里是什么样、为什么 V4 这样改。

三、这本书写给谁

如果你属于以下任何一种身份，这本书就是为你准备的：

如果你刚开始接触 LLM，建议先把官方技术报告读完一遍，再回来跟着源码读这本书——本书不会从"什么是 attention"讲起，那些前置知识是可以从《PyTorch 内核源码剖析》《vLLM 推理内核深度解析》两卷打底拿到的。

三·补 看完这本书你能"会"什么

源码书的价值不在于"知道",而在于"会"。读完这本书你应该具备以下五项可验证的能力：

能力一：能在 vLLM / SGLang 主仓库读懂任何 V4 相关 PR

V4 上线后下游引擎会持续合并 V4 适配 PR——KV cache 形状改造、稀疏 kernel 集成、YaRN 长上下文调优、grouped O 投影的 fused kernel 等等。这些 PR 的改动通常涉及"多个引擎模块的非平凡协作"。读完本书，你不需要任何额外资料就能直接打开 PR 描述、扫一遍 diff、判断它是否正确。

能力二：能从 V4 的 config.json 反推出该尺寸的 KV / FLOPs / 显存占用

第 1 章的动手实验给了你这套反推方法。掌握之后，下次任何一个新 MoE 模型发布——不管是 V5 / Qwen4-MoE / Llama 5——你都能在 5 分钟内从 config 反推出"它在 1M context 下大概要几 GB KV、单 token decode FLOPs 是多少"，从而判断它的工程经济性。

能力三：能独立写一个简化版的 384-expert + Hash-routing + sparse-attention 模型

第 2-9 章的源码逐行剖析给了你重构所需要的全部模块。结合 PyTorch（这本书系列另一卷讨论的）和 nanoGPT 模式的训练 loop，你能用 200-500 行代码实现一个"能跑、有 V4 关键创新"的 toy model——尺寸缩小到 100M 总参，可以在单卡 A100 上训练数小时见效果。

能力四：能识别其他论文 / 开源项目里"看起来新颖"实则是 V4 同源思路的设计

V4 在架构层做的几个创新（HC、Compressor、Indexer、grouped O、attn_sink）会被其他模型陆续 copy。读过本书后，看到任何论文 / 模型说"我们引入了 X 机制"，你能立刻判断它与 V4 的对应模块是否同源、做了哪些扩展或改造。这种"识别同源思路"的能力是在快速演进领域里"不被概念噪音淹没"的关键。

能力五：能跟资深 LLM 架构工程师做实质对话

在这个领域,所有人都在吃 V4 的源码。读完本书，你跟任何一个资深 LLM 工程师讨论"V4 的哪个设计你觉得不够好"、"V5 如果出可能会怎么改"、"V4 在某种特殊负载下会有什么 bug"——这些对话你都能加入并贡献观点。这是一种**"加入领域核心圈"**的工程身份。

四、本书的写作方法：源码原教旨主义

写一本"源码剖析"，最容易掉进的坑是把源码贴上来后用一段抽象文字复述一遍。读者读完，得到的还是 抽象的二手描述——离真相又远了一层。

这本书坚持三条铁律：

4.1 真实代码，标到行号

凡是引用源码，全部以官方仓库为准，并在引用处给出"文件路径:行号"标注，例如：

inference/model.py:459 的 Attention.__init__ 中，self.wq_b = ColumnParallelLinear(self.q_lora_rank, self.n_heads * self.head_dim) 表明 Q 投影矩阵被切分到 TP 多卡。

我不会"凭印象写出类似的代码"。如果一段细节没法在 HF 仓库里被精确定位，本书宁可不写。

4.2 设计意图先行，源码居中，工程实践收尾

每一节都遵循"为什么 → 怎么做 → 实战代价"的递进：

• 为什么要这样设计——把作者面对的 trade-off 列出来
• 源码怎么实现——给出最关键的几段代码和它们的串联关系
• 真实工程代价——这段实现在生产里会遇到什么问题、对部署有什么约束

4.3 图先于文字

V4 的源码里有大量"看起来很普通的张量操作"，但只要画一张图，结构就会跳出来。本书每章至少 2 个 Mermaid 图（架构图、序列图、状态图、数据流图）或对比表格。文字写得再清楚，也不如一张正确的图能帮读者建立脑内模型。

flowchart TB
  subgraph 读者期望["读者真正需要的"]
    A1["1. 这段代码在<b>什么位置</b>"]
    A2["2. 它<b>为什么</b>这样写"]
    A3["3. 它给<b>谁</b>用"]
    A4["4. 它<b>不能</b>怎么写"]
  end
  subgraph 普通源码书["普通源码书提供的"]
    B1["✓ 贴源码"]
    B2["✗ 复述源码"]
    B3["✗ 偶尔讲设计"]
    B4["✗ 不讲约束"]
  end
  subgraph 本书做法["本书坚持的"]
    C1["✓ 源码 + 行号"]
    C2["✓ 设计意图先行"]
    C3["✓ 用 Mermaid 标位置"]
    C4["✓ 工程代价 / 不能怎么写"]
  end
  普通源码书 -.->|读完仍困惑| 读者期望
  本书做法 -->|读完能复述| 读者期望

四·补 一本源码书的工程纪律

源码书在工程上的纪律，归根到底就两条：真实与密度。

真实意味着：

• 每段源码都先 Read / Grep 验证存在，再标 文件路径:行号
• 每个性能数字都标来源（README / 论文 / 第三方 benchmark）
• 不"凭印象写类似的代码"——任何"看起来对"的代码都先回到 HF 仓库主分支验证
• 不引用 SEO 农场博客的二手论断；引用论文给 arXiv / DOI 链接

密度意味着：

• 每一段文字都问"这一段有源码 / 数据 / 决策 / 案例之一吗？"——没有就删
• 不在章末写"本章圆满结束"、"愿读者一帆风顺"——这些都是填充
• 不重复已有内容凑字数——不会"小结一下刚才说的"
• 不写"作者反复强调"、"如前所述"、"本章再次提醒"——这些都是元注释，不是知识

杨艺韬讲堂的 21 本书都遵循这两条纪律。这本书是第 22 本——纪律没有任何放松。

四·补·补 给不同读者的精读路径

如果你时间紧、想在 1-2 周内吃透 V4 的核心，按你的身份选一条路径：

推理工程师（vLLM / SGLang / TensorRT-LLM 内核侧）

00 前言 → 01 全景 → 02 MLA → 03 Compressor → 04 Indexer
   → 05 sparse_attn 内核 → 19 部署 → 20 生态

主线是"模型架构 → 引擎对接"。重点章是 5、19——一个讲 V4 的稀疏 kernel 长什么样，一个讲 vLLM / SGLang 怎么把这些 kernel 接进 PagedAttention / 调度器。读完这条线，你应该能在 vLLM 主仓库里看懂任何与 V4 相关的 PR。

训练与对齐工程师

00 前言 → 01 全景 → 07 Gate → 08 Hash → 09 Expert
   → 10 HC → 11 MTP → 17 Muon → 18 后训练 → 14 QAT

主线是"参数空间 → 训练栈 → 后训练"。重点章是 10、17、18——HC 让你理解 V4 的"残差替代品"为什么稳定，Muon 让你理解 V4 的优化器选型，后训练让你理解 V4 的"领域专家 + 蒸馏"两阶段。读完这条线，你应该能独立设计一个简化版的 384-expert MoE 训练 pipeline。

算法研究者（架构与稀疏注意力方向）

00 前言 → 01 全景 → 02 MLA → 03 Compressor → 04 Indexer
   → 05 sparse_attn → 06 YaRN → 10 HC

主线是"V2 / V3 / V3.2 → V4 的算法演进"。重点章是 4、10——Indexer 是稀疏注意力研究的最新工业实证，HC 是"残差以外的 path mixing"研究方向的工业实证。读完这条线，你能看清 V4 在"稀疏 + 残差替代"这两个学术热点上的工程选择。

量化 / 精度工程师

00 前言 → 01 全景 → 12 FP4/FP8 几何 → 13 DeepGEMM
   → 14 QAT → 15 分布式 → 16 DeepEP

主线是"精度选择 → kernel 实现 → 分布式开销"。重点章是 13、14——DeepGEMM 是 V4 FP8/FP4 GEMM 的核心实现，QAT 章节讲的 act_quant 路径决定了 V4 在生产中精度损失的来源。

架构师 / 决策者

00 前言 → 01 全景 → 11 MTP → 18 后训练 → 19 部署 → 20 生态

主线是"全景 → 训练 → 部署 → 选型"。这条路径不深入源码细节，但能让你做出"该不该用 V4"、"用 Pro 还是 Flash"、"自建还是用 API"这些战略决策。

五、源码版本锁定（重要）

V4 当前为 Preview Release，2026-04-24 在 Hugging Face 首次提交，源码、配置、权重都可能在正式版释出前继续微调。本书所有源码引用基于以下版本：

取源命令（建议读者跟读时同步拉到本地）：

# 1. 模型仓库（含 inference/model.py、config.json、权重清单）
#    注意：如果你只读源码，加 --no-checkout-lfs 跳过 865 GB 权重
git clone https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro
cd DeepSeek-V4-Pro
git lfs install --local
# 只拉取小文件，不拉权重：
git lfs pull --include="*.json,*.py,*.md,*.pdf"

# 2. 三个工程仓库
git clone https://github.com/deepseek-ai/FlashMLA.git
git clone https://github.com/deepseek-ai/DeepGEMM.git
git clone https://github.com/deepseek-ai/DeepEP.git

如果未来 V4 GA（正式版）的代码与本书引用版本出现实质差异，本书会在每章页眉补一行"V4 GA 适配差异：xxx"。

五·补·补 本书所引用事实的"五级证据"

为了让读者能信任这本书的每一个断言，所有内容按"证据强度"分五级处理：

A 级 - 源码可验证：可以直接 git clone https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro 后用 grep 找到。例如"Indexer 类有自己的 Compressor"——任何人 5 秒能确认。本书的源码引用全部是 A 级。

B 级 - 配置可验证：可以从 config.json / generation_config.json 直接读出。例如 "hc_mult=4"、"n_routed_experts=384"。这些数字不会变（除非 GA 调参）。

C 级 - 官方文档可验证：可以从 README / 技术报告 PDF 找到。例如"V4 用 Muon 优化器"、"32T+ tokens pretrain"。如果 PDF / README 后续更新，本书会同步更正。

D 级 - 论文可追溯：依赖外部已发表论文（YaRN / GQA / Streaming LLM 等）。引用时给 arXiv / DOI。

E 级 - 工程推断：基于源码 + 配置做的推断（如"为什么是 16 组 group"、"为什么前 3 层 hash"）。本书会显式标注"这是基于 X 的工程推断"。这一级别是本书写作中最容易出错的地方——读者发现错误请联系作者，会在再版中修正。

本书严格不做的事情：

• ❌ 编造没有公开过的内部细节（"团队某次会议决定..."）
• ❌ 引用不可追溯的二手博客作为论据
• ❌ 用形容词代替数字（"性能很强"、"训练很稳"）
• ❌ 凭印象写"类似的代码"

读到 D / E 级别时请保持适度怀疑，欢迎反馈。

六、阅读路径推荐

V4 的源码不长，但信息密度极高。强行从第 1 章读到第 20 章是可行的，但更建议按你最关心的入口切入：

flowchart LR
  Start(["开篇 / 第 1 章<br/>架构总览"])
  Att["第 2-6 章<br/>注意力革命"]
  HC["第 10-11 章<br/>HC + MTP"]
  MoE["第 7-9 章<br/>MoE 引擎"]
  Prec["第 12-14 章<br/>FP4 / FP8"]
  Dist["第 15-16 章<br/>分布式"]
  Train["第 17-18 章<br/>训练与对齐"]
  Deploy["第 19-20 章<br/>部署与生态"]

  Start --> Att --> HC --> MoE --> Prec --> Dist --> Train --> Deploy

  Start -.推理工程师快路径.-> Att -.-> Deploy
  Start -.训练工程师快路径.-> MoE -.-> Train
  Start -.精度 / 量化工程师快路径.-> Prec -.-> Dist

• 推理工程师快路径：开篇 → 第 2-6 章注意力革命 → 第 19 章部署
• 训练工程师快路径：开篇 → 第 7-9 章 MoE → 第 17-18 章训练对齐
• 精度 / 量化工程师快路径：开篇 → 第 12-14 章混合精度 → 第 15-16 章分布式

六·补 一段写在卷首的"开源伦理"声明

V4 的开源是 MIT 许可——意味着你可以商业使用、修改、分发，无需付费、无需归属于 DeepSeek 团队。这种慷慨在 LLM 商业化白热化的 2026 年是反常的。

本书的态度是：配得上这份慷慨，最起码的方式是认真写。

具体来说：

• 本书引用 V4 源码时，永远先 Read 验证存在再标行号——不会用一个虚构的行号让 V4 团队"被引用了从未写过的代码"
• 本书在比较 V4 与其他模型时，永远基于公开数据——不会用"听说"的内部信息把 V4 写得比实际更好或更差
• 本书的"工程推断"小节（第 1 章 §1.5·补、§1.12·补 等），都明确标注"这是基于公开线索的推断"——不会让读者把推断当作官方立场
• 本书的"批评"段落（如有），都基于源码可证伪的事实——不会做无实质依据的攻击

这些都不是"特别高的标准",而是"写源码书应有的最低标准"。本书会守住这个最低标准。

七、丛书定位：V4 这本在大版图里的位置

杨艺韬讲堂目前已经覆盖三大领域共 21 本开源专著，本书是 AI Agent / LLM 卷的第 9 本：

AI Agent / LLM 卷:
  ├─ Claude Code 源码剖析
  ├─ Harness Engineering
  ├─ MCP 协议剖析
  ├─ LangChain
  ├─ LangGraph
  ├─ RAG 工程实践
  ├─ vLLM 推理内核                ◀── 本书第 5、19 章会反复引用
  ├─ LLM 评估工程（Evals）         ◀── 本书第 18 章会引用
  ├─ DeepSeek V4 源码剖析（本书）
  └─ PyTorch 内核源码剖析          ◀── 本书第 12-13 章会引用

它与 vLLM 卷形成"模型 ↔ 引擎"的对偶——

• vLLM 卷讲：给定一个模型，引擎怎么把它跑得最快？
• 本书讲：模型本身的结构，决定了引擎能怎么跑它。

它与 PyTorch 卷形成"算法 ↔ 框架"的对偶——

• PyTorch 卷讲：torch.float8_e4m3fn、view_as_complex、torch.distributed 这些原语怎么实现
• 本书讲：这些原语在 V4 源码里被组合成了什么样的工程结构

它与 Evals 卷形成"训练 ↔ 评估"的对偶——

• Evals 卷讲：怎么科学地度量一个模型
• 本书第 18 章讲：V4 的 SFT / RL / 蒸馏阶段是怎么用 evals 闭环驱动的

每写 3 章，本书会主动给读者拉一条到丛书其他卷的钩子。这些钩子不是"交叉营销"，而是让你知道这部分知识在更大版图里的位置。

八、我对读者的承诺

这本书不会出现以下内容：

• ❌ "DeepSeek V4 是一种 Mixture-of-Experts 模型"——这种用概念解释概念的循环定义
• ❌ "V4 的性能很强"——没有具体数字的形容词堆叠
• ❌ "想必读者已经理解"——绕过难点的偷懒
• ❌ "类似的代码大概是这样"——凭印象编造源码
• ❌ "本章感谢读者支持"——填充段、抒情段

这本书会出现以下内容：

• ✅ 每段源码引用都带 文件路径:行号 锚点，可直接 git blame 验证
• ✅ 每个设计决策都给出"作者面对的两条路 / 为什么选这条"
• ✅ 每章至少一张 Mermaid 图、一个真实事故案例或性能数字
• ✅ 每 3 章一次跨卷关联，告诉你这部分知识在丛书中的对偶卷在哪里
• ✅ 章末"动手实验"——一份可以在个人 GPU 或 CPU 上 run 起来的最小复现

字字如黄金，不堆形容词，不凑字数，不重复结尾。

八·补 这本书与杨艺韬讲堂"风格连贯性"的关系

杨艺韬讲堂的 22 本书都遵循一致的写作风格——这种连贯性对系列读者很重要。本书在以下细节上与前 21 本保持一致：

章节结构：

• 每章开篇有"问题引入"小节（§1）——用故事或场景把读者拉进来
• 中段做"宏观 → 中观 → 微观"的递进——先全景架构、再模块关系、最后核心代码
• 结尾有"动手实验"和"延伸阅读"——给愿意深入的读者下一个钩子
• 章末小结用"过渡到下一章"的引子收尾

源码标注：

• 引用代码块用 ```python 包裹
• 文件路径采用相对仓库根的形式：inference/model.py
• 行号引用采用 文件名:行号 格式：inference/model.py:459（基于 HF revision deepseek-ai/DeepSeek-V4-Pro main 分支当前 commit，文件总长 827 行）

跨卷引用：

• 第一次引用其他卷用全名 + 链接：《[vLLM 推理内核深度解析](../../vllm/)》
• 后续引用用简称：vLLM 卷第 5 章
• 引用必须给出"具体能在那本书学到什么"，而非泛泛的"请参考"

章节命名：

• 章节标题动词优先："深入剖析"、"逐行追踪"、"对比与权衡"——不用"概述"、"介绍" 这类静态名词
• 子章节采用 §X.Y 编号，便于跨章引用

Mermaid 风格：

• 架构图用 graph TD 或 flowchart TB
• 序列图用 sequenceDiagram
• 决策图用 flowchart + 菱形判断节点
• 颜色统一使用项目 config.ts 里定义的"杨艺韬讲堂主题色"——不用 mermaid 默认蓝黄

这些一致性不是束缚，而是为了让系列读者不需要重新学习每一本书的"读法"——把认知开销留给真正的技术内容。

九、致谢与版权

感谢 DeepSeek 团队把这份 1.6T MoE 完整开源，并在 README 第一行写下"License: MIT"——开源世界因这种慷慨而能继续生长。

感谢 vLLM、SGLang、FlashAttention、ColossalAI、Megatron-LM、HuggingFace transformers 这些社区——本书引用的几乎所有"对比基准"，都来自它们多年积累的工程语料。

本书所有正文采用 CC BY-NC 4.0 许可，引用源码部分遵循 DeepSeek 与对应仓库的 MIT 许可。

下一章，我们从 V2 那个 236B MoE 起步，沿着 V3 / V3.2-Exp 一路走到 V4——看 DeepSeek 是怎么用四代模型把"稀疏 + 长上下文 + 低精度"这条路一寸寸磨出来的。

第 1 章：V4 之路：从 V2 / V3 / V3.2 到 V4 的架构演进 →