Google TurboQuant, LLM 메모리를 6배 줄이고 속도를 8배 올렸다

3월 25일, Google Research가 TurboQuant를 공개했습니다. LLM의 Key-Value(KV) 캐시를 3비트로 압축하면서 정확도 손실은 제로입니다. Nvidia H100 GPU에서 어텐션 연산 속도가 최대 8배 빨라지고, KV 캐시 메모리는 6배 이상 줄어듭니다. 학습도, 파인튜닝도, 데이터 캘리브레이션도 필요 없습니다. Hacker News에서 479점을 받으며 인터넷은 즉시 이 기술을 HBO Silicon Valley의 Pied Piper에 비유했습니다.

KV 캐시가 왜 문제인가

LLM이 텍스트를 생성할 때, 이전에 처리한 모든 토큰의 Key와 Value 벡터를 메모리에 저장합니다. 이것이 KV 캐시입니다. 모델이 새 토큰을 생성할 때마다 이 캐시를 참조해서 문맥을 유지합니다. 문제는 컨텍스트가 길어질수록 이 캐시가 기하급수적으로 커진다는 것입니다.

100만 토큰 컨텍스트 윈도우를 가진 최신 모델들의 경우, KV 캐시만으로 수십 GB의 GPU 메모리를 소모합니다. GPU 메모리는 유한하고 비쌉니다. 결과적으로 KV 캐시는 동시에 처리할 수 있는 요청 수, 지원 가능한 최대 컨텍스트 길이, 그리고 추론 비용 모두를 제약하는 핵심 병목입니다.

기존에도 KV 캐시를 압축하는 양자화 기법들이 있었습니다. 하지만 대부분 캘리브레이션 데이터가 필요하거나, 모델별 파인튜닝이 요구되거나, 비트 수를 너무 줄이면 정확도가 떨어지는 한계가 있었습니다. TurboQuant는 이 세 가지 문제를 동시에 해결했습니다.

극좌표 변환이라는 발상의 전환

TurboQuant의 핵심 아이디어는 놀라울 정도로 우아합니다. 2단계 압축 전략으로 구성됩니다.

1단계는 PolarQuant입니다. AISTATS 2026에서 발표될 이 기법은 벡터 데이터를 데카르트 좌표에서 극좌표로 변환합니다. 각 벡터가 반지름(크기)과 각도(방향)로 분리되면, 각도 분포가 예측 가능하고 집중된 형태가 됩니다. 이 덕분에 기존 양자화에서 필수적이던 per-block 정규화 단계를 완전히 건너뛸 수 있습니다. 이것만으로도 상당한 메모리 오버헤드가 사라집니다.

2단계는 QJL(Quantized Johnson-Lindenstrauss)입니다. AAAI 2024에서 이미 발표된 이 기법은 원소당 단 1비트, 즉 부호(+1 또는 -1)만으로 수학적 오류 보정을 수행합니다. 고정밀 쿼리와 저정밀 압축 데이터 사이의 균형을 맞추는 특수 추정기(estimator)를 사용해서, 3비트까지 압축해도 어텐션 스코어의 정확도를 유지합니다.

두 기법의 조합이 TurboQuant(ICLR 2026)입니다. 결정적으로, 이 전체 과정에 학습이 필요 없습니다. 모델 가중치를 건드리지 않고, 캘리브레이션 데이터도 요구하지 않습니다. Google Research의 Amir Zandieh와 Vahab Mirrokni(VP, Google Fellow)가 이끄는 팀은 이를 "data-oblivious"하다고 설명합니다. 어떤 모델에든, 어떤 데이터에든 바로 적용할 수 있습니다.

숫자가 말하는 것들

Google Research 팀은 Gemma, Mistral, Llama-3.1-8B-Instruct 등 다양한 모델에서 TurboQuant를 검증했습니다. LongBench, Needle In A Haystack, ZeroSCROLLS, RULER, L-Eval 등 5개 벤치마크에서 QA, 코드 생성, 요약 작업을 테스트했습니다.

결과는 세 가지 숫자로 요약됩니다.

메모리 6배 감소. 32비트 FP16 KV 캐시를 3비트로 압축하면서 다운스트림 정확도 손실이 없었습니다. Needle-in-a-haystack 검색 작업에서는 완벽한 점수를 기록했습니다. 100만 토큰 컨텍스트에 H100 8장이 필요했다면, 이론적으로 2장이면 충분해집니다.

속도 8배 향상. H100 GPU에서 4비트 TurboQuant의 어텐션 logit 연산 속도가 32비트 대비 최대 8배 빨라졌습니다. 이는 메모리 대역폭 병목을 크게 완화한 결과입니다. LLM 추론에서 각 토큰 생성 시 KV 캐시 전체를 읽어야 하는데, 캐시가 작아지면 읽는 시간도 비례해서 줄어듭니다.

