2단계 두 번째 논문. 이 글은 Hoffmann 외, Training Compute-Optimal Large Language Models arXiv v1(2022-03-29)을 직접 읽고 썼다. 여기서 Chinchilla는 2022년 DeepMind의 연구용 70B(Billion, 10억) autoregressive Transformer다. 2026년의 어떤 공개 API(Application Programming Interface, 응용 프로그램 프로그래밍 인터페이스) 모델이나 “모델을 작게 만들어도 언제나 같다”는 일반 법칙을 뜻하지 않는다. 바로 앞의 Kaplan 외 Scaling Laws 글과 원문으로 대조했지만, 이 글 하나만 읽어도 Chinchilla 논문의 전제·식·실험·한계를 설명할 수 있게 썼다.
이 글에서 얻을 답과 범위
이 논문의 질문은 단순하지만 비싸다.
학습 GPU(Graphics Processing Unit, 그래픽 처리 장치) 예산이 똑같다.
A. 280B parameter 모델을 300B token만 읽힌다.
B. 70B parameter 모델을 1.4T(Trillion, 1조) token 읽힌다.
어느 쪽이 다음 token을 더 잘 예측하고, 실제 과제에서도 더 나은가?
2020년 Kaplan 논문은 당시 조건에서 compute를 주로 큰 모델에 배분하는 경향을 보고했다. 이 논문은 더 넓은 model/token 조합과 learning-rate schedule을 다시 측정해, fixed FLOP(Floating Point Operation, 부동소수점 연산) budget에서는 parameter 수 N과 training token 수 D를 대략 같은 비율로 키워야 한다고 제안했다. 그리고 같은 Gopher training compute에서 Chinchilla를 실제로 학습해 비교했다.
이 글을 다 읽으면 다음 질문에 답할 수 있어야 한다.
- “같은 compute”인데 왜 70B Chinchilla와 280B Gopher의 token 수가 크게 다른가?
N,D,C와6ND근사는 무엇이며, 왜 반올림된 모델 크기로 정확한 비용을 계산하면 안 되는가?- Approach 1, IsoFLOP(동일 FLOP) profile, parametric loss fit은 각각 무엇을 측정하고 왜 셋을 썼는가?
- cosine learning-rate schedule(코사인 학습률 스케줄)의 길이가 scaling 결론을 어떻게 바꿀 수 있는가?
- Chinchilla의 70B 구조·data mixture·optimizer·정밀도는 Gopher와 어디가 같고 다른가?
- MMLU(Massive Multitask Language Understanding, 대규모 다과목 언어 이해) 67.6%를 왜 “모든 업무에서 67.6%”라고 읽으면 안 되는가?
- 데이터 파이프라인 설계자가 이 논문을 내 환경의 작은 실험으로 어떻게 바꾸는가?
범위: 원 논문 §1–§5, Appendix A–I의 compute-optimal allocation, training dataset, architecture, evaluation, bias/toxicity, FLOP 계산, 한계를 다룬다. RAG(Retrieval-Augmented Generation, 검색 증강 생성), fine-tuning(미세조정), RLHF(Reinforcement Learning from Human Feedback, 인간 피드백 강화학습), 최신 MoE(Mixture of Experts, 전문가 혼합) scaling은 이 논문이 풀지 않은 별도 층이다.
먼저 외울 한 문장
Chinchilla 논문은 400개가 넘는 작은~중간 Transformer 학습 run에서 고정 FLOP일 때 loss가 가장 낮은
N과D의 조합을 세 방법으로 추정하고, Gopher와 비슷한 학습 compute로 70B 모델을 1.4T token 학습해 더 큰 280B Gopher보다 넓은 평가에서 대체로 좋음을 보인 연구다.
여기서 “대체로”, “비슷한 compute”, “그 평가”, “2022년 연구”를 빼면 과장이 된다.
왜 필요한가: 거대한 모델을 덜 읽히는 문제와 탄생 배경
12살 비유: 큰 공책을 한 번 훑는 학생 vs 작은 공책을 여러 권 읽는 학생
두 학생에게 같은 공부 시간이 있다고 하자.
Gopher식 학생: 큰 공책 280권 분량을 준비하고, 책 300권 분량만 읽는다.
Chinchilla식 학생: 공책은 70권 분량으로 줄이되, 책 1,400권 분량을 읽는다.
큰 공책은 더 많은 패턴을 적을 공간이 있다. 하지만 시간이 고정이면 한 줄을 처리할 때 드는 계산도 커져 읽을 수 있는 책 수가 줄어든다. 작은 공책은 표현력이 모자랄 수 있지만, 아직 읽지 않은 좋은 책이 많다면 더 많은 예문을 보게 하는 편이 낫다. 논문이 찾는 것은 어느 한쪽이 항상 이기는지가 아니라, 주어진 계산 시간에서 두 병목의 균형점이다.
2022년의 관찰: 많은 큰 dense LLM이 약 300B token에서 멈췄다
논문 확인: 원 논문 Table 1은 당시 대표 dense language model의 학습 token 수로 GPT-3 175B/300B, Jurassic 178B/300B, Gopher 280B/300B, MT-NLG 530B/270B를 제시한다. 모델 크기는 빨리 커졌지만 token 수는 비슷한 범위에 머물렀다는 것이 저자들의 출발점이다. Chinchilla 표에는 70B parameter와 1.4T training token이 적혀 있다.
이 비교에서 중요한 것은 70B < 280B라는 한 줄이 아니다.
학습 품질 = 모델 용량 + 본 고유 data + 학습한 horizon(기간)
+ learning-rate schedule + optimizer + tokenizer
+ numerical precision + data quality + 평가 방법
그래서 논문은 “작은 모델이 이겼다”만 말하지 않고, 3개의 scaling 추정 방법과 실제 large-scale 비교를 같이 냈다. 그래도 Gopher와 Chinchilla에는 Adam/AdamW, tokenizer, data sampling 같은 차이가 남아 있다. 이 사실은 결론의 신뢰도를 낮추기 위한 흠잡기가 아니라, 제품 실험에서 한 변수를 바꿀 때 다른 변수를 기록해야 하는 이유다.
loss가 먼저인 이유와 downstream task가 필요한 이유
사전학습은 이전 token을 보고 다음 token 확률을 맞히는 일이다. 정답 token 확률 p에 대해 loss는 -log(p)다. 문장 전체에서는 다음 평균 cross-entropy loss(교차 엔트로피 손실)를 쓴다.
T는 평가 token 수, x_t는 t번째 정답 token, θ는 모델 weight(가중치)다. loss는 0.49와 0.01처럼 “틀린 답에 둔 확률” 차이도 부드럽게 보여 주므로 scaling 곡선을 맞추기 좋다.
하지만 loss가 낮다고 모든 사용자가 원하는 답을 주는 것은 아니다. 예를 들어 비슷한 loss라도 SQL(Structured Query Language, 구조화 질의 언어)을 안전하게 실행하지 않거나, 최신 사내 규정을 모를 수 있다. 그래서 논문은 language modeling loss뿐 아니라 MMLU, BIG-bench, 독해, 상식, closed-book QA(Question Answering, 질의응답), bias/toxicity를 나누어 평가했다.
무엇인가: compute-optimal의 정의와 하지 않는 일
compute-optimal은 “가장 좋은 모델”이 아니라 “고정 학습 FLOP에서 loss가 가장 낮은 조합”이다
논문의 최적화 문제는 이렇다.
| 기호 | 뜻 | 12살 설명 |
|---|---|---|
N | model parameter count(모델 파라미터 수) | 모델 안의 조절 손잡이 수다. |
D | training tokens seen(학습 중 실제 본 token 수) | 책에서 실제로 읽은 글자 조각 수다. |
C | training FLOPs(학습 부동소수점 연산량) | 계산기에 시킨 곱셈·덧셈 총량의 근사다. |
L(N,D) | final pre-training loss | 학습 끝에 다음 token을 얼마나 잘 맞히는가다. |
N_opt,D_opt | 고정 C에서 loss를 최소로 하는 조합 | 같은 시간에 공책과 독서량을 가장 잘 나눈 값이다. |
이 정의에는 추론 비용이 없다. 다만 Chinchilla는 Gopher보다 parameter가 약 4배 작으므로, 같은 형식의 dense Transformer라면 weight memory와 token당 dense layer 계산이 작아져 fine-tuning·inference cost가 낮아질 가능성이 있다. 실제 서비스 비용은 context length, KV cache(Key/Value cache, 이전 attention 키·값 저장소), batch, hardware, request 수까지 따로 계산해야 한다.
C ≈ 6ND는 유용한 지름길이지 정확한 영수증이 아니다
Kaplan 논문에서 널리 쓰인 근사는 다음이다.
forward pass(순전파) ≈ 2N FLOP / token
backward pass(역전파) ≈ 4N FLOP / token
따라서 학습 ≈ 6N FLOP / token
C ≈ 6 × N × D
Chinchilla 논문 Appendix F는 embedding matrix(임베딩 행렬)까지 포함한 더 자세한 forward FLOP를 세고, backward를 forward의 2배로 가정했다. Table A4는 여러 모델에서 “자세한 계산 / 6ND 근사” 비율이 약 0.99~1.10임을 보여 준다. 충분히 가깝지만 똑같지는 않다.
따라서 아래 두 문장은 함께 참이다.
논문: Chinchilla와 Gopher는 같은 training FLOPs로 학습했다.
반올림 숫자 산술: 6×70B×1.4T = 5.88e23,
6×280B×300B = 5.04e23 이다.
모순이 아니다. 70B, 280B, 1.4T, 300B는 발표용 반올림 값이고, 논문의 FLOP는 embedding을 포함한 상세 구조·정확한 token/parameter 수로 계산했다. 원문 Figure 2·§3은 Gopher 예산을 5.76×10^23 FLOPs로 쓴다. 반올림 홍보 숫자에 6ND를 곱해 “same compute가 거짓”이라고 결론 내리면 안 된다.
이 논문이 하지 않는 일
- 모델·token을 1:1로 키우면 2026년 모든 모델에서 최적이라고 보장하지 않는다.
- data 1.4T token이 고품질·동의·라이선스·개인정보 문제까지 해결됐다는 뜻이 아니다.
- loss나 MMLU가 좋으면 factuality(사실성), 보안, 공정성, tool 권한 제어가 해결된다는 뜻이 아니다.
- 70B 모델의 공개 weight·training source를 제공하지 않는다. 원 논문 model card는 Chinchilla를 공개하지 않는다고 명시한다.
- MoE, multimodal data(여러 데이터 양식), 길어진 context, retrieval이 있는 최신 모델의 정확한 budgeting formula를 제공하지 않는다.
선행 개념: token·FLOP·learning-rate schedule을 섞지 않기
1. 고유 데이터셋과 본 token은 다를 수 있다
이 논문에서는 training token 수 D를 주로 실제 학습 horizon으로 쓴다. dataset에 고유 token이 1T인데 1.4T token을 보면 일부를 다시 읽은 것이다.
unique dataset tokens = 저장된 서로 다른 글 조각
processed/training D = optimizer가 실제로 처리한 글 조각
epochs = processed D / unique dataset tokens
원 논문 Appendix A Table A1은 1.4T token 학습에서 MassiveWeb과 Wikipedia subset은 1 epoch를 넘게 사용한다고 적는다. “Chinchilla는 정확히 한 번만 모든 data를 읽었다”는 말은 틀리다. 또한 training token이 많아도 문서가 중복되거나 test 질문을 포함하면 실질적인 새 지식은 늘지 않는다.
2. learning rate는 학습의 보폭이고, schedule은 보폭 변화표다
learning rate(학습률)는 손실을 줄이기 위해 weight를 한 번 갱신할 때 얼마나 움직일지 정한다. 너무 크면 발산하고 너무 작으면 예산 안에 충분히 배우지 못한다. cosine schedule은 학습률을 처음 크게 두고 시간이 갈수록 곡선 모양으로 낮추는 계획이다.
학습 초반: 큰 보폭으로 거친 방향을 찾음
학습 후반: 작은 보폭으로 loss 바닥 근처를 다듬음
논문 확인: Appendix B와 Figure A1은 cosine cycle length를 실제 training step보다 25% 이상 길게 잡으면, 끝날 때 학습률이 충분히 내려가지 않아 성능이 뚜렷이 나빠졌다고 보고한다. 이 점이 Kaplan 논문과의 핵심 차이 중 하나다. 모델 크기만 아니라 몇 token을 학습할지와 schedule 길이를 시작 전에 함께 정해야 한다.
3. IsoFLOP는 같은 연산 예산 위에서 모델 크기를 바꿔 보는 실험이다
C=10^21 FLOP라는 같은 지갑을 준 뒤, 작은 모델은 긴 D, 큰 모델은 짧은 D로 맞춘다. 각 모델의 최종 loss를 그리면 아래처럼 그릇의 골짜기 모양이 나온다.
loss
높음 큰 모델인데 너무 적게 읽음 작은 모델인데 용량 부족
\ /
\_______최적 N__________/
같은 C
골짜기 왼쪽은 작은 모델 capacity(표현 능력) 병목, 오른쪽은 큰 모델이 충분한 token을 보지 못한 undertraining(학습 부족) 병목이다. “가장 큰 모델”이 아니라 이 골짜기의 바닥을 찾는 것이 compute-optimal이다.
4. bootstrap은 숫자의 확실성을 과장하지 않기 위한 재표본 추출이다
논문 Table 2는 80% run을 무작위로 뽑아 100번 반복하는 bootstrap(부트스트랩)으로 지수의 10th~90th percentile(10·90백분위)을 제시한다. 예를 들어 Approach 2의 a=0.49에는 (0.462, 0.534) 범위가 붙는다. 이는 “정답 지수는 소수점 둘째 자리까지 영원히 0.49”가 아니라, 관측 run을 바꾸면 fit도 움직인다는 투명한 기록이다.
밑바닥 원리: 세 번 다른 방법으로 같은 질문을 검증하기
1. Approach 1 — 학습 곡선의 아래쪽 외피를 찾는다
원 논문 §3.1은 70M(Million, 100만)에서 10B를 넘는 모델을 고르고, 각 크기마다 training horizon이 16배 범위인 4개의 run을 학습했다. 각 run은 cosine schedule로 학습률을 10배 낮췄다.
각 run의 (FLOP, loss) 곡선을 smoothing(평활화)·보간
→ 같은 FLOP 값마다 모든 run 중 최저 loss 선택
→ 1,500개의 로그 간격 FLOP 지점에서 (C, Nopt, Dopt) 추출
→ Nopt ∝ C^a, Dopt ∝ C^b로 power-law fit
이 방법은 곡선의 중간 지점도 쓴다. 논문은 a=0.50, b=0.50을 얻었다. compute 10배에서 N도 약 10^0.50=3.16배, D도 약 3.16배라는 뜻이다.
2. Approach 2 — IsoFLOP 골짜기를 직접 자른다
§3.2는 6×10^18부터 3×10^21 FLOP까지 9개 고정 예산을 만든다. 각 예산에서 model size를 바꾸고, 그 모델이 쓸 token 수는 예산을 맞추도록 정한다. Approach 2는 최대 16B 모델까지 포함했다.
고정 C 하나
→ N=작음, 중간, 큼의 여러 모델을 학습
→ 각 N의 final loss를 점으로 그림
→ loss-N 곡선에 parabola(포물선)를 fit
→ 바닥의 Nopt와 해당 Dopt를 기록
이 방법의 장점은 “고정 budget에 실제 최적 model size가 있는가?”를 그래프의 골짜기로 바로 보여 주는 것이다. 결과는 a=0.49, b=0.51이었다. 포물선은 자연의 진짜 법칙이 아니라, 그 관측 범위의 골짜기 위치를 읽기 위한 local approximation(국소 근사)이다.
3. Approach 3 — L(N,D)라는 지도를 맞춘다
§3.3은 모든 최종 loss를 한 함수로 맞춘다.
| 항 | 뜻 | 아이 비유 |
|---|---|---|
E | ideal generative process의 loss floor | 아무리 잘해도 언어에는 남는 불확실성 바닥 |
A/N^α | function approximation error(함수 근사 오차) | 공책이 작아서 못 담는 부분 |
B/D^β | finite-data/finite-training error | 읽은 책이 부족하거나 한 번만 읽어 덜 배운 부분 |
A,B,α,β | data와 모델 family에 맞춘 값 | 다른 tokenizer·data·학습법이면 다시 맞춰야 하는 값 |
논문 Appendix D.2의 fitted form은 MassiveText 실험에서 다음이다.
이 식을 “자연어의 진짜 방정식”으로 읽으면 안 된다. 논문이 쓴 one-epoch(한 epoch) 근처의 Transformer·data·loss 표면을 설명하는 경험식이다. 저자들은 outlier(튀는 점)에 덜 끌리도록 log loss 차이에 Huber loss(작은 오차는 제곱, 큰 오차는 완만하게 다루는 손실)를 쓰고, L-BFGS(Limited-memory Broyden–Fletcher–Goldfarb–Shanno, 제한 메모리 준-뉴턴 최적화)로 상수를 맞췄다.
4. 식을 고정 compute 위에서 최소화하면 왜 거의 반반이 되는가
근사 C≈6ND 아래에서는 D=C/(6N)이다. 이를 Lhat에 넣고 N으로 미분해 최소점을 찾으면 논문 Eq. 4의 지수가 나온다.
α≈0.34, β≈0.28을 넣으면 a는 약 0.45, b는 약 0.55가 된다. 논문 Approach 3 결과 a=0.46, b=0.54가 이 직관과 맞는다. 둘의 합이 1인 까닭은 N×D가 compute에 비례한다는 제약 때문이다. 하나를 빠르게 키우면 다른 하나는 같은 budget에서 덜 키울 수밖에 없다.
5. 세 방법의 결과가 왜 더 믿을 만한가
| 방법 | 사용하는 관측 | 핵심 결과 Nopt∝C^a / Dopt∝C^b | 약점 |
|---|---|---|---|
| 1. training-curve envelope | 전체 학습 곡선의 최저 외피 | 0.50 / 0.50 | 중간 곡선·보간·schedule 가정 영향 |
| 2. IsoFLOP profile | 고정 C의 final loss 골짜기 | 0.49 / 0.51 | 고른 C·N 격자와 포물선 fit 영향 |
3. parametric Lhat | 모든 final loss의 하나의 표면 | 0.46 / 0.54 | 함수 모양·Huber fit·외삽 가정 영향 |
세 결과가 완전히 같지는 않다. 그래서 “정확히 0.5000”이 아니라 대략 동등 비율이라고 말해야 한다. 서로 다른 실패 방식이 있는 세 분석이 모두 Kaplan의 0.73 / 0.27과 다른 방향을 가리켰고, 뒤의 70B 대 280B large-scale 비교가 그 가설을 한 번 검증했다는 것이 논문의 힘이다.
내부 구조와 실제 실행 흐름: 70B Chinchilla는 무엇을 어떻게 학습했나
1. data pipeline: MassiveText는 한 개의 파일이 아니다
원 논문 §4.1과 Appendix A는 Chinchilla가 Gopher와 같은 MassiveText를 쓰되, 1.4T token 학습에 맞춰 subset sampling 비율을 조금 바꿨다고 적는다.
| subset | disk size | 문서 수 | Chinchilla sampling proportion | 1.4T token에서 epoch |
|---|---|---|---|---|
| MassiveWeb | 1.9TB | 604M | 45% | 1.24 |
| Books | 2.1TB | 4M | 30% | 0.75 |
| C4 | 0.75TB | 361M | 10% | 0.77 |
| News | 2.7TB | 1.1B | 10% | 0.21 |
| GitHub | 3.1TB | 142M | 4% | 0.13 |
| Wikipedia | 0.001TB | 6M | 1% | 3.40 |
표의 epoch가 1보다 큰 MassiveWeb·Wikipedia를 보면, 1.4T token이 모든 원문을 정확히 한 번 읽었다는 말이 아님을 알 수 있다. sampling proportion은 저장 용량 비율도 아니다. 학습 중 어느 source에서 다음 batch를 얼마나 자주 뽑을지 정한 혼합 확률이다. 이 확률을 바꾸면 token 수가 같아도 모델이 보는 언어·코드·책·뉴스의 분포가 달라진다.
2. tokenizer: 같은 문장도 token 수가 달라질 수 있다
Chinchilla는 SentencePiece tokenizer(문장을 subword token으로 나누는 도구)를 사용했고 vocabulary(어휘표) 크기는 32,000이다. Gopher tokenizer와 비교해 NFKC(Normalization Form Compatibility Composition, 유니코드 호환 정규화)를 적용하지 않는 수정이 있다. 원 논문 §4.1은 Gopher와 token의 94.15%가 같고, 수학·화학 표현에 특히 도움이 됐다고 보고한다.
원문 문자열 → tokenizer revision → token ID 배열 → token count D
따라서 “1.4T token”은 character(문자) 1.4T가 아니다. tokenizer가 달라지면 같은 corpus의 D도 달라진다. scaling table의 token 수와 dataset manifest에는 tokenizer revision·어휘표 hash를 같이 남겨야 한다.
3. model: Gopher와 같은 family, 더 좁은 dense Transformer
원 논문 Table 4는 Chinchilla와 Gopher의 핵심 값을 다음처럼 제시한다.
| 항목 | Chinchilla | Gopher | 의미 |
|---|---|---|---|
| total parameters | 70B | 280B | Chinchilla가 약 4배 작다. |
| layers | 80 | 80 | block을 같은 수만큼 쌓는다. |
| attention heads | 64 | 128 | 서로 다른 attention 관점 수다. |
| key/value size | 128 | 128 | head 하나의 key/value 폭이다. |
d_model | 8,192 | 16,384 | 각 token 표현 벡터의 폭이다. |
| FFN inner size | 32,768 | 65,536 | 논문 규칙 4×d_model이다. |
| max learning rate | 1×10^-4 | 4×10^-5 | 가장 큰 갱신 보폭이다. |
| batch size | 1.5M → 3M token | 3M → 6M token | 두 모델 모두 학습 중간에 두 배로 늘린다. |
64 head × 128 = 8,192, 128 head × 128 = 16,384이므로 head 수·head 폭·d_model이 맞물린다. FFN은 token마다 독립적으로 변환하는 넓은 층이다. 4×d_model은 이 논문의 architecture rule이지 모든 Transformer의 법칙이 아니다.
4. precision과 optimizer도 비교 조건이다
논문 확인: §4.1은 forward/backward를 bfloat16(Brain Floating Point 16-bit, 지수 범위를 넓힌 16비트 부동소수점)으로 계산하고, 분산 optimizer state에 float32(32비트 부동소수점) weight 복사본을 저장했다고 쓴다. Chinchilla는 AdamW(Adam with decoupled Weight Decay, 가중치 감쇠를 분리한 Adam)를, Gopher는 Adam을 사용했다. Appendix G는 동일한 크기의 비교에서 AdamW가 Adam보다 나은 결과를 보였다고 제시한다.
따라서 결과를 이렇게 읽어야 한다.
강한 관찰:
이 논문의 Chinchilla training setup은 같은 Gopher compute에서 더 작은/더 길게 학습한
모델이 더 큰 Gopher보다 많은 평가에서 좋음을 보였다.
읽으면 안 되는 과장:
parameter와 token 비율 하나만 바꾸면 optimizer·tokenizer·precision과 무관하게
같은 개선이 보장된다.
5. 실제 공개 구현과 weight의 경계
원 논문 model card Appendix I은 primary intended user를 DeepMind researcher로 적고, 모델을 공개하지 않겠다고 명시한다. 2026-07-24에 google-deepmind와 deepmind GitHub 조직에서 chinchilla 저장소를 검색하고, 자명한 세 저장소 이름에 git ls-remote를 실행했지만 공식 repository HEAD를 찾지 못했다.
이것은 “어디에도 복제 구현이 없다”는 증명이 아니다. 확인한 공식 조직·저장소 이름 범위에서 공개 code/weight를 찾지 못했다는 기록이다. 따라서 이 글은 Chinchilla source를 읽었거나 모델을 실행했다고 주장하지 않는다. 다음 절의 검증은 공개된 논문 수식과 표의 산술을 확인하는 작은 프로그램이다.
직접 검증과 재현: 표의 반올림값·식·메모리 단위를 직접 계산하기
환경과 검증 경계
| 항목 | 직접 실행 값 |
|---|---|
| 운영체제 | macOS 26.4.1 (Build 25E253) |
| 런타임 | Python 3.9.6 |
| 스크립트 | /tmp/chinchilla-research/verify_chinchilla_mechanics.py |
| SHA-256 | e208525b5ffb47829c13f399c89469e6d258fd7662a329a724e5fbc0f960ae77 |
| 검증 대상 | Eq. 2/4/10, Table 2/4/6, 6ND 근사, memory 단위 |
| 검증 제외 | MassiveText 수집, 400여 training run, TPUv3/v4·JAX/Haiku 학습, benchmark 재현 |
아래는 실행한 교육용 전체 코드다. 논문 source나 weight를 대체하지 않는다.
from math import pow
GIB = 2**30
def loss_hat(n, d):
# Appendix D.2 Eq. (10): MassiveText one-epoch fit.
return 1.69 + 406.4 / pow(n, 0.34) + 410.7 / pow(d, 0.28)
def six_nd(n, d):
# Appendix F의 공통 근사. 상세 FLOP와는 약간 다를 수 있다.
return 6 * n * d
chinchilla_n, chinchilla_d = 70e9, 1.4e12
gopher_n, gopher_d = 280e9, 300e9
print("Chinchilla rounded 6ND FLOPs:", f"{six_nd(chinchilla_n, chinchilla_d):.3e}")
print("Gopher rounded 6ND FLOPs:", f"{six_nd(gopher_n, gopher_d):.3e}")
print("Eq.10 Lhat Chinchilla:", round(loss_hat(chinchilla_n, chinchilla_d), 5))
print("Eq.10 Lhat Gopher:", round(loss_hat(gopher_n, gopher_d), 5))
for label, a, b in (("Approach 1", .50, .50),
("Approach 2", .49, .51),
("Approach 3", .46, .54)):
print(f"10x compute {label}: N x{pow(10,a):.3f}, D x{pow(10,b):.3f}")
print("Chinchilla heads * key/value size:", 64 * 128)
print("Chinchilla FFN width (4*dmodel):", 4 * 8192)
print("Chinchilla FP16 weight-only GiB:", round(chinchilla_n * 2 / GIB, 1))
print("MMLU percentage-point gain:", 67.6 - 60.0)
실행 명령과 실제 출력이다.
$ python3 /tmp/chinchilla-research/verify_chinchilla_mechanics.py
Chinchilla rounded 6ND FLOPs: 5.880e+23
Gopher rounded 6ND FLOPs: 5.040e+23
rounded FLOP ratio Chinchilla/Gopher: 1.1667
parameter ratio Gopher/Chinchilla: 4.0
token ratio Chinchilla/Gopher: 4.6667
Eq.10 Lhat Chinchilla rounded point: 1.93665
Eq.10 Lhat Gopher rounded point: 1.99326
10x compute Approach 1: N x3.162, D x3.162
10x compute Approach 2: N x3.090, D x3.236
10x compute Approach 3: N x2.884, D x3.467
Chinchilla heads * key/value size: 8192
Gopher heads * key/value size: 16384
Chinchilla FFN width (4*dmodel): 32768
Chinchilla FP16 weight-only GiB: 130.4
Chinchilla FP32 master-weight-only GiB: 260.8
MMLU absolute gain percentage points: 7.6
MMLU relative gain percent: 12.67
출력에서 확인한 것과 확인하지 못한 것
- 반올림 숫자 경계:
6ND는 Chinchilla5.88e23, Gopher5.04e23을 낸다. 이는 논문의 “같은 exact training FLOPs”와 다르다. 이유는 앞에서 설명했듯 발표용 parameter/token 반올림과 Appendix F의 상세 FLOP 계산 차이다. 스크립트가 반례를 만든 것이 아니라, 근사와 측정값을 구분하게 해 준다. - fitted loss surface: Eq. 10에 반올림된
N,D를 넣으면 Chinchilla 쪽1.93665, Gopher 쪽1.99326이 나온다. 원 논문 final benchmark score나 실제 측정 loss를 재현한 값이 아니다. 해당 fit이 그 방향을 예측하는지 본 산술이다. - 10배 compute: 세 방법 모두
N,D가 대략 3배씩 커진다. “정확히 3.162배”는 Approach 1의 지수에서만 나온다. - 구조 일관성:
64×128=8192,4×8192=32768으로 Table 4의 head·표현 폭·FFN 폭 관계를 확인한다. - 메모리 하한: FP16 weight만
70B×2 byte≈130.4 GiB다. activation, KV cache, temporary buffer, optimizer state, sharding은 빠졌다. “70B를 130GiB 메모리에서 학습할 수 있다”는 뜻이 아니다. - 평가 차이: MMLU
67.6-60.0=7.6은 percentage point(퍼센트포인트) 차이다. Gopher 대비 상대 증가는 약 12.67%지만, 논문 표의 핵심 보고 단위는 7.6p다.
실패를 관찰하는 최소 재현 실습
아래는 model을 학습하지 않고도 내 scaling experiment가 깨졌는지 찾는 최소 절차다.
1. 같은 tokenizer와 document-level split으로 small/medium/large N을 준비한다.
2. 각 N에 short/medium/long training horizon을 둔다.
3. horizon과 cosine cycle length를 함께 늘린다.
4. run마다 N, unique data, processed token D, batch, step, LR curve, seed를 저장한다.
5. 같은 FLOP bucket에서 validation loss의 최저점을 그린다.
6. 큰 N이 짧은 horizon에서 좋지 않다면 "큰 모델이 나쁘다"가 아니라
undertraining / schedule mismatch / data 병목을 먼저 분리한다.
같은 test set을 5번 보며 schedule을 고르면 test leakage(평가 데이터 누출)가 된다. validation으로 선택하고 test는 마지막 한 번만 보아야 한다. 문서 ID·중복 cluster를 기준으로 split하지 않으면 token 수가 많아도 같은 문장이 train/test 양쪽에 남을 수 있다.
성능, 복잡도와 트레이드오프: 70B가 이긴 범위와 비용을 함께 보기
논문이 보고한 대표 결과
아래는 2022년 원 논문의 평가 조건·prompt 형식·데이터에 묶인 수치다. 현재 최고 기록이나 일반 서비스 품질로 읽지 않는다.
| 평가 | Chinchilla | Gopher | 논문이 보여 주는 것 |
|---|---|---|---|
| MMLU 5-shot 평균 | 67.6% | 60.0% | 57개 과목 평균에서 7.6p 높음 |
| LAMBADA zero-shot | 77.4% | 74.5% | 마지막 단어 예측이 더 좋음 |
| RACE-m few-shot | 86.8% | 75.1% | 해당 독해 prompt/평가에서 차이 |
| RACE-h few-shot | 82.3% | 71.6% | 해당 독해 prompt/평가에서 차이 |
| BIG-bench 62 task 평균 | 65.1% | 54.4% | 평균 10.7p 높음, 4 task는 낮음 |
| WikiText-103 perplexity | 7.16 | 7.75 | 낮을수록 다음 token 확률이 좋음 |
논문 확인: §4.2.2는 MMLU 57개 중 Chinchilla가 51개에서 좋고, 2개는 같고, 4개는 낮았다고 적는다. 따라서 평균만 보고 “모든 과목에서 이겼다”고 말하면 틀리다. §4.2.1은 Chinchilla가 Gopher보다 4배 많은 data로 학습됐기 때문에 language modeling benchmark의 train/test overlap이 결과를 인위적으로 높일 수 있어 주의해야 한다고 직접 경고한다.
Chinchilla가 더 작아서 생기는 운영상 이득과 빠진 비용
dense model에서 같은 dtype(수 표현 형식)을 쓴다면 70B weight는 280B weight의 약 1/4이다.
FP16/BF16 weight-only memory
Chinchilla: 70B × 2 byte ≈ 130.4 GiB
Gopher: 280B × 2 byte ≈ 521.5 GiB
이 차이는 deployment sharding(여러 장비로 weight를 나누기), fine-tuning optimizer state, token당 matrix multiplication에 유리할 수 있다. 그러나 실제 inference memory는 다음을 더한다.
weight + KV cache + activation/workspace + runtime buffer + replica 여유분
긴 context나 동시 요청이 많으면 KV cache가 큰 비용이 된다. 그래서 “Chinchilla 원칙 = 무조건 작은 모델을 쓰면 싸다”가 아니다. 같은 목표 품질을 더 작고 충분히 학습된 model로 달성할 수 있으면 학습 뒤 비용까지 줄일 여지가 있다는 뜻이다.
데이터 비용은 계산 비용의 빈칸이 아니다
Chinchilla는 1.4T token으로 data를 크게 늘렸다. data가 무료라면 쉬운 해법처럼 보이지만 실제 파이프라인은 다음 비용을 가진다.
| 단계 | 모델 스케일링만 볼 때 빠지는 비용 | 반드시 남길 증거 |
|---|---|---|
| 수집 | source 권한·crawl 시점·삭제 요청 | source manifest, license, retrieval timestamp |
| 정제 | HTML·spam·malware·PII(Personally Identifiable Information, 개인 식별 정보) | filter version, redaction 통계 |
| 중복 제거 | train/test leakage, 반복 token 부풀리기 | document/near-duplicate cluster ID |
| tokenization | tokenizer 변경으로 D가 바뀜 | tokenizer model hash, vocabulary revision |
| 저장·학습 | shard skew, I/O, 재시도 | shard checksum, processed-token counter |
| 평가 | benchmark contamination | split provenance, evaluation access log |
데이터를 더 읽히는 방향은 데이터 파이프라인의 품질·거버넌스를 더 중요하게 만든다. 이 점이 데이터 파이프라인 설계·구축을 목표로 하는 내 경력과 이 논문이 만나는 지점이다.
실패, 한계, 장애와 운영: “더 많은 token”이 면죄부가 아닌 이유
1. large-scale 검증은 하나의 쌍뿐이었다
원 논문 §5는 비용 때문에 large scale에서 비교 가능한 run이 Chinchilla와 Gopher 두 개뿐이고, 그 사이 규모의 추가 검증이 없었다고 밝힌다. 이는 실험이 거짓이라는 뜻이 아니다. 다만 아래 두 주장을 구분해야 한다.
논문이 강하게 보인 것:
Gopher compute 근처에서 70B / 1.4T Chinchilla가 280B / 300B Gopher를
다수 측정에서 앞섰다.
논문이 아직 보장하지 않은 것:
모든 더 큰 C에서 exact Nopt와 Dopt가 계속 같은 지수로 늘어난다.
저자들은 high-compute 영역에서 log Nopt의 concavity(아래로 휘는 곡률)를 관찰했고, 단순 power law가 큰 모델의 최적 크기를 아직도 과대추정할 수 있다고 썼다(Appendix E, §5). 작은 run의 직선을 1T·10T로 길게 연장하는 것은 특히 위험하다.
2. 한 epoch 미만 분석은 multiple-epoch 환경의 답이 아니다
이 논문의 scaling run은 모두 data 한 epoch 미만에서 학습했다(§5). 그래서 다음 환경에서는 새 실험이 필요하다.
| 내 환경 | 논문 가정과의 차이 | 왜 새로 재야 하나 |
|---|---|---|
| 사내 문서가 작아 여러 epoch 필요 | D가 고유 data보다 processed token에 가까워짐 | 반복 학습·과적합·schedule의 역할이 커진다. |
| code/한국어/의료처럼 분포가 다름 | MassiveText 영어 mixture와 다름 | tokenization·data quality·loss floor가 달라진다. |
| context가 매우 김 | attention·KV cache 비용이 커짐 | 6ND 근사의 빠진 항이 무시하기 어려워진다. |
| MoE·retrieval 모델 | active parameter와 data access 방식이 다름 | dense Transformer frontier를 그대로 쓰기 어렵다. |
| instruction tuned model | 사전학습 loss 외 preference 목적이 추가됨 | “최저 next-token loss”가 최종 목표가 아니다. |
3. safety와 fairness는 loss가 낮아도 자동으로 좋아지지 않는다
원 논문 §4.2.7과 model card는 Chinchilla가 toxic language(유해 언어), gender/occupation stereotype(성별·직업 고정관념), private information(개인 정보)을 포함할 위험이 있다고 적는다. 25,000개 unprompted sample에서 PerspectiveAPI toxicity score의 평균(중앙값)은 Chinchilla 0.087(0.066), Gopher 0.081(0.064)였고 95백분위는 각각 0.238, 0.230이었다. 저자들은 큰 차이가 없다고 해석했다.
그것은 “안전하다”가 아니다. 모델 card는 영어 data로 학습됐고 일부 dialect에서 불균등 성능이 있었으며, downstream application은 추가 safety/fairness mitigation(안전·공정성 완화) 없이 쓰면 안 된다고 명시한다. 특히 dataset이 인터넷에서 수집됐으므로 toxic/biased content와 개인 정보가 있을 가능성을 인정한다.
4. benchmark 성능 장애를 디버깅하는 순서
| 관찰 | 가장 먼저 확인할 근거 | 흔한 잘못된 대응 | 다음 실험 |
|---|---|---|---|
| 큰 model의 final loss가 예상보다 높음 | horizon 대비 cosine cycle length, LR, processed D | N을 더 키운다 | 같은 N에서 cycle length와 D를 함께 sweep |
| train loss만 낮고 validation이 나쁨 | split, duplicate, epoch, data quality | training token을 계속 늘린다 | document-level holdout·dedup·early stop |
| IsoFLOP 골짜기가 안 보임 | N grid가 너무 좁음, measurement noise, budget 산정 | 한 점이 최적이라고 선언 | 더 작은/큰 N과 seed 반복 |
| transfer task가 나쁨 | source/target domain shift, prompt, scoring | base loss만 더 낮춘다 | task-specific held-out evaluation·RAG/finetune 비교 |
| model이 작아졌는데 latency가 안 줄음 | KV cache, request length, batch, network | parameter 수만 비교 | p50/p95 latency와 memory profiler 측정 |
| score가 비정상적으로 좋음 | train-test overlap, benchmark contamination | 홍보 점수로 사용 | provenance·near-duplicate·access log 감사 |
5. 데이터 파이프라인 운영 체크리스트
Chinchilla의 교훈을 실제 회사 data에 적용할 때, 아래 체크가 N:D 비율보다 먼저다.
[ ] source별 수집 시각, 허가, 라이선스, 삭제 요청 경로를 manifest에 저장
[ ] raw → filtered → deduplicated → tokenized 각 revision의 hash를 고정
[ ] PII 탐지·redaction 정책과 false positive/negative 표본을 기록
[ ] document/author/near-duplicate cluster 단위로 train·validation·test 분리
[ ] tokenizer/model/config/dataset/run/checkpoint를 하나의 experiment ID에 연결
[ ] processed token, unique token, epoch, retry token을 따로 계수
[ ] evaluation set 접근·변경을 read-only audit log로 남김
[ ] quality·bias·toxicity·privacy·security 평가를 deployment gate에 포함
이 체크리스트는 논문의 loss를 더 낮추는 마법이 아니다. “1.4T token을 썼다”는 말이 무엇을 뜻하는지 나중에도 검증할 수 있게 만드는 최소 계약이다.
대안, 비교와 선택 기준: 정답 비율을 외우지 말고 내 frontier를 만든다
Kaplan, Chinchilla, 현재 프로젝트는 경쟁 관계가 아니다
| 질문 | Kaplan et al. 2020 | Chinchilla 2022 | 내 프로젝트에서 해야 할 일 |
|---|---|---|---|
| 무엇을 발견? | N/D/C의 매끄러운 scaling과 당시 compute-efficient 경계 | schedule을 포함해 다시 재면 N과 D가 거의 함께 증가 | 내 tokenizer·data·hardware에서 작은 frontier 측정 |
| 10× compute N/D 지수 | 0.73 / 0.27 | 약 0.46~0.50 / 0.50~0.54 | 실험 결과로 선택, 외부 상수 하드코딩 금지 |
| 가장 큰 교훈 | 규모·데이터·연산을 분리해 본다 | undertraining을 피하고 horizon/schedule을 같이 정한다 | 데이터 품질·분할·운영 비용까지 목적 함수에 넣는다 |
두 논문은 서로를 지워 버리지 않는다. Chinchilla는 Kaplan의 프레임을 이용해 다른 더 큰 실험과 schedule로 계수를 재측정했다. 과학적으로 유용한 태도는 최신 지수 하나를 암기하는 것이 아니라, 식의 변수·범위·측정 방법을 내 문제에서 다시 검증하는 것이다.
백엔드·DBA 출신에게 추천하는 6주짜리 작은 frontier 실험
모델을 처음부터 70B로 만들 필요가 없다. 내 경쟁력은 수천 GPU를 빌리는 데 있지 않고, data와 experiment를 설명 가능하게 만드는 데 있다.
1주차 — 문제/측정 계약
- 목표 업무 하나: 예) 운영 로그 원인 분류 또는 사내 문서 근거 답변
- offline quality, latency, cost, privacy/security failure 기준을 명시
2주차 — data contract
- 문서 단위 split, dedup, source/license, tokenizer hash, manifest 고정
3주차 — baseline
- 작은 base model 또는 API baseline의 정확도·loss·token·p95 기록
4주차 — scale grid
- N 3~4개 × horizon D 2~3개를 같은 architecture family에서 실행
- cosine cycle length는 각 target D와 함께 설계
5주차 — frontier
- 같은 FLOP / 같은 wall-clock bucket에서 loss와 업무 metric 최저점 비교
- seed·data slice·prompt 형식별 편차 분해
6주차 — 선택·운영
- 더 좋은 데이터, 더 큰 모델, RAG, fine-tuning, cache 중 다음 투자처 결정
- run manifest·대시보드·재현 명령·실패 분석을 포트폴리오로 정리
이 계획의 산출물은 모델 checkpoint 하나가 아니다. 데이터 revision → 학습 config → 평가 결과 → 비용·지연 → 의사결정이 연결된 pipeline이다. 채용 담당자가 봐도 “LLM을 호출해 봤다”보다 “언제 data를 늘리고, 언제 N을 줄이며, 왜 점수를 신뢰할 수 있는지”를 보여 준다.
사전학습을 늘리는 대신 다른 층을 먼저 고를 때
| 실제 병목 | 먼저 검토할 선택 | Chinchilla가 주는 보조 질문 |
|---|---|---|
| 최신 사내 문서 근거가 없음 | 권한 있는 RAG | base model N보다 corpus freshness·retrieval recall이 병목인가? |
| 반복되는 좁은 output format이 불안정 | few-shot/지도 fine-tuning | 더 많은 pretraining token보다 label 품질·test fixture가 병목인가? |
| 모델이 도메인 문법 자체를 모름 | domain-adaptive pretraining(도메인 적응 사전학습) | N/D/horizon을 작은 grid로 어떻게 재나? |
| 서비스 GPU 비용이 큼 | distillation(지식 증류), cache, routing | same quality를 더 작은 충분히 학습된 모델로 낼 수 있나? |
| 데이터 권한·PII가 불명확 | data governance를 먼저 구축 | token 수를 늘려도 쓸 수 없는 data 아닌가? |
이 논문을 읽고 “무조건 data를 더 모으자”라고 끝내면 반만 이해한 것이다. 문제의 병목이 기초 모델 학습 부족일 때만 이 frontier가 직접 답을 준다.
흔한 오해와 질문의 답
Q1. “Chinchilla는 Gopher보다 작으니 작은 모델이 늘 낫다?”
아니다. 고정 training compute와 논문 조건에서 70B/1.4T 조합이 280B/300B보다 좋았다. 같은 data만 두고 70B로 줄이거나, 추론 품질만 최대화하거나, 다른 model family를 쓰는 상황까지 일반화할 수 없다.
Q2. “동등 scaling은 parameter 수와 token 수를 1:1로 같게 맞추라는 뜻?”
아니다. 70B parameter : 1.4T token처럼 숫자가 같다는 뜻이 아니다. compute를 10배 키울 때 둘 다 대략 3배 키운다는 growth rate(증가율)가 비슷하다는 뜻이다. 단위도 parameter와 token으로 다르다.
Q3. “1.4T token이면 1.4T개의 서로 다른 문장을 봤나?”
아니다. token은 subword 조각이고, Appendix A의 source별 epoch를 보면 일부 subset은 여러 번 샘플된다. token 수는 unique document 수, data 품질, license, 중복 제거 완료를 보장하지 않는다.
Q4. “6ND로 정확히 같은 compute인지 판정하면 되나?”
아니다. 6ND는 좋은 규모 근사다. Appendix F처럼 embedding, sequence length, 구조의 attention/dense 연산, 정확한 parameter를 세면 차이가 난다. 반올림된 발표 숫자는 planning에는 쓸 수 있어도 exact audit에는 부족하다.
Q5. “MMLU 67.6%면 의학·법률·SQL에서 67.6% 정확한가?”
아니다. MMLU 57 task의 5-shot 평균이다. task별 점수는 크게 다르고, 논문도 4 task에서는 Gopher보다 낮았다. 고위험 업무는 해당 도메인의 held-out set, 인간 검토, 권한·감사 경계가 따로 필요하다.
Q6. “loss가 낮아졌으니 toxic output과 bias도 줄었나?”
보장되지 않는다. 논문의 unprompted toxicity 통계는 두 모델 사이 큰 차이가 없었고, Winogender의 group별 성능 차이는 계속 남았다. 더 좋은 language model은 안전 모델의 동의어가 아니다.
Q7. “이 논문만 따라 하면 내 모델 학습 계획이 완성되나?”
아니다. 이 글은 규모를 정하는 사고 도구다. 실제 계획에는 data rights, privacy, tokenizer, architecture, optimizer, hardware throughput, evaluation, inference SLA(Service Level Agreement, 서비스 수준 협약), 안전성, budget을 넣어야 한다. 좋은 시작은 논문 상수를 복사하는 것이 아니라 3×3의 작은 N/D grid와 깨끗한 evaluation contract를 만드는 것이다.
출처
1차 자료
- Jordan Hoffmann et al., Training Compute-Optimal Large Language Models, arXiv:2203.15556v1, 2022-03-29. 이 글의 초록, §1–§5, Eq. 1–4, Figure 1–7, Table 1–10, Appendix A–I, Table A1–A8을 직접 확인했다.
- Jared Kaplan et al., Scaling Laws for Neural Language Models, arXiv:2001.08361v1, 2020-01-23. Chinchilla §1–§3이 대조한
C≈6ND근사와0.73/0.27결론의 원문 확인에 사용했다. - Google DeepMind GitHub repository search API, 2026-07-24의
chinchilla저장소 검색. 빈 검색 결과는 이 글에서 확인한 공개 공식 저장소 범위를 기록하는 자료이며, 공개 구현 전체의 부재를 증명하지 않는다.
직접 실행
/tmp/chinchilla-research/chinchilla.pdf와/tmp/scaling-laws-research/scaling-laws.pdf를 arXiv 원문 PDF에서 내려받아pdftotext로 읽었다./tmp/chinchilla-research/verify_chinchilla_mechanics.py를 macOS 26.4.1, Python 3.9.6에서 실행했다. SHA-256과 실제 출력은직접 검증과 재현절에 기록했다. 이 실행은 논문 표·식의 단위/지수/반올림 경계를 검산한 것이며 Chinchilla training, source, weight, benchmark를 재현한 것이 아니다.
댓글