학습 없이 Doom 렌더러를 실행하는 210억 파라미터 Transformer

Cursor Horizon에 이례적인 기술적 기준점이 등장했다. 학습 과정을 거치지 않고 Doom을 렌더링하는 210억 파라미터 transformer다. 개발자 Rob Porter는 게임의 렌더링 알고리즘을 transformer 가중치에 직접 컴파일했다. 그 결과는 모든 대형 transformer가 데이터로부터 동작 방식을 학습했다는 통념에 도전한다.

이 모델은 Doom 프레임이 어떤 모습이어야 하는지 예측하지 않는다. 변환된 렌더링 프로세스를 한 번에 하나의 토큰씩 실행한다. 프롬프트는 장면 지오메트리와 카메라 상태를 제공한다. 출력에는 작은 호스트 프로그램이 픽셀로 변환하는 중간 계산과 드로잉 명령이 담긴다.

이 차이는 이 프로젝트를 게임플레이 영상으로 학습한 생성형 Doom 실험과 구분 짓는다. 또한 이 Cursor Horizon 이야기의 핵심적인 긴장을 만든다. Transformer 추론은 기존 소프트웨어의 낯선 실행 대상이 되었지만, 그 결과물은 원래 게임보다 압도적으로 느리다.

공개된 산출물은 이 주장을 이례적으로 검증 가능하게 만든다. Porter는 컴파일러, 렌더러 그래프, 체크포인트, 프롬프트, 디코딩 도구, 참조 구현을 공개했다. 다만 성능과 정확도 결과 대부분은 여전히 독립적인 재현이 아닌 프로젝트 자체 테스트에 기반한다.

Doom의 렌더러가 표준 Transformer 체크포인트가 되다

핵심 변화는 AI 모델이 Doom 이미지를 만들어냈다는 데 있지 않다. 일반적인 렌더링 코드가 모델의 가중치가 되었다는 점이다.

Porter는 2026년 8월 13일 프로젝트를 공개한 데 이어, 상세한 커뮤니티 게시물을 올렸다. 그의 기술 문서는 torchwright라는 컴파일러를 설명한다. 이 컴파일러는 계산 그래프를 decoder-only transformer의 attention 및 feed-forward 가중치로 변환한다.

최적화 루프, 학습 코퍼스, 그래디언트 업데이트, Doom 게임플레이의 학습된 근사는 없다. 컴파일러는 Python으로 작성된 그래프에서 체크포인트의 가중치를 계산한다. 이 가중치는 실행 중 렌더러에 필요한 연산을 인코딩한다.

생성된 산출물은 표준 Phi3ForCausalLM 아키텍처를 사용한다. 이는 Hugging Face Transformers가 이미 이를 불러오고 실행하는 방법을 알고 있기 때문에 중요하다. 사용자는 커스텀 모델 코드나 잠재적으로 민감한 trust_remote_code=True 설정이 필요하지 않다.

주력 체크포인트는 38개 transformer 레이어와 약 210억 개의 파라미터를 담고 있다. fp32 가중치 샤드는 85.87 GB를 차지한다. 더 작은 80x50 버전은 70개 레이어와 34.09 GB의 fp32 샤드를 사용한다.

더 큰 체크포인트는 장면을 나타내는 3,614토큰 프롬프트를 입력받는다. 이후 프레임을 완성하기 전까지 53,747개 토큰을 생성한다. 전체 시퀀스는 57,361토큰에 이른다.

이 출력 중 픽셀을 직접 그리는 부분은 일부에 불과하다. 나머지 토큰은 렌더러 연산, 계산된 값, 제어 흐름, 임시 상태를 나타낸다. 자연어라기보다 실행 추적에 가깝게 작동한다.

공개된 체크포인트에는 모델 구성, 토크나이저, 프롬프트, 팔레트, 디코딩 유틸리티가 포함된다. 토크나이저는 연산과 값에 사람이 읽을 수 있는 단어를 사용한다. 이 선택 덕분에 임의의 토큰 ID를 디코딩하지 않고도 실행 추적의 일부를 이해할 수 있다.

호스트 프로그램은 의도적으로 제한적인 역할을 수행한다. 커서 위치를 기억하고, Doom의 팔레트에서 색상을 선택하며, 요청된 픽셀 구간을 그린다. 가시성, 지오메트리, 벽 순서, 텍스처 좌표, 오클루전을 계산하지는 않는다.

