▲

LLM을 컴퓨터로 만들 수 있을까? — 트랜스포머 안에서 직접 프로그램을 실행하는 방법

 (percepta.ai)
12P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • LLM이 수학 올림피아드 수준의 문제를 풀면서도 단순한 덧셈/스도쿠조차 외부 도구 없이는 정확히 수행하지 못하는 한계를 극복하기 위해, 트랜스포머 내부에 실제 컴퓨터를 구축하는 접근법
  • 임의의 C 코드를 토큰으로 변환하여 모델 자체가 수백만 스텝의 실행 트레이스를 직접 생성하며, CPU에서 초당 3만 토큰 이상의 속도로 스트리밍 가능
  • 핵심 기술은 어텐션 헤드 차원을 2D로 제한하여 볼록 껍질(convex hull) 기반의 기하학적 검색으로 전환, 선형 시간 스캔을 로그 시간으로 대체
  • WebAssembly 인터프리터를 트랜스포머 가중치에 구현하여, 외부 도구 호출 없이 모델의 디코딩 루프 안에서 프로그램 실행이 투명하게 이루어짐
  • 향후 프로그램을 가중치로 직접 컴파일하고, 학습된 표현과 컴파일된 알고리듬을 단일 연산 기반에 통합하는 AI 시스템으로의 확장 가능성 제시

LLM의 연산 한계

  • 최첨단 LLM은 국제수학올림피아드 금메달 수준의 문제를 풀거나 미해결 수학·과학 문제에 도전할 수 있지만, 순수 연산 작업에서는 여전히 실패
  • 기본적인 덧셈에서도 오류가 발생하고, Sudoku-Bench 같은 벤치마크에서 외부 도움 없는 풀이 성공률이 매우 낮음
  • 현재 이 격차를 메우는 두 가지 우회 방법 존재
    • 도구 사용(Tool use): 모델이 코드를 작성하면 외부 인터프리터가 실행하고 결과를 반환
    • 에이전트 오케스트레이션: 외부 루프가 중간 상태를 저장하고 작업을 분해하여 모델을 반복 호출
  • 이러한 접근은 유용하지만, 실제 연산 능력이 모델 외부에 존재한다는 근본적 한계를 부각
  • 비유하면 인간이 비행기를 만들었다고 해서 인간이 날 수 있는 것이 아닌 것과 동일한 상황
  • 모델이 연산에 대해 추론하거나 도구를 조율할 수 있지만, 스스로 실행할 수 없으면 진정한 컴퓨터가 아님

트랜스포머를 컴퓨터로 만든 방법

  • 트랜스포머 아키텍처가 튜링 머신을 시뮬레이션할 수 있다는 이론적 보편성은 여러 연구에서 입증되어 있으나, 이론적 표현력이 실용적 실행 효율을 보장하지는 않음
  • 순수 이론적 계산 모델 대신 현대적 RAM 컴퓨터를 트랜스포머 내부에 구현, 각 명령어가 최대 5개 토큰에 매핑
  • 그러나 더 깊은 문제는 디코딩 과정 자체에 존재
    • 표준 오토레그레시브 디코딩은 각 스텝에서 계속 늘어나는 전체 히스토리와 상호작용
    • KV 캐싱이 과거 키/값 재계산을 피하지만, 캐시 크기에 비례하는 어텐션 비용은 여전히 발생
  • 이 한계를 해결하기 위해 어텐션 헤드 차원을 2D로 제한, 실행 스타일 트레이스에 대한 효율적 디코딩 경로를 도입
    • 주요 검색/업데이트 연산이 시퀀스 길이에 대해 로그 시간으로 수행 가능
    • 이를 통해 수백만 스텝의 프로그램을 트랜스포머 내부에서 실행 가능

연산의 의미 — 도구 사용 vs 모델 내 실행

  • 기존 도구 사용 방식: 모델이 python -c "print(3+5)" 같은 코드를 출력 → 외부 인터프리터가 실행 → 결과를 토큰 스트림에 주입
  • 이 시스템의 방식: WebAssembly 인터프리터를 트랜스포머 가중치에 구현
    • WebAssembly는 빠르고 결정론적 실행을 위한 저수준 명령어 세트이자 C/C++의 범용 컴파일 타겟
    • 3 + 5 계산 시 모델이 wasm 명령어(i32.const, i32.add)를 출력한 후 빠른 디코딩 모드로 전환하여 스텝별 실행 트레이스를 직접 생성
  • 핵심 차이점
    • 도구 사용은 불투명(opaque): 모델이 제어를 넘기고 블랙박스 답변을 수신
    • 모델 내 실행은 투명(transparent): 모든 중간 단계가 트레이스에 나타나며, 모델이 자체 디코딩 루프를 벗어나지 않음

