Scaling Laws와 Pre-training

분류: Layer 11 - AI 기초 & 머신러닝 | 선수지식: L11-30 (ML 패러다임), L11-40 (신경망), L11-50 (트랜스포머)

Scaling Laws와 Pre-training — N, D, C를 어떻게 배분할 것인가

1. 한 줄 정의

Scaling laws는 모델 파라미터 수(N), 학습 토큰 수(D), 학습 연산량(C) 이 커질 때 loss가 어떤 속도로 줄어드는지 관찰한 경험 법칙이다. Pre-training은 이 법칙을 참고해 대규모 원시 데이터로 foundation model의 가중치를 처음부터 학습하는 단계다.

이 문서의 핵심 질문은 하나다.

한정된 compute가 있을 때
파라미터를 더 키울 것인가, 데이터를 더 먹일 것인가, 아니면 추론 비용까지 보고 다른 균형점을 잡을 것인가?

2. 왜 중요한가

LLM을 이해할 때 “큰 모델이 좋다”는 말은 출발점일 뿐이다. 실제 의사결정은 더 구체적이다.

모델 크기 결정: 7B, 13B, 70B, 405B, MoE 중 무엇을 학습하거나 사용할지 판단한다.
데이터 규모 결정: 7B 모델에 140B tokens만 넣을지, 1T+ tokens까지 반복 학습할지 판단한다.
비용 견적: pre-training FLOPs, GPU-hours, MFU(Model FLOPs Utilization)를 자릿수로 추정한다.
분산 학습 설계: data/tensor/pipeline parallelism과 ZeRO/FSDP가 왜 필요한지 설명한다.
도메인 적응 선택: continual pretraining, fine-tuning, RAG(Retrieval-Augmented Generation, 검색 결과를 프롬프트에 넣는 방식), prompt 중 무엇이 비용 대비 맞는지 고른다.
추론 비용까지 포함한 최적화: 학습 compute가 조금 더 들어도 작은 모델을 오래 쓰면 총비용이 낮을 수 있다.
Reasoning 모델 이해: 품질을 올리는 compute가 train-time에서 test-time으로도 이동한다.

Scaling laws를 외우는 목적은 논문 이름을 맞히는 것이 아니다. 목적은 품질을 올리는 자원을 N, D, C, inference compute 중 어디에 넣을지 설명하는 것이다.

2.5 선행 기술의 한계 — “Bigger is Better” 직감은 왜 부족했나

Scaling laws 이전에도 연구자들은 모델이 커지면 좋아지는 경향을 알고 있었다. 문제는 “얼마나 커야 하는가”와 “데이터도 같이 얼마나 늘려야 하는가”를 말할 수 없었다는 점이다.

예를 들어 같은 예산으로 두 선택지가 있다고 하자.

선택 A: 175B parameters 모델에 300B tokens를 학습한다.
선택 B: 70B parameters 모델에 1.4T tokens를 학습한다.

직감만으로는 A가 더 좋아 보인다. 파라미터가 훨씬 많기 때문이다. 하지만 Chinchilla 결과는 같은 compute 근처에서 B가 더 나을 수 있음을 보여줬다. 모델이 너무 크고 데이터가 부족하면, 큰 모델은 “배울 공간”은 많은데 충분히 채워지지 않은 상태가 된다. 반대로 모델은 작아도 데이터를 충분히 많이 보면 같은 compute에서 loss가 더 낮아질 수 있다.

이 한계가 scaling laws의 등장 이유다. Pre-training은 더 이상 “가장 큰 모델을 만들자”가 아니라 정해진 compute 안에서 N과 D를 배분하는 최적화 문제가 되었다.

3. Scaling Laws의 기본 언어

3.1 N, D, C

이 문서에서 계속 쓰는 세 기호는 다음과 같다.

기호	뜻	직관	늘릴 때 생기는 비용
N	파라미터 수	모델이 패턴을 저장하고 조합하는 용량	메모리, 학습·추론 연산, 통신 비용
D	학습 토큰 수	모델이 보는 예시의 양	데이터 수집·정제, 학습 step, 법적 검토
C	학습 compute, 보통 FLOPs로 근사	학습에 쓴 총 연산량	GPU-hours, 전력, 실패 시 재시작 비용

Parameter는 학습되는 숫자다. L11-40에서 본 가중치 행렬의 원소들이 여기에 해당한다. Token은 tokenizer가 문장을 쪼갠 단위다. L11-70에서 자세히 보겠지만, 여기서는 “모델이 next-token prediction을 위해 보는 학습 조각” 정도로 잡으면 된다. FLOPs는 floating point operations, 즉 부동소수점 연산 횟수다.

3.2 Power law 철학

Scaling law가 말하는 핵심은 “자원을 더 넣으면 좋아지지만, 개선 폭은 점점 작아진다”다. 손실은 대략 다음처럼 줄어든다고 본다.

Loss ≈ A · N^(-α) + B · D^(-β) + irreducible loss

N: parameters
D: tokens
α, β: 보통 0.05~0.1 근처의 작은 지수
irreducible loss: 데이터와 목표 자체 때문에 더 줄이기 어려운 손실

