Files
frankenstallm/source/eval/reports/01_perplexity_report.md
ModelHub XC d4abdb70fa 初始化项目,由ModelHub XC社区提供模型
Model: pathcosmos/frankenstallm
Source: Original Platform
2026-07-14 04:21:16 +08:00

15 KiB
Raw Permalink Blame History

평가 보고서 #01 — Perplexity 분석

모델: korean_1b_fp8_run1 작성일: 2026-02-26 평가 유형: Sliding-window Perplexity (슬라이딩 윈도우 퍼플렉시티)


1. 실험 설정

1.1 모델 아키텍처

항목
파라미터 수 1.19B (약 11.9억)
어휘 크기 (vocab_size) 64,000
히든 차원 (d_model) 2,048
레이어 수 (n_layers) 24
어텐션 헤드 수 (n_heads) 16
KV 헤드 수 (n_kv_heads) 4 (GQA — Grouped Query Attention)
Positional Encoding RoPE (Rotary Position Embedding)
활성화 함수 SwiGLU

GQA(Grouped Query Attention)를 적용하여 n_kv_heads=4로 설정함으로써 KV 캐시 메모리를 표준 MHA(Multi-Head Attention) 대비 약 75% 절감하였다. d_model=2048, n_layers=24 구성은 GPT-3 1.3B 계열의 아키텍처 설계와 유사하며, 한국어 전용 어휘 크기 64k를 채택하여 한국어 토크나이저 효율을 높였다.

1.2 학습 설정

항목
총 학습 스텝 34,000 steps
실효 에포크 수 약 4 에포크 (Muennighoff 2023 기준 최적)
총 처리 토큰 ~35.6B tokens
GPU 8× NVIDIA B200 (192GB VRAM each)
수치 정밀도 FP8 (MXFP8BlockScaling) + BF16 autocast
학습률 (lr) 2.0e-4
배치 크기 (유효) 8 GPU × 8 samples × 4 accum × 4096 seq = 1.05M tok/step
워밍업 2,000 steps
옵티마이저 AdamW
그래디언트 클리핑 1.0

FP8 학습은 TransformerEngine 2.10의 MXFP8BlockScaling 레시피를 사용하였다. B200은 FP8 연산을 네이티브로 지원하므로, BF16 대비 약 2배의 연산 처리량 향상이 가능하다. torch.autocast(dtype=torch.bfloat16)te.fp8_autocast()ExitStack으로 중첩하여 안정적인 FP8 학습을 구현하였다.

1.3 평가 방법론

평가 방법: Sliding-window Perplexity (슬라이딩 윈도우 퍼플렉시티)

  • 시퀀스 길이 (seq_len): 2,048 tokens
  • 스트라이드 (stride): 512 tokens
  • 중첩 비율: 75% (1,536 tokens 중첩, 512 tokens만 유효 예측)

슬라이딩 윈도우 방식은 고정 윈도우 방식보다 더 정확한 PPL 측정이 가능하다. 문서 경계에서 컨텍스트가 충분히 주어진 후에 예측을 수행하므로, 초반 토큰의 cold-start 문제를 완화한다. stride=512 설정은 seq_len=2048의 1/4로, 충분한 컨텍스트 중첩을 보장하면서 계산 비용을 적절히 조율한 값이다.

1.4 평가 데이터셋

데이터셋 설명
korean_val 4개 소스 통합 검증 세트
korean_wiki_val 한국어 위키백과 검증 세트
korean_c4_val Korean C4 (Colossal Clean Crawled Corpus) 검증 세트
korean_namuwiki_val 나무위키 검증 세트

2. Perplexity 결과

2.1 결과 테이블

Dataset PPL bits/token 평가 토큰 수
korean_val (통합) 6.9452 2.7960 53,512,147
korean_wiki_val 11.6595 3.5434 1,567,747
korean_c4_val 5.6698 2.5033 45,445,722
korean_namuwiki_val 25.3436 4.6636 6,488,957
  • PPL (Perplexity): 낮을수록 모델이 해당 텍스트를 더 잘 예측함을 의미
  • bits/token: log2(PPL) — 1 토큰을 예측하는 데 필요한 정보량(비트). 낮을수록 좋음
  • 평가 토큰 수: 슬라이딩 윈도우 방식으로 유효하게 평가된 총 토큰 수

2.2 데이터셋별 토큰 비율

