The Smol Training Playbook: The Secrets to Building World-Class LLMs

Introduction

오늘날 고성능 LLM을 학습시키기 위해 실제로 무엇이 필요한가?

공개된 연구 자료들은 이를 간단하게 보이도록 만든다: 전략적인 아키텍처 선택, 신중하게 선별된 데이터셋, 그리고 충분한 컴퓨팅 자원이다. 결과는 깔끔하게 다듬어져 있으며, 제거 실험(ablation)은 구조적이고 명확하다. 모든 결정은 돌이켜보면 당연하게 보인다. 하지만 이러한 보고서들은 오직 성공한 것만을 보여주며 장밋빛 회고를 적용할 뿐이다 – 그들은 새벽 2시의 데이터로더 디버깅 세션, 손실값 급등(loss spikes), 또는 학습을 조용히 방해하는 미묘한 텐서 병렬화 버그(나중에 참조)는 포착하지 않는다. 현실은 더 지저분하고, 더 반복적이며, 최종 논문에 담기지 않는 결정들로 가득하다.

11조(T) 토큰으로 학습된 3B 매개변수의 다국어 추론 모델인 SmolLM3의 학습 비하인드 스토리를 함께 살펴보자. 이것은 평범한 블로그 게시물이 아니라, 세계적 수준의 언어 모델을 구축하는 데 필요한 깊은 통찰력으로 이어진 결정, 발견, 그리고 막다른 골목의 거미줄을 풀어내는 작업이다.

또한 이 글은 우리의 모델 학습 장편 시리즈의 마지막 작품이다: 우리는 대규모 데이터셋 구축(FineWeb), 수천 개의 GPU를 조화롭게 작동시키기 위한 오케스트레이션(Ultra Scale Playbook), 그리고 프로세스의 각 단계에서 최적의 평가 지표 선택(Evaluation Guidebook)을 다루어 왔다. 이제 우리는 이 모든 것을 모아 강력한 AI 모델을 구축한다. 우리는 성공한 최종 레시피뿐만 아니라, 모든 결정을 형성했던 실패, 인프라 고장, 그리고 디버깅 프로세스를 포함하여 전체 여정을 안내한다.

이 이야기는 한 편의 드라마처럼 읽힌다: 때때로 유망했던 소규모 제거 실험이 대규모에서는 적용되지 않는 방식, 우리가 1조 토큰 학습 후에 학습을 재시작했던 이유, 강력한 영어 성능을 유지하면서 다국어, 수학, 코드라는 서로 경쟁하는 목표들의 균형을 맞추었던 방법, 그리고 마지막으로 하이브리드 추론 모델을 사후 학습(post-trained)했던 방법을 보게 될 것이다.

우리는 또한 우리가 했던 모든 것들을 냉정한 목록으로 나열하는 대신, 우리의 모험을 통한 짜임새 있는 이야기에 중점을 두려 한다. 이 글을 “우리는 훌륭한 데이터셋과 GPU를 가지고 있다”에서 “우리는 정말 강력한 모델을 구축했다”로 나아가려는 모든 이들을 위한 가이드로 생각한다. 우리는 이러한 개방성이 연구와 프로덕션 사이의 격차를 좁히고, 여러분의 다음 학습 실행을 조금 덜 혼란스럽게 만드는 데 도움이 되기를 희망한다.

이 블로그 글을 읽는 방법

이 블로그 게시물을 위에서 아래까지 모두 읽을 필요는 없으며, 이 시점에서 이미 한 번에 끝까지 현실적으로 읽기에는 너무 길다. 이 블로그 게시물은 건너뛰거나 개별적으로 읽을 수 있는 몇 가지 뚜렷한 부분으로 구성되어 있다:

학습 나침반 (Training compass): 자체 모델을 사전 학습해야 하는지 여부에 대한 높은 수준의 논의이다. 모든 벤처 캐피털(VC) 자금을 소진하기 전에 스스로에게 물어봐야 할 근본적인 질문과, 의사 결정 과정을 체계적으로 생각하는 방법을 안내한다. 이 부분은 높은 수준의 섹션이므로, 기술적인 내용으로 바로 건너뛰고 싶다면 이 부분을 빠르게 지나 스크롤해라.
사전 학습 (Pretraining): 학습 나침반 다음 섹션들은 자체 사전 학습 실행을 위한 견고한 레시피를 구축하는 데 필요한 모든 것을 다룬다: 제거 실험을 실행하는 방법, 평가 지표를 선택하는 방법, 데이터 소스를 혼합하는 방법, 아키텍처 선택, 하이퍼파라미터 튜닝, 그리고 마지막으로 학습 마라톤을 견뎌내는 방법이다. 이 섹션은 처음부터 사전 학습을 계획하고 있지 않더라도, continual pretraining (일명 중간 학습)에 관심이 있다면 적용된다.
사후 학습 (Post-training): 이 블로그의 이 부분에서는 사전 학습된 모델을 최대한 활용하는 데 필요한 모든 트릭을 배우게 될 것이다. SFT, DPO, GRPO로 시작하는 전체 사후 학습들 뿐만 아니라, 모델 병합(model merging)의 암흑 기술과 연금술을 배운다. 이러한 알고리즘들을 잘 작동하게 만드는 지식의 대부분은 고통스러운 교훈을 통해 습득되며, 바라건대 여러분에게 그중 일부를 덜어주기 위해 우리의 경험을 공유한다.
인프라 (Infrastructure): 사전 학습이 케이크이고 사후 학습이 그 위에 올리는 아이싱과 체리라면, 인프라는 산업용 오븐이다. 그것 없이는 아무 일도 일어나지 않으며, 고장 나면 여러분의 행복한 일요일 베이킹 세션은 화재 위험으로 변한다. GPU 클러스터를 이해하고, 분석하고, 디버깅하는 방법에 대한 지식은 다양한 라이브러리, 문서, 포럼 등 인터넷 전반에 흩어져 있다. 이 섹션은 GPU 레이아웃, CPU/GPU/노드/저장소 간의 통신 패턴, 그리고 병목 현상을 식별하고 극복하는 방법을 안내한다.

그렇다면 우리는 어디서부터 시작해야 할까? 가장 흥미롭다고 생각하는 섹션을 선택하고 시작해라!

Training compass: why → what → how

스크린샷 2025-12-01 오후 1.26.12.png

기계 학습 분야는 최적화와 강박적인 관계를 가지고 있다. 우리는 손실 곡선, 모델 아키텍처, 그리고 처리량(throughput)에 집착한다; 결국 기계 학습은 근본적으로 모델의 손실 함수를 최적화하는 것에 관한 것이다. 하지만 이러한 기술적 세부 사항에 뛰어들기 전에, 종종 질문되지 않는 더 근본적인 질문이 있다: 우리가 정말 이 모델을 학습시켜야 하는가?

아래 히트맵에서 보듯이, 오픈 소스 AI 생태계는 거의 매일 세계적 수준의 모델을 출시한다: Qwen, Gemma, DeepSeek, Kimi, Llama 🪦, Olmo 등 그 목록은 매달 길어진다. 이것들은 단순히 연구 프로토타입이나 장난감 예시가 아니다: 그들은 다국어 이해에서부터 코드 생성 및 추론에 이르기까지 놀라운 폭넓은 사용 사례를 포괄하는 프로덕션 수준의 모델이다. 대부분은 관대한 라이선스와 여러분이 그들을 사용하는 것을 도울 준비가 된 활발한 커뮤니티와 함께 제공된다.

스크린샷 2025-12-01 오후 1.26.46.png

이는 불편한 진실을 제기한다: 아마도 여러분은 자체 모델을 학습시킬 필요가 없을 수 있다.

이것은 “LLM 학습 가이드”를 시작하는 이상한 방법처럼 보일 수 있다. 그러나 실패한 많은 학습 프로젝트는 나쁜 하이퍼파라미터나 버그 있는 코드 때문에 실패한 것이 아니라, 누군가 필요하지 않은 모델을 학습시키기로 결정했기 때문에 실패했다. 따라서 학습에 전념하고, 그것을 실행하는 방법에 깊이 뛰어들기 전에, 여러분은 두 가지 질문에 답해야 한다: 왜 이 모델을 학습시키는가? 그리고 어떤 모델을 학습시켜야 하는가? 명확한 답변 없이는, 여러분은 세상에 이미 있거나, 더 나쁘게는, 아무도 필요로 하지 않는 것을 구축하는 데 수개월의 컴퓨팅 자원과 엔지니어링 시간을 낭비할 것이다.

먼저 왜부터 시작한다. 왜냐하면 목적을 이해하지 못하면, 뒤따르는 어떤 것에 대해서도 일관성 있는 결정을 내릴 수 없기 때문이다.

📍이 섹션에 대하여

이 섹션은 블로그의 나머지 부분과 다르다: 실험과 기술적 세부 사항보다는 전략적 계획에 가깝다. 우리는 모델을 처음부터 (from scratch) 학습해야 할지 말지에 대한 결정과, 무슨 모델을 구축할지를 결정하는 과정을 안내한다. 이미 당신이 ‘왜’ 와 ‘무엇’ 에 대해 깊이 생각했다면, 기술적인 심층 분석을 위해 “모든 큰 모델은 작은 제거 실험으로 시작한다” 챕터로 자유롭게 건너뛰어도 된다. 그러나 확신이 없다면, 여기에 시간을 투자하는 것이 나중에 많은 노력을 절약해 줄 것이다.

왜: 아무도 답하고 싶어 하지 않는 질문

실제로 일어나는 일에 대해 솔직해지자. 누군가 (운이 좋다면) GPU 클러스터에 접근하게 되고, 아마도 연구 보조금을 통해서, 또는 회사의 여유 자원을 통해서일 것이며, 아래와 같은 사고 과정을 거칠 것이다: “우리에게는 3개월 동안 100개의 H100이 있다. 모델을 학습시키자!” 모델 크기는 임의로 선택되고, 데이터셋은 사용 가능한 모든 것에서 조립된다. 학습이 시작된다. 그리고 6개월 후, 컴퓨팅 예산과 팀 사기를 소진한 후에도, 결과 모델은 아무도 왜라고 묻지 않았기 때문에 사용되지 않은 채로 남아있게 된다.

다음은 모델을 학습시키지 말아야 할 몇 가지 이유이다:

스크린샷 2025-12-01 오후 1.31.45.png

“우리가 자체 모델을 학습시켰다”는 것의 매력은 강하지만, 많은 시간과 자원을 투자하기 전에, 다음을 묻는 것이 합리적이다: 왜 이 모델을 학습시킬 필요가 있는가?

아래 순서도는 대규모 사전 학습 프로젝트를 시작하기 전에 거쳐야 할 사고 과정을 안내한다. 기술적 관점에서, 여러분은 본질적으로 먼저 기존 모델 중에서 작업을 수행하도록 프롬프트를 주거나 파인 튜닝할 수 있는 모델이 없는지 확인해야 한다.

스크린샷 2025-12-01 오후 1.32.32.png

맞춤형 사전 학습이 의미가 있는 세 가지 일반적인 영역이 본질적으로 있다: 새로운 연구를 하고 싶거나, 프로덕션 사용 사례에 대한 매우 구체적인 필요가 있거나, 또는 오픈 모델 생태계의 격차를 채우고 싶거나이다. 각각을 간단히 살펴보자:

연구: 무엇을 이해하고 싶은가?

LLM 분야에서 할 수 있는 연구는 풍부하다. LLM 연구 프로젝트의 공통점은 일반적으로 명확하게 정의된 질문으로 시작한다는 것이다:

우리는 이 새로운 옵티마이저에서의 학습을 10B+ 모델로 확장할 수 있는가? (Muon is Scalable for LLM Training에서)
강화 학습만으로, SFT 없이, 추론 능력을 생성할 수 있는가? (DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning에서)
순수하게 합성 교과서 데이터로 좋은 소형 모델을 학습시킬 수 있는가? (Textbooks Are All You Need에서)
오직 공개적으로 라이선스된 데이터만으로 학습하여 경쟁력 있는 성능을 달성할 수 있는가? (The Common Pile v0.1: An 8TB Dataset of Public Domain and Openly Licensed Text에서)

가설을 가능한 한 구체적으로 만들고 필요한 실험 규모에 대해 생각하는 것이 성공 가능성을 높인다.

프로덕션: 기존 모델을 사용할 수 없는 이유는 무엇인가?

기업이 자체 사용 사례를 위해 기존에 존재하는 모델을 사용할 수 없는 주요 이유는 세 가지가 있다. 그중 두 가지는 기술적이며 다른 하나는 거버넌스 때문이다.

자체 모델을 학습시키는 첫 번째 이유는 도메인 특수성이다: 여러분의 데이터나 작업이 기존 모델이 잘 처리할 수 없는 고도로 전문화된 어휘나 구조를 포함할 때이다. 예를 들면 다음과 같다:

고유한 어휘와 장거리 의존성을 가진 DNA 모델.
도메인별 전문 용어와 논리에 대한 깊은 이해가 필요한 법률 또는 금융 모델.

두 번째 이유로는 배포 제약이 있다: 여러분의 하드웨어, 지연 시간 또는 개인 정보 보호 요구 사항에 맞춘 모델이 필요할 때이다. 예를 들어, 드론이나 FPGA와 같은 맞춤형 하드웨어와 함께 온프레미스 시스템에서 실행되는 LLM이다.

여기 이를 확인하는 간단한 테스트가 있다: Qwen3, Gemma3 또는 다른 현재 SOTA 모델을 기반으로 며칠 동안 만들고자 하는 것을 개발해 본다. 프롬프팅, 도구 사용 또는 post-training 을 통해 성능 목표에 도달할 수 있는가? 그렇지 않다면, 아마도 자체 모델을 학습시킬 만한 때이다.

요구 사항을 충족하는 데 필요한 post-training 예산이 막대하더라도, 처음부터 시작하는 것보다 여전히 저렴할 수 있다. 모델을 1조(T) 토큰 동안 파인 튜닝하는 것은 10조(T) 토큰 이상을 학습시키기 위해 처음부터 시작하는 것보다 여전히 더 경제적이다.

(이 시점에서 LLM 학습자들은 기적적으로 이를 사후 학습(post-training) 대신 중간 학습(mid-training)이라고 부르기 시작했다.)

자체 사내 언어 모델을 구축하는 세 번째 이유는 안전 및 거버넌스이다: 규제 산업이나 고위험 애플리케이션에 속해 있으므로 학습 데이터, 모델 동작 및 업데이트 주기에 대한 완전한 통제가 필요하다. 여러분은 모델에 무엇이 들어갔는지 정확히 알아야 하며 규제 기관에 그것을 증명할 수 있어야 한다. 어떤 경우에는 자체 모델을 구축하는 것 외에 다른 선택의 여지가 없을 수 있다.

이것이 기업들이 사내 모델을 학습시키는 주요 이유이지만, 오픈 모델을 출시하는 회사나 조직의 경우는 어떨까?

전략적 오픈 소스: 채울 수 있는 격차가 보이는가?

숙련된 AI 연구소들이 새로운 오픈 모델을 출시하는 가장 흔한 이유 중 하나는 오픈 소스 생태계에서 특정 격차나 새로운 AI 사용 사례를 식별했기 때문이다.

패턴은 일반적으로 다음과 같다; 여러분은 충분히 탐색되지 않은 영역을 발견한다. 어쩌면 매우 긴 컨텍스트를 가진 강력한 온디바이스 모델이 없거나, 다국어 모델은 존재하지만 저자원 언어에서는 약하거나, 또는 분야가 Genie3와 같은 인터랙티브한 세계 모델로 이동하고 있는데 좋은 오픈 가중치 모델이 없는 상황이다.

여러분은 더 잘할 수 있다고 믿을 만한 이유가 있다; 아마도 더 나은 학습 데이터를 선별했거나, 더 나은 학습 레시피를 개발했거나, 아니면 다른 사람들이 할 수 없었던 곳에서 과도하게 학습시킬 컴퓨팅 자원이 있을 수 있다. 여러분의 목표는 구체적이다: “역대 최고의 모델”이 아니라, “온디바이스 사용을 위한 최고의 3B 모델” 또는 “1M 컨텍스트를 가진 최초의 소형 모델”이다.

이것은 현실적인 목표이며 성공은 가치를 창출한다: 개발자들이 여러분의 모델을 채택하고, 그것이 다른 사람들을 위한 인프라가 되거나, 기술적 신뢰도를 확립한다. 그러나 성공은 경험을 필요로 한다. 경쟁이 치열한 공간에서 실제로 무엇이 실현 가능하고 신뢰할 수 있게 실행하는 방법을 알아야 한다. 이를 구체화하기 위해, Hugging Face에서 이 질문에 대해 어떻게 생각하는지 살펴본다.

Hugging Face의 여정

그렇다면 Hugging Face는 왜 오픈 모델을 학습시키는가? 답은 간단하다: 우리는 오픈 소스 생태계에 유용하고, 다른 사람들이 거의 채우지 않는 격차를 채우는 것을 구축한다.

수백만 개의 오픈 가중치 모델이 있지만, 완전히 오픈된 모델을 학습시키는 조직은 거의 없다. Hugging Face 외에도 Ai2와 Stanford의 Marin 커뮤니티가 있다.

여기에는 데이터셋, 툴링 및 학습 모델이 포함된다. 우리가 시작한 모든 LLM 학습 프로젝트는 격차를 발견하고 의미 있는 것을 기여할 수 있다고 믿는 것에서 시작되었다.

우리는 GPT-3(Brown et al., 2020)가 출시된 후 첫 LLM 프로젝트를 시작했다. 당시에는 아무도 오픈 대체재를 구축하지 않는 것처럼 느껴졌고, 우리는 그 지식이 몇몇 산업 연구소에만 갇히게 될까 봐 우려했다. 그래서 우리는 GPT-3의 오픈 버전을 학습시키기 위해 BigScience 워크숍을 시작했다. 그 결과 모델은 Bloom이었고, 175B 매개변수 모델을 사전 학습하기 위해 학습 스택, 토크나이저, 그리고 사전 학습 코퍼스를 구축하는 데 1년 동안 수십 명의 기여자들의 작업에서 비롯되었다.

Bloom의 후속작은 2022년의 StarCoder(Li et al., 2023)였다. OpenAI는 GitHub Copilot을 위해 Codex(Chen et al., 2021)를 개발했지만, 그것은 클로즈드 소스였다. 오픈 소스 대안을 구축하는 것은 생태계에 가치를 제공할 것이 분명했다. 그래서 ServiceNow와의 협력으로 BigCode 산하에서, 우리는 The Stack 데이터셋을 구축했고, Codex를 재현하기 위해 StarCoder 15B를 학습시켰다. StarCoder2(Lozhkov et al., 2024)는 우리가 더 오래 학습시킬 수 있었다는 것을 배우고, 더 오래 학습된 더 작은 모델이 하나의 큰 모델보다 더 가치 있을 수 있다는 것을 인식하는 것에서 비롯되었다. 우리는 당시 오픈 코드 모델을 위해 다른 누구도 해본 적 없는 것보다 훨씬 많은 수조 토큰으로 모델 패밀리(3B/7B/15B)를 학습시켰다.

SmolLM 패밀리도 비슷한 패턴을 따랐다. 우리는 강력한 소형 모델이 거의 없다는 것을 발견했고, 마침 강력한 사전 학습 데이터셋인 FineWeb-Edu(Penedo et al., 2024)를 구축한 참이었다. SmolLM (135M/360M/1.7B)이 우리의 첫 번째 버전이었다. SmolLM2 (Allal et al., 2025)는 더 나은 데이터와 더 긴 학습에 초점을 맞추어 여러 분야에서 SOTA 성능에 도달했다. SmolLM3는 하이브리드 추론, 다국어 및 긴 컨텍스트를 추가하면서 3B로 확장했으며, 이는 커뮤니티가 2025년에 중요하게 생각하는 기능들이었다.

이 패턴은 사전 학습을 넘어 확장되었다: 우리는 DPO가 대규모에서 작동한다는 것을 보여주기 위해 Zephyr(Tunstall et al., 2023)를 학습시켰고, DeepSeek R1의 증류 파이프라인을 재현하기 위해 Open-R1을 시작했으며, 국제 정보 올림피아드에서 SOTA 성능을 가진 경쟁 프로그래밍을 위한 OlympicCoder를 출시했다. 우리는 또한 비전을 위한 SmolVLM(Marafioti et al., 2025)과 로봇 공학을 위한 SmolVLA(Shukor et al., 2025)와 함께 다른 양식들을 탐색했다.

(HF 과학 프로젝트에 대해 궁금하다면, 여기서 개요를 찾을 수 있다 **https://huggingface.co/science)**

바라건대, 이 섹션은 왜 모델을 학습시키고 싶은지에 대해 깊이 생각하는 것의 가치를 여러분에게 확신시켰을 것이다.

이 블로그 게시물의 나머지 부분에서는 여러분이 이러한 자기 성찰을 완료했고 학습할 정당한 이유가 있다고 가정하겠다.

무엇(What): 목표를 결정으로 변환하기

이제 당신은 왜 모델을 학습시켜야 하는지 알았다, 그렇다면 무엇을 학습시켜야 하는가? “무엇”이란 모델 유형(dense, MoE, 하이브리드, 새로운 것), 모델 크기, 아키텍처 세부 사항 및 데이터 혼합을 의미한다. 하나의 왜에 정착하면, 그것으로부터 무엇을 도출할 수 있다. 예를 들어:

온디바이스를 위한 빠른 모델 → 작고 효율적인 모델
다국어 모델 → 큰 토크나이저 어휘
매우 긴 컨텍스트 → 하이브리드 아키텍처

use-case 에 의해 주도되는 결정 외에도, 더 안정적이거나, 더 샘플 효율적이거나, 또는 더 빠름으로써 학습 자체를 최적화하는 몇 가지 선택 사항도 있다. 이러한 결정은 항상 그렇게 명확하게 구분되지 않지만, 결정 과정을 대략 두 단계로 나눌 수 있다:

계획: 실험을 실행하기 전에, 여러분의 use-case를 결정해야 하는 구성 요소에 매핑한다. 배포 환경은 모델 크기 제약 조건을 결정한다. 타임라인은 감수할 수 있는 아키텍처 위험을 결정한다. 목표 capability 들은 데이터셋 요구 사항을 결정한다. 이 단계는 ”**왜”**로부터의 각 제약 조건을 ”**무엇”**의 구체적인 사양에 연결하는 단계이다.
검증: 일단 시작할 지점과 잠재적 수정 목록을 갖게 되면, 체계적으로 테스트해나간다. 테스트는 비용이 많이 들기 때문에, 당신의 use case에 대한 성능을 의미 있게 개선하거나 학습을 최적화할 수 있는 변경 사항에 집중해야 한다. 이것이 제거 실험(ablations)이 등장하는 지점이며, 제거 실험 섹션에서 이를 구체적으로 다룬다.

📍테스트할 가치가 있는 것을 식별하는 법을 배운다. 단순히 테스트를 실행하는 방법만이 아니다.

관련 없는 선택에 대한 완벽한 제거 실험은 중요한 선택에 대한 부주의한 제거 실험만큼이나 많은 컴퓨팅 자원을 낭비한다.

다음 챕터들에서는 당신이 모델을 정의하기 위해 가지는 모든 종류의 옵션과, 체계적인 실험을 통해 선택을 좁히는 방법에 대해 배우게 될 것이다. 거기로 가기 전에 우리는 huggingface 내에서 자체 모델 학습을 한 경험과 다른 놀라운 팀들이 훌륭한 LLM을 구축하는 것을 관찰한 경험으로부터 팀과 프로젝트를 설정하는 방법에 대한 몇 가지 배운 점을 공유하고자 한다.

슈퍼 파워: 속도와 데이터

물론 로마로 가는 길은 많지만, 우리는 성공적인 LLM 학습 팀을 일관되게 구별하는 것이 ”Iteration Speed” 라는 것을 발견했다. LLM 학습은 실로 Training 을 해보며 배우는 분야이며, 더 자주 Training 해볼수록 팀은 더 나아질 것이다. 따라서 1년에 한 모델을 학습시키는 팀과 분기에 한 모델을 학습시키는 팀 사이에서, 후자가 훨씬 더 빠르게 개선될 것이다. 예를 들어 Qwen 및 DeepSeek의 팀들을 보자. 이제 누구나 아는 이름이 된 그들은 일관되게 빠른 속도로 새로운 모델을 출시하는 지속되는 기록을 가지고 있다.

Iteration Speed 외에도, LLM 학습의 가장 영향력 있는 측면은 단연코 데이터 큐레이션이다. 모델을 개선하기 위해 아키텍처 선택에 뛰어들려는 자연스러운 경향이 있지만, LLM 학습에서 탁월한 팀은 다른 무엇보다도 고품질 데이터에 집착하는 팀이다.

반복 속도와 연결된 또 다른 측면은 팀 규모이다: 주요 사전 학습 작업을 위해서는 실행할 충분한 컴퓨팅 자원을 갖춘 소수의 인력만 필요하다. 오늘날 Llama 3와 같은 모델을 사전 학습하는 데는 아마도 2~3명만 필요할 것이다. 더 다양한 학습과 다운스트림 작업(멀티모달, 다국어, post-training 등)에 모험을 시작할 때에만 각 도메인에서 탁월해지기 위해 천천히 몇 명의 사람들을 더 추가해야 할 것이다.

따라서 작고 잘 갖춰진 팀으로 시작하고, 2~3개월마다 새로운 모델을 구축한다. 그러면 짧은 시간 내에 정상에 오를 것이다. 이제 이 블로그의 나머지 부분은 이 팀의 기술적인 일상에 초점을 맞출 것이다!

Every big model starts with a small ablation

우리가 LLM 학습을 시작하기 전에, 모델의 성능과 학습 효율을 결정할 많은 결정을 내려야 한다. 어떤 아키텍처가 우리의 사용 사례에 가장 적합한가? 어떤 옵티마이저와 학습률 스케줄을 사용하고 어떤 데이터 소스를 혼합할 것인가?

이러한 결정들이 어떻게 이루어지는지에 대한 질문은 자주 물어진다. 사람들은 때때로 그것들에 대한 결정이 단지 그것들에 대해 깊이 생각함으로써 이루어진다고 예상하곤 한다. 전략적 사고는 필수적이지만—테스트할 가치가 있는 아키텍처 변경을 식별하는 것에 대해 논의했던 이전 섹션에서 다루었듯이—추론만으로는 충분하지 않다. LLM에서는 항상 직관적이지 않은 일이 일어나며, 작동해야 할 것이라는 가설이 실제로는 성공하지 못하는 경우가 있다.

예를 들어, “가장 높은 품질의 데이터”처럼 보이는 것을 사용하는 것이 항상 더 강력한 모델을 낳는 것은 아니다. 인류의 과학적 지식이 방대하게 모여있는 arXiv를 예로 들어보자. 직관적으로, 그러한 풍부한 STEM 데이터로 학습하는 것이 우수한 모델을 만들어내야 할 것 같지 않은가? 하지만 실제로는 그렇지 않으며, 특히 소형 모델의 경우 성능을 해칠 수도 있다 (Shao et al., 2024). 왜일까? 그 이유는 arXiv 논문이 지식으로 가득 차 있지만, 모델이 가장 잘 배우는 다양하고 일반적인 텍스트와는 상당히 다른, 고도로 전문화되고 좁은 학문적 스타일로 작성되어 있기 때문이다.

문제에 대해 오랫동안 열심히 고민하는 것이 도움이 되지 않는다면, 무엇이 작동하는지 어떻게 알 수 있을까? 우리는 훌륭한 경험주의자들처럼 많은 실험을 실행해야 한다! 기계 학습은 순수 수학이 아니라, 실제로는 매우 실험적인 과학이다.

이러한 실험들이 우리의 많은 중요한 결정을 안내할 것이므로, 그것들을 잘 설정하는 것이 정말로 중요하다. 본질적으로 우리는 그들로부터 두 가지 주요 속성을 원한다:

속도: 자주 반복할 수 있도록 가능한 한 빠르게 실행되어야 한다. 더 많은 제거 실험을 실행할수록, 더 많은 가설을 테스트할 수 있다.
신뢰성: 그들은 강력한 변별력을 제공해야 한다. 우리가 보는 메트릭이 초기에 다른 설정들을 의미 있게 구별할 수 없다면, 우리의 제거 실험은 거의 아무것도 드러내지 못할 수 있다 (그리고 노이즈가 많다면, 우리는 노이즈를 쫓을 위험이 있다!). 더 자세한 내용은 FineTaks 블로그 게시물을(https://huggingface.co/spaces/HuggingFaceFW/blogpost-fine-tasks) 확인해라.

하지만 우리가 제거 실험을 설정하기 전에, 아키텍처 유형과 모델 크기에 대한 몇 가지 기본적인 선택을 우리는 해야 한다. 우리의 나침반에 의해 안내되는 이러한 결정들은 어떤 학습 프레임워크를 사용할지, 컴퓨팅 예산을 어떻게 할당할지, 그리고 어떤 기준선(baseline)에서 시작할지에 영향을 미친다.

SmolLM3의 경우, 우리는 소형 온디바이스 모델을 목표로 했기 때문에 3B 매개변수의 밀집형 Llama 스타일 아키텍처를 선택했다. 그러나 모델 아키텍처 설계 챕터에서 보듯이, MoE 또는 하이브리드 모델이 여러분의 사용 사례에 더 적합할 수 있으며, 다른 모델 크기는 다른 장단점을 수반한다. 우리는 나중에 이러한 선택들을 깊이 탐색하고, 이러한 결정들을 내리는 방법을 보여줄 것이다. 지금은 가장 실용적인 첫 번째 단계인 “Baseline 선택”부터 시작한다.

기준선(Baseline) 선택

모든 성공적인 모델은 검증된 기반을 바탕으로 구축되며, 필요에 따라 그 기반을 수정해서 만들어진다. Qwen이 첫 모델 패밀리(Bai et al., 2023)를 학습시켰을 때, 그들은 Llama의 아키텍처에서 시작했다. Meta가 Llama 3를 학습시켰을 때, 그들은 Llama 2에서 시작했다. Kimi K2는 DeepSeek-V3의 MoE 아키텍처에서 시작했다. 이것은 아키텍처뿐만 아니라 학습 하이퍼파라미터 및 옵티마이저에도 적용된다.

왜일까? 좋은 아키텍처와 학습 설정 설계는 수많은 조직에 걸쳐 수년간의 반복을 필요로 한다. 표준 트랜스포머와 Adam과 같은 옵티마이저는 수천 번의 실험을 통해 개선되었다. 사람들은 그것들이 실패하는 상황들을 발견했고, 불안정성을 디버깅했으며, 구현을 최적화했다. 검증된 기반에서 시작한다는 것은 그 모든 축적된 지식을 계승한다는 것을 의미한다. 새로 시작한다는 것은 모든 문제를 스스로 재발견한다는 것을 의미한다.

다음은 아키텍처의 좋은 출발점을 만드는 요소이다:

제약 조건과 일치: 배포 대상 및 사용 사례와 일치한다.
대규모에서 검증: 유사하거나 더 큰 크기에서 수조 토큰 실행.
문서화가 잘 되어 있음: 오픈 모델에서 작동하는 것으로 입증된 알려진 하이퍼파라미터.
프레임워크 지원: 이상적으로는 고려 중인 학습 프레임워크와 사용하려는 추론 프레임워크에서 지원되어야 한다.

아래는 다양한 아키텍처 및 모델 크기에 대한 강력한 2025년 기준선 옵션의 전체는 아니지만 일부 목록이다:

아키텍처 유형	모델 패밀리	크기
밀집형(Dense)	Llama 3.1	8B, 70B
밀집형(Dense)	Llama 3.2	1B, 3B
밀집형(Dense)	Qwen3	0.6B, 1.7B, 4B, 14B, 32B
밀집형(Dense)	Gemma3	12B, 27B
밀집형(Dense)	SmolLM2, SmolLM3	135M, 360M, 1.7B, 3B
MoE	Qwen3 MoE	30B-A3B, 235B-A122B
MoE	GPT-OSS	21B-A3B, 117B-A5B
MoE	Kimi Moonlight	16B-A3B
MoE	Kimi-k2	1T-A32B
MoE	DeepSeek V3	671B-A37B
하이브리드(Hybrid)	Zamba2	1.2B, 2.7B, 7B
하이브리드(Hybrid)	Falcon-H1	0.5B, 1.5B, 3B, 7B, 34B
MoE + 하이브리드	Qwen3-Next	80B-A3B
MoE + 하이브리드	MiniMax-01	456B-A46B

당신이 원하는 아키텍처 유형으로 가서 당신이 모델이 갖기를 원하는 매개변수 수에 가까운 기준선을 선택해라. 당신이 시작하기로 한 아키텍처가 확정된 것은 아니므로 너무 많이 고민하지는 마라. 다음 섹션에서, 우리는 기준선에서 여러분에게 최적인 최종 아키텍처로 가는 방법을 보게 될 것이다.

기준선 수정: 위험 회피의 규율

이제 작동하고 여러분의 사용 사례에 맞는 기준선이 있다. 당신은 여기서 멈추고, 당신이 준비한 데이터로 (Data Mixture) (당신이 그것을 잘 만들었다고 가정하고) 그것을 학습시켜 괜찮은 모델을 얻을 수 있다. 많은 성공적인 프로젝트가 정확히 그렇게 한다. 그러나 기준선은 여러분의 특정 제약 조건에 최적화되지 않았으며, 그것들을 구축한 사람들의 사용 사례 및 배포 대상에 맞게 설계되었다. 따라서 여러분의 목표와 더 잘 일치하도록 만들 가치가 있는 수정 사항이 있을 수 있다. 하지만 모든 아키텍처 변경은 위험을 수반한다: 성능을 향상시키거나, 폭락시키거나, 또는 아무것도 하지 않으면서 제거 실험 컴퓨팅 자원을 낭비할 수 있다.

이 때 Derisking라는 이 규율이 당신이 궤도를 벗어나지 않게 유지해줄 것이다: 테스트하여 도움이 된다는 것이 입증되지 않는 한 아무것도 변경하지 않는다.

📍무엇이 Derisking (위험 회피)로 간주되는가?

변경 사항이 목표 기능에 대한 성능을 개선하거나, 허용 가능한 절충안을 넘어 성능을 해치지 않으면서 의미 있는 이점(예: 더 빠른 추론, 더 낮은 메모리, 더 나은 안정성)을 제공한다는 것을 테스트가 보여줄 때 변경 사항은 위험 회피가 된 것이다.

까다로운 부분은 여러분의 기준선과 학습 설정에 수정할 수 있는 많은 구성 요소가 있다는 것이다: 어텐션 메커니즘, Positional encodings, 활성화 함수, 옵티마이저, 학습 하이퍼파라미터, 정규화 방식, 모델 레이아웃 등이다. 각각은 잠재적인 실험을 대표하며, 이러한 구성 요소들은 종종 비선형적인 방식으로 상호 작용한다. 여러분은 모든 것을 테스트하거나 모든 상호 작용을 탐색할 시간이나 컴퓨팅 자원이 없다.

현재 기준선에 대해 유망한 변경 사항들을 테스트하는 것부터 시작한다. 무엇인가 작동하면, 그것을 통합하여 새로운 기준선을 만들고, 그것에 대해 다음 변경 사항을 테스트한다. 컴퓨팅 예산이 허락한다면 변경 사항들을 개별적으로 테스트하고 leave-one-out 분석을 실행할 수 있다.

모든 하이퍼파라미터에 대한 철저한 그리드 검색이나 나오는 모든 아키텍처 변형을 테스트하는 함정에 빠져서는 안 된다.

🎯 전략적 실험

어떤 실험을 실행할 가치가 있는지 모른다면 실험을 실행하는 방법을 아는 것만으로는 충분하지 않다. 어떤 수정 사항이든 테스트하기 전에 스스로에게 두 가지 질문을 던져야 한다:

이것이 내가 목표로 하고 있는 특정한 use case에 도움이 될 것인가?
이것이 나의 학습을 최적화할 것인가?

수정 사항이 두 질문 중 어느 하나를 명확하게 다루지 않는다면, 건너뛰어라.

이제 전략적 계획을 통해 무엇이 유망한지 식별하는 방법을 알았으므로, 경험적 검증으로 넘어갈 차례이다. 다음 섹션들에서는 이러한 변경 사항들을 실제로 테스트하는 방법을 보여줄 것이다. 우리는 신뢰할 수 있는 실험을 설정하는 방법, 결과를 해석하는 방법, 그리고 일반적인 함정을 피하는 방법을 다룰 것이다. 그런 다음 다음 챕터들에서는 인기 있는 아키텍처, 데이터, 인프라 및 학습 결정들을 테스트하는 구체적인 예시들을 안내할 것이다.

이제 우리의 실험에 사용할 수 있는 간단한 제거 실험 설정을 만들어보자. 먼저, 어떤 학습 프레임워크를 선택할지 결정해야 한다.

학습 프레임워크 선택

우리가 내려야 할 첫 번째 결정은 모델 학습을 위해, 그리고 나아가 우리의 모든 제거 실험을 실행하기 위해 어떤 프레임워크를 사용할지이다. 이 선택은 세 가지 주요 고려 사항의 균형을 맞추는 것을 포함한다:

프레임워크는 우리의 목표 아키텍처를 지원하거나 우리가 그것을 쉽게 확장할 수 있도록 해야 한다.
그것은 안정적이고 프로덕션 준비가 되어 있어야 하며, 학습 중간에 미스터리하게 고장 나기 쉬운 경향이 없어야 한다.
우리가 빠르게 반복하고 컴퓨팅 예산을 최대한 활용할 수 있도록 강력한 처리량을 제공해야 한다.

실제로는 이러한 요구 사항들이 서로 상충되어 트레이드오프를 생성할 수 있다. 사용 가능한 옵션들을 살펴본다.

프레임워크	기능	실전 검증	최적화	코드 라인 수 (핵심 / 전체)	확장성 및 디버깅
Megatron-LM	✅ 광범위함	✅ Kimi-K2, Nemotron	✅ 3D 병렬 처리의 선구자	93k / 269k	⚠️ 초보자에게는 어려움
DeepSpeed	✅ 광범위함	✅ BLOOM, GLM	✅ ZeRO 및 3D 병렬 처리의 선구자	94k / 194k	⚠️ 초보자에게는 어려움
TorchTitan	⚡ 기능 세트 성장 중	⚠️ 최신이지만 PyTorch 팀에서 테스트됨	⚡ 밀집형 모델에 최적화됨, MoE 개선 진행 중.	7k / 9k	⚡ 보통: 병렬 처리 노하우 필요
Nanotron	🎯 최소한, HF 사전 학습에 맞춤	✅ 예 (StarCoder, SmolLM)	✅ 최적화됨 (UltraScale Playbook)	15k / 66k	⚡ 보통: 병렬 처리 노하우 필요

위 표는 인기 있는 프레임워크 간의 주요 트레이드오프를 요약한다. 처음 세 프레임워크의 코드 라인 수는 TorchTitan 기술 보고서(Liang et al., 2025)에서 가져온 것이다. 각각에 대해 더 자세히 논의한다:

Nvidia의 Megatron-LM은 수년간 존재해 왔으며 실전 검증되었다. 그것은 Kimi의 K2(Team et al., 2025)와 같은 모델을 구동하며, 견고한 처리량을 제공하고 우리가 원하는 대부분의 프로덕션 기능을 갖추고 있다. 그러나 그 성숙도는 복잡성을 수반한다: 코드를 처음 접할 때 탐색하고 수정하기 어려울 수 있다.

DeepSpeed도 비슷한 범주에 속한다. 그것은 ZeRO 최적화의 선구자이며 BLOOM 및 GLM과 같은 모델을 구동했다. Megatron-LM과 마찬가지로, 광범위하게 실전 검증되고 최적화되었지만, 동일한 복잡성 문제를 공유한다. 특히 사용자 정의 기능을 구현하거나 예상치 못한 동작을 디버깅할 때, 큰 코드베이스(총 194k 라인)는 시작할 때 위협적일 수 있다.

반면에, PyTorch의 최신 TorchTitan 라이브러리는 컴팩트하고 모듈식 코드베이스 덕분에 훨씬 가볍고 탐색하기 쉽다. 그것은 사전 학습에 필요한 핵심 기능을 갖추고 있으며 빠른 실험에 훌륭하다. 그러나 더 최신이므로, 실전 검증이 덜 되었고 활발하게 개발 중이므로 여전히 약간 불안정할 수 있다.

우리는 다른 경로를 택하여, 처음부터 자체 프레임워크인 nanotron을 구축했다. 이것은 우리에게 완전한 유연성과 대규모 사전 학습에 대한 깊은 이해를 제공했다; 나중에 Ultra Scale Playbook으로 발전한 통찰력이다. 우리가 라이브러리를 오픈 소스로 공개한 이후, 우리는 커뮤니티로부터 귀중한 피드백을 받았지만, 대부분의 경우 기능을 먼저 자체적으로 실전 검증해야 했다. 이제 이 프레임워크는 학습에 필요한 모든 프로덕션 기능을 지원하지만, MoE 지원과 같은 영역은 여전히 구축 중이다.

처음부터 구축하는 것은 그때는 합리적이었지만, 문제 디버깅 및 누락된 기능 추가에 대한 팀 전문 지식과 시간에 막대한 투자를 요구한다. 강력한 대안은 기존 프레임워크를 포크하고 필요에 맞게 개선하는 것이다. 예를 들어, Thinking Machines Lab은 TorchTitan의 포크로 내부 사전 학습 라이브러리를 구축했다 (출처 https://x.com/cHHillee/status/1949470943291805832).

궁극적으로, 여러분의 선택은 팀의 전문 지식, 목표 기능, 그리고 개발에 투자할 의향이 있는 시간 대 가장 프로덕션 준비가 된 옵션을 사용하는 것에 달려있다.

여러 프레임워크가 여러분의 필요를 지원한다면, 여러분의 특정 하드웨어에서 그들의 Throughput을 비교해라. 빠른 실험과 속도 실행을 위해서는 더 간단한 코드베이스가 종종 승리한다.

제거 실험 설정

프레임워크를 선택했으므로, 이제 제거 실험 설계를 해야 한다. 우리는 빠르게 반복할 수 있을 만큼 빠르면서도, 결과가 우리에게 신호를 제공하고 최종 모델로 이전될 수 있을 만큼 충분히 큰 실험이 필요하다. 이것을 설정하는 방법을 살펴보자.

제거 실험 프레임워크 설정

제거 실험의 목표는 작은 규모로 실험을 실행하고, 최종 프로덕션 실행에 자신 있게 추정할 수 있는 결과를 얻는 것이다.

두 가지 주요 접근 방식이 있다. 첫째, 우리는 목표 모델 크기를 가져와서 더 적은 토큰으로 학습시킬 수 있다. SmolLM3 제거 실험의 경우, 우리는 최종 11조(T) 토큰 대신 전체 3B 모델을 100B 토큰으로 학습시켰다. 둘째, 우리의 목표 모델이 너무 크다면, 제거 실험을 위해 더 작은 대리 모델을 학습시킬 수 있다. 예를 들어, Kimi가 32B 활성 매개변수를 가진 1조 매개변수 Kimi K2 모델을 개발했을 때, 모든 제거 실험에 전체 크기를 사용하는 것은 비용이 너무 많이 들었을 것이므로, 그들은 5억 활성 매개변수를 가진 3B MoE 모델에서 일부 제거 실험을 실행했다 (Team et al., 2025).

한 가지 핵심 질문은 이러한 소규모 발견이 실제로 전이되는지 여부이다. 우리의 경험상, 작은 규모에서 성능을 해치는 것이 있다면, 대규모에서는 자신 있게 배제할 수 있다. 그러나 작은 규모에서 작동하는 것이 있다면, 이러한 발견이 더 큰 규모로 추정될 것이라는 높은 확률로 결론을 내리기 위해 합리적인 수의 토큰으로 학습시켰는지 확인해야 한다. 더 오래 학습시켰고 제거 실험 모델이 최종 모델에 가까울수록 더 좋다.

이 블로그 게시물에서는 모든 제거 실험에 기준이 되는 바닐라 트랜스포머를 사용할 것이다. 우리의 주요 설정은 45B 토큰으로 학습된 Llama3.2 1B 아키텍처를 따르는 1B 트랜스포머이다. 이것은 이 nanotron 설정을 사용하여 8xH100 노드에서 학습하는 데 약 1.5일이 걸린다 (GPU당 초당 42k 토큰). SmolLM3 학습 동안, 우리는 100B 토큰으로 학습된 3B 모델에서 이러한 제거 실험을 실행했다 (설정은 여기 https://huggingface.co/datasets/HuggingFaceTB/training-guide-nanotron-configs.). 우리는 각 챕터의 끝에서 그 결과를 공유할 것이다 (결론이 일치한다는 것을 보게 될 것이다).

우리의 기준 1B 설정은 구조화된 YAML 형식으로 모든 필수 학습 세부 정보를 포착한다. 다음은 핵심 섹션이다:

## 데이터셋 및 혼합 가중치
data_stages:
- data:

    dataset:
      dataset_folder:
      - fineweb-edu
      - stack-edu-python
      - finemath-3plus

      dataset_weights:
      - 0.7
      - 0.2
      - 0.1

## 모델 아키텍처, Llama3.2 1B 설정
model:
  model_config:
    hidden_size: 2048
    num_hidden_layers: 16
    num_attention_heads: 32
    num_key_value_heads: 8
    intermediate_size: 8192
    max_position_embeddings: 4096
    rope_theta: 50000.0
    tie_word_embeddings: true

## 학습 하이퍼파라미터, 코사인 스케줄을 가진 AdamW
optimizer:
  clip_grad: 1.0
  learning_rate_scheduler:
    learning_rate: 0.0005
    lr_decay_starting_step: 2000
    lr_decay_steps: 18000
    lr_decay_style: cosine
    lr_warmup_steps: 2000
    lr_warmup_style: linear
    min_decay_lr: 5.0e-05
  optimizer_factory:
    adam_beta1: 0.9
    adam_beta2: 0.95
    adam_eps: 1.0e-08
    name: adamW

## 병렬 처리, 1개 노드
parallelism:
  dp: 8  # 8개 GPU에 걸친 데이터 병렬 처리
  tp: 1  # 1B 규모에서는 텐서 또는 파이프라인 병렬 처리가 필요 없음
  pp: 1

## 토크나이저
tokenizer:
  tokenizer_max_length: 4096
  tokenizer_name_or_path: HuggingFaceTB/SmolLM3-3B

## 배치 크기, 시퀀스 길이 및 30B 토큰에 대한 총 학습
tokens:
  batch_accumulation_per_replica: 16
  micro_batch_size: 3 # GBS (글로벌 배치 크기)=dp * batch_acc* MBS * sequence=1.5M tokens
  sequence_length: 4096
  train_steps: 20000 # GBS * 20000 = 30B

 ...(생략)

제거 실험을 위해, 우리는 다른 모든 것을 일정하게 유지하면서 테스트하는 내용에 따라 다른 섹션들을 수정한다: 아키텍처 선택을 위한 model 섹션, 옵티마이저 및 학습 하이퍼파라미터를 위한 optimizer 섹션, 그리고 데이터 큐레이션을 위한 data_stages 섹션.

☝️한 번에 하나만 수정하기

다른 모든 것을 일정하게 유지하면서 제거 실험당 하나의 변수만 변경해라. 여러 가지를 변경하고 성능이 향상되면, 무엇이 원인인지 알 수 없다. 수정 사항들을 개별적으로 테스트한 다음, 성공적인 것들을 결합하고 재평가한다.

제거 실험을 실행할 때, 일부 아키텍처 변경은 매개변수 수를 크게 바꿀 수 있다. 예를 들어, tied embedding 에서 untied embedding 으로 전환하면 임베딩 매개변수가 두 배가 되는 반면, MHA에서 GQA 또는 MQA로 가면 어텐션 매개변수가 상당히 감소한다. 공정한 비교를 보장하기 위해, 우리는 매개변수 수를 추적하고 때때로 모델 크기를 대략 동일하게 유지하기 위해 다른 하이퍼파라미터(예: 은닉 크기 또는 레이어 수)를 조정해야 한다. 다음은 우리가 다른 구성에 대한 매개변수 수를 추정하는 데 사용하는 간단한 함수이다:

from transformers import LlamaConfig, LlamaForCausalLM

def count_parameters(
    tie_embeddings=True,
    num_key_value_heads=4,
    num_attention_heads=32,
    hidden_size=2048,
    num_hidden_layers=16,
    intermediate_size=8192,
    vocab_size=128256,
    sequence_length=4096,
):
    config = LlamaConfig(
        hidden_size=hidden_size,
        num_hidden_layers=num_hidden_layers,
        num_attention_heads=num_attention_heads,
        num_key_value_heads=num_key_value_heads,
        intermediate_size=intermediate_size,
        vocab_size=vocab_size,
        max_position_embeddings=sequence_length,
        tie_word_embeddings=tie_embeddings,
    )
    model = LlamaForCausalLM(config)
    return f"{sum(p.numel() for p in model.parameters())/1e9:.2f}B"

우리는 또한 Dense 트랜스포머의 경우 LLM 매개변수 분포를 시각화하는 대화형 도구를 제공한다. 이는 아키텍처 결정을 내리거나 제거 실험을 위한 설정을 할 때 유용할 수 있다.

스크린샷 2025-12-01 오후 2.27.04.png

무엇이 작동하는지 이해하기: 평가

제거 실험을 시작하고 나서, 무엇이 작동하는지 아닌지 어떻게 알 수 있을까?

모델을 학습시키는 사람이라면 누구나 Loss 를 보는 것이 첫 번째 본능일 수 있고, 실제로 그것이 중요하다. 여러분은 Loss 가 거친 급등이나 불안정성 없이 부드럽게 감소하는 것을 보고 싶어 할 것이다. 많은 아키텍처 선택에 대해, loss 는 다운스트림 성능과 잘 상관관계가 있으며 충분할 수 있다 (Y. Chen et al., 2025). 그러나 loss만 보는 것은 항상 신뢰할 수 있진 않다. 데이터 제거 실험의 예를 들면, 위키피디아에서 학습하는 것이 웹 페이지에서 학습하는 것보다 더 낮은 loss를 보여주지만 (다음 토큰을 예측하기가 더 쉽기 때문에), 그것이 더 유능한 모델을 얻는다는 것을 의미하지는 않는다. 마찬가지로, 실행 간에 토크나이저를 변경하면, 텍스트가 다르게 분할되기 때문에 loss 를 직접 비교할 수 없다. 일부 변경 사항은 또한 추론 및 수학과 같은 특정 기능을 특별히 영향을 미치고 평균 loss 에서는 보이지 않을 수도 있다. 마지막으로, 모델은 사전 학습 loss가 수렴된 후에도 다운스트림 작업에서 계속 개선될 수 있다 (Liu et al., 2022).

우리는 전체 그림을 보고 이러한 미묘한 효과를 이해하기 위해 더 세분화된 평가가 필요하며, 자연스러운 접근 방식은 지식, 이해, 추론 및 우리에게 중요한 기타 도메인을 테스트하는 다운스트림 평가를 사용하는 것이다.

이러한 제거 실험의 경우, 좋은 초기 신호를 제공하는 작업에 집중하고 노이즈가 많은 벤치마크는 피하는 것이 좋다. FineTasks 및 FineWeb2에서 신뢰할 수 있는 평가 작업은 네 가지 핵심 원칙으로 정의된다:

단조성(Monotonicity): 벤치마크 점수는 모델이 더 오래 학습할수록 일관되게 향상되어야 한다.
낮은 노이즈: 동일한 설정이지만 다른 랜덤 시드로 모델을 학습시킬 때, 벤치마크 점수는 크게 변동하지 않아야 한다.
랜덤 이상의 성능: 많은 기능은 학습 후반에만 나타나므로, 장기간 동안 랜덤 수준의 성능을 보이는 작업은 제거 실험에 유용하지 않다. 우리가 나중에 설명하듯이, 여러 선택 형식의 MMLU의 경우가 그렇다.
순위 일관성(Ranking consistency): 한 접근 방식이 초기 단계에서 다른 접근 방식보다 우수한 성능을 보인다면, 이 순서는 학습이 계속됨에 따라 안정적으로 유지되어야 한다.

작업의 품질은 또한 작업 공식화 (Task formulation, 모델에게 질문하는 방식)와 메트릭 선택 (답변 점수를 계산하는 방식)에도 의존한다.

세 가지 일반적인 작업 공식화는 객관식 형식(Multiple Choice Format, MCF), 클로즈 형식(Cloze Formulation, CF), 그리고 자유 형식 생성(Freeform Generation, FG)이다. 객관식 형식은 모델이 프롬프트에 명시적으로 제시되고 A/B/C/D가 접두사로 붙은 여러 선택 사항 중에서 옵션을 선택하도록 요구한다 (예를 들어, MMLU에서 수행되는 방식). 클로즈 형식에서는, 프롬프트에서 제공하지 않고 어떤 선택지가 더 가능성이 높은지 보기 위해 다른 선택지들의 가능성(likelihood)을 비교한다. FG에서는, 주어진 프롬프트에 대한 그리디 생성의 정확도를 본다. FG는 모델에 많은 잠재 지식을 요구하며, 전체 학습 전의 짧은 사전 학습 제거 실험에서 실제로 유용하기에는 보통 너무 어려운 작업이다. 따라서 우리는 작은 규모의 제거 실험을 실행할 때 객관식 형식에 집중해야 한다 (MCF 또는 CF).

📍주의 사항

post-train 된 모델의 경우, 모델이 실제로 유용한 응답을 생성할 수 있는지 평가하기 때문에 FG가 주요 공식화가 된다. 우리는 post-training 챕터에서 이러한 모델에 대한 평가를 다룰 것이다.

다양한 연구들은 모델은 학습 초기에 MCF에 어려움을 겪으며, 광범위한 학습 후에야 이 기술을 배우므로, CF가 초기 신호에 더 낫다는 것을 보여주고 있다 (Du et al., 2025; Gu et al., 2025; J. Li et al., 2025). 따라서 우리는 작은 제거 실험에는 CF를 사용하고, MCF는 모델이 MCF에 대해 충분히 높은 신호 대 노이즈 비율을 얻기 위한 임계값을 통과한 후 더 나은 중간 학습 신호를 제공하므로 주 실행에 통합한다. 또한, CF와 같은 시퀀스 가능성 평가에서 모델의 답변에 점수를 매기기 위해, 우리는 정답이 문자 수로 정규화된 가장 높은 로그 확률을 가지는 질문의 비율으로 정확도를 계산한다.(accuracy as the percentage of questions where the the correct answer has the highest log probability normalised by character count) 이 정규화는 더 짧은 답변에 대한 편향을 방지한다.

우리의 제거 실험 평가 스위트에는 FineWeb 제거 실험의 벤치마크가 포함되며, 너무 노이즈가 많다고 판단한 SIQA는 제외했다. 우리는 긴 컨텍스트 제거 실험을 위해 GSM8K 및 HumanEval과 같은 수학 및 코드 벤치마크와 긴 컨텍스트 벤치마크 RULER를 추가했다. 이러한 작업들의 집합은 아래 표에 표시된 대로 다양한 형식에 걸쳐 세계 지식, 추론 및 상식을 테스트한다. 일부 추가 노이즈를 감수하고 평가 속도를 높이기 위해, 우리는 각 벤치마크에서 1,000개의 질문만 평가했다 (GSM8K, HumanEval 및 RULER 제외, 이는 3B SmolLM3 제거 실험에는 전체를 사용했지만 아래의 1B 실험에서는 생략한다). 또한 위에서 설명한 대로 모든 객관식 벤치마크에 대해 클로즈 형식(CF) 평가 방식을 사용했다. 다국어 제거 실험 및 실제 학습의 경우, 다국어성을 테스트하기 위해 더 많은 벤치마크를 추가하며, 이는 나중에 자세히 설명하겠다. 이러한 평가는 LightEval을 사용하여 실행되며, 아래 표는 각 벤치마크의 주요 특징을 요약한다:

벤치마크	도메인	작업 유형	질문 수	테스트하는 내용
MMLU	지식	객관식	14k	57개 주제에 걸친 광범위한 학술 지식
ARC	과학 및 추론	객관식	7k	초등학교 수준의 과학 추론
HellaSwag	상식 추론	객관식	10k	일상 상황에 대한 상식 추론 (이야기 완성)
WinoGrande	상식 추론	이진 선택	1.7k	세계 지식이 필요한 대명사 해결
CommonSenseQA	상식 추론	객관식	1.1k	일상 개념에 대한 상식 추론
OpenBookQA	과학	객관식	500	추론을 포함한 기초 과학 사실
PIQA	물리적 상식	이진 선택	1.8k	일상 물체에 대한 물리적 상식
GSM8K	수학	자유 형식 생성	1.3k	초등학교 수학 단어 문제
HumanEval	코드	자유 형식 생성	164	독스트링(docstring)으로부터 파이썬 함수 합성

이러한 평가들이 실제로 무엇을 테스트하는지에 대한 구체적인 감각을 얻기 위해 각각의 몇 가지 예시 질문을 살펴보자:

스크린샷 2025-12-01 오후 2.37.24.png

위의 예시들을 훑어보면서 각 벤치마크의 질문 유형을 보자. MMLU와 ARC가 객관식으로 사실적 지식을 테스트하고, GSM8K가 수학 문제에 대한 수치적 답변 계산을 요구하며, HumanEval이 완전한 파이썬 코드 생성을 요구한다는 점에 주목해라. 이러한 다양성은 제거 실험 전반에 걸쳐 모델 능력의 다양한 측면을 테스트하는 것을 보장한다.

제거 실험을 위한 데이터 혼합은 무엇인가?

아키텍처 제거 실험을 위해, 우리는 광범위한 작업에서 초기 신호를 제공하는 고품질 데이터셋의 고정된 혼합으로 학습해본다. 우리는 영어(FineWeb-Edu), 수학(FineMath), 그리고 코드(Stack-Edu-Python)를 사용한다. 아키텍처 발견은 다국어 데이터를 포함하여 다른 데이터셋 및 도메인에도 잘 추정되어야 하므로, 우리는 데이터 혼합을 간단하게 유지할 수 있다.

데이터 제거 실험을 위해, 우리는 반대 접근 방식을 취한다: 아키텍처를 고정하고 데이터 혼합을 체계적으로 변경하여 다른 데이터 소스가 모델 성능에 어떻게 영향을 미치는지 이해한다.

견고한 제거 실험 설정의 진정한 가치는 단순히 좋은 모델을 구축하는 것을 넘어선다. 주 학습 실행 중에 필연적으로 문제가 발생할 때 (그리고 아무리 준비해도 문제가 발생할 것이다), 우리는 우리가 내린 모든 결정에 대해 확신하고, 제대로 테스트되지 않았고 문제를 일으킬 수 있는 구성 요소를 빠르게 식별하고자 한다. 이러한 준비는 디버깅 시간을 절약하고 미래의 정신 건강을 보장한다.

제거 실험 비용 추정

제거 실험은 놀랍지만 GPU 시간을 요구하며, 이러한 실험의 비용을 이해하는 것이 중요하다. 아래 표는 SmolLM3 사전 학습에 대한 우리의 전체 컴퓨팅 분석을 보여준다: 주 실행 (가끔 발생하는 다운타임을 고려), 학습 전후의 제거 실험, 그리고 재시작을 강제하고 일부 디버깅을 초래한 예상치 못한 확장 문제에 소비된 컴퓨팅 자원 (이는 나중에 자세히 설명할 것이다).

단계	GPU 수	일 수	GPU-시간
주 사전 학습 실행	384	30	276,480
제거 실험 (사전 학습)	192	15	69,120
제거 실험 (중간 학습)	192	10	46,080
학습 재설정 및 디버깅	384/192	3/4	46,080
총 비용	-	-	437,760

이 수치는 중요한 사실을 드러낸다: 제거 실험 및 디버깅은 총 161,280 GPU 시간을 소비했으며, 이는 우리의 주 학습 실행 비용 (276,480 GPU 시간)의 절반 이상이다. 우리는 SmolLM3 개발 전반에 걸쳐 총 100개 이상의 제거 실험을 실행했다: 사전 학습 제거 실험에 20일, 중간 학습 제거 실험에 10일, 그리고 재시작을 강제하고 일부 디버깅을 초래한 예상치 못한 학습 문제에서 회복하는 데 7일을 보냈다 (이는 나중에 자세히 설명할 것이다).

이것은 왜 제거 실험 비용이 여러분의 컴퓨팅 예산에 포함되어야 하는지를 강조한다: 학습 비용, 제거 실험 비용, 그리고 예상치 못한 상황에 대한 버퍼를 계획해야 한다. SOTA 성능을 목표로 하거나, 새로운 아키텍처 변경을 구현하거나, 이미 검증된 레시피가 없는 경우, 제거 실험은 사소한 실험이 아니라 상당한 비용 센터가 된다.

다음 섹션으로 넘어가기 전에, 실험을 실행하는 모든 사람이 따라야 할 몇 가지 기본 규칙을 확립하겠다.

참여 규칙

요약: 편집증을 가져라(Be paranoid).

평가 스위트(Evaluation suite)를 검증한다. 어떤 모델을 학습시키기 전에, 여러분이 비교할 모델들의 공개된 결과를 여러분의 평가 스위트가 재현할 수 있는지 확인한다. 벤치마크가 생성적인 성격(예: GSM8k)을 가진다면, 더욱 편집증적으로 몇 가지 샘플을 수동으로 검사하여 프롬프트가 올바르게 형식화되었는지, 그리고 모든 사후 과정이 정확한 정보를 추출하는지 확인한다. 평가는 모든 단일 결정을 안내할 것이므로, 이 단계를 올바르게 수행하는 것이 프로젝트 성공에 중요하다!

모든 변경 사항을 테스트한다. 아무리 작더라도 상관없다. 겉보기에는 무해해 보이는 라이브러리 업그레이드나 “두 줄만 변경한” 커밋의 영향을 과소평가하지 않는다. 이러한 작은 변경 사항들은 여러분의 결과를 오염시킬 미묘한 버그나 성능 변화를 유발할 수 있다. 회귀를 방지하기 위해 여러분에게 중요한 사례에 대한 강력한 테스트 스위트를 가진 라이브러리가 필요하다.

(어떤 경우에는 버그가 라이브러리를 최신 버전으로 업그레이드함으로써 해결될 수 있다. 이에 대한 아름다운 예시와 일부 탐정 디버깅은 Elana Simon의 블로그 게시물 https://elanapearl.github.io/blog/2025/the-bug-that-taught-me-pytorch/?t=1 을 참조해라.)

한 번에 하나씩 변경한다. 실험 간에 다른 모든 것을 동일하게 유지한다. 일부 변경 사항은 예상치 못한 방식으로 서로 상호 작용할 수 있으므로, 우리는 먼저 각 변경 사항의 개별 기여도를 평가한 다음, 전체 영향을 보기 위해 그것들을 결합해 보려 한다.

충분한 토큰으로 학습하고 충분한 평가를 사용한다. 앞에서 언급했듯이, 우리는 평가 스위트에서 좋은 커버리지를 확보하고 신뢰할 수 있는 신호를 얻을 만큼 충분히 오래 학습해야 한다. 여기서 지름길을 택하는 것은 노이즈가 많은 결과와 나쁜 결정으로 이어질 것이다.

이러한 규칙들을 따르는 것이 지나치게 조심스럽게 느껴질 수 있지만, 대안은 며칠 전에 일어난 무관한 종속성 업데이트로 인해 발생한 것으로 밝혀지는 불가사의한 성능 저하를 디버깅하는 데 시간을 보내는 것이다. 황금 원칙: 일단 좋은 설정을 갖추었다면, 테스트되지 않은 채로 넘어가서는 안 되는 변경 사항은 없다!

Designing the model architecture

이제 실험 프레임워크가 마련되었으므로, 모델을 정의할 중요한 결정들을 내릴 시간이다. 모델 크기부터 어텐션 메커니즘, 토크나이저 선택에 이르기까지 우리가 내리는 모든 선택은 모델 학습 및 사용에 영향을 미칠 제약과 기회를 만들어낸다.

학습 나침반을 기억해라: 기술적 선택을 하기 전에, 왜와 무엇에 대한 명확성이 필요하다. 왜 이 모델을 학습시키고, 그것은 어떻게 보여야 하는가?

이것은 자명하게 들리겠지만, 이전에 논의했던 학습 나침반에서 설명했듯이, 우리가 가능한 실험의 무한한 공간에서 길을 잃지 않으려면 여기서 신중하게 대해야 좋은 결정을 형성할 수 있다. 우리는 영어에서 SOTA 모델을 목표로 하는가? 긴 컨텍스트가 우선순위인가? 아니면 새로운 아키텍처를 검증하려 하는가? 학습 루프는 이 모든 경우에 유사하게 보일 수 있지만, 우리가 실행하는 실험과 우리가 수용하는 트레이드오프는 다를 것이다. 이 질문에 일찍 답하는 것은 데이터 작업과 아키텍처 작업 사이에 우리의 시간을 어떻게 균형 있게 배분할지, 그리고 실행을 시작하기 전에 각각에서 얼마나 혁신할지 결정하는 데 도움이 된다.

따라서, 모범을 보여 SmolLM3의 설계를 안내한 목표들을 살펴본다. 우리는 경쟁력 있는 다국어 성능, 견고한 수학 및 코딩 능력, 그리고 강력한 긴 컨텍스트 처리를 갖춘 온디바이스 애플리케이션을 위한 강력한 모델을 원했다. 이전에 언급했듯이, 이것은 우리를 3B 매개변수를 가진 Dense 모델로 이끌었다: 강력한 능력을 위해 충분히 크지만, 휴대폰에 편안하게 맞을 만큼 충분히 작다. 우리는 엣지 디바이스의 메모리 제약과 우리의 프로젝트 타임라인(약 3개월)을 고려하여 MoE 또는 하이브리드 모델 대신 밀집형 트랜스포머를 선택했다.

우리는 더 작은 규모(1.7B 매개변수)의 영어용 SmolLM2에서 작동하는 레시피를 가지고 있었지만, 규모를 확장하는 것은 모든 것을 재검증하고 다국어성 및 확장된 컨텍스트 길이와 같은 새로운 도전 과제를 해결하는 것을 의미했다. 이는 잘 정의된 목표를 갖는 것이 우리의 접근 방식을 어떻게 구성했는지에 대한 명확한 예시이다. 예를 들어, SmolLM2에서는 사전 학습이 끝날 무렵 컨텍스트 길이를 확장하는 데 어려움을 겪었으므로, SmolLM3에서는 처음부터 NoPE 및 문서 내 마스킹(intra-document masking)과 같은 아키텍처 선택을 하여 (나중에 참조) 그것을 올바르게 얻을 가능성을 극대화했고, 그것은 효과가 있었다.

(SmolLM2는 우리의 이전 세대 소형 언어 모델이었으며, 온디바이스 배포를 위해 설계된 1억 3500만, 3억 6천만, 그리고 17억 매개변수의 세 가지 변형이 있었다. 그것들은 8k 컨텍스트 길이를 가진 영어 전용이었다.)

우리의 목표가 명확해지면, 우리는 그것들을 실현할 기술적 결정들을 내리기 시작할 수 있다. 이 챕터에서는 아키텍처, 데이터, 그리고 하이퍼파라미터와 같은 이러한 핵심 결정들에 대한 우리의 체계적인 접근 방식을 살펴볼 것이다. 이것을 우리의 전략적 계획 단계로 생각한다. 이러한 기본 사항을 올바르게 파악하면 실제 학습 마라톤 동안 비용이 많이 드는 실수를 피할 수 있다.

아키텍처 선택

Qwen3, Gemma3, 또는 DeepSeek v3와 같은 최근 모델들을 보면, 그들의 차이점에도 불구하고, 그들 모두가 2017년에 도입된 동일한 기반인 트랜스포머 아키텍처를 공유한다는 것을 알 수 있다 (Vaswani et al., 2023). 수년에 걸쳐 바뀐 것은 근본적인 구조가 아니라, 그 핵심 구성 요소에 대한 개선 사항이다. 밀집형 모델, 전문가 혼합(Mixture of Experts), 또는 하이브리드 아키텍처를 구축하든, 여러분은 이러한 동일한 빌딩 블록들을 가지고 작업하는 것이다.

이러한 개선 사항들은 더 나은 성능을 추구하고 특정 도전 과제들을 해결하려는 팀들로부터 나타났다: 추론 중 메모리 제약, 대규모에서의 학습 불안정성, 또는 더 긴 컨텍스트를 처리할 필요성이 바로 그것들이다. Multi-Head Attention (MHA)에서 Grouped Query Attention (GQA) (Ainslie et al., 2023)과 같은 더 컴퓨팅 효율적인 어텐션 변형으로의 전환과 같은 일부 수정 사항은 이제 널리 채택되었다. 다른 것들, 예를 들어 다른 Positional 인코딩 방식들은 여전히 논의 중이다. 결국, 오늘날의 실험들은 내일의 기준선으로 구체화될 것이다.

그렇다면 오늘날 현대 LLM은 실제로 무엇을 사용하는가? 선도적인 모델들이 수렴한 모습을 살펴보자. 불행히도, 모든 모델이 그들의 학습 세부 정보를 공개하는 것은 아니지만, DeepSeek, OLMo, Kimi, 그리고 SmolLM과 같은 패밀리로부터 현재의 풍경을 충분히 투명하게 알아볼 수 있다:

모델	아키텍처	매개변수	학습 토큰	어텐션	컨텍스트 길이 (최종)	위치 인코딩	정밀도	초기화 (std)	옵티마이저	최대 LR	LR 스케줄	웜업 스텝	배치 크기
DeepSeek LLM 7B	Dense	7B	2T	GQA	4K	RoPE	BF16	0.006	AdamW	`4.2×10−44.2×10−4`	Multi-Step	2K	9.4M
DeepSeek LLM 67B	Dense	67B	2T	GQA	4K	RoPE	BF16	0.006	AdamW	`3.2×10−43.2×10−4`	Multi-Step	2K	18.9M
DeepSeek V2	MoE	236B (21B active)	8.1T	MLA	128K	Partial RoPE	-	0.006	AdamW	`2.4×10−42.4×10−4`	Multi-Step	2K	9.4M→37.7M (warmup 225B)
DeepSeek V3	MoE	671B (37B active)	14.8T	MLA	129K	Partial RoPE	FP8	0.006	AdamW	`2.2×10−42.2×10−4`	Multi-Step + Cosine	2K	12.6M→62.9M (warmup 469B)
MiniMax-01	MoE + 하이브리드	456B (45.9 active)	11.4T	Linear attention + GQA	4M	Partial RoPE	-	Xavier init with deepnorm scaling	AdamW	`2×10−42×10−4`	Multi-Step	500	16M→32M→64M→128M
Kimi K2	MoE	1T (32B active)	15.5T	MLA	128K	Partial RoPE	BF16	likely 0.006	MuonClip	`2×10−42×10−4`	WSD	500	67M
OLMo 2 7B	Dense	7B	5T	MHA	4K	RoPE	BF16	0.02	AdamW	`3×10−43×10−4`	Cosine	2K	4.2M
SmolLM3	Dense	3B	11T	GQA	128K	NoPE	BF16	0.02	AdamW	`2×10−42×10−4`	WSD	2K	2.3M

아직 MLA, NoPE 또는 WSD와 같은 용어를 이해하지 못해도 걱정하지 않아도 좋다. 우리는 이 섹션에서 추후 각각을 설명할 것이다. 지금은 다양성이 어디서 나타나는지에 대해 주목해라: 다른 어텐션 메커니즘 (MHA, GQA, MLA), 위치 인코딩 (RoPE, NoPE, partial RoPE), 그리고 학습률 스케줄 (Cosine, Multi-Step, WSD)이다.

이 긴 아키텍처 선택 목록을 보면 어디서부터 시작해야 할지 파악하기가 다소 벅차다. 대부분의 이러한 상황에서와 같이, 우리는 한 단계씩 진행하며 필요한 모든 노하우를 점진적으로 구축할 것이다. 우리는 먼저 가장 간단한 기본 아키텍처(밀집형 모델)에 초점을 맞추고 각 아키텍처 측면을 자세히 조사할 것이다. 나중에, 우리는 MoE 및 하이브리드 모델에 깊이 뛰어들어 그것들을 사용하는 것이 좋은 선택인 때를 논의할 것이다. 마지막으로 우리는 종종 간과되고 저평가되는 구성 요소인 토크나이저를 탐색한다. 기존 것을 사용해야 하는가 아니면 자체적으로 학습해야 하는가? 우리의 토크나이저가 좋은지 어떻게 평가하는가?

📍 제거 실험 설정

이 챕터의 나머지 부분에서, 우리는 위에 설명된 설정을 사용하여 대부분의 아키텍처 선택을 제거 실험을 통해 검증할 것이다: FineWeb-Edu, FineMath, 그리고 Python-Edu의 혼합으로부터 45B 토큰으로 학습된 우리의 1B baseline 모델 (Llama3.2 1B 아키텍처를 따름)을 기반으로. 각 실험에 대해, 우리는 각 수정 사항의 영향을 평가하기 위해 학습 손실 곡선과 다운스트림 평가 점수를 모두 보여줄 것이다. 모든 실행을 위한 설정은 HuggingFaceTB/training-guide-nanotron-configs에서 찾을 수 있다.

이제 모든 LLM의 핵심인 어텐션 메커니즘부터 시작해보자.

어텐션

트랜스포머 아키텍처 주변의 가장 활발한 연구 분야 중 하나는 어텐션 메커니즘이다. 피드포워드 레이어는 사전 학습 중 컴퓨팅을 지배하는 반면, 어텐션은 추론 시 (특히 긴 컨텍스트에서) 주요 병목 현상이 되며, 여기서 컴퓨팅 비용이 높아지고 KV 캐시가 빠르게 GPU 메모리를 소비하여 Throughput 을 감소시킨다. 주요 어텐션 메커니즘들이 능력과 속도를 어떻게 트레이드오프하는지에 대한 간략한 둘러보기를 해보자.

내 어텐션을 위한 헤드 수는 몇 개인가?

(Jay Alamar의 유명한 블로그 게시물 https://jalammar.github.io/illustrated-transformer/을 확인하여 빠르게 복습해라!)

**Multi-head attention (MHA)**는 오리지널 트랜스포머와 함께 도입된 표준 어텐션이다 (Vaswani et al., 2023). 주요 아이디어는 N개의 어텐션 헤드가 각각 독립적으로 동일한 검색 작업을 수행한다는 것이다: 은닉 상태를 쿼리, 키, 그리고 값으로 변환한 다음, 현재 쿼리를 사용하여 키 일치를 통해 가장 관련성이 높은 토큰을 검색하고 마지막으로 일치하는 토큰과 연결된 값을 전달한다. 추론 시 우리는 과거 토큰에 대한 KV 값을 다시 계산할 필요가 없으며 그것들을 재사용할 수 있다. 과거 KV 값에 대한 메모리를 KV-Cache라고 부른다. 컨텍스트 창이 증가함에 따라, 이 캐시는 빠르게 추론 병목 현상이 될 수 있으며 GPU 메모리의 큰 부분을 소비한다. 다음은 MHA와 8192의 시퀀스 길이를 가진 Llama 3 아키텍처에 대한 KV-Cache 메모리 $s_{KV}$ 를 추정하는 간단한 계산이다:

s_{KV}=2×nbytes×seq×nlayers×nheads×dim_{heads}\\=2×2×8192×32×32×128=4 GB \space \space (Llama 3 8B)\\=2×2×8192×80×64×128=20 GB \space \space (Llama 3 70B)

앞의 계수 2는 키 및 값 캐시를 모두 저장하는 것에서 비롯된다는 점에 주의해라. 보시다시피, 캐시는 시퀀스 길이에 따라 선형적으로 증가하지만, 컨텍스트 창은 기하급수적으로 증가하여 이제 수백만 토큰에 이른다. 따라서 캐시의 효율성을 개선하는 것은 추론 시 컨텍스트 확장을 훨씬 쉽게 만들 것이다.

묻게 되는 자연스러운 질문은: 각 헤드에 대해 새로운 KV 값이 정말로 필요한가? 이다. 아마도 아닐 것이며, Multi-Query Attention (MQA) (Shazeer, 2019)와 Grouped Query Attention (GQA) (Ainslie et al., 2023) 둘 다 이것을 다룬다. 가장 간단한 경우는 모든 헤드에 걸쳐 KV 값을 공유하는 것이며, 이 경우 KV 캐시의 크기를 $n_{heads}$ 로 나눌 수 있다. 이는 예를 들어 Llama 3 70B의 경우 64분의 1 감소이다! 이것이 MQA의 아이디어이며 MHA의 대안으로 StarCoder와 같은 일부 모델에서 사용되었다. 그러나 우리는 우리가 기꺼이 포기하려는 것보다 조금 더 많은 어텐션 능력을 포기할 수 있으므로, 우리는 중간 지점을 고려하고 헤드 그룹에 걸쳐 KV 값을 공유할 수 있다. 예를 들어, 4개의 헤드가 동일한 KV 값을 공유하는 것이다. 이것이 GQA 접근 방식이며 MQA와 MHA 사이의 중간 지점을 찾는다.

더 최근에, DeepSeek-v2 (그리고 v3에서도 사용됨)는 Multi-Latent Attention (MLA) (DeepSeek-AI et al., 2024)를 도입했는데, 이는 캐시를 압축하기 위해 다른 전략을 사용한다: KV 값의 수를 줄이는 대신 그 크기를 줄이고 실행 시간에 KV 값으로 압축 해제될 수 있는 잠재 변수를 저장한다. 이 접근 방식을 통해 그들은 MHA보다 더 강력한 성능을 제공하면서 2.25개의 그룹을 가진 GQA에 해당하는 캐시로 줄이는 데 성공했다! 이것이 RoPE와 함께 작동하도록 하기 위해, 여분의 작은 잠재 벡터를 가진 작은 조정이 필요하다. DeepSeek-v2에서 그들은 주 잠재 변수에 대해 $4*dimhead$ 를, RoPE 부분에 대해 $\frac{1}{2}*dim_{head}$ 를 선택하여 총 $4.5*dim_{head}$

를 선택했는데, 이는 K와 V 모두에 동시에 사용되어 앞의 계수 2를 제거한다.

(RoPE (Rotary Position Embeddings)는 시퀀스 내 위치를 기반으로 쿼리 및 키 벡터를 회전시켜 위치 정보를 인코딩하는 방법이다. 오늘날 LLM에서 흔히 사용된다.)

다음 그래픽에서 각 어텐션 메커니즘에 대한 시각적 설명을 볼 수 있다:

스크린샷 2025-12-05 오후 4.49.20.png

Multi-Head Attention (MHA), Grouped-Query Attention (GQA), Multi-Query Attention (MQA), 및 Multi-head Latent Attention (MLA)의 단순화된 그림이다. MLA는 키와 값을 잠재 벡터로 공동 압축함으로써, 추론 중 KV 캐시를 상당히 감소시킨다.

다음 표는 이 섹션에서 방금 논의한 어텐션 메커니즘을 비교한다. 단순화를 위해 토큰당 사용되는 매개변수를 비교한다. 총 메모리를 계산하려면 단순히 매개변수당 바이트 (일반적으로 2)와 시퀀스 길이를 곱하면 된다:

어텐션 메커니즘	토큰당 KV-캐시 매개변수
MHA	$2 \times n_{heads} \times n_{layers} \times dim_{head}$
MQA	$2 \times 1 \times n_{layers} \times dim_{head}$
GQA	$2 \times g \times n_{layers} \times dim_{head}$ (일반적으로 g=2,4,8)
MLA	$4.5 \times n_{layers} \times dim_{head}$

이제 이러한 어텐션 메커니즘이 실제 실험에서 어떻게 작동하는지 보자!

제거 실험 - GQA가 MHA를 이긴다

여기서 우리는 다른 어텐션 메커니즘을 비교한다. 우리의 기준 모델은 32개의 헤드와 8개의 KV 헤드를 사용하며, 이는 비율 32/8=4를 가진 GQA에 해당한다. MHA를 사용하거나, 또는 훨씬 더 적은 KV 헤드와 더 높은 GQA 비율로 간다면 성능은 어떻게 변할까?

(일부 라이브러리는 GQA 비율을 이렇게 부른다: 쿼리 그룹 = 쿼리 헤드 / KV 헤드)

KV 헤드 수를 변경하는 것은 특히 MHA의 경우 매개변수 수에 영향을 미친다. 일관성을 위해, MHA 실행의 경우 레이어 수를 조정했다. 그렇지 않으면 1억 이상의 매개변수 불일치가 발생할 것이기 때문이다. 나머지는 기본 16개 레이어를 유지했다.

어텐션 유형	쿼리 헤드	KV 헤드	레이어	매개변수 수	비고
MQA	32	1	16	1.21B
GQA (비율 16)	32	2	16	1.21B
GQA (비율 8)	32	4	16	1.22B	우리의 Baseline
GQA (비율 4)	32	8	16	1.24B
GQA (비율 2)	32	16	15	1.22B	레이어 감소
MHA	32	32	14	1.20B	레이어 감소
GQA (비율 2)	32	16	16	1.27B	너무 큼 - 제거 실험 안 함
MHA	32	32	16	1.34B	너무 큼 - 제거 실험 안 함

따라서 우리는 MHA, MQA, 그리고 4개의 GQA 설정 (비율 2, 4, 8, 16)을 비교했다. nanotron 설정은 여기에서 찾을 수 있다. https://huggingface.co/datasets/HuggingFaceTB/training-guide-nanotron-configs/tree/main/attention

제거 실험 결과를 보면, MQA와 16개 그룹을 가진 GQA (각각 1개와 2개의 KV 헤드만 남김)가 MHA보다 현저히 낮은 성능을 보인다. 반면에, 2, 4, 8개 그룹을 가진 GQA 구성은 MHA 성능과 대략 일치한다.

스크린샷 2025-12-05 오후 4.49.36.png

스크린샷 2025-12-05 오후 4.49.47.png

결과는 손실 곡선과 다운스트림 평가 모두에서 일관되었다. 우리는 HellaSwag, MMLU, ARC와 같은 벤치마크에서 이것을 명확하게 관찰하는 반면, OpenBookQA와 WinoGrande와 같은 벤치마크는 약간의 노이즈를 보였다.

이러한 제거 실험을 기반으로, GQA는 MHA의 견고한 대안이다. 이는 추론에서 더 효율적이면서 성능을 유지한다. 일부 최신 모델은 훨씬 더 큰 KV 캐시 압축을 위해 MLA를 채택했지만, 아직 널리 채택되지는 않았다. 제거 실험 당시 nanotron에 MLA가 구현되지 않았으므로 우리는 MLA를 제거 실험하지 않았다. SmolLM3의 경우, 우리는 4개 그룹을 가진 GQA를 사용했다.

어텐션 아키텍처 자체를 넘어, 우리가 학습 중에 사용하는 어텐션 패턴도 중요하다. 어텐션 마스킹을 살펴보자.

문서 마스킹

우리가 학습 시퀀스 전반에 걸쳐 어텐션을 적용하는 방식은 계산 효율성과 모델 성능 모두에 영향을 미친다. 이는 문서 마스킹과 데이터로더에서 학습 샘플을 구성하는 방법에 대한 더 넓은 질문으로 이어진다.

사전 학습 중에, 우리는 고정된 시퀀스 길이로 학습하지만 우리의 문서는 가변적인 길이를 가진다. 연구 논문은 10k 토큰일 수 있는 반면, 짧은 코드 스니펫은 수백 토큰만 가질 수 있다. 가변 길이 문서를 고정 길이 학습 시퀀스에 어떻게 맞추는가? 짧은 문서를 우리의 목표 길이에 도달하도록 패딩하는 것은 무의미한 패딩 토큰에 컴퓨팅 자원을 낭비한다. 대신, 우리는 **패킹(packing)**을 사용한다: 문서들을 시퀀스 끝(EOS) 토큰과 함께 섞고 연결한 다음, 그 결과를 시퀀스 크기와 일치하는 고정 길이 덩어리로 나눈다.

(우리는 문서 시작(BOS) 토큰을 문서 시작 부분에 추가할 수도 있다. 이 경우 모델/토크나이저 설정에서 다른 bos_token_id가 있음을 알게 될 것이다.)

실제에서 이것이 어떻게 보이는지 보자:

File 1: "Recipe for granola bars..." (400 tokens) <EOS>
File 2: "def hello_world()..." (300 tokens) <EOS>
File 3: "Climate change impacts..." (1000 tokens) <EOS>
File 4: "import numpy as np..." (3000 tokens) <EOS>
...

After concatenation and chunking into 4k sequences:
Sequence 1: [File 1] + [File 2] + [File 3] + [partial File 4]
Sequence 2: [rest of File 4] + [File 5] + [File 6] + ...

학습 시퀀스는 4k 컨텍스트를 채울 만큼 충분히 길다면 하나의 완전한 파일을 포함할 수 있지만, 대부분의 경우 파일이 짧으므로, 시퀀스는 여러 랜덤 파일의 연결을 포함한다.

표준 causal masking 을 사용하면, 토큰은 패킹된 시퀀스의 모든 이전 토큰에 어텐션할 수 있다. 위 예시들에서, 파일 4의 해당 파이썬 함수 내의 토큰은 그래놀라 바 레시피, 기후 변화 기사, 그리고 함께 패킹된 다른 모든 콘텐츠에 어텐션할 수 있다. 일반적인 4k 사전 학습 컨텍스트가 무엇을 포함하는지 빠르게 살펴보자. 빠른 분석 (https://www.harmdevries.com/post/context-length/)에 따르면 CommonCrawl 및 GitHub의 파일 중 상당 부분(약 80-90%)이 2k 토큰보다 짧다.

아래 차트는 이 블로그 전체에서 사용된 더 최근 데이터셋에 대한 토큰 분포를 조사한 결과이다:

스크린샷 2025-12-05 오후 4.49.59.png

FineWeb-Edu, DCLM, FineMath 및 Python-Edu의 문서 중 80% 이상이 2k 토큰 미만을 포함한다. 이는 2k 또는 4k 학습 시퀀스와 표준 인과적 마스킹을 사용하면, 토큰의 대다수가 함께 패킹된 관련 없는 문서에 어텐션하는 데 컴퓨팅 자원을 소비할 것임을 의미한다.

PDF의 더 긴 문서

대부분의 웹 기반 데이터셋은 짧은 문서로 구성되어 있지만, PDF 기반 데이터셋은 상당히 더 긴 콘텐츠를 포함한다. FinePDFs 문서는 웹 텍스트보다 평균 2배 더 길며, FineWeb-Edu 및 DCLM과 혼합될 때 성능을 향상시킨다.

계산 비효율성 외에도, Zhao et al. (2024)은 이 접근 방식이 성능을 저하시킬 수 있는 관련 없는 콘텐츠로부터 노이즈를 유발한다는 것을 발견한다. 그들은 **문서 내 마스킹(intra-document masking)**을 사용할 것을 제안하는데, 여기서 우리는 어텐션 마스크를 수정하여 토큰이 동일한 문서 내의 이전 토큰에만 어텐션할 수 있도록 한다. 아래 시각화는 이러한 차이를 보여준다:

스크린샷 2025-12-05 오후 4.50.11.png

SkyLadder의 Zhu et al. (2025)은 문서 내 마스킹에서 유사한 이점을 발견했지만, 다른 설명을 제공한다. 그들은 더 짧은 컨텍스트 길이가 학습에 더 잘 작동한다는 것을 발견했으며, 문서 내 마스킹은 평균 컨텍스트 길이를 효과적으로 줄인다.

SkyLadder의 이 플롯들은 여러 발견을 보여준다: (a) 더 짧은 컨텍스트가 사전 학습 중 더 나은 성능을 보이는 경우가 많고 (더 낮은 검증 혼란도), (b) 문서 내 마스킹(IntraDoc)이 랜덤 패킹(Random) 및 의미론적 그룹화(BM25)보다 더 낮은 혼란도를 달성하며, (c) 더 짧은 컨텍스트 이점은 위치 인코딩 없이도 유지되고, (d) IntraDoc은 더 짧은 유효 컨텍스트 길이로 편향된 분포를 생성한다.

Llama3 (Grattafiori et al., 2024)도 문서 내 마스킹으로 학습했으며, 그들은 짧은 컨텍스트 사전 학습 중에는 제한된 영향을 발견했지만, 어텐션 오버헤드가 더 중요해지는 긴 컨텍스트 확장에는 상당한 이점을 발견했다. 또한, ProLong 논문 (Gao et al., 2025)은 문서 마스킹을 사용하여 Llama3 8B의 컨텍스트를 지속적인 사전 학습에서 확장하는 것이 긴 컨텍스트 및 짧은 컨텍스트 벤치마크 모두에 이점을 준다는 것을 보여주었다.

우리는 우리의 1B 기준 모델에 대해 제거 실험을 실행하고 문서 마스킹이 짧은 컨텍스트 성능에 영향을 미치는지 테스트하기로 결정했다. 설정은 여기(https://huggingface.co/datasets/HuggingFaceTB/training-guide-nanotron-configs/blob/main/doc_masking/doc_masking.yaml) 에서 찾을 수 있다. 결과는 아래 차트에 표시된 대로 표준 인과적 마스킹과 비교하여 동일한 손실 곡선과 다운스트림 평가 점수를 보여주었다.

nanotron에서 문서 마스킹을 활성화하려면, 모델 설정에서 이 플래그를 참(true)으로 설정하기만 하면 된다:

model_config:
  _attn_implementation: flash_attention_2
  _fused_rms_norm: true
  _fused_rotary_emb: true
 _use_doc_masking: true # 이 부분을 true로 설정

스크린샷 2025-12-05 오후 4.50.42.png

스크린샷 2025-12-05 오후 4.50.51.png

Llama3와 유사하게, PIQA에서의 작은 개선을 제외하면, 짧은 컨텍스트 작업에 눈에 띄는 영향은 관찰되지 않았다. 그러나 문서 마스킹은 학습 속도를 높이기 위해 긴 시퀀스로 확장할 때 중요해진다. 이는 우리가 4k에서 64k 토큰으로 확장하는 긴 컨텍스트 확장에 특히 중요하다 (학습 마라톤 챕터에서 자세히 설명). 따라서 우리는 SmolLM3의 전체 학습 실행 전반에 걸쳐 그것을 채택했다.

우리는 이 섹션에서 어텐션이 시퀀스를 처리하는 방법을 다루었다. 이제 트랜스포머의 또 다른 주요 파라미터 블록인 임베딩을 살펴보자.

임베딩 공유

우리의 기준 제거 실험 모델의 설정(config)을 보면, 표준 트랜스포머와 다른 한 가지는 tie_word_embeddings 플래그로 활성화된 임베딩 공유이다.

LLM에는 두 가지 임베딩 구성 요소가 있다: 토큰 대 벡터 조회 테이블 역할을 하는 입력 임베딩 (크기 vocab_size × hidden_dim)과, 은닉 상태를 어휘 로짓으로 매핑하는 최종 선형 레이어인 출력 임베딩 (hidden_dim × vocab_size)이다. 이것들이 별개의 행렬인 고전적인 경우, 총 임베딩 매개변수는 2 × vocab_size × hidden_dim 이다. 따라서 소형 언어 모델에서는, 특히 큰 vocabulary size 에서는 임베딩이 전체 파라미터 수의 큰 부분을 차지할 수 있다. 이로 인해 임베딩 공유 (출력에서 입력 임베딩을 재사용)는 소형 모델에게 자연스러운 최적화가 된다.

스크린샷 2025-12-05 오후 4.51.06.png

더 큰 모델은 임베딩이 매개변수 예산의 더 작은 부분을 차지하기 때문에 일반적으로 이 기술을 사용하지 않는다. 예를 들어, 아래 원형 차트에 표시된 대로 공유 없는 총 임베딩은 Llama3.2 8B에서는 13%, Llama3.1 70B에서는 3%만을 차지한다.

스크린샷 2025-12-05 오후 4.51.56.png

스크린샷 2025-12-05 오후 4.52.03.png

제거 실험 - Tied 임베딩을 가진 모델은 더 큰 Untied 변형과 일치한다

이제 우리는 우리의 제거 실험 모델에 대한 임베딩 공유의 영향을 평가할 것이다. 우리는 MobileLLM이 125M 규모에서 이 기술에 대해 수행한 포괄적인 제거 실험에서 통찰력을 얻는다. 거기서 그들은 공유가 최소한의 정확도 저하로 매개변수를 11.8% 감소시킨다는 것을 입증했다.

묶이지 않은 임베딩은 우리의 파라미터 수를 1.2B에서 1.46B으로 증가시키기 때문에, 우리는 파라미터 수를 맞추기 위해 Untied 파라미터이지만 더 적은 레이어(12 레이어)를 가진 또 다른 모델을 학습시킬 것이다. 우리는 두 개의 1.2B 모델을 비교할 것이다: 묶인 임베딩을 가진 우리의 기준선 (16 레이어) 대 동일한 매개변수 예산을 유지하기 위해 더 적은 레이어 (12 레이어)를 가진 묶이지 않은 버전, 그리고 추가 참조점으로 우리의 기준선과 동일한 레이어 수 (16)를 가진 14억 6천만 묶이지 않은 모델의 비교이다. nanotron 설정은 여기 (https://huggingface.co/datasets/HuggingFaceTB/training-guide-nanotron-configs/blob/main/baseline_config_1B.yaml) 에서 찾을 수 있다.

스크린샷 2025-12-05 오후 4.52.15.png

스크린샷 2025-12-05 오후 4.52.24.png

손실 및 평가 결과는 우리의 기준 1.2B 모델이 Tied Embedding 을 가지고 있음에도 불구하고, WinoGrande를 제외한 모든 벤치마크에서 18% 더 적은 매개변수를 가짐에도 불구하고 1.46B Untied 모델과 필적하는 성능을 달성한다는 것을 보여주었다. Untied Embedding 과 감소된 레이어(16 vs 12)를 가진 1.2억 모델은 더 높은 손실과 더 낮은 다운스트림 평가 점수를 보이면서 두 구성 모두보다 낮은 성능을 보였다. 이것은 모델 깊이를 증가시키는 것이 동일한 매개변수 예산에서 임베딩을 묶지 않는 것보다 더 큰 이점을 제공함을 시사한다.

이러한 결과를 바탕으로, 우리는 SmolLM3 3B 모델에 묶인 임베딩(tied embeddings)을 유지했다.

이제 우리는 임베딩 공유 전략과 그 장단점을 탐색했다. 그러나 임베딩만으로는 시퀀스에서 토큰의 순서를 포착하지 못한다. 이 정보를 제공하는 것이 위치 인코딩(Positional Encoding)의 역할이다. 다음 섹션에서는 표준 RoPE에서부터 긴 컨텍스트에 대한 더 효과적인 모델링을 가능하게 하는 NoPE (No Positional Encoding)와 같은 새로운 접근 방식에 이르기까지 위치 인코딩 전략이 어떻게 발전했는지 살펴볼 것이다.

위치 인코딩(Positional Encoding) 및 긴 컨텍스트

트랜스포머가 텍스트를 처리할 때, 근본적인 도전에 직면한다: 그들은 병렬 어텐션 작업을 통해 전체 시퀀스를 동시에 소비하므로, 본질적으로 단어 순서에 대한 감각이 없다. 이것은 효율적인 학습을 가능하게 하지만 문제를 만든다. 명시적인 위치 정보 없이는, 모델의 관점에서 “Adam은 Muon을 이긴다”는 “Muon은 Adam을 이긴다”와 비슷하게 보인다.

해결책은 위치 임베딩이다: 각 토큰에 시퀀스에서 고유한 “주소”를 제공하는 수학적 인코딩이다. 그러나 초기 BERT의 512 토큰에서부터 오늘날의 백만 토큰 모델에 이르기까지 점점 더 긴 컨텍스트로 나아감에 따라, 위치 인코딩의 선택은 성능과 계산 효율성 모두에 점점 더 중요해져왔다.

위치 인코딩의 진화

초기 트랜스포머는 간단한 **절대 위치 임베딩(Absolute Position Embeddings, APE)**을 사용했다 (Vaswani et al., 2023). 이는 본질적으로 각 위치 (1, 2, 3…)를 토큰 임베딩에 추가되는 벡터에 매핑하는 학습된 조회 테이블이었다. 이것은 짧은 시퀀스에는 잘 작동했지만, 주요 한계가 있었다: 모델의 최대 입력 시퀀스 길이는 학습된 최대 입력 시퀀스 길이로 제한되었다. 그들은 더 긴 시퀀스에 대한 즉각적인 일반화 능력이 없었다.

이 분야는 절대 위치 대신 토큰 간의 거리를 포착하는 상대 위치 인코딩으로 진화했다. 이것은 직관적으로 합리적이다. 두 단어가 (5, 8) 대 (105, 108) 위치에 있는지 여부보다 3 위치 떨어져 있는지 여부가 더 중요한다.

(위치 인코딩에 대한 더 깊은 탐구를 위해, 이 블로그 (https://huggingface.co/blog/designing-positional-encoding) 는 기본 위치 지정에서 회전 인코딩으로의 단계별 개발 과정을 안내한다.)

ALiBi (Attention with Linear Biases) (Press et al., 2022)는 특히 토큰 거리를 기반으로 어텐션 점수를 수정한다. 두 토큰이 더 멀리 떨어져 있을수록, 어텐션 가중치에 적용되는 간단한 선형 편향을 통해 그들의 어텐션은 더 많이 페널티를 받는다. Alibi의 자세한 구현은 이 자료(https://nn.labml.ai/transformers/alibi/index.html) 를 확인하면 된다.

그러나 최근 대규모 언어 모델을 지배해 온 기술은 **회전 위치 임베딩(Rotary Position Embedding, RoPE)**이다 (Su et al., 2023).

RoPE: 회전으로서의 위치

RoPE의 핵심 통찰력은 위치 정보를 고차원 공간에서의 회전 각도로 인코딩하는 것이다. 토큰 임베딩에 위치 벡터를 추가하는 대신, RoPE는 쿼리 및 키 벡터를 그들의 절대 위치에 따라 달라지는 각도로 회전시킨다.

직관은 다음과 같다: 우리는 임베딩의 각 차원 쌍을 원 위의 좌표로 취급하고, 다음 두 가지에 의해 결정되는 각도로 그것들을 회전시킨다:

시퀀스에서 토큰의 위치
우리가 작업하는 차원 쌍 (다른 쌍은 베이스/참조 주파수의 지수인 다른 주파수로 회전한다)

import torch

def apply_rope_simplified(x, pos, dim=64, base=10000):
    """
    Rotary Position Embedding (RoPE)

    아이디어:
    - 각 토큰은 위치 인덱스 p (0, 1, 2, ...)를 가진다.
    - 벡터 차원의 각 쌍은 인덱스 k (0 .. dim/2 - 1)를 가진다.
    - RoPE는 모든 쌍 [x[2k], x[2k+1]]을 각도 θ_{p,k}만큼 회전시킨다.

    공식:
      θ_{p,k} = p * base^(-k / (dim/2))

    - 작은 k (초기 차원 쌍) → 느린 진동 → 장거리 정보 포착.
    - 큰 k (후기 차원 쌍) → 빠른 진동 → 세부 정보 포착.

    """
    rotated = []
    for i in range(0, dim, 2):
        k = i // 2  # 이 차원 쌍의 인덱스

        # 주파수 항: k가 높을수록 → 진동이 빠름
        inv_freq = 1.0 / (base ** (k / (dim // 2)))
        theta = pos * inv_freq  # 위치 p와 쌍 k에 대한 회전 각도

        cos_t = torch.cos(torch.tensor(theta, dtype=x.dtype, device=x.device))
        sin_t = torch.sin(torch.tensor(theta, dtype=x.dtype, device=x.device))

        x1, x2 = x[i], x[i+1]

        # 2D 회전 적용
        rotated.extend([x1 * cos_t - x2 * sin_t,
                        x1 * sin_t + x2 * cos_t])

    return torch.stack(rotated)

## Q, K: [batch, heads, seq, d_head]
Q = torch.randn(1, 2, 4, 8)
K = torch.randn(1, 2, 4, 8)

## 👉 Q와 K에 내적 *전에* RoPE 적용
Q_rope = torch.stack([apply_rope(Q[0,0,p], p) for p in range(Q.size(2))])
K_rope = torch.stack([apply_rope(K[0,0,p], p) for p in range(K.size(2))])

scores = (Q_rope @ K_rope.T) / math.sqrt(Q.size(-1))
attn_weights = torch.softmax(scores, dim=-1)

이 코드가 복잡해 보일 수 있으므로 구체적인 예시로 분석해보자. 문장 “The quick brown fox”에서 단어 “fox”를 고려해보자. 우리의 기준 1B 모델에서, 각 어텐션 헤드는 64차원 쿼리/키 벡터로 작업한다. RoPE는 이 벡터를 32쌍으로 그룹화한다: (x1,x2), (x3, x4), (x5, x6) 등이다. 우리는 2D 공간에서 원을 중심으로 회전하기 때문에 쌍으로 다루는 것이다 단순화를 위해, 첫 번째 쌍 (x1,x2) 에 초점을 맞춰 보자. 단어 “fox”는 우리 문장에서 위치 3에 나타나므로, RoPE는 이 첫 번째 차원 쌍을 다음으로 회전시킬 것이다:

rotation_angle = position × θ₀
                = 3 × (1/10000^(0/32))
                = 3 × 1.0
                = 3.0 radians
                = 172° degrees

우리의 기본 주파수는 10000이지만, 첫 번째 차원 쌍 (k=0)의 경우 우리의 지수는 0이므로 기본 주파수는 계산에 영향을 미치지 않는다 (우리는 0제곱을 한다). 아래 시각화는 이것을 보여준다:

스크린샷 2025-12-05 오후 4.52.40.png

이제 두 토큰이 어텐션을 통해 상호 작용할 때 마법이 발생한다. 그들의 회전된 표현 간의 내적은 그들의 회전 각도 간의 위상차를 통해 그들의 상대 거리를 직접 인코딩하게 된다. (여기서 m 과 n은 토큰 위치이다)

dot_product(RoPE(x, m), RoPE(y, n)) = Σₖ [xₖ * yₖ * cos((m-n) * θₖ)]

어텐션 패턴은 (m - n)에만 의존하므로, 5 위치 떨어진 토큰은 시퀀스 내 그들의 절대 위치와 관계없이 항상 동일한 각도 관계를 가질 것이다. 따라서 모델은 시퀀스 내 어느 절대 위치에서든 작동하고 더 긴 시퀀스로 추정할 수 있는 거리 기반 패턴을 학습하게 된다.

RoPE 주파수를 설정하는 방법?

실제 상황에서는, 대부분의 LLM 사전 학습은 10K 또는 50K와 같은 수만 단위의 RoPE 기본 주파수를 사용하여 상대적으로 짧은 컨텍스트 길이 (2K-4K 토큰)로 시작한다. 처음부터 매우 긴 시퀀스로 학습하는 것은 어텐션의 시퀀스 길이에 대한 2차 확장과 이전에 문서 마스킹 섹션에서 보았듯이 긴 컨텍스트 데이터 (4K 이상의 샘플)의 제한된 가용성으로 인해 계산 비용이 많이 들 것이다. 연구는 또한 짧은 컨텍스트 성능을 해칠 수 있음을 시사한다 (Zhu et al., 2025). 모델은 일반적으로 단어 간의 단거리 상관관계를 학습하는 것으로 시작하므로 긴 시퀀스는 크게 도움이 되지 않는다. 일반적인 접근 방식은 더 짧은 시퀀스로 대부분의 사전 학습을 수행한 다음, 지속적인 사전 학습을 하거나 최종 수천억 토큰을 더 긴 시퀀스에 소비하는 것이다. 그러나 시퀀스 길이가 증가함에 따라, 토큰 위치에 비례하는 회전 각도가 증가하고, 이는 먼 토큰에 대한 어텐션 점수가 너무 빠르게 감쇠하도록 유발할 수 있다 (Rozière et al., 2024; Xiong et al., 2023):

θ = position x 1 / (base^(k/(dim/2)))

해결책은 ABF 및 YaRN과 같은 방법을 사용하여 시퀀스 길이가 증가함에 따라 기본 주파수를 증가시켜 그러한 감쇠를 방지하는 것이다.

RoPE ABF (RoPE with Adjusted Base Frequency) (Xiong et al., 2023b): RoPE 공식에서 기본 주파수를 증가시켜 긴 컨텍스트에서의 어텐션 감쇠 문제를 해결한다. 이 조정은 토큰 위치 간의 회전 각도를 늦추어 먼 토큰의 어텐션 점수가 너무 빠르게 감쇠하는 것을 방지한다. ABF는 단일 단계 (직접적인 주파수 부스트) 또는 다단계 (컨텍스트가 증가함에 따라 점진적 증가)로 적용될 수 있다. 이 방법은 구현이 간단하며, 임베디드 벡터를 증가된 세분성으로 분산시켜 모델이 먼 위치를 더 쉽게 구별할 수 있도록 한다. 간단하고 효과적이지만, ABF의 모든 차원에 걸친 균일한 스케일링은 극도로 긴 컨텍스트에는 최적이 아닐 수 있다.

YaRN (Yet another RoPE extensioN) (Peng et al., 2023): 램프 또는 스케일링 함수를 사용하여 RoPE 차원에 걸쳐 주파수를 불균일하게 보간하는 더 정교한 접근 방식을 취한다. ABF의 균일한 조정과 달리, YaRN은 다른 주파수 구성 요소에 다른 스케일링 계수를 적용하여 확장된 컨텍스트 창을 최적화한다. 이는 동적 어텐션 스케일링 및 어텐션 로짓에서의 온도 조정과 같은 추가 기술을 포함하며, 이는 매우 큰 컨텍스트 크기에서 성능을 보존하는 데 도움이 된다. YaRN은 강력한 추정을 위해 더 적은 토큰과 더 적은 파인 튜닝을 요구하는 효율적인 “짧게 학습하고 길게 테스트하는” 전략을 가능하게 한다. ABF보다 더 복잡하지만, YaRN은 일반적으로 더 부드러운 스케일링을 제공하고 치명적인 어텐션 손실을 완화함으로써 극도로 긴 컨텍스트에 대해 더 나은 경험적 성능을 제공한다. 이는 파인 튜닝 없이도 추론 단독으로 활용될 수도 있다.

이러한 주파수 조정 방법들은 어텐션 점수 감쇠 효과를 늦추고 먼 토큰의 기여를 유지한다. 예를 들어, Qwen3의 학습은 시퀀스 길이가 4k 컨텍스트에서 32k로 확장됨에 따라 ABF를 사용하여 주파수를 10k에서 1M으로 증가시키는 것을 포함했다 (팀은 그 후 YaRN을 적용하여 131k, 4배 추정에 도달한다). 최적 값에 대한 강력한 합의는 없으며, 일반적으로 컨텍스트 확장 단계에서 다른 RoPE 값을 실험하여 특정 설정 및 평가 벤치마크에 가장 적합한 것을 찾는 것이 좋다.

오늘날 대부분의 주요 모델은 RoPE를 사용한다: Llama, Qwen, Gemma, 그리고 다른 많은 모델들이 그렇다. 이 기술은 다른 모델 크기와 아키텍처 (밀집형, MoE, 하이브리드)에 걸쳐 Robust 하다는 것이 입증되었다. 최근에 나타난 몇 가지 RoPE 변형을 더 살펴보자.

하이브리드 위치 인코딩 접근 방식

모델이 점점 더 큰 컨텍스트로 나아감에 따라 (Meta AI, 2025; Yang et al., 2025), RoPE조차도 성능 문제에 부딪히기 시작했다. 긴 컨텍스트 확장 중 RoPE의 주파수를 증가시키는 표준 접근 방식은 Needle in the Haystack (NIAH) (Kamradt, 2023)보다 더 도전적인 Ruler 및 HELMET (Hsieh et al., 2024; Yen et al., 2025)과 같은 긴 컨텍스트 벤치마크에서 평가될 때 한계가 있다. 여기에 도움이 되는 새로운 기술들이 도입되었다.

우리는 트랜스포머가 토큰 순서를 이해하기 위해 위치 정보가 필요하다고 말함으로써 이 섹션을 시작했지만, 최근 연구는 이 가정에 도전하고 있다. 명시적인 위치 인코딩이 결국 필요하지 않다면 어떨까?

NoPE (No Position Embedding) (Kazemnejad et al., 2023)는 명시적인 위치 인코딩 없이 트랜스포머를 학습시켜, 모델이 인과적 마스킹 및 어텐션 패턴을 통해 위치 정보를 암시적으로 학습할 수 있도록 한다. 저자들은 이 접근 방식이 ALiBi 및 RoPE에 비해 더 나은 길이 일반화를 보여준다는 것을 보여준다. 학습 길이를 넘어 외삽(extrapolate) 하기 위한 명시적인 위치 인코딩 없이, NoPE는 자연스럽게 더 긴 컨텍스트를 처리한다. 하지만 실제로는, NoPE 모델은 RoPE에 비해 짧은 컨텍스트 추론 및 지식 작업에서 더 약한 성능을 보이는 경향이 있다 (Yang et al.). 이것은 명시적인 위치 인코딩이 외삽을 제한할 수 있지만, 학습 컨텍스트 길이 내의 작업에 유용한 귀납적 편향을 제공함을 시사한다.

RNoPE 하이브리드 접근 방식: 이러한 장단점을 고려할 때; B. Yang et al. (2025)은 다른 위치 인코딩 전략을 결합하는 것이 흥미로울 수 있다고 제안한다. 그들은 모델 전체에 걸쳐 RoPE 레이어와 NoPE 레이어를 번갈아 사용하는 RNoPE를 도입한다. RoPE 레이어는 명시적인 위치 정보를 제공하고 최근성 편향을 가진 로컬 컨텍스트를 처리하는 반면, NoPE 레이어는 긴 거리에 걸친 정보 검색을 개선한다. 이 기술은 최근 Llama4, Command A 및 SmolLM3에서 사용되었다.

📍명명 규칙

나머지 이 블로그에서는 단순화를 위해 RNoPE를 “NoPE”라고 부를 것이다. (당신은 토론에서 사람들이 RNoPE를 의미하기 위해 “NoPE”를 사용하는 것을 종종 보게 될 것이다).

제거 실험 - NoPE는 짧은 컨텍스트에서 RoPE와 일치한다

하이브리드 NoPE 접근 방식을 테스트한다. 우리는 순수 RoPE 1B 제거 실험 기준선과 4번째 레이어마다 위치 인코딩을 제거하는 NoPE 변형, 그리고 이러한 기술 간의 상호 작용을 테스트하기 위해 NoPE와 문서 마스킹을 결합한 세 번째 설정을 비교할 것이다. 우리의 기본 질문은 다음과 같다: 더 나은 긴 컨텍스트 기능을 얻으면서 강력한 짧은 컨텍스트 성능을 유지할 수 있는가?

스크린샷 2025-12-05 오후 4.52.54.png

스크린샷 2025-12-05 오후 4.53.07.png

손실 및 평가 결과는 세 가지 구성 모두에서 유사한 성능을 보여주며, NoPE가 더 나은 긴 컨텍스트 처리를 위한 기반을 제공하는 동시에 강력한 짧은 컨텍스트 기능을 유지함을 나타낸다. 이러한 결과를 바탕으로, 우리는 SmolLM3에 NoPE + 문서 마스킹 조합을 채택했다.

Partial/Fractional RoPE: 또 다른 보완적인 아이디어는 모델 차원의 일부에만 RoPE를 적용하는 것이다. 전체 레이어를 RoPE와 NoPE 사이에 번갈아 사용하는 RNoPE와 달리, Partial RoPE는 동일한 레이어 내에서 그것들을 혼합한다. GLM‑4.5 (5 Team et al., 2025) 또는 Minimax-01 (MiniMax et al., 2025)과 같은 최근 모델들이 이 전략을 채택하지만, 이것은 gpt-j (Wang & Komatsuzaki, 2021)와 같은 더 오래된 모델에도 존재했다. 합리적인 추론 비용을 갖기 위해 필수적이기 때문에 MLA를 사용하는 모든 모델에서 이것을 보게 될 것이다.

🔧기술적 설명: Partial RoPE가 MLA에 필수적인 이유

MLA는 투영 흡수(projection absorption)로 추론을 효율적으로 만든다: 헤드별 키 $k_i^{(h)}$ 를 저장하는 대신, 작은 공유 latent $c_i = x_i W_c ∈ R^{d_c}$ 를 캐시하고 헤드의 쿼리/키 맵을 병합하여 각 점수가 저렴해지도록 한다. $q_t^{(h)} = x_t W_q^{(h)}$ 및 $k_i^{(h)} = c_i E^{(h)}$ 를 사용하여 $U^{(h)} = W_q^{(h)} E^{(h)}$ 를 정의하면 다음을 얻는다:

s_(t,i)^{(h)} = \frac{1}{\sqrt{(d_k)}} (q_t^{(h)})^⊤ k_i^{(h)} = \frac{1}{\sqrt{(d_k)}} (x_t U^{(h)})^⊤ c_i

따라서 작은 캐시 $c_i$ 에 대해 $q̃_t^{(h)} = x_t U^{(h)} ∈ R^{d_c}$ 로 계산할 수 있다 (헤드별 k 는 저장되지 않음). 하지만 RoPE는 두 맵 사이에 쌍 의존적 회전을 삽입하기 때문에 이것을 깨뜨린다: 전체 차원 RoPE를 사용하면,

s_{t,i}^{(h)} = \frac{1}{\sqrt{(d_k)}} (x_t W_q^{(h)})^⊤ R_{t-i} (c_i E^{(h)})

인데, $R_{t-i}$ 가 t-i 에 의존한다. 따라서 $W_q^{(h)}$ 와 $E^{(h)}$ 를 고정된 $U^{(h)}$ 로 미리 병합할 수 없다. 해결책이 Partial RoPE이다. 헤드 차원 $d_k = d_{nope} + d_{rope}$ 를 분할하고, 큰 블록에는 회전을 적용하지 않고 (이전과 같이 흡수: $(x_t U_{nope}^{(h)})^⊤ c_i$ ) 작은 블록에만 RoPE를 적용한다.

긴 컨텍스트에 대한 어텐션 범위 제한

지금까지 우리는 긴 컨텍스트에 대한 위치 정보를 처리하는 방법: RoPE 활성화, 비활성화 (NoPE), 일부 레이어에 부분적으로 적용 (RNoPE) 또는 일부 은닉 차원에 적용 (Partial RoPE), 또는 그 주파수 조정 (ABF, YaRN)을 탐색했다. 이러한 접근 방식들은 모델이 학습 중에 본 것보다 더 긴 시퀀스를 처리하기 위해 위치를 인코딩하는 방식을 수정한다. 그러나 보완적인 전략이 있다: 위치 인코딩을 조정하는 대신, 서로에게 어텐션하는 토큰을 제한할 수 있다.

이것이 왜 중요한지 보기 위해, 8개의 토큰 시퀀스로 사전 학습된 모델을 고려해보자. 추론 시, 우리는 16개의 토큰을 처리하고자 한다 (학습 길이보다 길다). 위치 8-15는 모델의 위치 인코딩에 대해 분포를 벗어난다. RoPE ABF와 같은 기술이 위치 주파수를 조정하여 이를 해결하는 반면, 어텐션 범위 기반 방법은 다른 접근 방식을 취한다: 그들은 전략적으로 서로에게 어텐션할 수 있는 토큰을 제한하여, 전체 시퀀스를 처리하면서도 어텐션 패턴을 익숙한 범위 내로 유지한다. 이것은 계산 비용과 메모리 요구 사항을 모두 줄인다. 아래 다이어그램은 8의 사전 학습 창을 가진 우리의 16 토큰 시퀀스를 처리하기 위한 다섯 가지 전략을 비교한다:

스크린샷 2025-12-05 오후 4.54.15.png

스크린샷 2025-12-05 오후 4.53.26.png

**청크형 어텐션(Chunked Attention)**은 시퀀스를 고정 크기 청크로 나누며, 토큰은 그들의 청크 내에서만 어텐션할 수 있다. 우리 예시에서, 16개의 토큰은 두 개의 8 토큰 청크 (0에서 7, 8에서 15)로 분할되며, 각 토큰은 자신의 청크 내의 다른 토큰만 볼 수 있다. 토큰 8에서 15가 이전 청크에 전혀 어텐션할 수 없음에 주목한다. 이것은 청크 경계에서 재설정되는 고립된 어텐션 창을 만든다. Llama 4 (Meta AI, 2025)는 RoPE 레이어 (4개의 디코더 레이어 중 3개)에서 8192 토큰 청크로 청크형 어텐션을 사용하는 반면, NoPE 레이어는 전체 컨텍스트 접근을 유지한다. 이것은 레이어당 KV 캐시 크기를 제한하여 메모리 요구 사항을 줄이지만, 토큰이 이전 청크에 어텐션할 수 없음을 의미하며, 이는 일부 긴 컨텍스트 작업에 영향을 미칠 수 있다.

스크린샷 2025-12-05 오후 4.53.37.png

**슬라이딩 창 어텐션(Sliding Window Attention, SWA)**은 Mistral 7B (Child et al., 2019; Jiang et al., 2023)에 의해 대중화되었으며, 가장 최근 토큰이 가장 관련성이 높다는 직관을 기반으로 다른 접근 방식을 취한다. 하드 청크 경계 대신, 각 토큰은 가장 최근 N개의 토큰에만 어텐션한다. 다이어그램에서, 모든 토큰은 8개 위치 뒤까지 볼 수 있으며, 시퀀스 전체에 걸쳐 연속적으로 이동하는 슬라이딩 창을 만든다. 토큰 15는 위치 8에서 15까지 어텐션할 수 있는 반면, 토큰 10은 위치 3에서 10까지 어텐션한다. 창은 앞으로 미끄러지며, 청킹의 인공적인 장벽 없이 전체 시퀀스에 걸쳐 로컬 컨텍스트를 유지한다. Gemma 3은 하이브리드 위치 인코딩 접근 방식이 다른 전략을 혼합하는 방식과 유사하게, SWA를 전체 어텐션과 번갈아 가며 사용한다.

스크린샷 2025-12-05 오후 4.53.50.png

듀얼 청크 어텐션(Dual Chunk Attention, DCA) (An et al., 2024)은 청크 간 정보 흐름을 유지하면서 청크형 어텐션을 확장하는 학습 없는 방법이다. 우리 예시에서, 우리는 청크 크기 s=4 를 사용하며, 16개의 토큰을 4개의 청크로 나눈다 (대각선을 따라 4x4 사각형을 시각화한다). DCA는 세 가지 메커니즘을 결합한다: (1) 토큰이 그들의 청크 내에서 정상적으로 어텐션하는 청크 내 어텐션 (대각선 패턴). (2) 쿼리가 이전 청크에 어텐션하기 위해 위치 인덱스 c−1=7 을 사용, 상대 위치는 7로 제한되는 청크 간 어텐션 (3) 이웃 청크 간의 지역성을 보존하는 로컬 창 w=3 을 가진 연속 청크 어텐션. 이것은 모든 상대 위치를 학습 분포 (0에서 7) 내로 유지하면서 청크 경계 전반에 걸쳐 부드러운 전환을 유지한다. DCA는 Qwen2.5와 같은 모델이 백만 토큰 시퀀스에 대한 지속적인 학습을 요구하지 않고도 추론 시 최대 100만 토큰의 초장기 컨텍스트 창을 지원할 수 있도록 만들었다.

📊어텐션 싱크

트랜스포머 모델에서 긴 컨텍스트로 흥미로운 현상이 나타난다: 모델은 의미론적으로 중요하지 않은 경우에도 시퀀스의 초기 토큰에 비정상적으로 높은 어텐션 점수를 할당한다. 이 동작을 **어텐션 싱크(attention sinks)**라고 부른다 (Xiao et al.). 이 초기 토큰은 어텐션 분포에 대한 안정화 메커니즘 역할을 하며, 어텐션이 축적될 수 있는 “싱크” 역할을 한다.

이로부터의 실용 측면에서의 통찰은 컨텍스트가 캐시 크기를 초과할 때, 가장 최근 토큰의 슬라이딩 창과 함께 단지 초기 몇 개의 토큰의 KV 캐시를 유지하는 것이 성능을 크게 회복할 수 있다는 것이다. 이 간단한 수정은 모델이 파인 튜닝이나 성능 저하 없이 훨씬 더 긴 시퀀스를 처리할 수 있도록 한다.

현대적인 구현은 어텐션 싱크를 다른 방식으로 활용한다. 원래 연구는 명시적인 어텐션 싱크 역할을 하는 전용 플레이스홀더 토큰을 사전 학습 중에 추가할 것을 제안한다. 더 최근에, gpt-oss와 같은 모델은 입력 시퀀스의 실제 토큰 대신 어텐션 점수에 추가되는 학습된 헤드별 편향 로짓으로 어텐션 싱크를 구현한다. 이 접근 방식은 토큰화된 입력을 수정하지 않고도 동일한 안정화 효과를 달성한다.

흥미롭게도, gpt-oss는 또한 어텐션 레이어 자체에 편향 유닛을 사용하는데, 이는 GPT-2 이후 거의 볼 수 없는 설계 선택이다. 이러한 편향 유닛은 일반적으로 표준 어텐션 작업에 대해 불필요하다고 간주되지만 (Dehghani et al.의 경험적 결과는 테스트 손실에 미미한 영향을 보여준다), 어텐션 싱크를 구현하는 전문화된 기능을 수행할 수 있다. 여기서의 핵심 통찰은: 특수 토큰, 학습된 편향, 또는 헤드별 로짓으로 구현되든, 어텐션 싱크는 긴 컨텍스트 시나리오에서 어텐션 분포를 위한 안정적인 “앵커”를 제공하여, 컨텍스트가 임의로 길어지더라도 모델이 전체 시퀀스에 대한 일반적으로 유용한 정보를 저장할 수 있도록 한다는 것이다.

이제 우리는 어텐션의 핵심 구성 요소들을 다루었다: 메모리와 컴퓨팅의 균형을 맞추는 다른 헤드 구성 (MHA, GQA, MLA), 모델이 토큰 순서를 이해하는 데 도움이 되는 위치 인코딩 전략 (RoPE, NoPE, 그리고 그들의 변형), 그리고 긴 컨텍스트를 다루기 쉽게 만드는 어텐션 범위 기술 (슬라이딩 창, 청킹, 그리고 어텐션 싱크)이다. 우리는 또한 임베딩 레이어가 어떻게 구성되고 초기화되어야 하는지 검토했다. 이러한 아키텍처 선택은 모델이 시퀀스를 처리하고 표현하는 방식을 정의한다.

그러나 올바른 아키텍처를 갖는 것은 전쟁의 절반에 불과하다. 잘 설계된 모델조차도 특히 대규모에서 학습 불안정성으로 고통받을 수 있다. 학습을 안정적으로 유지하는 데 도움이 되는 기술들을 살펴보자.

안정성 개선

이제 LLM 사전 학습에서 가장 큰 도전 과제 중 하나인 불안정성으로 넘어가자. 종종 손실 급등(loss spikes)이나 학습 손실의 급격한 점프로 나타나는 이러한 문제들은 대규모에서 특히 흔해진다.

우리는 학습 마라톤 섹션에서 다양한 유형의 급등과 그것들을 처리하는 방법에 대해 더 깊이 다룰 것이지만 (부동 소수점 정밀도, 옵티마이저, 학습률에 대해 자세히 다룬다), 특정 아키텍처 및 학습 기술도 불안정성을 줄이는 데 도움이 될 수 있으므로 여기서 잠시 그것들을 살펴본다. 우리는 안정성을 개선하기 위해 최근 대규모 학습 실행에서 사용된 몇 가지 간단한 기술 (예: Olmo2 (OLMo et al., 2025) 및 Qwen3 (A. Yang, Li, et al., 2025))을 다룰 것이다: Z-손실, 임베딩에서 가중치 감쇠 제거, 및 QK-정규화이다.

Z-손실 (Z-loss)

Z-손실 (Chowdhery et al., 2022)은 손실 함수에 페널티 항을 추가하여 최종 출력 로짓이 너무 커지는 것을 방지하는 정규화 기술이다. 이 정규화는 로짓에 대한 소프트맥스의 분모가 합리적인 범위 내에 머무르도록 장려하며, 이는 학습 중 수치적 안정성을 유지하는 데 도움이 된다.

L_{z-loss}=λ⋅{log}^{⁡2}(Z)

스크린샷 2025-12-05 오후 4.54.30.png

스크린샷 2025-12-05 오후 4.54.42.png

우리의 1B 모델에 대한 아래 제거 실험 결과는 Z-손실을 추가하는 것이 학습 손실이나 다운스트림 성능에 영향을 미치지 않는다는 것을 보여준다. SmolLM3의 경우, Z-손실 구현이 도입이 우리가 학습을 시작할 때까지 최적화하지 못한 학습 오버헤드를 발생시켰기 때문에 결국 그것을 사용하지 않았다.

임베딩에서 가중치 감쇠 제거

가중치 감쇠는 일반적으로 정규화 기술로 모든 모델 매개변수에 적용되지만, OLMo et al. (2025)은 임베딩을 가중치 감쇠에서 제외하는 것이 학습 안정성을 개선한다는 것을 발견했다. 그 이유는 가중치 감쇠가 학습 중에 임베딩 노름을 점진적으로 감소시키는데, 이는 레이어 정규화의 야코비 행렬이 입력 노름에 반비례하므로 초기 레이어에서 더 큰 기울기(gradients)로 이어질 수 있기 때문이다 (Takase et al., 2025).

우리는 세 가지 구성을 학습시켜 이 접근 방식을 테스트했다: 표준 가중치 감쇠를 가진 우리의 기준선, 임베딩에 가중치 감쇠가 없는 변형, 그리고 기술 간의 부정적인 상호 작용이 없는지 확인하기 위해 채택된 모든 변경 사항 (임베딩에 가중치 감쇠 없음 + NoPE + 문서 마스킹)을 결합한 세 번째 구성이다. 손실 곡선과 평가 결과는 세 가지 구성 모두에서 거의 동일했다. 그래서 우리는 SmolLM3 학습에서 3가지 변경 사항 모두를 채택했다.

스크린샷 2025-12-05 오후 4.54.56.png

스크린샷 2025-12-05 오후 4.55.06.png

QK-정규화 (QK-norm)

QK-정규화 (Dehghani et al., 2023)는 어텐션을 계산하기 전에 쿼리 및 키 벡터 모두에 레이어 정규화를 적용한다. 이 기술은 어텐션 로짓이 너무 커지는 것을 방지하는 데 도움이 되며, 안정성을 개선하기 위해 많은 최신 모델에서 사용되었다.

그러나 B. Yang et al. (2025)은 QK-정규화가 긴 컨텍스트 작업을 해친다는 것을 발견했다. 그들의 분석은 QK-정규화가 관련 토큰 (바늘, needles)에 대한 더 낮은 어텐션 질량과 관련 없는 컨텍스트에 대한 더 높은 어텐션 질량을 초래한다는 것을 밝혀냈다. 그들은 정규화 작업이 쿼리-키 내적에서 크기 정보를 제거하여 어텐션 로짓의 크기의 측면에서 더 가까워지기 때문에 이러한 현상이 발생한다고 주장했다. 이러한 이유로, 우리는 SmolLM3에서 QK-정규화를 사용하지 않았다. 추가적으로, 우리가 학습할 모델은 3B 매개변수의 작은 모델로서, QK-정규화가 가장 유익하다는 것이 입증된 더 큰 모델들에 비해 학습 불안정성의 위험이 적었다.

다른 핵심 구성 요소

우리가 다룬 구성 요소들 외에도, 완벽함을 위해 주목할 가치가 있는 몇 가지 다른 아키텍처 결정들이 있다.

매개변수를 초기화할 때, 현대 모델들은 일반적으로 절단 정규 초기화(truncated normal initialization) (평균=0, std=0.02 또는 std=0.006) 또는 muP 와 같은 초기화 방식(G. Yang & Hu, 2022)을 사용한다. 예를 들어, Cohere의 Command A (Cohere et al., 2025)가 그렇다. 이것은 제거 실험의 또 다른 주제가 될 수 있다.

활성화 함수 측면에서, SwiGLU는 현대 LLM에서 사실상의 표준이 되었다 (GeGLU를 사용하는 Gemma2, relu^2 를 사용하는 Nvidia를 제외하고 (Nvidia et al., 2024; NVIDIA et al., 2025)). 이는 ReLU 또는 GELU와 같은 이전 선택을 대체했다.

더 넓은 규모에서, 아키텍처 레이아웃 선택 또한 모델 동작을 형성하는 데 역할을 한다. 총 매개변수 수가 언어 모델의 능력을 크게 결정하지만, 그 매개변수들이 깊이와 너비에 걸쳐 어떻게 분포되는지도 중요하다. Petty et al. (2024)은 이점이 포화될 때까지 더 깊은 모델이 언어 모델링 및 합성 작업에서 동일한 크기의 더 넓은 모델보다 우수한 성능을 보인다는 것을 발견했다. 이 “깊고 얇은(deep-and-thin)” 전략은 MobileLLM 제거 실험에서 수십억 매개변수 미만의 LLM에 대해 잘 작동하는 반면 (Z. Liu et al., 2024), 더 넓은 모델은 더 큰 병렬 처리 덕분에 더 빠른 추론을 제공하는 경향이 있다. 현대 아키텍처들은 이 블로그 게시물 (https://sebastianraschka.com/blog/2025/the-big-llm-architecture-comparison.html) 에 언급된 대로 이 트레이드오프를 다르게 반영하고 있다.

우리는 이제 당신의 학습 실행을 위해 최적화할 가치가 있는 Dense 트랜스포머 아키텍처의 가장 중요한 측면들을 다루었다. 그러나 최근에는 모델 전체와 관련된 다른 아키텍처 개입, 즉 MoE 및 하이브리드 모델이 등장했다. MoE부터 시작하여, 그것들이 무엇을 제공하는지 살펴보자.

희소화로 가기: MoE (Mixture-of-Experts)

전문가 혼합(Mixture-of-Experts, MoE) 의 직관은 우리의 뇌가 당면한 작업에 따라 다른 영역 (예: 시각 또는 운동 피질)을 활성화하는 방식과 유사하게, 모든 토큰 예측에 전체 모델이 필요하지 않다는 것이다. LLM의 경우 이는 모델이 번역 작업을 수행할 때 코딩 구문에 대해 학습한 부분이 사용될 필요가 없음을 의미할 수 있다. 우리가 이것을 잘 할 수 있다면, 추론 시 전체 모델의 일부만 실행하면 되므로 많은 컴퓨팅 자원을 절약할 수 있음을 의미한다.

기술적인 수준에서 MoE는 간단한 목표를 가진다: 각 토큰에 대한 “활성” 매개변수 수를 늘리지 않으면서 총 매개변수를 늘린다. 다소 단순화하면 총 매개변수는 모델의 전체 학습 능력에 영향을 미치는 반면, 활성 매개변수는 학습 비용 및 추론 속도를 결정한다. 이것이 오늘날 많은 선도적인 시스템 (예: DeepSeek V3, K2, 그리고 Gemini, Grok와 같은 폐쇄형 모델…)이 MoE 아키텍처를 사용하는 이유이다. Ling 1.5 논문 (L. Team et al., 2025)의 이 플롯은 MoE와 Dense 모델의 스케일링 법칙을 비교한다:

만약 당신이 MoE를 처음 접하는 경우에도, 메커니즘은 복잡하지 않으니 걱정하지 않아도 좋다. 표준 Dense 아키텍처부터 시작하여 MoE에 필요한 변경 사항을 살펴보자 (Sebastian Raschka의 그림):

MoE를 사용하면, 단일 MLP를 여러 MLP(“전문가”)로 대체하고 MLP 앞에 학습 가능한 라우터(router)를 추가한다. 각 토큰에 대해 라우터는 실행할 전문가의 작은 부분집합을 선택한다. 총 매개변수와 활성 매개변수 간의 구분이 여기서 비롯된다: 모델은 많은 전문가를 가지고 있지만, 주어진 토큰은 일부만 사용한다.

MoE 레이어 설계는 몇 가지 핵심 질문을 제기한다:

전문가 형태 및 희소성: 많은 수의 작은 전문가를 사용해야 하는가 아니면 더 적은 수의 큰 전문가를 사용해야 하는가? 토큰당 몇 명의 전문가가 활성되어야 하는가, 총 몇 명의 전문가가 필요한가 (즉, 희소성 또는 “top-k”)? 일부 전문가는 보편적(universal)이어야 하므로 항상 활성되어야 하는가?
활용 및 전문화: 라우팅된 전문가를 어떻게 선택하고, 그들이 전문화되도록 장려하면서도 잘 사용되도록 (유휴 용량 방지) 유지하는가? 실제에서 이것은 로드 밸런싱 문제이며 학습 및 추론 효율성에 상당한 영향을 미친다.

여기서 우리는 하나의 목표에 초점을 맞춘다: 고정된 컴퓨팅 예산이 주어졌을 때, 손실을 최소화하는 MoE 구성을 어떻게 선택할까? 이것은 순수한 시스템 효율성 (처리량/지연 시간)과는 다른 질문이며, 우리는 나중에 그것으로 돌아올 것이다. 이 섹션의 대부분은 Ant Group의 MoE 스케일링 법칙 논문 (Tian et al., 2025)의 분석을 따른다.

우리는 그들의 효율성 레버리지(Efficiency Leverage, EL) 개념을 사용할 것이다. 간단히 말해, EL은 FLOPs를 측정 단위로 하여 MoE 설계로 달성된 손실과 일치하는 데 필요한 dense 컴퓨팅의 양을 측정한다. 더 높은 EL은 MoE 구성이 Dense 학습에 비해 컴퓨팅 단위당 더 많은 손실 개선을 제공함을 의미한다.

스크린샷 2025-12-05 오후 4.55.23.png

MoE의 희소성을 설정하여 효율성 레버리지를 어떻게 개선할 수 있는지 더 자세히 살펴보자.

희소성 / 활성화 비율

요약: 희소성이 높을수록 → FLOPs 효율성이 좋아진다 → 매우 높은 희소성에서는 점진적 이득 감소 → 최적점은 컴퓨팅 예산에 따라 달라진다.

이 섹션에서 우리는 어떤 MoE 설정이 최고인지 알아내고자 한다. 점근적으로 두 극단은 이상적인 설정이 아니라는 것을 쉽게 알 수 있다. 한쪽 극단의 경우는, 항상 모든 전문가를 활성화하는 것인데 이는 모든 매개변수가 항상 사용되는 Dense 설정으로 우리를 되돌린다. 다른 방향의 극단은, 활성 매개변수가 매우 낮다면 (극단적으로 활성 매개변수가 1개뿐이라고 생각한다) 좁은 도메인에서도 작업을 해결하기에 충분하지 않을 것이 분명하다. 따라서 우리는 명확히 중간 지점을 찾아야 한다. 최적의 설정을 찾는 데 더 깊이 들어가기 전에 두 가지 양을 정의하는 것이 유용하다: **활성화 비율(activation ratio)**과 그 역수인 **희소성(sparsity)**이다:

활성화 비율 = \frac{\#활성된 \space 전문가}{\#총 전문가}

희소성 = \frac{\#총 전문가}{\#활성된 \space 전문가} = \frac{1}{활성화 비율}

컴퓨팅 관점에서 비용은 활성 매개변수만으로 결정된다. 활성 전문가의 수(및 크기)를 고정하고 총 전문가 수를 늘리면, 추론/학습 FLOPs 예산은 다소 동일하게 유지되지만, 모델 능력을 추가하는 것이므로 충분히 오래 학습한다면 모델이 일반적으로 더 좋아져야 한다.

최근 MoE 논문을 조사하면 몇 가지 흥미로운 경험적 시사점이 있다: 활성 전문가의 수와 크기를 고정한 채, 총 전문가 수를 늘리면 (즉, 활성화 비율을 낮추고 / 희소성을 높이면) 손실이 개선되지만, 희소성이 매우 높아지면 점진적으로 이득이 감소한다.

두 가지 예시가 있다:

Kimi K2 플롯 (K. Team et al., 2025): 두 가지 효과를 모두 보여준다: 희소성이 높을수록 성능이 향상되지만, 희소성이 증가함에 따라 이득이 줄어든다.
Ant Group 플롯 (Tian et al., 2025): K2와 동일한 결론이며, 더 높은 희소성 MoE가 컴퓨팅 증가로부터 더 많은 이점을 얻는다는 추가 결과가 있다.

다음은 일부 MoE 모델의 희소성을 나타내는 표이다:

모델	총 전문가 수	토큰당 활성 전문가 수 (공유 전문가 포함)	희소성
Mixtral-8×7B	8	2	4.0
Grok-1	8	2	4.0
Grok-2	8	2	4.0
OLMoE-1B-7B-0924	64	8	8.0
gpt-oss 20b	32	4	8
Step-3	라우팅된 48 + 공유 1 = 49	라우팅된 3 + 공유 1 = 4	12.25
GLM-4.5-Air	라우팅된 128 + 공유 1 = 129	라우팅된 8 + 공유 1 = 9	14.3
Qwen3-30B-A3B	128	8	16.0
Qwen3-235B-A22B	128	8	16.0
GLM-4.5	라우팅된 160 + 공유 1 = 161	라우팅된 8 + 공유 1 = 9	17.8
DeepSeek-V2	라우팅된 160 + 공유 2 = 162	라우팅된 6 + 공유 2 = 8	20.25
DeepSeek-V3	라우팅된 256 + 공유 1 = 257	라우팅된 8 + 공유 1 = 9	28.6
gpt-oss 120b	128	4	32
Kimi K2	라우팅된 384 + 공유 1 = 385	라우팅된 8 + 공유 1 = 9	42.8
Qwen3-Next-80B-A3B-Instruct	라우팅된 512 + 공유 1 = 513	총 활성 10 + 공유 1 = 11	46.6

최근 추세는 명확하다: MoE 모델은 더 희소해지고 있다. 그렇긴 하지만, 최적의 희소성은 여전히 하드웨어와 종단 간 효율성에 따라 달라진다. 예를 들어, Step-3은 최고 효율성을 목표로 하며, 특정 하드웨어 및 대역폭 제약 조건에 맞추기 위해 의도적으로 희소성을 최대화하지 않는 반면, gpt-oss-20b는 온디바이스 메모리 제약 조건으로 인해 낮은 희소성을 가진다 (수동 전문가도 여전히 일부 메모리를 차지한다).

세분성 (Granularity)

희소성을 넘어, 각 전문가가 얼마나 커야 하는지 결정해야 한다. 이것은 Ant Group이 도입한 측정 기준인 세분성(Granularity) 으로 표현된다. 이 용어로 우리가 의미하는 바를 정확히 짚어보자. 용어는 논문마다 다르며, 일부는 약간 다른 공식을 사용한다. 여기서는 우리가 참조하는 플롯과 일치하는 정의를 사용할 것이다:

G=\frac{α×d_{model}}{d_{expert}} \space with \space α=2 \space or \space 4

더 높은 세분성 값은 더 작은 차원을 가진 더 많은 전문가를 갖는 것에 해당한다 (고정된 매개변수 수가 주어진 경우). 이 측정 기준은 전문가 차원 (d_expert)과 모델 차원 (d_model) 간의 비율이다.

밀집형 모델에서 일반적인 경험 법칙은 MLP의 차원을 $d_{intermediate}=4×d_{model}$ 로 설정하는 것이다.

α=4 인 경우 (Krajewski et al. (2024)와 같이). 당신은은 세분성을 밀집형 MLP 너비와 일치하는 데 필요한 전문가 수로 느슨하게 볼 수 있다 ( $4d_{model}=d_{intermediate}=Gd_{expert}$ ).

이 해석은 대략적인 발견적 방법일 뿐이다: 현대 MoE 설계는 단일 밀집형 MLP보다 훨씬 더 큰 총 능력을 할당하는 경우가 많으므로, 일대일 일치는 실제 상황에서 무너진다. Ant 팀 설정은 α=2 를 선택하는데, 이는 단순히 다른 정규화 선택이다. 일관성을 위해 우리는 이 관례를 따를 것이다.

다음은 일부 MoE 릴리스에 대한 다른 값을 가진 표이다:

모델	`d_model`	`d_expert`	`G=2d_model/d_expert`	연도
Mixtral-8×7B	4,096	14,336	0.571	2023
gpt-oss-120b	2,880	2,880	2.0	2025
gpt-oss-20b	2,880	2,880	2.0	2025
Grok 2	8,192	16,384	1.0	2024
StepFun Step-3	7,168	5,120	2.8	2025
OLMoE-1B-7B	2,048	1,024	4.0	2025
Qwen3-30B-A3B	2,048	768	5.3	2025
Qwen3-235B-A22B	4,096	1,536	5.3	2025
GLM-4.5-Air	4,096	1,408	5.8	2025
DeepSeek V2	5,120	1,536	6.6	2024
GLM-4.5	5,120	1,536	6.6	2025
Kimi K2	7,168	2,048	7.0	2025
DeepSeek V3	7,168	2,048	7.0	2024
Qwen3-Next-80B-A3B	2,048	512	8.0	2025

세분성이 동작을 어떻게 형성하는지에 대해 이야기해보자 (Ant Group의 논문에서):

세분성은 EL의 주된 동인처럼 보이지 않는다. 특히 2를 넘어서는 데 도움이 되지만, 손실을 결정하는 지배적인 요인은 아니다. 하지만 최적의 지점이 있다: 세분성을 더 높이는 것은 어느 지점까지는 도움이 되다가 이득이 평탄해진다. 따라서 세분성은 최근 릴리스에서 더 높은 값으로 가는 명확한 추세가 있는 유용한 튜닝 노브이지만, 고립되어 최적화되어서는 안 된다.

MoE를 개선하기 위해 널리 사용되는 또 다른 방법은 공유 전문가(shared experts)의 개념이다. 살펴보자!

공유 전문가

공유 전문가 설정은 모든 토큰을 상시 활성화되는 소수의 전문가 세트로 라우팅한다. 이 공유 전문가는 데이터의 기본적이고 반복되는 패턴을 흡수하여 나머지 전문가들이 더 공격적으로 전문화될 수 있도록 한다. 실제에서는, 많은 수가 필요하지 않다. 모델 설계자들은 일반적으로 하나, 많아야 두 개를 선택한다. 세분성이 증가함에 따라 (예: Qwen3 스타일 설정에서 Qwen3-Next에 더 가까운 것으로 이동), 공유 전문가는 더 유용해지는 경향이 있다. 다음 플롯을 보면, 전반적인 영향은 미미하며, EL을 극적으로 변화시키지는 않는다. 간단한 경험 법칙이 대부분의 경우에 잘 작동한다: DeepSeek V3, K2, Qwen3-Next와 같은 모델의 선택과 일치하는 하나의 공유 전문가만 사용하는 것이 불필요한 복잡성을 추가하지 않으면서 효율성을 극대화하는 경향이 있다. (Tian et al. (2025)의 그림)

공유 전문가는 일부 토큰이 항상 라우팅되는 전문가이다. 다른 전문가들은 어떠한가? 각 전문가에게 언제 라우팅할지 어떻게 학습하고, 소수의 전문가만 사용하지 않도록 어떻게 보장하는가? 다음으로 우리는 정확히 그 문제를 다루는 로드 밸런싱에 대해 논의할 것이다.

부하 분산 (로드 밸런싱)

로드 밸런싱은 MoE에서 중요한 부분이다. 제대로 설정되지 않으면, 다른 모든 설계 선택을 약화시킬 수 있다. 로드 밸런싱이 제대로 되지 않으면 다음과 같은 예시를 고려해보면 왜 많은 고통을 겪게 되는지 알 수 있다. 모델의 4명의 전문가를 GPU에 고르게 분산하는 4개의 GPU가 있는 매우 간단한 분산 학습 설정을 고려해보자. 라우팅이 붕괴되어 모든 토큰이 전문가 1로 라우팅되면, 이는 GPU의 1/4만 활용됨을 의미하며, 이는 학습 및 추론 효율성에 매우 나쁜 영향을 주게 된다. 그 외에도, 모든 전문가가 활성화되지 않으므로 우리 모델의 유효 학습 능력이 감소했음을 의미한다.

이 문제를 해결하기 위해 라우터에 추가 손실 항을 추가할 수 있다. 아래는 표준 보조 손실 기반 로드 밸런싱(LBL)이다:

L_{Bal}=α∑^Nr_{i=1}f_iP_i

이 간단한 공식은 세 가지 요소만 사용한다: 계수 α 는 손실의 강도를 결정하고, f_i

는 전문가 i 를 통과하는 토큰의 비율인 트래픽 비율이며, 마지막으로 P_i 는 확률 질량(probability mass)이며 전문가를 통과하는 토큰의 확률을 단순히 합산한다. f_i 는 실제 균형에 해당하고, P_i 는 부드럽고 미분 가능하여 기울기가 흐를 수 있도록 하기 때문에, 둘 다 필요하다. 완벽한 로드 밸런싱을 달성하면 $f_i=P_i=1/N_r$ 을 얻지만, α 를 너무 작게 조정하면 라우팅을 충분히 안내하지 못하고, 너무 크면 라우팅 균일성이 기본 언어 모델 손실보다 더 중요해지므로 신중해야 한다.

💡손실 없는 로드 밸런싱

명시적인 손실 항 없이도 균형을 달성하는 것이 가능하다. DeepSeek v3 (DeepSeek-AI et al., 2025)는 라우팅 소프트맥스에 들어가는 어피니티 점수(affinity scores)에 추가되는 간단한 편향 항을 도입했다. 라우터가 과부하되면 점수를 약간 줄여서 (상수 계수 γ) 선택될 가능성을 낮추고, 전문가가 활용되지 않으면 γ 만큼 증가시킨다. 이 간단한 적응 규칙으로 그들은 로드 밸런싱도 달성했다.

핵심 세부 사항은 라우팅 통계를 계산하는 범위이다: f_i 와 P_i가 로컬 배치(각 작업자의 미니 배치)별로 계산되는가 아니면 전역적으로(작업자/장치 전반에 걸쳐 집계) 계산되는가? Qwen 팀의 분석 (Qiu et al., 2025)은 각 로컬 배치에 충분한 토큰 다양성이 없을 때 로컬 계산이 전문가 전문화 (expert specialization, 라우팅 건전성에 대한 좋은 대리 지표)와 전반적인 모델 성능 모두를 해칠 수 있음을 보여준다. 전문가 전문화는 특정 도메인에 대해 하나 이상의 전문가가 다른 전문가보다 더 자주 활성화되는 현상이다. 즉, 로컬 배치가 좁으면 라우팅 통계가 노이즈/편향되어 좋은 균형으로 이어지지 않는다. 이는 가능할 때마다 전역 통계 (또는 적어도 장치 간 집계)를 사용해야 함을 의미한다. 특히, 해당 논문 당시 Megatron을 포함한 많은 프레임워크는 기본적으로 이러한 통계를 로컬로 계산했었다.

Qwen 논문의 다음 플롯은 마이크로 배치 대 전역 배치 집계의 차이와 그것이 성능 및 전문화에 미치는 영향을 보여준다:

일반적으로, MoE 주변의 아키텍처 선택을 제거 실험하는 것은 많은 측면과의 상호 작용이 있기 때문에 까다롭다. 예를 들어 공유 전문가의 유용성은 모델의 세분성에 따라 달라질 수 있다. 따라서 여러분이 찾고 있는 통찰력을 실제로 얻기 위해 좋은 실험 세트를 확보하는 데 시간을 투자할 가치가 있다!

우리는 이제 MoE의 기본 사항을 다루었지만, 여전히 더 발견할 것이 있다. 더 연구할 항목의 전체는 아니지만 일부 목록은 다음과 같다:

제로 컴퓨테이션 전문가, MoE 레이어 재조정 및 학습 모니터링 (LongCat-Flash 논문).
직교 손실 로드 밸런싱 (ERNIE 4.5에서와 같이).
학습 전반에 걸쳐 로드 밸런싱 계수를 스케줄링하는 것.
MoE와의 아키텍처/최적화 상호 작용, 예:
- 옵티마이저 순위가 MoE에 대해 변경되는지 여부.
- MuP를 MoE에 적용하는 방법.
- MoE에 대한 학습률을 조정하는 방법 (배치당 동일한 수의 토큰을 보지 않기 때문에).
시작 부분의 밀집형 레이어 수.
더 많은 것들…

우리는 이제 마지막 주요 아키텍처 선택인 하이브리드 모델로 넘어가므로, 더 깊은 곳으로 토끼굴을 따라가는 것은 열렬한 독자에게 맡긴다!

탐구: 하이브리드 모델

최근 추세는 표준 밀집형 또는 MoE 아키텍처를 상태 공간 모델(State Space Models, SSM) 또는 선형 어텐션 메커니즘으로 보강하는 것이다 (MiniMax et al., 2025; Zuo et al., 2025). 이러한 새로운 종류의 모델들은 트랜스포머의 근본적인 약점 중 일부를 해결하려고 시도한다: 매우 긴 컨텍스트를 효율적으로 처리하는 것이다. 그들은 임의의 길이 컨텍스트를 효율적으로 처리하고 선형적으로 확장할 수 있지만, 컨텍스트 내 정보를 활용하는 데 어려움을 겪을 수 있는 순환 모델과, 긴 컨텍스트에서 매우 비용이 많이 들지만 컨텍스트 내 패턴을 매우 잘 활용할 수 있는 트랜스포머 사이의 중간 지점을 취하고자 한다.

SSM의 한 형태인 Mamba 모델 (A. Gu & Dao, 2024)의 약점을 이해하기 위한 일부 연구가 있었으며 (Waleffe et al., 2024), 이러한 모델들이 많은 벤치마크에서 잘 수행하지만, 예를 들어 MMLU에서는 성능이 저하되며, 컨텍스트 내 학습(in-context learning)의 부족이 그 격차를 유발한다고 가설을 세웠다. 이것이 바로 그들이 Dense 또는 MoE 모델의 블록과 결합해 두 세계의 장점을 모두 얻으려는 이유이며, 따라서 하이브리드 모델이라는 이름이 붙게 되었다.

이러한 선형 어텐션 방법들의 핵심 아이디어는 어텐션이 더 이상 긴 컨텍스트에서 다루기 힘들어지는, $O(n^2d)$ 의 비용이 들지 않도록 계산 순서를 재정렬하는 것이다. 어떻게 그게 될까? 먼저, 추론 시 어텐션 공식을 기억해보자. 토큰 t 에 대한 출력을 생성하는 것은 다음과 같다:

o_t = \frac{\sum_{j=1}^{t} \exp(q_t^\top k_j)v_j}{\sum_{l=1}^{t} \exp(q_t^\top k_l)}

이제 소프트맥스를 제거한다:

o_t = \sum_{j=1}^{t} (q_t^\top k_j) v_j

재정렬하면 다음을 얻는다:

\sum_{j=1}^{t} (q_t^\top k_j) v_j = \left(\sum_{j=1}^{t} v_j k_j^\top\right) q_t

실행 상태(running state)를 다음과 같이 정의한다:

S_t \triangleq \sum_{j=1}^{t} k_j v_j^\top = K_{1:t}^\top V_{1:t} \in \mathbb{R}^{d \times d}

간단한 업데이트를 통해:

S_t = S_{t-1} + k_t v_t^\top

따라서 우리는 다음과 같이 쓸 수 있다:

o_t=S_tq_t=S_{t−1}q_t+v_t(k_t⊤q_t)

재정렬이 왜 중요한가? 왼쪽 형태 $\sum_{j \leq t} (q_t^\top k_j) v_j$ 는 “각 과거 토큰 $j$ 에 대해, 내적 $q_t^\top k_j$ (스칼라)를 취하고, 그것을 $v_j$ 를 스케일링하는 데 사용하며, 이 $t$ 개의 벡터들을 모두 더한다” 를 의미한다 —이는 스텝 $t$ 에서 약 $O(td)$ 작업이다. 오른쪽 형태는 이것을 $(\sum_{j \leq t} v_j k_j^\top) q_t$ 로 다시 작성한다: 당신은 이미 모든 과거 $(k_j, v_j)$ 를 요약하는 단일 실행 상태 행렬 $S_t = \sum_{j \leq t} v_j k_j^\top \in \mathbb{R}^{d \times d}$ 를 유지한다. 각 새 토큰은 하나의 외적 $v_t k_t^\top$ ( $O(d^2)$ 비용)으로 그것을 업데이트한 다음, 출력은 단지 하나의 행렬-벡터 곱셈 $S_t q_t$ (또 다른 $O(d^2)$ )이다. 따라서 왼쪽 형태로 $T$ 개의 토큰을 처음부터 생성하는 것은 $O(T^2 d)$ 인 반면, $S_t$ 를 유지하고 오른쪽 형태를 사용하는 것은 $O(T d^2)$ 이다. 직관적으로: 왼쪽 = “각 스텝마다 많은 작은 내적-스케일-덧셈”; 오른쪽 = “단일한 사전에 요약된 행렬에 쿼리를 곱함”이며, 시퀀스 길이에 대한 의존성을 차원에 대한 의존성으로 교환한다. 우리는 여기서 추론 및 순환 형태에 초점을 맞추지만, 재정렬이 다음 방정식만큼 간단한 학습에서도 더 효율적이다:

(QK^\top)_{n \times n} V = Q (K^\top V)_{d \times d}

따라서 이것이 RNN과 같은 구조와 매우 유사하게 보인다는 것을 알 수 있다. 이것이 우리의 문제를 해결한 것인가? 거의 그렇다. 실제 상황에서, 소프트맥스는 중요한 안정화 역할을 하며, 순진한 선형 형태는 일부 정규화 없이는 불안정할 수 있다. 이것은 라이트닝(lightning) 어텐션 또는 노름(norm) 어텐션이라는 실용적인 변형을 촉발했다!

라이트닝 및 노름 어텐션

이 계열은 Minimax01 (MiniMax et al., 2025)과, 더 최근에는 Ring-linear (L. Team, Han, et al., 2025)에서 나타난다. 이는 노름 어텐션 아이디어 (Qin et al., 2022)를 기반으로 만들어진다. 핵심 단계는 간단하다: 출력을 정규화하는 것이다. “라이트닝” 변형은 구현을 빠르고 효율적으로 만드는 데 초점을 맞추며 공식을 약간 다르게 만든다. 둘 다에 대한 공식은 다음과 같다:

NormAttention:

\text{RMSNorm}(Q(K^T V))

LightningAttention:

Q = \text{Silu}(Q), \quad K = \text{Silu}(K), \quad V = \text{Silu}(V)

O = \text{SRMSNorm}(Q(KV^T))

경험적으로, Norm attention을 가진 하이브리드 모델은 Minimax01에 따르면 대부분의 작업에서 소프트맥스와 일치한다.

스크린샷 2025-12-05 오후 4.55.43.png

여기서 흥미로운 점은 Needle in a Haystack (NIAH)과 같은 검색 작업에서 전체 소프트맥스 어텐션보다 훨씬 더 잘 수행할 수 있다는 것이다. 이는 놀랍게 보일 수 있지만, 소프트맥스와 선형 레이어가 함께 작동할 때 어떤 시너지가 있음을 시사할 수 있다!

MiniMax M2

놀랍게도, 최근 출시된 MiniMax M2는 하이브리드 또는 선형 어텐션을 사용하지 않는다. 그들의 사전 학습 리드에 따르면, 라이트닝 어텐션을 사용한 초기 MiniMax M1 실험이 당시 인기 있는 벤치마크 (MMLU, BBH, MATH)에서 더 작은 규모에서 유망해 보였지만, 그들은 더 큰 규모에서 “복잡한, 멀티-홉 추론 작업에서 명확한 결함”이 있음을 발견했다. 그들은 또한 RL 학습 중 수치 정밀도 문제 및 인프라 성숙도를 핵심 장애물로 언급한다. 그들은 아키텍처를 대규모에서 만드는 것이 데이터 분포, 옵티마이저와 같은 다른 매개변수에 대한 민감도로 인해 어렵고 컴퓨팅 집약적인 다변수 문제라고 결론짓는다.

그러나 그들은 “GPU 컴퓨팅 성장이 둔화되는 동시에 데이터 길이는 계속 증가함에 따라, 선형 및 희소 어텐션의 이점이 점진적으로 나타날 것”임을 인정한다. 이것은 아키텍처 제거 실험의 복잡성과 연구와 생산 현실 사이의 격차를 모두 강조한다.

이제 이러한 방법들 중 일부를 더 살펴보고 그것들이 통합된 프레임워크로 어떻게 이해될 수 있는지 본다.

고급 선형 어텐션

순환 모델로부터의 유용한 교훈은 상태가 때때로 과거를 놓아주도록 허용하는 것이다. 실제에서, 이는 이전 상태에 대한 게이트 Gt 를 도입하는 것을 의미한다:

S_t = G_t \odot S_{t-1} + v_t k_t^\top

거의 모든 최신 선형 어텐션 방법은 Gt의 다른 구현만을 가진 이 게이팅(gating) 구성 요소를 가진다. 다음은 이 논문에서 가져온 게이트 및 해당 아키텍처에 대한 다른 변형 목록이다:

스크린샷 2025-12-01 오후 8.57.26.png

최신 모델의 게이트형 선형 어텐션 공식은 Gt의 매개변수화에서 다양하다. 편향 항은 생략되었다.

목록에서 주목할 만한 한 변형은 Mamba-2 (Dao & Gu, 2024)이다. 이는 Nemotron-H (NVIDIA, :, Blakeman, et al., 2025), Falcon H1 (Zuo et al., 2025), 그리고 Granite-4.0-h (IBM Research, 2025)와 같은 많은 하이브리드 모델에서 사용된다.

그러나 아직 초기 단계이며 대규모 하이브리드 모델로 확장할 때 고려해야 할 중요한 미묘한 차이가 있다. 이들은 유망함을 보이지만, MiniMax가 M2에서 경험한 것은 작은 규모에서의 이점이 항상 복잡한 추론 작업, RL 학습 안정성 및 인프라 성숙도와 같은 대규모 프로덕션 시스템으로 이전되는 것은 아님을 강조한다. 하지만, 하이브리드 모델은 빠르게 움직이고 있으며 선도적인 학습을 위한 견고한 선택으로 남아있다. Qwen3-Next (게이트형 DeltaNet 업데이트 포함) (Qwen Team, 2025)는 긴 컨텍스트에서 추론이 더 빠르고, 학습이 더 빠르며, 일반적인 벤치마크에서 더 강하다고 보고한다. 우리는 또한 Kimi의 다음 모델이 그들의 새로운 “Kimi Delta Attention”을 사용할 가능성이 높다는 것을 기대하고 있다. 블록 또는 쿼리를 선택하여 어텐션을 계산함으로써 선형 어텐션과 동일한 긴 컨텍스트 문제를 해결하는 희소 어텐션(Sparse Attention)도 언급해야 한다. 몇 가지 예시는 Native Sparse Attention (Yuan et al., 2025), DeepSeek Sparse Attention (DeepSeek-AI, 2025) 및 InfLLM v2 (M. Team, Xiao, et al., 2025)이다.

이제 밀집형, MoE 또는 하이브리드 모델 중 무엇을 학습할지 결정하는 작은 의사 결정 트리를 구축함으로써, 토크나이저로 넘어가기 전에 아키텍처 선택을 마무리해보자.

MoE로 갈 것인가, 가지 않을 것인가: 기본 아키텍처 선택

우리는 이제 Dense, MoE, 그리고 하이브리드 모델을 보았으므로, 어떤 것을 사용해야 할지 자연스럽게 의문스러워졌을 것이다. 당신의 아키텍처 선택은 일반적으로 모델을 배포할 위치, 팀의 전문 지식, 그리고 타임라인에 따라 달라진다. 우리는 각 아키텍처의 장단점을 간략하게 살펴보고 여러분에게 적합한 아키텍처를 찾기 위한 간단한 안내 프로세스를 고안한다.

**밀집형 트랜스포머(Dense transformers)**는 모든 매개변수가 모든 토큰에 대해 활성화되는 기본 표준 디코더 전용 트랜스포머이다. 수학에 대해서는 The Annotated Transformers를, 직관을 구축하는 데는 The Illustrated Transformers를 참고해라.

장점: 광범위하게 지원됨, 잘 이해됨, 안정적인 학습, 매개변수당 좋은 성능.
단점: 컴퓨팅이 크기에 따라 선형적으로 확장됨, 70B 모델은 3B보다 약 23배 더 많은 비용이 든다.

이는 일반적으로 메모리 제약이 있는 사용 사례나 새로운 LLM 학습자에게 기본 선택이다.

**전문가 혼합(Mixture of Experts, MoE)**은 트랜스포머의 피드포워드 레이어를 여러 “전문가”로 대체한다. 각 토큰에 대해 게이팅 네트워크가 그것을 소수의 전문가에게만 라우팅한다. 그 결과는 적은 컴퓨팅으로 큰 네트워크의 능력을 얻는 것이다. 예를 들어 Kimi K2는 총 1조 매개변수를 가지지만 토큰당 32B만 활성된다. 문제는 모든 전문가가 메모리에 로드되어야 한다는 것이다. 시각적 가이드 및 상기를 위해 이 블로그(https://newsletter.maartengrootendorst.com/p/a-visual-guide-to-mixture-of-experts) 를 확인하라.

장점: 학습 및 추론을 위한 컴퓨팅당 더 나은 성능.
단점: 높은 메모리 (모든 전문가가 로드되어야 함). 밀집형 트랜스포머보다 더 복잡한 학습. 프레임워크 지원이 개선되고 있지만 밀집형 모델보다 성숙도가 낮다. 그리고 분산 학습은 전문가 배치, 부하 분산, 그리고 All-to-All 통신 문제로 악몽과 같다.

메모리 제약이 없고 컴퓨팅당 최대 성능을 원할 때 사용한다.

하이브리드 모델은 트랜스포머를 Mamba와 같은 상태 공간 모델(SSM)과 결합하여, 어텐션의 2차 확장과 비교하여 일부 작업에 대해 선형 복잡성을 제공한다. (수학적 블로그 https://srush.github.io/annotated-mamba/hard.html | 시각적 가이드 https://newsletter.maartengrootendorst.com/p/a-visual-guide-to-mamba-and-state)

장점: 잠재적으로 더 나은 긴 컨텍스트 처리. 매우 긴 시퀀스에 더 효율적이다.
단점: 검증된 학습 레시피가 적어 밀집형 및 MoE보다 덜 성숙하다. 제한된 프레임워크 지원.

표준 트랜스포머의 추론 오버헤드를 줄이면서 매우 긴 컨텍스트로 확장하고자 할 때 사용한다.

요약하자면, 모델이 어디에 배포될지 묻는 것부터 시작해야 한다. 그런 다음 팀의 전문 지식과 학습 타임라인을 고려하여 감당할 수 있는 탐색의 정도를 평가해야 한다:

스크린샷 2025-12-05 오후 4.56.05.png

SmolLM3의 경우, 우리는 온디바이스 배포를 위한 강력한 소형 모델을 구축하고자 했고, 대략 3개월의 타임라인을 가졌으며, 과거에 주로 밀집형 모델을 학습시켰다. 이것은 MoE (메모리 제약)와 하이브리드 (새로운 아키텍처를 탐색하기에는 짧은 타임라인, 그리고 밀집형 모델이 우리가 목표로 하는 최대 128k 토큰의 긴 컨텍스트를 얻을 수 있었음)를 배제했으므로, 우리는 Llama 스타일의 밀집형 모델을 선택했다.

이제 모델 아키텍처의 내부를 연구했으므로, 데이터와 우리 모델 사이의 다리를 형성하는 토크나이저를 살펴보자.

토크나이저

토큰화 방식은 아키텍처 혁신으로부터 주목을 받는 일은 거의 없지만, 아마도 모든 언어 모델에서 가장 저평가된 구성 요소 중 하나일 것이다. 토크나이저는 인간 언어와 모델이 존재하는 수학적 세계 사이의 번역가로 생각할 수 있으며, 다른 번역가와 마찬가지로 번역의 품질은 매우 중요하다. 그렇다면 우리의 필요에 맞는 올바른 토크나이저를 어떻게 구축하거나 선택할 수 있을까?

토크나이저의 기본

핵심적으로, 토크나이저는 실행 중인 텍스트를 토큰이라고 불리는 개별적으로 처리 가능한 단위로 분할하여, 원시 텍스트를 모델이 처리할 수 있는 숫자의 시퀀스로 변환한다. 기술적 세부 사항에 뛰어들기 전에, 우리의 토크나이저 설계를 안내할 몇 가지 근본적인 질문에 먼저 답해야 한다:

어떤 언어를 지원하고자 하는가? 다국어 모델을 구축하고 있지만 우리의 토크나이저가 영어만 보았다면, 모델은 불필요하게 훨씬 더 많은 토큰으로 분할되는 비영어 텍스트에 직면할 때 비효율적일 것이다. 이것은 성능, 학습 비용 및 추론 속도에 직접적인 영향을 미친다.
어떤 도메인이 우리에게 중요한가? 언어를 넘어, 수학 및 코드와 같은 도메인은 숫자의 신중한 표현을 요구한다.
우리의 목표 데이터 혼합을 알고 있는가? 처음부터 토크나이저를 학습시킬 계획이라면, 이상적으로는 최종 학습 혼합을 반영하는 샘플로 학습시켜야 한다.

이러한 질문에 답했다면, 주요 설계 결정을 검토할 수 있다:

(토큰화 기본 사항에 대한 깊은 탐구를 위해, Andrej Karpathy의 “Let’s build the GPT Tokenizer”는 훌륭한 실습 튜토리얼이다. 토크나이저 소개 및 다수의 외부 자료를 제공하는 이 자료 https://github.com/huggingface/evaluation-guidebook/blob/main/contents/general-knowledge/tokenization.md 를 확인할 수도 있다.)

어휘 크기 (Vocabulary size)

어휘 Vocabulary ****는 본질적으로 모델이 인식하는 모든 토큰 (단어, 하위 단어, 또는 기호와 같은 최소 텍스트 단위)을 나열하는 사전이다.

어휘가 클수록 문장당 더 적은 토큰을 생성하므로 텍스트를 더 효율적으로 압축하지만, 계산상의 트레이드오프가 있다. 어휘 크기는 우리의 임베딩 행렬의 크기에 직접적인 영향을 미친다. 어휘 크기가 V 이고 은닉 차원이 h

라면, 입력 임베딩은 V×h 매개변수를 가지며, 출력 레이어는 또 다른 V×h 매개변수를 가진다. “임베딩 공유” 섹션에서 보았듯이, 소형 모델의 경우 이것이 전체 매개변수의 상당한 부분을 차지하지만, 모델이 확장됨에 따라 상대적 비용은 줄어든다.

최적점은 우리의 목표 범위 및 모델 크기에 따라 달라진다. 영어 전용 모델의 경우, 약 50k 토큰이 일반적으로 충분하지만, 다국어 모델은 다양한 문자 체계 및 언어를 효율적으로 처리하기 위해 종종 100k+가 필요하다. Llama3와 같은 현대의 SOTA 모델들은 다양한 언어에 걸쳐 토큰 효율성을 개선하기 위해 128k+ 범위의 어휘를 채택했다. 동일한 패밀리의 소형 모델들은 더 큰 어휘의 이점을 여전히 얻으면서 임베딩 매개변수의 비율을 줄이기 위해 임베딩 공유를 적용한다. Dagan et al. (2024)은 어휘 크기가 압축, 추론 및 메모리에 미치는 영향을 분석했다. 그들은 더 큰 어휘로부터의 압축 이득이 기하급수적으로 감소하여 최적의 크기가 존재함을 시사한다는 것을 관찰했다. 추론의 경우, 압축이 소프트맥스에서 추가 임베딩 토큰 비용보다 순방향 전달에서 더 많이 절약되므로 더 큰 어휘가 더 큰 모델에 이점을 준다. 메모리의 경우, 최적의 크기는 시퀀스 길이와 배치 크기에 따라 달라진다: 더 긴 컨텍스트와 큰 배치는 더 적은 토큰을 가짐으로써 KV 캐시 절약 때문에 더 큰 어휘로부터 이점을 얻는다.

토큰화 알고리즘

BPE (Byte-Pair Encoding) (Sennrich et al., 2016)는 가장 인기 있는 선택으로 남아 있으며, WordPiece 또는 SentencePiece와 같은 다른 알고리즘이 존재하지만 덜 채택된다. 또한 바이트 또는 문자에 직접 작동하는 토크나이저 없는 접근 방식에 대한 연구 관심이 증가하고 있으며, 그러한 연구들은 잠재적으로 토큰화를 완전히 제거하는 것을 목표로 하고 있다.

이제 토크나이저를 정의하는 주요 매개변수를 보았으므로, 우리는 실용적인 결정을 내려야 한다: 기존 토크나이저를 사용해야 하는가 아니면 처음부터 학습해야 하는가? 답은 범위(coverage)에 달려있다: 목표 어휘 크기를 가진 기존 토크나이저가 우리의 언어와 도메인을 잘 처리하는지 여부이다.

아래 그림은 GPT-2의 영어 전용 토크나이저 (Radford et al., 2019)와 Gemma 3의 다국어 토크나이저 (G. Team, Kamath, et al., 2025)가 동일한 영어 및 아랍어 문장을 어떻게 분할하는지 비교한다.

스크린샷 2025-12-05 오후 4.56.19.png

두 토크나이저는 영어에서는 유사하게 분할을 수행하는 것처럼 보이지만, 아랍어의 경우 그 차이가 두드러진다: GPT2는 텍스트를 100개 이상의 조각으로 나누는 반면, Gemma3는 다국어 학습 데이터와 더 크고 포괄적인 어휘 덕분에 훨씬 더 적은 토큰을 생성한다.

그러나 토크나이저의 품질을 측정하기 위해 몇 가지 토큰화 예시를 눈으로 훑어보고 좋다고 할 수는 없다. 이는 제거 실험을 실행하지 않고 직관에 기반하여 아키텍처 변경을 할 수 없는 것과 마찬가지이다. 토크나이저 품질을 평가하기 위한 구체적인 측정 기준이 필요하다.

토크나이저 품질 측정

토크나이저가 얼마나 잘 수행하는지 평가하기 위해, FineWeb2에서 사용된 두 가지 주요 측정 기준을 사용할 수 있다 (Penedo et al., 2025).

생산성 (Fertility):

이것은 단어를 인코딩하는 데 필요한 평균 토큰 수를 측정한다. 생산성이 낮을수록 더 나은 압축을 의미하며, 이는 더 빠른 학습 및 추론으로 이어진다. 이렇게 생각한다: 한 토크나이저가 대부분의 단어를 인코딩하는 데 한두 개의 토큰이 더 필요한 반면 다른 토크나이저는 더 적은 토큰으로 수행한다면, 후자가 분명히 더 효율적이다.

생산성을 측정하는 표준 접근 방식은 **단어 대 토큰 비율 (word fertility)**을 계산하는 것이다. 이는 평균적으로 단어당 몇 개의 토큰이 필요한지 측정한다. 이 측정 기준은 적절한 단어 토크나이저가 사용 가능할 때 (예: Spacy 및 Stanza에서) 의미 있는 교차 언어 비교를 제공하기 때문에 단어 개념을 중심으로 정의된다 (Penedo et al., 2025).

단일 언어에 대한 토크나이저를 비교할 때, 단어 대신 문자 또는 바이트 수를 사용하여 문자 대 토큰 비율 또는 바이트 대 토큰 비율을 얻을 수도 있다 (Dagan et al., 2024). 그러나 이러한 측정 기준은 교차 언어 비교에 한계가 있다. 다른 스크립트의 문자가 다른 바이트 표현을 요구하므로 (예: 중국어 문자는 UTF-8에서 3바이트를 사용하는 반면 라틴어 문자는 1~2바이트를 사용), 바이트는 왜곡될 수 있다. 유사하게, 문자 수를 사용하는 것은 언어마다 단어 길이가 극적으로 다르다는 사실을 설명하지 못한다. 예를 들어, 중국어 단어는 독일어 복합어보다 훨씬 짧은 경향이 있다.

분할된 단어의 비율 (Proportion of continued words, PCW):

이 측정 기준은 단어의 몇 퍼센트가 여러 조각으로 분할되는지 알려준다. 더 낮은 비율이 더 좋다. 이는 더 적은 단어가 조각화되어 더 효율적인 토큰화로 이어진다는 것을 의미하기 때문이다.

아래는 이러한 측정 기준의 구현이다:

import numpy as np

def compute_tokenizer_metrics(tokenizer, word_tokenizer, text):
    """
    생산성(fertility)과 분할된 단어의 비율(proportion of continued words)을 계산한다.

    반환값:
        tuple: (fertility, proportion_continued_words)
            - fertility: 단어당 평균 토큰 (낮을수록 좋음)
            - proportion_continued_words: 2개 이상의 토큰으로 분할된 단어의 백분율 (낮을수록 좋음)

    """
    words = word_tokenizer.word_tokenize(text)
    tokens = tokenizer.batch_encode_plus(words, add_special_tokens=False)
    tokens_per_word = np.array(list(map(len, tokens["input_ids"])))

    fertility = np.mean(tokens_per_word).item()
    proportion_continued_words = (tokens_per_word >= 2).sum() / len(tokens_per_word)

    return fertility, proportion_continued_words

하지만 코드 및 수학과 같은 전문화된 도메인의 경우, 생산성 외에도 도메인별 패턴을 토크나이저가 얼마나 잘 처리하는지 더 깊이 파고들어야 한다. 대부분의 현대 토크나이저는 단일 숫자 분할을 수행한다 (따라서 “123”은 [“1”, “2”, “3”]이 된다) (Chowdhery et al., 2022; DeepSeek-AI et al., 2024). 숫자를 분리하는 것이 직관에 반하는 것처럼 보일 수 있지만, 실제로는 모델이 산술 패턴을 더 효과적으로 학습하는 데 도움이 된다. “342792”가 하나의 분리 불가능한 토큰으로 인코딩되면, 모델은 그 특정 토큰을 다른 모든 숫자 토큰과 더하거나, 빼거나, 곱할 때 무슨 일이 일어나는지 암기해야 한다. 그러나 그것이 분할될 때, 모델은 숫자 수준 연산이 어떻게 작동하는지 학습한다. Llama3 (Grattafiori et al., 2024)와 같은 일부 토크나이저는 1부터 999까지의 숫자를 고유한 토큰으로 인코딩하고 나머지는 이러한 토큰들로 구성된다.

(토큰화가 산술 성능에 미치는 영향에 대한 더 깊은 탐구를 위해, From Digits to Decisions: How Tokenization Impacts Arithmetic in LLMs는 수학 작업에 대한 다른 토큰화 방식을 비교한다.)

따라서 우리는 토크나이저의 약점과 강점을 평가하기 위해 목표 도메인에서 생산성을 측정할 수 있다. 아래 표는 다른 언어 및 도메인에 대한 인기 있는 토크나이저의 생산성을 비교한다.

토크나이저 평가

다른 언어에 걸쳐 토크나이저를 비교하기 위해, 우리는 위키피디아 기사를 평가 코퍼스로 사용하여 FineWeb2 토크나이저 분석의 설정을 사용할 것이다. 각 언어에 대해, 계산을 관리 가능한 수준으로 유지하면서 의미 있는 샘플을 얻기 위해 100개의 기사를 샘플링할 것이다.

먼저, 종속성을 설치하고 비교하고자 하는 토크나이저와 언어를 정의한다:

pip install transformers datasets sentencepiece 'datatrove[multilingual]'
## 단어 토크나이저를 로드하기 위해 datatrove가 필요하다

tokenizers = [
    ("Llama3", "meta-llama/Llama-3.2-1B"),
    ("Gemma3", "google/gemma-3-1b-pt"),
    ("Mistral (S)", "mistralai/Mistral-Small-24B-Instruct-2501"),
    ("Qwen3", "Qwen/Qwen3-4B")
]

languages = [
    ("English", "eng_Latn", "en"),
    ("Chinese", "cmn_Hani", "zh"),
    ("French", "fra_Latn", "fr"),
    ("Arabic", "arb_Arab", "ar"),
]

이제 우리의 위키피디아 샘플을 로드한다. 전체 데이터셋을 다운로드하는 것을 피하기 위해 스트리밍을 사용하자:

from datasets import load_dataset

wikis = {}
for lang_name, lang_code, short_lang_code in languages:
	wiki_ds = load_dataset("wikimedia/wikipedia", f"20231101.{short_lang_code}", streaming=True, split="train")
	wiki_ds = wiki_ds.shuffle(seed=42, buffer_size=10_000)
	# 언어당 100개 기사 샘플링
  ds_iter = iter(wiki_ds)
  wikis[lang_code] = "\n".join([next(ds_iter)["text"] for _ in range(100)])

데이터가 준비되었으므로, 이제 각 언어에 대해 각 토크나이저를 평가할 수 있다. 각 조합에 대해, 우리는 datatrove에서 적절한 단어 토크나이저를 로드하고 두 측정 기준을 모두 계산한다:

from transformers import AutoTokenizer
from datatrove.utils.word_tokenizers import load_word_tokenizer
import pandas as pd

results = []

for tokenizer_name, tokenizer_path in tokenizers:
    tokenizer = AutoTokenizer.from_pretrained(tokenizer_path, trust_remote_code=True)

    for lang_name, lang_code, short_lang_code in languages:
        word_tokenizer = load_word_tokenizer(lang_code)

        # 위키피디아에서 측정 기준 계산
        fertility, pcw = compute_tokenizer_metrics(tokenizer, word_tokenizer, wikis[lang_code])

        results.append({
            "tokenizer": tokenizer_name,
            "language": lang_name,
            "fertility": fertility,
            "pcw": pcw
        })

df = pd.DataFrame(results)
print(df)

      tokenizer    language  fertility       pcw
0        Llama3     English   1.481715  0.322058
1        Llama3     Chinese   1.601615  0.425918
2        Llama3      French   1.728040  0.482036
3        Llama3     Spanish   1.721480  0.463431
4        Llama3  Portuguese   1.865398  0.491938
5        Llama3     Italian   1.811955  0.541326
6        Llama3      Arabic   2.349994  0.718284
7        Gemma3     English   1.412533  0.260423
8        Gemma3     Chinese   1.470705  0.330617
9        Gemma3      French   1.562824  0.399101
10       Gemma3     Spanish   1.586070  0.407092
11       Gemma3  Portuguese   1.905458  0.460791
12       Gemma3     Italian   1.696459  0.484186
13       Gemma3      Arabic   2.253702  0.700607
14  Mistral (S)     English   1.590875  0.367867
15  Mistral (S)     Chinese   1.782379  0.471219
16  Mistral (S)      French   1.686307  0.465154
17  Mistral (S)     Spanish   1.702656  0.456864
18  Mistral (S)  Portuguese   2.013821  0.496445
19  Mistral (S)     Italian   1.816314  0.534061
20  Mistral (S)      Arabic   2.148934  0.659853
21        Qwen3     English   1.543511  0.328073
22        Qwen3     Chinese   1.454369  0.307489
23        Qwen3      French   1.749418  0.477866
24        Qwen3     Spanish   1.757938  0.468954
25        Qwen3  Portuguese   2.064296  0.500651
26        Qwen3     Italian   1.883456  0.549402
27        Qwen3      Arabic   2.255253  0.660318

결과는 우선순위에 따라 승자와 트레이드오프를 보여준다:

스크린샷 2025-12-05 오후 4.56.33.png

Gemma3 토크나이저는 다국어 학습 데이터와 Llama3의 128k보다 약 2배 더 큰 262k의 매우 큰 어휘 크기로 설명될 수 있는 영어, 프랑스어, 스페인어를 포함한 여러 언어에 걸쳐 낮은 생산성과 단어 분할 비율을 달성한다. Qwen3 토크나이저는 중국어에서 탁월하지만, 영어, 프랑스어, 스페인어에서는 Llama3 토크나이저에 뒤처진다. Mistral Small의 토크나이저 (Mistral AI, 2025)는 아랍어에서 가장 우수한 성능을 보이지만, 영어와 중국어에서는 다른 토크나이저에 미치지 못한다.

기존 토크나이저와 맞춤형 토크나이저 사이의 선택

현재, 강력한 토크나이저의 좋은 선택이 가능하다. 많은 최신 모델은 GPT4의 토크나이저 (OpenAI et al., 2024)와 같은 것으로 시작하여 추가 다국어 토큰으로 보강한다. 위 표에서 볼 수 있듯이, Llama 3의 토크나이저는 다국어 텍스트 및 코드 전반에 걸쳐 평균적으로 좋은 성능을 보이는 반면, Qwen 2.5는 특히 중국어 및 일부 저자원 언어에서 탁월하다.

기존 토크나이저를 사용해야 할 때: 우리의 목표 사용 사례가 위의 최고의 토크나이저들 (Llama, Qwen, Gemma)의 언어 또는 도메인 범위와 일치한다면, 그들은 실전 검증된 견고한 선택이다. SmolLM3 학습을 위해 우리는 Llama3의 토크나이저를 선택했다: 그것은 우리의 소형 모델 크기에 합리적인 적당한 어휘 크기로 우리의 목표 언어들 (영어, 프랑스어, 스페인어, 포르투갈어, 이탈리아어)에 대해 경쟁력 있는 토큰화 품질을 제공한다. 임베딩이 전체 매개변수의 더 작은 부분을 차지하는 더 큰 모델의 경우, Gemma3의 효율성 이점이 더 매력적이 된다.
자체 토크나이저를 학습해야 할 때: 저자원 언어를 위해 학습하거나 매우 다른 데이터 혼합을 가지고 있다면, 좋은 범위를 보장하기 위해 자체 토크나이저를 학습시켜야 할 가능성이 높다. 이 경우, 최종 학습 혼합이 어떻게 보일 것이라고 우리가 믿는 것과 가까운 데이터셋으로 토크나이저를 학습시키는 것이 중요하다. 이것은 데이터 제거 실험을 실행하고 혼합을 찾기 위해 토크나이저가 필요하기 때문에 일종의 닭이 먼저냐 달걀이 먼저냐 하는 문제를 만든다. 그러나 최종 실행을 시작하기 전에 토크나이저를 재학습시키고 다운스트림 성능이 개선되고 생산성이 여전히 좋은지 확인할 수 있다.

여러분의 토크나이저 선택은 기술적인 세부 사항처럼 보일 수 있지만, 모델 성능의 모든 측면에 영향을 미친다. 따라서 그것을 올바르게 하는 데 시간을 투자하는 것을 두려워하지 않아야 한다.

SmolLM3

이제 아키텍처 환경을 탐색하고 체계적인 제거 실험을 실행했으므로, SmolLM3와 같은 모델에 대해 이 모든 것이 실제로 어떻게 하나로 합쳐지는지 살펴보자.

SmolLM 패밀리는 소형 모델로 가능한 것의 경계를 넓히는 것에 관한 시도였다. SmolLM2는 모두 온디바이스에서 효율적으로 실행되도록 설계된 1억 3500만, 3억 6천만, 그리고 17억 매개변수의 세 가지 유능한 모델을 제공했다. SmolLM3의 경우, 우리는 휴대폰에 충분히 작게 유지하면서 성능을 확장하고 SmolLM2의 약점인 다국어성, 매우 긴 컨텍스트 처리, 그리고 강력한 추론 능력을 해결하고자 했다. 우리는 이 균형을 위한 최적점으로 3B 매개변수를 선택했다.

우리는 검증된 레시피를 확장하고 있었기 때문에, 자연스럽게 판단은 밀집형 트랜스포머로 기울어졌다. MoE는 nanotron에 아직 구현되지 않았으며, 우리는 이미 강력한 소형 밀집형 모델을 학습시키는 전문 지식과 인프라를 가지고 있었다. 더 중요하게는, 엣지 디바이스 배포의 경우 우리는 메모리 제약이 있는데, 비록 일부 매개변수만 활성되더라도 많은 매개변수를 가진 MoE는 모든 전문가를 메모리에 로드해야 하므로 제한적이며, 이는 밀집형 모델을 우리의 엣지 배포 목표에 더 실용적으로 만들었다.

제거 실험: 우리는 SmolLM2 17억의 아키텍처를 기반으로 시작한 다음, Qwen2.5-3B 레이아웃을 사용하여 100B 토큰으로 3B 제거 실험 모델을 학습시켰다. 이것은 각 수정 사항을 개별적으로 테스트하기 위한 견고한 기준선을 제공했다. 각 아키텍처 변경은 영어 벤치마크에서 손실 및 다운스트림 성능을 개선하거나 품질 저하 없이 추론 속도와 같은 측정 가능한 이점을 제공해야 했다.

다음은 우리가 실행을 시작하기 전에 테스트하여 채택된 사항이다:

토크나이저: 아키텍처 수정에 뛰어들기 전에, 우리는 토크나이저를 선택해야 했다. 우리는 목표 언어와 도메인을 포괄하는 좋은 토크나이저들을 발견했다. 우리의 생산성 분석을 기반으로, Llama3.2의 토크나이저는 우리의 6개 목표 언어 사이에서 최적의 트레이드오프를 제공하는 동시에, 다국어 효율성을 위해 충분히 크지만 임베딩 가중치로 3B 매개변수 수를 부풀리지 않을 만큼 적당한 128k의 어휘를 유지했다.

그룹 쿼리 어텐션 (GQA): 우리는 4개 그룹을 가진 GQA가 Multi-Head Attention 성능과 일치한다는 우리의 초기 발견을 재확인했지만, 이번에는 100B 토큰을 가진 3B 규모에서였다. KV 캐시 효율성 이점은 포기하기에는 너무 좋았으며, 특히 메모리가 소중한 온디바이스 배포에 중요했다.

긴 컨텍스트를 위한 NoPE: 우리는 4번째 레이어마다 RoPE를 제거하여 NoPE를 구현했다. 우리의 3B 제거 실험은 위 섹션의 발견을 확인했다. NoPE는 짧은 컨텍스트 성능을 희생하지 않고 긴 컨텍스트 처리를 개선했다.

문서 내 어텐션 마스킹: 우리는 매우 큰 시퀀스로 학습할 때 학습 속도와 안정성을 돕기 위해 학습 중 문서 간 어텐션을 방지했다. 다시 한번 우리는 이것이 다운스트림 성능에 영향을 미치지 않는다는 것을 발견한다.

모델 레이아웃 최적화: 우리는 문헌의 최근 3B 모델들의 레이아웃을 비교했다. 일부는 깊이를 우선시하고, 다른 일부는 너비를 우선시했다. 우리는 Qwen2.5-3B (31억), Llama3.2-3B (32억), 그리고 Falcon3-H1-3B (31억) 레이아웃을 우리의 학습 설정에서 테스트했는데, 여기서 깊이와 너비가 다양했다. 결과는 흥미로웠다: Qwen2.5-3B가 실제로는 더 적은 매개변수를 가졌음에도 불구하고 모든 레이아웃이 거의 동일한 손실과 다운스트림 성능을 달성했다. 그러나 Qwen2.5-3B의 더 깊은 아키텍처는 네트워크 깊이가 일반화에 도움이 된다는 연구와 일치했다 (Petty et al., 2024). 따라서, 우리는 학습이 진행됨에 따라 도움이 될 것이라고 예상하며, 더 깊은 레이아웃을 선택했다.

안정성 개선: 우리는 SmolLM2에서 묶인 임베딩을 유지했지만, OLMo2에서 영감을 받은 새로운 트릭인 임베딩에서 가중치 감쇠 제거를 추가했다. 우리의 제거 실험은 이것이 성능을 해치지 않으면서 임베딩 노름을 낮추어, 학습 발산을 방지하는 데 도움이 될 수 있음을 보여주었다.

이러한 체계적인 제거 실험 접근 방식의 아름다움은 각각이 검증되었음을 알고 모든 이러한 수정 사항을 자신 있게 결합할 수 있었다는 것이다.

💡제거 실험에서 변경 사항 결합

실제에서는 변경 사항을 점진적으로 테스트했다: 일단 기능이 검증되면, 그것은 다음 기능을 테스트하기 위한 기준선의 일부가 되었다. 테스트 순서가 중요하다: 실전 검증된 기능부터 시작했다. (임베딩 묶기 → GQA → 문서 마스킹 → NoPE → 가중치 감쇠 제거).

참여 규칙

요약: 여러분의 use case가 선택을 주도하게 해라.

배포 대상을 아키텍처 결정의 지침으로 삼아야 한다. 새로운 아키텍처 혁신을 평가할 때 모델이 실제로 어떻게, 어디서 실행될지 고려하라.

혁신과 실용주의 사이의 올바른 균형을 맞춘다. 주요 아키텍처 발전을 무시할 수는 없다. GQA 및 더 나은 대안이 존재하는 오늘날 Multi-Head Attention을 사용하는 것은 좋지 않은 기술적 선택일 것이다. 최신 연구에 대한 정보를 얻고, 대규모에서 명확하고 검증된 이점을 제공하는 기술을 채택해야 한다. 그러나 사소한 이득을 약속하는 모든 새로운 논문을 쫓으려는 유혹에 저항해야 한다 (그렇게 할 자원이 있거나 목표가 아키텍처 연구인 경우가 아니라면).

체계적인 것이 직관적인 것을 이긴다. 아무리 유망해 보이더라도 모든 아키텍처 변경을 검증하라. 그런 다음 영향력을 이해하기 위해 결합하기 전에 수정 사항을 개별적으로 테스트해라.

규모 효과는 실재한다 - 가능하면 목표 크기에서 다시 제거 실험을 진행하라. 소규모 제거 실험이 목표 모델 크기에서 완벽하게 유지될 것이라고 가정하지 않아야 한다. 컴퓨팅 자원이 있다면, 그것들을 재확인하려고 시도해라.

실제 도메인에서 토크나이저 효율성을 검증하라. 목표 언어 및 도메인 전반의 생산성 측정 기준은 최신 모델이 사용한 것을 따르는 것보다 더 중요하다. 진지한 다국어 작업을 위해 50k 영어 토크나이저만으로는 부족하지만, 그렇게 많은 언어를 다루지 않는다면 256k 어휘도 필요하지 않다.

이제 모델 아키텍처가 결정되었으므로, 학습 프로세스를 주도할 옵티마이저와 하이퍼파라미터를 다룰 차례이다.

옵티마이저 및 학습 하이퍼파라미터

조각들이 제자리를 찾고 있다. 우리는 제거 실험을 실행했고, 아키텍처를 결정했으며, 토크나이저를 선택했다. 그러나 실제로 학습을 시작하기 전에, 여전히 몇 가지 중요한 누락된 조각들이 있다: 어떤 옵티마이저를 사용해야 하는가? 어떤 학습률과 배치 크기를 사용해야 하는가? 학습 전반에 걸쳐 학습률을 어떻게 스케줄링해야 할까?

여기서 시도하고 싶은 접근 방식은 문헌의 다른 강력한 모델에서 값을 빌려오는 것일 수 있다. 결국, 그것이 큰 연구소에서 작동했다면, 우리에게도 작동해야 하지 않을까? 그리고 유사한 아키텍처와 모델 크기에서 값을 가져오는 경우 많은 경우에 잘 작동할 것이다.

그러나 우리의 특정 설정에 대해 이러한 값들을 튜닝하지 않음으로써 성능을 테이블 위에 남겨둘 위험이 있다. 문헌의 하이퍼파라미터는 특정 데이터와 제약 조건에 대해 최적화되었으며, 때로는 그러한 제약 조건이 성능에 관한 것도 아닐 수도 있다. 아마도 그 학습률은 개발 초기에 선택되었고 다시 검토되지 않았을 수 있다. 모델 저자들이 철저한 하이퍼파라미터 스윕을 수행하더라도, 그 최적 값은 우리의 것이 아닌, 그들의 정확한 아키텍처, 데이터 및 학습 체제의 조합에 대해 발견된 것이다. 문헌 값은 항상 좋은 출발점이지만, 우리가 주변에서 더 나은 값을 찾을 수 있는지 탐색하는 것이 좋은 생각이다.

이 챕터에서는 최신 옵티마이저를 탐색하고 (신뢰할 수 있는 오래된 AdamW (Kingma, 2014)가 여전히 시간의 시험을 견디는지 본다 🎉), 표준 코사인 감쇠를 넘어선 학습률 스케줄에 깊이 뛰어들고, 모델 및 데이터 크기가 주어졌을 때 학습률과 배치 크기를 조정하는 방법을 알아낼 것이다.

옵티마이저 전쟁부터 시작하자.

옵티마이저: AdamW 및 그 이상

옵티마이저는 전체 LLM 학습 작업의 핵심에 있다. 그것은 과거 업데이트, 현재 가중치 및 손실에서 파생된 기울기를 기반으로 모든 매개변수에 대해 실제 업데이트 단계가 무엇이 될지 결정한다. 동시에 그것은 또한 메모리와 컴퓨팅을 많이 잡아먹는 괴물이므로, 필요한 GPU 수와 학습 속도에 영향을 미칠 수 있다.

(옵티마이저가 무엇이며 무엇에 유용한지 확실하지 않다면, 주목할 만하게 멋진 옵티마이저를 비교하는 Ruder의 경사 하강법 및 옵티마이저에 대한 블로그 https://www.ruder.io/optimizing-gradient-descent/를 확인해라.)

우리는 LLM 사전 학습에 사용되는 옵티마이저의 현재 상황을 요약하는 데 노력을 아끼지 않았다:

모델	옵티마이저
Kimi K2, GLM 4.5	Muon
다른 모든 모델	AdamW

그래서, 여러분은 왜 모든 사람이 AdamW를 사용하는지 궁금할 것이다.

이 블로그 게시물의 이 부분을 작성하는 사람은 “사람들이 게으르기 때문에”라고 생각하지만 , 다른 사람들은 AdamW가 오랫동안 다양한 규모에서 잘/더 잘 작동해 왔으며, 특히 매우 긴 학습에서 얼마나 잘 작동하는지 테스트하기 어렵거나 (즉, 비싸거나) 비용이 많이 든다면 그러한 핵심 구성 요소를 변경하는 것이 항상 조금 무섭다고 더 현실적으로 말할 수 있다.

게다가, 옵티마이저를 공정하게 비교하는 것은 보이는 것보다 더 어렵다. 규모는 작은 제거 실험에서 시뮬레이션하기 어려울 수 있는 방식으로 역학을 변화시키므로, 하이퍼파라미터 튜닝이 복잡하다. 여러분은 “괜찮다, 나는 AdamW를 몇 주 동안 튜닝했고, 비교를 위해 동일한 하이퍼파라미터를 재사용할 수 있다!”라고 말할 수 있으며, 우리는 이것이 사실이기를 정말로 바란다. 그러나 불행히도, 각 옵티마이저에 대해 적절한 하이퍼파라미터 탐색 (1D? 2D? 3D?)을 수행해야 하며, 이는 옵티마이저 연구를 어렵고 비용이 많이 들게 만든다.

(종종, 기준선이 잘 튜닝되지 않아, 새로운 옵티마이저가 약한 AdamW 설정과 비교된다. 최근 연구 (Wen et al., 2025)는 그것만으로 보고된 이득이 얼마나 왜곡되는지 보여준다.)

그러므로 Durk Kingma의 무서운 Google 스칼라 지배력의 기반인 고전, AdamW부터 시작한다.

AdamW

Adam (Adaptive Momentum Estimation)은 1차 최적화 기술이다. 이는 기울기만 보는 것 외에도, 이전 단계에서 가중치가 얼마나 변했는지도 고려한다는 것을 의미한다. 이것은 각 매개변수에 대한 학습률이 모멘텀을 기반으로 적응하도록 만든다.

조심스러운 독자는 궁금해할 수 있다: 이봐, W가 빠졌잖아? 물론이다! 우리가 구체적으로 W (=가중치 감쇠)를 추가하는 이유는 다음과 같다. 표준 SGD에서 우리는 L2 정규화를 적용하기 위해 손실 함수에 $λθ^2$ (θ는 가중치)를 간단히 추가할 수 있다. 그러나 Adam에서 똑같은 방식을 사용하면, 적응형 학습률이 L2 정규화에도 영향을 미치게 되는데, 이는 정규화 강도가 기울기 크기에 의존하도록 만들어 그 효과를 약화시킨다는 것을 의미한다. 이것은 우리가 원하는 결과가 아니기 때문에, AdamW는 이것을 해결하고자 가중치 감쇠를 주 최적화 루프와 분리하여 적용한다.

흥미롭게도, 지난 몇 년 동안 AdamW 하이퍼파라미터는 거의 움직이지 않았다:

β1=0.9, β2=0.95
기울기 노름 클리핑 (grad norm clipping) = 1.0
가중치 감쇠 (weight decay) = 0.1 (Llama-3-405B는 이것을 0.01로 낮춘다)

동일한 세 설정이 Llama 1, 2, 3에서 DeepSeek-V1, 2, 3 671B까지 거의 재사용되며, 변경이 없다. Durk Kingma가 처음부터 옳았던 걸까, 아니면 우리가 더 잘할 방법이 있을까?

Muon 한 줄 요약

Adam은 기울기만을 사용하므로 1차 방법이다. Muon은 매개변수 텐서의 행렬 뷰에 작용하는 2차 옵티마이저이다.

G_t = \nabla_\theta L_t(\theta_{t-1})

B_t = \mu B_{t-1} + G_t

O_t = \text{NewtonSchulz}_5(B_t) \approx UV^\top \text{ if } B_t = U\Sigma V^\top \text{ (SVD)}

\theta_t = \theta_{t-1} - \eta O_t

이러한 방정식들을 보면, 기울기만 보이고 더 높은 차수의 항은 보이지 않기 때문에, 이것이 왜 2차 방법인지 궁금할 수 있다. 2차 최적화는 실제로는 Newton Schulz 단계 내에서 발생하지만, 여기서는 더 이상 자세히 설명하지 않을 것이다. Muon을 깊이 있게 설명하는 고품질 블로그가 이미 있으므로, 여기서는 Muon의 세 가지 핵심 아이디어만 나열한다:

매개변수별 업데이트 대 행렬별 기하학: AdamW는 매개변수별로 사전 조건을 부여한다 (대각 2차 모멘트). Muon은 각 가중치 행렬을 단일 객체로 취급하고 G=UV⊤을 따라 업데이트하며, 이는 행/열 부분 공간 구조를 포착한다.
직교화를 통한 등방성 단계: 특이값 분해(SVD)를 사용하여 G=UΣV⊤를 분해하는 것은 크기 (Σ)와 방향 (왼쪽/오른쪽 부분 공간 U,V)이 분리된다. G를 UV⊤로 대체하는 것은 특이값을 버리는 것으로, 이는 활성 부분 공간에서 업데이트 단계를 **등방성(isotropic)**으로 만든다. 이는 정보를 잃는 것처럼 보이므로 처음에는 다소 직관에 반할 수 있지만, 이는 축 정렬 편향을 줄이고, 이를 하지 않았을 경우에는 매우 작은 특이값에 의해 억제되었을 방향들에 대한 탐색을 장려한다. 이러한 방식의 탐색은 단순히 손실값만 봐서는 명확하지 않은 다른 능력들을 모델에게 부여하는지에 대해서는 여전히 열린 질문으로 남아있다.
더 큰 배치 크기에 대한 경험적 허용 오차: 실제 환경에서에서, Muon은 종종 더 높은 배치 크기를 잘 견뎌낸다. 우리는 배치 크기 섹션에서 이것에 대해 더 깊이 이야기할 것이지만, 이것이 Muon 채택의 핵심 포인트일 수 있다!

수년 동안 커뮤니티는 주로 AdamW에 정착했으며 선도적인 연구소의 옵티마이저 레시피는 종종 비밀로 유지되지만 (예를 들어 Qwen은 그들의 것에 대해 이야기하지 않는다), 최근 Muon은 높은 관심의 출시에서 채택되었다 (예: Kimi K2, GLM-4.5). 더 개방적이고 견고한 레시피가 나오기를 바란다.

옵티마이저의 야생 동물원은 존재하는데, 연구자들이 가능한 모든 모멘텀과 도함수를 결합하는 것보다 더 창의적인 유일한 것은 그것들에 대한 이름을 생각해내는 것이다: Shampoo, SOAP, PSGD, CASPR, DION, Sophia, Lion… 심지어 AdamW도 NAdamW, StableAdamW 등과 같은 자체 변형을 가지고 있다. 이 모든 옵티마이저에 깊이 뛰어드는 것은 그 자체로 블로그 글로 작성될 가치가 있지만, 우리는 그것을 다음 기회로 미룬다. 대신, 옵티마이저 간 비교를 할 때 하이퍼파라미터 튜닝이 얼마나 중요한지 보여주기 위해 많은 다양한 옵티마이저를 벤치마킹한 stanford/marin 팀의 이 놀라운 논문 (Wen et al., 2025)을 추천한다.

거의 모든 옵티마이저와 떼려야 뗄 수 없는 질문은 바로 가중치를 얼마나 강하게 업데이트할 것인가이다. 이는 통상 옵티마이저 방정식에서 단순한 스칼라 값으로 등장하는 학습률(learning rate) 에 의해 결정된다. 겉보기에는 단순해 보이는 이 주제가 실제로는 얼마나 다양한 측면을 지니고 있는지 살펴보자.

학습률

학습률은 우리가 설정해야 할 가장 중요한 하이퍼파라미터 중 하나이다. 각 학습 단계에서, 그것은 계산된 기울기를 기반으로 모델 가중치를 얼마나 조정할지 제어한다. 학습률을 너무 낮게 선택하면 학습이 고통스럽게 느려지고 나쁜 지역 최소값(local minima)에 갇힐 수 있다. 손실 곡선은 평평하게 보일 것이고, 우리는 의미 있는 진전을 이루지 못한 채 컴퓨팅 예산을 소진할 것이다. 반면에 학습률을 너무 높게 설정하면 옵티마이저가 최적의 솔루션을 지나치는 거대한 단계를 밟아 절대 수렴하지 않거나, 상상할 수 없는 일이 발생하여 손실이 발산하고 달까지 치솟을 수 있다.

그러나 학습 역학이 학습을 하는 과정에서 변하기 때문에 최고의 학습률조차도 일정하지 않다. 높은 학습률은 우리가 좋은 솔루션에서 멀리 떨어져 있는 초기에 효과가 있지만, 수렴 근처에서는 불안정성을 유발한다. 여기서 학습률 스케줄이 등장한다: 초기 혼란을 피하기 위해 0에서 웜업한 다음, 좋은 최소값에 정착하기 위해 감쇠한다. 이러한 패턴 (예: 웜업 + 코사인 감쇠)은 신경망 학습을 위해 수년 동안 검증되었다.

💡웜업 단계

대부분의 현대 LLM은 모델 크기 및 학습 길이에 관계없이 고정된 수의 웜업 단계 (예: 2000)를 사용한다 (표 1 참조). 우리는 긴 학습의 경우 웜업 단계 수를 늘리는 것이 성능에 영향을 미치지 않지만, 매우 짧은 학습의 경우 사람들은 일반적으로 학습 단계의 1%에서 5%를 사용한다는 것을 발견했다

일반적인 스케줄을 살펴본 다음, 피크 값을 선택하는 방법을 논의해보자.

학습률 스케줄: 코사인 감쇠를 넘어서

학습률을 변경하는 것이 수렴에 도움이 된다는 것은 수년 동안 알려져 왔으며 (Smith & Topin, 2018), 코사인 감쇠 (Loshchilov & Hutter, 2017)는 LLM 학습을 위한 기본 스케줄이었다: 웜업 후 피크 학습률에서 시작한 다음, 코사인 곡선을 따라 부드럽게 감소한다. 간단하고 잘 작동한다. 그러나 주요 단점은 유연성 부족이다; 코사인 주기 길이는 총 학습 기간과 일치해야 하므로 총 학습 단계를 미리 알아야 한다. 이것은 일반적인 시나리오에서 문제가 된다: 모델이 아직 정체기에 도달하지 않았거나, 더 많은 컴퓨팅에 접근할 수 있어 더 오래 학습하고 싶거나, 스케일링 법칙을 실행하고 있어 동일한 모델을 다른 토큰 수로 학습해야 하는 경우이다. 코사인 감쇠는 처음부터 다시 시작하도록 강요한다.

많은 팀들이 이제 웜업 직후에 감쇠를 시작할 필요가 없는 스케줄을 사용한다. 아래 플롯에 표시된 Warmup-Stable-Decay (WSD) (Hu et al., 2024) 및 Multi-Step (DeepSeek-AI, :, et al., 2024) 변형이 그렇다. 학습의 대부분 동안 일정한 높은 학습률을 유지하고, WSD의 경우 최종 단계 (일반적으로 토큰의 마지막 10-20%)에서 급격히 감쇠하거나, DeepSeek LLM의 Multi-Step 스케줄에서 수행된 것처럼 예를 들어 학습의 80% 후, 그리고 90% 후에 학습률을 낮추기 위해 이산적인 하락 (단계)을 수행한다.

스크린샷 2025-12-02 오후 2.26.28.png

이러한 스케줄은 코사인 감쇠보다 실질적인 이점을 제공한다. 우리는 처음에 계획했던 것보다 더 오래 학습하고 싶거나, 학습 진행 상황을 더 잘 측정하기 위해 일찍 감쇠하거나, 하나의 주요 학습 실행으로 다양한 토큰 수에 걸쳐 스케일링 법칙 실험을 실행할 수 있는 등 재시작 없이 실행 중간에 학습을 확장할 수 있다. 게다가, 연구들은 WSD와 Multi-Step 모두 실제 학습 시나리오에 더 실용적이면서 코사인 감쇠와 일치함을 보여준다 (DeepSeek-AI, :, et al., 2024; Hägele et al., 2024).

(최근 GLM 4.5는 WSD가 일반 벤치마크 (SimpleQA, MMLU)에서 더 나쁜 성능을 보인다고 언급하지만, 결과를 제공하지는 않는다.)

그러나 여러분은 아마도 이러한 스케줄이 코사인에 비해 새로운 하이퍼파라미터를 도입한다는 것을 알아차렸을 것이다: WSD에서 감쇠 단계는 얼마나 지속되어야 하는가? 그리고 Multi-Step 변형에서 각 단계는 얼마나 길어야 하는가?

WSD의 경우: 코사인 성능과 일치시키기 위해 필요한 쿨다운 기간은 학습 실행이 길어질수록 감소하며, 총 토큰의 10-20%를 감쇠 단계에 할당하는 것이 권장된다 (Hägele et al., 2024). 우리는 아래의 제거 실험에서 이 설정이 코사인과 일치함을 확인할 것이다.
Multi-Step의 경우: DeepSeek LLM의 제거 실험은 그들의 기본 80/10/10 분할 (80%까지 안정, 80-90%에서 첫 번째 단계, 90-100%에서 두 번째 단계)이 코사인과 일치하는 반면, 이러한 비율을 조정하면 예를 들어 70/15/15 및 60/20/20 분할을 사용할 때 심지어 그것을 능가할 수도 있음을 발견했다.

하지만 우리는 이러한 스케줄로 더욱 창의적일 수 있다. DeepSeek 모델의 각 패밀리에서 사용된 스케줄을 살펴본다:

스크린샷 2025-12-02 오후 2.28.21.png

DeepSeek LLM은 기본 Multi-Step 스케줄 (80/10/10)을 사용했다. DeepSeek V2는 비율을 60/30/10으로 조정하여 첫 번째 감쇠 단계에 더 많은 시간을 주었다. DeepSeek V3는 가장 창의적인 접근 방식을 취했다: 일정한 학습률을 유지한 다음 두 번의 급격한 단계를 거치는 대신, 코사인 감쇠 (학습의 67%에서 97%까지)를 통해 일정한 단계에서 전환한 다음, 최종 급격한 단계 전에 짧은 일정한 단계를 적용한다.

DeepSeek 스케줄 변경

DeepSeek-V2 및 V3의 기술 보고서는 이러한 스케줄 변경에 대한 제거 실험을 포함하지 않는다. 여러분의 설정을 위해, 간단한 WSD 또는 Multi-Step 스케줄로 시작한 다음, 제거 실험을 통해 매개변수를 튜닝하는 것을 고려한다.

이국적인 학습률 스케줄에 대한 조사를 여기서 멈추고 실제로 무엇이 작동하는지 확인하기 위해 GPU 시간을 좀 태워보자!

제거 실험 - WSD는 코사인과 일치한다

이제 제거 실험을 할 시간이다! WSD가 실제로 실제에서 코사인의 성능과 일치하는지 테스트해보자. 우리는 여기서 Multi-Step 제거 실험을 보여주지 않지만, Multi-Step이 다른 단계 분할로 코사인과 일치함을 보여준 DeepSeek LLM의 제거 실험을 참고하길 추천한다. 이 섹션에서는 코사인 감쇠를 두 가지 감쇠 창 (10% 및 20%)을 가진 WSD와 비교할 것이다.

스크린샷 2025-12-02 오후 2.29.52.png

스크린샷 2025-12-02 오후 2.30.03.png

평가 결과는 세 가지 구성 모두에서 유사한 최종 성능을 보여준다. 손실 및 평가 곡선 (특히 HellaSwag)을 보면 흥미로운 패턴이 보인다: 코사인은 안정 단계 (WSD의 감쇠가 시작되기 전) 동안 더 나은 손실 및 평가 점수를 달성한다. 그러나 WSD가 감쇠 단계에 진입하면, 손실 및 다운스트림 지표 모두에서 거의 선형적인 개선이 있어 WSD가 학습이 끝날 때쯤 코사인을 따라잡을 수 있다.

이것은 WSD의 10-20% 감쇠 창이 실행 중간에 학습을 확장할 수 있는 유연성을 유지하면서 코사인의 최종 성능과 일치시키기에 충분함을 확인시켜 준다. 우리는 SmolLM3를 위해 10% 감쇠를 가진 WSD를 선택했다.

⚠️ 실행 중간에 다른 스케줄러로 학습된 모델 비교

안정 단계 동안 코사인과 WSD 사이의 중간 체크포인트를 비교하는 경우, 공정한 비교를 위해 WSD 체크포인트에 감쇠를 적용해야 한다.

이제 인기 있는 학습률 스케줄에 대한 좋은 개요를 얻었으므로, 다음 질문은: 피크 학습률은 실제로 무엇이어야 하는가?

최적의 학습률 찾기

우리의 특정 학습률 스케줄러 및 학습 설정에 적합한 학습률을 어떻게 선택해야 할까?

우리는 아키텍처 선택을 위해 했던 것처럼 짧은 제거 실험에서 학습률 스윕을 실행할 수 있다. 그러나 최적의 학습률은 학습 기간에 따라 다르다: 짧은 제거 실험에서 가장 빠르게 수렴하는 학습률이 전체 실행에 가장 좋은 것은 아닐 수 있다. 그리고 우리는 단지 다른 학습률을 테스트하기 위해 비싼 다주간의 학습을 여러 번 실행할 여유가 없다.

먼저 너무 높거나 낮은 학습률을 배제하는 데 도움이 되는 빠르게 실행할 수 있는 간단한 스윕을 살펴본 다음 하이퍼파라미터에 대한 스케일링 법칙을 논의할 것이다.

제거 실험 - LR 스윕

다른 학습률의 영향을 설명하기 위해, 45B 토큰으로 학습된 1B 제거 실험 모델에 대한 스윕을 살펴본다. 우리는 동일한 모델을 동일한 설정에서 4가지 다른 학습률로 학습시킨다: 1e-4, 5e-4, 5e-3, 5e-2. 결과는 두 극단에서의 위험을 명확하게 보여준다:

스크린샷 2025-12-02 오후 2.32.16.png

스크린샷 2025-12-02 오후 2.32.35.png

LR 5e-2는 거의 즉시 발산하며, 손실은 초기에 급등하고 절대 회복되지 않아 모델을 사용할 수 없게 만든다. LR 1e-4는 너무 보수적이며, 안정적으로 학습되지만 다른 학습률보다 훨씬 느리게 수렴한다. 5e-4와 5e-3의 중간 지점은 더 나은 수렴과 비교할 만한 성능을 보여준다. 그러나 모든 모델 크기에 대해 스윕을 실행하는 것은 빠르게 비싸지고, 더 중요하게는 앞서 언급했듯이 계획된 학습 토큰 수를 고려하지 않는다. 여기서 스케일링 법칙이 매우 귀중해진다.

SmolLM3의 경우, 우리는 WSD 스케줄을 사용하는 AdamW로 100B 토큰에 대해 3B 모델을 학습시켰고, 여러 학습률을 비교했다. 우리는 2e-4가 손실 및 다운스트림 성능 모두에서 1e-4보다 훨씬 빠르게 수렴한다는 것을 발견했으며, 3e-4는 2e-4보다 약간 더 나을 뿐이었다. 3e-4의 한계 이익은 긴 학습 실행 중 불안정성의 위험 증가를 동반했으므로, 우리는 2e-4를 우리의 최적점으로 선택했다.

이러한 스윕은 명백히 너무 높거나 (발산) 너무 낮은 (느린 수렴) 학습률을 배제하는 데 도움이 되지만, 모든 모델 크기에 대해 스윕을 실행하는 것은 빠르게 비싸지고, 더 중요하게는 앞서 언급했듯이 계획된 학습 토큰 수를 고려하지 않는다. 여기서 스케일링 법칙이 매우 귀중해진다.

그러나 하이퍼파라미터에 대한 스케일링 법칙에 뛰어들기 전에, 학습률과 상호 작용하는 또 다른 중요한 하이퍼파라미터인 배치 크기를 논의해보자.

배치 크기 (Batch size)

배치 크기는 모델 가중치를 업데이트하기 전에 처리되는 샘플의 수이다. 이것은 학습 효율성과 최종 모델 성능 모두에 직접적인 영향을 미친다. 배치 크기를 늘리면 하드웨어 및 학습 스택이 장치 간에 잘 확장되는 경우 처리량(throughput)을 향상시킨다. 그러나 특정 지점을 넘어서면, 더 큰 배치는 데이터 효율성을 해치기 시작한다: 모델은 동일한 손실에 도달하기 위해 더 많은 총 토큰을 필요로 하게 된다. 이것이 발생하는 분기점은 **임계 배치 크기(critical batch size)**로 알려져 있다 (McCandlish et al., 2018).

(처리량(Throughput)은 학습 중 초당 처리되는 토큰의 수이다.)

임계값 미만에서 배치 크기 증가: 배치 크기를 늘리고 학습률을 재조정한 후, 더 작은 배치 크기 실행과 동일한 수의 토큰으로 동일한 손실에 도달하며, 낭비되는 데이터가 없다.
임계값 초과에서 배치 크기 증가: 더 큰 배치는 데이터 효율성을 희생하기 시작한다; 더 많은 칩이 바쁘기 때문에 실제 시간(wall-clock time)이 줄어들더라도, 동일한 손실에 도달하려면 이제 더 많은 총 토큰 (따라서 더 많은 돈)이 필요하다.

왜 학습률을 재조정해야 하는지, 그리고 임계 배치 크기가 무엇이어야 하는지 추정치를 계산하는 방법에 대해 약간의 직관을 제공해보겠다.

배치 크기가 커지면, 각 미니 배치 기울기는 실제 기울기에 대한 더 나은 추정치가 되므로, 더 큰 단계 (즉, 학습률 증가)를 안전하게 밟아 더 적은 업데이트로 목표 손실에 도달할 수 있다. 문제는 그것을 어떻게 확장하느냐이다.

B개의 샘플에 대한 평균화 과정

배치 기울기는 $\tilde{g}_B = \frac{1}{B}\sum_{i=1}^{B}\tilde{g}^{(i)}$ 이다.
평균은 동일하게 유지된다: $\mathbb{E}[\tilde{g}_B] = g$
그러나 공분산은 줄어든다: $\text{Cov}(\tilde{g}_B) = \frac{\Sigma}{B}$

SGD 매개변수 업데이트는 다음과 같다:

$\Delta w = -\eta \tilde{g}_B$

이 업데이트의 분산은 다음에 비례한다:

$\text{Var}(\Delta w) \propto \frac{\eta^2 \Sigma}{B}$

따라서 업데이트 분산을 대략 일정하게 유지하려면, 배치 크기를 k 배 확장할 경우, 학습률을 $\sqrt{k}$ 배 확장해야 한다. 예를 들어 최적의 배치 크기와 학습률을 계산했고 임계 배치 크기까지 늘리는 것이 가능하며 처리량을 증가시킨다는 것을 발견했다면, 최적의 학습률 또한 조정해야 한다.

B_{\text{critical}} \rightarrow k B_{\text{optimal}} \Rightarrow \eta_{\text{critical}} \rightarrow k \eta_{\text{optimal}}

*(이에 대한 더 많은 수학적 내용은 (놀라운) Jianlin Su의 시리즈를 참고해라: **https://kexue.fm/archives/11260)***

AdamW 또는 Muon과 같은 옵티마이저에 대한 유용한 경험 법칙은 배치 크기가 증가함에 따라 제곱근 LR 스케일링을 하는 것이지만, 이것은 또한 옵티마이저에 따라 달라진다. 예를 들어 AdamW를 사용하면 매우 다른 동작을 유발할 수 있는 beta1 / beta2와의 상호 작용이 있다. 실용적인 대안은 학습을 짧은 기간 동안 분기하는 것이다: 하나의 실행은 원래 배치로 유지하고, 두 번째는 더 큰 배치와 재조정된 LR로 시작하며, 재조정 후 두 손실 곡선이 일치하는 경우에만 더 큰 배치를 채택한다 (Merrill et al., 2025). 논문에서, 그들은 배치 크기를 전환할 때 학습률을 다시 웜업하고 옵티마이저 상태를 재설정한다. 그들은 또한 손실이 “일치”하는지 결정하기 위해 허용 오차와 시간 창을 설정하며, 두 노브(knob)는 경험적으로 선택된다. 그들은 $B_{\text{simple}}$ 추정치 (이 또한 노이즈가 많음)가 “실제” 임계 배치 크기를 과소평가하고 있음을 발견했다. 이것은 새로운 배치/LR 쌍이 학습 역학을 보존하는지 빠르고 위험 부담이 적은 확인을 제공한다.

임계 배치 크기는 고정되어 있지 않으며, 학습이 진행됨에 따라 커진다. 학습 초기에는 모델이 큰 기울기 단계를 밟으므로 $\|g\|^2$ 가 크며 이는 $B_{\text{simple}}$ 이 작다는 것을 의미하므로, 모델은 더 작은 임계 배치 크기를 가진다. 나중에 모델 업데이트가 안정화됨에 따라 더 큰 배치가 더 효과적이게 된다. 이것이 일부 대규모 학습에서 배치 크기를 일정하게 유지하지 않고 우리가 배치 크기 웜업이라고 부르는 것을 사용하는 이유이다. 예를 들어, DeepSeek-V3는 처음 ~469B 토큰에 대해 1260만 배치로 시작한 다음, 나머지 학습 동안 6290만으로 증가시켰다. 이와 같은 배치 크기 웜업 스케줄은 학습률 웜업과 동일한 목적을 수행한다: 기울기 노이즈 규모가 커짐에 따라 모델을 효율적인 경계(efficient frontier)에 유지하여 전체적으로 안정적이고 효율적인 최적화를 유지하는 것이다.

또 다른 흥미로운 접근 방식은 손실을 임계 배치 크기에 대한 대리 지표로 취급하는 것이다. Minimax01이 이것을 사용했으며 마지막 단계에서 그들은 1억 2800만 배치 크기로 학습시켰다! 이것은 그들이 학습률을 증가시키지 않기 때문에 약간 다른데, 따라서 그들의 배치 크기 스케줄은 학습률 감쇠 스케줄처럼 작동한다.

배치 크기 및 학습률 튜닝

실제 상황에서는, 배치 크기와 학습률을 선택하는 방법은 다음과 같다:

스케일링 법칙 (나중에 설명!) 또는 문헌에서 최적이라고 생각하는 배치 크기와 학습률을 먼저 선택한다.
그런 다음, 학습 처리량을 향상시킬 수 있는지 확인하기 위해 배치 크기를 튜닝할 수 있다.

핵심 통찰은 시작 배치 크기와 임계 배치 크기 사이에 데이터 효율성을 희생하지 않으면서 하드웨어 활용도를 높이기 위해 배치 크기를 늘릴 수 있는 범위가 종종 있다는 것이다. 그러나 이에 따라 학습률은 재조정되어야 한다. 처리량 이득이 크지 않거나, (재조정된 학습률로) 더 큰 배치 크기를 테스트했을 때 더 나쁜 데이터 효율성을 보인다면, 초기 값을 고수해라.

위의 참고 사항에서 언급했듯이, 배치 크기와 학습률에 대한 시작점을 선택하는 한 가지 방법은 스케일링 법칙을 통하는 것이다. 이러한 스케일링 법칙이 어떻게 작동하고 컴퓨팅 예산의 함수로서 두 하이퍼파라미터를 어떻게 예측하는지 살펴보자.

하이퍼파라미터에 대한 스케일링 법칙

최적의 학습률과 배치 크기는 단지 모델 아키텍처와 크기에만 관련된 것이 아니라, 모델 매개변수 수와 학습 토큰 수를 모두 결합한 컴퓨팅 예산에도 의존한다. 실제에서, 이 두 가지 요소는 상호 작용하여 업데이트가 얼마나 공격적이거나 보수적이어야 하는지를 결정한다. 여기서 스케일링 법칙이 등장한다.

스케일링 법칙은 더 큰 모델이나 더 많은 학습 데이터를 통해 학습 규모를 늘림에 따라 모델 성능이 어떻게 진화하는지 설명하는 경험적 관계를 확립한다 (전체 역사는 이 장 끝의 “스케일링 법칙” 섹션 참조). 그러나 스케일링 법칙은 또한 DeepSeek 및 Qwen2.5의 최근 작업에서 수행된 것처럼, 학습을 확장함에 따라 학습률 및 배치 크기와 같은 주요 하이퍼파라미터를 조정하는 방법을 예측하는 데 도움을 줄 수 있다. 이것은 하이퍼파라미터 스윕에 전적으로 의존하는 대신 원칙에 입각한 기본값을 제공해준다.

이 맥락에서 스케일링 법칙을 적용하려면, 학습 규모를 정량화할 방법이 필요하다. 표준 측정 기준은 C 로 표시되고 FLOPs로 측정되는 컴퓨팅 예산이며, 다음과 같이 근사할 수 있다:

C≈6×N×D

N 은 모델 매개변수의 수이고 (예: 1B = 1e9), D 는 학습 토큰의 수이다. 이것은 종종 실제 계산이 얼마나 수행되고 있는지를 정량화하는 하드웨어-agnostic 한 방법인 FLOPs (부동 소수점 연산)로 측정된다. 그러나 FLOPs가 너무 추상적으로 느껴진다면, 이렇게 생각해라: 100B 토큰에 대해 1B 매개변수 모델을 학습시키는 것은 100B 토큰에 대해 2B 모델을 학습시키거나, 200B 토큰에 대해 1B 모델을 학습시키는 것보다 약 2배 적은 FLOPs를 소비한다.

상수 6은 트랜스포머를 학습시키는 데 필요한 부동 소수점 연산 수에 대한 경험적 추정치에서 비롯되며, 대략 토큰당 매개변수당 6 FLOPs이다.

(MoE 레이어 및 하이브리드 레이어를 고려한 더 정확한 측정을 원한다면 Megatron-LM의 num_floating_point_operations 함수를 확인할 수 있다.)

이제, 이것이 학습률과 어떻게 관련되어 있을까? 우리는 총 컴퓨팅 예산 (C)의 함수로서 최적의 학습률과 배치 크기를 예측하는 스케일링 법칙을 도출할 수 있다. 그들은 다음과 같은 질문에 답하는 데 도움이 된다:

1B에서 7B 매개변수로 확장할 때 학습률은 어떻게 변해야 하는가?
학습 데이터를 두 배로 늘리면 학습률을 조정해야 하는가?

DeepSeek가 사용한 접근 방식을 따라 이것이 어떻게 작동하는지 살펴보자: 먼저, 유연성을 위해 이상적으로는 WSD인 학습률 스케줄을 선택한다. 그런 다음, 다양한 배치 크기와 학습률 조합으로 다양한 컴퓨팅 예산 (예: 1e17, 5e17, 1e18, 5e18, 1e19, 2e19 FLOPs)에 걸쳐 모델을 학습시킨다. 더 간단한 용어로: 우리는 다른 토큰 수에 대해 다른 모델 크기를 학습시키며, 다른 하이퍼파라미터 설정을 테스트한다. 이것이 WSD 스케줄이 빛나는 부분인데, 우리는 재시작 없이 동일한 학습 실행을 다른 토큰 수로 확장할 수 있다.

각 설정에 대해, 우리는 학습률과 배치 크기에 대한 스윕을 수행하고 최적에 가까운 성능 (일반적으로 학습 세트와 유사한 분포를 가진 독립적인 검증 세트에서 계산된 최고의 검증 손실의 작은 마진 (예: 0.25%) 내에 있는 것으로 정의됨)을 만들어내는 구성을 식별한다. 각 최적에 가까운 구성은 우리에게 데이터 포인트 — (컴퓨팅 예산 C, 최적 학습률 η) 또는 (C , 최적 배치 크기 B)의 튜플을 제공하게 된다. 이를 로그-로그 스케일로 그려보면, 이러한 관계는 일반적으로 거듭제곱 법칙의 모습을 보이며, 대략 직선으로 나타난다 (위 그림 참조). 이러한 데이터 포인트를 피팅함으로써, 우리는 최적의 하이퍼파라미터가 컴퓨팅에 따라 어떻게 진화하는지 설명하는 스케일링 법칙을 추출할 수 있다.

이 과정에서 중요한 발견은 고정된 모델 크기와 컴퓨팅 예산에 대해, 광범위한 하이퍼파라미터에 걸쳐 성능이 안정적으로 유지된다는 것이다. 이는 좁은 최적점이 아니라 넓은 스위트 스폿(sweet spot)이 있다는 것을 의미한다. 우리는 완벽한 값을 찾을 필요가 없으며, 충분히 가까운 값만 찾으면 되므로 전체 프로세스가 훨씬 더 실용적이다.

여기서 각 점이 최적에 가까운 설정을 나타내는 DeepSeek가 도출한 스케일링 법칙의 결과를 볼 수 있다:

이러한 결과 뒤에 숨겨진 핵심 직관은 학습이 더 커지고 길어짐에 따라, 우리는 더 안정적인 업데이트 (따라서 더 작은 학습률)와 더 효율적인 기울기 추정 (따라서 더 큰 배치 크기)을 원하게 된다는 것이다.

이러한 스케일링 법칙은 우리에게 학습률과 배치 크기에 대한 시작점을 제공한다. 그러나 목표는 “기울기당 최적의 샘플”이 아니라 “시간 및 GPU 제약 내에서 도달 가능한 더 낮은 손실”이면서 여전히 모든 토큰에서 전체 신호를 추출하는 것이다.

실제 상황에서, 당신은 데이터 효율성을 의미 있게 해치지 않으면서 처리량을 크게 향상시키기 위해, 앞서 논의한 임계 배치 크기까지 예측된 최적 배치 크기 이상으로 배치 크기를 늘릴 수 있을지도 모른다.

SmolLM3

그렇다면 우리는 SmolLM3에 무엇을 사용했는가? SmolLM3를 시작하기 전 제거 실험 당시, 우리는 100B 토큰으로 학습된 1B 모델에서 AdamW, AdEMAMix, 그리고 Muon을 비교했다. Muon은 적절히 튜닝될 때 AdamW를 능가할 수 있었지만 학습률에 민감했고 발산하기 쉬웠다. AdeMaMix는 덜 민감했고 Muon과 유사한 손실을 달성했다. AdamW는 가장 안정적이었지만 튜닝된 대안들보다 더 높은 최종 손실에 도달했다.

그러나 3B으로 확장했을 때, 우리는 Muon과 AdeMaMix에서 더 빈번한 발산을 겪었다. 이는 우리가 제거 실험을 마친 후 발견한 병렬 처리 버그 때문일 수 있지만 (학습 마라톤 챕터 참조), 우리는 이것을 확신하지 못했다. 우리는 가중치 감쇠 0.1 및 기울기 클리핑 1을 사용하는 AdamW (beta1: 0.9, beta2: 0.95)를 사용하기로 결정했다. 결국 매우 평범한(vanilla) 설정이다.

학습률 스케줄의 경우, 우리는 WSD를 선택했다. 우리는 SmolLM2에서 그것을 성공적으로 사용했었으며, 사용 용이성과 총 학습 기간에 대한 유연성, 그리고 중간 학습 감쇠 실험을 실행할 수 있는 능력 측면에서 최고의 결정 중 하나임이 입증되었다. 우리는 학습률 스윕을 실행하고 2e-4에 정착했다. 전역 배치 크기의 경우, 우리는 2M에서 4M 토큰의 값을 테스트했지만 손실이나 다운스트림 성능에 미치는 영향이 미미하다는 것을 발견하여, 최고의 처리량을 제공하는 크기인 2.36M 토큰을 선택했다.

참여 규칙

요약: 탐색과 실행의 균형을 맞춘다. 완료된 것이 완벽한 것보다 낫다.

우리는 “무엇” (옵티마이저, 학습률, 배치 크기)에 대해 많이 이야기했지만 “어떻게”도 그만큼 중요하다. 실험할 가치가 있는 것을 어떻게 결정할까? 시간을 어떻게 구조화할까? 언제 탐색을 멈추고 학습을 시작할까?

탐색과 실행 사이에 시간을 현명하게 할당하라. 새로운 방법의 사소한 개선을 완벽하게 하는 데 몇 주를 보내는 것은 더 나은 데이터 큐레이션이나 더 철저한 아키텍처 제거 실험에 같은 컴퓨팅을 투자하는 것보다 가치가 적다. 우리의 경험상, 그리고 아키텍처 애호가들을 실망시킬 수도 있지만, 가장 큰 성능 향상은 일반적으로 데이터 큐레이션에서 나온다.

의심스러울 때는 최고 성능보다 유연성과 안정성을 선택해라. 두 방법이 똑같이 잘 수행된다면, 더 많은 유연성을 제공하거나 구현 성숙도와 안정성이 더 나은 것을 선택한다. 학습을 확장하거나 중간 학습 실험을 실행할 수 있게 해주는 WSD와 같은 학습률 스케줄은 약간 더 잘 수렴할 수 있는 엄격한 스케줄보다 더 가치가 있다.

언제 최적화를 멈추고 학습을 시작할지 알아라. 튜닝할 하이퍼파라미터는 항상 하나 더 있거나 시도할 옵티마이저는 하나 더 있다. 탐색을 위한 마감일을 설정하고 그것을 고수한다 - 우리가 실제로 학습을 완료한 모델은 우리가 결코 시작하지 않은 완벽한 모델을 항상 이길 것이다.

제거 실험 하나만 더 한다고 해를 끼치진 않겠지 (스포일러: 해를 끼쳤다)

완벽함은 좋음의 적이다, 특히 우리가 유한한 컴퓨팅 예산과 마감일로 작업할 때는 더욱 그렇다.

스케일링 법칙: 매개변수는 얼마나 많이, 데이터는 얼마나 많이 필요한가?

딥러닝 초기 시절, 언어 모델(그리고 그것들이 학습된 클러스터)이 “거대”하기 전에는, 학습 실행은 종종 컴퓨팅 자원에 의해 심하게 제약받지 않았다. 모델을 학습시킬 때, 여러분은 하드웨어에 맞는 가장 큰 모델과 배치 크기를 선택하고 모델이 과적합되기 시작하거나 데이터가 바닥날 때까지 학습시켰을 것이다. 하지만 이 초기 시절에도 규모가 도움이 된다는 감각이 있었다 — 예를 들어, Hestness et al.은 2017년에 더 큰 모델을 더 오래 학습시키는 것이 예측 가능한 이득을 낳는다는 것을 보여주는 포괄적인 결과 세트를 제공했다.

거대 언어 모델의 시대에, 우리는 항상 컴퓨팅 제약을 받는다. 왜일까? 이러한 초기의 확장성 개념은 신경 언어 모델을 위한 스케일링 법칙에 관한 Kaplan et al.의 연구에 의해 공식화되었는데, 여기서 언어 모델 성능이 여러 규모의 자릿수에 걸쳐 놀랍도록 예측 가능하다는 것이 밝혀졌다. 이것은 언어 모델의 크기와 학습 기간의 폭발적인 증가를 촉발했는데, 규모를 늘림으로써 성능이 얼마나 향상될지 정확하게 예측할 수 있는 방법을 제공했기 때문이다. 결과적으로, 더 나은 언어 모델을 구축하려는 경쟁은 끊임없이 증가하는 컴퓨팅 예산으로 더 방대한 데이터에 대해 더 큰 모델을 학습시키는 경쟁이 되었고, 언어 모델의 개발은 빠르게 컴퓨팅 제약을 받게 되었다.

컴퓨팅 제약에 직면했을 때, 가장 중요한 질문은 더 큰 모델을 학습시킬지 아니면 더 많은 데이터로 학습시킬지 여부이다. 놀랍게도, Kaplan et al.의 스케일링 법칙은 이전의 모범 사례보다 모델 규모에 훨씬 더 많은 컴퓨팅을 할당하는 것이 유리하다는 것을 시사했다 — 예를 들어, 거대한 (175B 매개변수) GPT-3 모델을 비교적 적은 토큰 예산 (300B 토큰)으로 학습시키도록 동기를 부여했다. 재검토 결과, Hoffman et al.은 Kaplan et al.의 접근 방식에서 방법론적 문제를 발견했고, 궁극적으로 학습 기간에 훨씬 더 많은 컴퓨팅을 할당할 것을 제안하는 스케일링 법칙을 재도출했다. 이는 예를 들어 175B 매개변수 GPT-3의 컴퓨팅 최적 학습이 3.7T 토큰을 소비했어야 함을 보여주었다!

이것은 이 분야를 “모델을 더 크게 만들기”에서 “더 길고 더 잘 학습시키기”로 전환시켰다. 그러나 대부분의 현대 학습은 여전히 친칠라 법칙들을 엄격하게 따르지는 않는데, 왜냐하면 그것들에 단점이 있기 때문이다: 그들은 특정 컴퓨팅 예산이 주어졌을 때 최고의 성능을 달성하는 모델 크기와 학습 기간을 예측하는 것을 목표로 하지만, 더 큰 모델은 학습 후(추론 시)에 더 비싸다는 사실을 고려하지 않았다. 달리 말하면, 우리는 주어진 컴퓨팅 예산을 사용하여 더 작은 모델을 더 오래 학습시키는 것을 선호할 수 있다 — 비록 이것이 “컴퓨팅 최적”이 아닐지라도 — 왜냐하면 이것이 추론 비용을 더 저렴하게 만들 것이기 때문이다 (Sardana et al., de Vries). 이는 모델이 많은 추론 사용량을 보일 것으로 예상되는 경우 (예를 들어, 오픈소스로 공개되기 때문에 🤗)에 해당할 수 있다. 최근, 스케일링 법칙이 제안한 학습 기간을 넘어 모델을 “과잉 학습(overtraining)“시키는 이러한 관행은 표준이 되었으며, 우리가 SmolLM3를 개발할 때 취한 접근 방식이다.

스케일링 법칙이 특정 컴퓨팅 예산이 주어졌을 때 모델 크기와 학습 기간에 대한 제안을 제공해주기는 하지만, 과잉 학습을 선택한다는 것은 여러분이 이러한 요소들을 직접 결정해야 한다는 것을 의미한다. SmolLM3의 경우, 우리는 3B 매개변수의 목표 모델 크기를 선택하는 것으로 시작했다. Qwen3 4B, Gemma 3 4B, Llama 3.2 3B와 같은 유사한 규모의 최근 모델들을 기반으로, 우리는 3B가 의미 있는 능력 (추론 및 도구 호출과 같은)을 갖기에 충분히 크지만, 초고속 추론과 효율적인 로컬 사용을 가능하게 할 만큼 충분히 작다고 판단했다. 학습 기간을 선택하기 위해, 우리는 먼저 최근 모델들이 극도로 과잉 학습되었다는 점에 주목했다 — 예를 들어, 앞서 언급한 Qwen3 시리즈는 36T 토큰 동안 학습되었다고 주장된다! 결과적으로, 학습 기간은 종종 사용 가능한 컴퓨팅의 양에 의해 좌우된다. 우리는 약 한 달 동안 384개의 H100을 확보했으며, 이는 11조 토큰에 대한 학습 예산을 제공했다 (MFU를 약 ~30%로 가정).

스케일링 법칙

이러한 간극에도 불구하고, 스케일링 법칙은 여전히 실질적으로 가치가 있다. 그것들은 실험 설계를 위한 기준선을 제공하고, 사람들은 종종 제거 실험에서 신호를 얻기 위해 친칠라 최적 설정을 사용하며, 모델 크기가 목표 성능에 도달할 수 있는지 예측하는 데 도움을 준다. de Vries가 이 블로그에서 언급했듯이, 모델 크기를 줄임으로써 임계 모델 크기에 도달할 수 있다: 이는 주어진 손실에 도달하기 위해 필요한 최소한의 용량이며, 그 이하에서는 수확 체감이 발생하기 시작한다.

이제 모델 아키텍처, 학습 설정, 모델 크기, 그리고 학습 기간을 확정했으므로, 우리는 두 가지 중요한 구성 요소를 준비해야 한다: 모델을 가르칠 데이터 혼합(Data Mixture)과 그것을 안정적으로 학습시킬 인프라이다. SmolLM3의 아키텍처가 3B 매개변수로 설정됨에 따라, 우리는 강력한 다국어, 수학 및 코드 성능을 제공할 데이터 혼합을 큐레이션하고 11T 토큰의 학습을 견딜 만큼 견고한 인프라를 설정해야 했다. 이러한 기본 사항을 올바르게 파악하는 것이 필수적이며, 최고의 아키텍처 선택조차도 열악한 데이터 큐레이션이나 불안정한 학습 시스템으로부터 우리를 구해주지는 못할 것이다.

The art of data curation

상상해 보라: 여러분은 아키텍처를 완벽하게 만들고, 하이퍼파라미터를 튜닝하고, 가장 견고한 학습 인프라를 설정하는 데 몇 주를 보냈다. 모델은 아름답게 수렴하지만, 막상… 일관성 있는 코드를 작성하지 못하고, 기초 수학에 어려움을 겪으며, 심지어 문장 중간에 언어를 바꾸기도 한다. 무엇이 잘못되었을까? 답은 대개 데이터에 있다. 우리가 화려한 아키텍처 혁신과 하이퍼파라미터 스윕에 집착하는 동안, 데이터 큐레이션은 종종 우리 모델이 진정으로 유용해질지 아니면 그저 또 하나의 비싼 실험이 될지를 결정한다. 그것은 무작위 웹 크롤링 데이터로 학습하는 것과 우리가 모델이 배우기를 원하는 기술을 실제로 가르치는 신중하게 큐레이션된 고품질 데이터셋으로 학습하는 것의 차이이다.

모델 아키텍처가 모델이 어떻게 학습하는지를 정의한다면, 데이터는 모델이 무엇을 학습하는지를 정의하며, 아무리 많은 컴퓨팅이나 옵티마이저 튜닝도 잘못된 콘텐츠로 학습하는 것으로부터 성능을 보정해줄 수 없다. 게다가, 학습 데이터를 올바르게 얻는 것은 단지 좋은 데이터셋을 갖는 것만이 아니다. 그것은 올바른 **혼합(mixture)**을 조립하는 것에 관한 것이다: 상충되는 목표들 (예: 강력한 영어 대 견고한 다국어성)의 균형을 맞추고 우리의 성능 목표에 맞게 데이터 비율을 조정하는 것이다. 이 과정은 보편적인 최고의 혼합을 찾는 것이 아니라, 올바른 질문을 던지고 그에 답하기 위한 구체적인 계획을 고안하는 것에 가깝다:

우리는 모델이 무엇을 잘하기를 원한가?
각 도메인에 가장 적합한 데이터셋은 무엇이며 어떻게 혼합해야 하는가?
우리의 목표 학습 규모에 맞는 충분한 고품질 데이터를 가지고 있는가?

이 섹션은 훌륭한 데이터셋 더미를 훌륭한 학습 혼합(training mixture)으로 바꾸기 위해 원칙에 입각한 방법, 제거 실험, 그리고 약간의 연금술을 혼합하여 이러한 질문들을 헤쳐나가는 것에 관해 다룰 것이다.

좋은 데이터 혼합이란 무엇이며 왜 가장 중요한가

우리는 언어 모델에 많은 것을 기대한다. 그들은 코드를 작성하는 것을 돕고, 조언을 주고, 거의 모든 것에 대한 질문에 답하고, 도구를 사용하여 작업을 완료하는 등의 일을 할 수 있어야 한다. 웹과 같은 풍부한 사전 학습 데이터 소스는 이러한 작업에 필요한 지식과 기능의 전체 범위를 포괄하지 않는다. 결과적으로, 최근 모델들은 수학 및 코딩과 같은 특정 도메인을 목표로 하는 더 전문화된 사전 학습 데이터셋에 추가로 의존하고 있다. 우리는 과거에 데이터셋 큐레이션에 대해 많은 작업을 해왔지만, SmolLM3의 경우 주로 기존 데이터셋을 활용했다. 데이터셋 큐레이션에 대해 더 자세히 알아보려면 FineWeb 및 FineWeb-Edu, FineWeb2, Stack-Edu, 그리고 FineMath 구축에 대한 우리의 보고서를 확인한다.

데이터 혼합의 직관에 반하는 본질

언어 모델 학습이 처음이라면, 좋은 데이터 혼합을 찾는 것이 간단해 보일 수 있다: 목표 기능을 식별하고, 각 도메인에 대한 고품질 데이터셋을 수집하고, 결합하면 될 것 같다. 현실은 더 복잡한데, 일부 도메인은 학습 예산을 두고 서로 경쟁할 수 있기 때문이다. 코딩과 같은 특정 기능에 집중할 때, 소스 코드와 같은 작업 관련 데이터의 가중치를 높이고 싶은 유혹이 있을 수 있다. 그러나 한 소스의 가중치를 높이는 것은 암시적으로 다른 모든 소스의 가중치를 낮추는 것이며, 이는 다른 설정에서 언어 모델의 기능을 해칠 수 있다. 따라서 다양한 소스의 모음으로 학습하는 것은 다운스트림 기능들 사이에서 일종의 균형을 맞추는 것을 포함한다.

또한, 이러한 모든 소스와 도메인 전반에 걸쳐, 언어 모델의 기능을 개선하는 데 특히 도움이 되는 “고품질” 데이터의 하위 집합이 종종 있다. 왜 그냥 모든 낮은 품질의 데이터를 버리고 최고 품질의 데이터로만 학습하지 않는가? SmolLM3의 11조 토큰이라는 대규모 학습 예산의 경우, 그러한 극단적인 필터링을 하면 데이터가 여러 번 반복되는 결과를 낳을 것이다. 이전 연구는 이런 종류의 반복이 해로울 수 있음을 보여주었으므로 (Muennighoff et al., 2025), 우리는 이상적으로 모델 성능을 여전히 최대화하면서 더 높은 품질과 더 낮은 품질의 데이터를 모두 활용할 수 있어야 한다.

소스 간 데이터 균형을 맞추고 고품질 데이터를 활용하기 위해, 우리는 **혼합(mixture)**을 신중하게 설계해야 한다: 각 소스에서 가져온 학습 문서의 상대적 비율이다. 특정 작업이나 도메인에 대한 언어 모델의 성능은 해당 작업과 관련된 데이터의 양에 크게 의존하므로, 혼합 가중치를 튜닝하는 것은 도메인 전반에 걸쳐 모델 기능의 균형을 맞추는 직접적인 방법을 제공한다. 이러한 트레이드오프는 모델에 따라 다르고 예측하기 어렵기 때문에, 제거 실험은 필수적이다.

그러나 혼합이 학습 내내 고정되어 있을 필요는 없다. 학습이 진행됨에 따라 혼합을 조정함으로써 (우리가 다단계 학습(multi-stage training) 또는 커리큘럼(curriculum)이라고 부르는 것), 우리는 고품질 데이터와 저품질 데이터 모두를 더 잘 활용할 수 있다.

학습 커리큘럼의 진화

거대 언어 모델 학습의 초기에는 전체 학습 실행에 대해 단일 데이터 혼합을 고정하는 것이 표준 접근 방식이었다. GPT3 및 Llama의 초기 버전과 같은 모델들은 시작부터 끝까지 정적 혼합으로 학습했다. 더 최근에, 이 분야는 학습 과정에 걸쳐 데이터 혼합이 변하는 다단계 학습 (Allal et al., 2025)으로 이동했다. 주요 동기는 언어 모델의 최종 행동이 학습 끝 무렵에 본 데이터에 의해 강하게 영향을 받는다는 것이다 (Y. Chen et al., 2025b). 이 통찰력은 실용적인 전략을 가능하게 했다: 학습 초기에는 더 풍부한 소스의 가중치를 높이고 끝으로 갈수록 더 적고 더 높은 품질의 소스를 혼합하는 것이다.

흔한 질문은: 혼합을 변경할 시점을 어떻게 결정하는가? 보편적인 규칙은 없지만, 우리는 일반적으로 다음 원칙을 따른다:

성능 주도 개입: 주요 벤치마크에서 평가 지표를 모니터링하고 특정 기능의 병목 현상을 해결하기 위해 데이터셋 혼합을 조정한다. 예를 들어, 다른 기능들은 계속 개선되는데 수학 성능이 정체된다면, 그것은 더 높은 품질의 수학 데이터를 도입하라는 신호이다.
고품질 데이터를 후반 단계를 위해 아끼기: 작고 고품질인 수학 및 코드 데이터셋은 어닐링 단계 (학습률 감쇠가 있는 최종 단계) 동안 도입될 때 가장 큰 영향을 미친다.

이제 혼합이 왜 중요한지, 그리고 커리큘럼이 어떻게 작동하는지 확립했으므로, 두 가지를 튜닝하는 방법에 대해 논의하자.

제거 실험 설정: 데이터 레시피를 체계적으로 테스트하는 방법

데이터 혼합을 테스트할 때, 우리의 접근 방식은 아키텍처 제거 실험을 실행하는 방식과 유사하지만 한 가지 차이점이 있다: 우리는 목표 모델 규모에서 실행하려고 노력해야 한다. 작은 모델과 큰 모델은 다른 용량을 가지고 있다. 예를 들어, 매우 작은 모델은 많은 언어를 처리하는 데 어려움을 겪을 수 있는 반면, 더 큰 모델은 다른 곳에서 성능을 희생하지 않고 그것들을 흡수할 수 있다. 따라서 너무 작은 규모에서 데이터 제거 실험을 실행하면 최적의 혼합에 대해 잘못된 결론을 도출할 위험이 있다.

SmolLM3의 경우, 우리는 50B 및 100B 토큰의 더 짧은 학습 실행을 사용하여 30B모델에서 직접 주요 데이터 제거 실험을 실행했다. 우리는 또한 다른 유형의 제거 실험 설정을 사용했다: 어닐링(annealing) 실험이다. 다른 혼합으로 처음부터 학습하는 대신, 우리는 주 실행에서 중간 체크포인트 (예를 들어 7조 토큰에서)를 가져와 수정된 데이터 구성으로 학습을 계속했다. 이 접근 방식은 다단계 학습 (즉, 학습 중간에 학습 혼합 변경)을 위한 데이터 혼합 변경을 테스트할 수 있게 해주며, SmolLM2, Llama3 및 Olmo2와 같은 최근 작업에서 사용되었다. 평가를 위해, 우리는 표준 영어 평가와 함께 다국어 작업을 포함하도록 벤치마크 스위트를 확장하여 다른 언어 비율 간의 트레이드오프를 적절하게 평가할 수 있도록 보장했다.

스크린샷 2025-12-02 오후 3.34.49.png

최근 연구는 최적의 데이터 비율을 찾기 위한 자동화된 접근 방식을 제안한다.:

DoReMi (Xie et al., 2023): 작은 프록시 모델을 사용하여 validation 손실을 최소화하는 도메인 가중치를 학습한다.
Rho Loss (Mindermann et al., 2022): 홀드아웃(holdout) 손실을 기반으로 개별 학습 포인트를 선택하여, 학습 가능하고, 작업 관련성이 있으며, 모델에 의해 아직 학습되지 않은 샘플을 우선시한다.
RegMix (Q. Liu et al., 2025): 여러 평가 목표 및 데이터 도메인 전반의 성능 균형을 맞추는 정규화 회귀를 통해 최적의 데이터 혼합 비율을 결정한다.

우리는 과거 프로젝트에서 DoReMi와 Rho Loss를 실험했지만, 그것들이 데이터셋 크기의 자연스러운 분포를 대략 반영하는 분포로 수렴하는 경향이 있음을 발견했다. 본질적으로 우리가 더 많이 가지고 있는 것을 더 많이 사용하라고 제안하는 것이다. 이론적으로 매력적이지만, 우리가 직접 설정한 신중한 수동 제거 실험보다 성능이 우수하지 않았다. 최근 SOTA 모델들은 여전히 체계적인 제거 실험 및 어닐링 실험을 통한 수동 혼합 튜닝에 의존하며, 이는 우리가 SmolLM3에 채택한 접근 방식이다.

SmolLM3: 데이터 혼합 큐레이션 (웹, 다국어, 수학, 코드)

SmolLM3의 경우, 우리는 영어와 여러 다른 언어를 처리할 수 있고 수학과 코드에서 뛰어난 모델을 원했다. 이러한 도메인 — 웹 텍스트, 다국어 콘텐츠, 코드 및 수학 — 은 대부분의 LLM에서 일반적이지만, 우리가 여기서 설명할 프로세스는 저자원 언어나 금융 또는 의료와 같은 특정 도메인을 위해 학습하는 경우에도 동일하게 적용된다. 방법은 동일하다: 좋은 후보 데이터셋을 식별하고, 제거 실험을 실행하고, 모든 목표 도메인의 균형을 맞추는 혼합을 설계하는 것이다.

우리는 고품질 데이터셋을 구축하는 방법은 여기서 다루지 않을 것이다. 이전 작업 (FineWeb, FineWeb2, FineMath 및 Stack-Edu)에서 광범위하게 자세히 설명했기 때문이다. 대신, 이 섹션은 그러한 데이터셋들을 효과적인 사전 학습 혼합으로 결합하는 방법에 중점을 둔다.

검증된 기반 위에 구축하기

사전 학습 데이터에 대한 좋은 소식은 우리가 거의 처음부터 시작할 필요는 없다는 것이다. 오픈 소스 커뮤니티는 이미 대부분의 일반적인 도메인에 대한 강력한 데이터셋을 구축해왔다. 때로는 우리가 Fine 시리즈 (FineWeb, FineMath 등)와 함께 했던 것처럼 새로운 것을 만들어야 할 필요가 있을 수는 있지만, 도전은 기존 소스를 다시 발명하는 것이 아니라 선택하고 결합하는 데에 더 흔하다.

그것이 SmolLM3에서의 우리 상황이었다. SmolLM2는 이미 영어 웹 데이터에 대해 1.7B 매개변수에서 강력한 레시피를 확립했고, 우리가 접근할 수 있는 최고의 수학 및 코드 데이터셋로 확인되었다. 우리의 목표는 특정 기능들을 추가하면서 그 성공을 3B으로 확장하는 것이었다: 견고한 다국어성, 더 강력한 수학적 추론, 그리고 더 나은 코드 생성이다.

영어 웹 데이터: 기초 레이어

웹 텍스트는 모든 범용 LLM의 중추를 형성하지만, 품질은 양만큼이나 중요하다.

SmolLM3로부터, 우리는 FineWeb-Edu와 DCLM이 학습 당시 가장 강력한 오픈 영어 웹 데이터셋이라는 것을 알고 있었다. 함께, 그들은 우리에게 5.1조 토큰의 고품질 영어 웹 데이터를 제공했다. 이 때 질문은: 최적의 혼합 비율은 무엇인가? 이다. FineWeb-Edu는 교육 및 STEM 벤치마크에 도움이 되는 반면, DCLM은 상식 추론을 개선한다.

SmolLM2 방법론을 따르며, 우리는 3B 모델에서 100B 토큰에 대해 스윕을 실행하여 20/80, 40/60, 50/50, 60/40, 및 80/20 (FineWeb-Edu/DCLM) 비율을 테스트했다. 그것들을 혼합하는 것 (약 60/40 또는 50/50으로)이 최고의 트레이드오프를 제공했다. 우리는 100B 토큰으로 학습된 3B 모델에서 SmolLM2 논문과 동일한 제거 실험을 다시 실행했고 동일한 결론을 얻었다.

60/40 또는 50/50을 사용하는 것이 벤치마크 전반에 걸쳐 가장 좋은 균형을 제공하여, 우리의 SmolLM2 발견과 일치했다. 우리는 1단계(Stage 1)에 50/50 비율을 사용했다.

우리는 또한 Pes2o, Wikipedia & Wikibooks 및 StackExchange와 같은 다른 데이터셋을 추가했다. 이러한 데이터셋은 성능에 영향을 미치지 않았지만 다양성을 개선하기 위해 포함시켰다.

다국어 웹 데이터

다국어 기능을 위해, 우리는 5개의 다른 언어를 목표로 삼았다: 프랑스어, 스페인어, 독일어, 이탈리아어, 그리고 포르투갈어이다. 우리는 FineWeb2-HQ에서 그것들을 선택했는데, 이는 우리에게 총 628B 토큰을 제공했다. 우리는 또한 중국어, 아랍어, 러시아어와 같은 10개의 다른 언어를 더 작은 비율로 포함시켰다. 이는 그것들에 대해 최첨단 성능을 목표로 하기 위함이 아니라, 사람들이 그것들에 대해 SmolLM3의 지속 사전 학습(continual pretraining)을 쉽게 수행할 수 있도록 하기 위함이었다. 우리는 FineWeb2-HQ에서 지원되지 않는 언어에는 FineWeb2를 사용했다.

핵심 질문은 이것이다: 우리 웹 데이터의 얼마나 많은 부분이 비영어여야 하는가? 우리는 모델이 언어나 도메인에서 더 많은 데이터를 볼수록 해당 언어나 도메인에서 더 좋아진다는 것을 안다. 트레이드오프는 우리의 고정된 컴퓨팅 예산에서 비롯된다: 한 언어에 대한 데이터를 늘리는 것은 영어를 포함한 다른 언어에 대한 데이터를 줄이는 것을 의미하게 된다.

3B 모델에 대한 제거 실험을 통해, 우리는 웹 혼합에서 12% 다국어 콘텐츠가 올바른 균형을 이루어 영어 벤치마크를 저하시키지 않으면서 다국어 성능을 향상시킨다는 것을 발견했다. 이것은 영어가 주 언어로 남을 SmolLM3의 예상 사용량에 맞았다. 또한 5.1T 영어 토큰에 비해 단지 628B 토큰의 비영어 데이터만 가지고 있으므로, 훨씬 더 높게 가는 것은 다국어 데이터의 더 많은 반복을 수행해야 한다는 점도 고려할만했다.

코드 데이터

1단계를 위한 우리의 코드 소스는 The Stack v2와 StarCoder2 학습 코퍼스에서 추출되었다:

우리의 기초로서 The Stack v2 (16개 언어), StarCoder2Data로 필터링됨.
실제 코드 리뷰 추론을 위한 StarCoder2 GitHub 풀 리퀘스트.
실행 가능한 단계별 워크플로를 위한 Jupyter 및 Kaggle 노트북.
코드 주변의 맥락적 토론을 위한 GitHub 이슈 및 StackExchange 스레드.

Aryabumi et al. (2024)은 코드가 코딩을 넘어 언어 모델의 성능을 향상시킨다는 점을 강조했다. 예를 들어 자연어 추론 및 세계 지식에서 그렇다. 그리고 학습 혼합에 25% 코드를 사용할 것을 권장한다. 이 논문으로부터 동기를 부여받아, 우리는 혼합에 25% 코드로 제거 실험을 시작했다. 그러나 우리는 영어 벤치마크 (HellaSwag, ARC-C, MMLU)에서 상당한 저하를 관찰했다. 코드를 10%로 줄였을 때, 0% 코드에 비해 영어 벤치마크 스위트에서 개선을 보지 못했지만, 코드는 모델에 있어야 할 매우 중요한 기능이었기 때문에 어쨌든 포함시켰다.

우리는 Stack-Edu — 교육적으로 필터링된 StarCoder2Data의 하위 집합 — 추가를 나중 단계까지 미루어, 최대한 후반 학습 효과를 얻기 위해 고품질 데이터를 단계적으로 도입한다는 원칙을 따랐다.

수학 데이터

수학은 코드와 유사한 철학을 따랐다. 초기에는, 더 크고 더 일반적인 세트인 FineMath3+ 및 InfiWebMath3+를 사용했고, 나중에 FineMath4+ 및 InfiWebMath4+를 업샘플링했으며, 다음과 같은 새로운 고품질 데이터셋을 도입했다:

MegaMath (Zhou et al., 2025)
OpenMathInstruct (Toshniwal et al., 2024) 및 OpenMathReasoning (Moshkov et al., 2025)과 같은 지침 및 추론 데이터셋

우리는 1단계에서 수학의 3%를 FineMath3+와 InfiWebMath3+ 사이에 균등하게 나누어 사용한다. 수학 데이터는 단지 54B 토큰만 사용 가능하고 1단계가 8T에서 9T 토큰으로 추정되는 상황에서, 3% 이상의 수학을 사용하는 것은 데이터셋에 대해 5 에포크 이상을 요구하게 되었기 때문이다.

새로운 단계를 위한 올바른 혼합 찾기

우리는 1단계 혼합을 결정하기 위해 처음부터 제거 실험을 실행했지만, 새로운 단계 (우리의 경우 두 개의 새로운 단계)를 위한 새로운 데이터셋을 테스트하기 위해 우리는 어닐링 제거 실험을 사용했다: 우리는 약 7조 토큰 (1단계 후반)에서 체크포인트를 가져와 다음 설정으로 50B 토큰 어닐링 실험을 실행했다:

40% 기준 혼합: 우리가 학습해 온 정확한 1단계 혼합
60% 새로운 데이터셋: 우리가 평가하고자 하는 후보 데이터셋

예를 들어, MegaMath가 우리의 수학 성능을 향상시킬지 테스트하기 위해, 우리는 40% 1단계 혼합 (75/12/10/3 도메인 분할 유지)과 60% MegaMath를 실행했다.

다음 섹션에서 3단계의 구성을 찾을 수 있다.

데이터가 신중하게 큐레이션되고 혼합이 제거 실험을 통해 검증되었으므로, 우리는 실제 학습 여정을 시작할 준비가 되었다. 이어지는 챕터는 SmolLM3의 한 달 동안의 학습 실행에 대한 이야기이다: 준비, 예상치 못한 도전 과제, 그리고 그 과정에서 배운 교훈들이다.

The training marathon

여기까지 왔다니, 축하한다! 진짜 재미는 이제 시작되려 한다.

이 시점에서, 우리는 모든 것을 제자리에 갖추었다: 검증된 아키텍처, 확정된 데이터 혼합, 그리고 튜닝된 하이퍼파라미터. 남은 유일한 일은 인프라를 설정하고 “학습” 버튼을 누르는 것이다.

SmolLM3의 경우, 우리는 거의 한 달 동안 384개의 H100 GPU (48개 노드)에서 학습시켜 11조 토큰을 처리했다. 이 섹션은 긴 학습 실행 중에 실제로 일어나는 일을 안내한다: 비행 전 점검, 불가피한 놀라움, 그리고 우리가 상황을 안정적으로 유지한 방법이다. 여러분은 왜 견고한 제거 실험 관행과 신뢰할 수 있는 인프라가 모두 중요한지 직접 보게 될 것이다. 우리는 GPU 하드웨어, 스토리지 시스템, 그리고 처리량 최적화의 기술적인 인프라 세부 사항을 마지막 챕터에서 다룬다.

우리 팀은 이것을 여러 번 겪어왔다: StarCoder와 StarCoder2에서부터 SmolLM, SmolLM2, 그리고 이제 SmolLM3에 이르기까지. 모든 단일 실행은 다르다. 십여 개의 모델을 학습시켰더라도, 각 새로운 실행은 여러분을 놀라게 할 신선한 방법을 찾는다. 이 섹션은 여러분에게 유리하게 확률을 쌓아 그러한 놀라움에 대비하는 것에 관한 것이다.

비행 전 점검 목록: “학습”을 누르기 전에 확인해야 할 사항

“학습”을 누르기 전에, 우리는 모든 것이 종단 간(end-to-end)으로 작동하는지 확인하기 위해 점검 목록을 거쳐야 한다:

인프라 준비 상태:

여러분의 클러스터가 Slurm 예약을 지원한다면, 그것을 사용하자. SmolLM3의 경우, 우리는 전체 실행을 위해 고정된 48개 노드 예약을 가졌다. 그것은 대기 지연 없음, 일관된 처리량, 그리고 시간에 따른 노드 상태 추적 기능을 의미했다.
시작 전에 GPU 스트레스 테스트를 수행하여 (우리는 GPU Fryer와 DCGM Diagnostics를 사용한다) 스로틀링이나 성능 저하를 잡아낸다. SmolLM3의 경우, 우리는 두 개의 GPU가 스로틀링되는 것을 발견하고 실행을 시작하기 전에 교체했다.
스토리지 비대화를 피한다: 우리 시스템은 각 체크포인트를 S3에 업로드한 다음, 다음 것을 저장한 직후 로컬 복사본을 삭제하므로, 우리는 빠른 로컬 GPU SSD에 하나 이상의 체크포인트를 저장하지 않도록 했다.

평가 설정: 평가는 믿을 수 없을 정도로 시간이 많이 걸린다. 모든 것이 구현되어 있더라도, 수동으로 실행하고, 결과를 기록하고, 플롯을 만드는 것은 매번 몇 시간을 잡아먹을 수 있다. 따라서 완전히 자동화하고, 실행이 시작되기 전에 올바르게 실행되고 기록되는지 확인해라. SmolLM3의 경우, 저장된 모든 체크포인트가 클러스터에서 평가 작업을 자동으로 트리거하여 Wandb와 Trackio에 기록되도록 했다.

체크포인트 및 자동 재시작 시스템: 체크포인트가 올바르게 저장되는지, 그리고 학습 작업이 수동 개입 없이 최신 체크포인트에서 재개될 수 있는지 확인해라. Slurm에서는 실패한 작업이 자동으로 다시 시작되어 가장 최근 체크포인트에서 재개되도록 —requeue 옵션을 사용한다.

지표 로깅: 여러분이 신경 쓰는 모든 지표를 로깅하고 있는지 확인해라: 평가 점수, 처리량 (토큰/초), 학습 손실, 기울기 노름, 노드 상태 (GPU 활용률, 온도, 메모리 사용량), 그리고 실행에 특정한 모든 사용자 정의 디버그 지표이다.

학습 구성 온전성 (Sanity) 검사: 학습 설정, 시작 스크립트, 그리고 Slurm 제출 명령을 다시 확인한다.

인프라 심층 분석

GPU 테스트, 스토리지 벤치마킹, 모니터링 설정, 그리고 탄력적인 학습 시스템 구축에 대한 자세한 안내는 인프라 챕터를 확인하라.

스케일링의 놀라움

SmolLM3에 대한 광범위한 제거 실험을 실행한 후, 우리는 전체 규모 실행을 위한 준비가 되었다. 100B 토큰에 대한 우리의 3B 제거 실험은 유망해 보였다. SmolLM2와 비교한 아키텍처 변경 사항 (아키텍처 선택 파트에서 자세히 설명됨: GQA, NoPE, 문서 마스킹, 토크나이저)은 성능을 향상시키거나 유지했으며, 우리는 영어, 다국어, 코드, 및 수학 성능의 균형을 맞추는 좋은 데이터 혼합을 찾았다 (데이터 큐레이션의 기술 파트 참조). 우리는 384개 GPU (48개 노드)에서 약 30% MFU를 위해 구성을 최적화했다.

우리는 큰 하나의 학습을 위한 준비가 되었다: 11조 토큰. 그때 현실이 커브볼을 던지기 시작했다.

미스터리 #1 – 사라진 처리량

시작 몇 시간 만에, 처리량이 급감했다. 반복적인 급격한 하락과 함께 큰 점프였다.

📍처리량이 중요한 이유

처리량은 학습 중 우리 시스템이 초당 얼마나 많은 토큰을 처리하는지를 측정한다. 이것은 우리의 학습 시간에 직접적인 영향을 미치며, 처리량이 50% 떨어지면 우리의 한 달 실행은 두 달 실행이 된다. 인프라 챕터에서, 우리는 실행을 시작하기 전에 SmolLM3를 위해 처리량을 어떻게 최적화했는지 보여줄 것이다.

스크린샷 2025-12-02 오후 5.34.52.png

이것은 어떤 제거 실험 실행에서도 일어나지 않았었다. 무엇이 바뀌었는가? 세 가지가 있다:

하드웨어 상태는 시간이 지남에 따라 변할 수 있다. 제거 실험에서 잘 작동했던 GPU가 실패할 수 있고 지속적인 부하 하에서 네트워크 연결이 저하될 수 있다.
학습 데이터셋의 크기. 우리는 이제 제거 실험에서 사용하던 더 작은 하위 집합 대신 전체 ~24 TB 학습 데이터셋을 사용했지만, 데이터 소스 자체는 동일했다.
학습 단계 수. 우리는 짧은 100B 토큰 제거 실험 기간 대신 11조 토큰에 대한 실제 단계 수를 설정했다.

다른 모든 것은 처리량 제거 실험과 정확히 동일하게 유지되었다: 노드 수, 데이터로더 구성, 모델 레이아웃, 그리고 병렬 처리 설정…

직관적으로, 데이터셋 크기나 단계 수 모두 처리량 저하를 일으키지 않아야 하므로, 우리는 자연스럽게 하드웨어 문제를 먼저 의심했다. 우리의 노드 모니터링 지표를 확인했는데, 이는 큰 처리량 점프가 디스크 읽기 지연 시간의 급등과 상관관계가 있음을 보여주었다. 그것은 우리를 곧장 우리의 데이터 스토리지로 안내했다.

📍우리 클러스터의 스토리지 옵션

우리 클러스터는 학습 데이터를 위한 세 가지 스토리지 계층을 가지고 있다:

FSx: Weka를 사용하는 네트워크 연결 스토리지로, 자주 액세스되는 파일을 로컬에 저장하고 용량이 차면 비활성 “콜드” 파일을 S3로 축출하는 “키프-핫(keep-hot)” 캐싱 모델이다.
스크래치 (로컬 NVMe RAID): 각 노드의 빠른 로컬 스토리지 (RAID로 구성된 8×3.5TB NVMe 드라이브)로, FSx보다 빠르지만 로컬 노드 액세스로 제한된다.
S3: 콜드 데이터 및 백업을 위한 원격 객체 스토리지.

자세한 내용은 인프라 챕터에서 찾을 수 있다.

SmolLM3의 24TB 데이터셋의 경우, 우리는 처음에 데이터를 FSx (Weka)에 저장했다. 24TB의 학습 데이터에 더해, 다른 여러 팀이 이미 사용 중인 스토리지가 겹쳐져, 우리는 Weka의 스토리지를 한계까지 밀어붙이고 있었다. 그래서 학습 중간에 데이터셋 샤드를 제거(evict)하기 시작했고, 이는 우리가 그것들을 다시 페치해와야 한다는 것을 의미했으며, 정체를 일으켰고, 이는 큰 처리량 점프의 발생을 설명해주었다. 더 나쁜 것은: 전체 학습 동안 우리의 데이터셋 폴더를 핫(hot)으로 고정할 방법이 없었다는 것이다.

수정 #1 – 데이터 스토리지 변경

우리는 Weka에서 전체 학습 동안 데이터셋 폴더를 핫으로 고정할 방법을 찾지 못했으므로, 스토리지 방법을 변경하려고 시도했다. S3에서 직접 스트리밍하는 것은 느렸으므로, 우리는 데이터를 각 노드의 로컬 스토리지 /scratch에 저장하기로 결정했다.

여기에는 함정이 있었다: 노드가 죽고 교체되면, 새로운 교체 GPU에는 데이터가 없었다. s5cmd로 S3에서 24TB를 다운로드하는 데 3시간이 걸렸다. 우리는 S3를 거치는 대신 fpsync를 사용하여 다른 건강한 노드에서 복사함으로써 그것을 1시간 30분으로 줄였다. 모든 노드가 동일한 데이터 센터에 있었기 때문에 이것이 더 빨랐다.

여전히, 노드 장애당 1시간 30분의 다운타임과 데이터를 새 노드로 즉시 수동으로 복사해야 할 필요성은 고통스러웠다. 마침내 그것을 견딜 수 있게 만든 핵: 데이터셋이 미리 로드된 예비 노드를 우리의 Slurm 예약에 확보하는 것이다. 노드가 죽으면, 우리는 그것을 예비 노드와 즉시 교환하여 복구 지연을 없앴다. 유휴 상태인 동안 예비 노드는 평가나 개발 작업을 실행했으므로 낭비되지 않았다.

이것이 미스터리 #1을 해결했다… 고 적어도 우리는 그렇게 생각했었다.

미스터리 #2 – 지속되는 처리량 저하

스크래치로 이동한 후에도, 하드웨어 모니터링 지표에서 어떤 이상 징후도 발견하지 못했음에도 불구하고 개별 처리량 저하는 계속 발생했다. 아래 차트는 스토리지 문제를 수정한 후 우리가 얻은 처리량(주황색)을 제거 실험 동안 얻었던 처리량(파란색)과 비교한다. 보시다시피, 저하가 훨씬 더 급격해졌다.

스크린샷 2025-12-02 오후 5.39.18.png

여전히 하드웨어를 의심하며, 우리는 더 적은 노드에서 테스트하기로 결정했다. 384개의 GPU로는 무언가가 실패할 가능성이 높다. 놀랍게도, 우리는 우리가 어떤 특정 노드를 테스트하든 상관없이 단일 노드에서 정확히 동일한 처리량 저하를 재현할 수 있었다. 이것은 하드웨어 문제를 배제했다.

우리의 제거 실험에서 변경된 세 가지를 기억하는가? 우리는 이미 로컬 노드 스토리지로 이동하여 데이터 스토리지 문제를 해결했다. 하드웨어는 이제 제거되었다. 남은 것은 단 하나의 변수였다: 단계 수. 우리는 더 작은 단계 수로 롤백하여 (300만에서 32k로) 이것을 테스트했고 처리량 저하가 더 작아졌다! 더 큰 단계 수는 더 급격하고 빈번한 저하를 생성했다.

이것을 테스트하기 위해, 우리는 32k에서 320만으로 학습 단계만 변경된 동일한 구성을 실행했다. 여기서 (https://huggingface.co/datasets/HuggingFaceTB/ablations-training-configs/tree/main/throughput_debugging) 우리가 사용한 정확한 구성을 볼 수 있다:

## Short run (32k steps)
 "lr_decay_starting_step": 2560000
 "lr_decay_steps": 640000
 "train_steps": 3200000

## Long run (3.2M steps)
 "lr_decay_starting_step": 26000
 "lr_decay_steps": 6000
 "train_steps": 32000

아래 차트에 표시된 결과는 명확했다: 짧은 실행은 작은 처리량 저하를 보인 반면, 더 긴 단계 수는 더 급격하고 빈번한 저하를 생성했다. 따라서 문제는 하드웨어가 아니라 소프트웨어 병목 현상이었으며, 아마도 데이터로더에 있는 것이었다! 대부분의 다른 학습 구성 요소는 단계 수에 관계없이 각 배치를 동일하게 처리하기 때문이다.

스크린샷 2025-12-02 오후 5.41.26.png

그때 우리는 nanotron의 데이터로더로 대규모 사전 학습을 실제로 해본 적이 없다는 것을 깨달았다. SmolLM2는 내부 래퍼를 통해 Megatron-LM 파생 데이터로더 (TokenizedBytes)를 사용하여 꾸준한 처리량으로 학습되었다. SmolLM3의 경우, 우리는 nanotron의 내장 데이터로더 (nanosets)로 전환했다.

그 구현을 깊이 파고든 후, 우리는 그것이 각 학습 단계마다 커지는 하나의 거대한 인덱스를 순진하게 구축하고 있음을 발견했다. 매우 큰 단계의 경우, 이것은 더 높은 공유 메모리를 유발하여 처리량 저하를 촉발했다.

수정 #2 – TokenizedBytes 데이터로더 가져오기

데이터로더가 실제로 범인인지 확인하기 위해, 우리는 TokenizedBytes 데이터로더를 사용하는 내부 SmolLM2 프레임워크로 동일한 구성을 시작했다. 저하는 없었다. 동일한 데이터셋을 사용하는 48개 노드에서도 마찬가지였다.

가장 빠른 진행 경로: 이 데이터로더를 nanotron으로 복사한다. 저하는 사라졌고 처리량은 목표치로 돌아왔다.

우리는 다시 시작할 준비가 되었다… 다음 커브볼이 날아올 때까지.

미스터리 #3 – 노이즈가 많은 손실

새로운 데이터로더로 처리량 저하는 없었지만 손실 곡선이 더 노이즈가 많아 보였다.

nanosets는 더 부드러운 손실을 생성했었고, 그 차이는 오래된 디버깅 전쟁의 기억을 떠올리게 했다: 몇 년 전, 우리는 문서들은 섞였지만 배치 내의 시퀀스들은 섞이지 않아 작은 급등으로 이어지는 셔플링 버그를 사전 학습 코드에서 발견했었다.

우리의 새 데이터로더를 확인해보니 그것이 확인되었다: 그것은 각 문서에서 시퀀스를 순차적으로 읽고 있었다. 짧은 파일에는 괜찮지만, 코드와 같은 도메인의 경우, 하나의 긴 저품질 파일이 전체 배치를 채우고 손실 급등을 일으킬 수 있다.

수정 #3 – 시퀀스 수준에서 셔플

우리는 두 가지 옵션이 있었다:

랜덤 액세스를 하도록 데이터로더 변경 (위험: 더 높은 메모리 사용량).
토큰화된 시퀀스를 오프라인에서 미리 셔플(pre-shuffle)한다.

실행을 시작해야 하는 시간에 대한 압박과 실행 중인 클러스터 예약으로 인해, 우리는 더 안전하고 빠른 수정으로 옵션 #2를 선택했다. 토큰화된 데이터는 이미 각 노드에 있었으므로 로컬에서 다시 셔플하는 것은 저렴했다 (~1시간). 우리는 또한 에포크 간 셔플링 패턴이 반복되는 것을 피하기 위해 다른 시드로 각 에포크에 대한 셔플된 시퀀스를 생성했다.

패치할 때와 수정할 때를 알라

긴급한 마감일이 닥쳤을 때, 고장 난 구현을 디버깅하는 것보다 검증된 솔루션이나 빠른 해결책을 채택하는 것이 더 빠를 수 있다. 앞서 우리는 nanosets의 인덱스 구현을 수정하는 대신 TokenizedBytes 데이터로더를 연결했다. 여기서, 우리는 데이터로더 변경보다 오프라인 사전 셔플링을 선택했다. 그러나 언제 지름길을 택해야 할지 알아야 하며, 그렇지 않으면 유지 보수하거나 최적화하기 어려운 누더기 시스템으로 끝나게 될 것이다.

시작, 테이크 2

이제 우리는 다음을 갖추었다:

안정적인 처리량 (스크래치 스토리지 + 예비 노드 전략)
단계 수 유발 저하 없음 (TokenizedBytes 데이터로더)
깨끗한, 시퀀스 수준 셔플링 (에포크당 오프라인 사전 셔플)

우리는 다시 시작했다. 이번에는 모든 것이 유지되었다. 손실 곡선은 부드러웠고, 처리량은 일관되었으며, 우리는 마침내 소방 활동 대신 학습에 집중할 수 있었다.

미스터리 #4 – 불만족스러운 성능

처리량과 데이터로더 문제를 수정한 후, 우리는 실행을 다시 시작했고 처음 이틀 동안 순조롭게 학습했다. 처리량은 안정적이었고, 손실 곡선은 예상대로 보였으며, 로그의 어떤 것도 문제를 암시하지 않았다. 그러나 약 1조 토큰 지점에서, 평가는 예상치 못한 것을 드러냈다.

모니터링의 일환으로, 우리는 중간 체크포인트를 평가하고 그것들을 과거 실행과 비교한다. 예를 들어, 우리는 유사한 레시피로 학습된 SmolLM2 (1.7B)의 중간 체크포인트를 가지고 있었으므로, 두 모델이 동일한 학습 단계에서 어떻게 진행되었는지 추적할 수 있었다. 결과는 당황스러웠다: 더 많은 매개변수와 더 나은 데이터 혼합을 가졌음에도 불구하고, 3B 모델은 동일한 학습 지점에서 1B보다 더 나쁜 성능을 보이고 있었다. 손실은 여전히 감소하고 있었고 벤치마크 점수는 향상되고 있었지만, 개선 속도는 명백히 기대 이하였다.

SmolLM2에 비해 SmolLM3에 도입된 모든 아키텍처 및 데이터 변경 사항을 철저히 테스트했으므로, 우리는 학습 프레임워크를 검증했고 두 학습 설정 간에 테스트되지 않은 차이점은 몇 가지 밖에 남지 않았다. 가장 명백한 것은 텐서 병렬화(Tensor Parallelism, TP)였다. SmolLM2는 단일 GPU에 맞을 수 있었고 TP 없이 학습된 반면, SmolLM3는 메모리에 맞추기 위해 TP=2가 필요했다. TP는 3B 제거 실험에 사용되었고 그 결과가 타당했기 때문에, 우리는 이전에 그것을 의심하거나 테스트할 생각을 하지 않았다.

수정 #4 - 최종 수정

TP 버그 가설을 테스트하기 위해, 우리는 SmolLM3와 정확히 동일한 설정 — 동일한 아키텍처 변경 (문서 마스킹, NoPE), 동일한 데이터 혼합, 동일한 하이퍼파라미터 — 으로 1.7B 모델을 TP 있이 그리고 없이 모두 학습시켰다. 차이는 즉각적이었다: TP 버전은 지속적으로 비-TP 버전보다 더 높은 손실과 더 낮은 다운스트림 성능을 가졌다. 그것은 우리가 TP 관련 버그를 보고 있음을 확인시켜 주었다.

그런 다음 우리는 TP와 비-TP 실행의 가중치를 비교하며 TP 구현을 자세히 조사했다. 문제는 미묘하지만 심각한 것으로 밝혀졌다: 우리는 모든 TP 랭크에 걸쳐 동일한 랜덤 시드를 사용하고 있었는데, 각 랭크는 다른 시드로 초기화되었어야 했다. 이것은 샤드 간에 상관관계가 있는 가중치 초기화를 유발하여 수렴에 영향을 미쳤다. 효과는 치명적이지 않았다 — 모델은 여전히 학습되고 개선되었다 — 그러나 그것은 대규모에서 우리가 관찰한 격차를 설명하기에 충분한 비효율성을 도입했다. 아래는 버그 수정이다:

diff --git a/src/nanotron/trainer.py b/src/nanotron/trainer.py
index 1234567..abcdefg 100644
-- a/src/nanotron/trainer.py
++ b/src/nanotron/trainer.py
@@ -185,7 +185,10 @@ class DistributedTrainer:
     ):
         # 랜덤 상태 설정
-        set_random_seed(self.config.general.seed)
+       # 다양성을 보장하기 위해 각 TP 랭크에 대해 다른 랜덤 시드 설정
+       tp_rank = dist.get_rank(self.parallel_context.tp_pg)
+       set_random_seed(self.config.general.seed + tp_rank)

스크린샷 2025-12-02 오후 5.47.59.png

각 TP 랭크가 다른 시드를 사용하도록 시드를 수정한 후, 우리는 제거 실험을 반복했고 TP와 비-TP 실행이 이제 손실 곡선과 다운스트림 성능 모두에서 일치함을 확인했다. 다른 숨겨진 문제가 없는지 확인하기 위해, 우리는 추가적인 온전성 검사를 실행했다: 3B 매개변수에서의 SmolLM2 스타일 (아키텍처 및 데이터 측면) 실행과, 별도의 3B 매개변수에서의 SmolLM3 실행을 수행하고 둘 다 SmolLM2의 체크포인트와 비교했다. 결과는 이제 기대와 일치했다: 1.7B SmolLM2는 3B SmolLM2 변형보다 성능이 나빴으며, 이는 차례로 SmolLM3의 3B 성능보다 아래였다.

스크린샷 2025-12-02 오후 5.48.50.png

이 디버깅 프로세스는 우리가 이 블로그의 앞부분에서 설명한 핵심 원칙 중 하나를 강화했다:

“견고한 제거 실험 설정의 진정한 가치는 단순히 좋은 모델을 구축하는 것을 넘어선다. 주 학습 실행 중에 필연적으로 문제가 발생할 때 (그리고 아무리 준비해도 문제가 발생할 것이다), 우리는 우리가 내린 모든 결정에 대해 확신하고, 제대로 테스트되지 않았고 문제를 일으킬 수 있는 구성 요소를 빠르게 식별하고자 한다. 이러한 준비는 디버깅 시간을 절약하고 우리의 정신 건강을 온전하게 유지한다. 버그가 어디에 숨어 있을지 모른 채 미스터리한 학습 실패를 쳐다보고 있는 것보다 더 나쁜 것은 없다.”

우리 학습의 다른 모든 구성 요소가 검증되었기 때문에, 우리는 TP를 유일하게 타당한 원인으로 정확히 지적하고 성능 격차를 감지한 지 하루 만에 버그를 수정할 수 있었다.

그것으로, 우리는 시작 이후 표면화된 일련의 예상치 못한 문제 중 마지막 문제를 해결했다. 삼세번의 운으로, 그 시점부터 남은 한 달의 학습은 노드 장애로 인한 가끔의 재시작으로 중단되는 것을 제외하고는 수조 개의 토큰을 완성된 모델로 바꾸는 꾸준한 작업으로 비교적 평온했다.

코스를 유지하기

이전 섹션에서 보았듯이, 제거 실험에서 전체 사전 학습으로 확장하는 것은 단순히 “플러그 앤 플레이”가 아니었다. 예상치 못한 문제들이 발생했지만, 우리는 각 문제를 성공적으로 식별하고 해결했다. 이 섹션에서는 대규모 학습 실행을 위한 필수 모니터링 설정 및 고려 사항을 다룬다. 우리는 중요한 질문들을 다룰 것이다: 문제에 직면한 후 언제 학습을 재시작해야 하는가? 실행 중간에 표면화되는 문제들을 어떻게 처리하는가? 어떤 지표가 진정으로 중요한가? 학습 전반에 걸쳐 고정된 데이터 혼합을 유지해야 하는가?

학습 모니터링: 손실 곡선을 넘어서

우리가 텐서 병렬화(TP) 버그를 잡은 이유는 괜찮아 보였던 손실 곡선 때문이 아니라, 다운스트림 평가가 기대치보다 뒤처져 있었다는 사실 때문이었다. 또한, SmolLM2의 중간 체크포인트로부터의 평가를 가지고 있었던 것이 중요했다: 그것들은 3B 모델이 초기에 올바른 궤도에 있지 않다는 온전성 검사를 할 수 있게 해주었다. 따라서 대규모 모델을 학습시킨다면, 다운스트림 평가를 일찍 실행하기 시작하고, 오픈 소스 모델과 비교한다면 저자들에게 중간 체크포인트를 제공할 수 있는지 물어본다. 그것들은 참조점으로서 매우 귀중할 수 있다.

인프라 측면에서 가장 중요한 지표는 초당 토큰 수로 측정되는 처리량이다. SmolLM3의 경우, 우리는 실행 전반에 걸쳐 13,500–14,000 토큰/초 사이의 안정적인 처리량을 예상했으며, 지속적인 편차는 위험 신호였다. 그러나 처리량만으로는 충분하지 않다: 하드웨어 고장을 예측하고 감지하기 위해 지속적인 하드웨어 상태 모니터링도 필요하다. 우리가 추적한 주요 지표로는 GPU 온도, 메모리 사용량 및 컴퓨팅 활용률이 포함된다. 우리는 그것들을 Grafana 대시보드에 기록하고 하드웨어 이상 징후에 대한 실시간 Slack 경고를 설정했다.

수정 후 재시작 대 즉석에서 수정

우리가 1조 토큰 후에 실행을 재시작했다는 점을 고려할 때, 중요한 질문이 제기된다: 뭔가 잘못되었을 때 항상 재시작해야 하는가? 답은 문제의 심각성과 근본 원인에 따라 다르다.

우리의 경우, TP 시딩 버그는 우리가 첫 단추를 잘못 꿰었다는 것을 의미했다. 가중치의 절반이 제대로 초기화되지 않았기 때문이다. 모델은 SmolLM2와 유사한 성능을 보이고 비슷한 지점에서 정체되고 있었으며, 이는 우리가 동일한 성능을 발휘하지만 학습 비용은 거의 두 배나 드는 모델로 끝날 가능성이 높다는 것을 의미했다. 재시작하는 것이 합리적이었다. 그러나 많은 문제들은 컴퓨팅 낭비를 피하기 위해 실행 중간에 수정될 수 있다. 가장 일반적인 문제는 손실 급등(loss spikes)과 관련이 있으며, 이는 사소한 문제나 발산을 알릴 수 있는 학습 손실의 갑작스러운 점프이다.

Stas Bekman이 머신 러닝 엔지니어링 오픈 북에서 멋지게 표현했듯이 “학습 손실 플롯은 심장 박동 패턴과 유사하다—좋은 것, 나쁜 것, 그리고 걱정해야 할 것이 있다.”

스크린샷 2025-12-02 오후 5.53.01.png

손실 급등은 두 가지 범주로 나뉜다:

회복 가능한 급등: 이것들은 빠르게 (급등 직후) 또는 느리게 (급등 전 궤적으로 돌아가기 위해 몇 번의 학습 단계가 더 필요함) 회복될 수 있다. 보통 이것들을 뚫고 계속 학습할 수 있다. 회복이 매우 느리다면, 문제가 되는 배치를 건너뛰기 위해 이전 체크포인트로 되감기를 시도할 수 있다.
회복 불가능한 급등: 모델이 발산하거나 급등 전보다 더 나쁜 성능에서 정체된다. 이것들은 단순히 이전 체크포인트로 되감는 것보다 더 중요한 개입을 필요로 한다.

우리는 학습 불안정성을 완전히 이해하지 못하지만, 대규모에서 더 빈번해진다는 것을 알고 있다. 보수적인 아키텍처와 옵티마이저를 가정할 때 일반적인 범인은 다음과 같다:

높은 학습률: 학습 초기에 불안정성을 유발하며 학습률을 줄임으로써 해결될 수 있다.
나쁜 데이터: 회복이 느릴 수 있지만 일반적으로 회복 가능한 급등의 주요 원인이다. 모델이 저품질 데이터를 만날 때 학습 후반부에 발생할 수 있다.
데이터-매개변수 상태 상호 작용: PaLM (Chowdhery et al., 2022)은 급등이 종종 “나쁜 데이터” 단독보다는 데이터 배치와 모델 매개변수 상태의 특정 조합에서 발생한다는 것을 관찰했다. 다른 체크포인트에서 동일한 문제 배치를 학습했을 때 급등이 재현되지 않았다.
나쁜 초기화: OLMo2 (OLMo et al., 2025)의 최근 연구는 스케일링된 초기화에서 단순한 정규 분포 (평균=0,표준편차=0.02)로 전환하는 것이 안정성을 개선했음을 보여주었다.
정밀도 문제: 더 이상 아무도 FP16으로 학습하지 않긴 하지만, BLOOM은 BF16에 비해 그것이 매우 불안정하다는 것을 발견했다.

급등이 발생하기 전에, 안정성을 구축하라:

보수적인 학습률과 좋은 데이터를 가진 소형 모델은 거의 급등하지 않지만, 더 큰 모델은 사전 예방적인 안정성 조치를 요구한다. 더 많은 팀들이 대규모로 학습함에 따라, 우리는 학습 불안정성을 예방하는 데 도움이 되는 기술 도구 상자들을 축적했다:

데이터 필터링 및 셔플링: 이 블로그의 이 시점에서, 당신은 우리가 얼마나 자주 데이터로 되돌아가야 하는지 알아차렸을 것이다. 데이터가 깨끗하고 잘 섞였는지 확인하는 것은 급등을 예방할 수 있다. 예를 들어, OLMo2는 반복되는 n-gram (1-13 토큰 스팬의 32회 이상 반복)을 가진 문서를 제거하는 것이 급등 빈도를 상당히 줄인다는 것을 발견했다.

학습 수정: Z-손실 정규화는 성능에 영향을 주지 않으면서 출력 로짓이 너무 커지는 것을 방지한다. 그리고 임베딩을 가중치 감쇠에서 제외하는 것도 도움이 된다.

아키텍처 변경: QKNorm (어텐션 전 쿼리와 키 투영 정규화)은 효과적인 것으로 입증되었다. OLMo2와 다른 팀들은 그것이 안정성에 도움이 된다는 것을 발견했으며, 흥미롭게도 Marin 팀은 발산 문제를 해결하기 위해 실행 중간에 적용될 수도 있음을 발견했다.

어쨌든 급등이 발생했을 때 - 피해 통제:

이러한 예방 조치에도 불구하고, 급등은 여전히 발생할 수 있다. 다음은 그것들을 수정하기 위한 몇 가지 옵션이다:

문제가 되는 배치 건너뛰기: 급등 전으로 되감고 문제가 되는 배치를 건너뛴다. 이것은 급등에 대한 가장 일반적인 수정이다. Falcon 팀 (Almazrouei et al., 2023)은 그들의 급등을 해결하기 위해 1B 토큰을 건너뛰었고, PaLM 팀 (Chowdhery et al., 2022)은 급등 위치 주변의 200-500 배치를 건너뛰는 것이 재발을 방지한다는 것을 발견했다.
기울기 클리핑 강화: 기울기 노름 임계값을 일시적으로 줄인다.
아키텍처 수정 적용: Marin에서 수행된 것과 같이 QKnorm과 같은 아키텍처 수정을 적용한다.

우리는 처리량 저하에서 TP 버그에 이르기까지의 확장 문제, 문제를 조기에 포착하기 위한 모니터링 관행, 그리고 손실 급등을 예방하고 수정하기 위한 전략을 살펴보았다. 다단계 학습이 모델의 최종 성능을 어떻게 향상시킬 수 있는지 논의하며 이 챕터를 마치고자 한다.

중간 학습 (Mid-training)

현대 LLM 사전 학습은 일반적으로 다른 데이터 혼합을 가진 다단계(multiple stages)를 포함하며, 종종 컨텍스트 길이를 확장하기 위한 최종 단계가 뒤따른다. 예를 들어, Qwen3 (A. Yang, Li, et al., 2025)는 3단계 접근 방식을 사용한다: 4k 컨텍스트에서 30T토큰에 대한 일반 단계, STEM 및 코딩을 강조하는 5T 고품질 토큰을 사용한 추론 단계, 그리고 마지막으로 32k 컨텍스트 길이에서 수천억 토큰에 대한 긴 컨텍스트 단계이다. SmolLM3는 고품질 데이터셋을 도입하고 컨텍스트를 확장하기 위한 계획된 개입과 함께, 성능 모니터링에 기반한 반응형 조정을 한다는, 유사한 철학을 따랐다.

우리가 데이터 큐레이션 섹션에서 설명했듯이, 데이터 혼합은 학습 내내 고정되어 있을 필요가 없다. 다단계 학습을 통해 학습이 진행됨에 따라 데이터셋 비율을 전략적으로 변경할 수 있다. 일부 개입은 처음부터 계획된다: SmolLM3의 경우, 우리는 2단계에서 고품질 FineMath4+ 및 Stack-Edu를 도입한 다음, 최종 감쇠 단계 동안 큐레이션된 Q&A 및 추론 데이터를 추가할 것을 미리 계획하여 알고 있었다. 다른 개입은 반응형이며, 학습 중 성능 모니터링에 의해 주도된다. 예를 들어, SmolLM2에서 수학 및 코드 성능이 목표보다 뒤처지는 것을 발견했을 때, 우리는 완전히 새로운 데이터셋 (FineMath 및 Stack-Edu)을 큐레이션하고 중간 학습에 도입했다. 계획된 커리큘럼을 따르든 나타나는 격차에 적응하든, 이러한 유연성은 우리가 컴퓨팅 예산의 가치를 극대화할 수 있게 해주는 것이다.

2단계 및 3단계 혼합

아래 차트는 우리의 3가지 학습 단계와 학습 중 웹/코드/수학 비율의 진행 상황을 보여준다. 각 단계에 대한 SmolLM3 학습 설정은 정확한 데이터 가중치와 함께 여기(https://github.com/huggingface/smollm/tree/main/text/pretraining/smollm3) 에서 확인할 수 있다. 각 단계의 근거와 구성에 대한 자세한 내용은 데이터 큐레이션 섹션을 참고해라.

스크린샷 2025-12-02 오후 6.00.32.png

1단계: 기본 학습 (8조 토큰, 4k 컨텍스트) 기초 단계는 우리의 핵심 사전 학습 혼합을 사용한다: 웹 데이터 (FineWeb-Edu, DCLM, FineWeb2, FineWeb2-HQ), The Stack v2와 StarCoder2의 코드, 그리고 FineMath3+와 InfiWebMath3+의 수학이다. 모든 학습은 4k 컨텍스트 길이에서 이루어진다.

**2단계: 고품질 주입 (2조 토큰, 4k 컨텍스트)**우리는 고품질 필터링된 데이터셋을 도입한다: 코드를 위한 Stack-Edu, 수학을 위한 FineMath4+ 및 InfiWebMath4+, 그리고 고급 수학적 추론을 위한 MegaMath (우리는 Qwen Q&A 데이터, 합성 재작성, 및 텍스트-코드 인터리브 블록을 추가한다).

3단계: 추론 및 Q&A 데이터를 포함한 LR 감쇠 (1.1조 토큰, 4k 컨텍스트) 학습률 감쇠 단계 동안, 우리는 고품질 코드 및 수학 데이터셋을 더욱 업샘플링하면서 OpenMathReasoning, OpenCodeReasoning 및 OpenMathInstruct와 같은 지침 및 추론 데이터를 도입한다. Q&A 샘플은 단순히 Concatenate 되고, 줄바꿈으로 구분된다.

긴 컨텍스트 확장: 4k에서 128k 토큰으로

컨텍스트 길이는 모델이 얼마나 많은 텍스트를 처리할 수 있는지를 결정하며, 긴 문서 분석, 일관된 멀티턴 대화 유지, 또는 전체 코드베이스 처리와 같은 작업에 중요하다. SmolLM3는 4k 토큰에서 학습을 시작했지만, 실제 애플리케이션을 위해 128k로 확장해야 했다.

왜 중간 학습에서 컨텍스트를 확장하는가?

처음부터 긴 컨텍스트로 학습하는 것은 어텐션 메커니즘이 시퀀스 길이에 따라 연산량이 제곱으로 확장되므로 계산 비용이 많이 든다. 게다가, 연구는 학습 끝 무렵이나 지속적인 사전 학습 중에 수십억에서 천억 토큰으로 컨텍스트를 확장하는 것만으로도 좋은 긴 컨텍스트 성능에 도달하기에 충분하다는 것을 보여준다 (Gao et al., 2025).

순차적 확장: 4k → 32K → 64K

우리는 곧바로 128k로 점프하지 않았다. 대신, 우리는 단계적으로 컨텍스트를 점진적으로 확장하여 모델이 더 나아가기 전에 각 길이에 적응할 시간을 주었다. 우리는 두 개의 긴 컨텍스트 단계를 실행했다: 먼저 4k에서 32k로, 그 다음 32k에서 64k로 (128k 기능은 학습이 아닌 추론 시 외삽에서 나온다). 우리는 50B 토큰에 걸쳐 각 단계에 대해 새로운 학습률 스케줄을 시작하는 것이 주 감쇠 단계의 마지막 100B 토큰 동안 컨텍스트를 확장하는 것보다 더 잘 작동한다는 것을 발견했다. 각 단계에서, 우리는 좋은 긴 컨텍스트 데이터 혼합과 RoPE theta 값을 찾기 위해 제거 실험을 실행했고, Ruler 벤치마크에서 평가했다.

💡기본 모델에서의 긴 컨텍스트 평가

긴 컨텍스트 제거 실험 동안, 우리는 HELMET 벤치마크가 기본 모델에서 매우 노이즈가 많다는 것을 발견했다 (다른 시드로 동일한 학습을 하면 가변적인 결과가 나온다). Gao et al.은 벤치마크 작업의 분산을 줄이기 위해 그 위에 SFT를 수행할 것을 권장한다. 대신 우리는 기본 모델 수준에서 더 신뢰할 수 있는 신호를 제공하는 RULER를 선택했다.

이 단계 동안, 긴 컨텍스트 성능을 향상시키기 위해 긴 웹 페이지 및 책과 같은 긴 컨텍스트 문서를 업샘플링하는 것이 일반적이다 (Gao et al., 2025). 우리는 FineWeb-Edu 및 Python-Edu를 사용하여 Qwen2.5-1M의 접근 방식 (A. Yang, Yu, et al., 2025)을 따라 검색 및 중간 채우기(fill-in-the-middle)와 같은 작업을 위해 책, 기사, 심지어 합성 생성된 문서까지 업샘플링하는 여러 제거 실험을 실행했다. 놀랍게도, 우리는 3단계의 기준 혼합을 사용하는 것보다 개선을 관찰하지 못했는데, 이는 이미 Ruler에서 Llama 3.2 3B 및 Qwen2.5 3B와 같은 다른 최첨단 모델과 경쟁력이 있었다. 우리는 기준 혼합이 웹 데이터 및 코드 (토큰의 10%로 추정됨)로부터 자연스럽게 긴 문서를 포함하고 있으며, NoPE를 사용한 것이 도움이 되었다고 가설을 세웠다.

(긴 컨텍스트 확장에 대한 더 많은 통찰력을 위해, How to Train Long-Context Language Models (Effectively) 논문을 읽는 것을 추천한다.)

RoPE ABF (RoPE with Adjusted Base Frequency): 4k에서 32k로 갈 때, 우리는 RoPE theta (기본 주파수)를 2M으로 늘렸고, 32k에서 64k로 갈 때는 5M으로 늘렸다. 우리는 10M과 같은 더 큰 값을 사용하는 것이 RULER 점수를 약간 향상시키지만 GSM8k와 같은 일부 짧은 컨텍스트 작업을 해친다는 것을 발견하여, 짧은 컨텍스트에 영향을 미치지 않는 5M을 유지했다. 이 컨텍스트 확장 단계 동안, 우리는 또한 수학, 코드, 및 추론 Q&A 데이터를 더욱 업샘플링할 기회를 이용했으며, ChatML 형식의 수십만 개의 샘플을 추가했다.

YARN 외삽: 128k 도달. 64k 컨텍스트에서 학습한 후에도, 우리는 SmolLM3가 추론 시 128k를 처리하기를 원했다. 128k 시퀀스로 학습하는 대신 (비용이 엄청나게 많이 든다), 우리는 YARN (Yet Another RoPE extensioN method) (B. Peng et al., 2023)을 사용했는데, 이는 모델이 학습 길이를 넘어 외삽할 수 있게 해준다. 이론적으로, YARN은 시퀀스 길이의 4배 증가를 허용한다. 우리는 64k 체크포인트를 사용하는 것이 32k 체크포인트를 사용하는 것보다 128k에서 더 나은 성능을 제공한다는 것을 발견하여, 목표 추론 길이에 더 가깝게 학습하는 것의 이점을 확인했다. 그러나 256k (64k의 4배)로 밀어붙이는 것은 저하된 Ruler 성능을 보였으므로, 우리는 모델을 128k까지만 사용할 것을 권장한다.

이것으로, 우리는 계획 및 제거 실험에서부터 최종 학습 실행까지, 그 과정에서 겪은 모든 비하인드 스토리의 도전과 함께 SmolLM3를 위한 전체 사전 학습 여정을 이야기했다.

사전 학습 마무리

우리는 많은 내용을 다루었다. 왜 그리고 무엇을 학습할지 결정하는 데 도움을 준 학습 나침반부터, 전략적 계획, 모든 아키텍처 선택을 검증한 체계적인 제거 실험, 그리고 대규모에서 놀라운 일들이 등장했던 실제 학습 마라톤 (미스터리하게 붕괴하는 처리량, 데이터로더 병목 현상, 그리고 1조 토큰에서 재시작을 강제한 미묘한 텐서 병렬화 버그)까지.

잘 다듬어진 기술 보고서 뒤의 지저분한 현실이 이제 보인다: LLM 학습은 아키텍처 혁신 및 데이터 큐레이션만큼이나 절제된 실험과 빠른 디버깅에 관한 것이다. 계획은 테스트할 가치가 있는 것을 식별한다. 제거 실험은 각 결정을 검증한다. 모니터링은 문제를 조기에 포착한다. 그리고 필연적으로 무언가 고장 날 때, 체계적인 위험 제거는 정확히 어디를 봐야 할지 알려준다.

SmolLM3의 경우 구체적으로, 이 프로세스는 우리가 구축하고자 했던 것을 제공했다: 수학, 코드, 다국어 이해, 그리고 긴 컨텍스트 작업에서 경쟁력 있는, Qwen3 모델의 파레토 프론티어에 있는 11조 토큰으로 학습된 3B 모델이다.

스크린샷 2025-12-02 오후 6.09.06.png

12개 인기 LLM 벤치마크에 대한 기본 모델 평가 승률 (%). 벤치마크: HellaSwag, ARC, Winogrande, CommonsenseQA, MMLU-CF, MMLU Pro CF, PIQA, OpenBookQA, GSM8K, MATH, HumanEval+, MBPP+

기본 모델 체크포인트가 저장되고, 학습이 완료되고, GPU가 마침내 식으면, 우리는 끝났다고 부르고 싶을지도 모른다. 결국, 우리는 텍스트를 잘 예측하고, 강력한 벤치마크 점수를 달성하며, 우리가 목표로 한 능력을 보여주는 모델을 가지고 있다.

아직은 아니다. 왜냐하면 오늘날 사람들이 원하는 것은 가공되지 않은 다음 토큰 예측기가 아니라 어시스턴트와 코딩 에이전트이기 때문이다.

여기서 사후 학습(Post-training)이 등장한다. 그리고 사전 학습과 마찬가지로, 현실은 논문보다 더 지저분하다.

Beyond base models — post-training in 2025

사전 학습이 끝나면 하루 안에 SFT 기준선을 확보해야 한다.

— Lewis Tunstall, 낙관적인 LLM 전문가.

스크린샷 2025-12-02 오후 6.40.09.png

자신만의 사후 학습 모험을 선택해라.

사전 학습은 우리에게 SmolLM3의 원초적인 능력을 주었지만, GPU가 식기도 전에 우리는 모델 능력의 다음 개척지인 **사후 학습(post-training)**에 진입한다. 여기에는 지도 파인 튜닝(SFT), 강화 학습, 모델 병합 등이 포함되며, 모두 “텍스트를 예측하는 모델”에서 “사람들이 실제로 사용할 수 있는 모델”로의 격차를 메우기 위해 설계되었다. 사전 학습이 지식을 가중치에 억지로 집어넣는 것이라면, 사후 학습은 그 원초적인 능력을 신뢰할 수 있고 조종 가능한 무언가로 조각하는 것이다. 그리고 사전 학습과 마찬가지로, 잘 다듬어진 사후 학습 논문들은 심야의 놀라움: GPU 멜트다운, 까다로운 데이터 혼합, 또는 겉보기에 사소한 채팅 템플릿 결정이 다운스트림 벤치마크에 파급되는 방식을 보여주지 않는다. 이 섹션에서, 우리는 SmolLM3를 강력한 기본 모델에서 최첨단 하이브리드 추론 모델로 바꾸기 위해 사후 학습의 혼란스러운 세계를 어떻게 헤쳐나갔는지 보여줄 것이다.

📍하이브리드 추론 모델이란 무엇인가?

하이브리드 추론 모델은 두 가지 별개의 모드로 작동한다: 하나는 간결하고 직접적인 응답을 위한 것이고 다른 하나는 확장된 단계별 추론을 위한 것이다. 일반적으로 작동 모드는 시스템 메시지에서 사용자에 의해 설정된다. Qwen3를 따라, 우리는 가벼운 명령어로 이를 명시적으로 만든다: “/think”는 확장된 추론을 호출하는 반면, “/no_think”는 간결한 답변을 강제한다. 이런 식으로, 사용자는 모델이 깊이와 속도 중 무엇을 우선시할지 제어한다.

사후 학습 나침반: 왜 → 무엇을 → 어떻게

사전 학습과 마찬가지로, 사후 학습은 낭비되는 연구 및 엔지니어링 주기를 피하기 위해 명확한 나침반으로부터 이점을 얻는다. 프레임화하는 방법은 다음과 같다:

왜 사후 학습을 하는가? 우리가 사전 학습 나침반에서 설명한 학습의 세 가지 동기—연구, 프로덕션, 그리고 전략적 오픈 소스—는 사후 학습에도 동일하게 적용된다. 예를 들어, RL이 기존 모델에서 새로운 추론 능력을 잠금 해제할 수 있는지 탐색하고 있거나(연구), 지연 시간 문제로 인해 큰 모델을 작은 모델로 증류(distill)해야 하거나(프로덕션), 특정 사용 사례에 대한 강력한 오픈 모델이 존재하지 않는 격차를 식별했을 수 있다(전략적 오픈 소스). 차이점은 사후 학습이 처음부터 능력을 만드는 대신 기존 능력을 기반으로 구축한다는 것이다. 그러나 GPU에 손을 뻗기 전에 아래 질문들을 스스로에게 물어봐야 한다:
- 정말로 사후 학습을 해야 하는가? 많은 오픈 가중치 모델들이 이제 광범위한 작업에서 독점 모델들과 경쟁한다. 일부는 양자화와 적당한 컴퓨팅으로 로컬에서 실행될 수도 있다. 범용 어시스턴트를 원한다면, Hugging Face Hub의 기성 모델이 이미 여러분의 필요를 충족시킬 수 있다.
- 고품질, 도메인별 데이터에 접근할 수 있는가? 사후 학습은 범용 모델이 저조한 성능을 보이는 특정 작업이나 도메인을 목표로 할 때 가장 의미가 있다. 올바른 데이터를 가지고 있다면, 여러분이 가장 중요하게 생각하는 애플리케이션에 대해 더 정확한 출력을 생성하도록 모델을 튜닝할 수 있다.
- 성공을 측정할 수 있는가? 명확한 평가 기준 없이는 사후 학습이 정말 도움이 되는지 알 수 없을 것이다.
사후 학습은 무엇을 달성해야 하는가? 이것은 여러분의 우선순위에 달려있다:
- 주제를 거의 벗어나지 않는 깔끔한 지침 수행자를 원하는가?
- 요구에 따라 톤과 역할을 전환할 수 있는 다재다능한 어시스턴트인가?
- 수학, 코드, 또는 에이전트 문제를 해결할 수 있는 추론 엔진인가?
- 여러 언어로 대화할 수 있는 모델인가?
어떻게 도달할 것인가? 그것이 레시피가 중요한 이유이다. 우리는 다음을 다룰 것이다:
- 핵심 능력을 주입하기 위한 지도 파인 튜닝(SFT).
- 인간 또는 AI 선호도로부터 직접 학습하기 위한 선호도 최적화(PO).
- 지도 데이터를 넘어 신뢰성과 추론을 정제하기 위한 강화 학습(RL).
- 다양성과 품질 사이의 올바른 균형을 맞추기 위한 데이터 큐레이션.
- 진전을 추적하고 회귀를 조기에 포착하기 위한 평가.

이 나침반은 사후 학습의 카오스에서 방향을 잡게 해준다. 왜는 방향을 제시하고, 무엇은 우선순위를 설정하며, 어떻게는 야망을 실용적인 학습 루프로 바꾼다.

SmolLM3에 대해 우리가 이 질문들에 어떻게 답했는지 살펴보자:

왜? 우리에게 “왜”는 간단했다. 출시 전에 사후 학습이 필요한 기본 모델을 가지고 있었기 때문이다. 동시에 Qwen3와 같은 하이브리드 추론 모델이 점점 인기를 얻고 있었지만, 그것들을 학습시키는 방법을 보여주는 오픈 레시피는 드물었다. SmolLM3는 우리에게 두 가지를 해결할 기회를 주었다: 실제 사용을 위해 모델을 준비하고, Qwen3의 1.7B 및 4B 모델과 함께 파레토 프론트에 자리할 완전히 개방된 레시피에 기여하는 것이다.
무엇? 우리는 SmolLM3의 강점에 맞춘 하이브리드 추론 모델을 학습시키기로 했으며, 주로 영어 이외의 언어에서도 추론 품질이 유지되어야 한다는 점이었다. 그리고 실제 사용은 점점 더 도구 호출 및 긴 컨텍스트 워크플로를 포함하므로, 그것들이 우리의 사후 학습 레시피에서 핵심 요구 사항이 되었다.
어떻게? 그것은 이 챕터의 나머지 부분이다 😀.

사전 학습과 마찬가지로, 우리는 기본부터 시작해야 한다: 평가(evals)와 기준선(baselines). 왜냐하면 모든 큰 모델은 작은 제거 실험으로 시작하기 때문이다. 그러나 우리가 제거 실험을 수행하는 방식에 중요한 차이가 있다. 사전 학습에서 “작은”은 일반적으로 더 작은 모델과 데이터셋을 의미한다. 사후 학습에서 “작은”은 더 작은 데이터셋과 더 간단한 알고리즘을 의미한다. 우리는 동작이 너무 모델 의존적이고 실행이 대상 모델에서 직접 반복할 수 있을 만큼 짧기 때문에 제거 실험을 위해 다른 기본 모델을 거의 사용하지 않는다.

많은 모델 학습자들이 프로젝트 후반까지 피하는 주제인, 평가부터 시작해보자.

가장 먼저 할 일: 다른 모든 것보다 평가(evals)

사후 학습의 가장 첫 번째 단계는 — 사전 학습과 마찬가지로 — 올바른 평가 세트를 결정하는 것이다. 오늘날 대부분의 LLM이 어시스턴트로 사용되기 때문에, 우리는 ARC-AGI와 같은 “지능”의 추상적인 벤치마크를 쫓는 것보다 “잘 작동하는” 모델을 목표로 하는 것이 더 나은 목표라는 것을 발견했다. 그렇다면 좋은 어시스턴트는 무엇을 해야 하는가? 최소한 다음을 할 수 있어야 한다:

모호한 지침 처리하기
단계별로 계획하기
코드 작성하기
적절할 때 도구 호출하기

이러한 행동은 추론, 긴 컨텍스트 처리, 그리고 수학, 코드 및 도구 사용 기술의 혼합에 의존한다. 30억 매개변수만큼 작거나 심지어 그보다 작은 모델도 어시스턴트로 잘 작동할 수 있지만, 성능은 일반적으로 10억 미만에서 급격히 떨어진다.

(아주 작은 모델이 제한된 용량을 상쇄하기 위해 도구 호출을 사용하여 실행 가능한 어시스턴트로 작동할 수 있는지 여부는 흥미롭지만 여전히 열린 질문으로 남아 있다. 이 방향의 최근 작업은 LiquidAI의 모델들을 참고해라.)

Hugging Face에서, 우리는 사전 학습을 위한 제거 실험 섹션에서 자세히 설명한 사전 학습 원칙 (단조성, 낮은 노이즈, 랜덤 이상의 신호, 순위 일관성)을 반영하는 계층화된 평가 스위트를 사용했다.

📍평가를 최신 상태로 유지하기

고려해야 할 평가 목록은 모델이 개선됨에 따라 지속적으로 진화하고 있으며 아래 논의된 평가들은 2025년 중반의 우리의 초점을 반영하고 있다. 사후 학습 평가에 대한 포괄적인 개요는 Evaluation Guidebook을 참고하라.

다음은 사후 학습된 모델을 평가할 수 있는 여러 가지 방법이다:

능력 평가 (Capability evals)

이 클래스의 평가는 추론 및 경쟁 수학 및 코딩과 같은 기본 기술을 목표로 한다.

지식. 우리는 현재 과학적 지식을 위한 주요 평가로 GPQA Diamond (Rein et al., 2024)를 사용한다. 이 벤치마크는 대학원 수준의 객관식 질문으로 구성된다. 소형 모델의 경우 포화 상태와는 거리가 멀고 MMLU 및 친구들보다 더 나은 신호를 제공하며 실행 속도도 훨씬 빠르다. 사실성에 대한 또 다른 좋은 테스트는 SimpleQA (Wei et al., 2024)이지만, 소형 모델은 제한된 지식으로 인해 이 벤치마크에서 상당히 어려움을 겪는 경향이 있다.
수학. 수학적 능력을 측정하기 위해, 오늘날 대부분의 모델은 최신 버전의 AIME (현재 2025 버전)에서 평가된다. MATH-500 (Lightman et al., 2023)은 소형 모델에 유용한 온전성 테스트로 남아 있지만, 추론 모델에 의해 크게 포화되었다. 더 포괄적인 수학 평가 세트를 위해 MathArena의 평가들을 추천한다.
코드. 우리는 코딩 역량을 추적하기 위해 최신 버전의 LiveCodeBench를 사용한다. 경쟁 프로그래밍 문제를 목표로 하지만, 우리는 LiveCodeBench의 개선이 비록 Python에 국한되지만 더 나은 코딩 모델로 이어진다는 것을 발견했다. SWE-bench Verified는 코딩 기술의 더 정교한 척도이지만, 소형 모델에는 너무 어려운 경향이 있어 우리가 일반적으로 고려하는 대상은 아니었다.
다국어성. 불행히도, 모델의 다국어 기능을 테스트하는 것에 관해서는 선택지가 많지 않다. 우리는 현재 우리 모델이 잘 수행해야 하는 주요 언어를 목표로 Global MMLU (Singh et al., 2025)에 의존하며, MGSM (Shi et al., 2022)이 다국어 수학적 능력 테스트로 포함된다.

통합 작업 평가 (Integrated task evals)

이러한 평가들은 우리가 출시할 것과 가까운 것들을 테스트한다: 반-현실적인 설정에서의 멀티턴 추론, 긴 컨텍스트 사용, 그리고 도구 호출이다.

긴 컨텍스트. 긴 컨텍스트 검색을 위한 가장 일반적으로 사용되는 테스트는 Needle in a Haystack (NIAH) (Kamradt, 2023)으로, 무작위 사실(“바늘”)이 긴 문서(“건초더미”) 내 어딘가에 배치되고 모델이 그것을 검색해야 한다. 그러나 이 벤치마크는 긴 컨텍스트 이해를 구별하기에는 너무 표면적이어서, 커뮤니티는 RULER (Hsieh et al., 2024) 및 HELMET (Yen et al., 2025)과 같은 더 포괄적인 평가를 개발했다. 더 최근에 OpenAI는 긴 컨텍스트 평가의 난이도를 확장하는 MRCR 및 GraphWalks 벤치마크를 출시했다. (긴 컨텍스트 평가의 한계와 현실적인 평가를 설계하는 방법에 대한 이 훌륭한 블로그 게시물https://nrehiew.github.io/blog/long_context/도 참고해라.)
지침 따르기. IFEval (J. Zhou et al., 2023)은 현재 지침 따르기를 측정하는 가장 인기 있는 평가이며, “검증 가능한 지침”에 대해 자동 채점을 사용한다. IFBench (Pyatkin et al., 2025)는 IFEval보다 더 다양한 제약 조건 세트를 포함하고 최근 모델 릴리스에서 발생한 일부 벤치마크 최적화(benchmaxxing)를 완화하는 Ai2의 새로운 확장판이다. 멀티턴 지침 따르기를 위해 우리는 Multi-IF (He et al., 2024) 또는 MultiChallenge (Sirdeshmukh et al., 2025)를 추천한다.
정렬 (Alignment). 모델이 사용자 의도에 얼마나 잘 부합하는지 측정하는 것은 일반적으로 인간 주석자 또는 LMArena와 같은 공개 순위표에 의해 수행된다. 자유 형식 생성, 스타일 또는 전반적인 유용성과 같은 품질은 자동화된 지표로 정량적으로 측정하기 어렵기 때문이다. 그러나 모든 경우에 이러한 평가를 실행하는 것은 매우 비용이 많이 들기 때문에 커뮤니티는 인간 선호도에 대한 대리자로 LLM을 사용하는 것에 의존하게 되었다. 이런 종류의 가장 인기 있는 벤치마크에는 AlpacaEval (Dubois et al., 2025), ArenaHard (T. Li et al., 2024) 및 MixEval (Ni et al., 2024)이 포함되며, 후자는 LMArena의 인간 Elo 등급과 가장 강한 상관관계를 가진다.
도구 호출. BFCL은 도구 호출에 대한 포괄적인 테스트를 제공하지만, 종종 꽤 빨리 포화된다. TAU-Bench (Barres et al., 2025)는 시뮬레이션된 고객 서비스 설정에서 도구를 사용하고 사용자 문제를 해결하는 모델의 능력을 테스트하며 보고하기에 인기 있는 벤치마크가 되었다.

과적합 방지 평가 (Overfitting-prevention evals)

모델이 특정 기술에 과적합되고 있는지 테스트하기 위해, 우리는 GSM8k (Cobbe et al., 2021)의 문제를 교란시켜 모델이 여전히 비슷한 난이도의 문제를 해결할 수 있는지 테스트하는 GSMPlus (Q. Li et al., 2024)와 같은 견고성 또는 적응성 평가를 세트에 포함했다.

내부 평가 (Internal evals)

공개 벤치마크가 모델 개발 중에 유용한 신호를 제공할 수 있지만, 특정 기능을 목표로 하는 자체 내부 평가를 구현하거나 내부 전문가에게 모델과 상호 작용하도록 요청하는 것을 대체할 수는 없다.

(이것은 AI 제품을 구축하는 경우 특히 그렇다. 이 주제에 대한 구체적인 조언은 Hamel Husain의 훌륭한 블로그 게시물 https://www.decodingai.com/?utm_source=navbar&utm_medium=web 을 참고해라.)

예를 들어, SmolLM3의 경우 모델이 멀티턴 추론을 할 수 있는지 평가하기 위한 벤치마크가 필요했으므로, 이를 측정하기 위해 Multi-IF 변형을 구현했다.

바이브 평가 및 아레나 (Vibe evaluations and arenas)

마찬가지로, 우리는 중간 체크포인트를 “바이브 테스트” (즉, 모델과 상호 작용하는 것)하는 것이 평가 점수로 포착되지 않는 모델 동작의 미묘한 기벽을 발견하는 데 필수적이라는 것을 발견했다. 나중에 논의하겠지만, 바이브 테스트는 모든 시스템 메시지가 코퍼스에서 삭제되는 데이터 처리 코드의 버그를 발견했다! 이것은 또한 인기 있는 LMArena에서처럼 인간 선호도를 측정하기 위해 대규모로 수행될 수 있는 것이다. 그러나 크라우드소싱된 인간 평가는 깨지기 쉬운 경향이 있으므로 (실제 유용성보다 아첨과 화려한 언사를 선호함), 낮은 신호 피드백으로 보는 것이 중요하다.

☝️ 학습 데이터를 오염 제거한다

공개 벤치마크에 의존할 때의 한 가지 위험은 모델이 쉽게 그것들에 과적합될 수 있다는 것인데, 특히 목표 벤치마크와 유사한 프롬프트 및 응답을 생성하기 위해 합성 데이터가 사용될 때 그렇다. 이러한 이유로, 모델 개발을 안내하는 데 사용할 평가에 대해 학습 데이터를 오염 제거하는 것이 필수적이다. Open-R1 (https://github.com/huggingface/open-r1/blob/main/scripts/decontaminate.py) 에 있는 것과 같은 스크립트를 사용하여 N-gram 일치로 이를 수행할 수 있다.

SmolLM3의 경우 구체적으로, 우리는 지침을 안정적으로 따르고 수학 및 코드와 같은 인기 있는 도메인에서 잘 추론할 수 있는 하이브리드 추론 모델을 원했다. 우리는 또한 기본 모델의 다국어성 및 긴 컨텍스트 검색 기능을 보존하도록 보장하고 싶었다.

이것은 우리를 다음과 같은 평가 세트를 사용하게 만들었다:

벤치마크	카테고리	프롬프트 수	지표
AIME25	경쟁 수학	30	avg@64
LiveCodeBench (검증용 v4, 최종 출시용 v5)	경쟁 프로그래밍	100 (268)	avg@16
GPQA Diamond	대학원 수준 추론	198	avg@8
IFEval	지침 따르기	541	정확도
MixEval Hard	정렬	1000	정확도
BFCL v3	도구 사용	4441	혼합
Global MMLU (검증용 lite)	다국어 Q&A	590,000 (6,400)	정확도
GSMPlus (검증용 mini)	견고성	10,000 (2,400)	정확도
RULER	긴 컨텍스트	6,500	정확도

이 평가들이 실제로 무엇을 테스트하는지에 대한 구체적인 감각을 얻기 위해 각각의 몇 가지 예시 질문을 살펴보자:

스크린샷 2025-12-02 오후 6.55.06.png

위의 예시들을 훑어보면서 각 벤치마크의 질문 유형을 봐라. 도메인의 다양성이 우리가 제거 실험 전반에 걸쳐 모델 능력의 다양한 측면을 테스트하고 있음을 어떻게 보장하는지 주목해라.

우리가 작업하고 있던 30억 모델 규모에 대해, 우리는 이러한 평가들이 실행 가능한 신호를 주고, 학습 자체보다 빠르게 실행되며, 개선이 샘플링 노이즈가 아니라 실제라는 확신을 줄 것이라고 느꼈다. 우리는 또한 기본 모델 성능에서 너무 많이 회귀하지 않았는지 확인하기 위해 사전 학습 평가 (전체 목록은 제거 실험 섹션 참조) 의 성능도 계속 추적했다.

☝️평가의 우선순위를 정한다

위의 이야기는 우리가 팀으로 모여 평가 세트에 대해 합의하고, 어떤 모델을 학습시키기 전에 그것들을 준비했다는 것처럼 들린다. 현실은 훨씬 더 지저분했다: 우리는 촉박한 마감일이 있었고 위의 많은 평가들이 구현되기 전에 모델 학습을 서둘렀다 (예: RULER는 모델 출시 며칠 전까지 사용할 수 없었다 🙈). 돌이켜보면 이것은 실수였으며, 우리는 어떤 핵심 평가가 사후 학습 전반에 걸쳐 보존되어야 하는지 사전 학습 팀과 논의했어야 했고 기본 모델 학습이 완료되기 훨씬 전에 그것들을 구현하는 것을 우선순위로 삼았어야 했다. 즉, 다른 모든 것보다 평가를 우선시해야 한다!

참여 규칙

수천 개의 모델을 평가하면서 얻은 몇 가지 힘들게 얻은 교훈으로 이 섹션을 요약한다:

모델 개발 중 평가를 가속화하기 위해 작은 하위 집합을 사용한다. 예를 들어, LiveCodeBench v4는 v5와 높은 상관관계가 있지만 절반의 시간 만에 실행된다. 대안으로, 전체 평가와 안정적으로 일치하는 가장 작은 프롬프트 하위 집합을 찾으려는 tinyBenchmarks (Polo et al., 2024)와 같은 방법을 사용한다.
추론 모델의 경우, 채점된 출력에서 생각의 사슬(chain-of-thought)을 제거한다. 이것은 거짓 긍정을 제거하고 “50단어 미만으로 시를 써라”와 같은 제약 조건을 위반하는 응답에 페널티를 주는 IFEval과 같은 벤치마크에 직접적인 영향을 미친다.
평가가 LLM 심판을 사용하는 경우, 시간에 따른 공정한 비교를 위해 심판과 버전을 고정한다. 더 좋은 방법은 모델 공급자가 심판 모델에 대한 서비스를 중단하더라도 평가를 재현할 수 있도록 오픈 가중치 모델을 사용하는 것이다.
기본 모델의 오염을 경계한다. 예를 들어, AIME 2025 이전에 출시된 대부분의 모델은 AIME 2024보다 훨씬 나쁜 성능을 보였는데, 이는 일부 벤치마크 최적화가 작용했음을 시사한다.
가능하다면, 제거 실험 중에 사용된 모든 것을 테스트가 아닌 검증으로 취급한다. 이는 Tulu3 평가 프레임워크 (Lambert et al., 2025)와 유사하게 최종 모델 보고서를 위해 보류된 벤치마크 세트를 유지하는 것을 의미한다.
공개 스위트에 대한 과적합을 잡기 위해 항상 자신의 데이터 및 작업에 대한 작은 “바이브 평가” 세트를 포함한다.
문제 수가 적은 평가 (일반적으로 ~2k 미만)의 경우, k번 샘플링하고 avg@k 정확도를 보고한다. 이것은 개발 중 잘못된 결정으로 이어질 수 있는 노이즈를 완화하는 데 중요하다.
새로운 평가를 구현할 때, 몇 가지 모델의 공개된 결과를 복제할 수 있는지 확인한다 (일부 오차 범위 내에서). 이것을 하지 않으면 나중에 구현을 수정하고 많은 체크포인트를 재평가해야 하는 경우 많은 시간을 낭비하게 될 것이다.
의심스러울 때는 항상 평가 데이터로 돌아가서 모델에 무엇을 프롬프트하고 있는지 주목해서 검사한다.

평가가 준비되었으므로, 이제 모델을 좀 학습시킬 시간이다! 그 전에, 우리는 먼저 사후 학습 프레임워크를 선택해야 한다.

무역의 도구 (Tools of the trade)

모든 사후 학습 레시피 뒤에는 대규모 실험을 가능하게 하는 프레임워크 및 라이브러리 도구 상자가 있다. 각 프레임워크는 자체적으로 지원되는 알고리즘, 파인 튜닝 방법 및 확장성 기능 세트를 제공한다. 아래 표는 각 프레임워크의 지도 파인 튜닝(SFT)에서 선호도 최적화(PO) 및 강화 학습(RL)에 이르는 주요 지원 영역을 요약한다:

프레임워크	SFT	PO	RL	멀티모달	FullFT	LoRA	분산
TRL	✅	✅	✅	✅	✅	✅	✅
Axolotl	✅	✅	✅	✅	✅	✅	✅
OpenInstruct	✅	✅	✅	❌	✅	✅	✅
Unsloth	✅	✅	✅	✅	✅	✅	✅
vERL	✅	❌	✅	✅	✅	✅	✅
Prime RL	✅	❌	✅	❌	✅	✅	✅
PipelineRL	❌	❌	✅	❌	✅	✅	✅
ART	❌	❌	✅	❌	❌	✅	❌
TorchForge	✅	❌	✅	❌	✅	❌	✅
NemoRL	✅	✅	✅	❌	✅	❌	✅
OpenRLHF	✅	✅	✅	❌	✅	✅	✅

여기서 FullFT는 학습 중 모든 모델 매개변수가 업데이트되는 **전체 파인 튜닝(full fine-tuning)**을 의미한다. LoRA는 기본 모델을 동결된 상태로 유지하면서 작은 저순위 행렬만 업데이트하는 매개변수 효율적 접근 방식인 Low-Rank Adaptation을 나타낸다. 멀티모달은 텍스트 이외의 양식 (예: 이미지)에 대한 학습 지원 여부를 나타내며 분산은 하나 이상의 GPU에서 모델을 학습시키는 것이 가능한지 여부를 나타낸다.

Hugging Face에서 우리는 TRL을 개발하고 유지 관리하므로, 이것이 우리가 선택한 프레임워크이며 SmolLM3를 사후 학습시키는 데 사용하였다.

📍프레임워크를 포크(fork)하라

이 분야의 빠른 속도를 감안할 때, 우리는 TRL의 내부 포크에서 실험을 실행하는 것이 꽤 효과적이라는 것을 발견했다. 이를 통해 새로운 기능을 매우 빠르게 추가할 수 있으며, 나중에 메인 라이브러리로 업스트림된다. 프레임워크의 내부 작업에 익숙하다면, 유사한 워크플로를 채택하는 것이 빠른 반복을 위한 강력한 접근 방식이 될 수 있다.

도대체 왜 프레임워크를 사용하는가?

학습 프레임워크 사용을 한탄하고 대신 항상 모든 것을 처음부터 구현해야 한다고 주장하는 연구자 부류가 있다. 여기 내포된 주장은 “진정한” 이해는 모든 RL 알고리즘을 다시 구현하거나, 모든 분산 학습 기본 요소를 수동으로 코딩하거나, 일회용 평가 하네스를 해킹하여 만드는 것에서만 나온다는 것이다.

그러나 이 입장은 현대 연구 및 생산의 현실을 무시한다. RL을 예로 들어본다. PPO 및 GRPO와 같은 알고리즘은 올바르게 구현하기가 까다로운 것으로 악명이 높으며 (Huang et al., 2024), 정규화 또는 KL 페널티의 작은 실수는 며칠 간의 낭비된 컴퓨팅 및 노력으로 이어질 수 있다.

마찬가지로, 어떤 알고리즘의 단일 파일 구현을 직접 작성하고 싶을 수 있지만, 그 동일한 스크립트가 10억에서 1000억 이상의 매개변수로 확장될 수 있을까?

프레임워크는 기본 사항이 이미 잘 이해되어 있고 끝없이 재발명하는 것이 시간 낭비이기 때문에 존재한다. 그렇다고 저수준 팅커링에 가치가 없다는 말은 아니다. PPO를 처음부터 한 번 구현하는 것은 훌륭한 공부가 되는 연습이다. 프레임워크 없이 장난감 트랜스포머를 작성하면 어텐션이 실제로 어떻게 작동하는지 배울 수 있다. 그러나 대부분의 경우, 마음에 드는 프레임워크를 선택하고 목적에 맞게 해킹하여 사용한다.

잔소리는 그만두고, 우리가 종종 학습 실행을 시작하는 곳을 살펴보자.

왜 (거의) 모든 사후 학습 파이프라인이 SFT로 시작하는가

요즘 X(트위터)에서 시간을 보낸다면, 강화 학습(RL)만이 유일한 게임이라고 생각할 것이다. 매일 새로운 약어, 알고리즘 조정, 그리고 RL이 새로운 능력을 끌어낼 수 있는지 여부에 대한 뜨거운 논쟁이 벌어지고 있다 (Chu et al., 2025; Yue et al., 2025).

물론 RL은 새로운 것이 아니다. OpenAI와 다른 연구소들은 초기 모델을 정렬하기 위해 인간 피드백 기반 강화 학습(RLHF) (Lambert et al., 2022)에 크게 의존했지만, DeepSeek-R1 (DeepSeek-AI, Guo, et al., 2025)이 출시되고 나서야 RL 기반 사후 학습이 오픈 소스 생태계에서 진정으로 인기를 얻었다.

그러나 변하지 않은 한 가지가 있다: 거의 모든 효과적인 사후 학습 파이프라인은 여전히 지도 파인 튜닝(SFT)으로 시작한다. 이유는 간단하다:

저렴하다: SFT는 RL에 비해 적당한 컴퓨팅을 요구한다. 실리콘 모닥불을 피우지 않고도, 그리고 RL에 필요한 시간의 일부만으로도 일반적으로 의미 있는 이득을 얻을 수 있다.
안정적이다: 보상 설계 및 하이퍼파라미터에 극도로 민감한 것으로 악명 높은 RL과 달리, SFT는 “그냥 작동한다”.
올바른 기준선이다: 좋은 SFT 체크포인트는 일반적으로 여러분이 추구하는 대부분의 이득을 제공하며, DPO 또는 RLHF와 같은 나중 방법을 훨씬 더 효과적으로 만든다.

실제로, 이것은 SFT가 쉽기 때문에 첫 단계일 뿐만 아니라; 더 복잡한 것을 시도하기 전에 성능을 일관되게 향상시키는 단계임을 의미한다. 기본 모델로 작업할 때 특히 그렇다. 몇 가지 예외를 제외하고, 기본 모델은 고급 사후 학습 방법의 이점을 얻기에는 너무 정제되지 않았다.

📍DeepSeek R1-Zero는 어떤가?

최전선에서는, SFT로 시작하는 일반적인 이유가 항상 적용되는 것은 아니다. 증류할 더 강력한 모델이 없으며 긴 생각의 사슬과 같은 복잡한 행동에 대해 인간 주석은 너무 노이즈가 많다. 이것이 DeepSeek가 SFT를 건너뛰고 R1-Zero로 바로 RL로 간 이유이다; 표준 지도로 가르칠 수 없는 추론 행동을 발견하기 위해서이다.

여러분이 그 체제에 있다면, RL로 시작하는 것이 합리적일 수 있다. 하지만 그곳에서 일하고 있다면… 아마 이 블로그 게시물을 읽고 있지 않을 것이다 😀.

따라서 SFT가 대부분의 파이프라인이 시작되는 곳이라면, 다음 질문은: 무엇을 파인 튜닝해야 하는가이다. 그것은 올바른 기본 모델을 선택하는 것에서 시작한다.

기본 모델 선택

사후 학습을 위한 기본 모델을 선택할 때, 몇 가지 실용적인 차원이 가장 중요하다:

모델 크기: 스몰(smol) 모델들은 시간이 지남에 따라 극적으로 개선되었지만, 오늘날에도 여전히 더 큰 모델이 더 잘 일반화하고 종종 더 적은 샘플로 일반화한다. 학습 후 모델을 사용하거나 배포할 계획을 대표하는 모델 크기를 선택하라. Hugging Face Hub에서 양식 및 크기별로 모델을 필터링하여 적합한 후보를 찾을 수 있다.

아키텍처 (MoE 대 Dense): MoE 모델은 토큰당 매개변수의 하위 집합을 활성화하고 컴퓨팅 단위당 더 높은 용량을 제공한다. 대규모 서빙에는 훌륭하지만, 경험상 파인 튜닝하기 더 까다롭다. 대조적으로, 밀집형 모델은 학습하기 더 간단하고 종종 더 작은 규모에서 MoE보다 성능이 뛰어나다.
사후 학습 실적: 벤치마크는 유용하지만, 기본 모델이 이미 커뮤니티와 공명하는 강력한 사후 학습 모델 컬렉션을 낳았다면 훨씬 더 좋다. 이것은 모델이 잘 학습되는지에 대한 대리 지표를 제공한다.

(LocalLLaMa 서브레딧은 새로운 모델의 광범위한 분위기를 이해하기에 좋은 곳이다. Artificial Analysis 및 LMArena도 새로운 모델에 대한 독립적인 평가를 제공하지만, 이러한 플랫폼은 때때로 모델 제공자에 의해 벤치마크 최적화(benchmaxxed)된다.)

우리의 경험상, Qwen, Mistral, 및 DeepSeek의 기본 모델이 사후 학습에 가장 적합하며, Qwen은 각 모델 시리즈가 일반적으로 큰 매개변수 범위 (예: Qwen3 모델은 0.6B에서 235B까지 다양함!)를 포괄하기 때문에 확실한 인기 모델이다. 이 기능은 확장을 훨씬 더 간단하게 만든다.

배포 요구 사항에 맞는 기본 모델을 선택했다면, 다음 단계는 핵심 기술을 조사하기 위한 간단하고 빠른 SFT 기준선을 수립하는 것이다.

간단한 기준선 학습

SFT의 경우, 좋은 기준선은 학습 속도가 빠르고, 모델의 핵심 기술에 집중하며, 특정 능력이 기준에 미치지 못할 때 더 많은 데이터로 확장하기 간단해야 한다. 초기 기준선에 사용할 데이터셋을 선택하는 것은 고품질일 가능성이 높은 데이터셋에 대한 취향과 친숙함을 포함해서 이루어진다. 일반적으로 학술 벤치마크에서 높은 점수를 보고하는 공개 데이터셋에 과도하게 인덱싱하는 것을 피하고 대신 OpenHermes와 같은 훌륭한 모델을 학습시키는 데 사용된 데이터셋에 집중한다. 예를 들어, SmolLM1 개발에서 우리는 처음에 서류상으로는 훌륭한 데이터셋인 WebInstruct에 대해 SFT를 실행했다. 그러나 바이브 테스트 중에, 모델이 “잘 지내세요?”와 같은 간단한 인사에 방정식으로 응답했기 때문에 과학에 너무 집중되어 있다는 것을 발견했다.

(학습 데이터의 기벽을 발견하기 위해 바이브 테스트를 사용하는 것은 이 챕터에서 반복되는 주제이다 — 단순히 모델과 채팅하는 것의 힘을 과소평가하지 않아야 한다!)

이로 인해 우리는 Everyday Conversations 데이터셋을 만들게 되었고 이는 소형 모델에 기본 채팅 기능을 주입하는 데 중요한 것으로 판명되었다.

SmolLM3의 경우, 우리는 하이브리드 추론 모델을 학습시키기로 했고 처음에 추론, 지침 따르기, 및 조종 가능성을 목표로 하는 작은 데이터셋 세트를 선택했다. 아래 표는 각 데이터셋의 통계를 보여준다:

데이터셋	추론 모드	예제 수	예제 %	토큰 수 (M)	토큰 %	예제당 평균 토큰	컨텍스트 내 평균 토큰	응답 내 평균 토큰	평균 턴 수
Everyday Conversations	/no_think	2,260	2.3	0.6	0.8	260.2	222.3	94.0	7.8
SystemChats 30k	/no_think	33,997	35.2	21.5	28.2	631.9	422.8	267.7	6.3
Tulu 3 SFT Personas IF	/no_think	29,970	31.0	13.3	17.5	444.5	119.8	380.7	2
Everyday Conversations (Qwen3-32B)	/think	2,057	2.1	3.1	4.1	1,522.4	376.8	1,385.6	4
SystemChats 30k (Qwen3-32B)	/think	27,436	28.4	29.4	38.6	1070.8	84.6	1,042.7	2
s1k-1.1	/think	835	0.9	8.2	10.8	8,859.3	370.9	9,728.5	2
합계	-	96,555	100.0	76.1	100.0	2,131.5	266.2	2,149.9	4.0

하이브리드 추론 기준선을 위한 데이터 혼합

SmolLM3 개발 전반에 걸쳐 배웠듯이, 하이브리드 추론 모델을 학습시키는 것은 표준 SFT보다 까다롭다. 단순히 데이터셋을 섞을 수 없고; 모드 전반에 걸쳐 데이터를 **짝지어(pair)**야 하기 때문이다. 각 예제는 모델이 확장된 추론에 참여해야 하는지 아니면 간결한 답변을 제공해야 하는지를 명확하게 나타내야 하며, 이상적으로는 모드를 언제 전환해야 하는지 가르치는 병렬 예제를 필요로 한다. 위 표에서 주목해야 할 또 다른 사항은 예제 수가 아닌 토큰 수 측면에서 데이터 혼합의 균형을 맞춰야 한다는 것이다: 예를 들어, s1k-1.1 데이터셋은 전체 예제의 ~1%이지만 긴 추론 응답으로 인해 전체 토큰의 ~11%를 차지한다.

이것은 우리가 가장 신경 쓰는 기술 전반에 걸쳐 기본적인 범위를 제공했지만, 또한 새로운 도전을 도입했다: 각 데이터셋은 확장된 사고를 가능하게 해야 하는지 여부에 따라 다르게 형식화되어야 했다. 이러한 형식을 통합하기 위해, 우리는 일관된 채팅 템플릿이 필요했다.

좋은 채팅 템플릿 선택

채팅 템플릿을 선택하거나 설계할 때, 모든 것에 맞는 정답은 없다. 실제 상황에서, 우리는 미리 생각해볼 가치가 있는 몇 가지 질문이 있다는 것을 발견했다:

사용자가 시스템 역할을 사용자 정의할 수 있는가? 사용자가 자신의 시스템 프롬프트 (예: “해적처럼 행동하라”)를 정의할 수 있어야 한다면, 템플릿은 그것을 깔끔하게 처리해야 한다.
모델이 도구를 필요로 하는가? 모델이 API를 호출해야 한다면, 템플릿은 도구 호출 및 응답을 위한 구조화된 출력을 수용해야 한다.
추론 모델인가? 추론 모델은 <think> ... </think>와 같은 템플릿을 사용하여 모델의 “생각”을 최종 답변과 분리한다. 일부 모델은 대화의 턴 전반에 걸쳐 추론 토큰을 버리며, 채팅 템플릿은 그 로직을 처리해야 한다.
추론 엔진과 작동할 것인가? vLLM 및 SGLang과 같은 추론 엔진은 추론 및 도구를 위한 전용 파서가 있다. 이러한 파서와의 호환성은 나중에 많은 고통을 덜어준다. 특히 일관된 도구 호출이 필수적인 복잡한 에이전트 벤치마크에서 그렇다.

아래 표는 몇 가지 인기 있는 채팅 템플릿과 주요 고려 사항 전반에 걸친 비교를 보여준다:

채팅 템플릿	시스템 역할 사용자 정의	도구	추론	추론 호환성	비고
ChatML	✅	✅	❌	✅	간단하고 대부분의 사용 사례에 좋음.
Qwen3	✅	✅	✅	✅	하이브리드 추론 템플릿
DeepSeek-R1	❌	❌	✅	✅	`<think>`로 추론 콘텐츠를 미리 채움(Prefills).
Llama 3	✅	✅	❌	✅	파이썬 코드 인터프리터와 같은 내장 도구가 있음.
Gemma 3	✅	❌	❌	❌	첫 번째 사용자 턴에서 정의된 시스템 역할 사용자 정의.
Command A Reasoning	✅	✅	✅	❌	모델당 여러 채팅 템플릿.
GPT-OSS	✅	✅	✅	✅	Harmony 응답 형식 기반. 복잡하지만 다재다능함.

대부분의 경우에서, 우리는 ChatML이나 Qwen의 채팅 템플릿이 시작하기에 훌륭한 시작점이라는 것을 발견했다. SmolLM3의 경우, 우리는 하이브리드 추론을 위한 템플릿이 필요했고 Qwen3가 우리가 신경 쓰는 차원 전반에 걸쳐 좋은 균형을 이룬 몇 안 되는 템플릿 중 하나라는 것을 확인했다. 그러나 우리가 완전히 만족하지 못했던 한 가지 성질이 있었다: 추론 콘텐츠가 대화의 마지막 턴을 제외한 모든 턴에서 버려진다는 것이다. 아래 그림과 같이, 이것은 OpenAI의 추론 모델이 작동하는 방식과 유사하다:

스크린샷 2025-12-02 오후 9.24.53.png

이것은 추론 시 (컨텍스트 폭발을 피하기 위해) 합리적이지만, 우리는 학습을 위해서는 모델을 적절하게 조건화하기 위해 모든 턴에 걸쳐 추론 토큰을 유지하는 것이 중요하다고 결론지었다.

대신, 우리는 다음 기능을 갖춘 자체 채팅 템플릿을 만들기로 결정했다:

Llama 3 및 독점 모델에서 탈옥된 것과 같은 구조화된 시스템 프롬프트. 우리는 또한 시스템 프롬프트를 완전히 재정의할 수 있는 유연성을 제공하고 싶었다.
JSON 도구 호출 대신 임의의 파이썬 코드를 실행하는 코드 에이전트 지원.
시스템 메시지를 통한 추론 모드의 명시적 제어.

채팅 템플릿 디자인을 반복하기 위해, 우리는 Chat Template Playground를 사용했다. 이 편리한 애플리케이션은 Hugging Face의 동료들에 의해 개발되었으며 메시지가 렌더링되는 방식을 미리 보고 서식 문제를 디버깅하기 쉽게 만든다.

스크린샷 2025-12-02 오후 9.26.23.png

드롭다운에서 다른 예제를 선택하여 채팅 템플릿이 멀티턴 대화, 추론 또는 도구 사용에 대해 어떻게 작동하는지 봐라. JSON 입력을 수동으로 변경하여 다른 동작을 활성화할 수도 있다. 예를 들어, enable_thinking: false를 제공하거나 시스템 메시지에 /no_think를 추가하면 무슨 일이 일어나는지 보라.

초기 데이터셋과 채팅 템플릿을 정했다면, 이제 몇몇 기준선들을 학습시켜볼 차례이다!

아기 기준선 (Baby baselines)

최적화에 뛰어들고 성능의 모든 점수를 짜내기 전에, 우리는 몇 가지 “아기 기준선”을 수립해야 한다. 이 기준선들은 (아직) 최첨단에 도달하는 것이 아니라, 채팅 템플릿이 원하는 대로 수행하고 초기 하이퍼파라미터 세트가 안정적인 학습을 생성하는지 검증하는 것을 목표로 한다. 이 기초를 갖춘 후에만 우리는 하이퍼파라미터와 학습 혼합을 집중적으로 튜닝하기 시작할 수 있다.

SFT 기준선 학습과 관련하여 고려해야 할 주요 사항은 다음과 같다:

전체 파인 튜닝(FullFT)을 사용할 것인가 아니면 LoRA나 QLoRA와 같은 매개변수 효율적 방법을 사용할 것인가? Thinking Machines의 훌륭한 블로그 게시물(https://thinkingmachines.ai/blog/lora/)에 설명된 대로, LoRA는 특정 조건 (일반적으로 데이터셋 크기에 의해 결정됨) 하에서 FullFT와 일치할 수 있다.
어떤 유형의 병렬 처리가 필요한가? 소형 모델이나 LoRA로 학습된 모델의 경우 일반적으로 데이터 병렬 처리로 충분하다. 더 큰 모델의 경우 모델 가중치와 옵티마이저 상태를 공유하기 위해 FSDP2 또는 DeepSpeed ZeRO-3가 필요하다. 긴 컨텍스트로 학습된 모델의 경우 컨텍스트 병렬 처리와 같은 방법을 사용한다.
하드웨어가 지원하는 경우 FlashAttention 및 Liger와 같은 커널을 사용한다. 이러한 커널 중 다수는 Hugging Face Hub에 호스팅되어 있으며 TRL에서 간단한 인수를 통해 설정하여 VRAM 사용량을 크게 낮출 수 있다.
어시스턴트 토큰에 대해서만 학습하도록 손실을 마스킹한다. 아래에서 논의하겠지만, 이는 채팅 템플릿의 어시스턴트 턴을 특별한 {% generation %} 키워드로 감싸서 달성할 수 있다.
학습률을 튜닝한다; 데이터 외에도, 이것은 모델이 “그저 그런” 대 “훌륭한” 지를 결정하는 가장 중요한 요소이다.
학습 샘플을 패킹(pack)하고 데이터 분포와 일치하도록 시퀀스 길이를 튜닝한다. 이것은 학습 속도를 극적으로 높일 것이다. TRL에는 이를 수행하는 편리한 애플리케이션이 있다.

SmolLM3에 대해 이러한 선택 중 일부가 어떻게 전개되었는지 살펴본다. 첫 번째 기준선 실험을 위해, 우리는 간단한 온전성 검사(sanity check)를 원했다: 채팅 템플릿이 실제로 하이브리드 추론을 이끌어내는가? 이를 테스트하기 위해 우리 테이블의 세 가지 데이터 혼합을 비교했다:

Instruct: 비추론 예제에 대해 학습한다.
Thinking: 추론 예제에 대해 학습한다.
Hybrid: 모든 예제에 대해 학습한다.

각 혼합에 대해, 우리는 1e-5의 학습률, 128의 유효 배치 크기를 사용하여 FullFT로 SmolLM3-3B-Base에 대해 SFT를 실행하고 1 에포크 동안 학습했다.

(우리는 대부분의 모델과 데이터셋에 대해, 이 하이퍼파라미터 선택이 기준선으로 잘 작동한다는 것을 발견했다.)

이것들은 작은 데이터셋이므로 패킹을 사용하지 않았으며, Instruct 하위 집합의 경우 시퀀스를 8,192 토큰으로, 나머지는 32,768 토큰으로 제한했다. 8 x H100의 한 노드에서, 이러한 실험은 빠르게 실행할 수 있었으며 하위 집합에 따라 30-90분 사이가 소요되었다. 아래 그림은 해당 추론 모드에 대한 각 하위 집합의 성능을 비교한다:

스크린샷 2025-12-02 오후 9.30.09.png

이 결과는 하이브리드 모델이 한 추론 모드에 대한 데이터 혼합이 다른 모드에 거의 영향을 미치지 않는 일종의 “분리 뇌(split brain)“를 나타낸다는 것을 빠르게 보여주었다. 이는 Instruct, Thinking 및 Hybrid 하위 집합 간에 대부분의 평가가 유사한 점수를 갖는 것으로 분명하지만, LiveCodeBench v4 및 IFEval은 예외로 하이브리드 데이터가 전반적인 성능을 향상시킨다.

기준선 바이브 테스트

평가는 괜찮아 보였지만, 하이브리드 모델을 다른 페르소나 (예: 해적처럼)로 행동하게 하려고 했을 때, 시스템 메시지에 배치한 것은 무엇이든 지속적으로 무시했다. 조금 파헤친 후, 우리는 그 이유가 데이터를 형식화한 방식 때문이라는 것을 발견했다:

무슨 일이 일어났냐 하면, 채팅 템플릿 설계에서 우리는 시스템 프롬프트를 저장하기 위해 custom_instructions 인수를 노출했다. 예를 들어, 대화에서 페르소나를 설정하는 방법은 다음과 같다:

from transformers import AutoTokenizer

tok = AutoTokenizer.from_pretrained("HuggingFaceTB/SmolLM3-3B")

messages = [
    {
        "content": "I'm trying to set up my iPhone, can you help?",
        "role": "user",
    },
    {
        "content": "Of course, even as a vampire, technology can be a bit of a challenge sometimes [TRUNCATED]",
        "role": "assistant",
    },
]
chat_template_kwargs = {
    "custom_instructions": "You are a vampire technologist",
    "enable_thinking": False,
}
rendered_input = tok.apply_chat_template(
    messages, tokenize=False, **chat_template_kwargs
)
print(rendered_input)
## <|im_start|>system
### Metadata

## Knowledge Cutoff Date: June 2025
## Today Date: 28 October 2025
## Reasoning Mode: /no_think

### Custom Instructions

## You are a vampire technologist

## <|im_start|>user
## I'm trying to set up my iPhone, can you help?<|im_end|>
## <|im_start|>assistant
## <think>

## </think>
## Of course, even as a vampire, technology can be a bit of a challenge sometimes # [TRUNCATED]<|im_end|>

문제는 우리 데이터 샘플이 다음과 같이 보였다는 것이다:

{
    "messages": [
        {
            "content": "I'm trying to set up my iPhone, can you help?",
            "role": "user",
        },
        {
            "content": "Of course, even as a vampire, technology can be a bit of a challenge sometimes [TRUNCATED]",
            "role": "assistant",
        },
    ],
    "chat_template_kwargs": {
        "custom_instructions": None,
        "enable_thinking": False,
        "python_tools": None,
        "xml_tools": None,
    },
}

처리 코드의 버그가 custom_instructions를 None으로 설정했는데, 이는 사실상 모든 단일 학습 샘플에서 시스템 메시지를 제거했다 🙈! 그래서 이러한 학습 샘플에 대해 멋진 페르소나를 얻는 대신, 우리는 SmolLM3 기본 시스템 프롬프트로 끝났다:

chat_template_kwargs = {"custom_instructions": None, "enable_thinking": False}
rendered_input = tok.apply_chat_template(messages, tokenize=False, **chat_template_kwargs)
print(rendered_input)
## <|im_start|>system
#### Metadata

## Knowledge Cutoff Date: June 2025
## Today Date: 28 October 2025
## Reasoning Mode: /no_think

#### Custom Instructions

## You are a helpful AI assistant named SmolLM, trained by Hugging Face.

## <|im_start|>user
## I'm trying to set up my iPhone, can you help?<|im_end|>
## <|im_start|>assistant
## <think>

## </think>
## Of course, even as a vampire, technology can be a bit of a challenge sometimes [TRUNCATED]<|im_end|>

이것은 모든 페르소나가 custom_instructions를 통해 정의되는 SystemChats 하위 집합에 특히 문제가 되었으므로, 모델이 대화 중간에 무작위로 캐릭터를 전환하는 경향이 있었다. 이것은 우리를 다음 규칙으로 이끌었다:

☝️규칙

평가가 괜찮아 보일지라도 항상 모델을 바이브 테스트한다. 십중팔구, 학습 데이터의 미묘한 버그를 발견하게 될 것이다.

이 버그를 수정하는 것은 평가에 영향을 미치지 않았지만, 마침내 우리는 채팅 템플릿과 데이터셋 서식이 작동하고 있다는 확신을 가졌다. 설정이 안정되고 데이터 파이프라인이 확인되면, 다음 단계는 특정 기능을 개발하는 데 집중하는 것이다.

특정 기능 타겟팅

Open-R1 개발 중에, 우리는 기본 모델을 단일 턴 추론 데이터로만 학습시키면 멀티턴으로 일반화되지 않는다는 것을 발견했다. 이것은 놀라운 일이 아니다; 그러한 예제가 없다면, 모델은 학습 분포 밖에서 테스트되고 있는 것이다.

SmolLM3에 대해 이를 정량적으로 측정하기 위해, 우리는 /think 또는 /no_think 태그를 무작위로 삽입하여 모델이 추론 모드를 일관되게 전환할 수 있는지 테스트하는 ThinkFollow라는 내부 평가를 개발한 Qwen3에서 영감을 얻었다. 구현에서, 우리는 Multi-IF의 프롬프트를 가져온 다음 모델이 <think>와 </think> 태그로 닫힌 빈 또는 비어 있지 않은 생각 블록을 생성하는지 확인했다. 예상대로, 하이브리드 기준선의 결과는 모델이 첫 번째 턴을 넘어 추론 모드를 활성화하는 데 끔찍하게 실패함을 보여주었다:

스크린샷 2025-12-02 오후 9.35.19.png

이 기능을 수정하기 위해, 우리는 IFThink라는 새로운 데이터셋을 구축했다. Multi-IF 파이프라인을 기반으로, 우리는 Tulu 3의 지침 따르기 하위 집합에서 단일 턴 지침을 사용하고 Qwen3-32B를 사용하여 검증 가능한 지침과 추론 추적을 모두 생성함으로써 그것들을 멀티턴 교환으로 확장했다. 방법은 아래에 설명되어 있다:

(우리는 충돌하는 지침을 필터링하는 것을 고려했지만, 초기 결과가 이 단계를 건너뛸 만큼 충분히 강력했다.)

스크린샷 2025-12-02 오후 9.36.00.png

이 데이터를 우리의 기준선 혼합에 포함하니 극적인 개선이 이루어졌다:

스크린샷 2025-12-02 오후 9.36.23.png

IFThink로 멀티턴 추론 문제를 수정한 후, 우리의 기준선은 마침내 의도한 대로 동작했다; 턴 전반에 걸쳐 일관성을 유지하고, 지침을 따르며, 채팅 템플릿을 올바르게 사용할 수 있었다. 그 기초가 마련되었으므로, 우리는 기본으로 돌아갔다: 학습 설정 자체를 튜닝하는 것이다.

어떤 하이퍼파라미터가 실제로 중요한가?

SFT에서는, 실제로 중요한 하이퍼파라미터가 몇 개뿐이다. 학습률, 배치 크기, 그리고 패킹은 모델이 얼마나 효율적으로 학습하고 얼마나 잘 일반화하는지에 대한 거의 모든 것을 결정한다. 아기 기준선에서, 우리는 데이터와 채팅 템플릿을 검증하기 위해 합리적인 기본값을 선택했다. 이제 설정이 안정되었으므로, 우리는 이러한 선택이 기준선에 얼마나 많은 영향을 미치는지 확인하기 위해 다시 돌아왔다.

사용자 턴 마스킹 (Masking user turns)

채팅 템플릿에 대한 미묘한 설계 선택 중 하나는 학습 중에 사용자 턴을 마스킹할지 여부이다. 대부분의 채팅 스타일 데이터셋에서, 각 학습 예제는 교대로 나타나는 사용자 및 어시스턴트 메시지 (도구 호출이 섞일 수 있음)로 구성된다. 모델이 모든 토큰을 예측하도록 학습시키면, 고품질 어시스턴트 응답을 생성하는 데 집중하는 대신 사용자 쿼리를 자동 완성하는 것을 효과적으로 학습한다.

아래 그림과 같이, 사용자 턴 마스킹은 모델의 손실이 사용자 메시지가 아닌 어시스턴트 출력에 대해서만 계산되도록 보장함으로써 이를 방지한다:

스크린샷 2025-12-02 오후 9.37.40.png

TRL에서, 마스킹은 어시스턴트 토큰 마스크를 반환할 수 있는 채팅 템플릿에 적용된다. 실제 상황에서, 이것은 다음과 같이 템플릿에 {% generation %} 키워드를 포함하는 것을 수반한다:

{%- for message in messages -%}
  {%- if message.role == "user" -%}
    {{ "<|im_start|>" + message.role + "\n" + message.content + "<|im_end|>\n" }}
  {%- elif message.role == "assistant" -%}
{% generation %}
{{ "<|im_start|>assistant" + "\n" + message.content + "<|im_end|>\n" }}
{% endgeneration %}
  {%- endif %}
{%- endfor %}
{%- if add_generation_prompt %}
  {{ "<|im_start|>assistant\n" }}
{%- endif %}

그러고 나서, return_assistant_tokens_mask=True와 함께 apply_chat_template()이 사용될 때, 채팅 템플릿은 대화의 어느 부분이 마스킹되어야 하는지 나타낼 것이다. 다음은 간단한 예시로, 어시스턴트 토큰에는 ID 1이 부여되는 반면, 사용자 토큰은 ID 0으로 마스킹되는 방식을 보여준다:

chat_template = '''
{%- for message in messages -%}
  {%- if message.role == "user" -%}
    {{ "<|im_start|>" + message.role + "\n" + message.content + "<|im_end|>\n" }}
  {%- elif message.role == "assistant" %}
    {% generation %}
    {{ "<|im_start|>assistant" + "\n" + message.content + "<|im_end|>\n" }}
    {% endgeneration %}
  {%- endif %}
{%- endfor %}
{%- if add_generation_prompt %}
  {{ "<|im_start|>assistant\n" }}
{%- endif %}
'''
rendered_input = tok.apply_chat_template(messages, chat_template=chat_template, return_assistant_tokens_mask=True, return_dict=True)
print(rendered_input)
## {'input_ids': [128011, 882, 198, 40, 2846, 4560, 311, 743, 709, 856, 12443, 11, 649, 499, 1520, 30, 128012, 198, 257, 128011, 78191, 198, 2173, 3388, 11, 1524, 439, 264, 51587, 11, 5557, 649, 387, 264, 2766, 315, 264, 8815, 7170, 510, 2434, 12921, 9182, 60, 128012, 271], 'attention_mask': [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1], 'assistant_masks': [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1]}

실제 상황에서는, 마스킹은 다운스트림 평가에 큰 영향을 미치지 않으며 대부분의 경우 몇 지점의 개선을 제공한다. SmolLM3의 경우, 우리는 IFEval에 가장 큰 영향을 미친다는 것을 발견했는데, 아마도 모델이 프롬프트를 다시 진술하려는 경향이 적고 다양한 제약 조건을 더 면밀히 따르기 때문일 것이다. 사용자 마스킹이 각 평가 및 추론 모드에 어떤 영향을 미쳤는지 비교한 내용은 다음과 같다:

스크린샷 2025-12-02 오후 9.40.58.png

패킹할 것인가 말 것인가? (To pack or not to pack?)

시퀀스 패킹은 학습 효율성에 큰 차이를 만드는 학습 세부 사항 중 하나이다. SFT에서 대부분의 데이터셋은 가변 길이의 샘플을 포함하므로, 각 배치는 컴퓨팅을 낭비하고 수렴을 늦추는 많은 패딩 토큰을 포함한다.

패킹은 원하는 최대 토큰 길이에 도달할 때까지 여러 시퀀스를 함께 연결하여 이 문제를 해결한다. 연결을 수행하는 다양한 방법이 있으며, TRL은 패킹할 시퀀스의 순서가 길이에 의해 결정되는 “최적 적합 감소(best-fit decreasing)” 전략 (Ding et al., 2024)을 채택한다.

스크린샷 2025-12-02 오후 9.41.24.png

사후 학습 대 사전 학습에서의 패킹

사전 학습에서는 이것이 실제로 질문이 되지 않는다. 수조 개의 토큰에 대해 학습할 때, 패딩에 상당한 양의 컴퓨팅을 낭비하지 않으려면 패킹이 필수적이다. Megatron-LM 및 Nanotron과 같은 사전 학습 프레임워크는 기본적으로 패킹을 구현한다. 사후 학습은 다르다. 실행이 더 짧기 때문에 트레이드오프가 바뀐다.

패킹이 학습에 얼마나 효율적인지 감을 잡기 위해, 아래에서 우리는 기준 데이터셋의 1 에포크에 걸쳐 패킹과 비패킹 간의 런타임을 비교한다:

스크린샷 2025-12-02 오후 9.42.12.png

(런타임이 유효 배치 크기 32 이후 평평해지는 이유는 이것이 기울기 누적을 호출하지 않고 가능한 가장 큰 크기이기 때문이다.)

배치 크기에 따라, 우리는 패킹이 처리량을 3-5배 향상시킨다는 것을 알 수 있다! 그렇다면 항상 패킹을 사용해야 하는가? 어느 정도 답은 데이터셋이 얼마나 큰지에 달려있다. 패킹은 각 단계에 더 많은 토큰을 맞춤으로써 에포크당 최적화 단계 수를 줄이기 때문이다. 다음 그림에서 이를 볼 수 있다. 여기서 우리는 배치당 평균 비패딩 토큰 수를 시각화한다:

스크린샷 2025-12-02 오후 9.42.49.png

패킹을 사용하면 배치당 토큰 수는 배치 크기에 따라 선형적으로 확장되며 패킹 없는 학습에 비해 최적화 단계당 최대 33배 더 많은 토큰을 포함할 수 있다! 그러나 패킹은 학습 역학을 약간 변경할 수 있다: 전체적으로 더 많은 데이터를 처리하는 동안, 더 적은 기울기 업데이트를 수행하여 최종 성능에 영향을 줄 수 있으며, 특히 각 샘플이 더 중요한 작은 데이터셋에서 그렇다. 예를 들어, 동일한 유효 배치 크기 128에서 패킹 대 비패킹을 비교하면, IFEval과 같은 일부 평가가 거의 10퍼센트 포인트의 상당한 성능 타격을 입는 것을 볼 수 있다:

스크린샷 2025-12-02 오후 9.43.34.png

더 일반적으로, 유효 배치 크기가 32보다 크면 이 특정 모델 및 데이터셋에 대해 평균 성능 저하가 있음을 알 수 있다:

스크린샷 2025-12-02 오후 9.43.58.png

스크린샷 2025-12-05 오후 4.59.15.png

실제 상황에서는, 데이터셋이 방대한 대규모 SFT의 경우, 컴퓨팅 절약이 기울기 빈도의 사소한 차이보다 훨씬 크기 때문에 패킹은 거의 항상 유용하다. 그러나 더 작거나 더 다양한 데이터셋 — 도메인별 파인 튜닝이나 제한된 인간 큐레이션 데이터에 대한 지침 튜닝과 같은 — 의 경우, 샘플 세분성을 보존하고 모든 예제가 최적화에 깨끗하게 기여하도록 보장하기 위해 패킹을 비활성화할 가치가 있을 수 있다.

궁극적으로, 최선의 전략은 경험적으로 결정하는 것이다: 패킹을 활성화하고 시작하고, 처리량과 다운스트림 평가를 모두 모니터링하고, 속도 이득이 동등하거나 향상된 모델 품질로 이어지는지에 따라 조정한다.

학습률 튜닝

이제 마지막이지만 여전히 중요한 하이퍼파라미터인 학습률에 도달했다. 너무 높게 설정하면 학습이 발산할 수 있고; 너무 낮으면 수렴이 고통스럽게 느리다.

SFT에서 최적의 학습률은 일반적으로 사전 학습 중에 사용된 것보다 한 자릿수 (또는 그 이상) 작다. 이는 우리가 풍부한 표현을 가진 모델에서 초기화하고 있으며, 공격적인 업데이트는 치명적인 망각으로 이어질 수 있기 때문이다.

사후 학습 대 사전 학습에서의 학습률 튜닝

전체 실행에 대한 하이퍼파라미터 스윕이 엄청나게 비싼 사전 학습과 달리, 사후 학습 실행은 실제로 전체 학습률 스윕을 수행할 수 있을 만큼 짧다.

우리의 실험에서, 우리는 “최고의” 학습률이 모델 패밀리, 크기 및 패킹 사용에 따라 달라진다는 것을 발견했다. 높은 학습률은 폭발적인 기울기로 이어질 수 있으므로, 패킹이 활성화될 때 학습률을 약간 낮추는 것이 종종 더 안전하다는 것을 발견했다. 아래에서 볼 수 있듯이, 3e-6 또는 1e-5의 작은 학습률을 사용하는 것이 큰 값보다 전반적으로 더 나은 성능을 제공한다:

스크린샷 2025-12-02 오후 9.45.42.png

스크린샷 2025-12-02 오후 9.46.09.png

(스캔할 학습률 값 범위를 선택할 때, [1e-6, 3e-6, 1e-5, 3e-5, 1e-4]와 같은 초기 범위를 선택하는 것이 유용하다. 이것은 두 자릿수를 포괄하며 추가 튜닝을 적용할 수 있는 영역을 좁힐 수 있게 해준다.)

평균적으로 몇 점은 별것 아닌 것처럼 보일 수 있지만, AIME25와 같은 개별 벤치마크를 보면 학습률이 1e-5보다 클 때 성능이 급격히 떨어지는 것을 볼 수 있다.

에포크 수 확장

우리의 제거 실험에서, 우리는 빠르게 반복하기 위해 보통 단일 에포크 동안 학습한다. 좋은 데이터 혼합을 식별하고 학습률과 같은 주요 매개변수를 튜닝했다면, 다음 단계는 최종 학습을 위해 에포크 수를 늘리는 것이다.

예를 들어, 우리의 기준 데이터 혼합을 가져와 5 에포크 동안 학습하면, 평균적으로 몇 퍼센트 포인트의 성능을 더 짜낼 수 있음을 알 수 있다:

스크린샷 2025-12-02 오후 9.46.51.png

스크린샷 2025-12-02 오후 9.47.00.png

학습률 스캔에서 보았듯이, 평균 성능은 에포크 수 확장이 개별 평가에 미치는 영향을 가린다: 확장된 사고를 가진 LiveCodeBench v4의 경우, 우리는 1 에포크에 비해 성능을 거의 두 배로 올렸다!

SFT 데이터 혼합을 반복하고 모델이 합리적인 수준의 성능에 도달했다면, 다음 단계는 종종 선호도 최적화나 강화 학습과 같은 고급 방법을 탐색하는 것이다. 그러나 그것들에 뛰어들기 전에, 추가 컴퓨팅을 지속적인 사전 학습(continued pretraining)을 통해 기본 모델을 강화하는 데 쓰는 것이 더 나을지 고려할 가치가 있다.

📍사후 학습에서의 옵티마이저

사전 학습 섹션에서 언급한 또 다른 중요한 구성 요소는 옵티마이저이다. 마찬가지로 AdamW는 사후 학습을 위한 기본 선택으로 남아 있다. 열린 질문은 Muon과 같은 대체 옵티마이저로 사전 학습된 모델이 동일한 옵티마이저로 사후 학습되어야 하는지 여부이다. Kimi 팀은 사전 및 사후 학습에 동일한 옵티마이저를 사용하는 것이 Moonlight 모델에 최고의 성능을 낸다는 것을 발견했다.

지속적 사전 학습을 통한 추론 강화

지속적인 사전 학습—또는 멋지게 들리고 싶다면 중간 학습(mid-training)—은 기본 모델을 가져와 SFT를 수행하기 전에 대량의 도메인별 토큰으로 더 학습시키는 것을 의미한다. 중간 학습은 SFT의 목표 기능이 코딩이나 추론과 같은 공통 핵심 기술을 공유할 때 유용하다. 실제에서, 이것은 모델을 추론, 특정 언어, 또는 여러분이 신경 쓰는 다른 기능을 더 잘 지원하는 분포로 이동시킨다. 이미 그 핵심 기술을 통합한 모델에서 SFT를 시작하면 모델이 처음부터 핵심 기술을 배우기 위해 컴퓨팅을 사용하는 대신 SFT 데이터의 특정 주제에 더 잘 집중할 수 있다.

중간 학습 접근 방식은 일반 사전 학습 → 중간 학습 → 사후 학습의 3단계 파이프라인을 개척한 ULMFit (Howard & Ruder, 2018)으로 거슬러 올라가며, 이는 이제 FAIR의 Code World Model (team et al., 2025)과 같은 현대 LLM에서 일반적이다.

스크린샷 2025-12-02 오후 9.50.06.png

이 접근 방식은 Phi-4-Mini-Reasoning (Xu et al., 2025)의 학습에도 사용되었지만, 한 가지 변형이 있다: 저자들은 웹 데이터에 대해 지속적인 사전 학습을 하는 대신, 중간 학습 코퍼스로 DeepSeek-R1에서 증류된 추론 토큰을 사용했다. 결과는 설득력 있었으며, 다단계 학습을 통해 일관되고 큰 이득을 보여주었다:

모델	AIME24	MATH-500	GPQA Diamond
Phi-4-Mini	10.0	71.8	36.9
+ 증류 중간 학습	30.0	82.9	42.6
+ 증류 파인 튜닝	43.3	89.3	48.3
+ 롤아웃 DPO	50.0	93.6	49.0
+ RL (Phi-4-Mini-Reasoning)	57.5	94.6	52.0

이 결과들은 우리가 유사한 접근 방식을 시도하도록 자극했다. Open-R1에서 추론 데이터셋을 만들고 평가한 이전 경험으로부터, 우리는 작업할 세 가지 주요 후보를 가지고 있었다:

Mixture of Thoughts: 수학, 코드, 과학 전반에 걸쳐 DeepSeek-R1에서 증류된 35만 개의 추론 샘플.
Llama-Nemotron-Post-Training-Dataset: Llama3 및 DeepSeek-R1과 같은 다양한 모델에서 증류된 NVIDIA의 대규모 데이터셋. 우리는 DeepSeek-R1 출력에 대해 데이터셋을 필터링하여 약 364만 샘플 또는 187억 토큰을 얻었다.
OpenThoughts3-1.2M: QwQ-32B에서 증류된 120만 샘플, 165억 토큰으로 구성된 최고 품질의 추론 데이터셋 중 하나.

우리는 최종 SFT 혼합에 추론 데이터를 포함할 계획이었으므로, 해당 단계를 위해 Mixture of Thoughts를 아껴놓고 나머지는 중간 학습을 위해 사용하기로 결정했다. 우리는 SmolLM3 템플릿이 너무 일찍 “번인(burn in)“되는 것을 피하기 위해 ChatML을 채팅 템플릿으로 사용했다. 또한 128의 유효 배치 크기로 학습을 가속화하기 위해 8개 노드를 사용하여 2e-5의 학습률로 5 에포크 동안 학습했다.

📍언제 중간 학습을 하는가?

우리가 SFT 실행을 몇 번 한 후에 중간 학습을 논의하는 이유가 궁금할 수 있다. 연대기적으로, 중간 학습은 기본 모델에 대한 SFT 이전에 발생한다. 그러나 중간 학습을 수행하기로 한 결정은 초기 SFT 실험을 실행하고 성능 격차를 확인한 후에만 명확해진다. 실제에서, 여러분은 종종 반복할 것이다: SFT를 실행하여 약한 영역을 식별하고, 목표 중간 학습을 수행한 다음, 다시 SFT를 실행한다. 이 섹션을 “SFT만으로 충분하지 않을 때 해야 할 일”로 생각하라.

녹는 GPU의 미스터리

이 실험들을 실행하는 것은 우리 클러스터에서 놀라운 도전으로 판명되었다: 노화된 GPU는 다양한 지점에서 스로틀링되어 하드웨어 고장과 각 실행의 강제 재시작으로 이어졌다. 어떤 상황이었는지 맛보여드리기 위해, 다음은 실행 중 하나의 로그이며, 각 색상은 재시작을 나타낸다:

우리는 처음에 DeepSpeed가 범인일 수 있다고 생각했다. 액셀러레이터가 처리량에 고도로 최적화되어 있기 때문이다. 이를 테스트하기 위해 DP로 전환했는데, 다소 도움이 되었지만 손실이 극적으로 달랐다!

(한밤중에 코드에서 버그를 찾는 것은 생각보다 흔하다. 돌이켜보면, 이 규모의 긴 실행의 경우 nanotron이 실전 검증되었고 처리량이 더 빨랐기 때문에 그것을 사용하는 것이 더 합리적이었을 것이다.)

나중에 발견했듯이, Accelerate의 DP 버그로 인해 가중치와 기울기가 모델의 기본 정밀도 (이 경우 BF16)로 저장되어 수치 불안정성과 누적 및 최적화 중 기울기 정확도 손실로 이어졌다.

(이를 방지하기 위해 대부분의 액셀러레이터는 “마스터 가중치” 및 옵티마이저 상태에 FP32를 사용하고 순방향 및 역방향 패스에 대해서만 BF16으로 다시 캐스팅한다.)

그래서 우리는 DeepSpeed로 다시 전환하고 GPU 과열 및 “버스에서 떨어짐”으로 인한 시간 손실을 최소화하기 위해 공격적인 체크포인팅을 추가했다. 이 전략은 성공적임이 입증되었으며 우리가 더 일반적으로 권장하는 것이다:

☝️규칙

사전 학습에서 강조했듯이, 학습 실행 중 모델 체크포인트를 자주 저장하고, 우발적인 덮어쓰기를 피하기 위해 이상적으로는 Hugging Face Hub에 푸시한다. 또한 학습 프레임워크를 장애에 강하고 자동 재시작이 가능하도록 만든다. 이 두 가지 전략 모두 시간을 절약해 줄 것이다. 특히 중간 학습과 같이 장기 실행 작업의 경우 더욱 그렇다.

약 일주일 동안 실행들을 열심히 돌봐주었고, 마침내 결과를 얻었다:

스크린샷 2025-12-02 오후 9.55.07.png

전반적으로, 우리는 NVIDIA의 사후 학습 데이터셋이 OpenThoughts보다 더 나은 성능을 제공하지만, 함께 쓰는 것이 전체적으로 가장 좋다는 것을 발견했다.

이제 이러한 체크포인트 중 하나를 가져와 동일한 기준 데이터 혼합을 적용했을 때의 효과를 살펴보자:

스크린샷 2025-12-05 오후 5.00.07.png

스크린샷 2025-12-02 오후 9.56.09.png

사전 학습된 모델 대신 중간 학습된 추론 모델을 사용하는 효과는 극적이다: 확장된 사고로 AIME25 및 LiveCodeBench v4에서 성능을 거의 세 배로 늘렸고, GPQA-D는 전체 10점 향상을 받았다. 다소 놀랍게도, 추론 핵심은 /no_think 추론 모드로 부분적으로 이전되어, 추론 벤치마크에서 약 4-6점 향상되었다. 이 결과는 추론 모델의 경우, 기본 모델이 사전 학습 중에 이미 많은 추론 데이터를 보지 않았다면 어느 정도의 중간 학습을 수행하는 것이 거의 항상 합리적이라는 명확한 증거를 제공했다.

📍언제 중간 학습을 하지 않는가

중간 학습은 모델이 새로운 핵심 기술을 배워야 할 때 빛난다. 기본 모델이 이미 기술을 가지고 있거나 스타일이나 대화 잡담과 같은 얕은 능력을 끌어내려고 한다면 덜 유용하다. 이러한 경우, 중간 학습을 건너뛰고 컴퓨팅을 선호도 최적화나 강화 학습과 같은 다른 방법에 할당하는 것을 권장한다.

SFT 데이터 혼합과 모델의 광범위한 능력에 확신이 생기면, 초점은 자연스럽게 기술 학습에서 기술 정제로 이동한다. 대부분의 경우, 가장 효과적인 방법은 선호도 최적화이다.

SFT에서 선호도 최적화로: 모델에게 ‘더 나음’이 무엇인지 가르치기

SFT를 더 많은 데이터로 계속 확장할 수 있지만, 어느 시점에서는 이득이 줄어들거나 모델이 자신의 버그 있는 코드를 수정하지 못하는 것과 같은 실패하는 모습을 관찰하게 될 것이다. 왜일까? SFT는 **모방 학습(imitation learning)**의 한 형태이므로, 모델은 학습된 데이터의 패턴을 재생산하는 것만 배우기 때문이다. 데이터에 이미 좋은 수정 사항이 포함되어 있지 않거나 증류를 통해 원하는 행동을 끌어내기 어렵다면, 모델은 무엇이 “더 나은” 것인지에 대한 명확한 신호를 얻지 못한다.

여기서 선호도 최적화(preference optimisation)가 등장한다. 데모를 단순히 복사하는 대신, 우리는 모델에게 “응답 A가 응답 B보다 낫다”와 같은 비교 피드백을 제공한다. 이러한 선호도는 품질에 대한 더 직접적인 학습 신호를 제공하고 모델 성능이 SFT만의 한계를 넘어 확장될 수 있게 해준다.

선호도 최적화의 또 다른 이점은 시작점이 이미 지침을 따를 수 있고 이전 학습 단계의 지식을 가지고 있는 꽤 좋은 모델이기 때문에 일반적으로 SFT보다 훨씬 적은 데이터를 필요로 한다는 것이다.

이러한 데이터셋이 어떻게 만들어지는지 살펴보자.

선호도 데이터셋 생성

역사적으로, 선호도 데이터셋은 인간 주석자에게 모델 응답 쌍을 제공하고 어떤 것이 더 나은지 (아마도 척도로) 평가하도록 요청하여 생성되었다. 이 접근 방식은 여전히 LLM 제공자가 인간 선호도 레이블을 수집하는 데 사용되지만, 매우 비싸고 확장이 잘 안 된다. 최근, LLM은 고품질 응답을, 종종 비용 효율적인 방식으로 생성할 수 있게 되었다. 이러한 발전은 LLM이 많은 애플리케이션에 대한 선호도를 생성하는 것을 실용적으로 만든다. 실제에서, 두 가지 일반적인 접근 방식이 있다:

강한 것 대 약한 것 (Strong vs. weak)

고정된 프롬프트 세트 x를 취한다 (종종 범위와 난이도를 위해 큐레이션됨).
약한 모델이나 기준 모델에서 하나의 응답을 생성하고, 고성능 모델에서 다른 하나를 생성한다.
더 강한 모델의 출력을 선택된 응답 y_c로, 더 약한 것을 거부된 응답 y_r로 레이블링한다.

이것은 “더 강한 것 대 더 약한 것” 비교 데이터셋 $({x,y_c,y_r})$ 을 생성하는데, 더 강한 모델의 출력이 확실히 더 낫다고 가정하기 때문에 구축하기 간단하다.

아래는 Intel의 인기 있는 예시로, gpt-3.5와 gpt-4의 응답이 포함된 SFT 데이터셋을 가져와 gpt-4 응답을 선택됨으로, gpt-3.5 응답을 거부됨으로 선택하여 선호도 데이터셋으로 변환했다:

스크린샷 2025-12-02 오후 10.25.04.png

채점을 통한 온-폴리시 (On-policy with grading)

학습시킬 동일한 모델을 사용하여 동일한 프롬프트에 대해 여러 후보 응답을 생성한다. 이것은 모델이 자연스럽게 생성할 출력의 분포를 반영하기 때문에 “온-폴리시(on-policy)” 데이터를 생성한다.
더 강한 모델을 레퍼런스로 의존하는 대신, 하나 이상의 품질 축 (예: 유용성 또는 사실적 정확성)을 따라 응답을 점수 매기는 검증자(verifier) 또는 보상 모델인 **외부 채점자(external grader)**를 도입한다.
그런 다음 채점자는 후보 응답 간에 선호도 레이블을 할당하여 더 미묘하고 유연한 선호도 데이터셋을 생성한다.

이 방법은 모델이 개선됨에 따라 선호도 데이터의 지속적인 부트스트래핑을 허용하지만, 그 품질은 평가자의 신뢰성과 교정(calibration)에 크게 의존한다.

그러한 데이터셋의 좋은 예는 SnorkelAI에서 나온 것으로, UltraFeedback이라는 인기 있는 선호도 데이터셋에서 프롬프트를 가져와 3개 세트로 나누고, 위 레시피를 반복적으로 적용하여 모델을 개선했다:

스크린샷 2025-12-04 오후 4.50.24.png

SmolLM3 개발 당시에는 추론 경로가 포함된 선호도 데이터가 존재하지 않았으므로, 우리는 “강한 것 대 약한 것” 접근 방식을 사용하여 자체적으로 일부를 생성하기로 결정했다. 우리는 Ai2의 Tulu 3 선호도 혼합의 프롬프트를 사용하여 /think 모드에서 Qwen3-0.6B 및 Qwen3-32B의 응답을 생성했다. 그 결과로 25만 개 이상의 LLM 생성 선호도로 구성된 대규모 데이터셋을 만들었으며, 선호도 최적화 알고리즘을 사용하여 여러 축에 걸쳐 SFT 체크포인트를 동시에 개선할 준비가 되었다.

어떤 알고리즘을 선택해야 하는가?

직접 선호도 최적화(Direct Preference Optimization, DPO) (Rafailov et al., 2024)는 오픈 소스에서 널리 채택된 최초의 선호도 최적화 알고리즘이었다.

DPO의 매력은 구현하기 간단하고, 실제에서 안정적이며, 적당한 양의 선호도 데이터로도 효과적이라는 것이다. 결과적으로, DPO는 RL과 같은 더 복잡한 기술에 도달하기 전에 SFT 모델을 개선하는 기본 방법이 되었다.

그러나 연구자들은 DPO를 개선할 수 있는 많은 방법이 있음을 빠르게 발견했으며, 오늘날 탐색할 수 있는 다양한 대안이 있다. 아래에 우리 가장 효과적이라고 생각한 몇 가지를 나열한다:

Kahneman-Tversky 최적화 (KTO) [Ethayarajh et al. (2024)]: 선호도 쌍에 의존하는 대신, KTO는 인간의 의사 결정에서 아이디어를 얻어 개별 응답이 “바람직한지 아닌지” 모델링한다. 짝을 이룬 선호도 데이터 (예: 최종 사용자가 수집한 👍 또는 👎와 같은 원시 응답)에 접근할 수 없는 경우 좋은 선택이다.
승산비 선호도 최적화 (ORPO) [Hong et al. (2024)]: 교차 엔트로피 손실에 승산비(odds ratio)를 추가하여 선호도 최적화를 SFT에 직접 통합한다. 결과적으로 참조 모델이나 SFT 단계가 필요 없으므로 이 방법은 계산적으로 더 효율적이다.
앵커 선호도 최적화 (APO) [D’Oosterlinck et al. (2024)]: 이것은 단순히 차이를 최적화하는 것이 아니라, 선택된 출력 대 거부된 출력에 대한 모델의 가능도가 얼마나 이동해야 하는지 명시적으로 정규화하는 더 제어 가능한 목적 함수이다. 두 가지 변형 (APO-zero 및 APO-down)이 있으며, 그 선택은 모델과 선호도 데이터 간의 관계, 즉 선택된 출력이 모델보다 더 나은지 나쁜지에 따라 달라진다.

다행히도, 이러한 선택 중 다수는 TRL의 DPOTrainer에서 한 줄 변경에 불과하므로, 초기 기준선을 위해 우리는 다음을 수행했다:

Ai2의 Tülu3 Preference Personas IF 데이터셋의 프롬프트와 답변을 사용하여 /no_think 추론 모드로 IFEval에서 지침 따르기 개선을 측정한다.
위의 프롬프트를 재사용하지만, 이제 Qwen3-32B 및 Qwen3-0.6B로 “강한 것 대 약한 것” 선호도 쌍을 생성한다. 이것은 우리에게 /think 추론 모드에 대한 선호도 데이터를 제공했다.
1 에포크 동안 학습하고 IFEval에 대한 도메인 내 개선과 함께 지침 따르기와 직접적인 상관관계가 있는 AIME25와 같은 다른 평가에 대한 도메인-밖 영향을 측정한다.

아래 그림과 같이, 두 추론 모드에 대한 도메인 내 개선은 상당했다: IFEval에서 APO-zero는 SFT 체크포인트보다 15-20퍼센트 포인트 향상되었다!

스크린샷 2025-12-04 오후 4.55.57.png

APO-zero는 또한 최고의 전반적인 도메인-밖 성능을 가졌으므로, 우리는 나머지 제거 실험에 그것을 사용하기로 결정했다.

📍선호도 최적화는 추론에 효과적이다

위의 결과에서 보듯이, 선호도 최적화는 모델을 더 도움이 되거나 정렬되게 만들 뿐만 아니라, 더 잘 추론하도록 가르친다. 추론 모델을 개선할 빠른 방법이 필요하다면, 강한 것 대 약한 것 선호도를 생성하고 다른 손실 함수를 제거 실험해 보라: 바닐라 DPO보다 상당한 개선을 확인할 수 있을 것이다!

선호도 최적화에 가장 중요한 하이퍼파라미터는 무엇인가?

선호도 최적화의 경우, 일반적으로 학습 역학에 영향을 미치는 세 가지 하이퍼파라미터만 있다:

학습률, 일반적으로 SFT에 사용된 것보다 10-100배 더 작다.
매개변수 β, 일반적으로 선호도 쌍 사이의 마진 크기를 제어한다.
배치 크기

SmolLM3에 대해 이것들이 어떻게 작용했는지 살펴보자. smoltalk2 전체에 대해 학습된 SFT 체크포인트부터 시작하자.

최고의 성능을 위해 작은 학습률 사용

우리가 실행한 첫 번째 제거 실험은 학습률이 모델 성능에 미치는 영향을 확인하는 것이었다. 우리는 SFT 학습률(2e-5)보다 ~200배 더 작은(1e-7) 것부터 ~2배 더 작은(1e-5) 것 사이의 학습률의 영향을 확인하기 위해 실험을 진행했다. Zephyr 7B와 같은 이전 프로젝트는 선호도 최적화 방법에 대한 최고의 학습률이 SFT에 사용된 것보다 약 10배 더 작다아야 한다는 것을 가르쳐 주었고, SmolLM3에 대해 실행한 제거 실험은 이 경험 법칙을 재확인했다.

아래 그림과 같이, ~10배 더 작은 학습률은 두 추론 모드에서 SFT 모델의 성능을 향상시키지만, 그 10배 제한을 넘어서는 모든 학습률은 확장된 사고 모드에 대해 더 나쁜 성능을 초래했다:

스크린샷 2025-12-04 오후 4.58.45.png

스크린샷 2025-12-05 오후 5.04.03.png

스크린샷 2025-12-05 오후 5.04.12.png

/no_think 추론 모드에 대한 경향은 더 안정적이며, 최고의 학습률은 5e-6이다. 이것은 주로 단일 벤치마크 (LiveCodeBench v4)에 의해 주도되므로, 우리는 SmolLM3 실행에 1e-6을 선택했다.

여러분의 학습 실행에 대한 우리의 권장 사항은 SFT 학습률보다 5배에서 20배 더 작은 범위에서 학습률 스캔을 실행하는 것이다. 그 범위 내에서 최적의 성능을 찾을 가능성이 매우 높다!

β 튜닝

β 매개변수에 대해 실행한 실험은 0.01에서 0.99까지, 레퍼런스 모델에 대한 각각 다른 정도의 정렬을 장려하는 값들을 탐색했다. 상기시키자면, 베타 값이 낮을수록 레퍼런스 모델에 가깝게 머무르는 것을 장려하고 높은 값은 모델이 선호도 데이터와 더 밀접하게 일치하도록 허용한다. β=0.1 에 대한 모델 성능은 두 추론 모드 모두에서 가장 높으며 SFT 체크포인트의 지표와 비교하여 향상된다. 낮은 베타 값을 사용하면 모델 성능을 해치고 SFT 체크포인트보다 더 나쁜 모델을 초래하는 반면, 확장된 사고 없이는 여러 β 값에 걸쳐 성능이 안정적으로 유지된다.

이러한 결과는 선호도 최적화에 0.1보다 큰 값이 바람직하며, 모델을 선호도 데이터와 정렬하는 것이 레퍼런스 모델에 가깝게 유지하는 것보다 더 유리하다는 것을 시사한다. 그러나 우리는 0.01과 0.5 범위의 β 값을 탐색할 것을 제안한다. 더 높은 값은 플롯에 표시된 평가에서 포착하지 못할 수도 있는 SFT 체크포인트의 능력을 지울 수 있다.

스크린샷 2025-12-04 오후 5.01.09.png

선호도 데이터 확장

우리는 또한 데이터셋 크기가 결과에 어떻게 영향을 미치는지 결정하기 위해 실험을 실행하여 2k에서 340k 선호도 쌍의 값을 테스트했다. 이 범위 전반에 걸쳐 성능은 안정적으로 유지되었다. 확장된 사고 모드에서의 성능 저하는 100k 선호도 쌍을 넘어서는 데이터셋에서 발생하지만, 그 저하는 우리가 다른 학습률 값에서 본 것만큼 두드러지지는 않았다. SmolLM3 학습 실행에 사용한 데이터셋은 169k 선호도 쌍이었지만, 결과는 더 작은 데이터셋도 SFT 체크포인트보다 개선을 보여줌을 보여준다. 미래 프로젝트를 위해, 우리는 반복 단계 동안 더 작은 데이터셋으로 실험할 수 있다는 것을 알게 되었는데, 여러 아이디어를 시도하고 가장 유망한 구성을 빠르게 식별하는 것이 중요하기 때문이다.

스크린샷 2025-12-04 오후 5.03.06.png

모든 것을 하나로 모으기

이 모든 스레드를 하나로 모아 최종 SmolLM3-3B 모델을 만들었다: 동급 크기 중 최고이며 Qwen의 자체 하이브리드 추론 모델과 함께 파레토 프론트에 위치한다.

추론 없는 Instruction 모델

스크린샷 2025-12-04 오후 5.03.52.png

몇 주간의 작업치고는 꽤 괜찮다!

참여 규칙

미래 프로젝트에 유용할 수 있는 선호도 최적화에 대한 우리의 발견을 요약하겠다:

자체 선호도 데이터를 만드는 것을 두려워하지 마라! 추론이 “너무 저렴해서 측정할 수 없을 정도”가 됨에 따라, 요즘에는 다양한 추론 제공자로부터 LLM 선호도를 생성하는 것이 간단하고 비용 효율적이다.
DPO를 초기 기준선으로 선택하고 거기서부터 반복하라. 선호도 데이터의 유형에 따라 ORPO, KTO, 또는 APO와 같은 다른 알고리즘이 DPO보다 상당한 이득을 제공할 수 있다는 것을 발견했다.
SFT에 사용된 것보다 약 10배 더 작은 학습률을 사용하라.
β 에 대해 스캔한다, 일반적으로 0.01에서 0.5 범위이다.
대부분의 선호도 알고리즘은 1 에포크 후에 과적합되므로, 데이터를 분할하고 최고의 성능을 위해 반복적으로 학습한다.

선호도 최적화는 종종 단순성과 성능 사이의 최적점이지만, 여전히 지도학습으로부터 주요 한계를 물려받는다: 오직 수집할 수 있는 오프라인 선호도 데이터만큼만 좋다는 것이다. 어느 시점에서, 정적 데이터셋은 신호가 고갈되고 모델이 프롬프트 및 환경과 상호 작용함에 따라 온라인에서 새로운 학습 피드백을 생성할 수 있는 방법이 필요하다. 그곳이 선호도 최적화가 온-폴리시 및 RL 기반 방법의 더 넓은 가족들과 만나는 지점이다.

온-폴리시 및 지도 레이블을 넘어서

모델이 수학 문제를 일관되게 해결하거나, 실행 가능한 코드를 생성하거나, 여러 단계에 걸쳐 계획하기를 원한다면, 단순히 “A가 B보다 낫다”는 것보다는 **보상 신호(reward signal)**가 필요한 경우가 많다.

여기서 RL이 의미있어지기 시작한다. 선호도로 모델을 감독하는 대신, 환경 (수학 검증자, 코드 실행기, 또는 실제 사용자 피드백일 수 있음)과 상호 작용하게 하고 결과로부터 직접 학습하게 하는 것이다. RL은 다음과 같은 경우에 빛난다:

정확도를 자동으로 확인할 수 있을 때, 예: 단위 테스트, 수학적 증명, API 호출, 또는 고품질 검증자나 보상 모델에 접근할 수 있을 때.
작업이 다단계 추론 또는 계획을 필요로 할 때, 여기서 로컬 선호도는 장기적인 성공을 포착하지 못할 수 있다.
단위 테스트 통과 또는 목표 최대화와 같이 선호도 레이블를 넘어선 목표를 위해 최적화하고자 할 때.

LLM과 관련하여, RL에는 두 가지 주요 방향성이 있다:

인간 피드백 기반 강화 학습 (RLHF): 이것은 OpenAI의 InstructGPT 논문 (Ouyang et al., 2022)에 의해 대중화되었으며 gpt-3.5 및 많은 현대 LLM의 기초가 된 접근 방식이다. 여기서, 인간 주석자는 모델 출력 (예: “A가 B보다 낫다”)을 비교하고 보상 모델이 그러한 선호도를 예측하도록 학습된다. 그런 다음 정책은 학습된 보상을 최대화하기 위해 RL로 파인 튜닝된다.

(보상 모델은 인간 선호도를 근사할 뿐이므로, 때때로 보상 해킹(reward hacking)을 장려할 수 있다. 정책이 “더 더 더 더”와 같은 분포 외 시퀀스를 방출하고 가짜 높은 보상을 받아 RL 루프를 통해 모델에 구워지는 것이다.)
검증 가능한 보상 기반 강화 학습 (RLVR): 이것은 DeepSeek-R1에 의해 대중화된 접근 방식이며 모델의 출력이 명확하게 정의된 정확성 기준을 충족하는지 확인하는 검증자를 사용하는 것을 포함한다 (예: 코드가 컴파일되고 모든 테스트를 통과하는가, 또는 수학적 답변이 올바른가?). 그런 다음 정책은 더 검증 가능하게 올바른 출력을 생성하기 위해 RL로 파인 튜닝된다.

RLHF와 RLVR 모두 모델이 무엇을 위해 최적화되고 있는지를 정의하지만, 그 최적화가 어떻게 수행되어야 하는지는 말해주지 않는다. 실제에서, RL 기반 학습의 효율성과 안정성은 학습 알고리즘이 **온-폴리시(on-policy)**인지 **오프-폴리시(off-policy)**인지에 크게 의존한다.

GRPO와 같은 방법은 일반적으로 온-폴리시 최적화 알고리즘 범주에 속하며, 답변을 생성하는 모델(정책)이 최적화되는 모델과 동일하다. GRPO가 온-폴리시 알고리즘인 것은 대체로 사실이지만, 몇 가지 주의 사항이 있다. 첫째, 생성 단계를 최적화하기 위해 여러 배치의 생성이 샘플링된 다음 모델에 대해 k 번의 업데이트가 이루어지기 때문에, 첫 번째 배치는 온-폴리시이고 다음 몇 배치는 약간 오프-폴리시이다.

생성에 사용된 모델과 최적화되는 현재 모델 사이의 정책 지연(policy-lag)을 설명하기 위해, 중요도 샘플링(importance sampling)과 클리핑이 토큰 확률을 다시 가중치 재부여 및 업데이트 크기를 제한하는 데 사용된다.

(우리는 여기서 오프-폴리시 RL을 언급하지만, Q-learning과 같이 궤적(trajectory)을 생성하는 데 사용되는 정책이 최적화되는 정책과 완전히 다를 수 있는 몇 가지 진정한 오프-폴리시 RL 알고리즘이 있다. GRPO가 LLM에 적용될 때, 생성에 사용되는 정책은 최적화에 사용되는 정책보다 뒤처질 수 있지만, 일반적으로 둘 사이에 16단계 미만의 차이가 있다.)

LLM의 자기 회귀 생성이 느리기 때문에, verl 및 PipelineRL과 같은 많은 프레임워크는 학습 처리량을 최대화하기 위해 답변(completion)의 비동기 생성 및 모델 가중치의 “비행 중(in-flight)” 업데이트를 추가했다. 이러한 접근 방식은 더 복잡하고 신중한 구현을 요구하지만, 동기식 학습 방법보다 4-5배 더 높은 학습 속도를 달성할 수 있다. 나중에 보게 되겠지만, 학습 효율성의 이러한 개선은 롱테일 토큰 분포를 가진 추론 모델에 대해 특히 두드러진다.

SmolLM3의 경우, 우리는 주로 시간 제약과 오프라인 선호도 최적화만으로 이미 동급 최고인 모델을 가지고 있었기 때문에 RL을 완전히 건너뛰었다. 그러나 출시 이후 우리는 이 주제를 다시 방문했으며 하이브리드 추론 모델에 RLVR을 적용하면서 얻은 교훈 중 일부를 공유하며 사후 학습 챕터를 마칠 것이다.

하이브리드 추론 모델에 RLVR 적용

하이브리드 추론 모델은 추론 모드에 따라 생성 길이가 상당히 다르기 때문에 RLVR에 추가적인 복잡성을 제기한다. 예를 들어, 아래 그림에서 우리는 SmolLM3의 최종 APO 체크포인트에 대해 AIME25에서의 토큰 길이 분포를 시각화했다:

스크린샷 2025-12-04 오후 5.12.47.png

보시다시피, /no_think 모드는 약 2k 토큰의 중앙값 길이를 가진 솔루션을 생성하는 반면, /think 모드는 16k 토큰과 두꺼운 꼬리(fat-tailed) 분포로 훨씬 더 크다. 이상적으로, 우리는 RLVR로 두 모드의 전반적인 성능을 향상시키면서 그들의 각 길이 분포를 너무 급격하게 변경하지 않기를 원했다.

그렇게 할 방법을 알아내기 위해, 우리는 먼저 /no_think 모드를 최적화하는 데 집중했고 검증된 답변이 있는 25만 개 이상의 수학 문제 데이터셋인 Big-Math에서 프롬프트의 부분 집합을 가져왔다.

놀랍게도, 순진하게 GRPO를 적용하면 일종의 보상 해킹으로 이어진다: 긴 CoT를 만들도록 프롬프트되지 않았음에도 불구하고, 모델은 보상을 늘리기 위해 기본 추론 능력을 악용하는 법을 배운다. 아래 그림과 같이, 보상만 올라가는 것이 아니라 완료 길이도 올라간다:

스크린샷 2025-12-04 오후 5.14.38.png

SmolLM3에 순진하게 RLVR을 적용하면 높은 보상과 향상된 다운스트림 성능을 달성하지만, 폭발적인 completion 길이라는 비용이 발생하게 된다.

달리 말하면, GRPO를 사용한 RLVR은 우리 추론 모델의 /no_think 모드를 /think 모드와 매우 유사해 보이는 것으로 바꿔버렸다!

모델의 답변을 검토할 때, 우리는 모델이 이제 긴 CoT를 생성하고 심지어 추론 모델과 관련된 “잠깐, …”과 같은 인지적 행동 (Gandhi et al., 2025) 중 일부를 포함한다는 것을 알 수 있다. 이에 대한 예시는 아래와 같다:

However, since the jogger and the train are moving in the same direction, the relative speed between them is the difference of their speeds:
\\( v_{\\text{rel}} = v_t - v_j = 12.7778 - 2.7778 = 10 \\) m/s

 **Wait,**  let me double-check the calculation:

 **Wait,**  46 km/hr to m/s:
46 * 1000 m / 3600 s = (46 * 10)/36 = 460/36 ≈ 12.7778 m/s (correct)
10 km/hr is:
10 * 1000 / 3600 = 10000 / 3600 ≈ 2.7778 m/s (correct)
Difference: 12.7778 - 2.7778 = 10 m/s (exact, since 46-10=36 km/hr → 36*(1000/3600)=10 m/s exactly)

The jogger is 340 meters ahead of the train's engine. When the train passes the jogger, the distance the train needs to cover relative to the jogger is 340 meters plus the length of the train? Wait, actually, let me think about the problem again.

 **Wait,**  actually, when the problem says the train takes 46 seconds to pass the jogger, that usually means the time from the front of the train to the end passing the jogger. The length of the train would then be equal to the relative speed multiplied by the time.

But first, the initial position: the jogger is 340 meters ahead of the engine. So the engine is 340 meters ahead of the jogger. Wait no, the wording says "340 m ahead of the engine", so the jogger is ahead by 340 meters. So when the jogger is running alongside, the engine of the train is 340 m away behind the jogger? Wait, maybe I need to clarify.

 **Wait**  the problem says: "A jogger running at 10 km/hr alongside a railway track is 340 m ahead of the engine of a train running at 46 km/hr in the same direction. The train takes 46 seconds to pass the jogger. How long is the train in meters?"

Hmm, so the jogger is 340 m ahead of the engine along the track. Since they're moving in the same direction, the train is behind the jogger by 340 meters. To pass the jogger, the train has to cover that 340 meters plus the length of the train itself?

과도한 길이 페널티로 보상 해킹 완화

이 문제는 특정 길이 이상의 완료에 페널티를 주는 **과도한 길이 페널티(overlong completion penalty)**를 포함함으로써 완화될 수 있다. 페널티는 두 가지 인수, 최대 완료 길이 $L_{max}$ 와 소프트 처벌 캐시 $L_{cache}$ 에 의해 매개변수화된다. 이 페널티는 DAPO 논문 (Yu et al., 2025)에서 제안된 개선 사항 중 하나였으며 다음과 같이 보상 함수를 적용하는 것과 같다:

R_{\text{length}}(y) = \begin{cases} 0, & |y| \leq L_{\max} - L_{\text{cache}} \\ \frac{L_{\max} - L_{\text{cache}} - |y|}{L_{\text{cache}}}, & L_{\max} - L_{\text{cache}} < |y| \leq L_{\max} \\ -1, & L_{\max} < |y| \end{cases}

이 페널티를 사용하여, 우리는 모델의 출력 분포를 직접 제어하고 응답 길이 증가와 성능 사이의 트레이드오프를 측정할 수 있다. 아래 그림에 예시가 나와 있는데, 여기서 우리는 과도한 길이 페널티를 1.5k에서 4k까지 512 토큰 단위로 변경한다:

스크린샷 2025-12-04 오후 5.28.16.png

스크린샷 2025-12-04 오후 5.28.22.png

과도한 길이 페널티를 적용하면 각 롤아웃의 길이를 제한하면서 평균 보상도 줄어든다.

응답 길이와 성능 사이의 트레이드오프는 AIME25에서의 개선을 조사할 때 더 명확했다:

스크린샷 2025-12-04 오후 5.28.56.png

AIME25에서의 RLVR을 사용한 SmolLM3의 다운스트림 성능.

이제 우리는 과도한 길이 페널티가 다운스트림 성능에 어떻게 영향을 미치는지 명확하게 볼 수 있으며, 2-4k 범위의 페널티가 토큰 분포를 억제하면서 상당한 개선을 만든다는 것을 보았다. 아래 그림과 같이, 단계 400에서 체크포인트를 가져오면, 다양한 페널티 범위에 걸쳐 초기 정책과 최종 모델 간의 출력 토큰 분포를 비교할 수 있다:

스크린샷 2025-12-04 오후 5.31.05.png

스크린샷 2025-12-04 오후 5.30.51.png

모든 것을 하나로 모아

우리는 2.5-3k 범위의 길이 페널티를 적용하는 것이 성능과 응답 길이 사이의 최고의 트레이드오프를 제공한다는 것을 발견했으며, 아래 그림은 GRPO가 APO와 같은 오프라인 방법에 비해 AIME 2025에서 성능을 거의 두 배로 늘린다는 것을 보여준다:

스크린샷 2025-12-04 오후 5.31.27.png

이제 /no_think 추론 모드에서 성능을 향상시키는 방법을 알았으므로, RL 학습 파이프라인의 다음 단계는 두 추론 모드에서 모델을 한 번에 공동 학습시키는 것일 것이다. 그러나 우리는 이것이 꽤 해결하기 어려운 문제라는 것을 발견했는데, 각 모드가 고유한 길이 페널티를 요구하고, 그렇기 때문에 그 상호 작용이 학습을 불안정하게 만들었기 때문이다. 이것은 하이브리드 추론 모델에 RL을 적용하려고 할 때의 주요 도전 과제이며, 우리는 이것이 어렵기 때문에 Qwen과 같은 모델 개발자들이 Instruction 및 추론 변형 모델을 별도로 출시하는 새로운 추세를 따르게 된 것에 반영된 것을 알 수 있었다.

우리의 실험은 RLVR이 추론 행동을 효과적으로 조종할 수 있음을 보여주지만, 이것은 신중한 보상 형성 및 안정성 메커니즘이 있어야만 가능하다. 이러한 복잡성을 감안할 때, 강화 학습이 유일한 실행 가능한 경로인지 물어볼 가치가 있다. 사실, 최근 문헌에서 몇 가지 더 가벼운 온-폴리시 최적화 전략이 제안되었지만, 오픈 소스 커뮤니티에서는 놀랍게도 이러한 것들이 덜 탐색되었다. 그것들 중 일부를 살펴보며 이 챕터를 마치겠다.

RL만이 유일한 게임인가?

온-폴리시 학습에 대한 다른 접근 방식은 선호도 최적화와 증류를 모델이 진화함에 따라 학습 신호를 새로 고치는 반복 루프로 확장하는 것이다:

온라인 DPO: 고정된 선호도 데이터셋에 대해 한 번 학습하는 대신, 모델은 지속적으로 새로운 응답을 샘플링하고, 새로운 선호도 레이블 (보상 모델이나 LLM 채점자로부터)을 수집하고, 스스로를 업데이트한다. 이것은 최적화를 온-폴리시로 유지하고 학습 데이터와 모델의 현재 동작 간의 드리프트를 줄인다 (Guo et al., 2024).
온-폴리시 증류: 선호도 대신, 신호를 더 강력한 교사 모델로부터 얻는다. 학생은 모든 학습 단계에서 응답을 샘플링하고 이러한 샘플에 대한 학생과 교사 로짓 간의 KL 발산이 학습 신호를 제공한다. 이것은 학생이 명시적인 선호도 레이블이나 검증자 없이 지속적으로 교사의 능력을 흡수할 수 있게 한다 (Agarwal et al., 2024).

이러한 방법들은 정적인 선호도 최적화와 전체 RL 사이의 경계를 흐리게 한다: 이러한 방법을 사용하면, 강화 학습 루프를 설계하고 안정화하는 전체 복잡성 없이도 모델의 현재 분포에 적응하는 이점을 여전히 얻을 수 있다.

어떤 방법을 선택해야 하는가?

어떤 온-폴리시 방법이 “최고”인지에 대한 수많은 연구 논문이 있지만, 실제 상황에서의 결정은 아래 표에 표시된 몇 가지 요인에 따라 달라진다:

알고리즘	언제 사용할까	트레이드오프	최적 모델 크기
온라인 DPO	선호도 레이블을 저렴하게 얻을 수 있을 때. 진화하는 분포와 행동을 정렬하는 데 최적.	반복적으로 확장하기 쉽고 RL보다 안정적이지만, 레이블 품질 및 범위에 의존함. 지원되는 학습 프레임워크가 적음.	선호도가 모방을 넘어선 개선을 포착할 수 있는 모든 크기.
온-폴리시 증류	더 강력한 교사 모델에 접근할 수 있고 능력을 효율적으로 전이하고 싶을 때.	구현이 간단하고 실행 비용이 저렴하지만, 교사 모델이 가진 편향을 상속하게 되며 성능의 한계가 교사에 의해 제한됨. TRL 및 NemoRL에서만 지원됨.	중소형 모델 (<30B)에 가장 효과적.
강화 학습	검증 가능한 보상이나 다단계 추론/계획이 필요한 작업이 있을 때 최적. 보상 모델과 함께 사용할 수 있지만, 보상 모델의 약점을 이용하는 보상 해킹과 같은 도전 과제가 있음.	유연하고 강력하지만, 비용이 많이 들고 안정화하기 어려움; 신중한 보상 형성이 필요함. 대부분의 사후 학습 프레임워크에서 지원됨.	중대형 모델 (20B+), 추가 용량이 구조화된 보상 신호를 활용할 수 있게 해줌.

오픈 소스 생태계에서 GRPO 및 REINFORCE와 같은 강화 학습 방법이 가장 널리 사용되는 경향이 있지만, Qwen3 기술 보고서 (A. Yang, Li, et al., 2025)는 320억 매개변수 미만의 모델을 학습시키는 데 온-폴리시 증류를 사용했다는 것을 강조했다:

스크린샷 2025-12-04 오후 5.37.56.png

소형 모델에 대한 온-폴리시 증류의 한 가지 흥미로운 속성은 일반적으로 RL 기반 방법보다 적은 컴퓨팅 비용으로 더 나은 성능을 낸다는 것이다. 이는 프롬프트당 여러 롤아웃을 생성하는 대신 하나만 샘플링한 다음 단일 순방향-역방향 패스에서 교사에 의해 채점되기 때문이다. Qwen3 기술 보고서에서 볼 수 있듯이, GRPO 대비 이득은 상당할 수 있다:

방법	AIME’24	AIME’25	MATH500	LiveCodeBench v5	MMLU -Redux	GPQA -Diamond	GPU 시간
오프-폴리시 증류	55.0	42.8	92.4	42.0	86.4	55.6	-
+ 강화 학습	67.6	55.5	94.8	52.9	86.9	61.3	17,920
+ 온-폴리시 증류	74.4	65.5	97.0	60.3	88.3	63.3	1,800

더 최근에, Thinking Machines는 온-폴리시 증류가 사후 학습된 모델이 새로운 도메인에서 추가로 학습될 때 이전 성능이 저하되는 **치명적인 망각(catastrophic forgetting)**을 완화하는 데에도 효과적임을 보여주었다. 아래 표에서, 그들은 Qwen3-8b (IFEval)의 채팅 성능이 내부 데이터로 파인 튜닝될 때 떨어지지만, 저렴한 증류로 행동이 복원될 수 있음을 보여준다:

우리는 더 작고 작업별 모델로 증류될 수 있는 다양하고 유능한 오픈 가중치 LLM을 많이 가지고 있기 때문에, 온-폴리시 증류에 대해 상당히 흥분하고 있다. 그러나 모든 온-폴리시 증류 방법의 한 가지 약점은 교사와 학생이 동일한 토크나이저를 공유해야 한다는 것이다. 이를 해결하기 위해, 우리는 모든 교사가 모든 학생에게 증류될 수 있도록 하는 GOLD (General On-Policy Logit Distillation)라는 새로운 방법을 개발했다. 이 주제에 관심이 있다면 우리의 기술 기사를 확인하는 것을 추천한다.

마찬가지로, FAIR의 연구자들은 DPO에 대해 완전히 오프-폴리시인 것과 온-폴리시인 것의 효과를 비교했으며 훨씬 적은 컴퓨팅을 사용하여 GRPO의 성능과 일치하는 것이 가능하다는 것을 보여주었다 (Lanchantin et al., 2025):

스크린샷 2025-12-04 오후 5.40.13.png

그들의 논문에서 볼 수 있듯이, 온라인 DPO는 수학 작업에 잘 작동하며 세미-온-폴리시 변형조차도 많은 단계를 가진 오프-폴리시일 뿐임에도 불구하고 경쟁할 만한 성능을 달성한다:

학습 방법	Math500	NuminaMath	AMC23
시드 (Llama-3.1-8B-Instruct)	47.4	33.9	23.7
오프라인 DPO (s = inf)	53.7	36.4	28.8
세미-온라인 DPO (s = 100)	58.9	39.3	35.1
세미-온라인 DPO (s = 10)	57.2	39.4	31.4
온라인 DPO (s = 1)	58.7	39.6	32.9
GRPO	58.1	38.8	33.6

전반적으로, 우리는 RL을 효과적으로 확장하는 것 (Khatri et al., 2025)과 계산 효율성을 위한 다른 방법을 탐색하는 것 모두에 대해 여전히 할 일이 많다고 느낀다. 참으로 흥미진진한 시간이다!

사후 학습 마무리

여기까지 왔다면 축하한다: 이제 사후 학습의 성공에 필요한 모든 핵심 재료를 갖추었다. 이제 SOTA 결과를 얻기 위해 많은 실험을 실행하고 다양한 알고리즘을 테스트할 준비가 되었다.

그러나 아마 깨달았겠지만, 훌륭한 모델을 학습시키는 방법을 아는 것은 이야기의 절반일 뿐이다. 실제로 그러한 모델에 생명을 불어넣으려면 올바른 인프라가 필요하다. LLM 학습의 숨은 영웅으로 이 작품을 마무리하고자 한다.

Infrastructure - the unsung hero

이제 여러분은 모델 생성 및 학습에 대해 우리가 알고 있는 모든 것을 알았으므로, 프로젝트(그리고 은행 계좌)를 성패로 이끌 수 있는 중요하지만 저평가된 구성 요소인 인프라를 다뤄볼 차례이다. 프레임워크, 아키텍처, 데이터 큐레이션 중 어디에 집중하든 인프라 기초를 이해하면 학습 병목 현상을 식별하고, 병렬화 전략을 최적화하고, 처리량 문제를 디버깅하는 데 도움이 된다. (최소한 인프라 팀과의 의사소통은 개선된다 😉).

모델을 학습시키는 대부분의 사람들은 아키텍처와 데이터에 깊은 관심을 가지지만, 인프라 세부 사항을 이해하는 사람은 거의 없다. 인프라 전문 지식은 일반적으로 프레임워크 개발자와 클러스터 엔지니어에게 있으며, 나머지는 해결된 문제로 취급한다: GPU를 빌리고, PyTorch를 설치하면 준비가 된 것이다. 우리는 거의 한 달 동안 384개의 H100에서 SmolLM3를 학습시켜 총 11조 토큰을 처리했다… 그리고 이것은 순조로운 여정이 아니었다! 그 기간 동안 우리는 노드 고장, 스토리지 문제, 실행 재시작을 처리했다 (학습 마라톤 섹션 참조). 이러한 문제에 대비하고 학습을 원활하고 유지 보수가 적게 들도록 유지하기 위해 좋은 비상 계획과 전략을 가져야 한다.

이 챕터는 그 지식 격차를 메우는 것을 목표로 한다. 학습에 중요한 질문에 초점을 맞춘 하드웨어 계층에 대한 실용적인 가이드로 생각하라. (참고: 각 하위 섹션은 TL;DR- 요약으로 시작하므로 깊이 수준을 선택할 수 있도록 했다.)

처음 두 섹션은 하드웨어 작동 방식의 기초를 다룬다: GPU는 실제로 무엇으로 구성되어 있는가? 메모리 계층 구조는 어떻게 작동하는가? CPU와 GPU는 어떻게 통신하는가? 우리는 또한 GPU를 확보할 때 고려해야 할 사항과 긴 학습 실행에 전념하기 전에 테스트하는 방법을 살펴볼 것이다. 가장 중요한 것은 각 단계에서 이러한 시스템을 직접 측정하고 진단하는 방법을 보여줄 것이다. 다음 섹션은 더 응용된 내용이며, 인프라를 장애에 탄력적으로 만들고 학습 처리량을 최대한 최적화하는 방법을 볼 것이다.

이 챕터의 핵심은 병목 현상을 찾아 수정하는 것이다!

이것을 특정 설계 결정이 중요한 이유에 대한 직관을 구축하는 공부 과정으로 생각해라. 모델의 활성화가 각각 다른 대역폭과 지연 시간 특성을 가진 여러 수준의 캐시를 통과해야 한다는 것을 이해하면, 데이터 이동을 최소화하기 위해 학습을 구조화하는 방법에 대해 자연스럽게 생각하기 시작할 수 있어질 것이다. 노드 간 통신이 노드 내 통신보다 몇 배나 느리다는 것을 알게 되면, 병렬화 전략이 왜 그렇게 중요한지 이해하게 될 것이다.

GPU를 열어보고 무엇이 들어 있는지 보는 것으로 시작하자.

GPU 내부: 내부 아키텍처

GPU는 근본적으로 지연 시간보다 처리량에 최적화된 대규모 병렬 프로세서이다. 몇 가지 복잡한 명령 스트림을 빠르게 실행하는 데 탁월한 CPU와 달리, GPU는 수천 개의 간단한 작업을 동시에 실행하여 성능을 달성한다.

GPU 성능을 이해하는 열쇠는 단순히 원시 컴퓨팅 파워가 아니라 계산과 데이터 이동 간의 상호 작용에 있음을 인식하는 데 있다. GPU는 이론적인 테라플롭스의 컴퓨팅을 가질 수 있지만 데이터가 컴퓨팅 유닛에 충분히 빨리 도달할 수 없다면 그 잠재력은 사용되지 않는다. 이것이 우리가 메모리 계층 구조 (데이터가 이동하는 방식)와 컴퓨팅 파이프라인 (작업이 완료되는 방식)을 모두 이해해야 하는 이유이다.

따라서 가장 높은 수준에서 GPU는 두 가지 필수 작업을 수행한다:

데이터 이동 및 저장 (메모리 시스템)
데이터로 유용한 작업 수행 (컴퓨팅 파이프라인)

컴퓨팅 유닛 및 FLOPs

요약: GPU는 성능을 FLOPs (초당 부동 소수점 연산)로 측정한다.

H100과 같은 최신 GPU는 더 낮은 정밀도에서 극적으로 더 높은 처리량을 제공한다: 990 TFLOPs (BF16) 대 67 TFLOPs (FP32). 그러나 실제 성능은 메모리 병목 현상으로 인해 이론적 피크의 70-77%이다. 최첨단 학습은 20-41%의 종단 간(end-to-end) 효율성, 즉 모델 플롭스 활용률(MFU)을 달성한다. 학습 실행을 계획할 때 마케팅 사양이 아닌 현실적인 수치를 사용해야 한다.

GPU 컴퓨팅 성능은 FLOPs (초당 부동 소수점 연산)로 측정된다. FLOP은 단일 산술 연산, 일반적으로 a+b 와 같은 부동 소수점 덧셈이며, 최신 GPU는 초당 수조 개의 이러한 연산(TFLOPs)을 실행할 수 있다.

GPU 컴퓨팅의 기본 빌딩 블록은 **스트리밍 멀티프로세서(SM)**로, 명령을 병렬로 실행하는 독립적인 처리 장치이다. 각 SM에는 두 가지 유형의 코어가 포함되어 있다: 표준 부동 소수점 연산을 위한 CUDA 코어와 딥러닝의 주력 연산(트랜스포머 성능에 중요함)인 행렬 곱셈에 최적화된 Tensor 코어이다.

현대 GPU는 칩 전체에 수백 개의 이러한 SM을 정렬한다! 예를 들어, H100 SXM5 버전(우리 클러스터에서 사용하는 GPU)에는 132개의 SM이 포함되어 있다. 각 SM은 독립적으로 작동하며 **워프(warp)**라고 불리는 32개의 스레드 그룹을 동시에 실행한다. 이를 돕기 위해 SM은 또 다른 구성 요소인 워프 스케줄러에 의존한다: 다른 워프에 명령을 균형 있게 할당함으로써 하나가 멈출 때 워프 간 전환을 통해 SM이 “지연 시간을 숨길” 수 있도록 한다. 이 SIMT (단일 명령, 다중 스레드) 실행 모델은 워프의 모든 스레드가 다른 데이터에 대해 동시에 동일한 명령을 실행함을 의미한다.

(워프는 Lindholm et al., 2008에 따르면 “최초의 병렬 스레드 기술”인 직조를 참조하여 명명되었다. 다른 GPU 프로그래밍 모델에서 워프에 해당하는 것에는 WebGPU의 하위 그룹(subgroups), DirectX의 웨이브(waves), Metal의 simdgroups가 포함된다.)

스크린샷 2025-12-04 오후 5.58.32.png

수백 개의 SM이 각각 여러 워프를 동시에 실행하므로 단일 GPU는 수만 개의 스레드를 동시에 실행할 수 있다. 이 대규모 병렬 처리가 GPU가 딥러닝 워크로드를 지배하는 행렬 연산에서 탁월할 수 있게 해준다!

FLOPs를 논의할 때 정밀도(Precision)는 상당히 중요하다. Tensor 코어는 다양한 정밀도(FP64, FP32, FP16/BF16, FP8, FP4 - 부동 소수점 숫자에 대한 상기는 여기 참조)에서 작동할 수 있다. 따라서 달성 가능한 처리량은 데이터 유형에 따라 종종 자릿수 차이로 극적으로 달라진다. 더 낮은 정밀도 형식은 더 적은 데이터 이동을 요구하고 동일한 실리콘 영역에 더 많은 연산을 패킹할 수 있기 때문에 더 높은 처리량을 가능하게 하지만, 이전에는 학습 불안정성 때문에 피했었다. 그러나 오늘날에는 다양한 새로운 기술 덕분에 학습과 추론 모두 점점 더 낮은 정밀도를 사용해가고 있으며 FP8 및 FP4에 도달하고 있다.

(FP8 혼합 정밀도 학습에 대한 우리의 경험에 대해 더 자세히 알고 싶다면 Ultra Scale Playbook을 확인하라.)

아래 표는 다양한 NVIDIA GPU 세대 및 정밀도에 걸친 이론적 피크 성능을 보여준다:

정밀도 / GPU 유형	A100	H100	H200	B100	B200
FP64	9.7	34	34	40	40
FP32	19.5	67	67	80	80
FP16/BF16	312	990	990	1750	2250
FP8	-	3960	3960	4500	5000
FP4	-	-	-	9000	10000

정밀도 및 GPU 세대에 따른 이론적 TFLOPs를 보여주는 표. 출처: Nvidia, SemiAnalysis

더 낮은 정밀도에서의 극적인 처리량 증가는 단순히 원시 속도에 관한 것이 아니라 수치 계산에 대한 우리의 생각을 근본적으로 전환하는 것을 반영한다. FP8 및 FP4는 모델이 와트당 및 초당 더 많은 연산을 수행할 수 있게 하여 대규모 학습 및 추론 모두에 필수적이다. H100의 FP8에서의 3960 TFLOPs는 FP16/BF16 대비 4배 향상을 나타내며, B200의 FP4에서의 10,000 TFLOPs는 이를 더욱 밀어붙인 것이다.

숫자 이해하기: 이러한 이론적 피크 FLOPs는 모든 컴퓨팅 유닛이 완전히 활용되고 데이터가 쉽게 사용 가능한 이상적인 조건 하에서 달성 가능한 최대 계산 처리량을 나타낸다. 실제에서, 실제 성능은 워크로드가 컴퓨팅 유닛에 데이터를 얼마나 잘 공급할 수 있는지, 그리고 작업이 사용 가능한 하드웨어에 효율적으로 매핑될 수 있는지에 크게 좌우된다.

SmolLM3의 경우 NVIDIA H100 80GB HBM3 GPU에서 학습할 예정이었으므로 먼저 실제 성능 대비 H100의 이론적 TFLOPs 사양을 테스트하고 싶었다. 이를 위해 우리는 SemiAnalysis GEMM 벤치마크를 사용했다: 이것은 Meta의 Llama 70B 학습의 실제 행렬 곱셈 모양에 대한 처리량을 테스트한다.

모양 (M, N, K)	FP64 torch.matmul	FP32 torch.matmul	FP16 torch.matmul	BF16 torch.matmul	FP8 TE.Linear (autocast, bias=False)	FP8 torch._scaled_mm (e5m2/e4m3fn)	FP8 torch._scaled_mm (e4m3)
(16384, 8192, 1280)	51.5 TFLOPS	364.5 TFLOPS	686.5 TFLOPS	714.5 TFLOPS	837.6 TFLOPS	1226.7 TFLOPS	1209.7 TFLOPS
(16384, 1024, 8192)	56.1 TFLOPS	396.1 TFLOPS	720.0 TFLOPS	757.7 TFLOPS	547.3 TFLOPS	1366.2 TFLOPS	1329.7 TFLOPS
(16384, 8192, 7168)	49.5 TFLOPS	356.5 TFLOPS	727.1 TFLOPS	752.9 TFLOPS	1120.8 TFLOPS	1464.6 TFLOPS	1456.6 TFLOPS
(16384, 3584, 8192)	51.0 TFLOPS	373.3 TFLOPS	732.2 TFLOPS	733.0 TFLOPS	952.9 TFLOPS	1445.7 TFLOPS	1370.3 TFLOPS
(8192, 8192, 8192)	51.4 TFLOPS	372.7 TFLOPS	724.9 TFLOPS	729.4 TFLOPS	1029.1 TFLOPS	1404.4 TFLOPS	1397.5 TFLOPS

Llama 70B 학습 워크로드의 정밀도 및 행렬 모양에 따라 H100 80GB에서 달성된 TFLOPs를 보여주는 표

이론적 성능 검증: 우리의 실험은 이론적 피크와 달성 가능한 성능 사이의 격차를 드러냈다.

FP64 Tensor 코어 연산의 경우 49-56 TFLOPs를 달성하여 이론적 피크(67 TFLOPs)의 74-84%를 나타냈다. TF32(PyTorch가 기본적으로 Tensor 코어의 FP32 텐서에 사용하는 TensorFloat-32)의 경우 356-396 TFLOPs를 달성하여 이론적 피크(~495 TFLOPs dense)의 72-80%를 나타냈다. 이들은 훌륭한 하드웨어 활용률을 보여주지만, 현대 딥러닝 학습에서는 이러한 정밀도가 거의 사용되지 않는다: FP64는 계산 비용 때문이고, TF32는 BF16 및 FP8과 같은 더 낮은 정밀도가 더 나은 성능을 제공하기 때문이다.

(NVIDIA 사양은 종종 2:4 구조적 희소성 패턴을 가정한 희소 성능(TF32의 경우 989 TFLOPs)을 나열한다. 우리 벤치마크가 테스트하는 밀집형 연산은 희소 피크의 약 절반(~495 TFLOPs)을 달성한다.)

BF16 연산의 경우 다양한 행렬 모양에서 일관되게 714-758 TFLOPs를 달성했으며, 이는 H100의 이론적 990 TFLOPs 피크의 약 72-77%이다. 이것은 실제로 실제 워크로드에 대해 훌륭한 활용률(utilisation rate) 이다!

📊 모델 FLOPs 활용률 (MFU)

커널 벤치마크는 원시 TFLOPS를 측정하지만, 종단 간 학습 효율성은 **모델 FLOPs 활용률(MFU)**로 포착된다: 이론적 피크 하드웨어 성능에 대한 유용한 모델 계산의 비율이다.

우리의 BF16 matmul 벤치마크는 H100 이론적 피크의 72-77%를 달성했음을 보여주었다. 이것은 우리 설정에 대해 커널 수준에서 달성할 수 있는 상한선을 나타낸다. 종단 간 학습 MFU는 더 복잡한 비-matmul 연산, 통신 오버헤드 및 기타 보조 계산으로 인해 필연적으로 더 낮을 것이다.

SOTA 학습 MFU: Meta는 Llama 3 405B를 학습할 때 38-41%를 달성한 반면, DeepSeek-v3는 MoE 아키텍처와 관련된 더 엄격한 통신 병목 현상이 있는 GPU에서 ~20-30%에 도달했다. SmolLM3의 경우 나중에 보게 되겠지만 ~30% MFU를 달성했다. 격차의 많은 부분은 분산 학습의 노드 간 통신 오버헤드에서 비롯된다. ~77%의 커널 수준 상한선을 감안할 때, 이러한 종단 간 수치는 달성 가능한 matmul 성능 대비 대략 50-55% 효율성을 나타낸다. 추론 워크로드는 원시 matmul 성능에 더 가까운 70% 이상의 더 높은 MFU에 도달할 수 있지만 프로덕션 배포에서 공개된 결과는 드물다.

FP8 결과는 더 미묘하다. 3가지 다른 행렬 곱셈 방법/커널에 대한 우리의 결과를 살펴보자.

(커널은 CUDA 코드의 단위이다.)

e4m3 정밀도로 PyTorch의 torch._scaled_mm 커널을 사용하여, 우리는 행렬 모양에 따라 1,210-1,457 TFLOPs를 달성했는데, 이는 이론적 3,960 TFLOPs 피크의 대략 31-37%이다. 😮 왜일까? (FP8에서) 이 낮은 활용률 비율은 실제로 성능 저하를 나타내지 않는다; 오히려, 컴퓨팅 처리량이 증가함에 따라 이러한 연산이 점점 더 메모리 제한적(memory-bound)이 됨을 보여준다. Tensor 코어는 메모리 시스템이 전달할 수 있는 것보다 더 빨리 FP8 데이터를 처리할 수 있어 메모리 대역폭이 제한 요인이 되는 것이다.

Transformer Engine의 TE.Linear는 모양에 따라 547-1,121 TFLOPs를 달성한 반면, torch._scaled_mm은 일관되게 더 높은 처리량을 제공했다. 이것은 중요한 교훈을 강조한다: 커널 구현은 상당히 중요하며, API 선택은 동일한 하드웨어 기능을 대상으로 할 때에도 성능에 2-3배 영향을 미칠 수 있다.

SmolLM3 학습의 경우, 이러한 실제 측정값은 현실적인 처리량 기대치를 설정하는 데 도움이 되었다. 자체 학습 실행을 계획할 때, 기대치를 설정하기 위해 이론적 피크보다는 이러한 달성 가능한 수치를 사용한다.

🔧컴퓨팅 능력 (Compute Capability)

올바른 커널 API를 선택하는 것 외에도, 우리는 그러한 커널이 올바른 하드웨어 세대를 위해 컴파일되었는지 확인해야 한다. 컴퓨팅 능력(CC, Compute Capability)은 PTX 명령 세트에서 물리적 GPU 세부 정보를 추상화하는 NVIDIA의 버전 관리 시스템이다. 이것은 GPU가 지원하는 명령 및 기능을 결정한다.

이것이 중요한 이유: 특정 컴퓨팅 능력을 위해 컴파일된 커널은 이전 하드웨어에서 실행되지 않을 수 있으며, 코드가 대상 GPU의 CC에 대해 컴파일되지 않은 경우 최적화를 놓칠 수 있다. 더 나쁜 것은, 프레임워크가 조용히 차선의 커널을 선택할 수 있다는 것이다—우리는 PyTorch가 H100에서 sm_75 커널 (Turing GPU용으로 설계된 컴퓨팅 능력 7.5)을 선택하여 미스터리한 속도 저하를 유발하는 것을 발견했다. 이것은 PyTorch 커뮤니티에 문서화된 유사한 문제로, 프레임워크가 종종 최적의 것보다는 더 오래되고 호환 가능한 커널을 기본값으로 설정한다. 이 겉보기에는 사소한 세부 사항은 동일한 하드웨어에서 720 TFLOPS를 얻느냐 500 TFLOPS를 얻느냐의 차이를 만들 수 있다.

미리 컴파일된 라이브러리나 사용자 정의 커널을 사용할 때, 항상 호환성과 최적의 성능을 보장하기 위해 하드웨어의 컴퓨팅 능력에 맞게 빌드되었는지 확인해야 한다. 예를 들어, sm90xmma_gemm…_cublas는 SM 9.0 (H100에서 사용되는 컴퓨팅 능력 9.0)용으로 컴파일된 커널을 나타낸다.

nvidia-smi --query-gpu=compute_cap으로 GPU의 컴퓨팅 능력을 확인하거나 NVIDIA CUDA C 프로그래밍 가이드의 컴퓨팅 능력 섹션에서 기술 사양을 찾을 수 있다.

우리가 보았듯이, 낮은 정밀도에서 계산이 너무 빨라지면 GPU 메모리가 병목 현상이 되는 것 같다. GPU 메모리가 어떻게 작동하는지, 그리고 무엇이 병목 현상을 유발하는지 살펴보자!

GPU 메모리 계층 구조: 레지스터에서 HBM까지

계산을 수행하기 위해 GPU는 메모리에 읽기/쓰기를 해야 하므로 이러한 전송이 어떤 속도로 발생하는지 아는 것이 중요하다. GPU 메모리 계층 구조를 이해하는 것은 고성능 커널을 작성하는 데 중요하다.

요약: GPU는 빠르지만 작은 것(레지스터, 공유 메모리)에서 느리지만 큰 것(HBM 메인 메모리)에 이르는 계층 구조로 메모리를 구성한다. 현대 AI는 종종 메모리 제한적이기 때문에 이 계층 구조를 이해하는 것이 중요하다: 병목 현상은 데이터를 계산하는 것이 아니라 이동시키는 것이다. 연산자 융합(Flash Attention과 같은)은 중간 결과를 느린 HBM에 쓰는 대신 빠른 온칩 메모리에 유지함으로써 2-4배 속도 향상을 달성한다. 벤치마크에 따르면 H100의 HBM3는 대규모 전송에 대해 이론적 사양과 일치하는 실제 ~3 TB/s를 제공한다.

실제로 메모리 작업이 GPU를 통해 어떻게 흐르는지 시각화하기 위해, 먼저 선택한 커널에 대해 서로 다른 메모리 장치 간에 데이터가 어떻게 이동하는지 그래픽으로 보여주는 프로파일링 그래프인 NVIDIA Nsight Compute의 메모리 차트를 살펴보자:

일반적으로 메모리 차트는 전역(Global), 로컬(Local), 텍스처(Texture), 표면(Surface), 공유(Shared) 메모리와 같은 논리적 장치(녹색)와 L1/TEX 캐시, 공유 메모리, L2 캐시, 장치 메모리와 같은 물리적 장치(파란색)를 모두 보여준다. 장치 간의 링크는 장치 간에 발생하는 명령(Inst) 또는 요청(Req) 수를 나타내며, 색상은 사용되지 않음(0%)에서 피크 성능 작동(100%)까지의 피크 활용률 백분율을 나타낸다.

NVIDIA Nsight Compute를 사용하여 모든 커널에 대해 이 메모리 차트를 생성할 수 있다:

## Profile a specific kernel with memory workload analysis
ncu --set full --kernel-name "your_kernel_name" --launch-skip 0 --launch-count 1 python your_script.py
## Once profiling is complete, open the results in the Nsight Compute GUI to view the Memory Chart

이것은 몇 가지 핵심 통찰력을 제공해줄 수 있따:

병목 현상 식별: 포화된 링크 (빨간색/주황색으로 표시됨)는 데이터 이동이 제한된 곳을 나타낸다.
캐시 효율성: L1/TEX 및 L2 캐시에 대한 적중률은 커널이 메모리 계층 구조를 얼마나 잘 활용하는지 보여준다.
메모리 액세스 패턴: 논리적 장치와 물리적 장치 간의 흐름은 커널이 좋은 공간적/시간적 지역성을 가지고 있는지 보여준다.
포트 활용률: 개별 메모리 포트는 총 대역폭이 활용되지 않은 것처럼 보일 때에도 포화될 수 있다.

위의 특정 사례에서, 커널 명령이 메모리 계층 구조를 통해 어떻게 흐르는지 볼 수 있다 (우리 하드웨어의 FP64 행렬 곱셈의 경우): 전역 로드 명령은 L1/TEX 캐시에 대한 요청을 생성하며, 이는 적중하거나 누락되어 L2에 대한 추가 요청을 생성하고, 이는 궁극적으로 누락 시 장치 메모리 (HBM)에 액세스한다. 장치 내부의 색칠된 직사각형은 포트 활용률을 보여준다. 개별 링크가 피크 미만으로 작동하더라도 공유 데이터 포트가 포화될 수 있다.

💡 메모리 계층 구조 액세스 최적화

최적의 성능을 위해, 느린 메모리 계층 (HBM)으로의 트래픽을 최소화하고 빠른 계층 (공유 메모리, 레지스터)의 활용을 극대화하는 것을 목표로 한다.

이제 이 차트를 가능하게 하는 기본 메모리 계층 구조를 이해해보자. 현대 GPU는 속도, 용량 및 비용의 균형을 맞추는 계층 구조로 메모리를 구성하는데, 이는 근본적인 물리 및 회로 제약에 의해 결정되는 설계이다.

이 계층 구조의 맨 아래에는 **HBM (High Bandwidth Memory)**이 있다: GPU의 메인 메모리로, 전역 메모리 또는 장치 메모리라고도 한다. H100은 이론적 대역폭이 3.35 TB/s인 HBM3를 가지고 있다. HBM은 메모리 계층 구조에서 가장 크지만 가장 느린 계층이다.

컴퓨팅 유닛을 향해 계층 구조를 올라가면 점진적으로 더 빠르지만 더 작은 메모리 계층이 있다:

L2 캐시: GPU 전체에 공유되는 대형 SRAM 기반 캐시로, 일반적으로 수십 메가바이트이다. H100에서는 이것이 50MB이며 ~13 TB/s의 대역폭을 가진다.
L1 캐시 및 공유 메모리 (SMEM): 각 스트리밍 멀티프로세서(SM)는 자체 L1 캐시와 프로그래머 관리 공유 메모리를 가지고 있으며, 이는 동일한 물리적 SRAM 스토리지를 공유한다. H100에서 이 결합된 공간은 SM당 256KB이며 SM당 ~31 TB/s의 대역폭을 가진다.
레지스터 파일 (RMEM): 계층 구조의 맨 위에서, 레지스터는 컴퓨팅 유닛 바로 옆에 위치한 가장 빠른 스토리지이다. 레지스터는 개별 스레드에 비공개이며 SM당 ~100s TB/s로 측정되는 대역폭을 제공한다.

이 계층 구조가 존재하는 이유는 SRAM (캐시 및 레지스터에 사용됨)은 빠르지만 물리적으로 크고 비싼 반면, DRAM (HBM에 사용됨)은 밀도가 높고 저렴하지만 느리기 때문이다. 결과: 빠른 메모리는 컴퓨팅에 가까운 소량으로 제공되며, 더 멀리 있는 더 느린 메모리의 점진적으로 더 큰 풀에 의해 지원된다.

이것이 중요한 이유: 이 계층 구조를 이해하는 것은 커널 최적화에 필수적이다. 핵심 통찰력은 메모리 제한 작업이 계산 속도가 아니라 데이터를 이동시키는 속도에 의해 제한된다는 것이다. Horace He가 Making Deep Learning Go Brrrr From First Principles에서 설명하듯이,

“메모리에서 로드” → “자체적으로 두 번 곱하기” → “메모리에 쓰기”

는 본질적으로

“메모리에서 로드” → “자체적으로 한 번 곱하기” → “메모리에 쓰기”

와 동일한 시간이 걸린다: 계산은 메모리 액세스에 비해 사실상 “공짜”이다.

이것이 **연산자 융합(operator fusion)**이 그토록 강력한 이유이다: 여러 연산을 단일 커널로 결합함으로써, 연산 사이에 느린 HBM에 다시 쓰는 대신 중간 결과를 빠른 SRAM에 유지할 수 있다. Flash Attention은 이 원칙이 작동하는 완벽한 예시이다.

⚡Flash Attention: 메모리 계층 구조 최적화 사례 연구

표준 어텐션 구현은 전체 어텐션 행렬을 HBM에 materialize 하기 때문에 메모리 제한적이다:

Q@K^T 를 계산 → N×N 크기의 어텐션 점수를 HBM에 쓰기
소프트맥스 적용 → HBM에서 읽기, 계산, HBM에 다시 쓰기
V 와 곱하기 → HBM에서 어텐션 점수 다시 읽기

Flash Attention은 이러한 연산을 융합하고 중간 결과를 SRAM에 유지함으로써 2-4배 속도 향상을 달성한다:

전체 어텐션 행렬을 계산하는 대신, SRAM에 맞는 타일(tiles)로 어텐션을 처리한다.
중간 어텐션 점수는 결코 빠른 온칩 메모리를 떠나지 않는다.
최종 출력만 HBM에 다시 쓰여진다.

결과: Flash Attention은 HBM 액세스를 $O(N^2)$ 에서 $O(N)$ 으로 줄여 메모리 제한 작업을 GPU의 컴퓨팅 기능을 더 잘 활용하는 작업으로 변환한다. 이것이 효율적인 커널 설계의 본질이다: 느린 메모리 이동 최소화, 빠른 계산 최대화

예시: 실제 HBM3 대역폭 검증

이제 메모리 계층 구조를 이해했으므로, 이론을 실천에 옮겨 H100 GPU의 실제 대역폭을 검증해 보자! 이 지점이 바로 벤치마킹 도구가 필수적이게 되는 순간이다.

NVBandwidth는 GPU 시스템 전반의 대역폭과 지연 시간을 측정하기 위해 특별히 설계된 NVIDIA의 오픈 소스 벤치마킹 도구이다. 이는 복사 엔진과 커널 기반 방법을 모두 사용하여 다양한 메모리 복사 패턴 (호스트-장치, 장치-호스트, 장치-장치 작업)에 대한 데이터 전송 속도를 평가한다. 이 도구는 특히 GPU 간 통신 (예: NVLink 및 PCIe, 두 가지 유형의 커넥터)을 평가하고 다중 GPU 환경에서 시스템 성능을 검증하는 데 유용하다.

NVIDIA의 GitHub 리포지토리에서 NVBandwidth를 설치할 수 있다. 이 도구는 다양한 장치 간에 데이터가 얼마나 효율적으로 전송되는지 보여주는 자세한 대역폭 행렬을 출력하므로 성능 병목 현상을 진단하거나 건강한 GPU 상호 연결을 확인하는 데 이상적이다.

다양한 메시지 크기에 걸쳐 GPU 로컬인 장치 버퍼 간 cuMemcpyAsync의 대역폭을 측정하는 device_local_copy 테스트를 사용하여 H100의 로컬 메모리 대역폭을 측정해보자.

(cuMemcpyAsync는 두 메모리 포인터 간에 데이터를 비동기적으로 복사하며 전송 유형(호스트-호스트, 호스트-장치, 장치-장치, 또는 장치-호스트)을 추론하는 CUDA 드라이버 API 함수이다.)

$ ./nvbandwidth -t device_local_copy -b 2048
memcpy local GPU(column) bandwidth (GB/s)
           0         1         2         3         4         5         6         7
 0   1519.07   1518.93   1519.07   1519.60   1519.13   1518.86   1519.13   1519.33

측정된 H100 로컬 메모리 대역폭

스크린샷 2025-12-04 오후 6.21.30.png

결과는 메모리 시스템의 중요한 특징을 드러낸다: 작은 메시지 크기 (< 1 MB)의 경우, 우리는 대역폭 제한보다는 **지연 시간 제한(latency-bound)**이다. 메모리 전송을 시작하는 오버헤드가 성능을 지배하여 피크 대역폭에 도달하는 것을 방해한다. 그러나 큰 메시지 크기 ( ≥1 MB)의 경우, 우리는 읽기 및 쓰기 작업 모두에 대해 ~1,500 GB/s의 지속적인 대역폭을 달성한다.

HBM 대역폭은 읽기와 쓰기가 동시에 발생하는 것을 고려하므로, 이들을 합산하여 3 TB/s 총 양방향 대역폭 (1,519 읽기 + 1,519 쓰기)을 얻으며, 이는 H100의 이론적 3.35 TB/s HBM3 사양이 밀접하게 검증된 것이다.

루프라인 모델 (Roofline Model)

커널이 컴퓨팅 제한적인지 메모리 제한적인지 이해하는 것은 어떤 최적화가 도움이 될지 결정할 수 있게 해준다.

두 가지 시나리오가 있다:

**메모리 제한적(memory-bound)**인 경우 (대부분의 시간을 데이터 이동에 소비): 컴퓨팅 처리량을 늘리는 것은 도움이 되지 않는다: 연산자 융합과 같은 기술을 통해 메모리 트래픽을 줄여야 한다.
**컴퓨팅 제한적(compute-bound)**인 경우 (대부분의 시간을 FLOPs에 소비): 메모리 액세스 패턴을 최적화하는 것은 도움이 되지 않는다: 더 많은 컴퓨팅 파워나 더 나은 알고리즘이 필요하다.

루프라인 모델은 이러한 성능 특성을 이해하고 최적화 기회를 식별하기 위한 시각적 프레임워크를 제공한다.

실제 커널 분석에 적용해보자. 앞서 언급한 NSight Compute 프로파일링 도구에서 사용할 수 있다 (“roofline analysis view” 아래). 다음은 이를 실행했을 때 얻는 결과의 모습이다:

(커널 성능 경계를 보여주는 루프라인 차트 - 출처: NVIDIA NSight Compute Profiling Guide)

두 개의 축을 가진 이 차트를 읽는 방법은 다음과 같다:

수직축 (FLOP/s): 달성된 초당 부동 소수점 연산을 보여주며, 큰 범위의 값을 수용하기 위해 로그 스케일을 사용한다.
수평축 (산술 강도, Arithmetic Intensity): 메모리 트래픽(바이트)에 대한 작업(FLOPs)의 비율을 나타내며, 바이트당 FLOPs로 측정된다. 이것 또한 로그 스케일을 사용한다.

루프라인 자체는 두 개의 경계로 구성된다:

메모리 대역폭 경계 (기울어진 선): GPU의 메모리 전송 속도(HBM 대역폭)에 의해 결정된다. 이 선을 따른 성능은 데이터를 이동할 수 있는 속도에 의해 제한된다.
피크 성능 경계 (평평한 선): GPU의 최대 컴퓨팅 처리량에 의해 결정된다. 이 선을 따른 성능은 계산을 실행할 수 있는 속도에 의해 제한된다.

이러한 경계가 만나는 **융기점(ridge point)**은 메모리 제한 체제와 컴퓨팅 제한 상태 사이의 전환을 나타내는 지점이다.

우리는 이제 차트의 두 분할된 영역을 보며 성능을 해석할 수 있다:

메모리 제한 (기울어진 경계 아래): 이 영역의 커널은 메모리 대역폭에 의해 제한된다. GPU는 데이터를 기다리고 있으며, 컴퓨팅 파워를 늘리는 것은 도움이 되지 않는다. 최적화는 연산자 융합, 더 나은 메모리 액세스 패턴 또는 산술 강도 증가와 같은 기술을 통해 메모리 트래픽을 줄이는 데 초점을 맞춰야 한다.
컴퓨팅 제한 (평평한 경계 아래): 이 영역의 커널은 컴퓨팅 처리량에 의해 제한된다. GPU는 충분한 데이터를 가지고 있지만 충분히 빨리 처리할 수 없다. 최적화는 알고리즘 개선이나 Tensor 코어와 같은 특수 하드웨어 활용에 초점을 맞춰야 한다.

달성된 값 (플롯된 점)은 커널이 현재 어디에 위치하는지 보여준다. 이 점과 루프라인 경계까지의 거리는 최적화 여유 공간을 나타내며, 경계에 가까울수록 커널의 성능이 더 최적이다.

우리 예시에서, 커널은 메모리 제한 영역에 위치하며, 이는 메모리 트래픽을 최적화하여 개선할 여지가 여전히 있음을 나타낸다!

CUDA 코어, Tensor 코어, 메모리 계층 구조 및 저수준 최적화 기술에 대한 자세한 설명을 포함하여 GPU 내부에 대한 더 깊은 탐구를 원하면 Ultrascale Playbook을 확인하라! 이제 GPU 내부에서 무슨 일이 일어나는지 이해했으므로, 축소하여 GPU가 나머지 세상과 어떻게 통신하는지 살펴보자.

GPU 외부: GPU가 세상과 대화하는 방법

이제 GPU가 내부 메모리 계층 구조를 사용하여 계산을 수행하는 방법을 이해했으므로, 중요한 현실을 다뤄야 한다: GPU는 홀로 고립되어 작동하지 않는다. 계산이 일어나기 전에, 데이터는 GPU 메모리로 로드되어야 한다. CPU는 커널을 스케줄링하고 작업을 조정해야 한다. 그리고 분산 학습에서, GPU는 서로 활성화, 기울기, 그리고 모델 가중치를 지속적으로 교환해야 한다.

이곳이 외부 통신 인프라가 중요해지는 곳이다. GPU의 컴퓨팅 유닛이 아무리 강력하더라도 데이터가 CPU, 스토리지, 또는 다른 GPU로부터 충분히 빨리 도달할 수 없다면, 비싼 하드웨어는 유휴(idle) 상태가 된다. 이러한 통신 경로와 대역폭 특성을 이해하는 것은 하드웨어 활용을 극대화하고 병목 현상을 최소화하는 데 필수적이다.

이 섹션에서는 GPU를 외부 세계와 연결하는 네 가지 중요한 통신 링크를 살펴볼 것이다:

GPU-CPU: CPU가 작업을 스케줄링하고 데이터를 GPU로 전송하는 방법
GPU-GPU 노드 내 (Intra-node): 동일한 머신에 있는 GPU가 통신하는 방법
GPU-GPU 노드 간 (Inter-node): 네트워크를 통해 다른 머신에 있는 GPU가 통신하는 방법
GPU-스토리지: 데이터가 스토리지에서 GPU 메모리로 흐르는 방법

각 링크는 서로 다른 대역폭과 지연 시간 특성을 가지고 있으며, 이를 이해하면 학습 파이프라인이 어디에서 병목 현상을 겪고 있는지 식별하는 데 도움이 될 것이다. 이해를 돕기 위해, 우리는 가장 중요한 구성 요소와 통신 링크를 강조하는 단순화된 다이어그램을 만들었다:

스크린샷 2025-12-04 오후 6.28.54.png

이것이 너무 과하게 어려워 보인다고 하더라도 걱정하지 않아도 좋다. 우리는 이러한 각각의 연결에 대해 자세히 알아보고 각 링크의 성능 특성을 이해하기 위해 실제 대역폭을 측정해볼 것이다.

GPU 대 CPU (GPU-to-CPU)

요약: CPU는 PCIe 연결을 통해 GPU 작업을 조율하며, 우리 p5 인스턴스의 CPU 대 GPU 전송의 경우 ~14.2 GB/s (PCIe Gen4 x8)에서 병목 현상이 발생한다. CPU-GPU 지연 시간은 ~1.4 마이크로초이며, 이는 많은 작은 커널이 있는 워크로드에 문제가 되는 커널 실행 오버헤드를 추가한다. CUDA 그래프는 작업을 배치 처리하여 이 오버헤드를 줄일 수 있다. NUMA 친화도는 멀티 소켓 시스템에서 중요하며; 잘못된 CPU 소켓에서 GPU 프로세스를 실행하면 상당한 지연 시간이 추가된다. Grace Hopper와 같은 최신 아키텍처는 NVLink-C2C (900 GB/s 대 128 GB/s)로 PCIe 병목 현상을 제거한다.

CPU는 GPU 계산의 지휘자(orchestrator)이다. 커널 실행, 메모리 할당 관리, 데이터 전송 조정을 담당한다. 하지만 CPU는 실제로 얼마나 빨리 GPU와 통신할 수 있는가? 이것은 그들 사이의 PCIe (Peripheral Component Interconnect Express) 연결에 의해 결정된다.

이 링크를 이해하는 것은 이 링크가 다음과 같은 영향을 미치기 때문에 중요하다:

커널 실행 지연 시간: CPU가 GPU에 작업을 얼마나 빨리 스케줄링할 수 있는가
데이터 전송 속도: CPU와 GPU 메모리 간에 데이터를 얼마나 빨리 이동할 수 있는가
동기화 오버헤드: CPU-GPU 조정 지점의 비용

현대 GPU 서버에서 CPU-GPU 연결은 크게 발전했다. 초기 시스템은 다이렉트 PCIe 연결을 사용했지만, DGX H100과 같은 현대 고성능 시스템은 여러 GPU를 효율적으로 관리하기 위해 PCIe 스위치를 사용하는 더 정교한 토폴로지를 사용한다. 그리고 최신 GB200 아키텍처를 통해 NVIDIA는 CPU와 GPU를 동일한 인쇄 회로 기판에 배치하여 외부 스위치의 필요성을 완전히 제거함으로써 이를 한 단계 더 발전시켰다.

잠재적인 병목 현상을 식별하기 위해 lstopo를 사용하여 p5 인스턴스의 물리적 토폴로지를 검사한 다음 이 중요한 링크의 실제 성능을 측정해보자.

$ lstopo -v
...
HostBridge L#1 (buses=0000:[44-54])
    PCIBridge L#2 (busid=0000:44:00.0 id=1d0f:0200 class=0604(PCIBridge) link=15.75GB/s buses=0000:[45-54] PCISlot=64)
        PCIBridge L#3 (busid=0000:45:00.0 id=1d0f:0200 class=0604(PCIBridge) link=15.75GB/s buses=0000:[46-54] PCISlot=1-1)
            ...
            PCIBridge L#12 (busid=0000:46:01.4 id=1d0f:0200 class=0604(PCIBridge) link=63.02GB/s buses=0000:[53-53])
                PCI L#11 (busid=0000:53:00.0 id=10de:2330 class=0302(3D) link=63.02GB/s PCISlot=86-1)
                    Co-Processor(CUDA) L#8 (Backend=CUDA GPUVendor="NVIDIA Corporation" GPUModel="NVIDIA H100 80GB HBM3" CUDAGlobalMemorySize=83295872 CUDAL2CacheSize=51200 CUDAMultiProcessors=132 CUDACoresPerMP=128 CUDASharedMemorySizePerMP=48) "cuda0"
                    GPU(NVML) L#9 (Backend=NVML GPUVendor="NVIDIA Corporation" GPUModel="NVIDIA H100 80GB HBM3" NVIDIASerial=1654922006536 NVIDIAUUID=GPU-ba136838-6443-7991-9143-1bf4e48b2994) "nvml0"
            ...
...

lstopo 출력에서 우리 시스템의 두 가지 주요 PCIe 대역폭 값을 볼 수 있다:

15.75GB/s: PCIe Gen4 x8 링크 (CPU에서 PCIe 스위치로)에 해당
63.02GB/s: PCIe Gen5 x16 링크 (PCIe 스위치에서 GPU로)에 해당

전체 토폴로지를 더 잘 이해하기 위해 다음을 사용하여 시각화할 수 있다:

$ lstopo --whole-system lstopo-diagram.png

이 다이어그램은 우리 시스템의 계층 구조를 보여준다:

두 개의 NUMA (Non-Uniform Memory Access) 노드를 포함한다 (NUMA는 CPU 소켓당 메모리 영역이다).
각 CPU 소켓은 PCIe Gen4 x8 링크 (15.75GB/s)를 통해 4개의 PCIe 스위치에 연결된다.
각 PCIe 스위치는 PCIe Gen5 x16 링크 (63.02GB/s)를 통해 하나의 H100 GPU에 연결된다.
… (우리는 다음 섹션에서 NVSwitch, EFA 네트워크 카드 및 NVMe 드라이브와 같은 다른 구성 요소를 탐색할 것이다.)

PCIe 사양은 세대마다 다르며, 레인당 전송 속도가 두 배로 증가했다. 전송 속도는 GT/s (초당 기가전송)로 측정되며 원시 신호 속도를 나타내는 반면, 처리량은 GB/s (초당 기가바이트)로 측정되며 인코딩 오버헤드를 설명하고 실제 사용 가능한 대역폭을 나타낸다는 점에 유의해야 한다:

PCIe 버전	전송 속도 (레인당)	처리량 (GB/s) x16
1.0	2.5 GT/s	4.0
2.0	5.0 GT/s	8.0
3.0	8.0 GT/s	15.754
4.0	16.0 GT/s	31.508
5.0	32.0 GT/s	63.015
6.0	64.0 GT/s	121.0
7.0	128.0 GT/s	242.0

스크린샷 2025-12-04 오후 8.34.19.png

토폴로지 다이어그램과 PCIe 대역폭 표에서, CPU-대-GPU 경로가 두 개의 PCIe 홉을 통과함을 알 수 있다: 먼저 PCIe Gen4 x8 (15.754 GB/s)을 통해 CPU에서 PCIe 스위치로, 그 다음 PCIe Gen5 x16 (63.015 GB/s)을 통해 PCIe 스위치에서 GPU로 간다. 이는 CPU-GPU 통신의 병목 현상이 15.754 GB/s 에서의 첫 번째 홉임을 의미한다. 또 다른 유틸리티인 nvbandwidth로 이것을 검증해보자!

host_to_device_memcpy_ce 명령은 GPU의 복사 엔진을 사용하여 호스트(CPU) 메모리에서 장치(GPU) 메모리로의 cuMemcpyAsync의 대역폭을 측정한다.

./nvbandwidth -t host_to_device_memcpy_ce -b <message_size> -i 5

스크린샷 2025-12-04 오후 8.35.40.png

결과는 실제로 작은 메시지 크기의 경우 지연 시간 제한적이지만, 큰 메시지 크기의 경우 ~14.2 GB/s를 달성함을 보여주며, 이는 PCIe Gen4 x8에 대한 이론적 15.754 GB/s 대역폭의 약 90%이다. 이것은 CPU-GPU 통신에서 CPU-대-PCIe 스위치 링크가 실제로 우리의 병목 현상임을 확인시켜준다.

대역폭 외에도, 지연 시간은 CPU가 커널을 얼마나 빨리 스케줄링할 수 있는지 결정하므로 CPU-GPU 통신에 똑같이 중요하다. 이를 측정하기 위해 포인터 추적 커널을 사용하여 왕복 지연 시간을 측정하는 nvbandwidth의 host_device_latency_sm 테스트를 사용할 수 있다. host_device_latency_sm 테스트는 호스트(CPU)에 버퍼를 할당하고 포인터 추적 커널을 사용하여 GPU에서 액세스함으로써 왕복 지연 시간을 측정한다. 이것은 CPU-GPU 통신의 실제 지연 시간을 시뮬레이션해준다.

./nvbandwidth -t host_device_latency_sm -i 5

스크린샷 2025-12-04 오후 8.37.08.png

결과는 지연 시간이 약 1.4 마이크로초임을 보여준다. 이것은 우리가 ML 워크로드에서 종종 관찰하는 몇 마이크로초의 커널 실행 오버헤드를 설명해준다. 많은 작은 커널을 실행하는 워크로드의 경우, 추가된 지연 시간이 병목 현상이 될 수 있다; 그렇지 않으면 오버헤드는 겹치는 실행에 의해 숨겨진다.

(예를 들어 소형 모델이나 작은 배치의 경우 커널 실행 때문에 GPU에서 추론이 포화되는 것을 볼 수 있다. FlashFormer는 속도 향상을 얻기 위해 전체 레이어를 융합함으로써 이를 해결한다 (Nrusimha et al., 2025).)

🚀 실행 오버헤드를 줄이기 위한 CUDA 그래프

CUDA 그래프는 일련의 작업을 캡처하고 단일 단위로 재생함으로써 각 커널 실행에 대한 마이크로초 단위의 CPU-GPU 왕복 지연 시간을 제거하여 커널 실행 오버헤드를 크게 줄일 수 있다. 이것은 많은 작은 커널이나 빈번한 CPU-GPU 동기화가 있는 워크로드에 특히 유용하다. 실행 오버헤드 이해 및 최적화에 대한 자세한 내용은 NVIDIA Nsight Systems의 오버헤드 및 지연 시간 시각화 이해(https://developer.nvidia.com/blog/understanding-the-visualization-of-overhead-and-latency-in-nsight-systems/) 를 참조해라.

⚠️ MoE 모델 및 CPU-GPU 동기화 오버헤드

전문가 혼합(MoE) 모델의 일부 구현은 선택된 전문가에 적절한 커널을 스케줄링하기 위해 각 반복에서 CPU-GPU 동기화를 요구한다. 이것은 특히 CPU-GPU 연결이 느릴 때 처리량에 상당한 영향을 미칠 수 있는 커널 실행 오버헤드가 MoE에서 발생할 수 있기 때문이다. 예를 들어, DeepSeek MOE 커널의 MakoGenerate 최적화에서, 참조 구현은 순방향 패스당 67개의 CPU-GPU 동기화 지점과 함께 1,043개의 커널을 디스패치했다. 전문가 라우팅 메커니즘을 재구성함으로써, 그들은 이를 533개의 커널 실행과 단 3개의 동기화 지점으로 줄여, 동기화 오버헤드를 97% 줄이고 종단 간 지연 시간을 44% 줄였다. 모든 MoE 구현이 CPU-GPU 동기화를 요구하는 것은 아니지만 (현대 구현은 종종 라우팅을 전적으로 GPU에 유지한다), 그렇게 하는 경우 효율적인 CPU-GPU 통신이 성능에 크게 기여한다.

🔗 Grace Hopper 슈퍼칩: CPU-GPU 통신에 대한 다른 접근 방식

NVIDIA의 Grace Hopper 슈퍼칩은 기존 x86+Hopper 시스템에 비해 CPU-GPU 통신에 근본적으로 다른 접근 방식을 취한다. 주요 개선 사항은 다음과 같다:

1:1 GPU 대 CPU 비율 (x86+Hopper의 경우 4:1과 비교), GPU당 3.5배 더 높은 CPU 메모리 대역폭 제공
NVLink-C2C가 PCIe Gen5 레인을 대체하여 900 GB/s 대 128 GB/s 제공 (7배 더 높은 GPU-CPU 링크 대역폭)
PCIe Gen4를 통해 연결된 InfiniBand NDR400 NIC보다 9배 더 높은 GPU-GPU 링크 대역폭을 제공하는 NVLink 스위치 시스템

자세한 내용은 NVIDIA Grace Hopper 슈퍼칩 아키텍처 백서 (11페이지, https://download.deltacomputer.com/NVIDIA Grace Hopper Superchip Architecture Whitepaper.pdf)를 참고하라.

⚠️ NUMA 친화도: 멀티 소켓 성능에 중요함

우리의 AMD EPYC 7R13 노드 (2 소켓, 각 48 코어)와 같은 멀티 소켓 시스템에서, NUMA 친화도(NUMA affinity)는 GPU 성능에 중요하다. 이는 대상 장치 (예: GPU)와 동일한 소켓을 공유하는 CPU 코어에서 프로세스를 실행하는 것을 의미한다. GPU 프로세스가 GPU가 연결된 곳과 다른 NUMA 노드의 CPU에서 실행되면, 작업은 CPU 상호 연결 (AMD Infinity Fabric)을 통과해야 하므로 상당한 지연 시간과 대역폭 제약이 추가된다.

먼저, 성능의 의미를 이해하기 위해 NUMA 토폴로지와 노드 거리를 검사해보자:

$ numactl --hardware
node distances:
node   0   1
  0:  10  32
  1:  32  10

거리 값은 동일한 NUMA 노드 (거리 10)의 메모리에 액세스하는 것이 다른 NUMA 노드 (거리 32)로 건너가는 것보다 훨씬 빠르다는 것을 보여준다. 이 3.2배의 메모리 액세스 지연 시간 차이는 프로세스가 잘못된 NUMA 노드에 고정될 때 GPU 성능에 상당한 영향을 미칠 수 있다.

NUMA 관련 성능 문제 진단 및 해결에 대한 자세한 단계는 상호 연결 성능 문제 해결 섹션을 참고해라.

GPU 대 GPU 노드 내 (GPU-to-GPU Intranode)

분산 학습에서, GPU는 종종 반복당 기가바이트의 데이터인 기울기, 가중치, 활성화를 자주 교환해야 한다. 이 방대한 양의 데이터는 통신의 신중한 처리를 요구한다. H100의 내부 HBM은 약 3 TB/s로 읽을 수 있지만, 실수로 잘못된 플래그를 사용하면 GPU 대 GPU 통신 대역폭이 완전히 망가질 수 있다!

동일한 노드 내의 GPU 간 통신을 수행할 수 있는 모든 방법 (그리고 설정해야 하거나 설정하지 말아야 하는 모든 플래그)을 검토하여 왜 망가질 수 있는지 그 이유에 대해 알아보자 🙂

요약: 노드 내의 GPU는 세 가지 방식으로 통신할 수 있다: CPU를 통함 (가장 느림, ~3 GB/s, PCIe 병목), EFA NIC를 통한 GPUDirect RDMA (~38 GB/s), 또는 NVLink를 통한 GPUDirect RDMA (~786 GB/s 양방향). NVLink는 9-112배 빠르며 CPU/PCIe를 완전히 우회한다. NCCL은 사용 가능할 때 NVLink를 자동으로 우선시한다. NVLink SHARP (NVLS)는 하드웨어 가속 집합(collective)을 제공하여 allreduce 성능을 1.3배인 480 GB/s로 높인다. 그러나 alltoall 작업 (340 GB/s)은 NVLS 가속의 이점을 얻지 못한다.

CPU를 통해

순진한 접근 방식은 호스트 메모리 (SHM)를 사용한다: 데이터는 GPU1에서 PCIe 스위치를 통해 CPU로, 호스트 메모리로 들어갔다가, 다시 CPU를 통해, PCIe 스위치를 다시 통과하여, 마지막으로 GPU2로 이동한다. 이것은 NCCL에 의해 NCCL_P2P_DISABLE=1 및 FI_PROVIDER=tcp 환경 변수를 사용하여 달성될 수 있다 (권장되지는 않음). 이 모드가 활성화되면 NCCL_DEBUG=INFO를 설정하여 확인할 수 있으며 다음과 같은 메시지가 표시된다:

NCCL INFO Channel 00 : 1[1] -> 0[0] via SHM/direct/direct

스크린샷 2025-12-04 오후 8.51.50.png

CPU 및 메인 메모리를 통한 GPU-대-GPU 통신 경로, PCIe 스위치와 CPU를 통과하는 비효율적인 왕복을 보여준다.

이 우회 경로는 여러 메모리 복사를 포함하며 PCIe 및 CPU 메모리 버스를 모두 포화시켜 혼잡을 유발한다. 4개의 H100이 동일한 CPU 메모리 버스를 공유하는 우리 토폴로지에서, 이 혼잡은 여러 GPU가 동시 통신을 시도할 때 더욱 문제가 되는데, 그들이 동일한 제한된 CPU 메모리 대역폭을 두고 경쟁하기 때문이다… 😢

이 CPU 중개 접근 방식을 사용하면, 우리는 근본적으로 CPU와 PCIe 스위치 사이의 ~16 GB/s인 PCIe Gen4 x8 링크에 의해 병목 현상을 겪는다. 다행히도, CPU를 포함하지 않고 우리 GPU가 통신할 수 있는 더 나은 방법이 있다: GPUDirect RDMA.

Libfabric EFA를 통해

**GPUDirect RDMA (Remote Direct Memory Access 또는 GDRDMA)**는 GPU 메모리에 대한 직접 액세스를 허용하여 NVIDIA GPU 간의 직접 통신을 가능하게 하는 기술이다. 이는 데이터가 시스템 CPU를 통과할 필요성을 제거하고 시스템 메모리를 통한 버퍼 복사를 피하여, 기존 CPU 중개 전송에 비해 최대 10배 더 나은 성능을 제공한다. GPUDirect RDMA는 PCIe를 통해 작동하여 노드 내에서 (여기서 보는 바와 같이) 그리고 RDMA 기능이 있는 NIC (네트워크 인터페이스 카드, 다음 섹션에서 보게 될 것이다)를 사용하여 노드 간에 빠른 GPU 대 GPU 통신을 가능하게 한다. 자세한 내용은 NVIDIA GPUDirect (https://developer.nvidia.com/gpudirect)를 참고해라..

토폴로지 다이어그램을 다시 보면, 각 PCIe 스위치에 4개의 EFA (Elastic Fabric Adapter) NIC가 있음을 알 수 있다. 즉, 각 GPU는 4개의 EFA 어댑터에 액세스할 수 있다. EFA는 클라우드 인스턴스를 위한 AWS의 맞춤형 고성능 네트워크 인터페이스로, 저지연, 고처리량 인스턴스 간 통신을 제공하도록 설계되었다. p5 인스턴스에서, EFA는 애플리케이션이 사용할 수 있는 libfabric 인터페이스 (고성능 계산을 위한 특정 통신 API)를 노출하며, 노드 간 직접 GPU 대 GPU 통신을 위한 GPUDirect RDMA를 가능하게 하는 RDMA 유사 기능을 제공한다.

(EFA는 상품 데이터 센터 네트워크(많은 수의 네트워크 경로가 있는)를 사용하도록 설계된 Scalable Reliable Datagram (SRD)이라는 신뢰할 수 있는 이더넷 기반 전송 프로토콜을 사용한다. 여기(https://aws.amazon.com/blogs/hpc/in-the-search-for-performance-theres-more-than-one-way-to-build-a-network/) 에서 그 중요성에 대해 알아볼 수 있다.)

$ lstopo -v
...
## We can see 4 such EFA devices per each PCIe switch
PCIBridge L#8 (busid=0000:46:01.0 id=1d0f:0200 class=0604(PCIBridge) link=15.75GB/s buses=0000:[4f-4f] PCIVendor="Amazon.com, Inc.")
PCI L#6 (busid=0000:4f:00.0 id=1d0f:efa1 class=0200(Ethernet) link=15.75GB/s PCISlot=82-1 PCIVendor="Amazon.com, Inc.")
    OpenFabrics L#4 (NodeGUID=cd77:f833:0000:1001 SysImageGUID=0000:0000:0000:0000 Port1State=4 Port1LID=0x0 Port1LMC=1 Port1GID0=fe80:0000:0000:0000:14b0:33ff:fef8:77cd) "rdmap79s0"
...

$ fi_info --verbose
        fi_link_attr:
            address: EFA-fe80::14b0:33ff:fef8:77cd
            mtu: 8760            # maximum packet size is 8760 bytes
            speed: 100000000000  # each EFA link provides 100 Gbps of bandwidth
            state: FI_LINK_UP
            network_type: Ethernet

각 EFA 링크는 100 Gbps (12.5 GB/s)의 대역폭을 제공한다. GPU당 4개의 EFA NIC와 노드당 8개의 GPU가 있으므로, 이는 **노드당 100×4×8=3200 Gbps (400GB/s)**의 총 대역폭을 제공한다.

(libfabric과 EFA를 사용하여 이 3200 Gbps 대역폭을 완전히 활용하는 방법에 대한 자세한 탐구는 Lequn Chen의 훌륭한 블로그 시리즈: Harnessing 3200 Gbps Network: A Journey with RDMA, EFA, and libfabric을 참고하라.)

EFA를 통한 GPUDirect RDMA를 활성화하고 있는지 확인하려면, FI_PROVIDER=efa 및 NCCL_P2P_DISABLE=1 환경 변수를 설정해야 한다. 이 모드가 활성화되면 NCCL_DEBUG=INFO를 설정하여 작동하는지 확인할 수 있으며 다음과 같은 메시지가 표시된다:

NCCL INFO Channel 01/1 : 1[1] -> 0[0] [receive] via NET/Libfabric/0/GDRDMA/Shared

스크린샷 2025-12-04 오후 8.55.16.png

Libfabric EFA를 통한 GPU-대-GPU 통신 경로. 이것은 NVLink를 사용하는 것에 비해 노드 내 통신에 덜 효율적이라는 점에 유의해라.

EFA를 통한 GPUDirect RDMA가 GPU당 4개의 EFA 카드로 약 50 GB/s를 달성하여 CPU 중개 전송보다 상당한 개선을 제공하지만, 더 잘할 수 있을까? 여기서 NVLink가 등장한다.

NVLink를 통해

NVLink는 서버 내에서 빠른 다중 GPU 통신을 가능하게 하는 NVIDIA의 고속, 직접 GPU 대 GPU 상호 연결 기술이다. H100은 4세대 NVLink (NVLink 4.0)를 사용하여, 각각 양방향 50 GB/s로 작동하는 18개의 링크를 통해 GPU당 900 GB/s의 양방향 대역폭을 제공한다 (NVIDIA H100 Tensor Core GPU 데이터시트 https://resources.nvidia.com/en-us-hopper-architecture/nvidia-h100-tensor-c).

DGX H100 아키텍처에서, 4개의 3세대 NVSwitch는 각 GPU가 스위치 전반에 걸쳐 5+4+4+5 링크로 연결되는 계층화된 토폴로지를 사용하여 8개의 GPU를 연결한다. 이 구성은 단 1개의 NVSwitch라는 일정한 홉 수로 모든 GPU 쌍 간에 여러 직접 경로를 보장하여 3.6 TB/s의 총 양방향 NVLink 네트워크 대역폭을 구축한다.

NVLink 2.0 (Volta)	NVLink 3.0 (Ampere)	NVLink 4.0 (Hopper)	NVLink 5.0 (Blackwell)
대역폭	300 GB/s	600 GB/s	900 GB/s

표: 세대별 NVLink 대역폭 비교, 이론적 사양을 보여준다

기본적으로 NCCL은 사용 가능할 때 노드 내 GPU 통신을 위해 NVLink를 우선시하는데, 이는 동일한 머신에 있는 GPU 간에 가장 낮은 지연 시간과 가장 높은 대역폭 경로를 제공하기 때문이다. 그러나 플래그를 제대로 설정하지 않았다면 NVLink 사용을 방해하고 있을 수 있다! 😱

NVLink는 CPU나 시스템 메모리를 포함하지 않고 직접 GPU 대 GPU 메모리 액세스를 가능하게 한다. NVLink를 사용할 수 없을 때 NCCL은 PCIe를 통한 GPUDirect P2P로 되돌아가거나, 소켓 간 PCIe 전송이 차선책일 때 공유 메모리 (SHM) 전송을 사용한다.

NVLink가 사용되고 있는지 확인하려면 NCCL_DEBUG=INFO를 설정하고 다음과 같은 메시지를 찾으면 된다:

NCCL INFO Channel 00/1 : 0[0] -> 1[1] via P2P/CUMEM

(CUMEM은 피어 투 피어 작업이 CUDA 메모리 핸들(cuMem API)을 사용함을 나타낸다. 자세한 내용은 여기(https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/troubleshooting.html#cumem-host-allocations) 를 참고해라.)

다음 다이어그램은 NVLink를 사용할 때 데이터가 이동하는 직접 경로를 보여준다:

스크린샷 2025-12-04 오후 8.57.36.png

NVLink 4.0의 이론적 대역폭인 900 GB/s와 EFA의 ~50 GB/s를 비교하면, 노드 내 통신에 대해 18배의 이점을 기대할 수 있다. 실제에서 이를 검증하기 위해, 우리는 NCCL의 SendRecv 성능 테스트를 실행하여 다양한 통신 경로에 걸쳐 실제 대역폭을 측정했다:

$ FI_PROVIDER=XXX NCCL_P2P_DISABLE=X sendrecv_perf -b 8 -e 8G -f 2 -g 1 -c 1 -n 100

스크린샷 2025-12-04 오후 8.58.39.png

이것은 NVLink가 얼마나 더 효율적인지 의심의 여지 없이 보여준다: 그것은 EFA의 38.16 GB/s (9배 더 빠름, 또는 양방향 18배)와 CPU 기준선의 3.24 GB/s (112.6배 더 빠름)에 비해 364.93 GB/s를 달성한다. 이러한 측정은 NCCL이 노드 내 GPU 통신을 위해 NVLink를 우선시하는 이유를 확인시켜 주지만, NVLink의 성능을 더 확인하기 위해 양방향 동시 복사를 사용하여 모든 GPU 쌍 간의 양방향 대역폭을 측정하는 nvbandwidth를 실행해보자:

./nvbandwidth -t device_to_device_bidirectional_memcpy_write_ce -b <message_size> -i 5
memcpy CE GPU(row) <-> GPU(column) Total bandwidth (GB/s)
           0         1         2         3         4         5         6         7
 0       N/A    785.81    785.92    785.90    785.92    785.78    785.92    785.90
 1    785.83       N/A    785.87    785.83    785.98    785.90    786.05    785.94
 2    785.87    785.89       N/A    785.83    785.96    785.83    785.96    786.03
 3    785.89    785.85    785.90       N/A    785.96    785.89    785.90    785.96
 4    785.87    785.96    785.92    786.01       N/A    785.98    786.14    786.08
 5    785.81    785.92    785.85    785.89    785.89       N/A    786.10    786.03
 6    785.94    785.92    785.99    785.99    786.10    786.05       N/A    786.07
 7    785.94    786.07    785.99    786.01    786.05    786.05    786.14       N/A

SUM device_to_device_bidirectional_memcpy_write_ce_total 44013.06

측정된 양방향 대역폭 786 GB/s는 NVLink 4.0의 이론적 900 GB/s 사양의 85%를 나타낸다. NVLink를 사용함으로써 CPU 병목 현상을 완전히 우회했다 (gpu-to-gpu 통신을 위해)!

하지만 이것이 집합 통신 패턴으로 어떻게 변환되는가? NCCL 테스트의 all_reduce_perf 벤치마크를 사용하여 단일 노드 내의 allreduce 성능을 측정해 본다.

(집합 통신 패턴에 대한 빠른 복습은 UltraScale Playbook 부록을 참고해라.)

$ ./all_reduce_perf -b 8 -e 16G -f 2 -g 1 -c 1 -n 100

(포괄적인 벤치마킹 스크립트 및 구성에 대해서는 AWS Distributed Training Samples의 훌륭한 컬렉션 (https://github.com/aws-samples/awsome-distributed-training/tree/main/micro-benchmarks/nccl-tests) 을 참고해라.)

스크린샷 2025-12-04 오후 9.01.15.png

잠깐만… 우리는 480 GB/s를 달성하고 있는데, 이는 NVLink 4.0의 이론적 단방향 대역폭인 450 GB/s를 초과한다 😮 이것은 무슨 마법이며, 어떻게 가능할까?

문서를 조금 파헤쳐 보니, 답은 NVIDIA의 하드웨어 가속 집합 연산 기술인 **NVLink SHARP (NVLS)**에 있는 것 같다. 그것은 H100 GPU가 있는 단일 노드에서 allreduce 연산에 대해 약 1.3배의 속도 향상을 제공한다!

NVSwitch가 이러한 하드웨어 가속 집합 연산을 활성화하는 방법에 대한 기술적 세부 사항은 NVSwitch 아키텍처 프레젠테이션 (https://hc34.hotchips.org/assets/program/conference/day2/Network and Switches/NVSwitch HotChips 2022 r5.pdf) 을 참고해라.

그게 다른 곳에서도 도움이 될 수 있을까? alltoall 성능을 검토해보자:

$ ./all_to_all_perf -b 8 -e 16G -f 2 -g 1 -c 1 -n 100

스크린샷 2025-12-04 오후 9.03.02.png

우리는 alltoall 연산에 대해 340 GB/s를 달성하는데, 이는 NVLink 4.0을 사용하는 H100 시스템에 대한 유사한 성능 특성을 보여주는 공개된 벤치마크와 일치한다 (출처 https://juser.fz-juelich.de/record/1019178/files/02-NCCL_NVSHMEM.pdf#page=20.00). allreduce와 달리 alltoall 연산은 NVLS 하드웨어 가속의 이점을 얻지 못하며, 이는 allreduce로 달성한 480 GB/s과 달리 여기서는 340 GB/s라는 수치가 나타나는 이유를 설명한다. alltoall 패턴은 모든 GPU 쌍 간의 더 복잡한 지점 간 데이터 교환을 요구하며, NVSwitch의 집합 가속 기능보다는 순수한 NVLink의 기본 대역폭에 의존한다.

⚡ 고급 커널 최적화

일부 최적화된 커널은 전송을 처리하기 위해 전용 워프를 할당하여 계산과 NVLink 통신을 분리한다. 예를 들어, ThunderKittens는 특정 워프가 NVLink 전송을 발행하고 완료를 기다리는 동안 다른 워프는 계산 작업을 계속하는 워프 수준 설계를 사용한다. SM 계산과 NVLink 통신의 이 세분화된 중첩은 대부분의 GPU 간 통신 지연 시간을 숨길 수 있다. 구현 세부 사항은 다중 GPU 커널에 대한 ThunderKittens 블로그 게시물(https://hazyresearch.stanford.edu/blog/2025-09-22-pgl#fine-grained-overlap-of-sm-compute-and-nvlink-communication-with-thunderkittens) 을 참고해라.

NVLink가 단일 노드 내에서 탁월한 대역폭을 제공하지만, 프런티어 모델 학습은 여러 노드에 걸친 확장을 요구한다.

이것은 새로운 잠재적 병목 현상을 도입한다: NVLink보다 훨씬 낮은 대역폭에서 작동하는 노드 간 네트워크 상호 연결이다.

GPU 대 GPU 노드 간 (GPU-to-GPU Internode)

요약: 다중 노드 GPU 통신은 InfiniBand (400 Gbps) 또는 RoCE (100 Gbps)와 같은 고속 네트워크를 사용한다. Allreduce는 잘 확장되어 (노드 전반에 걸쳐 320-350 GB/s 안정적), 대규모 학습 클러스터를 가능하게 한다. Alltoall은 알고리즘 복잡성으로 인해 대역폭이 더 급격히 저하된다. 지연 시간은 노드 내 ~13μs에서 노드 간 55μs+로 점프한다. 빈번한 all-to-all 연산이 필요한 MoE 워크로드의 경우, NVSHMEM은 CPU 조율 전송보다 훨씬 더 나은 성능으로 비동기 GPU 시작 통신을 제공할 수 있따.

모델이 단일 노드가 수용할 수 있는 것 이상으로 확장됨에 따라, 학습은 고속 네트워크를 통해 연결된 여러 노드에 계산을 분산시켜야 한다. 벤치마크에 뛰어들기 전에, 다중 노드 GPU 클러스터에서 직면하게 될 3가지 주요 네트워킹 기술을 살펴본다:

**이더넷(Ethernet)**은 1 Gbps에서 100+ Gbps 속도로 진화했으며 HPC 및 데이터 센터 클러스터에서 널리 사용된다.
**RoCE (RDMA over Converged Ethernet)**는 이더넷 네트워크에 RDMA 기능을 가져오며, 전통적인 TCP 메커니즘 대신 혼잡 제어를 위해 ECN을 사용한다.
InfiniBand는 NVIDIA의 산업 표준 스위치 패브릭으로, 최대 400 Gbps 대역폭과 RDMA 지원을 통한 마이크로초 미만의 지연 시간을 제공하여 GPUDirect RDMA를 통해 호스트 CPU를 우회하면서 직접 GPU 대 GPU 메모리 액세스를 가능하게 한다.

요약하자면:

이름	이더넷 (25–100 Gbps)	이더넷 (200–400 Gbps)	RoCE	Infiniband
제조업체	다수	다수	다수	NVIDIA/Mellanox
단방향 대역폭 (Gbps)	25–100	200–400	100	400
종단 간 지연 시간 (μs)	10-30	N/A	~1	<1
RDMA	아니요	아니요	예	예

표: 상호 연결 비교. 출처: https://www.sciencedirect.com/science/article/pii/S2772485922000618

AWS p5 인스턴스의 경우 NIC (네트워크 인터페이스 카드)로 **Elastic Fabric Adapter (EFA)**를 사용하며, 여기서 각 GPU는 이전에 본 것처럼 PCIe Gen5 x16 레인을 통해 4개의 100 Gbps EFA 네트워크 카드에 연결된다.

스크린샷 2025-12-04 오후 9.07.12.png

Libfabric EFA를 통한 노드 간 GPU-대-GPU 통신 경로

위에 설명된 바와 같이, GPU와 네트워크 카드가 동일한 PCIe 스위치에 연결되면 GPUDirect RDMA를 통해 통신이 해당 스위치를 통해서만 발생할 수 있다. 이 설정을 통해 PCIe Gen5 x16 대역폭을 완전히 활용할 수 있으며 다른 PCIe 스위치나 CPU 메모리 버스를 포함하지 않는다. 이론적으로, 노드당 8개의 PCIe 스위치 x 스위치당 4개의 EFA NIC x 각 EFA NIC 100 Gbps는 3200 Gbps(400GB/s) 의 대역폭을 제공한다 (이는 AWS p5 사양에서 찾을 수 있는 대역폭이다). 그렇다면 실제로는 어떻게 유지되는가? 이전과 동일한 벤치마크를 실행하지만 다른 노드에 걸쳐 실행하여 알아보자!

Bandwidth Analysis

스크린샷 2025-12-04 오후 9.08.04.png

지점 간 send/receive 연산은 2-4개 노드에 대해 약 42-43 GB/s를 달성하지만 5개 이상의 노드에 대해서는 약 21 GB/s로 떨어진다. 이 성능 저하는 NCCL이 4개 이상의 노드로 확장할 때 피어당 지점 간 채널 수를 2개에서 1개로 자동으로 줄여 사용 가능한 대역폭 활용률을 효과적으로 절반으로 줄이기 때문에 발생한다. 이론적 최대치는 ~50 GB/s (4 EFA NIC × 12.5 GB/s 각)로 유지된다. 우리는 NCCL_NCHANNELS_PER_NET_PEER=2 를 설정하여 5개 이상의 노드에서 이 테스트에 대한 전체 처리량을 복원하는 데 성공했지만, 이 플래그는 예를 들어 all-to-all 성능을 저하시킬 수 있으므로 주의해서 사용해야 한다 (자세한 내용은 GitHub 이슈 #1272 https://github.com/NVIDIA/nccl/issues/1272 참조).

all-reduce 연산은 단일 노드 내에서 탁월한 성능을 보여주며 480 GB/s의 버스 대역폭을 달성한다. 2개 노드로 확장할 때 대역폭은 479 GB/s로 거의 동일하게 유지된 후, 3-16개 노드에 대해 약 320-350 GB/s로 안정화된다. 이 패턴은 중요한 특징을 드러낸다: NVLink에서 노드 간 네트워크 패브릭으로의 전환으로 인해 노드 경계를 넘을 때 초기 하락이 있지만, 그 후에는 더 많은 노드를 추가함에 따라 대역폭이 거의 일정하게 확장된다.

💡 노드 전반에 걸친 All-Reduce 확장

2개 노드를 넘어선 이 거의 일정한 확장 동작은 대규모 학습에 있어 실제로 꽤 고무적이다. 3-16개 노드에 걸쳐 비교적 안정적인 320-350 GB/s는 all-reduce 연산에 의존하는 병렬화 전략 (예를 들어, 데이터 병렬 처리에서)이 GPU당 상당한 대역폭 저하 없이 수백 또는 수천 개의 GPU로 확장될 수 있음을 시사한다. 이 로그 스케일링 특성은 8개의 GPU 각각이 별도의 스위치 레일에 연결되어 양분 대역폭(bisection bandwidth)을 최대화하는 잘 설계된 8-레일 최적화 팻 트리(fat tree)를 사용하는 다계층 네트워크 토폴로지의 전형이다. 현대 프런티어 학습 클러스터는 일상적으로 100,000개 이상의 GPU에서 작동하며, 이 안정적인 확장 동작이 그러한 대규모 Deployment 를 가능하게 만드는 것이다.

다른 대역폭 링크 (노드 내 NVLink 대 노드 간 네트워크)로 작업할 때, 사용 가능한 모든 대역폭을 완전히 활용하기 위해 각 대역폭 계층에 병렬화 전략을 조정하는 것을 고려해라. 이기종 네트워크 토폴로지에 대한 병렬화 구성 최적화에 대한 자세한 지침은 Ultrascale playbook을 참고해라.

all-to-all 연산은 더 극적인 확장 문제를 보여준다: 단일 노드에 대해 344 GB/s에서 시작하여, 2개 노드에서 81 GB/s로 떨어지고 더 큰 클러스터에 대해 약 45-58 GB/s로 계속 감소한다. 이 더 가파른 저하는 all-to-all 패턴의 집중적인 네트워크 요구를 반영하며, 여기서 각 GPU는 노드 전반에 걸쳐 다른 모든 GPU와 통신해야 하므로 all-reduce 연산보다 훨씬 더 많은 네트워크 혼잡을 생성한다.

지연 시간 (latency) 분석

스크린샷 2025-12-04 오후 9.11.04.png

지연 시간 측정은 노드 경계를 넘는 근본적인 비용을 드러낸다. Send/receive 연산은 모든 다중 노드 구성 전반에 걸쳐 40-53 μs의 비교적 안정적인 지연 시간을 유지하며, 지점 간 통신 지연 시간이 클러스터 크기보다는 주로 기본 네트워크 왕복 시간에 의해 결정됨을 보여주지만, 일부 변동은 네트워크 토폴로지 및 라우팅 효과가 여전히 역할을 함을 시사한다.

All-reduce 연산은 단일 노드 내에서 12.9 μs의 최소 지연 시간을 보여주지만, 2개 노드에 대해 55.5 μ

s로 점프하고 클러스터 크기에 따라 거의 선형적으로 계속 증가하여 16개 노드에서 235 μs에 도달한다. 이 흐름은 증가된 통신 거리와 더 많은 노드에 걸친 축소 트리(reduction tree)의 증가하는 복잡성을 모두 반영해 보여준다다.

All-to-all 연산은 유사한 추세를 보여주며, 단일 노드 통신에 대해 7.6 μs에서 시작하지만 2개 노드에서 60 μs로 올라가고 16개 노드에서 621 μs에 도달한다. all-to-all 연산에 대한 지연 시간의 초선형(superlinear) 성장은 더 많은 노드가 집합에 참여함에 따라 네트워크 혼잡 및 조정 오버헤드가 복합적으로 작용함을 보여준다.

🚀 최적화된 GPU 통신을 위한 NVSHMEM

전문가 라우팅을 위해 빈번한 all-to-all 통신 패턴을 필요로 하는 전문가 혼합(MoE) 아키텍처의 부상으로, 최적화된 GPU 통신 라이브러리가 점점 더 중요해지고 있다.

NVSHMEM(https://developer.nvidia.com/nvshmem) 은 여러 GPU의 메모리를 분할된 전역 주소 공간(PGAS)으로 결합하는 고성능 통신 라이브러리로 상당한 관심을 얻고 있다. CPU가 조율하는 데이터 전송에 의존하는 전통적인 MPI 기반 접근 방식과 달리, NVSHMEM은 CPU-GPU 동기화 오버헤드를 제거하는 비동기, GPU 시동 작업을 가능하게 한다.

NVSHMEM은 GPU 통신에 대한 몇 가지 주요 이점을 제공한다: GPUDirect Async와 같은 기술을 통해, GPU는 노드 간 통신을 발행할 때 CPU를 완전히 우회하여 작은 메시지 (<1 KiB)에 대해 최대 9.5배 더 높은 처리량을 달성할 수 있다. 이것은 집중적인 네트워크 통신 패턴을 필요로 하는 집합 연산에 특히 유익하다.

라이브러리는 현재 Mellanox 어댑터 (CX-4 이상)가 있는 InfiniBand/RoCE, Slingshot-11 (Libfabric CXI), 및 Amazon EFA (Libfabric EFA)를 지원한다. 세분화된 통신으로 강력한 확장을 요구하는 애플리케이션의 경우, NVSHMEM의 오버헤드가 낮은 단방향 통신 기본 요소는 전통적인 CPU 프록시 방법에 비해 성능을 크게 향상시킬 수 있다.

NVSHMEM 문서와 GPUDirect Async에 대한 이 자세한 블로그 게시물(https://developer.nvidia.com/blog/improving-network-performance-of-hpc-systems-using-nvidia-magnum-io-nvshmem-and-gpudirect-async/) 에서 자세한 내용을 알아볼 수 있다.

대역폭 측정이 기대에 미치지 못할 때, 여러 요인이 성능을 제한하는 원인일 수 있따. 이러한 잠재적 병목 현상을 이해하는 것은 최적의 상호 연결 활용을 달성하는 데 필수적이다.

상호 연결 문제 해결

예상보다 낮은 대역폭을 경험하고 있다면, 다음 영역을 체계적으로 확인해야 한다:

라이브러리 버전

오래된 NCCL, EFA, 또는 CUDA 라이브러리는 중요한 성능 최적화나 버그 수정이 누락될 수 있다. 항상 모든 통신 라이브러리의 최신 호환 버전을 실행하고 있는지 확인한다. 예: AWS는 하드웨어에 최적화된 라이브러리 버전으로 Deep Learning AMI를 정기적으로 업데이트한다. 또한 중요한 실험을 위해 이러한 라이브러리 버전을 기록하는 것이 좋다.

CPU 친화도 구성

부적절한 CPU 친화도 설정은 불필요한 NUMA 간 트래픽을 유발하여 NCCL 성능에 상당한 영향을 미칠 수 있다. 각 GPU는 메모리 액세스 지연 시간을 최소화하기 위해 동일한 NUMA 노드의 CPU에 바인딩되어야 한다. 실제에서, 이 Github 이슈(https://github.com/NVIDIA/nccl/issues/1017#issuecomment-1751385723)는 NCCL_IGNORE_CPU_AFFINITY=1 및 --cpu-bind none을 사용하는 것이 컨테이너 지연 시간을 크게 줄이는 데 어떻게 도움이 되었는지 보여준다. 자세한 내용은 여기(https://enterprise-support.nvidia.com/s/article/understanding-numa-node-for-performance-benchmarks#Mapping-between-PCI-device-driver-port-and-NUMA) 에서 읽을 수 있다.

네트워크 토폴로지 및 배치

네트워크 토폴로지를 이해하는 것은 성능 문제를 진단하는 데 중요하다. 클라우드 배치 그룹은 도움이 되지만 인스턴스 간 최소 네트워크 홉을 보장하지는 않는다. 현대 데이터 센터 팻 트리 토폴로지에서, 다른 최상위 스위치 아래에 배치된 인스턴스는 라우팅 경로의 추가 네트워크 홉으로 인해 더 높은 지연 시간과 잠재적으로 더 낮은 대역폭을 경험할 것이다.

AWS EC2 사용자의 경우, 인스턴스 토폴로지 API는 네트워크 노드 배치에 대한 귀중한 가시성을 제공한다. 맨 아래 계층 (인스턴스에 직접 연결됨)에서 동일한 네트워크 노드를 공유하는 인스턴스는 물리적으로 가장 가깝고 가장 낮은 지연 시간 통신을 달성할 것이다.

스크린샷 2025-12-04 오후 9.16.20.png

통신하는 노드 간의 네트워크 홉을 최소화하는 것은 더 나은 상호 연결 성능으로 곧바로 나타난다. 소규모 실험 및 제거 실험의 경우, 인스턴스가 동일한 네트워크 스위치에 공동 배치되도록 하는 것은 지연 시간과 대역폭 활용 모두에서 측정 가능한 차이를 만들 수 있다.

올바른 환경 변수

네트워크 어댑터에 대한 누락되거나 잘못된 환경 변수는 대역폭 활용을 심각하게 제한할 수 있다. NCCL과 같은 통신 라이브러리는 적응형 라우팅, GPU 시작 전송 및 적절한 버퍼 크기 조정과 같은 최적의 성능 기능을 활성화하기 위해 특정 구성 플래그에 의존한다.

예를 들어, AWS EFA (Elastic Fabric Adapter)를 사용할 때, 인스턴스 유형에 대해 권장되는 NCCL 및 EFA 환경 변수를 설정하고 있는지 확인해야 한다. AWS EFA 치트시트(https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/efa-cheatsheet.md)는 다양한 시나리오에 대한 최적의 플래그 구성에 대한 포괄적인 지침을 제공한다.

컨테이너별 고려 사항

컨테이너 (Docker/Enroot)를 사용할 때, 몇 가지 구성 단계가 최적의 NCCL 성능에 중요하다:

공유 및 고정 메모리: Docker 컨테이너는 기본적으로 제한된 공유 및 고정 메모리 리소스로 설정된다. 초기화 실패를 방지하기 위해 -shm-size=1g --ulimit memlock=-1로 컨테이너를 시작해라.
NUMA 지원: Docker는 기본적으로 NUMA 지원을 비활성화하는데, 이는 cuMem 호스트 할당이 올바르게 작동하지 못하게 할 수 있다. -cap-add SYS_NICE로 Docker를 호출하여 NUMA 지원을 활성화해라.
PCI 토폴로지 발견: NCCL이 GPU 및 네트워크 카드의 PCI 토폴로지를 발견할 수 있도록 /sys가 올바르게 마운트되었는지 확인해라. /sys가 가상 PCI 토폴로지를 노출하게 하면 차선의 성능이 발생할 수 있다.

🤗 커뮤니티 문제 해결

우리는 커뮤니티 노력으로 문제 해결 결과를 여기에 모으고 있습니다. 성능 문제에 직면했거나 효과적인 디버깅 방법을 발견했다면 토론 탭(https://huggingface.co/spaces/HuggingFaceTB/smol-training-playbook/discussions) 으로 이동하여 다른 사람들이 상호 연결 활용을 최적화하도록 돕기 위해 경험을 공유해주세요.

이제 GPU-CPU 및 GPU-GPU 통신에서 병목 현상을 디버깅하는 방법을 알았으므로 일반적으로 덜 주목받는 GPU 통신 부분, 즉 스토리지 계층과의 통신을 살펴보자!

GPU 대 스토리지 (GPU-to-Storage)

GPU와 스토리지 시스템 간의 연결은 종종 간과되지만 학습 효율성에 상당한 영향을 미칠 수 있다. 학습 중, GPU는 스토리지에서 지속적으로 데이터를 읽어야 하며 (데이터 로딩, 특히 대용량 이미지/비디오 파일이 있는 멀티모달 데이터의 경우) 주기적으로 모델 상태를 스토리지에 다시 써야 한다 (즉, 체크포인팅). 현대 대규모 학습 실행의 경우, 이러한 I/O 작업이 적절하게 최적화되지 않으면 병목 현상이 될 수 있다.

요약: GPU-스토리지 I/O는 데이터 로딩 및 체크포인팅을 통해 학습에 영향을 미친다. GPUDirect Storage (GDS)는 더 나은 성능을 위해 CPU를 우회하여 직접 GPU 대 스토리지 전송을 가능하게 한다. 우리 클러스터에서 GDS가 활성화되지 않았음에도 불구하고, 로컬 NVMe RAID (RAID 0의 8×3.5TB 드라이브)는 26.59 GiB/s 및 337K IOPS (네트워크 스토리지보다 6.3배 빠름)를 제공하여 체크포인트에 이상적이다.

스토리지 토폴로지 이해

GPU와 스토리지 장치 간의 물리적 연결은 GPU 상호 연결과 유사한 계층 구조를 따른다. 스토리지 장치는 PCIe 브리지를 통해 연결되며, 이 토폴로지를 이해하면 성능 특성과 잠재적 병목 현상을 설명하는 데 도움이 된다.

lstopo의 시스템 토폴로지를 보면, NVMe 드라이브가 시스템에 어떻게 연결되는지 알 수 있다. 우리 p5 인스턴스에는 GPU당 1개의 NVMe SSD가 있다:

PCIBridge L#13 (busid=0000:46:01.5 id=1d0f:0200 class=0604(PCIBridge) link=15.75GB/s buses=0000:[54-54] PCIVendor="Amazon.com, Inc.")
PCI L#11 (busid=0000:54:00.0 id=1d0f:cd01 class=0108(NVMExp) link=15.75GB/s PCISlot=87-1 PCIVendor="Amazon.com, Inc." PCIDevice="NVMe SSD Controller")
    Block(Disk) L#9 (Size=3710937500 SectorSize=512 LinuxDeviceID=259:2 Model="Amazon EC2 NVMe Instance Storage" Revision=0 SerialNumber=AWS110C9F44F9A530351) "nvme1n1"

자연스러운 질문은 GPU가 CPU를 포함하지 않고 NVMe 드라이브에 직접 액세스할 수 있는지 여부일 것이다. 대답은 **GPUDirect Storage (GDS)**를 통해 그렇다, 이다.

GPUDirect Storage는 스토리지 (로컬 NVMe 또는 원격 NVMe-oF)와 GPU 메모리 간의 직접 데이터 경로를 가능하게 하는 NVIDIA의 GPUDirect 기술 제품군의 일부이다. 스토리지 컨트롤러 근처의 DMA 엔진이 데이터를 GPU 메모리로 직접 이동시키거나 GPU 메모리에서 직접 이동시킬 수 있도록 함으로써 CPU 바운스 버퍼를 통한 불필요한 메모리 복사를 제거한다. 이는 CPU 오버헤드를 줄이고, 지연 시간을 줄이며, 대규모 멀티모달 데이터셋에 대한 학습과 같은 데이터 집약적 워크로드에 대한 I/O 성능을 크게 향상시킨다.

GPUDirect Storage가 시스템에 올바르게 구성되어 있는지 확인하려면, GDS 구성 파일을 확인하고 제공된 진단 도구를 사용할 수 있다:

$ /usr/local/cuda/gds/tools/gdscheck.py -p
 =====================
 DRIVER CONFIGURATION:
 =====================
 NVMe               : Supported
 NVMeOF             : Unsupported
 SCSI               : Unsupported
 ScaleFlux CSD      : Unsupported
 NVMesh             : Unsupported
 DDN EXAScaler      : Unsupported
 IBM Spectrum Scale : Unsupported
 NFS                : Unsupported
 BeeGFS             : Unsupported
 WekaFS             : Unsupported
 Userspace RDMA     : Unsupported
 --Mellanox PeerDirect : Enabled
 --rdma library        : Not Loaded (libcufile_rdma.so)
 --rdma devices        : Not configured
 --rdma_device_status  : Up: 0 Down: 0
 =====================

NVMe: Supported 를 통해 GDS가 현재 NVMe 드라이브에 대해 작동하도록 구성되어 있음을 알 수 있으며, Unsupported 플래그에서 알 수 있듯이 다른 모든 스토리지 유형은 올바르게 구성되지 않았다. GDS가 스토리지 유형에 대해 올바르게 구성되지 않은 경우, /etc/cufile.json에서 구성 파일을 수정하는 지침에 대해 NVIDIA GPUDirect Storage 구성 가이드(https://docs.nvidia.com/gpudirect-storage/configuration-guide/index.html) 를 참고해라.

블록 스토리지 장치

시스템에서 사용 가능한 스토리지 장치를 이해하기 위해, lsblk를 사용하여 블록 장치 계층 구조를 표시할 수 있다:

$ lsblk --fs -M
    NAME        FSTYPE            LABEL                   UUID                                 FSAVAIL FSUSE% MOUNTPOINT
...
    nvme0n1
    └─nvme0n1p1 ext4              cloudimg-rootfs         24ec7991-cb5c-4fab-99e5-52c45690ba30  189.7G    35% /
┌┈▶ nvme1n1     linux_raid_member ip-26-0-164-236:MY_RAID d0795631-71f0-37e5-133b-e748befec126
├┈▶ nvme2n1     linux_raid_member ip-26-0-164-236:MY_RAID d0795631-71f0-37e5-133b-e748befec126
├┈▶ nvme3n1     linux_raid_member ip-26-0-164-236:MY_RAID d0795631-71f0-37e5-133b-e748befec126
├┈▶ nvme8n1     linux_raid_member ip-26-0-164-236:MY_RAID d0795631-71f0-37e5-133b-e748befec126
├┈▶ nvme5n1     linux_raid_member ip-26-0-164-236:MY_RAID d0795631-71f0-37e5-133b-e748befec126
├┈▶ nvme4n1     linux_raid_member ip-26-0-164-236:MY_RAID d0795631-71f0-37e5-133b-e748befec126
├┈▶ nvme6n1     linux_raid_member ip-26-0-164-236:MY_RAID d0795631-71f0-37e5-133b-e748befec126
└┬▶ nvme7n1     linux_raid_member ip-26-0-164-236:MY_RAID d0795631-71f0-37e5-133b-e748befec126
 └┈┈md0         xfs                                       dddb6849-e5b5-4828-9034-96da65da27f0   27.5T     1% /scratch

이 출력은 시스템의 블록 장치 계층 구조를 보여준다. 주요 관찰 사항:

nvme0n1p1은 전체 ~300GB 용량의 35%를 사용하는 /에 마운트된 루트 Amazon EBS 파일 시스템이다.
8개의 NVMe 드라이브 (nvme1n1부터 nvme8n1)가 MY_RAID라는 이름의 RAID 어레이로 구성되어 있다.
RAID 어레이는 /dev/md0으로 노출되고, XFS로 포맷되었으며, 28TB (8x3.5TB) 사용 가능 공간으로 /scratch에 마운트된다.
화살표 (┈▶)는 여러 NVMe 장치가 동일한 RAID 어레이의 구성원이며, 단일 md0 장치로 결합됨을 나타낸다.

(Amazon Elastic Block Store (EBS)는 Amazon EC2 인스턴스와 함께 사용하도록 설계된 고성능, 확장 가능한 블록 스토리지 서비스이다.)

네트워크 스토리지

로컬 NVMe 스토리지 외에도, 시스템은 네트워크 연결 스토리지 시스템에 액세스할 수 있다:

$ df -h
Filesystem                                         Size  Used Avail Use% Mounted on
/dev/root                                          291G  101G  190G  35% /
weka-hopper.hpc.internal.huggingface.tech/default  393T  263T  131T  67% /fsx
10.53.83.155@tcp:/fg7ntbev                         4.5T  2.9T  1.7T  63% /admin
/dev/md0                                            28T  206G   28T   1% /scratch

이 출력은 다음을 보여준다:

/dev/root (291GB Amazon EBS)는 35% 용량의 루트 파일 시스템이다.
/fsx (393TB WekaFS)는 131TB 사용 가능 공간으로 67% 차 있다.
/admin (4.5TB FSx Lustre)는 1.7TB 사용 가능 공간으로 63% 차 있다.
/dev/md0 (28TB 로컬 NVMe RAID)는 /scratch에서 28TB 사용 가능 공간으로 단 1% 차 있다. 이것은 RAID에 있는 우리의 8×3.5TB SSD NVMe 인스턴스 스토어 드라이브이다.

(참고: /fsx는 실제로 Amazon FSx가 아니라 WekaFS이다. 우리는 FSx에서 WekaFS로 마이그레이션할 때 편의를 위해 동일한 마운트 포인트 이름을 유지했다.)

로컬 NVMe RAID 어레이 (/scratch)는 가장 빠른 I/O 성능을 제공하는 반면, 네트워크 파일 시스템은 공유 데이터 스토리지를 위한 더 큰 용량을 제공한다.

💾 스토리지 기술의 종류

RAID (Redundant Array of Independent Disks): 데이터 스트라이핑, 패리티, 또는 미러링을 통해 성능 및/또는 신뢰성을 향상시키기 위해 여러 드라이브를 결합한다.

NVMe (Non-Volatile Memory Express): PCIe에 직접 연결되는 SSD용 고성능 스토리지 프로토콜로, SATA/SAS보다 높은 처리량과 낮은 지연 시간을 제공한다.

WekaFS: AI/ML 워크로드를 위해 설계된 고성능 병렬 파일 시스템으로, 여러 노드에 걸쳐 저지연 액세스와 높은 처리량을 제공한다.

FSx Lustre: 병렬 액세스를 가능하게 하기 위해 메타데이터와 데이터 서비스를 다른 서버에 분리하는 HPC용으로 설계된 병렬 파일 시스템이다. 대용량 파일에 효과적이지만, 많은 작은 파일을 포함하는 메타데이터 집약적 AI/ML 워크로드에서는 어려움을 겪을 수 있다.

스토리지 대역폭 벤치마킹

각 스토리지 시스템의 성능 특성을 이해하기 위해, GPUDirect Storage (GDS)를 사용하여 읽기/쓰기 속도를 벤치마킹할 수 있다. 다음은 다양한 구성을 테스트하는 포괄적인 매개변수 벤치마크 스크립트이다:

gdsio -f /<disk_path>/gds_test.dat -d 0 -w <n_threads> -s 10G -i <io_size> -x 1 -I 1 -T 10

벤치마크는 처리량, 지연 시간, IOPS뿐만 아니라 다음 항목들에 걸쳐 스토리지 시스템 성능을 평가한다:

확장성: 다른 스레드 수와 I/O 크기에 따라 성능이 어떻게 변하는지. 이는 다양한 워크로드 패턴에 대한 최적의 구성을 보여준다:

작은 I/O 크기 (64K ~ 256K)는 일반적으로 IOPS를 최대화하지만 대역폭을 포화시키지 못할 수 있다.
큰 I/O 크기 (2M ~ 8M)는 일반적으로 처리량을 최대화하지만 IOPS를 줄인다.
스레드 수는 둘 다에 영향을 미친다: 더 많은 스레드는 하드웨어 한계까지 총 IOPS와 처리량을 증가시킬 수 있다.

전송 방법 효율성: GPU_DIRECT 대 CPU_GPU 대 CPUONLY를 비교하면 CPU 메모리를 우회하는 것의 이점을 보여준다:

GPU_DIRECT: RDMA를 사용하여 데이터를 GPU 메모리로 직접 전송하여 CPU를 완전히 우회한다 (가장 낮은 지연 시간, 가장 높은 효율성, 작은 작업에 대한 최고의 IOPS).
CPU_GPU: 데이터가 먼저 CPU 메모리로 이동한 다음 GPU로 복사되는 전통적인 경로 (CPU 오버헤드 및 메모리 대역폭 경합 추가, 유효 IOPS 감소).
CPUONLY: GPU 개입 없는 기본 CPU 전용 I/O.

📊 IOPS (I/O Operations Per Second)

IOPS는 초당 완료된 개별 I/O 작업의 수이다. gdsio 출력에서 ops / total_time으로 계산된다. IOPS는 다음에 특히 중요하다:

작은 I/O 크기를 가진 랜덤 액세스 패턴
많은 작은 파일이나 흩어진 데이터 액세스가 있는 워크로드
원시 대역폭보다 작업당 지연 시간이 더 중요한 데이터베이스 유사 작업
더 높은 IOPS는 동시, 세분화된 데이터 액세스를 처리하는 더 나은 능력을 나타낸다.

스크린샷 2025-12-05 오후 5.06.52.png

스크린샷 2025-12-05 오후 5.07.57.png

스크린샷 2025-12-05 오후 5.08.15.png

스크린샷 2025-12-05 오후 5.08.06.png

스크린샷 2025-12-05 오후 5.07.34.png

스크린샷 2025-12-05 오후 5.07.23.png

벤치마크는 4개의 스토리지 시스템 전반에 걸친 극적인 성능 차이를 드러낸다:

**/scratch (로컬 NVMe RAID)**는 26.59 GiB/s 처리량 및 337K IOPS로 지배적이며, FSx보다 처리량은 6.3배 빠르고 IOPS는 6.6배 더 좋다. 8×3.5TB NVMe 드라이브의 이 로컬 RAID 어레이는 가장 낮은 지연 시간 (피크 IOPS에서 190μs)을 제공하며 스레드 수에 따라 매우 잘 확장되어, 처리량의 경우 1M I/O 크기, 64 스레드에서 피크 성능을 달성한다.

**/fsx (WekaFS)**는 4.21 GiB/s 및 51K IOPS의 견고한 네트워크 스토리지 성능을 제공하여, 합리적인 성능이 필요한 공유 데이터에 가장 적합한 선택이다. FSx는 CPUONLY 전송을 사용하여 최고의 처리량(4.21 GiB/s)을 달성하는 반면, 최고의 IOPS(51K)는 GPUD 전송 유형을 사용한다.

/admin (FSx Lustre) 및 /root (EBS) 파일 시스템은 약 1.1 GiB/s 처리량의 유사한 적당한 성능을 보이지만 IOPS 기능에서 크게 다르다. Admin은 GPUD 전송으로 피크 처리량(1.13 GiB/s)을 달성하고 CPU_GPU 전송으로 17K IOPS에서 피크를 찍어(Root보다 24배 더 좋음), 많은 작은 작업을 포함하는 워크로드에 더 적합하다. Root의 열악한 IOPS 성능(730)은 대규모 순차 작업에만 가장 적합함을 확인시켜 준다.

GPU_DIRECT 결과에 대한 참고 사항: GPUDirect Storage (GDS)는 현재 우리 클러스터에서 활성화되지 않았으므로, NVMe 스토리지 (Scratch 및 Root)에 대한 GPUD 결과가 CPUONLY 전송에 비해 저조한 성능을 보이는 이유를 설명한다. GDS가 올바르게 구성되면, 특히 고성능 NVMe 어레이에 대해 직접 GPU 대 스토리지 전송에 대해 GPUD가 상당한 이점을 보일 것으로 예상한다.

최적의 구성 패턴: 모든 스토리지 유형에 걸쳐, 최대 처리량은 1M I/O 크기에서 발생하는 반면, 최대 IOPS는 테스트된 가장 작은 크기 (64K)에서 발생한다. 이 고전적인 트레이드오프는 워크로드 특성에 따라 원시 대역폭(큰 I/O)과 작업 동시성(작은 I/O) 중에서 선택하는 것을 의미한다. 대용량 체크포인트 파일이 있는 ML 학습의 경우, Scratch의 1M-8M 범위가 최적의 성능을 제공한다.

요약

여기까지 왔다면 축하한다! 이제 스토리지 계층 구조와 학습 인프라에서 서로 다른 구성 요소가 상호 작용하는 방식에 대한 포괄적인 이해를 갖게 되었다. 하지만 당신이 이 파트로부터 얻어가길 바라는 핵심 통찰력은 이것이다: 병목 현상을 식별해내는 것이 이론적 지식과 실용적 최적화가 구분되는 지점이다.

이 가이드 전반에 걸쳐, 우리는 스택의 모든 수준에서 실제 대역폭을 측정했다: 단일 GPU 내 HBM3의 3TB/s, 노드 내 GPU 간 NVLink의 786 GB/s, CPU-GPU 전송을 위한 PCIe Gen4 x8의 14.2 GB/s, 지점 간 통신을 위한 노드 간 네트워크의 42 GB/s, 그리고 26.59 GB/s (로컬 NVMe)에서 1.1 GB/s (공유 파일 시스템)에 이르는 스토리지 시스템이다. 이러한 측정은 학습 파이프라인이 어디서 느려질지 드러내며 높은 모델 FLOPs 활용률(MFU)을 달성하는 데 필수적이다.

그러나 원시 대역폭 수치만으로는 전체 이야기를 알 수 없다. 현대 학습 시스템은 계산과 통신을 중첩시켜 통신 비용을 계산 작업 뒤에 효과적으로 숨길 수 있다. 이 병렬화는 상호 연결이 느릴 때에도 병목 현상을 완화하는 데 도움이 된다. 처리량을 최대화하기 위해 계산과 통신을 중첩하는 자세한 전략은 Ultra-Scale Playbook을 참조한다.

아래 다이어그램은 벤치마킹된 모든 측정값을 단일 뷰로 종합하여 GPU에서 멀어질수록 대역폭이 극적으로 감소하는 것을 보여준다:

스크린샷 2025-12-04 오후 9.28.46.png

이제 하드웨어 및 소프트웨어 설정에서 병목 현상을 식별하는 방법을 알았으므로, 한 단계 더 나아가 몇 달 동안 안정적으로 실행할 수 있는 탄력적인 시스템을 확보하는 방법을 살펴보자.

탄력적인 학습 시스템 구축

빠른 하드웨어를 갖는 것은 LLM 학습을 위한 좋고 안정적인 인프라를 갖기 위한 입장권일 뿐이다. 학습 아마추어에서 프로로 가려면, 우리는 raw 한 수준의 속도를 넘어 전체 학습 경험을 더 원활하게 만들고 다운타임을 최소화하는 덜 화려하지만 중요한 인프라 조각들에 집중해야 한다.

이 섹션에서 우리는 하드웨어 및 소프트웨어 최적화에서 **프로덕션 준비 상태(production readiness)**로 넘어가려 한다: 불가피한 장애에서 살아남을 만큼 충분히 견고하고, 지속적인 관리 없이 실행될 만큼 충분히 자동화되었으며, 문제가 발생할 때 적응할 만큼 충분히 유연한 시스템을 구축하는 것이다.

노드 상태 모니터링 및 교체

충분히 빠른 GPU를 갖는 것은 학습에 중요하지만, LLM 학습은 며칠이 아니라 몇 주 또는 몇 달 동안 실행되므로 시간 경과에 따른 GPU 상태 추적이 중요하다. 초기 벤치마크를 통과한 GPU도 장기간의 학습 실행 중에 열 스로틀링, 메모리 오류, 또는 성능 저하를 겪을 수 있다. 이 섹션에서는 우리가 이 문제에 접근하는 방법과 사용하는 도구를 공유할 것이다.

사전 테스트: SmolLM3를 시작하기 전에, 우리는 여러 도구를 사용하여 포괄적인 GPU 진단을 실행했다. 우리는 열 스로틀링, 메모리 오류, 및 성능 이상 징후에 대해 GPU를 스트레스 테스트하는 내부 도구인 GPU Fryer를 사용했다. 우리는 또한 GPU 하드웨어를 검증하고, 성능을 모니터링하며, 컴퓨팅, PCIe 연결성, 메모리 무결성, 및 열 안정성을 다루는 심층 진단 테스트를 통해 장애나 전력 이상의 근본 원인을 식별하는 널리 사용되는 도구인 NVIDIA의 DCGM 진단을 실행했다. 이러한 사전 테스트는 학습 중 문제를 일으켰을 두 개의 문제가 있는 GPU를 잡아냈다.

다음 표에서 DCGM 진단 도구로 테스트할 수 있는 내용을 볼 수 있다:

테스트 수준	기간	소프트웨어	PCIe + NVLink	GPU 메모리	메모리 대역폭	진단	목표 스트레스	목표 전력	NVBandwidth	메모리 스트레스	입력 EDPp
r1 (짧음)	초	✓	✓	✓
r2 (중간)	< 2분	✓	✓	✓	✓	✓
r3 (김)	< 30분	✓	✓	✓	✓	✓	✓	✓	✓
r4 (아주 김)	1-2시간	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓

DCGM 진단 실행 수준. 출처: NVIDIA DCGM 문서

$ dcgmi diag -r 2 -v -d VERB
Successfully ran diagnostic for group.
+---------------------------+------------------------------------------------+
| Diagnostic | Result |
+===========================+================================================+
| -----  Metadata  ----------+------------------------------------------------ |
| DCGM Version | 3.3.1 |
| Driver Version Detected | 575.57.08 |
| GPU Device IDs Detected | 2330,2330,2330,2330,2330,2330,2330,2330 |
| -----  Deployment  --------+------------------------------------------------ |
| Denylist | Pass |
| NVML Library | Pass |
| CUDA Main Library | Pass |
| Permissions and OS Blocks | Pass |
| Persistence Mode | Pass |
| Environment Variables | Pass |
| Page Retirement/Row Remap | Pass |
| Graphics Processes | Pass |
| Inforom | Pass |

+-----  Integration  -------+------------------------------------------------+
| PCIe | Pass - All |
| Info | GPU 0 GPU to Host bandwidth:  14.26 GB/s, GPU |
| 0 Host to GPU bandwidth:  8.66 GB/s, GPU 0 b |
| idirectional bandwidth: 10.91 GB/s, GPU 0 GPU |
| to Host latency:  2.085 us, GPU 0 Host to GP |
| U latency:  2.484 us, GPU 0 bidirectional lat |
| ency:  3.813 us |

...
+-----  Hardware  ----------+------------------------------------------------+
| GPU Memory | Pass - All |
| Info | GPU 0 Allocated 83892938283 bytes (98.4%) |
| Info | GPU 1 Allocated 83892938283 bytes (98.4%) |
| Info | GPU 2 Allocated 83892938283 bytes (98.4%) |
| Info | GPU 3 Allocated 83892938283 bytes (98.4%) |
| Info | GPU 4 Allocated 83892938283 bytes (98.4%) |
| Info | GPU 5 Allocated 83892938283 bytes (98.4%) |
| Info | GPU 6 Allocated 83892938283 bytes (98.4%) |
| Info | GPU 7 Allocated 83892938283 bytes (98.4%) |

+-----  Stress  ------------+------------------------------------------------+

노드 예약: SmolLM3는 Slurm 관리 클러스터에서 학습되었으므로, 우리는 전체 실행을 위해 고정된 48개 노드 예약을 예약했다. 이 설정은 시간 경과에 따른 정확히 동일한 노드의 상태와 성능을 추적할 수 있게 해주었으며, 우리가 논의한 데이터 스토리지 문제를 해결하는 데에도 필요했다. 우리는 또한 예비 노드 (자동차의 스페어 타이어처럼)를 확보하여 하나가 실패하면 수리를 기다리지 않고 즉시 교체할 수 있도록 했다. 유휴 상태일 때, 예비 노드는 평가 작업이나 개발 실험을 실행했다.

지속적인 모니터링: 학습 중, 우리는 모든 노드에서 GPU 온도, 메모리 사용량, 컴퓨팅 활용률 및 처리량 변동과 같은 주요 지표를 추적했다. 우리는 Prometheus를 사용하여 모든 GPU에서 DCGM 지표를 수집하고 실시간 모니터링을 위해 Grafana 대시보드에 시각화했다. AWS 인프라에서 GPU 모니터링을 위해 Prometheus와 Grafana를 배포하는 자세한 설정 지침은 이 예시 설정 가이드(https://github.com/aws-samples/awsome-distributed-training/tree/3ae961d022399021cc4053c3ba19b182ca6b8dc8/4.validation_and_observability/4.prometheus-grafana) 를 참고해라. Slack 봇은 노드가 의심스러운 동작을 보일 때 우리에게 경고하여 전체 학습 실행을 중단시키기 전에 사전에 고장 난 하드웨어를 교체할 수 있게 했다.

이 다층 접근 방식은 하드웨어 문제가 관리 가능한 중단이 되도록 했다.

열 현실 점검: GPU가 느려질 때

마케팅 사양은 완벽한 냉각을 가정하지만 현실은 더 지저분하다. GPU는 과열될 때 자동으로 클럭 속도를 줄여 잘 설계된 시스템에서도 이론적 최대치 미만으로 성능을 떨어뜨린다.

이 Grafana 대시보드는 우리 GPU 클러스터 전반의 열 스로틀링 이벤트를 보여준다. 아래 패널의 막대는 과열로 인해 GPU가 자동으로 클럭 속도를 줄인 때를 나타낸다.

우리는 NVIDIA의 DCGM에서 DCGM_FI_DEV_CLOCK_THROTTLE_REASONS 지표를 모니터링하여 열 스로틀링을 감지한다. 이 지표가 0이 아닌 값을 보이면, GPU는 과열로 인해 자동으로 클럭 속도를 줄이고 있는 것이다. 위의 대시보드는 이러한 스로틀링 이벤트가 실제로 어떻게 나타나는지 보여준다.

열 스로틀링은 영향을 받는 GPU만 해치는 것이 아니다; 전체 분산 학습 설정에 파급 효과를 미친다. 테스트 중, 우리는 단일 스로틀링 노드가 집합 통신 성능에 얼마나 극적인 영향을 미칠 수 있는지 관찰했다.

스크린샷 2025-12-04 오후 9.33.50.png

스트레스 테스트 중 노드 전반의 AllReduce 대역폭 저하. 14개 노드 이후의 급격한 하락 (350 GB/s에서 100 GB/s로)은 단일 열 스로틀링 GPU에 의해 발생했으며, 하나의 느린 노드가 전체 분산 학습 파이프라인을 병목 현상에 빠뜨릴 수 있음을 보여준다.

위의 차트는 1에서 16개 노드로 확장함에 따라 AllReduce 대역폭이 저하되는 것을 보여준다. 14개 노드 이후 350 GB/s에서 100 GB/s로 급격히 떨어지는 것에 주목해라 (이전에는 대역폭이 300GB/s 이상 유지될 것으로 예상했다). 이것은 네트워크 문제가 아니었다: 열 스로틀링이 있는 단일 노드가 병목 현상이 되어 기울기 동기화 중에 다른 모든 노드가 기다리게 만들었다. 분산 학습에서, 여러분은 가장 느린 노드만큼만 빠르다.

👉 핵심 교훈: 긴 학습 실행에 전념하기 전에, 앞서 언급한 도구를 사용하여 하드웨어를 스트레스 테스트하여 열 및 전력 제한을 식별한다. DCGM 원격 측정을 사용하여 온도를 지속적으로 모니터링하고 실제 열 제한을 계획한다. GPU 클럭이 최대 성능으로 설정되었는지 확인하는 것도 좋은 관행이다. 전력 제약으로 인해 GPU가 광고된 성능을 유지할 수 없는 이유에 대한 더 깊은 내용은 전력 스로틀링에 대한 이 훌륭한 분석(https://www.thonking.ai/p/strangely-matrix-multiplications)을 참고해라.

체크포인트 관리

체크포인트는 긴 학습 실행 중 우리의 안전망이다. 우리는 세 가지 실용적인 이유로 이를 정기적으로 저장했다: 장애로부터의 복구, 평가를 통한 학습 진행 모니터링, 그리고 연구를 위해 중간 모델을 커뮤니티와 공유하는 것이다. 복구 측면이 가장 중요하다. 실행이 실패하면, 즉시 재개할 경우 최대 저장 간격만큼만 잃도록 최신 저장된 체크포인트에서 다시 시작하기를 우리는 원한다 (예: 4시간마다 저장하는 경우 4시간의 학습).

💡 재개 프로세스 자동화

재개 프로세스를 자동화하려고 노력해라. 예를 들어 Slurm에서는 SBATCH --requeue를 사용하여 작업이 최신 체크포인트에서 자동으로 다시 시작되도록 할 수 있다. 이렇게 하면 누군가 실패를 알아차리고 수동으로 다시 시작하기를 기다리는 시간을 낭비하는 것을 피할 수 있다.

재개 메커니즘을 구현할 때 명심해야 할 두 가지 중요한 세부 사항이 있다:

체크포인트 저장은 학습 처리량에 영향을 주지 않으면서 백그라운드에서 이루어져야 한다.
스토리지를 주시한다. 24일 실행 동안 4시간마다 저장하면 ~144개의 체크포인트가 된다. 대규모 모델과 옵티마이저 상태의 경우, 이것은 빠르게 늘어난다. 우리의 경우, 한 번에 하나의 로컬 체크포인트 (최신 저장된 것)만 저장하고 나머지는 클러스터 스토리지를 채우지 않도록 S3로 오프로드했다.

과거의 고통스러운 교훈:

우리의 첫 번째 대규모 실행 (StarCoder 15B) 동안, 학습은 여러 번의 재시작을 통해 순조롭게 진행되었다. 마지막 날, 우리는 이전 처리량 테스트 스크립트의 맨 끝에 남아 있던 rm -rf $CHECKPOINT_PATH 명령에 의해 전체 체크포인트 폴더가 삭제된 것을 발견했다. 이 파괴적인 명령은 Slurm 작업이 실제로 완료되었을 때만 트리거되었는데, 이전 재시작에서는 발생하지 않았다.

다행히도, 전날의 체크포인트가 저장되어 있어서 하루치 재학습 비용만 들었다. 교훈은 명확했다: 프로덕션 스크립트에 파괴적인 명령을 남겨두지 말고, 수동 개입에 의존하기보다 저장 직후 체크포인트 백업을 자동화해라.

우리의 nanotron 학습에서는 로컬에 2시간마다 체크포인트를 저장하고, 즉시 각 체크포인트를 S3에 업로드한 다음, 백업이 확인되면 로컬 복사본을 삭제한다. 재개 시, 최신 체크포인트를 로컬에서 사용할 수 없는 경우 S3에서 가져온다. 이 접근 방식은 스토리지를 절약하고, 백업을 보장하며, 빠른 복구를 가능하게 한다.

자동화된 평가

평가를 수동으로 실행하는 것은 빠르게 병목 현상이 된다. 반복해서 수행하기 전까지는 간단해 보인다. 모든 실행에 대해 벤치마크를 실행하고, 결과를 추적하고 플롯하는 것은 상당한 오버헤드가 된다. 해결책은? 처음부터 모든 것을 자동화하는 것이다.

SmolLM3의 경우, 우리는 LightEval을 사용하여 nanotron 체크포인트에서 평가를 실행했다. 저장된 모든 체크포인트는 클러스터에서 평가 작업을 트리거한다. 결과는 Weights & Biases 또는 Trackio로 직접 푸시되므로, 우리는 대시보드를 열고 곡선이 진화하는 것을 지켜보기만 하면 되었다. 이것은 우리에게 막대한 시간을 절약해 주었고 실행 내내 평가 추적을 일관되게 유지했다.

학습 설정에서 단 하나만 자동화할 수 있다면, 평가를 자동화해라.

마지막으로, 처리량을 극대화하기 위해 학습 레이아웃, 즉 모델이 사용 가능한 GPU 전체에 어떻게 분산되는지 최적화하는 방법을 살펴보자.

학습 처리량 최적화

얼마나 많은 GPU가 필요한가?

좋은 질문이다! 사양과 벤치마크에 대한 모든 이야기 후에, 여전히 실용적인 질문을 해결해야 한다: 실제로 얼마나 많은 GPU를 빌리거나 사야 하는가?

기본 크기 조정 공식:

\text{GPU 수} = \frac{\text{필요한 총 FLOPs}}{\text{GPU당 처리량} \times \text{목표 학습 시간}}

이 공식은 문제를 세 가지 주요 구성 요소로 나눈다:

필요한 총 FLOPs: 모델을 학습시키는 데 필요한 계산 작업 (모델 크기, 학습 토큰, 아키텍처에 따라 다름)
GPU당 처리량: 각 GPU가 실제로 제공할 수 있는 초당 FLOPs 수 (이론적 피크가 아니다!)
목표 학습 시간: 학습이 완료될 때까지 기다릴 의향이 있는 기간

핵심적인 인사이트: 피크 사양이 아니라 현실적인 처리량을 추정해야 한다. 이는 모델 FLOPs 활용률(MFU)을 고려하는 것을 의미한다: 실제로 달성하는 것은 이론적 피크 성능의 일부분이다.

SmolLM3의 경우, 계산은 다음과 같았다:

모델 크기: 30억 매개변수
학습 토큰: 11조 토큰
예상 MFU: 30% (유사한 규모의 실험을 기반으로 함)

먼저, 표준 트랜스포머 근사치인 토큰당 6N FLOPs (여기서 N = 매개변수)를 사용하여 필요한 총 FLOPs를 계산했다:

\text{총 FLOPs} = 6 \times 3 \times 10^9 \text{ 매개변수} \times 11 \times 10^{12} \text{ 토큰} = 1.98 \times 10^{23} \text{ FLOPs}

예상 MFU 30%를 사용하여 유효 GPU당 처리량은 다음과 같다:

\text{유효 처리량} = 720 \times 10^{12} \text{ FLOPs/sec} \times 0.30 = 216 \times 10^{12} \text{ FLOPs/sec}

이제 크기 조정 공식에 대입한다:

\text{GPU 수} = \frac{1.98 \times 10^{23} \text{ FLOPs}}{216 \times 10^{12} \text{ FLOPs/sec} \times 4 \text{ 주} \times 604{,}800 \text{ 초/주}}

= \frac{1.98 \times 10^{23}}{5.23 \times 10^{20}} \approx 379 \text{ GPU}

이 계산은 우리에게 375-400개의 H100을 가리켰고, 우리는 384개의 H100을 확보했다. 이는 우리의 병렬화 전략과 잘 일치하고 노드 장애 및 재시작과 같은 예상치 못한 문제에 대한 약간의 버퍼와 함께 현실적인 4주 타임라인을 제공한 숫자였다.

왜 더 많은 GPU가 항상 더 나은 것은 아닌가: 암달의 법칙 작용

여기 직관에 반하는 진실이 있다: 더 많은 GPU를 추가하면 실제로 학습이 느려질 수 있다. 암달의 법칙(Amdahl’s Law, https://en.wikipedia.org/wiki/Amdahl%27s_law)이 작용하게 되기 때문이다.

암달의 법칙은 병렬화로 인한 속도 향상이 근본적으로 워크로드의 직렬 (병렬화할 수 없는) 부분에 의해 제한된다고 명시한다. LLM 학습에서, 이 “직렬” 부분은 주로 통신 오버헤드이다: 병렬화될 수 없는 GPU 간의 기울기/가중치/활성화 동기화에 소비되는 시간이다 (여기(https://acenet-arc.github.io/ACENET_Summer_School_General/05-performance/index.html)서 자세히 알아볼 수 있다).

공식은 다음과 같다:

\text{최대 속도 향상} = \frac{1}{\text{직렬 비율} + \frac{\text{병렬 비율}}{\text{프로세서 수}}}

스크린샷 2025-12-04 오후 9.45.11.png

SmolLM3의 30억 모델의 경우, 통신이 각 학습 단계의 10%를 차지한다면, 아무리 많은 GPU를 추가하더라도 10배 이상의 속도 향상을 절대 얻을 수 없다. 더 나쁜 것은, GPU를 추가함에 따라 통신 비율이 종종 증가한다는 것이다. 왜냐하면:

더 많은 GPU = 더 많은 AllReduce 참가자 = 더 긴 동기화
네트워크 지연 시간/대역폭이 병목 현상이 됨
소형 모델은 계산 뒤에 통신을 숨길 수 없음

SmolLM3의 경우, 우리는 약한 확장(weak scaling) 원칙을 사용했다: 전역 배치 크기는 GPU 수에 따라 확장되어 전역적으로 GPU당 대략 8K 토큰을 유지했다. 이것은 처리량을 극대화하면서 통신 대 계산 비율을 합리적으로 유지했다.

최적의 병렬화 구성 찾기

GPU를 확보했다면, 다음 과제는 실제로 효율적으로 학습하도록 구성하는 것이다. 이를 위해 병렬화 전략이 중요해진다.

우리는 최적의 학습 구성을 찾기 위해 Ultra-Scale Playbook의 접근 방식을 따른다. 플레이북은 문제를 세 가지 순차적 단계로 나눈다: 먼저 모델이 메모리에 맞는지 확인하고, 목표 배치 크기를 달성한 다음, 마지막으로 최대 처리량을 위해 최적화한다. SmolLM3에 이것을 어떻게 적용했는지 살펴보자.

(다양한 병렬화 전략 (데이터 병렬화, 텐서 병렬화, 파이프라인 병렬화, ZeRO 등)에 대한 자세한 설명은 다시 한 번 Ultra-Scale Playbook을 확인할 것을 촉구한다.)

1단계: 학습 단계를 메모리에 맞추기

첫 번째 질문은 간단하다: 우리 SmolLM3 30억 모델이 단일 H100의 80GB 메모리에 맞는가? 이에 답하기 위해, 모델 매개변수, 옵티마이저 상태, 기울기 및 활성화에 대한 메모리 소비를 추정하는 nanotron의 predict_memory 도구를 사용해본다.

스크린샷 2025-12-04 오후 9.47.13.png

nanotron의 predict_memory 도구의 메모리 타임라인은 SmolLM3 3B가 74GB에서 피크를 찍어 H100의 80GB 한계에 접근함을 보여준다.

결과는 우리가 80GB 한계에 가깝게 밀어붙이고 있음을 보여준다. 이는 텐서 병렬화 (GPU 전반에 걸쳐 모델 레이어 분할), 파이프라인 병렬화 (GPU 전반에 걸쳐 모델 깊이 분할), 또는 ZeRO 옵티마이저 샤딩 (옵티마이저 상태 분산) 등 GPU당 메모리 사용량을 줄이는 어떤 형태의 병렬화가 필요함을 의미한다. 이러한 전략 중 적어도 하나가 없다면 효율적으로 또는 전혀 학습할 수 없을 것이다.

2단계: 목표 전역 배치 크기 달성

이제 모델이 어떤 형태의 병렬화로 메모리에 맞는다는 것을 알았으므로, 약 200만 토큰의 목표 전역 배치 크기(GBS)를 달성하는 방법을 결정해야 한다. 이 제약 조건은 우리에게 첫 번째 방정식을 제공한다:

GBS = DP \times MBS \times GRAD\_ACC \times SEQLEN \approx 2M \text{ tokens}

여기서:

DP (Data Parallelism): 데이터 병렬 복제본 수
MBS (Micro Batch Size): 마이크로 배치당 GPU당 처리되는 토큰 수
GRAD_ACC (Gradient Accumulation): 옵티마이저 단계 전 순방향-역방향 횟수
SEQLEN (Sequence Length): 시퀀스당 토큰 수 (1차 사전 학습 단계의 경우 4096)

이다.

우리는 또한 384개의 H100에서 하드웨어 제약 조건을 가지고 있다:

DP×TP×PP=384=2^7×3

여기서:

TP (Tensor Parallelism): 모델 레이어당 GPU 수 (가중치 행렬 분할)
PP (Pipeline Parallelism): 모델 깊이당 GPU 수 (레이어를 수직으로 분할)

이다.

이 두 방정식은 우리의 탐색 공간을 정의한다. 우리는 학습 처리량을 최대화하면서 두 제약 조건을 모두 만족하는 값을 찾아야 한다.

3단계: 학습 처리량 최적화

제약 조건이 확립되었으므로, 학습 처리량을 최대화하는 병렬화 구성을 찾아야 한다. 탐색 공간은 하드웨어 토폴로지와 모델 아키텍처에 의해 정의된다.

우리의 하드웨어 설정은 위 섹션에서 본 것처럼 두 가지 별개의 상호 연결 유형을 제시한다: 노드 내 통신을 위한 NVLink (900 GB/s)와 노드 간 통신을 위한 EFA (~50 GB/s). 이 토폴로지는 자연스럽게 네트워크 특성에 맞추기 위해 적어도 두 가지 형태의 병렬화를 사용할 것을 제안한다. 이러한 상호 연결 간의 극적인 대역폭 차이는 어떤 병렬화 전략이 가장 잘 작동하는지에 큰 영향을 미칠 것이다.

모델 관점에서, SmolLM3의 아키텍처는 옵션을 제한한다. 전문가 혼합 아키텍처를 사용하지 않으므로 **전문가 병렬화(Expert Parallelism)**가 필요하지 않다. 마찬가지로, 첫 번째 단계에서 4096 시퀀스 길이로 학습한다는 것은 **컨텍스트 병렬화(Context Parallelism)**가 필요하지 않음을 의미한다. 이것은 우리에게 탐색할 세 가지 주요 병렬화 차원, 즉 데이터 병렬화(DP), 텐서 병렬화(TP), 파이프라인 병렬화(PP)를 남긴다.

2단계의 제약 조건을 고려할 때, 우리는 여러 매개변수에 걸쳐 스윕해야 한다:

ZeRO 변형이 있는 DP (ZeRO-0, ZeRO-1, ZeRO-3): 1에서 384까지의 값, 2 및/또는 3의 배수로 제한됨
TP (1, 2, 3, 4, 6, 8): NVLink의 높은 대역폭을 완전히 활용하기 위해 단일 노드 내에 유지
PP (1..48): GPU 전반에 걸쳐 모델 깊이 분할
MBS (2, 3, 4, 5): 병렬화로 인한 메모리 절약에 따라, Tensor 코어를 더 잘 활용하기 위해 MBS를 늘릴 수 있음
활성화 체크포인팅 (없음, 선택적, 전체): 메모리 및 통신 감소를 위해 추가 계산을 트레이드함
커널 최적화: 사용 가능한 경우 CUDA 그래프 및 최적화된 커널

이것이 압도적인 수의 조합처럼 보일 수 있지만, 실용적인 접근 방식은 각 차원을 먼저 독립적으로 벤치마킹한 다음 처리량을 크게 해치는 구성을 제거하는 것이다. 핵심 통찰력은 모든 병렬화 전략이 동일하게 생성되는 것은 아니라는 것이다. 일부는 특히 우리 규모에서 이점보다 훨씬 큰 통신 오버헤드를 도입한다.

우리의 경우, **파이프라인 병렬화(PP)**는 나쁜 성능 특성을 보였다. PP는 노드 전반에 걸쳐 빈번한 파이프라인 버블 동기화를 요구하며, 상대적으로 작은 30억 모델의 경우 통신 오버헤드가 잠재적 이점을 넘어섰다. 또한 파이프라인 버블을 완전히 제거할 수 있는 고도로 효율적인 PP 스케줄에 액세스할 수 없었기 때문에 PP의 실행 가능성이 더욱 제한되었다. 마찬가지로, 0보다 높은 ZeRO 수준은 메모리에 도움이 되는 것보다 처리량을 더 많이 해치는 상당한 all-gather 및 reduce-scatter 작업을 도입했다. 이러한 초기 벤치마크를 통해 우리는 탐색 공간을 극적으로 좁힐 수 있었고, 데이터 병렬화와 적당한 텐서 병렬화를 결합한 구성에 집중했다.

👉 각 구성을 평가하기 위해 5회 반복에 대해 벤치마크를 실행하고 **GPU당 초당 토큰 (tok/s/gpu)**을 기록했는데, 이는 궁극적으로 우리가 신경 쓰는 지표이다. 우리는 Weights & Biases와 Trackio를 사용하여 처리량과 구성을 기록하여 다양한 병렬화 전략을 쉽게 비교할 수 있다.

nanotron에서 사용 가능한 옵션을 체계적으로 벤치마킹한 후, 우리는 DP = 192에 정착했는데, 이는 데이터 병렬 기울기 동기화를 위해 노드 간 EFA 대역폭을 활용한다. 이는 192개의 독립적인 모델 복제본이 각각 다른 데이터 배치를 처리함을 의미한다. 텐서 병렬화의 경우, 우리는 TP = 2를 선택하여 텐서 병렬 통신을 단일 노드 내에 유지하여 NVLink의 높은 대역폭을 완전히 활용했다. 이것은 각 레이어의 가중치 행렬을 두 개의 GPU에 분할하여 순방향 및 역방향 패스를 위한 빠른 통신을 요구한다.

우리의 마이크로 배치 크기 = 3은 메모리 사용량과 계산 효율성 사이의 균형을 맞춘다. 더 큰 배치 크기는 Tensor 코어를 더 잘 활용하겠지만, 우리는 이미 메모리 한계에 가깝게 밀어붙이고 있다. 마지막으로, 우리는 ZeRO-0을 선택했는데, 이는 옵티마이저 상태 샤딩이 없음을 의미한다. ZeRO-1이나 ZeRO-3은 메모리 사용량을 줄일 수 있지만, 384개의 GPU에 걸쳐 옵티마이저 상태를 수집하고 분산하는 통신 오버헤드는 처리량을 크게 해칠 것이다.

(이러한 병렬화 결정 중 다수는 실험 당시 라이브러리 상태의 영향을 받았다. 예를 들어 nanotron은 아직 ZeRO-3을 지원하지 않았고, 우리는 파이프라인 버블을 제거할 수 있는 고도로 최적화된 파이프라인 병렬화 스케줄이 부족했다. 프레임워크가 발전함에 따라 이러한 트레이드오프 중 일부가 바뀔 수 있다. 기여는 언제나 환영한다!)

이 구성은 우리의 384 H100 클러스터에서 처리량을 최대화하면서 약 200만 토큰 ( 192×3×1×4096≈2.3M)의 목표 전역 배치 크기를 달성했다. stage1_8T.yaml (https://github.com/huggingface/smollm/blob/main/text/pretraining/smollm3/stage1_8T.yaml)에서 전체 학습 구성을 볼 수 있다.

Conclusion

우리는 간단한 질문으로 이 여정을 시작했다: 2025년에 고성능 LLM을 학습시키기 위해 실제로 무엇이 필요한가? 사전 학습에서 사후 학습에 이르는 전체 파이프라인을 안내한 후, 우리는 기술뿐만 아니라 그것들을 작동시키는 방법론을 보여주었다.

대규모 사전 학습. 우리는 학습 여부를 결정하기 위한 학습 나침반 프레임워크를 안내한 다음, 목표를 구체적인 아키텍처 결정으로 변환하는 방법을 보여주었다. 신뢰할 수 있는 제거 실험 파이프라인을 설정하고, 변경 사항을 개별적으로 테스트하고, 수십억 토큰 실험에서 수조 토큰 실행으로 확장하는 방법을 보았다. 우리는 대규모에서 나타날 수 있는 인프라 문제 (처리량 붕괴, 데이터로더 병목 현상, 미묘한 버그)와 모니터링 및 체계적인 위험 제거가 어떻게 그것들을 조기에 포착하고 빠르게 디버깅하는 데 도움이 되는지 문서화했다.

실제 사후 학습. 우리는 기본 모델에서 프로덕션 어시스턴트로 가는 것이 자체적인 체계적 접근 방식을 요구한다는 것을 보여주었다: 어떤 것을 학습하기 전에 평가를 수립하고, SFT 데이터 혼합을 반복하고, 선호도 최적화를 적용하고, 선택적으로 RL로 더 밀어붙이는 것이다. 바이브 테스트가 지표가 놓친 버그를 어떻게 잡는지, 채팅 템플릿이 어떻게 조용히 지침 따르기를 깨뜨릴 수 있는지, 그리고 데이터 혼합 균형이 사전 학습만큼 사후 학습에서 왜 중요한지 보았다.

두 단계 모두에서, 우리는 동일한 핵심 통찰력으로 계속 돌아왔다: 실험을 통해 모든 것을 검증하고, 한 번에 하나씩 변경하고, 규모가 새로운 방식으로 물건을 부술 것이라고 예상하고, 모든 새로운 논문을 쫓는 대신 사용 사례가 결정을 주도하게 하라. 이 프로세스를 따라, 우리는 SmolLM3를 학습시켰다: 긴 컨텍스트를 가진 경쟁력 있는 30억 다국어 추론 모델이다. 그 과정에서, 우리는 무엇이 작동하고, 무엇이 깨지고, 상황이 잘못될 때 디버깅하는 방법에 대해 많은 것을 배웠다. 우리는 성공과 실패 모두를 문서화하려고 노력했다.

다음은 무엇인가?

이 블로그는 현대 LLM 학습의 기초를 다루지만, 이 분야는 빠르게 진화한다. 더 깊이 들어가는 방법은 다음과 같다:

직접 실험을 실행한다. 제거 실험에 대해 읽는 것은 유용하지만, 직접 실행해 보는 것은 실제로 무엇이 중요한지 가르쳐준다. 소형 모델을 선택하고, 평가를 설정하고, 실험을 시작한다.
소스 코드를 읽는다. nanotron, TRL 등과 같은 학습 프레임워크는 오픈 소스이다. 그들의 구현을 이해하면 논문이 얼버무리는 세부 사항이 드러난다.
최근 작업을 팔로우한다. 최근 최첨단 모델의 논문은 이 분야가 어디로 향하고 있는지 보여준다. 참조 섹션에는 영향력 있는 논문 및 리소스의 큐레이션된 목록이 포함되어 있다.

우리는 이 블로그가 여러분이 프런티어를 추진하는 대형 연구소에 있든 특정 문제를 해결하는 소규모 팀에 있든 상관없이 명확성과 자신감을 가지고 다음 학습 프로젝트에 접근하는 데 도움이 되기를 희망한다.

이제 가서 무언가를 학습시키자. 그리고 새벽 2시에 손실이 미스터리하게 급등할 때 기억해라: 모든 훌륭한 모델 뒤에는 디버깅 이야기가 있다. 오픈 소스와 오픈 사이언스의 포스가 항상 함께 하기를!

감사의 말

귀중한 피드백을 주신 Guilherme, Hugo, Mario와 Trackio에 도움을 준 Abubakar에게 감사드립니다.

Below is a curated list of papers, books, and blog posts that have informed us the most on our LLM training journey.

LLM Architecture

Dense models: Llama3, Olmo2, MobileLLM
MoEs: DeepSeek V2, DeepSeek V3, Scaling Laws of Efficient MoEs
Hybrid: MiniMax-01, Mamba2

Optimisers & training parameters

Data curation

Web: FineWeb & FineWeb-Edu, FineWeb2, DCLM
Code: The Stack v2, To Code or Not to Code
Math: DeepSeekMath, FineMath, MegaMath
Data mixtures: SmolLM2, Does your data spark joy

Scaling laws

Kaplan, Chinchilla, Scaling Data-Constrained Language Models

Post-training

InstructGPT: OpenAI’s foundational paper to turn base models into helpful assistants. The precursor to ChatGPT and a key step on humanity’s path up the Kardashev scale.
Llama 2 & 3: Extremely detailed tech reports from Meta on the training behind their Llama models (may they rest in peace). They each contain many insights into human data collection, both for human preferences and model evaluation.
Secrets of RLHF in LLMs, Part I & II: these papers contain lots of goodies on the nuts and bolts for RLHF, specifically on how to train strong reward models.
Direct Preference Optimisation: the breakthrough paper from 2023 that convinced everyone to stop doing RL with LLMs.
DeepSeek-R1: the breakthrough paper from 2025 that convinced everyone to start doing RL with LLMs.
Dr. GRPO: one of the most important papers on understanding the baked-in biases with GRPO and how to fix them.
DAPO: Bytedance shares many implementation details to unlock stable R1-Zero-like training for the community.
ScaleRL: a massive flex from Meta to derive scaling laws for RL. Burns over 400k GPU hours to establish a training recipe that scales reliably over many orders of compute.
LoRA without Regret: a beautifully written blog post which finds that RL with low-rank LoRA can match full-finetuning (a most surprising result).
Command A: a remarkably detailed tech report from Cohere on various strategies to post-train LLMs effectively.