Executive Summary

주요 수치

출처: Donaghy 외, arXiv:2609.17380 (2026-09-15) · 감사 하네스 저장소

보고서는 지금의 모델 공개를 세 층으로 나눈다. API로만 닿을 수 있는 폐쇄형, 최종 가중치만 여는 오픈 웨이트, 데이터와 레시피까지 함께 내놓는 오픈 소스다. 그리고 넷째 층을 제안한다. 학습 중 모든 데이터 표본에 가해진 모든 연산을 누구나 자기 기계에서 비트 단위로 다시 확인할 수 있는 상태이고, 저자들은 이것을 완전 감사 가능(fully auditable)이라 부른다.

새 층을 세우려면 낱말 둘을 먼저 갈라 놓아야 한다. 결정성은 같은 기계에서 같은 환경으로 두 번 돌렸을 때 같은 값이 나오는 성질이다. 대부분의 딥러닝 프레임워크가 결정적 모드라는 이름으로 제공하는 것이 이쪽이다. 재현성은 더 센 요구다. 프로세서와 GPU처럼 서로 다른 하드웨어에서도 마지막 비트까지 같은 값이 나와야 한다. 앞의 것이 참이어도 뒤의 것은 거짓일 수 있고, 지금까지 오픈 소스 모델들이 놓여 있던 자리가 바로 거기다.

이 구분이 왜 실무에 걸리는지는 초록에 적혀 있다. 다른 기계에서 같은 결과를 만들 수 없으면, 내가 내려받은 체크포인트가 정말 공개된 레시피로 만들어진 것인지 확인할 방법이 없다. 그 빈자리에 미공개 데이터와 주입된 편향, 백도어가 들어설 수 있다. 학습 증명이나 학습 데이터 증명 같은 기존 기법은 확률적 보증만 주는데, 백도어는 데이터 몇 점으로도 심을 수 있어 표본 검사의 그물을 그대로 빠져나간다.

출발점은 학교에서 배운 결합법칙이 컴퓨터 안에서는 참이 아니라는 사실이다. 부동소수점은 실수 가운데 일부만 정확히 담고 나머지는 가장 가까운 값으로 반올림한다. 세 수를 더할 때 앞의 둘을 먼저 더하느냐 뒤의 둘을 먼저 더하느냐에 따라 반올림이 끼어드는 자리가 달라지고, 결과의 마지막 비트가 달라진다. 긴 합을 수천 개 레인에 쪼개 더하는 GPU와 한쪽 끝에서 다른 끝까지 차례로 더하는 프로세서는 애초에 다른 순서로 더한다.

보고서는 비트 단위 동일성을 깨는 지점을 다섯 가지로 정리하고, 각각에 RepOps가 붙드는 방법을 짝지어 둔다.

네 번째 줄인 서브노멀 항목이 하드웨어의 성격을 특히 잘 보여 준다. 0에 아주 가까운 값을 애플 GPU는 기본적으로 0으로 밀어 버리고, 프로세서와 엔비디아 GPU는 살려 둔다. 같은 값이 한쪽에서는 남고 다른 쪽에서는 사라지니 학습 궤적이 갈린다. 해법은 가장 너그럽지 않은 쪽에 맞추는 것이다. 굳이 그럴 필요가 없는 하드웨어에서도 일부러 서브노멀을 버린다. 재현성을 위한 결정은 대체로 이 모양이라고 저자들은 정리한다. 여러 기계에서 같아지려면 그중 가장 인색한 기계의 행동을 일부러 골라야 한다.

난수 항목도 직관과 어긋난다. 시드를 똑같이 박아도 프로세서와 엔비디아 GPU와 애플 GPU는 각자 다른 수열을 뽑는다. 한 벤더 안에서도 사정은 같아서, 엔비디아 GPU에서는 난수 생성기가 수천 개 레인에 일을 흩뿌리기 때문에 어느 레인이 몇 번째 수를 뽑느냐가 병렬화 방식에 따라 달라진다.

