NVIDIA Blackwell 전용 추론 엔진 NVFP4를 활용한 vLLM 로컬 모델 서빙

먼저 30초 요약 (비전공자용)

1. NVFP4는 모델을 더 작고 빠르게 돌리기 위한 숫자 표현 방식입니다.

2. 단순 4비트로 줄이면 품질이 떨어지기 쉬운데, NVFP4는 스케일 보정을 넣어 정확도 하락을 줄입니다.

3. 그래서 Blackwell GPU + vLLM 조합에서는 큰 모델을 로컬에서 현실적으로 운영하기 쉬워집니다.

들어가며: Plaid Labs가 이걸 왜 파고들었나

Plaid Labs는 조직 내 다양한 컨텍스트를 주기적으로 통합하고, Slack 챗봇으로 반복 업무를 자동화하고 있습니다. 이때 중요한 건 "모델이 똑똑하냐"만이 아니라, 응답이 빠르고, 장애 없이, 비용 효율적으로 운영되느냐입니다.

이번 글은 그 관점에서 NVFP4가 왜 중요한지, 그리고 실제로 vLLM 로컬 서빙에서 어떻게 써먹는지를 쉬운 설명부터 차근히 정리한 기록입니다.

0. 용어를 아주 쉽게 먼저 정리

1. NVFP4를 진짜 쉽게 이해해보기

1-1. 비유로 이해: 작은 컵으로 정확히 계량하기

FP4를 쓰는 건 큰 계량컵 대신 아주 작은 컵으로 요리하는 것과 비슷합니다. 재료를 많이 빨리 담을 수 있지만, 자칫하면 오차가 커집니다.

NVFP4는 여기서 한 가지를 더 합니다. 구간별 보정값(스케일)을 둬서 "이 구간은 조금 더 촘촘하게" 맞추는 방식입니다. 즉, 작은 컵을 쓰되 중간중간 눈금을 더 똑똑하게 적용하는 셈입니다.

1-2. 왜 4비트가 매력적인가

모델 메모리 관점에서 아주 단순하게 보면:

FP16: 값 하나 = 16비트
FP4:  값 하나 = 4비트

이론적으로만 보면 4배까지 줄어듭니다. 실제 NVFP4는 스케일 정보가 붙어서 오버헤드가 조금 있지만, 그래도 큰 폭으로 줄어듭니다.

1-2a. 초간단 VRAM 계산법 (감잡기 용)

실무에서 가장 자주 쓰는 빠른 계산은 아래 한 줄입니다.

VRAM(GB, 가중치만) ≈ 파라미터 수(B) × 정밀도(bit) / 8

10B 모델 기준 감잡기:

• FP16: 10 × 16 / 8 = 20GB

• FP8: 10 × 8 / 8 = 10GB

• FP4: 10 × 4 / 8 = 5GB

단, 이 값은 가중치만 계산한 값입니다. 실제 서빙에서는 KV Cache, 런타임 버퍼, 프레임워크 오버헤드, 안전 여유 VRAM이 추가로 필요합니다.

즉 실제 필요 VRAM은 대략 가중치 + KV Cache + 런타임/버퍼 + 여유분으로 보시면 됩니다. 정확 계산은 APXML VRAM Calculator를 권장합니다: https://apxml.com/tools/vram-calculator

1-3. NVFP4의 핵심 구조 (조금 기술적으로)

NVFP4는 값 자체를 FP4(E2M1)로 저장하고, 여기에 두 단계 스케일을 씁니다.

• 블록 스케일: 16개 값 묶음마다 FP8(E4M3) 스케일 1개

• 텐서 스케일: 텐서 전체에 FP32 스케일 1개

복원값 ≈ (4비트 값) × (16개 블록 스케일) × (텐서 전체 스케일)

이 설계가 중요한 이유는, 4비트의 한계를 스케일링으로 보완하기 때문입니다.

1-4. FP4 / MXFP4 / NVFP4 차이

1-5. 숫자로 보는 오버헤드 (쉽게)

NVFP4는 16개 값마다 스케일 1개를 더 저장합니다.

16개 값 × 4비트 = 64비트
+ 스케일 8비트 = 72비트
=> 값 1개당 72/16 = 4.5비트 (+ 텐서당 FP32 스케일 1개)

즉 "완전한 4비트"는 아니지만, 여전히 FP16/FP8 대비 메모리 이점이 매우 큽니다.

1-6. 정확도는 괜찮은가?

NVIDIA가 공개한 비교에서는 FP8 대비 NVFP4가 주요 벤치마크에서 큰 차이 없이 유지되는 사례가 제시됩니다. 즉, 잘 만든 NVFP4 양자화 모델은 실사용에서 충분히 유의미한 품질을 보여줄 수 있습니다.