스도쿠 데모 — 정확한 장기 연산의 스트레스 테스트

  • 학습된 신경망 접근법은 쉬운 스도쿠에서는 좋은 성능을 보이나 어려운 문제에서 완전히 실패
  • 오토레그레시브 모델이 제약 만족 문제에 근본적으로 부적합하다는 일반적 설명이 있으나, 이 시스템은 완전히 오토레그레시브이면서도 100% 정확도 달성
    • 실제 병목은 오토레그레시브 패러다임 자체가 아니라, 어려운 스도쿠가 매우 긴 실행 트레이스를 요구하고 표준 어텐션이 긴 컨텍스트 생성을 비실용적으로 만드는 것
  • 컴파일된 완전한 스도쿠 솔버를 트랜스포머 내부에서 실행, 학습된 휴리스틱이 아닌 실제 알고리듬을 스텝별로 수행
  • Arto Inkala의 "세계에서 가장 어려운 스도쿠"를 3분 이내에 정확히 해결
  • 컴파일된 솔버가 정확하면 트랜스포머의 실행도 정확하다는 보편적 보장 제공

연산의 인코딩 방식 — 추가만 가능한 트레이스

  • 오토레그레시브 트랜스포머를 자신의 히스토리 안에 사는 기계로 비유
    • 전통적 컴퓨터는 편집 가능한 메모리를 업데이트하지만, 트랜스포머에는 그런 개념이 없음
    • 고정된 프롬프트(입력/프로그램)와 계속 커지기만 하는 트레이스(생성된 토큰)로 구성
  • 추가만 가능한 노트북 비유
    • 첫 줄들은 입력(프롬프트), 이후 각 줄은 연산의 다음 스텝을 기록
    • 이전 줄을 수정할 수 없고, 각 스텝에서 소수의 이전 위치만 참조 가능
  • 많은 알고리듬이 "각 스텝에서 고정된 소수의 이전 위치만 참조하는, 추가만 가능한 트레이스"로 표현 가능
  • 이 시스템에서 모델이 생성하는 토큰은 가상 머신의 명령어 포인터, 메모리/스택 연산, 산술, 제어 흐름, 출력 등 진화하는 상태를 표현
  • 어텐션 헤드는 공유된 1차원 배열처럼 작동하며, 각 토큰이 하나의 인덱스에 값을 쓰고 다른 인덱스에서 값을 읽는 쓰기 후 읽기 프리미티브 제공
  • 어텐션이 누적 합산(cumulative sums) 도 계산 가능하여 명령어 포인터, 스택 깊이 등을 델타 증분의 누적 합으로 추적

