양자화를 통한 생성 AI 모델 최적화 | James Harmison

dimohy · 8월 18, 2025, 11:46오후

최적화: 생성형 AI 모델의 양자화(Quantization) 활용 상세 요약

1. 개요

생성형 AI(Gen AI) 모델은 생산성 향상, 통찰 확보, 새로운 상호작용 서비스 구축을 위해 폭넓게 채택되고 있다. 그러나 (1) 규제 요구, (2) 비용 대비 가치 불균형, (3) 온프레미스/사내 가속기 재활용 필요성 때문에 자체 인프라에서의 고성능·고효율 추론이 중요해지고 있다. 오픈소스 LLM 생태계는 아키텍처/훈련 기법/파라미터 규모가 빠르게 변하며, 이러한 모델을 자체 하드웨어에서 효율적으로 운영하기 위한 핵심 기술 중 하나가 바로 양자화이다.

2. 문제 배경과 동인

2.1 모델 크기·정밀도 증가 추세

FP16 기반 대형 모델 확산, 더 긴 컨텍스트 윈도우 지원 → VRAM 소비 증가.
예시: Kimi K2 (FP8), Qwen3-235B-A22B-Instruct-2507 (FP16) 비교에서 파라미터 수가 적어도 데이터 타입 차이와 컨텍스트 윈도우로 실제 메모리 요구가 커질 수 있음.

2.2 자원 한정과 성능 요구

고정된 GPU 풀에서 더 큰(또는 더 긴 컨텍스트) 모델을 동일한 처리량으로 운영하기 어려움.
KV Cache 메모리 요구 증가가 병목이 됨.

2.3 비용 및 규제

외부 클라우드 위탁 실행은 초기 진입은 빠르나 장기 비용·규제 제약 발생.

3. 양자화(Quantization) 개념

3.1 정의

모델 파라미터(가중치 등)를 더 적은 비트를 사용하는 다른 데이터 타입으로 재해석하여 VRAM 사용량과 추론 비용을 절감하는 기법.

3.2 메모리 효과 (예시)

FP16: 1 파라미터 = 2바이트 → 8B 모델 ≈ 15GiB (순수 가중치)
FP8 변환 시 ≈ 7.5GiB → 남는 7.5GiB를 KV Cache 등에 활용 가능 → 병렬 처리 및 처리량 향상 기여.

3.3 주요 이점

메모리 풋프린트 감소
성능 개선: TTFT(Time-To-First-Token), TPS(Tokens-Per-Second) 향상 (특히 출력 토큰 처리량)

3.4 주의점

하드웨어가 해당 데이터 타입을 네이티브 가속 지원해야 함. (예: Kimi K2 FP8은 최신 Hopper 세대 GPU 요구)
정밀도(precision) 감소 → 훈련 시 활용되던 미세한 정보 손실 가능 → 정확도 하락 우려
목표: 성능 향상 + 허용 가능한 정확도 손실(예: Red Hat AI Hugging Face 저장소 내 양자화 모델은 LLM Compressor 사용, 기준 정확도 99% 이상 회복)

4. 도구 소개: LLM Compressor 및 vLLM

4.1 LLM Compressor

vLLM 프로젝트 일부로 통합
Weight / Activation / Weight-only 등 다양한 양자화 알고리즘
Hugging Face 모델과 연동, 매우 큰 모델 포함 지원
vLLM과 호환되는 compressed-tensors 포맷 생성

4.2 Red Hat AI Inference Server

Enterprise-grade vLLM 배포 포함
검증된 제3자 생성형 AI 모델 저장소와 연동 (예: Granite 계열)
Open Source Assurance: 특정 포함 모델 사용 시 지적재산권 면책 (현재 IBM Granite 3.1 언급)

5. Granite 3.3 모델 사례 분석

5.1 Granite 3.3 특징

Granite 3.1 대비 여러 벤치마크에서 높은 성능
Fill-in-the-Middle(FITM) 1급 지원 등 새로운 활용 가능성
구조적 급격한 변화는 아니나 기능·성능 향상
아직 검증된 제3자 모델 저장소/공식 지원 범위 밖 (Granite 3.1은 지원, 3.3은 대기 상태)

5.2 목표

공개된 Granite 3.1 8B INT8 양자화 레시피를 Granite 3.3 8B에 응용하여 성능·메모리 효율 확보.

6. 실험 환경 요약

