DeepSeek-V4-Flash 双机拓扑选型：TP8x2、TP4x4 与 PP2/TP8
大模型推理拓扑没有“万能最佳”。同样是双机 16 卡，真正要先分清的是两类扩展：一类是服务级副本扩展，例如 TP8x2、TP4x4；另一类是单模型副本的模型并行扩展，例如 PP2/TP8。
TP8x2 和 PP2/TP8 看起来都用了 16 张卡，但含义完全不同。TP8x2 是两个独立 TP=8 的 vLLM 实例，每个请求只落到其中一台 8 卡机器。PP2/TP8 是一个 vLLM engine，TP=8、PP=2，单个请求会跨两台机器完成。
本文基于项目中的 DeepSeek-V4-Flash 双机压测资料整理公开版经验。文中不暴露真实节点、IP、端口和原始结果路径，只保留拓扑含义、指标矩阵和生产判断方法。
一、三种拓扑分别是什么
| 拓扑 | 准确含义 | endpoint 数 | 单请求执行路径 | 主要风险 |
|---|---|---|---|---|
TP8x2 |
2 个独立 vLLM 副本，每个副本 TP=8, PP=1 |
2 | 请求只进入其中一台 8 卡节点 | 需要入口层负载均衡，单请求无法同时用满双机 |
TP4x4 |
4 个独立 vLLM 副本，每个副本 TP=4, PP=1 |
4 | 请求只进入其中 4 张卡 | 模型必须能在 4 卡副本内容纳，长上下文能力可能下降 |
PP2/TP8 |
1 个跨双机 vLLM engine，TP=8, PP=2 |
1 | 请求跨两台机器，按 pipeline stage 执行 | pipeline bubble、跨机通信、单入口队列放大 |
所以 TP8x2 和 PP2/TP8 不是同一个东西。前者是“两个服务副本”，优势是隔离简单、入口可横向扩展；后者是“一个跨机模型副本”，优势是单个模型副本可以使用两台机器的显存和算力，但每个请求会经历跨机 pipeline。
从直觉看，TP4x4 副本更多，似乎适合并发；PP2/TP8 用满两台机器，似乎适合超大模型；TP8x2 则是容易生产化的折中。但最终不能靠直觉，必须用业务 workload 和高并发扫描共同判断。
二、为什么要把 workload 分成两类
项目资料里使用了两类压测口径。
第一类是业务三组：
| case | 含义 |
|---|---|
1000/300/c6 |
输入约 1000 token，输出约 300 token，并发 6 |
9000/600/c2 |
输入约 9000 token，输出约 600 token，并发 2 |
50000/1000/c1 |
输入约 50000 token，输出约 1000 token，并发 1 |
这类 workload 适合看业务体验，重点看 TTFT、TPOT、P95 latency、QPM、TPM。
第二类是高并发短输出扫描，例如：
c1024_r2048_t128
c2048_r4096_t128
c2560_r5120_t128
这里 c2048_r4096_t128 表示并发 2048、总请求 4096、每个请求最大输出 128 token。它更适合找吞吐峰值、过载拐点和 P95 latency 退化。
生产选型时不能只看其中一类。只看业务三组，可能看不到满载能力；只看高并发短输出，又可能误判长上下文体验。
三、DeepSeek-V4-Flash 历史拓扑结论
TP4x4 在 DeepSeek-V4-Flash 上表现非常强，双机高并发短输出峰值达到：
| 拓扑 | 峰值 case | completion tok/s | total tok/s | P95 latency |
|---|---|---|---|---|
TP4x4 |
c2048_r4096_t128 |
11,866.308 | 14,091.241 | 25.192 s |
TP8x2 |
c1536_r3072_t128 |
1,525.866 | 1,811.965 | 129.028 s |
PP2/TP8 |
c2048_r4096_t128 |
1,528.639 | 2,028.048 | 98.160 s |
在这组结果里，TP4x4 明显适合高并发短输出。原因也很清楚：TP=4 已能容纳模型和 65K KV cache，单副本通信域更小，4 个独立副本可以提供更多请求队列。
但后续 H20 + DSFlash 项目中，同口径与 6000D 对齐时，TP8x2 成为了当前服务级推荐基线。这里的 TP8x2 指两个独立 TP8 endpoint，而不是一个 TP=16 或 PP=2 的跨机 engine。原因是新一轮同字段测试显示：
| source | topology | case | P95 latency | TTFT | TPOT | QPM | total tok/s |
|---|---|---|---|---|---|---|---|
| H20 | TP8x2 |
1000/300/c6 |
7.302 s | 2,519.993 ms | 15.987 ms | 49.287 | 1,076.090 |
| H20 | TP4x4 |
1000/300/c6 |
24.273 s | 18,860.387 ms | 18.097 ms | 14.830 | 323.786 |
| H20 | TP8x2 |
9000/600/c2 |
8.786 s | 224.857 ms | 14.291 ms | 13.657 | 2,182.083 |
| H20 | TP4x4 |
9000/600/c2 |
10.765 s | 967.701 ms | 16.340 ms | 11.145 | 1,780.738 |
| H20 | TP8x2 |
50000/1000/c1 |
14.774 s | 353.421 ms | 14.435 ms | 4.061 | 3,442.439 |
| H20 | TP4x4 |
50000/1000/c1 |
27.114 s | 11,128.173 ms | 16.002 ms | 2.213 | 1,875.849 |
这说明同一个模型，在不同镜像、内核、调度参数、入口策略、压测口径下，最佳拓扑会变化。
四、当前 H20 TP8x2 为什么成为推荐基线
当前 H20 与 6000D 的同拓扑对齐结果显示，H20 TP8x2 在三组 workload 上均优于 6000D 参考口径。它适合作为生产基线的原因，不是“单请求用了 16 卡”，而是“每台机器一个独立 TP8 副本，入口层可以稳定分流”：
| case | H20 P95 latency | H20 QPM | H20 total tok/s | 6000D QPM | 6000D total tok/s |
|---|---|---|---|---|---|
1000/300/c6 |
7.302 s | 49.287 | 1,076.090 | 19.276 | 417.642 |
9000/600/c2 |
8.786 s | 13.657 | 2,182.083 | 10.314 | 1,650.300 |
50000/1000/c1 |
14.774 s | 4.061 | 3,442.439 | 2.044 | 1,737.605 |
这组结果说明，当前服务的瓶颈不一定在 H20、RoCE/NCCL 或显存硬件能力本身。对 TP8x2 来说，每个请求主要在单机 8 卡副本内完成，跨机 RoCE 更偏向服务编排和入口侧，而不是单请求每层必经路径。更值得关注的是 vLLM 调度、HTTP 连接复用和入口分流。
五、短请求为什么要单独优化入口
TP8x2 的优化记录里，一个很重要的发现是：短输入高并发时，HTTP 连接复用和 API worker 分配不均可能导致 TTFT 排队。对 1000/300/c6 做不同策略后结果如下：
| variant | P95 latency | TTFT p50 | TPOT p50 | QPM | total tok/s |
|---|---|---|---|---|---|
| baseline | 7.302 s | 2,519.993 ms | 15.987 ms | 49.287 | 1,076.090 |
| batched16384 | 5.261 s | 500.742 ms | 15.914 ms | 68.397 | 1,493.336 |
| force-close | 4.836 s | 246.449 ms | 15.347 ms | 74.429 | 1,625.034 |
| HAProxy short entry | 5.001 s | 552.773 ms | 14.870 ms | 71.968 | 1,571.308 |
但是 force-close 和更大的 batched tokens 并不适合所有请求。中长上下文可能退化。因此更合理的生产策略不是全局改参数，而是分入口：
| 入口 | 适合流量 | 策略 |
|---|---|---|
| 短请求入口 | 短输入、高并发、低 TTFT | 多连接分发，减少队列集中 |
| 长上下文入口 | 9k/50k 这类中长输入 | 保持默认连接策略，避免退化 |
| 原生调试入口 | 排障、回归、直接访问 vLLM | 保留最少中间层 |
这也是拓扑选型之外非常重要的一点：很多“模型慢”其实是入口层和客户端连接策略导致的排队。
六、PP2/TP8 什么时候有价值
PP2/TP8 不适合作为当前默认生产吞吐拓扑，但并非没有价值。它和 TP8x2 的核心差别是：PP2/TP8 是一个跨机模型副本，因此适合验证“单请求跨双机”的能力，而不是替代两个独立 endpoint 做高并发吞吐。
它适合三类场景：
- 复现跨机 pipeline 性能问题。
- 做超长输入、低并发、单请求专项对照。
- 验证跨机模型内部执行路径的稳定性。
50000/1000/c1 这类单请求超长输入下，PP2/TP8 的 TPM 曾比 TP4x4 高约 2.99%。但这不能代表整体吞吐最佳。只要进入中短输入或高并发，pipeline bubble、跨机通信和单 endpoint 队列都会放大延迟。
如果模型单机 8 卡能放下，生产上通常优先考虑 TP8x2 这类副本并行；如果模型单机放不下，或需要验证单请求使用双机显存，才更自然地进入 PP2/TP8 或更复杂的 TP/PP 组合。
七、选型方法论
我建议把推理拓扑选择做成四步：
第一步，确定业务流量形态。短问答、代码助手、RAG 长上下文、批量摘要、多轮 Agent，它们需要看的指标不一样。
第二步，定义统一 workload。至少包含短输入并发、中长输入、超长输入、吞吐峰值扫描四类。
第三步，固定变量做 A/B。一次只改一个变量：拓扑、batch token、连接策略、P2P/RoCE、CUDA graph、MTP、max-num-seqs。
第四步，按场景给入口，而不是追求一个全局最优参数。短请求和长上下文混在同一个入口，很容易互相拖累。
八、参考资料
- vLLM Parallelism and Scaling：https://docs.vllm.ai/en/stable/serving/parallelism_scaling/
- vLLM Distributed Inference and Serving：https://docs.vllm.ai/en/v0.6.0/serving/distributed_serving.html
九、总结
DeepSeek-V4-Flash 的双机拓扑选型不能用一句“TP4x4 更快”或“TP8x2 更稳”概括。更准确的说法是：TP8x2、TP4x4 是服务副本扩展，PP2/TP8 是单模型副本跨机扩展，二者解决的问题不同。
历史探索中，TP4x4 在高并发短输出峰值上非常强；但当前 H20 + DSFlash 同口径复测里，TP8x2 是服务级推荐基线，并且通过短/长入口分流进一步改善了业务体验。
真正可落地的结论是：拓扑选择要绑定 workload、指标口径和入口策略。生产默认可以选当前综合最稳的 TP8x2，但保留 TP4x4 和 PP2/TP8 作为专项对照，才能在业务变化时快速复测和切换。
