r/LocalLLaMA•5개월 전•69•48
Blackwell 아키텍처에서 llama.cpp의 네이티브 NVFP4 지원 벤치마크 결과 요약
llama.cpp benchmark native vs. non native NVFP4 on Blackwell - summary
핵심 요약
llama.cpp의 네이티브 NVFP4 지원이 프롬프트 처리 속도를 최대 1.7배 향상시키지만, 토큰 생성 속도에는 영향이 없음.
- 프롬프트 처리 성능 — 네이티브 NVFP4 적용 시 prefill 속도가 43~68% 대폭 향상됨.
- 토큰 생성 속도 — 네이티브 NVFP4 적용 전후로 생성 속도 변화가 거의 없음.
- 하드웨어 최적화 — Blackwell 아키텍처(RTX 5090 등)에서 NVFP4 모델 사용 시 효과적임.
- 실제 활용성 — 긴 문맥 처리나 RAG 작업 시 응답 대기 시간이 크게 단축됨.
동일한 Qwen3.6-27B-NVFP4 모델을 사용하여 두 가지 llama.cpp 빌드를 테스트했습니다.
llama-bench는 모델 라벨을 qwen35 27B NVFP4로 보고하지만, 실제 테스트한 모델은 Qwen3.6-27B-NVFP4입니다.
테스트 플랫폼
- GPU: NVIDIA GeForce RTX 5090
- CPU: AMD Ryzen 9 9950X3D
- RAM: 128 GB DDR5 5600 CL36
- 백엔드: CUDA
테스트한 빌드
- b8966 — 네이티브 NVFP4 지원이 없는 마지막 빌드
- b8967 — 네이티브 NVFP4 지원이 포함된 빌드 (네이티브 NVFP4를 지원하는 첫 빌드)
두 실행 모두 동일한 모델과 설정을 사용했습니다: Qwen3.6-27B-NVFP4, 17.50 GiB, 26.90B 파라미터, CUDA 백엔드, ngl=999, fa=1.
주요 결론
b8967의 네이티브 NVFP4 지원은 프롬프트 처리 / 프롬프트 입력 성능을 크게 향상시키지만, 토큰 생성 속도에는 의미 있는 변화를 주지 않습니다.
실질적으로는:
- 프롬프트 처리가 네이티브 NVFP4 사용 시 약 43~68% 더 빠름,
- 평균 프롬프트 처리 향상 폭은 대략 57%,
- 토큰 생성 속도는 사실상 변화 없음,
- 긴 프롬프트, 대규모 컨텍스트, RAG 워크로드, 문서 분석, 코드 위주의 프롬프트에서 가장 큰 이점을 볼 수 있음,
- 일반적인 채팅 생성 속도는 생성이 시작되면 거의 동일하게 느껴짐.
프롬프트 처리 결과
|테스트|b8966 — 네이티브 NVFP4 없음|b8967 — 네이티브 NVFP4 있음|향상률|
|:-|:-|:-|:-|
|`pp512`|3295.10 t/s|5546.93 t/s|**+68.3%**|
|`pp2048`|3373.30 t/s|5594.58 t/s|**+65.8%**|
|`pp512 @ d4096`|3265.74 t/s|5232.92 t/s|**+60.2%**|
|`pp2048 @ d4096`|3231.69 t/s|5272.82 t/s|**+63.2%**|
|`pp512 @ d8192`|3152.71 t/s|4995.34 t/s|**+58.4%**|
|`pp2048 @ d8192`|3117.80 t/s|5005.44 t/s|**+60.5%**|
|`pp512 @ d16384`|2965.81 t/s|4537.54 t/s|**+53.0%**|
|`pp2048 @ d16384`|2934.26 t/s|4547.25 t/s|**+55.0%**|
|`pp512 @ d32768`|2514.70 t/s|3586.58 t/s|**+42.6%**|
|`pp2048 @ d32768`|2479.39 t/s|3560.58 t/s|**+43.6%**|
네이티브 NVFP4 빌드는 프리필(prefill) 과정에서 일관되게 훨씬 빠릅니다. 가장 큰 이득은 짧거나 중간 정도의 컨텍스트 크기에서 나타나며, b8967이 b8966보다 약 1.6~1.7배 더 빠릅니다. d32768과 같은 매우 긴 컨텍스트에서는 이점이 줄어들지만, 여전히 약 는 상당한 이점을 보입니다.