C(compute)는 여기서 빠진 별도 마법 변수가 아니라, 대략 6 × N × D로 묶이는 예산 제약으로 본다. 같은 C 안에서 N을 키우면 D를 줄여야 하고, D를 키우면 N을 줄여야 한다. Scaling laws의 실전 의미는 “주어진 C를 N과 D에 어떻게 나눌 것인가”다.

지수가 작다는 말은 중요하다. N을 10배 늘려도 loss가 10배 좋아지지 않는다. 예를 들어 α = 0.07이면 10^-0.07 ≈ 0.85라서 해당 항은 약 15% 줄어드는 정도다. 이 때문에 LLM 학습은 항상 “더 넣으면 좋아진다”와 “그 개선을 살 돈이 있는가”가 같이 등장한다.

Power law는 자연 법칙이 아니라 실험적 fit이다. 그래서 다음 경계를 둬야 한다.

학습한 스케일 밖으로 멀리 extrapolation하면 틀릴 수 있다.
loss 개선이 곧 제품 지표 개선이라는 뜻은 아니다.
데이터 품질이 낮으면 D를 늘려도 downstream 성능이 정체될 수 있다.
같은 compute라도 architecture, optimizer, tokenizer, 데이터 mixture가 바뀌면 상수항이 달라진다.

4. Kaplan vs Chinchilla — 자원 배분 관점의 전환

4.1 Kaplan Scaling Laws (2020)

Kaplan et al. 2020은 언어 모델 loss가 파라미터, 데이터, compute에 대해 power law로 줄어든다는 사실을 정량화했다. 당시 결론을 거칠게 요약하면 다음과 같다.

compute가 제한되어 있으면
데이터를 너무 많이 반복하기보다 모델 크기 N을 크게 잡는 편이 유리하다.

이 결론은 GPT-3 시대의 “매우 큰 모델 + 상대적으로 적은 토큰” 전략과 잘 맞았다. GPT-3 175B는 약 300B tokens로 학습되어, 대략 300B / 175B ≈ 1.7 tokens/parameter 수준이었다.

Kaplan 결론을 읽을 때 조심할 점은 fit에 쓰인 측정 방식과 스케일이다. 이후 분석에서는 작은 모델에서 embedding 비중이 큰데 non-embedding parameter 중심으로 N을 재는 문제, 작은 스케일에서 큰 스케일로 extrapolation한 문제가 지적됐다. 이 맥락을 모르고 “Kaplan은 틀렸다”라고만 외우면 핵심을 놓친다. 더 정확히는 초기 scaling law가 자원 배분 방향을 열었고, Chinchilla가 그 배분 비율을 다시 잡았다고 보는 편이 좋다.

정량 감각으로는 Kaplan 계열이 N_optimal ∝ C^0.73처럼 모델 크기 쪽에 더 기울었고, Chinchilla 재측정은 N_optimal ∝ C^0.50에 가까운 균형 결론으로 바뀌었다고 기억하면 된다. Hoffmann et al.은 수백 개 run sweep으로 이 비율을 다시 맞췄고, 이후 재현 연구도 “모델만 키우는 전략은 undertraining을 만들 수 있다”는 결론을 강화했다.

4.2 Chinchilla Scaling Laws (2022)

Hoffmann et al. 2022의 Chinchilla 결과는 결론을 바꿨다.

compute가 제한되어 있으면
모델 크기 N과 데이터 D를 균형 있게 키워야 한다.

실전 암기값: D ≈ 20 × N tokens

이 20:1은 완벽한 상수가 아니라 compute-optimal 근사치다. Hoffmann 논문의 fit 방식에 따라 11~25 사이로 흔들리고, 재현 연구도 비슷한 범위를 보고한다. 그래도 학습 직관으로는 매우 강하다.

손계산 예시

모델 크기 N	Chinchilla식 D≈20N	해석
50M	1B tokens	도메인 데이터 1B tokens라면 compute-optimal 모델은 생각보다 작다
7B	140B tokens	7B를 처음부터 학습하려면 최소 수천억 토큰 자릿수가 필요하다
70B	1.4T tokens	Chinchilla 70B가 이 비율의 대표 사례다
175B	3.5T tokens	GPT-3식 300B tokens는 이 기준으로는 undertrained다

Chinchilla의 메시지는 “작은 모델이 항상 낫다”가 아니다. 메시지는 큰 모델을 만들려면 그 모델을 채울 데이터도 같이 준비하라는 것이다.

4.3 Kaplan과 Chinchilla 비교

구분	Kaplan식 직관	Chinchilla식 직관
핵심 질문	compute가 제한될 때 N을 얼마나 키울까	같은 compute에서 N과 D를 어떻게 균형 잡을까
권장 방향	큰 모델, 상대적으로 적은 데이터	모델과 데이터를 함께 확대
대표 오해	”큰 모델이면 데이터는 적당해도 된다"	"20:1은 모든 상황의 정답이다”
깨지는 지점	undertrained 대형 모델	추론 비용까지 보면 overtraining이 유리할 수 있음

4.4 선택 맥락 — Emergent abilities 논쟁

큰 모델이 일정 크기를 넘으면 작은 모델에는 없던 능력을 갑자기 보인다는 주장을 emergent abilities라고 부른다. Wei et al. 2022는 이를 phase transition처럼 설명했고, Schaeffer et al. 2023은 평가 metric이 거칠면 부드러운 개선도 갑작스러운 발현처럼 보일 수 있다고 반론했다.

