Scaling Laws for Neural Language Models 해부: 같은 GPU 예산에서 모델·데이터·학습을 어떻게 나눌까

2단계 첫 번째 논문. 이 글은 Kaplan 외, Scaling Laws for Neural Language Models arXiv v1(2020-01-23)을 직접 읽고 썼다. 논문은 WebText2와 2020년의 decoder-only Transformer에서 본 경험적 관측이다. 모든 LLM(Large Language Model, 대규모 언어 모델)의 영구 법칙이나 2026년 학습 레시피가 아니다. 같은 질문을 더 큰 실험으로 다시 측정한 Hoffmann 외, Training Compute-Optimal Large Language Models도 원문으로 대조했다.

이 글에서 얻을 답과 범위

내가 처음 이 제목을 봤을 때의 오해는 이랬다.

"스케일링 법칙 = 모델을 크게 만들수록 좋아진다는 말인가?"

아니다. 이 논문이 묻는 더 정확한 질문은 다음이다.

GPU(Graphics Processing Unit, 그래픽 처리 장치)를 30일만 빌릴 수 있다.

선택 A: 작은 모델을 오래 학습한다.
선택 B: 큰 모델을 짧게 학습한다.
선택 C: 데이터를 더 모으고 모델은 그대로 둔다.

어느 조합이 같은 계산 예산에서 validation loss(검증 손실)를 가장 낮추는가?

논문은 언어 모델의 성능을 cross-entropy loss(교차 엔트로피 손실) L로 측정하고, 다음 세 양을 따로 바꿔 관찰했다.

기호	이름	12살 설명	논문에서의 단위
`N`	non-embedding parameter count(임베딩을 뺀 파라미터 수)	모델 뇌 안에서 학습되는 숫자 수. 단어 사전표·위치표는 제외한다.	개
`D`	dataset size(고유 데이터셋 크기)	준비한 서로 다른 읽을거리의 토큰 수. 같은 글을 여러 번 읽은 횟수와 다르다.	token(토큰)
`C`	training compute(학습 연산량)	학습에 쓴 덧셈·곱셈의 총량. GPU 시간의 근사다.	FLOP 또는 PF-day

이 글을 다 읽으면 다음을 설명할 수 있어야 한다.

N, D, C를 왜 서로 바꾸어 말하면 안 되는가?
power law(멱법칙)가 “성능은 무한히 좋아진다”가 아니라 왜 감소폭이 점점 작아지는 관측 곡선인가?
논문의 C ≈ 6NBS에서 B, S, 6은 무엇이며, 어떤 비용은 빠졌는가?
데이터가 작은데 모델만 키우면 왜 early stopping(조기 종료)이 필요해지는가?
critical batch size(임계 배치 크기)는 속도와 총 연산량을 어떻게 교환하는가?
왜 2020년 논문의 “큰 모델을 짧게” 결론을 오늘 그대로 복사하면 안 되는가?
백엔드·DBA(Database Administrator, 데이터베이스 관리자) 출신이 작은 예산에서 이 논문을 어떻게 실험 계획으로 바꿀 수 있는가?

범위: 원 논문 §1–§8, Appendix A–D의 Transformer 언어 모델 loss scaling, 데이터 부족, 배치·학습 단계, compute-efficient frontier(계산 효율 경계)를 설명한다. 추론 품질, 안전성, RAG(Retrieval-Augmented Generation, 검색 증강 생성), RLHF(Reinforcement Learning from Human Feedback, 인간 피드백 강화학습), Mixture of Experts(MoE, 전문가 혼합)는 이 식만으로 결정되지 않는다. 다음 순서의 Chinchilla 논문은 여기서 후속 반증·선택 기준으로만 비교한다.

먼저 외울 한 문장

이 논문은 Transformer 언어 모델의 손실이 모델 크기 N, 고유 데이터 D, 학습 연산 C에 대해 넓은 범위에서 멱법칙처럼 줄어든다고 관찰하고, 당시 WebText2 실험에서는 고정 계산 예산을 주로 더 큰 모델에 배분해 완전 수렴 전에 멈추는 편이 효율적이라고 추정했다.

당시, WebText2, 손실 세 단어를 빼면 문장이 틀리기 시작한다.

왜 필요한가: GPU를 더 쓰기 전에 풀어야 하는 문제와 탄생 배경

작은 음식점 비유: 주방 크기, 재료, 조리 시간은 같은 것이 아니다

피자 가게를 만든다고 하자.

N(모델 크기) = 주방의 도구와 조리대 수
D(고유 데이터) = 서로 다른 레시피 카드 수
B × S(처리 토큰) = 카드를 한 번에 몇 장(B)씩, 몇 차례(S) 읽었는가
C(연산량) = 도구를 실제로 얼마나 오래 돌렸는가

조리대만 10배 늘리고 레시피 카드가 10장뿐이면, 같은 카드만 반복해서 외울 가능성이 커진다. 반대로 레시피는 산더미인데 주방이 너무 작으면, 배운 내용을 담아 둘 능력이 부족하다. 같은 전기료(C)에서 한 번에 아주 많은 카드를 읽으면 빨리 끝날 수 있지만, 카드마다 충분히 자세히 배우지 못할 수도 있다.

언어 모델도 같다. “파라미터가 70B(Billion, 10억)인가?” 하나만 보면 설계가 보이지 않는다. 그 모델이 몇 토큰을, **몇 번의 parameter update(파라미터 갱신)**로, 어떤 배치 크기에서, 어떤 데이터 품질로 학습됐는지를 함께 봐야 한다.

당시의 실무 병목: 한 번의 큰 학습은 비싸고 되돌리기 어렵다

대규모 사전학습은 실험 하나가 끝날 때까지 수일~수개월이 걸리고, 가속기·전력·데이터 정제 비용을 되돌리기 어렵다. “가장 큰 모델부터 학습해 보고 실패하면 고친다”는 방법은 비용이 너무 크다. 이 논문은 작은 모델부터 큰 모델까지 여러 run(학습 실행)을 관찰해, 아직 하지 않은 큰 run의 loss를 대략 예측할 수 있는지 연구했다.

논문 확인: 원 논문 §1과 §3은 non-embedding parameter(임베딩 제외 파라미터)를 약 768개부터 1.5B까지, 데이터셋을 22M부터 23B token까지 바꾸고, 모델 크기·데이터·연산량에 대한 추세를 관찰했다. 초록은 이 추세가 연산량 기준 7자릿수 이상에 걸쳤다고 적는다. 이것은 “무한한 크기까지 증명했다”가 아니라, 관측한 범위에서 잘 맞는 곡선을 찾았다는 뜻이다.