다섯 가지 출력 명령이 드로잉을 제어한다. 두 명령은 커서 좌표를 설정한다. 두 명령은 커서가 수평 또는 수직으로 이동할지를 선택한다. 다섯 번째는 지정된 색상과 너비로 픽셀 구간을 그린다.

이 경계는 프로젝트의 신뢰성에 핵심적이다. 모델이 외부 소프트웨어에 Doom 렌더링을 단순히 요청했다면 흥미가 덜했을 것이다. 여기서는 체크포인트가 시점에 따른 렌더링 작업을 수행하고, 호스트는 그 드로잉 명령을 기계적으로 적용한다고 알려졌다.

이 체크포인트는 완전한 Doom 게임이 아니다. 게임플레이, 적, 일반 스프라이트, 사운드, 플레이어 조작을 구현하지 않는다. 고정된 텍스처 라이브러리를 사용하는 장면을 위한 제한된 버전의 렌더러를 구현한다.

전체 출력은 저해상도 모드에서 Doom의 320x200 디스플레이 해상도를 사용한다. 렌더러는 160개 열을 계산하고, 각각을 두 픽셀 너비로 표시한다. 9개의 벽 텍스처와 6개의 바닥 또는 천장 텍스처가 모델에 컴파일되어 있다.

플레이어 위치, 시선 방향, 맵 지오메트리, 섹터 정보, 이진 공간 분할 트리는 프롬프트를 통해 전달된다. 이진 공간 분할 트리, 즉 BSP 트리는 효율적인 가시성 순서 처리를 위해 맵을 분할한다.

장면이 컴파일된 텍스처 및 구성 한도 내에 머무르는 한, 이 입력은 체크포인트를 다시 빌드하지 않고 변경할 수 있다. 지원되지 않는 텍스처를 추가하려면 재컴파일이 필요하다.

바로 이 점에서 Cursor Horizon의 프레이밍은 주목할 가치가 있다. 이 프로젝트는 transformer 체크포인트를 학습된 지식 저장소가 아니라 실행 가능한 패키지 형식으로 다룬다. 그 파라미터는 컴파일러가 생성한 프로그램 재료다.

Cursor Horizon이 학습 우선 모델에 도전하는 이유

Torwright는 transformer 아키텍처를 결정론적 컴퓨팅 기반으로 바꾸지만, 기존 프로세서를 대체할 실용적 방안은 제시하지 않는다.

대부분의 대형 언어 모델은 학습을 통해 행동을 습득한다. 엔지니어는 아키텍처를 선택하고, 데이터를 노출하며, 오류를 측정하고, 그래디언트 하강법을 통해 가중치를 조정한다. 최종 모델에는 이러한 예시에서 학습한 패턴이 담긴다.

Torwright는 이 워크플로를 뒤집는다. 개발자가 계산 그래프를 정의하면 컴파일러가 해당 연산을 실행하는 가중치를 구성한다. 완성된 transformer는 여전히 토큰을 하나씩 예측하지만, 예측 프로세스는 설계된 프로그램을 따른다.

이 차이는 예시를 통해 곱셈을 학습하는 것과 곱셈 회로를 실행하는 것의 차이와 비슷하다. 둘 다 같은 답을 낼 수 있다. 그러나 내부적 기원, 신뢰성의 한계, 실패 방식은 다르다.

오픈 소스 torchwright 컴파일러는 선형 연산, attention 기반 조회, 비교, 선택, 곱셈을 지원한다. 그래프 노드를 transformer 레이어 전반에 배치하고 계산된 값을 residual stream에 저장한다.

Residual stream은 transformer 레이어를 거치며 전달되는 변화하는 벡터다. Torchwright는 이 벡터의 일부를 프로그램 값에 할당한다. 값이 더 이상 필요하지 않으면 다른 연산이 이를 상쇄하고 그 공간을 재사용한다.

이 구조에서 attention은 의미적 연관성 이상의 역할을 수행한다. 구조화된 필드를 일치시켜 이전 토큰에서 값을 검색한다. 이 필드는 노드 식별자, 트리 깊이, 연산 유형, 화면 좌표를 나타낼 수 있다.

