<![CDATA[單R9700 + VLLM(GGZ14/vllm-mxfp4) + unsloth/Qwen3.8-27B-NVFP4 測試]]>vLLM Radiance DECODE / PREFILL 性能測試報告

測試時間: 2026-09-19 23:40 CST
測試目標: 192.168.1.241:8080
模型: unsloth/Qwen3.8-27B-NVFP4
硬體: AMD Radeon AI PRO R9700 (32GB VRAM, RDNA4 gfx1201)

1. 模型配置

參數 值
模型 Qwen3.8-27B-MXFP4 (不想重設就都用一樣的)
最大模型長度 225,000 tokens (NVFP4最大值就這麼多)
KV Cache 資料類型 FP8
KV Cache 大小 8.6 GB
GPU 記憶體使用率 0.98
張量並行 1
最大並行序列 1
最大批次 tokens 2,560
注意力後端 R4D
投機解碼 DFlash2 (Qwen3.8-27B-DFlash2-FP8)
投機 tokens 數量 7
投機取樣方法 Greedy
投機注意力後端 TRITON_ATTN
禁用填充草稿批次 true
前綴快取 已啟用
非同步排程 已禁用
溫度 / Top-P / Top-K 0.7 / 0.95 / 20 (溫度我最終都還是會設成1.0)
語言模型 only 是
啟用提示 tokens 詳細資訊 是

完整啟動命令

/opt/vllm/bin/python3 /opt/vllm/bin/vllm serve /models/paiton-qwen38/target \
  --served-model-name Qwen3.8 Qwen3.6 Qwen3.8-MXFP4 \
  --host 0.0.0.0 --port 8080 \
  --kv-cache-dtype fp8 \
  --tensor-parallel-size 1 \
  --gpu-memory-utilization 0.98 \
  --kv-cache-memory 8600000000 \
  --max-model-len 225000 \
  --max-num-seqs 1 \
  --max-num-batched-tokens 2560 \
  --attention-backend R4D \
  --speculative-config {"method":"dflash","model":"/models/qwen38-27b-R9700/models/tcclaviger/Qwen3.8-27B-DFlash2-FP8","num_speculative_tokens":7,"attention_backend":"TRITON_ATTN","disable_padded_drafter_batch":true,"draft_sample_method":"greedy"} \
  --no-async-scheduling \
  --mamba-cache-dtype bfloat16 \
  --mamba-ssm-cache-dtype float16 \
  --compilation-config {"cudagraph_capture_sizes":[1,2,4,8],"pass_config":{"fuse_norm_quant":true,"fuse_act_quant":true}} \
  --enable-prefix-caching \
  --mamba-cache-mode align \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder \
  --reasoning-parser qwen3 \
  --override-generation-config {"temperature":0.7,"top_p":0.95,"top_k":20} \
  --chat-template /patches/qwen-fixed-v22.5.jinja \
  --served-model-name qwen3.8-27b-mxfp4 \
  --language-model-only \
  --enable-prompt-tokens-details \
  --enable-force-include-usage

2. 測試方法論

避免緩存的策略

  1. 隨機 Prompt 內容: 每個測試使用完全不同的隨機字串作為 prompt，避免前綴快取（prefix caching）命中
  2. 丟棄預熱請求: 每個測試回合前先發送一次丟棄的預熱請求，確保 GPU 處於穩定狀態
  3. 隨機 Token 長度: 每個字詞長度為 3-12 個字元（英數混合），避免固定模式

測試分類

  • PREFILL 測試: 不同 prompt 長度（256-4096 tokens 目標），只生成 1 token → 測量純 prefill 吞吐
  • DECODE 測試: 極短 prompt（~20 tokens），不同輸出長度（32-512 tokens）→ 測量純 decode 吞吐
  • 混合場景測試: 不同 prompt + 輸出長度組合 → 模擬真實使用情境

3. PREFILL 性能測試

測量不同 prompt 長度下的 prefill 處理速度（prefill tokens / 秒）

目標 Prompt Tokens 實際 Prompt Tokens Wall Time (s) Prefill 速度 (tok/s)
256 4,428 1.535 2,883.9
512 8,818 3.118 2,828.3
1,024 17,495 6.345 2,757.2
2,048 35,276 13.724 2,570.4
4,096 70,563 31.370 2,249.4