처음 읽을 때는 논쟁 이름보다 경계를 잡는 편이 낫다. Scaling law는 loss의 평균적 개선을 설명하지만, 특정 task 점수는 metric, prompting, 채점 방식에 따라 계단처럼 보일 수 있다. 그래서 “모델이 커지면 어느 순간 모든 능력이 자동으로 열린다”는 식으로 해석하면 위험하다. 작은 모델로 충분한지, 큰 모델이 필요한지는 task와 metric을 따로 놓고 확인해야 한다.

5. N/D/C 메커니즘 — FLOPs ≈ 6ND

LLM pre-training 비용을 처음 볼 때는 다음 근사식 하나를 잡으면 된다.

학습 FLOPs ≈ 6 × N × D

forward pass  ≈ 2ND
backward pass ≈ 4ND
합계          ≈ 6ND

이 식은 transformer의 세부 구조를 모두 반영한 정밀 견적이 아니라, pre-training 규모를 빠르게 잡는 기준선이다. 그래도 의사결정에는 충분히 강하다.

작은 worked example — 7B 모델

N = 7e9 parameters
Chinchilla D = 20 × N = 140e9 tokens

FLOPs ≈ 6 × 7e9 × 140e9
      ≈ 5.88e21 FLOPs

같은 7B 모델에 1.4T tokens를 넣으면 D가 10배가 되므로 FLOPs도 거의 10배가 된다. 이 추가 학습은 compute-optimal 관점에서는 비싸지만, 모델이 매우 많이 호출되어 추론 비용을 줄일 수 있다면 inference-optimal 관점에서는 합리적일 수 있다.

GPU-hours로 바꾸는 식

GPU 시간 = FLOPs / (GPU peak FLOPs × MFU)

MFU(Model FLOPs Utilization)는 이론 peak 중 실제 모델 학습 연산에 쓰인 비율이다. 대규모 학습에서는 30~55% 같은 자릿수로 논의하는 경우가 많다. 정확한 값은 하드웨어, 네트워크, parallelism, batch, kernel 최적화에 따라 바뀐다.

6. Inference-Optimal Scaling — 학습 후 얼마나 많이 쓸 것인가

Chinchilla 비율은 학습 compute만 최소화하는 관점이다. 하지만 실제 모델은 학습 후 수십억, 수조 token을 추론한다. 이때는 작은 모델을 더 오래 학습시켜 품질을 끌어올리는 전략이 총비용을 낮출 수 있다.

LLaMA 계열이 이 직관을 보여준다.

LLaMA 1은 7B/13B/33B/65B 모델을 1T~1.4T tokens 수준으로 학습했다.
LLaMA 3 8B는 15T tokens로 학습했다고 보고되어, Chinchilla식 8B 기준인 160B tokens보다 훨씬 많다.

이 전략은 “작은 모델에 데이터를 더 넣으면 항상 좋다”가 아니다. 핵심은 손익분기다.

추가 학습비가 줄어든 추론비의 누적분보다 작아야 한다

extra_train_FLOPs × train_$/FLOP
  is smaller than saved_active_parameters × monthly_tokens × months_in_service × inference_$/FLOP

이 부등식이 성립하려면 모델이 오래, 많이 호출되어야 한다. 내부 도메인 모델처럼 호출량이 수십억 token보다 작거나 3~6개월마다 교체되는 모델이라면 Chinchilla 근처의 compute-optimal 지점이 더 안전할 수 있다.

반례 — 데이터만 더 넣으면 되는가

상황: 7B 모델에 도메인 데이터를 계속 반복 학습한다.
관측: eval_loss는 천천히 내려간다.
문제: MMLU, HumanEval, 한국어 QA 같은 downstream 점수는 거의 오르지 않는다.

여기서 MMLU는 여러 지식 영역을 묻는 대표 벤치마크, HumanEval은 코드 생성 능력을 보는 대표 벤치마크다. Gold set은 운영자가 직접 검수해 고정해 둔 검증셋이다. L11-80 평가 문서에서 자세히 다루지만, 여기서는 “loss가 좋아져도 실제 과업 점수가 안 오를 수 있다”는 신호로만 잡으면 충분하다.

이때는 D가 부족한 것이 아니라 데이터 품질, mixture, 중복, 평가셋과 목표의 불일치가 병목일 수 있다. “loss는 내려가는데 task 성능은 정체”는 scaling 전략이 아니라 데이터 큐레이션 문제를 먼저 의심해야 하는 신호다.

7. Pre-training Pipeline — 무엇이 실제로 일어나는가

Pre-training은 단순히 model.fit(corpus)를 크게 돌리는 작업이 아니다. 다음 흐름이 한 번의 긴 시스템으로 묶인다.

1. 데이터 수집
2. 필터링·중복 제거
3. Tokenization
4. 데이터 mixture 설계
5. 분산 학습
6. checkpoint 저장과 재시작
7. evaluation
8. post-training으로 넘김

7.1 데이터 수집과 필터링

