LLM Fine-tuning 인프라 가이드¶

Fine-tuning 방식과 인프라 선택을 위한 실무 가이드.

개요¶

LLM Fine-tuning은 목적과 리소스에 따라 접근 방식이 달라진다. 이 문서는 상황별 최적의 선택을 안내한다.

Fine-tuning 방식 비교¶

방식	VRAM 요구량	학습 속도	성능	적합한 상황
Full Fine-tuning	매우 높음 (80GB+)	느림	최고	충분한 GPU, 대규모 데이터
LoRA	중간 (24-48GB)	빠름	좋음	제한된 GPU, 도메인 적응
QLoRA	낮음 (8-16GB)	중간	양호	소규모 GPU, 실험/프로토타입
Adapter	낮음	빠름	양호	다중 태스크 전환 필요

상황별 선택 가이드¶

Case 1: 소규모 팀, 제한된 예산¶

추천: QLoRA + 클라우드 Spot 인스턴스

리소스: RTX 4090 (24GB) 또는 A10G
모델: 7B-13B 파라미터
데이터: 1K-10K 샘플

설정 예시:

# QLoRA 설정
lora_config = LoraConfig(
    r=16,
    lora_alpha=32,
    target_modules=["q_proj", "v_proj", "k_proj", "o_proj"],
    lora_dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM"
)

# 4-bit 양자화
bnb_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_compute_dtype=torch.bfloat16,
    bnb_4bit_use_double_quant=True
)

예상 비용: - AWS g5.2xlarge (A10G): $1.21/hour - 1000 스텝 학습: 약 2-3시간 → $3-4

Case 2: 엔터프라이즈, 민감한 데이터¶

추천: Full Fine-tuning + On-premise

리소스: H100 SXM5 80GB × 4-8
모델: 70B+ 파라미터
데이터: 100K+ 샘플

인프라 구성:

# DeepSpeed ZeRO-3 설정
{
  "zero_optimization": {
    "stage": 3,
    "offload_optimizer": {"device": "cpu"},
    "offload_param": {"device": "cpu"},
    "overlap_comm": true,
    "contiguous_gradients": true
  },
  "bf16": {"enabled": true},
  "gradient_accumulation_steps": 4
}

주요 고려사항: - 데이터 보안: VPC 내 격리 - 체크포인트 관리: S3/NFS 자동 백업 - 모니터링: Weights & Biases, MLflow

Case 3: 빠른 실험, 다중 도메인¶

추천: LoRA + Adapter Hub

리소스: A100 40GB
모델: 7B-13B 파라미터
데이터: 도메인별 1K-5K 샘플

장점: - 베이스 모델 1개 + 여러 Adapter - 런타임 Adapter 스위칭 가능 - 저장 공간 효율적

# 다중 Adapter 로드
model.load_adapter("legal_adapter", adapter_name="legal")
model.load_adapter("medical_adapter", adapter_name="medical")

# 추론 시 전환
model.set_active_adapters("legal")
response = model.generate(legal_prompt)

model.set_active_adapters("medical")
response = model.generate(medical_prompt)

데이터 준비 체크리스트¶

품질 기준¶

항목	최소 기준	권장 기준
샘플 수	500+	5,000+
평균 토큰 길이	100+	500+
중복 비율	<10%	<5%
라벨 일관성	90%+	95%+

전처리 파이프라인¶

def prepare_dataset(raw_data):
    # 1. 중복 제거
    data = remove_duplicates(raw_data)

    # 2. 품질 필터링
    data = filter_by_quality(data, min_tokens=100)

    # 3. 포맷 변환 (Chat Template)
    data = apply_chat_template(data, tokenizer)

    # 4. 토큰화 + 패딩
    tokenized = tokenizer(
        data["text"],
        truncation=True,
        max_length=2048,
        padding="max_length"
    )

    return tokenized

학습 모니터링¶

핵심 메트릭¶

메트릭	정상 범위	이상 징후
Train Loss	점진적 감소	급격한 스파이크
Eval Loss	Train과 유사	Train보다 훨씬 높음 (과적합)
Gradient Norm	0.1-10	>100 (Exploding)
Learning Rate	스케줄 따름	비정상적 변동

조기 종료 기준¶

early_stopping = EarlyStoppingCallback(
    early_stopping_patience=3,
    early_stopping_threshold=0.01
)

서빙 전환¶

LoRA → Merged Model¶

# Adapter 병합
merged_model = model.merge_and_unload()

# 양자화 후 저장
merged_model.save_pretrained("merged_model", safe_serialization=True)

최적화 옵션¶

방식	지연시간	처리량	권장 상황
vLLM	최저	최고	프로덕션
TensorRT-LLM	매우 낮음	매우 높음	NVIDIA 전용
llama.cpp	낮음	중간	Edge/로컬
ONNX Runtime	중간	중간	크로스플랫폼

비용 최적화¶

클라우드 전략¶

1. Spot 인스턴스 활용 (60-80% 절감)
2. 체크포인트 자동 저장 (중단 대비)
3. 필요 시에만 GPU 할당 (Kubernetes + GPU Operator)

On-premise ROI 계산¶

월 클라우드 비용 > H100 감가상각/12 + 전기료 + 운영비
→ On-premise 전환 고려

손익분기점 예시: - H100 SXM5: ~$30,000 - 감가상각 (3년): $833/월 - 전기료 (700W × 24h × 30d × $0.1): ~$50/월 - AWS p5.48xlarge: ~$98/hour → $70,560/월 (24/7 기준)

요약¶

상황	추천 방식	인프라
실험/프로토타입	QLoRA	클라우드 Spot
프로덕션 (일반)	LoRA	클라우드 Reserved
프로덕션 (민감 데이터)	Full FT	On-premise
다중 도메인	LoRA + Adapter	클라우드/하이브리드