밑바닥부터 만드는 LLM

[!IMPORTANT] 새로운 목표 : Apex-3 학습 중

총 7.30B / 활성 3.36B MoE · 30층 · d_model 2,560 · GQA(20Q/4KV) + QK-Norm · local:global 5:1 · 라우팅 전문가 32개 top-8 + 공유 1개 · SuperBPE 204,800 · 목표 ~2T 토큰 → ThinkingLab

[!NOTE] 이 저장소는 계속 다듬는 중입니다.
학습 결과, 벤치마크, 문서가 버전마다 바뀔 수 있습니다. 최신 커밋을 기준으로 봐 주세요. Issue / PR 환영합니다.

시작하기에 앞서, 이 글은 가독성이 좋지 않을 수 있습니다. AI를 사용하여 "가독성이 좋게 다듬어줘" 라는 말을 할 수 있지만, 나중에 제가 어떤 생각을 했고 어떤 과정을 거쳤는지 없어질 수 있기때문입니다. 물론 AI를 통해 배우는것은 좋지만 문장을 몇 번씩 다듬으면서 나의 지식을 정리하는게 더 중요합니다.

[!IMPORTANT] APEX-2 (MoE · 3.87B / 활성 1.45B) — Pretrain · SFT 완료

실측 3,869.1M 파라미터 (토큰당 활성 1,453.2M). ( 32층 · d_model 2048 · GQA(16Q/4KV) + QK-Norm + RoPE + SwiGLU MoE(16 experts · top-4) + RMSNorm )

• 🤗 공개: huggingface.co/YOON1v/Apex-2 — transformers·vLLM으로 바로 로드 가능 (Qwen3MoeForCausalLM 아키텍처 매핑)
• 📏 컨텍스트: 4096
• 🔥 Pretrain: 54,250 step · 86.5B 토큰 (웹·코드·수학·큐레이션 혼합) → SFT 2.77B 토큰 (2단계)
• 📊 상세: BENCHMARK v3 · 이전 모델 APEX-1(1.1B dense)은 BENCHMARK v2 · HF Apex-1-DPO

모델	사전학습 토큰	HumanEval	HumanEval+	MBPP	MBPP+	GSM8K	IFEval	MMLU
Apex-2 SFT (3.87B · 활성 1.45B)	0.087T	43.9	41.5	56.3	48.9	32.4	44.7	28.6
Apex-1 DPO (1.1B dense)	0.02T	8.5	—	5.2	—	1.9	—	24.9
Qwen2.5-1.5B-Instruct	18T	61.6	—	63.2	—	73.2	42.5	50.7
Qwen2.5-Coder-1.5B-Instruct	5.5T	70.7	66.5	69.2	59.4	—	—	—
Qwen3-1.7B	36T	—	—	—	—	—	68.2	64.4
Llama-3.2-1B-Instruct	9T	—	—	—	—	44.4	59.5*	49.3
Gemma-3-1B-it	2T	41.5	—	35.2	—	62.8	80.2*	38.8
OLMoE-1B-7B (활성 1.3B)	5.1T	62.3	54.4	—	—	72.4	66.4*	55.1
DeepSeek-Coder-1.3B	2T	65.9	60.4	65.3	54.8	—	—	—

_{DeepSeek-Coder는 Qwen2.5-Coder 보고서의 재측정값입니다. * IFEval 지표가 다릅니다 (Apex-2·Qwen: prompt-level strict, 나머지: 여러 지표 평균 또는 미표기). Apex-1은 lm-eval(GSM8K 5-shot, MMLU 5-shot) 값입니다. Apex-2는 greedy · 0-shot 채팅(GSM8K는 0-shot CoT, MMLU는 5-shot)으로 직접 측정했고, 다른 모델은 공식 모델 카드·기술 보고서 값이라 평가 방식이 서로 다릅니다 → BENCHMARK v3 §6
벤치마크 출처: HumanEval+ · MBPP+ Liu+23 (EvalPlus) · GSM8K Cobbe+21 · IFEval Zhou+23 · MMLU Hendrycks+21
비교 모델 출처: Qwen2.5 Qwen+24 · Qwen2.5-Coder Hui+24 · Qwen3 Qwen+25 · Llama 3.2 model card · Gemma 3 Gemma+25 · OLMoE model card · DeepSeek-Coder Guo+24}

[!NOTE] APEX-1 (1B급) — Pretrain · SFT · DPO 완료

실측 1,119.5M 파라미터. ( 24층 · d_model 2048 · GQA(16Q/4KV) + RoPE + SwiGLU + RMSNorm )