표에 들어가지 않은 자리도 있다. 부록을 보면 평균을 내는 나눗셈까지 다시 썼다. 부동소수점 텐서를 정수로 나누는 연산은 백엔드를 건너가지 못하는데, 프로세서는 정확히 반올림한 나눗셈을 하고 쿠다는 같은 식을 호스트가 미리 구한 역수의 곱으로 낮춰 실행하기 때문이다. 나누는 수가 2의 거듭제곱이 아니면 둘은 마지막 한 자리에서 갈린다. 그래서 학습 쪽과 감사 쪽 모두 나눗셈 기호를 쓰지 않고 미리 계산해 둔 역수를 곱한다. 어긋남이 작다는 것은 참작 사유가 못 된다. 노드 사이에서 합친 그래디언트를 한 대에서 그냥 차례로 더하면 클러스터가 낸 값과 1000억분의 1 수준까지 맞는데, 비트로는 다르다. 감사에서 그 값은 아주 틀린 값과 같은 판정을 받는다.

비결정성의 출처는 크게 셋이다. GPU 커널 안의 축약, 여러 대에 흩어진 배치의 순서, 노드 안팎의 집합 통신이다. 각각에 장치가 하나씩 붙는다.

3.1어디서나 같은 순서로 더하는 연산 묶음

RepOps는 프로세서와 엔비디아 GPU와 애플 GPU에서 같은 비트를 돌려주는 연산 묶음이다. 행렬 곱셈과 정규화, 손실과 그래디언트 축약까지 합이 들어가는 자리마다 고정된 순서를 강요하고, 하드웨어가 선호하는 순서를 포기한 만큼 속도를 내준다. 난수 쪽은 아예 성격을 바꿨다. 카운터 기반 생성기에서 i번째 값은 시드와 논리적 위치만으로 곧바로 계산되는 순수 함수의 값이다. 일을 몇 갈래로 쪼갰는지, 레인이 몇 개인지, 텐서가 얼마나 큰지와 무관하다.

3.2기계 수에 묶이지 않는 데이터 스트림

연산만 같아서는 부족하다. 감사자가 재생하는 스텝은 클러스터가 그 스텝에 넣은 토큰을 같은 순서로 받아야 한다. 보통의 데이터 로더는 워커 수가 바뀌면 배치 순서가 바뀌므로 이 조건을 못 지킨다. 그래서 학습 데이터를 하나의 정본 스트림으로 정의한다. 스트림은 학습 시드와 코퍼스 매니페스트와 시퀀스 길이만의 함수이고, 노드 수나 랭크에는 기대지 않는다. 문서 순서를 정하는 난수기의 시드에도 소스 이름을 SHA-256으로 해시해 넣었다. 파이썬의 프로세스마다 달라지는 해시를 쓰면 기계가 바뀔 때 순열이 달라지기 때문이다.

병렬화는 스트림이 정해진 다음에 붙는다. GPU 수를 바꾸면 몇 번째 창을 어느 랭크가 읽느냐만 바뀌고, 창의 내용과 전체 순서는 그대로다. 학습 도중 장비가 죽어 다른 대수로 다시 짜도 데이터 순서가 흔들리지 않고, 감사자는 한 대에서 그 스텝의 마이크로배치를 그대로 재구성할 수 있다.

그 스트림에 무엇을 흘려 넣었는지도 숫자로 나와 있다. 보고서는 학습 코퍼스를 Open-1B Mix 0626이라 부르고 토큰 4,505억 개, 문서 3억 3,220만 개로 집계한다. 허용적 라이선스로 공개된 자료 네 갈래를 섞었고, 토큰 비중은 DCLM 베이스라인 66.7%에 FineWeb-Edu 13.3%, 더 스택 v2 12.0%, 프루프파일 2가 8.0%다. 앞의 둘이 웹에서 온 것이라 전체의 약 80%가 웹 문서다. 출처별 비중을 디스크 크기에 비례하게 잡아 네 갈래가 같은 속도로 소비됐고, 4,000억 토큰 예산 안에서 각 출처는 0.89 에포크를 돌았다. 같은 문서를 두 번 본 적은 없다는 뜻이다. 이 모든 순서의 출발점은 숫자 하나다. 공개된 런의 전역 시드는 42이고, 소스를 고르는 난수기와 샤드 순서와 문서 순서를 정하는 난수기가 모두 거기서 갈라져 나온다.

