왜 지금 KV 캐시·벡터 검색이 병목이 됐나 — 구글 터보퀀트 KV캐시 6배 축소 2/12

시리즈: 구글 터보퀀트 KV캐시 6배 축소 (총 12편) | 2회

왜 지금 KV 캐시·벡터 검색이 병목이 됐나

LLM 컨텍스트가 길어질수록 KV 캐시가 GPU 메모리를 잡아먹고, 대규모 벡터 검색은 인덱스 구축 비용이 발목을 잡아. 터보퀀트가 왜 이 두 병목을 동시에 겨냥했는지, 그리고 2단계 압축 구조가 어떻게 작동하는지 정리했어.

Summary

• 컨텍스트 길이가 늘어나면 KV 캐시가 선형으로 커져 GPU OOM과 처리량 저하가 동시에 온다
• 벡터 검색은 인덱스 메모리와 코드북 학습 비용이 지배하는데, 터보퀀트는 데이터-무관 방식으로 이를 우회한다
• 터보퀀트는 회전 후 주 양자화(1단계) + QJL 잔차 보정(2단계) 파이프라인으로 극단 압축을 달성한다

이 글의 대상

• LLM 서빙 비용 구조가 궁금한 ML 엔지니어·MLOps 담당자
• 대규모 벡터 DB 운영 중에 인덱스 메모리 문제를 겪어본 사람
• 양자화 기술의 작동 원리를 쉽게 이해하고 싶은 개발자

목차

1. KV 캐시는 왜 터지나
2. 벡터 검색의 진짜 비용
3. 터보퀀트의 2단계 압축 구조
4. 압축 상태에서 내적을 계산하는 원리
5. 핵심 정리
6. FAQ
7. 참고 자료
8. 다음 편 예고

---

1. KV 캐시는 왜 터지나

컨텍스트 길이가 늘어나는 만큼 KV 캐시도 정직하게 커진다. 트랜스포머는 매 토큰을 생성할 때마다 이전 토큰들의 key와 value를 저장해 재사용해. 덕분에 반복 계산을 피할 수 있지만, 반대로 컨텍스트가 길어질수록 이 캐시가 GPU HBM(고대역폭 메모리)을 선형으로 잡아먹는다는 뜻이기도 해.

실제 서빙 환경에서 이게 어떤 문제로 이어지냐면:

상황	결과
동시 세션 수를 늘릴 때	KV 캐시가 HBM을 채워 OOM이 먼저 터진다
배치 크기를 줄일 때	처리량이 떨어지고 토큰당 비용이 뛴다
긴 컨텍스트를 제공하려 할 때	GPU를 더 많이 붙여야 해서 인프라 비용이 폭증한다

결국 “더 긴 컨텍스트”와 “더 많은 동시 사용자”라는 두 방향 모두 KV 캐시가 병목이 돼. 모델 자체가 아니라 KV가 GPU를 다 써버리는 상황이 오는 거야.

터보퀀트의 접근은 여기서 출발해. “KV를 줄여서 컨텍스트 경제성을 바꾼다”는 거거든.

---

2. 벡터 검색의 진짜 비용

벡터 검색의 승부처는 “임베딩을 얼마나 싸게 저장하고, 얼마나 빨리 근사 최근접을 찾느냐”야. 검색 품질 자체보다 이 비용 구조가 실제 운영을 좌우하는 경우가 많아.

기존 PQ(Product Quantization) 계열 방식은 압축률이 꽤 높지만, 문제가 있어:

• 코드북 학습: 데이터를 보고 최적화하는 과정이 필요해
• 인덱스 구축: 데이터가 커질수록 빌드 시간이 부담이 된다
• 튜닝 비용: 데이터 분포가 바뀌면 재학습이 필요하다

1억 개, 10억 개 규모의 벡터를 다루는 환경에선 인덱스 빌드 자체가 수십 시간씩 걸리기도 해. 새 데이터를 빠르게 추가하거나, 분포가 자주 바뀌는 경우엔 PQ 계열이 발목을 잡는 거야.

터보퀀트는 데이터-무관(data-independent) 방식을 표방해. 코드북 학습 없이 인덱스 빌드 시간을 사실상 없애면서 리콜을 유지하겠다는 거지.

---

3. 터보퀀트의 2단계 압축 구조

터보퀀트는 한 가지 트릭이 아니라 2단계 파이프라인으로 이해해야 정확해.

1단계: 회전으로 분포를 정돈하고, 낮은 비트로 크게 줄인다

고차원 벡터를 그냥 좌표별로 독립 양자화하면 손해가 커. 왜냐면 좌표 간에 상관관계가 있고, 분포가 비대칭한 경우가 많거든. 특정 좌표는 값이 몰려 있고, 어떤 좌표는 극단값이 튀는 식으로.

