TurboQuant

• TurboQuant는 Google Research가 2025년 발표한 LLM KV 캐시 극한 압축 알고리즘
• 모델 재학습 없이 KV 캐시 메모리를 6배 축소하면서 정확도 손실 0인 무손실 양자화 기법
• PolarQuant(극좌표 변환)와 QJL(1비트 오차 보정)의 2단계 파이프라인
• ICLR 2026 채택 논문이자 이론적 최적 한계에 근접한 수학적 보장을 가진 알고리즘

해당 개념이 필요한 이유

LLM이 길어진 대화를 처리할수록 KV Cache 가 차지하는 메모리가 폭발적으로 늘어난다. 컨텍스트 창이 128K → 1M 토큰으로 커지면서 KV 캐시가 모델 가중치보다 더 큰 메모리를 차지하는 역전 현상까지 생겼다.

AS-IS

sequenceDiagram
    autonumber
    participant User as 사용자
    participant LLM as LLM
    participant KVCache as KV 캐시 (메모리)

    User->>LLM: "아까 내가 한 말 기억해?"
    LLM->>KVCache: 이전 토큰 전체 K·V 텐서 저장 (FP16)
    Note over KVCache: LLaMA-2 13B 기준<br/>4K 토큰 = 약 4GB<br/>100K 토큰 = 약 100GB
    KVCache-->>LLM: 메모리 부족 → 대화 길이 제한
    LLM-->>User: 긴 문서 처리 불가 / 느린 응답

TO-BE

sequenceDiagram
    autonumber
    participant User as 사용자
    participant LLM as LLM
    participant TurboQuant as TurboQuant
    participant KVCache as KV 캐시 (메모리)

    User->>LLM: "아까 내가 한 말 기억해?"
    LLM->>TurboQuant: K·V 벡터 압축 요청
    TurboQuant->>TurboQuant: Stage 1: PolarQuant → 3비트
    TurboQuant->>TurboQuant: Stage 2: QJL → 1비트 오차 보정
    TurboQuant->>KVCache: 6배 작아진 캐시 저장
    KVCache-->>LLM: 동일 메모리에서 6배 긴 문맥 처리
    LLM-->>User: 104,000 토큰도 100% 정확 응답

최근 주목받는 이유 3가지

1. 컨텍스트 전쟁의 병목이 정확히 KV 캐시

2025년 이후 LLM들이 32K → 128K → 1M 토큰으로 컨텍스트 창을 키우면서 KV Cache 가 차지하는 메모리가 모델 가중치보다 더 커지는 역전 현상이 발생했다. TurboQuant는 이 병목을 정조준했다.

2. 재학습 없이 즉시 적용

기존 양자화 기법은 모델을 다시 파인튜닝해야 하지만, TurboQuant는 서빙 중 런타임에 바로 적용 가능하다. Gemma, Mistral에 코드 한 줄 추가 수준으로 붙일 수 있다.

3. H100에서 8배 속도 향상 — 클라우드 비용 직결

이 속도 향상은 단순히 “빠르다”는 게 아니라 클라우드 비용 구조를 바꾼다는 의미다.

KV Cache 문서에서 설명한 것처럼 LLM 토큰 생성(Decode Phase)의 병목은 메모리 대역폭이다 — GPU가 캐시에서 K·V 데이터를 읽어오는 속도가 전체 처리 속도를 결정한다.

FP16 KV 캐시: 토큰당 읽어야 할 데이터 = 16비트
TurboQuant KV 캐시: 토큰당 읽어야 할 데이터 = 3.5비트
→ 읽어야 할 데이터 양 = 약 1/4.5

H100 메모리 대역폭 (3.35 TB/s)을 동일하게 쓴다고 하면:
→ 같은 시간에 처리할 수 있는 토큰 수 ≈ 4~8배 증가

AWS H100 인스턴스 비용이 시간당 수십 달러인데, 같은 GPU로 8배 많은 요청을 처리할 수 있다면 토큰당 비용이 1/8로 줄어드는 것과 같다.

작동 원리 — 2단계 파이프라인