왜 accuracy(정확도)가 아니라 loss를 썼는가

객관식 정답률은 맞음/틀림 두 칸뿐이다. 모델이 틀린 답의 확률을 0.49에서 0.01로 낮춰도 정답률은 그대로일 수 있다. 다음 토큰 예측은 각 토큰에 준 확률 전체를 보려면 더 부드러운 값이 필요하다. 그래서 논문은 평균 negative log-likelihood(음의 로그 우도), 곧 cross-entropy loss를 기본 지표로 썼다.

정답 token의 확률이 p일 때
loss = -log(p)

p = 1.00  → loss = 0          (완전히 확신)
p = 0.50  → loss ≈ 0.693 nat  (반반)
p = 0.10  → loss ≈ 2.303 nat  (거의 못 맞힘)

여기서 log는 자연로그이고 단위 nat은 natural logarithm unit(자연로그 단위)다. 문장 토큰이 x₁ … x_T일 때 평균 loss는 다음이다.

L = -\frac{1}{T}\sum_{t=1}^{T}\log P_\theta(x_t \mid x_1, \dots, x_{t-1})

T는 평가 토큰 수, P_θ는 가중치 θ를 가진 모델이 앞 토큰을 읽은 뒤 정답 x_t에 준 확률이다. loss가 낮아지면 정답 토큰에 높은 확률을 준다는 뜻이다. 하지만 loss가 0.1 낮아졌다고 요약·코딩·안전성이 같은 정도로 좋아진다는 뜻은 아니다. 원 논문 §8도 loss의 매끄러운 변화가 능력의 질적 변화를 숨길 수 있다고 경고한다.

무엇인가: 멱법칙의 정의와 하지 않는 일

멱법칙은 “X를 두 배 하면 L이 일정 비율로 줄어든다”는 관찰식이다

가장 단순한 형태는 이렇다.

L(X) = \left(\frac{X_c}{X}\right)^{\alpha}

기호	뜻	주의점
`X`	여기서는 `N`, `D`, `C` 같은 한 가지 scale factor(규모 요인)	다른 요인이 병목이면 이 식 하나로 설명 못 한다.
`L`	토큰당 cross-entropy loss	정확도·매출·사실성 그 자체가 아니다.
`α`	exponent(지수)	작을수록 `X`를 크게 늘려도 loss 감소는 느리다.
`X_c`	fit scale(맞춤 상수)	tokenization(토큰화), 어휘 수, 데이터 분포가 달라지면 바뀐다. 자연 상수가 아니다.

예를 들어 논문 Appendix A의 α_N = 0.076을 잠시 사용하면, 파라미터 N을 두 배로 했을 때 loss 비율은 2^(-0.076) ≈ 0.94868이다. 즉 loss가 약 5.1% 줄어든다는 곡선의 비율이지, 모든 벤치마크가 정확히 5.1 percentage point(퍼센트포인트) 좋아진다는 뜻이 아니다.

논문이 실제로 주장한 세 개의 단변수 추세

원 논문 §1.2와 Appendix A Table 5는 다른 병목이 충분히 풀린 조건에서 대략 다음 fit을 제시한다.

관찰 축	조건	지수	원 논문이 말하는 해석
`L(N)`	데이터 충분, 거의 수렴	`α_N ≈ 0.076`	모델 용량 병목을 줄인다.
`L(D)`	모델 충분, 데이터 제한·조기 종료	`α_D ≈ 0.095`	고유 데이터 병목을 줄인다.
`L(C_min)`	모델·배치 크기를 효율적으로 골랐고 데이터 충분	`α_Cmin ≈ 0.050`	고정 compute에서 얻는 최선 loss의 관찰식이다.

C_min은 “아무렇게나 GPU를 쓴 실제 연산량”이 아니다. 논문 §1.3·§5.1의 정의대로 목표 loss에 도달하는 데 필요한 최소 비임베딩 연산량을 추정해 보정한 값이다. 따라서 고정 배치로 쓴 raw C 추세와 같은 숫자로 섞으면 안 된다.

이 논문이 하지 않는 일

이 논문은 다음을 보장하지 않는다.

어떤 데이터가 좋은지, 저작권·동의·개인정보 문제가 없는지 판정하지 않는다.
test loss가 낮으면 환각(hallucination, 근거 없이 그럴듯한 답 생성), 편향, 보안 문제가 해결된다고 말하지 않는다.
특정 GPU·통신·메모리 구성에서 wall-clock time(실제 경과 시간)이 가장 짧다고 보장하지 않는다.
2020년 WebText2·1024-token context의 계수를 2026년 tokenizer, 장문 context, multimodal(여러 양식), MoE 모델에 그대로 적용하라고 말하지 않는다.
“더 큰 모델이 언제나 더 싸다”라고 말하지 않는다. 학습 효율과 serving inference(서비스 추론) 비용은 다른 목적 함수다.

선행 개념: `N`, `D`, `B`, `S`, `C`를 분해해 보기

1. parameter와 embedding을 왜 나눴나

Transformer는 token embedding(토큰 임베딩) 표와 position embedding(위치 임베딩) 표, attention(어텐션)과 FFN(Feed-Forward Network, 피드포워드 신경망) block으로 이뤄진다. 논문 §2.1은 N을 어휘·위치 embedding을 제외한 parameter 수로 정의했다. 작은 모델에서 embedding 표가 차지하는 비율이 크면, 전체 parameter 수를 써서 모델들을 비교할 때 “사전표가 큰가?”와 “계산을 많이 하는 본체가 큰가?”가 섞여 scaling 곡선이 흐려졌기 때문이다.

논문의 표준 Transformer 근사에서는 layer 수 n_layer, 표현 폭 d_model, attention 출력 폭 d_attn, FFN 중간 폭 d_ff로 다음처럼 쓴다.

N \approx 2d_{model}n_{layer}(2d_{attn}+d_{ff}) = 12n_{layer}d_{model}^2

두 번째 등식은 논문에서 쓴 표준 비율 d_attn = d_model, d_ff = 4d_model을 넣은 근사다. bias(편향), LayerNorm(층 정규화) 같은 작은 항은 뺐다. 이 식은 모델을 직접 설계하는 완전한 계산기가 아니라 논문 실험 안에서 N을 한 가지 일관된 방식으로 세기 위한 약속이다.

2. `D`와 `B×S`는 둘 다 token 수지만 질문이 다르다

D       = 고유 학습 말뭉치에 들어 있는 서로 다른 token 수
B × S   = 실제 optimizer가 본 token 수
epoch   = (B × S) / D

