TurboQuant는 결국 무엇이 대단한 걸까? LLM의 KV 캐시 압축을 쉽게 읽기

안녕하세요! FLUX CTO인 Edwin Li입니다.

최근 TurboQuant라는 논문이 상당히 화제가 되고 있습니다.

"KV 캐시 (KV Cache)를 3bit 대까지 압축할 수 있다고 한다", "긴 컨텍스트 (Long Context)를 더 저렴하게 다룰 수 있을지도 모른다"라는 말을 들으면 확실히 대단해 보입니다.

다만, 논문 제목이나 소개만 봐서는 솔직히 "그래서 무엇이 그렇게 새로운 거지?"라는 의문이 들기 쉬운 테마이기도 합니다.

이 논문이 흥미로운 이유는 모델 본체의 가중치 (Weights)를 가볍게 만드는 이야기가 아니라, 추론 (Inference) 중에 계속해서 늘어나는 KV 캐시를 잘 압축하는 이야기이기 때문입니다. Google Research 또한 TurboQuant를 긴 컨텍스트에서의 추론이나 벡터 검색 (Vector Search)에 효과적인 기반 기술로 소개하고 있습니다.

이 이야기는 단순한 논문 소재로 끝나지 않습니다.

로컬 LLM, 에이전트 (Agent), 장문 컨텍스트, 벡터 검색과 같이 지금 한창 달아오르고 있는 모든 테마와 연결되어 있습니다. The Register에서도 TurboQuant는 메모리 수요를 없애기보다는, 오히려 긴 컨텍스트를 사용하는 애플리케이션을 더욱 늘릴 수도 있다고 보고 있습니다.

이번에는 TurboQuant의 무엇이 새롭고, 왜 지금 이토록 주목받고 있는지 최대한 쉽게 정리해 보려고 합니다. 수식을 자세히 쫓기 전에 우선 전체적인 상을 파악하는 것이 목적입니다. 어디까지나 논문 해독 편으로 봐주시기 바랍니다.

!

본 기사는 TurboQuant를 깊이 이해하기 위한 전편·후편 2부작으로 전달해 드립니다.

• 전편 (이 기사): 논문의 배경·핵심 아이디어·업계에 미치는 영향을 정리한다
• 후편 (다음 기사): Python으로 최소 구현을 진행하고, community 구현의 지견과 함께 구동한다

이 기사에서 알 수 있는 것

• KV 캐시란 무엇이며, 왜 긴 컨텍스트에서 병목 현상 (Bottleneck)이 발생하는가
• TurboQuant의 핵심 아이디어가 대략적으로 무엇을 하고 있는가
• AI 업계·메모리 업계·오픈 모델 생태계에 어떤 일이 일어날 수 있는가
• 논문의 주장과 실제로 구현해 본 사람들의 온도 차

우선 결론

먼저 결론부터 적겠습니다.

TurboQuant의 본질은 **"고차원 벡터를 그대로 대충 뭉개는 것이 아니라, 랜덤 회전 (Random Rotation)으로 정보를 균등하게 만든 후, 각 좌표를 적절히 스칼라 양자화 (Scalar Quantization)하고, 나아가 잔차 (Residual)를 1bit로 보정한다"**는 설계에 있습니다.

풀어서 말하자면, TurboQuant는

"긴 문맥을 다루는 AI의 '단기 기억'을 최대한 정밀도를 해치지 않으면서 똑똑하게 압축하는 기술"

입니다.

여기서 중요한 것은 모델의 가중치를 가볍게 만드는 이야기가 아니라, 추론할 때마다 점점 불어나는 메모리 쪽을 줄이는 이야기라는 점입니다. 그렇기 때문에 장문 채팅, RAG, 코딩 에이전트, 로컬 실행과의 궁합이 매우 좋습니다. Google Research의 소개에 따르면, 장문 벤치마크에서 품질을 크게 떨어뜨리지 않으면서 KV 메모리를 최소 6배 압축할 수 있으며, 4-bit에서는 H100 상에서 attention logits의 계산 속도가 최대 8배 빨라졌다고 합니다.