웹, 코드, 책, 논문, 다국어 corpus 같은 원천을 모은다. Common Crawl, C4, RefinedWeb, RedPajama, FineWeb, DCLM 같은 이름은 이 단계의 산출물 또는 공개 데이터셋으로 보면 된다.

원시 데이터는 그대로 쓰기 어렵다. 중복, 스팸, boilerplate, 저품질 페이지, 깨진 인코딩, 개인정보, 라이선스 문제가 섞여 있기 때문이다. Pre-training 품질은 모델 구조만큼 데이터 정제에 크게 좌우된다.

중복 제거가 중요한 이유

Corpus A: 1T tokens라고 표시됨
실제 내용: 같은 문서와 템플릿이 많이 반복되어 유효 다양성은 훨씬 작음

결과:
- train loss는 잘 내려간다.
- benchmark 일부는 좋아 보일 수 있다.
- 새 문제와 드문 언어·도메인에서는 일반화가 약하다.

MinHash + LSH 같은 fuzzy deduplication은 완전히 같은 문자열뿐 아니라 거의 같은 문서도 줄이기 위해 쓰인다. “D를 늘린다”는 말은 토큰 수만 늘리는 것이 아니라 새로운 정보와 다양한 패턴을 늘린다는 뜻이어야 한다.

7.2 Tokenization과 데이터 mixture

Tokenization은 문자열을 모델이 예측할 단위로 바꾸는 단계다. BPE나 sentencepiece 같은 방식이 자주 쓰인다. Tokenizer가 바뀌면 같은 문서도 token 수와 rare token 처리가 달라지므로 D의 의미가 조금 바뀐다.

데이터 mixture는 web, code, math, multilingual, domain data의 비율을 정하는 일이다.

mixture 결정	좋아지는 것	나빠질 수 있는 것
code 비율 증가	코딩, 구조적 추론	일반 대화나 일부 언어 다양성
math 비율 증가	수학·추론 benchmark	자연스러운 문체, 도메인 균형
다국어 비율 증가	비영어 성능	영어 benchmark 일부
도메인 데이터 증가	해당 도메인 용어·문체	일반 능력, 최신성 유지 비용

Mixture는 정답표가 아니라 가설이다. 좋은 팀은 작은 proxy run으로 mixture를 비교하고, loss뿐 아니라 downstream 평가와 safety 평가를 함께 본다.

7.3 분산 학습과 checkpoint

모델과 batch가 단일 GPU에 들어가지 않기 때문에 수백~수천 GPU에 계산을 나눈다. 학습 도중에는 주기적으로 checkpoint를 저장한다. Loss spike, 노드 장애, 네트워크 문제, 데이터 오류가 생기면 최근 checkpoint에서 재시작해야 하기 때문이다.

Checkpoint는 단순 백업이 아니다. 대규모 학습에서는 실패를 전제로 한 진행 단위다. 몇 주짜리 run에서 한 번도 장애가 없을 것이라고 가정하면 운영 계획이 깨진다.

8. Distributed Training — 3D Parallelism과 ZeRO/FSDP

8.1 3D Parallelism

대규모 transformer 학습은 보통 여러 병렬화 축을 섞는다.

3D Parallelism 비교

Data parallel

batch를 GPU마다 나눠 계산하고 gradient를 all-reduce로 합친다.

가장 단순하다. 하지만 각 GPU가 모델 전체를 들고 있어 모델 메모리는 줄지 않는다.

Tensor parallel

한 layer 안의 큰 weight 행렬이나 attention head를 여러 GPU에 나눈다.

모델 메모리를 줄인다. 대신 layer마다 activation 통신이 자주 발생한다.

Pipeline parallel

layer 묶음을 stage로 나눠 GPU 그룹 사이에 순서대로 흘린다.

깊은 모델에 유리하다. stage가 기다리는 bubble 손실이 생긴다.

Context parallel

긴 sequence를 여러 GPU에 나눠 attention 계산을 분산한다.

long-context 학습에 필요하다. attention 통신 설계가 까다롭다.

Expert parallel

MoE expert를 GPU마다 나누고 token routing을 통신한다.

MoE 전용이다. expert 불균형과 routing 비용을 관리해야 한다.

3D parallelism은 보통 data + tensor + pipeline 조합을 가리킨다. 여기에 long-context면 context parallel, MoE면 expert parallel이 추가된다.

짧은 분산 시스템 비유로 보면 data parallel은 row sharding, tensor parallel은 큰 행렬의 column/row 분할, pipeline parallel은 stage 분리와 닮았다. 비유의 목적은 하나다. 메모리를 줄이면 통신이 늘고, 통신을 줄이면 유휴 시간이 생길 수 있다는 trade-off를 기억하는 것이다.

8.2 ZeRO와 FSDP

Data parallel은 단순하지만 모든 GPU가 parameters, gradients, optimizer state를 거의 다 들고 있어 메모리 중복이 크다. ZeRO(Zero Redundancy Optimizer)는 이 중복을 단계적으로 줄인다. PyTorch FSDP(Fully Sharded Data Parallel)는 ZeRO-3에 가까운 방식으로 이해하면 된다.

