DeepSeek部署实践解析

Prefill 阶段的输出，指的是模型在一次性处理所有输入 Token（即 Prompt Tokens）后，为每个输入 Token 生成的隐藏状态（hidden states）。这些隐藏状态可以被用于后续任务，比如解码阶段的进一步生成、分类任务，或者其他下游操作。

要点总结：  

1. 统一的 61 层结构：

   - Prefill 和 Decode 阶段均使用相同的 61 层结构，无需额外子层划分  

2. Prefill 阶段特点：

   - 一次性输入所有 Token，进行并行计算  

   - 不需要 KV-Cache

3. Decode 阶段特点：

   - 每次输入 1 个 Token，利用 KV-Cache 避免重复计算  

   - 每层的 Self-Attention 读取 KV-Cache 并生成新的 KV  

4. MoE（稀疏专家）： 

   - MoE FFN 是每层结构的一部分，Prefill 和 Decode 阶段均按需使用  

   - 提供稀疏计算以提升模型效率和扩展能力  

二、R1的部署架构

逻辑上，R1有61个decoder层，每层 256 个路由专家 + 8 个激活专家 + 1 个共享专家。最简配置可以以SGLang的方式在8个MI300X或者8个H200上部署。

DeepSeek R1满血版on Azure AMD MI300X

但如果面对大规模并发时，可以参考优化配置。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. 模型逻辑：
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   • 每一层都有 256 个“路由专家”，也就是最多可供选择的专家总数为 256。
   • 但推理时，并不是 256 个专家同时计算，而是对每个输入 token 只激活其中 8 个（也就是“8 个激活专家”）。
   • 此外，还有 1 个“共享专家”，所有 token 都必须经过它（不需要稀疏路由）。
   
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2. Prefill 阶段配置：EP32 / DP32
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   • 集群的规模：4 个节点 × 8 张 GPU/每节点 = 32 张 GPU。
   • 官方给出的部署：一次性把 256 个路由专家分布到 32 张卡上，但带有“冗余”，因此每张卡上不是 256 ÷ 32 = 8，而是放了 9 个路由专家。
   • 这样算下来：32 张 GPU × 每卡 9 个路由专家 = 288 份路由专家副本。
   – 从 256 到 288，多出了 32 个“冗余专家（副本）”。这样做通常是为了让常被调度的专家有更多副本，在多卡之间平衡负载。
   • 与此同时，“1 个共享专家”走数据并行，也就“每张卡都复制一份”。因此每张卡上看到的就是“9 个路由专家 + 1 个共享专家”。
   • 总结：逻辑上依然是“256 个路由专家 + 1 个共享专家”，只是物理上多了一些冗余，让每张卡都放 9 个，从而凑足“EP32 + DP32”。
   
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
3. Decode 阶段配置：EP144 / DP144
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   • Decode 阶段使用更多节点：18 个节点 × 8 张 GPU/节点 = 144 张 GPU。
   • 这个阶段又把 256 个路由专家分散到 144 张卡上，同样会有冗余，因此每张卡上放 2 个路由专家。
   • 结果：144 张 GPU × 每卡 2 个路由专家 = 288 份路由专家副本。
   – 和 Prefill 时一样，也比 256 多出 32 个，做冗余或负载均衡用。
   • “1 个共享专家”继续以数据并行方式复制到这 144 张卡上；所以这时每张卡显示为“2 个路由专家 + 1 个共享专家”。
   • 逻辑层面还是“256 + 1”，只是在不同并行规模下，专家被重新分布并且带冗余，形成“EP144 + DP144”。
   
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
4. “8 个激活专家”与分布的关系
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   • “每个 token 激活 8 个专家”说的是：当输入进来时，门控路由会从 256（物理上 288）个路由专家里选最匹配的 8 个执行运算。
   • 无论是在 Prefill（每卡 9 个）还是 Decode（每卡 2 个）阶段，对应的门控系统都能在所有卡、所有专家副本中找到所需的那 8 个专家，并把 token 的计算负载路由过去。
   • 冗余副本越多，越能缓解单卡拥堵并提升整体吞吐。
   
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5. 一句话总结
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   • 模型从训练或逻辑角度看：一层“256 个路由专家 + 8 个激活专家 + 1 个共享专家”。
   • 部署到数十上百张 GPU 时，会把这 256 个专家带冗余副本拆分到不同卡，比如 32 张卡时是“每卡 9 个 → 共 288”，144 张卡时是“每卡 2 个 → 共 288”，都属于“256 + 32 冗余”。与此同时，那个“1 个共享专家”就简单地在每卡各复制一份（DP）。
   • 最终就形成官网提到的：
   – Prefill 阶段：EP32 / DP32，每张卡“9 路由 + 1 共享”
   – Decode 阶段：EP144 / DP144，每张卡“2 路由 + 1 共享”
   同时保持“每层 256 + 1”这一 MoE 结构和“8 个激活专家”大框架不变。