分析

  • 短 prompt 可達 ~2,884 tok/s 的 prefill 吞吐
  • 隨著 prompt 長度增加，prefill 速度略微下降（瓶頸從 compute 轉向 memory bandwidth）
  • 4K tokens 仍有 2,249 tok/s，表現穩定

4. DECODE 性能測試

使用極短 prompt（~20 tokens），測量純 decode 速度

要求 Tokens 實際輸出 Tokens Wall Time (s) 解碼時間估計 (s) Decode 速度 (tok/s)
32 32 0.459 0.439 72.9
64 64 0.542 0.522 122.6
128 128 0.814 0.794 161.2
256 256 2.151 2.131 120.1
512 512 5.071 5.051 101.4

分析

  • 峰值 decode 速度 ~161 tok/s（128 tokens 情境）
  • 較長輸出時速度回落（101-120 tok/s），可能受 KV cache 壓力影響
  • 投機解碼（DFlash2）在短輸出時可能尚未完全啟動

5. 混合場景測試

模擬真實使用：不同 prompt + 輸出長度組合

場景 Prompt Tokens 輸出 Tokens Wall Time (s) 整體吞吐 (tok/s)
Short (597t → 64t) 597 64 1.047 631.2
Medium (5,804t → 128t) 5,804 128 3.628 1,634.9
Long (22,985t → 256t) 22,985 256 12.083 1,923.4

分析

  • 混合場景下 prefill 主導整體吞吐（prompt 越長，prefill 佔比越高）
  • Long 場景達到 1,923 tok/s 整體吞吐（prefill 貢獻最大）

6. vLLM /metrics 分析

測試期間的 Metrics 變化

指標 開始值 結束值 差異
成功請求數 225 259 +34
Prompt Tokens 總量 2,479,447 2,651,764 +172,317
Generation Tokens 總量 54,457 56,685 +2,228
投機解碼草稿總數 17,257 17,723 +466
投機接受 tokens 37,322 39,088 +1,766
前綴快取命中 1,473,120 1,473,120 0 (確認無緩存)

關鍵性能指標（來自 Histogram）

指標 平均值
TTFT (Time to First Token) 738.1s / 260 req = 2.84s
Inter-token Latency 751.4s / 17,723 tokens = 42.4ms
Prefill Time 551.9s / 259 req = 2.13s
Decode Time 711.7s / 259 req = 2.75s
E2E Latency 1,447.8s / 259 req = 5.59s

投碼解碼效率

指標 值
每次迭代平均接受 tokens 1,766 / 466 = 3.79 tokens/step
投碼接受率 39,088 / (17,723 × 7) = 31.5%
解碼加速比（vs 逐 token） ~3.79x

7. 總結

測試項目 最佳表現 備註
Prefill 速度 2,884 tok/s 短 prompt（256 tokens）
Decode 速度 161 tok/s 128 tokens 輸出
混合場景吞吐 1,923 tok/s Long prompt + medium output
投碼加速比 3.79x DFlash2 每次迭代產出 3.79 tokens
Inter-token 延遲 42.4 ms 包含投碼驗證的整體延遲

關鍵發現

  1. Prefill 無瓶頸: 即使是 4K tokens 仍有 2,249 tok/s，compute-bound 表現優秀
  2. Decode 受投碼影響: 128 tokens 時達到峰值 161 tok/s，更長輸出時回落至 101-120 tok/s
  3. DFlash2 效率: 每次投碼迭代產出 3.79 tokens（預期 7 tokens 的 54%），投碼接受率約 31.5%
  4. 前綴快取正確避開: 測試期間 prefix_cache_hits_total 無變化（增加 0），確認緩存完全避免
  5. FP8 KV Cache 穩定: 8.6GB 配置下無 OOM 或效能衰退