Stage	나누는 대상	메모리 효과	비용과 경계
ZeRO-1	optimizer state	AdamW의 m/v 같은 상태를 나눠 큰 절감	통신 패턴은 data parallel과 비슷
ZeRO-2	optimizer state + gradients	gradient까지 중복 제거	backward 중 통신 관리가 더 중요
ZeRO-3 / FSDP	optimizer state + gradients + parameters	GPU 수에 비례해 모델 메모리 절감	forward/backward 때 parameter를 모으고 흩는 통신 증가

LLaMA 3 405B 같은 대형 모델은 단일 GPU 메모리에 들어가지 않으므로 FSDP/ZeRO-3, tensor parallel, pipeline parallel 조합이 필요하다. 반대로 7B LoRA를 단일 GPU에서 돌리는 상황에 ZeRO-3를 억지로 넣으면 통신 오버헤드만 커질 수 있다.

9. 학습 안정성 — Loss Spike와 작은 run의 역할

Pre-training은 loss가 매끄럽게 내려가기만 하는 작업이 아니다. 큰 batch 안의 outlier, 잘못 섞인 데이터 shard, learning rate 문제, fp16 overflow, 통신 불안정 때문에 loss spike가 생길 수 있다.

Loss spike는 loss가 갑자기 튀고 gradient norm이 커지거나 NaN이 발생하는 현상이다. PaLM, OPT-175B, GLM-130B 같은 대형 학습에서 자주 보고되었고, 표준 대응은 최근 안정 checkpoint로 rollback한 뒤 원인을 줄이는 것이다.

대응	왜 쓰는가	실패 신호
gradient clipping	큰 gradient update를 제한한다	norm이 반복해서 튀면 LR이나 데이터 outlier도 봐야 한다
warmup + decay	초반 update를 천천히 키우고 후반 수렴을 안정화한다	warmup이 짧으면 초반 spike가 늘 수 있다
bf16	fp16보다 exponent 범위가 넓어 overflow에 강하다	오래된 GPU에서는 fp16 + loss scaling이 필요할 수 있다
skip/residual scaling	깊은 transformer의 activation 폭주를 줄인다	깊이가 늘 때만 의미 있고 얕은 모델에는 과할 수 있다
proxy run과 μP(Maximal Update Parametrization)	작은 모델에서 hyperparameter를 먼저 찾는다	proxy와 큰 모델의 architecture 차이가 크면 전이가 약하다

Repeated data scaling도 경계가 필요하다. Muennighoff et al. 2023은 데이터가 부족할 때 보고된 조건에서 약 4 epoch까지는 repeated data가 fresh data와 비슷하게 작동할 수 있음을 보였다. 하지만 반복 데이터가 무한히 좋은 것은 아니다. 중복이 늘수록 일반화와 downstream 다양성이 줄 수 있다.

10. 비용 산식과 비용 주장 읽는 법

Pre-training 비용은 최신 가격표처럼 읽으면 위험하다. GPU 가격, 예약 방식, 지역, MFU, 재시작, 평가 run 포함 여부가 계속 바뀐다. 이 문서에서는 숫자를 시대별 고정 사실이 아니라 출처가 있는 order-of-magnitude 예시로 읽는다.

Llama 3 405B 보고값 기반 예시

N = 405e9
D = 15.6e12 tokens
FLOPs ≈ 6 × 405e9 × 15.6e12 ≈ 3.8e25

H100 BF16 peak = 1979 TFLOPs/s
MFU 40%를 단순 가정하면 약 12M H100-hours
Meta Llama 3 paper 보고 사용량은 약 30.84M H100-hours

차이가 나는 이유는 단순식이 평가, downtime, restart, cluster inefficiency, non-model overhead를 완전히 반영하지 않기 때문이다. 그래서 비용 견적은 항상 범위로 둔다.

출처 링크가 붙은 비용 사례로 읽기

Llama 3 405B는 수천만 H100-hours 자릿수로 보고된 대형 dense model 사례다.
DeepSeek-V3는 671B MoE, 14.8T tokens, 2.788M H800-hours, 약 $5.6M 학습 비용을 보고한 사례다. 이 숫자는 MoE, FP8, DualPipe 같은 설계와 특정 환경의 보고값이지 모든 frontier 모델의 새 표준 가격이 아니다.

FP8은 8-bit floating point 형식으로 연산·통신 bytes를 줄이는 precision 선택이고, DualPipe는 pipeline 병렬화의 bubble과 통신을 줄이기 위한 학습 스케줄로 읽으면 된다. 처음에는 이름을 외우기보다 “precision과 pipeline을 바꿔 MFU와 비용을 줄인 사례”로 잡는다.

따라서 “pre-training은 $50M~$100M다”나 “이제 $5.6M이면 frontier가 된다”를 timeless fact처럼 외우면 안 된다. 더 안전한 결론은 다음이다.

pre-training은 대부분의 제품팀에게 직접 수행 문제가 아니라
모델 선택, open-weight 활용, fine-tuning, RAG, API 비용 비교 문제다.

11. Continual Pre-training vs Fine-tuning vs RAG

Pre-training을 처음부터 다시 하는 일은 드물다. 실무에서 자주 만나는 질문은 이미 있는 모델을 도메인에 어떻게 맞출지다. 여기서 SFT(Supervised Fine-Tuning)는 검수된 입력-출력 예시로 모델의 답변 형식과 행동을 맞추는 fine-tuning을 뜻한다.