다만 저자들은 데이터 품질까지 자기 몫으로 주장하지 않는다. 상류 공개본의 필터링에 기대고 자기가 더한 것은 셋뿐이다. FineWeb-Edu는 교육 점수 3 이상만 남겨 약 4분의 1을 취했고, 더 스택 v2는 1MB 이하의 허용 라이선스 파일로 제한했고, 빈 문서를 버렸다. 중복 제거는 하지 않았고, DCLM 베이스라인과 FineWeb-Edu 사이에 근중복이 남아 있다는 점도 함께 쓴다. 무엇이 들어갔는지 끝까지 셀 수 있다는 것과 들어간 것이 깨끗하다는 것은 서로 다른 주장이다. 이 공개가 세운 것은 앞쪽이다.

3.3한 대에서 되짚을 수 있는 집합 통신

여러 대가 그래디언트를 합치는 통신도 순서를 탄다. 널리 쓰이는 링 방식의 올리듀스는 빠르지만 합치는 순서가 클러스터 모양에 딸려 있어서, 토폴로지가 없는 한 대짜리 재생에서는 그 순서를 되짚을 근거가 없다. 대신 노드 안에서는 샤드를 오름차순으로 더하고, 노드 사이에서는 짝짓는 순서를 고정한 이진 트리 방식으로 접는다. 감사 하네스는 이 순서를 그대로 한 대에서 차례대로 실행한다. 저장소 설정 문서는 이 선택을 숨기지 않는다. 축약 방식을 통상적인 NCCL로 돌리면 처리량은 오르지만 그 런은 재생할 수 없게 되며, 감사 도구는 그런 런을 잘못 재현하느니 아예 거부한다.

학습에 쓴 장비는 H100 48장이고, 실제로 돌린 시간은 27.8일이다. GPU 시간으로 환산하면 1,300일이 넘는다. 이걸 한 대로 다시 도는 일은 가능하지 않다. 그래서 저자들이 택한 방식은 검증을 쪼개는 것이다. 오픈소스 소프트웨어에서 각자 한 모듈씩 읽어 나가듯, 여러 사람이 서로 다른 스텝을 하나씩 인증해 전 구간을 덮는다.

쪼개려면 대조할 표적이 스텝마다 있어야 한다. 매 스텝에 상태 해시가 하나씩 붙는다. blake2b 다이제스트 하나가 가중치와 옵티마이저 모멘트, 그 스텝의 클리핑 뒤 그래디언트, 랭크별 배치 다이제스트를 함께 담고, 각 스텝의 해시는 직전 스텝의 해시를 접어 넣는다. 사슬처럼 이어지므로 중간 한 곳을 손대면 뒤가 전부 어긋난다. Open-1B는 이 해시를 한 스텝도 빠뜨리지 않고 남겼고, 중간 체크포인트는 100스텝 간격으로 810개가 공개돼 있다. 아무리 짧은 구간을 고르더라도 맞춰 볼 대상이 있다는 뜻이다.

감사를 시작하는 데 계정도 자격 증명도 들지 않는다. 휠 두 개를 설치하고 명령 한 줄을 돌리면 일치인지 불일치인지가 찍힌다. 받은 파일이 공개된 sha256과 맞는지는 설치 전에 직접 확인하게 되어 있고, 맞지 않으면 거기서 멈추라고 문서는 못 박는다. 다른 바이트를 검증해 봐야 그 주장에 대해서는 아무것도 말해 주지 않기 때문이다. 하드웨어는 애플 실리콘 맥과 엔비디아 GPU가 달린 리눅스, 그리고 GPU가 아예 없는 프로세서가 모두 1급이다. 오히려 프로세서가 나머지 둘을 견주는 기준 장치다. 맥에서 한 감사와 H100에서 한 감사의 값이 똑같아야 한다는 것은 편의가 아니라 주장 자체라고 런북은 강조한다.

