Transformer 내부에서 프로그램을 실행해 지수적으로 빠른 Inference 달성하기

Who Should Read

LLM 추론 속도와 아키텍처에 관심 있는 ML 엔지니어나 연구자, 특히 Tool Calling 방식의 한계를 느끼며 모델 내부 계산 구조를 개선하고 싶은 개발자.

Core Mechanics

• 기존 LLM이 계산을 수행하는 방식은 '모델이 코드를 생성하고 외부 인터프리터가 실행하는' 구조다. 이 연구는 그 계산을 외부 도구 없이 Transformer 내부에서 직접 실행하는 방식을 탐구했다.
• 핵심 기술은 'HullKV'라는 방식으로, Attention Head의 차원을 2차원으로 제한하고 2D 공간의 Convex Hull(볼록 껍질, 점들의 외곽선)만 탐색함으로써 Attention 연산을 기존 O(n)에서 O(log n)으로 줄이는 것이다.
• 이 구조에서 Transformer는 레지스터(임시 저장공간)와 스택(함수 호출 기록)을 텍스트 표현으로 추적하며 프로그램을 단계별로 실행할 수 있다. 즉, 모델 자체가 일종의 CPU처럼 동작한다.
• 컴파일 방식으로 수도쿠 솔버 같은 프로그램을 Transformer 가중치에 직접 구워 넣는 'Code-to-Weight 컴파일러'를 활용했다. 다만 실제 구현 세부사항(학습 데이터, 방법 등)이 글에서 명확히 공개되지 않아 커뮤니티에서 비판을 받았다.
• 이 계산 과정 전체가 미분 가능(differentiable)하다는 점이 외부 Tool Calling과의 핵심 차이다. 즉, 역전파(Backpropagation)로 이 계산 경로 자체를 학습에 포함시킬 수 있어 '훈련 가능한 계산 기판'이 된다.
• 실용적 활용 시나리오로 세 가지를 제안했다: (1) 느린 범용 모델과 짝을 이루는 빠른 전용 경로, (2) 단일 시스템 내 Fast/Slow 하이브리드 아키텍처, (3) 빠른 토큰 제안 후 일반 Attention 모델이 검증하는 Speculative Execution 모델.
• WebAssembly(WASM)를 컴파일 타깃으로 사용했는데, 이는 프로그램 실행을 표준화하기 위한 선택으로 보이지만 커뮤니티에서는 WASM의 표현력 한계가 고수준 추론을 제약할 수 있다는 우려가 제기됐다.

Evidence

• '왜 외부 도구를 쓰면 안 되냐'는 회의론이 많았다. 인간 뇌도 10자리 곱셈은 느리지만 계산기를 쓰면 되듯, LLM도 ALU에 맡기면 더 빠르고 에너지 효율적이지 않냐는 의견이 여러 댓글에서 반복됐다. 이에 대해 '미분 가능성' 때문에 의미가 있다는 반론이 있었는데, 이 계산이 훈련 루프에 통합되면 gradient descent로 프로그램 내 상수나 함수 호출 자체를 최적화할 수 있다는 점이 Tool Calling과 근본적으로 다르다는 주장이었다.
• 학습 방식에 대한 정보 부족이 큰 불만으로 지적됐다. 수도쿠 솔버를 가중치에 구워 넣을 때 손으로 짠 코드를 컴파일러로 변환한 것인지, 아니면 예제 데이터로 학습시킨 것인지조차 글에서 불분명하다는 비판이 있었다. 가중치와 컴파일러 도구가 공개되지 않은 점도 재현 불가능하다는 이유로 비판을 받았다.
• 훈련 데이터 합성 도구로서의 가능성에 주목한 시각도 있었다. 단순히 추론 실행 방식으로 보는 게 아니라, 80% 정확도의 전문가 시스템을 모델에 임베딩해 훈련 비용을 낮추는 방식으로 활용하면 AI 개발 진입 장벽을 낮출 수 있다는 의견이었다.
• 해석 가능성(Interpretability) 연구와의 연관성을 흥미롭게 보는 시각이 있었다. 모델의 동작 일부가 유사-심볼릭(pseudo-symbolic) 방식으로 이루어진다면, 이 연구가 모델 내부를 이해하는 새로운 경로가 될 수 있다는 기대가 댓글에서 표현됐다.
• 글 자체가 AI로 작성된 것 아니냐는 비판도 있었다. 문장은 유려하지만 핵심 질문인 '속도가 빠른가', '벤치마크가 있는가', '역전파를 실제로 적용했는가' 등에 대한 답이 없어 마케팅 글처럼 보인다는 냉소적 의견도 있었다.