這是R9700單卡目前的最速配置了，就是上下文最大就225K(不載入視覺)，但很夠用了。AMD能跑NVFP4真的很神，而且還這麼快。推薦裝一個來試試。

]]>https://lcz.me/topic/1820RSS for NodeMon, 12 Oct 2026 12:24:35 GMTSat, 19 Sep 2026 16:10:12 GMT60<![CDATA[Reply to 單R9700 + VLLM(GGZ14/vllm-mxfp4) + unsloth/Qwen3.8-27B-NVFP4 測試 on Thu, 01 Oct 2026 11:17:20 GMT]]>🔥 本帖参与讨论人数已达 10+，入选热议，作者 +3 积分奖励，感谢分享！

奖励凭证：热议 +3 分 · 编号 h1820-1142-1（系统自动发放，显示稍有延迟）

]]>https://lcz.me/post/21802https://lcz.me/post/21802Thu, 01 Oct 2026 11:17:20 GMT<![CDATA[Reply to 單R9700 + VLLM(GGZ14/vllm-mxfp4) + unsloth/Qwen3.8-27B-NVFP4 測試 on Sun, 27 Sep 2026 12:10:00 GMT]]>我今天带小孩出去无聊的时候也升级到了R3，还是200k的上下文，带图。PP和tg都有提升，tg甚至到了125左右，比上个版本快个30%左右。老天，这个也太牛逼了！哈哈

Screenshot_20260927_220248_com_android_chrome_ChromeTabbedActivity.jpg

]]>https://lcz.me/post/21150https://lcz.me/post/21150Sun, 27 Sep 2026 12:10:00 GMT<![CDATA[Reply to 單R9700 + VLLM(GGZ14/vllm-mxfp4) + unsloth/Qwen3.8-27B-NVFP4 測試 on Sun, 27 Sep 2026 05:02:58 GMT]]>@applejuice

對話都是秒起動，真的比較爽，少那近20K上下文就認了。

]]>https://lcz.me/post/21091https://lcz.me/post/21091Sun, 27 Sep 2026 05:02:58 GMT<![CDATA[Reply to 單R9700 + VLLM(GGZ14/vllm-mxfp4) + unsloth/Qwen3.8-27B-NVFP4 測試 on Sun, 27 Sep 2026 04:52:20 GMT]]>@paul-hou prefill 高就是爽

]]>https://lcz.me/post/21090https://lcz.me/post/21090Sun, 27 Sep 2026 04:52:20 GMT<![CDATA[Reply to 單R9700 + VLLM(GGZ14/vllm-mxfp4) + unsloth/Qwen3.8-27B-NVFP4 測試 on Sun, 27 Sep 2026 04:46:49 GMT]]>@fcme

65K-R3版雖然只有174K上下文，但在DSH中用起來真的更像線上API了，開新會話都是在2秒內就會開始跑起來，所以我還是研究了一下，把上下文調到了216000。

最終設定

項目 值 備註
max-model-len 216000 245 blocks × 880 = 215,600,在 pool 內
max-num-seqs 1 單請求
max-num-batched-tokens 2048 維持原值(改動 #2 不做)
kv-cache-memory-bytes auto vLLM 依 gpu-mem-util 自動算
gpu-memory-utilization 0.98
KV pool(實測) 7.47 GiB = 216,480 tokens 開機日誌 GPU KV cache size: 216,480 tokens
CUDA graphs [1,2,4,8] 改動 #1
defrag max_split_size_mb:64 改動 #3
prefix caching on RADIANCE_GDN_LAZY=0
KV dtype fp8
attention R4D
speculative DFlash2 x7,TRITON_ATTN,draft_sample_method probabilistic
mamba-cache-mode align
served-model-name qwen3.8-27b-mxfp4
host / port 0.0.0.0 / 8080
reasoning effort medium 伺服器預設
n-gram co-drafting off(預設);PAITON_NGRAM=1 開啟 +27% decode(agentic 編碼場景)
]]>https://lcz.me/post/21089https://lcz.me/post/21089Sun, 27 Sep 2026 04:46:49 GMT<![CDATA[Reply to 單R9700 + VLLM(GGZ14/vllm-mxfp4) + unsloth/Qwen3.8-27B-NVFP4 測試 on Sun, 27 Sep 2026 00:04:16 GMT]]>@applejuice 可以，拆两层说。