Feed-forward 레이어는 비선형 연산을 구현한다. Torchwright는 ReLU 또는 SwiGLU 활성화로 구성된 연산 라이브러리를 제공한다. 컴파일러는 각 그래프 연산을 feed-forward 가중치의 특정 행이나 attention 헤드로 변환한다.

이 접근법에는 학술적 선례가 있다. RASP는 프리미티브가 transformer 연산에 매핑되는 프로그래밍 언어를 도입했다. DeepMind의 Tracr 연구는 해석 가능성 실험을 위해 RASP 프로그램을 transformer 가중치로 컴파일했다.

Torwright는 이 방향을 일반적인 Python 계산 그래프와 표준 Phi-3 출력 형식으로 확장한다. 기존 추론 소프트웨어가 이례적인 기원을 이해하지 못해도 결과물을 불러올 수 있다는 점에서 이 대상은 중요하다.

이 호환성은 도발적인 가능성을 만든다. 표준 체크포인트에는 학습된 통계적 행동, 의도적으로 컴파일된 로직, 또는 둘의 혼합이 담길 수 있다. 파일 구조만으로는 어떤 경로가 가중치를 만들었는지 알 수 없다.

개발자에게 이는 모델 산출물을 해석하는 방식을 바꾼다. 파라미터 수는 일반적으로 학습된 역량과 추론 비용의 대략적인 신호로 작용한다. 그러나 여기서 210억 개 파라미터는 주로 극도로 비효율적인 컴파일 대상임을 반영한다.

이 숫자가 체크포인트가 폭넓은 언어 지식을 가졌다는 뜻은 아니다. 지원하는 렌더러 범위를 벗어난 일반 질문에 답하거나 Doom 장면을 즉흥적으로 만들 수 없다. 그 가중치는 개방형 언어 모델이 아니라 제약된 프로그램을 구현한다.

따라서 Cursor Horizon은 더 넓은 경계 문제를 포착한다. Transformer 생태계는 이제 로더, 가속기, 샤딩, 배포 도구, 표준화된 모델 클래스를 제공한다. 컴파일러는 학습된 적 없는 소프트웨어를 위해 이 인프라를 활용할 수 있다.

그렇다고 transformer가 CPU보다 더 바람직해지는 것은 아니다. 이는 그 실행 메커니즘이 명시적으로 구성된 알고리즘을 수용할 만큼 일반적임을 보여준다. 일반성, 효율성, 유용성은 여전히 별개의 문제다.

프로젝트의 가장 강력한 기여는 상업적이라기보다 개념적이다. 아키텍처와 학습의 차이를 눈에 보이게 만든다. Transformer는 수학적 구조다. LLM은 그 구조를 언어로 학습해 구축한 친숙한 응용 사례 중 하나다.

Porter의 모델은 익숙한 추론 동작을 유지하면서 학습 과정을 제거한다. 토큰을 받아 attention 및 feed-forward 레이어를 적용하고, 다음 토큰을 선택한 뒤 반복한다. 내부 계산이 평범하지 않아도 루프는 평범해 보인다.

이 특성은 통제된 연구 환경도 제공한다. 모든 가중치가 알려진 그래프 연산에서 나오므로 연구자는 값이 나타나는 이유를 추적할 수 있다. 이는 내부 특징이 학습을 통해 등장한 모델을 해석하는 일과 뚜렷이 다르다.

하지만 Doom 체크포인트는 일반적인 해석 가능성 테스트 모델보다 훨씬 크다. 그 규모는 컴파일된 구조물이 현대 모델 인프라에 도달할 수 있음을 보여준다. 동시에 검사와 독립적 재현의 비용도 높인다.

Transformer는 Doom을 한 번에 하나의 토큰으로 실행한다

이 렌더러는 Doom의 변경 가능한 실행 상태를 attention이 검색할 수 있는 추가 전용 토큰 이력으로 변환해 작동한다.

Doom의 렌더러는 BSP 트리를 가까운 영역에서 먼 영역 순으로 순회한다. 벽을 화면 열에 투영하고, 이미 가려진 영역을 추적하며, 더 가까운 표면 뒤에 숨은 지오메트리를 건너뛴다.

기존 코드는 메모리에서 변수와 데이터 구조를 갱신한다. 자기회귀 생성은 이전 토큰을 수정할 수 없다. 새 토큰은 이후 transformer 패스에서 계속 사용할 수 있는 추가 전용 시퀀스에 합류한다.

