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

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

1. NVFP4는 4비트 기반 저정밀 포맷이지만, 보정 스케일을 함께 써서 정확도 손실을 줄이는 방식입니다.

2. Blackwell GPU에서는 이런 저정밀 연산 최적화가 강해, 큰 모델을 더 현실적인 비용/지연시간으로 서빙할 수 있습니다.

3. Plaid Labs처럼 내부 자동화/챗봇 워크로드를 로컬에서 안정 운영하려면, 현재 조합에서는 vLLM이 가장 운영 친화적이었습니다.

들어가며: 왜 이 삽질을 했나

Plaid Labs는 조직 컨텍스트를 주기적으로 통합하고, 다양한 보조 작업을 Slack 챗봇으로 자동화하고 있습니다. 이때 중요한 건 단순 모델 성능이 아니라 지연시간, 안정성, 운영 편의성, 비용입니다.

그래서 로컬 환경(듀얼 Blackwell)에서 "진짜 운영 가능한" 구성을 찾는 과정에서 NVFP4 + vLLM 조합을 집중 검토했습니다. 이 글은 그 과정을 지식이 낮은 분도 이해할 수 있게 정리한 실전 기록입니다.

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

1. NVFP4가 뭔지, 정말 쉽게 + 기술적으로

1-1. 비유로 이해: 작은 컵 + 보정 눈금

FP4는 큰 계량컵 대신 작은 컵을 쓰는 것과 비슷합니다. 공간은 아끼지만 오차가 커질 수 있습니다.

NVFP4는 여기서 한 걸음 더 가서 보정 눈금(스케일)을 함께 둡니다. 즉, 작은 컵으로 담되 구간마다 보정해서 품질 저하를 줄이는 접근입니다.

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

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

이론적으로 값 저장량은 FP16 대비 FP8은 절반, FP4는 1/4 수준까지 줄어듭니다. 메모리 절감은 곧 더 큰 모델 탑재, 더 높은 동시성, 더 낮은 비용으로 이어집니다.

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이 추가됩니다.

정확 계산은 APXML VRAM Calculator를 권장합니다: https://apxml.com/tools/vram-calculator

1-3. NVFP4의 핵심 구조 (기술 버전)

NVFP4는 값 포맷(E2M1) 자체는 4비트이지만, 스케일을 2단계로 둡니다.

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

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

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

즉, 단순 4비트 절삭이 아니라 "정확도를 지키기 위한 보정 구조"까지 포함한 포맷입니다.

1-4. 오버헤드까지 포함하면?

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

완전한 4.0비트는 아니지만, 여전히 FP8/FP16 대비 큰 메모리 이점이 있습니다.

2. llama.cpp vs Ollama vs vLLM: 우리 목적에서의 현실 비교

3. Plaid Labs 환경에서 왜 vLLM이 맞았나

• CPU: Intel Ultra 9 285K

• RAM: DDR5 256GB

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

우리 워크로드는 "여러 서비스/Slack bot이 동시에 API를 때리는 형태"이기 때문에, 단발 테스트보다 동시성, 안정성, 운영지표 관리가 더 중요했습니다. 이 관점에서는 vLLM이 가장 실용적이었습니다.

4. 실제 적용 가이드 (듀얼 Blackwell + vLLM)

초기 설정은 아래처럼 시작하고, 이후에 단계적으로 조정하는 방식을 추천합니다.

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. 운영 모니터링: 이건 꼭 붙이자

성능 튜닝은 체감이 아니라 지표로 해야 합니다. 최소한 아래는 계속 보세요.

• TTFT(Time To First Token)

• tokens/sec

• p95/p99 latency

• OOM 횟수, 재시작 횟수

Grafana에서는 vLLM 메트릭을 Prometheus에 연결한 뒤 vllm-master-v2, vllm-monitoring-v2 대시보드로 운영 상태를 보는 구성이 실무에서 유용했습니다.

6. 자주 겪는 함정

1. max-model-len을 과도하게 크게 시작: KV cache가 급증해 동시성과 지연시간이 악화됩니다.

2. 메모리 사용률을 너무 보수적으로 고정: 안정성은 좋지만 처리량 손해가 큽니다. 점진적으로 상향 검증이 필요합니다.

3. 모니터링 없이 체감 튜닝: 동일 시간대/동일 부하 비교 없이 설정을 바꾸면 잘못된 결론이 나기 쉽습니다.

7. 결론

NVFP4의 핵심은 "그냥 4비트"가 아니라, 정확도를 지키기 위한 보정 메커니즘이 포함된 실전 저정밀 포맷이라는 점입니다. Blackwell + vLLM 조합에서는 이 장점이 실제 운영 성능/비용 개선으로 이어질 가능성이 높습니다.

Plaid Labs처럼 여러 내부 자동화/챗봇을 안정적으로 돌려야 하는 조직이라면, vLLM 중심으로 운영 지표를 잡고 NVFP4 모델을 단계적으로 검증하는 접근이 가장 현실적입니다.

참고 자료

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

• NVIDIA Transformer Engine: NVFP4BlockScaling

• Pretraining Large Language Models with NVFP4 (arXiv)

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

• vLLM Tool Calling

• vLLM Prometheus/Grafana 예시

• APXML VRAM Calculator