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

NVFP4를 쉬운 비유와 실전 예시로 설명하고, Blackwell 듀얼 GPU에서 vLLM 로컬 서빙을 안정적으로 운영하는 방법을 정리한 가이드입니다.

Feb 07, 2026

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

Contents

먼저 30초 요약 들어가며: 왜 이 삽질을 했나 0. 용어를 아주 쉽게 먼저 정리 1. NVFP4가 뭔지, 정말 쉽게 + 기술적으로 1-1. 비유로 이해: 작은 컵 + 보정 눈금 1-2. 왜 4비트가 매력적인가 1-2a. 초간단 VRAM 계산법 (감잡기 용)1-3. NVFP4의 핵심 구조 (기술 버전)1-4. 오버헤드까지 포함하면?2. llama.cpp vs Ollama vs vLLM: 우리 목적에서의 현실 비교 3. Plaid Labs 환경에서 왜 vLLM이 맞았나 4. 실제 적용 가이드 (듀얼 Blackwell + vLLM)5. 운영 모니터링: 이건 꼭 붙이자 6. 자주 겪는 함정 7. 빠른 운영 체크리스트 8. 결론 참고 자료

먼저 30초 요약

NVFP4는 4비트 기반 저정밀 포맷이지만, 보정 스케일을 함께 써서 정확도 손실을 줄이는 방식입니다.
Blackwell GPU에서는 이런 저정밀 연산 최적화가 강해, 큰 모델을 더 현실적인 비용/지연시간으로 서빙할 수 있습니다.
Plaid Labs처럼 내부 자동화/챗봇 워크로드를 로컬에서 안정 운영하려면, 현재 조합에서는 vLLM이 가장 운영 친화적이었습니다.
개인용·소규모 팀이라면 NVIDIA 서버 대신 Apple Silicon + MLX 조합이 더 현실적입니다. Mac mini M4 Pro에서 MLX로 30B 모델 돌려본 기록에서 같은 문제를 개인용 시점으로 다뤘습니다.

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

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

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

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

용어	쉽게 말하면	왜 중요한가
FP16	숫자 1개를 16비트로 저장	정확도 기준점, 대신 메모리 사용량 큼
FP8	숫자 1개를 8비트로 저장	FP16 대비 메모리/속도 이점
FP4	숫자 1개를 4비트로 저장	매우 가볍지만 정확도 손실 위험 큼
NVFP4	FP4 + 2단계 스케일 보정	4비트 이점은 유지하면서 정확도 하락 완화
vLLM	LLM API 서버를 고처리량으로 운영하는 엔진	동시성/지연시간/운영옵션에서 실전성이 높음

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비트 절삭이 아니라 "정확도를 지키기 위한 보정 구조"까지 포함한 포맷입니다.

NVFP4 two-level scaling — NVFP4 2단계 스케일링 개념 (NVIDIA)

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

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

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

NVFP4 accuracy comparison — FP8 대비 NVFP4 정확도 비교 예시 (NVIDIA)

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

엔진	장점	아쉬운 점	추천 상황
llama.cpp	가볍고 빠른 실험, GGUF 생태계 강점	대규모 멀티 GPU API 운영에선 제어면이 제한적일 수 있음	온디바이스, 경량 추론, 빠른 검증
Ollama	초기 진입장벽이 가장 낮고 사용이 단순	고급 튜닝/세밀한 운영제어는 상대적으로 제한	개인 생산성, 소규모 내부도구, PoC
vLLM	고처리량, OpenAI API 호환, 배치/캐시/병렬 옵션 풍부	초기 러닝커브와 튜닝 학습이 필요	대형 모델 프로덕션 서빙, 팀 단위 운영

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

튜닝 순서는 아래가 가장 안전했습니다.

max-model-len을 먼저 현실값(예: 32k)으로 고정
max-num-seqs와 max-num-batched-tokens를 단계적으로 상향
OOM 직전보다 10~15% 낮은 값을 운영 기본값으로 채택

5. 운영 모니터링: 이건 꼭 붙이자

성능 튜닝은 체감이 아니라 지표로 해야 합니다. vLLM은 Prometheus 호환 메트릭을 /metrics 엔드포인트로 노출하기 때문에, 별도 에이전트 없이 Prometheus가 직접 스크랩할 수 있습니다. 운영 단계에서 항상 보고 있어야 하는 핵심 지표는 다음 7가지입니다.

