这次测试的前提是：

X99 平台上的两张 Radeon AI PRO R9700 已经先打通 P2P，再进行 SGLang TP2 测试。

基于目前已经完成的测试，可以确认：

• X99 + 双 R9700 在 P2P 打通后可以实际运行 SGLang TP2。
• 在后续正式的对比中，Plain / MTP / DFlash2 使用的是同一个 Qwen/Qwen3.8-27B-FP8 target，因此这组 8K / 32K / 64K 数据可以用于比较三种 decode 路径。
• DFlash2 相比普通 MTP：
  • 8K：42.29 → 51.44 tok/s，约 1.22×
  • 32K：45.32 → 55.39 tok/s，约 1.22×
  • 64K：28.60 → 59.81 tok/s，约 2.09×
• 后续单独对 FP8 + DFlash2 做完整长上下文 characterization 时，192K decode 中位数为 33.75 tok/s。
• 当前已经完成 224,000 input tokens 的单次容量验证，HTTP 200、输出正确，两张 GPU 都有持续计算活动。
• 当前这套 DFlash2 TP2 runtime 中，/v1/models 可报告 max_model_len=262144，但 R8N 日志中实际 request admission ceiling 为 227701 tokens。因此本文只声称 224K 已验证，不声称 256K 已验证。
• 同样的 Qwen/Qwen3.8-27B-FP8 + DFlash2 在单张 R9700 32GB 上无法完成初始化，OOM 发生在 DFlash draft worker 权重构造阶段，因此目前没有严格 apples-to-apples 的 TP1 / TP2 吞吐 scaling 数据。

另外需要说明：

我此前也测试过 shawnw3i/Qwen3.8-27B-AWQ-MTP 路线，并尝试过在 AWQ target 上挂 DFlash2。那属于更早阶段的探索，不是本文 P5B-R 里 51.44 / 55.39 / 59.81 这组 DFlash2 数据。

本文会把两条路线分开写，避免混淆。

一、测试平台与 P2P 前提

硬件环境

CPU:
Intel Xeon E5-2697A v4

RAM:
128GB DDR4

主板:
华南金牌X99-TF GAMING V6.0

GPU:
2 × AMD Radeon AI PRO R9700 32GB

本文后续所有双卡 TP2 数据，均是在：

X99
+
双 R9700
+
P2P 已打通
+
SGLang TP2

这一前提下取得。

此前已经单独完成过双卡 P2P / HIP IPC 验证，参加帖子 https://lcz.me/topic/1925/52 X99 + 双 AMD Radeon AI PRO R9700 跑通跨 Root Port P2P：从内核、RCCL 到 SGLang Qwen3.8 实战

本文不重复讨论 P2P 打通方法，只讨论打通之后的 SGLang TP2 与 DFlash2 表现。

需要区分：

• P2P 是否打通：属于双卡通信前置条件；
• 两张卡是否真的参与同一次 TP2 推理：后续通过运行时状态及 AMD-SMI 按 PCI BDF 的活动采样进行确认。

二、权重口径：AWQ 早期路线与后续 FP8 路线要分开

这一点是整篇帖子最需要避免混淆的地方。

1. 早期 AWQ-MTP 路线

上一个帖子曾经使用：

shawnw3i/Qwen3.8-27B-AWQ-MTP

进行 MTP / speculative 相关探索。

也尝试过：

shawnw3i/Qwen3.8-27B-AWQ-MTP
+
DFlash2 draft

但这一阶段属于更早的 AWQ 路线测试。

本文后面引用的 51.44 / 55.39 / 59.81 tok/s，不是这条 AWQ + DFlash2 路线的数据。

因此：

shawnw3i/Qwen3.8-27B-AWQ-MTP

只作为早期历史路线说明，不和后面的FP8 数据混在一起。

2. MTP / DFlash2 正式对比

后续 DFlash2 测试正式对比统一使用：

Target:
Qwen/Qwen3.8-27B-FP8

三种运行方式分别是：

Plain

Qwen/Qwen3.8-27B-FP8
无 speculative decoding

MTP

Qwen/Qwen3.8-27B-FP8
+
MTP

DFlash2

Target:
Qwen/Qwen3.8-27B-FP8

Draft:
z-lab/Qwen3.8-27B-DFlash2

因此本次测试的：

Plain
vs
MTP
vs
DFlash2

是在同一个 FP8 target 下完成的对比。

这组数据才是本文用于判断 DFlash2 相对普通 MTP 效果的主要依据。

3. 后续 DFlash2 characterization

后续 8K / 32K / 64K / 128K / 192K 的完整 characterization，以及 224K capacity probe，继续统一使用：

Target:
Qwen/Qwen3.8-27B-FP8

