DeepSeek V4-Pro 的 PDC 分离推理：从计算原理到部署配置

面向 NVIDIA B300 与华为 Ascend 950 Supernode，回答三个问题：几个 P 对几个 D？P/D 各用多少 GPU/NPU？内部并行怎么配？

本文不仅给结论，更完整展示每个关键数字是怎么算出来的——读者可以跟着推导链自己验证。

---

先说结论，再讲为什么

PD 分离部署的核心逻辑只有三层：

NVIDIA B300 基准配置（λ=5.86 req/s, O=512, h=0.56）：

华为 950 Supernode（纯 950DT 保守估算；推荐用 950PR 做 P）：

接下来，我们从头算起。

---

一、V4-Pro 的结构参数：一切计算的起点

在开始算之前，需要先钉死 V4-Pro 的关键参数。这些数字是后面所有推导的地基。

V4-Pro 是一个 1.6T 总参数、49B 激活参数的 MoE（Mixture of Experts）模型。MoE 的核心思想是：模型很大，但每次推理只用其中一小部分。对 V4-Pro 来说：

• 总参数 1.6T，但每 token 只激活 49B——激活率约 3%，这就是 MoE 的效率来源
• 每层有 1 个 shared expert + 384 个 routed experts
• 每 token 激活 6 个 routed experts（top-6 路由）
• Expert intermediate dimension = 3072
• MTP depth = 1（Multi-Token Prediction，预测下一个 token 的同时尝试多预测一个，用于加速 decode）
• 支持 1M context

这几个数字为什么重要？因为它们直接决定了：

1. 每 token 的计算量（FLOPs）→ 决定需要多少算力
2. 每 token 的 KV cache 大小 → 决定需要多少显存
3. Expert 的分片方式 → 决定 EP（Expert Parallelism）怎么配

---

二、先定义 workload，再谈配置

2.1 一个常见的误区

很多人拿到一个模型，第一反应是"这个模型需要多少张卡"。但正确的问题不是"模型需要多少卡"，而是"我的业务需要多少卡"。

同样一个 V4-Pro 模型：

• 如果你的业务是 4K 短对话、30 tok/s 标准速度 → 可能 192 张 B300 就够
• 如果你的业务是 1M 长文档分析、100 tok/s → 至少 576 张 B300
• 差距是 3 倍，全是 workload 差的

所以我们必须先定义 workload。

2.2 四个关键业务参数

决定部署配置的业务参数只有四个：

• λ（请求到达率）：每秒多少新请求
• O（平均输出长度）：每个会话平均输出多少 token
• L（平均输入上下文长度）：每个会话的 prompt 有多长
• h（prefix cache 命中率）：P 层有多少前缀可以跳过计算

有了这四个参数，P 和 D 的负载就完全确定了：

D 端总输出吞吐：Q_D = λ × O（每秒要输出多少 token）

P 端总输入吞吐：Q_P = λ × L × (1 − h)（每秒要处理多少新输入 token，扣掉 cache 命中的部分）

注意 P 端有个 (1−h) 因子——如果 cache 命中了，P 端就不需要重新计算那部分 prompt。

2.3 我们用什么基准来算

本文通篇使用这个基准：

O = 512，h = 0.56，λ = 5.86 req/s

λ = 5.86 不是拍脑袋的数字。它等价于一个具体场景：

想象你有 100 个用户同时在用模型，每个用户的生成速度是 30 tok/s，平均每个会话输出 512 token。 一个会话从开始到结束需要 512 / 30 ≈ 17 秒。 在这 17 秒内，100 个用户轮流产生新请求： λ = 100 × 30 / 512 = 5.86 req/s

同一 λ 下，不同单会话速度对应的活跃会话数完全不同：

这个表揭示了一个反直觉的事实：同样的业务流量（同样的 req/s），单会话速度越快，同时活跃的 decode 会话越少。 400 tok/s 时只有 7.5 个活跃会话。

活跃会话少听起来是好事，但对 MoE 模型来说是个大麻烦——我们后面会展开讲。

---

三、每 token 需要多少计算量（FLOPs）

现在来算 V4-Pro 每处理一个 token 到底需要多少计算。