정확도 0% 손실. 벡터 검색 벤치마크에서는 Product Quantization, RabbiQ 같은 기존 기법들을 GloVe 데이터셋(d=200) 기준 1@k 리콜에서 능가했습니다.

이것이 의미하는 것: 추론 경제학의 변화

TurboQuant의 파급력을 이해하려면 현재 AI 추론 비용 구조를 알아야 합니다.

데이터센터 수준에서는 비용 혁신입니다. 추론 제공업체들은 동일 하드웨어에서 6배 더 많은 long-context 요청을 처리할 수 있습니다. OpenAI가 올해 $14B를 태울 것으로 예상되는 가운데, 이런 효율성 향상은 AI 사업의 경제적 지속가능성에 직접 기여합니다. Google이 이 기술을 자체 인프라에 먼저 적용할 것은 분명합니다. Google은 검색, Gemini, Cloud AI 서비스에서 매일 천문학적인 추론을 수행하고 있으며, TurboQuant 같은 압축 기술의 가장 절실한 수요자이기도 합니다.

온디바이스 AI에는 새로운 가능성이 열립니다. 3비트 KV 캐시는 소프트웨어만으로 스마트폰에서 32K 이상의 컨텍스트 윈도우를 가능하게 합니다. 최근 iPhone 17 Pro에서 400B 파라미터 LLM이 동작하는 데모가 등장했는데, TurboQuant 같은 KV 캐시 압축은 이런 온디바이스 모델의 실용적 컨텍스트 길이를 획기적으로 늘릴 수 있습니다.

벡터 검색에도 적용됩니다. TurboQuant는 KV 캐시뿐 아니라 대규모 벡터 인덱스 구축과 쿼리에도 사용할 수 있습니다. RAG(검색 증강 생성) 시스템이 보편화되면서, 수억 개의 벡터를 메모리 효율적으로 저장하고 검색하는 것은 점점 더 중요한 인프라 과제가 되고 있습니다.

커뮤니티의 열기와 회의

Hacker News에서 479점을 기록한 TurboQuant 스레드에는 129개의 댓글이 달렸습니다. 반응은 열광과 회의가 공존합니다.

가장 주목할 만한 움직임은 구현 속도입니다. 공개 당일에 이미 llama.cpp 구현이 시작되었고, 놀라울 정도로 적은 코드량으로 동작한다는 보고가 올라왔습니다. 한 개발자는 Google 원본의 O(d²) 랜덤 회전을 Subsampled Randomized Hadamard Transform으로 대체해 O(d·log d) 로 개선하기까지 했습니다. 독립적인 PyTorch 구현도 등장했는데, 커뮤니티 반응은 "Google 원본 블로그보다 설명이 명확하다"였습니다.

회의적 시각도 만만치 않습니다. 한 댓글은 핵심을 찔렀습니다.

"정확도 대 공간 차트만 보여주고 end-to-end 레이턴시를 숨긴다면, 보통 실제 코드가 fp16보다 느리다는 뜻입니다."

극좌표 변환이 GPU 병렬화에 불리할 수 있다는 기술적 지적도 나왔습니다. GPU는 규칙적인 메모리 접근 패턴에 최적화되어 있는데, 극좌표 변환이 이 패턴을 깨뜨릴 가능성이 있다는 것입니다.

인용 누락 논란도 터졌습니다. 한 연구자(amitport)는 자신의 2021년 NeurIPS 논문 "DRIVE"가 TurboQuant의 핵심인 회전 기반 바이어스 보정 기법의 선행 연구라고 주장했습니다. "Google이 내 논문을 읽고 발표까지 초청해놓고 인용하지 않았다면 문제"라는 날카로운 비판이 뒤따랐습니다. 다른 댓글러들은 더 직접적이었습니다.

"Johnson-Lindenstrauss는 고전적 기법입니다. 이 맥락에서는 몇 년마다 재발견됩니다."

블로그 포스트 자체의 품질도 비판 대상이었습니다. Y축이 0 대신 48에서 시작하는 차트, "this clever step" 같은 AI가 생성한 듯한 문장 등이 지적되었습니다.

MLA와의 관계: 보완인가 경쟁인가

KV 캐시 문제를 해결하는 또 다른 접근법으로 Multi-Head Latent Attention(MLA)이 있습니다. DeepSeek V2에서 도입된 이 기법은 모델 학습 단계부터 KV 캐시를 저차원으로 압축합니다. HN 토론에서 한 사용자가 둘의 관계를 명확히 정리했습니다.

"MLA는 처음부터 학습에 포함되어야 합니다. 반면 VQ(벡터 양자화)는 사후에 적용할 수 있고, 두 기법을 결합하는 것도 가능합니다."