애초에 KV 캐시란 무엇인가?

Transformer 계열의 LLM은 과거 토큰의 Key (키)와 Value (밸류)를 저장해 두었다가, 다음 토큰을 생성할 때 재사용합니다. 이 메커니즘이 KV 캐시입니다.

짧은 대화에서는 문제가 되지 않지만, 컨텍스트가 길어지면 KV 캐시는 점점 불어납니다. 그러면 VRAM을 압박하게 되어, "모델 본체는 올라가는데, 긴 문맥이 되면 갑자기 힘들어지는" 현상이 발생합니다.

이 부분이 조금 까다로운데, 평소 자주 듣는 양자화 (Quantization)는 "모델의 가중치를 16bit → 8bit / 4bit로 만드는 이야기"인 경우가 많습니다.

하지만 TurboQuant가 노리는 것은 그것이 아닙니다. 모델 본체가 아니라, 추론 중에 늘어나는 작업용 메모리를 줄이는 것이 주안점입니다. 그렇기 때문에 "같은 GPU로 더 긴 컨텍스트를 다룰 수 있게 될지도 모른다"라는 이야기로 이어집니다.

XDA Developers의 기사에서는 예를 들어 Llama 3.1 8B로 128K 컨텍스트를 다룰 때, FP16의 KV 캐시만으로 약 16GB에 달하는데, TurboQuant라면 2.5bit에서 약 3GB, 3.5bit에서도 약 3.5GB 정도까지 낮출 수 있을 가능성이 있다는 감각적인 시산이 소개되어 있습니다.

왜 지금 TurboQuant가 화제인가

TurboQuant가 단순한 논문 소개 이상의 화제가 되고 있는 이유는, AI 업계의 몇 가지 큰 흐름과 잘 맞물려 있기 때문이라고 생각합니다. 순서대로 살펴보겠습니다.

AI 업계에 무엇이 변하는가

지난 1~2년 사이, 파운데이션 모델 (Foundation Model)의 성능은 상당히 높은 수준에 도달했습니다.

그 결과, 현장에서는 "모델이 얼마나 똑똑한가"뿐만 아니라, 얼마나 긴 컨텍스트 (Context)를, 얼마나 저렴하게, 얼마나 빠르게 돌릴 수 있는가가 갑자기 중요해지고 있습니다.

Zenn의 트렌드 관찰 기사에서도 "2026년은 추론 모델의 시대에서 구현의 시대로"라는 견해가 나왔습니다. AI가 대단하다는 것뿐만 아니라, "실제로 도입했을 때 무엇이 병목 (Bottleneck)인가", "어디에서 현실적인 문제에 부딪히는가"를 이야기하는 기사가 읽히는 분위기가 되어가고 있습니다.

TurboQuant의 의의는 바로 이 "운용의 병목"에 직접적으로 작용하는 기술이기 때문입니다. 모델의 IQ를 높이는 이야기가 아니라, 같은 똑똑함을 가진 모델을 더 길게, 더 저렴하게 움직일 수 있도록 만드는 이야기입니다. 이 점이 지금의 흐름과 맞닿아 있습니다.

메모리 업계에 영향은 있는가

TurboQuant가 발표된 후, 일부 시장 관계자들이 "AI 메모리 수요가 줄어드는 것 아니냐"라고 반응하며 메모리 반도체 주가가 움직였던 장면이 있었습니다.

다만, The Register는 상당히 냉정한 견해를 보이고 있습니다. TurboQuant는 모델 자체를 작게 만드는 기술이 아니라, KV 캐시 (KV Cache) 측면을 압축하는 기술이며, 오히려 이를 통해 긴 컨텍스트를 사용하는 애플리케이션이 늘어나 결과적으로 메모리 수요는 더욱 늘어날 가능성이 높다고 정리했습니다.

이 견해는 직관적으로도 납득하기 쉽습니다.

압축을 통해 1회당 비용이 낮아지면, 업계는 종종 "그만큼 더 많이 사용한다"는 방향으로 나아갑니다. Seeking Alpha에서도 Morgan Stanley의 애널리스트가 "추론이 저렴해지면 그만큼 수요가 늘어날 것"이라는 견해를 보였습니다.