3.1 基础 FLOPs：为什么是 0.098 TFLOP/token

V4-Pro 每 token 激活 49B 参数。对于 transformer 的线性层，一次前向传播的计算量约等于 2 × 参数量（一次矩阵乘法的 FLOPs 约为 2mn，这里 n 是输入维度、m 是输出维度，权重矩阵有 mn 个参数）。

所以：

基础 FLOPs = 2 × 49B = 98B FLOP = 0.098 TFLOP / token

这是不管 prefill 还是 decode 都要付的"基础计算税"。

3.2 Attention 的额外开销随上下文增长

但上面只算了 feed-forward / MoE 部分的计算量。Attention 部分的计算量跟上下文长度 L 有关：

• Prefill：attention 要处理从位置 0 到 L-1 的所有 KV，计算量约为 attention 参数 × L × 平均位置（从 0 到 L 累积，平均约 L/2）
• Decode：每个新 token 的 attention 要读取所有已有位置（长度 L）的 KV，计算量约为 attention 参数 × L

所以 attention 部分的 FLOPs 可以近似为：

F_decode(L) = 0.098 + 0.202 × L_M TFLOP/output token

F_prefill(L) = 0.098 + 0.101 × L_M TFLOP/input token

其中 L_M = L / 10⁶（以百万 token 为单位）。

Decode 的 attention 项（0.202）是 prefill 的 2 倍，因为 prefill 从 0 累积到 L，平均只需要处理一半的长度；而 decode 每一步都要扫全部 L 个位置。

让我们代入几个具体数字验证一下直觉：

这意味着：1M 场景下，decode 每 token 的计算量是 4K 场景的 3 倍；prefill 每 token 的计算量是 4K 的 2 倍。 上下文长度对计算量的影响不容忽视。

---

四、KV cache：每个会话占多少显存

MoE 模型的 KV cache 跟 dense 模型不同。V4-Pro 使用了异构 KV 结构：CSA/HCA compressed KV、SWA（Sliding Window Attention）KV、state cache 分开管理。我们主要关注 compressed CSA/HCA 部分：

K(L) ≈ 5.3 × L_M GB/sequence

具体数字：

一个重要细节：SWA KV 约为 compressed CSA/HCA KV 的 8 倍。也就是说，如果系统把 SWA 也全量缓存，1M 场景每个会话的 KV 就是 5.3 × 8 = 42.4 GB——一张 B300 GPU 的显存都放不了几个会话。所以 C 层（Cache 层）不能默认全量缓存 SWA，必须做 selective caching。

---

五、P-unit 和 D-unit：为什么先定义单元，再算比例

5.1 为什么不直接说"P:D = 1:1"

很多文章会直接给一个 P:D 比例，比如"P:D = 1:2"。但这个比例没有意义，除非你知道"P 是多大、D 是多大"。

打个比方：说"厨房和人一样多"没有意义，除非你知道这个厨房能出多少菜、这个人能吃多少。一个能同时做 20 道菜的厨房配 20 个吃得不多的人，和一个只能做 5 道菜的厨房配 5 个大胃王，P:D 都是 1:1，但含义完全不同。

所以正确做法是：

1. 先定义 P-unit（一个最小可独立运行 prefill 的部署单元）和 D-unit（一个最小可独立运行 decode 的部署单元）
2. 算出每个 unit 的 goodput（实际有效吞吐）
3. 然后根据业务流量推算需要几个 P-unit 和几个 D-unit
4. P:D 比例是算出来的，不是拍出来的

5.2 P-unit / D-unit 的 goodput 怎么算

Goodput ≠ 裸 FLOPS 峰值。 实际有效吞吐需要考虑：

• 硬件峰值算力 C_node
• 模型在特定 workload 下的硬件利用率 η
• SLA 约束（TTFT 对 P 端、TPOT 对 D 端）
• 通信开销（EP 的 all-to-all 通信）

我们用这个公式：

G_P = reserve × C_node × η_P × 1000 / F_P(L) tok/s

G_D = reserve × C_node × η_D × 1000 / F_D(L) tok/s