D=100억, B×S=300억이면 같은 데이터셋을 평균 세 번 읽은 셈이다. 반복 읽기가 언제나 나쁜 것은 아니다. 작은 데이터에서는 유용할 수 있다. 하지만 모델이 이미 훈련 예문을 너무 잘 외워 test loss가 더 이상 줄지 않으면, 추가 반복은 generalization(일반화)에 도움이 덜 된다. 이 논문 §4의 L(N,D)는 바로 이 데이터 부족·과적합 경계를 모델링하려는 식이다.

3. batch와 step은 속도/효율 레버다

B는 한 update에서 처리하는 token 수, S는 update 횟수다. 총 처리량 E=B×S가 같아도 B=1,000, S=1,000과 B=10,000, S=100은 다르다.

큰 B: 기기를 많이 병렬로 써서 한 update를 빨리 끝낼 수 있다. 하지만 너무 크면 update 하나가 가진 새 정보가 늘지 않아, 같은 목표에 도달하는 총 token/연산 효율이 나빠진다.
작은 B: update를 더 많이 하며 총 연산 효율은 좋을 수 있다. 하지만 serial step(직렬 단계)이 많아 실제 시계 시간은 길어질 수 있다.

논문은 이 균형을 B_crit으로 정리했다. B_crit보다 작으면 batch를 키워도 compute 효율 손실이 작고, 넘으면 속도는 늘어도 총 학습 자원이 더 많이 든다는 관찰이다.

4. FLOP와 PF-day는 돈과 같지 않다

FLOP(Floating Point Operation, 부동소수점 연산) 하나는 실수형 덧셈 또는 곱셈 같은 계산 하나다. 논문은 1 PF-day = 10^15 FLOP/s × 86,400s = 8.64×10^19 FLOP로 쓴다.

그러나 같은 FLOP여도 GPU 세대, memory bandwidth(메모리 대역폭), 통신, kernel 효율, checkpoint I/O(Input/Output, 입출력), 전력 가격에 따라 돈과 실제 시간은 달라진다. C는 비교용 연산 근사이지 청구서가 아니다.

밑바닥 원리: 손실 곡선에서 계산 효율 경계까지

1. 학습 연산 근사 `C ≈ 6NBS`는 어디서 오는가

원 논문 §2.1은 한 token의 Transformer forward pass(순전파)를 대략 2N FLOP로 본다. 행렬 곱에서 곱하고 더하는 일을 둘로 세기 때문이다. backward pass(역전파)는 순전파의 약 두 배 연산으로 근사한다.

forward      ≈ 2N FLOP / token
backward     ≈ 4N FLOP / token
합계         ≈ 6N FLOP / token
전체 token   = B × S

따라서 C ≈ 6 × N × B × S

이 근사는 n_ctx(context length, 문맥 길이)에 비례하는 attention 비용, embedding, LayerNorm, optimizer state update, 통신을 생략한다. 논문 Appendix C도 n_ctx ≳ 12d_model인 아주 긴 context 영역에서는 이 생략이 compute scaling을 교란할 수 있다고 명시한다. 장문 context LLM에 그대로 대입하면 안 되는 첫 이유다.

2. 모델과 데이터가 함께 제한될 때: `L(N,D)`

모델이 너무 작으면 더 많은 데이터를 줘도 지식·규칙을 담을 자리가 부족하다. 반대로 데이터가 너무 작으면 모델을 키워도 반복된 예문에 맞춰질 뿐 새 문장에서 좋아지지 않는다. 논문 §4는 조기 종료된 test loss를 다음처럼 fit했다.

L(N,D) = \left[\left(\frac{N_c}{N}\right)^{\alpha_N/\alpha_D} + \frac{D_c}{D}\right]^{\alpha_D}

이 식을 외우기보다 극한을 읽는 편이 좋다.

D → 매우 큼  : D_c / D → 0, 그래서 모델 크기 N의 병목이 남는다.
N → 매우 큼  : 첫 항이 작아져, 데이터 크기 D의 병목이 남는다.
N과 D가 모두 큼: 두 병목이 함께 줄어든다.

논문 확인: §4.2 Table 2는 이 동시 fit에서 α_N=0.076, α_D=0.103, N_c=6.4×10^13, D_c=1.8×10^13을 보고했다. §1.2의 단변수 fit 값(α_D≈0.095 등)과 완전히 같지 않은 이유는 fit 대상과 조건이 다르기 때문이다. 상수를 아무 표에서나 섞어 새 식을 만드는 것은 잘못이다.

3. 과적합 경계: 큰 모델에 데이터는 얼마나 필요했나

논문은 seed(무작위 초기값) 차이에 따른 loss 변동을 약 0.02로 보고, 그 정도보다 작은 과적합을 목표로 할 때 대략 다음 관계를 제시했다(§4.2 Eq. 4.4).

D \gtrsim (5\times10^3)N^{0.74}

N을 8배 키울 때 필요한 D는 8배가 아니라 약 5배(8^0.74)라는 뜻이다. 하지만 이 또한 WebText2·해당 dropout(드롭아웃)·early stopping 조건의 관찰이다. 데이터의 중복, 품질, 라이선스, 도메인 차이는 이 한 식에 없다.

4. critical batch size: 빨리 끝내기와 적게 쓰기의 교차점

논문 §5.1은 목표 loss 하나를 고정했을 때 최소 step 수 S_min, 최소 처리 예제 수 E_min을 두고 다음 관계를 사용했다.

\left(\frac{S}{S_{min}}-1\right) \left(\frac{E}{E_{min}}-1\right)=1,\quad E=B S

B_crit = E_min / S_min이다. 이곳에서 중요한 것은 B_crit가 “내 GPU의 최대 배치”가 아니라 목표 loss에 따른 통계적 효율의 경계라는 점이다.

B << Bcrit : token은 적게 쓰지만 update가 많아져 느리다.
B ≈ Bcrit  : step과 token 사용 사이의 균형점이다.
B >> Bcrit : step 수는 더 줄 수 있지만, 추가 batch의 효율은 급격히 작아진다.

논문은 B_crit(L) ≈ B* / L^(1/α_B), B*≈2×10^8 token, α_B≈0.21이라 fit했다. loss가 낮아질수록 더 큰 batch가 효율적인 영역이 된다는 관찰이다. 현실에서 batch를 정할 때는 이론식뿐 아니라 GPU memory, all-reduce 통신, gradient accumulation(기울기 누적), optimizer 안정성, checkpoint 간격을 함께 재야 한다.