6.1 하드웨어·플랫폼

AWS EC2 g6.2xlarge (NVIDIA L4 24GiB VRAM, 8 vCPU, 32GiB 메모리)
RHEL 9.6 + NVIDIA GPU Driver (Compute-only Open Kernel Modules 지침 기반 설치)

6.2 Python 환경 구성 (uv 활용)

requirements.txt:

--extra-index-url https://download.pytorch.org/whl/cu128
datasets==4.0.0
llmcompressor==0.6.0
transformers==4.52.0
vllm==0.9.2
lm-eval[vllm]==0.4.9
guidellm==0.2.1

가상환경 & 설치:

uv venv --system-site-packages --python 3.12 --seed .venv
source .venv/bin/activate
uv pip install --index-strategy unsafe-best-match -r requirements.txt

7. 기본 추론 실행 (FP16 원본 모델)

7.1 초기 실행

export HF_HOME="${PWD}/huggingface"
vllm serve ibm-granite/granite-3.3-8b-instruct

→ KV Cache 메모리 부족 오류: 최대 시퀀스 길이(131072) 대비 필요 KV Cache 20.00 GiB > 사용 가능 4.06 GiB.

7.2 컨텍스트 윈도우 축소 후 재시도

vllm serve --max-model-len=16384 ibm-granite/granite-3.3-8b-instruct

7.3 기능 확인 (OpenAI 호환 API)

curl http://localhost:8000/v1/models | jq .
curl -H 'Content-Type: application/json' http://localhost:8000/v1/chat/completions -d '{"model": "ibm-granite/granite-3.3-8b-instruct", "messages": [{"role": "system", "content": "You are a helpful assistant named Steve."},{"role": "user", "content": "Hey! My name is James. What is yours?"}]}' | jq .

8. INT8 양자화 수행

8.1 스크립트 실행

Granite 3.1 INT8 레시피 기반 quantize.py 수정 후:

python ./quantize.py

8.2 결과

quantized/granite-3.3-8b-instruct-quantized.w8a8 생성
디렉터리 비교(du -sh): 원본 대비 약 절반 크기 (INT8 데이터 타입 반영)

9. 정확도 평가 (lm-eval, GSM8K)

9.1 원본 FP16 평가

lm_eval --model vllm --model_args pretrained=ibm-granite/granite-3.3-8b-instruct,max_model_len=16384 --tasks gsm8k --num_fewshot 5 --batch_size auto

결과 (발췌): strict-match exact_match ≈ 0.6710

9.2 INT8 양자화 모델 평가

lm_eval --model vllm --model_args pretrained=./quantized/granite-3.3-8b-instruct-quantized.w8a8,max_model_len=16384 --tasks gsm8k --num_fewshot 5 --batch_size auto

결과: strict-match exact_match ≈ 0.6672

9.3 정확도 회복 비율

약 99.43% 수준(단일 런 변동 범위 내)
정확도 손실이 매우 제한적이며 INT8 이점 확보.

10. 성능 벤치마킹 (GuideLLM)

10.1 FP16 서버 기동

vllm serve --max-model-len=16384 ibm-granite/granite-3.3-8b-instruct

벤치마크:

while ! curl -L http://localhost:8000/v1/models >/dev/null 2>&1; do sleep 1; done
guidellm benchmark --target http://localhost:8000 \
	--rate-type sweep --max-seconds 30 \
	--output-path fp16.json \
	--data prompt_tokens=256,output_tokens=128

요약 (발췌): 동기(synchronous) 평균 TTFT ≈ 8.41ms, 특정 구간 Tot Tok/sec ≈ 183.8 / 918.7 등 (컨커런시별 표 존재)

10.2 INT8 서버 기동

vllm serve --max-model-len=16384 --served-model-name=granite-3.3-8b-instruct-quantized.w8a8 ./quantized/granite-3.3-8b-instruct-quantized.w8a8

벤치마크:

while ! curl -L http://localhost:8000/v1/models >/dev/null 2>&1; do sleep 1; done
guidellm benchmark --target http://localhost:8000 \
	--rate-type sweep --max-seconds 30 \
	--output-path int8.json \
	--processor ./quantized/granite-3.3-8b-instruct-quantized.w8a8 \
	--data prompt_tokens=256,output_tokens=128