지표	vLLM 메트릭	왜 봐야 하는가
TTFT (Time To First Token)	`vllm:time_to_first_token_seconds`	체감 응답성. p95가 1.5s를 넘어가면 prefill 단계 튜닝 필요
ITL (Inter-Token Latency)	`vllm:time_per_output_token_seconds`	스트리밍 안정성. 튀는 구간은 decode 경합 신호
처리량	`vllm:generation_tokens_total`	tok/s 추세. 동일 부하 대비 저하 시 KV cache 압박 의심
대기열 길이	`vllm:num_requests_waiting`	0보다 크면 캡 도달. max-num-seqs 조정 트리거
KV 캐시 사용률	`vllm:gpu_cache_usage_perc`	90% 지속 시 OOM 임박. max-model-len 또는 max-num-seqs 조절
GPU 활용률	`DCGM_FI_DEV_GPU_UTIL`	DCGM exporter 별도. 70% 미만 지속이면 동시성을 더 올릴 여지
p95/p99 응답시간	`vllm:e2e_request_latency_seconds`	SLO 지표. 알람 임계값을 이 위에 건다

Grafana 대시보드는 한 화면에 모든 걸 펴놓기보다 세 줄로 나누는 편이 운영 친화적입니다. 첫 줄은 응답성(TTFT/ITL), 두 번째 줄은 처리량과 대기열, 세 번째 줄은 GPU/메모리 자원 사용률. vLLM 공식 레포의 examples/online_serving/prometheus_grafana에 즉시 import 가능한 JSON 템플릿이 있어 출발점으로 쓰기 좋습니다.

알람은 처음부터 욕심내지 말고 두 개만 거세요. (1) num_requests_waiting > 0이 5분 지속, (2) p95 e2e latency가 SLO 1.5배 초과 5분 지속. 나머지는 대시보드에서 관찰하면서 추가합니다.

6. 자주 겪는 함정

max-model-len을 과도하게 크게 시작: KV cache가 급증해 동시성과 지연시간이 악화됩니다. 실제 워크로드의 p99 입력 길이 + 응답 토큰 여유 + 20% 정도로 시작해 점진적으로 늘리세요.
메모리 사용률을 너무 보수적으로 고정: 안정성은 좋지만 처리량 손해가 큽니다. gpu-memory-utilization을 0.85부터 시작해 OOM이 없으면 0.90, 0.92로 단계적으로 올리는 편이 안전합니다.
모니터링 없이 체감 튜닝: 동일 시간대/동일 부하 비교 없이 설정을 바꾸면 잘못된 결론이 나기 쉽습니다. 변경 전후 30분 윈도우의 p95 latency와 tok/s를 같은 대시보드에서 비교하세요.
tensor-parallel-size와 GPU 수 불일치: 듀얼 Blackwell이라면 --tensor-parallel-size 2가 기본 출발점입니다. 1로 두면 한 GPU만 쓰고, NCCL 환경변수(NCCL_DEBUG=warn, NCCL_P2P_DISABLE=0)를 같이 확인해야 합니다.
NVFP4 모델과 vLLM 버전 호환성: NVFP4는 비교적 새 포맷이라 vLLM nightly나 0.7+ 라인을 권장합니다. stable 태그에 고정해두면 모델 로딩 단계에서 quantization not supported로 떨어지는 경우가 있습니다.
KV cache eviction 정책 미설정: 장시간 세션이 섞여 들어오는 워크로드에서는 --enable-prefix-caching과 cache 크기 한도를 같이 잡지 않으면 캐시 hit율이 떨어집니다. 챗봇처럼 system prompt가 길고 반복되는 경우 prefix caching의 효과가 큽니다.
양자화 모델 정확도 회귀를 무시하기: NVFP4 변환본은 같은 모델의 FP16/FP8 대비 미세한 품질 회귀가 있을 수 있습니다. 발행 전에 자체 평가셋(최소 50개 케이스)으로 회귀 테스트를 돌려서 허용 범위 안인지 확인하세요.

7. 빠른 운영 체크리스트

실제 운영에 들어가기 전에 한 번 훑어볼 수 있는 체크리스트입니다. 듀얼 Blackwell + vLLM + NVFP4 조합 기준으로 정리했습니다.

모델 로딩이 --tensor-parallel-size 2로 두 GPU에 분산되는지 확인 (nvidia-smi에서 두 GPU 모두 점유 표시)
gpu-memory-utilization 초기값 0.85, OOM 없으면 단계적 상향
max-model-len은 실제 p99 컨텍스트 + 응답 여유로 시작 (무한히 크게 두지 말 것)
prefix caching 활성화 여부를 워크로드 특성(긴 system prompt 여부)에 맞춰 결정
Prometheus가 vLLM /metrics를 스크랩하고 있고, Grafana 대시보드가 떠 있음
알람 2개(대기열 누적, p95 latency 초과) 임계값 설정 완료
NVFP4 변환본의 품질 회귀 테스트 통과 (자체 평가셋 50+ 케이스)
Tool calling이 필요한 경우 --enable-auto-tool-choice와 모델별 tool parser 설정 확인
컨테이너 ipc: host, --shm-size 충분히 잡혀 있음 (멀티 GPU 통신 안정성)