컴파일된 렌더러는 각 상태 변경을 또 하나의 토큰으로 표현해 이 불일치를 해결한다. 이후 연산은 attention을 사용해 가장 최근의 관련 기록을 찾거나 여러 이전 기록을 결합한다.

재귀적 트리 순회는 일반적으로 호출 스택에 의존한다. 모델은 대신 하강 중에 breadcrumb 기록을 출력한다. 리프에 도달하면 attention이 적절한 breadcrumb를 검색하고 실행을 재개할 위치를 결정한다.

벽 가림 처리는 또 다른 전략을 요구한다. Doom은 solidsegs라는 변경 가능한 구조에 가려진 수평 범위를 저장한다. 이 범위는 더 가까운 지오메트리 뒤에 이미 숨겨진 벽을 다시 그리지 않도록 돕는다.

Transformer는 이전 범위 기록을 병합하거나 덮어쓸 수 없다. 새로 가려진 모든 범위를 추가한다. 이후 연산은 누적된 이력을 조회해 열이 가려졌는지와 가려진 구간이 어디에서 끝나는지를 찾는다.

바닥과 천장도 유사한 패턴을 따른다. 벽 패스는 각 화면 열에 대해 이들의 보이는 경계를 기록한다. 이후 패스는 해당 기록을 검색하고 수평 드로잉 구간을 출력한다.

그 결과는 여러 역할을 수행하는 토큰 시퀀스다. 명령 스트림이자 작업 메모리, 호출 스택, 상태 로그, 출력 프로토콜이다. 어텐션은 이 역할들을 연결하는 조회 메커니즘을 제공한다.

긴 계산 역시 생성된 토큰에 걸쳐 분할된다. 트랜스포머 레이어는 잔차 스트림을 다음 단계로 넘기기 전까지 제한된 양의 순차 작업만 수행할 수 있다. 더 긴 의존성 사슬에는 더 많은 레이어가 필요하다.

렌더러는 때때로 중간 결과를 내보낸 뒤 이후 디코딩 단계에서 이를 소비한다. 이 전략은 단계별로 필요한 깊이를 줄이는 대신 더 많은 토큰을 사용한다.

벽 투영은 이러한 절충을 보여준다. 모델은 월드 각도를 계산하고 이를 카메라 기준 각도로 변환한 다음, 끝점을 화면 위에 투영한다. 중간 각도 토큰이 이들 의존적인 단계를 분리한다.

이 설계는 플래그십 모델을 38개 레이어로 유지한다. 또한 한 프레임에 필요한 53,747토큰 롤아웃에도 영향을 준다. 중간 전달이 하나 늘어날 때마다 모델 전체를 한 번 더 통과해야 한다.

renderer source는 이 파이프라인을 공개한다. 모듈은 장면 입력, 순회, 투영, 래스터화, 텍스처, 출력 프로토콜을 처리한다. 별도의 Python 렌더러는 정확성 참조 역할을 한다.

모델은 탐욕적으로 토큰을 생성한다. 즉, 샘플링 없이 점수가 가장 높은 다음 토큰을 선택한다. 이 체크포인트는 결정론적 로직을 실행하도록 설계됐으므로 무작위성은 부적절하다.

Cursor Horizon이라는 키워드는 모델의 상태 경계를 비유하는 표현으로 유용하다. 출력 커서는 렌더링된 이미지를 따라 전진하고, 어텐션 지평선은 실행 이력을 거슬러 올라간다.

하지만 이 메커니즘은 시적인 비유보다 훨씬 더 문자 그대로 작동한다. 새 연산은 앞선 장면 사실과 생성된 기록을 살펴볼 수 있다. 이 과정에는 대화형 모델과 연관된 의미적 유연성이 전혀 필요하지 않다.

프롬프트는 읽기 전용 메모리 역할을 한다. 여기에는 뷰와 무관한 맵 사실, 플레이어의 위치와 방향이 포함된다. 생성된 부분은 뷰 의존적 계산을 위한 추가 전용 작업 메모리 역할을 한다.

호스트는 이후 Doom의 256색 팔레트를 사용해 드로잉 토큰을 해석한다. 소프트웨어 커서를 이동시키고 요청된 구간을 칠한다. Porter의 최소 데모는 이 부분을 Python 43줄로 구현한다.