오픈 모델 에코시스템에 어떻게 작용하는가

로컬 LLM을 구동하는 사람들에게 KV 캐시 압축의 임팩트는 매우 직접적입니다.

예를 들어 24GB 클래스의 소비자용 GPU에서는 그동안 "큰 모델을 올릴 것인가" 아니면 "긴 컨텍스트를 가져갈 것인가"를 두고 상당히 가혹한 트레이드오프 (Trade-off)가 있었습니다. XDA Developers의 기사가 지적하듯, TurboQuant와 같은 KV 압축이 실용화되면 그 트레이드오프가 상당히 완화됩니다.

모델의 가중치 (Weight)가 같더라도 KV 캐시가 4~5배 작아진다면, 남는 VRAM으로 긴 컨텍스트를 가져오거나 동시 실행 수를 늘릴 수 있습니다. 이는 Ollama나 LM Studio를 사용하여 개인 환경에서 LLM을 돌리는 사람들에게 경험 자체가 바뀔 수 있는 수준의 이야기입니다.

OpenClaw와 같은 에이전트 시대와 어떻게 연결되는가

최근 흐름에서 빼놓을 수 없는 것이 OpenClaw로 대표되는 퍼스널 AI 에이전트 (Personal AI Agent) 화제입니다.

OpenClaw는 모델 자체가 아니라, 로컬에서 동작하는 개인 AI 어시스턴트의 제어 프레임워크입니다. WhatsApp, Slack, Discord 등 기존 메시징 앱과 연동되며, 영속적인 메모리를 가지고 셸 커맨드 (Shell Command) 실행이나 파일 조작 등의 도구를 사용하여 태스크를 자동화할 수 있습니다.

여기서 TurboQuant가 힘을 발휘합니다.

에이전트가 다루는 태스크는 긴 이력을 참조하거나, 여러 도구를 호출하거나, 다단계 추론을 수행하는 등 긴 컨텍스트를 갖는 것 자체가 전제가 되기 쉽습니다. 즉, KV 캐시를 저렴하게 유지할 수 있는 기술은 에이전트의 실용성을 끌어올리는 기반이 됩니다.

OpenClaw의 문서를 보면 Ollama, LM Studio, vLLM 등 로컬 계열 모델 프로바이더 (Model Provider)와 유연하게 연결할 수 있도록 설계되어 있습니다. 이는 오픈 웨이트 모델 (Open Weight Model)을 교체해가며 에이전트를 운용하는 세계가 현실화되고 있다는 뜻입니다. 그렇게 되면 "어떤 모델이 가장 똑똑한가"뿐만 아니라 "얼마나 가볍게 긴 컨텍스트를 다룰 수 있는가"가 점점 더 중요해집니다.

TurboQuant의 개념을 대략적으로 파악하기

이제부터 논문의 내용으로 들어갑니다.

다만, 갑자기 수식을 따라가면 상당히 힘들 수 있으므로, 우선 "무엇을 하고 싶은가"와 "어떤 2단계 구조인가"만 파악해 두겠습니다.

TurboQuant가 목표로 하는 것은 고차원 벡터를 가능한 한 적은 비트 (Bit)로 표현하면서도, 원래 벡터들 사이의 관계(특히 내적 (Inner Product))를 최대한 깨뜨리지 않는 것입니다.

LLM의 attention이나 벡터 검색 (Vector Search)에서는 벡터의 내적 (Inner Product)이 「어떤 정보가 중요한가」를 결정하는 열쇠가 됩니다. 따라서 단순히 압축할 수만 있으면 되는 것이 아니라, 압축 후에도 내적이 크게 어긋나지 않는 것이 매우 중요합니다.

단계 1: 랜덤 회전 후 양자화 (Quantization)

TurboQuant에서 가장 먼저 수행하는 것은 입력 벡터에 랜덤한 직교 행렬 (Orthogonal Matrix)을 곱하여 「회전」시키는 것입니다.

이것이 직관적으로 가장 흥미로운 포인트입니다.

