언어 모델 구조를 평가할 때 층 수나 파라미터 규모만큼 중요한 것이 상태의 수명 주기다. 어떤 정보를 토큰 사이에 남기고, 언제 초기화하며, 프롬프트에서 생성 단계로 어떻게 넘기는지가 실제 계산 구조를 결정하기 때문이다. Recurrent Looped Transformer (RLT)은 이 문제를 모델 내부의 핵심 설계로 끌어올린다.
핵심은 더 깊은 모델이 아니라 이어지는 상태다
Yifan Zhang이 제안한 Recurrent Looped Transformer (RLT)은 인과적 인코더와 순환 디코더를 결합한다.1 인코더가 전역 키·값 메모리를 구성하면, 디코더는 현재 입력만 처리하는 대신 앞선 토큰에서 형성된 상태를 이어받아 계산한다.
이때 상태는 하나의 벡터로 끝나지 않는다. 이전 토큰의 순환 출력과 디코더 각 층의 슬라이딩 윈도 어텐션 KV 캐시가 함께 전체 상태를 이룬다. 순환 출력은 다음 토큰의 인코더 표현과 병합되고, 각 디코더 층은 자신이 보존한 최근 키와 값을 참조한다. 따라서 이 설계에서 상태는 부가적인 최적화가 아니라 모델 동작을 정의하는 구성 요소에 가깝다.
이 관점은 RLT를 단순히 층이 많은 Transformer로 해석하는 것과 다른 평가 기준을 요구한다. 기준 구성은 토큰마다 인코더 48개 층과 디코더 48개 층을 실행하지만, 관심의 초점은 96개 논리 블록이라는 정적 수치보다 디코더 경로가 토큰 진행에 따라 누적된다는 점에 있다. t개 토큰 뒤 상태로 이어지는 디코더 경로는 48t개 블록 규모로 길어진다.1
서빙 경계가 모델의 일부가 되는 이유
RLT에서는 프롬프트와 응답에 동일한 상태 전이 규칙이 적용된다. 응답 생성을 시작할 때 디코더 상태를 초기화하지 않고, 프롬프트 처리 과정에서 만들어진 상태를 계속 사용한다.1
이는 구현 검증에서 중요한 구분을 만든다. 같은 가중치를 사용하더라도 프롬프트 종료 시 순환 출력이나 층별 캐시를 버린다면 보고서가 정의한 계산을 그대로 재현했다고 보기 어렵다. 슬라이딩 윈도 역시 단순한 메모리 절감 장치로만 볼 수 없다. 크기 W의 윈도는 현재 토큰을 포함하고 다음 갱신을 위해 과거 항목을 최대 W-1개 보존하므로, 어떤 캐시가 어느 층에 남아 있는지가 다음 상태에 직접 관여한다.
결국 실제 시스템에서는 다음과 같은 상태 관리 문제가 모델 평가와 분리되기 어렵다.
프롬프트 처리와 생성 사이에서 순환 출력이 정확히 전달되는가
디코더 각 층의 KV 캐시가 정해진 윈도 규칙에 따라 갱신되는가
요청 경계와 모델이 요구하는 상태 경계가 일치하는가
긴 시퀀스에서 상태 보존 비용이 지연 시간과 메모리에 어떤 부담을 주는가
긴 계산 경로가 곧 더 나은 추론은 아니다
토큰이 늘어날수록 계산 경로가 길어진다는 구조적 특성은 새로운 가능성을 제시하지만, 그 자체로 성능 향상을 입증하지는 않는다. 정보가 오래 전달되는지, 반복 계산이 유용한 표현을 형성하는지, 긴 경로에서도 학습과 생성이 안정적인지는 각각 실험으로 확인해야 할 문제다.
특히 비교 실험에서는 정확도 하나만으로 결론을 내리기 어렵다. 순환 상태와 층별 캐시를 유지하는 비용까지 포함해 처리량, 토큰당 지연 시간, 메모리 사용량을 함께 살펴야 한다. 상태를 일부 제거한 변형과 원래 규칙을 지킨 구성을 구분하는 것도 필요하다. 그렇지 않으면 구조 자체의 효과와 구현상 절충을 혼동할 수 있다.
다음 공개에서 확인할 항목
현재 코드, 가중치, 측정 결과가 공개되지 않았기 때문에 Recurrent Looped Transformer (RLT)의 실용적 가치는 아직 검증 단계에 들어가지 못했다.1 향후에는 단순한 결과 수치뿐 아니라 상태 초기화 조건, 캐시 구현, 시퀀스 길이별 비용, 비교 기준이 함께 제시되는지를 봐야 한다.
RLT가 던지는 중요한 질문은 모델을 얼마나 깊게 쌓을 수 있느냐보다, 토큰 사이에 이어지는 계산을 얼마나 정확하고 효율적으로 유지할 수 있느냐다. 재현 가능한 구현이 공개된다면 성능 순위보다 먼저 상태 연속성이 설계대로 보존됐는지 확인하는 것이 타당하다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.