• 🤗 공개: huggingface.co/YOON1v/Apex-1-DPO — transformers로 바로 로드 가능 (Qwen3ForCausalLM 아키텍처 매핑)
• 컨텍스트: max 4096 (학습 2048)
• Pretrain: 51K step · 20B 토큰 · v3-en 80.8GB · 영어 전용

모델	학습 토큰	HellaSwag	ARC(평균)	PIQA	GSM8K	HumanEval
Apex-1 DPO (1.1B)	0.02T	46.9	41.6	68.6	1.9	8.5
Pythia-1.0B	0.3T	47.2	38.0	69.2	—	1.8
OPT-1.3B	0.18T	53.7	40.1	72.4	—	—

_{벤치마크 출처(각 분야 표준 인용 논문): HellaSwag Zellers+19 · ARC Clark+18 · PIQA Bisk+19 · GSM8K Cobbe+21
HumanEval Chen+21
비교 모델 출처: Pythia Biderman+23 · OPT Zhang+22}

---

좋아요, 그럼 시작하겠습니다.

이 프로젝트가 하는 일

NVIDIA CUDA 위에서 돌아가는 범용 LLM과, 코딩·문서 작업처럼 실무에 쓸 수 있는 AI를 밑바닥부터 만드는 실험입니다.

• 토크나이저 학습
• 모델 아키텍처 (Decoder-only Transformer)
• 사전학습 · SFT · DPO · GRPO
• KV 캐시 추론 · 사고 모드 (THINKING)
• 사람 피드백 수집 UI · 승격 게이트

오픈소스 LLM을 받아 파인튜닝하는 편이 훨씬 빠르지만, 그럼에도 처음부터 다시 짠 이유는 하나뿐입니다.

LLM 내부를 손으로 짜 보지 않으면, 결국 남의 코드를 빌려 쓰는 쪽에 머문다.

LLM 내부를 손으로 짜 보지 않으면, 결국 남의 코드를 빌려 쓰는 쪽에 머문다.

그래서 이 저장소는 외부 상용/오픈 LLM 가중치에 기대지 않습니다.

[326.7M급 모델을 개발하면서 느낀 교훈]

1. 다국어 비효율

작은 모델 조건부에서 다국어를 지원하는 것은 ~7B급 모델에서는 치명적이다. v7에서 보여줬듯, 소형 다국어는 셋 다 어중한간 항태로 수렴한다.

70B급 이상부터는 언어간 전이가 오히려 이득이 되지만, 작은 모델에서는 영어권 코퍼스가 압도적으로 양과 질이 좋으므로, 작은 모델에서는 영어에 초점을 맞춰야 한다.

2. 코퍼스의 질은 상당히 중요하다.

성능 = 파라미터 x 토큰 수 x 데이터 질이다. 기존에 공개된 코퍼스라 할지라도, 좋은 질의 코퍼스를 찾는것이 가장 급선무이다. 

3. 벤치마크에서의 노이즈

학습을 끝낸 후 벤치마크를 돌렸을 때, temperature 0.7값으로 문항당 1번만 샘플링했다. 같은 모델이 실행마다 다른 답을 내니 버전 간 점수 차이가 실력 차인지 주사위인지 구분이 불가능했다.

해결: v5부터 greedy 프로토콜을 사용하여 같은 모델은 항상 같은 답을 사용하게 하여 해결했다.

다만, val loss에도 속았다.

val이 코퍼스 파일 순서의 마지막 1%였는데, ko위키 꼬리 단일 도메인이라 전체 능력을 대표하지 못했다. (v2에서 ko위키 val은 나빠졌지만 다운스트림 벤치마크는 역대 최고)

측정이 무작위 16시퀀스 1배치라 +-0.25 노이즈가 있었는데, 이 등락을 실제 개선/악화로 오독해 두 번 판단을 실수했다. 즉, 두 번 속았다.

해결: 다중 배치 평균으로만 판단 + v3-en 다운로더에 소스별 1%씩 혼합 val을 구조적으로 내장했다.

4. thinking 붕괴 (v1~v5, 최대 실수)

정답을 <THINKING> 안에 써놓고 답변은 공란이었다. 6버전 내내 thinking 코딩 0/5
원인으로는 총 3개가 있었다.

> thinking 학습 데이터의 99%가 max_len=1024에서 사고 도중 절단되었다.
> THINK_SUFFIX가 학습/추론 간 불일치했다.
> infer.py에서 사고/답변 토큰 예산이 미분리라 사고가 예산을 다 먹으면 답변이 공란이었다.

