제 개발 시스템에서 인기 있는 양자화(quants) 모델들을 대상으로 VLLM을 사용하여 Qwen 3.6 27B를 테스트한 결과를 공유합니다. 결과를 생성하기 위해 llama benchy를 사용하였고, 가독성을 높이기 위해 표 형식으로 정리하는 과정에서 LLM을 활용했습니다.

NVFP4는 매우 빠르지만, BF16에서는 발생하지 않는 Copilot에서의 루핑(looping) 문제가 발생했습니다. 또한 에이전트(agent) 모드로 사용할 때의 전반적인 응답이 더 높은 양자화(higher quants) 모델들에 비해 덜 철저한 것으로 보입니다. 이러한 결과에 기반했을 때, FP8이 적절한 선택으로 보입니다. 더 나은 성능을 얻기 위해 일부 파라미터를 추가로 튜닝할 수 있겠지만, 코딩 용도로 사용하기에는 이 정도만으로도 충분히 빨랐습니다.

이전에는 llama.cpp를 사용했으나, 실제로는 VLLM이 (Paged Attention 덕분에) 더 빠를 뿐만 아니라 더 안정적이라는 것을 알게 되었습니다 (llama.cpp는 빈번하게 무작위 오류를 발생시켜 프롬프트를 재설정하거나 서비스를 재시작해야 하는 경우가 있었습니다).

개선 사항에 대한 의견이나 제안이 있다면 알려주세요.

테스트 시스템:
메인보드: Asus Proart Z890
CPU: Intel 270K plus
RAM: 96GB DDR5 (6000MHZ)
GPU: RTX 6000 Pro Blackwell 96GB (Max-Q, ECC 활성화)

소프트웨어:
OS: 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 스크립트를 수정된 채팅 템플릿(chat template)으로 교체함

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
주요 성능 요약 (Key Performance Takeaways)

NVFP4가 토큰 생성 속도에서 압도적임 (~BF16보다 약 2.6배 빠름): 토큰 디코딩 (Decoding)은 엄격하게 메모리 대역폭 제한 (Memory-bandwidth bound)을 받기 때문에, 가중치 (Weights)를 4비트로 압축하면 PCIe/VRAM 데이터 전송을 획기적으로 줄일 수 있습니다. 이를 통해 생성 처리량 (Generation throughput)이 ~61 t/s (BF16)에서 최대 ~163 t/s (NVFP4)까지 급증합니다.
FP8은 프롬프트 처리 및 프리필 (Prefill) 속도에서 우세함 (~BF16보다 약 20% 빠름): 프롬프트 프리필은 연산 제한 (Compute-bound, 대규모 행렬 연산) 영역입니다. FP8은 역양자화 (Dequantization) 오버헤드 없이 네이티브 Tensor Core 가속을 활용하여, 입력 단계 (Ingestion)에서 BF16과 NVFP4를 모두 앞섭니다.
NVFP4는 FP8 대비 약간의 프리필 페널티가 있음: NVFP4는 연산 집약적인 대규모 프리필 배치 (Prefill batches) 중에 가중치를 실시간으로 역양자화해야 하므로, 프롬프트 처리 속도에서 FP8보다 약 10–15% 뒤처지지만, 여전히 기준점인 BF16보다는 성능이 뛰어납니다.

1. 토큰 생성 속도 (Token Generation Speed, tg32 Throughput)
   높을수록 좋습니다. 증가하는 컨텍스트 깊이 (Context depths)에서 32개의 새로운 토큰을 생성할 때의 디코딩 속도를 측정합니다.

컨텍스트 깊이 Context Depth	BF16 (t/s)	FP8 (t/s)	NVFP4 (t/s)	속도 향상 (NVFP4 vs BF16)
Base (0k)	59.10 ± 1.67	97.49 ± 4.08	169.23 ± 9.02	2.86x
4k Context	63.01 ± 3.63	103.03 ± 4.46	157.90 ± 14.55	2.51x
8k Context	67.55 ± 2.70	96.88 ± 5.11	166.52 ± 9.93	2.47x
16k Context	64.57 ± 2.99	101.51 ± 7.11	171.12 ± 0.50	2.65x
32k Context	59.46 ± 3.68	100.48 ± 4.33	158.04 ± 16.51	2.66x
65k Context	61.55 ± 2.81	98.99 ± 5.06	159.91 ± 7.52	2.60x

2. 프롬프트 처리 속도 (Prompt Processing Speed, pp2048 Throughput)
   높을수록 좋습니다. 기존 컨텍스트 깊이에서 2048개의 프롬프트 토큰을 프리필할 때의 입력 (Ingestion) 속도를 측정합니다.

Context Depth BF16 (t/s) FP8 (t/s) NVFP4 (t/s) Speedup (FP8 vs BF16)

Base (0k) 4359.28 ± 66.84 4747.78 ± 9.40 4732.42 ± 17.77 1.09x
4k Context 1856.76 ± 9.93 2250.71 ± 0.84 2010.97 ± 3.54 1.21x
8k Context 2095.89 ± 6.85 2479.30 ± 16.20 2191.59 ± 2.93 1.18x
16k Context 1765.10 ± 13.83 2029.02 ± 13.96 1832.65 ± 3.78 1.15x
32k Context 1317.16 ± 21.52 1503.80 ± 6.42 1388.85 ± 8.14 1.14x
65k Context 880.40 ± 6.51 1058.40 ± 33.99 902.65 ± 3.01 1.20x

3. Full Context Prefill Latency (ctx_pp End-to-End TTFT)
   Lower is better. Measures total Time-To-First-Token (in milliseconds) required to ingest and evaluate the entire context window.

Context Depth BF16 (ms) FP8 (ms) NVFP4 (ms) FP8 Latency Reduction

4k Context 1023.29 ± 6.08 833.65 ± 14.57 927.45 ± 1.68 -18.5%
8k Context 1974.69 ± 1.80 1415.69 ± 11.07 1869.70 ± 4.42 -28.3%
16k Context 4122.54 ± 18.20 2926.47 ± 6.89 3927.95 ± 4.72 -29.0%
32k Context 9179.91 ± 58.16 6572.61 ± 8.87 8692.01 ± 30.53 -28.4%
65k Context 21760.57 ± 85.68 16425.60 ± 137.66 20613.26 ± 18.28 -24.5%

4. Standalone Peak & First-Token Metrics
   Measures peak recorded generation speed and baseline TTFT without context saturation.

Quantization Format Peak Generation Throughput (peak t/s) Baseline TTFT (pp2048 ttfr) Estimated 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

submitted by    /u/live4evrr  

[link] [comments]