korean_c4_val       ████████████████████████████████████  84.97%  (45,445,722 tokens)
korean_namuwiki_val ██████                                12.13%  ( 6,488,957 tokens)
korean_wiki_val     ██                                     2.93%  ( 1,567,747 tokens)

통합 korean_val의 PPL은 C4가 전체 평가 토큰의 약 85%를 차지하므로, C4 PPL(5.67)에 강하게 편향된 가중 평균으로 이해해야 한다.


3. 분석 및 해석

3.1 Korean C4 — PPL 5.6698 (가장 낮음)

C4(Colossal Clean Crawled Corpus)는 Common Crawl을 품질 필터링한 일반 웹 텍스트 데이터셋이다.

낮은 PPL의 주요 원인:

  • 학습 데이터 비중: Korean C4는 학습 코퍼스에서 가장 큰 비중을 차지한다(약 15M tokens 이상). 모델이 이 도메인의 텍스트 분포를 가장 많이 학습하여 평가 세트와의 분포 간격(distribution gap)이 최소화된다.
  • 텍스트 패턴의 예측 가능성: 일반 웹 문서는 뉴스 기사, 블로그, 제품 설명 등 비교적 정형화된 서술 패턴을 따른다. 어휘 다양성보다 반복적 표현이 많아 다음 토큰 예측이 상대적으로 용이하다.
  • 필터링 품질: C4는 공격적인 품질 필터링(언어 감지, 중복 제거, 짧은 문장 제거 등)을 거친 고품질 데이터다. 노이즈가 적고 자연스러운 문장 구조를 가지므로 언어 모델이 학습하기 좋은 분포를 형성한다.
  • bits/token = 2.50: 1 토큰 예측에 평균 2.5비트의 정보량이 필요하다는 뜻으로, 모델이 실질적으로 높은 예측 정확도를 달성하고 있음을 의미한다.

3.2 Korean Wikipedia — PPL 11.6595

위키백과는 백과사전적 서술 방식의 고품질 텍스트다.

중간 수준 PPL의 주요 원인:

  • 사실 기반 고유명사의 불확실성: 위키백과 텍스트에는 인물명, 지명, 날짜, 수치, 학술 용어 등 고유명사와 특수 정보가 밀집되어 있다. 이들은 문법적으로는 예측 가능한 위치에 있더라도, 실제 값은 다음 토큰 예측이 어려운 high-entropy 위치를 구성한다.
    • 예: "이 사건은 ___년에 발생하였다" → 연도는 문법적으로 명사 위치지만 어떤 숫자인지는 예측이 어려움
  • 문체의 이중성: 위키백과는 문법적으로는 정형화된 백과사전 서술체(예측 쉬움)이지만, 개별 팩트(사실)는 임의적(예측 어려움)이다. 이 두 요인이 상쇄되어 중간 수준의 PPL을 보인다.
  • 낮은 토큰 비율(2.93%): 위키백과 데이터가 학습 코퍼스에서 차지하는 비율이 상대적으로 작아, 도메인 적응이 C4 대비 부족할 수 있다.
  • bits/token = 3.54: C4(2.50) 대비 약 1비트 더 필요하며, 이는 팩트 기반 텍스트의 본질적 불확실성을 반영한다.

3.3 Korean Namuwiki — PPL 25.3436 (가장 높음)

나무위키는 대한민국의 비공식 위키 사이트로, 일반 위키백과와는 매우 다른 텍스트 특성을 가진다.

높은 PPL의 주요 원인:

  • 비정형 텍스트 포맷: 나무위키는 자체적인 마크업 문법, 표, 접기(fold), 인용구 등 비표준 서식이 혼재한다. 모델이 이 특수한 포맷 패턴을 충분히 학습하지 못했을 가능성이 높다.
  • 밈, 인터넷 용어, 신조어: 나무위키는 디시인사이드, 트위터 등 커뮤니티 문화에서 파생된 밈, 은어, 줄임말이 대량 포함되어 있다. 이러한 언어는 표준 한국어 말뭉치에서 등장 빈도가 낮아 모델이 예측하기 어렵다.
  • 팬 문화 및 서브컬처 콘텐츠: 애니메이션, 게임, 아이돌 등 매우 특화된 도메인 지식이 많다. 고유명사(캐릭터명, 작품명 등)의 밀도가 높아 next-token prediction 난이도가 높다.
  • 특수문자 및 혼합 언어: 영어, 일본어, 특수문자가 한국어와 혼재하여 토크나이저 처리와 모델 예측 모두 복잡해진다.
  • 학습 데이터에서의 상대적 낮은 비중: 전체 학습 데이터에서 나무위키의 비율이 낮을 경우, 이 도메인에 대한 도메인 적응이 부족하여 PPL이 높게 나타난다.
  • bits/token = 4.66: 1 토큰 예측에 평균 4.66비트가 필요하여, 모델 입장에서 나무위키 텍스트는 상당히 불확실한 도메인임을 나타낸다.

