GPU를 늘리면 학습 의미도 바뀐다

분산 학습을 처음 할 때 자주 하는 실수는 GPU 수를 늘리고도 단일 GPU 때와 같은 optimizer 감각을 유지하는 것이다. 하지만 rank 수가 늘어나면 optimizer가 한 번의 step에서 보는 샘플 수 자체가 바뀐다.

보통 global batch size는 다음처럼 계산한다.

micro_batch_per_rank * num_ranks * grad_accum_steps

이 값이 커지면 한 step의 gradient estimate는 더 안정적일 수 있지만, optimizer dynamics는 달라진다. 학습률을 같은 값으로 두면 과도하게 큰 update가 생길 수도 있고, 반대로 너무 보수적으로 업데이트해서 throughput 증가를 제대로 활용하지 못할 수도 있다.

gradient accumulation은 왜 많이 쓰일까?

LLM 학습에서는 메모리 때문에 rank당 micro-batch를 크게 잡기 어렵다. 이때 accumulation을 사용하면 optimizer step을 늦춰서 더 큰 global batch를 흉내 낼 수 있다.

장점은:

  • 메모리 제약 안에서 큰 global batch를 만들 수 있다
  • 통신 빈도를 줄일 수 있다
  • optimizer step 횟수를 제어할 수 있다

하지만 accumulation은 "공짜로 큰 배치를 얻는 방법"은 아니다. activation을 더 오래 잡고 있어야 할 수도 있고, step 주기가 바뀌므로 scheduler와 logging 해석도 달라진다.

scaling rule은 왜 단순 공식으로 끝나지 않을까?

실전에서는 흔히 linear scaling rule 같은 경험 법칙을 언급하지만, LLM에서는 항상 그대로 먹히지 않는다.

  • optimizer 종류가 다르다
  • warmup 길이가 중요하다
  • gradient clipping 유무가 영향을 준다
  • sequence length와 data mixture가 바뀐다

즉 "batch를 두 배로 키웠으니 learning rate도 두 배"처럼 단순하게 가면 위험하다.

실무에서 보는 체크리스트

분산 학습 설정을 바꿀 때는 다음을 같이 본다.

  • effective tokens per update가 얼마나 달라졌는가
  • loss curve가 더 noisy해졌는가, 혹은 지나치게 flat해졌는가
  • throughput이 늘었는데 validation quality는 유지되는가
  • accumulation 때문에 한 step latency가 지나치게 길어지지 않았는가

특히 "GPU는 많이 쓰는데 convergence가 이상해졌다"면 통신보다 batch semantics부터 다시 봐야 한다.

이 글이 뒤의 메모리/병렬화 주제로 이어지는 이유

많은 팀이 data parallel scale-out에서 막히는 이유는 단순히 통신만이 아니다. micro-batch를 줄이고 accumulation을 늘리다 보면 utilization, optimizer dynamics, checkpoint cadence가 함께 꼬인다. 이 지점에서 결국 메모리 구조와 model parallel 전략을 보게 된다.

다음 글에서는 LLM 학습에서 메모리가 정확히 어디에 쓰이는지 해부한다. 파라미터만 보는 감각으로는 왜 분산 전략 선택을 잘못하게 되는지 거기서 분명해진다.