해결: data.py에 thinking 꼬리 보존(길면 사고 중간을 잘라도 닫는 태그+답변은 보존: 47,273건, 너무 길면 no-thinking으로 강등: 17,540건) + THINK_SUFFIX 조건부 부착 + infer.py 예산 분리·EOS 가드

해결법을 적용하니 thinking 답변 10/14→14/14, 평균 0.50→2.93, 첫 코드 출력 4/5 점수를 받았다.

공통적인 교훈으로는 셋 다 모델이 멍청해서가 아니라, 측정기나 배관이 고장나있었다.
초점을 학습 모델에 맞추다 보니 생긴 문제였는데, 다음번부터 점수가 이상해도 샘플링, val 설계, 전처리 부터 의심하는 것을 순서로 둔다.

---

문서 안내

---

1. 아키텍처

토큰 → 임베딩 → 어텐션 → FFN → logit 까지의 숫자 예제 워크스루는 ARCHITECTURE — 트랜스포머 동작 원리에 옮겼습니다. (교육용 예제와 실제 LLaMA 스타일 설계의 차이는 그 문서에서 이어서 설명합니다.)

처음에 생각했던 길

처음 계획은 단순했습니다.

1. 자연어 데이터만으로 LLM을 먼저 만든다
2. 그 위에 코딩 특화 데이터를 얹는다
3. 사람이 강화학습으로 다듬는다

코딩 AI라도 질문은 자연어로 오니까,
“말을 알아듣는 능력”을 먼저 완성해야 한다고 봤기 때문입니다.

논문이 알려 준 것

Llama 3 를 보면 그 순서가 없습니다.
사전학습 단계부터 이미 한 믹스에 섞습니다.

후속학습에서 instruction, preference, coding, tool-use 를 강화할 뿐입니다.
“자연어를 먼저 끝낸 뒤 코드를 얹는다” 단계는 없습니다.

DeepSeek-Coder 도 같은 방향입니다.
코드 87% + 코드 관련 영어 10% + 기타 3% 로 처음부터 학습했고,
자연어가 13%뿐인데도 당시 오픈 코드 LLM 중 상위권이었습니다.

그래서 바꾼 파이프라인

  자연어 + 코드 + 수학 + 문서
            │
            ▼
   base pretraining
            │
            ▼
  code-heavy continued pretrain
            │
            ▼
    instruction tuning (SFT)
            │
            ▼
   preference (DPO / GRPO …)

데이터 믹스 가이드 (300M ~ 1B)

2. 파라미터는 천천히 키운다

파라미터는 모델 크기입니다. (용어는 GLOSSARY)
클수록 여지는 커지지만, 이 프로젝트는 300M → 1B → 3B 처럼 단계를 나눕니다.

Chinchilla 요지:

[!TIP] 같은 compute 예산이면 모델 크기와 토큰 수를 같이 키워야 한다.

당시 대형 모델은 크기에 비해 데이터가 부족한 경우가 많았고,
더 작은 Chinchilla(70B, 1.4T 토큰)가 더 큰 Gopher보다 나은 점수를 내기도 했습니다.

그래서 원칙은 이렇습니다.

1. 작은 모델에서 tokenizer · dataloader · loss · eval · checkpoint 가 도는지 확인
2. 그다음 규모를 올린다

StarCoder2 도 3B / 7B / 15B 를 각각 다른 토큰 예산으로 나눠 학습한 사례입니다.

이 프로젝트가 밟는 단계

1B(APEX-1)에 이어 **APEX-2(MoE 3.87B, 활성 1.45B)**까지 외부 사전학습 가중치 없이 Pretrain·SFT를 마쳤습니다.

두 라인을 병행 중입니다: 1B Apex-1 라인 최신은 dpo_Apex-1_v1 (pretrain+SFT+DPO 완료, 표준 벤치 11종 측정 완료), 327M base 라인 최신은 sft_base_v6 입니다. APEX-2는 MoE 라인으로 따로 기록합니다. → §5 벤치마크 한눈에 · 버전별 상세 기록 BENCHMARK v3 · BENCHMARK v2

---

3. 모델 vs RAG · Tool

회사 지식을 전부 가중치에 넣으려 하면 감당이 안 됩니다.
코드, 문서, 빌드 로그는 계속 바뀌기 때문입니다.

[!IMPORTANT] 모델 = 어떻게 생각하고 도구를 쓸지
RAG / Tool = 지금 무엇이 사실인지

(RAG · Tool 런타임 연동은 로드맵에 있고, 현재 공개 범위의 핵심은 학습 · 추론 · 정렬 파이프라인입니다.)