5. 고정 compute에서 무엇을 키우라는 결론이 나왔나

논문은 L(N,S_min)의 두 병목을 더했다.

L(N,S_{min})= \left(\frac{N_c}{N}\right)^{\alpha_N} +\left(\frac{S_c}{S_{min}}\right)^{\alpha_S}

여기서 α_S≈0.76이다. 계산 예산 제약 C_min≈6NB_critS_min 안에서 이 loss를 최소화하면, 원 논문 Appendix A Table 6의 경험적 결과는 다음이었다.

같은 효율 조건에서 compute를 키울 때	2020년 논문 지수	compute 10배일 때 배율
최적 모델 `N_opt`	`C_min^0.73`	약 `5.37×`
임계 배치 `B`	`C_min^0.24`	약 `1.74×`
최소 직렬 단계 `S_min`	`C_min^0.03`	약 `1.07×`
한 epoch 고유 data `D_opt`	`C_min^0.27`	약 `1.86×`

그래서 원 논문은 “당시 조건에서는 대부분의 추가 compute를 더 큰 모델에 쓰고, 모델을 완전 수렴 전 약간 일찍 멈추는 편이 효율적”이라고 결론 내렸다. Appendix B는 효율 경계에서 converged loss보다 약 α_N/α_S≈10% 위에서 멈추는 해석을 제시한다. 이는 최고 품질만이 아니라 “주어진 학습 FLOP에서 손실 최소”라는 목적 함수의 답이다.

내부 구조와 실제 실행 흐름: 논문 실험은 무엇을 고정하고 무엇을 바꿨나

1. 실험의 입력에서 숫자 하나까지의 흐름

이 논문은 거대한 모델 하나를 한 번 돌린 보고서가 아니다. 많은 작은·중간 모델을 통제된 방식으로 학습하고, 마지막의 test loss들을 곡선으로 fit한 실험이다. 원 논문 §2–§3의 흐름을 실행 관점으로 다시 쓰면 다음과 같다.

WebText2 문서
  → BPE(Byte Pair Encoding, 바이트 쌍 인코딩) tokenizer
  → 1,024-token 문맥 조각
  → decoder-only Transformer의 다음 token 확률
  → cross-entropy loss
  → Adam / 큰 모델은 Adafactor optimizer로 θ 갱신
  → WebText2 held-out test와 다른 분포의 text에서 loss 기록
  → N / D / B / S를 달리한 여러 run의 곡선을 fit
  → 고정 compute에서 가장 낮은 loss를 내는 N을 찾음

논문 확인: §2.2는 기본적으로 512개 sequence × 1024 token 배치, 2.5×10^5 step, 3,000-step linear warm-up(선형 워밍업) 뒤 cosine decay(코사인 감쇠)를 썼다고 기록한다. 1B parameter보다 큰 모델은 memory constraint(메모리 제약) 때문에 Adafactor를 썼다. §2.3은 WebText2가 20.3M 문서, 96GB text, reversible BPE 기준 2.29×10^10 token이며 그중 6.6×10^8 token을 test로 남겼다고 적는다. 이 숫자는 WebText2 당시 버전의 사실이지, 오늘 공개 웹 전체를 뜻하지 않는다.

2. 같은 파라미터 수에서 모양이 크게 중요하지 않았다는 뜻

모델 크기 N이 같아도 n_layer=6의 넓은 모델과 n_layer=48의 더 좁은 모델은 다르다. 논문 Figure 5–6은 극단을 제외한 넓은 범위에서 depth(깊이), width(폭), head 수, FFN 비율의 영향이 총 비임베딩 파라미터 수보다 작았다고 관찰했다. Figure 5 설명은 aspect ratio(폭/깊이 비율)를 약 40배 바꿔도 손실 차이가 작았던 비교를 제시한다.

이 결과를 “구조 설계는 중요하지 않다”로 번역하면 틀린다.

논문이 말한 것:
  해당 Transformer, 해당 범위, 해당 loss에서는 N의 영향이 더 컸다.

논문이 말하지 않은 것:
  attention 구현, positional encoding, normalization, optimizer,
  context length, sparse/MoE 구조, 하드웨어 효율은 아무 의미가 없다.

오늘의 모델에서 RoPE(Rotary Position Embedding, 회전 위치 임베딩), GQA(Grouped-Query Attention, 그룹 질의 어텐션), MoE, long-context attention은 품질·메모리·서빙 비용을 크게 바꾼다. 이 논문의 shape independence를 그런 선택의 면허로 쓰면 안 된다.

3. 검증 분포가 바뀌어도 loss 차이가 거의 일정했던 관찰

논문 §3.2.2와 Figure 8은 WebText2 test loss가 좋아질수록 Books, Common Crawl, Wikipedia, Internet Books의 loss도 대체로 같은 방향으로 좋아지며, 분포마다 거의 일정한 offset(간격)이 있었다고 보고한다. 이를 다음처럼 읽을 수 있다.

WebText2와 비슷한 문장 예측을 더 잘함
  ≠ 모든 업무·모든 언어·모든 안전 제약에서 충분히 잘함

이것은 transfer의 한 종류의 손실 측정일 뿐이다. 한국어 SQL 설명, 사내 규정 Q&A(Question and Answer, 질의응답), 코드 수정 정확성에는 별도 evaluation set(평가 세트)이 필요하다.

4. 실제 공개 구현의 경계

직접 확인: 2026-07-24에 https://api.github.com/search/repositories?q=scaling+laws+user%3Aopenai를 조회했을 때 결과 저장소 목록은 비어 있었다. openai/scaling-laws-for-neural-language-models, openai/scaling_laws, openai/scaling-laws에 대해 git ls-remote ... HEAD도 HEAD를 돌려주지 않았다. 원 논문에는 재현용 training source나 checkpoint(학습 중간 저장본) URL이 없다.

이 결과는 “세상 어디에도 복제 구현이 없다”는 증명이 아니다. 확인한 OpenAI 소유 저장소 이름과 API 검색 범위에서 공식 구현을 찾지 못했다는 기록이다. 따라서 이 글은 비공개 논문 코드를 읽었다거나 1.5B 모델을 재학습했다고 주장하지 않는다. 아래 실습은 논문 식·단위·지수의 작은 산술 검증이다.

직접 검증과 재현: 식을 숫자로 내려 보기

환경과 재현 범위