이 작은 호스트만으로 모든 렌더링 계산이 체크포인트 안에서 이뤄진다는 점이 증명되지는 않는다. 그러나 공개 소스 덕분에 그 경계는 검증 가능하다. 검토자는 프롬프트 구성, 그래프 모듈, 출력 디코딩, 참조 비교를 살펴볼 수 있다.

프로젝트는 Python 렌더러를 기준으로 픽셀 단위 검사를 수행했다고 보고한다. 플래그십 프레임에서는 전체 픽셀 커버리지, 허용된 색상 선택지 내에서 99.9% 일치, 그리고 96.7%의 정확한 일치를 측정했다.

이 수치는 원문 기사에서 사용한 반올림된 97%와 약간 다르다. 저장소의 정식 사실 파일은 최신 측정치가 8월 9일 프로덕션 렌더에서 나온 것이라고 명시한다.

저해상도 체크포인트는 전체 커버리지, 선택지 내 색상 완전 일치, 93.9%의 정확한 일치를 달성한 것으로 전해진다. 해당 프레임에는 비교 대상 픽셀 3,964개가 포함됐다.

이는 프로젝트가 보고한 측정치다. 동일한 결과가 환경, 프롬프트, 장면 변형 전반에서 유지되는지는 아직 독립 테스트로 확인되지 않았다.

진정한 결과는 하루 35프레임이다

이 프로젝트는 실용적인 Doom 렌더러로서는 극적으로 실패하기 때문에, 오히려 컴파일러 데모로서 정확히 성공한다.

원래 Doom은 1990년대 초반 하드웨어에서 초당 35프레임을 목표로 했다. Porter의 전체 체크포인트는 Nvidia B200 가속기에서 초당 약 0.0004프레임을 생성한다.

보고된 프로덕션 실행에서 탐욕적 디코딩에는 2,383.5초가 걸렸다. 모델 로딩과 기타 오버헤드를 포함한 엔드투엔드 시간은 2,528.1초, 즉 42.1분이었다.

연속 운영과 유사한 실행 시간을 가정하면 하루 약 35프레임이다. 이 비교는 프로젝트의 가장 기억에 남는 농담이 됐다. 동시에 평범한 소프트웨어를 자기회귀 추론으로 컴파일할 때 드는 핵심 비용도 드러낸다.

내보내는 모든 토큰에는 210억 파라미터 모델을 한 번 더 통과해야 한다. 프레임 하나를 그리려면 이러한 패스가 수만 번 필요하다. 이 아키텍처는 일반 하드웨어가 압축된 명령어와 병렬 파이프라인으로 처리하는 연산을 직렬화한다.

B200 실행은 최대치에서 151 GiB의 메모리를 예약한 것으로 전해진다. 체크포인트만도 이진 기비바이트 기준으로 거의 80 GiB를 차지한다. 대부분의 독자가 데스크톱 GPU에서 시험할 수 있는 프로그램은 아니다.

소비자용 체크포인트는 해상도를 80×50픽셀로 낮춘다. 7,007토큰 롤아웃을 생성하며, 80 GB 메모리의 A100 한 대에서 338.3초 만에 디코딩된다고 보고됐다.

34.09 GB 체크포인트는 자동 디바이스 매핑을 통해 32 GB 소비자용 GPU 두 대에 분산할 수도 있다. 이 버전은 재현을 좀 더 가능하게 하지만, 작은 프레임을 위해서는 여전히 과도한 자원 사용이다.

정밀도도 또 다른 제약이다. 공개된 모델은 fp32 가중치를 사용한다. 일반적인 LLM 배포는 더 낮은 정밀도 형식이나 양자화를 통해 메모리와 연산량을 줄이는 경우가 많다.

양자화는 여기서 위험하다. 수치 오류가 단지 언어 확률을 완화하는 데 그치지 않는다. 잔차 스트림 내부의 프로그램 상태, 비교, 주소와 유사한 조회, 상쇄 연산을 손상시킬 수 있다.

Torwright의 컴파일러 문서는 일부 비선형 구성이 구간별 선형 근사를 사용한다고 인정한다. 테스트는 개별 연산의 오차 한계를 측정하고 컴파일된 그래프 노드를 직접 평가와 비교한다.

