H200에서 긴 컨텍스트 워크로드를 다루는 엔지니어라면, 모델을 한 글자도 바꾸지 않고 하네스만 바꿔서 장문 처리 토큰을 16분의 1로 줄일 수 있습니다. MIT의 Recursive Language Models(RLM) 논문 주장을 저희가 자체 H200 클러스터에서 직접 실측했습니다. 그 숫자가 어디까지 진짜이고 어디부터 조심해야 하는지, 그리고 최신 논문을 그대로 따라 돌릴 때 실제로 무엇이 부러지는지를 이 글에 담았습니다.

왜 하네스인가

RLM의 발상은 단순합니다. 긴 문서를 모델 컨텍스트에 통째로 밀어넣는 대신 문서를 실행 환경의 변수로 두고, 모델이 grep이나 부분 읽기 같은 프로그램적 접근으로 필요한 조각만 꺼내 보게 합니다. 원저자들은 여기서 한 걸음 더 나아갑니다. 이렇게 설계된 하네스는 구조가 비슷한 태스크들을 토큰 수준에서 거의 동일하게 만들어 버리므로 짧은 과제만 훈련해도 8배에서 32배 긴 과제로 일반화된다고 주장합니다. 일반화를 운반하는 것은 트랜스포머가 아니라 하네스라는 이야기입니다.

저희는 이 주장을 그대로 믿는 대신 저희 클러스터에서 숫자부터 확인하기로 했습니다. 실측은 두 갈래로 나눴습니다. 하나는 훈련 없이 하네스만 얹었을 때의 이득(E1)이고, 다른 하나는 논문의 RL 훈련을 H200 2장으로 축소 재현하는 일(E2)입니다.

E1: 같은 모델, 세 가지 하네스

미훈련 Qwen3-8B 한 대를 vLLM으로 서빙해 두고 같은 질문을 세 가지 방식으로 풀게 했습니다. 문서 전체를 프롬프트에 넣는 1-pass(논문과 동일하게 YaRN으로 131k 창을 확장), 문서를 잘라 조각마다 묻고 합치는 flat map-reduce, 그리고 RLM 방식 재귀 하네스입니다. 재귀 하네스에서 모델은 문서를 직접 보지 못합니다. grep과 부분 읽기, 하위 호출 액션만으로 답을 조립합니다.

과제는 OOLONG 계열을 본뜬 합성 장문 집계 QA 24문항입니다. 수백 개의 티켓 레코드가 흩어진 32k, 64k, 128k 토큰급 문서에서 특정 조건의 티켓 수를 세거나 최다 제품을 찾는 문제이며, 정답은 코드가 계산하고 채점은 exact match로 합니다.

하네스별 정확도 세 하네스의 티어별 정확도. 재귀 하네스만 32k와 64k에서 0.5에 도달하고, 두 대조군은 같은 값에 머뭅니다.

전체 정확도는 재귀 하네스가 41.7%(10/24), 1-pass와 map-reduce가 똑같이 16.7%(4/24)였습니다. 25%p 차이는 사전에 등록해 둔 채택 기준(+5%p)을 넘습니다. 다만 24문항 규모에서 이 차이는 통계적 유의성(McNemar 검정 p 약 0.11)에는 못 미치므로 정확도 이득은 방향성 있는 신호로 읽는 것이 정직합니다.

숫자가 확실하게 갈린 쪽은 비용입니다.

하네스별 토큰 비용 문항당 평균 토큰(로그 스케일). 재귀 하네스는 문서가 4배 길어져도 4천 토큰 언저리에 머뭅니다.

1-pass와 map-reduce는 문서 길이에 비례해 문항당 2만 8천에서 11만 토큰을 태웠지만, 재귀 하네스는 문서가 32k든 128k든 4천 토큰 안팎으로 일정했습니다. 24문항 전체로 보면 150만 토큰 대 9만 2천 토큰입니다. 16배입니다. 하네스가 태스크 길이와 모델이 실제로 읽는 토큰을 분리해 버린다는 논문의 quotient set 설명과 정확히 맞아떨어지는 패턴입니다.

map-reduce 대조군이 중요한 이유가 여기 있습니다. 만약 이득의 원천이 단순히 문서를 잘라 읽는 것이었다면 map-reduce도 좋아졌어야 합니다. 그런데 map-reduce는 정확도에서 1-pass와 완전히 같았고 토큰은 오히려 더 썼습니다. 이득은 청킹이 아니라 재귀 구조와 프로그램적 접근에서 나온다는 뜻입니다. 탐색적으로 뜯어보면 그림이 더 선명합니다. 단일 조건 카운트 문제에서 재귀 하네스는 6문항 전부를 맞혔고 두 대조군은 전부 틀렸습니다. grep이 결정론적 카운터 역할을 해 준 덕분입니다. 반면 두 조건을 조합해야 하는 문제는 재귀 하네스도 전멸했는데, 미훈련 모델이 조건을 합성한 grep 패턴을 스스로 만들어내지 못했기 때문입니다. 훈련이 전략을 가르쳐야 한다는 원논문의 동기를 저희 데이터가 반대편에서 확인해 준 셈입니다.

