Nemotron EP2 vs TP2：两台 DGX Spark 的实际对比
结论先行#
在同一份 Nemotron 3 Super 120B A12B NVFP4、同一镜像、同一保守 profile 下，我这轮测试里 TP2 明显好于 EP2。
我这里做的是 clean-room 对比：清掉两台机器上所有其他 vLLM 实例后，分别跑 EP2 和 TP2，再额外用 max_tokens=32 做一次长输出探针。
测试条件#
- 镜像：
vllm/vllm-openai:gemma4-cu130 - 模型目录：
/home/admin/models/NVIDIA-Nemotron-3-Super-120B-A12B-NVFP4-aria2 - 公共参数：
gpu_memory_utilization=0.75、max_model_len=32768、kv_cache_dtype=fp8、quantization=fp4、mamba-ssm-cache-dtype=float32 - EP2：
TP=1 + DP=2 + --enable-expert-parallel - TP2：
tensor-parallel-size=2
结果对比#
| 拓扑 | 短输出 benchmark | 成功数 | 成功 case 平均 tok/s | 最慢 case 延迟 | 32-token 探针 | 结论 |
|---|---|---|---|---|---|---|
| EP2 | TP=1 + DP=2 + --enable-expert-parallel |
2/4 | 2.44 | 301.64 s | 第 3 个 case 即把服务打死，后续探针 connection refused |
可启动，但不稳定 |
| TP2 | tensor-parallel-size=2 |
4/4 | 4.68 | 23.48 s | HTTP 200，32 completion tokens 在 2.91 s 内返回 |
当前环境下更实用 |
为什么这轮测试里 TP2 表现更好#
从日志看，EP2 的主要问题不是“模型装不下”，而是 decode 阶段的跨 rank 协调失稳。失败时，核心报错一直是：
No available shared memory broadcast block found in 60 secondsTimeoutError: RPC call to sample_tokens timed out
这说明 EP2 在当前构型下，卡住的是 sample_tokens 这条多进程/多 rank 通路，而不是普通的启动或健康检查。
我认为可能有三层原因：
-
EP2 的通信路径更重
EP2 同时带着 DP 协调和 expert parallel 通信，短请求下也要付额外同步成本；对这种 2 节点、短输出 workload 来说，通信开销超过了收益。 -
当前这版 vLLM build 看起来对 EP2 更敏感
这版日志里，EP2 一旦进入较长 decode，就会在shm_broadcast等待里卡住，最后把sample_tokensRPC 拖超时。TP2 没走这条路径，所以避开了这类失稳点。 -
TP2 更贴近这台机器上当前更实际的选择
对 Nemotron 这种 NVFP4 / MoE / reasoning 较重的模型，TP2 虽然不是理论上最“优雅”的分布式方案，但至少在这组测试里，它更简单、更直接，也更容易得到稳定吞吐。
最终判断#
如果目标是“当前这套软件栈下，先把 Nemotron 跑稳”，我这次的结论相对明确：
在当前这组环境里，我会先选 TP2。
如果目标是“继续把 EP2 调到稳定”，那它仍然值得留着做后续排障，但就这次实测来说，EP2 还没达到我会当成默认方案的稳定性。