이러한 안전장치는 증거를 제공할 뿐, 모든 완전한 실행에 대한 수학적 확실성을 보장하지는 않는다. 연산별 오차 한계가 긴 연쇄 전체에 자동으로 합성되는 것은 아니다. 따라서 컴파일러는 더 폭넓은 그래프 프로브와 출력 비교에 의존한다.

프로젝트의 공개 Reddit 토론에서도 이 우려가 직접 제기됐다. Porter는 부주의한 양자화가 저충실도 이미지가 아니라 손상된 출력을 낼 것으로 예상한다고 말했다. 또한 그 시나리오는 테스트하지 않았다고 덧붙였다.

또 다른 한계는 일반성이다. 이 체크포인트는 선택된 영역, 고정 해상도, E1M1 시작 구역 주변에 필요한 텍스처를 지원한다. 모든 Doom 콘텐츠 전반에서 렌더러 전체를 재현하지는 않는다.

스프라이트는 아직 구현되지 않았다. 무기와 상태 바는 권총으로 시작하는 상태에 고정돼 있다. 모델이 렌더링하는 것은 장면이지, 일반적인 게임플레이 시스템을 갖춘 상호작용 게임 루프가 아니다.

프로젝트의 맵 프롬프트도 추론 전에 준비 과정을 거친다. 호스트 측 코드는 레벨을 고정된 월드 공간 영역으로 잘라내고 정적 사실을 토큰으로 인코딩한다. 저장소는 그 경계를 레벨 로딩과 비슷한 것으로 설명한다.

비평가들은 이것이 여전히 트랜스포머 안에서 실행되는 Doom으로 볼 수 있는지 합리적으로 물을 수 있다. 가장 방어 가능한 답은 더 좁다. 뷰 의존적 렌더링 로직이 제약된 Doom 장면을 위한 컴파일된 체크포인트 내부에서 실행된다는 것이다.

Doom 자체가 LLM이 됐다고 주장하는 것은 부정확하다. 이 체크포인트에는 학습된 언어 능력이 없으며, 게임 전체를 구현하지도 않는다. “트랜스포머 호스팅 렌더러”가 더 명확한 설명이다.

Cursor Horizon의 관점도 이 구분을 유지해야 한다. 이 프로젝트는 표준 모델 파일이 표현할 수 있는 범위를 넓히지만, 그래픽 컴퓨팅을 위한 경쟁력 있는 새 경로를 제시하지는 않는다.

또한 폭넓은 독립 검증도 아직 받지 못했다. 저장소는 코드, 가중치, 프롬프트, 측정치, 비교 도구를 제공한다. 하지만 플래그십 결과를 재현하려면 여전히 값비싼 하드웨어와 상당한 다운로드 용량이 필요하다.

커뮤니티 반응은 양면을 반영한다. 개발자들은 컴파일러 아이디어를 칭찬하면서도 성능을 보고 웃었다. 다른 이들은 병렬 출력, 대안적 아키텍처, 확산 시스템이 프레임을 더 효율적으로 렌더링할 수 있는지 물었다.

그러한 제안은 프로젝트의 의도적인 제약 일부를 놓친다. Porter는 일반적인 Hugging Face 클래스가 불러올 수 있는 표준 텍스트 생성 모델을 원했다. 이 선택은 렌더러를 비효율적인 토큰당 한 단계 루프에 묶었다.

아키텍처를 바꾸면 데모의 설득력을 약화시키는 대신 속도는 개선될 수 있다. 이 프로젝트가 흥미로운 이유는 기본적인 인과적 트랜스포머의 한계를 받아들이면서도 렌더링 과정을 완성하기 때문이다.

Cursor Horizon이 다음으로 주시해야 할 것

다음 시험은 또 하나의 인상적인 스크린샷이 아니다. 외부인이 컴파일된 실행을 재현하고, 압축하고, 일반화할 수 있는지가 관건이다.

첫 번째 신호는 독립 재현이다. 제3자는 공개된 저해상도 체크포인트를 실행하고, 출력을 참조 렌더러와 비교하며, 하드웨어와 소프트웨어 세부 사항을 공개해야 한다.

성공적인 재현은 일반 체크포인트가 문서화된 그래프를 실행한다는 주장을 강화할 것이다. 출력이 다르면 트랜스포머 버전, 수치 커널, 디바이스 배치, 부동소수점 동작에 대한 민감성이 드러날 것이다.