선택	가중치 변경	잘 맞는 목표	데이터 기준 감각	대표 위험
Continual pretraining	크게 변경	도메인 언어·지식 분포를 더 익힘	GB~수십GB+ 텍스트, 안정적 corpus	catastrophic forgetting, 비용
SFT / LoRA	일부 또는 전체 변경	답변 형식, 작업 절차, 도메인 행동	1K~100K+ 검수 입출력	overfitting, base 능력 손실
RAG	변경 없음	자주 바뀌는 지식, 출처 기반 답변	문서 corpus와 검색 품질	검색 실패, context 비용
Prompt / orchestration	변경 없음	규칙이 명확하고 작음	예시 몇 개, 도구 흐름	복잡 작업에서 취약

작은 결정 예시

상황: 법률 도메인 Q&A

문제 A: 법령이 자주 바뀌고 출처가 중요하다.
1차 선택: RAG
이유: 문서 갱신과 citation이 가중치 재학습보다 싸고 안전하다.

문제 B: 모델이 법률 문체와 용어를 전반적으로 잘 못 읽는다.
후보: continual pretraining
조건: 충분한 라이선스 corpus, 일반 능력 평가셋, replay data가 필요하다.

문제 C: 답변 포맷과 검토 절차만 고정하면 된다.
후보: SFT/LoRA 또는 prompt
조건: 검수된 입출력 예시와 rollback 가능한 평가 체계가 있어야 한다.

Continual pretraining의 핵심 실패는 catastrophic forgetting이다. 도메인 corpus만 계속 학습하면 일반 능력, 다국어, 코드, 수학 능력이 떨어질 수 있다. 그래서 일반 데이터 replay를 섞거나, LoRA 같은 parameter-efficient 방식으로 base model을 보존하는 선택지를 검토한다.

12. Test-Time Compute — 새 scaling 축

전통적인 scaling은 train-time compute 중심이었다. 2024년 이후 reasoning 모델 흐름에서는 inference 중 더 많은 token과 탐색을 쓰는 test-time compute가 품질 축으로 올라왔다.

대표 아이디어는 다음과 같다.

모델이 짧은 답을 바로 내는 대신 더 긴 reasoning trace를 생성한다.
여러 후보를 만들고 self-consistency처럼 선택한다.
쉬운 문제에는 적게, 어려운 문제에는 더 많은 inference compute를 쓴다.

Snell et al. 2024는 특정 난이도 영역에서 test-time scaling이 훨씬 큰 모델을 쓰는 것보다 효율적일 수 있음을 보였다. 보고된 비교에서는 더 작은 모델에 test-time compute를 더 쓰는 방식이 14배 큰 모델을 이기는 구간도 있었다. 다만 이 결론도 모든 과업에 적용되지 않는다.

작업	test-time compute가 유리한 경우	불리한 경우
수학·코딩·multi-step reasoning	더 생각하면 정답률이 오르는 문제	base 모델이 아예 못 푸는 난도
단순 분류	거의 없음	긴 reasoning이 비용과 지연만 늘림
요약·추출	검증 단계가 필요한 고위험 문서	단순 포맷 변환
에이전트 작업	도구 호출 계획과 검증이 필요한 경우	즉시 응답성이 더 중요한 경우

이제 compute budget은 두 개다.

train-time compute: 모델 가중치를 만들 때 드는 비용
test-time compute: 매 요청에서 더 생각하고 검증하는 비용

운영자는 두 비용을 나눠 봐야 한다. Reasoning 모델은 학습비를 줄이는 듯 보여도, 높은 호출량에서는 긴 output token과 latency가 총비용을 밀어 올릴 수 있다.

13. 깨지는 조건과 실패 신호

13.1 선택 기준

판단 상황	먼저 고를 기준	피해야 할 오해
처음부터 pretraining	N, D, C, 데이터 라이선스, 분산 인프라	모델 크기만 정하면 된다고 보기
open-weight 모델 선택	누적 inference tokens, latency, hosting 비용	benchmark 1개로 결정하기
도메인 적응	업데이트 빈도, 데이터 양, 출처 필요성	RAG와 fine-tuning을 같은 문제로 보기
long-context 또는 reasoning	output token 비용, p95 latency, 정확도 이득	더 긴 chain-of-thought가 항상 낫다고 보기
분산 학습	모델이 안 들어가는 메모리 병목인지, throughput 병목인지	ZeRO-3를 모든 경우에 켜기

13.2 Silent Failure — 학습은 진행되는데 downstream이 깨지는 경우

증상	정량 신호	먼저 의심할 원인	대응 방향
train loss는 OK, eval 폭락	val loss가 train loss의 2배 이상	overfit, eval 분포 불일치	early stopping, eval set 재점검
eval_loss만 개선되고 task 정체	eval improvement와 downstream improvement가 5%p+ 격차	데이터 품질·mixture 병목	dedup, mixture 조정, task eval 강화
다국어 능력 폭락	한국어/비영어 benchmark 큰 폭 하락	continual pretraining replay 부족	일반·다국어 replay 30~50% 검토
catastrophic forgetting	HumanEval, MMLU 같은 공통 평가 30%+ 하락	full fine-tune 또는 도메인 과적응	LoRA, replay buffer, regularization
loss spike 빈발	시간당 NaN 여러 번, gradient norm 폭주	LR, clipping, outlier shard, fp16 overflow	clipping, bf16, warmup, 데이터 shard 점검
MFU 폭락	30%대에서 20% 미만으로 하락	통신 병목, parallelism 과분할	tensor parallel 축소, batch/sequence 재조정
throughput 들쑥날쑥	step time std/mean > 0.3	pipeline bubble, checkpoint 불균형	micro-batch, stage 균형, selective checkpointing

