모델 커스터마이징

커스터마이징

파운데이션 모델의 한계와 5가지 대응 기법

파운데이션 모델의 4대 한계

범용 모델이 프로덕션에서 부딪히는 근본적 문제

5가지 기법 스펙트럼

비용이 낮은 순서대로 시도 — 대부분은 프롬프트 엔지니어링 + RAG로 충분

의사결정 흐름

항상 비용이 낮은 방법부터 시도

1. 1
   프롬프트로 해결?

   프롬프트 최적화 (DSPy/GEPA) — GEPA는 GRPO를 평균 6%·최대 20% 능가 (ICLR 2026)

2. 2
   RAG로 해결?

   검색으로 최신/도메인 정보 주입 — 대부분의 환각 문제 해결

3. 3
   포맷/톤 필요?

   SFT — 1K~10K 데이터로 응답 형식 각인

4. 4
   안전성/정렬?

   DPO/GRPO — 선호 쌍 또는 검증 가능 보상으로 정렬

5. 5
   도메인 지식?

   CPT — 수십억 토큰 비레이블 코퍼스, 최후 수단

SFT와 LoRA

행동을 각인하는 가장 표준적인 경로

SFT 동작 원리

Instruction-Response 쌍으로 모델의 행동을 각인

1. 1
   데이터 준비

   (Instruction, Response) 쌍 1K~10K 고품질 샘플 — JSONL 포맷

2. 2
   LoRA 적용

   전체 가중치의 0.1~1%만 학습 — rank 16~64, 메모리 대폭 절감

3. 3
   학습

   단일 GPU(H100) 수 시간 — 에포크 1~3, lr 1e-5~5e-5

4. 4
   평가

   홀드아웃 세트에서 정확도·포맷 일치율 측정 → 배포 결정

Full FT vs LoRA vs QLoRA

파라미터 효율적 학습으로 비용을 대폭 절감 — 표의 메모리·시간은 규모 가늠용 예시

SFT 데이터 포맷

Bedrock Fine-tuning이 요구하는 JSONL 형식

{"system": "AWS 비용 분석 전문가. JSON으로 답변.",
 "messages": [
   {"role": "user", "content": "지난달 EC2 비용 알려줘"},
   {"role": "assistant", "content": "{\"service\": \"EC2\", \"cost\": 1234.56, \"change\": \"+12%\"}"}
 ]}
{"system": "AWS 비용 분석 전문가. JSON으로 답변.",
 "messages": [
   {"role": "user", "content": "S3 비용 추이 보여줘"},
   {"role": "assistant", "content": "{\"service\": \"S3\", \"cost\": 89.12, \"change\": \"-3%\"}"}
 ]}

Bedrock Fine-tuning API

CreateModelCustomizationJob — S3에 데이터 올리고 API 한 번 호출

import boto3

# ① 컨트롤 플레인 "bedrock" 클라이언트로 잡 생성 (bedrock-runtime 아님)
client = boto3.client("bedrock", region_name="us-east-1")

response = client.create_model_customization_job(
    jobName="cost-analyst-sft",
    customModelName="cost-analyst-v1",
    roleArn="arn:aws:iam::123456789012:role/BedrockFTRole",
    # ② 베이스 모델 + 커스터마이징 유형 선택
    baseModelIdentifier="amazon.nova-pro-v1:0",
    customizationType="FINE_TUNING",
    # ③ 학습 데이터(JSONL)와 출력 경로는 S3 URI — roleArn에 접근 권한 필요
    trainingDataConfig={
        "s3Uri": "s3://my-bucket/training.jsonl"
    },
    outputDataConfig={
        "s3Uri": "s3://my-bucket/output/"
    },
    # ④ 하이퍼파라미터는 모두 문자열로 전달
    hyperParameters={
        "epochCount": "3",
        "learningRate": "0.00001",
    },
)

Bedrock Fine-tuning 옵션

관리형 학습 · Nova Forge · RFT

Alignment

보상 모델을 지워온 정렬의 역사

Alignment 진화

보상 모델을 단계적으로 제거하며 단순화

DPO — 실전 적용

chosen/rejected 쌍 5K~50K로 인간 선호에 정렬

RLHF vs DPO vs GRPO

상황에 맞는 정렬 기법 선택

CPT와 Distillation

지식을 넣는 기법과 비용을 줄이는 기법

CPT (Continued Pre-Training)

수십억 토큰 비레이블 코퍼스로 모델의 도메인 지식을 확장

Knowledge Distillation

Teacher(대형) → Student(소형) — 성능 유지 · 비용 절감

1. 1
   Teacher 선택

   대형 모델(Nova Premier, Llama 3.1 405B 등)이 고품질 응답 생성 — Bedrock은 동일 프로바이더 페어링만

2. 2
   합성 데이터 생성

   Teacher가 도메인 질문에 대한 응답 수만~수십만 건 생성

3. 3
   Student 학습

   소형 모델(Nova Lite·Micro 등)을 Teacher 응답으로 SFT

4. 4
   배포

   Student 모델로 프로덕션 서빙 — 비용 최대 75% 절감 (AWS 공식, 정확도 손실 2% 미만)

의사결정과 파이프라인

데이터·비용·자동화 세 축

데이터 규모 가이드

기법별 필요 데이터 양과 형식

비용 순위

항상 비용이 낮은 기법부터 시도 — 금액은 규모 가늠용 예시

1. 1
   프롬프트 엔지니어링 (무료)

   프롬프트만 수정. 인프라 비용 $0. DSPy/APO로 자동 최적화하면 SFT급 성능 가능.

2. 2
   RAG (인프라)

   벡터 DB + 임베딩 모델 운영비. 모델 학습 비용 없음. OpenSearch Serverless 기준.

3. 3
   SFT — QLoRA (GPU)

   단일 H100 수 시간. unsloth 사용 시 7B~70B 모델. 약 $10~100/run.

4. 4
   DPO/GRPO (GPU+)

   SFT 이후 추가 학습. 데이터 수집 비용 추가. 약 $50~500/run.

5. 5
   CPT (클러스터)

   다중 GPU 수 일~수 주. 수천 달러~수만 달러. HyperPod 권장.

프로덕션 파이프라인

SageMaker AI로 학습→평가→배포 자동화

대부분은 프롬프트로 충분

프롬프트 엔지니어링 → RAG → SFT → DPO → CPT — 안 될 때만 가중치를 건드리는 비용 순서