其中 reserve 是 SLA 保留余量（P 端留 30% 给突发，D 端留 40% 给 TPOT p90），η 是模型在该硬件上的 FLOPS 利用率。

两个平台的参数：

为什么 D 端利用率比 P 端低这么多？ P 端 prefill 是 compute-bound（大批量处理整个 prompt），硬件利用率高；D 端 decode 是 memory-bound（每步只生成 1 个 token，大量时间花在读取权重和 KV cache 上），硬件利用率天然低。D 端的 0.14/0.12 是 MoE decode 的典型值，不是异常。

这些效率参数来自 DeepSeek V3/R1 在 H800 上的生产数据校准（EP32 prefill + EP144 decode），不是 V4-Pro 实测——这一点后面会反复提醒。

5.3 从 goodput 到 P-unit / D-unit 尺寸

P-unit 和 D-unit 的尺寸不是由平均流量决定的，而是由单会话速度 SLA 和 TPOT（Time Per Output Token）约束决定的。

D-unit 的逻辑最直观：

你的 SLA 是 100 tok/s，等价于 TPOT ≤ 10ms。在 MoE 模型中，每一步 decode 都需要做一次 expert all-to-all 通信。EP 越大（每个 GPU 负责的 expert 越少），每步计算越快，TPOT 越低。

所以 D-unit 尺寸主要由"我要达到多少 tok/s"决定：

EP 跟 GPU 数的关系是什么？ V4-Pro 有 384 个 routed experts。EP128 意味着 384 个 experts 分到 128 个 GPU 上，每个 GPU 放 384/128 = 3 个 expert。同理：

P-unit 尺寸的逻辑类似，但 prefill 是 compute-bound，不需要极低 TPOT，所以 P-unit 可以相对小一些。B300 用 EP64（64 GPU，每个 GPU 6 个 expert），950DT 用 EP128（128 NPU，每个 NPU 3 个 expert）。

---

六、完整推导：从 workload 到 P:D 比例

6.1 通用公式

有了 P-unit 和 D-unit 的 goodput，N_P 和 N_D 的计算就水到渠成：

N_P = ⌈Q_P / G_{P,unit}(L)⌉ = ⌈λ × L × (1−h) / G_{P,unit}(L)⌉

N_D = max(⌈Q_D / G_{D,unit}(L)⌉, N_D^SLA)

其中 N_D^SLA 是满足 TPOT SLA 所需的最少 D-unit 数。

注意 N_D 取 max：即使流量很小，D 端也至少需要 1 个 D-unit 才能保证 TPOT。

6.2 实战推导：B300，128K，100 tok/s

让我们一步步推导一个具体场景：B300 平台，128K 上下文，100 tok/s，基准业务流量。

Step 1：P 端需要处理多少 token/s？

Q_P = λ × L × (1−h) = 5.86 × 128000 × (1−0.56) = 5.86 × 128000 × 0.44

先算 5.86 × 0.44 = 2.578

再算 2.578 × 128000 = 330,000 token/s ≈ 330K token/s

Step 2：一个 P-unit（64 GPU）能处理多少？

F_prefill(128K) = 0.098 + 0.101 × 0.128 = 0.098 + 0.013 = 0.111 TFLOP/token

一个 B300 节点（8 GPU）的 raw 吞吐：

S_P = 36 PFLOPS × 0.45 × 1000 / 0.111 = 145,946 token/s ≈ 146K token/s

8 节点 = 64 GPU 的 P-unit：

G_{P,unit} = 0.7 × 146K × 8 = 817K token/s

Step 3：需要几个 P-unit？

N_P = ⌈330K / 817K⌉ = ⌈0.40⌉ = 1

Step 4：D 端需要处理多少 token/s？

Q_D = λ × O = 5.86 × 512 = 3,000 token/s（约 3000 tok/s）

Step 5：D-unit 至少需要几个？

100 tok/s 对应 D100-unit = 192 GPU (EP192)，每个 D-unit 的 goodput：

F_decode(128K) = 0.098 + 0.202 × 0.128 = 0.098 + 0.026 = 0.124 TFLOP/token

单节点 raw decode 吞吐：