8. 결론

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

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

반대로 개인이나 소규모 팀이 비슷한 워크로드를 풀려고 한다면 NVIDIA 서버 전체를 들이는 대신 Apple Silicon + MLX 조합이 더 현실적입니다. 같은 문제를 개인용 스케일에서 어떻게 풀었는지는 개인용 로컬 LLM 추론의 새 기준, MLX에서 같은 시리즈로 다뤘습니다.

참고 자료

Plaid Labs 기술 블로그 — 개인용 로컬 LLM 추론의 새 기준, MLX (개인용·소규모 팀 시점)
Plaid Labs 기술 블로그 — 오픈소스 LLM 생태계 2026: DeepSeek-V4·Qwen3.6·GLM-5.1 (모델 동향)
Plaid Labs 기술 블로그 — Speculative Decoding이란 무엇인가? (추론 가속 시리즈 4편)
Plaid Labs 기술 블로그 — LLM을 작게 만드는 여러가지 압축 기술들 (BitNet · AutoRound · TurboQuant · REAP)
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

Contents

AI Research

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

NVFP4를 쉬운 비유와 실전 예시로 설명하고, Blackwell 듀얼 GPU에서 vLLM 로컬 서빙을 안정적으로 운영하는 방법을 정리한 가이드입니다.

조태완

Feb 07, 2026

Contents

먼저 30초 요약

NVFP4는 4비트 기반 저정밀 포맷이지만, 보정 스케일을 함께 써서 정확도 손실을 줄이는 방식입니다.
Blackwell GPU에서는 이런 저정밀 연산 최적화가 강해, 큰 모델을 더 현실적인 비용/지연시간으로 서빙할 수 있습니다.
Plaid Labs처럼 내부 자동화/챗봇 워크로드를 로컬에서 안정 운영하려면, 현재 조합에서는 vLLM이 가장 운영 친화적이었습니다.
개인용·소규모 팀이라면 NVIDIA 서버 대신 Apple Silicon + MLX 조합이 더 현실적입니다. Mac mini M4 Pro에서 MLX로 30B 모델 돌려본 기록에서 같은 문제를 개인용 시점으로 다뤘습니다.

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

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

용어	쉽게 말하면	왜 중요한가
FP16	숫자 1개를 16비트로 저장	정확도 기준점, 대신 메모리 사용량 큼
FP8	숫자 1개를 8비트로 저장	FP16 대비 메모리/속도 이점
FP4	숫자 1개를 4비트로 저장	매우 가볍지만 정확도 손실 위험 큼
NVFP4	FP4 + 2단계 스케일 보정	4비트 이점은 유지하면서 정확도 하락 완화
vLLM	LLM API 서버를 고처리량으로 운영하는 엔진	동시성/지연시간/운영옵션에서 실전성이 높음

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

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

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

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

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

FP16: 값 하나 = 16비트
FP8:  값 하나 = 8비트
FP4:  값 하나 = 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: 우리 목적에서의 현실 비교

엔진	장점	아쉬운 점	추천 상황
llama.cpp	가볍고 빠른 실험, GGUF 생태계 강점	대규모 멀티 GPU API 운영에선 제어면이 제한적일 수 있음	온디바이스, 경량 추론, 빠른 검증
Ollama	초기 진입장벽이 가장 낮고 사용이 단순	고급 튜닝/세밀한 운영제어는 상대적으로 제한	개인 생산성, 소규모 내부도구, PoC
vLLM	고처리량, OpenAI API 호환, 배치/캐시/병렬 옵션 풍부	초기 러닝커브와 튜닝 학습이 필요	대형 모델 프로덕션 서빙, 팀 단위 운영

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

CPU: Intel Ultra 9 285K
RAM: DDR5 256GB
GPU: RTX PRO 6000 Blackwell WS 2장 (총 192GB VRAM)

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

튜닝 순서는 아래가 가장 안전했습니다.

max-model-len을 먼저 현실값(예: 32k)으로 고정
max-num-seqs와 max-num-batched-tokens를 단계적으로 상향
OOM 직전보다 10~15% 낮은 값을 운영 기본값으로 채택

5. 운영 모니터링: 이건 꼭 붙이자

