Tulu 3 Review

2026-04-09 9 분 소요

0. Introduction

Tulu 3는 모델 아키텍처 논문이라기보다 post-training 시스템 논문으로 읽는 편이 훨씬 맞다. 이 논문이 흥미로운 이유는 단순히 instruct checkpoint 하나를 공개한 것이 아니라, 어떤 데이터를 모으고, 어떻게 decontaminate하고, 어떤 평가로 개발을 유도하고, 어느 stage에서 어떤 objective를 써야 하는가를 꽤 정직하게 공개했기 때문이다.

특히 최근 open model 성능 차이가 base model 자체보다 post-training recipe의 품질에서 더 크게 갈리는 상황을 생각하면, Tulu 3는 “좋은 모델 소개”보다 “좋은 학습 운영체계 해부”에 더 가까운 논문이다.

한 줄 요약: Tulu 3는 prompt curation, evaluation hygiene, SFT → DPO → RLVR로 이어지는 stage-aligned recipe를 한 묶음으로 공개해, open post-training을 checkpoint 결과가 아니라 재현 가능한 운영 레시피로 만든 논문이다.

이 논문을 지금 볼 가치가 있는 이유는 다음과 같음.

요즘 open assistant 품질 차이는 아키텍처보다 post-training 데이터/평가/레시피에서 더 크게 벌어지는 경우가 많다.
모델, 데이터, 코드, evaluation, decontamination 도구까지 함께 공개해서 실제로 재사용하거나 비교하기 좋다.
잘 된 결과만 보여주는 대신, 무엇이 잘 안 되었는지와 어디서 과적합이 생기는지도 같이 보여준다.

내가 보기엔 이 논문은 “AllenAI가 강한 instruct model을 만들었다”보다, 현대 post-training에서 무엇을 어떤 순서로 건드려야 하는가를 정리한 실전 문서로 읽는 편이 더 가치가 크다.

1. Problem Setting

1-1. Problem definition

이 논문이 겨냥하는 핵심 문제는 open model의 post-training이 여전히 proprietary recipe보다 불투명하고 재현성이 낮다는 점이다.
pretraining이 base capability를 정한다면, 실제 assistant behavior는 점점 더 post-training에서 결정된다.
그런데 post-training은 단일 목표 최적화가 아니라 knowledge recall, reasoning, math, coding, instruction following, general chat, safety를 동시에 다루는 multi-objective problem이다.
따라서 문제는 “벤치마크 하나를 높이는 법”이 아니라, 여러 핵심 능력을 균형 있게 끌어올리면서도 결과를 신뢰할 수 있는 개발 루프를 만드는 것이다.

1-2. Why previous approaches are insufficient

기존 open recipe는 구현이 쉬운 단순 파이프라인에 머무는 경우가 많았고, 이 때문에 closed recipe와의 격차가 남아 있었다.
또 evaluation contamination이나 benchmark-specific overfitting 때문에, 겉으로 보이는 향상이 실제 generalization 향상인지 분리하기 어려웠다.
SFT 하나만으로는 broad assistant prior를 잡는 데는 도움이 되지만, preference shaping이나 verifiable skill 강화까지 한 번에 해결하기 어렵다.
반대로 RLHF 계열은 강력할 수 있지만, reward가 애매하거나 infrastructure가 부족하면 비용은 크고 이득은 불안정해질 수 있다.
즉, 기존 접근의 한계는 알고리즘 하나의 문제가 아니라, data quality, evaluation quality, stage choice, infra choice가 따로 놀았다는 데 있다.

2. Core Idea

2-1. Main contribution

Tulu 3의 핵심 기여는 크게 3개다.
Tulu 3 Data: target skill을 기준으로 prompt를 모으고, synthetic data를 추가하고, evaluation contamination을 공격적으로 제거한다.
Tulu 3 Eval: development와 unseen evaluation을 분리하고, instruction-following generalization을 보기 위한 IFEval-OOD와 HREF까지 포함한다.
Tulu 3 Recipe: SFT, preference tuning, RLVR를 stage별로 나눠 각각의 objective가 가장 잘 먹히는 곳에 배치한다.

2-2. Design intuition

이 논문의 설계 직관은 꽤 명확하다. post-training은 하나의 알고리즘이 아니라 control loop라는 것이다.
먼저 어떤 능력을 올릴지 정하고, 그 능력을 측정할 evaluation을 만들고, 부족한 영역을 확인한 다음, 그에 맞는 데이터와 objective를 다음 stage에 투입한다.
그래서 이 논문은 “좋은 데이터 한 덩어리를 만들자”보다, 어떤 stage에 어떤 종류의 supervision을 줘야 하는가를 더 중요하게 본다.
SFT는 broad behavior prior를 만드는 데 쓰고, DPO는 response ranking과 preference shaping에 쓰며, RLVR는 correctness를 자동 검증할 수 있는 수학/제약 추종 같은 영역에 한정해서 쓴다.
결국 핵심은 “강한 recipe”가 아니라, 각 stage가 맡아야 할 역할을 분리한 recipe다.

