정밀도 수준별 디코드, 프리필, 전력

모든 로컬 LLM 배포에는 중요한 2가지 속도가 있으며, 이 속도는 정밀도 조절에 따라 다르게 반응합니다. 이 페이지에서는 FP16에서 INT4로 낮추면 생성 속도가 세 배까지 빨라질 수 있지만 프롬프트 처리 시간은 거의 변하지 않는 이유와, 자체 하드웨어에서 이러한 트레이드오프를 측정하는 방법을 설명합니다.

중요한 두 가지 속도

디코드 처리량은 모델이 답변을 시작한 후 토큰을 생성하는 속도로, 초당 토큰 수(tok/s)로 측정됩니다. 이는 채팅 응답이나 코드 완성 결과가 화면에 나타나는 속도를 결정합니다. 프리필 대기 시간은 모델이 1번째 토큰을 생성하기 전에 입력을 처리하는 데 걸리는 시간으로, 토큰당 밀리초(ms/token)로 측정됩니다. 이는 Enter를 누른 후 스트리밍 출력이 시작되기까지의 일시 정지 시간을 결정합니다. 작업 부하에 따라 중요한 속도가 다릅니다:

작업 부하	가장 중요한 요소	이유
대화형 채팅	디코드 처리량	짧은 프롬프트, 긴 응답 — 생성이 지배적임
문서 분석	프리필 대기 시간	긴 프롬프트(10K+ 토큰), 짧은 응답 — 입력 처리가 지배적임
코딩 에이전트	둘 다	중간 길이 프롬프트, 긴 다중 턴 출력 — 둘 다 체감됨
배치 처리	총 처리량	디코드와 프리필이 모두 실제 경과時間に 기여함

첫 토큰 도달 시간(TTFT)은 프리필 대기 시간에 스케줄링 또는 대기열 지연이 결합된 것입니다. 로컬 하드웨어에서 단일 사용자의 경우 TTFT는 프리필 시간과 거의 같습니다. 동시 부하 하에서는 대기열이 TTFT에 독립적으로 추가됩니다.

속도에 대한 정밀도의 의미

정밀도는 모델의 각 가중치를 표현하는 데 사용되는 비트 수를 제어합니다. 비트 수가 적을수록 가중치가 작아지며, 이는 모델이 차지하는 메모리 양과 토큰당 GPU가 읽는 데이터 양이라는 2가지 사항을 변경합니다.

정밀도	메모리 배수	일반적인 품질 영향	지원 하드웨어
FP16 / BF16	1.0x (기준)	없음 — 완전한 충실도	모든 GPU
FP8 (E4M3)	0.5x	<2% (최신 모델 기준)	Ada/Hopper/Blackwell (SM89+)
INT8 (W8A8)	0.5x	1-3% 손실	INT8 텐서 코어가 있는 대부분의 GPU
INT4 (W4A16, GPTQ, AWQ)	0.25x	2-5% 손실	모든 GPU (런타임 시 역양자화)
NVFP4	0.25x	1-3% 손실	Blackwell / DGX Spark (SM121)

품질 열은 근사값입니다. 양자화 인식 학습(QAT)으로 훈련된 최신 모델은 낮은 정밀도에서 더 적은 품질 손실을 보입니다. 자세한 내용은 QAT 개념을 참조하세요.

정밀도가 디코드와 프리필에 다르게 미치는 영향

여기서 핵심 통찰력은 이렇습니다: 디코드와 프리필은 서로 다른 하드웨어 병목 현상을 겪기 때문에, 동일한 정밀도 변경이 둘에 불균등하게 영향을 미칩니다.

디코드는 메모리 대역폭에 제한됨

디코드 중 모델은 한 번에 1개의 토큰을 생성합니다. 각 토큰마다 모델은 메모리에서 전체 가중치 행렬을 읽고 가중치당 아주 작은 양의 계산을 수행합니다. GPU는 수학 연산을 하는 시간보다 메모리에서 데이터가 도착하기를 기다리는 데 대부분의 시간을 보냅니다. 가중치가 작을수록 = 읽어야 할 데이터가 적어짐 = 더 빠른 디코드. 속도 향상은 메모리 감소에 비례합니다:

