PyLLM

主题

1.3 DeepSeek 的技术架构：MoE + 混合推理 ​

671B 参数但只激活 37B——MoE 架构让 DeepSeek 用 1/18 的计算量跑出 671B 的效果。

这一节在讲什么？ ​

前面两节我们聊了 DeepSeek 是什么、它的模型家族怎么选。这一节我们要往深处走——DeepSeek 为什么能做到"又大又便宜"？答案在于两个关键技术：MoE（Mixture of Experts）架构和混合推理架构。MoE 让 DeepSeek 拥有 671B 参数的"知识储备"，但每次推理只激活 37B 参数的"计算量"——这就是它便宜的根本原因。混合推理架构让同一个模型支持"快思考"和"慢思考"两种模式——简单问题快速回答，复杂问题深度推理。理解这些技术原理，你才能明白 DeepSeek 的价格为什么这么低、推理为什么这么强。

MoE 架构：671B 参数，只激活 37B ​

MoE（Mixture of Experts，专家混合）是 DeepSeek 最核心的架构创新。理解 MoE 之前，先理解传统 Dense 模型的问题。

Dense 模型 vs MoE 模型 ​

Dense 模型（如 GPT-4、Claude）：

  输入 token → [所有参数都参与计算] → 输出 token

  每次推理，模型的每一个参数都要参与计算
  参数量 = 计算量
  671B 参数 → 每次推理需要 671B 的计算量

MoE 模型（如 DeepSeek）：

  输入 token → [路由器选择相关专家] → [只有被选中的专家参与计算] → 输出 token

  每次推理，只有部分"专家"参与计算
  参数量 ≠ 计算量
  671B 参数 → 每次推理只需 37B 的计算量

用一个生活中的比喻：

  • Dense 模型像一个"全科医生"——每个病人来了，他都要调动所有医学知识来诊断，不管问题是感冒还是心脏病。
  • MoE 模型像一个"医院"——有 256 个专科医生（专家），病人来了，分诊台（路由器）根据症状分配给 8 个相关专科医生，只有这 8 个医生参与诊断。

DeepSeek 的 MoE 架构具体参数：

DeepSeek-V3/R1 的 MoE 架构：

  总参数量：671B
  每次激活的参数量：37B
  专家数量：256 个
  每次激活的专家数量：8 个
  激活比例：37B / 671B ≈ 5.5%

  这意味着：
  - DeepSeek 的"知识储备"是 671B 参数
  - 但每次推理的"计算成本"只有 37B 参数
  - 相当于用 1/18 的计算量获得了 671B 的效果

MoE 为什么便宜 ​

MoE 的经济价值在于推理成本与激活参数成正比，而不是与总参数成正比：

同样生成 1000 个 token 的推理成本：

  Dense 671B 模型（假设存在）：
  → 每个token需要 671B 的计算量
  → 需要数十张 H100 GPU
  → 成本极高

  DeepSeek MoE 671B：
  → 每个token只需 37B 的计算量
  → 只需要几张 GPU
  → 成本与 37B Dense 模型相当

  这就是 DeepSeek API 价格只有 GPT-4 1/10 的根本原因：
  它用 37B 的计算量实现了接近 671B 的效果

MoE 的代价 ​

MoE 不是没有代价的——它的"代价"是显存：

MoE 的显存需求：

  虽然 MoE 每次推理只激活 37B 参数
  但所有 671B 参数都需要加载到显存中
  → 推理时显存需求 ≈ 671B 模型的显存
  → 只是计算量减少了，不是显存减少了

  这意味着：
  - API 调用：用户不需要关心显存，DeepSeek 服务器承担
  - 本地部署：需要足够的显存加载所有参数（蒸馏版解决了这个问题）

混合推理架构：快思考与慢思考 ​

从 V3.1 开始，DeepSeek 引入了混合推理架构——一个模型同时支持"快思考"（非推理模式）和"慢思考"（推理模式）。

快思考 vs 慢思考 ​

快思考（非推理模式，deepseek-chat）：

  用户问题 → 模型直接生成回答
  → 速度快、成本低
  → 适合简单任务

  示例：
  用户："用 Python 写一个快速排序"
  模型：直接输出代码（1-2 秒）

慢思考（推理模式，deepseek-reasoner）：

  用户问题 → 模型先内部推理 → 再生成回答
  → 速度慢、成本高，但更准确
  → 适合复杂任务

  示例：
  用户："证明快速排序的平均时间复杂度是 O(n log n)"
  模型：
    <think)>
    让我分析这个问题...
    快速排序的分区操作...
    递归树的期望深度...
    ...
    </think)>
    最终回答：证明过程...
  （5-10 秒）