48장이 나눠 한 일이 한 대의 메모리에 들어가는 셈법은 부록에 있다. 하네스는 클러스터의 각 GPU가 그 스텝에 한 일을 차례로 다시 돌리는데, 그러면 합칠 부분합이 노드 수만큼 쌓인다. 저자들은 이진수 자리올림처럼 접는 방식을 택했다. 같은 크기의 부분합이 둘 생기는 순간 바로 합쳐 한 단 위로 올리니, 동시에 들고 있어야 하는 전체 크기 누적기가 노드 수만큼이 아니라 그 로그만큼으로 줄어든다. 여덟 노드라면 여덟 개가 아니라 넷을 넘지 않는다. 실제 구현은 쉬고 있는 항목을 디스크로 내려, 램에는 지금 더하는 두 항만 남긴다. 접는 짝짓기 순서를 클러스터와 똑같이 맞추는 것이 전제이고, 순서를 바꾸면 값도 바뀐다.

비용은 단위에 따라 크게 벌어진다. 초기 상태만 맞춰 보는 단위는 M4 맥스에서 29.7초에 끝나고 메모리는 5.8GB면 된다. 실제 학습 한 스텝을 통째로 재생하는 단위는 같은 급 기계에서 반나절 정도가 걸린다. 그래서 감사 단위가 여러 스텝이 아니라 한 스텝 하나로 잘려 있고, 자원자 한 사람은 구간이 아니라 스텝 하나를 맡는다. 이 수치로 셈해 보면 왜 나눠야 하는지가 분명해진다. 8만 957스텝을 한 사람이 한 대로 이어 돌면 100년 단위의 시간이 나온다.

저장소 문서는 해시가 맞았을 때 증명되는 범위를 직접 좁힌다. 일치는 고른 재생 구간이 고정된 산출물과 입력으로 예상된 상태 해시를 그 백엔드에서 만들어 냈다는 사실을 세운다. 초기화만 맞춰 본 단위는 학습 구간을 검증하지 않는다. 지금 판본의 해시는 가중치와 옵티마이저 상태와 그래디언트와 배치 다이제스트를 덮지만 난수 상태나 데이터 스트림 커서, 스파이크 상태까지 덮지는 않는다. 체크포인트 디렉터리는 데이터가 아니라 코드로 취급하라는 경고도 붙어 있다. 불러오는 과정에서 메타데이터 색인이 먼저 언피클되기 때문이다. 출처를 믿을 수 있는 체크포인트만 재생하고 나머지는 격리된 환경에서 다루라고 문서는 권한다.

구조가 그렇다는 것과 검산이 실제로 진행됐다는 것은 다른 얘기다. 젠신은 감사 기록을 웹으로 공개하고 집계도 함께 내놓는다. 2026년 9월 17일에 받아 본 값은 이렇다. 검산이 접수된 스텝이 19개, 참여자가 10명, 자원자들이 보고한 재생 시간의 합계가 67.9시간이다. 구간 810개 어디에도 100스텝이 빈틈없이 채워진 곳은 없다. 누군가 맡아 놓고 진행 중인 구간이 9개, 잠정 기록이 한 건이라도 붙은 구간이 7개이고, 나머지 794개는 아직 아무도 손대지 않았다. 공개 사흘째의 수치이니 적다고 탓할 일은 아니다. 대신 이 수치에서 감사의 문턱이 어디쯤인지가 읽힌다.

더딘 데는 이유가 있다. 감사는 순서를 탄다. 어떤 스텝을 재생하려면 그 직전의 상태가 손에 있어야 하는데, 공개된 체크포인트는 100스텝 간격이다. 그래서 감사자는 공개 체크포인트에서 곧바로 시작하거나, 앞선 자원자가 올려 둔 중간 체크포인트를 이어받는다. 이어받는 쪽은 제출 때 손실값과 파일 다이제스트 검사를 통과한 것이어야 하고, 받는 사람의 도구가 다이제스트와 학습 상태 해시를 다시 확인한 뒤 재생에 들어간다. 기록에 적힌 스텝 번호에 그 릴레이가 그대로 드러난다. 100번과 101번, 102번이 서로 다른 세 사람의 이름으로 이어져 있고, 12100번부터 12103번까지 넷이 한 사람 이름으로 붙어 있다. 구간 하나가 확정되려면 100스텝이 끊기지 않고 이어져야 하는데, 지금 가장 앞선 구간이 4스텝이다.

