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

관련 논문

• Claude Code는 프롬프트 읽기 전에 33k 토큰을 전송한다; OpenCode는 7k

  동일한 모델과 작업 환경에서 Claude Code와 OpenCode의 실제 토큰 사용량을 API 레벨에서 측정한 결과, Claude Code가 시스템 프롬프트 오버헤드만으로 OpenCode 대비 4.7배 더 많은 토큰을 소비한다는 것을 확인했다.

• Mesh LLM: iroh 기반 분산 AI 컴퓨팅

  사무실, 집, 클라우드에 흩어진 GPU들을 하나의 OpenAI 호환 API로 묶어주는 분산 LLM 실행 시스템으로, 비싼 API 비용 없이 큰 모델을 직접 운영할 수 있다.

• Frugon – LLM API 호출 로그를 분석해서 더 싼 모델로 대체 가능한 구간을 찾아주는 로컬 도구

  내 LLM API 비용이 어디서 새는지 로컬에서 분석해주는 오픈소스 CLI 도구로, 비싼 모델 대신 저렴한 모델로 전환 가능한 호출을 골라낸다.

• 로컬에서 SOTA LLM 실행하기 완전 가이드 (하드웨어부터 설정까지)

  2천 달러짜리 RTX 3090 한 장부터 4만 달러짜리 RTX PRO 6000 4장 셋업까지, 로컬에서 최신 LLM을 직접 돌리는 방법을 하드웨어 선택·구성·실행 설정까지 통째로 정리한 실전 가이드다.

• Manticore Search에서 ONNX 경로를 재설계해 임베딩 속도를 14배 높인 방법

  Manticore Search가 기존 SentenceTransformers/Candle 백엔드를 ONNX Runtime으로 교체해 텍스트 임베딩 생성 속도를 평균 14배 향상시켰다. 별도 모델 서비스 없이 DB 내부에서 직접 임베딩을 처리하는 구조에서 INSERT 속도가 곧 임베딩 속도이기 때문에 이 개선은 실질적인 ingest 처리량 향상으로 직결된다.

• Asymmetric Quantization: 97% 스토리지 절감으로 Late Interaction 검색 품질 유지하기

  멀티벡터 검색 모델의 문서 벡터를 1비트 이진값으로 압축하고 쿼리 벡터만 int8로 유지하는 비대칭 양자화 기법으로, 스토리지를 97% 줄이면서 검색 품질 손실을 0.61점(NDCG@10 기준)에 그치게 만든 실제 프로덕션 적용 사례다.

Related Resources

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