항목	직접 실행 값
운영체제	macOS 26.4.1 (Build 25E253)
런타임	Python 3.9.6
스크립트	`/tmp/scaling-laws-research/verify_scaling_laws_mechanics.py`
SHA-256	`95b249a84c7f63d2ddfa6760966bb542488af41df5e16332982c5de158165519`
재현하는 것	§1.2, §2.1, §4.2, §5.1, §6.1, Appendix A의 산술·단위
재현하지 않는 것	WebText2 수집, 768~1.5B 모델 학습, loss curve fit, 논문 benchmark

다음은 실행한 전체 스크립트다. 원 논문 모델이나 data를 흉내 낸 코드가 아니라, 식에서 변수 하나를 잘못 곱하거나 지수를 뒤집지 않기 위한 teaching toy(교육용 작은 계산기)다.

from math import pow

PF_DAY_FLOPS = 1e15 * 24 * 60 * 60

# 논문 §2.2의 기본 batch: 512 sequence × 1024 token, 250,000 update.
n = 1_000_000_000          # non-embedding parameters
b = 512 * 1024             # tokens / update
s = 250_000                # updates
compute = 6 * n * b * s    # §2.1: C ≈ 6NBS

print("paper setup batch tokens:", b)
print("training FLOPs (6*N*B*S):", f"{compute:.6e}")
print("training PF-days:", round(compute / PF_DAY_FLOPS, 3))

for label, exponent in (
    ("optimal N", 0.73), ("optimal B", 0.24),
    ("minimum S", 0.03), ("one-epoch D", 0.27),
):
    print(f"10x compute -> {label} multiplier:", round(pow(10, exponent), 3))

print("2x parameters -> L multiplier:", round(pow(2, -0.076), 5))
print("10x compute-min -> L multiplier:", round(pow(10, -0.050), 5))
print("Eq. 4.4 data for N=1B tokens:", f"{5e3 * pow(n, 0.74):.3e}")

실행 명령과 실제 출력의 핵심은 다음이다.

$ python3 /tmp/scaling-laws-research/verify_scaling_laws_mechanics.py
paper setup batch tokens: 524288
training FLOPs (6*N*B*S): 7.864320e+20
training PF-days: 9.102
10x compute -> optimal N multiplier: 5.37
10x compute -> optimal B multiplier: 1.738
10x compute -> minimum S multiplier: 1.072
10x compute -> one-epoch D multiplier: 1.862
2x parameters -> L multiplier: 0.94868
10x compute-min -> L multiplier: 0.89125
Eq. 4.4 data for N=1B tokens: 2.285e+10
Bcrit at L=4.0 tokens: 271693
Bcrit at L=3.0 tokens: 1069114
Bcrit at L=2.5 tokens: 2547285
Eq. 4.1 fitted L(N=1B,D=22.9B): 2.3675

출력 하나씩 해석하기

524288은 512×1024다. 원 논문 기본 batch가 sequence 개수만이 아니라 token 단위로 약 2^19개라는 확인이다.
7.864320e+20 FLOP / 8.64e+19 = 9.102 PF-day다. 이것은 1B parameter라는 임의의 예시에 기본 batch·step을 넣은 근사다. 논문의 전체 모델 비용 표가 아니다.
10배 compute에서 N이 약 5.37배, 한 epoch의 D가 약 1.86배가 되는 출력은 Appendix A 지수의 단순 거듭제곱이다. “각 수를 10배”가 아님을 눈으로 확인한다.
0.94868은 파라미터 2배에 대한 loss 비율이다. 기존 loss가 3.0이라면 같은 조건의 식은 2.846 정도를 예측한다. 모델 품질이 94.868%라는 뜻이 아니다.
Eq. 4.4의 2.285e10은 1B parameter에 대해 논문의 약 0.02 loss variation 기준을 넣은 값이다. WebText2의 약 22.9B token과 비슷한 크기가 나오는지 확인한 것이다. 데이터 품질 검증을 면제하지 않는다.
loss가 4.0→2.5로 낮아지는 목표에서는 B_crit가 약 0.27M→2.55M token으로 커진다. 더 좋은 loss를 겨냥할수록 큰 배치가 효율적인 영역이라는 fit을 수로 본다. GPU가 이 배치를 반드시 담을 수 있다는 뜻은 아니다.

한 값을 바꿔 보는 실패 실습

N=1B을 유지하고 데이터만 Eq. 4.4의 절반으로 두면, 이 논문의 “과적합이 0.02 이내”라는 경험적 조건을 만족하지 않는다. 그러면 선택지는 네 가지다.

잘못된 대응: loss가 나빠졌으니 모델을 더 키운다.

점검 순서:
1. train loss와 held-out validation loss를 같은 tokenization으로 분리해 기록한다.
2. document-level deduplication(문서 단위 중복 제거)·train/test leakage를 확인한다.
3. unique D, processed B×S, epoch 수를 각각 기록한다.
4. data가 실제 병목이면 더 다양한 고품질 D를 확보하거나 N을 낮춘다.
5. dropout·weight decay·learning-rate schedule을 바꿨다면 별도 실험으로 취급한다.

여기서 validation loss만 보고 멈출 때를 고르면 early stopping이다. test set은 마지막 보고용으로 남기는 것이 좋다. test를 계속 보며 종료 시점을 고르면 test도 개발 데이터처럼 오염된다.

성능, 복잡도와 트레이드오프: 같은 점수표가 아닌 두 비용표를 보라

멱법칙의 작은 지수는 큰 예산을 요구한다

Appendix A의 α_Cmin≈0.050이면 효율적 compute를 10배로 늘렸을 때 loss 곱은 10^-0.05≈0.89125다. 감소는 약 10.9%다. C를 100배로 해도 100^-0.05≈0.794다. 그래서 scaling은 “늘리면 좋아진다”와 “늘릴수록 비싸다”가 동시에 참이다.

목표	무엇을 줄이나	이 논문이 도움 되는 질문	이 논문만으로 답할 수 없는 질문
학습 loss	`N`, `D`, `C` 병목	다음 작은 실험의 규모를 어떻게 정할까?	답변이 사실인가?
학습 wall-clock	`B`, 병렬화	큰 batch가 step을 얼마나 줄일까?	특정 클러스터의 통신 병목은?
inference cost	모델 크기·KV cache	작은 모델로도 목표 loss가 가능한가?	실제 QPS(Query Per Second, 초당 요청 수)와 p95 latency는?
데이터 비용	고유 `D`, 품질·정제	데이터 병목처럼 보이는가?	라이선스·개인정보·도메인 적합성은?

training-efficient와 serving-efficient는 다를 수 있다

논문의 목적 함수는 pretraining FLOP 안에서 loss를 줄이는 것이다. 제품의 총 비용은 보통 다음처럼 더 넓다.