어떤 기계로 돌렸고 얼마가 걸렸는지도 같은 기록에 남는다. 자원자가 스스로 적은 값이라 조건이 고르지 않지만, 기계 사이 격차의 크기는 분명하다.

앱이 스텝을 맡기 전에 미리 알려 주는 요구치도 같이 놓고 봐야 한다. 메모리는 24GB부터이고 애플 실리콘에서는 40GB 이상을 요구한다. 40GB 아래로 내려가면 재생이 스와핑에 들어가 시간이 길어지고, 스와핑하는 기계에서 돌린 두 건은 아무것과도 맞지 않는 해시를 그때마다 다르게 돌려줬다고 앱은 경고한다. 불일치가 나오면 메모리가 더 큰 기계에서 다시 돌려 본 뒤에 판정하라는 당부도 함께 붙는다. 엔비디아 카드는 24GB로 충분하고, 실제로 24GB RTX 4090에서 감사가 돌았다. 여유 디스크는 처음 설치하는 기계에서 74GiB를 잡아 두라고 하고, 일치가 나온 뒤 올릴 체크포인트는 약 25.7GB다. 스텝마다 뜨는 소요 시간 추정치는 메모리 48GB M5에서 잰 애플 기준값이고, 40GB 밑에서 스와핑하는 기계는 세 배로 잡는다. 0번 스텝만 사정이 다르다. 옵티마이저를 덜어 낼 수 없어 호스트 메모리 48GiB를 잠정 요구치로 걸어 두었고, 아직 시간을 재 본 기계가 없다. 소비자용 하드웨어에서 돌아간다는 말은 맞지만, 여기서 말하는 소비자용은 꽤 잘 갖춘 기계다.

보상은 없다. 기록에 붙은 안내문은 이름 목록이 알파벳 순이고 순위가 아니라고 먼저 밝힌 다음, 지불도 포인트도 앞날의 보상도 없다고 잘라 말한다. 기록이 감사를 받아들이면 이름이 올라가지만 스텝은 그 구간이 확정될 때까지 잠정 상태로 남는다. 이더리움 주소는 적어 넣은 사람만 공개되고, 열 명 가운데 다섯 명이 적었다. 남는 것은 처음으로 완전히 감사된 학습 런의 기록에 이름이 오른다는 사실뿐이라고 회사도 발표문에 그렇게 적었다.

보고서는 한 절을 통째로 비용에 쓴다. 먼저 해시다. 스텝마다 붙는 상태 해시는 일이 랭크당 고정이라 규모와 무관하게 스텝당 5.77초에서 5.96초 사이로 일정하다. 노드를 늘려 스텝 자체가 짧아질수록 이 고정비의 몫은 커진다. 1노드에서 4.9%이던 것이 2노드 9.3%, 4노드 16.7%를 거쳐 6노드에서는 스텝 시간의 21.4%가 된다. 해시를 켜고 잰 강확장 효율이 71%, 끄면 86%인 것도 여기서 나온다. 순전파와 역전파만 떼어 보면 99.7%이니, 잃은 몫은 대부분 해시와 노드 간 통신에 있다.

해시에 드는 이 시간을 재현성의 비용과 한 덩어리로 세지 않는 편이 낫다. 부록은 해시가 감사에 붙은 비용이지 재현성에 붙은 비용은 아니라고 선을 긋는다. 해시를 아예 끄고 돌려도 결정적 커널과 통신은 같은 비트를 내놓는다. 다만 그때는 중간 스텝에서 맞춰 볼 대상이 없다. 노드를 늘릴 때 순서를 붙든 통신이 얼마를 요구하는지도 따로 쟀다. 결정적 올리듀스는 순서를 고정하는 대신 홉마다 버퍼 전체를 보내므로, 같은 부분군에서 통상적인 NCCL로 잰 값과 견주면 2노드에서 1.13배, 4노드에서 1.59배, 6노드에서 3.54배가 든다. 6노드에서 크게 뛰는 것은 대역폭 때문이 아니라 노드 수가 2의 거듭제곱이 아니어서 접기가 두 갈래로 갈리기 때문이다. 약 5배라는 요약도 그래서 조건에 딸린 숫자다. 여섯 노드에서 격차가 좁아 보이는 데는 기준선 쪽 사정도 섞여 있다. 이 클러스터는 GPUDirect 없는 소켓 패브릭을 쓰는데, 그 위에서 파이토치의 강확장 효율은 66%로 내려앉고 재현 가능한 쪽은 86%에서 91%를 지킨다.