这个设计借鉴了诺贝尔经济学奖得主丹尼尔·卡尼曼的"系统1/系统2"理论——系统1（快思考）处理简单直觉任务，系统2（慢思考）处理复杂推理任务。DeepSeek 把两种模式融合到一个模型中，通过参数控制切换。

混合推理的技术实现 ​

混合推理的关键是后训练策略的分化：

DeepSeek-V3.2 基座模型
  │
  ├── 非推理模式（deepseek-chat）
  │   → 标准 SFT + RLHF 训练
  │   → 优化目标：快速、准确、遵循指令
  │
  └── 推理模式（deepseek-reasoner）
      → 大规模强化学习（RL）训练
      → 优化目标：深度推理、思维链完整
      → 训练数据：数学证明、逻辑推理、算法设计

两条线共享同一个基座模型，但通过不同的后训练策略分化出不同的行为模式。这意味着 DeepSeek 不需要维护两个独立的模型——一个模型通过参数切换就能实现两种模式。

蒸馏技术：大模型的"浓缩精华" ​

蒸馏（Distillation）是 DeepSeek 另一个重要的技术——它让普通硬件也能运行 DeepSeek 的推理能力。

蒸馏的原理 ​

蒸馏的核心思路是：用大模型的推理数据训练小模型，让小模型学会大模型的"思维方式"。

蒸馏过程：

  1. 用 DeepSeek-R1（671B）生成 80 万条推理样本
     每条样本包含：问题 + 完整思考过程 + 最终答案

  2. 用这些推理样本微调小模型（如 Qwen2.5-7B）
     小模型学习 R1 的推理模式

  3. 得到蒸馏模型（如 DeepSeek-R1-Distill-Qwen-7B）
     7B 参数，但推理能力远超原始 Qwen2.5-7B

蒸馏跟微调（Fine-tuning）的区别在于：微调是用"答案"训练模型，蒸馏是用"思考过程+答案"训练模型。模型不仅学到了"正确答案是什么"，还学到了"怎么推导出正确答案"。

蒸馏的效果 ​

蒸馏的效果令人惊讶——7B 蒸馏版在 AIME 2024 上超过了 Qwen3-8B（+10.0%），与 Qwen3-235B 相当。这意味着：

一个 7B 的蒸馏模型 ≈ 一个 235B 的原始模型的推理能力

  原因：蒸馏模型继承了 R1 的推理策略
  意义：普通消费级 GPU 就能运行接近 o1-mini 的推理模型

常见误区 ​

误区一：671B 参数意味着需要 671B 的显存

MoE 架构只激活 37B 参数，推理成本与 37B Dense 模型相当。但所有 671B 参数都需要加载到显存中——所以 API 调用不需要关心显存（DeepSeek 服务器承担），本地部署需要考虑显存（但可以用蒸馏版解决）。

误区二：MoE 模型比 Dense 模型质量差

不一定。MoE 的"稀疏激活"意味着每个 token 只由最相关的专家处理，而不是所有参数。在理想情况下，这比 Dense 模型更高效——因为每个专家可以专注于自己擅长的领域。DeepSeek 的实际表现证明了 MoE 模型可以达到甚至超过同等参数量的 Dense 模型。

误区三：蒸馏模型只是"缩小版"的 R1

不是简单的"缩小"。蒸馏模型用的是不同架构的基座（Qwen/Llama），但通过 R1 的推理数据训练，学会了 R1 的推理策略。它不是 R1 的"缩小版"，而是"学会了 R1 思维方式的小模型"。

误区四：混合推理意味着 V3 和 R1 完全一样

它们共享基座模型，但后训练策略不同。V3 优化的是"快速准确地回答"，R1 优化的是"深度推理后再回答"。同样的基座，不同的训练目标，导致了不同的行为模式。

小结 ​

这一节我们深入了 DeepSeek 的技术架构：MoE 架构让 671B 参数的模型只需 37B 的计算量，这是 DeepSeek 便宜的根本原因；混合推理架构让同一个模型支持快思考和慢思考两种模式；蒸馏技术让普通硬件也能运行 DeepSeek 的推理能力。理解了这些技术原理，你就能明白为什么 DeepSeek 能做到"又大又便宜"——不是偷工减料，而是架构创新。下一章我们开始动手，从注册 API Key 到第一次调用。

基于 MIT 许可发布

版权所有 © 2024-至今