총비용 = 사전학습 + 데이터 정제 + 실험 실패분 + 저장/네트워크
       + 매일의 추론 GPU + 사람 검수 + 장애/보안 비용

학습 때 큰 모델을 쓰는 것이 효율적이어도, 요청이 수억 건이면 작은 distilled model(지식 증류 모델)이나 routing(요청 라우팅), cache가 더 싸울 수 있다. 반대로 모델을 지나치게 작게 고르면 few-shot·tool use처럼 복잡한 업무에서 품질 검수 비용이 커질 수 있다. 그러므로 C_min 앞의 “min”을 회사 비용 전체의 최소로 읽으면 안 된다.

추론·학습 모두에서 관찰할 지표

시점	반드시 남길 값	왜 필요한가
데이터 수집	raw/filtered/deduplicated token, unique document, license	`D`가 단순 파일 크기가 아닌지 확인한다.
학습	model revision, N 정의, B, S, processed tokens, epoch, LR schedule	다른 run과 비교 가능한 단위를 만든다.
품질	train/validation/test loss, 도메인별 task metric, seed	loss 개선이 재현되는지 확인한다.
시스템	accelerator utilization, memory, communication time, checkpoint duration	FLOP 근사와 실제 시간의 차이를 찾는다.
서비스	prompt/output token, p50/p95 latency, cost/request, refusal/error rate	학습 효율을 제품 효율로 오해하지 않는다.

p50은 중앙값, p95는 요청의 95%가 그 값 이하인 지연 시간이다. 평균 latency 하나만 보면 긴 prompt나 재시도 때문에 생기는 tail latency(꼬리 지연)를 숨길 수 있다.

실패, 한계, 장애와 운영: 이 식이 깨지는 곳을 먼저 적기

1. 원 논문 스스로 밝힌 한계

원 논문 Appendix C는 이 결과를 만능 규칙으로 만들지 않았다. 특히 다음 한계를 직접 적었다.

한계	왜 위험한가	운영에서의 대응
이론적 유도 부재	식이 잘 맞은 이유와 어느 지점에서 꺾일지를 확정할 수 없다.	작은 규모 pilot(사전 실험)으로 내 데이터 곡선을 먼저 맞춘다.
`B_crit` 외삽 불확실	관측 범위 밖 loss에서 batch 예측이 틀리면 병렬화·학습 시간 계획이 어긋난다.	batch sweep(여러 배치 크기 실험)과 throughput 측정을 한다.
아주 작은 `D`에서 fit 불량	가장 작은 데이터셋은 epoch당 40 step뿐이어서 다른 regime(동작 영역)일 수 있었다.	작은 사내 데이터에 큰 모델 식을 바로 대입하지 않는다.
regularization 미탐색	dropout, augmentation, weight decay가 경계를 바꿀 수 있다.	바꾼 hyperparameter마다 동일 scale 비교를 다시 한다.
긴 context 비용 생략	`6NBS`에 attention의 context 비례 항을 빼었다.	실제 profiler와 context-length별 FLOP/메모리를 기록한다.
hyperparameter 미완전 tuning	initialization, momentum, learning rate가 scaling 자체를 바꿀 수 있다.	한 run 실패를 모델 크기 탓으로 단정하지 않는다.

논문 §6.3은 더 큰 문제도 보여 준다. 자체 추세를 아주 멀리 외삽하면 compute-efficient data 사용량은 느리게 늘어나지만, 과적합을 막는 데 필요한 데이터는 더 빨리 늘어나 모순이 생긴다. 논문은 이 교점 근처에서 자신의 법칙이 깨져야 한다고 썼다. 그때의 수치 C*~10^4 PF-day, N*~10^12, D*~10^12, L*~1.7 nat/token은 매우 불확실하며 지수값에 따라 한 자릿수 규모로 달라질 수 있다고 명시했다. 이를 “자연어의 절대 한계가 1.7”이라고 인용하면 틀리다.

2. 후속 연구가 바꾼 가장 중요한 처방: Chinchilla

여기서 원 논문을 멈추면 2020년식 결론만 남는다. Hoffmann 외(2022)는 70M~~16B parameter, 5B~~500B token의 400개 이상 모델 실험을 바탕으로 같은 고정 FLOP 질문을 다시 측정했다. 초록은 compute-optimal 조건에서 모델 parameter 수와 학습 token 수를 같은 비율로 키워야 한다고 보고한다.

compute를 10배로 할 때	Kaplan et al. 2020	Hoffmann et al. 2022의 세 추정 접근
`N_opt` 배율	`10^0.73 ≈ 5.37×`	대략 `10^0.46~0.50 ≈ 2.9~3.2×`
`D_opt` 배율	`10^0.27 ≈ 1.86×`	대략 `10^0.50~0.54 ≈ 3.2~3.5×`
핵심 메시지	큰 모델 비중을 크게 늘린다.	parameter와 token을 대략 함께 늘린다.

논문 확인: Chinchilla §1–§3은 이 차이를 명시한다. 저자들은 Kaplan 논문이 모든 모델에 고정된 training token 수와 learning-rate schedule을 사용해, 짧은 horizon의 중간 loss를 실제로 그 horizon에 맞춘 schedule로 학습한 loss보다 과대평가했을 수 있다고 분석했다. 또한 더 큰 모델 범위를 사용했다. 이는 후속 저자들의 방법론적 설명이며, 2020년 논문이 쓸모없다는 판정이 아니다. 같은 질문에 대해 실험 범위·학습 schedule·데이터가 달라지면 지수도 달라진다는 가장 좋은 실증이다.

Chinchilla는 같은 Gopher compute budget에서 70B parameter와 1.4T token으로 학습한 모델을 제시했고, 280B Gopher보다 여러 downstream task에서 앞섰다고 보고했다(초록·§4). 이 비교가 오늘의 수치 처방으로도 영구 보장되는 것은 아니다. dense Transformer, 해당 데이터 혼합, 해당 평가의 결과다. 하지만 “Kaplan의 0.73/0.27을 프로젝트 요구사항에 하드코딩하지 말라”는 충분한 근거다.

3. 데이터 파이프라인 관점에서 더 자주 실패하는 지점

백엔드·DBA 시각에서는 식의 지수보다 데이터 계약이 먼저 깨지는 경우가 많다.

원본 문서
  → 수집 시각·권한·라이선스 기록
  → PII(Personally Identifiable Information, 개인 식별 정보) 탐지/제거
  → 문서/문단 near-duplicate(유사 중복) 제거
  → 언어·도메인·품질 분포 샘플링
  → tokenizer 버전 고정 후 token count
  → train/validation/test를 문서 단위로 분리
  → manifest(파일 목록·해시·통계) immutable 저장
  → 학습 run의 dataset revision 연결