터보퀀트는 먼저 직교 회전(Π) 을 벡터에 적용해. 이 회전은 벡터의 정보(내적값)를 보존하면서 분포를 “양자화하기 좋은 형태”로 만들어 줘. 쉽게 말하면, 에너지를 여러 좌표에 고르게 퍼뜨리는 거야.

회전 후에는 좌표별 스칼라 양자화를 적용해. 구글 리서치 블로그에선 이를 PolarQuant 라고 부르고, OpenReview 논문은 “회전 후 centroid 기반 최적 스칼라 양자화”로 더 엄밀하게 정리해.

핵심 구조:
원본 벡터 x
  → 직교 회전 Π 적용
  → 좌표별 낮은 비트 스칼라 양자화 (x̂_mse)
  → 1단계 압축 완료

2단계: 잔차를 1비트로 보정하는 QJL

1단계만으로는 내적 계산에서 편향이 생길 수 있어. 양자화 오차가 누적되면 실제 유사도 순위가 틀어지거든.

그래서 터보퀀트는 QJL(Quantized Johnson–Lindenstrauss) 을 추가해. 작동 방식은 이래:

1. 잔차 r = x − x̂(1단계 복원) 를 구한다
2. 이 잔차를 랜덤 프로젝션한다
3. sign(±1)만 저장한다

저장 비용이 1비트/차원 수준으로 제한되면서 내적 왜곡을 줄이는 역할을 해. 구글 블로그는 QJL을 “zero-overhead”에 가깝게 표현하는데, 엄밀히는 1비트열(qjl)과 잔차 노름 γ(스칼라) 저장이 들어가. 다만 전통 PQ류가 블록마다 스케일·오프셋 같은 메타데이터를 많이 달고 다니는 것과 비교하면, “숨은 오버헤드가 작다”는 주장은 타당해.

---

4. 압축 상태에서 내적을 계산하는 원리

터보퀀트의 진짜 목표는 “압축해서 저장”에서 끝나지 않아. 압축된 채로 내적을 계산하는 거야.

OpenReview 논문의 전개를 따르면 내적은 이렇게 분해돼:

⟨y, x̂⟩ ≈ ⟨y, x̂_mse⟩ + const · γ · ⟨S·y, qjl⟩

각 항이 뭘 의미하냐면:

항	의미	연산 방식
⟨y, x̂_mse⟩	1단계 양자화 결과와의 내적	저비트 곱산
⟨S·y, qjl⟩	QJL 잔차 보정항	qjl이 1비트라 popcount 비트 연산 으로 처리 가능
γ	잔차 노름 스칼라	단순 곱셈

qjl이 1비트로 패킹되어 있어서 popcount 같은 비트 연산으로 빠르게 처리할 여지가 생겨. CPU/GPU 모두에서 고속 비트 연산을 쓸 수 있거든.

단, 쿼리 측에서 S·y 같은 추가 변환 비용이 생기는 것도 사실이야. 그래서 “압축이 곧 가속”이 자동으로 되는 건 아니고, 어떤 경로가 실제 병목인지에 따라 성능 이득이 갈려.

---

핵심 정리

1. KV 캐시는 컨텍스트 길이에 비례해 선형으로 커지며,
   GPU 메모리를 빠르게 채워 동시 처리량과 비용을 동시에 악화시킨다

2. 벡터 검색의 병목은 압축률보다 인덱스 빌드 비용과
   코드북 학습·갱신 부담이다

3. 터보퀀트 1단계: 직교 회전으로 분포를 정돈한 뒤
   낮은 비트(극단 압축) 스칼라 양자화를 적용한다

4. 터보퀀트 2단계: QJL이 잔차를 1비트/차원으로 보정해
   내적 편향을 낮은 오버헤드로 교정한다

5. 압축된 채로 내적을 분해·계산하는 구조 덕분에
   복원 없이 유사도 검색이 가능하다 — 단, 병목 위치가 성패를 가른다

---

FAQ

Q. KV 캐시가 뭔지 모르는데, 쉽게 설명해줄 수 있어?

A. 트랜스포머 모델이 글을 생성할 때, 이전에 처리한 내용을 매번 다시 계산하면 너무 느려. 그래서 이미 계산한 key와 value 값을 메모리에 저장해두는 게 KV 캐시야. 대화가 길어질수록 이 저장량이 계속 늘어나는 구조야.

Q. HBM이 뭐야?

