跳转至

Qwen3.8-27B 三种精度实测:原始、FP8 和 NVFP4 到底差多少?

写在前面。

Qwen3.8-27B 出来后,我一直想把一件事测清楚:同一张卡、同一套 prompts、同样生成 128 tokens,原始权重、FP8 和 NVFP4 到底能差多少?

这种测试最怕条件不一致。只要 prompts、生成长度或者并发配置不同,跑出来的数字就不能直接放在一起比较。

所以这一次我把条件全部重新对齐了。

硬件是单卡 NVIDIA RTX PRO 6000,推理框架是 vLLM。三种权重都跑 C1、C2、C4、C8,每档 3 轮,每轮 128 个请求,并且每个请求都生成 128 tokens。

最后的结果很直接:原始权重 C8 只有 292 tok/s 左右,FP8 能跑到 425 tok/s,NVFP4 则到了 477 tok/s。

也就是说,量化不只是省显存。至少在这张卡、这个模型和这套参数下,它实实在在把吞吐拉高了,而且延迟还更低。

一、先把测试条件说清楚

模型 Qwen3.8-27B
权重 原始 / FP8 / NVFP4(Unsloth)
GPU NVIDIA RTX PRO 6000
框架 vLLM
压测工具 InferBench
并发 1 / 2 / 4 / 8
每档轮次 3
每轮请求 128
Max tokens 128
temperature 0.0
Warmup 1
Prompts 3 条循环,三组完全一致

36 轮实验全部完成,每轮都是 128/128 请求成功。

这里还有一个限制需要提前说:InferBench 这次没有采到 TTFT 和 TPOT,所以文中的延迟统一看端到端 P50 / P95。它能回答“一个请求多久完成”,但不能单独告诉你首 token 有多快。

另外,Serving 地址、内部实验台地址和私密配置都没有写进来。文章只保留可公开的环境信息和测试结果。

二、从原始权重换到 FP8,提升是肉眼可见的

先看原始权重。

并发 输出吞吐 请求吞吐 P50 P95 相对 C1 单流 tok/s 线性效率
C1 43.29 tok/s 0.34 req/s 2.94 s 3.05 s 1.00x 43.29 100%
C2 83.81 tok/s 0.66 req/s 3.00 s 3.33 s 1.94x 41.91 97%
C4 158.94 tok/s 1.24 req/s 3.16 s 3.49 s 3.67x 39.74 92%
C8 291.61 tok/s 2.28 req/s 3.43 s 3.77 s 6.74x 36.45 84%

原始权重的并发扩展其实不差。

C1 到 C8,总吞吐从 43 tok/s 涨到 292 tok/s,放大了 6.74 倍,线性效率还有 84%。问题不在于它不会扩展,而是底子确实慢:单流只有 43 tok/s 左右,C8 的 P95 也已经到了 3.77 秒。

原始权重 C1

原始权重 C2

原始权重 C4

原始权重 C8

再看 FP8。

并发 输出吞吐 请求吞吐 P50 P95 相对 C1 单流 tok/s 线性效率
C1 70.33 tok/s 0.55 req/s 1.83 s 1.92 s 1.00x 70.33 100%
C2 131.06 tok/s 1.02 req/s 1.88 s 2.23 s 1.86x 65.53 93%
C4 241.49 tok/s 1.89 req/s 2.07 s 2.36 s 3.43x 60.37 86%
C8 425.43 tok/s 3.32 req/s 2.32 s 2.68 s 6.05x 53.18 76%

这组数据有两个地方值得注意。

第一个是单流。C1 从原始权重的 43 tok/s 直接涨到 70 tok/s,提升了 62%。这不是跑分里才看得见的小数点差距,而是实际对话时能感觉出来的变化。

第二个是延迟。同样在 C8,FP8 的吞吐比原始权重高了 46%,P95 却从 3.77 秒降到了 2.68 秒。通常我们会担心“吞吐上去了,单个请求会不会更慢”,但这次没有。FP8 是吞吐和延迟一起变好。

三轮之间也很稳。C1 和 C8 的吞吐 CV 分别只有 0.2% 和 0.5%,所以这不是某一轮偶然跑出来的高分。

FP8 C1

FP8 C2

FP8 C4

FP8 C8

