온도를 올리면 망가지는 확산 모델, 사카나는 두 모델에게 한 답을 나눠 맡겼습니다

사카나는 한국 시각 21일 밤 11시 공식 X 계정에 확산 언어 모델에서도 테스트타임 스케일링이 통하느냐는 물음으로 발표를 시작했습니다. 여러 확산 모델이 한 답을 함께 만들게 하면 코딩과 수학 성적이 오른다는 내용이고, 다음 날 아침에는 일본어 설명을 따로 올렸습니다. 논문은 2월 arXiv에 처음 올라왔고, 발표 전날인 7월 20일 고친 판이 올라왔습니다.

뽑을 만큼 뽑아 테스트로 고르는 방식

테스트타임 스케일링은 모델을 더 학습시키지 않고, 답을 낼 때 연산을 더 써서 성능을 끌어올리는 방법입니다. 모델에게 더 오래 생각하게 하거나 답을 여러 개 뽑게 합니다. 코딩처럼 정답 여부를 테스트로 가릴 수 있는 과제에서는 Best-of-N이 널리 쓰입니다. 온도(모델이 다음 토큰을 고를 때 무작위성을 키우는 값)를 높여 답 N개를 뽑고, 테스트를 가장 많이 통과한 답을 고릅니다.

코딩에서 이 방식을 대규모로 보여 준 사례가 2022년 2월 딥마인드의 알파코드입니다. 알파코드는 문제마다 C++와 파이썬 프로그램을 이전 연구보다 몇 자릿수 많이 만든 뒤, 거르고 묶고 순위를 다시 매겨 10개만 제출했습니다. 코드포스 대회 10개에 모의로 참가한 결과는 참가자 상위 54% 수준이었습니다. 답을 토큰 하나씩 왼쪽에서 오른쪽으로 쓰는 자기회귀 모델에서는 온도를 올려도 답의 품질이 크게 무너지지 않아서 이런 방식이 통했습니다.

확산 언어 모델은 답을 쓰는 순서가 다릅니다. 전체가 가려진(마스크된) 상태에서 출발해, 모델이 가장 자신 있는 위치부터 가림을 벗기며 여러 곳을 동시에 채웁니다. 한 번에 여러 토큰을 채우니 속도에서 이점이 있고, 문장 전체를 보면서 채운다는 점도 장점으로 꼽힙니다. 구글 딥마인드는 실험용 텍스트 확산 모델 Gemini Diffusion을 데모로 열어 두고, 오버헤드를 뺀 생성 속도를 초당 1,479토큰으로 적었습니다. 이번 논문에 쓰인 Dream-Coder와 LLaDA는 누구나 내려받을 수 있는 70억~80억 파라미터급 확산 모델입니다.

온도를 올리자 정답률이 떨어졌습니다

사카나는 코딩에 강한 확산 모델 Dream-Coder로 Best-of-N부터 돌려 봤습니다. 확산 모델에는 무작위를 넣는 방법이 두 가지 있습니다. 온도를 올리는 방법과, 가림을 벗기는 순서를 무작위로 섞는 방법입니다.

온도를 0.1로 낮추면 거의 매번 같은 답이 나와서, 답을 16개 뽑아도 LiveCodeBench 정답률은 18%에서 움직이지 않았습니다. 온도를 1.0으로 올리면 답은 다양해졌지만 품질이 무너져 16개를 뽑고도 8%에 그쳤습니다. 순서를 무작위로 섞으면 뽑을수록 올라가긴 했지만 16개에서 12%로, 무작위 없이 한 번 뽑은 답의 18%를 넘지 못했습니다. HumanEval+와 MBPP+에서도 같은 모양이 나왔습니다.

논문은 무작위가 탐색 비용까지 키운다고 설명합니다. 무작위가 섞이면 같은 경로를 다시 돌려도 점수가 달라지기 때문에, 어느 가지가 좋은지 가리려면 같은 곳을 여러 번 돌려 평균을 내야 합니다. 정해진 예산이 새 경로를 찾는 데 쓰이지 못하고 점수를 확인하는 데 쓰입니다.

채우다 만 답을 다른 모델에 넘깁니다