---

4. 프로젝트 구조

AI/
├── README.md                 설계 철학 · 실행 안내
├── GLOSSARY.md               용어
├── ARCHITECTURE.md           모델 · 학습 · 추론
├── POST-TRAINING.md          피드백 후속학습
├── BENCHMARK-v3.md           APEX-2(MoE) 벤치 리포트
├── BENCHMARK-v2.md           APEX-1(1B) 벤치 리포트
├── BENCHMARK-v1.md           327M 벤치 리포트
└── llm/                      구현
    ├── model.py              RMSNorm + RoPE + SwiGLU + GQA
    ├── tokenizer.py
    ├── data.py
    ├── train.py              pretrain / sft / dpo
    ├── infer.py              채팅 · 로그
    ├── feedback.py           피드백 웹 UI
    ├── reward.py · rlhf.py   RM + GRPO / RLVR
    └── eval_gate.py          승격 게이트

대용량 가중치(.pt), 원본 코퍼스, 일부 소스는 저장소에 올리지 않습니다.
문서로 설계와 벤치를 먼저 공개하는 형태입니다.

---

5. 벤치마크 한눈에

학습 GPU: H100, A100

두 라인이 병행됩니다: 1B Apex-1(영어 전용) 와 327M base (한/일/영 다국어). 세트도 서로 다릅니다.

5.0 APEX-2 (MoE 3.87B · 활성 1.45B) ⭐ 최신

SFT 모델을 vLLM greedy · 0-shot 채팅으로 측정했습니다 (모델이 쓴 코드는 샌드박스에서 실행해 채점). base는 사전학습 직후 모델입니다.

DPO(Dolci-Instruct-DPO)는 답이 2.3배 길어지며 코드·수학·지시 수행이 떨어져 폐기했고, SFT를 최종으로 했습니다. 상세: BENCHMARK-v3.md

5.1 1B Apex-1 라인

영어 전용 15문항 × THINKING on/off (코딩 5문항은 327M 세트와 동일 문항).
최신 스냅샷: sft_Apex-1_v1 (ckpt/benchmark_sft_Apex-1_v1_raw.json, 2026-07-22). Pretrain 51K step(20B 토큰) + SFT 8.4K step + RLVR 폐기 후 DPO까지 전부 완료(§6 in BENCHMARK v2).

sft_Apex-1_v1

327M 라인의 최대 실패였던 THINKING 핸드오프(답 칸 공란)는 이 라인에서 처음부터 발생하지 않았습니다. 대신 새 병목은 장황함·반복이고, THINKING을 켜면 코딩·QA 모두 오히려 떨어집니다(사고가 답변 예산을 먼저 소모).

능력(코딩 5/5 만점)은 충분하다고 판단해 처음엔 RLVR을 골랐지만, 실제로 돌려보니 GSM8K 정답률이 ~0%라 GRPO 그룹 내 보상 분산이 0이 되어 학습 신호가 아예 없었습니다. 장황함·지시불이행이라는 원래 문제는 정답 능력이 필요 없는 DPO로 직접 겨냥할 수 있어 그쪽으로 전환, 60K 선호쌍으로 학습을 완료했습니다.

상세 기록: BENCHMARK-v2.md

5.2 표준 벤치마크 (lm-evaluation-harness)

sft_Apex-1_v1 vs dpo_Apex-1_v1를 HF로 변환해(로짓 일치 검증 max diff 2.3e-5) 표준 하네스로, 공개된 점수가 있는 다른 모델들과 나란히 측정했습니다. 상식 7종은 0-shot, MMLU는 5-shot, GSM8K는 5-shot, HumanEval·MBPP는 0-shot pass@1 — TinyLlama 논문(Table 2·3) 프로토콜과 동일하게 맞췄습니다.

[!IMPORTANT] DPO ≥ SFT, alignment tax 없음 — 전 항목에서 DPO가 SFT와 같거나 앞섭니다. BoolQ 62.20은 비교 4모델(TinyLlama-1.1B·Pythia-1.0B·OPT-1.3B 포함) 중 1위이고, ~20B 토큰만 학습한 Apex-1이 300B 토큰짜리 Pythia-1.0B를 HumanEval에서 8.54 vs 1.83으로 크게 앞섭니다.

비교 모델: TinyLlama-1.1B(1.1B 파라미터 · 3T 토큰, 2024) · Pythia-1.0B(1.0B 파라미터 · 300B 토큰, EleutherAI) · OPT-1.3B(1.3B 파라미터 · 180B 토큰, Meta) — Apex-1(1.12B 파라미터 · ~20B 토큰) 대비 토큰 수가 각각 150배·15배·9배입니다.