S_D = 36 PFLOPS × 0.14 × 1000 / 0.124 = 40,645 token/s ≈ 40.6K token/s

24 节点 = 192 GPU 的 D-unit：

G_{D,unit} = 0.6 × 40.6K × 24 = 585K token/s

Step 6：

N_D = max(⌈3000 / 585K⌉, 1) = max(⌈0.005⌉, 1) = 1

结果：P1:D1 = 64 + 192 = 256 GPU ✓

你可能注意到，D-unit 的 goodput（585K tok/s）远超业务需求（3K tok/s）。这就是为什么 P:D = 1:1 不是因为 P 和 D 吞吐恰好相等，而是因为 D-unit 的最小可部署粒度已经远超容量下界——你不可能用少于 192 GPU 来做一个满足 100 tok/s SLA 的 D-unit。

6.3 为什么 1M 需要 P6:D1——完整推导

1M 场景是 P 层的噩梦。让我们算清楚为什么。

Step 1：P 端 token/s

Q_P = 5.86 × 1,000,000 × 0.44 = 2,578,000 token/s ≈ 2.58M token/s

对比 128K 的 330K token/s——1M 的 P 端负载是 128K 的 7.8 倍。

Step 2：P-unit goodput 在 1M 下是多少？

F_prefill(1M) = 0.098 + 0.101 × 1.0 = 0.199 TFLOP/token

单节点 raw prefill 吞吐：

S_P = 36 × 0.45 × 1000 / 0.199 = 81,407 token/s ≈ 81.4K token/s

P-unit (8 节点 = 64 GPU) goodput：

G_{P,unit} = 0.7 × 81.4K × 8 = 455.8K token/s

Step 3：

N_P = ⌈2578K / 455.8K⌉ = ⌈5.66⌉ = 6

6 个 P-unit = 384 GPU。

所以 P6:D1 = 384P + 192D = 576 GPU（100 tok/s 场景）。

这 6 个 P-unit 可以独立运行，也可以合并成一个 384-GPU 的 P-supergroup，用 CP8（Context Parallelism 8 路并行）把一个 1M prefill 拆到 8 组 GPU 上并行计算，降低 TTFT。

为什么不直接用更大的 P-unit？ 因为 EP 过大会增加 all-to-all 通信开销。P6 独立运行时每个 P-unit 仍然保持 EP64（每个 GPU 6 个 expert），通信开销可控。合并为 CP8 supergroup 时，每组内部仍是 EP64，跨组只传 KV 而不是 expert weights。

6.4 华为 950 Supernode：为什么 1M 要到 P13:D1 甚至 P16:D1

同样的推导逻辑，但 950DT 的单节点算力更低（8 PFLOPS vs B300 的 36 PFLOPS）。

P-unit goodput（128 NPU）：

F_prefill(1M) = 0.199 TFLOP/token

单节点 raw: 8 × 0.45 × 1000 / 0.199 = 18,091 token/s ≈ 18.1K token/s

P-unit (16 节点 = 128 NPU) goodput: 0.7 × 18.1K × 16 = 202.5K token/s

N_P = ⌈2578K / 202.5K⌉ = ⌈12.7⌉ = 13

P13:D1 = 13 × 128P + 192D = 1664 + 192 = 1856 NPU（取整到 2048 NPU 考虑余量）。

但 P13 不利于规整的 CP 分组——13 不能被整除为合理的 CP × EP 组合。生产建议 P16:D1 = 2048P + 384D = 2432 NPU，用 EP128 × CP16 或 EP256 × CP8。

这就是为什么我们反复说：华为 1M 场景不应该用纯 950DT，应该用 950PR 做 P。 950PR 专门面向 prefill 设计，如果它的 prefill goodput 是 950DT 的 2 倍（合理预期），P 层 NPU 数就能砍掉一半。

---

七、400 tok/s：为什么这个速度特别难

现在回到前面那张表里 400 tok/s 时只有 7.5 个活跃会话的问题。

7.1 Expert microbatch 的灾难

V4-Pro 每 token 激活 6 个 routed experts。如果有 384 个 routed experts，那每个 expert 被激活的概率是 6/384 = 1/64。

