Qwen3.8-27B 部署测速报告(GB10 / DGX Spark)

简介: 本报告测试Qwen3.8-27B在NVIDIA GB10(121GB统一内存)上的推理性能,覆盖vLLM、SGLang、llama.cpp三大引擎。SGLang+RadixArk NVFP4+NEXTN达成单流23.02 tok/s峰值,为当前最优;llama.cpp Q4_K_M方案仅需17GB显存,兼顾效率与成本。实测GB10单流上限约23 tok/s。

Qwen3.8-27B 部署测速报告(GB10 / DGX Spark)

测试日期:2026-08-14 ~ 08-16

1. 测试环境

项目 配置
GPU NVIDIA GB10(DGX Spark,aarch64,sm_121,121GB 统一内存)
CUDA / 驱动 CUDA 13.0 / 580.142
vLLM vllm025 venv = 0.26.0(torch 2.11.0+cu130);vllm0272 venv = 0.27.2rc1.dev91 nightly(torch 2.13.0+cu130)
SGLang 0.5.17(sgl-kernel 0.3.21,aarch64)
llama.cpp build 10449(master 0d9ceae1e,CUDA 编译)
操作系统内存 121GB 统一内存(GPU/CPU 共享)

2. 测速方法

统一使用 ~/bench_100k.py

  • 输入:约 99,912 tokens 长上下文 prompt(流式 SSE 计时)
  • 输出:256 tokens
  • 指标:Prefill = prompt_tokens / TTFT;Decode = (completion_tokens-1) / (末token时间 - 首token时间)
  • 单请求、单流;并发测试使用 ~/bench_concurrent.py
  • 测速调度脚本:~/gguf_bench_one.sh(llama.cpp)、~/sglang_bench_one.sh(SGLang)

