# Qwen 3.6 27B - VLLM 性能基准测试结果（BF16、FP8、NVFP4）

分享一些关于在我的开发系统上使用 VLLM 对 Qwen 3.6 27B 模型进行各种量化版本的测试结果。我使用了 llama-benchy 来生成结果，然后将其输入 LLM 以格式化表格使其更易读。虽然 NVFP4 速度快得惊人，但在 copilot 中遇到了循环问题，而使用 BF16 时没有这个问题，并且在 agent 模式下使用时的回答总体上不如更高量化版本详尽。基于这些结果，FP8 似乎是正确的选择。我相信一些参数可以进一步调整以获得更好的性能，但这些用于编码目的已经足够快了。我以前使用 llama.cpp，但发现 VLLM 在实践中更快（由于分页注意力），也更稳定（llama.cpp 会频繁给我随机错误，需要我重置提示或重新启动服务）。如果您有任何改进意见或建议，请告诉我。 测试系统： 主板：Asus Proart Z890 CPU：Intel 270K plus 内存：96GB DDR5（6000MHZ） GPU：RTX 6000 Pro Blackwell 96GB（Max-Q，ECC 启用） 软件： 操作系统：Ubuntu 26.04 LTS（x86_64） Python 版本：3.12.13 vLLM 版本：0.24.0 NVIDIA-SMI 595.71.05 CUDA 版本：13.2 模型： Qwen 3.6 27B - BF16 和 FP8（HF Qwen） Qwen 3.6 27B - NVFP4（HF Nvidia） * 用修复过的聊天模板替换了提供的 jinja 脚本 VLLM 参数： GPU_COUNT="1" MAX_LEN="262144" export VLLM_USE_DEEP_GEMM=0 export FLASHINFER_MAX_NUM_TOKENS=8192 export TORCH_CUDA_ARCH_LIST="12.0f" export TORCH_FLOAT32_MATMUL_PRECISION=high export PYTORCH_ALLOC_CONF=expandable_segments:True export VLLM_USE_FLASHINFER_SAMPLER=1 vllm serve "$MODEL_PATH" \ --port "$PORT" \ --tensor-parallel-size "$GPU_COUNT" \ --max-model-len "$MAX_LEN" \ --performance-mode interactivity \ --attention-backend FLASHINFER \ --gpu-memory-utilization 0.88 \ --max-num-seqs 2 \ --enable-chunked-prefill \ --max-num-batched-tokens 8192 \ --kv-cache-dtype fp8 \ --reasoning-parser qwen3 \ --enable-auto-tool-choice \ --tool-call-parser qwen3_coder \ --speculative-config '{"method":"mtp","num_speculative_tokens":2}' \ --enable-prefix-caching \ --trust-remote-code 关键性能要点 NVFP4 在 token 生成速度上占据绝对优势（约比 BF16 快 2.6 倍）：因为 token 解码严格受内存带宽限制，将权重压缩到 4 位可以大幅减少 PCIe/VRAM 数据传输，使生成吞吐量从约 61 t/s（BF16）跃升至约 163 t/s（NVFP4）。 FP8 在提示处理与预填充速度上胜出（约比 BF16 快 20%）：提示预填充是计算密集型的（大量矩阵运算）。FP8 利用原生 Tensor Core 加速，且无需反量化开销，在摄入阶段同时优于 BF16 和 NVFP4。 NVFP4 相对于 FP8 有轻微的预填充惩罚：因为 NVFP4 在大型计算密集的预填充批次中必须即时反量化权重，在提示处理速度上落后 FP8 约 10–15%，但仍优于基线 BF16。 1. Token 生成速度（tg32 吞吐量） 越高越好。测量在不断增加上下文深度的情况下生成 32 个新 token 时的解码速度。 | 上下文深度 | BF16 (t/s) | FP8 (t/s) | NVFP4 (t/s) | 加速比 (NVFP4 vs BF16) | |------------|------------|-----------|-------------|-------------------------| | 基线 (0k) | 59.10 ± 1.67 | 97.49 ± 4.08 | 169.23 ± 9.02 | 2.86x | | 4k 上下文 | 63.01 ± 3.63 | 103.03 ± 4.46 | 157.90 ± 14.55 | 2.51x | | 8k 上下文 | 67.55 ± 2.70 | 96.88 ± 5.11 | 166.52 ± 9.93 | 2.47x | | 16k 上下文 | 64.57 ± 2.99 | 101.51 ± 7.11 | 171.12 ± 0.50 | 2.65x | | 32k 上下文 | 59.46 ± 3.68 | 100.48 ± 4.33 | 158.04 ± 16.51 | 2.66x | | 65k 上下文 | 61.55 ± 2.81 | 98.99 ± 5.06 | 159.91 ± 7.52 | 2.60x | 2. 提示处理速度（pp2048 吞吐量） 越高越好。测量在已有上下文深度下预填充 2048 个提示 token 时的摄入速度。 | 上下文深度 | BF16 (t/s) | FP8 (t/s) | NVFP4 (t/s) | 加速比 (FP8 vs BF16) | |------------|------------|-----------|-------------|-----------------------| | 基线 (0k) | 4359.28 ± 66.84 | 4747.78 ± 9.40 | 4732.42 ± 17.77 | 1.09x | | 4k 上下文 | 1856.76 ± 9.93 | 2250.71 ± 0.84 | 2010.97 ± 3.54 | 1.21x | | 8k 上下文 | 2095.89 ± 6.85 | 2479.30 ± 16.20 | 2191.59 ± 2.93 | 1.18x | | 16k 上下文 | 1765.10 ± 13.83 | 2029.02 ± 13.96 | 1832.65 ± 3.78 | 1.15x | | 32k 上下文 | 1317.16 ± 21.52 | 1503.80 ± 6.42 | 1388.85 ± 8.14 | 1.14x | | 65k 上下文 | 880.40 ± 6.51 | 1058.40 ± 33.99 | 902.65 ± 3.01 | 1.20x | 3. 完整上下文预填充延迟（ctx_pp 端到端 TTFT） 越低越好。测量摄入并评估整个上下文窗口所需的总时间（毫秒，即首 token 时间）。 | 上下文深度 | BF16 (ms) | FP8 (ms) | NVFP4 (ms) | FP8 延迟减少 | |------------|-----------|----------|------------|---------------| | 4k 上下文 | 1023.29 ± 6.08 | 833.65 ± 14.57 | 927.45 ± 1.68 | -18.5% | | 8k 上下文 | 1974.69 ± 1.80 | 1415.69 ± 11.07 | 1869.70 ± 4.42 | -28.3% | | 16k 上下文 | 4122.54 ± 18.20 | 2926.47 ± 6.89 | 3927.95 ± 4.72 | -29.0% | | 32k 上下文 | 9179.91 ± 58.16 | 6572.61 ± 8.87 | 8692.01 ± 30.53 | -28.4% | | 65k 上下文 | 21760.57 ± 85.68 | 16425.60 ± 137.66 | 20613.26 ± 18.28 | -24.5% | 4. 独立峰值与首 token 指标 测量无上下文饱和时的峰值生成速度和基线 TTFT。 | 量化格式 | 峰值生成吞吐量（峰值 t/s） | 基线 TTFT（pp2048 ttfr） | 估计 PPT（pp2048 est_ppt） | |----------|--------------------------|--------------------------|-----------------------------| | BF16 | 61.01 ± 1.72 t/s | 525.03 ± 7.29 ms | 470.14 ± 7.29 ms | | FP8 | 100.63 ± 4.21 t/s | 469.82 ± 0.85 ms | 431.57 ± 0.85 ms | | NVFP4 | 174.69 ± 9.31 t/s | 467.40 ± 1.62 ms | 432.98 ± 1.62 ms |