假设当前有 B 个并发 token 在做 forward pass，那单个 expert 收到的 microbatch size 是：

B_expert = B × 6 / 384 = B / 64

代入不同速度下的活跃会话数：

expert microbatch = 0.12 意味着：在一个 forward pass 中，平均每个 expert 只收到 0.12 个 token——甚至不到 1 个。GPU 的 GEMM 单元完全吃不饱。

这就是 MoE decode 的根本矛盾：你想要更快的单会话速度，就需要更少的并发流来满足 TPOT；但更少的并发流意味着 MoE expert 的 batch 更小，GEMM 利用率更差。

7.2 怎么缓解

400 tok/s 不是完全不可能，但需要多种技术组合：

1. EP384 或 EP512：每个 GPU 只负责 1 个 expert（甚至不到 1 个），减少 all-to-all 通信量和路由跳数
2. MTP / Speculative Decoding：每步不只预测 1 个 token，而是用 draft model 猜 2-4 个 token，让 expert microbatch × 2-4
3. Hot expert replica：对高频 expert 做多副本，降低单 expert 的负载不均衡
4. D-unit 独立 speed tier：400 tok/s 用户独享 D-unit，不和 30 tok/s 用户混跑
5. 最关键的一点：V4-Pro 实测 TPOT p90

CloudMatrix-Infer 在 DeepSeek-R1 上的实测数据已经表明：TPOT SLO 越严格，batch size 越小，decode throughput 越低。这是 fundamental trade-off，不是调参能解决的。

建议：30 tok/s 作为标准 SLA，100 tok/s 作为高端 SLA，400 tok/s 只能作为 premium/experimental SLA——在没有 V4-Pro 实测数据之前，不要向客户承诺 400 tok/s。

---

八、EP/TP/PP/DP 的具体取舍

8.1 EP 是主轴

整个并行策略的核心是 EP（Expert Parallelism）。原因很简单：V4-Pro 有 384 个 routed experts，天然适合按 expert 切分到多个 GPU 上。

EP 的 trade-off 很清晰：

• EP 越大 → 每 GPU 负责 expert 越少 → 每 step 计算越快 → TPOT 越低
• EP 越大 → all-to-all 通信量越大 → 通信延迟越高

在 decode 场景中，计算很快（memory-bound），通信延迟占比大。所以 EP 不是越大越好，而是要找到 TPOT 的 sweet spot：

8.2 TP 尽量小

TP（Tensor Parallelism）把一个 expert 的权重切到多个 GPU 上。对 MoE 模型来说，TP 会带来两个问题：

1. 增加通信：每步 forward 都需要 all-reduce
2. KV duplication：如果 attention 层也做 TP，KV cache 会在多个 GPU 上重复存储

所以推荐 TP1 起步。只有在 HBM 放不下、或者 1M 场景 KV cache 太大时，才考虑 TP2 + DCP（Decode Context Parallelism）来降低 KV duplication。

8.3 PP 默认 1

PP（Pipeline Parallelism）把模型的不同层放到不同 GPU 上。推理尤其是 decode 默认 PP1——因为 PP 会引入 pipeline bubble（气泡），直接增加 per-token 延迟。

只在一种场景考虑 PP：单 execution group 的 HBM 放不下整个模型。但 V4-Pro 的 MoE 部分通过 EP 已经分散了 expert 权重，dense/shared 部分相对小，PP 的需求不大。

8.4 DP 就是 P/D 副本数

PD 分离中 DP 的最实际含义：

DP_P = N_P（几个 P-unit） DP_D = N_D（几个 D-unit）

扩流量时优先加 DP（加 unit 数量），不要随意改变单个 unit 的 TP/EP/PP。 单 unit 的并行配置是经过 SLA 验证的，改了可能打破 TPOT 约束。

8.5 CP/DCP：1M 场景的关键

CP（Context Parallelism，用于 prefill）和 DCP（Decode Context Parallelism）虽然在"TP/EP/PP/DP"这个标准四件套里没有列出，但 128K+ 尤其是 1M 必须加入设计：