핵심 잠금 해제: 지수적으로 빠른 어텐션

  • 실제 컴퓨터는 명령어당 거의 일정한 작업량으로 소형 상태를 업데이트하지만, 표준 트랜스포머는 t번째 디코딩 스텝에서 길이 t의 프리픽스와 상호작용, 총 비용이 이차적으로 증가
  • HullKVCache 도입으로 이 이차적 폭증을 해결
    • 실제 벤치마크에서 HullKVCache는 초당 31,037 토큰(6,747줄/초), 표준 KVCache는 초당 272 토큰(59줄/초)으로, 약 114배 차이
    • 스텝당 Θ(t) 시간 대신 O(log t) 시간으로 어텐션 검색 수행

  • 2D 어텐션의 빠른 경로

    • 트랜스포머를 일반적으로 가속하거나 새로운 아키텍처를 도입하는 것이 아니라, 바닐라 트랜스포머에서 헤드 차원을 2D로 제한하는 다루기 쉬운 파라미터화에 집중
    • d_model = 36, n_heads = 18로 헤드당 정확히 2차원, 7개 레이어, 표준 nn.MultiheadAttention, 게이트드 피드포워드 네트워크 사용
      • 커스텀 어텐션 커널이나 희소 마스크 없이 순수 바닐라 PyTorch로 구성
    • 레이어 수, 헤드 수, 임베딩 크기는 임의로 크게 설정 가능하므로 전체 모델이 작을 필요 없음
      • n_heads = d_model / 2로 더 많은 헤드를 사용

  • 2D 어텐션의 기하학적 관점

    • 어텐션 메커니즘: 과거 토큰이 2D 키 벡터 kⱼ와 값 vⱼ를 제공, 현재 스텝이 쿼리 q를 형성하여 내적이 최대인 키의 값을 반환 (하드맥스 어텐션)
    • 이는 계산기하학의 고전적 "지지점(supporting point) 쿼리" 와 정확히 동일: 방향 q가 주어졌을 때 볼록 껍질에서 해당 방향으로 가장 먼 점을 찾는 문제
    • 토큰 생성과 동시에 볼록 껍질 자료구조를 유지하여 전체 과거 포인트에 대해 로그 시간 검색 가능
    • 메모리/스택 연산을 위해 "인덱스 i에 가장 최근 저장된 값" 조회가 필요하며, 이것이 2D 키를 요구하는 이유
      • 인덱스 j를 2D 키 kⱼ = (2j, -j²)로 저장하고 방향 q = (i, 1)로 쿼리하면 이차 항 -j²가 정확한 매칭만 이기도록 페널티 역할
    • 튜링 완전성을 위해 2D 어텐션이면 충분하며, 이 블로그에서 보여준 것처럼 전체 RAM 컴퓨터를 표현할 수 있음

향후 계획

  • 더 풍부한 어텐션 메커니즘

    • 현재 구현은 하드맥스 어텐션 사용이지만 이는 근본적 제약이 아님
    • k-sparse 소프트맥스 어텐션으로 근사 가능: 중첩된 볼록 껍질에서 상위 k개 키를 검색하여 그것들에 대해서만 소프트맥스 수행, 비용 O(k + log n)
    • 기하학적 빠른 경로가 실행기 구조에만 국한되지 않으며, 원칙적으로 2D 헤드를 가진 모든 트랜스포머의 디코딩 시간을 가속 가능
    • 3D 헤드로도 3D 볼록 껍질을 통해 자연스럽게 확장 가능하나, 더 높은 차원은 효율이 급격히 감소

  • 2D 헤드로 대규모 모델 학습

    • 2D 헤드 파라미터화는 본질적으로 작은 것이 아님 — 더 많은 헤드와 레이어를 사용하여 표준 트랜스포머와 비슷한 총 파라미터 수 유지 가능
    • 여러 활용 모드 가능
      • 더 느리고 범용적인 모델과 결합하는 전용 빠른 경로
      • 단일 시스템 내의 빠름/느림 하이브리드 아키텍처
      • 2D 모델이 토큰을 빠르게 제안하고 일반 어텐션 모델이 검증하는 추측적 디코딩(speculative decoding)
    • 실행 트레이스가 포워드 패스의 일부이므로 전체 과정이 미분 가능(differentiable) — 외부 도구와는 근본적으로 다르며, 더 큰 모델에 직접 통합 가능한 학습 가능한 연산 기반

  • 프로그램을 가중치로 컴파일

    • 현재는 모델이 가중치에 인코딩된 인터프리터를 학습하지만, 가중치 생성 컴파일 기계를 확장하면 임의의 프로그램을 토큰 시퀀스 없이 직접 가중치로 컴파일 가능
    • 가중치 자체가 소프트웨어의 배포 대상(deployment target) 이 되어, 모델이 소프트웨어 같은 행동을 학습하는 것이 아니라 컴파일된 프로그램 로직을 내부 회로의 일부로 포함
    • 로직을 가중치로 컴파일할 수 있다면, 경사 하강법이 모델을 수정하는 유일한 방법이 아니게 됨 — 구조, 알고리듬, 보장을 네트워크에 직접 삽입하는 또 다른 경로
    • 궁극적으로 경험에서 학습할 뿐만 아니라 자신의 가중치를 수정하거나 확장하여 내부 기계를 스스로 재작성하는 시스템으로 발전 가능

  • AI 시스템을 소프트웨어처럼 성장시키기

    • 현대 소프트웨어 생태계가 모듈, 추상화, 재사용 가능한 컴포넌트를 축적하며 진화하듯, AI 시스템 내부에서도 새로운 연산 능력이 점진적으로 추가되는 유사한 과정이 가능
    • 새로운 기능이 전체 시스템을 재학습하지 않고 기존 회로에 연결
    • 미래의 AI 시스템은 소프트웨어를 단순히 사용하는 것이 아니라 소프트웨어를 내부에 포함, 학습된 표현과 컴파일된 알고리듬을 단일 연산 기반에 통합