커널 쪽이 훨씬 비싸다. 단일 노드에서 비트 단위로 재현 가능한 bf16 커널의 GPU 활용률은 3.3%였고, 같은 모델과 같은 레시피를 스톡 파이토치로 돌린 쪽은 40.5%였다. 12.2배 차이다. int8 양자화 인식 학습이 그 격차를 6.8배로 줄였고, 여섯 노드까지 올리면 약 5배로 좁혀진다. 재현성의 부담이 최적화된 파이토치보다 약 5배 비싸다는 것이 저자들의 요약이다. 가장 큰 개선 여지로 꼽힌 것은 해시다. 지금은 호스트 쪽에서 계산하느라 장치와 호스트 사이의 메모리 전송이 매 스텝 끼어든다.

이 부담은 벤치마크 점수에 그대로 남는다. 학습 토큰이 4,000억 개에 그쳤고, 비교 대상인 OLMo 2 1B는 4조 개를 봤다. OLMES 매크로 점수는 50.1 대 61.5, 열 과제 평균은 25.4 대 31.9다. 열 과제 가운데 Open-1B가 앞선 것은 ARC 챌린지와 MMLU 프로 둘뿐이다. 비교 대상 쪽 점수는 저자들이 직접 재서 얻었다. OLMo 2 보고서가 열 종목 중 다섯 개를 공개하지 않아, 평가 하네스를 고정해 공개된 OLMo 2 1B 체크포인트에 그대로 돌려 매크로를 다시 냈다고 설명한다. 저자들은 결론에서 이 차이의 원인으로 재현성 오버헤드와 자원 제약, 그리고 열 배 적은 토큰 예산을 직접 든다. 같은 조건에서 진 것이 아니라 같은 조건을 살 수 없었던 쪽에 가깝다.

공개된 런은 한 번에 나오지 않았다. 거기 이르기까지 밟은 실패 둘이 보고서에 함께 들어 있다. 하나는 1,160억 토큰 무렵부터 그래디언트가 슬금슬금 커진 일이다. 파고들어 보니 int8로 양자화한 플래시 어텐션 역전파가 쿼리 쪽 그래디언트를 0으로 내보내고 있었고, 그걸 메우려고 QK 정규화의 이득 파라미터가 단조롭게 커지던 중이었다. 처방은 재현성을 깨지 않는 스케일 인자를 그래디언트 커널에 넣고, QK 정규화에서 이득 자체를 들어내는 것이었다. 다른 하나는 약 2,000스텝 뒤 첫 블록의 그래디언트 노름이 1,000을 넘긴 일이다. 정수 어텐션 커널부터 학습률까지 후보를 하나씩 갈아 끼우며 지운 끝에 가중치 양자화기가 범인으로 확정됐고, 스텝 크기를 학습시키는 대신 매 스텝 다시 계산하는 쪽으로 바꿨다. 비용은 스텝 시간의 약 2%다. 두 처방 모두 공개된 레시피에 들어가 있다.