3. Architecture / Method

3-1. Overview

Item	Description
Goal	open post-training을 fully open, reproducible recipe로 정리하는 것
Base model	Llama 3.1 8B / 70B / 405B
Key module	Tulu 3 Data + Tulu 3 Eval + SFT / DPO / RLVR
Release scope	intermediate/final checkpoints, SFT/DPO datasets, training/eval/decontamination tools
Difference from prior work	end-to-end openness, dev/unseen split, on-policy preference curation, RLVR, failed methods까지 공개

3-2. Module breakdown

1) Tulu 3 Data

Tulu 3는 먼저 매우 넓은 prompt reservoir를 만든 뒤, 여기서 stage별로 필요한 subset을 뽑아 쓴다.
중요한 건 단순히 prompt 수가 많다는 점이 아니라, skill-addressable data라는 점이다.
math, coding, instruction following, safety, multilinguality, knowledge recall, general chat를 각각 겨냥하는 데이터가 분리되어 있고, 부족한 skill은 synthetic prompt generation으로 보완한다.
즉, 데이터가 “어디서 왔는가”만 중요한 게 아니라, 어떤 약점을 보강하려고 넣는가가 훨씬 중요하다.

2) Decontamination as part of the method

이 논문에서 decontamination은 cleanup이 아니라 method 그 자체다.
completions는 재생성되는 경우가 많기 때문에, prompt 혹은 user turn 기준으로 contamination을 검사한다.
핵심 아이디어는 표면적으로 살짝 바뀐 문제도 잡아내기 위해 8-gram 기반 overlap을 쓰고, evaluation과 겹치는 dataset은 아예 제거하거나 matching instance를 제거하는 것이다.
이런 정책이 중요한 이유는 post-training 논문이 결국 evaluation-driven optimization이기 때문이다. 평가를 새면 recipe 전체가 왜곡된다.

3) Supervised Finetuning (SFT)

SFT는 broad assistant prior를 잡는 stage다.
저자들은 처음부터 하나의 final mix를 정하지 않고, skill-specific mixture를 먼저 만들고 각각이 특정 능력을 얼마나 올리는지 본다.
그 뒤 이들을 합치고 덜어내는 식으로 balanced final mix를 만든다.
이 과정은 생각보다 중요하다. Tulu 3의 메시지는 “SFT는 초반 단계이므로 대충 해도 된다”가 아니라, SFT mix가 이후 DPO와 RLVR의 출발점 품질을 결정한다는 쪽에 가깝다.

4) Preference tuning

Tulu 3의 preference stage는 public preference set을 그대로 쓰는 방식이 아니다.
prompt를 고르고, 여러 모델로 응답을 생성하고, on-policy 응답도 섞고, LLM judge로 비교해 preference pair를 만든다.
다시 말해 DPO의 성능은 loss 하나보다 prompt selection, response generation pool, judge choice, on/off-policy mix에 의해 크게 좌우된다.
이 논문이 좋은 이유는 바로 이 지점을 추상적으로 넘기지 않고 ablation으로 보여준다는 데 있다.

5) RLVR

RLVR는 Tulu 3의 마지막 차별점이다.
일반 reward model 기반 RLHF 대신, correctness를 자동 확인할 수 있는 task에서는 verifiable reward를 준다.
이 접근은 수학, constraint following처럼 정답 판정이 가능한 영역에서는 매우 설득력이 있다.
반대로 말하면 RLVR의 성공은 “RL이 항상 좋다”의 증거가 아니라, reward가 sharp할 때 RL이 쓸모 있다는 증거로 읽는 편이 맞다.

6) Evaluation loop

Tulu 3 Eval은 부록이 아니라 core contribution이다.
development split로 모델을 고도화하고, unseen split로 개발 과정이 실제로 일반화되는지를 확인한다.
특히 instruction following은 기존 IFEval만 보면 쉽게 과대평가될 수 있기 때문에, authors는 IFEval-OOD와 HREF를 따로 설계한다.
이 부분은 실무적으로도 중요하다. 내부 eval만 보고 model selection을 하면 금방 그 eval에 과적합되기 때문이다.

4. Training / Data / Recipe

4-1. Data