원래의 좌표계 상태 그대로라면 차원마다 정보의 편향이나 상관관계가 있어, 각 좌표를 제각각 양자화하면 오차가 커질 수 있습니다. 그래서 일단 랜덤하게 회전시켜서, 정보를 좌표 전체에 균등하게 분산시킨 후 양자화하기 쉬운 형태로 만듭니다.

논문에서는 회전 후의 각 좌표가 특정 분포 (Beta 분포)를 따른다는 점을 이용하여, 각 좌표마다 상당히 우수한 스칼라 양자화기 (Scalar Quantizer)를 설계할 수 있음을 보여줍니다. 이것이 「고차원 벡터 양자화를 다루기 쉬운 1차원 문제로 분해하는」 아름다운 지점입니다.

단계 2: MSE를 작게 만드는 스칼라 양자화

단계 1에서 회전시킨 후, 각 좌표를 Lloyd-Max 방식의 스칼라 양자화로 압축합니다.

목적은 우선 MSE (Mean Squared Error)를 작게 만드는 것입니다. 즉, 「재구성된 벡터가 원래 벡터로부터 얼마나 떨어져 있는가」를 억제합니다.

Google Research의 소개에서는 이 고품질 압축 부분을 PolarQuant의 개념으로 설명하고 있습니다.

PolarQuant에 의한 좌표 변환 이미지 (Google Research 인용)

PolarQuant에 의한 좌표 변환 이미지 (Google Research 인용)

쉽게 바꿔 말하면, 여기서는

「원래 벡터의 대략적인 형태를 최대한 무너뜨리지 않으면서 적은 비트 (Bit)로 옮겨 적는 것」

을 수행하고 있습니다. 압축의 대부분은 이 단계가 담당합니다.

단계 3: 잔차에 1bit QJL을 적용하여 내적의 오차 보정

하지만 MSE가 작다고 해서 attention에 충분하다는 뜻은 아닙니다.

attention은 본질적으로 벡터의 내적으로 작동하기 때문에, 재구성 오차가 작더라도 내적에 계통적인 오차 (Bias)가 발생하면 곤란합니다.

그래서 TurboQuant는 단계 2에서 남은 오차 (잔차, Residual)에 대해 1bit의 Quantized Johnson-Lindenstrauss (QJL)라는 기법을 사용하여 보정을 가합니다.

논문에서는 이 잔차 보정을 통해 내적 추정에 편향 (Bias)이 생기기 어려워지는 것이 핵심이라고 설명합니다. 이것이 TurboQuant를 단순히 「MSE를 작게 만드는 양자화」가 아니라, attention을 겨냥한 양자화라고 부를 수 있는 이유입니다.

TurboQuant는 무엇을 최적화하고 있는가

이 논문을 읽을 때 가장 중요한 점은 TurboQuant가 바라보는 목표가 하나가 아니라는 것입니다.

주로 두 가지 목표가 있습니다:

• MSE (Mean Squared Error): 재구성된 벡터가 원래 벡터로부터 얼마나 떨어져 있는가
• 내적 왜곡 (Inner Product Distortion): 벡터 간의 내적이 압축에 의해 얼마나 어긋나는가

MSE만 본다면 「겉보기의 유사성」은 유지할 수 있습니다.

하지만 LLM의 attention에서는 query와 key의 궁합, 즉 내적이 매우 본질적입니다. 따라서 TurboQuant는 복원 오차뿐만 아니라 내적이 얼마나 망가지는지까지 제대로 고려하고 있습니다. 이것이 "KV 캐시용 양자화"로서 매우 타당한 접근 방식인 이유입니다.

이론적 주장

이론적인 측면에서 TurboQuant는 정보 이론적 하한 (Shannon lower bound)에 상당히 가까운 왜곡률을 달성할 수 있다고 주장합니다.

구체적으로는 전체적으로 약 2.7배 이내, 1bit의 경우에는 약 1.45배 수준입니다.

물론 「이론적으로 가깝다」는 것과 「구현해서 그대로 작동한다」는 것은 별개의 문제입니다.

