Google TurboQuant 개념 및 원리 정리

 

 

1. 왜 TurboQuant가 등장했나

LLM이 느려지는 이유는 단순하다.

메모리 때문이다

 

LLM 내부 실제 구조

LLM은 토큰을 생성할 때마다

KV cache (Key, Value)

 

를 계속 저장한다.

문제

• 토큰 길어질수록 KV cache 증가
• 메모리 사용량 폭증
• GPU는 계산 못 하고 기다림

👉 이걸 “memory wall”이라고 부름

 

 

2. 기존 해결 방식의 한계

기존에도 압축은 있었다.

대표적으로:

• Vector Quantization
• Product Quantization

문제

압축하면 → 정확도 깨짐
정확도 유지하면 → 메모리 못 줄임

 

또 하나 중요한 문제:

압축하면서 추가 데이터(정규화 값 등)가 필요함

 

👉 오히려 메모리 다시 증가

 

 

3. TurboQuant의 핵심 아이디어

“정보를 유지하면서 최소 비트로 표현”

 

핵심 결과

• KV cache → 3bit까지 압축
• 메모리 → 최소 6배 감소
• 속도 → 최대 8배 향상

4. TurboQuant 알고리즘 구조 (핵심 2단계)

1️⃣ PolarQuant (핵심 압축)

기존 방식:

(x, y, z) → 그대로 압축

 

 

TurboQuant:

벡터 → (크기, 방향)으로 분리

 

• radius (크기)
• angle (방향)

왜 이게 중요하냐

• 방향 정보는 패턴이 있음
• 분포가 집중됨

👉 적은 비트로 표현 가능

핵심 효과

❌ 복잡한 정규화 필요 없음
⭕ 추가 메모리 오버헤드 제거

 

2️⃣ QJL (오차 보정)

압축하면 당연히 오차 생김

 

TurboQuant 해결 방식:

남은 오차 → 1bit로 보정

 

• Johnson-Lindenstrauss 기반
• 거리/유사도 유지

 

 

핵심 효과

압축하면서도
attention 결과 정확도 유지

5. 왜 정확도가 안 깨지냐

 

1️⃣ Attention 구조 특성

softmax(query · key)

 

👉 큰 값만 영향

 

 

2️⃣ 벡터 구조 보존

TurboQuant는:

• 단순 값 보존 ❌

거리/내적 유지 ⭕

 

👉 LLM은 값보다 **관계(유사도)**가 중요

 

6. 왜 속도가 빨라지는가 (진짜 핵심)

 

기존

큰 KV cache 읽기 → 느림

 

 

TurboQuant

작은 데이터 읽기 → decompress → 계산

 

 

핵심 비교

(작은 데이터 읽기 + decompress) << (큰 데이터 읽기)

 

 

👉 메모리 I/O가 압도적으로 비싸기 때문

실제 병목

GPU는 연산이 아니라
메모리 대기 상태가 문제

7. 왜 decompress가 싸냐

• bit unpack = 매우 단순 연산
• GPU 병렬 처리 가능

레지스터에서 바로 실행

👉 결론:

연산 조금 늘리고
메모리 접근 크게 줄이는 구조

8. TurboQuant의 진짜 의미

이건 단순 압축 기술이 아니다.

 

 

핵심 변화

기존

성능 = 연산 성능

 

 

현재 LLM

성능 = 메모리 대역폭

 

 

TurboQuant

메모리 병목 제거 → 성능 상승

 

 

 

9. 중요한 오해 (이건 꼭 알아야 함)

❌ “전체 메모리 6배 감소”

아님

 

 

⭕ 실제

KV cache만 줄어듦
(추론 단계 일부)

 

👉 모델 weight, storage는 영향 없음

 

10. 실무 영향 

효과

• GPU 메모리 절약
• 더 긴 context 처리 가능
• batch 증가
• latency 감소
• 비용 절감

특히 중요한 포인트

Inference 비용 ↓

11. 한 줄 정리

TurboQuant는
KV cache를 구조적으로 압축해서
메모리 병목을 제거하는 기술

 

🔥 최종 핵심 요약 (진짜 중요)

• KV cache = LLM 병목
• TurboQuant = KV cache 압축
• 핵심 기술 = PolarQuant + QJL
• 효과 = 메모리 ↓ + 속도 ↑
• 이유 = 메모리 I/O 감소