A. HBM(High Bandwidth Memory)은 GPU에 붙어있는 고속 메모리야. A100 기준으로 80GB 정도인데, LLM 모델 가중치 + KV 캐시 + 활성화값이 여기에 다 들어가야 해. 컨텍스트가 길어지면 KV 캐시 혼자 이 공간을 잡아먹기 시작해.

Q. 직교 회전이 왜 양자화에 도움이 돼?

A. 양자화는 연속적인 값을 몇 단계로 끊어서 저장하는 건데, 분포가 고르지 않으면 오차가 커져. 직교 회전은 벡터의 정보(길이·내적)를 그대로 유지하면서 에너지를 좌표 전체에 고르게 퍼뜨려. 고른 분포에선 같은 비트 수로 오차가 훨씬 작아져.

Q. QJL의 “Johnson–Lindenstrauss”는 뭘 가리키는 거야?

A. Johnson–Lindenstrauss 보조정리(JL lemma)는 “고차원 벡터를 랜덤 프로젝션으로 저차원에 투영해도 거리·내적이 대략 보존된다”는 수학적 결과야. QJL은 이 원리를 극단으로 밀어붙여서 1비트(±1 부호)만 저장해도 잔차 방향 정보를 어느 정도 살릴 수 있다는 아이디어야.

Q. PQ 계열 대비 터보퀀트가 유리한 게 정확히 뭐야?

A. PQ(Product Quantization)는 데이터를 보고 코드북을 학습해야 해. 데이터 분포가 바뀌면 재학습이 필요하고, 대규모 인덱스 빌드에 시간이 오래 걸려. 터보퀀트는 데이터를 안 봐도 되는 데이터-무관 방식이라 빌드 시간을 사실상 없앨 수 있어. 단, 데이터에 맞게 최적화하는 PQ가 특정 분포에선 더 유리할 수 있어.

Q. 2단계 구조에서 QJL을 빼면 어떻게 돼?

A. 1단계(회전 + 스칼라 양자화)만 쓰면 내적 편향이 생겨. 특히 비트 수를 극단으로 낮출수록 오차가 커지거든. QJL이 이 편향을 1비트라는 최소 비용으로 보정하는 역할을 해. 빼면 같은 압축률에서 검색 정확도(리콜)가 더 떨어질 가능성이 높아.

Q. “데이터-무관”이라는 게 정확히 무슨 의미야?

A. 일반적인 압축 방식은 “이 데이터의 분포를 분석해서 최적화된 코드북을 만든다”는 식이야. 데이터에 의존하는 거지. 데이터-무관 방식은 데이터를 분석하지 않고도 작동하는 수학적 구조(랜덤 회전, 랜덤 프로젝션 등)를 써. 대신 특정 데이터에 맞게 최적화되진 않아.

Q. popcount 비트 연산이 왜 빠른 거야?

A. popcount는 비트열에서 1의 개수를 세는 연산인데, CPU/GPU 모두 하드웨어 수준에서 극히 빠르게 지원해. QJL 잔차가 1비트(±1)로 패킹되어 있으면, 내적 계산을 부동소수점 곱셈 대신 popcount로 처리할 수 있어서 연산량이 대폭 줄어들어.

Q. 이 구조가 추론 속도를 실제로 빠르게 만들어?

A. 항상 빠른 건 아니야. “압축 = 자동 가속”이 아니거든. 쿼리 처리 시 S·y 같은 추가 변환 비용도 생기기 때문에, 실제 병목이 어디 있냐에 따라 달라져. KV 캐시나 인덱스 메모리가 병목인 상황에선 유효하지만, 연산 자체가 병목이면 효과가 제한적일 수 있어.

---

참고 자료 (References)

데이터 출처

출처	설명	링크
Google Research 블로그	터보퀀트 공식 소개, PolarQuant·QJL 직관적 설명	링크
arXiv 2504.19874	터보퀀트 논문 사전공개본	링크
OpenReview PDF	수식 전개 포함 기술 상세, 내적 분해 공식	링크

핵심 인용

“TurboQuant는 KV를 줄여서 컨텍스트 경제성을 바꾼다는 접근이다.”
— Google Research 블로그

“QJL은 잔차를 랜덤 프로젝션한 뒤 sign만 저장해, 추가 저장비를 1비트/차원 수준으로 제한하면서 내적 왜곡을 줄인다.”
— OpenReview PDF (TurboQuant)

---

다음 편 예고

[3편] 비트폭 하나가 메모리·속도·품질을 동시에 바꾼다 — TurboQuant 트레이드오프 완전 정리

• 비트 수를 낮출수록 압축률과 오차가 어떻게 달라지는지
• 실제 벤치마크에서 리콜·정확도와 압축률의 교환 관계
• “몇 비트가 현실적인 선택인가”를 판단하는 기준