Draft:
z-lab/Qwen3.8-27B-DFlash2

因此后半部分的 DFlash2 数据也是同一条 FP8 + DFlash2 路线。

三、后续 FP8 + DFlash2 测试的启动条件

后续独立 DFlash2 characterization 使用的核心运行条件如下。

SGLang:
0.5.18 + RDNA4 patch

Image:
sglang-rdna4-production:v0.5.18-r1

Image ID:
sha256:bea0f21f6e2ebcac99274b3f14f271281bf1249111840d9798542f3383191b49

Patch SHA256:
2f78d14d12787d029453671979229a4a26a6c2b3ccd732b422754a2c82f99cce

Frozen launch SHA256:
15f266c4934d89cf6463422b768446341edf3292ed6bbec0b36575e691223a47

Target:
Qwen/Qwen3.8-27B-FP8

Draft:
z-lab/Qwen3.8-27B-DFlash2

Tensor Parallel:
2

GPU count:
2

GPU BDF:
0000:05:00.0
0000:08:00.0

KV cache dtype:
FP8 e4m3

DFlash2:
ON

BN:
32

SSM precision:
FP32

ReplaySSM:
OFF

Default thinking:
enable_thinking=false

Context 配置

完整 8K–192K characterization 阶段使用的是当时冻结的常规测试配置。

后续为了验证 200K 以上容量，只对测试用 TP2 runtime 的 context cap 做了临时调整，其它核心模型和 DFlash2 条件保持不变。

/v1/models max_model_len:
262144

但 229000-token 请求被 SGLang 拒绝，日志给出的实际 request admission ceiling 为：

227701 tokens

随后使用：

input tokens:
224000

max output tokens:
128

完成单次成功验证。

测试结束后，临时 context 调整已撤销，launcher 已恢复原状态。

四、Plain / MTP / DFlash2 同一 FP8 Target 对比

这一组是本文最重要的性能对比。

三种模式的 target 都是：

Qwen/Qwen3.8-27B-FP8

同时：

TP:
2

KV:
FP8 e4m3

DFlash2 模式额外挂载：

z-lab/Qwen3.8-27B-DFlash2

实测 decode：

Plain → MTP

MTP 本身已经带来明显提升。

例如 32K：

Plain:
19.21 tok/s

MTP:
45.32 tok/s

MTP → DFlash2

DFlash2 在同一个 FP8 target 下继续提高 decode。

8K：

42.29 → 51.44 tok/s
≈ 1.22×

32K：

45.32 → 55.39 tok/s
≈ 1.22×

64K：

28.60 → 59.81 tok/s
≈ 2.09×

因此在这组同 target 测试里，可以直接说：

DFlash2 相比普通 MTP 有明确提升。

但也需要注意：

这三个倍数是对应这组具体 workload 的实测结果，不应直接外推为所有 prompt、所有输出类型下都固定存在相同倍数。

Speculative decoding 的实际速度仍然会受到：

accept rate
accept length
verify latency

等因素影响。

五、FP8 + DFlash2 完整长上下文 characterization

后续重新固定了一套 benchmark workload，对 FP8 + DFlash2 单独进行完整长上下文测试。

当前结果：

从这组数据本身看：

8K      40.78 tok/s
32K     40.00 tok/s
64K     35.48 tok/s
128K    34.38 tok/s
192K    33.75 tok/s

8K 到 192K 的 decode 下降约 17%。

Prefill：

8K      1747.70 tok/s
32K     1499.38 tok/s
64K     1248.14 tok/s
128K     929.67 tok/s
192K     739.79 tok/s

需要特别注意：

这组 40.78 / 40.00 / 35.48 / 34.38 / 33.75 不能直接和之前的 51.44 / 55.39 / 59.81 做“版本性能回归”判断。

因为两轮：

• prompt 不同；
• output workload 不同；
• cache 状态不同；
• benchmark harness 不同；
• streaming / timing 方法不同。

所以两组数据用途不同：

• 前面一组：Plain / MTP / DFlash2 同 target 对比；
• 后续 characterization：观察 FP8 + DFlash2 自己的长上下文性能曲线。

六、224K 单次容量验证

在完成 192K benchmark 后，又继续验证更长输入。

R8N-1 最终只发送一次长请求：

Actual input tokens:
224000

Max output tokens:
128

服务器报告：

prompt tokens:
224000

HTTP:
200

output:
READY

TTFT:
330.757s

E2E:
330.872s

GPU 采样：

GPU 05:
319 samples
GFX average = 100%
GFX peak = 100%

GPU 08:
319 samples
GFX average = 100%
GFX peak = 100%

峰值显存：

GPU 05:
30132 MB