Table 7 기준으로 저자들은 매우 큰 prompt reservoir를 구축한 뒤, 그중 939,344 prompts를 SFT에, 425,145 prompts를 DPO-stage sourcing에 사용한다.
구성에는 OpenAssistant, No Robots, WildChat, FLAN v2, SciRIFF, TableGPT, Aya 같은 public data와, math / coding / precise instruction following / safety를 겨냥한 synthetic persona data가 함께 들어간다.
SFT response는 기존 human/frontier-model response를 유지하거나, 필요할 경우 새로 생성해 붙인다.
preference data도 단순 재사용이 아니다. Table 15 기준 최종 best preference pool은 354,192 instances이며, 8B와 70B가 각각 약간 다른 최적 혼합을 사용한다.
RLVR는 general chat 전체가 아니라, 정답 여부를 자동 검증할 수 있는 좁고 강한 데이터셋으로 들어간다.

4-2. Training strategy

전체 흐름은 SFT → DPO-norm → RLVR다.
공개 재현 문서 기준으로 SFT는 8B와 70B 모두 max sequence length 4096, 2 epochs로 학습된다.
학습률은 8B가 5e-6, 70B가 2e-6로 설정되어 있고, 둘 다 linear schedule과 warmup ratio 0.03을 사용한다.
DPO는 8B와 70B 모두 max sequence length 2048, 1 epoch로 학습되며, 최종적으로는 length-normalized DPO와 β = 5 설정을 채택한다.
RLVR는 DPO checkpoint 위에서 시작하고, verifiable reward가 가능한 데이터셋으로 PPO를 돌린다.
405B는 같은 큰 틀의 recipe를 따르되, RLVR 단계에서는 GSM8K나 IF보다 MATH 중심으로 좁혀 학습한다.

4-3. Engineering notes

이 논문이 특히 좋은 이유는 “잘 된 아이디어”뿐 아니라 실제로 돌아가게 만든 엔지니어링 포인트를 같이 공개한다는 점이다.
SFT에서는 padding token에 대한 평균 손실 집계 때문에 성능 차이가 생겼고, 이를 sum loss로 바꾸면서 격차를 줄였다고 설명한다.
DPO에서는 reference model log-prob caching과 chosen/rejected 분리 forward 같은 방식으로 메모리 사용을 줄인다.
RLVR/PPO는 Ray, vLLM, PagedAttention, asynchronous training을 활용해 rollout과 learner를 분리하고, 405B scale까지 확장한다.
즉, Tulu 3는 “좋은 objective를 찾았다”보다, 좋은 objective가 실제로 학습되도록 만드는 infra recipe까지 포함한다.

5. Evaluation

5-1. Main results

Setting	What the paper shows
SFT mix	Tulu 3 8B SFT는 평균 60.1, Tulu 3 70B SFT는 평균 72.6으로, 비교군 SFT mix 대비 강한 균형 성능을 보인다.
DPO algorithm choice	저자들의 통제된 실험에서는 length-normalized DPO가 vanilla DPO, PPO, SimPO보다 가장 좋은 평균 성능을 보였다.
Final 70B	development suite에서 Tulu 3 70B는 평균 76.2를 기록하며, Llama 3.1 70B Instruct(74.1), Qwen 2.5 72B Instruct(72.8), GPT-3.5 Turbo(64.7), GPT-4o Mini(69.6), Claude 3.5 Haiku(75.3)를 앞선다.
Final 8B	Tulu 3 8B는 평균 65.1로 Llama 3.1 8B Instruct(62.9)보다 분명히 강하지만, 모든 strong 7B/8B peer를 일방적으로 압도하는 형태로 읽으면 과장이다.
405B scaling	Tulu 3 405B는 prior Llama 3.1 405B-based finetunes보다 강하고, DeepSeek V3와 GPT-4o에 대해 competitive하거나 일부 지표에서 superior하다고 보고된다.

5-2. What really matters in the experiments

이 논문의 핵심은 final checkpoint table 하나가 아니다. 어떤 결정이 성능을 만들었는가를 단계별로 보여준다는 점이 더 중요하다.
SFT 쪽에서는 WildChat 같은 diverse real-user data가 broad skill, 특히 chat 계열에서 의미 있는 기여를 하고, safety data는 대체로 다른 skill과 orthogonal하다는 점이 드러난다.
preference stage에서는 중복 prompt를 늘리는 것보다 새로운 unique prompt를 늘리는 것이 더 중요하고, SFT 때 썼던 prompt만 재사용하는 것보다 unused prompt를 섞는 편이 더 유리하다는 결과가 나온다.
또 on-policy data가 downstream DPO 성능에 도움이 된다는 점은 꽤 실무적이다. 즉, preference tuning도 결국 현재 policy 분포에 가까운 데이터를 얼마나 잘 모으느냐의 문제다.
알고리즘 측면에서도 흥미로운 점이 있다. 이 논문에서는 PPO가 늘 더 좋은 게 아니고, 오히려 잘 튜닝된 DPO-norm이 cost/performance 측면에서 더 현실적인 선택으로 나온다.
RLVR는 general chat 전체를 바꾸는 만능 stage가 아니라, verifiable reward가 있는 target skill booster로 보는 편이 맞다.
unseen evaluation 분석도 중요하다. Tulu 3 recipe는 전반적으로 unseen task로 어느 정도 일반화되지만, instruction following은 IFEval에 과적합되기 쉽고, 일부 reasoning/knowledge/mathematics 선택도 development task 쪽으로 치우칠 수 있음을 저자들이 직접 보여준다.