FP16 → FP8: ~1.8-2.0x 디코드 속도 향상
FP16 → INT4: ~2.5-3.5x 디코드 속도 향상
FP16 → NVFP4: ~2.5-3.0x 디코드 속도 향상

프리필은 계산에 제한됨

프리필 중 모델은 모든 입력 토큰을 병렬로 처리합니다. 가중치는 한 번 읽지만, 모든 프롬프트 토큰에 걸쳐 큰 행렬 곱셈을 수행합니다. GPU는 메모리를 기다리는 시간보다 수학 연산을 하는 데 대부분의 시간을 보냅니다. 계산이 병목 현상이므로 가중치 읽기가 아닌 계산이 병목이 되므로, 양자화가 프리필에 덜 도움이 됩니다:

FP16 → FP8: ~1.3-1.5x 프리필 속도 향상
FP16 → INT4: ~1.2-1.5x 프리필 속도 향상
FP16 → NVFP4: ~1.3-1.5x 프리필 속도 향상

실제 영향

정밀도가 낮아질수록 디코드가 프리필보다 더 빠르게 개선됩니다. INT4에서 FP16에서 느리게 느껴지던 모델은 텍스트를 빠르게 생성하지만 긴 프롬프트에서는 여전히 눈에 띄게 일시 정지합니다. 이러한 비대칭성이 아래 작업 부하별 권장 사항을 이끕니다.

정밀도 수준별 전력 소비

낮은 정밀도는 2가지 이유로 전력 소비를 줄입니다: 메모리 읽기 횟수 감소(메모리 액세스가 에너지 비용의 대부분을 차지함)와 단순화된 산술 연산(INT4 곱셈은 FP16 곱셈보다 비용이 적음).

DGX Spark 전력 범위

DGX Spark의 GB10 칩은 Grace CPU와 Blackwell GPU가 공유하는 약 40W의 TDP를 가집니다. 다음은 추론 중 관찰된 전력 범위입니다:

정밀도	대기 전력	디코드 부하	프리필 부하
FP16	8-12W	30-38W	35-40W
FP8	8-12W	25-33W	30-38W
NVFP4	8-12W	22-30W	28-35W

소비자 GPU 전력 기대치

GPU	FP16 디코드 부하	INT4/FP8 디코드 부하	절감 효과
RTX 4090 (450W TDP)	300-400W	200-300W	약 25% 절감 (INT4에서)
Strix Halo (120W TDP)	80-110W	60-85W	약 20% 절감 (INT4에서)

24/7 서비스 비용

디코드 부하에서 지속적으로 실행되는 DGX Spark의 경우:

정밀도	평균 전력	월간 kWh (약)
FP16	34W	~24 kWh
FP8	29W	~21 kWh
NVFP4	26W	~19 kWh

RTX 4090과 같은 소비자 GPU에서 하루 10시간 기준:

정밀도	평균 전력	월간 kWh (약)
FP16	350W	~105 kWh
FP8	250W	~75 kWh
INT4	200W	~60 kWh

벤치마킹 방법론

정밀도가 특정 모델과 하드웨어에 어떻게 영향을 미치는지 확인하려면 자체 설정에서 다음 테스트를 실행하세요.

디코드 처리량 측정

짧은 프롬프트에서 고정 수의 출력 토큰을 생성하고 초당 토큰 수를 측정합니다.

# Start the server first
vllm serve <model> --quantization <precision> --max-model-len 8192

# In another terminal
python -m vllm.benchmarks.benchmark_serving \
  --model <model> \
  --num-prompts 5 \
  --request-rate 1 \
  --max-input-len 128 \
  --max-output-len 256

./llama-bench \
  -m <model>.gguf \
  -p 512 \
  -n 128 \
  -ngl 99 \
  --repetitions 3

ollama run <model> --verbose "Write a short paragraph about inference speed."
# The --verbose flag prints eval rate in tok/s

프리필 대기 시간 측정

다양한 프롬프트 길이에서 모델이 1번째 토큰을 생성하는 데 걸리는 시간을 측정합니다.

# vLLM — vary --max-input-len to test prefill at different prompt sizes
python -m vllm.benchmarks.benchmark_serving \
  --model <model> \
  --num-prompts 3 \
  --request-rate 1 \
  --max-input-len 2048 \
  --max-output-len 1

