产品推广方案范本/百度关键词seo排名优化

1、引言

DeepSeek R1 采用了混合专家（Mixture of Experts，MoE）架构，包含多个专家子网络，并通过一个门控机制动态地激活最相关的专家来处理特定的任务。DeepSeek R1 总共有 6710 亿个参数，但在每个前向传播过程中仅激活 370 亿个参数。模型的每一层都包含 256 个专家，并且每个 token 会并行路由到其中 8 个不同的专家("num_experts_per_tok": 8)进行评估。

2、DeepSeek R1 的混合专家架构

DeepSeek R1 由 61 个 Transformer 层组成。MoE 架构主要在 Transformer 模块的前馈网络（Feed-Forward Network，FFN）层中实现。每个 FFN 层都包含 256 个专家。理解 MoE 位于 Transformer 层的 FFN 中，有助于理解计算的结构以及如何应用分布式。Transformer 层是像 DeepSeek R1 这样的模型的基本构建模块。DeepSeek R1模型的671B总参数中，并不是所有参数都在专家层中。MoE模型的参数可以分为两类：

稀疏参数：只在特定token激活的专家层参数
密集参数：每个token都会使用的共享参数

在DeepSeek R1中每次激活的37B参数具体如下：
1个共享专家（所有token都激活同一个共享专家）
门控网络选择的8个普通专家（从255个普通专家中选择）
所以总共是9个专家

参数计算：

共享专家的参数量与普通专家相当（约2.6B参数）
总共激活的参数 = 1个共享专家(~2.6B) + 8个普通专家(~21B) + 稠密层参数(~13.4B) ≈ 37B

DeepSeek R1专家分布分析

从配置文件中可以看到关键参数：

MoE层的分布：
- "moe_layer_freq": 1 - 这表明每一层都是MoE层，而不是我之前猜测的隔层分布
- "num_hidden_layers": 61 - 总共有61层Transformer块
- 所有61层都包含MoE结构
专家配置：
- "n_routed_experts": 256 - 256个常规路由专家
- "n_shared_experts": 1 - 1个共享专家
- "num_experts_per_tok": 8 - 每个token激活8个路由专家(不包括共享专家)
专家参数量:
- "hidden_size": 7168 - 隐藏层维度
- "intermediate_size": 18432 - 稠密前馈网络的中间层大小
- "moe_intermediate_size": 2048 - MoE专家内部的中间层大小

MoE计算细节

根据配置：

专家参数主要集中在FFN部分，计算每个专家大小约为：
- 7168 × 2048 × 2 ≈ 29.4M参数（输入和输出矩阵）
257个专家(256常规+1共享)×61层 ≈ 约462B参数仅在专家部分

MoE层结构:
[共享专家(1个)] + [普通专家(255个)]
↑ ↑
总是激活选择8个激活
↓ ↓
每个token激活9个专家(1+8)

共享专家能接触到所有数据，学习通用模式，而普通专家则专注于特定类型的输入，两者结合提高了模型的整体能力和效率。共享专家相当于是一个"通用底层处理器"，确保即使路由决策不理想，每个token也能得到基本处理。

3. 推理过程的分解：理解预填充和解码阶段

特征	预填充阶段	解码阶段
计算强度	高	中等
并行化程度	高	低
内存需求	高内存带宽	中等（KV 缓存访问）
关键指标	吞吐量	延迟
典型硬件优化	多 GPU，高计算能力	快速内存访问，低延迟互连

预填充阶段在计算上受限且受内存带宽限制，特别是对于长输入序列。它需要大量的并行处理能力和内存带宽来处理整个输入。解码阶段通常受内存限制，因为它主要涉及访问 KV 缓存并一次执行单个 token 的计算。延迟是此阶段的关键问题。在预填充期间，模型一次性处理整个输入序列。这允许跨输入的不同部分以及跨模型的不同层进行并行计算。在分布式环境中，不同的节点可以并行处理输入的不同片段或不同的层，从而可能显着提高速度。