다음 두 run이 모두 “D=100B token”이라고 말해도 같은 실험이 아닐 수 있다.

run A: 동일한 문서를 10회 중복, 일부 benchmark 문제를 포함
run B: 출처·언어·중복을 관리한 100B token, held-out test 문서와 분리

스케일링 법칙은 D의 양을 수치로 다루지만 데이터의 독립성·품질·법적 사용 가능성을 대신 측정하지 않는다. 데이터 파이프라인 설계·구축을 목표로 한다면, 이 한계를 통제하는 일이 모델 parameter를 외우는 것보다 직접적인 경쟁력이다.

4. 장애를 “loss가 안 떨어진다” 하나로 뭉개지 말기

관찰	먼저 의심할 것	확인 방법	다음 조치
train·validation loss 모두 평평	learning rate가 너무 작음, model capacity 부족, data pipeline 오류	token 샘플·gradient norm·LR·작은 overfit test	입력·label shift 확인 후 LR/model sweep
train만 계속 하락, validation 상승	데이터 부족·중복·leakage·과적합	unique `D`, epoch, dedup rate, split 키	early stop, data 확대, N 축소, split 재작성
큰 batch에서 throughput만 좋고 최종 loss 나쁨	`B > B_crit`, LR scaling 불안정	B별 tokens/sec와 동일 FLOP loss 비교	B 감소·gradient accumulation·schedule 재조정
예측보다 loss가 높음	논문 범위 밖 tokenizer/data/context/optimizer	run metadata와 가정 비교	내 환경의 scaling fit을 새로 수집
학습은 성공, 서비스가 비쌈	inference 목적 함수 누락	request token, KV cache, p95, cost/request	smaller model, batching, cache, routing 비교

gradient norm은 가중치 갱신 크기를 나타내는 기울기 벡터의 길이다. 0에 가깝거나 갑자기 폭증하면 optimizer가 학습하지 못하거나 발산할 신호일 수 있다. 단, 정상 임계값은 모델·optimizer·정규화 방식마다 다르므로 이 글의 숫자로 alert를 고정하면 안 된다.

5. 보안과 재현성은 scale보다 먼저 고정한다

학습 데이터와 checkpoint는 다음 권한 경계를 가져야 한다.

dataset manifest / source URL / license / hash → read-only audit log
raw privileged data                         → 최소 권한, 별도 접근 정책
tokenized training shard                    → versioned immutable object
evaluation set                              → 개발자 변경 금지, 접근 기록
checkpoint / experiment config              → run ID로 1:1 연결

loss가 낮아도 학습 데이터 출처를 재현할 수 없거나 evaluation set이 개발 중 노출되면 결과를 신뢰하기 어렵다. 모델 크기를 정하는 식과 이 접근 제어는 대체 관계가 아니라, 같은 실험을 두 번 해석하기 위한 전제다.

대안, 비교와 선택 기준: 논문 상수를 복사하지 말고 작은 경계를 만든다

세 가지 선택지는 목표 함수가 다르다

선택	언제 맞는가	장점	반드시 지불할 대가
Kaplan 식을 학습용 추정치로 쓴다	역사적 원리를 배우고, 논문과 가까운 조건에서 초기 가설이 필요할 때	`N/D/C`를 분리해 생각하게 한다.	2020 계수를 최신 모델에 그대로 적용하면 위험하다.
Chinchilla식 token 비중을 우선 검토한다	dense language-model pretraining의 현대 출발점이 필요할 때	undertraining을 피하는 강한 반례를 제공한다.	데이터 품질·도메인·학습 schedule을 따로 검증해야 한다.
내 데이터로 local scaling study(국소 스케일링 실험)를 한다	실제 예산·도메인·tokenizer·목표 task가 정해졌을 때	내 목적 함수에 맞는 선택이 된다.	작은 실험 설계와 메타데이터 관리가 필요하다.

내가 추천하는 것은 세 번째다. 첫째와 둘째는 “무엇을 바꿔야 할지” 알려 주는 지도다. 실제 배포 결정을 대신하는 GPS(Global Positioning System, 위성 위치 확인 체계)가 아니다.

12살도 따라 할 수 있는 작은 scaling study

175B 모델을 만들 필요가 없다. 업무와 예산이 작아도 관계를 측정하는 습관은 같다.

목표: 사내 기술 문서를 바탕으로 다음 문장 예측을 잘하는 작은 한국어 모델을 비교한다.

1. 목적 지표를 두 개로 정한다.
   - pretraining validation loss
   - 실제 업무 held-out set의 요약/분류/검색 후 답변 품질

2. 데이터 계약을 고정한다.
   - 문서 ID로 train/validation/test 분리
   - tokenizer revision, dedup 방법, license를 manifest에 남김

3. 네 개 정도의 N을 고른다.
   - 예: 30M, 60M, 120M, 240M
   - architecture family와 context length는 우선 고정

4. 각 N에 두세 개 D/horizon을 배치한다.
   - 같은 `N`에서 짧게/중간/길게 학습
   - B, S, processed token, epoch, LR schedule을 전부 기록

5. 같은 validation set에서 loss와 실제 업무 지표를 함께 그린다.
   - 한 seed만 믿지 말고 가능한 run을 반복
   - 가장 큰 모델 하나만 비교하지 않는다.

6. 같은 FLOP 또는 같은 wall-clock bucket에서 최저 loss 후보를 찾는다.
   - inference latency/cost도 같이 붙인다.

7. 다음 큰 run은 그 경계 근처에서만 선택한다.
   - 데이터가 병목이면 수집·정제에 투자
   - 모델이 병목이면 N을 키움
   - 시스템이 병목이면 B·병렬화·I/O를 바꿈

여기서 architecture family는 같은 종류의 모델 골격을 뜻한다. 모델 층 수·폭을 한꺼번에 바꾸면서 tokenizer·데이터·learning rate까지 바꾸면, 손실이 왜 달라졌는지 알 수 없다. 실험은 빨리 많이 하는 일이 아니라 한 번의 차이를 해석 가능하게 만드는 일이다.

RAG·fine-tuning·더 많은 사전학습 중 무엇을 고를까

이 논문의 목표는 base model pretraining(기초 모델 사전학습) loss다. 회사에서 “모델 지식이 최신이 아니고 사내 문서 근거를 답해야 한다”는 문제는 N을 늘려도 해결되지 않는다.

