單R9700 + VLLM(GGZ14/vllm-mxfp4) + unsloth/Qwen3.8-27B-NVFP4 測試
-
模型优化团队也是自杀群体。
越优化的越好。卡越涨价。。。。。。。。
无解 -
-
-
https://github.com/Eliovp-BV/paiton-vllm-plugin/tree/main
這方案讓QWEN3.8 27B NVFP4去安裝，只修改一次就啟動成功了
就不貼一大篇了，講差異就行了。
vllm版本 ： 0.27.1 => 0.29.0
ROCM版本 ： 7.14.0 => 10
PREFILL ： 少不到100，也許是誤差
DECODE ： +5~10%左右@paul-hou
我们用同一张 R9700 测试了不同功耗和上下文配置，数据如下，供参考。测试环境
项目 值 显卡 AMD Radeon AI PRO R9700 32 GB (RDNA4 gfx1201) TP 1 方案 Eliovp-BV/paiton-vllm-plugin vLLM 0.29.0 + ROCm 10 官方镜像 v1.1.0 (sha256:28af1731cfd8) 模型 Qwen3.8-27B MXFP4 KV cache 8 GiB fp8 chunk size 4096 spec decode DFlash2, num_speculative_tokens=7 测试工具 BetterBench 0.6.0 采样 temp 0.7 / top_p 0.95，每类别 n=20，8 类别共 160 A. 功耗对比 — Paiton vLLM 0.29 ROCm10, 65K preset
Prefill（tok/s）
深度 (tok) 260 W 300 W ~1.5K 3,160 3,498 ~5.9K 3,149 3,433 ~11.8K 3,219 3,471 ~23.5K 3,069 3,292 ~47.0K 2,859 3,054 Decode（weighted t/s，8 类别合并）
功耗 Weighted decode 260 W 138.4 300 W 141.5 两组为同一张卡、同一镜像、同一天、同一组测试参数，只修改
power1_cap（260 W
300 W）。B. 三种上下文配置对比 — Paiton v1.1.0 官方镜像，全部 260 W
本节三个配置使用同一个官方 v1.1.0 镜像。其中 64K×8 为官方 preset；100K×2 为官方 entrypoint override（
--max-model-len 100000 --max-num-seqs 2），非官方 preset，未经官方完整 benchmark 认证。TG（weighted decode t/s）
配置 上下文 max_num_seqs TG wt 64K×8 65,536 8 103.89 200K×1 200,000 1 103.91 100K×2 100,000 2 103.84 Prefill（tok/s）
深度 (tok) 64K×8 200K×1 100K×2 ~1.5K 3,228 3,234 3,229 ~5.9K 3,130 3,143 3,153 ~11.8K 3,048 3,066 3,072 ~23.5K 2,862 2,876 2,883 ~47.0K 2,522 2,538 2,540 并发（aggregate t/s ／ TTFT p50 ms，48 请求／档位）
配置 c1 c2 c4 c8 64K×8 87.2 ／ 109 ms 151.1 ／ 162 ms 226.2 ／ 179 ms 309.6 ／ 201 ms 100K×2 87.1 ／ 109 ms 147.7 ／ 162 ms 151.3 ／ 2,771 ms 148.2 ／ 8,588 ms 200K×1 87.1 ／ 109 ms 87.0 ／ 2,227 ms 85.8 ／ 7,835 ms 87.4 ／ 15,396 ms
-
@paul-hou
我们用同一张 R9700 测试了不同功耗和上下文配置，数据如下，供参考。测试环境
项目 值 显卡 AMD Radeon AI PRO R9700 32 GB (RDNA4 gfx1201) TP 1 方案 Eliovp-BV/paiton-vllm-plugin vLLM 0.29.0 + ROCm 10 官方镜像 v1.1.0 (sha256:28af1731cfd8) 模型 Qwen3.8-27B MXFP4 KV cache 8 GiB fp8 chunk size 4096 spec decode DFlash2, num_speculative_tokens=7 测试工具 BetterBench 0.6.0 采样 temp 0.7 / top_p 0.95，每类别 n=20，8 类别共 160 A. 功耗对比 — Paiton vLLM 0.29 ROCm10, 65K preset
Prefill（tok/s）
深度 (tok) 260 W 300 W ~1.5K 3,160 3,498 ~5.9K 3,149 3,433 ~11.8K 3,219 3,471 ~23.5K 3,069 3,292 ~47.0K 2,859 3,054 Decode（weighted t/s，8 类别合并）
功耗 Weighted decode 260 W 138.4 300 W 141.5 两组为同一张卡、同一镜像、同一天、同一组测试参数，只修改
power1_cap（260 W 300 W）。B. 三种上下文配置对比 — Paiton v1.1.0 官方镜像，全部 260 W
本节三个配置使用同一个官方 v1.1.0 镜像。其中 64K×8 为官方 preset；100K×2 为官方 entrypoint override（
--max-model-len 100000 --max-num-seqs 2），非官方 preset，未经官方完整 benchmark 认证。TG（weighted decode t/s）
配置 上下文 max_num_seqs TG wt 64K×8 65,536 8 103.89 200K×1 200,000 1 103.91 100K×2 100,000 2 103.84 Prefill（tok/s）
深度 (tok) 64K×8 200K×1 100K×2 ~1.5K 3,228 3,234 3,229 ~5.9K 3,130 3,143 3,153 ~11.8K 3,048 3,066 3,072 ~23.5K 2,862 2,876 2,883 ~47.0K 2,522 2,538 2,540 并发（aggregate t/s ／ TTFT p50 ms，48 请求／档位）
配置 c1 c2 c4 c8 64K×8 87.2 ／ 109 ms 151.1 ／ 162 ms 226.2 ／ 179 ms 309.6 ／ 201 ms 100K×2 87.1 ／ 109 ms 147.7 ／ 162 ms 151.3 ／ 2,771 ms 148.2 ／ 8,588 ms 200K×1 87.1 ／ 109 ms 87.0 ／ 2,227 ms 85.8 ／ 7,835 ms 87.4 ／ 15,396 ms
-
我是降到210W，降速約30%，PREFILL慢了近22%，真是一分電源一分速度。
DEOCDE差異就小很多了。
所以還是降功率比較好。 -
我是降到210W，降速約30%，PREFILL慢了近22%，真是一分電源一分速度。
DEOCDE差異就小很多了。
所以還是降功率比較好。应该不至于吧，我这边反复测试的结果大概是210W会有10%的性能影响。
-
測試傳說中的Generate an SVG of a pelican riding a bicycle.
方案：https://github.com/Eliovp-BV/paiton-vllm-plugin/tree/main
目前思考強度的設定是無效的，所以思考強度是被VLLM強設在MEDIUM。
有种智能体在网上搜答案的感觉
-
，
T terry 固定了此主题
-
@张光璞 我也是R9700用家，上載給大家參考一下
-
-
我手上用着3090x2
看到这个帖我有冲动买 r9700 -
@applejuice
CUDA才是王道，R9700是窮人家的玩具。 -
-
-
，系统 取消固定了此主题
-
-
@张光璞 我也是R9700用家，上載給大家參考一下
-
-
-
-
@alan.lgv60 你们都是怎么做到的？
@Magic629 我的配置就是照抄 paul hou 的作业，自己没怎么调过。
硬件：
- 显卡：单张 R9700 32G（ReBAR 开，PCIe 4.0 x8）
- CPU：Intel Core i9-13900HK ES（14C/20T）
- 内存：32G DDR4
- 功耗上限：260W
软件（全部照 paul hou 帖里的 paiton 方案来）：
- 镜像：
ghcr.io/eliovp/paiton-vllm-plugin - 模型：
amd/Qwen3.8-27B-Quark-AWQ-MXFP4 - 投机解码 draft：
tcclaviger/Qwen3.8-27B-DFlash2-FP8（dflash，7 tokens） - 上下文 200K，KV cache fp8（8G），prefix caching 开
实际跑起来：
日常跑 agent 的时候，DSH WebUI 状态栏大概 115 tok/s，cache 命中 91%。
要说明的是，这个 115 不是裸 benchmark 的 decode 速度 —— 91% 的输入命中缓存了，所以平均偏高。真要对比裸测数字，还是看 paul hou 帖里的 PP/TG 数据更准。
归根到底就是那套作业一字不改抄下来，能跑通就行。
！