지표	vLLM 메트릭	왜 봐야 하는가
TTFT (Time To First Token)	`vllm:time_to_first_token_seconds`	체감 응답성. p95가 1.5s를 넘어가면 prefill 단계 튜닝 필요
ITL (Inter-Token Latency)	`vllm:time_per_output_token_seconds`	스트리밍 안정성. 튀는 구간은 decode 경합 신호
처리량	`vllm:generation_tokens_total`	tok/s 추세. 동일 부하 대비 저하 시 KV cache 압박 의심
대기열 길이	`vllm:num_requests_waiting`	0보다 크면 캡 도달. max-num-seqs 조정 트리거
KV 캐시 사용률	`vllm:gpu_cache_usage_perc`	90% 지속 시 OOM 임박. max-model-len 또는 max-num-seqs 조절
GPU 활용률	`DCGM_FI_DEV_GPU_UTIL`	DCGM exporter 별도. 70% 미만 지속이면 동시성을 더 올릴 여지
p95/p99 응답시간	`vllm:e2e_request_latency_seconds`	SLO 지표. 알람 임계값을 이 위에 건다

6. 자주 겪는 함정

max-model-len을 과도하게 크게 시작: KV cache가 급증해 동시성과 지연시간이 악화됩니다. 실제 워크로드의 p99 입력 길이 + 응답 토큰 여유 + 20% 정도로 시작해 점진적으로 늘리세요.
메모리 사용률을 너무 보수적으로 고정: 안정성은 좋지만 처리량 손해가 큽니다. gpu-memory-utilization을 0.85부터 시작해 OOM이 없으면 0.90, 0.92로 단계적으로 올리는 편이 안전합니다.
모니터링 없이 체감 튜닝: 동일 시간대/동일 부하 비교 없이 설정을 바꾸면 잘못된 결론이 나기 쉽습니다. 변경 전후 30분 윈도우의 p95 latency와 tok/s를 같은 대시보드에서 비교하세요.
tensor-parallel-size와 GPU 수 불일치: 듀얼 Blackwell이라면 --tensor-parallel-size 2가 기본 출발점입니다. 1로 두면 한 GPU만 쓰고, NCCL 환경변수(NCCL_DEBUG=warn, NCCL_P2P_DISABLE=0)를 같이 확인해야 합니다.
NVFP4 모델과 vLLM 버전 호환성: NVFP4는 비교적 새 포맷이라 vLLM nightly나 0.7+ 라인을 권장합니다. stable 태그에 고정해두면 모델 로딩 단계에서 quantization not supported로 떨어지는 경우가 있습니다.
KV cache eviction 정책 미설정: 장시간 세션이 섞여 들어오는 워크로드에서는 --enable-prefix-caching과 cache 크기 한도를 같이 잡지 않으면 캐시 hit율이 떨어집니다. 챗봇처럼 system prompt가 길고 반복되는 경우 prefix caching의 효과가 큽니다.
양자화 모델 정확도 회귀를 무시하기: NVFP4 변환본은 같은 모델의 FP16/FP8 대비 미세한 품질 회귀가 있을 수 있습니다. 발행 전에 자체 평가셋(최소 50개 케이스)으로 회귀 테스트를 돌려서 허용 범위 안인지 확인하세요.

7. 빠른 운영 체크리스트

실제 운영에 들어가기 전에 한 번 훑어볼 수 있는 체크리스트입니다. 듀얼 Blackwell + vLLM + NVFP4 조합 기준으로 정리했습니다.

모델 로딩이 --tensor-parallel-size 2로 두 GPU에 분산되는지 확인 (nvidia-smi에서 두 GPU 모두 점유 표시)
gpu-memory-utilization 초기값 0.85, OOM 없으면 단계적 상향
max-model-len은 실제 p99 컨텍스트 + 응답 여유로 시작 (무한히 크게 두지 말 것)
prefix caching 활성화 여부를 워크로드 특성(긴 system prompt 여부)에 맞춰 결정
Prometheus가 vLLM /metrics를 스크랩하고 있고, Grafana 대시보드가 떠 있음
알람 2개(대기열 누적, p95 latency 초과) 임계값 설정 완료
NVFP4 변환본의 품질 회귀 테스트 통과 (자체 평가셋 50+ 케이스)
Tool calling이 필요한 경우 --enable-auto-tool-choice와 모델별 tool parser 설정 확인
컨테이너 ipc: host, --shm-size 충분히 잡혀 있음 (멀티 GPU 통신 안정성)

8. 결론

참고 자료

Plaid Labs 기술 블로그 — 개인용 로컬 LLM 추론의 새 기준, MLX (개인용·소규모 팀 시점)
Plaid Labs 기술 블로그 — 오픈소스 LLM 생태계 2026: DeepSeek-V4·Qwen3.6·GLM-5.1 (모델 동향)
Plaid Labs 기술 블로그 — Speculative Decoding이란 무엇인가? (추론 가속 시리즈 4편)
Plaid Labs 기술 블로그 — LLM을 작게 만드는 여러가지 압축 기술들 (BitNet · AutoRound · TurboQuant · REAP)
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

Contents