두 번째 신호는 저정밀도 실행이다. 검증된 bf16, fp16 또는 양자화 빌드는 프로젝트의 하드웨어 장벽을 낮출 것이다. 또한 torchwright가 정밀도 저하 환경에서 잔차 상쇄와 비교를 관리할 수 있는지 시험하게 된다.

성공한다면 컴파일된 트랜스포머를 연구하고 배포하기가 더 쉬워질 것이다. 실패한다면 정확한 수치 동작이 이 프로그래밍 모델의 주요 제약으로 남는다는 점이 분명해질 것이다.

세 번째 신호는 더 폭넓은 장면 지원이다. 동일한 체크포인트가 재컴파일 없이 여러 위치, 방향, 호환되는 맵 영역을 렌더링해야 한다. 공개된 비교는 플래그십 E1M1 뷰 이상을 다뤄야 한다.

이 시험은 일반적인 렌더러 구현과 고도로 최적화된 데모 경로를 구분할 것이다. 또한 기하 구조와 토큰 수가 달라질 때 추가 전용 상태 메커니즘이 어떻게 작동하는지도 보여줄 것이다.

병렬성은 여전히 중요한 장기 과제다. Porter의 현재 설계는 제한된 계산 단계마다 생성 토큰 하나를 사용한다. 한 패스에서 여러 안전한 연산을 내보내는 시스템은 막대한 디코딩 부담을 줄일 수 있다.

다만 그 변화는 프로젝트의 핵심 주장을 보존해야 한다. 기하 계산이나 가시성 결정을 호스트 코드로 옮기면, 컴파일된 트랜스포머 실행을 개선하는 것이 아니라 렌더러를 이전해 성능을 높이는 셈이다.

향후 torchwright 예시는 더 빠른 Doom 프레임보다 더 많은 정보를 제공할 수 있다. 결정론적 파서, 프로토콜 검증기, 계산기, 투명한 알고리즘 모듈은 실시간 그래픽보다 컴파일러의 강점에 더 잘 맞는다.

컴파일된 로직은 학습된 구성 요소와 결합될 수도 있다. 학습 모델이 모호한 언어를 처리하고, 구성된 서브네트워크가 계산이나 프로토콜을 강제할 수 있다. 이 가능성은 여전히 추측 단계이며 기술적으로 어렵다.

보안 연구자들은 표준 체크포인트 형식도 주시해야 한다. 기존 모델 스캐너는 흔히 직렬화된 코드, 안전하지 않은 로딩, 의심스러운 파일에 집중한다. 직접 구성된 가중치는 기존 실행 파일 코드를 포함하지 않고도 동작을 도입한다.

그렇다고 torchwright가 악의적이라는 뜻은 아니다. 소스와 의도는 이례적으로 공개돼 있다. 더 넓은 교훈은 “커스텀 코드가 없다”가 “프로그래밍된 동작이 없다”를 의미하지는 않는다는 것이다.

개발자들은 파라미터 수를 지능 점수처럼 다루는 것도 피해야 한다. 이 체크포인트가 210억 파라미터를 가진 이유는 컴파일러가 렌더러를 번거로운 아키텍처에 매핑하기 때문이다. 크기만으로는 학습된 지식이나 유용한 추론 능력을 거의 알 수 없다.

Cursor Horizon 독자에게 실질적인 핵심은 트랜스포머에 대한 더 선명한 정신적 모델이다. 학습은 가중치를 설정하는 한 가지 방법이다. 결과가 터무니없이 비효율적이더라도 컴파일도 또 다른 방법이다.

이 프로젝트의 가장 큰 가치는 실행 가능한 주장이라는 데 있다. 익숙한 모델 인프라가 통계적 기억뿐 아니라 결정론적 프로그램도 담을 수 있음을 보여준다. 동시에 전통적인 컴퓨터가 전통적인 계산에 여전히 탁월하다는 점도 보여준다.

실행 추적을 읽고, 컴파일러 그래프를 점검하거나, 더 작은 체크포인트를 재현해 보라. 그런 다음 Doom을 넘어선 핵심 질문을 던져라. 어떤 알고리즘이 transformer-native 실행에서 실질적인 이점을 얻고, 어떤 알고리즘은 그저 비용만 많이 드는 호기심거리로 남는가?