模型推理究竟是如何工作的？整个流程实际上可以拆解为两个关键阶段：预填充（Prefill）和解码（Decode）。首先来看 Prefill 阶段，该阶段会将输入的所有 Token 一次性喂给模型，并行计算出每个 Token 的隐藏状态（即 hidden states）。这些隐藏状态后续用途广泛，例如为 Decode 阶段生成内容、执行分类任务或进行其他下游处理。而 Decode 阶段则每次只接收一个 Token，借助 KV-Cache 避免重复计算；每一层的自注意力机制读取已有的 KV-Cache，再生成新的 KV 值。

以下几个要点值得关注：

• 统一的 61 层结构：Prefill 和 Decode 共用这 61 层，没有额外的子层划分。
• Prefill 的特点：一次性输入所有 Token，并行计算，无需 KV-Cache。
• Decode 的特点：每次仅输入 1 个 Token，依赖 KV-Cache 来降低计算开销。
• MoE（稀疏专家）：这是每层结构的一部分，无论 Prefill 还是 Decode，都会按需启用，通过稀疏计算提升效率与扩展能力。

一、DeepSeek R1 的部署架构解析

从逻辑架构来看，R1 设有 61 个 decoder 层，每层配置了 256 个路由专家、8 个激活专家和 1 个共享专家。最简部署方案可采用 SGLang 方式，在 8 张 MI300X 或 8 张 H200 上运行。当然，面对大规模并发场景，还有更优化的策略。

首先说说模型逻辑：每一层都有 256 个路由专家，但推理时并非所有专家同时工作；对于每个输入 token，仅激活其中 8 个——也就是那 8 个激活专家。此外，有 1 个共享专家，所有 token 都必须经过它，无需经过稀疏路由。

在Prefill 阶段，官方配置为 EP32 / DP32。集群规模为 4 个节点，每个节点 8 张 GPU，共计 32 张 GPU。部署时，将 256 个路由专家分布到 32 张卡上，但每张卡并非简单放置 8 个，而是放 9 个——多出 1 个冗余副本。表面上看是 32 张卡 × 9 个路由专家 = 288 份，比 256 多了 32 个冗余副本。这样做的目的很直接：让那些频繁被调度的专家拥有更多副本，在多卡之间平衡负载。同时，共享专家采用数据并行，每张卡复制一份，因此每张卡实际承载的是“9 个路由专家 + 1 个共享专家”。逻辑上仍是“256+1”，只是物理上增加了冗余。

到了Decode 阶段，配置变为 EP144 / DP144。此时需要更多节点：18 个节点 × 8 张 GPU = 144 张 GPU。256 个路由专家被重新分布到 144 张卡上，每张卡放置 2 个，结果又是 144 × 2 = 288 份，比 256 多了 32 个冗余。共享专家继续数据并行，每张卡最终包含“2 个路由专家 + 1 个共享专家”。同样的逻辑框架，只是并行规模改变，专家分布也随之调整。

那么8 个激活专家是如何与分布式布局关联的？简单来说，当一个 token 进入时，门控路由系统会从 256 个（物理上是 288 个）路由专家中挑选出最匹配的 8 个来执行计算。无论 Prefill 阶段每卡有 9 个专家，还是 Decode 阶段每卡只有 2 个，门控系统都能跨卡、跨专家副本找到那 8 个，并将计算负载路由过去。冗余副本越多，单卡拥堵的概率越低，整体吞吐量自然随之提升。

一句话总结：从模型逻辑看，就是“256 个路由专家 + 8 个激活专家 + 1 个共享专家”。但部署到数十上百张 GPU 时，会将 256 个专家带上冗余副本分散到不同卡上。32 张卡时，每卡 9 个，总共 288 份；144 张卡时，每卡 2 个，也是 288 份——都是“256 + 32 冗余”。共享专家则简单地在每卡复制一份（DP）。最终形成官方提到的两个配置：Prefill 阶段 EP32 / DP32，每卡“9 路由 + 1 共享”；Decode 阶段 EP144 / DP144，每卡“2 路由 + 1 共享”。而“每层 256+1”的 MoE 结构以及“8 个激活专家”的框架，始终不变。