26 KiB
26 KiB
한국어 LLM 전체 로드맵 & 의사결정 프레임워크
작성일: 2026-02-26
현재 상태: SFT 5,000 steps 완료 (loss 1.9677), 1.19B 파라미터 모델
목표: 실사용 가능한 한국어 LLM 배포
0. TL;DR — 지금 당장 할 일
- SFT 모델 빠른 생성 테스트 (30분, 오늘): temperature sampling으로 반복 퇴화 확인
- lm-eval-harness ko_ifeval + ko_winogrande 실행 (2~4시간): 숫자 확인
- 결과에 따라 분기 → 아래 의사결정 트리 참조
1. 현재 위치 파악
1.1 SFT 학습 현황 요약
| 항목 | 값 |
|---|---|
| Steps | 5,000 |
| Final Loss | 1.9677 |
| 학습 시간 | 0.61h (~37분) |
| 처리 속도 | ~75,700 tok/s (단일 B200) |
| LR (final) | 2.00e-06 (완전히 decay됨) |
| Gradient Norm | 안정 (1.0~1.4 범위) |
| SFT 데이터 | 알 수 없음 (확인 필요) |
주목: 5,000 steps는 매우 적은 양이다. SFT에서 보통 1~3 에폭을 돌리는데, 데이터셋 크기에 따라 steps 충분성이 결정된다.
1.2 업계 내 위치
벤치마크 기준 (Open Ko-LLM Leaderboard 실측치 기반 추정)
모델 규모 ko_ifeval ko_winogrande 비고
──────────────────────────────────────────────────────────────────────
EXAONE-3.0-7.8B-Instruct 7.8B ~55% ~80%+ 8T tokens, SFT+DPO
Llama-3.1-8B-Korean-SFT 8B ~40% ~72% Llama 기반 한국어 적응
SOLAR-10.7B-Instruct 10.7B ~50% ~78% 업스테이지
Gemma-2-9B-Korean 9B ~45% ~75% Google 기반
── 현실적 1B SFT 벤치마크 (타사 사례) ────────────────────────────────
dltjdgh0928/test_instruction ~?B 24.1% 57.1% 리더보드 실측
lookuss/test-llilu ~?B 22.9% 58.2% 리더보드 실측
generic 1B SFT (추정) 1~2B 20-30% 52-62% 현실적 범위
── 우리 모델 예상 ──────────────────────────────────────────────────────
korean_1b_sft (5k steps) 1.19B 15-28%? 50-58%? 평가 전 추정
핵심 격차 분석
| 비교 대상 | 파라미터 차이 | 예상 성능 격차 | 주요 이유 |
|---|---|---|---|
| EXAONE-3.0-7.8B | 6.6× | 매우 큼 | 규모 + 데이터 + DPO |
| 8B 한국어 SFT | 6.7× | 큼 | 규모 차이가 지배적 |
| 타사 1B SFT | 유사 | 작음~중간 | 데이터/학습 방법 차이 |
현실적 평가: 1B 모델은 7~10B 모델과 direct 경쟁이 불가능하다. 그러나:
- 엣지 배포 (로컬 서빙, 저지연 API): 1B가 명확한 우위
- 리소스 효율: 1B는 단일 GPU, 심지어 CPU에서도 구동
- 특화 도메인: 한국어 특화 fine-tuning으로 특정 태스크에서 대형 범용 모델 근접 가능
1.3 1B 규모의 한계와 가능성
현실적 한계:
- ko_ifeval 30% 초과 어려움 (instruction following 복잡도)
- 수학/코드: 사전학습 데이터 없으면 거의 불가
- 장문 맥락 이해: 4K context에서 degradation 시작
- 사실 기억: 세밀한 사실 저장 capacity 부족
가능한 것:
- 한국어 기본 QA, 요약, 분류
- 간단한 지시 따르기 (1~2단계)
- 한국어 자동완성, 교정
- 도메인 특화 태스크 (제한된 형식)
2. 단계별 로드맵
Phase 1: SFT 검증 (지금 → ~1주)
목표
SFT 5,000 steps 결과가 실사용 가능한 수준인지 판정
체크리스트
□ 1-1. 생성 품질 빠른 점검 (30분)
- temperature=0.8, top_p=0.9으로 10개 프롬프트 생성
- 체크: 반복 퇴화 비율 (목표: < 20%)
- 체크: 한국어 어미/조사 처리 자연스러운가
- 체크: instruction 따르는가 (base와 비교)
□ 1-2. 공식 벤치마크 (2~4시간)
- lm-evaluation-harness 설치 및 ko_ifeval 실행
- lm-evaluation-harness ko_winogrande 실행
- 선택: ko_gsm8k (수학 데이터 없으면 skip 가능)
□ 1-3. SFT 데이터 품질 점검
- SFT 학습에 사용된 데이터셋 확인
- 데이터 수 (몇 개 샘플인가?)
- 5,000 steps × batch_size = 총 토큰 수 산출
- 에폭 수 계산: epoch 2에 진입했으므로 최소 1 에폭 완료 확인됨
□ 1-4. Base vs SFT 비교
- 동일 프롬프트에 base (pretrained)와 SFT 결과 비교
- SFT가 instruction following 능력을 부여했는가?
Pass/Fail 기준 (수치화)
| 지표 | Pass ✅ | 경계선 ⚠️ | Fail ❌ |
|---|---|---|---|
| ko_ifeval (prompt strict) | > 25% | 15~25% | < 15% |
| ko_winogrande | > 53% | 50~53% | < 50% |
| 반복 퇴화율 (greedy) | < 20% | 20~40% | > 40% |
| temperature 샘플링 품질 | 자연스러움 | 어색함 | 무의미 |
| Base 대비 SFT 개선 | 명확한 instruction 따르기 | 미미한 개선 | 개선 없음/악화 |
참고: ko_winogrande 50%는 random (binary choice) 수준. 실질적 의미 있으려면 53%+.
실패 시 대응
- ko_ifeval < 15% + 반복 > 40%: SFT 데이터 문제 또는 steps 부족 → Phase 2A
- Base 대비 개선 없음: SFT 데이터 형식/품질 점검, 학습률 재검토
- 모든 지표 Fail: 데이터 파이프라인부터 재검토
Phase 2A: SFT 개선 (선택적, Phase 1 결과 기준)
언제 진입하는가?
Phase 2A 진입 조건:
├── ko_ifeval < 25% AND 반복 > 20% → 즉시 진입
├── ko_ifeval 25-30% AND 반복 20-30% → 데이터 보강 후 진입
└── ko_ifeval > 30% AND 반복 < 15% → Phase 2B 또는 4로 바로
옵션별 분석
옵션 A: Steps 증가 (5k → 10k~20k)
- 언제: 데이터는 충분하고 아직 수렴하지 않은 경우
- 확인 방법: Loss 곡선이 아직 하강 중인가? (5,000 steps에서 1.97 — 수렴 근접)
- 예상 효과: 소폭 개선 (loss 1.97 → 1.80 목표, ko_ifeval +3~7%p 예상)
- 비용: B200 1개 기준 1.5~3시간 추가
- 주의: 이미 epoch 2에 진입 — 과적합 위험 있음
옵션 B: 더 좋은 데이터
- 언제: 현재 SFT 데이터가 부족하거나 품질이 낮을 때 (가장 흔한 이유)
- 추천 데이터셋:
beomi/KoAlpaca-v1.1a— 21K 한국어 instructionHAERAE-HUB/KMMLU— 한국어 지식 QAnayohan/llama3-baseline-ko-dataset— 다양한 instructionsquarelike/sharegpt_deepl_ko_ko-en— ShareGPT 한국어- 합산 목표: 50K~200K 고품질 샘플
- 예상 효과: 데이터 품질 개선이 steps 2배보다 효과적 (경험적 법칙)
- 비용: 데이터 정제 1
2일, 학습 추가 26시간
옵션 C: ORPO (Odds Ratio Preference Optimization)
- 언제: SFT baseline 확보 후 preference 정렬이 필요할 때
- 장점: reference model 불필요 → 메모리 절약, 학습 단순화
- 한국어 데이터:
kuotient/orca-math-korean-preference(193K),heegyu/orca-math-korean-preference-cleaned(192K) 존재 - 예상 효과: 반복 퇴화 -10
20%p, instruction following +510%p - 비용: 데이터 준비 1일, 학습 3~6시간
옵션 D: DPO (Direct Preference Optimization)
- 언제: ORPO보다 더 강한 정렬이 필요할 때, 또는 SFT가 어느 정도 잘 됐을 때
- 장점: RLHF와 유사한 효과, PPO보다 안정적
- 단점: reference model 필요 (메모리 2×)
- B200에서 가능성: 1.19B × 2 = ~2.4B params — 단일 B200 183GB에서 충분
- 비용: 학습 4~8시간
권장 순서
데이터 점검 → 데이터 보강 (옵션 B) → Steps 추가 (옵션 A) → ORPO (옵션 C)
Phase 2B: 스케일업 — 3B 모델
데이터 충분성 분석
| 기준 | 필요 토큰 | 현재 보유 | 판정 |
|---|---|---|---|
| Chinchilla 최소 (20×) | 3B × 20 = 60B | ~150B | ✅ 충분 |
| Chinchilla 최적 (70×) | 3B × 70 = 210B | ~150B | ⚠️ 71% 수준 |
| Llama 방식 (고품질 집중) | 3B × 100 = 300B | ~150B | ❌ 부족 |
결론: 지금 데이터로 3B 학습 가능. 단, optimal은 아님. 고품질 데이터를 50B 추가 수집하면 optimal 근접.
예상 학습 시간 (8× B200 기준)
3B 모델 설정 추정:
- 처리 속도: ~2.5~3M tok/s (8× B200, 1.19B 기준 2.64M)
→ 3B 모델은 속도 ~40% 감소 예상 (메모리/연산 증가)
→ 실효 속도: ~1.6M tok/s (추정)
60B tokens (최소): 60B / 1.6M = 37,500초 ≈ 10.4시간
150B tokens (현재 보유 전량): 150B / 1.6M = 93,750초 ≈ 26시간
210B tokens (optimal): 210B / 1.6M = 131,250초 ≈ 36.5시간
→ 현실적 학습 기간: 1~2일 (8× B200)
3B 학습 준비사항
□ 모델 아키텍처 설정 변경:
- d_model: 2048 → 2560 (또는 3072)
- n_layers: 24 → 32
- n_heads: 16 → 32
- n_kv_heads (GQA): 4 → 8
- d_ffn: 5472 → ~8192
→ 예상 파라미터: ~3B
□ 데이터 준비:
- cc100 ko 재다운로드 (버그 수정 후)
- CulturaX 24.8B 활용
- 총 150B+ 토큰 한국어 데이터 병합
□ configs/korean_3b_fp8.yaml 작성
□ 체크포인트 저장 전략: 매 5,000 steps
□ FP8 설정 유지 (B200 최적화)
1B SFT 결과의 3B 진행 여부 영향
1B SFT 결과 → 3B 진행 여부
──────────────────────────────────────────────────────
ko_ifeval > 30% → 강력히 추천: 1B가 이미 좋음, 3B는 확실히 더 좋을 것
ko_ifeval 20-30% → 조건부 추천: 데이터/방법론 확인 후 3B
ko_ifeval < 20% → 3B 전에 원인 분석 필수: 같은 문제가 3B에도 재현됨
반복 퇴화 > 40% → 사전학습 데이터 문제 의심: 3B도 동일 문제 가능
SFT 개선 없음 → SFT 파이프라인 수정 후 3B
Phase 3: RLHF / Preference Optimization (선택적)
언제 필요한가?
| 시나리오 | 필요성 |
|---|---|
| 서비스 배포 (사용자 대면) | 강력히 필요 — safety, coherence |
| 리더보드 점수 극대화 | 필요 — DPO/ORPO로 +5~15%p |
| 내부 연구/실험 | 불필요 |
| RAG 시스템 백엔드 | 불필요 |
ORPO vs DPO vs PPO 비교
| 방법 | 언제 | 메모리 | 복잡도 | 한국어 데이터 |
|---|---|---|---|---|
| ORPO | SFT와 동시, 빠른 정렬 | 1× (ref 없음) | 낮음 | 193K+ 존재 |
| DPO | SFT 이후, 안정적 정렬 | 2× (ref 필요) | 중간 | 193K+ 존재 |
| SimPO | ref 없이 DPO 효과 | 1× | 중간 | 범용 적용 |
| PPO | RLHF 완전 구현 | 3~4× | 높음 | reward model 필요 |
B200 환경에서 추천: ORPO 또는 SimPO (reference model 없음, 메모리 효율)
한국어 Preference 데이터 현황 (HuggingFace)
kuotient/orca-math-korean-preference 193K 샘플 수학 중심
heegyu/orca-math-korean-preference-cleaned 192K 수학 (정제본)
lemon-mint/korean-realqa-reasoning-v01-preference 7.7K 추론
ChuGyouk/argilla-distilabel-math-preference-dpo-korean 2.4K 소규모
→ 수학 특화 데이터가 많음. 일반 한국어 preference는 부족.
→ 일반 preference는 자체 생성 또는 번역으로 보강 필요.
방법: GPT-4/Claude로 chosen/rejected 쌍 생성 (Self-Play)
Phase 4: 배포
서빙 옵션 비교
| 옵션 | 특징 | B200 적합성 | 추천 상황 |
|---|---|---|---|
| vLLM | PagedAttention, 고처리량 | ✅ 최우수 | API 서버, 배치 추론 |
| TGI (Text Generation Inference) | HF 공식, 안정적 | ✅ 우수 | HF Hub 연동 |
| llama.cpp + GGUF | CPU/저사양 가능 | ⚠️ B200에선 과소 | 엣지 배포, Ollama |
| Ollama | 로컬 배포 편의성 | ⚠️ | 개인 사용, 데모 |
B200 기준 vLLM 예상 throughput (1.19B 모델):
1.19B 모델 (BF16):
- 메모리: ~2.4GB (파라미터) + KV cache
- 단일 B200 183GB: KV cache 극대화 가능
- 예상 throughput: 5,000~15,000 tokens/s (배치 처리)
- 단일 스트리밍: 200~500 tokens/s (사용자 체감)
→ 동시 사용자 100~500명 지원 가능 (단일 GPU)
양자화 옵션 (B200 환경)
| 포맷 | 정밀도 손실 | 크기 | B200 적합성 | 추천 |
|---|---|---|---|---|
| FP8 (Native) | 없음 | 1.2GB | ✅ 최우수 (HW 지원) | 최우선 |
| BF16 | 없음 | 2.4GB | ✅ 기본 | 기준선 |
| AWQ (W4A16) | 매우 적음 | 0.6GB | ✅ 우수 | 엣지/저메모리 |
| GPTQ (W4) | 적음 | 0.6GB | ✅ 우수 | CPU 오프로드 |
| GGUF Q4_K_M | 적음 | ~0.7GB | ⚠️ (CPU용) | Ollama 배포용 |
B200 권장: FP8 → AWQ 순서로 고려. B200은 FP8 하드웨어 지원으로 양자화 없이 이미 효율적.
HuggingFace Hub 업로드
필요 작업:
□ HF 포맷 변환: config.json, model.safetensors, tokenizer_config.json
□ model card 작성 (한국어 설명, 벤치마크 결과, 사용법)
□ 라이선스 설정 (Apache 2.0 권장)
□ eval 결과 포함
□ Open Ko-LLM Leaderboard 제출 (평가 요청)
3. 의사결정 트리 (수치 기반)
══════════════════════════════════════════════════════════════════
[Phase 1: SFT 평가 결과]
══════════════════════════════════════════════════════════════════
├── ko_ifeval > 30% AND 반복율 < 15%
│ ├── 데이터 150B 모두 사용 가능? → Phase 2B (3B 사전학습)
│ └── 지금 당장 배포가 목표? → Phase 4 (vLLM 서빙 + HF 업로드)
│
├── ko_ifeval 20~30% AND 반복율 15~30%
│ ├── SFT 데이터가 < 10K 샘플? → Phase 2A-B (데이터 보강 최우선)
│ ├── SFT 데이터가 10~50K 샘플? → Phase 2A-A (steps 추가) + 2A-C (ORPO)
│ └── SFT 데이터가 > 50K 샘플? → Phase 2A-A (steps 추가) OR 2B (3B)
│
├── ko_ifeval 10~20% AND 반복율 30~50%
│ ├── base 모델과 SFT 차이 없음? → SFT 파이프라인 버그 점검
│ ├── SFT 데이터 품질 의심? → 데이터 전수 점검 후 Phase 2A-B
│ └── base PPL이 높음 (> 15)? → 사전학습 더 필요 (데이터 추가)
│
└── ko_ifeval < 10% OR 반복율 > 50%
├── base 모델 자체가 이미 반복 > 30%? → 사전학습 데이터 품질 문제
│ └── → cc100 노이즈 필터링 후 추가 사전학습
├── SFT loss가 발산했는가? → 학습률/optimizer 설정 재검토
└── 모든 생성이 무의미? → 체크포인트 손상 확인, 이전 체크포인트 복원
══════════════════════════════════════════════════════════════════
[Phase 2A 내부 의사결정]
══════════════════════════════════════════════════════════════════
Phase 2A 진입 후:
├── 현재 SFT 데이터 < 20K 샘플?
│ └── → 데이터 보강이 steps 추가보다 효과적 (최우선)
│ 데이터: beomi/KoAlpaca, squarelike/sharegpt_ko, nayohan/llama3-ko
│
├── loss curve가 아직 하강 중 (step 4000~5000 차이 > 0.05)?
│ └── → steps 2배 추가 시도 (10k까지)
│
├── 반복율 > 30% (주요 문제)?
│ └── → ORPO 또는 repetition penalty 적용 먼저
│ ORPO 데이터: kuotient/orca-math-korean-preference (193K)
│
└── ko_ifeval < 20% + 데이터 보강 후에도 개선 없음?
└── → 3B 사전학습으로 전환 (1B SFT 한계 도달 가능성)
══════════════════════════════════════════════════════════════════
[Phase 2B 내부 의사결정]
══════════════════════════════════════════════════════════════════
3B 사전학습 진행 결정 시:
├── 현재 150B 토큰이 한국어 단일 언어?
│ └── → 영어 데이터 10~30% 혼합 권장 (cross-lingual transfer)
│ 영어 수학/코드 포함하면 ko_gsm8k 등 추가 개선 가능
│
├── cc100 ko 데이터 수집 완료?
│ └── No → CulturaX 24.8B만으로 시작 가능 (60B 목표 달성 가능)
│
└── 3B 학습 중 중간 checkpoint에서 SFT 테스트?
└── → 1B보다 3B base가 SFT 반응성이 높으면 3B SFT로 바로 진행
══════════════════════════════════════════════════════════════════
[Phase 4 배포 의사결정]
══════════════════════════════════════════════════════════════════
배포 방식 선택:
├── 연구/데모 목적?
│ └── → HF Hub 업로드 + Gradio Space 생성 (무료)
│
├── 내부 API 서빙?
│ └── → vLLM (FP8 native) + OpenAI 호환 엔드포인트
│ 커맨드: vllm serve ./checkpoints/korean_1b_sft --dtype fp8
│
├── 개인/팀 로컬 사용?
│ └── → GGUF Q4_K_M 변환 + Ollama (이미 Modelfile 존재)
│
└── Open Ko-LLM 리더보드 등재?
└── → HF Hub 업로드 필수 → 리더보드 제출 양식 작성
4. 추가 확장 Job 후보군 (우선순위 순)
즉시 가능 (지금 서버에서 바로, 추가 데이터 불필요)
| 우선순위 | Job | 예상 시간 | 기대 효과 |
|---|---|---|---|
| ⭐⭐⭐ | SFT 모델 생성 테스트 (temperature sampling) | 30분 | 반복율 현황 파악 |
| ⭐⭐⭐ | lm-eval-harness 설치 + ko_ifeval 실행 | 2~4시간 | 공식 벤치마크 수치 |
| ⭐⭐⭐ | ko_winogrande 실행 | 1~2시간 | 언어 이해 수치 |
| ⭐⭐ | Base vs SFT 비교 생성 (동일 프롬프트) | 1시간 | SFT 효과 측정 |
| ⭐⭐ | SFT 학습 손실 곡선 분석 (tensorboard) | 30분 | 수렴 여부 판단 |
| ⭐⭐ | 반복 퇴화 정량 측정 (repetition_penalty 효과) | 1시간 | 배포 가능성 판단 |
| ⭐ | vLLM 서빙 테스트 (FP8) | 1~2시간 | throughput 측정 |
| ⭐ | HF 포맷 변환 (config.json, safetensors) | 2~3시간 | HF Hub 업로드 준비 |
데이터 준비 필요
| 우선순위 | Job | 준비 시간 | 기대 효과 |
|---|---|---|---|
| ⭐⭐⭐ | SFT 데이터 보강 (KoAlpaca + ShareGPT-ko 50K~) | 1~2일 | ko_ifeval +5~15%p |
| ⭐⭐⭐ | cc100 재수집 (버그 수정 후) | 0.5~1일 | 150B+ 토큰 확보 |
| ⭐⭐ | ORPO 데이터 준비 (orca-math-korean 193K) | 0.5일 | 반복 퇴화 -20%p |
| ⭐⭐ | 3B 사전학습 데이터 병합 (150B 토큰 통합) | 1~2일 | 3B 학습 준비 |
| ⭐ | 일반 한국어 preference 데이터 생성 (GPT-4 활용) | 3~7일 | 범용 ORPO/DPO |
| ⭐ | 영어/코드 데이터 추가 (10~30% 혼합) | 1~3일 | 수학/코드 개선 |
외부 리소스 필요
| 우선순위 | Job | 필요 리소스 | 기대 효과 |
|---|---|---|---|
| ⭐⭐ | HuggingFace Hub 계정 업로드 | HF 계정, 인터넷 | 리더보드 제출 가능 |
| ⭐⭐ | Open Ko-LLM Leaderboard 제출 | HF 계정 | 공식 순위 확인 |
| ⭐ | KoMT-Bench / LogicKor 평가 | 외부 API 또는 스크립트 | 질적 평가 |
| ⭐ | VRAM 증설 또는 Multi-GPU SFT | 현재 12GB → 가능 더 필요? | 더 큰 배치 |
5. 리스크 분석
5.1 현재 학습 방식의 잠재적 문제점
| 리스크 | 심각도 | 현재 증거 | 완화 방법 |
|---|---|---|---|
| SFT steps 과소 (5k) | 🔴 높음 | epoch 2 진입, loss 아직 1.97 | steps 증가 또는 데이터 보강 |
| 사전학습 데이터 부족 (~8.91B) | 🟡 중간 | Chinchilla 대비 1B × 20 = 20B 필요 → 미달 | 150B 데이터 추가 학습 |
| 코드/수학 데이터 없음 | 🟡 중간 | ko_gsm8k 거의 0 예상 | 영어 코드/수학 데이터 혼합 |
| Greedy decoding 반복 퇴화 | 🔴 높음 | base에서 30% 발생 확인 | SFT + repetition_penalty + ORPO |
5.2 cc100 데이터 품질 이슈
알려진 문제:
- cc100은 CommonCrawl에서 추출된 웹 텍스트로 노이즈가 심함
- 한국어 cc100 특히: 광고 텍스트, 스팸, 반복 콘텐츠 다수
- 중복률: 문서 수준 중복 10~30% 추정 (MinHash 제거 필요)
실제 영향:
노이즈 포함 학습 → 모델이 광고/스팸 패턴 학습 → 생성 품질 저하
중복 데이터 → 특정 패턴 과도 암기 → 반복 퇴화 악화
권장 전처리:
# 1. 중복 제거 (MinHash LSH)
python scripts/dedup_minhash.py --input cc100_ko.bin --threshold 0.8
# 2. 품질 필터링 (perplexity 기반)
# 낮은 품질 텍스트: PPL > 1000 제거
python scripts/quality_filter.py --max_ppl 1000
# 3. 길이 필터링
# 너무 짧은 문장 (< 50 tokens) 제거
5.3 Tokenizer 선택 (korean_sp 64K)의 영향
현재 설정: SentencePiece Unigram 64K vocab, 한국어 특화
장점:
- 한국어 형태소 분리에 최적화 → 효율적 인코딩
- 64K vocab으로 영어 vs 한국어 token fertility 균형
- 한국어 글자 1개 = 평균 1.2~1.8 tokens (BPE 대비 효율적)
잠재적 문제:
| 문제 | 심각도 | 설명 |
|---|---|---|
| 영어 vocabulary 부족 | 🟡 중간 | 영어 코드/수학 처리 효율 낮음 (byte fallback) |
| 기존 모델과 호환 불가 | 🟡 중간 | RLHF 데이터 재토크나이징 필요 |
| 신조어/외래어 처리 | 🟡 중간 | OOV 처리는 byte fallback이지만 느림 |
| 표준 Llama/Mistral 토크나이저와 다름 | 🟢 낮음 | HF 업로드 시 tokenizer 포함하면 OK |
완화:
- 향후 3B 모델에서는 tiktoken (cl100k_base) 또는 Llama 계열 토크나이저 채택 고려
- 현재 1.19B 모델은 현재 토크나이저 유지 (재학습 비용 too high)
6. 시나리오 목록 ("만약 X라면 Y를 해야 한다")
| # | 조건 (IF) | 액션 (THEN) |
|---|---|---|
| 1 | ko_ifeval > 30% AND 반복 < 15% | → 즉시 HF Hub 업로드 + 리더보드 제출 + 3B 사전학습 병렬 진행 |
| 2 | ko_ifeval 20 |
→ KoAlpaca+ShareGPT-ko로 데이터 보강 후 10k steps SFT 재실행 |
| 3 | ko_ifeval < 20% AND base와 차이 없음 | → SFT 학습 파이프라인 버그 점검 (데이터 로딩, 포맷 확인) |
| 4 | 반복율 > 40% | → ORPO (orca-math-korean 193K) 즉시 적용 |
| 5 | 모든 SFT 시도 후에도 ko_ifeval < 20% | → 1B 한계 인정, 3B 사전학습으로 전환 |
| 6 | cc100 수집 완료 (65~100B) | → 3B 사전학습 바로 시작 (26시간, 8× B200) |
| 7 | 3B base PPL < 8 달성 | → 3B SFT (KoAlpaca + ORPO) → 리더보드 목표 ko_ifeval 40%+ |
| 8 | 서비스 배포 결정 | → vLLM FP8 서빙 + GGUF Q4_K_M Ollama 병행 |
| 9 | 수학/코드 성능 필요 | → 영어 수학+코드 데이터 20% 혼합하여 3B 재학습 |
| 10 | 한국어 preference 데이터 자체 생성 원함 | → Claude/GPT-4로 chosen/rejected 쌍 10K 생성 후 DPO |
7. 전체 타임라인
현재 (2026-02-26)
│
├─ Week 1: Phase 1 검증
│ ├─ D+0: SFT 생성 테스트 (30분)
│ ├─ D+0: lm-eval ko_ifeval + ko_winogrande (4시간)
│ └─ D+2: 결과 분석 + 다음 단계 결정
│
├─ Week 2~3: Phase 2A 또는 2B 결정 후 실행
│ ├─ [2A 경로] 데이터 보강 (3~5일) + 재학습 (1~2일)
│ └─ [2B 경로] 3B 사전학습 (26시간) + 3B SFT (3~6시간)
│
├─ Week 4: Phase 3 (필요시)
│ └─ ORPO 학습 (193K 데이터, 3~6시간)
│
└─ Week 4~5: Phase 4 배포
├─ HF 포맷 변환 (2~3시간)
├─ HF Hub 업로드 + Model Card
├─ vLLM 서빙 설정
└─ Ko-LLM 리더보드 제출
총 예상 기간: 3~5주 (3B 스케일업 포함)
8. 즉각적인 다음 단계 (Action Items)
# Step 1: lm-evaluation-harness 설치
pip install lm-eval
# Step 2: ko_ifeval 실행 (SFT 체크포인트)
lm_eval \
--model hf \
--model_args pretrained=/PROJECT/0325120031_A/ghong/taketimes/llm-bang/checkpoints/korean_1b_sft/checkpoint-0005000,dtype=bfloat16 \
--tasks ko_ifeval \
--device cuda:0 \
--output_path ./eval/results/sft_5k_ko_ifeval.json
# Step 3: ko_winogrande 실행
lm_eval \
--model hf \
--model_args pretrained=/PROJECT/0325120031_A/ghong/taketimes/llm-bang/checkpoints/korean_1b_sft/checkpoint-0005000,dtype=bfloat16 \
--tasks ko_winogrande \
--device cuda:0 \
--output_path ./eval/results/sft_5k_ko_winogrande.json
이 문서는 평가 결과에 따라 업데이트 예정.
다음 업데이트: Phase 1 평가 완료 후 (예상: D+1~2)