• P 端 CP：把一个长 prefill 的 attention 计算拆到多组 GPU 上并行，降低 TTFT
• D 端 DCP：把 KV cache shard 到多个 GPU 上，降低单 GPU 的 KV 存储压力

1M 场景下一个会话的 KV cache 约 5.3 GB。如果 D 端一个 GPU 同时服务 20 个会话，光是 KV 就是 106 GB——B300 单 GPU 262.5 GB HBM 的一大半。DCP 可以把 KV 分散到多个 GPU，但代价是每次 attention 都需要跨 GPU 读取 KV，增加通信。

---

九、B300 全场景配置速查

综合以上分析，B300 的全场景配置：

P-unit / D-unit 定义

全场景 P:D 配置

基准：λ = 5.86, O = 512, h = 0.56

解读：

• 4K–256K 的 P1:D1：不是因为 P/D 吞吐恰好 1:1，而是因为最小部署单元已经超过了容量下界。P-unit 64 GPU 和 D-unit 128/192/384 GPU 都远超实际流量需要。
• 1M 的 P6:D1：P 层的 1M prefill 是绝对瓶颈。TTFT 随上下文长度线性增长，1M 的 prefill 计算量是 4K 的 200 倍。384 GPU 的 P-supergroup 用 CP8 才能在一个合理时间内完成 1M prefill。

---

十、华为 950 Supernode 全场景配置

10.1 推荐架构

华为方案不建议纯 950DT 平铺，正确架构是：

P 层：950PR（面向 prefill 优化）
D 层：950DT（面向 decode 优化）
C 层：Atlas 950 SuperPoD / UnifiedBus / Kunpeng / EMS / NVMe cache

下面的数字先按纯 950DT 做保守估算。950PR 的实测 prefill goodput 出来后，P 层数量预期会明显降低。

10.2 全场景 P:D 配置（纯 950DT）

基准：λ = 5.86, O = 512, h = 0.56

更规整的 Supernode 生产切片：

10.3 内部并行推荐

---

十一、成本：每百万 token 多少钱

最后来算成本。这个推导链很直接：

$/MTok = GPU 总数 × 每 GPU 每小时成本 ÷ 每小时输出的百万 token 数

每小时输出 token 数 = λ × O × 3600

$/MTok = N_gpu × $/GPU-hour / (λ × O × 3600 / 1,000,000)

成本假设：

• B300：$5/GPU-hour（规划值，非官方定价）
• 950DT：$2/NPU-hour（规划值）

11.1 完整推导一个数字：B300 128K / 100 tok/s

N_gpu = 256 (P1:D1 = 64P + 192D)

每小时输出 = 5.86 × 512 × 3600 = 10,786,432 token ≈ 10.79M token

每小时成本 = 256 × $5 = $1,280

$/MTok = $1,280 / 10.79 = $119/MTok

11.2 完整推导：B300 1M / 100 tok/s

N_gpu = 576 (P6:D1 = 384P + 192D)

每小时输出 = 10.79M token（同一 λ）

每小时成本 = 576 × $5 = $2,880

$/MTok = $2,880 / 10.79 = $267/MTok

11.3 B300 全场景成本

11.4 950DT 全场景成本

11.5 成本解读

几个值得注意的数字：

1. 4K–128K：950DT 名义成本低（$59 vs $89），但这个优势完全建立在 NPU-hour = $2 的假设上。如果实际 NPU-hour 更贵，优势消失。
2. 1M：B300 反而更便宜（$267 vs $379）。原因是 950DT 的 1M 配置在 P 层膨胀到 2048 NPU——单节点算力低导致 P 层需要更多 NPU，而更多 NPU 意味着更高成本。
3. 950DT 要在 1M 打平 B300，NPU-hour 需降到大约 $1.1 以下——比当前假设再砍一半。

---

十二、C 层：P 和 D 之间的 cache 和带宽

12.1 P→D 需要多大带宽

Prefill 完成后，P 层需要把 KV cache 传给 D 层。每个会话的 KV 大小是 K(L)，每秒有 λ 个新会话，所以：

B_{P→D} = λ × K(L)

代入基准 λ = 5.86：