How to Apply

• Speculative Decoding 파이프라인을 구축 중인 경우, 이 연구에서 제안하는 'log(n) Attention 소형 모델을 Draft 모델로, 일반 모델을 Verifier로' 쓰는 패턴을 아키텍처 설계 옵션으로 고려해볼 수 있다. 현재 Speculative Decoding은 별도의 소형 언어 모델을 Draft로 쓰는데, 프로그램 실행 특화 모델이 그 역할을 대체하면 특정 연산 집약적 태스크에서 처리량을 높일 수 있다.
• 분류(Classification)나 규칙 기반 로직이 포함된 데이터 라벨링 파이프라인을 운영 중이라면, 기존 전문가 시스템(rule-based classifier)을 모델 가중치로 컴파일해 학습 데이터 생성 비용을 줄이는 방향으로 응용 가능성을 검토할 수 있다. 단, 현재 컴파일러 도구가 공개되지 않았으므로 논문 공개를 기다리며 개념을 파악해두는 수준이 현실적이다.
• Tool Calling 방식의 외부 계산을 모델 내부로 통합하는 실험을 하고 싶다면, 먼저 이 연구의 핵심인 'HullKV + 2D Head Dimension 제한' 방식의 Attention이 어떻게 구현되는지 원문 블로그와 후속 논문을 추적하면서, 소규모 Transformer로 재현 실험을 준비할 수 있다.

Terminology

관련 논문

• Swift로 LLM 학습시키기 Part 1: 행렬 곱셈을 Gflop/s에서 Tflop/s로 끌어올리기

  Apple Silicon에서 Swift로 직접 행렬 곱셈 커널을 구현하며 CPU, SIMD, AMX, GPU(Metal)를 단계별로 최적화해 Gflop/s에서 Tflop/s 수준까지 성능을 높이는 과정을 상세히 설명한 글이다. 프레임워크 없이 LLM 학습의 핵심 연산을 밑바닥부터 구현하고 싶은 개발자에게 Apple Silicon의 성능 한계를 체감할 수 있는 드문 자료다.

• fsync 없이 로컬 스토리지 엔진을 crash-consistent하게 만든 방법

  FractalBits가 fsync 없이 SSD 전용 KV 스토리지 엔진을 구현해 동일 조건 대비 약 65% 높은 쓰기 성능을 달성한 설계 방법을 공유했다. fsync의 메타데이터 오버헤드를 피하기 위해 사전 할당, O_DIRECT, SSD 원자 쓰기 단위 정렬 저널을 조합한 구조가 핵심이다.

• Google Chrome, 사용자 동의 없이 4GB AI 모델(Gemini Nano)을 몰래 설치

  Google Chrome이 사용자 동의 없이 Gemini Nano 4GB 모델 파일을 자동 다운로드하고, 삭제해도 재다운로드되는 문제가 발견됐다. GDPR 위반 가능성과 수십억 대 기기에 적용될 때의 환경 비용 문제가 제기되고 있다.

• OpenAI가 대규모 저지연 Voice AI를 제공하는 방법

  OpenAI가 9억 명 이상의 사용자에게 실시간 음성 AI를 제공하기 위해 WebRTC 스택을 어떻게 재설계했는지 설명하는 글로, relay + transceiver 분리 아키텍처의 설계 결정과 trade-off를 상세히 다룬다.

• Truncated Decoding Tree의 결정론적 탐색을 통한 효율적인 Test-Time Inference

  Self-consistency의 중복 샘플링 낭비를 없애는 결정론적 트리 탐색 디코딩 기법 DLE로 수학/코드 추론 성능과 속도를 동시에 개선

• GoModel – Go로 작성된 오픈소스 AI Gateway

  OpenAI, Anthropic, Gemini 등 여러 AI 프로바이더를 하나의 OpenAI 호환 API로 묶어주는 Go 기반 오픈소스 AI 게이트웨이로, LiteLLM의 컴파일 언어 대안이다.

Related Resources

• Can LLMs Be Computers? (원문 블로그)