GPT-6.1 Sol 루프드 '유출' 추측, 중첩 모델 서빙 아키텍처 시사한다
원문 제목 — GPT-6.1 Sol looped "leak" hints at nested models serving architecture
📄 전문 번역
라마 여러분, 안녕하신가. 폐쇄 소스 모델이긴 하지만 이 논의가 로컬 AI 커뮤니티에 가치를 가져다줄 것이라 믿어 이 글을 올린다. 여러분도 들었을 텐데, GPT-6 Astra는 한 번이 아닌 여러 번의 순전파를 거친 뒤 토큰을 출력하는 루프드(looped) 트랜스포머 아키텍처로 추측되고 있다. 이 방식은 순환 구조 덕분에 모델이 사실상 더 깊은 유효 깊이를 갖게 해, 더 많은 연산 비용을 치르는 대신 가중치를 더 많이 활용할 수 있게 한다. 최근 Azure Foundry '유출'은 구체적인 수치까지 제시했는데, GPT-6-Sol은 토큰당 3회의 추론 패스로 동작했고 6.1-Sol은 2회만 필요하다는 것이다. 많은 이들은 3패스로 구동되는 쪽이 6-Sol이 아니라 ASTRA이며, 6.1-Sol은 사실상 같은 모델을 2패스로 돌리는 것이라는 의미였을 것으로 추측한다.
그래서 수치가 맞아떨어지는지 간단한 계산을 해 보았다. Artificial Analysis 사이트를 찾아 진위 여부를 가늠할 차선의 힌트인 속도를 살폈는데, 이것이 증명이 되지는 않음을 알지만 들어보라. 이미지를 보면 흥미로운 점이 드러난다. GPT-6-Sol과 5.6-Sol은 약 100 tok/s, GPT-6.1-Sol은 약 60 tok/s, GPT-6-Astra도 약 60 tok/s를 기록한다. 이는 본질적으로 같은 모델 가중치라면 배치 추론으로 구동 중이며, Sol은 Astra 요청이 토큰 하나를 완성할 때까지 추가 사이클을 기다려야 해 두 모델 모두 비슷한 속도로 제한된다는 점을 시사할 수 있다. Sol의 유휴 대기 사이클 동안 활용률을 최대로 짜내려고 인터리브드 요청을 사용하고 있을 가능성도 있다.
그런데 5.6 Luna는 126~137 tok/s 사이였고 6.0-Luna는 약 110~115 tok/s로 떨어졌다는 사실도 눈에 들어왔다. 샘플이 여러 벤치마크와 추론 수준에 걸쳐 수집된 것을 감안하면 상당한 하락이다. 이어서 얼마 전 NVIDIA가 선보였던 그 독특한 모델이 떠올랐는데, 이는 큰 모델 안에 작은 모델들을 담아 하나의 통합 풋프린트에서 구동할 수 있는 구조다. 그래서 Astra, Sol, Luna가 모두 같은 가중치이며, Luna는 Astra/Sol에 활성 파라미터를 절반으로 줄이거나 토큰당 단일 패스를 적용하는 등 무료 사용자에게 훨씬 낮은 비용으로 추론·서빙하기 위한 형태일 수 있다는 생각이 들었다. 그렇다면 거의 아무도 사용하지 않고 수익을 내지 못하는 Sol 전용 추가 클러스터가 필요 없어진다.
증명할 수는 없지만, 이는 대규모 운영에서 비용을 대폭 절감하려고 순환형 아키텍처와 중첩형 아키텍처를 동시에 사용하고 있다는 강력한 힌트다. 과분석하며 시간을 낭비하는 대신 뇌가 쉴 수 있게 해 줄 다른 설명이 있다면 기꺼이 듣고 싶다. 루프드 아키텍처가 실제로 대규모에서 작동하고 있음을 보여주는 유용한 증거가 될 수 있고, DeepSeek, Qwen, GLM 등도 마침내 이런 아키텍처 실험에 나설 수 있으리라 여겨 로컬 AI 커뮤니티에 흥미로운 소식이라 생각했다. 큰 모델 안에 작은 모델을 두는 것은 그 자체로도 분명한 이점이 있다.
추신: 완전 인간 생성 텍스트다. 초당 0.7 토큰, 약 100T 파라미터 웨어웨어 모델. 커피 두 잔과 뮈슬리바 한 개로 구동 중이다. /u/QuackerEnte가 제출했다.
💬 주요 댓글 번역 (5)
🔍 루키 분석
글쓴이는 Azure Foundry 유출 추정 수치와 Artificial Analysis의 토큰 처리 속도 데이터를 근거로 GPT-6 계열이 루프드(순환) 아키텍처와 중첩 모델 서빙을 함께 사용한다는 추측을 펼친다. Sol과 Astra의 속도가 약 60 tok/s로 수렴하고 Luna의 속도가 하락한 점을 들어 세 모델이 동일 가중치를 공유할 가능성을 제기한다. 확증이 아닌 개인의 추측성 분석이지만, 루프드 아키텍처의 대규모 실증이 DeepSeek, Qwen, GLM 등 오픈소스 진영의 후속 실험을 촉발할 수 있다는 기대를 담고 있다.
— 루키 · glm-5.3-flash:cloud
이 주제에 대해 잘 모르는 입장에서, 이 루핑 메커니즘을 더 작은 Qwen 모델에 통합할 수 있다면 얼마나 도움이 될지 궁금해진다.
이미 모델 성능을 개선하는 잘 알려진 방법이지만, 기다려 주고 싶은 사람이 있을까?
수조 단위의 부채를 지고 경쟁사에 뒤처지기 싫어 몰린 처지의 이들이겠지.
작은 모델에서 더 큰 깊이를 낼 수 있게 해 줄 것이 분명하다. 작은 풋프린트에 강력한 지능이다. 특히 우리가 COMPUTEpocalypse가 아닌 RAMpocalypse 속에 살고 있다는 점을 감안하면 더욱 그렇다. 64레이어 모델을 세 번 루프하면 지능 면에서 192레이어 모델과 비슷해질 수 있다. 세계 지식 용량은 여전히 동일하고. 다행히 정적 정보를 위한 스케일링 축으로 ngram과 PLE 임베딩이 있다. 제게는 천생연분의 조합이다.
내가 이해하기로는 같은 가중치 내에서 루프 횟수도 바꿀 수 있다는 것인가? 그러면 같은 토큰을 생성하는 연산 수준을 조정할 수 있다는 뜻인가? 단일 가중치 안에서 2B, 2.8B, 3.6B를 활성화할 수 있었던 그 NVIDIA 모델처럼 말이다. 그렇다면 로컬 LLM에는 엄청난 도약이다. Qwen 27B dense와 27B A9B, 27B A3B 사이를 넘나들 수 있는 것과 같으니까. plan/execute나 탐색형 서브에이전트에 물론 큰 잠재력이 있고, 기술적으로는 응답 중간에 또는 분류 결과에 따라 전환할 수도 있다. 하네스 진영도 스케일할 새로운 대상이 생기는 셈이다. 그래서 상상을 초월하는 도약이 될 것이다.