처음 그 느낌을 받았던 순간이 아직도 또렷합니다. 새벽 두 시쯤, GPU 메모리 사용량 그래프를 멍하니 보고 있었죠. 빨간색으로 꽉 찬 막대, 요란하게 돌아가는 팬 소리. 그런데도 모델은… 기대만큼 똑똑하지 않았습니다. 모델을 더 키우자니 너무 무겁고, reasoning token을 늘리자니 너무 느렸죠. 열, 비용, 그리고 슬슬 쌓이는 짜증 사이에서 이런 생각이 떠올랐습니다.
“다른 길은 없을까?”
이 글은 바로 그 ‘다른 길’에 대한 이야기입니다.
이름은 parallel scaling.
요즘 AI 스케일링 논의에서 생각보다 덜 주목받고 있지만, 방향을 바꿀 수 있는 아이디어라고 느꼈습니다.
한 줄 요약 (왜 사람들이 주목하는가)
parallel scaling은 parameter를 무작정 늘리거나 inference time을 길게 쓰지 않고도 Large Language Model의 성능을 끌어올리는 새로운 방식입니다.
핵심은 간단합니다. 같은 parameter를 재사용하면서 병렬로 계산하고, 그 결과를 똑똑하게 합치는 것.
모델을 키우지도 않고, 오래 생각하게 만들지도 않죠.
특히 coding, math, reasoning처럼 머리를 많이 써야 하는 작업에서 효과가 두드러지고, edge device 같은 저자원 환경에서도 현실적인 선택지가 됩니다.
한 문장으로 정리하면 이렇습니다.
parallel scaling은 하나의 뇌로 여러 관점에서 동시에 생각하게 만드는 방법이다.
지금까지의 스케일링 방식, 그리고 한계
LLM 성능 향상은 오랫동안 두 가지 길에 의존해 왔습니다.
1. Parameter Scaling
모델을 키운다. parameter를 늘린다. 성능은 오른다.
하지만 대가는 큽니다. 메모리 폭증, GPU 비용, edge deployment는 사실상 불가능.
2. Inference-Time Scaling
모델이 더 오래 생각하게 한다. reasoning token을 늘린다.
잘 작동할 때도 있지만, 종종 지나치게 많은 token을 써서 사소한 문제에도 ‘과잉 사고(overthinking)’가 발생합니다. 게다가 training 전략도 까다롭고 latency 비용도 무시하기 어렵죠.
결국 우리는 벽에 부딪혔습니다.
공간은 한정돼 있고, 시간도 한정돼 있으니까요.
그래서 등장한 것이 세 번째 길입니다.
parallel scaling이란 무엇인가
parallel scaling은 모델 크기도, token 길이도 늘리지 않습니다.
대신 **병렬 계산(parallel computation)**을 늘립니다.
아주 쉽게 비유해 볼게요.
같은 전문가에게 질문을 던지되, 서로 다른 관점으로 동시에 묻는다고 생각해 보세요. 전문가를 더 고용하지도 않고, 기다리는 시간도 늘지 않지만 답은 더 풍부해집니다.
이게 바로 parallel scaling의 직관입니다.
실제로는 어떻게 동작할까
Inference 시점에서 모델은 P개의 parallel stream을 실행합니다.
- 동일한 입력을 살짝씩 변형해 각 stream에 전달
- 동일한 backbone model이 모든 stream을 동시에 forward pass
- 각 결과를 dynamic하게 결합해 최종 output 생성
중요한 포인트는 이겁니다.
- parameter는 그대로 재사용
- 메모리 증가는 주로 KV cache 수준
- 성능은 마치 parameter를 N × log(P) 만큼 늘린 것과 유사
처음 이 결과를 봤을 때, 저도 잠깐 멈춰서 다시 계산해 봤습니다.
아이디어의 출처: Diffusion Model의 CFG
이 접근은 완전히 새로운 발상은 아닙니다.
Diffusion model에서 쓰이는 **Classifier-Free Guidance(CFG)**가 힌트였습니다.
CFG는 두 번의 forward pass를 수행합니다.
- 정상 입력
- conditioning을 변형한 입력
그리고 결과를 조합하죠.
연구진의 질문은 단순했습니다.
“두 번이 효과가 있다면, P번은 어떨까?”
그 질문이 parallel scaling으로 이어졌습니다.
Stream마다 다른 시각을 주는 방법
병렬 실행만으로는 부족합니다. 모든 stream이 같은 생각을 하면 의미가 없으니까요.
그래서 prefix tuning이 사용됩니다.
- 각 stream마다 learnable prefix embedding 부여
- Transformer attention의 key/value 앞에 추가
- 결과적으로 각 stream은 서로 다른 context를 갖게 됨
같은 모델이지만, 서로 다른 안경을 쓰고 세상을 보는 셈이죠.
Output을 어떻게 합치는가
각 stream이 logits를 내놓으면 다음 과정이 이어집니다.
- 모든 logits를 concat
- 작은 MLP가 stream별 weight 예측
- softmax로 정규화
- weighted average로 최종 token 결정
이 과정은 매 token마다 동적으로 이루어집니다.
어떤 순간엔 한 stream이 주도하고, 다른 순간엔 또 다른 stream이 앞서죠.
묘하게 사람 팀워크 같다는 생각도 들었습니다.
학습 초기에 발생하는 문제와 해결
초기 학습 단계에서는 특정 stream만 선택되는 현상이 발생할 수 있습니다.
이른바 load imbalance.
해결책은 의외로 단순합니다. label smoothing.
과도한 확신을 막아 모든 stream이 학습에 지속적으로 참여하게 만듭니다.
Parallel Scaling Law
이 연구는 Chinchilla scaling law를 확장합니다.
핵심은 다음과 같습니다.
- 유효 parameter 수는 P와 stream diversity에 의해 결정
- stream 간 예측이 독립적이거나 음의 상관을 가질수록 성능 극대화
한 줄로 요약하면 이렇습니다.
같은 말의 반복보다, 다른 관점의 합이 강하다.
실험 결과는 이 이론을 거의 완벽하게 따라갔습니다.
어디서 가장 효과적인가
Coding & Math
Stack V2 Python 데이터셋에서 parallel scaling 효과는 일반 상식 데이터보다 훨씬 크게 나타났습니다.
이는 중요한 시사점을 줍니다.
- parameter는 암기 능력
- computation은 추론 능력
parallel scaling은 computation을 확장합니다.
큰 모델일수록 더 좋다
Loss contour 분석 결과, base model이 클수록 parallel scaling의 효과는 더욱 커졌습니다.
같은 비용이라면 parameter를 늘리는 것보다 P를 늘리는 편이 더 효율적이었습니다.
Memory와 Time 관점에서의 의미
하드웨어 관점에서 특히 인상적인 결과입니다.
- P 증가에도 메모리 증가는 매우 작음
- batch size = 1 환경에서 효율 극대화
- edge device에서는 사실상 유일한 고성능 대안
Latency는 증가하지만, parameter scaling 대비 훨씬 완만하며 조절 가능합니다.
Training Cost는 어떻게 줄였나
parallel scaling이 비싸 보일 수 있지만, two-stage pretraining이 이를 해결합니다.
- 전체 데이터의 98%는 일반 training
- 나머지 2%로 parallel scaling training
초기엔 loss spike가 나타나지만 빠르게 안정화되고, P가 클수록 더 낮은 loss를 달성합니다.
비용과 성능을 동시에 잡은 셈이죠.
Fine-Tuning과 기존 모델에도 적용 가능
이 방식은 생각보다 유연합니다.
- instruction fine-tuning에서도 일관된 성능 향상
- backbone weight를 freeze한 상태에서도 효과적
- 추가된 소수 parameter만 tuning 가능
말 그대로 plug-in처럼 붙일 수 있습니다.
Dynamic Parallel Scaling이라는 배포 전략
운영 관점에서 가장 흥미로운 부분입니다.
- 하나의 backbone model 배포
- 상황에 따라 P에 해당하는 작은 weight 세트만 교체
- latency, 비용, 사용자 등급에 따라 동적 조절
여러 모델을 관리할 필요가 없습니다.
MoE와의 관계
parallel scaling과 Mixture-of-Experts는 정반대처럼 보입니다.
- MoE: 다른 parameter 선택
- parallel scaling: 같은 parameter 재사용
하지만 둘은 경쟁자가 아니라 조합 대상입니다.
하이브리드 구조는 새로운 효율 지점을 열 가능성이 큽니다.
왜 중요한가
parallel scaling은 한 가지 믿음을 뒤흔듭니다.
“크면 무조건 좋다”는 생각 말이죠.
이미 가진 것을 더 잘 쓰는 방식.
- 추론 효율 향상
- edge deployment 가능
- 유연한 운영
- 비용 절감
많은 논문을 읽어왔지만, 이건 방향성을 제시하는 연구였습니다.
자주 묻는 질문 (2025 기준)
Q1. Ensemble과 같은가요?
아닙니다. Ensemble은 여러 모델, parallel scaling은 하나의 모델입니다.
Q2. Inference latency는 늘어나나요?
늘어나지만, parameter scaling보다 훨씬 적고 조절 가능합니다.
Q3. 왜 reasoning task에 강한가요?
추론은 parameter보다 computation 다양성의 영향을 더 받기 때문입니다.
Q4. 기존 모델에도 적용할 수 있나요?
네. pretrained model에도 가능합니다.
Q5. 추가 training data는 얼마나 필요하죠?
약 2%면 충분합니다.
Q6. Edge device에 적합한가요?
특히 적합합니다.
Q7. Memory 증가는 어느 정도인가요?
주로 KV cache 수준입니다.
Q8. P는 runtime에 바꿀 수 있나요?
가능합니다.
Q9. Inference-time scaling을 대체하나요?
아니요. 오히려 함께 쓰면 시너지가 납니다.
Q10. 실서비스에 쓸 수 있나요?
엔지니어링만 갖추면 충분히 가능합니다.
마무리
parallel scaling은 요란하지 않습니다.
parameter 숫자로 과시하지도 않습니다.
그저 이렇게 묻습니다.
“이미 가진 걸, 더 잘 쓸 수는 없을까?”
그리고 가끔은, 그런 질문이 판을 바꿉니다.
'SW > 인공지능' 카테고리의 다른 글
| NVIDIA GR00T란 무엇인가? 휴머노이드 로봇을 위한 파운데이션 모델 완전 정리 (2025) (0) | 2026.02.02 |
|---|---|
| Cursor 2.0 완벽 가이드: AI agent 기반 code editor를 처음 쓰는 개발자를 위한 설명 (0) | 2026.01.30 |
| 2026년 기준 LLM 로컬 실행 방법 정리: Ollama와 Docker Model Runner 비교 (0) | 2026.01.28 |
| 2025년 AI website builder로 웹 개발 에이전시 시작하는 방법 (white label 모델 정리) (0) | 2026.01.25 |
| Genspark란 무엇인가? ChatGPT와 뭐가 다른지 기능부터 실제 활용까지 정리 (0) | 2026.01.24 |