3.4 Korean Val (통합) — PPL 6.9452

통합 검증 세트의 PPL은 각 소스 데이터셋의 토큰 수 가중 평균에 가깝게 형성된다.

통합 PPL 계산 근거:

전체 53.5M 토큰 중 C4가 45.4M(84.97%)을 차지하므로, 통합 PPL은 C4 PPL(5.67)에 강하게 편향된다. 나무위키(12.13%, PPL 25.34)와 위키(2.93%, PPL 11.66)의 기여로 통합 PPL이 C4 PPL보다 다소 높은 6.95 수준이 된다.

로그 공간에서의 단순 가중 합산으로 추정:

log(PPL_통합) ≈ 0.8497 × log(5.67) + 0.1213 × log(25.34) + 0.0293 × log(11.66)
             ≈ 0.8497 × 1.736 + 0.1213 × 3.232 + 0.0293 × 2.456
             ≈ 1.476 + 0.392 + 0.072
             ≈ 1.940  →  exp(1.940) ≈ 6.96  (실측 6.95와 근접)

이 계산은 실측값 6.9452와 매우 잘 일치하며, 평가 파이프라인의 일관성을 검증한다.


4. 1B 모델 기준 적정 PPL 범위 비교

4.1 영어 기준 레퍼런스 모델과 비교

모델 파라미터 평가 데이터 PPL
GPT-2 (OpenAI) 1.5B WebText (영어) ~1520
OPT-1.3B (Meta) 1.3B WikiText-103 (영어) ~1416
LLaMA-1 1.3B (Meta) 1.3B WikiText-103 (영어) ~9.8
우리 모델 1.19B Korean Wiki 11.66
우리 모델 1.19B Korean C4 5.67
우리 모델 1.19B Korean 통합 6.95

4.2 해석

긍정적 신호:

  • Korean Wiki PPL=11.66은 동급 영어 모델(OPT-1.3B ~1416)과 비교해도 경쟁력 있는 수준이다. 단, 이 비교는 언어, 평가 데이터셋, 토크나이저가 모두 다르므로 직접 비교에는 주의가 필요하다.
  • Korean C4 PPL=5.67은 매우 낮은 수치로, 학습 데이터와 유사한 도메인에서 모델이 효과적으로 한국어 패턴을 학습했음을 시사한다.
  • LLaMA-1 1.3B의 WikiText PPL ~9.8과 비교 시, 우리 모델의 Korean Wiki PPL 11.66은 합리적인 수준이다.

주의사항 — 직접 비교의 한계:

  • 토크나이저 차이: 한국어는 교착어로, BPE 토크나이저가 한국어를 영어보다 더 많은 토큰으로 분리하는 경향이 있다. 동일한 텍스트라도 한국어 모델의 PPL이 영어 모델보다 높거나 낮게 나올 수 있으며, bits/char 또는 bits/word 단위 비교가 더 공정하다.
  • 학습 데이터 분포: C4 PPL=5.67이 특히 낮은 이유는 평가 데이터가 학습 데이터와 **같은 소스(C4)**에서 추출되었기 때문이다. 이는 모델의 실제 일반화 능력보다 학습-평가 데이터의 분포 일치에 기인한다.
  • 데이터 오염 위험: 충분한 데이터 중복 제거(deduplication)가 없다면, 평가 세트가 학습 세트와 중복될 위험이 있다. 결과 해석 시 이 점을 유의해야 한다.

4.3 PPL 건강 진단 요약

도메인          PPL     판정
────────────────────────────────
C4 (웹 텍스트)  5.67    매우 양호 — 학습 도메인과 일치
Wiki (백과사전) 11.66   양호 — 1B 규모 기준 경쟁력 있음
Namuwiki (커뮤니티) 25.34  개선 필요 — 도메인 적응 부족
통합            6.95    전반적으로 건강한 수준