다만, 양자화 관련 연구는 구현상의 잔기술처럼 보이기 쉬운 반면, 이 논문은 이론적 뒷받침이 매우 탄탄하기 때문에 「왜 이런 설계인가」를 추적하기 쉽다는 장점이 있습니다.

실험에서 무엇이 증명되었는가

논문에서는 DBpedia Entities나 GloVe와 같은 벡터 검색용 데이터뿐만 아니라, Llama-3.1-8B-Instruct 또는 Ministral-7B-Instruct와 같은 LLM을 사용한 평가가 이루어졌습니다.

Needle-In-A-Haystack 계열의 테스트에서는 3.5 bits per channel에서 거의 품질에 영향이 없었으며, 2.5 bits per channel에서도 경미한 저하에 그쳤다고 보고되었습니다.

Google Research의 소개에 따르면, LongBench, Needle-In-A-Haystack, ZeroSCROLLS, RULER, L-Eval과 같은 장문 벤치마크에서 TurboQuant는 우수한 다운스트림 태스크 (downstream task) 성능을 유지하면서 KV 메모리를 최소 6배까지 압축할 수 있었다고 합니다. 또한, 4-bit TurboQuant를 통한 attention logits 계산의 가속화도 강조되었습니다.

나아가 벡터 검색 용도에서도 PQ (Product Quantization) 등과 비교하여 좋은 재현율 (recall)을 달성했다고 소개되었으며, Google은 TurboQuant를 LLM 추론뿐만 아니라 고차원 벡터 검색 기반에도 효과적인 것으로 위치시키고 있습니다.

냉정하게 보면, TurboQuant는 "마법"이 아니다

여기까지 읽으면 "그럼 앞으로는 전부 TurboQuant로 해결되는 것 아닌가?"라는 생각이 들고 싶어집니다.

하지만 냉정하게 살펴봐야 할 포인트가 몇 가지 있습니다.

모델 본체는 작아지지 않는다

The Register도 지적했듯이, TurboQuant는 모델의 가중치 (weights)를 압축하는 기술이 아닙니다. 어디까지나 KV 캐시 (KV cache) 측의 압축이므로, 모델 가중치가 지배적인 경우(예를 들어 컨텍스트가 짧은 경우)에는 효과에 한계가 있습니다.

논문의 설계가 곧바로 최적해라고 할 수는 없다

이 부분이 구현 편으로 가기 위한 포석이기도 합니다만, 커뮤니티의 구현을 보면 논문의 아름다움과 현장의 최적해 사이에는 격차가 있다는 것을 알 수 있습니다.

예를 들어 scos-lab/turboquant라는 레퍼런스 구현에서는 몇 가지 흥미로운 보고가 있습니다:

Key와 Value의 노름 (norm) 차이가 매우 큰 모델이 있다. Qwen 계열에서는 Key의 노름이 Value의 50~1000배 이상이 되는 경우가 있어, 동일한 비트 폭을 할당하는 것은 상당히 비효율적이다.

논문이 권장하는 Prod 방식 (QJL 포함)보다, MSE-only 방식이 실제 attention 품질 면에서는 오히려 더 좋다. QJL의 잔차 보정은 이론상 바이어스 (bias)를 제거하지만, 분산 (variance)이 증가하여 softmax가 그 분산을 증폭시켜 버린다.

dejan.ai의 구현 기사에서도 QJL을 재구성 벡터에 그대로 더하면 노이즈가 증가하여 코사인 유사도 (cosine similarity)가 대폭 떨어졌기 때문에, KV 캐시에는 MSE-only를 사용하는 것이 더 좋았다고 보고되었습니다.

또한 같은 기사에서는 Hadamard 변환을 Python 루프로 작성하면 CUDA 커널이 잘게 쪼개져 실행되어 처참할 정도로 느려진다거나, HuggingFace의 DynamicCache를 서브클래싱 (subclassing)하면 버전 차이로 인해 깨지기 쉽다는 등의 구현상의 함정도 공유되었습니다.