3. 模型文件(~/models/models/

路径 格式 大小 来源
Qwen/Qwen3.8-27B-FP8 safetensors FP8 29G ModelScope(官方)
Inferact/Qwen3.8-27B-NVFP4 safetensors NVFP4 25G HuggingFace
RadixArk/Qwen3.8-27B-NVFP4 safetensors NVFP4(混合:MLP NVFP4 + 注意力 FP8 + MTP/视觉 BF16) 21G HuggingFace
unsloth/Qwen3.8-27B-NVFP4 safetensors NVFP4(compressed-tensors,含 model_mtp.safetensors) 22G HuggingFace
unsloth/Qwen3.8-27B-GGUF GGUF Q8_0/Q6_K/Q5_K_M/Q4_K_M + mmproj-BF16 86G ModelScope
RadixArk/Qwen3.8-27B-DSpark DSpark 推测器(1.36B,block 7)+ 自转 GGUF 2.7G×2 ModelScope

4. vLLM 测试结果

配置 引擎参数要点 启动脚本 Decode Prefill
FP8 基线 v0.26, enforce-eager, util 0.88, 262K, kv fp8 run_qwen38_vllm.sh 7.18 805
NVFP4(Inferact) 基线 同上 run_qwen38_nvfp4_vllm.sh 8.05 1030
FP8 + MTP k=3 v0.27.2, CUDA Graph, util 0.88, 262K run_qwen38_fp8_mtp_vllm.sh 14.76 1031
FP8 + MTP k=3 + 吞吐参数 util 0.5, 131K, async-scheduling, 32768/32 同上 16.71 685
NVFP4 + MTP k=3 v0.27.2, util 0.88, 262K run_qwen38_mtp_vllm.sh 17.80 698
NVFP4 + MTP k=3 + 吞吐参数 util 0.5, 131K, async-scheduling 同上 15.73 727
NVFP4 + MTP k=5 util 0.88 同上 NUM_SPEC_TOKENS=5 13.94 981
NVFP4 + MTP k=8 同上 NUM_SPEC_TOKENS=8 14.62 854
FP8 + DSpark k=3 method=dspark, RadixArk draft, util 0.88 run_qwen38_dspark_vllm.sh 14.55 710
FP8 + DSpark k=7 同上(block 7 原生) NUM_SPEC_TOKENS=7 17.63 688

注:vLLM 仅支持单一推测方法,MTP+DSpark 不可叠加;util 0.9 曾导致系统卡死,安全上限 0.88。

5. llama.cpp 测试结果(-c 262144 -ngl 99 -fa on --mmproj)

量化 无MTP MTP n=3 MTP n=5 MTP n=8 DSpark(n=7)
Q8_0 (29G) 6.35 14.13 12.91 14.08 12.54
Q6_K (23G) 7.10 15.90 19.49 15.20 20.24
Q5_K_M (20G) 7.98 16.17 16.93 14.11
Q4_K_M (17G) 8.78 19.65 21.44 15.70 21.33

Prefill 均在 520~620 tok/s 区间。
精度实测(llama-perplexity,同一技术文本):Q8_0 PPL=1.2373,Q4_K_M PPL=1.2411,相对损失 ~0.3%
MTP+DSpark 链式(draft-mtp,draft-dspark):不可行——链式要求 draft 模型自带 MTP 头,DSpark checkpoint 没有。

启动脚本:run_qwen38_gguf.sh(Q4_K_M+MTP n5)、run_qwen38_gguf_q6k_dspark.sh(Q6_K+DSpark)。

6. SGLang 测试结果(0.5.17, flashinfer 后端, trust-remote-code)

配置 Decode Prefill 脚本/参数
RadixArk NVFP4 + NEXTN(MTP 3/1/4) 23.02 🏆 744 sglang_bench_one.sh $R nextn
unsloth NVFP4 + NEXTN 19.12 842 同上 $U nextn
RadixArk NVFP4 + NEXTN + DGX调优 21.31 1098 EXTRA_ARGS: mem 0.95, mamba-ratio 4.59, chunk 8192, disable-prefill-cuda-graph
RadixArk NVFP4 + NEXTN + 仅prefill优化 21.86 1106 chunk 8192 + disable-prefill-cuda-graph(最终采用
NVFP4 + DSPARK(两版) ❌ 失败 SGLang 0.5.17 DSPARK 实现报 shape mismatch,需 main 分支

7. 并发测试

配置 并发 聚合 decode 每路
vLLM NVFP4+MTP(吞吐参数) 8 82.2 tok/s 10.3~11.3
llama.cpp Q4_K_M+MTP n5 4 43.9 tok/s 11.0~11.8
llama.cpp Q4_K_M+MTP n5 2 26.5 tok/s 13.3~13.4

8. 结论

  1. 单流冠军:SGLang + RadixArk NVFP4 + NEXTN = 23.02 tok/s(100K 上下文)
  2. 最终采用(常驻服务 ~/run_qwen38_sglang.sh):RadixArk NVFP4 + NEXTN + prefill 优化(chunk 8192 + disable-prefill-cuda-graph),decode 21.86~23 tok/s、prefill 1106 tok/s(TTFT 90s@100K,比默认快 47%)
  3. GB10 单流天花板 ~23 tok/s(内存带宽 273GB/s 物理限制),30 tok/s 不可达
  4. RadixArk NVFP4 优于 unsloth NVFP4(23.02 vs 19.12),unsloth 版已删除,仅保留 RadixArk 版
  5. MTP/DSpark 推测采样不影响生成质量(验证采样保分布);k/n-max 甜点位 3~5,过大反而回落
  6. llama.cpp 路线胜在内存占用小(17GB Q4_K_M),SGLang 胜在速度与并发

9. 过程中修复的环境问题(备忘)

  • flashinfer JIT 需 venv bin 在 PATH(找 ninja);MAX_JOBS=2 防 nvcc 并发 OOM
  • .bashrcCUDA_HOME=/usr/local/cuda-12.4 指向残缺工具链,脚本内强制 /usr/local/cuda
  • RadixArk DSpark 的 config.json 架构名需从 DSparkDraftModel 改为 Qwen3DSparkModel(vLLM 识别),已备份 config.json.bak
  • vLLM 0.27.2 nightly 才有 Qwen3.8 的 MTP gated-delta-net 修复
目录
相关文章
|
存储 缓存 文件存储
如何保证分布式文件系统的数据一致性
分布式文件系统需要向上层应用提供透明的客户端缓存,从而缓解网络延时现象,更好地支持客户端性能水平扩展,同时也降低对文件服务器的访问压力。当考虑客户端缓存的时候,由于在客户端上引入了多个本地数据副本(Replica),就相应地需要提供客户端对数据访问的全局数据一致性。
33250 201
如何保证分布式文件系统的数据一致性
|
设计模式 存储 监控
设计模式(C++版)
看懂UML类图和时序图30分钟学会UML类图设计原则单一职责原则定义:单一职责原则,所谓职责是指类变化的原因。如果一个类有多于一个的动机被改变,那么这个类就具有多于一个的职责。而单一职责原则就是指一个类或者模块应该有且只有一个改变的原因。bad case:IPhone类承担了协议管理(Dial、HangUp)、数据传送(Chat)。good case:里式替换原则定义:里氏代换原则(Liskov 
36820 22
设计模式(C++版)
|
存储 编译器 C语言
抽丝剥茧C语言(初阶 下)(下)
抽丝剥茧C语言(初阶 下)
|
机器学习/深度学习 人工智能 自然语言处理
带你简单了解Chatgpt背后的秘密:大语言模型所需要条件(数据算法算力)以及其当前阶段的缺点局限性
带你简单了解Chatgpt背后的秘密:大语言模型所需要条件(数据算法算力)以及其当前阶段的缺点局限性
24905 16
|
机器学习/深度学习 弹性计算 监控
重生之---我测阿里云U1实例(通用算力型)
阿里云产品全线降价的一力作,2023年4月阿里云推出新款通用算力型ECS云服务器Universal实例,该款服务器的真实表现如何?让我先测为敬!
36824 15
重生之---我测阿里云U1实例(通用算力型)
|
SQL 存储 弹性计算
Redis性能高30%,阿里云倚天ECS性能摸底和迁移实践
Redis在倚天ECS环境下与同规格的基于 x86 的 ECS 实例相比,Redis 部署在基于 Yitian 710 的 ECS 上可获得高达 30% 的吞吐量优势。成本方面基于倚天710的G8y实例售价比G7实例低23%,总性价比提高50%;按照相同算法,相对G8a,性价比为1.4倍左右。
|
存储 算法 Java
【分布式技术专题】「分布式技术架构」手把手教你如何开发一个属于自己的限流器RateLimiter功能服务
随着互联网的快速发展,越来越多的应用程序需要处理大量的请求。如果没有限制,这些请求可能会导致应用程序崩溃或变得不可用。因此,限流器是一种非常重要的技术,可以帮助应用程序控制请求的数量和速率,以保持稳定和可靠的运行。
29948 52

热门文章

最新文章