Korean LLM v4는 어떤 프로젝트인가?
Korean LLM v4는 약 1.09B, 즉 약 10억 9천만 개의 파라미터를 가진 Decoder-style Transformer 기반 한국어 LLM 프로젝트입니다.
프로젝트 설명에서 특히 강조되는 변화는 단순히 모델 크기를 키운 것이 아니라 학습 파이프라인을 Pretraining과 SFT로 분리했다는 점입니다. 이전 버전에서는 instruction 데이터 중심 학습 비중이 컸지만, v4에서는 일반적인 언어 패턴을 먼저 학습하는 Pretraining 단계와 이후 질의응답 형식에 맞추는 SFT(Supervised Fine-Tuning) 단계를 분리했습니다.
기술 사양과 아키텍처
| 항목 | 공개 내용 |
|---|---|
| 모델 구조 | Decoder-style Transformer |
| 파라미터 | 약 1.09B |
| Hidden Dimension | 1,920 |
| Transformer Layers | 20 |
| Attention Heads | 10 |
| Head Dimension | 192 |
| FFN Hidden | 4,800 |
| FFN / Activation | SwiGLU |
| Normalization | RMSNorm |
| Positional Encoding | RoPE |
| Attention 구현 | PyTorch Scaled Dot-Product Attention |
| Weight Tying | 적용 |
| Tokenizer | beomi/Llama-3-Open-Ko-8B |
| 모델 클래스 Max Sequence | 2,048 tokens |
| 기본 학습 Sequence | 512 tokens |
| Training Precision | BF16 |
| Optimizer | AdamW8bit 지원, 미지원 환경에서는 AdamW |
| Gradient Checkpointing | 지원 |
| KV Cache | 지원 |
| 학습 단계 | Pretraining → SFT |
| 기본 Pretraining | 100,000 steps |
| 기본 SFT | 10,000 steps |
| Validation Split | 2% |
| Seed | 42 |
구조 자체는 현대적인 Decoder Transformer에서 널리 사용하는 구성요소를 채택하고 있습니다. 위치 정보를 처리하기 위한 RoPE, normalization의 RMSNorm, Feed-Forward Network의 SwiGLU가 사용됩니다.
출력 projection과 token embedding의 weight를 공유하는 weight tying이 적용되어 있고, 추론 시 이전 token의 Key/Value를 반복 계산하지 않도록 KV Cache를 지원합니다. 학습 메모리를 줄이기 위해 BF16, gradient checkpointing, gradient accumulation, 가능한 경우 bitsandbytes의 8-bit AdamW를 사용할 수 있도록 구성되어 있습니다.
beomi/Llama-3-Open-Ko-8B
Transformer Block × 20
FFN Hidden: 4,800
공개된 README와 소스 코드를 기반으로 단순화한 구조입니다. 실제 구현의 모든 연산 경로를 표현한 것은 아닙니다.
v4의 핵심은 Pretraining 이후 SFT
v4에서 눈여겨볼 부분은 기존 instruction 중심 학습에서 벗어나 언어 자체를 먼저 학습하는 Pretraining과, 질문에 어떻게 답할지를 학습하는 SFT를 구분했다는 점입니다.
Korean Text Corpus
↓
Pretraining
↓
Base Checkpoint
↓
SFT
↓
Korean LLM v4SFT 단계에서는 response-only loss가 사용됩니다. 질문 영역까지 동일하게 loss를 계산하는 대신, 질문에 해당하는 label을 -100으로 masking하고 응답 token에 대해서만 실제 cross entropy loss를 계산하는 방식입니다.
### 질문: 한국의 수도는?
### 응답: 서울입니다.
질문 토큰 → label = -100 → loss 계산 제외
응답 토큰 → 실제 loss 계산이 방식은 모델이 사용자 프롬프트 자체를 예측하는 것보다 응답 부분을 생성하는 능력에 학습 신호를 집중시키는 데 목적이 있습니다.
학습 데이터는 어디까지 공개됐나?
Hugging Face metadata에는 다음 데이터셋들이 training dataset으로 표시됩니다.
beomi/KoAlpaca-v1.1a, nlpai-lab/kullm-v2, AdaMLLab/KorMix
다만 현재 공개된 Python 코드의 기본 DEFAULT_SFT_DATASETS에는 KULLM-v2와 KoAlpaca-v1.1a 두 데이터셋이 기본값으로 정의되어 있습니다. 따라서 Hugging Face metadata에 KorMix가 표시된다는 이유만으로 KorMix 전체가 어떤 비율로 최종 Pretraining에 사용됐다고 단정하기는 어렵습니다.
| 항목 | 확인 결과 |
|---|---|
| KoAlpaca-v1.1a | HF metadata 및 코드에서 확인 |
| kullm-v2 | HF metadata 및 코드에서 확인 |
| KorMix | HF metadata에 표시 |
| KorMix가 현재 기본 Pretraining 구성인지 | 확인되지 않음 |
| Pretraining 총 Token 수 | 미지시 |
| Dataset Mixing Ratio | 미지시 |
| 데이터 수집 기간 | 미지시 |
| Knowledge Cutoff | 미지시 |
| 한국어 비중 | 미지시 |
| 영어·기타 언어 비중 | 미지시 |
| 중복 제거 비율 | 미지시 |
| PII 제거 방법 | 미지시 |
| 유해 콘텐츠 Filtering | 미지시 |
| Benchmark Contamination 검사 | 미지시 |
학습 데이터 범위가 정확히 공개되지 않은 상태에서는 knowledge cutoff, 실제 한국어 학습 비율, benchmark 데이터 오염 여부를 외부에서 완전히 검증하기 어렵습니다. 공개되지 않은 값은 추정하기보다 미지시 또는 확인되지 않음으로 보는 편이 안전합니다.
README 내부에는 Gradient Accumulation의 기본값을 다르게 설명하는 부분도 확인되기 때문에, 실제 재현을 시도할 때는 설명문보다 실행 시점의 코드와 commit hash를 고정하는 것이 좋습니다.
현재 바로 다운로드해서 사용할 수 있는 모델인가?
2026년 9월 12일 기준 Hugging Face의 seoan1024/Korean-llm-v4 저장소는 전체가 약 154 kB 수준입니다.
저장소에는 README, LICENSE, assets, korean_llm_advanced_v4.py 등의 소스가 있으나, 1B급 학습 완료 모델에서 일반적으로 볼 수 있는 .safetensors, 대용량 .bin, 학습 완료 .pth 형태의 weight 파일은 확인되지 않습니다.
Hugging Face 페이지에도 현재 Inference Provider에 배포되어 있지 않음이 표시되어 있습니다.
“1.09B 학습 완료 모델 weight가 공개됐다”기보다는 “1.09B 규모의 한국어 LLM 구조와 Pretraining → SFT 학습 파이프라인을 포함한 오픈소스 프로젝트가 공개됐다”고 보는 편이 정확합니다.
API와 가격
| 공식 Hosted API | 현재 확인되지 않음 |
|---|---|
| Hugging Face Inference Provider | 미배포 |
| API 가격 | 미지시 |
| Self-host | 코드상 가능하나 직접 학습한 checkpoint 필요 |
| 공식 응답 속도 | 미지시 |
| 공식 GPU 비용 | 미지시 |
Korean LLM v4의 성능은 어느 정도일까?
현재 가장 조심해서 해석해야 하는 부분입니다. Korean LLM v4에는 아직 KMMLU-Pro, KMMLU-Redux, HAE-RAE, CLIcK 등 널리 사용되는 한국어 표준 벤치마크의 공개 점수가 확인되지 않습니다.
따라서 현 시점에서 EXAONE보다 좋다거나 Qwen보다 낫다, Gemma보다 한국어를 잘한다고 결론을 내릴 객관적인 근거는 없습니다. 파라미터 수와 실제 모델 능력은 동일한 개념이 아니며, Pretraining token 규모, 데이터 품질, post-training, 평가 방법 등이 모두 성능에 영향을 줍니다.
비교 기준을 만들기 위해 LG AI Research의 EXAONE 4.0 Technical Report에 포함된 small-size / non-reasoning 모델의 동일 비교표를 참고할 수 있습니다. 아래 수치는 서로 다른 홍보 페이지의 숫자를 임의로 섞은 것이 아니라, 동일 기술 보고서 표 안에서 제시된 값을 기준으로 정리한 것입니다.
| 모델 | Params | KMMLU-Pro | KMMLU-Redux | KSM | Context | 동등환경 속도 | 라이선스 |
|---|---|---|---|---|---|---|---|
| Korean LLM v4 | 약 1.09B | N/A | N/A | N/A | 2,048 / 학습 기본 512 | 미지시 | GPL-3.0 코드 |
| EXAONE 4.0 1.2B | 1.28B | 37.5 | 40.4 | 26.3 | 65,536 | 공식 통일 수치 미지시 | EXAONE 1.2-NC |
| Qwen3 1.7B | 1.72B | 29.5 | 29.8 | 16.3 | 32K | 공식 통일 수치 미지시 | Apache 2.0 |
| Qwen3 0.6B | 596M | 24.6 | 22.8 | 0.1 | 32K | 공식 통일 수치 미지시 | Apache 2.0 |
| Gemma 3 1B | 1.00B | 9.7 | 19.4 | 22.8 | 32K | 공식 통일 수치 미지시 | Gemma Terms |
여기서 Korean LLM v4의 N/A는 0점을 의미하지 않습니다. 같은 평가 방식의 공개 결과가 없기 때문에 비교값을 넣을 수 없다는 뜻입니다.
KMMLU-Pro 점수 시각화
위 막대는 100점 만점 중 점수의 상대적 크기를 보여주기 위한 것입니다. 하나의 벤치마크 점수가 모델 전체 품질을 의미하지는 않습니다.
왜 단순한 벤치마크 숫자 비교를 조심해야 할까?
한국어 LLM 벤치마크에서는 같은 모델이라도 prompt template, few-shot 설정, decoding parameter, evaluator 구현에 따라 결과가 달라질 수 있습니다.
HRET(Haerae Evaluation Toolkit) 관련 연구에서는 같은 모델도 기관이나 평가 방식에 따라 결과가 상당히 달라질 수 있으며, prompt template, inference setting, evaluation criterion 등이 주요 원인이 될 수 있음을 지적합니다.
같은 dataset version, 같은 split, 같은 prompt, 같은 chat template, 같은 decoding 설정, 같은 evaluation metric을 사용해야 합니다. 서로 다른 리포트의 점수를 한 표에 단순히 섞어 순위를 만들면 왜곡될 수 있습니다.
한국어 LLM 평가에서 자주 등장하는 벤치마크
| 벤치마크 | 주요 평가 영역 | 해석 시 주의점 |
|---|---|---|
| KMMLU | 한국어 기반 다분야 지식·문제 해결 | Prompt와 평가 harness 조건을 함께 확인해야 함 |
| KMMLU-Pro / Redux | 전문성·난도·정제 수준을 강화한 한국어 평가 | Reasoning 여부와 decoding 조건을 맞춰야 함 |
| HAE-RAE 계열 | 한국어 언어·문화·지식 능력 | 평가 버전과 세부 task 구성이 중요 |
| CLiCK | 한국 문화·언어 맥락 관련 평가 | 언어 능력 전체를 하나의 점수로 대표하지는 않음 |
Korean LLM v4를 직접 검증한다면
향후 공식 checkpoint가 공개되거나 동일 설정으로 직접 학습한다면, 최소한 아래 항목을 고정해 평가하는 것이 좋습니다.
- Git commit SHA와 코드 버전 고정
- Python·PyTorch·CUDA·Tokenizer revision 기록
- 동일 checkpoint hash 기록
- KMMLU-Pro / KMMLU-Redux 실행
- HAE-RAE 또는 CLIcK 등 한국어 benchmark 추가
- 동일 system prompt와 chat template 사용
- Temperature·Top-p·Max tokens 고정
- Accuracy 외에 한국어 출력 일관성 평가
- TTFT와 output tokens/sec 측정
- Peak VRAM과 p50·p95 latency 측정
- Safety·Bias·Hallucination 평가를 별도로 수행
# 예: 저장소와 commit 고정
git clone https://github.com/seoan1024/Korean-llm-v4.git
cd Korean-llm-v4
git rev-parse HEAD
# 실행 환경 기록
python --version
pip freeze > requirements-lock.txt
# Pretraining
python korean_llm_advanced_v4.py \
--stage pretrain \
--pretrain-steps 100000
# SFT
python korean_llm_advanced_v4.py \
--stage sft \
--sft-steps 10000다만 위와 같이 새로 학습한 모델을 원 개발자가 보유한 checkpoint와 완전히 동일한 모델이라고 가정해서는 안 됩니다. dataset revision, random seed, GPU kernel, 실제 데이터 구성 등 차이가 발생할 수 있기 때문입니다.
응답 속도는 어떻게 비교해야 할까?
현재 Korean LLM v4의 표준화된 inference latency는 공개되어 있지 않습니다. 따라서 1.09B라는 파라미터 수만 보고 다른 모델보다 빠르다고 말하기는 어렵습니다.
| TTFT | 입력 후 첫 token이 생성될 때까지 걸리는 시간 |
|---|---|
| Tokens/sec | 초당 생성하는 output token 수 |
| End-to-End Latency | 요청부터 전체 답변 완료까지의 시간 |
| p50 / p95 | 평균 하나가 아니라 실제 latency 분포 |
| Peak VRAM | 최대 GPU memory 사용량 |
실제 비교에서는 같은 GPU, 같은 precision, 같은 batch size와 context 길이를 사용해야 모델 간 속도·메모리 차이를 의미 있게 해석할 수 있습니다.
라이선스와 상업적 사용은?
GitHub와 Hugging Face에 표시된 Korean LLM v4 프로젝트의 소스코드 라이선스는 GPL-3.0입니다.
여기서 중요한 것은 “GitHub 코드 라이선스 = 학습 완료 모델과 데이터셋의 모든 상업적 권리”는 아니라는 점입니다. 실제 서비스를 구성하려면 tokenizer, pretraining dataset, SFT dataset, 최종 checkpoint에 적용되는 조건을 각각 검토해야 합니다.
프로젝트 README에서도 사용하는 각 Hugging Face dataset의 라이선스와 이용 조건을 별도로 확인해야 한다는 취지의 안내가 있습니다.
현재 공개된 코드가 GPL-3.0이라는 사실만으로 “Korean LLM v4를 어떤 조건에서도 상업적으로 사용할 수 있다”고 단정해서는 안 됩니다. 실제 사용 데이터셋, tokenizer, 추후 공개될 weight의 조건을 함께 검토해야 합니다.
보안·프라이버시·편향은 검증됐나?
현재 공개 문서에서는 Korean LLM v4를 대상으로 한 safety benchmark, red-team 결과, jailbreak robustness, toxicity test, bias benchmark, PII memorization test 등의 정량 결과가 확인되지 않습니다.
| 평가 항목 | 공개 여부 |
|---|---|
| Safety Benchmark | 미지시 |
| Red Team | 미지시 |
| Jailbreak Test | 미지시 |
| Bias Evaluation | 미지시 |
| PII Filtering | 미지시 |
| Copyright Filtering | 미지시 |
이는 모델이 안전하지 않다는 의미가 아니라, 외부에서 안전성이 충분히 검증됐다고 판단할 공개 근거가 아직 부족하다는 의미입니다.
실제 서비스에 적용한다면 hallucination, 유해 요청, 개인정보 재현, prompt injection, jailbreak, 편향, 저작권 관련 출력 재현 여부까지 별도 검증하는 것이 필요합니다.
어떤 용도에 적합할까?
| 활용 분야 | 현재 판단 |
|---|---|
| LLM 구조 학습 | 추천 |
| Transformer 직접 구현 분석 | 추천 |
| Pretraining / SFT 실험 | 추천 |
| 한국어 데이터 파이프라인 연구 | 추천 |
| 개인 GPU 학습 실험 | 조건부 추천 |
| Production Chatbot | 현재 검증 부족 |
| 기업 고객 서비스 | 현재 검증 부족 |
| 금융·의료·법률 의사결정 | 권장하지 않음 |
| 개인정보 포함 서비스 | 검증 전 권장하지 않음 |
현재 공개 상태를 기준으로 보면 Korean LLM v4는 상용 챗봇을 바로 교체하기 위한 모델보다 LLM 구조와 학습 과정을 공부하고 실험하기 위한 프로젝트에 더 가깝습니다.
특히 Transformer를 직접 구현해 보고 싶거나, 한국어 corpus를 이용한 Pretraining, response-only SFT, validation, checkpoint 저장과 generation 흐름을 학습하려는 개발자에게는 좋은 참고 자료가 될 수 있습니다.
현재 시점에서 Korean LLM v4를 어떻게 봐야 할까?
Korean LLM v4의 의미는 “1B급 상용 한국어 LLM이 하나 더 등장했다”기보다는 “개인 개발자가 한국어 LLM의 architecture부터 Pretraining·SFT·checkpoint·generation까지 하나의 학습 프로젝트로 직접 구현하고 공개했다” 는 데 더 가깝습니다.
특히 v4에서 Pretraining과 SFT를 분리하고, response-only loss, BF16, gradient checkpointing, AdamW8bit, KV cache까지 포함했다는 점은 LLM이 실제로 어떻게 학습되고 동작하는지 공부하려는 개발자에게 유용한 자료입니다.
반면 현재는 학습 완료 weight가 공개된 상태로 확인되지 않고, 표준 한국어 benchmark, latency, safety evaluation도 공개되어 있지 않습니다. 따라서 EXAONE·Qwen·Gemma를 대체할 수준의 모델이라고 결론 내리기는 아직 이릅니다.
향후 확인할 핵심은 명확합니다. 실제 checkpoint 공개, Pretraining token과 dataset 구성 공개, KMMLU-Pro·Redux 결과, 한국어 생성 품질, inference 속도와 VRAM, safety·bias·hallucination 평가가 추가되어야 보다 객관적인 모델 간 비교가 가능해집니다.
자주 묻는 질문
Korean LLM v4는 Google이 만든 모델인가요?
seoan1024 계정이며 GitHub와 Hugging Face에 공개되어 있습니다. Google의 공식 생성형 AI 계열은 Gemini와 Gemma가 별도로 안내됩니다.1.09B면 Gemma 3 1B보다 한국어 성능이 좋은가요?
Hugging Face에서 바로 다운로드해 실행할 수 있나요?
개인 GPU에서 학습할 수 있나요?
상업 서비스에 바로 사용할 수 있나요?
참고 자료와 원출처
| 출처 | 확인 용도 | 링크 |
|---|---|---|
| Korean LLM v4 GitHub | 모델 구조·코드·학습 설정·제한 | GitHub 원본 |
| Korean LLM v4 Hugging Face | 파일·데이터셋 metadata·Inference 상태 | Hugging Face |
| GeekNews | v4 공개 맥락 | GeekNews |
| EXAONE 4.0 Technical Report | 1B급 모델 성능 비교·KMMLU 수치 | arXiv |
| EXAONE 4.0 1.2B | 모델 카드·라이선스·제한사항 | 공식 모델 카드 |
| Qwen3 공식 발표 | 모델 사양·Context·Apache 2.0 | Qwen 공식 |
| Gemma 3 Model Card | Gemma 3 공식 사양 | Google AI |
| Google AI for Developers | Google의 Gemini·Gemma 공식 제품군 확인 | Google AI |
| HRET | 한국어 LLM 평가 재현성 연구 | arXiv |
| KMMLU | 한국어 Multitask LLM Benchmark | arXiv |