2. 왜 우리 환경에서는 vLLM이 맞았나

환경:

• CPU: Ultra 9 285K

• RAM: DDR5 256GB

• GPU: RTX PRO 6000 Blackwell WS 2장 (총 192GB VRAM)

llama.cpp/Ollama도 장점이 분명하지만, Plaid Labs처럼 "큰 모델을 API 서버로 안정 운영"하는 목적에서는 vLLM이 제어 옵션이 가장 풍부했습니다.

3. 실제 삽질 포인트 (초보자도 이해되게)

초기 설정:

--model RedHatAI/Qwen3-235B-A22B-Instruct-2507-NVFP4
--served-model-name plaidlabs
--gpu-memory-utilization 0.80
--max-model-len 65536
--enable-auto-tool-choice
--tool-call-parser hermes
--max-num-seqs 5
--tensor-parallel-size 2
--disable-custom-all-reduce

1. max-model-len 65536의 함정: 컨텍스트를 크게 잡으면 "좋아 보이지만", 실제로는 KV 캐시가 커져 속도와 동시성이 떨어질 수 있습니다.

2. 도구 호출 파서: Qwen 계열은 공식 문서 기준 Hermes 스타일을 맞춰주는 게 안정적입니다. parser가 어긋나면 tool call 파싱 실패가 늘어납니다.

3. 메모리 비율: 0.80은 안전하지만 보수적입니다. 안정성 테스트 후 0.90 전후로 올리면 처리량 개선 여지가 큽니다.

4. 바로 써볼 수 있는 권장 시작값

services:
  vllm:
    image: vllm/vllm-openai:nightly
    container_name: vllm-server
    ipc: host
    restart: always
    environment:
      - CUDA_VISIBLE_DEVICES=0,1
      - NCCL_DEBUG=warn
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              device_ids: ['0', '1']
              capabilities: [gpu]
    volumes:
      - ~/.cache/huggingface:/root/.cache/huggingface
      - /dev/shm:/dev/shm
    ports:
      - "8000:8000"
    command: >
      --model RedHatAI/Qwen3-235B-A22B-Instruct-2507-NVFP4
      --served-model-name plaidlabs
      --tensor-parallel-size 2
      --gpu-memory-utilization 0.90
      --max-model-len 32768
      --max-num-seqs 8
      --max-num-batched-tokens 24576
      --enable-prefix-caching
      --enable-chunked-prefill
      --enable-auto-tool-choice
      --tool-call-parser hermes

튜닝은 다음 순서가 가장 덜 헷갈립니다.

1. max-model-len 먼저 고정 (예: 32k)

2. max-num-seqs, max-num-batched-tokens를 단계적으로 상향

3. OOM 직전보다 10~15% 여유를 운영값으로 선택

5. 진짜 운영할 때 체크리스트

5-1. 스모크 테스트

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "plaidlabs",
    "messages": [
      {"role": "system", "content": "You are a concise assistant."},
      {"role": "user", "content": "Plaid Labs용 주간 운영 리포트 템플릿을 5줄로 작성해줘."}
    ],
    "temperature": 0.2,
    "max_tokens": 300
  }'

5-2. 꼭 수집할 지표

• TTFT(Time To First Token)

• tokens/sec

• p95/p99 latency

• OOM, 재시작 횟수

Grafana 연동 시에는 vLLM Prometheus 메트릭을 붙여 vllm-master-v2, vllm-monitoring-v2 대시보드로 모니터링하면 운영 상태를 빠르게 파악할 수 있습니다.

6. 결론

이번 경험의 결론은 명확했습니다. NVFP4는 "무작정 4비트"가 아니라, 정확도를 지키기 위한 보정 구조까지 포함한 실전 포맷입니다. Blackwell + vLLM 환경에서는 이 장점이 특히 크게 드러났고, Plaid Labs의 자동화 워크로드에도 잘 맞았습니다.

참고 자료

• NVIDIA: Introducing NVFP4 for Efficient and Accurate Low-Precision Inference

• NVIDIA Transformer Engine: NVFP4BlockScaling

• Pretraining Large Language Models with NVFP4 (arXiv:2509.25149)

• RedHatAI/Qwen3-235B-A22B-Instruct-2507-NVFP4

• Qwen Function Calling (vLLM)

• vLLM Tool Calling

• vLLM GitHub

• vLLM Prometheus/Grafana 예시

• llama.cpp GitHub

• Ollama GitHub

• APXML VRAM Calculator