출력에서 첫 토큰 도달 시간(TTFT)을 기록합니다. 512, 1024, 4096, 8192 입력 토큰에서 반복합니다.

전력 소비 측정

# Sample power every second during inference
watch -n 1 nvidia-smi --query-gpu=power.draw,power.limit --format=csv

# Reports SoC power on Grace/Blackwell
tegrastats --interval 1000

보고해야 할 사항

테스트하는 각 정밀도 수준에 대해 다음 표를 작성합니다:

지표	FP16	FP8	INT4 / NVFP4
디코드 (tok/s)
프리필 (ms/token, 4K 프롬프트)
프리필 (ms/token, 16K 프롬프트)
TTFT (s, 8K 프롬프트)
디코드 부하 시 전력 (W)
대기 전력 (W)

실제 의사 결정 표

주요 작업 부하와 일치하는 행을 선택하세요:

사용 사례	우선순위	권장 정밀도	이유
대화형 챗봇	디코드 속도	Q4_K_M 또는 FP8	짧은 프롬프트, 긴 응답 — 디코드가 경험의 대부분을 차지함
문서 분석	프리필 속도	FP16 또는 FP8	긴 프롬프트(10K+ 토큰) — 프리필이 대기 시간을 지배함
노트북 / 배터리 작동	전력 효율성	INT4 (Q4_K_M, AWQ)	가장 작은 메모리 footprint, 가장 낮은 전력 소비
다중 사용자 서비스	둘 다	배치 처리와 함께 FP8	품질과 처리량 균형; FP8 KV 캐시는 동시성을 두 배로 증가시킴
최대 출력 품질	품질만	FP16 / BF16	양자화 손실 제로를 위해 높은 메모리 및 전력 비용 수용
DGX Spark 배포	디코드 + 메모리 적합성	NVFP4	네이티브 SM121 지원, 75% 크기 감소, 128GB에 대형 모델 적합

항상 INT4를 사용하지 않는 이유는 무엇입니까?

INT4 양자화(GPTQ, AWQ, Q4_K_M)는 작은 모델과 지시 따르기 작업에서 품질을 눈에 띄게 저하시킵니다. 13B 파라미터 미만의 모델에서는 FP16과 INT4 사이의 품질 격차가 출력을 저하시킬 수 있습니다. 70B+ 모델에서는 모델이 양자화 노이즈를 흡수할 수 있는 용량이 더 많기 때문에 격차가 좁아집니다. 확정하기 전에 특정 모델을 테스트하세요.

KV 캐시 정밀도가 이 수치에 영향을 미치나요?

네. FP8 KV 캐시(vLLM에서 --kv-cache-dtype fp8로 설정)는 가중치 양자화와 독립적으로 KV 캐시 메모리를 절반으로 줄입니다. 디코드 속도에 미치는 영향은 미미하지만 더 긴 컨텍스트나 더 많은 동시 사용자를 수용할 수 있게 합니다. 크기 조정 표는 DGX Spark 메모리 튜닝을 참조하세요.

컨텍스트 길이가 디코드 속도를 어떻게 변경하나요?

디코드는 각 토큰마다 전체 KV 캐시를 읽습니다. 더 긴 대화는 더 큰 캐시를 구축하므로 컨텍스트가 커짐에 따라 디코드가 느려집니다. 4K 컨텍스트에서 모델은 40 tok/s로 생성할 수 있지만 25 tok/s로 떨어질 수 있으며, 이는 동일한 하드웨어에서 32K 컨텍스트에서 해당합니다. 메커니즘은 KV 캐시 및 컨텍스트를 참조하세요.

빠른 벤치마킹 명령어

단일 모델에서 정밀도를 비교하기 위해 다음을 시작점으로 사용하세요.

vLLM 벤치마킹 스위트

# Launch with a specific quantization
vllm serve <model> --quantization fp8 --max-model-len 8192

# Run the built-in benchmark
python -m vllm.benchmarks.benchmark_serving \
  --model <model> \
  --num-prompts 10 \
  --request-rate 2 \
  --max-input-len 1024 \
  --max-output-len 128

# Repeat with --quantization nvfp4, then compare results

llama.cpp 벤치마킹

# FP16 baseline
./llama-bench -m model-f16.gguf -p 512 -n 128 -ngl 99

