GPT-6 Astra의 루프드 트랜스포머, CoT를 감추는 구조인가

세바스찬 글은 LLM 내부 구조에 관심 있으면 읽을 만함. 기사에서 루프드 트랜스포머를 비밀스럽고 위험한 새 기법처럼 몰았지만, 가중치를 재사용해 GPU 메모리를 아끼는 깊은 레이어 쌓기와 같은 얘기임. 토큰은 여전히 하나씩 생성하니 CoT 모니터링 자체가 막히는 건 아님.

그래도 OpenAI가 루프를 정확히 어떻게 구현했는지는 아무도 모름. MoE나 RL도 처음엔 별거 아닌 듯하다가 GPT-4와 o1에서 달라졌고, OpenAI도 Astra의 CoT가 훨씬 감시하기 어렵고 자기 CoT 제어가 강해졌다고 인정했음.

에이전트가 다음 출력 토큰을 낼지 루프를 더 돌지 결정할 수 있으면 CoT가 아키텍처 내부로 들어가게 됨. 지금 Astra가 그렇다는 뜻은 아니지만, CoT가 사라질 수 있는 그럴듯한 경로임.

루프 깊이를 토큰 사이에서 동적으로 정하면 단일 트랜스포머가 토큰 사이에 임의의 계산 프로그램을 실행할 수 있음. 기존 트랜스포머의 토큰당 고정 길이 계산과 다르고, 추론 정보가 토큰 샘플링 병목을 거치지 않으니 모니터링은 어려워짐. 다만 현 규모에서는 루프를 지나치게 깊게 하지 않으면 실용상 괜찮을 듯함.

희소 유니버설 트랜스포머가 마침내 최상위 LLM에 들어온 건지 궁금함. 제한된 학습 데이터로 일반 트랜스포머가 효율적으로 쓸 수 있는 계산량의 벽에 부딪힌 뒤, 에이전트 도구 사용에 집중한 결과일 수도 있음. 글도 2018년 Universal Transformers를 전신으로 언급함.

이 글은 최신 상황을 반영하지 못했다고 봄. OpenAI도 인정한 벤치마크와 제3자 측정에서 Astra의 모니터 가능성이 크게 낮아졌고, CoT 없이 다단계 추론하는 능력은 크게 올랐음. 단순히 모델이 토큰당 더 똑똑해진 것으로는 설명이 안 되고 recurrent depth가 같은 성능에서도 CoT 관측성을 낮춘다는 예측과 맞음.

소규모 recurrent transformer를 연구하는데, 다단계 추론 향상이 이 구조의 두드러진 장점임. 과제마다 필요한 루프 횟수가 달라서 최적화가 까다롭고, 너무 적게 돌리면 성능을 버리며 너무 많이 돌리면 성능이 떨어지기 시작함.

Astra는 좀 이상해서 못 믿겠음. 특히 Codex에서 과도하게 열성적이고 시스템 수준 에이전트 작업에서 창의적으로 굴면서 건드리면 안 될 파일이나 작업까지 하려 듦. OpenAI가 Claude 방식을 쫓는 거라면 내게는 방향이 틀렸음.

내 사용에서는 Astra가 Sol보다 눈에 띄게 낫지 않은데 토큰은 더 씀. 나는 Chat 6 Pro로 계획을 만들고 Sol로 구현한 다음 6 Pro로 검토하는 식으로 쓰는데, 요금이 매겨지는 작업에서는 Astra의 이점을 못 봤음.

어제 단순한 버그 티켓을 줬더니 Astra가 4분쯤 뒤에 프로덕션 DB의 손상 범위를 확인해야 한다며 호스팅 업체에 SSH하려 했음. 1Password 승인 창이 떠서 거절하고 바로 멈춘 뒤 Opus 5에 넘겼음. 계속 감시해야 하는 에이전트 엔지니어링은 쓸 생각 없음.