31 GB/s 只是 P→D KV 传输的下界。实际 C 层流量还包括 lookup、D→C write-back、evict、replay 等多路叠加。1M 场景的实际 C 层带宽需求可能在 100-200 GB/s 级别。

这个量级意味着：

• 4K–32K：标准 Ethernet/RoCE 就够
• 128K–256K：需要 RDMA 或 NVLink-domain
• 1M：需要 RDMA + UB（UnifiedBus）+ NVLink-domain KV transfer

12.2 1M 场景的 C 层必须做的事

1M 场景的 cache 策略不是优化项，是生存项：

• prefix hash：相同前缀只存一份 compressed KV
• compressed CSA/HCA KV 优先缓存：SWA 不默认全量缓存
• SWA periodic checkpointing：SWA 做周期性快照，不实时全量保存
• cache-aware routing：请求路由优先打到有 cache 命中的 D-unit
• SSD endurance 管理：on-disk KV cache 的 SSD 写入量巨大，要监控写入寿命
• cache hit 率作为调度目标：不是把请求平均分配，而是优先利用已有 cache

---

十三、P/D/C 调度：不要静态绑定

13.1 三个独立资源池

生产上不要把 P1 永久绑定 D1。应该用三个独立资源池：

P Pool  |  D Pool  |  C Cache Pool

请求流程：

1. Router 做 prefix hash
2. 查 C 层是否命中 compressed KV
3. 命中 → 减少 P 负载，只做 tail recompute
4. 未命中 → 分配 P-unit 做 full prefill
5. P 完成 → 按 D 端负载和 cache locality 分配 D-unit
6. D decode 过程中持续 append KV，可复用部分写回 C 层

13.2 P 层调度看什么

P 层调度不能只看请求数。同样一个请求，4K prompt 和 1M prompt 的 prefill 负载差 250 倍。 长上下文 prefill 应按 token budget 调度——"这个 P-unit 还有 500K token 的 prefill 预算"，而不是"这个 P-unit 还能接 5 个请求"。

13.3 D 层调度看什么

D 层调度要同时看：

• active streams（当前活跃会话数）
• KV length（每个会话的 KV 有多长）
• expert load（expert 负载是否均衡）
• per user speed tier（30/100/400 tok/s 混跑时不能放在同一个 D-unit）
• TPOT p90（实时监控，超出 SLA 要减流）

---

十四、高利用率场景：打满 D-unit 需要多少 P

§6–10 的配置是 SLA-safe 配置——保证 TPOT 和 TTFT，但 D 端利用率很低（D-unit goodput 远超实际流量）。如果目标是把 D-unit 打满（吞吐最优），P:D 会完全不同。

P / D ≈ (L/O) × (1−h) × G_D / G_P

直觉上：上下文越长（L 大）、输出越短（O 小）、cache 命中率越低（h 小），P 层相对 D 层就越大。

B300（P-unit = 64 GPU）

结论：1M、短输出（O=512）、半冷前缀（h=0.56）时，不应该追求 D 满载——否则 P 层会膨胀到无法接受的程度。正确做法是：利用 cache 提高 h，长输出任务分流，或者用更大 EP 做 D-unit 来提高 D 的 goodput。

---

十五、最终推荐

B300

P 层：TP1 / EP64 / PP1，1M 加 CP8 D 层：EP192/384，400 tok/s 必须加 MTP

华为 950 Supernode

首选架构：950PR 做 P、950DT 做 D、SuperPoD 做 C/cache

---

十六、不确定性与验证节点

最后必须说清楚哪些是确定的、哪些是推测的：

下一个验证节点：

1. V4-Pro 在 B300 上的实测 decode goodput 和 TPOT p90
2. 950DT 在 V4-Pro 上的实测 prefill/decode 效率
3. 950PR 的 prefill goodput
4. B300 和 950DT 的实际商用定价
5. V4-Pro 的 SWA KV 策略和实际 cache 开销

在拿到实测数据之前，本文的所有配置应视为容量规划的起点和框架，不是最终答案。但框架是对的——先定义 workload、再算 goodput、再推 P:D——拿到实测数据后只需要替换效率参数，不需要改方法论。