강화학습(RL, 모델이 스스로 답을 내보고 잘한 쪽으로 학습하는 방식)으로 LLM을 더 똑똑하게 만들 때, 시간과 비용의 대부분은 LLM이 긴 답변을 스스로 생성해보는 롤아웃(rollout) 단계가 차지한다. 그래서 "롤아웃만 저정밀로 돌려 싸게 하자"는 아이디어가 오래전부터 있었지만, 품질이 흔들린다는 벽에 막혀 있었다.
알리바바 토큰허브와 오하이오주립대 연구진이 공개한 TRACE가 이 벽을 넘었다. 롤아웃을 FP4(4비트 저정밀)로 돌리면서도 BF16(16비트)으로 돌린 것과 거의 같은 성능을 냈다. 핵심 발상은 한 문장이다 — 두 경로를 각각 정확하게 만들려 하지 말고, 두 경로 사이의 어긋남을 직접 줄여라.
용어 빠른 풀이 - 롤아웃(rollout): RL 훈련에서 모델이 긴 답변을 반복 생성하는 구간. 가장 비싸다. - FP4 / BF16: 숫자를 담는 그릇의 크기. 4비트(FP4)는 16비트(BF16)보다 가볍고 빠르지만, 값을 담을 '칸'이 훨씬 적다. - MoE(전문가 혼합): 토큰마다 일부 '전문가' 모듈만 골라 쓰는 모델 구조.
저정밀 롤아웃은 "답을 뽑는 동안만 모델을 낮은 비트로 양자화(값을 더 적은 비트로 줄여 담는 것)해 빠르게 하자"는 아이디어다. 문제는 FP4의 '칸'이 너무 적다는 데 있다. 값을 담을 자리가 몇 개뿐이라, 롤아웃 경로와 훈련 경로가 같은 값을 놓고도 서로 다른 칸으로 반올림해버린다. 그러면 두 경로가 계산하는 정책(모델이 다음에 어떤 토큰을 낼지 정하는 규칙)이 어긋나고, 이 어긋남이 쌓이면 훈련이 불안정해지거나 붕괴한다.
MoE에서는 더 고약하다. MoE는 토큰마다 라우터가 점수를 매겨 전문가를 고르는데, 작은 수치 차이가 점수를 흔들면 아예 다른 전문가가 켜진다. 반올림 한 칸 차이가 "누가 이 토큰을 처리하느냐"까지 바꿔 불일치가 증폭된다.
기존 FP4 RL 연구도 여기까지는 알고 있었다. 하지만 그들은 두 경로를 각각 고정밀(BF16) 원본에 가깝게 만드는 데 집중했다. 각 경로의 오차를 따로 줄인다고 두 경로 사이의 거리가 줄어드는 건 아니다 — 한 경로만 원본에 맞춰 보정하면 오히려 간격이 더 벌어지기도 한다. TRACE는 바로 이 지점을 문제의 뿌리로 짚는다.
TRACE라는 이름 자체가 설계를 압축한다. Train-Rollout Quantization Alignment via Compact GuidancE — 훈련과 롤아웃의 양자화를 '작은 힌트'로 정렬한다는 뜻이다.
반올림에 빗대보자. 두 사람이 같은 소수 2.49를 각자 정수로 반올림한다. 기준이 조금만 흔들리면 한 명은 2로, 다른 한 명은 3으로 간다. 둘 다 "가장 가까운 정수로"라는 규칙을 지켰는데도 결과는 벌어진다. FP4의 반올림 경계에서 꼭 이 일이 벌어진다. BF16에서는 아주 작게만 차이 나던 훈련값과 롤아웃값이, 같은 배율(스케일, 값을 칸에 맞추려 곱하는 수)로 정규화되는 순간 경계의 양쪽으로 떨어져 서로 다른 칸으로 반올림되고, 차이가 크게 증폭된다.
TRACE의 처방은 단순하다. 훈련 쪽이 경계 근처 값을 반올림할 때, "가장 가까운 칸으로"를 고집하지 않고, 롤아웃이 실제로 어느 칸을 골랐는지 보고 그쪽으로 맞춘다. 2.49의 두 사람이 "너는 어느 쪽으로 반올림했어?"를 물어 같은 쪽으로 가는 셈이다. 저자들은 이 선택이 기본 규칙(가장 가까운 칸)보다 그 지점의 어긋남을 더 키우지 않음을 수학적으로 보장한다고 밝힌다.
롤아웃의 반올림 결과를 훈련이 참고하려면, 그 정보를 기록했다가 훈련 엔진으로 넘겨야 한다. 이론적으로는 되지만, 현실에서는 데이터 양이 어마어마해 곧장 벽에 부딪힌다. 논문의 Qwen3.5-35B-A3B 예시에서 값 하나당 4.5비트로 잡아도 토큰 하나가 약 50KB를 만든다. 한 RL 스텝에 궤적 4,096개를 샘플링하면 스텝당 최대 약 51TB다. GPU-CPU 대역폭을 300GB/s로 잡아도 전송에만 3분, 저장 대역폭 5GB/s로 읽고 쓰면 약 3시간이 걸린다. RL 한 스텝은 그보다 훨씬 짧게 끝나야 하므로, 전송 3분·저장 3시간짜리 설계는 애초에 후보가 될 수 없다.
TRACE는 "반올림 방향을 정하는 데 꼭 필요한 정보만 보낸다"로 이 벽을 뚫었다. 근거는 두 관찰이다. 첫째, 엇갈린 값의 99% 이상이 바로 옆 칸 하나 차이다. 옆 칸 하나라면 완전한 양자화 값을 다 보낼 필요 없이, 칸을 구분하는 자릿수(가수, 부동소수점에서 유효숫자에 해당하는 부분)의 일부만 보내도 원하는 칸을 집어낼 수 있다. 둘째, 이런 보정은 주로 깊은 층에서 일어나므로 모델 층의 뒤쪽 절반에서만 정보를 보낸다. 저장·통신 부담을 크게 줄이면서 정렬 효과는 지킨다.
얼마나 빨라지나. 롤아웃의 처리량(단위 시간에 뽑아내는 토큰 양)이 최대 5.4배 늘었다. 단, 조건이 붙는다. BF16 롤아웃과 비교한 롤아웃 처리량이고, SGLang 롤아웃 엔진만으로 GB200 4장에서 잰 값이다. 전체 훈련 시간이 5.4배 줄었다는 뜻은 아니다. 이 배수가 말해주는 건, TRACE가 정렬을 위해 얹는 추가 계산이 그만큼 가볍다는 점이다.
품질은 유지되나. 검증한 범위에서는 유지됐다. MoE 4종을 추론·코딩·장기 과제 세 갈래로 돌렸을 때, FP4 롤아웃으로 훈련한 TRACE가 BF16 롤아웃과 맞먹었고 같은 FP4 조건의 기존 방법들을 앞섰다(수치는 아래 '결과').
우리도 쓸 수 있나. 검증은 거대 MoE와 GB200 72장 규모 인프라 위에서 이뤄졌다. 작은 모델·가벼운 서빙에서 같은 배수와 같은 품질이 재현된다는 보장은 이 논문 밖의 이야기다. 규모와 무관하게 가져갈 수 있는 건 "두 경로의 거리를 줄여라"라는 설계 원칙이며, 이건 맨 끝 '온틀의 판단'에서 다룬다.
표는 조건과 함께 읽어야 한다. 모든 FP4 방법은 같은 조건(가중치·활성값, 그리고 KV 캐시 — 직전까지 계산해둔 값을 저장해 재사용하는 메모리 — 모두 FP4)에서 비교했고, 숫자는 각 과제의 평균 점수다.
추론 RL — Qwen3.5-35B-A3B. 추론 RL은 수학·코딩 문제를 풀게 하는 과제다. 아래는 네 벤치마크(AIME·HMMT25 같은 수학 경시, LiveCodeBench 같은 코딩) 평균이다.
| 방법 | 평균 점수 |
|---|---|
| BF16 롤아웃(상한 기준) | 74.9 |
| 바닐라 QAT | 59.6 |
| QaRL | 58.6 |
| QUADS | 68.8 |
| TRACE | 75.3 |
TRACE는 본문 표에 제시한 기존 방법 중 최고인 QUADS보다 평균 6.5점 높고 BF16 수준을 회복했다. 특히 고난도 수학 벤치마크 HMMT25에서는 QUADS 59.0 대 TRACE 70.0으로 11.0점 차가 났다. (QAT는 양자화를 미리 겪게 하며 훈련하는 방식이다.)
더 큰 모델 — 코딩·장기 과제. DeepSWE·Terminal-Bench는 실제 코드를 고치거나 터미널 작업을 수행하는 벤치마크, GDPval은 장기 과제 평가다. 각 대표 벤치마크만 추렸다.
| 모델 · 벤치마크 | BF16 | QAT | QUADS | TRACE |
|---|---|---|---|---|
| 122B-A10B · DeepSWE | 33.4 | 28.8 | 29.1 | 33.0 |
| Flash-Next · Terminal-Bench | 68.8 | 60.4 | 66.4 | 70.6 |
| 2.4T-A95B · GDPval | 90.3 | 88.7 | 85.9 | 90.2 |
세 경우 모두 BF16 롤아웃에 맞먹었고 같은 FP4 조건의 QAT·QUADS를 앞섰다. Terminal-Bench처럼 TRACE가 BF16을 소폭 넘긴 사례도 있다.
QAT·QaRL·QUADS는 훈련이 갈수록 어긋남이 커져 후반에 보상이 급락하고 점수가 무너진다. TRACE는 어긋남을 눌러 BF16에 가까운 흐름을 유지한다. 여기서 저자들이 '저정밀 적응'이라 부르는 현상이 나온다 — 초반에는 양자화 손실로 BF16보다 낮게 출발하지만, 어긋남이 충분히 통제되면 정책이 FP4 환경에 점차 적응해 격차를 줄인다. HMMT25에서는 약 120스텝 뒤 BF16을 따라잡고 이후 비슷하게 유지됐다. 모델이 저정밀 환경을 억지로 버티는 게 아니라 거기에 맞춰 학습한다는 이야기다. 그래서 저자들은 BF16으로 훈련한 뒤 사후에 FP4로 내리는 것보다, 처음부터 FP4에서 훈련한 정책이 FP4에서 더 잘 돈다고 보고한다.
한 줄로 요약하면, 다른 방법들이 저마다 원본에 가까워지려다 길을 잃을 때 TRACE는 두 경로 사이의 거리계만 보고 둘을 서로에게 다가가게 만든다. 각 경로를 정확하게 만드는 게 아니라 두 모습을 포개는 것이 목표다.
남은 한계는 저자들도 분명히 긋는다.
이 연구의 진짜 가치는 '5.4배'라는 숫자가 아니라, 그 숫자를 만든 설계 원칙에 있다. TRACE는 거대 모델의 특수한 문제를 풀었지만, 그 과정에서 "훈련 때의 모델과 서빙 때의 모델이 다르면 품질이 샌다"는 보편적인 문제를 수면 위로 끌어올렸다. 보통 우리는 "제대로(고정밀) 훈련해두고 배포할 때 가볍게 줄인다"는 순서를 당연하게 여긴다. TRACE의 결과는 그 순서가 늘 최선은 아닐 수 있음을 보여준다.
여기까지는 연구에서 빌려오는 원칙이다. 그럼 온틀은 뭘 바꿀까. 온틀은 소기업·1인 창업가의 반복 업무를 대신 처리하는데, 비용을 줄이려고 고객 문의 응대 모델을 경량화해 서빙하는 경우가 생긴다. 이때 "가벼운데 싸니까 좋다"로 끝내지 말고, 배포를 확정하기 전에 다음 절차를 넣자는 것이 우리의 제안이다.
모델별로 정확도만 보던 점검표에, '훈련 때 모습과 서빙 때 모습의 거리'라는 칸 하나를 더 두자는 것이다 — 단, 그 거리는 추상적인 수치가 아니라 위처럼 '같은 문의에 대한 두 버전의 통과율 차이'로 구체화해서.
본문 흐름을 끊지 않도록 세부 설정과 방법 이름은 여기 모았다.
| 항목 | 내용 |
|---|---|
| 훈련 스택 | VeRL(비동기 RL 조율) · Megatron(훈련 백엔드) · SGLang(롤아웃 생성), 모든 방법 동일 버전 비교 |
| 정책 최적화 | GRPO(정책 최적화 알고리즘) + R3(롤아웃의 전문가 라우팅을 훈련 때 재생) |
| 안정화 | 토큰 단위 중요도 비율 클리핑 상한 5, 정책 노후 제한 max_version_diff=3 |
| 양자화 범위 | 롤아웃 동안 MoE 라우팅 전문가 + 어텐션 KV 캐시(앞서 계산한 값을 저장해 재사용하는 메모리)만 FP4, 나머지 모듈 BF16 |
| 평가 모델 | Qwen3.5-35B-A3B, Qwen3.5-122B-A10B, Qwen3.8-Flash-Next(총 125B·활성 6B), Qwen3.8-2.4T-A95B |
| 과제·평가 | 추론 RL(35B → LiveCodeBench v6·AIME24/25·HMMT25, 응답 32K) / 코딩 RL(122B → DeepSWE v1.1, Flash-Next → Terminal-Bench 2.1, 컨텍스트 256K) / 장기 과제 RL(2.4T → GDPval) |
| 지표 | AIME24/25·HMMT25 응답 8개, LiveCodeBench 10개 평균 pass@1 / Terminal-Bench·DeepSWE·GDPval 과제당 10·4·3회 평균 |
| 효율 측정 | 디코딩 처리량 = GB200 4장(SGLang만) / 엔드투엔드 RL 스텝 = GB200 72장 |
| 훈련 스텝 | 35B·Flash-Next 400스텝, 122B·2.4T 50스텝 |
이 설계가 재는 것은 "FP4로 롤아웃을 돌려도 최종 성능과 훈련 안정성이 BF16만큼 나오는가"다. 양자화 범위를 전문가·KV로 한정했고 모델도 Qwen 계열이므로, 전면 FP4 구성이나 다른 계열의 거동은 이 표로 말할 수 없다.
아닙니다. 검증한 과제 범위에서 BF16과 맞먹거나 일부 소폭 앞선 것이고, 이는 '저정밀 적응'으로 격차를 따라잡은 결과입니다. "저정밀이 고정밀보다 우수하다"는 일반 주장으로 읽으면 안 됩니다 — 실험은 Qwen 계열 MoE와 특정 과제로 한정됩니다.
그대로는 안 됩니다. 5.4배는 GB200에서 잰 '롤아웃 처리량' 배수이지 전체 훈련 시간이나 서빙 비용이 아니며, 작은 모델에서 재현된다는 보장도 없습니다. 규모와 무관하게 가져갈 수 있는 건 '훈련 모습과 서빙 모습의 거리를 점검하라'는 원칙뿐입니다.