전제: 숫자를 줄이면 왜 문제가 생기는가

LLM의 KV Cache에 저장되는 K·V 텐서의 각 숫자는 보통 FP16(16비트)로 저장된다. 이를 3비트로 줄이면 저장 공간이 5배 이상 줄어든다.

문제: 숫자 정밀도를 줄이면 오차가 생긴다. 기존 양자화 방법들은 이 오차를 보정하기 위해 “보정값(normalization constant)“을 블록마다 따로 저장했다.

기존 방법:
[벡터 16개] → 압축 → [3비트 값 16개] + [보정상수 FP16 1개]
실제 압축률: (16 × 3 + 16) ÷ (16 × 16) ≈ 절반밖에 안 됨

TurboQuant의 핵심 아이디어: 보정값이 필요 없는 좌표계로 바꾸면 어떨까?

---

Stage 1 — PolarQuant: “방향과 거리”로 표현을 바꾼다

왜 좌표계 변환인가

고등학교 수학에서 배우는 극좌표계(polar coordinates) 를 떠올려보자. 점의 위치를 표현하는 두 방법이 있다.

방법	표현	특징
직교좌표 (x, y)	“오른쪽 3, 위 4”	기준점이 바뀌면 값도 바뀜
극좌표 (r, θ)	“거리 5, 각도 53°“	거리와 방향이 분리됨

핵심 비유: 다트판과 직교 격자

직교좌표로 표시한 다트 점수 기록표:

선수가 다트를 던진 위치를 (x, y)로 기록
→ 매 경기 전에 "오늘 다트판 크기"(보정값)를 별도로 기록해야 함
→ 판 크기 모르면 좌표가 의미 없음

극좌표로 표시한 다트 점수 기록표:

선수가 다트를 던진 위치를 (거리, 각도)로 기록
→ "정중앙에서 3cm 거리, 시계 2시 방향"
→ 각도는 360° 중 하나 — 판 크기와 무관하게 고정된 의미

KV 캐시 벡터들의 특성상 방향(각도)이 좁은 범위에 몰려 있다. 이 각도들을 미리 만들어둔 고정 격자(codebook) 에 매핑할 수 있어서 보정값 없이 압축이 가능해진다.

PolarQuant 처리 과정:

[K 벡터: (x₁, x₂, ..., x₁₂₈)]
       ↓ 극좌표 변환
[반지름 r (크기)] + [각도 θ₁, θ₂, ... (방향들)]
       ↓
각도들을 고정 코드북의 가장 가까운 격자점에 매핑
       ↓
[r: 4비트] + [각도 인덱스: 3비트 × n개]
보정값(normalization constant): 0비트 필요

이것이 기존 방법이 1~2비트 오버헤드를 피할 수 없었던 것을 완전히 제거하는 방식이다.

---

Stage 2 — QJL: “그림자”로 오차를 1비트에 담는다

PolarQuant 이후에도 오차가 남는 이유

아무리 정교하게 극좌표로 변환해도 3비트로 줄인 이상 미세한 오차가 남는다. 이 오차가 Attention 점수 계산에 쌓이면:

원래 계산: score = Q · K_original
압축 후:   score = Q · K_compressed
오차:      Δ = Q · (K_original - K_compressed)

이 Δ가 크면 모델이 “어느 토큰에 집중해야 하는지” 판단을 잘못 내린다.

존슨-린덴슈트라우스 변환 — 고등학생 비유

여론조사 비유:

전국 5000만 명의 정치 성향을 파악하고 싶다. 각 사람의 성향을 1~100점으로 정확히 물을 수도 있지만, QJL은 다른 접근을 한다.

전통적 방법: "정치 성향 점수 말해주세요" → 정밀한 숫자 → 저장 공간 大
QJL 방법:   "이 정책에 찬성하나요?" (예/아니오만) → 1비트 → 저장 공간 극소

핵심은 무작위로 선택한 질문 여러 개에 예/아니오만 모아도, 그 집합이 전체 오차의 방향(편향) 을 충분히 포착한다는 수학적 증명이다. 이것이 존슨-린덴슈트라우스 정리다.