UMF는 다양성을 무작위 대신 모델 교대에서 얻습니다. 확산 모델이 답을 채우는 도중의 상태, 곧 가려진 토큰과 채워진 토큰이 섞인 문장은 어느 확산 모델이 만들든 구조가 같습니다. 그래서 Dream-Coder가 3분의 1쯤 채운 답을 LLaDA에 넘기면, LLaDA는 거기서부터 이어 씁니다. 두 모델은 예측하는 토큰도, 자신 있어 하는 위치도 달라서 넘겨받은 뒤의 답은 한 모델이 끝까지 썼을 답과 달라집니다. 각 모델은 온도를 거의 0으로 두고 가장 자신 있는 위치부터 채우니, 무작위를 넣지 않고도 답이 여러 갈래로 갈라집니다.

걸림돌은 토크나이저(글자를 모델이 읽는 토큰으로 자르는 규칙)였습니다. Dream과 LLaDA는 토크나이저가 달라서, 넘길 때마다 이미 채운 글자를 문자열로 풀었다가 받는 쪽 규칙으로 다시 자릅니다. 논문이 LiveCodeBench 100문제로 재 보니 이 과정에서 길이가 평균 1.09% 달라졌습니다. 담당 교대는 탐색 나무가 갈라지는 지점에서만 일어나고, 나무 깊이가 최대 7이라 768토큰짜리 답 하나에서 토크나이저가 바뀌는 횟수는 많아야 6번입니다.

몬테카를로 트리 탐색이 교대 순서를 고릅니다

남은 문제는 어느 모델이 어느 단계를 맡을지입니다. UMF는 가려진 비율로 교대 지점을 미리 정해 둡니다. 예를 들어 66%와 33% 지점에서 담당을 바꿀 수 있게 하면 Dream→Dream→LLaDA, LLaDA→Dream→LLaDA 같은 순서가 나무 모양으로 펼쳐집니다. 몬테카를로 트리 탐색은 이 가운데 점수가 좋았던 쪽을 골라 더 깊이 내려가고, 새 가지는 곧바로 답을 끝까지 채워 테스트로 점수를 매긴 뒤, 점수를 위로 올려 다음 선택에 씁니다. 점수는 공개 테스트를 통과한 비율이고, 최종 정답률은 탐색에 쓰지 않은 비공개 테스트로 잽니다.

온도를 거의 0으로 둔 덕에 같은 상태에서 같은 모델을 돌리면 같은 글이 나옵니다. 그래서 한 번 지나간 중간 상태를 저장해 두면 다음에는 계산을 건너뛸 수 있습니다. 예산 1만 2,288번에서 캐시 적중률은 55.8%였고, 캐시가 아낀 모델 호출은 1만 4,186번이었습니다. 같은 예산에서 캐시를 끄면 LiveCodeBench 정답률이 28%에서 26%로 내려갔습니다.

같은 예산에서 19개, 21개, 28개

비교 조건은 엄격하게 맞췄습니다. 모든 방법에 모델 호출 1만 2,288번과 768토큰의 답 길이를 똑같이 줬고, 기존 방법은 온도 0.1·0.5·1.0 가운데 가장 잘 나온 값을 썼습니다. 토큰 하나를 채울 때마다 모델을 한 번 부르게 해 두어서, 답 하나를 끝까지 채우는 데 768번이 들고 1만 2,288번은 답 16개 분량입니다. 벤치마크마다 100문제를 골라 풀게 했습니다.

단위는 100문제 가운데 푼 문제 수(Pass@1, %)이고, 모델 호출 1만 2,288번 기준입니다(출처: 논문 표 1).

예산을 두 배인 2만 4,576번으로 늘리자 LiveCodeBench는 30%까지 올랐습니다. 온도를 올려야 하는 기존 방법들은 예산이 적을 때 크게 흔들렸고, UMF는 적은 예산에서도 온도를 낮춘 답의 안정성을 그대로 가져갔습니다.

모델 둘을 쓰니 점수가 오른 것 아니냐는 물음에는 논문이 기준선으로 답해 뒀습니다. 두 모델에게 따로 풀게 하고 더 나은 답을 고르는 방식(표의 첫 줄)은 19개였고, 두 모델이 각자 UMF를 돌려 예산을 반씩 쓴 뒤 고르는 방식도 24개에 그쳤습니다. 한 모델 안에서 온도만 바꿔 가며 교대시킨 UMF도 세 벤치마크 평균 60.0%로, 두 모델을 쓴 기존 방법들보다 벤치마크마다 높았습니다. 논문은 이를 근거로 UMF의 이득이 모델을 섞은 효과만으로는 설명되지 않는다고 적었습니다.