실패 신호를 볼 때 중요한 습관은 “loss 하나만 보지 않는다”다. Pre-training은 loss를 줄이는 작업이지만, 제품에서 필요한 것은 downstream 성능, 안전성, latency, 비용의 균형이다.

14. Scaling Laws의 일반 매핑

Scaling law는 신경망만의 특수한 이야기가 아니다. 자원을 더 넣으면 성능이 좋아지지만 수확 체감이 있고, 최적점은 누적 사용량에 따라 달라진다는 일반 시스템 패턴이다.

Scaling Laws 구성요소	일반 시스템 매핑
`FLOPs ≈ 6ND`	`system cost ≈ unit_cost × resource × throughput`
Compute-optimal ratio	데이터센터 CPU/GPU/메모리/네트워크 비율 최적화
Inference-optimal	CDN, 검색 인덱스처럼 한 번 만들고 많이 쓰는 시스템
3D parallelism	data/schema/service sharding
Checkpoint rollback	DB snapshot, batch job restart point
Test-time compute	precompute vs on-demand compute

일반 공식은 다음처럼 요약할 수 있다.

성능은 자원의 power law를 따르는 경우가 많고,
최적점은 "만드는 비용"과 "반복해서 쓰는 비용"을 함께 볼 때 정해진다.

15. 실무 의사결정 예시

모델 선택 결정

상황: 한국어 챗봇 서비스
- 월 1M 호출
- 도메인 문서가 자주 바뀜
- P95 latency가 중요함
- 자체 pretraining 예산은 없음

선택지:
A. 고성능 closed API
B. open-weight 70B self-host
C. 7B~14B open-weight + LoRA/SFT
D. RAG + 작은 모델

결정 프레임은 다음 순서가 낫다.

지식이 자주 바뀌는가? 그렇다면 RAG가 먼저다.
답변 형식과 행동 습관이 문제인가? 그렇다면 SFT/LoRA 후보가 된다.
latency와 월 호출량이 self-host 운영비를 정당화하는가?
작은 모델로 부족한 task가 reasoning인지, 지식 부족인지, 포맷 문제인지 구분했는가?
최종 후보를 gold dataset, latency, 월 비용, failure review로 비교했는가?

이 예시에서 “무조건 D” 같은 정답은 없다. 하지만 scaling laws 관점은 결정을 흔들리지 않게 만든다. 직접 pretraining은 후보에서 빠지고, 작은 모델을 더 잘 쓰는 inference-optimal 전략과 RAG/fine-tuning 조합이 현실적인 탐색 공간이 된다.

16. 자주 헷갈리는 개념 비교

개념 A	개념 B	차이점
Kaplan scaling	Chinchilla scaling	Kaplan은 큰 N 쪽 결론이 강했고, Chinchilla는 N과 D 균형을 강조한다
Compute-optimal	Inference-optimal	학습 비용 최소 vs 학습 후 누적 추론 비용까지 포함한 총비용 최소
Pre-training	Continual pretraining	scratch 학습 vs 기존 모델에 도메인 raw text를 추가 학습
Continual pretraining	Fine-tuning/SFT	도메인 분포 학습 vs 행동·포맷·작업 절차 적응
Fine-tuning	RAG	가중치 변경 vs 외부 문서를 prompt context에 넣기
Data parallel	Tensor parallel	batch 분할 vs layer 내부 행렬 분할
Tensor parallel	Pipeline parallel	layer 내부 통신 증가 vs stage 사이 bubble
ZeRO-1/2/3	FSDP	ZeRO 단계는 무엇을 shard하는지의 구분, FSDP는 parameter shard 중심 구현
MFU	HFU(Hardware FLOPs Utilization)	모델 FLOPs 활용률 vs 하드웨어 전체 FLOPs 활용률
Train-time compute	Test-time compute	가중치를 만드는 비용 vs 매 요청에서 더 생각하는 비용

17. 내가 직접 확인해볼 것

Compute 견적

Compute 견적 체크

LLaMA-3-8B 학습 compute를 6·N·D로 직접 계산한다: N=8e9, D=15e12 → 7.2e23 FLOPs.
H100 BF16 peak 1979 TFLOPs/s와 MFU 40%를 가정해 GPU-hours를 추정한다.
같은 식으로 7B Chinchilla-optimal(D=140B)과 7B overtrained(D=1.4T)을 비교해 D 10배가 FLOPs 10배로 이어지는지 확인한다.

Chinchilla 비율 체감

Chinchilla 비율 체감 체크