6. Limitations

이 논문은 모든 size에서 동급 모델을 완전히 sweep했다는 논문이 아니다. 특히 8B는 strong peer 대비 competitive하게 읽는 편이 더 정확하다.
evaluation-driven recipe는 evaluation overfitting 위험을 항상 안고 있다. 저자들도 IFEval과 IFEval-OOD 간 격차를 통해 이 문제를 명시적으로 보여준다.
데이터가 길지 않다. 논문은 mixture의 평균 turn 수가 2.4이고, 대부분 2,048 tokens 이하라고 적는다. 따라서 long-context / long multi-turn capability는 Tulu 3의 핵심 강점이 아니다.
주로 영어 중심이다. Aya를 일부 포함하지만, multilingual post-training을 본격적으로 다루는 레시피는 아니다.
tool use / agent setting은 거의 다루지 않는다. 실제 서비스에서는 중요한 영역이지만, 이번 recipe의 중심은 standalone assistant quality다.
405B 결과는 더 좋아질 여지가 남아 있다. authors는 RLVR training을 compute constraint 때문에 일찍 멈췄다고 말한다.
안 되는 방법도 있었다. Online DPO나 rejection sampling은 이 setup에서 일관된 개선을 주지 못했다.

7. My Take

7-1. Why this matters for my work

Tulu 3가 주는 가장 큰 교훈은 post-training 논문을 alignment paper가 아니라 systems paper처럼 읽어야 한다는 점이다.
실제 서비스에 가까운 assistant를 만들 때 중요한 건 loss function 하나가 아니라, 데이터 소싱, decontamination, eval 설계, on-policy preference collection, late-stage objective selection이 어떻게 연결되는가다.
그런 의미에서 Tulu 3는 “새로운 모델”보다 open assistant를 만드는 운영 절차서로 보는 편이 더 실용적이다.

7-2. Reuse potential

내가 보기에 재사용 가치가 큰 포인트는 5가지다.
첫째, development / unseen split 기반의 model selection. 내부 eval 하나만 보고 recipe를 고정하면 금방 과적합된다.
둘째, hard decontamination policy. 특히 prompt overlap 기준을 명시적으로 두는 방식은 dataset hygiene 측면에서 바로 응용 가능하다.
셋째, on-policy preference data generation. preference tuning을 public pair 재학습으로 끝내지 않고, 현재 policy에 맞는 데이터를 다시 만든다는 점이 중요하다.
넷째, DPO-norm을 기본값으로 두고 RL은 verifiable domain에만 쓰는 운영 원칙. compute budget이 제한된 팀일수록 더 현실적이다.
다섯째, 엔지니어링 이슈를 recipe의 일부로 본다는 태도. sum loss, logprob caching, async RL 같은 디테일이 실제 재현성의 핵심이다.

7-3. Follow-up papers

Camels in a Changing Climate: Enhancing LM Adaptation with Tulu 2
Unpacking DPO and PPO: Disentangling Best Practices for Learning from Preference Feedback
UltraFeedback: Boosting Language Models with Scaled AI Feedback

8. Summary

Tulu 3의 핵심은 강한 instruct model 하나가 아니라 Data / Eval / Recipe를 묶은 open post-training framework다.
이 논문은 SFT, DPO, RLVR를 한꺼번에 쓰는 것이 아니라, 각 stage가 맡을 역할을 분리해 설계한다.
실험에서 특히 중요한 메시지는 SFT mix 설계, unique prompts, on-policy preference data, evaluation hygiene가 알고리즘 못지않게 중요하다는 점이다.
RLVR는 만능 alignment stage가 아니라, 정답을 검증할 수 있는 능력을 late stage에서 증폭하는 도구로 읽는 편이 맞다.
결국 Tulu 3는 “좋은 open assistant를 어떻게 만들 것인가”보다, 좋은 post-training 개발 루프를 어떻게 설계할 것인가에 대한 논문이다.

Twitter Facebook LinkedIn