두 번째 처방에서는 재현성이 선택지를 좁혔다는 점도 읽힌다. 저정밀 학습의 불안정에 흔히 쓰는 처방은 값을 확률에 따라 위나 아래 격자로 올리는 확률적 라운딩인데, 무작위가 끼는 만큼 비트 단위 재현성과 같이 갈 수 없다. 카운터 기반 생성기를 옵티마이저 안에까지 끌어들이지 않는 한 그렇다. 스텝 크기를 매번 다시 계산하는 쪽은 가중치의 결정적 함수라 그런 장치가 필요 없었고, 당시 함께 검토한 다른 길인 양자화 해제는 스텝 시간의 약 70%를 요구했다. 건너뛴 스텝의 사정도 비슷하게 데이터 쪽을 가리킨다. 클리핑 전 그래디언트 노름이 5를 넘은 배치는 전체 런에서 두 건(1,782번과 43,737번 스텝)이고, 한 건마다 다섯 스텝을 건너뛰는 규약이 걸려 합계 10스텝이 빠졌다. 안정 구간에서 클리핑이 걸린 비율은 0.16%인데, 저자들은 이것을 최적화가 흔들린 흔적보다 고유 토큰 비율이 낮은 배치 같은 데이터 쪽 이상으로 읽는다. 데이터 순서가 시드의 함수이므로 그 배치가 정확히 어느 문서들이었는지는 스텝 번호만으로 되짚을 수 있다.

전체 런이 엔지니어링 문제로 일곱 개 구간에 나뉘어 끝난 것도 흠으로만 남지는 않았다. 각 구간을 직전 체크포인트에서 다시 시작하면서 겹쳐 돈 스텝의 해시를 앞 구간의 것과 대조해 재시작이 옳았는지 확인했기 때문이다. 재시작이 일곱 번 있었으니 같은 스텝을 다시 돌려 같은 해시가 나오는지 보는 시험이 공개 전에 일곱 번 있었던 셈이다.

여기서부터는 보고서를 떠나, 데이터를 다루는 쪽에서 이 소식을 다시 읽는다. 페블러스가 오래 붙들어 온 물음은 어떤 값이 어디서 와서 무엇을 거쳐 지금 모습이 됐는가다. 모델 공급자가 이 데이터로 배웠다고 말할 때 그 말을 내가 직접 확인할 수 있는가 하는 물음은 그 계보 문제의 마지막 관문에 해당한다. 오늘 그 물음에 예라고 답할 수 있는 곳은 거의 없다. 이번 사례는 예라고 답하는 길이 있을 수 있다는 존재 증명 하나를 세웠다.

귀속을 먼저 바로 해 둘 것이 있다. 이 물음을 젠신도 같은 날 자기 발표문에 적었다. 발표문은 감사 가능성이 여는 응용의 첫째로 어떤 데이터가 학습에 들어갔는지 증명하는 일을 들고, 빠진 것이 없음을 검증할 수 있는 학습 데이터 전체를 훑어보는 검색 도구를 함께 공개했다고 밝힌다. 연구소들이 이 기법을 쓰면 소비자가 자기 초상이나 자기가 쓴 글이 학습에 쓰였는지 요청해 확인하는 일도 가능하다고 적는다. 웹사이트가 요청을 받으면 보유한 개인 정보를 내주는 것과 같은 방식으로 말이다. 아래 단락들이 데이터 파이프라인으로 끌어오는 결론은 이 글이 더한 해석이지만, 문제를 이렇게 세우는 방식 자체는 회사의 것이다.

옮겨 올 만한 교훈은 설계의 순서에 있다. 감사 가능성은 학습이 끝난 뒤에 덧붙일 수 있는 성질이 아니다. 연산 순서를 고정하고, 난수를 위치의 함수로 바꾸고, 데이터 순서를 장비 대수에서 떼어 내는 일은 모두 첫 스텝을 돌리기 전에 박아 넣어야 한다. 데이터 쪽으로 옮기면 이렇게 읽힌다. 나중에 계보를 캐낼 수 있으려면, 어떤 문서가 몇 번째 창에 들어갔는지를 재구성할 수 있는 형태로 파이프라인을 처음부터 짜 놓아야 한다. 일이 끝난 뒤 로그를 뒤져 복원하는 작업과는 성격이 다르고, 뒤늦게 시작하면 대개 복원되지 않는다. 발표문은 이 점을 한 줄로 끊는다. 오늘 공개한 검증 도구로 라마나 GPT를 감사할 수는 없다.