비교 대상인 AB-MCTS는 사카나가 2025년 7월 내놓은 자기네 기법입니다. 당시 사카나는 o4-mini와 Gemini 2.5 Pro, 딥시크 R1을 함께 쓰는 AB-MCTS로 ARC-AGI-2 공개 평가 120문제 가운데 30% 넘게, 250번 시도 안에서 맞는 풀이를 찾았습니다. AB-MCTS는 각 모델이 답을 통째로 새로 쓰거나 앞선 답을 고치는 방식이고, UMF는 한 답의 생성 과정 자체를 모델들이 나눠 맡습니다.

세 번째 모델을 넣자 32개가 됐습니다

애플이 공개한 확산 모델 DiffuCoder를 세 번째로 넣자 LiveCodeBench는 28개에서 32개로, MBPP+는 72개에서 76개로 올랐습니다. HumanEval+는 88개에서 87개로 거의 그대로였고, 세 벤치마크 평균은 62.7%에서 65.0%가 됐습니다. 논문은 DiffuCoder가 세 모델 가운데 단독 성적이 가장 좋은 모델도 아니었다는 점을 짚고, 점수가 오른 이유를 나눠 맡을 수 있는 조합이 늘어난 데서 찾았습니다.

코딩 밖에서도 같은 흐름이 나왔습니다. MATH 데이터셋 7개 분야에서 15문제씩 모두 105문제를 Dream과 LLaDA에게 풀게 하고 수학 풀이 채점 모델(Qwen2.5-Math-PRM-7B)로 점수를 매기자, 정답률이 예산 768번의 49.52%에서 1만 2,288번의 60.95%로 11.43%포인트 올랐습니다. 문장을 네 토큰짜리 토막으로 나눠 채우는 블록 확산 방식으로 바이트댄스의 Stable-DiffCoder와 LLaDA를 돌렸을 때도 LiveCodeBench가 예산 768번의 19%에서 1만 2,288번의 31%로 올랐습니다.

정답 코드 한 편을 두 모델이 번갈아 썼습니다

논문에는 예산을 1만 2,288번까지 늘린 뒤에야 풀린 LiveCodeBench 문제의 탐색 나무가 실려 있습니다. 정답에 이른 가지는 Dream→LLaDA→LLaDA→LLaDA→Dream 순서였고, 다른 가지들은 모두 훨씬 낮은 점수에 그쳤습니다.

코드를 채운 순서를 보면 Dream-Coder가 먼저 풀이 단계를 개요로 잡았습니다. LLaDA가 이어받아 코드 끝부분의 요구 사항을 채우고 주된 구현을 시작했고, 마지막에 Dream-Coder가 다시 넘겨받아 나머지를 다듬어 완성했습니다. 어느 모델이 무엇에 강한지 사람이 미리 정해 준 적은 없습니다. 탐색이 점수를 따라가며 이 순서를 찾아냈습니다.

문제 하나에 H100 한 장으로 12분

실제로 돌리는 비용은 부록에 있습니다. H100 GPU 한 장에 Dream-Coder와 LLaDA를 함께 올리면 GPU 메모리는 35.64GiB로 예산과 상관없이 일정했습니다. 걸린 시간은 예산에 거의 비례해서, 예산 768번에서는 문제당 42.7초, 1만 2,288번에서는 702.9초가 걸렸고 그 가운데 647초가 모델이 가림을 벗기는 시간이었습니다. 제 계산으로는 LiveCodeBench 100문제를 가장 큰 예산으로 풀면 H100 한 장으로 19시간 반쯤 걸립니다.

메모리가 모자라면 쉬는 모델을 CPU 메모리로 내려 둘 수 있습니다. Dream-Coder는 14.2GiB, LLaDA는 14.9GiB를 쓰고, 한 번 옮기는 데 0.55초 안팎이 걸렸습니다. 1만 2,288번 예산에서 모델 교대는 문제당 평균 13.5번이라, 옮기는 시간은 전체에 비해 작았습니다.