그림자 비유 (더 직관적):

오차 벡터 = 3D 공간의 물체

QJL이 하는 일:
1. 무작위 방향에서 손전등으로 비춘다 (랜덤 사영)
2. 그림자가 생기는지 안 생기는지만 기록 (+1 또는 -1, 단 1비트)
3. 여러 방향에서 반복

→ 정밀한 3D 형상은 모르지만, 물체의 "기울어진 방향"(편향)은 정확히 파악
→ 이 편향을 Attention 점수에서 빼면 오차 보정 완료

실제 계산 흐름

# Stage 1: PolarQuant 압축
k_compressed = polar_quant(k_original)  # 3비트로 압축
 
# Stage 2: QJL 오차 보정
residual = k_original - k_compressed    # 남은 오차
random_proj = random_matrix @ residual  # 무작위 사영 (고정 시드)
sign_correction = sign(random_proj)     # 부호만 저장 (1비트)
 
# Attention 계산 시
score = query @ k_compressed + correction_factor(sign_correction)
# 오차 보정된 정확한 Attention 점수

성능 — 숫자로 보는 결과

항목	기존 (FP16)	TurboQuant (3.5비트)
KV 캐시 메모리	기준	1/6 (83% 절감)
Attention 연산 속도 (H100)	기준	최대 8배 빠름
Needle-in-haystack 정확도	100%	100% (104K 토큰)
LongBench 점수	기준	동등 or 초과
재학습 필요 여부	—	불필요

이론적 보장 — “증명된 한계치”

TurboQuant의 차별점은 수학적으로 최적에 가깝다는 증명이 있다는 것이다.

정보이론에서 양자화의 이론적 최솟값(MSE 왜곡 하한)이 존재한다. TurboQuant는 이 한계치의 ~2.7배 이내에서 동작하고, 1비트 극한 압축에서도 ~1.45배 이내다. “잘 되더라”가 아니라 “얼마나 최적에 가까운지 증명된” 알고리즘이다.

TurboQuant는 VRAM을 얼마나 줄여주는가

TurboQuant는 KV 캐시만 압축한다. 모델 가중치(weights)는 건드리지 않는다.

VRAM은 두 가지를 담는다:

VRAM = [모델 가중치] + [KV 캐시]
          고정            변동 (컨텍스트 길이에 비례)

항목	무엇인가	TurboQuant 영향
모델 가중치	35B 파라미터 자체	❌ 건드리지 않음
KV 캐시	대화 기록 메모리	✅ 6배 압축

Qwen 3.5 35B 실제 계산

모델 가중치:
  FP16 원본:    ~70GB  → 64GB GPU도 부족
  Q4 양자화:    ~20GB  → 24GB GPU에서 가능

KV 캐시 (Q4 가중치 기준, 32K 컨텍스트):
  FP16 KV 캐시:           ~16GB
  TurboQuant 3비트 KV:    ~3GB

합산:
  Q4 가중치 + FP16 KV (32K):         20 + 16 = 36GB → 40GB 필요
  Q4 가중치 + TurboQuant KV (32K):   20 +  3 = 23GB → 24GB에서 가능 ✅
  Q4 가중치 + TurboQuant KV (64K):   20 +  6 = 26GB → 32GB에서 가능 ✅

TurboQuant의 실제 가치는 “더 작은 GPU에서 같은 모델”이 아니라 “같은 GPU에서 훨씬 긴 대화” 를 가능하게 하는 것이다.

시나리오	TurboQuant 이전	TurboQuant 이후
RTX 4090 (24GB)에서 35B	Q4 + 4K 컨텍스트만 가능	Q4 + 32K 컨텍스트 가능
A100 (80GB)에서 70B	32K 컨텍스트 한계	192K 컨텍스트 가능
서버 1대로 동시 요청 처리	배치 크기 제한	6배 더 많은 동시 요청

---

품질과 속도 — 비트 수에 따른 트레이드오프

품질: 비트 수에 따라 스펙트럼이 있다

“정확도 손실 0”은 마케팅 표현이고, 실제로는 비트 수에 따라 달라진다.