1）R9700「支持 FP4」指的是权重格式，不是 FP4 算力。
RDNA4/gfx1201 原生能吃 MXFP4 权重（e2m1 + 每 32 一组 e8m0 指数），但矩阵计算路径不是 FP4 MAC。这个仓库（GGZ14/vllm-mxfp4）跑的是 W4A8：4bit 权重 × FP8 激活、走 fp8 WMMA（gfx1201 上 fp8 WMMA 325 TFLOP/s，f16 只有 160）。上游 vLLM 默认跑不了，是三道软门槛：is_fp4_avail() 白名单不含 gfx1201、aiter 模块路径变动、gfx1250 的 WMMA tile（本卡只有 16x16x16）；仓库用 patch + 手写 HIP kernel 绕过。

2）NVFP4 → MXFP4 是在线重量化。
NVFP4 是 e2m1 + 每 16 一个 e4m3 scale + 每张量 fp32 scale；加载后 dequant 再重量化成 MXFP4（e2m1 + 每 32 一个 e8m0），按合并 linear 的 partition 做，约 10s/rank。这一步是 double rounding，实测 relRMS 0.113 → 0.158（直接 bf16→MXFP4 是 0.112），GSM8K 基本看不出来。

3）为什么以前没人做、收益在哪。
以前缺的是愿意写 gfx1201 小众 kernel 的人；现在 AI 辅助编码让「只有几十个人要的优化」变得可做——不是硬件突然开放了 FP4。收益主要来自权重流量：27B 的 MXFP4 body 9.24 GiB/GPU，FP8 约 12.6 GiB，decode 省带宽，还腾出大量 KV（单卡 65k ctx 约 99k tokens；双卡 262k ctx、943k tokens）。decode 仍受带宽约束，4bit 是把墙推远一点，不是推倒。

]]>https://lcz.me/post/21024https://lcz.me/post/21024Sun, 27 Sep 2026 00:04:16 GMT<![CDATA[Reply to 單R9700 + VLLM(GGZ14/vllm-mxfp4) + unsloth/Qwen3.8-27B-NVFP4 測試 on Sat, 26 Sep 2026 12:27:08 GMT]]>@paul-hou
那就不值得了，不需要识图的话用识图能力换也行，能顶到240k左右。开了就只有200k了，我这几天用下来也基本够了，配合dsh非常非常好用了。感觉有用DS v4 flash的感觉，和V4.1的拉稀一样的速度没法比。

]]>https://lcz.me/post/20960https://lcz.me/post/20960Sat, 26 Sep 2026 12:27:08 GMT<![CDATA[Reply to 單R9700 + VLLM(GGZ14/vllm-mxfp4) + unsloth/Qwen3.8-27B-NVFP4 測試 on Sat, 26 Sep 2026 12:22:26 GMT]]>@fcme
雙卡可用一樣的prefill可以超過6000。
單卡併發試完了，結論就不適合，看來要雙卡以上才適合併發。
後來有發現沒啟用到緩存功能，打開後上下文下降到174k。這10%的加速要用60k上下文來換。

]]>https://lcz.me/post/20957https://lcz.me/post/20957Sat, 26 Sep 2026 12:22:26 GMT<![CDATA[Reply to 單R9700 + VLLM(GGZ14/vllm-mxfp4) + unsloth/Qwen3.8-27B-NVFP4 測試 on Sat, 26 Sep 2026 11:56:15 GMT]]>@suboyang
双卡tp会有不同的框架吧。个人使用的话单卡就很好了，我现在200k上下文，pp/tg3500/100左右，双卡的话基本就是为了多开更长的长下文才有意义。

]]>https://lcz.me/post/20948https://lcz.me/post/20948Sat, 26 Sep 2026 11:56:15 GMT<![CDATA[Reply to 單R9700 + VLLM(GGZ14/vllm-mxfp4) + unsloth/Qwen3.8-27B-NVFP4 測試 on Sat, 26 Sep 2026 08:35:52 GMT]]>@fcme

关键是他说的是一张卡
Tested on one Radeon AI PRO R9700 (32 GB, RDNA4, gfx1201). Other GPUs have not been qualified.

