LLM 양자화(GGUF·AWQ·GPTQ)로 오픈소스 모델 로컬 추론 최적화
INT4 양자화는 FP16 대비 메모리를 4배 가까이 줄입니다. GGUF·AWQ·GPTQ의 차이와 llama.cpp·vLLM·ExLlamaV2 중 무엇과 조합할지, 로컬 추론 환경별로 골라 드립니다.
목차
- 개요
- 양자화의 핵심 원리
- GGUF · AWQ · GPTQ 비교 분석
- 로컬 추론 환경 구축
- 성능 측정과 트레이드오프
- 운영 환경 적용 시 고려사항
- 맺음말
개요
문제 배경: 왜 양자화가 필요한가
LLM 양자화(Quantization)는 수백억 개의 파라미터를 가진 대형 언어 모델을 소비자용 하드웨어에서 실행 가능하게 만드는 핵심 압축 기술입니다. Llama 3.1 70B 모델을 FP16(16비트 부동소수점) 정밀도 그대로 저장하면 약 140GB VRAM이 필요합니다. 이는 NVIDIA A100 80GB GPU를 두 장 연결해야 겨우 올라가는 수준이며, 클라우드 비용으로 환산하면 시간당 수십 달러가 소요됩니다. 반면 4비트 양자화를 적용하면 동일 모델이 약 35GB로 압축되어, RTX 4090 한 장이나 Apple M2 Max 맥스택에서도 실행할 수 있게 됩니다. 이 차이가 오픈소스 LLM을 현업 서버나 개인 연구 환경에서 직접 서빙할 수 있는지 없는지를 가릅니다.
기존 방식의 한계: FP16 모델의 제약
양자화 이전의 전통적인 접근은 오프로딩(CPU offloading) 이었습니다. GPU VRAM이 부족할 경우 일부 레이어를 시스템 RAM이나 NVMe SSD에 올려놓고 추론 시에 필요한 레이어만 GPU로 옮기는 방식입니다. 그러나 이 접근은 GPU↔CPU 간 PCIe 대역폭 병목을 피할 수 없어, 토큰 생성 속도가 초당 0.5~2개 수준으로 떨어지는 경우가 잦습니다. 실제 대화형 애플리케이션에서 사용자가 체감하는 응답 지연은 수십 초에 달하며, 이는 사용성 측면에서 허용하기 어렵습니다. 양자화는 모델 자체의 표현 크기를 줄여 이 근본적인 문제를 해결합니다.
양자화 방식에 따라 같은 모델도 탑재 가능한 하드웨어 스펙이 크게 달라집니다.
양자화의 핵심 원리
가중치 압축 메커니즘
양자화의 수학적 본질은 연속 실수 공간의 값을 유한한 정수 격자로 근사하는 것입니다. FP32 가중치 하나는 32비트(4바이트)를 사용하지만, INT4로 양자화하면 4비트(0.5바이트)만 사용합니다. 압축률이 8배에 달하는 셈입니다. 양자화의 핵심 수식은 다음과 같습니다.
W_q = round(W / scale) + zero_point
여기서 scale은 원본 가중치의 범위를 정수 범위로 매핑하는 스케일 팩터이며, zero_point는 비대칭 분포를 보정하는 오프셋입니다. 추론 시에는 역연산으로 W ≈ (W_q - zero_point) × scale 를 계산해 원본 값에 근사한 수를 복원합니다. 이 과정에서 발생하는 양자화 오류(Quantization Error) 가 모델 품질 저하의 원인이 됩니다.
중요한 점은 모든 가중치를 균일하게 양자화하지 않는다는 것입니다. 현대 양자화 기법은 그룹 양자화(Group Quantization) 를 채택해, 예컨대 128개 혹은 64개 가중치를 하나의 그룹으로 묶어 각 그룹마다 개별 스케일 팩터를 계산합니다. 그룹 크기가 작을수록 정밀도가 높아지지만 스케일 메타데이터가 늘어나 오버헤드가 증가합니다.
그룹 단위 스케일 팩터가 전체 모델의 스케일 하나보다 양자화 오류를 크게 줄여 줍니다.
비트 폭과 정밀도 트레이드오프
비트 폭 선택은 추론 성능과 모델 품질 사이의 핵심 교환점입니다. 실제 프로젝트에서 자주 쓰이는 비트 폭별 특성을 정리하면 아래와 같습니다.
| 비트 폭 | 표현 가능한 정수 범위 | 70B 모델 크기 | 품질 손실 | 주요 용도 |
|---|---|---|---|---|
| FP16 | — (부동소수점) | ~140GB | 없음 | 기준선, 서버 |
| INT8 | 0~255 | ~70GB | 거의 없음 | 서버, 프로덕션 |
| INT4 | 0~15 | ~35GB | 소폭 (~1–3%) | 소비자 GPU |
| INT3 | 0~7 | ~26GB | 눈에 띄는 저하 | VRAM 극한 절약 |
| INT2 | 0~3 | ~18GB | 심각 | 실험적 |
INT4는 대부분의 현업 케이스에서 실용적 선택입니다. 퍼플렉서티(Perplexity) 기준으로 INT4 4비트 양자화는 원본 FP16 대비 1~3% 수준의 손실을 보이는 반면, 메모리는 절반 이하로 줄어듭니다. INT8은 품질 손실이 거의 없지만 메모리 절감 효과가 INT4에 비해 작습니다. 결국 VRAM 예산에 따라 INT8과 INT4 사이에서 선택하는 경우가 대부분입니다.
보정(Calibration) 과정
사후 학습 양자화(Post-Training Quantization, PTQ) 방식은 이미 학습된 모델에 양자화를 적용합니다. 이때 보정 데이터셋(Calibration Dataset) 이 필요합니다. 보정 과정은 실제 입력 데이터를 소량(128~512 샘플) 통과시키면서 각 레이어의 활성화 분포를 측정하고, 이 통계를 바탕으로 최적의 스케일 팩터를 결정합니다. 보정 데이터가 실제 서비스 도메인과 가까울수록 양자화 품질이 높아지며, 반대로 도메인이 맞지 않으면 특정 입력 유형에서 비정상적인 출력이 나올 수 있습니다. GGUF는 이미 완성된 양자화 파일을 배포하기 때문에 사용자가 보정 과정을 직접 수행할 필요가 없지만, AWQ나 GPTQ로 직접 양자화할 때는 보정 데이터 선택이 품질에 직접 영향을 줍니다.
GGUF · AWQ · GPTQ 비교 분석
GGUF: llama.cpp 생태계의 표준
GGUF(GPT-Generated Unified Format) 는 llama.cpp 프로젝트가 정의한 모델 파일 포맷입니다. 전신인 GGML 포맷의 한계를 개선해 2023년 하반기에 도입되었으며, 현재는 HuggingFace에서 가장 많이 배포되는 양자화 포맷 중 하나입니다. GGUF의 가장 큰 특징은 CPU 추론과 GPU 추론을 동시에 지원한다는 점입니다. VRAM이 부족할 경우 일부 레이어를 CPU RAM에 두고 나머지만 GPU에 올리는 하이브리드 모드가 네이티브로 지원됩니다. 이 덕분에 GPU가 없는 MacBook이나 일반 PC에서도 실용적인 속도로 추론할 수 있습니다.
GGUF 파일명에는 양자화 유형이 명시됩니다. Q4_K_M이라면 4비트, K-quants 방식, Medium 그룹 크기를 뜻합니다. Q5_K_S는 5비트, Small 그룹 크기입니다. K-quants는 일부 중요한 레이어(임베딩, 출력 레이어)를 더 높은 비트 폭으로 유지하는 혼합 정밀도 방식으로, 단순 균일 양자화보다 품질이 좋습니다. Llama.cpp 외에도 Ollama, LM Studio, Jan 같은 로컬 LLM 클라이언트들이 GGUF를 기본 포맷으로 채택하고 있어, 설치 경험이 가장 간편합니다.
GGUF는 VRAM 예산이 부족해도 레이어 오프로딩으로 실행 자체는 보장됩니다.
AWQ: 활성화 인식 가중치 양자화
AWQ(Activation-aware Weight Quantization) 는 MIT가 2023년에 발표한 방식으로, 가중치의 중요도를 활성화 분포에서 추론해 선택적으로 보호하는 전략을 씁니다. 핵심 통찰은 모든 가중치가 동등하지 않다는 것입니다. 실험적으로 활성화 값이 큰(salient) 채널에 해당하는 가중치 약 1%가 모델 성능의 대부분을 담당합니다. AWQ는 이 1%의 가중치를 FP16으로 유지하거나, 스케일을 조정해 INT4 범위 안에서 더 높은 해상도로 표현합니다.
AWQ의 실용적 장점은 AutoAWQ 라이브러리와 vLLM의 긴밀한 통합입니다. vLLM은 현재 가장 널리 쓰이는 고성능 LLM 서빙 프레임워크로, PagedAttention, continuous batching, CUDA 그래프 최적화가 내장되어 있습니다. vLLM이 AWQ를 네이티브로 지원하기 때문에, AWQ 모델을 프로덕션 서빙 파이프라인에 바로 투입할 수 있습니다. 또한 AWQ는 GGUF에 비해 GPU 전용 추론에서 처리량(throughput)이 높고, 동시 요청 처리 성능이 우수합니다.
GPTQ: 레이어별 최적화 전략
GPTQ(Generative Pre-trained Transformer Quantization) 는 2023년 초 발표된 방법으로, OBQ(Optimal Brain Quantization) 알고리즘을 LLM에 확장 적용합니다. GPTQ는 레이어 단위로 헤시안 행렬(Hessian matrix) 을 이용해 양자화 오류를 최소화하는 최적 가중치를 계산합니다. 다른 가중치를 조금씩 보정해 가며 양자화 오류를 분산시키는 Lazy Batch Updates 기법으로 전체 오류를 줄입니다.
GPTQ는 현재 AutoGPTQ, ExLlamaV2, HuggingFace Transformers 에서 지원됩니다. ExLlamaV2는 GPTQ 모델 전용으로 극도로 최적화된 CUDA 커널을 제공해, 단일 RTX 3090에서 Llama 2 70B GPTQ 4비트를 초당 20~30 토큰 수준으로 생성할 수 있습니다. GPTQ는 양자화 과정 자체가 AWQ보다 느리고 GPU 메모리를 많이 사용하지만, 결과물의 품질 면에서 동등하거나 특정 태스크에서 더 좋은 결과를 보입니다.
세 포맷은 각각 다른 실행 환경에 최적화되어 있으며, 서빙 스택 선택이 포맷 선택을 사실상 결정합니다.
로컬 추론 환경 구축
llama.cpp와 GGUF 모델 실행
llama.cpp는 C/C++로 작성되어 별도의 Python 환경 없이 바이너리만으로 실행됩니다. macOS에서는 Homebrew로 brew install llama.cpp 한 줄로 설치가 끝납니다. Linux나 Windows에서도 소스 컴파일이 비교적 간단합니다. 모델 파일은 HuggingFace의 TheBloke 또는 bartowski 같은 커뮤니티 계정에서 검증된 GGUF 파일을 다운받아 사용하면 됩니다.
다음은 Llama 3.1 8B Instruct의 Q4_K_M GGUF 모델을 llama.cpp 서버로 띄우는 예시입니다. GPU 레이어 수(-ngl)를 조정해 VRAM 사용량을 제어할 수 있습니다.
# GGUF 모델 다운로드 (huggingface-cli 사용)
huggingface-cli download \
bartowski/Meta-Llama-3.1-8B-Instruct-GGUF \
Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
--local-dir ./models
# llama-server 실행
# -ngl: GPU에 올릴 레이어 수 (전체 레이어 수 이상이면 전량 GPU)
# -c: 컨텍스트 길이 (메모리 사용량에 직접 영향)
llama-server \
--model ./models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
--port 8080 \
--ctx-size 4096 \
--n-gpu-layers 33 \
--threads 8
# 결과: INFO [main] model loaded // Q4_K_M, 4.65 GB, 33 layers on GPU
# 결과: INFO [main] server listening at http://127.0.0.1:8080-ngl 33은 Llama 3.1 8B의 전체 레이어(32개 트랜스포머 레이어 + 임베딩)를 모두 GPU에 올리라는 의미입니다. RTX 3060 12GB라면 이 설정으로 VRAM 6~7GB를 사용하며, 컨텍스트 4096 토큰 기준 초당 40~60 토큰 생성 속도가 나옵니다. VRAM이 부족하면 -ngl 20처럼 줄여서 일부만 GPU에 올리고 나머지를 CPU로 처리합니다.
핵심 규칙:
-ngl을 GPU에 올릴 수 있는 최대값으로 설정하세요. 레이어 하나라도 CPU로 내려가면 토큰 생성 속도가 크게 떨어집니다.
vLLM으로 AWQ/GPTQ 서빙
vLLM은 Python 환경에서 실행되는 고성능 LLM 서빙 엔진입니다. HuggingFace Hub에서 AWQ 또는 GPTQ 모델을 직접 지정하면 자동으로 적절한 양자화 커널을 불러옵니다. 다음 예시는 Qwen2.5 7B AWQ 모델을 vLLM OpenAI 호환 서버로 서빙하는 것입니다.
# vLLM OpenAI 호환 서버 실행 (Python 스크립트 또는 CLI)
# pip install vllm autoawq
from vllm import LLM, SamplingParams
# AWQ 모델 로드: quantization 파라미터로 awq 지정
llm = LLM(
model="Qwen/Qwen2.5-7B-Instruct-AWQ",
quantization="awq", # AWQ 커널 활성화
max_model_len=8192,
gpu_memory_utilization=0.85, # VRAM의 85%까지 사용
dtype="float16",
)
sampling_params = SamplingParams(
temperature=0.7,
top_p=0.9,
max_tokens=512,
)
prompts = ["한국의 수도는 어디인가요? 상세히 설명해 주세요."]
outputs = llm.generate(prompts, sampling_params)
for output in outputs:
print(output.outputs[0].text)
# 결과: "한국의 수도는 서울입니다. 서울은 한반도 중서부에 위치한..."vLLM을 CLI로 실행할 때는 python -m vllm.entrypoints.openai.api_server --model Qwen/Qwen2.5-7B-Instruct-AWQ --quantization awq --port 8000 한 줄로 OpenAI API 호환 엔드포인트를 바로 띄울 수 있습니다. 이 방식은 기존 OpenAI SDK를 사용하는 애플리케이션에서 base_url만 변경해 로컬 모델로 전환하는 데 특히 유리합니다.
하드웨어별 최적 설정
하드웨어 환경에 따라 최적 구성이 달라집니다. GPU VRAM 용량과 모델 크기의 조합이 가장 결정적인 요인입니다.
VRAM 용량이 모델 서빙 전략의 출발점이며, GPU가 없더라도 CPU 추론으로 7B 이하 모델은 충분히 실용적입니다.
Apple Silicon의 경우 별도의 VRAM 구분이 없고 통합 메모리(Unified Memory)를 사용합니다. M2 Pro 16GB라면 7B Q4 모델을, M2 Max 32GB라면 13B Q4나 7B FP16 모델을 실용적인 속도로 실행할 수 있습니다. Metal GPU 가속이 llama.cpp에서 네이티브 지원되므로 -ngl 999 옵션으로 모든 레이어를 GPU에 올릴 수 있으며, 초당 30~50 토큰 수준의 생성 속도가 나옵니다.
성능 측정과 트레이드오프
추론 속도와 메모리 사용량 비교
양자화 방식마다 실제 추론 성능이 다릅니다. 같은 모델, 같은 하드웨어라도 포맷과 런타임 선택에 따라 초당 생성 토큰 수(tokens/s)가 두 배 이상 차이날 수 있습니다. RTX 4090 단일 GPU에서 Llama 3 8B 기준 대략적인 수치를 정리하면 다음과 같습니다.
| 포맷 | 런타임 | VRAM 사용 | 생성 속도(t/s) | 배치 처리 | 주요 강점 |
|---|---|---|---|---|---|
| FP16 | vLLM | ~16GB | ~120 | 우수 | 품질 기준선 |
| INT8 (GPTQ) | vLLM | ~10GB | ~90 | 우수 | 품질·속도 균형 |
| INT4 AWQ | vLLM | ~6GB | ~110 | 우수 | GPU 서빙 최적 |
| INT4 GPTQ | ExLlamaV2 | ~6GB | ~130 | 보통 | 단일 요청 빠름 |
| Q4_K_M (GGUF) | llama.cpp | ~5.5GB | ~80 | 제한적 | CPU 호환성 |
| Q4_K_M (GGUF) | Ollama | ~5.5GB | ~75 | 제한적 | 설치 간편성 |
AWQ가 GPTQ보다 vLLM 환경에서 배치 처리 성능이 더 좋은 이유는 AWQ의 CUDA 커널이 PagedAttention과 결합할 때 메모리 접근 패턴이 더 효율적이기 때문입니다. GPTQ는 단일 스트림 추론에서는 ExLlamaV2 덕분에 빠르지만, 동시 요청이 늘어나면 상대적으로 처리량이 줄어듭니다.
품질 손실 평가
양자화로 인한 품질 저하는 퍼플렉서티(PPL) 지표로 측정합니다. 퍼플렉서티가 낮을수록 언어 모델이 텍스트를 더 잘 예측하며, 일반적으로 원본 대비 5% 이내의 PPL 증가는 실제 사용에서 느끼기 어렵습니다.
INT8과 INT4 AWQ는 대부분의 태스크에서 원본 대비 통계적으로 유의미한 차이를 보이지 않습니다.
주의해야 할 점은 퍼플렉서티가 모든 태스크를 대표하지는 않는다는 것입니다. 수학 추론이나 코드 생성 태스크에서는 INT4가 INT8보다 유의미하게 낮은 정확도를 보이는 경우가 있습니다. 반면 요약, 번역, 일반 대화에서는 차이가 거의 없습니다. 따라서 특정 도메인에 배포할 때는 해당 도메인의 벤치마크 데이터셋으로 직접 평가하는 과정이 중요합니다.
어떤 양자화를 선택할 것인가
양자화 선택 기준은 크게 네 가지 요인에 따라 결정됩니다. 첫째, 하드웨어 환경입니다. GPU가 없거나 CUDA 환경 구성이 어렵다면 GGUF가 유일한 실용적 선택입니다. GPU가 있고 서빙 서버를 운영한다면 AWQ+vLLM 조합이 가장 안정적입니다. 둘째, 동시 요청 수입니다. 단일 사용자 인터랙티브 환경은 GGUF로 충분하지만, 다중 사용자 API 서버는 vLLM의 배치 처리가 필수입니다. 셋째, 모델 재양자화 가능 여부입니다. 도메인 특화 보정 데이터를 사용하고 싶다면 AWQ나 GPTQ로 직접 양자화해야 합니다. 넷째, 운영 복잡도입니다. 팀 역량이나 유지보수 여력이 제한적이라면 Ollama로 GGUF를 서빙하는 방식이 운영 부담이 가장 낮습니다.
운영 환경 적용 시 고려사항
흔한 실수와 함정
가장 많이 마주치는 문제는 컨텍스트 길이와 KV 캐시 메모리 과소 추정입니다. KV 캐시는 추론 시 이전 토큰의 키·값 행렬을 저장하는 메모리 영역으로, 컨텍스트가 길어질수록 선형으로 증가합니다. 예를 들어 Llama 3.1 8B Q4 모델 자체는 VRAM 5.5GB를 사용하지만, 컨텍스트 32768 토큰 기준 KV 캐시는 추가로 8~12GB를 필요로 합니다. 모델을 로드한 뒤에 긴 요청을 처리하다가 OOM(Out of Memory)이 발생하는 원인의 대부분이 여기에 있습니다.
두 번째 함정은 배치 크기와 메모리의 관계를 간과하는 것입니다. vLLM의 gpu_memory_utilization 파라미터를 너무 높게 설정하면 GPU 메모리 조각화가 발생해 오히려 처리량이 감소하는 역효과가 납니다. 권장 범위는 0.80~0.90이며, 먼저 0.85로 시작해 실제 부하를 측정하면서 조정하는 것이 안전합니다.
세 번째는 양자화 포맷과 런타임의 버전 불일치입니다. ExLlamaV2, AutoGPTQ, AutoAWQ는 각각 독립적으로 업데이트되며, 특정 버전 조합에서 모델이 잘못 로드되거나 출력이 깨지는 경우가 있습니다. HuggingFace 모델 카드에 명시된 권장 라이브러리 버전을 먼저 확인하고, 가상 환경을 분리해 버전을 고정하는 것이 좋습니다.
운영 환경에서 문제가 발생하면 OOM·출력 품질·속도 순으로 진단하는 것이 효율적입니다.
모니터링과 디버깅
프로덕션에서 반드시 추적해야 할 지표가 있습니다. TTFT(Time to First Token) 는 요청 수신 후 첫 번째 토큰이 출력될 때까지의 시간으로, 프리필(prefill) 단계의 성능을 반영합니다. 긴 시스템 프롬프트나 긴 컨텍스트가 누적될수록 TTFT가 늘어납니다. TPOT(Time per Output Token) 는 디코딩 단계의 속도로, 모델 가중치 로드와 VRAM 대역폭 활용도를 보여 줍니다.
vLLM은 /metrics 엔드포인트로 Prometheus 호환 메트릭을 노출합니다. vllm:num_requests_running, vllm:gpu_cache_usage_perc, vllm:time_to_first_token_seconds 같은 지표를 Grafana 대시보드로 시각화하면 이상 징후를 빠르게 포착할 수 있습니다. GGUF + llama.cpp 환경에서는 --verbose 옵션으로 실행하면 요청별 처리 시간과 VRAM 사용량이 표준 출력으로 노출됩니다.
TTFT와 KV 캐시 사용률 두 지표만으로도 대부분의 성능 문제를 조기에 감지할 수 있습니다.
확장과 마이그레이션
단일 GPU에서 다중 GPU 또는 다중 노드로 확장할 때 고려해야 할 사항이 있습니다. 텐서 병렬(Tensor Parallelism) 은 모델 레이어를 여러 GPU에 나누는 방식으로, vLLM에서 --tensor-parallel-size 2처럼 설정합니다. GGUF + llama.cpp는 기본적으로 다중 GPU 텐서 병렬을 지원하지 않기 때문에, 규모 확장 시점에 vLLM으로 마이그레이션을 고려해야 합니다.
모델을 업그레이드할 때, 예를 들어 Llama 3.1에서 Llama 3.2로 전환할 때는 동일한 양자화 수준의 새 모델이 HuggingFace에 게시될 때까지 기다리거나 직접 양자화해야 합니다. 직접 양자화하려면 AutoAWQ나 AutoGPTQ 스크립트를 사용하며, RTX 4090 기준으로 70B 모델 양자화에 약 1~2시간이 소요됩니다. 이 과정에서 보정 데이터를 서비스 도메인에 맞게 준비하면 품질을 한 단계 끌어올릴 수 있습니다.
또한 양자화 모델은 파인튜닝(Fine-tuning)과 연계해 사용할 수 있습니다. QLoRA(Quantized Low-Rank Adaptation) 는 INT4 양자화 모델 위에 LoRA 어댑터를 학습해 최소한의 GPU 메모리로 도메인 특화 파인튜닝을 수행합니다. QLoRA로 학습한 어댑터는 양자화 모델과 분리 저장되며, 서빙 시 동적으로 합칩니다. 이 방식은 24GB VRAM GPU 한 장으로도 70B 모델을 파인튜닝할 수 있게 해 줍니다.
맺음말
핵심 요약
LLM 양자화는 대형 모델을 현실적인 하드웨어 예산 안에서 운영하는 핵심 기술입니다. 세 가지 주요 포맷 각각의 위치가 분명합니다. GGUF는 CPU 호환성과 낮은 진입 장벽으로 개인 개발자와 소규모 팀에 적합합니다. AWQ는 GPU 서버 환경에서 vLLM과 함께 쓸 때 처리량과 운영 편의성이 균형을 이룹니다. GPTQ는 ExLlamaV2와 조합해 단일 요청 지연(latency)이 중요한 인터랙티브 애플리케이션에서 강점을 발휘합니다. INT4 양자화는 대부분의 태스크에서 품질 손실이 실사용 수준에서 감지하기 어려울 정도로 작으며, 메모리는 FP16 대비 4배 가까이 절약됩니다.
적용 판단 기준
로컬 추론 환경을 처음 시작한다면 Ollama + GGUF Q4_K_M 조합이 가장 빠른 시작점입니다. 팀 내 API 서버를 운영해야 한다면 vLLM + AWQ가 기본 선택이 됩니다. 지연 시간보다 처리량이 중요한 배치 처리 워크로드도 vLLM이 유리합니다. 반면 마이크로서비스 형태의 단일 사용자 인터랙티브 챗봇이라면 GPTQ + ExLlamaV2가 체감 속도 면에서 더 나은 결과를 줄 수 있습니다. 어떤 포맷을 선택하든, 운영 전에 대상 도메인의 벤치마크로 품질을 검증하는 과정은 생략할 수 없습니다. 양자화 수준이 높아질수록 추론 속도와 메모리 효율은 올라가지만 품질 리스크도 함께 올라가며, 이 균형을 데이터로 확인하는 것이 신뢰할 수 있는 서비스의 출발점입니다.