현재 문제	우선 선택	scaling law가 주는 보조 질문
최신 사내 문서에 근거해 답해야 함	RAG와 권한 있는 retrieval	모델 학습보다 corpus freshness·retrieval recall이 병목인가?
좁고 반복되는 출력 형식이 불안정	supervised fine-tuning(지도 미세조정) 또는 few-shot 평가	pretraining 규모보다 label 품질·평가 set이 병목인가?
도메인 언어 자체를 모델이 전혀 모름	계속 사전학습 또는 domain model	데이터 양·품질·N의 조합은 어떤 경계인가?
비용·지연이 큼	smaller model, distillation, cache, routing	학습 최적과 inference 최적이 충돌하는가?
모델을 처음부터 만드는 연구	scaling study	내 stack에서 `N/D/C` 관계는 실제로 어떻게 측정되는가?

이 표가 말하는 핵심은 “스케일링 법칙을 무시하라”가 아니다. 병목 이름이 사전학습 loss가 아닐 때는 다른 층의 문제를 먼저 푼다는 뜻이다.

흔한 오해와 질문의 답

Q1. “파라미터를 두 배 하면 성능도 두 배인가?”

아니다. 원 논문의 α_N≈0.076에서 loss 비율은 약 0.94868이다. 더 많은 parameter가 보통 더 낮은 loss와 연결됐다는 관찰이지, 정확도·사용자 만족도·안전성이 선형으로 두 배가 된다는 뜻이 아니다.

Q2. “`C≈6NBS`만 알면 학습 비용을 정확히 견적 낼 수 있나?”

아니다. 이 식은 논문이 non-embedding compute를 비교하기 위해 만든 근사다. context attention, optimizer, network all-reduce, memory stall, checkpoint, 재시도, GPU 가격은 빠졌다. 실제 예산은 작은 profiling run에서 tokens/sec, utilization, 메모리, 통신 시간을 측정해 곱해야 한다.

Q3. “Kaplan 논문의 결론은 Chinchilla가 나왔으니 틀린 지식인가?”

아니다. N/D/C를 분리해 측정하고 멱법칙적 추세·과적합·batch/step 교환을 한 프레임으로 만든 기여는 남는다. 다만 compute-optimal 배분의 수치는 후속 연구의 더 큰 범위·다른 schedule에서 달라졌다. 이 차이는 논문 읽기의 결론이 “숫자 암기”가 아니라 “가정과 측정 범위 확인”이어야 하는 이유다.

Q4. “그러면 지금은 무조건 model과 token을 1:1로 키우면 되나?”

아니다. Chinchilla의 동등 비율도 그 논문의 dense Transformer·데이터·학습·FLOP 정의에서 나온 결과다. long context, MoE, multimodal data, 고품질 데이터 고갈, inference 비용, 실제 task metric이 바뀌면 경계도 바뀐다. 현재 프로젝트에서는 작은 local scaling study로 확인한다.

Q5. “데이터만 많이 모으면 작은 모델도 큰 모델을 이기나?”

아니다. L(N,D)의 두 항이 보여 주듯 model capacity와 data는 서로의 병목을 없애지 않는다. 모델이 작아 N 항이 크면 D만 늘리는 이득은 작아지고, 데이터가 부족하면 N만 늘리는 이득도 작아진다.

Q6. “batch는 GPU 메모리가 허용하는 최대치로 하면 되나?”

아니다. 최대 batch는 hardware limit이고 B_crit는 목표 loss에서의 효율 경계다. 서로 다른 질문이다. 최대 batch가 B_crit보다 훨씬 크면 총 처리 token·연산 효율이 악화될 수 있다. 반대로 B_crit보다 작으면 gradient accumulation으로 유효 batch를 키우는 실험을 할 수 있지만, 통신·학습률·수렴을 반드시 다시 검증해야 한다.

Q7. “loss가 좋으면 채용 포트폴리오도 좋은가?”

아니다. 좋은 포트폴리오는 “큰 모델을 돌렸다”가 아니라 아래를 보여 준다.

문제 정의 → 데이터 권한/분할/중복 관리 → 재현 가능한 run config
→ baseline과 scale 비교 → 품질·비용·지연의 같은 표 → 실패 원인 분석
→ 왜 다음 투자처가 모델/데이터/시스템 중 하나인지 설명

이 과정은 데이터 파이프라인 설계·구축을 목표로 하는 백엔드/DBA 경력과 직접 연결된다. 단순히 최신 모델 API를 호출하는 사람보다, 데이터 revision·권한·평가·운영 지표를 연결해 다음 실험이 왜 필요한지 말할 수 있는 사람이 된다.

Q8. “이 글만 읽고 1T 모델 계획을 승인해도 되나?”

안 된다. 이 글은 논문을 이해하고 작은 실험의 질문을 설계하는 기반이다. 실제 승인에는 데이터 권리, 개인정보 영향, hardware 공급, 전력·예산, failure budget(실패 허용 비용), 보안 위협 모델, 서비스 SLA(Service Level Agreement, 서비스 수준 협약), 모델 평가가 별도로 필요하다.

출처

1차 자료

Jared Kaplan et al., Scaling Laws for Neural Language Models, arXiv:2001.08361v1, 2020-01-23. 이 글의 초록, §1–§8, Eq. 1.1–1.8·2.1–2.2·4.1–4.4·5.1–5.5·6.1–6.8, Figure 1–16, Table 1–6, Appendix A–D를 직접 확인했다.
Jordan Hoffmann et al., Training Compute-Optimal Large Language Models, arXiv:2203.15556v1, 2022-03-29. 초록, §1–§4, Table 1–3을 읽어 Kaplan 논문의 compute-optimal allocation과 후속 결과가 왜 다른지 대조했다.
OpenAI GitHub repository search API, 2026-07-24에 조회한 scaling laws 저장소 검색. 검색 결과가 빈 목록이었던 직접 확인의 재조회 경로다. 이는 공식 구현 전체의 부재를 증명하는 자료가 아니다.

직접 실행

/tmp/scaling-laws-research/scaling-laws.pdf와 /tmp/scaling-laws-research/chinchilla.pdf를 각각 arXiv 원문 PDF에서 내려받아 pdftotext로 읽었다.
/tmp/scaling-laws-research/verify_scaling_laws_mechanics.py를 macOS 26.4.1, Python 3.9.6에서 실행했다. SHA-256과 실제 출력은 직접 검증과 재현 절에 기록했다. 이 실행은 원 논문 식의 단위·거듭제곱 검산이며, 대규모 언어 모델 학습 재현이 아니다.