전반적으로 1B 파라미터 규모의 한국어 모델로서 건강한 PPL 범위에 속한다고 평가한다.


5. 개선 방향

5.1 Namuwiki 도메인 성능 개선 (우선순위: 높음)

나무위키 PPL(25.34)이 다른 도메인 대비 월등히 높다. 이를 개선하기 위한 접근법:

  • 학습 데이터 비중 조정: 나무위키 데이터의 학습 데이터 비율을 높인다. 현재 비중이 낮을 경우, 나무위키 도메인 데이터를 23배 업샘플링하는 것을 고려한다.
  • 도메인 적응 파인튜닝 (Domain Adaptive Pretraining, DAPT): 기학습된 체크포인트에서 나무위키 데이터로 추가 사전학습을 수행한다. 전체 재학습 없이 특정 도메인 성능을 빠르게 개선할 수 있다.
  • 토크나이저 개선: 나무위키 특유의 어휘(밈, 은어, 신조어)를 어휘 사전에 추가하거나, 나무위키 코퍼스를 포함하여 토크나이저를 재학습한다.
  • 데이터 정제: 나무위키의 마크업 문법을 전처리 단계에서 더 철저히 제거하거나, 마크업 패턴을 인식할 수 있도록 특수 토큰을 도입한다.

5.2 Wiki 도메인 성능 개선 (우선순위: 중간)

Wikipedia PPL(11.66)은 적정 범위이지만, 사실 지식(factual knowledge) 성능 개선에는 근본적 한계가 있다.

  • 모델 규모 확대: 사실 지식 암기 능력(memorization capacity)은 파라미터 수에 비례한다. 1B → 3B 또는 7B 규모로 확대하면 위키 PPL이 유의미하게 하락할 것으로 예상된다.
  • 위키백과 데이터 업샘플링: 현재 위키백과가 전체 평가 토큰의 2.93%에 불과한 것처럼, 학습 데이터에서도 비중이 낮을 가능성이 있다. 위키백과 데이터를 35배 업샘플링하면 도메인 적응이 개선된다.
  • RAG(Retrieval-Augmented Generation) 접근: 순수 파라미터 기억 외에 검색 기반 보강을 통해 사실 지식 한계를 우회하는 방법도 고려할 수 있다 (파인튜닝 이후 단계).

5.3 전반적 성능 개선 방향

  • 더 많은 토큰 학습: 현재 34k steps (~35.6B tokens, 4 에포크). Chinchilla 스케일링 법칙에 따르면 1.19B 모델의 최적 학습 토큰은 약 24B이지만, 데이터 다양성과 도메인 커버리지를 높이기 위해 추가 코퍼스 확보가 유리하다.
  • Instruction Tuning / RLHF: 사전학습 완료 후 지시문 따르기(instruction following) 데이터로 파인튜닝하면 실제 활용 성능이 크게 향상된다.
  • 평가 범위 확대: PPL 외에 KoBEST, KLUE 등 한국어 다운스트림 벤치마크에서 정성적 평가를 추가한다. PPL과 downstream task 성능이 항상 상관관계를 갖지는 않으므로 다각도 평가가 필요하다.

6. 결론

항목 내용
모델 korean_1b_fp8_run1 (1.19B params)
학습 완료 34,000 steps, 8×B200, FP8
통합 PPL 6.9452 (bits/token: 2.7960)
최고 성능 도메인 Korean C4 — PPL 5.6698
최저 성능 도메인 Korean Namuwiki — PPL 25.3436
전반 평가 1B 규모 한국어 모델로서 건강한 수준

이번 평가를 통해 korean_1b_fp8_run1은 학습 도메인(C4)에서 우수한 성능을 보이며, 사실 지식이 풍부한 위키백과 도메인에서도 경쟁력 있는 PPL을 달성하였음을 확인하였다. 나무위키 도메인의 높은 PPL은 학습 데이터 비중 부족 및 도메인 특수성에 기인하며, 도메인 적응 사전학습(DAPT)을 통해 개선 가능하다. 전반적으로 FP8 학습과 MXFP8BlockScaling 레시피가 1B 규모 한국어 모델 학습에 성공적으로 적용되었음을 확인하였다.


이 보고서는 korean_1b_fp8_run1 체크포인트의 Sliding-window Perplexity 평가 결과를 기록한 문서입니다. 평가 파이프라인: eval/perplexity.py, 보고서 작성일: 2026-02-26