커스텀 모델
Bedrock에서 커스텀 모델을 생성하고 배포하는 실전 가이드
Amazon Bedrock 커스텀 모델
SFT · RFT · Distillation · Custom Import · 운영
파인튜닝도 관리형으로
CustomizationJob API로 SFT·RFT·Distillation 실행과 모델 배포
Bedrock 커스터마이징 개요
4가지 방법 · 비교 · 선택 가이드
Bedrock 커스터마이징
관리형 커스터마이징의 전체 지도 — 방식별 위치
현행 3종 + Import
학습은 SFT · RFT · Distillation 3종이 현행 — 외부에서 학습한 모델은 Custom Import로 반입합니다.
- SFT — 지시·응답 쌍으로 태스크 특화
- RFT — 보상 함수 기반 강화학습 (GRPO)
- Distillation — Teacher→Student 비용 절감
- Custom Import — 외부 모델 반입 · On-demand 서빙
CPT(Continued Pre-training)는 Titan Text 전용의 구세대 방식으로 현행 커스터마이징 목록에서 빠졌습니다 — 신규 설계는 3종 중에서 고릅니다.
4가지 커스터마이징 방법
Bedrock이 제공하는 관리형 커스터마이징 옵션
SFT (Supervised Fine-tuning)
Instruction-Response 쌍으로 태스크 특화 — 소량 고품질 데이터
RFT (Reinforcement Fine-tuning)
보상 함수 기반 강화학습(GRPO) — 검증 가능한 정답이 있는 태스크 최적화
Knowledge Distillation
Teacher→Student 자동 증류 — invocation 로그 활용, 비용 최대 75% 절감(AWS 공식)
Custom Model Import
외부 학습 모델을 Bedrock에 올려 서빙 — SageMaker/HuggingFace 연계
선택 가이드
데이터 유형과 목표에 따른 의사결정
-
1
태스크 특화 필요?
SFT 선택. 라벨된 지시-응답 쌍으로 원하는 출력 형식과 태스크 정확도를 학습. 소량 고품질 데이터로 충분.
-
2
정답이 검증 가능?
RFT 선택. 채점 코드나 judge 모델이 정답 여부를 판정할 수 있는 태스크(수학·코드·분류)라면 보상 기반 강화학습으로 라벨 없이도 정확도를 끌어올림.
-
3
비용 절감이 목표?
Distillation 선택. Teacher 모델의 지식을 소형 Student 모델로 전이. invocation 로그 활용으로 추론 비용 최대 75% 절감(AWS 공식).
-
4
외부 모델 활용?
Custom Import 선택. SageMaker·HuggingFace 등 외부에서 학습한 모델을 Bedrock에 반입. Converse API로 동일 인터페이스 서빙.
태스크 특화는 SFT, 검증 가능한 정답은 RFT, 비용 절감은 Distillation, 외부 모델은 Import — 데이터 유형과 목표가 답을 정합니다.
Reinforcement Fine-tuning
보상 기반 최적화 · GRPO · 검증 가능한 정답
RFT
정답이 검증 가능한 태스크를 보상으로 최적화하는 방식 — 세 가지 구성 요소
라벨 대신 보상
프롬프트당 여러 응답을 생성해 상대 비교로 학습하는 GRPO 강화학습입니다 — 채점 가능한 태스크라면 라벨 없이도 정확도를 끌어올립니다.
- GRPO — Group Relative Policy Optimization
- 보상 함수 2방식 — Lambda 채점 코드(RLVR) · Model as judge(RLAIF)
- 지원 모델 — Nova 2 Lite(us-east-1) · gpt-oss-20B · Qwen3 32B(us-west-2)
수학·코드·분류처럼 정답이 검증 가능한 태스크가 RFT의 자리입니다 — 보상 함수가 라벨을 대신합니다.
RFT 데이터와 설정
프롬프트 JSONL + 보상 함수 → CreateModelCustomizationJob(REINFORCEMENT_FINE_TUNING) 호출
데이터 포맷
messages배열 +reference_answer필드- 최대 20K 프롬프트 — 100~200건으로 시작 권장
- invocation 로그 제공 시 자동 변환
핵심 설정
rftConfig.graderConfig.lambdaGrader— 보상 함수trainingSamplePerPrompt— 프롬프트당 샘플 수reasoningEffort: low · medium · highepochCount·batchSize·learningRate
{"messages": [{"role": "user", "content": "질문"}],
"reference_answer": "채점 기준이 되는 정답"}
- "messages" — 프롬프트만 제공, 응답은 학습 중 모델이 생성 (SFT와 달리 모범 답변 라벨 불필요)
- "reference_answer" — 보상 함수(Lambda 채점 코드 · Model as judge)가 참조하는 채점 기준
open-weight 모델(gpt-oss-20B·Qwen3 32B)은 OpenAI 호환 fine-tuning API 별도 경로를 사용합니다 — 학습 완료 후 별도 배포 없이 즉시 추론 가능합니다.
Supervised Fine-tuning
태스크 특화 · 입출력 쌍 학습
SFT
입력·출력 쌍으로 스타일과 태스크를 학습시키는 표준 경로
지시·응답 쌍으로 각인
system + messages 구조의 JSONL로 원하는 출력 형식과 태스크 정확도를 학습합니다 — 소량 고품질 데이터로 충분합니다.
- JSONL — system + messages 지시·응답 쌍
- 훈련/검증 파일 분리 — 과적합 조기 탐지
- 최소 예제 수 모델별 — 100~200건
- LoRA — 일부 모델 자동 적용
데이터는 소량 고품질이 기준입니다 — 모델별 최소 예제 수(100~200건)만 넘기면 시작할 수 있습니다.
SFT 데이터와 설정
훈련·검증 파일 분리로 과적합 조기 탐지
데이터 포맷
- 훈련 파일 + 검증 파일 분리
- 최소 예제 수는 모델별 상이 — Nova 권장 100 · Nova 2 최소 200
핵심 하이퍼파라미터
epochCount: 1~5 (Nova 기준 — 모델별 상이)batchSize: 모델별 상이 (Nova는 미노출)learningRate: 1e-6~1e-4 (Nova 기준)learningRateWarmupSteps: 0~100 (Nova 기준)- LoRA: 일부 모델 자동 적용
{"system": "시스템 지시", "messages": [
{"role": "user", "content": "질문"},
{"role": "assistant", "content": "답변"}
]}
- "system" — 추론 시 쓸 시스템 지시를 예제와 함께 각인 (선택)
- "messages" — user 질문 + assistant 모범 답변 쌍, 이 구조 한 줄이 JSONL 예제 1건
- "assistant" — 모델이 따라 배우는 정답 라벨 — RFT와 달리 모범 답변을 직접 제공
Knowledge Distillation
Teacher→Student · 비용 최대 75% 절감(AWS 공식)
Distillation
Teacher의 품질을 Student의 가격으로 — 증류의 구조
Teacher의 품질을 Student의 가격으로
Teacher invocation 로그를 자동 활용해 별도 레이블링 없이 소형 Student를 학습합니다.
- Teacher — Nova Pro·Premier · Llama 3.1 405B 등 동일 프로바이더 상위 모델 (Anthropic 현재 비가용)
- invocation 로그 — 자동 학습 데이터화 · 레이블링 불필요
- Student — Nova Lite·Micro 등 동일 프로바이더 소형 모델
- 비용 — 최대 75% 절감 · 정확도 손실 2% 미만 (AWS 공식)
기존 API 호출 로그가 그대로 학습 데이터가 됩니다 — Teacher를 쓰던 워크로드일수록 시작이 쉽습니다.
Bedrock Distillation
Teacher invocation 로그를 자동 활용 — 별도 레이블링 불필요
-
1
Teacher 선택
Nova Pro·Premier 또는 Llama 상위 모델을 Teacher로 지정 (Anthropic 모델은 현재 비가용)
-
2
로그 수집
기존 API 호출 로그를 자동 학습 데이터로 활용
-
3
Student 학습
Nova Lite·Micro 등 동일 프로바이더 소형 Student에 지식 전이 실행
-
4
배포
커스텀 모델로 배포 → 추론 비용 최대 75% 절감(AWS 공식, 정확도 손실 2% 미만)
레이블 데이터 없이도 시작할 수 있습니다 — Production에서 Teacher를 쓰다가 충분한 로그가 쌓이면 Distillation을 실행합니다.
Custom Model Import & 운영
외부 모델 · 배포 · 평가
Import & 운영
외부 모델 반입부터 배포 후 품질 관리까지
반입하고, 서빙하고, 검증한다
외부에서 학습한 모델을 CreateModelImportJob으로 반입해 Converse API 동일 인터페이스로 서빙하고, Baseline 대비 품질을 검증합니다.
- Custom Import — SageMaker·HuggingFace 모델 반입
- On-demand 서빙 — CMU(Custom Model Unit) 과금
- Converse API — 다른 Bedrock 모델과 동일 인터페이스
- 평가 — Baseline vs Custom A/B · 회귀 테스트
어디서 학습했든 서빙 인터페이스는 Converse API 하나로 통일됩니다 — 배포 후에는 Baseline 대비 검증이 품질을 지킵니다.
Custom Model Import
외부에서 학습한 모델을 Bedrock에 올려 Converse API로 서빙
-
1
모델 준비
SageMaker/HuggingFace에서 학습한 모델 가중치를 S3에 저장
-
2
Import 실행
CreateModelImportJob API로 Bedrock에 등록
-
3
서빙 설정
On-demand로 즉시 호출 — CMU(Custom Model Unit) 단위 과금, 첫 추론 호출부터 5분 청구 윈도우
-
4
호출
Converse API로 동일하게 호출 — 다른 Bedrock 모델과 동일 인터페이스
S3에 가중치를 올리고 CreateModelImportJob을 호출하면 끝입니다 — 첫 추론 호출부터 CMU 단위 5분 청구 윈도우로 과금됩니다.
모델 평가와 운영
커스텀 모델 배포 후 프로덕션 품질 보장
평가 전략
- Baseline(원본 파운데이션 모델) vs Custom 비교
- 동일 테스트셋 기준 A/B 테스트
- MMLU·HellaSwag 회귀 테스트
- 도메인 특화 벤치마크 추가
운영
- On-demand 배포 또는 Provisioned Throughput — 모델·리전 조건에 따라 선택
- CloudWatch 메트릭 모니터링
- 모델 버전 관리 (v1, v2...)
- Rollback 전략 수립
원본 파운데이션 모델을 Baseline으로 A/B 비교하고 MMLU·HellaSwag 회귀 테스트로 성능 후퇴를 걸러냅니다 — Rollback 전략까지 세워야 운영이 완성됩니다.
Bedrock Fine-tuning 실습
CustomizationJob API로 SFT Fine-tuning을 실행합니다.
학습 목표
- JSONL 데이터 포맷 작성
- S3에 학습 데이터 업로드
- CreateModelCustomizationJob API 호출
- 학습 완료 후 커스텀 모델 평가
커스터마이징 파이프라인
데이터 준비부터 배포까지 전체 흐름
품질 평가를 통과한 모델만 Bedrock 배포로 넘어갑니다 — 데이터 준비부터 배포까지가 하나의 파이프라인입니다.
기법별 데이터 요구량
일반 ML 관점에서 본 기법별 데이터 규모 비교
| 기법 | 요구 규모 | 데이터 형태 |
|---|---|---|
| Continued Pre-Training (CPT) | 수십억 토큰 | 비라벨 도메인 코퍼스 전체 |
| SFT (Supervised Fine-Tuning) | 수천~수만 예시 | 고품질 라벨 (지시·응답 쌍) |
| DPO (Direct Preference) | 수백~수천 쌍 | 선호도 쌍 |
| RLVR (Verifiable Rewards) | 수백 건 | 검증 가능 문제+정답 |
| Multi-turn RL | 수십~수백 건 | 에피소드 |
Bedrock 관리형은 SFT·RFT·Distillation 3종입니다 — DPO·Multi-turn RL은 SageMaker AI 레시피로 학습한 뒤 Bedrock에 배포합니다.
커스터마이징 진화
프롬프트 → Fine-tuning → RL — 점진적 투자 확대 전략
Few-shot에서 시작해 SFT, DPO+RLVR, Multi-turn RL로 — 투자를 점진적으로 늘려가는 전략입니다.
커스터마이징 vs RAG
전략 선택의 기준 — 데이터·목표·예산
커스터마이징 (모델 변경)
- 모델 내부 지식/스타일 변경
- 1회 학습 → 영구 적용
- 데이터 + GPU 비용 (선투자)
- 적합: 도메인 특화 언어, 특정 포맷 생성
RAG (외부 지식 주입)
- 모델 변경 없이 컨텍스트 제공
- 실시간 업데이트 가능
- 검색 + 인덱싱 비용 (지속)
- 적합: 최신 정보, 대량 문서 참조
도메인 특화 언어·특정 포맷은 커스터마이징, 최신 정보·대량 문서 참조는 RAG가 적합합니다 — 선투자와 지속 비용의 선택입니다.
점진적 커스터마이징
프롬프트 → RAG → Fine-tuning — 투자 수준에 따라 깊이를 높이는 순서
프롬프트로 안 되면 RAG, RAG로 안 되면 Fine-tuning
투자 수준에 따라 커스터마이징 깊이를 점진적으로 높입니다
CustomizationJob · JSONL · GRPO · Distillation · Import · On-demand