三、NVFP4 的优势,到了并发场景才真正拉开

如果只看 C1,NVFP4 和 FP8 其实没有差得特别多。

FP8 是 70.33 tok/s,NVFP4 是 72.04 tok/s,只快了 2%。如果测试只跑单并发,很容易得出一个结论:FP4 好像也没比 FP8 快多少。

但把并发拉起来后,事情就不一样了。

并发 输出吞吐 请求吞吐 P50 P95 相对 C1 单流 tok/s 线性效率
C1 72.04 tok/s 0.56 req/s 1.81 s 1.86 s 1.00x 72.04 100%
C2 148.94 tok/s 1.16 req/s 1.66 s 1.95 s 2.07x 74.47 103%
C4 271.48 tok/s 2.12 req/s 1.85 s 2.07 s 3.77x 67.87 94%
C8 476.64 tok/s 3.72 req/s 2.10 s 2.36 s 6.62x 59.58 83%

C2 时,NVFP4 比 FP8 快 14%;C4 和 C8 也都快了 12%左右。

最有意思的是 C2。总吞吐达到 C1 的 2.07 倍,算下来单流反而从 72.04 涨到了 74.47 tok/s。这个 103% 不是算错了,而是单并发时 GPU 没有完全吃满,到了 C2,batching 反而把利用率提了起来。

当然,这不代表继续加并发就能一直超线性。到了 C4 和 C8,单流速度还是会往下掉。只不过 NVFP4 掉得更慢,C8 还能保留 83% 的线性效率,比 FP8 的 76% 更好。

C8 三轮的吞吐 CV 只有 0.25%,基本都稳定在 477 tok/s 左右。P95 是 2.36 秒,比 FP8 C8 少了约 320 ms,比原始权重少了 1.4 秒。

NVFP4 C1

NVFP4 C2

NVFP4 C4

NVFP4 C8

把三组放到一起看,会更直观:

并发 原始 tok/s FP8 tok/s NVFP4 tok/s FP8 / 原始 NVFP4 / 原始 NVFP4 / FP8
C1 43.29 70.33 72.04 1.62x 1.66x 1.02x
C2 83.81 131.06 148.94 1.56x 1.78x 1.14x
C4 158.94 241.49 271.48 1.52x 1.71x 1.12x
C8 291.61 425.43 476.64 1.46x 1.63x 1.12x
并发 原始 P95 FP8 P95 NVFP4 P95
C1 3.05 s 1.92 s 1.86 s
C2 3.33 s 2.23 s 1.95 s
C4 3.49 s 2.36 s 2.07 s
C8 3.77 s 2.68 s 2.36 s

四、如果让我选,我会怎么配?

只看这轮数据,我会直接选 NVFP4。

交互式应用用 C1 或 C2。C1 单流 72 tok/s,追求的是一个人用起来快;C2 总吞吐接近 149 tok/s,P95 还在 2 秒附近,更适合有少量并发的服务。

如果既想要吞吐,又不想让延迟涨得太厉害,我会选 C4。271 tok/s、P95 2.07 秒、线性效率 94%,这是这组数据里比较舒服的平衡点。

C8 则很明确,就是拿单卡总吞吐。477 tok/s 是本轮最高值,P95 2.36 秒也还没有失控,适合批处理或者对响应时间没那么敏感的场景。

那 FP8 还有没有必要?

有。因为这次只测了速度,没有测回答质量。NVFP4 性能更强,不等于它在你的业务数据上一定更好。如果后续质量评测发现 FP4 掉点明显,那 FP8 依然是更稳妥的选择。它的 C8 也有 425 tok/s,比原始权重快了 46%,已经是很实在的提升。

至于原始权重,这轮结果里确实没有性能优势。除非业务明确要求保留原始精度,否则单看这张 PRO 6000,我没有继续用原始权重的理由。

说到底,选哪种精度不能只看模型名字,也不能只跑一个 C1。单流看不出来的差距,到了真实并发里会被明显放大。这也是我这次坚持把 C1、C2、C4、C8 全部跑完的原因。

下一步就该补质量评测了。性能这边,答案已经很清楚:NVFP4 最快,FP8 最稳妥,原始权重最慢。

数据源:InferBench,max_tokens=128,2026-08-26。

回到页面顶部