<![CDATA[X99＋7900 XTX+7700 XT 跑 vLLM实测]]>已改成精简版帖子，只保留 vLLM 操作和实测。注释 1

X99＋7900 XTX/7700 XT 跑 vLLM：128K、缓存及 MTP 实测

配置：X99-AD4、E5-2686 v4、64GB、7900 XTX 24GB＋7700 XT 12GB。

模型：Vishva007/Qwen3.8-27B-W4A16-AutoRound-GPTQ，vLLM 0.28.0、ROCm 7.2.3 wheel。

1. 做了哪些修改

操作 实验结果
开启 Above 4G Decoding、ReBAR 双卡进入 Ubuntu，大 BAR 生效
给主机桥 8086:6f00 加 P2PDMA 白名单，编译实验内核 缺 gawk 失败一次，补齐后完成，累计编译约54分钟；HIP peer 双向由0变1，复制和IPC校验通过
换用 AMD RCCL build 38，移除 LD_PRELOAD 解决原库双卡 AllReduce 段错误，集合通信通过
修正 GPTQ 零点传参、按显卡读取CU数量、开启decode graph，并加入MTP3 TP2下1K输入TG从5.87提高到47.26
移植 JartX 的 RDNA3 prefill 调度参数 16K PP提高21.4%，32K提高42.2%
改为不等量分层，让XTX承担更多层 长上下文PP提高，跑通128K

注意：最终 RCCL 仍走 SHM，不能宣称高速P2P已打通；也未证明实验内核是最终方案的必要条件。

2. PP/TG 实测

JartX prefill 调整前后，保持TP2＋MTP3：

输入 调整前PP 调整后PP 调整后TG
16K 561.8 682.2 29.23
32K 452.9 644.0 17.89

之后改成 TP1＋PP2、7700 XT前20层／XTX后44层，无MTP、无缓存。单请求生成256 token：

实际输入token PP（tok/s） TG（tok/s）
4,096 1,016.56 27.55
16,384 995.61 24.94
32,768 933.16 24.78
130,816 670.88 18.06

最后一项输入＋输出共131,072，整次请求209.1秒。分层后短上下文TG不如早期TP2＋MTP3，但PP更高，32K生成也更快。

3. 最终使用配置

接入视觉后重新平衡显存，改成 18/46分层、128K、前缀缓存、最多4并发。batch预算1024，显存预算0.948，无MTP。

测试 结果
约3K输入／256输出 TG 28.74／28.93 tok/s
7,552 token文本首次／重复请求 首token 7.451秒／0.788秒
图片首次／重复请求 首token 2.146秒／0.591秒，均识别出数码管Ab
保留视觉编码器，131,008输入＋64输出 满128K请求186.1秒完成

并发调优阶段，约7.5K输入／160输出、缓存已热：

并发 每路TG 首token延迟
2 18.83–20.46 0.828–1.630秒
4 15.02–18.59 0.928–3.092秒

这组并发数据使用0.94显存预算。前面的完整长上下文表属于纯文本20/44方案，不是最终视觉配置的成绩。四并发也不代表能同时容纳四个独立满128K请求。

4. 为什么最终没留MTP

适配PP＋MTP后，约3K输入、256输出：

配置 两次TG（tok/s）
无MTP 28.62／28.80
MTP1 14.88／15.06
MTP2 16.59／16.50
MTP3 18.55／18.83

MTP实验为8K、无缓存，基线为128K＋缓存，是部署方案对比而非严格单变量实验。虽然成功运行，但TG下降，因此撤回。

DFlash2也试过：1K输入TG从30.01到32.58，但受显存限制，完成测试的上下文上限只有2304；runner与缓存配置也不同，不能视为严格加速对照，最终放弃。

目前保留无MTP的128K＋视觉＋缓存方案，DSH和公网接口均已接通。单流约3K上下文TG为29 tok/s，多会话主要依靠前缀缓存减少重复处理。

以上均为短期实测：128K验证的是容量，不是长期稳定性或长上下文语义能力。

]]>https://lcz.me/topic/1498RSS for NodeWed, 09 Sep 2026 22:53:36 GMTFri, 04 Sep 2026 03:31:14 GMT60