상식 7종·MMLU·GSM8K·HumanEval·MBPP가 각각 뭘 재는 벤치마크인지, 업계에서 얼마나 널리 쓰이는지, 세부 7종 결과(OPT 포함)까지는 → BENCHMARK-v2.md §5.4

더 넓은 비교 — 학습 토큰 규모가 훨씬 큰 2024~2025 소형 오픈모델까지 포함하면(🏆 = 열별 1위):

[!IMPORTANT] 토큰 효율로 읽으면 — Apex-1(0.02T)은 15배 더 학습한 Pythia-1.0B(0.3T)와 상식 평균 동급·ARC는 오히려 앞섭니다. HumanEval 8.5는 Pythia(1.83)의 4.7배이고 3조 토큰인 TinyLlama(9.15)에도 근접 — ~20B 토큰 모델치고 이례적입니다. Llama-3.2-1B(9T)·Qwen2.5-1.5B(18T)와의 격차는 아키텍처가 아니라 데이터 규모 450~900배 차이입니다.

SmolLM2·Qwen2.5는 Apex-1보다 토큰을 550~900배 더 썼습니다 — 여기서 밀리는 건 예상된 결과이고, 토큰 규모가 비슷한 모델과 비교(위 표) 가 이 프로젝트의 실제 위치를 더 공정하게 보여줍니다. 자세히: BENCHMARK-v2.md §5.4

5.3 327M `base` 라인 (펼쳐서 보기)

base (~327M) 기준, 동일 14문항 × THINKING on/off.
최신 스냅샷: sft_base_v6 (ckpt/benchmark_sft_base_v6.json, 2026-07-15).

체크포인트	요약
pretrain v1	채팅 형식에서 사실상 0점 (지시 미학습)
sft v1	지시는 시도함. 정답률은 낮음. THINKING 답 0/14 (태그 미종료)
sft v2	THINKING 종료 대부분 복구 (비어 있지 않은 답 13/14). 코딩은 여전히 약함
sft v3	코딩(일반 채팅) 4/5 완전 통과. 영어 강세, 한국어 전 문항 0점. THINKING 코딩은 여전히 0/5
sft v4	한국어 SFT 비중↑ (10.3%→22.5%). 벤치는 거의 횡보, 한국어 회복은 미미
sft v5	베이스를 pretrain_v2로 교체 + greedy 디코딩. 코딩 첫 만점(5/5), 한국어 회복 시작(8/30)
sft v6	THINKING 핸드오프 해결. prep_sft 전처리 + 추론 예산 분리만으로 사고 평균 0.50→2.93, 사고 코딩 첫 통과(4/5)

sft_base_v6 · 일반 채팅 모드 (THINKING 끔) · 평균 점수 3.93 / 5

영역	결과
한국어	평균 2.67 / 5 (fact 문항 첫 만점)
일본어	평균 3.00 / 5
영어	평균 4.33 / 5
코딩	테스트 25 / 25 (완전 통과 5 / 5)
THINKING 켬	평균 2.93 / 5 · 비어 있지 않은 답 14/14 · 코딩 완전 통과 4/5 (+prime 부분 3/5)

v6 하이라이트 (v5 대비):

• THINKING 핸드오프 문제 해결: 빈 답 4/14 → 0/14 (전부 답변 생성), THINKING 평균 0.50 → 2.93 (약 6배)
• THINKING 코딩 0/5 → 4/5 — 프로젝트 6개 버전 만에 첫 실제 코드 출력 (+prime 부분 통과 3/5)
• 일반 채팅 평균도 동반 상승: 3.21 → 3.93, 코딩 5/5 만점 유지
• 한국어 fact 최초 만점 · 일본어 수학 양쪽 모드 첫 정답 (한국어 합 8/30 → 10/30)
• 베이스·SFT 소스 믹스는 v5와 완전히 동일 — 변화는 오직 데이터 전처리(prep_sft)와 추론 예산 분리뿐
• 남은 문제: 한국어 산술은 여전히 붕괴, 긴 생성의 반복/퇴화, 일→영 번역 미형성

학습 과정·데이터셋·문항별 Q&A (버전별 상세 기록):

• BENCHMARK-v1.md (한국어)
• BENCHMARK-v1.en.md
• BENCHMARK-v1.ja.md

아직 early-stage 입니다. 버전을 올릴 때마다 같은 문항으로 비교할 예정입니다.

---

6. 참고 문헌

---