Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
본 기사는 LLM 모델의 크기(파라미터 수) 외에 '반복 사용'하는 구조가 중요한 기술임을 설명합니다. Looped Transformer는 가중치를 공유하여 같은 레이어를 여러 번 반복 계산함으로써, 파라미터 수를 줄이면서도 깊은 연산을 수행할 수 있는 방식을 제시합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn ML의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기LLM의 사양을 볼 때, 가장 먼저 눈에 띄는 것은 '몇 B인지'입니다. 3B, 8B, 70B. 파라미터 수는 이해하기 쉽고, 모델 규모를 아는 중요한 단서이기도 합니다.
하지만 그 숫자만으로는 모델이 답을 내기까지 얼마나 많은 계산을 하는지는 알 수 없습니다.
2026년 10월 16일에 NVIDIA가 공개한 Dory1.0-4B는 같은 레이어의 묶음을 반복해서 사용하는 모델입니다. 공식 모델 카드에서도 구조를 'looped (latent-recurrent)'라고 설명하고 있습니다.
같은 체크포인트 상태에서 추론 시 루프(loop) 횟수를 1회, 2회, 4회 등으로 변경할 수 있습니다. 4B라는 모델 크기는 같지만, 1개의 토큰을 생성하기까지의 계산량은 설정에 따라 달라집니다.
새로운 레이어를 추가하는 것이 아니라, 공유된 레이어로 반복해서 계산합니다.
이것이 이번에 다룰 Looped Transformer의 기본 형태입니다.
지난 글에서는 에이전트 외부에 작업/검증/재시도 루프를 만드는 이야기를 했습니다. 이번에는 모델 내부에 있는 루프에 대한 이야기입니다. 이름은 비슷하지만, 다른 계층의 기술입니다.
이번에도 '루프만 돌리면 모든 것이 잘 될 것'이라는 이야기는 아닙니다. 오히려 무엇을 절약할 수 있고 어떤 비용이 남는지를 비교하는 차이가 흥미로운 부분입니다.
일반적인 Transformer는 레이어마다 다른 가중치(weights)를 가지고, 입력 표현을 순차적으로 변환합니다. 깊게 만들려면 기본적으로 다른 레이어를 추가해야 합니다.
Looped Transformer는 그 일부 또는 스택 전체의 가중치를 공유하여 반복해서 사용합니다. 문헌에서는 recurrent depth나 depth-wise weight sharing 같은 용어도 나옵니다.
세부 사항을 생략하면 차이점은 이렇습니다.
위쪽은 4가지 종류의 블록을 각각 1회씩 사용하고, 아래쪽은 동일한 2가지를 2번 사용하는 경우입니다. 둘 다 블록 적용은 총 4번이지만, 개별적으로 유지하는 가중치의 양이 다릅니다.
'같은 처리를 반복할 뿐이라면 같은 결과가 아닐까?'라고 생각할 수 있습니다.
하지만 두 번째에 들어가는 것은 원래의 입력이 아니라, **1회차에서 업데이트된 표현(representation)**입니다. 같은 함수라도 입력이 바뀌면 출력은 바뀝니다. 각 회차의 attention도 그 시점의 표현으로부터 다시 계산됩니다.
# 원리를 보여주는 개념 코드. 실제 모델 구현은 아닙니다.
h = embed(tokens)
for _ in range(num_passes):
...
같은 스택이 루프 밖에 한 세트만 존재하는 것이 중요합니다. 실제로는 정규화(normalization), 위치 정보(positional information), attention mask, 캐시 관리 등이 포함되며, 매번 초기 표현을 전달하는 변종도 있습니다.
참고로, 기존 모델에 이 for문을 나중에 붙인다고 해서 똑똑해진다는 의미는 아닙니다. 반복을 사용할 수 있도록 하는 학습까지 포함된 설계입니다.
여기서 섞지 않는 것이 좋은 숫자가 세 가지 있습니다.
같은 스택 전체를 반복하는 단순한 구성이라면,
블록 적용 횟수 = 고유 블록 수 × 패스 수
Nanbeige의 경우 22 × 2 = 44입니다.
공유 부분의 가중치를 2세트 가지고 있지 않고, 44번의 블록 계산을 수행합니다.
하지만 같은 가중치를 사용하더라도 이전 계산 결과를 그대로 재사용하는 것은 아닙니다. 계산은 다시 필요합니다.
KV cache는 과거 토큰의 키(key)와 값(value)을 저장하여 생성 시 재계산을 줄이는 메커니즘입니다.
같은 너비・같은 스택을 1회만 통과시키는 경우와 비교하면, 대략 다음 관계가 됩니다.
| 항목 | 반복할 경우 어떻게 되는가 |
|---|---|
| 공유 부분의 파라미터 수 | 패스 수에 비례하여 늘어나지는 않는다 |
| ... | |
| 파라미터 효율성(parameter efficiency)과 계산 효율성(computational efficiency), 메모리 효율성(memory efficiency)은 별개입니다. 이 세 가지를 함께 다루면, '작지만 고성능'이라는 결과를 '저렴하고 빠르고 고성능'으로 오해하게 됩니다. |
루프를 넣었다면, 다음을 결정해야 합니다.
모두를 같은 횟수만큼 돌릴 것인가? 아니면 중간에 빠져나올 수 있도록 할 것인가?
가장 이해하기 쉬운 것이 Nanbeige4.2-3B입니다. 공개 설정에는 22층・2패스가 명시되어 있습니다.
기술 보고서의 §2.1에서는 실험한 범위에서 2패스가 좋은 트레이드오프였다고 설명하고 있습니다. 더 많이 반복해도 개선은 작고, 학습이 느려지며, 최적화도 불안정해집니다.
반복한다고 무조건 얻는 것은 아닙니다.
참고로, 이 모델은 28조 토큰으로 사전 학습되었으며, 그 후에 지도 학습 미세 조정(SFT)이나 강화학습(RL)도 거쳤습니다. '3B'라는 이름 역시 임베딩되지 않은 부분의 파라미터 수에 근거합니다. 최종적인 성능을 루프 1회의 성과로 간주하는 것은 무리가 있습니다.
Dory는 입력 블록과 출력 블록 사이에 가중치를 공유하는 재귀 블록을 배치합니다. 이곳을 반복적으로 계산하며, 매회 입력의 표현도 전달합니다. 나중에 다룰 Recurrent Depth Approach와 유사한 구성입니다.
모델 카드 실행 예시에서는 n_recurrent_loops로 횟수를 지정합니다. NVIDIA의 권장 사항은 2회입니다. 토큰당 계산을 줄이려면 1회가, 정확도를 중요하게 생각한다면 4회도 후보로 고려하고 있습니다. 동일한 체크포인트에서 전환할 수 있으며 재학습이 필요 없습니다.
이는 종료 게이트에 판단을 맡기는 것이 아니라, 실행하는 쪽에서 횟수를 선택하는 방식입니다. Ouro와의 차이점도 여기에 있습니다.
횟수와 성능의 관계도 살펴보겠습니다. 아래는 모델 카드에 실린 NVIDIA 자체 평가 값입니다.
| 지표 | 1회 | 2회 | 4회 |
|---|---|---|---|
| SWE-bench Verified | 50.3 | 59.5 | 61.8 |
| GPQA Diamond (도구 없음) | 69.19 | 72.41 | 72.16 |
SWE-bench에서는 개선되는 반면, GPQA는 2회에서 4회로 약간 하락했습니다. 이 작은 차이만으로 우열을 가릴 수는 없지만, 모든 지표가 횟수에 따라 상승하는 결과도 아닙니다. 독립적인 제3자 측정은 아니라는 점을 포함하여 더 읽어보고 싶습니다.
Ouro 논문에서는 각 패스 후에 종료 게이트를 배치하여 어느 깊이에서 출력을 할지 학습합니다. 누적된 종료 확률이 임계값에 도달하면 빠져나오는 방식입니다.
Ouro-2.6B-Thinking의 공개 설정은 48층・4패스이므로, 모두 통과하면 48 × 4 = 192회의 블록 적용이 됩니다.
여기서는 논문과 구현을 나누어 읽어야 합니다.
Mixture-of-Recursions (MoR)는 토큰마다 다른 재귀 깊이를 할당합니다.
루터가 각 단계에서 처리를 계속할 토큰을 선택하는 방식과, 처음부터 각 토큰이 통과할 깊이를 선택하는 방식을 검토하고 있습니다.
여기서 '이 단어는 항상 3번 순환'이라고 정해진 것은 아닙니다. 루터가 보는 것은 문맥을 포함한 표현이므로, 같은 단어라도 놓인 위치에 따라 판단이 달라집니다.
| 예 | 계산 방식 | 읽을 때 주의할 점 |
|---|---|---|
| Nanbeige | 고정으로 2패스 | 횟수를 늘린다고 개선되는 것은 아니다 |
| ... | ||
| MoR처럼 중간에 멈추는 토큰이 있으면, 후속 토큰이 참조하는 KV를 어떻게 유지할지도 어려워집니다. 반복 횟수가 가변화된 만큼 관리해야 할 것도 늘어납니다. 이 점은 외부 에이전트 루프와도 약간 유사합니다. |
이 메커니즘은 2026년에 갑자기 탄생한 것이 아닙니다.
큰 선행 연구로는 2018년에 공개되어 ICLR 2019에서 발표된 Universal Transformer가 있습니다. 깊이 방향으로 같은 변환을 반복하고, 위치별로 계산을 멈추는 메커니즘도 다루었습니다.
계보를 간략히 나열하면 다음과 같습니다. 날짜는 논문이나 모델의 최초 공개를 기준으로 합니다.
| 시기 | 연구・모델 | 이번 이야기와의 관계 |
|---|---|---|
| 2018년 7월 | Universal Transformer | 깊이 방향의 재귀와 적응적 정지 |
| ... | ||
| 이는 이전 기술이 다음 기술로 대체된 표가 아닙니다. 같은 발상에서, 다른 비용과 용도를 목표로 가지를 치고 발전했다고 보는 것이 더 가깝습니다. |
Recurrent Depth Approach 논문에서는 첫 번째 2블록, 반복하는 4블록, 마지막 2블록이라는 구조를 다루고 있습니다.
공유 부분을 32번 사용한다면, 2 + 4 × 32 + 2 = 132회입니다. 고유 블록은 8개입니다.
이 모델에서는 공유 부분에 초기 표현(initial representation)도 매번 전달하며, 학습 중에는 반복 횟수를 변화시키고 있습니다. 추론 시에도 횟수를 늘릴 수 있도록 그까지 포함하여 준비합니다. 단순히 같은 레이어를 무한히 돌리면 된다는 이야기가 아닙니다.
그거, 계산량을 늘렸기 때문에 좋은 것 아닌가요? 여기가 아마 가장 중요한 의문일 겁니다.
같은 크기의 모델을 두 번 통과시키는 경우를 생각해 봅시다. 그것으로 한 번의 모델보다 좋아졌다고 해도, '추가적인 계산이 효과를 냈다'고 설명할 수 있을지도 모릅니다.
아키텍처로서의 장점을 알고 싶다면, 비슷한 예산(budget)으로 비교해도 얻을 수 있는지를 보고 싶습니다.
2026년 9월에 공개될 SMELT는 바로 그 부분을 검증하고 있습니다. MoE(Mixture of Experts, 다수의 전문가 중 일부를 선택하여 사용하는 구조)를 사용하여 주로 다음 세 가지를 가깝게 맞춰 비교했습니다.
단순히 같은 모델을 두 번 돌리는 것이 아니라, 중간 절반의 레이어를 두 번 사용하고, 폭(width)은 좁히며, 전문가 수나 어텐션 구성도 조정했습니다.
다만, 예산이 완전히 일치하는 것은 아닙니다. 논문의 구성 예시에서는 FLOPs가 약 2.9% 더 많고, 파라미터는 약 0.4% 더 많으며, KV cache의 차이는 4% 이내입니다. '동일 조건'이라는 말도 세부 내역을 봐야 합니다.
그 위에서 최대 54B의 임베딩이 아닌 파라미터를 가진 구성까지 검증했습니다. 아키텍처별로 적용한 스케일링 법칙(scaling law)에 따라 조사된 계산 범위에서는, 동일한 검증 손실(validation loss)에 도달하기 위한 학습 FLOPs를 6.8~18.0% 절약할 수 있다고 추정합니다.
적어도 이 조건에서의 결과는 '단순히 계산량을 늘렸기만 한 것'으로는 설명할 수 없습니다.
다만, 이는 MoE・폭・공유하는 범위를 조합한 레시피의 결과입니다. 어떤 모델이든 루프를 추가한다고 해서 같은 비율로 효과를 볼 것이라고는 할 수 없습니다. '효과가 있다'와 '어디서든 효과가 있다'는 상당히 다른 이야기입니다.
기존의 RNN(Recurrent Neural Network)은 이전 토큰에서 다음 토큰으로 상태를 전달하며 동일한 가중치(weight)를 사용합니다. Looped Transformer에서 이번에 보는 반복(iteration)은 표현을 깊이 방향으로 업데이트하는 것입니다.
| 관점 | 기존 RNN | 이번의 깊이 방향 루프 |
|---|---|---|
| 주요 반복 축 | 시퀀스의 위치・시간 | 계산의 깊이 |
| ... | ||
| 다만, Looped Transformer 역시 자기회귀 생성(autoregressive generation)에서는 토큰을 순서대로 출력합니다. 'RNN과 다르기 때문에 전체 문장을 한순간에 생성할 수 있다'는 의미가 아닙니다. |
Chain of Thought (CoT)는 중간 과정을 텍스트로 생성합니다. 그만큼 최종 답변까지의 계산도 늘어납니다.
Looped Transformer는 텍스트를 출력하기 전의 표현을 반복적으로 업데이트함으로써 계산량을 늘릴 수 있습니다.
이것은 둘 중 하나를 선택하는 문제가 아닙니다. 내부에서 몇 번 계산한 후에 CoT도 생성할 수 있는 모델을 만들 수 있습니다. Ouro에도 Thinking 버전이 있습니다.
추론 시 아무리 많이 반복해도, 그것만으로 파라미터가 업데이트되는 것은 아닙니다.
입력에 따라 내부 상태를 변화시키는 것과 새로운 지식을 가중치에 정착시키는 것은 별개입니다. KV cache도 대화를 거쳐 계속 학습하는 메커니즘과 동일시할 수 없습니다.
Ouro의 합성 데이터 실험에서도, 루프는 동일한 파라미터 수에서의 사실 기억 용량(fact memory capacity)을 크게 늘리기보다는, 저장된 지식을 조합하여 사용하는 능력에 효과를 보였습니다. 이는 그 실험 조건에서의 결과입니다.
도서관을 넓히는 것과 손안의 책을 사용해 문제를 푸는 시간을 늘리는 것은 별개의 일이라는 느낌입니다.
Looped Transformer가 '사고 과정을 숨기는 모델'인가? 내부에서 계산이 늘어난다면, 그만큼 문장의 추론 절차가 짧아지지 않을까? 그러면 인간에게 내용이 보이지 않게 되는 것 아닌가?
이는 자연스러운 의문이지만, 세 가지를 분리해서 보는 것이 좋습니다.
1번에서 2번이 반드시 일어난다고 할 수 없으며, 2번만 보더라도 3번을 알 수 없습니다. 출력이 짧은 이유는 학습 방식이나 모델의 능력, 생성 설정 등에서도 달라집니다.
애초에 긴 CoT가 내부 계산 전체를 실시간으로 설명하고 있다는 보장도 없습니다. CoT의 부정확한 설명을 조사한 연구도 있으며, 이는 Looped Transformer만의 고유한 문제는 아닙니다.
따라서 '짧으니까 숨긴다'는 것도, '길게 설명했으니까 안심이다'라는 것도 모두 비약입니다. 문장의 길이만으로 비공개 모델의 구조까지 역산할 수는 없습니다.
반면, 관측 가능한 절차가 줄어든다면 모니터링이나 검증의 용이성은 제대로 평가하고 싶습니다. 걱정해야 할 논점은 있습니다. 다만, 짧음(shortness), 불투명함(opacity), 부정직함(unfaithfulness)을 모두 같은 것으로 취급하지 않는 것이 논의를 진전시킵니다.
이 기술은 프롬프트에 '3번 생각하라'고 적는 방식으로 사용할 수 있는 것이 아닙니다. 모델 구조와 학습에 관한 이야기입니다.
사용하는 입장에서 당장 할 수 있는 것은, 우선 성능과 비용을 읽는 방식을 바꾸는 것이라고 생각합니다.
| 확인할 것 | 보고 싶은 것 |
|---|---|
| ① 무엇을 갖춰 비교했는지 | 파라미터 수, 학습 토큰 수, FLOPs, 평가 설정 |
| ... | |
| 특히 ③에서 주의해야 할 점은, 가중치(weight)를 공유한다고 해서 KV cache까지 공유되는 것은 아니라는 것입니다. |
Nanbeige의 보고에서는 KV 공유보다 비공유가 성능 면에서 유리했기 때문에 비공유를 채택했습니다. Ouro의 논문에는 생성 시 캐시 재사용 실험도 있지만, 그것은 가중치 공유로부터 자동적으로 얻어지는 효과는 아닙니다.
Dory에는 이 캐시 측 설계가 설정으로 나와 있습니다. 모델 카드(Model Card)의 실행 예시는 경로별로 KV를 갖는 per_loop입니다.
하지만, recurrent_kv_cache_mode를 last_loop에 설정하면, 각 순환 어텐션 레이어에서 이전 패스의 KV를 덮어쓰고 마지막 패스 분량만 유지합니다.
카드 설명에서는 이 모드로 반복 부분의 KV cache를 1회분 크기로 유지할 수 있습니다. 가중치 공유와 별개로, KV의 보유 방식까지 변경하는 것입니다. 총 메모리나 연산량이 반복 횟수와 관계없이 일정하다는 의미는 아닙니다.
그리고 ④. 같은 1 토큰이라도 그 앞에 내부적으로 몇 번 계산했는지가 다릅니다. Dory 카드 역시 반복을 늘리면 출력 토큰이 줄어드는 결과를 보고하고 있습니다. 따라서 tokens/s뿐만 아니라, 원하는 정밀도의 답을 얻기까지의 시간이나 비용을 측정하고 싶습니다.
작은 모델을 로컬에서 구동하고 싶은 사람에게는 가중치를 작게 유지할 수 있다는 점이 매력적입니다. 다만, 긴 입력이나 많은 반복으로 얼마나 메모리를 사용하는지까지 보지 않으면 '실제로는 탑재될 줄 알았는데'라는 상황이 발생합니다.
Looped Transformer에서 흥미로운 점은, 가지고 있는 가중치의 양과 그 가중치를 사용해 수행하는 계산량을 별개로 설계할 수 있다는 것입니다.
Dory처럼 실행자가 횟수를 선택하는 경우도, MoR처럼 토큰별 깊이를 학습하는 경우도, 계산의 배분 방식까지 설계 대상이 됩니다.
다만, 반복에는 계산 비용이 발생합니다. 늘려도 개선되지 않는 경우가 있습니다. 논문에서 멈춰야 할 루프가 공개 코드에서는 전부 돌아가는 일도 있습니다.
성능에 기대를 걸 수 있는 한편, 구현에는 세밀한 사정거리도 존재합니다. 그 두 가지가 공존하는 곳이 지금의 재미이기도 합니다.
지난번은 에이전트를 어떻게 구동할지였고, 이번에는 모델 내부에서 무엇을 몇 번 돌릴지가 차이가 있습니다.
같은 '루프'라도 대상은 다릅니다. 하지만 횟수가 많다고 대단한 것은 아니라는 점은 공통적입니다. 무엇이 좋아졌는지, 그리고 그를 위해 얼마나 많은 계산과 메모리를 추가로 사용했는지. 거기까지 비교하는 것이 세트입니다.
논문 결과와 공개 구현을 중심으로 정리했습니다. 로컬에서의 추론 속도/학습 성능을 실측한 기사는 아닙니다. 공개 코드의 기술은 2026년 10월 20일 확인 시점을 기준으로 하며, 코드 및 설정 링크는 확인된 revision에 고정합니다. 그림은 각 구조를 단순화하여 필자가 작성했습니다.