요약 (발췌): 동기 평균 TTFT ≈ 5.08ms (FP16 대비 약 40% 단축), Tot Tok/sec (특정 구간) 224.3 / 1121.0 등 → 응답 지연 개선 + 처리량 증가

10.3 해석

INT8: 첫 토큰 응답 더 빠름 → 사용자 체감 반응성 향상
높은 동시 요청에서 누적 지연 감소, ITL/TPOT 지표 개선 구간 존재
메모리 절감 → 더 큰 KV Cache 확보 → 스루풋 및 윈도우 확장 잠재력

11. 컨텍스트 윈도우 확장 활용

양자화 후 메모리 여유분을 활용해 FP16에서 불가능했던 더 큰 --max-model-len 설정 가능:

vllm serve --max-model-len=65536 --served-model-name=granite-3.3-8b-instruct-quantized.w8a8 ./quantized/granite-3.3-8b-instruct-quantized.w8a8

→ FP16 환경 제약(16384) 대비 4배 컨텍스트 달성 사례

12. 종합 정리 (Recap)

양자화는:

메모리 사용량 감소로 더 긴 컨텍스트 또는 더 높은 동시성 확보
TTFT/TPS 개선으로 추론 지연 단축
적절한 도구(LLM Compressor, vLLM, GuideLLM, lm-eval) 조합으로 반복 가능·검증 가능한 워크플로우 구성
정확도는 정량 평가(GSM8K 등)로 손실 범위 관리 → 본 사례에서 99%+ 회복

13. 단계별 실행 절차 요약

환경 준비: RHEL 9.6 + NVIDIA Driver + Python 가상환경 구성
종속 패키지 설치 (requirements.txt 기반)
원본 모델 FP16 추론 시도 → 컨텍스트 길이 조정(메모리 오류 해결)
quantize.py 활용 INT8 양자화 수행
크기 비교 및 산출물 확인
lm-eval(GSM8K)로 원본 vs 양자화 정확도 비교
GuideLLM 성능 벤치마크(FP16 & INT8) → TTFT/TPS 비교
필요 시 컨텍스트 윈도우 확장 재배포
결과 해석 및 활용 시나리오 확장

14. 실용적인 팁과 주의사항 (본문 근거 기반)

팁

컨텍스트 윈도우가 너무 커서 KV Cache 메모리 부족 시 --max-model-len 축소로 즉시 해결
양자화 후 남는 VRAM을 KV Cache에 활용하면 동시성·처리량 향상 가능
정확도 비교 시 동일한 max_model_len 등 환경 고정 → 순수 양자화 영향만 평가
평가 전 가동 중인 vLLM 서버 종료(lm_eval이 자체 관리)
벤치마크 전 API 준비 상태를 폴링하여 안정된 측정 확보

주의사항

하드웨어가 지원하지 않는 데이터 타입(FP8 등) 양자화 활용 금지
정밀도 감소 → 일부 벤치마크 지표 변동: 단일 지표만으로 판단하지 말고 다각적 검증 필요
공식 검증·지원 범위 밖 모델(Granite 3.3 등)은 지원·보증 수준 차이 인지

15. 코드·명령어 스니펫 (본문 등장 순 발췌)

이미 위 섹션들에 통합 제시 (requirements.txt, vllm serve, lm_eval, guidellm 등).

16. 학습 리소스 및 참고 항목 (본문에 언급된 것만)

LLM Compressor (vLLM 통합)
vLLM
Red Hat AI Inference Server
Red Hat AI Hugging Face Repository (양자화 모델 및 레시피)
IBM Granite 3.1 / Granite 3.3 모델
Kimi K2 LLM, Qwen3-235B-A22B-Instruct-2507
GuideLLM (성능 벤치마크 도구)
lm-evaluation-harness (lm_eval)
GSM8K 데이터셋
AWS EC2 g6.2xlarge (NVIDIA L4 24GiB)
RHEL 9.6

17. 결론

양자화는 정확도 유지(>99% 회복)와 성능/자원 최적화(메모리 절감, TTFT 및 TPS 개선, 컨텍스트 확장)를 동시에 달성한 실질적 수단으로 입증되었다. 체계적 절차(환경 준비→양자화→정확도 검증→성능 측정→컨텍스트 확장)를 통해 모델 운영 효율을 극대화할 수 있다. 후속 반복(Part 2 예고)에서는 다중 서버·클러스터 스케일 확장이 예고되어, 동일 원리의 대규모 오케스트레이션 가능성이 강조된다.