GPU 08:
29849 MB

请求期间未发现：

OOM
GPU reset
GPU hang
HIP fatal
page fault

因此可以直接确认：

X99 双 R9700 P2P + SGLang TP2 + Qwen/Qwen3.8-27B-FP8 + DFlash2 已经实际完成 224,000-token 输入。

这里的 224K 是 server-reported prompt tokens，不是文本长度估算值。

七、为什么本文不写“256K 已验证”

R8N 中：

/v1/models:
max_model_len = 262144

但：

229000-token input

被 SGLang request layer 拒绝。

日志给出的实际 request ceiling：

227701 tokens

所以目前有三个不同数字：

模型报告 max_model_len:
262144

当前 DFlash2 TP2 runtime 已知 request ceiling:
227701

最高实际成功验证 input:
224000

它们不能混为一谈。

本轮测试只证明：

当前 runtime 能接收并完成 224K；229K 超过了当时 runtime 给出的 admission limit。

至于：

262144 → 227701

中间的差额究竟有多少来自：

DFlash2 draft
draft KV
target KV
token pool
其它 runtime reservation

本文并没有逐项隔离，所以不把它写成已证明的单一因果关系。

因此本文不会声称：

双 R9700 硬件最多只能 227.7K

也不会声称：

DFlash2 固定只能到 227.7K

准确结论只有：

当前这套冻结 DFlash2 TP2 runtime 实测成功到 224K，R8N 日志给出的 admission ceiling 为 227701 tokens。

八、为什么没有 TP1 性能对比

原计划还想做：

TP1 DFlash2
vs
TP2 DFlash2

计算第二张 R9700 带来的纯 throughput scaling。

但是严格相同的 FP8 + DFlash2 stack 在单卡上无法完成启动。

TP1 使用：

GPU:
1 × R9700 32GB

TP:
1

Target:
Qwen/Qwen3.8-27B-FP8

DFlash2:
ON

分别尝试：

32K
64K
128K

三档都在启动阶段 OOM。

32K 的典型状态：

GPU total:
31.86 GiB

allocated:
31.41 GiB

free:
112 MiB

next allocation:
170 MiB

result:
OOM

64K、128K 的失败点和显存状态基本一致。

后续初始化顺序审计确认：

OOM 发生在 DFlash draft worker 权重构造阶段。

此时：

KV pool
attention backend
CUDA/HIP graph

都还没有初始化。

因此可以确认：

32K / 64K / 128K 全部失败并不是上下文长度本身导致的，而是当前 FP8 target + DFlash2 stack 在单张 32GB R9700 上无法完成初始化。

所以目前没有合法的：

TP2 / TP1 decode speedup

可以计算。

如果为了获得 TP1 数字而改：

模型精度
权重量化
offload
CPU spill

那就已经不是同一个测试对象。

九、这组测试实际说明了什么

1. X99 打通 P2P 后，双 R9700 TP2 可以实际工作

本文不是只验证：

系统识别两张 GPU

而是在真实长上下文请求期间观察两张卡的运行活动。

224K 请求：

05:00.0:
319 个 1 秒样本
GFX 平均 100%

08:00.0:
319 个 1 秒样本
GFX 平均 100%

因此至少对于这套机器，可以确认：

X99 老平台在 P2P 打通以后，可以承载实际双 R9700 TP2 推理。

2. DFlash2 对同一个 FP8 target 的提升明确存在

P5B-R：

Target:
Qwen/Qwen3.8-27B-FP8

实测：

8K:
MTP 42.29
DFlash2 51.44
≈1.22×

32K:
MTP 45.32
DFlash2 55.39
≈1.22×

64K:
MTP 28.60
DFlash2 59.81
≈2.09×

这一组可以用于直接比较：

同一个 FP8 target 下，普通 MTP 与 DFlash2 的实际表现。

3. FP8 + DFlash2 的长上下文能力已经实际验证到 224K

正式 characterization：

192K decode:
33.75 tok/s

单次 capacity probe：

224000 input tokens:
PASS

因此这里不只是模型配置上“允许长上下文”，而是真实请求已经跑过。

4. 双卡首先解决的是容量问题

单卡：

Qwen/Qwen3.8-27B-FP8 + DFlash2
→ draft worker 初始化 OOM

双卡：

X99 + P2P + TP2
→ 正常启动
→ 192K benchmark 完成
→ 224K request 完成

因此这套 stack 上第二张 R9700 的第一层价值是：

让完整 FP8 + DFlash2 从单卡无法初始化，变成双卡可以正常运行长上下文。

至于纯粹 TP1 → TP2 的 throughput scaling，因为 TP1 同配置没有可运行基线，目前不能给出严谨数字。