비트 수	코사인 유사도	실용적 품질	권장 대상
4비트	0.997	사실상 동일	대부분의 서비스
3.5비트	~0.995	LongBench 기준 동등 or 초과	긴 문서 처리
3비트	~0.98	8B 이상 모델에서 무시 가능	메모리 최우선
2비트	0.94	체감 가능한 품질 저하	비권장

TurboQuant가 압축하는 건 KV 캐시 — 즉 “이미 처리한 이전 토큰들의 기억”이다. 모델의 추론 능력 자체(가중치)는 그대로라서 짧은 대화에서는 품질 차이가 거의 없다. 컨텍스트가 길어질수록(50K+ 토큰) 누적 오차가 조금씩 영향을 줄 수 있다.

속도: 오히려 빨라진다

KV Cache Decode Phase의 병목은 메모리 읽기 속도(bandwidth) 다. 데이터가 작아지면 읽는 시간도 줄어든다.

FP16 (16비트): GPU가 토큰당 16비트 × N개 읽음
TurboQuant 3비트: GPU가 토큰당 3비트 × N개 읽음
→ 읽어야 할 데이터 양 = 약 1/5
→ 같은 bandwidth에서 5배 빠른 처리 가능

환경	속도 향상
H100 (4비트 기준)	최대 8배 (attention logit 연산)
RTX 4090 (vLLM 플러그인)	3.7배 (decode throughput)

KV 벡터를 압축하는 오버헤드는 논문 기준 “negligible” — GPU 연산 대비 무시 가능한 수준이다.

---

커뮤니티 구현 현황 (2026년 3월 기준)

논문 발표(2026.03.24) 일주일 만에 llama.cpp, vLLM, MLX 모두 커뮤니티 구현이 나왔다. Google 공식 릴리즈(Q2 2026) 전에 이미 사용 가능한 상태다.

llama.cpp (로컬 실행)

./build/bin/llama-server \
  -m models/your-model.gguf \
  --cache-type-k turbo4 \   # Key 캐시 → 4비트
  --cache-type-v turbo4 \   # Value 캐시 → 4비트
  -ngl 99 \
  -c 262144 \               # 262K 토큰 컨텍스트
  -fa on \
  --host 0.0.0.0 --port 8080

기존 q8_0, q4_0 KV 캐시 타입과 동일한 방식으로 교체하면 된다.

vLLM (프로덕션 서버)

pip install turboquant-vllm

from turboquant_vllm import CompressedDynamicCache
 
cache = DynamicCache()
compressed = CompressedDynamicCache(cache, head_dim=128, bits=4)
# RTX 4090 기준 3.76x 압축 + 3.7x 빠른 decode

MLX (Apple Silicon)

Qwen 3.5 35B + 64K 컨텍스트 테스트 결과:

KV 캐시 크기: 4.9배 감소 (2.5비트)
Needle-in-haystack: 6/6 완벽 정답 유지

커뮤니티 검증 수치

구현	압축 방식	압축률	논문 MSE	구현 MSE
llama.cpp gist	TQ3 (3비트)	4.9x	0.034	0.034 ✅
llama.cpp gist	TQ4 (4비트)	3.8x	0.009	0.009 ✅
vLLM plugin	4비트	3.76x	—	cos_sim=0.997 ✅

실전 주의사항

이슈	내용
fp32 필수	FP16 계산 시 36 레이어 누적 오차 → 11,397 토큰 이후 출력 깨짐
비트 선택	4비트가 손실 없는 최적 균형점. 2비트는 소형 모델에서 품질 저하
레이어 제한	Full attention 레이어만 지원, Mamba/Linear attention 미지원

권장 설정: --cache-type-k turbo4 --cache-type-v turbo4 (4비트)

---

참고 문서

• Google Research Blog — TurboQuant
• ICLR 2026 논문 (OpenReview)
• Tom’s Hardware 분석
• MarkTechPost 요약
• llama.cpp Discussion #20969
• 0xSero/turboquant (vLLM + Triton)
• vLLM feature request #38171
• DEV Community — vLLM 72시간 후기