즉 TurboQuant는 논문으로서는 상당히 강력하지만, 구현으로 옮길 때는 "논문의 권장 사항대로"가 반드시 최선은 아닌 타입의 연구입니다. 이는 부정적인 이야기가 아니라, 오히려 구현해 볼 가치가 있는 이유이기도 합니다.

이 논문의 관전 포인트 3가지

개인적으로 이 논문의 관전 포인트는 3가지가 있다고 생각합니다.

첫 번째는, 양자화 (quantization)를 "비트를 줄이는 것뿐인 이야기"로 만들지 않았다는 점입니다.

MSE와 내적 (inner product)의 왜곡을 나누어 생각하여, attention의 본질에 다가간 설계가 되어 있습니다.

두 번째는, random rotation을 축으로 삼아 고차원 문제를 스칼라 양자화 (scalar quantization)로 풀기 쉽게 만들었다는 점입니다.

이론적 전망이 좋아 "왜 이 설계로 작동하는가"를 구현을 읽으면서도 쉽게 추적할 수 있습니다.

세 번째는, 지금의 AI 분위기와 일치한다는 점입니다.

모델의 성능이 충분히 올라온 지금, 차이를 만드는 것은 컨텍스트 길이, 추론 비용, 동시 실행, 에이전트 (agent) 운용입니다. 그 지점에 TurboQuant가 직접적으로 꽂힙니다. 그렇기에 이 논문은 단순한 학술적 소재 이상으로 화제가 되고 있다고 생각합니다.

다음 예고: 구현 편에서 할 일

이번에는 논문의 전체적인 모습을 파악하는 데 집중했기 때문에, 코드는 의도적으로 다루지 않았습니다. 하지만 TurboQuant의 진정한 재미는 이론과 구현 사이의 간극에 있습니다.

따라서 다음 회차인 「구현 편」에서는 다음과 같은 흐름으로 그 핵심에 다가갈 예정입니다:

• random rotation + scalar quantization (스칼라 양자화)의 최소 데모를 Python으로 작성하고 실행하기
• TurboQuant의 Step 1 (MSE 양자화)만 재현하기
• 가능하다면 QJL 잔차 보정 (residual correction)의 효과도 확인하기
• 커뮤니티 구현이 "왜 MSE-only에 치우쳐 있는지"를 직접 손으로 비교하기

요약

언뜻 보면 「KV 캐시 압축」이라는 수수한 주제로 보일 수 있는 TurboQuant이지만, 사실은 「더 똑똑한 모델」에서 「더 길게, 저렴하게, 실용적으로 구동하는」 방향으로 키를 잡은 현재의 AI 트렌드 정중앙에 위치한 논문입니다. 이 논문의 가치는,

random rotation → MSE-optimal scalar quantization → residual QJL

이라는 3단계 구성을 이론과 실험 양면에서 정교하게 구축했다는 점에 있습니다.

한편, 구현 현장에서는 QJL의 취급 방법, Key와 Value의 비대칭적인 비트 배분, GPU 커널화(kernelization)의 필요성 등 논문을 읽는 것만으로는 보이지 않는 논점들이 많이 존재합니다.

솔직히 말해서, TurboQuant는 논문을 읽고 납득하는 것 이상으로, 직접 구현해 보아야 비로소 재미있어지는 타입의 연구라고 생각합니다.

다음 구현 편에서는 그 "손맛"을 확실히 전달해 드릴 예정이니, 꼭 지켜봐 주세요!

참고 링크

논문 · 공식

• TurboQuant: Online Vector Quantization with Near-optimal Distortion Rate (arXiv)
• Google Research: TurboQuant: Redefining AI efficiency with extreme compression

업계 반응 · 분석

• The Register: TurboQuant is a big deal, but it won't end the memory crunch
• XDA Developers: TurboQuant tackles the hidden memory problem

커뮤니티 구현 · 구현 블로그

• scos-lab/turboquant (레퍼런스 구현 + 공학적 지견)
• tonbistudio/turboquant-pytorch (PyTorch 구현)
• dejan.ai: TurboQuant: From Paper to Triton Kernel in One Session
• 0xSero/turboquant (vLLM 통합 구현)