▲
GN⁺ 2일전  [-]
Hacker News 의견들

  • 단순한 계산 수행보다 훨씬 흥미로운 접근임
    모델이 토큰 수의 로그에 비례하는 동적 어텐션 전환을 수행할 수 있음
    이렇게 하면 텍스트로 표현된 레지스터와 스택을 추적하며 프로그램 실행을 흉내낼 수 있음
    만약 LLM이 ‘집중 모드’로 전환해 매우 빠르게 토큰을 생성할 수 있다면, 수많은 가설을 탐색하고 정리하는 추론 단계를 가속화할 수 있을 것임
    논문에서는 빠른 경로와 느린 경로를 결합한 하이브리드 구조나, 추측 실행(speculative execution) 모델로 활용 가능하다고 제안함

  • 처음엔 “왜 이런 걸 해야 하지?”라는 생각이었지만, 지금은 훈련 부트스트랩 관점에서 보게 됨
    예를 들어 80% 정확도의 전문가 시스템을 모델에 내장하고, 그 결과를 학습 데이터로 삼아 정확도를 높일 수 있음
    다양한 작업의 훈련 비용을 낮출수록 AI 경쟁의 진입 장벽이 낮아짐

    • 하지만 이 접근법은 훈련에는 부적합함
      softmax 어텐션과 달리 average-hard 어텐션은 키와 쿼리에 대해 미분 불가능함
      straight-through 추정으로 보정해도 역전파 속도는 향상되지 않음
    • 훈련은 어렵겠지만, 흥미로운 관련 연구로 이 논문을 참고할 만함

  • 인간의 뇌는 계산 능력이 뛰어나지 않음
    10자리 수 곱셈도 오래 걸림. 이런 계산은 논리 게이트가 훨씬 효율적으로 처리함
    그렇다면 LLM이 직접 계산하기보다 ALU 같은 외부 모듈을 호출하는 게 더 낫지 않을까 생각함

    • 하지만 내장 프로그램을 모델의 다른 가중치와 연결하면, 단순 계산을 넘어 다양한 고정 알고리즘을 통합할 수 있음
    • 또 이 접근은 모델에 기하학적 직관과 공간 추론 능력을 가르치는 메커니즘이 될 수 있음
    • 시도조차 하지 않으면 가능성을 알 수 없음. 결정적 계산을 신경망 내부에 통합하면 도구 호출 오버헤드를 줄일 수도 있음

  • AI가 작성한 듯한 문체지만, 핵심 메시지가 불분명함
    모델이 외부 시스템 대신 내부에서 프로그램을 실행하는 게 왜 좋은지, 속도·역전파·벤치마크 중 어떤 이점이 있는지 명확하지 않음

    • 단순히 “AI가 쓴 글 같다”는 비판보다는, 내용 자체를 논의해야 함
      일부는 상징 논리(symbolic logic)가 필수라고 믿지만, 이런 시도는 단순히 흥미로운 실험으로 볼 수 있음
    • 실제로 논문을 보면, 실행 추적이 순전파의 일부이기 때문에 미분 가능하며, 계산 자체를 통해 그래디언트를 전파할 수 있음
      이는 외부 도구 호출과 근본적으로 다름
      또 O(k + log n) 복잡도의 디코딩 비용을 가지며, Sudoku 같은 문제를 100% 정확도로 푼다면 충분히 의미 있음
      이런 방식을 MoE 스타일로 결합하거나, WASM 기반 VM 내장처럼 다양한 해석기를 실험해볼 수 있을 것임
    • 외부 도구 호출을 제거하면 보안성도 향상됨. 외부 도구가 손상될 위험이 사라짐
    • 모델이 실행 중에 코드를 작성하고 수정할 수 있다는 점이 핵심임. 인간의 “아하 모먼트” 와 유사한 동적 실행임
    • 문체의 반복은 일반 독자를 위한 설명일 수 있음. 인간도 종종 그런 실수를 함

  • 모델의 내부 계산 경로에 도구를 통합하는 아이디어가 해석 가능성 측면에서 매우 흥미로움
    단순한 Transformer로 이런 효율을 낼 수 있다는 점이 놀라움

  • 잠재력은 있지만, 현재 상태로는 실용성이 낮음
    가중치나 “컴파일러” 도구가 공개되지 않아 실험이 어려움
    그래도 사전 정의된 계산 프리미티브를 LLM에 내장하는 아이디어는 여전히 유용할 수 있음

    • 작은 프로그램을 Transformer 가중치에 하드코딩하려면 ALTA를 참고할 만함
    • “neurosymbolic garbage”라는 표현이 무엇을 의미하는지 궁금함

  • 이 문장이 핵심임:
    “실행 추적이 순전파의 일부이기 때문에, 계산 자체를 통해 그래디언트를 전파할 수 있음”
    즉, 외부 도구 호출과 달리 훈련 가능한 계산 기반이 됨

    • 하지만 실제로는 완전한 미분 가능 구조가 아니며, 논문에서도 근사적 방법만 제안함
      또 훈련 데이터나 손실 함수 설계가 불분명함
      다만 도구 호출이 배치 효율성을 깨뜨린다는 점에서, 내부 계산 서브넷을 통과시키면 대규모 효율 향상이 가능함
      다만 그 서브넷이 굳이 Transformer일 필요는 없고, GPU에 최적화된 비학습 레이어로도 충분할 것 같음

  • 논문이 핵심을 숨기고 있음
    어텐션 헤드 차원을 2로 제한하면, 로그 시간 복잡도로 토큰을 검색·갱신할 수 있음
    하지만 왜 이 전략이 “코드 토큰”에만 적용되는지 불분명함
    WASM을 타깃으로 삼은 것도 효율성 측면에서 의문임

    • 두 차원과 RoPE, hard-max 어텐션을 사용하면 상대 주소 지정을 단일 헤드로 구현할 수 있음
    • 그러나 논문은 수식이나 훈련 세부 정보가 부족하고, 비표준 용어를 사용함
      예를 들어 self-attention을 “lookup table”로 표현하는 건 부정확함
      코드 예시에서 d_model = 36, n_heads = 18로 2D per head를 구성했지만, 여전히 불명확함

  • Sudoku 솔버를 Transformer 가중치로 어떻게 컴파일했는지 구체적 설명이 없음
    직접 코드-투-웨이트 컴파일을 했는지, 아니면 학습으로 습득했는지 불명확함

    • 내 해석으로는, 단순한 가상 머신을 가중치에 내장하고, 그 위에서 WASM 런타임을 컴파일한 뒤 솔버를 실행한 것 같음
    • 실제로 논문에는 WASM 인터프리터를 학습했다고 명시되어 있음

  • 흥미롭지만, “왜 굳이 이렇게 해야 하는가”라는 의문이 남음
    인간의 뇌도 튜링 머신을 시뮬레이션할 수 있지만 느림. 그래서 외부 도구를 사용함
    모델도 마찬가지로 외부 도구를 쓰는 게 더 효율적이지 않을까 생각함

    • 논문은 Python 호출의 오버헤드를 줄이기 위해 WebAssembly 내장을 제안하지만, 이는 90년대의 프로세스 vs 스레드 논쟁과 유사함
      Elixir 같은 언어를 내장해 더 짧은 코드를 실행하는 것도 가능할 것임
    • “계산할 수 없는 시스템은 계산을 이해할 수 없다”는 철학적 주장도 흥미로움
      모델이 실행 중에 코드를 수정하거나 디버깅 능력을 가질 수 있다는 발상임
    • 다만 논문은 이런 가능성을 탐구하지 않고, 단순히 실행 엔진 수준에서 멈춤
    • 굳이 프로그램을 가중치로 컴파일할 거라면, 도구 호출 최적화가 더 합리적일 수도 있음
    • 또, 인간이 계산기를 뇌에 내장할 수 있다면 더 빠르고 효율적일 것이라는 비유도 가능함
답변달기