# 한국어 LLM 전체 로드맵 & 의사결정 프레임워크

> **작성일**: 2026-02-26  
> **현재 상태**: SFT 5,000 steps 완료 (loss 1.9677), 1.19B 파라미터 모델  
> **목표**: 실사용 가능한 한국어 LLM 배포

---

## 0. TL;DR — 지금 당장 할 일

1. **SFT 모델 빠른 생성 테스트** (30분, 오늘): temperature sampling으로 반복 퇴화 확인
2. **lm-eval-harness ko_ifeval + ko_winogrande 실행** (2~4시간): 숫자 확인
3. **결과에 따라 분기** → 아래 의사결정 트리 참조

---

## 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 한국어 instruction
  - `HAERAE-HUB/KMMLU` — 한국어 지식 QA
  - `nayohan/llama3-baseline-ko-dataset` — 다양한 instruction
  - `squarelike/sharegpt_deepl_ko_ko-en` — ShareGPT 한국어
  - 합산 목표: 50K~200K 고품질 샘플
- **예상 효과**: 데이터 품질 개선이 steps 2배보다 효과적 (경험적 법칙)
- **비용**: 데이터 정제 1~2일, 학습 추가 2~6시간

**옵션 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 +5~10%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 제거 필요)

**실제 영향**:
```
노이즈 포함 학습 → 모델이 광고/스팸 패턴 학습 → 생성 품질 저하
중복 데이터 → 특정 패턴 과도 암기 → 반복 퇴화 악화
```

**권장 전처리**:
```bash
# 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~30% AND 반복 15~30% | → 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)

```bash
# 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)*