# Q4_K_M quantized
./llama-bench -m model-q4_k_m.gguf -p 512 -n 128 -ngl 99

# Q8_0 for comparison
./llama-bench -m model-q8_0.gguf -p 512 -n 128 -ngl 99

llama.cpp는 프롬프트 처리(pp)와 텍스트 생성(tg) 속도를 나란히 보여주는 비교 표를 출력합니다.

Ollama 내장 평가

# Run with verbose output to see eval speed
ollama run <model> --verbose "Summarize the theory of general relativity in 3 sentences."

# The output includes:
# eval count:   42 generation(s)
# eval duration: 1.8s
# eval rate:    23.3 tokens/s

정밀도 간 비교

각 정밀도에서 동일한 프롬프트를 실행하고 결과를 표에 기록합니다:

정밀도	pp (ms/token)	tg (tok/s)	메모리 (GB)
FP16
FP8
Q4_K_M

가장 재현 가능한 결과를 얻으려면 측정 전에 1개의 요청으로 모델을 워밍업하고, 다른 GPU 작업 부하를 닫으며, 최소 3번 반복 실행하세요. 중앙값을 보고하세요.

다음 단계

DGX Spark 메모리 튜닝

128GB 통합 메모리를 위한 KV 캐시 크기 조정, 배치 트레이드오프 및 튜닝 매개변수.

DGX Spark에서 vLLM

설치, NVFP4 구성 및 최적 시작 명령어.

배포 벤치마킹

Tokios를 통한 엔드투엔드 테스트 — 대기 시간, 스트리밍 및 클라이언트 비교.

양자화 개념

GPTQ, AWQ, GGUF 및 양자화 트레이드오프에 대한 심층 설명.

하드웨어와 호환성

런타임 서빙과 연결

클라이언트 또는 앱 연결

비교

정밀도 수준별 디코드, 프리필, 전력

중요한 두 가지 속도

속도에 대한 정밀도의 의미

정밀도가 디코드와 프리필에 다르게 미치는 영향

디코드는 메모리 대역폭에 제한됨

프리필은 계산에 제한됨

실제 영향

정밀도 수준별 전력 소비

DGX Spark 전력 범위

소비자 GPU 전력 기대치

24/7 서비스 비용

벤치마킹 방법론

디코드 처리량 측정

프리필 대기 시간 측정

전력 소비 측정

보고해야 할 사항

실제 의사 결정 표

빠른 벤치마킹 명령어

vLLM 벤치마킹 스위트

llama.cpp 벤치마킹

Ollama 내장 평가

정밀도 간 비교

다음 단계

DGX Spark 메모리 튜닝

DGX Spark에서 vLLM

배포 벤치마킹

양자화 개념

​중요한 두 가지 속도

​속도에 대한 정밀도의 의미

​정밀도가 디코드와 프리필에 다르게 미치는 영향

​디코드는 메모리 대역폭에 제한됨

​프리필은 계산에 제한됨

​실제 영향

​정밀도 수준별 전력 소비

​DGX Spark 전력 범위

​소비자 GPU 전력 기대치

​24/7 서비스 비용

​벤치마킹 방법론

​디코드 처리량 측정

​프리필 대기 시간 측정

​전력 소비 측정

​보고해야 할 사항

​실제 의사 결정 표

​빠른 벤치마킹 명령어

​vLLM 벤치마킹 스위트

​llama.cpp 벤치마킹

​Ollama 내장 평가

​정밀도 간 비교

​다음 단계

DGX Spark 메모리 튜닝

DGX Spark에서 vLLM

배포 벤치마킹

양자화 개념

중요한 두 가지 속도

속도에 대한 정밀도의 의미

정밀도가 디코드와 프리필에 다르게 미치는 영향

디코드는 메모리 대역폭에 제한됨

프리필은 계산에 제한됨

실제 영향

정밀도 수준별 전력 소비

DGX Spark 전력 범위

소비자 GPU 전력 기대치

24/7 서비스 비용

벤치마킹 방법론

디코드 처리량 측정

프리필 대기 시간 측정

전력 소비 측정

보고해야 할 사항

실제 의사 결정 표

빠른 벤치마킹 명령어

vLLM 벤치마킹 스위트

llama.cpp 벤치마킹

Ollama 내장 평가

정밀도 간 비교

다음 단계