E2: 2장의 H200으로 RLM 훈련 돌려보기

논문 쪽 훈련은 prime-rl 위에서 GRPO로 이루어집니다. 원저자들은 Qwen3-30B-A3B를 8 GPU로 돌렸지만, 저희는 논문이 처음 훈련한 스케일인 Qwen3-8B에 LoRA(rank 32)를 붙여 H200 2장(트레이너 1장, vLLM 추론 서버 1장)으로 축소했습니다. 결론부터 말하면 16 스텝 훈련이 끝까지 완주했고, 스텝당 1분 반에서 8분, 트레이너 피크 메모리 18.5GiB로 141GB짜리 카드에 여유가 컸습니다. RLM 훈련의 진입 장벽이 생각보다 낮다는 것 자체가 수확입니다.

다만 과학적 결론은 보수적으로 남겨야 합니다. 훈련 컨텍스트(16k에서 32k)의 8배인 131k 평가에서 16 스텝 모델의 보상은 0이었는데, 하필 평가 직전 노드의 GPU가 리셋이 필요한 상태에 빠지면서 미훈련 베이스라인 재측정이 막혔습니다. 그래서 이 0이 아무것도 배우지 못했다는 뜻인지, 과제 자체가 이 스케일에서 바닥인지는 아직 가르지 못했습니다. 원논문은 저희보다 10배에서 30배 많은 스텝을 썼으므로, 16 스텝에서 전이 신호가 없다는 것이 논문 반증은 아닙니다. 같은 컴퓨트로 재귀 하네스를 끈 비재귀 대조군은 이번엔 돌리지 못했습니다. 그래서 이 글의 E2는 전이의 입증이 아니라 재현 가능성과 훈련 안정성의 확인으로 읽는 것이 정확합니다.

논문을 그대로 따라 돌리면 실제로 부러지는 것들

이번 실측에서 가장 밀도 높은 교훈은 어쩌면 숫자가 아니라 재현 과정 자체였습니다. 환경 성립까지 열한 번의 반복이 필요했고, 하나를 고치면 정확히 다음 관문이 나타났습니다. prime-rl은 서브모듈이 SSH URL로 박혀 있어 키 없는 포드에서 클론이 깨지고, rlm 레포의 예제 설정 파일은 prime-rl 최신 스키마와 이미 어긋나 있으며, flash-attn은 opt-in extra라 따로 설치해야 하고, H200(SM90)에서는 attn 자동 설정이 소스 빌드가 필요한 FlashAttention 3를 골라 트레이너가 즉사합니다. 모델 다운로드는 hf_transfer가 deprecated되어 Xet 고성능 플래그를 켜야 파일당 5분에서 수십 초로 내려옵니다. 여기에 심야의 클러스터 egress 불안정과 GPU 경합, 마지막에는 NVLink 상태 오류까지 겹쳤습니다.

이 목록을 남기는 이유는 불평이 아닙니다. 공개 두 달 안쪽의 논문 스택은 코드가 있어도 스키마와 CLI가 매주 움직이고 있어서, 재현 비용의 대부분이 알고리즘이 아니라 이런 드리프트에서 나옵니다. 각 실패를 로그 수확 지점으로 만들어 두면(트레이너 로그를 결과 파일에 병합하는 한 줄이 저희를 살렸습니다) 반복당 진단 시간이 극적으로 줄어듭니다.

무엇을 가져가면 되는가

긴 컨텍스트 파이프라인을 운영한다면, 훈련 없이도 재귀 하네스는 오늘 시도해 볼 만합니다. 특히 문서에서 조건 검색과 집계가 많은 워크로드라면 토큰 비용이 자릿수로 줄어드는 것을 저희처럼 확인할 가능성이 높습니다. 저희는 이 패턴을 Paxis 스킬 하네스의 궤적 압축 설계에 반영하는 검토에 들어갔고, 훈련 쪽은 보상 곡선과 베이스라인까지 수확되도록 계측을 보강해 재실행할 계획입니다.

실험의 모든 수치는 사전 등록된 기준으로 판정했고, 세 명의 적대적 리뷰 에이전트가 초기 집계의 산술 오류를 잡아내 본문 숫자는 교정본입니다. 이 글의 측정값은 시뮬레이션이 아니라 tkai-prod-compute-h200 클러스터의 실측입니다.

참고 자료

태그: grpo, h200, harness, long-context, paxis, prime-rl, qwen3, recursive-language-models, rlm, vllm

카테고리:

업데이트:

참고