双卡TP性能，决定R9700双卡有没有价值。如果双卡TP性能单流速度很低，那么R9700价值也不是很高。真正用本地模型干活，速度还是很重要的。

]]>https://lcz.me/post/20918https://lcz.me/post/20918Sat, 26 Sep 2026 08:35:52 GMT<![CDATA[Reply to 單R9700 + VLLM(GGZ14/vllm-mxfp4) + unsloth/Qwen3.8-27B-NVFP4 測試 on Sat, 26 Sep 2026 08:21:17 GMT]]>@paul-hou
等你作业了，不过我主要是办公场景，不开发，感觉差的这点点区别不是很大就先不折腾了。paiton这个仓库现在就很好了，和普通的框架1100左右的pp已经是云泥之别了。

]]>https://lcz.me/post/20916https://lcz.me/post/20916Sat, 26 Sep 2026 08:21:17 GMT<![CDATA[Reply to 單R9700 + VLLM(GGZ14/vllm-mxfp4) + unsloth/Qwen3.8-27B-NVFP4 測試 on Sat, 26 Sep 2026 07:56:59 GMT]]>@fcme

我是把65K-R3又重新調整了一次設定成單請求不併發，最大上下文就192K左右。
200K的改成2併發150K，設成一些DRAM給他超出VRAM備用，還要試試超出的情況。

]]>https://lcz.me/post/20913https://lcz.me/post/20913Sat, 26 Sep 2026 07:56:59 GMT<![CDATA[Reply to 單R9700 + VLLM(GGZ14/vllm-mxfp4) + unsloth/Qwen3.8-27B-NVFP4 測試 on Sat, 26 Sep 2026 07:48:33 GMT]]>調回300W再測一次，調成300W似乎效能差異滿大的。

2. PREFILL 效能結果（本次全量重測）

固定 output ~32 tokens，變化輸入長度：

Prompt tokens TTFT (ms) 邊際 prefill (tok/s)
111 94.0 —（基準點）
507 177.0 4,377
1,002 290.1 3,564
1,992 567.9 3,645
4,071 1,138.2 3,464
8,031 2,281.3 3,472

結論：PREFILL 邊際速率 ≈ 3,460–4,380 tok/s，隨輸入變長收斂至約 3,500 tok/s；TTFT 隨 prompt 近似線性成長（~0.28 ms/輸入 token）。

3. DECODE 效能結果（通用自然語言，本次全量重測）

固定 prompt ~256 tokens，thinking OFF：

Output tokens TTFT (ms) 總時間 (s) TPOT (ms/token) Decode (tok/s)
64 98.5 0.66 8.97 111.4
128 95.5 1.10 7.92 126.3
256 95.6 2.21 8.28 120.7

結論：平均 DECODE ≈ 119.5 tok/s（TPOT ≈ 8.39 ms/token），穩定在 111–126 tok/s。

4. 編程（Programming）DECODE 效能結果（本次全量重測）

5 種真實程式設計任務，thinking OFF、單請求、輸出固定 256 tokens：

任務 Output tokens TTFT (ms) 總時間 (s) TPOT (ms/token) Decode (tok/s)
fibonacci 256 52.3 1.26 4.73 211.4
sorting 256 50.7 1.36 5.13 195.1
api 256 50.8 1.56 5.91 169.2
regex 256 50.7 1.53 5.78 172.9
class 256 51.0 1.76 6.70 149.3

結論：編程 DECODE 平均 ≈ 179.6 tok/s（中位數 ≈ 172.9 tok/s，範圍 149.3–211.4），TPOT ≈ 5.65 ms/token。

]]>https://lcz.me/post/20912https://lcz.me/post/20912Sat, 26 Sep 2026 07:48:33 GMT<![CDATA[Reply to 單R9700 + VLLM(GGZ14/vllm-mxfp4) + unsloth/Qwen3.8-27B-NVFP4 測試 on Sat, 26 Sep 2026 07:43:22 GMT]]>@paul-hou
他这个把上下文调短了以后，貌似是为了优化多并发的场景。在agent时代65k的上下文有点不够看啊，单人使用还是老的200k版本好些。

]]>https://lcz.me/post/20911https://lcz.me/post/20911Sat, 26 Sep 2026 07:43:22 GMT<![CDATA[Reply to 單R9700 + VLLM(GGZ14/vllm-mxfp4) + unsloth/Qwen3.8-27B-NVFP4 測試 on Sat, 26 Sep 2026 07:20:13 GMT]]>paiton方案又有新的鏡像，65K-R3版，調整了一下，單卡上下文的最大值又降到只剩192K左右。
效能又上升了一點(PREFILL滿大一個點)。
以下是限制功率在210W下的測試結果。

