FP4 양자화 + Blackwell GPU: H100 대비 4배 처리량이 가능한 조건과 쓰면 안 되는 상황

`RTX 5090 / B200 / vLLM FP4 / llm-compressor 적용 결과*

RTX 5090을 처음 만졌을 때 솔직히 "그냥 또 새 GPU 아닌가?" 싶었습니다. 그런데 FP4 양자화 수치를 보고 나서 생각이 바뀌었습니다. MLPerf v5.0 공식 벤치마크에서 단일 B200이 Llama 2 70B 추론으로 초당 10,755 토큰을 뽑아냈고, DGX B200 8-GPU 시스템은 DGX H200 대비 3.1배 처리량을 기록했습니다. 마케팅 숫자가 아니라 공인 벤치마크 수치라는 게 포인트입니다. 그리고 바로 이 시점에서 "그럼 내 모델에도 해당되는 이야기일까?"라는 의문이 생겼고, 저도 직접 코드를 돌려가며 확인해봤습니다.

이 글에서 다루는 내용은 다음 세 가지입니다:

• FP4가 왜 지금 시점에 의미 있는 기술인지, Blackwell 아키텍처와 어떻게 맞물리는지
• 실제 코드로 검증하는 세 가지 시나리오 — LLM 서빙, MoE 모델, 이미지 생성
• 어떤 상황에서는 FP4를 쓰면 안 되는지 — 태스크별 정확도 손실 수치와 대응 방안

"양자화는 정확도 손실이 있으니 조심해야 한다"는 막연한 경고 말고, 실제로 어느 태스크에서 얼마만큼 손실이 나타나는지까지 다룹니다. FP4는 Blackwell GPU와 맞물렸을 때만 의미가 있고, 그 조건과 예외를 정확히 아는 것이 이 기술을 실제로 활용하는 첫걸음입니다. GPU 서버 비용이 부담스러운 팀이라면 끝까지 읽어보시면 좋겠습니다.

핵심 개념

FP4가 INT4와 다른 이유: 비선형 표현이 LLM 가중치 분포에 유리한 이유

저도 처음엔 "4비트끼리 뭐가 다르냐"고 생각했습니다. 결론부터 말하면 표현 방식 자체가 다릅니다. INT4는 -8~7 사이의 정수 격자점만 표현합니다. 반면 NVFP4는 지수부를 가진 부동소수점이라 비선형 간격으로 값을 표현합니다. 이게 왜 중요하냐면, LLM 가중치 분포에는 대부분의 값이 0 근처에 몰려 있고 드물게 튀는 극단값(outlier)이 섞여 있거든요. INT4는 이 극단값 때문에 스케일을 넓게 잡으면 0 근처 값들의 정밀도가 떨어지는 딜레마가 생기는데, FP4는 비선형 간격 덕분에 이 문제를 일정 부분 완화합니다.

NVFP4 내부 구조를 간단히 정리하면:

표를 보면 자연스럽게 두 가지 의문이 생깁니다.

왜 FP32가 아닌 FP16으로 누산하나요? FP4 연산 결과는 이미 값의 범위가 제한되어 있어 FP32 누산기는 과잉입니다. FP16으로 누산하면 메모리 대역폭을 절반으로 줄이면서도 LLM 추론 정밀도에 충분합니다. 정밀도보다 대역폭 절감을 택한 설계 선택입니다.

왜 메모리 비율이 0.25×가 아닌 0.29×인가요? 단순 비트 비율(4/16)이면 0.25×가 맞지만, NVFP4는 블록 스케일 오버헤드가 있습니다. 값 16개(64비트) + FP8 스케일 1개(8비트) = 72비트. 같은 16개를 FP16으로 저장하면 256비트. 따라서 72÷256 ≈ 0.28×, 반올림하면 0.29×가 됩니다. INT4는 이 스케일 오버헤드가 없어 0.25×를 달성하지만, 그만큼 정밀도 제어를 포기한 것입니다.

참고로 MXFP4(Microsoft/Intel이 주도하는 포맷)는 블록 크기를 32로 잡아 오버헤드를 줄이는 방향을 선택했습니다. NVFP4의 블록 16 vs MXFP4의 블록 32는 정밀도 vs 압축 효율의 트레이드오프를 반영한 설계 차이입니다. NVIDIA GPU를 쓴다면 NVFP4, 크로스 플랫폼을 고려한다면 MXFP4 표준화 동향도 함께 지켜볼 필요가 있습니다.

용어: PTQ (Post-Training Quantization) — 학습이 끝난 모델을 재학습 없이 양자화하는 기법. 빠르게 적용 가능하지만 교정 데이터셋(calibration dataset)이 필요하며, 양자화 인식 학습(QAT)보다 정확도가 낮을 수 있습니다.

W4A4: 왜 처리량이 4배 뛰는가

FP4가 단순히 가중치만 압축하는 게 아니라는 점이 중요합니다. W4A4는 가중치(Weights)와 활성화(Activations)를 둘 다 FP4로 줄이는 방식입니다. 가중치만 압축하는 W4A16이나 W4A8과 비교하면, W4A4는 메모리 대역폭과 연산량을 동시에 줄이기 때문에 처리량 향상이 훨씬 큽니다. Blackwell의 5세대 Tensor Core가 FP4 연산을 네이티브로 처리한다는 게 이 조합의 전제 조건입니다.

핵심: FP4의 속도 이점은 Blackwell 이전 GPU에서는 나타나지 않습니다. Hopper(H100)나 Ampere에서는 소프트웨어 에뮬레이션으로 처리되어 속도 이점이 사라지거나 오히려 느려집니다. GPU 아키텍처 확인을 먼저 하는 것이 순서입니다.

정밀도 포맷 한눈에 비교

이 표에서 실무상 가장 중요한 행은 마지막 두 줄입니다. NVFP4는 0.29×로 INT4보다 조금 덜 압축되지만, Blackwell에서 네이티브로 실행된다는 점이 결정적 차이입니다. 이 아키텍처 차이가 이어질 코드 예시들의 전제입니다.

실전 적용

예시 1: LLM 양자화 — llm-compressor + vLLM으로 Llama 3 FP4 서빙

vLLM 생태계를 쓰고 있다면 llm-compressor로 W4A4 FP4 양자화 파이프라인을 구성할 수 있습니다. 교정 데이터셋만 준비되면 생각보다 코드가 간단합니다. 처음 해봤을 때 "이게 다야?" 싶었을 만큼 보일러플레이트가 적습니다.

from llmcompressor import oneshot
from llmcompressor.modifiers.quantization import QuantizationModifier
 
# 교정 데이터셋 준비 (512개 샘플 권장)
recipe = QuantizationModifier(
    targets="Linear",
    scheme="NVFP4",          # W4A4 FP4 적용
    ignore=["lm_head"],      # 출력 레이어는 FP16 유지
)
 
oneshot(
    model="meta-llama/Llama-3-8B-Instruct",
    dataset="open_platypus",
    recipe=recipe,
    num_calibration_samples=512,
    output_dir="./llama3-nvfp4",
)

# FP4 지원 버전 설치 (2025년 5월 기준)
pip install "llmcompressor>=0.3.0" "vllm>=0.4.2"
 
# 양자화된 모델로 vLLM 서빙
vllm serve ./llama3-nvfp4 \
  --quantization nvfp4 \
  --dtype float16
  # RTX 5090 기준 약 2,400 tok/s (FP16 대비 약 2.8× 향상)

버전 주의: NVFP4 지원은 특정 버전 이후부터 안정적으로 동작합니다. pip install llmcompressor로 설치 후 FP4 관련 에러가 난다면 버전 충돌을 먼저 의심해보는 것이 좋습니다.

예시 2: MoE 모델 선택적 양자화 — NVIDIA ModelOpt

LLM 양자화를 해봤다면 자연스럽게 Mixtral이나 DeepSeek-V3 같은 MoE 모델에도 적용하고 싶어집니다. 그런데 이 부분에서 저도 처음에 실수를 했습니다. 모든 레이어를 일괄 FP4로 밀었다가 라우팅이 이상해지는 케이스를 겪었거든요.

MoE 모델의 라우팅 레이어는 어느 전문가(expert)에게 토큰을 보낼지 결정하는 핵심 컴포넌트입니다. 이 레이어에 FP4를 적용하면 라우팅 결정 자체가 흔들려 전체 출력 품질이 떨어집니다. ModelOpt의 nvfp4_experts_only 설정이 이 문제를 우회하는 방법입니다.

import modelopt.torch.quantization as mtq
from torch.utils.data import DataLoader
 
# forward_loop: 모델에 교정 데이터를 통과시켜 값 통계를 수집하는 함수
# 양자화 스케일을 결정하는 데 사용됩니다
def forward_loop(model):
    for batch in calibration_dataloader:  # 사전에 준비한 DataLoader
        model(**batch)
 
# MoE 전문가 레이어만 NVFP4, 나머지는 FP8 유지
quant_config = {
    "quant_cfg": {
        "*experts*": {"num_bits": (4, 3), "axis": None},  # NVFP4
        "*": {"num_bits": (8, 7), "axis": None},           # FP8
    }
}
 
# 사전 정의된 설정 사용 (권장)
model = mtq.quantize(model, mtq.NVFP4_EXPERTS_ONLY_CFG, forward_loop)
mtq.print_quant_summary(model)  # 레이어별 양자화 결과 확인

pip install "nvidia-modelopt[torch]>=0.17.0"

nvfp4_experts_only는 전문가 레이어만 FP4, 어텐션과 비전문가 레이어는 FP8로 유지합니다. 메모리 절감과 정확도 사이의 균형점을 실무적으로 잘 잡은 설정이라고 생각합니다.

예시 3: 이미지 생성 — TorchAO + NVFP4로 FLUX 모델 최적화

이 예시에서는 한 가지 중요한 선택에 대해 먼저 설명이 필요합니다. 왜 앞서 설명한 W4A4가 아닌 W4A16(가중치만 FP4)을 쓰는가? 현재 diffusion 모델은 활성화 양자화(A4)를 아직 완전히 지원하지 않습니다. Transformer 기반 diffusion 아키텍처는 활성화 패턴이 LLM과 달라 A4 적용 시 이미지 품질 저하가 심하고, 이를 안정화하는 런타임 지원도 아직 성숙하지 않았습니다. 그래서 이 시나리오에서는 W4A16, 즉 가중치만 FP4로 내립니다.

SVDQuant는 MIT HAN Lab에서 개발한 기법으로, 가중치의 outlier 성분을 특이값 분해(SVD)로 저랭크 행렬에 흡수시킨 뒤 FP4를 적용합니다. outlier가 저랭크 행렬로 빠져나가면 남은 가중치의 값 범위가 좁아지고, 그래야 FP4의 좁은 표현 범위로도 커버가 가능해집니다. 이 결과 FLUX.1-dev에서 PSNR 21.5를 달성했습니다. PSNR 20 이상은 일반적으로 육안으로 수용 가능한 품질 기준이고, 21.5는 원본 16비트 모델과 대부분의 용도에서 구분하기 어려운 수준입니다.

from torchao.quantization import quantize_, nvfp4_weight_only
from diffusers import FluxPipeline
import torch
 
pipe = FluxPipeline.from_pretrained(
    "black-forest-labs/FLUX.1-dev",
    torch_dtype=torch.bfloat16,
)
 
# W4A16: 가중치만 NVFP4 적용 (활성화는 bfloat16 유지)
quantize_(pipe.transformer, nvfp4_weight_only())
pipe.to("cuda")
 
image = pipe(
    "a photo of a cat sitting on a GPU",
    num_inference_steps=20,
).images[0]
image.save("output.png")
# RTX 5090 기준 FP8 대비 약 3× 속도 향상, 메모리 4× 절감

pip install "torch>=2.5" "torchao>=0.6.0" diffusers transformers

주의: I2V(Image-to-Video) 태스크에서는 FP4 정밀도가 참조 이미지의 세부 특징을 유지하기에 부족해 품질이 실용 기준 미달로 떨어질 수 있습니다. T2V(Text-to-Video)에서는 상대적으로 양호하지만, I2V는 FP8 이상을 유지하는 것을 권장합니다.

장단점 분석

수치와 코드를 충분히 봤으니, 이제 실무에서 가장 중요한 질문으로 돌아옵니다. "우리 팀에 FP4가 맞는가?"를 판단하는 데 아래 표가 도움이 될 것입니다.

장점

단점 및 주의사항

이 중에서 실무에서 가장 자주 마주치는 항목은 단연 '하드웨어 잠금'입니다. RTX 4090을 쓰는 팀이 FP4를 시도했다가 오히려 느려지는 경우가 있는데, 정확히 이 이유 때문입니다.

용어: AWQ (Activation-aware Weight Quantization) — 활성화 분포를 고려해 가중치의 중요 채널은 높은 정밀도로 유지하는 INT4 양자화 기법입니다. Blackwell이 없는 환경이나 VRAM이 극도로 제한된 경우에도 동작하며, Transformers/llama.cpp 생태계에서 광범위하게 지원됩니다.

용어: MXFP4 — Microsoft와 Intel이 주도하는 MX(Microscaling) 포맷의 FP4 버전입니다. NVFP4와 블록 스케일링 방식이 달라(블록 크기 32 vs 16) 상호 호환되지 않습니다.

실무에서 가장 흔한 실수

1. Hopper GPU(H100)에서 NVFP4를 시도하는 경우 — 소프트웨어 에뮬레이션으로 처리되어 FP8보다 오히려 느려집니다. torch.cuda.get_device_capability()로 확인했을 때 Blackwell은 (10, 0), **Hopper(H100)는 (9, 0)**을 반환합니다. (10, 0) 이상이어야 FP4 네이티브 실행이 가능합니다.

2. 교정 데이터셋을 무작위 샘플로 구성하는 경우 — 실제 서비스에서 들어오는 쿼리 분포와 다른 데이터로 교정하면 운영 환경에서 예상치 못한 정확도 하락이 나타납니다. 가능하면 실제 로그 기반 샘플을 활용하는 것이 좋습니다.

3. 모든 레이어를 일괄 FP4로 적용하는 경우 — 어텐션 레이어나 MoE 라우팅 레이어처럼 민감한 부분은 FP8로 남겨두는 혼합 정밀도 전략이 정확도 손실을 크게 줄여줍니다. ModelOpt의 AutoQuantize나 nvfp4_experts_only 설정을 활용하면 됩니다.

마치며

FP4는 Blackwell GPU와 함께라면 "실험적 기술"을 넘어 프로덕션에서 진지하게 검토할 수 있는 수준에 도달했습니다. 다만 GPU 아키텍처, 태스크 특성, 정확도 요구 수준을 먼저 점검하는 게 순서입니다. 아래 판단 흐름이 도움이 될 것입니다:

Blackwell GPU (RTX 50, B100/B200) + 추론 최적화  → NVFP4 적극 검토
Hopper / Ampere GPU                               → FP8 우선
코드 생성·수학 추론·I2V 태스크                    → 민감 레이어 FP8 유지 또는 혼합 정밀도
VRAM 극도 제한 환경 (Blackwell 없음)              → AWQ INT4 고려

지금 바로 시작할 수 있는 3단계:

1. GPU 컴퓨트 캐퍼빌리티 확인이 먼저입니다 — python -c "import torch; print(torch.cuda.get_device_capability())" 명령으로 확인할 수 있습니다. (10, 0) 이상이면 Blackwell이고 FP4 네이티브 실행이 가능합니다. (9, 0)이면 Hopper(H100)이니 FP8을 선택하는 쪽이 낫습니다.

2. Hugging Face의 사전 양자화 모델로 속도를 먼저 체감 — nvidia/ 네임스페이스에서 Llama 3 NVFP4 체크포인트를 내려받아 vLLM으로 서빙해보면, 직접 양자화 작업 없이 처리량 차이를 바로 확인할 수 있습니다.

3. 직접 양자화가 필요하다면 llm-compressor로 시작 — 위 예시 코드에서 모델 경로와 교정 데이터셋만 교체하면 됩니다. 교정 샘플 512개로도 첫 결과를 확인할 수 있습니다.

참고 자료

• Introducing NVFP4 for Efficient and Accurate Low-Precision Inference | NVIDIA Technical Blog
• Scaling NVFP4 Inference for FLUX.2 on NVIDIA Blackwell Data Center GPUs | NVIDIA Technical Blog
• NVIDIA TensorRT Unlocks FP4 Image Generation for Blackwell GeForce RTX 50 Series | NVIDIA Technical Blog
• FP4 Quantization on Blackwell GPUs: Throughput, Cost, and When It's Worth It | Spheron Blog
• Nvidia publishes first Blackwell B200 MLPerf results: Up to 4X faster than H100 using FP4 | Tom's Hardware
• fp4 Quantization with NVFP4 - LLM Compressor Docs | vLLM
• NVFP4 Quantization | DGX Spark | NVIDIA Build
• Faster Diffusion on Blackwell: MXFP8 and NVFP4 with Diffusers and TorchAO | PyTorch Blog
• SVDQuant Meets NVFP4: 4× Smaller and 3× Faster FLUX | MIT HAN Lab
• Testing NVFP4 Quantization on RTX 5090: Quality Gap Between T2V and I2V | Zenn
• FP4 All the Way: Fully Quantized Training of LLMs | arXiv
• Microbenchmarking NVIDIA's Blackwell Architecture | arXiv
• NVIDIA Model Optimizer GitHub Repository
• FP4 vs FP8 vs FP16 for LLM Inference: Which Precision Should You Use? | VRLA Tech
• Diagnosing FP4 inference: layer-wise and block-wise sensitivity analysis | arXiv