국내 개발팀이 사내 코드에 붙여 본다면 라이선스와 채점 수단이 먼저 걸립니다. 논문에 쓰인 모델의 라이선스는 이렇습니다.

32개를 낸 세 모델 조합에 들어간 DiffuCoder는 애플의 머신러닝 연구 모델 라이선스로 풀렸고, 이 라이선스는 상업적 이용과 제품 개발을 허용 범위에서 뺍니다. 28개를 낸 두 모델 조합은 Apache 2.0과 MIT 모델로만 이뤄져 있습니다. UMF 코드 저장소는 기술 블로그와 논문 페이지 어디에도 링크돼 있지 않습니다.

채점 수단도 필요합니다. UMF의 탐색은 공개 테스트를 몇 개 통과했는지를 점수로 삼아 방향을 잡습니다. 논문이 공개 테스트를 일부러 지워 보니 10%를 지워도 정답률은 28%로 같았고, 50%를 지우면 25%, 80%를 지우면 24%였습니다. 테스트가 절반만 있어도 탐색은 대부분 작동했고, 테스트가 없는 과제에서는 MATH 실험처럼 답을 채점하는 보상 모델이 그 역할을 맡습니다.

사카나가 모델을 엮어 온 길

사카나는 UMF를 AB-MCTS, Sakana Fugu와 함께 AI의 집단지성 연구로 소개했습니다. 2024년에는 기존 오픈 모델을 진화 알고리즘으로 합쳐 새 모델을 만드는 모델 병합을 냈고, 2025년 7월에는 여러 프런티어 모델이 함께 시행착오를 거치는 AB-MCTS를 냈습니다. 여러 모델을 한 API 뒤에서 지휘하는 Fugu는 상용 서비스로 나왔고, 7월 16일에는 엔비디아의 Nemotron 등 오픈 모델을 Fugu에 넣는 협력을 발표했습니다. UMF를 발표한 같은 날 아침에는 보안 특화판 Fugu-Cyber도 내놨습니다.

이 연구들은 모두 모델 하나를 더 키우는 대신 이미 있는 모델을 엮어 성능을 얻는 방식입니다. UMF는 이 방식을 답을 쓰는 순서가 다른 확산 모델로 옮긴 사례이고, 사카나는 서로 다른 데이터와 방법으로 학습한 확산 모델이 늘수록 UMF가 쓸 수 있는 조합도 늘어난다고 적었습니다.

논문이 보인 것과 남긴 것

정리하면 이 논문은 세 가지를 새로 보였습니다. Dream-Coder에서는 온도를 올리거나 순서를 섞는 무작위가 한 번 뽑은 답보다 못했고, 모델 교대로 만든 다양성은 같은 예산에서 기존 방법들을 앞섰으며, 무작위가 없는 덕에 롤아웃의 절반가량에서 저장해 둔 계산을 다시 쓸 수 있었습니다.

저자들은 다음 과제로 어느 모델이 어느 부분을 맡을지 학습으로 예측해 탐색 비용을 줄이는 방법과, 문제 난이도에 따라 후보 모델과 교대 계획을 바꾸는 방식을 꼽았습니다. 다른 확산 모델 탐색법과도 견줬는데, ReMDM은 LiveCodeBench에서 예산을 늘려도 18%에 머물렀고 TReASURe는 MATH에서 10% 안팎이었습니다. 다만 저자들은 두 방법이 탐색 방식과 채점 방식이 달라 정확한 맞대결로 보기 어려운 참고치라고 밝혔습니다. 논문 끝의 영향 문단에는 코드를 더 잘 짜게 된 시스템이 악성 코드와 공격 코드 제작에 쓰일 수 있고, 추론 연산이 늘어 에너지와 비용도 함께 는다고 적었습니다.

측정은 벤치마크마다 100문제를 뽑아 이뤄졌고, 쓰인 모델은 70억~80억 파라미터급입니다. 네 번째, 다섯 번째 모델을 넣었을 때도 점수가 계속 오르는지는 논문에 없습니다. 네 번째 모델을 더한 점수와 UMF 코드의 공개 여부가 다음에 볼 대목입니다.

읽어 주셔서 고맙습니다.

초이 드림