2. DECODE 效能結果

固定 prompt ~256 tokens，thinking OFF：

Output tokens TTFT (ms) 生成時間 (s) TPOT (ms/token) Decode (tok/s)
64 114.1 0.85 11.63 86.0
128 113.8 1.41 10.21 98.0
256 114.0 2.84 10.71 93.4

結論：平均 DECODE ≈ 92.5 tok/s（TPOT ≈ 10.9 ms/token），穩定在 86–98 tok/s。

3. 編程（Programming）DECODE 效能結果

針對 5 種真實程式設計任務，thinking OFF、單請求、輸出固定 256 tokens、每設定 4 次取中位數：

任務 Output tokens TTFT (ms) 總時間 (s) TPOT (ms/token) Decode (tok/s)
fibonacci 256 57.3 1.61 6.10 164.0
sorting 256 57.3 1.74 6.62 151.2
api 256 57.0 2.00 7.61 131.4
regex 256 57.0 1.96 7.45 134.2
class 256 59.0 2.26 8.63 115.8

結論：編程 DECODE 平均 ≈ 139.3 tok/s（中位數 ≈ 134.2 tok/s，範圍 115.8–164.0），TPOT ≈ 7.28 ms/token。

4. PREFILL 效能結果

固定 output ~32 tokens，變化輸入長度：

Prompt tokens TTFT (ms) 邊際 prefill (tok/s)
111 112.5 —（基準點）
507 220.7 3,660
1,002 356.6 3,642
1,992 693.3 2,940
4,071 1,373.2 3,058
8,031 2,757.3 2,861

結論：PREFILL 邊際速率 ≈ 2,900–3,600 tok/s，隨輸入變長收斂至約 3,000 tok/s；TTFT 隨 prompt 近似線性成長（~0.34 ms/輸入 token）。

]]>https://lcz.me/post/20908https://lcz.me/post/20908Sat, 26 Sep 2026 07:20:13 GMT<![CDATA[Reply to 單R9700 + VLLM(GGZ14/vllm-mxfp4) + unsloth/Qwen3.8-27B-NVFP4 測試 on Sat, 26 Sep 2026 04:16:12 GMT]]>

@applejuice said:

纳闷为啥以前没人弄这个，估计也是和现在AI能力强了以后有想法的牛人更加可以用Claude之类牛逼模型把这么小众的需求给满足了。根本上还是5090太贵了吧

一張5090 32G 價格接近4張R9700 (128G) 這性價比出來了 在LLM單一模型上

]]>https://lcz.me/post/20866https://lcz.me/post/20866Sat, 26 Sep 2026 04:16:12 GMT<![CDATA[Reply to 單R9700 + VLLM(GGZ14/vllm-mxfp4) + unsloth/Qwen3.8-27B-NVFP4 測試 on Sat, 26 Sep 2026 04:11:38 GMT]]>

@fcme said:

买！这个库是新出的，有了这个库以后跑27b的FP4模型3000以上的pp速度和100左右的tg在本地模型里面就是最甜的甜点了，综合了价格和性能，还有输出质量。

我今天剛完成 雙卡RTX5070 Ti -NInfer-Qwen3.6-27B-NVFP4
純文字速度大約 100 TPS
解題速度大約 140 TPS
Prefill 約 3300 tok/s
但CP值不高