이것이 TurboQuant의 실질적 강점입니다. 이미 학습된 모든 모델에 바로 적용할 수 있습니다. MLA를 사용하려면 처음부터 다시 학습해야 하지만, TurboQuant는 Llama든 Gemma든 Mistral이든 기존 모델에 그대로 씌울 수 있습니다. 학습 비용이 수천만 달러에 달하는 프론티어 모델 시대에, 재학습 없는 최적화의 가치는 막대합니다.

물론 장기적으로는 MLA와 TurboQuant를 결합하는 것이 최적일 수 있습니다. MLA로 학습 단계에서 KV 캐시 차원을 줄이고, 추론 시 TurboQuant로 비트 수를 추가로 압축하는 이중 최적화입니다.

Google의 수직 통합 전략

한 Hacker News 댓글이 TurboQuant의 전략적 맥락을 정확히 짚었습니다.

"Google은 수직 통합되어 있고 실제로 AI 인프라 비용을 지불합니다. 모델 크기를 줄이려는 인센티브가 더 절실합니다."

Google은 TPU를 설계하고, 데이터센터를 운영하고, Gemini를 학습시키고, 검색과 Cloud AI에서 추론을 서빙합니다. AI의 전체 스택을 소유한 기업에게 추론 효율화는 직접적인 비용 절감입니다. OpenAI가 Microsoft Azure에 의존하고, Anthropic이 AWS/GCP를 함께 쓰는 것과 대조적입니다.

TurboQuant를 ICLR 2026에서 공개 논문으로 발표한 것도 주목할 만합니다. Google은 이 기술을 독점하지 않고 오픈 연구로 내놓았습니다. 이는 AI 압축 기술의 표준화를 주도하려는 의도로 읽힙니다. 실제로 공개 당일 llama.cpp 구현이 시작된 것에서 보듯, 오픈소스 생태계의 빠른 채택이 Google의 연구 영향력을 확대합니다.

아직 남은 질문들

TurboQuant가 인상적인 숫자들을 제시했지만, 실전 배포까지는 검증해야 할 것들이 있습니다.

첫째, end-to-end 레이턴시입니다. 어텐션 logit 연산이 8배 빨라졌다는 것은 전체 추론 파이프라인의 일부일 뿐입니다. 극좌표 변환과 역변환 오버헤드가 전체 레이턴시에 미치는 영향은 아직 명확하지 않습니다.

둘째, 대규모 프로덕션 환경에서의 안정성입니다. 벤치마크에서의 정확도 보존이 수십억 건의 실제 서비스 요청에서도 유지되는지 검증이 필요합니다. 특히 코드 생성이나 수학 추론 같은 정밀도가 요구되는 작업에서의 edge case는 충분히 테스트되었는지 의문입니다.

셋째, GPU 아키텍처 의존성입니다. H100에서의 8배 속도 향상이 다른 GPU(A100, L40, 소비자용 GPU)에서도 비슷한 비율로 나타나는지 확인이 필요합니다. GPU마다 메모리 대역폭과 연산 유닛의 비율이 다르기 때문에, 압축의 효과도 달라질 수 있습니다.

AI 효율성 경쟁의 새로운 전선

TurboQuant는 더 큰 모델을 만드는 경쟁이 아니라, 같은 모델을 더 적은 자원으로 돌리는 경쟁의 최전선에 있습니다.

2026년 AI 산업은 이중적 압력 아래 놓여 있습니다. 한쪽에서는 모델이 계속 커지고 컨텍스트 윈도우가 100만 토큰을 넘어가고 있습니다. 다른 쪽에서는 AI 기업들의 연간 수백억 달러에 달하는 비용이 지속가능성 의문을 키우고 있습니다. TurboQuant 같은 추론 효율화 기술은 이 두 압력 사이에서 경제적 균형점을 찾는 열쇠가 될 수 있습니다.

Google Research의 Vahab Mirrokni(VP, Google Fellow)가 이끄는 이 프로젝트는 단순한 학술 연구가 아닙니다. 세계에서 가장 많은 AI 추론을 수행하는 기업이, 자사 인프라의 핵심 병목을 해결하기 위해 만든 기술입니다. 학습 불필요, 데이터 불필요, 모델 불문. 이 세 가지 특성이 TurboQuant를 단순한 논문에서 실전 무기로 만듭니다.

llama.cpp 구현이 공개 당일에 시작된 것은 우연이 아닙니다. 오픈소스 커뮤니티가 이 기술의 실전 가치를 즉시 인식했다는 뜻입니다. 앞으로 몇 주 안에 주요 추론 프레임워크(vLLM, TGI, Ollama)에 TurboQuant 지원이 추가될 가능성이 높습니다. 그때가 되면 우리는 3비트 KV 캐시가 단순한 연구 결과인지, 아니면 AI 추론 비용의 구조적 변화를 이끄는 전환점인지 판단할 수 있을 것입니다.