18. 훈련 파이프라인 (SFT → PPO)
이 문서는 LLM 파인튜닝의 전체 훈련 순서를 설명합니다. 각 훈련 타입(SFT → DPO/ORPO → RM → PPO)을 어떤 순서로, 왜 진행하는지, 그리고 실전에서 조합할 수 있는 경로를 구체적으로 안내합니다.
1. 전체 그림
┌───────────────────────────────────────────────────┐
│ 기초 능력 부여 │
│ │
│ pretrain (선택) → SFT (필수 시작점) │
│ ──────────── ───────────── │
│ raw text로 instruction-following │
│ 언어 모델링 능력 부여 │
└─────────────────────┬─────────────────────────────┘
│
┌───────────────┼───────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ DPO │ │ ORPO │ │ RM │
│ │ │ │ │ │
│ 선호 직접 │ │ SFT+선호 │ │ 보상모델 │
│ 최적화 │ │ 통합 │ │ 학습 │
└────┬─────┘ └──────────┘ └────┬─────┘
│ │
│ 최종 모델 │
│◄─────────────────────────────┘
│ │
▼ ▼
┌──────────┐ ┌──────────┐
│ 배포/벤치 │ │ PPO │
│ │ │ (RLHF) │
└──────────┘ └────┬─────┘
│
┌──────────┐
│ 배포/벤치 │
└──────────┘
2. 각 훈련 타입의 역할
| 훈련 타입 | 입력 데이터 | 학습 목표 | 비유 |
|---|---|---|---|
| SFT | prompt + response 쌍 | "이런 질문에 이렇게 대답해" 패턴 학습 | 교과서로 공부 |
| DPO | prompt + chosen/rejected 쌍 | 좋은 응답 선호 확률 높이기 (reference 모델 대비) | 선생님이 "이게 더 나아"라고 알려줌 |
| ORPO | prompt + chosen/rejected 쌍 | SFT + 선호 학습을 한 번에 (reference 불필요) | 공부하면서 동시에 피드백 |
| RM | prompt + chosen/rejected 쌍 | 응답 품질 점수 예측 (스칼라 리워드) | 채점관 양성 |
| PPO | prompt + RM 점수 | 높은 리워드를 받는 응답 생성 전략 학습 (3모델: policy+RM+reference) | 채점관 피드백으로 반복 연습 |
DPO vs ORPO: 선호 학습 선택 가이드
DPO와 ORPO는 모두 선호 학습이지만 구조적으로 다릅니다:
| 항목 | DPO | ORPO |
|---|---|---|
| Reference 모델 | 필요 (adapter disable) | 불필요 |
| Forward 횟수 | 2회 (policy + reference) | 1회 |
| GPU 메모리 | 높음 (2× forward) | 낮음 (1× forward) |
| Loss 구조 | preference loss만 | SFT + preference 결합 |
| Handoff 호환 | 비호환 (LoRA frozen → loss 고정) | 호환 |
| MoE Phase 0 | reward=0 (정상, LoRA freeze 시) | sft_loss는 여전히 유효 |
권장: 단일 GPU + MoE 조합에서는 ORPO가 실용적 대안입니다. DPO는 충분한 GPU 메모리 + Handoff 미사용 시 선택하세요.
3. 권장 훈련 순서
경로 A: SFT → DPO (가장 일반적)
SFT (5,000 steps) → DPO (1,500 steps) → 배포
| 단계 | 목적 | 장점 |
|---|---|---|
| SFT | instruction-following 기초 | 모델이 질문에 대답하는 법을 배움 |
| DPO | 선호 정렬 | reference 모델(SFT) 대비 좋은 응답 선호. 별도 RM 불필요 |
장점: 가장 단순한 2단계 파이프라인. RM 학습 없이 직접 선호 최적화.
# Step 1: SFT
eulerforge train --preset configs/presets/qwen3.5_0.8b_dense_lora_sft.yml \
--set data.format=raw --set data.task=sft \
--set data.path=data/sft_10k_raw.jsonl \
--output-dir ./outputs/pipeline/dense_lora_sft
# Step 2: DPO (SFT 체크포인트 기반)
eulerforge train --preset configs/presets/qwen3.5_0.8b_moe_expert_lora_dpo.yml \
--set model_name=outputs/run_YYYYMMDD_HHMMSS/final \
--set data.format=raw --set data.task=prompted_preference \
--set data.path=data/dpo_10k_raw.jsonl
경로 B: SFT → ORPO (DPO의 실용적 대안 — 권장)
SFT (5,000 steps) → ORPO (2,000 steps) → 배포
| 단계 | 목적 | 장점 |
|---|---|---|
| SFT | instruction-following 기초 | |
| ORPO | SFT + 선호를 결합 | reference 모델 불필요. DPO보다 메모리 효율적 |
장점: DPO보다 메모리 효율적 — 2회 forward (policy + reference) 대신 1회. ORPO의 odds-ratio 방식이 reference 없이 선호 학습.
# Step 1: SFT (동일)
# Step 2: ORPO
eulerforge train --preset configs/presets/qwen3.5_0.8b_dense_lora_orpo.yml \
--set model_name=outputs/run_YYYYMMDD_HHMMSS/final \
--set data.format=raw --set data.task=preference \
--set data.path=data/dpo_10k_raw.jsonl
경고: SFT 없이 ORPO/DPO를 base 모델에 직접 적용하면 성능이 하락할 수 있습니다. Base 모델은 instruction-following 능력이 없으므로, preference 학습만으로는 기초 능력이 형성되지 않습니다. 소규모 데이터(10K 미만)에서는 반드시 SFT → ORPO/DPO 2단계로 진행하세요. ORPO 단독 적용은 50K+ 고품질 데이터가 있을 때만 고려하세요. 상세 분석: preference_training_analysis.md
경로 C: SFT → RM → PPO (풀 RLHF)
SFT (5,000 steps) → RM (2,000 steps) → PPO (1,000 steps) → 배포
| 단계 | 목적 | 장점 |
|---|---|---|
| SFT | instruction-following 기초 | |
| RM | 보상 모델 학습 | "좋은 응답이란 무엇인가"를 학습한 채점관 |
| PPO | 보상 최대화 정책 | RM이 높은 점수를 주는 응답 생성 전략 학습 |
장점: 가장 정교한 정렬. RM이 복잡한 선호 기준을 학습하면 PPO가 이를 활용하여 creative하면서도 align된 응답 생성.
단점: 3단계로 복잡. RM 품질이 PPO 결과에 직결. 불안정할 수 있음.
# Step 1: SFT
eulerforge train --preset configs/presets/qwen3.5_0.8b_dense_lora_sft.yml \
--set data.format=raw --set data.task=sft \
--set data.path=data/sft_10k_raw.jsonl
# Step 2: RM (SFT 체크포인트 기반)
eulerforge train --preset configs/presets/qwen3.5_0.8b_dense_lora_rm.yml \
--set model_name=outputs/sft_run/final \
--set data.format=raw --set data.task=preference \
--set data.path=data/dpo_10k_raw.jsonl
# Step 3: PPO (SFT policy + RM reward)
eulerforge train --preset configs/presets/qwen3.5_0.8b_dense_lora_ppo.yml \
--set model_name=outputs/sft_run/final \
--set training.reward_model.checkpoint_path=outputs/rm_run/final
경로 D: SFT → DPO → PPO (DPO로 초기 정렬 후 PPO로 미세 조정)
SFT (5,000 steps) → DPO (1,500 steps) → RM (2,000 steps) → PPO (500 steps) → 배포
장점: DPO로 대략적 선호 정렬 후, RM+PPO로 정교하게 미세 조정. 두 방식의 장점을 결합.
경로 E: SFT → ORPO → RM → PPO (ORPO 기반 풀 RLHF — DPO 대체 권장)
SFT (5,000 steps) → ORPO (2,000 steps) → RM (2,000 steps) → PPO (1,000 steps) → 배포
| 단계 | 목적 | DPO 경로 대비 장점 |
|---|---|---|
| SFT | 기초 능력 | 동일 |
| ORPO (DPO 대체) | SFT + 선호 결합 | 메모리 50% 절약, Handoff 호환, 단일 forward |
| RM | 보상 모델 | 동일 |
| PPO | RLHF 정책 | 동일 |
이 경로를 권장하는 이유: - DPO의 2× forward가 단일 GPU에서 OOM 위험 → ORPO는 1× forward로 해결 - MoE + Handoff 조합에서도 ORPO는 정상 작동 (reference model 불필요) - ORPO의 SFT loss가 선호 학습과 동시에 기초 능력을 유지
# Step 1: SFT
eulerforge train --preset configs/presets/qwen3.5_0.8b_dense_lora_sft.yml \
--set data.format=raw --set data.task=sft \
--set data.path=data/sft_10k_raw.jsonl
# Step 2: ORPO (DPO 대체)
eulerforge train --preset configs/presets/qwen3.5_0.8b_dense_lora_orpo.yml \
--set model_name=outputs/sft_run/final \
--set data.format=raw --set data.task=preference \
--set data.path=data/dpo_10k_raw.jsonl
# Step 3: RM
eulerforge train --preset configs/presets/qwen3.5_0.8b_dense_lora_rm.yml \
--set model_name=outputs/sft_run/final \
--set data.format=raw --set data.task=preference \
--set data.path=data/dpo_10k_raw.jsonl
# Step 4: PPO
eulerforge train --preset configs/presets/qwen3.5_0.8b_dense_lora_ppo.yml \
--set model_name=outputs/orpo_run/final \
--set training.reward_model.checkpoint_path=outputs/rm_run/final
4. 경로 비교표
| 경로 | 단계 | GPU 메모리 | 복잡도 | Handoff 호환 | 추천 상황 |
|---|---|---|---|---|---|
| A: SFT→DPO | 2 | 중 (2×fwd) | 낮음 | X | GPU 여유 + Handoff 미사용 |
| B: SFT→ORPO | 2 | 낮음 (1×fwd) | 낮음 | O | 단일 GPU 권장, MoE+Handoff 호환 |
| C: SFT→RM→PPO | 3 | 높음 | 높음 | O | 정교한 정렬 필요 시 |
| D: SFT→DPO→RM→PPO | 4 | 높음 | 최고 | X | 연구/실험용 |
| E: SFT→ORPO→RM→PPO | 4 | 중 | 높음 | O | 풀 RLHF + 메모리 효율 — DPO 대체 권장 |
5. 인젝션 전략과의 조합
모든 훈련 타입은 4가지 인젝션 전략과 자유롭게 조합됩니다:
| 인젝션 전략 | SFT | DPO | ORPO | RM | PPO |
|---|---|---|---|---|---|
dense_lora |
O | O | O | O | O |
mixture_lora |
O | O | O | O | O |
moe_expert_lora |
O | O | O | O | O |
native_moe_expert_lora |
O | O | O | O | O |
MoE 전략(mixture_lora, moe_expert_lora)과 DPO 조합 시 참고:
Phase 0에서 ["router"]만 학습하면 DPO의 reward_chosen/rejected가 0으로 나타납니다. 이것은 정상입니다 — LoRA가 freeze되면 policy와 reference가 동일한 출력을 생성하기 때문. Phase 1에서 LoRA가 활성화되면 정상적인 DPO 학습이 시작됩니다.
6. 데이터 형식 매핑
| 훈련 타입 | raw 데이터 task | 필수 필드 |
|---|---|---|
| SFT | sft |
text 또는 prompt+response |
| DPO | prompted_preference |
prompt, chosen, rejected |
| ORPO | preference |
chosen, rejected |
| RM | preference |
chosen, rejected |
| PPO | prompt_only |
prompt |
7. 실전 팁
7.1 SFT는 충분히
SFT가 부족하면 이후 선호 학습이 효과가 떨어집니다. 모델이 "질문에 대답하는 법"을 먼저 배워야 "어떤 대답이 더 좋은지"를 학습할 수 있습니다.
7.2 DPO vs ORPO 선택 기준
| 기준 | DPO 선호 | ORPO 선호 |
|---|---|---|
| GPU 메모리 | 여유 있음 | 제한적 |
| reference 모델 | 별도 관리 가능 | 관리 부담 줄이고 싶음 |
| 검증된 방법론 | O (더 많은 논문/실험) | 비교적 새로운 방법 |
| 한 번에 끝내고 싶음 | — | O (SFT+선호 통합) |
7.3 RM 품질이 PPO를 결정
PPO는 RM의 점수를 보상으로 사용합니다. RM이 잘못된 선호를 학습하면 PPO도 잘못된 방향으로 최적화됩니다. RM을 먼저 벤치마크로 평가한 후 PPO에 투입하세요.
7.4 체크포인트 체인 (자동 탐지)
각 단계의 체크포인트가 다음 단계의 입력:
SFT final/ → DPO의 model_name
SFT final/ → RM의 model_name
SFT final/ + RM final/ → PPO의 model_name + reward_model.checkpoint_path
자동 탐지: model_name에 EulerForge 체크포인트 경로를 지정하면, 자동으로 원본 base 모델을 탐지하여 올바르게 로드합니다. lora_info.json과 resolved_config.json을 기반으로 base 모델 → LoRA injection → 어댑터 가중치 복원 순서로 진행됩니다.
Injection 자동 override: 이전 체크포인트의 LoRA 구조(lora_r, lora_alpha, target_keywords, start_layer, num_layers 등)가 현재 config와 다를 경우, 체크포인트의 설정으로 자동 override됩니다. 예를 들어 SFT(lora_r=48) → DPO(lora_r=24) 파이프라인에서, DPO 단계는 자동으로 SFT의 lora_r=48을 사용합니다. 경고 로그가 출력됩니다.
# SFT 체크포인트를 직접 DPO model_name으로 지정 — base 모델은 자동 해석됨
# injection 설정(lora_r, lora_alpha 등)은 SFT 체크포인트에서 자동으로 가져옴
eulerforge train --preset configs/presets/qwen3.5_0.8b_dense_lora_dpo.yml \
--set model_name=outputs/sft/final
7.5 데이터 품질 > 데이터 양
특히 DPO/ORPO에서는 chosen과 rejected의 품질 차이가 명확한 데이터가 중요합니다. 둘의 차이가 미미하면 모델이 선호 방향을 학습하기 어렵습니다.
7.6 단일 GPU에서의 현실적 제약
| 모델 크기 | SFT | DPO | PPO | 권장 |
|---|---|---|---|---|
| ~0.8B (int4) | 가능 | 가능 | 가능 | batch_size=2~4 |
| ~2B (int4) | 가능 | batch_size=1 | 어려움 | grad_accum 증가 |
| ~4B+ | batch_size=1 | OOM 위험 | 불가 | ORPO로 대체 권장 |
DPO는 policy + reference 2회 forward가 필요하므로 SFT 대비 약 2배 메모리. 단일 GPU에서 큰 모델이면 ORPO(1회 forward)가 현실적 대안.
7.7 모델 크기별 권장 데이터 규모
LoRA(Hu et al., 2021)는 base 모델을 고정한 채 저랭크 어댑터만 학습하므로, 작은 모델에서는 빠른 반복 실험이, 큰 모델에서는 제한된 GPU에서도 도메인 적응이 가능합니다. QLoRA(Dettmers et al., 2023)는 4-bit 양자화를 통해 65B 모델도 단일 48GB GPU에서 미세조정 가능함을 보였습니다.
LIMA(Zhou et al., 2023)는 고품질 1K 데이터로 65B 모델의 정렬 효과를 보였지만, 이는 대형 모델의 “이미 있는 능력을 형식적으로 표면화”한 것이며, 작은 모델이나 멀티턴/안전성까지 포함하면 더 많은 데이터가 필요합니다. 데이터 규모는 “무조건 많을수록 좋다”가 아니라 모델 크기와 데이터 품질에 맞게 조절하는 것이 핵심입니다.
| 모델 크기 | 권장 SFT 데이터 | 권장 선호 데이터 (DPO/ORPO/RM) | 권장 PPO prompt pool | 권장 시작점 |
|---|---|---|---|---|
| 0.8B | 3K~10K | 1K~3K | 500~2K | dense_lora + SFT → ORPO |
| 2B | 8K~30K | 2K~8K | 1K~3K | dense_lora + SFT → ORPO |
| 3B~4B | 15K~60K | 5K~20K | 2K~5K | dense_lora/mixture_lora + SFT → ORPO |
| 7B~8B | 10K~80K | 8K~30K | 3K~8K | mixture_lora/moe_expert_lora + SFT → ORPO → RM |
| MoE형 | 도메인별 10K~50K | 도메인별 2K~10K | 도메인별 1K~3K | moe_expert_lora + phased SFT → ORPO |
7B~8B 참고: 고품질 curated 데이터라면 10K~50K로 충분합니다. 80K 이상은 다양한 멀티태스크/다국어 데이터를 포함할 때만 정당화됩니다.
해석 원칙
- 작은 모델은 데이터 양보다 포맷 일관성, 정답성, refusal 품질이 더 중요합니다.
- 큰 모델은 적은 고품질 데이터만으로도 형식 정렬이 되지만, enterprise에서는 커버리지 부족이 더 큰 리스크이므로 데이터 다양성을 함께 확보합니다.
- 선호 데이터는 SFT보다 적어도 되지만, chosen과 rejected의 차이는 더 분명해야 합니다. DPO와 ORPO 모두 선호 차이가 명확할수록 잘 작동합니다.
7.8 모델 크기별 실전 가이드
0.8B
이 구간은 짧고 안정적으로 포맷을 지키는 모델을 만드는 데 적합합니다. 분류, triage, 필드 추출, 간단한 QA, 응답 초안 생성 같은 작업으로 제한하세요.
- 인젝션:
dense_lora - SFT 데이터: 3K~10K / 선호 데이터: 1K~3K
- 권장 경로:
SFT → ORPO/ RM·PPO: 특별한 이유가 없으면 생략 - 작은 모델은 데이터가 늘수록 좋아지기보다, 잡음과 스타일 충돌에 더 취약합니다.
- 첫 실험은 3K 내외 고품질 SFT로 시작하고, 포맷 준수율이 낮을 때만 6K~10K로 확장하세요.
2B
Enterprise assistant의 최소 실전선입니다. 고객지원, 문서 요약, 분류, 규칙 기반 답변, 추출+설명 조합 작업에 적합합니다.
- 인젝션:
dense_lora, 필요 시mixture_lora - SFT 데이터: 8K~30K / 선호 데이터: 2K~8K
- 권장 경로:
SFT → ORPO/ DPO: GPU 여유가 있을 때 비교 실험용 - 하위 작업이 2~3개로 나뉘면
mixture_lora를 고려하세요 (예: 분류/요약/권고안 초안)
3B~4B
문서 분석, 코드 보조, 법률/특허/과학 QA처럼 한 단계 더 복합적인 작업이 가능합니다. 대부분의 enterprise PoC에서 가장 균형이 좋습니다.
- 인젝션:
dense_lora또는mixture_lora - SFT 데이터: 15K~60K / 선호 데이터: 5K~20K
- 권장 경로:
SFT → ORPO, 필요 시→ RM - 첫 실험은 15K~25K SFT와 5K 선호 데이터로 시작, bench 실패 유형을 본 뒤 확장 권장
- DPO는 가능하지만 reference forward 추가로 단일 GPU에서는 ORPO가 더 현실적
7B~8B
고난도 domain copilot, 긴 문서 처리, 과학/특허/법률/코드 reasoning 같은 고부가가치 PoC에 적합합니다.
- 인젝션:
mixture_lora또는moe_expert_lora - SFT 데이터: 10K~80K / 선호 데이터: 8K~30K
- 권장 경로:
SFT → ORPO → RM/ PPO: RM 성능이 검증된 뒤에만 적용 - 하나의 LoRA에 모든 업무를 몰아넣기보다, 업무/도메인 단위로 expert를 나누는 편이 나음
- PPO는 마지막 10~20% 튜닝용으로만 사용하세요
MoE형 4B~8B+
여러 specialist behavior를 한 모델 안에 담고 싶을 때 유용합니다.
- 인젝션:
moe_expert_lora또는native_moe_expert_lora - SFT 데이터: 도메인별 10K~50K / 선호 데이터: 도메인별 2K~10K
- 권장 경로:
SFT → ORPO → RM, 필요 시→ PPO - 도메인 경계가 흐리면 MoE 이점이 줄어듭니다
- router 학습이 불안정하면 PPO보다 먼저 routing 품질을 점검하세요
7.9 인젝션 전략별 선택 가이드
인젝션 전략은 “모델 크기”보다 업무 구조가 단일한지, 여러 expert로 분리되는지를 기준으로 선택합니다.
| 전략 | 가장 잘 맞는 상황 | 권장 모델 크기 | 기본 권장 경로 |
|---|---|---|---|
dense_lora |
단일 도메인, 빠른 baseline, 단일 task | 0.8B~4B | SFT → ORPO |
mixture_lora |
2~4개 하위 업무 혼합, 다부서 assistant | 2B~8B | SFT → ORPO → RM |
moe_expert_lora |
멀티도메인 specialist, expert 분할 명확 | 4B~8B+ | SFT → ORPO → RM → PPO |
native_moe_expert_lora |
MoE 백본 특성 활용 고급 실험 | 7B~8B+ | MoE full pipeline |
권장 기본값
- 첫 실험은 항상 dense_lora로 시작합니다.
- 하나의 모델이 분류/추출/요약/답변 초안을 동시에 해야 하면 mixture_lora를 검토합니다.
- 도메인별 데이터와 평가셋이 뚜렷이 분리되어 있으면 moe_expert_lora가 더 적합합니다.
- 작은 모델에 무리하게 MoE를 얹기보다, 먼저 dense baseline이 충분히 올라오는지 확인합니다.
7.10 SFT 단계 가이드
LIMA(Zhou et al., 2023)는 1K 고품질 데이터로 정렬 효과를 보였지만, 이는 65B 모델에서 “이미 있는 능력의 형식적 표면화(Superficial Alignment Hypothesis)”이며, 작은 모델에서는 더 많은 데이터가 필요합니다. 실전 enterprise 튜닝에서는 3K~10K 이상의 균질하고 형식이 정돈된 SFT 데이터가 안전합니다.
SFT 권장 데이터 구성 - 50~70%: 핵심 업무형 데이터 - 20~30%: edge case / refusal / uncertainty handling - 10~20%: 출력 포맷/톤/길이 제어용 canonical example
SFT 중단 기준 - dev prompt 100~300개에서 형식 준수율을 함께 확인 (validation loss만 보지 말 것) - 응답 길이만 길어지고 bench가 오르지 않으면 과적합/스타일 과주입을 의심 - 포맷 오류가 거의 사라지고 edge case 대응이 안정되면 다음 단계로 이동
7.11 ORPO / DPO 단계 가이드
DPO(Rafailov et al., 2023)는 별도 RM 없이 reference model과의 비교로 직접 선호 최적화합니다. ORPO(Hong et al., 2024)는 reference model 없이 SFT loss + odds-ratio 기반 선호 penalty를 한 단계에서 동시 최적화합니다.
ORPO에 대한 정확한 이해: ORPO 논문의 핵심 주장은 SFT→선호학습 2단계가 아닌, SFT와 선호를 동시에 수행하는 것입니다. 그러나 EulerForge에서는 SFT를 먼저 수행하여 기초 능력을 확보한 뒤 ORPO로 선호를 추가하는 2단계 방식을 사용합니다. 이는 소규모 데이터에서의 안정성을 위한 실용적 선택입니다.
DPO vs ORPO 기본 선택: DPO는 더 많은 연구/검증/커뮤니티 도구(TRL, NeMo-Aligner 등)를 거쳤습니다. ORPO를 EulerForge의 기본값으로 권장하는 이유는 단일 GPU 자원 제약 관점의 실용적 선택이며, 품질 우위를 주장하는 것은 아닙니다. GPU 여유가 있다면 DPO를 먼저 시도하는 것도 합리적입니다.
권장 선택 기준 - ORPO 우선: 단일 GPU / 큰 모델 / MoE 계열 / reference 관리 부담을 줄이고 싶을 때 - DPO 우선: GPU 메모리 여유 충분 / chosen/rejected 차이 매우 선명 / 검증용 비교 실험
좋은 preference pair의 조건 - 정답성 차이가 명확하다 - 근거 제시 여부가 다르다 - 길이 제어와 불확실성 표현이 다르다 - 단순 오타, 문장부호 차이만 있는 pair는 가능하면 제외
실전 권장량 - 0.8B~2B: 1K~8K pair - 3B~4B: 5K~20K pair - 7B~8B+: 8K~30K pair - MoE: 도메인별 2K~10K pair
7.12 RM 단계 가이드
InstructGPT(Ouyang et al., 2022)는 인간 선호 데이터로 RM을 학습한 뒤 PPO에 연결하는 3단계 RLHF를 확립했습니다.
RM을 쓰기 좋은 경우 - 정답성 외에 길이, 톤, 근거성, 안전성, 포맷을 함께 최적화해야 할 때 - ORPO/DPO만으로는 원하는 스타일 제어가 부족할 때 - PPO를 실제로 적용할 계획이 있을 때
RM 비권장 경우 - SFT 품질이 아직 불안정 / 선호 데이터 품질이 낮음 / PPO까지 갈 계획 없음
RM 권장량: 최소 5K~20K pair, task별 stratified split, hard negative 포함 권장
RM 체크포인트: reward score 분포 확인, chosen > rejected 정확도, task별 편향, 길이만 높게 주는 reward hack 여부
7.13 PPO 단계 가이드
PPO는 InstructGPT의 핵심 RLHF 구성요소이지만, DPO가 지적하듯 구현/튜닝 복잡성이 높습니다. 기본 경로가 아니라 마지막 미세 조정 단계로 접근하세요.
PPO를 적용할 조건 - SFT + ORPO/DPO 결과가 이미 충분히 안정적 - RM standalone 평가가 유의미 - 최적화 목표가 명확 (예: 짧고 근거 중심 답변, 과잉 확신 감소, 안전한 거절 강화)
PPO를 피할 조건: 포맷 오류 많음 / RM 품질 미검증 / 단일 GPU에서 메모리/시간 여유 부족
권장 시작점: 작은 모델은 가능하면 생략, 3B~4B는 짧은 실험만, 7B~8B/MoE는 RM 검증 후 제한적 적용
7.14 실전 추천 경로 요약
| 상황 | 권장 경로 |
|---|---|
| 24GB 단일 GPU, 0.8B~2B | dense_lora + SFT → ORPO |
| 48GB 단일 GPU, 3B~4B | dense_lora/mixture_lora + SFT → ORPO |
| 80GB 단일 GPU, 7B~8B | mixture_lora/moe_expert_lora + SFT → ORPO → RM |
| 80GB 이상, 연구형 실험 | SFT → ORPO → RM → PPO |
| 멀티도메인 specialist | MoE full pipeline, expert별 선호 정렬 |
7.15 권장 실험 순서
- SFT baseline — 형식 준수율, 장문화, 환각 비율 확인
- ORPO 1차 정렬 — 단일 GPU/대형 모델/MoE에서 기본 선택
- DPO 대조 실험 — GPU 메모리 여유가 있을 때만 수행
- RM — 다기준 품질 점수화가 필요할 때만 수행
- PPO — RM이 검증된 뒤 마지막 단계로만 수행
7.16 추가 실험 체크리스트
- 동일 SFT 체크포인트에서 ORPO vs DPO 비교
- 동일 데이터로 dense_lora vs mixture_lora 비교
- SFT 데이터 25% / 50% / 100% ablation
- preference 데이터에서 weak negative 제거 전후 비교
- RM standalone 품질이 낮으면 PPO 중단
- MoE 계열은 router confusion 및 expert별 bench를 분리 측정
7.17 참고 문헌
| # | 논문 | 핵심 기여 |
|---|---|---|
| 1 | Hong et al. (2024), ORPO: Monolithic Preference Optimization without Reference Model | Reference-free, SFT+선호 동시 최적화 |
| 2 | Dettmers et al. (2023), QLoRA: Efficient Finetuning of Quantized Language Models | 4-bit 양자화로 65B 단일 GPU 미세조정 |
| 3 | Hu et al. (2021), LoRA: Low-Rank Adaptation of Large Language Models | 저랭크 어댑터 기반 효율적 파인튜닝 |
| 4 | Rafailov et al. (2023), Direct Preference Optimization | RM 없이 직접 선호 최적화, RLHF 단순화 |
| 5 | Zhou et al. (2023), LIMA: Less Is More for Alignment | 1K 고품질 데이터의 정렬 효과 (Superficial Alignment Hypothesis) |
| 6 | Ouyang et al. (2022), Training language models to follow instructions with human feedback (InstructGPT) | SFT→RM→PPO 3단계 RLHF 파이프라인 확립 |
8. 실전 과제
아래 과제를 통해 실제 파이프라인을 처음부터 끝까지 경험할 수 있습니다.
| 과제 | 난이도 | 목표 | 문서 |
|---|---|---|---|
| 수학/코딩 강화 | 중급 | GSM8K/코드 데이터로 SFT→DPO | 20_lab_math_coding.md |
| Thinking 모델 | 고급 | <think> 추론 과정 출력 모델 |
21_lab_thinking_model.md |
| 한국어 대화 품질 | 초/중급 | 보유 데이터로 SFT→ORPO→Bench | 22_lab_korean_finance_copilot.md |
| 풀 파이프라인 MoE | 최고 | 4도메인 MoE + SFT→DPO→RM→PPO 전체 | 23_lab_full_pipeline_moe.md |
관련 문서
- 01_dense_lora.md — Plain LoRA SFT
- 05_dpo_training.md — DPO 상세
- 06_orpo_training.md — ORPO 상세
- 07_rm_training.md — Reward Model 상세
- 08_ppo_training.md — PPO (RLHF) 상세
- CLI 레퍼런스 — 훈련 타입별 CLI 옵션