경계도 분명히 해 두는 편이 낫다. 규모는 16억 파라미터이고 속도 손해가 약 5배이며, 이런 방식으로 검증되는 모델은 아직 하나다. 그리고 보증의 바닥에는 신뢰가 한 겹 남아 있다. 모든 연산이 통과하는 RepOps를 보고서의 결론은 독점 라이브러리라고 부르고, 감사용 휠에는 컴파일된 커널만 들어 있으며 소스 트리는 공개돼 있지 않다. 런북은 이 점을 감추지 않는다. 기계어를 배포한다는 것은 디스어셈블할 수 있는 무언가를 배포한다는 뜻이고, 그 일에 진짜 품이 들지만 불가능하지는 않다고 적은 다음, 이 키트가 요구하는 것은 들여다볼 수 없는 코드를 믿으라는 것이 아니라 스스로 다시 유도할 수 있는 산술이라고 말한다. 그 맞바꿈을 받아들일지는 읽는 사람이 판단할 몫이지만, 신뢰가 어디에 얼마나 남아 있는지가 문서에 적혀 있다는 사실 자체가 이 공개의 성격을 보여 준다.

왜 하필 이 회사가 이 일을 했는지도 그림의 일부다. 젠신은 탈중앙 연산 네트워크를 만드는 회사다. 발표문은 이 방식이 탈중앙 학습과 기능상 같지만 모델을 만드는 일이 아니라 모델을 검증하는 일을 그 노드들로 옮긴 것이라고 적는다. 앞단 학습을 중앙에서 끝냈으니 탈중앙 학습이 지는 초기 비용과 통신 문제를 피한다는 설명이다. 같은 발표문은 이 방식을 지금도 더 큰 모델로 키울 수 있다고 말한다. 다만 보고서가 실제로 잰 결과는 순서를 붙든 통신의 부담이 노드를 늘릴수록 커진다는 것이었고, 둘 사이의 거리는 아직 공개된 수치로 채워져 있지 않다.

모델을 직접 학습시키거나 외부 모델을 들여와 쓰는 팀이라면 다음 다섯 가지를 확인해 볼 만하다.

• 우리 모델이 무엇을 보고 배웠는지 문서 단위로 지목할 수 있는가. 지목할 수 없으면 무엇이 안 들어갔는지도 말할 수 없다.
• 같은 레시피로 다시 돌렸을 때 같은 결과가 나오는가. 같은 기계에서만 그런지, 다른 기계에서도 그런지를 갈라서 답할 수 있어야 한다.
• 데이터 순서가 장비 구성에 묶여 있지는 않은가. GPU 대수가 바뀌면 다른 모델이 나오는 파이프라인은 나중에 아무것도 증명하지 못한다.
• 중간 상태를 얼마나 자주 남기는가. 남긴 것이 없으면 대조할 표적도 없고, 문제가 어느 구간에서 생겼는지도 좁힐 수 없다.
• 외부에서 들여온 모델을 볼 때, 그쪽이 공개한 것이 결과물인지 과정인지 구분하고 있는가. 가중치 공개와 과정 공개는 다른 약속이다.

여기까지 읽어 주셔서 감사하다. 이 글이 인용한 수치와 문장은 arXiv에 공개된 보고서와 감사 하네스 저장소에서 누구나 원문으로 확인할 수 있고, 감사 앱에서는 스텝별 기록을 직접 넘겨 볼 수 있다. 여러분의 조직에서는 모델이 무엇으로 배웠는지를 어떤 방법으로 확인하고 계신지 나눠 주시면 좋겠다.

학술 논문

• 1.Donaghy, J. et al. (2026). "OPEN-1B: A Fully Auditable Training Run." arXiv:2609.17380.

1차 문서·감사 도구

• 2.Gensyn. "gensyn-ai/open-transformers." GitHub, 감사 하네스 저장소.
• 3.Gensyn. "Audit Volunteer Runbook." GitHub — gensyn-ai/open-transformers.
• 4.Gensyn (2026). "Introducing open-1b: the first model you don't have to trust." Gensyn News, 2026-09-15.
• 5.Gensyn. "Open-1B Audit." 감사 진행 현황·원장, 2026-09-17 조회분.