雙卡 R97000 Prefill 可以高達6000 tok/s 這真誘人
而且看過4卡是12,000 tok/s的數據

]]>https://lcz.me/post/20863https://lcz.me/post/20863Sat, 26 Sep 2026 04:11:38 GMT<![CDATA[Reply to 單R9700 + VLLM(GGZ14/vllm-mxfp4) + unsloth/Qwen3.8-27B-NVFP4 測試 on Sat, 26 Sep 2026 04:04:27 GMT]]>挺好的测试，我对VLLM的实测不太多，偶尔玩玩，这样的帖子很有意义。毕竟是主力框架之一！

]]>https://lcz.me/post/20860https://lcz.me/post/20860Sat, 26 Sep 2026 04:04:27 GMT<![CDATA[Reply to 單R9700 + VLLM(GGZ14/vllm-mxfp4) + unsloth/Qwen3.8-27B-NVFP4 測試 on Sat, 26 Sep 2026 04:02:02 GMT]]>

@fcme 说:

@applejuice
不是，速度起来是因为R9700本身是支持FP4的，这次这个框架可以把nvfp4的模型转换为AMD的mxfp4，这样就能充分利用9700的FP4能力了。纳闷为啥以前没人弄这个，估计也是和现在AI能力强了以后有想法的牛人更加可以用Claude之类牛逼模型把这么小众的需求给满足了。根本上还是5090太贵了吧，狗头保命，哈哈。

@xiaote 可以解释吗？

]]>https://lcz.me/post/20859https://lcz.me/post/20859Sat, 26 Sep 2026 04:02:02 GMT<![CDATA[Reply to 單R9700 + VLLM(GGZ14/vllm-mxfp4) + unsloth/Qwen3.8-27B-NVFP4 測試 on Sat, 26 Sep 2026 04:00:19 GMT]]>@applejuice
不是，速度起来是因为R9700本身是支持FP4的，这次这个框架可以把nvfp4的模型转换为AMD的mxfp4，这样就能充分利用9700的FP4能力了。纳闷为啥以前没人弄这个，估计也是和现在AI能力强了以后有想法的牛人更加可以用Claude之类牛逼模型把这么小众的需求给满足了。根本上还是5090太贵了吧，狗头保命，哈哈。

]]>https://lcz.me/post/20857https://lcz.me/post/20857Sat, 26 Sep 2026 04:00:19 GMT<![CDATA[Reply to 單R9700 + VLLM(GGZ14/vllm-mxfp4) + unsloth/Qwen3.8-27B-NVFP4 測試 on Sat, 26 Sep 2026 03:38:57 GMT]]>@fcme 据了解 这次的速度提升不在mxfp4 而是社区优化了 vllm/sglang
mxfp4 只是用更小的vram

]]>https://lcz.me/post/20852https://lcz.me/post/20852Sat, 26 Sep 2026 03:38:57 GMT<![CDATA[Reply to 單R9700 + VLLM(GGZ14/vllm-mxfp4) + unsloth/Qwen3.8-27B-NVFP4 測試 on Sat, 26 Sep 2026 03:36:05 GMT]]>@kos-or
买！这个库是新出的，有了这个库以后跑27b的FP4模型3000以上的pp速度和100左右的tg在本地模型里面就是最甜的甜点了，综合了价格和性能，还有输出质量。
唯一的缺憾就是这个库的底层用的是vllm，框架开销比较大。我晕下来不带识图的话，上下文可以开到240左右，开了识图以后，上下文也就只能开到200~210k。基本上就把32g的显存跑满了。

]]>https://lcz.me/post/20849https://lcz.me/post/20849Sat, 26 Sep 2026 03:36:05 GMT<![CDATA[Reply to 單R9700 + VLLM(GGZ14/vllm-mxfp4) + unsloth/Qwen3.8-27B-NVFP4 測試 on Sat, 26 Sep 2026 03:00:31 GMT]]>

@applejuice said:

看到这个帖我有冲动买 r9700

哈哈 我跟你一樣有這個衝動

]]>https://lcz.me/post/20845https://lcz.me/post/20845Sat, 26 Sep 2026 03:00:31 GMT<![CDATA[Reply to 單R9700 + VLLM(GGZ14/vllm-mxfp4) + unsloth/Qwen3.8-27B-NVFP4 測試 on Sat, 26 Sep 2026 01:55:15 GMT]]>@alan.lgv60 好的，谢谢！

]]>https://lcz.me/post/20815https://lcz.me/post/20815Sat, 26 Sep 2026 01:55:15 GMT