解码阶段以自回归方式逐个生成输出 token [用户查询。每个新 token 的预测都基于先前生成的 token 和来自预填充阶段的 KV 缓存。由于 token 生成的顺序性质，此阶段通常比预填充阶段慢且并行化程度较低。解码阶段的顺序性质给并行化带来了挑战。

通过分布专家，仍然可以通过减少每个节点在每个 token 生成步骤中的计算负载来提高效率。与预填充不同，解码是按顺序发生的。每个生成的 token 都依赖于前一个 token。这使得跨序列长度进行并行化变得更加困难。然而，在每个 token 生成步骤中，激活专家的计算仍然可以分布在多个节点上，从而降低每个步骤的延迟。

token在transformer层中传递的流程

在每一层中，token首先通过自注意力机制
然后该层的门控网络会独立评估这个token
门控网络动态选择8个最相关的路由专家
token同时也会通过1个共享专家处理
9个专家(8个路由+1个共享)的输出被加权合并
合并后的结果传递到下一层
在下一层，这个过程完全重复，重新选择专家

关键点是：

所有层共享同一个专家池(257个专家)
每层都有独立的门控网络做出独立的专家选择
专家选择是动态的，完全基于token在当前层的表示
不同层可能选择完全不同的专家组合

4、DeepSeek R1 的分布式部署策略

通过将 256 个专家分布在不同的节点上，每个节点仅存储一部分专家的参数。在推理期间，当一个 token 被路由到一组特定的 8 个专家时，只有托管这些专家的节点才需要执行涉及其参数的大量计算。这避免了每个节点都需要访问整个 6710 亿个参数，从而显着减少了需要本地获取和处理的数据量。这种有针对性的参数访问降低了内存带宽需求以及传输到每个节点的数据量。

通过将计算负载分布到多个节点上，可以并行处理更多的 token 和请求，从而实现更高的吞吐量。专家并行通过启用更大的批处理大小，进一步提高了 GPU 矩阵计算效率并提升了吞吐量。DeepSeek 报告每个 H800 节点在预填充期间的平均输入 token 吞吐量约为 73.7k/s，在解码期间的平均输出 token 吞吐量约为 14.8k/s 。处理更大的批次和并行化计算的能力直接转化为在给定时间内服务更多用户或处理更多数据。当工作负载分布化时，系统的总处理能力会增加。

DeepSeek R1 推理并行策略

策略	描述	DeepSeek R1 的优势	DeepSeek R1 中的应用
专家并行 (EP)	将模型专家分布在节点上，允许每个节点处理模型参数的一个子集。	扩展批处理大小，减少每个节点的内存访问，降低延迟。	跨节点的 EP 用于预填充和解码，具有不同的配置。
数据并行 (DP)	将输入数据分布在多个设备上，每个设备都持有模型的副本（或在某些情况下是分区）。	通过避免注意力层中的 KV 缓存重复来提高内存效率（在 MLA 的上下文中）。	DP 与 EP 结合使用，例如预填充期间的 MLA/共享专家 DP32。

5、单机部署deepseek r1的局限性

主要性能影响排序

吞吐量严重受限（最主要影响）
- 并发请求处理能力达到硬性上限，无法超越8卡能力
- 无法通过增加节点横向扩展处理更多并发请求
- 在高负载场景下，请求队列迅速增长
高负载下延迟不稳定
- 随着并发请求增加，热门专家争抢造成性能波动
- 无法通过分布式部署分散负载压力
- 专家访问不均衡导致部分GPU成为系统瓶颈
上下文长度与批量处理互斥
- 长上下文需要占用大量显存存储KV缓存
- 在固定显存条件下，上下文越长，能处理的批次越少
- 这种权衡限制了同时支持长上下文和高吞吐量的能力
资源利用率不均衡
- 热门专家所在GPU可能负载过重
- 冷门专家所在GPU可能相对闲置
- 无法通过动态调整优化全局资源利用

单机部署的资源利用情况

总显存: 8×141GB = 1128GB
FP8模型参数: ~671GB
剩余显存在KV缓存与批处理空间之间权衡
关键规律: 上下文长度增加→可处理批次减少→吞吐量下降

专家在H20 8卡上的实际分布

在H20 8卡(每卡141GB)部署时，专家分布如下：

专家分配策略：
- 256个路由专家均匀分布在8个GPU上
- 每张GPU分配32个路由专家
- 共享专家可能放在其中一张GPU上或复制到多个GPU
显存占用计算：
- 模型总参数：671B
- 单个专家估算参数量：~2.62B (FP8精度下约2.62GB)
- 每张GPU存储32个专家：~84GB
- 基础模型部分(张量并行切分)：~10-20GB
- 总计每卡显存占用：~94-104GB
- 剩余显存(~37-47GB)：用于KV缓存、激活值等