자기 도메인 데이터 1B tokens가 있다고 가정하고, D/20 = 50M parameters라는 결론이 왜 'pretraining 모델은 생각보다 작아야 한다'는 신호인지 설명한다.
7B 모델을 Chinchilla optimal로 학습하려면 약 140B tokens가 필요하고, LLaMA 3 8B의 15T tokens는 inference-optimal 전략이라는 점을 설명한다.
GPT-3 175B의 300B tokens가 왜 약 1.7 tokens/parameter이고, Chinchilla식 3.5T tokens와 얼마나 차이 나는지 계산한다.

분산 학습 시뮬레이션

분산 학습 시뮬레이션 체크

작은 GPT 계열 모델을 data parallel로 학습하고, 각 GPU가 모델 전체를 들고 있다는 점을 memory profile로 확인한다.
PyTorch FSDP tutorial로 같은 모델을 shard하고 ZeRO-3/FSDP가 줄이는 대상이 parameters·gradients·optimizer state임을 확인한다.
학습 속도가 거의 안 빨라질 때 compute 병목인지 통신 병목인지 step time과 GPU utilization으로 나눠 본다.

Continual pretraining 결정

의학 도메인 5GB 텍스트가 있다고 가정하고 continual pretraining, SFT/LoRA, RAG 중 무엇을 고를지 표로 작성한다.
업데이트 빈도, 라이선스, citation 필요성, 일반 능력 보존 평가셋을 기준으로 선택을 바꿔 본다.
continual pretraining을 고른다면 replay 비율과 catastrophic forgetting 평가셋을 먼저 정한다.

결과가 예상과 다를 때

compute 추정이 실제보다 너무 낮다 → MFU, downtime, evaluation, restart, non-model overhead 포함 여부를 점검한다.
eval_loss는 개선되는데 제품 지표가 안 오른다 → 데이터 mixture, downstream eval, task 정의를 먼저 본다.
continual pretraining 후 일반 능력이 떨어진다 → replay 비율을 늘리거나 LoRA/adapter 방식으로 base 보존을 검토한다.
FSDP를 켰는데 느려진다 → 모델이 충분히 크지 않거나 통신 병목이 커졌을 수 있다.

18. 체크리스트

Scaling Laws와 Pre-training 체크

N(parameters), D(tokens), C(compute)를 정의하고 각각을 늘릴 때 드는 비용을 설명할 수 있다
power law의 작은 exponent가 왜 수확 체감을 뜻하는지 예시로 설명할 수 있다
Kaplan과 Chinchilla scaling laws의 결론 차이를 parameters 우선 vs N/D 균형으로 설명할 수 있다
Chinchilla 비율 D ≈ 20·N을 사용해 7B, 70B 모델의 적정 token 수를 손계산할 수 있다
FLOPs ≈ 6·N·D 식으로 pretraining compute를 자릿수로 추정할 수 있다
compute-optimal과 inference-optimal의 차이를 LLaMA식 overtraining 예시로 설명할 수 있다
pre-training pipeline에서 데이터 수집, dedup, tokenizer, mixture, checkpoint, evaluation의 역할을 말할 수 있다
3D parallelism과 ZeRO/FSDP의 차이를 메모리·통신·bubble 관점에서 비교할 수 있다
loss spike, catastrophic forgetting, MFU 폭락 같은 실패 신호를 원인과 연결할 수 있다
continual pretraining, fine-tuning, RAG, prompt를 데이터 양·업데이트 빈도·행동 변화 기준으로 고를 수 있다
test-time compute가 reasoning 작업에서 품질 축이 되지만 단순 작업에서는 비용 낭비일 수 있음을 설명할 수 있다

19. 추가 학습 키워드

Scaling laws: Kaplan, Chinchilla, broken scaling laws, emergent abilities, μP scaling
Compute accounting: FLOPs, GPU-hours, MFU, HFU, downtime, restart overhead
Pre-training data: Common Crawl, C4, RefinedWeb, RedPajama, FineWeb, DCLM, MinHash, deduplication
분산 학습: Megatron-LM, DeepSpeed, NeMo, FSDP, tensor parallelism, pipeline parallelism, context parallelism
메모리 최적화: ZeRO-1/2/3, activation checkpointing, selective recomputation
학습 안정성: loss spike, gradient clipping, warmup, bf16, skip-init, repeated data scaling
도메인 적응: continual pretraining, replay, LoRA, SFT, RAG, distillation
Test-time compute: chain-of-thought, self-consistency, tree-of-thoughts, o1-style scaling

20. 5줄 요약

Scaling laws는 N(parameters), D(tokens), C(compute)가 loss를 어떻게 줄이는지 보는 경험 법칙이다.
Kaplan은 모델 크기 우선 직관을 강화했고, Chinchilla는 compute-optimal 지점에서 D≈20N 균형이 중요함을 보여줬다.
Pre-training compute는 FLOPs ≈ 6ND로 자릿수 추정할 수 있으며, 실제 비용은 MFU·재시작·평가·인프라 효율에 따라 달라진다.
LLaMA식 inference-optimal 전략은 작은 모델에 더 많은 데이터를 넣어 누적 추론 비용을 줄이는 선택이지만, 호출량이 작으면 손익분기가 깨진다.
대규모 pre-training은 데이터 큐레이션, 3D parallelism, ZeRO/FSDP, loss spike 대응, continual/RAG/fine-tune 선택까지 포함하는 자원 배분 문제다.

21. 출처

최종 수정: 2026-07-09