XQuant: KV 캐시 대신 활성화 X를 저장하고 K·V를 재물질화해 LLM 서빙의 메모리 벽을 넘는 방법 (arXiv:2508.10395)

요약

LLM 서빙에서 GPU의 병목은 계산이 아니라 메모리 대역폭이다. B200 세대에 오면 상황은 더 극단으로 간다. FP4 텐서 코어가 초당 수 페타FLOPS를 뿜어내는 사이, HBM3e 대역폭은 8TB/s 수준에서 정체된다. 디코딩 매 스텝마다 KV 캐시 전체를 HBM에서 읽어 어텐션을 계산해야 하는 트랜스포머 추론은 이 격차의 정면에 서 있다.

지금까지의 대응은 대부분 KV 캐시를 그대로 두되 압축하는 방향이었다. KIVI·KVQuant·KVLinC 계열은 저장 시점에 K/V를 저정밀도로 양자화한다. 프리픽스 캐시·PagedAttention·계층 오프로딩은 재사용 또는 지역성으로 대역폭을 아낀다.

2026년 8월 공개된 XQuant(arXiv:2508.10395, "Breaking the Memory Wall for LLM Inference with KV Cache Rematerialization")는 다른 각도로 접근한다. KV 캐시를 저장하지 말고, LayerNorm을 지난 입력 활성화 X만 저장한 뒤 K·V를 매 디코드 스텝마다 다시 계산한다. 텐서 하나로 두 텐서를 대체하니 MHA에서 캐시 크기가 즉시 절반이 된다. 여기에 저비트 양자화와 레이어 간 델타 압축을 더한 XQuant-CL은 FP16 KV 대비 최대 12.5× 메모리 절감, 퍼플렉시티 저하는 0.1 이하를 보고한다.

이 글은 이 접근이 왜 지금 성립하는지(하드웨어 트렌드), 어떻게 동작하는지(X 캐시·재물질화 경로·XQuant-CL·GQA 확장), 실제 성능이 어떻게 나오는지, 그리고 vLLM/SGLang 같은 서빙 엔진에 통합할 때 운영자가 확인해야 할 것들을 다룬다.

배경: 메모리 벽이 왜 강해지는가

트랜스포머 어텐션의 자동회귀 디코딩은 메모리 바운드다. 새 토큰을 하나 만들 때마다 이전 모든 토큰의 K와 V 텐서를 HBM에서 로드해 Q와 곱한다. 계산량은 배치·시퀀스 길이에 대해 선형이지만, 로드해야 할 바이트는 KV 캐시 전체 크기에 비례한다.

이 상황을 정량화하는 지표가 연산 강도(arithmetic intensity)다. Q · K^T 계산의 연산 강도는 대략 배치 크기(정확히는 요청당 헤드 수를 배치 차원과 합친 값)에 비례한다. 배치가 1이면 극도로 낮고, 배치를 키워야 텐서 코어를 채운다.

문제는 하드웨어가 연산 강도의 손익분기점을 계속 밀어올린다는 데 있다. NVIDIA GPU 세대별 대략적인 값(BF16 기준)을 보면:

FP8/FP4로 내려가면 격차는 더 벌어져 B200의 FP4 텐서 성능은 HBM 대역폭 대비 1,000배가 넘는다. 즉, 매년 "메모리에서 바이트 한 번 읽을 시간에 얼마나 많은 곱셈을 할 수 있는가"의 비율은 계속 올라가고 있다. 이 트렌드가 XQuant 같은 "계산을 더 써서 메모리 로드를 줄이는" 알고리즘의 존재 근거를 만든다.

KV 캐시가 여전히 병목인 이유

FP8·FP4 KV 양자화, GQA, MQA, SWA(Sliding Window Attention), MLA(Multi-Head Latent Attention) 같은 최적화가 이미 광범위하게 쓰이고 있음에도 KV 캐시는 여전히 서빙 병목이다. 이유는 세 가지가 겹친다.

• 컨텍스트 길이 인플레이션. 32K → 128K → 1M로 늘어난 컨텍스트 길이 자체가 캐시 크기를 선형으로 밀어올린다.
• 에이전트 워크로드. 도구 호출, 관찰, 재계획이 프롬프트에 흡수되면서 요청당 평균 KV 크기가 눈에 띄게 커졌다.
• 양자화의 정확도 한계. 4비트 KV 양자화까지는 대체로 안전하지만, 3비트 이하로 내려가면 긴 문맥에서 퍼플렉시티가 급격히 무너지는 경우가 흔하다. KIVI·KVQuant조차 2비트 이하에서는 실용 정확도를 지키기 어렵다.

XQuant는 이 마지막 벽—"KV 자체는 더 이상 저비트로 못 내려간다"—를 KV가 아니라 KV를 만들 재료(X)를 저장함으로써 우회한다.

아이디어: X를 저장하고 K·V를 다시 만든다

각 트랜스포머 레이어의 셀프 어텐션 앞단은 다음처럼 동작한다.

1. 이전 레이어 출력에 LayerNorm(또는 RMSNorm)을 적용해 정규화된 활성화 X를 얻는다.
2. K = X · W_K, V = X · W_V, Q = X · W_Q를 계산한다.
3. 이 K/V를 캐시에 저장하고, Q와 함께 어텐션을 수행한다.

여기서 관찰이 하나 있다. K와 V는 서로 독립적인 두 개의 사영이지만, 둘 다 같은 X에서 파생된다. 즉 X만 있으면 W_K·W_V(고정된 가중치)로 언제든 K와 V를 다시 만들 수 있다.

XQuant의 핵심은 이 관찰을 저장 정책으로 뒤집는 것이다.

• 원래 KV 캐시: K와 V를 저장한다(텐서 2개, 히든 차원 × 2).
• XQuant: 정규화된 입력 X를 저장한다(텐서 1개, 히든 차원).

MHA(Multi-Head Attention) 모델에서 K와 V의 총 크기는 X의 대략 2배(정확히는 2 × head_dim × n_heads / hidden_size)이므로 텐서 하나만 저장하면 캐시 메모리는 즉시 절반이 된다. 여기에 저비트 양자화를 X에 그대로 적용하면 이 감소가 곱해진다.

재물질화 경로

디코딩 시점에 어텐션을 계산하려면 K와 V가 필요하다. XQuant는 이 시점에 두 단계를 추가한다.

1. 역양자화(dequant): HBM에서 로드한 저비트 X를 BF16(또는 연산 정밀도)으로 복원한다.
2. 재사영(re-projection): 두 개의 GEMM(X · W_K, X · W_V)을 수행해 K와 V를 만든다. W_K와 W_V는 모델 가중치이므로 이미 GPU에 상주해 있다.

이 두 단계는 추가 연산이지만 추가 HBM 로드는 없다(W_K/W_V는 이미 로드되어 있고, X는 원래 KV 로드 대신 로드한다). 그리고 재사영은 텐서 코어의 강점 영역이라 실제 시간 비용은 아주 작다. 오히려 KV를 HBM에서 통째로 읽는 것을 대체하기 때문에 디코딩 latency가 개선되는 경우가 많다.

왜 KV가 아니라 X를 양자화하는가

X와 K/V 중 어느 쪽이 저비트 양자화에 더 관대한지는 실측 문제다. XQuant 논문은 이 지점에서 세 가지를 근거로 든다.

• 분포의 균일성. LayerNorm/RMSNorm 직후의 X는 채널별 스케일이 정규화되어 있고 outlier가 적다. 반면 K와 V는 사영 후이므로 헤드별·채널별 스케일 편차가 크다.
• 정보의 응집도. K·V는 X를 두 개의 다른 방향으로 사영한 결과이므로 서로 상관이 크다. X 하나에서 두 벡터를 만들 정보가 이미 다 들어있다는 뜻이다.
• 분해 가능성. GQA 모델에서는 W_K와 W_V가 저차원 latent를 공유하도록 재구성할 수 있다(뒤에서 SVD 확장을 다룬다). 이 latent 공간에서 X는 더 압축이 잘 된다.

논문은 같은 메모리 예산에서 XQuant가 KIVI 대비 최대 0.88 perplexity 개선을 보임을 실측으로 확인했다. 즉 "같은 비트 예산으로 더 정확", 또는 "같은 정확도로 더 낮은 비트"가 성립한다.

XQuant-CL: 레이어 간 델타로 한 번 더 압축

XQuant의 두 번째 축은 레이어 간 X 유사도를 이용한 추가 압축이다. 트랜스포머의 residual stream은 매 레이어에서 아주 작은 폭으로 갱신되기 때문에, 인접 레이어의 X는 서로 매우 비슷하다. 이 관찰이 XQuant-CL("CL"은 Cross-Layer)의 근거다.

저장 형식

XQuant-CL은 X 캐시를 두 부분으로 분해한다.

• 공유 기저(shared base): 여러 레이어가 공유하는 낮은 비트폭의 양자화 벡터. 절대값이 아니라 residual stream의 방향성을 요약한다.
• 레이어별 델타(per-layer delta): 각 레이어의 X와 공유 기저의 차이. 다이나믹 레인지가 작으므로 아주 낮은 비트로 양자화해도 오차가 크지 않다.

역양자화 시점에는 두 값을 더해 원래 X를 복원한다. 이 구조가 평균적으로 sub-1.4-bit 수준의 등가 비트폭을 만들어낸다. 논문 표에 따르면:

• XQuant (레이어별 독립): Llama-2-7B/13B에서 FP16 대비 7.7× 메모리 절감, PPL 저하 < 0.1
• XQuant-CL: 최대 10× 메모리 절감에 PPL 저하 0.01, 12.5× 메모리 절감에 PPL 저하 0.1
• Mistral-7B 3-bit: 5× 메모리 절감, PPL 저하 < 0.1
• Mistral-7B 4-bit: 3.7× 메모리 절감, PPL 저하 0.01

숫자 자체보다 중요한 것은 곡선의 형태다. 기존 KV 양자화는 3비트 이하에서 PPL이 급격히 무너지는데, XQuant-CL은 등가 비트가 1.4비트에 근접해도 PPL 곡선이 완만하다. 즉 "저비트 영역에서 정확도 절벽"이 사라진다.

레이어 그룹 크기

CL 압축의 자연스러운 하이퍼파라미터는 그룹 크기(공유 기저를 몇 개 레이어가 공유하는가)다. 그룹이 크면 저장은 절약되지만 델타의 다이나믹 레인지가 커진다. 논문은 실측으로 2–4 레이어 그룹이 안전한 상한이라고 보고한다. 그 이상은 델타가 자체 스케일 편차로 저비트 양자화 오차를 흡수하지 못한다.

GQA/MLA 확장: latent 공간에서 X를 압축한다

MHA는 상대적으로 단순하다. K와 V가 각각 X · W_K, X · W_V로 만들어지고, KV 캐시 크기는 X 대비 2배다. 문제는 최근 모델은 대부분 GQA 혹은 MLA라는 점이다. Llama-3, Qwen3, DeepSeek-V3 계열이 대표적이다.

GQA에서는 K 헤드 수 H_kv가 Q 헤드 수 H_q보다 작다(예: Llama-3-70B는 H_q=64, H_kv=8). 이 경우 이미 KV 캐시가 X보다 작다. 그러니 X를 저장하면 오히려 손해다. XQuant는 이 지점에서 SVD 기반 재구성을 도입한다.

아이디어

W_K와 W_V를 SVD로 분해해 저차원 latent 공간을 뽑는다. 예를 들어:

• W_K ≈ U_K · S_K · V_K^T
• W_V ≈ U_V · S_V · V_V^T

이때 X를 그대로 저장하는 대신 U_K^T · X와 U_V^T · X를 각각 저장한다. 이 벡터의 차원은 원래 X보다 작다(rank r). 디코드 시점에는 V_K, V_V(가중치, 이미 로드됨)와 곱해 K, V를 복원한다.

이 latent-space 재구성은 MLA(DeepSeek-V3의 Multi-Head Latent Attention)의 학습 시점 latent 압축을 후처리로 흉내내는 것과 비슷하다. 학습 없이 기존 GQA 체크포인트에 적용할 수 있다는 점이 실무상 이점이다.

논문 실험은 GQA 모델에서도 XQuant-CL이 FP16 KV 대비 유의미한 메모리 절감을 유지함을 확인한다. 다만 절감 폭은 MHA만큼 크지 않다(대략 3–5× 수준). 그럼에도 저비트 KV 양자화 대비 정확도 우위는 유지된다.

계산-메모리 트레이드오프의 실제

XQuant는 무료가 아니다. 매 디코드 스텝마다 각 레이어에서 다음 세 가지 추가 작업이 발생한다.

1. Dequant X: 저비트 X → BF16 복원. 캐시 크기에 비례.
2. W_K, W_V 사영(GEMM 2회): X 크기와 latent 차원에 비례.
3. (XQuant-CL) 델타 + 공유 기저 합: 캐시 크기에 비례하는 elementwise 덧셈.

이 세 가지는 텐서 코어의 강점 영역이라 latency 오버헤드가 작다. 논문의 roofline 분석은 다음을 보여준다.

• H100 이후 세대에서 디코드 스텝의 wall-clock latency는 KV 로드 시간이 지배적이다.
• 재사영 GEMM은 텐서 코어의 유휴 시간을 채우는 방향이라 실제 latency에 거의 더해지지 않는다.
• 결과: XQuant는 대부분의 배치 크기에서 KV FP16 대비 latency 감소를 보인다(대역폭 절감이 GEMM 오버헤드를 상회).

어디서 이득이 얇아지는가

이 구조가 이득을 잃는 조건도 명확하다.

• 아주 짧은 컨텍스트: KV 로드 자체가 크지 않으면 재계산 오버헤드가 상대적으로 커진다.
• 작은 배치·단일 요청: 어차피 배치가 작으면 이미 KV 로드가 지배적이지 않을 수 있다. 단, 이 경우는 어차피 서빙 처리량이 낮은 구간이라 실무 영향은 제한적.
• 아주 넓은 hidden(70B급 이상 MHA 모델): 재사영 GEMM 크기가 커져 텐서 코어 유휴를 벗어난다. 그래도 여전히 이득은 있으나 폭이 얇아진다.
• compute-bound 하드웨어: 텐서 코어 대비 HBM 대역폭이 상대적으로 큰 하드웨어(예: 데이터센터 CPU inference)에서는 이 트레이드오프가 반대로 작동한다. XQuant는 GPU-first 최적화다.

서빙 엔진 통합 관점

XQuant는 원 논문 기준으로 프로토타입 수준이지만, 이미 llama.cpp 커뮤니티(GitHub 논의 #15400)에서 통합 논의가 진행 중이고, 여러 서빙 스택이 실험적 브랜치를 열고 있다. 운영자 관점에서 실제 서빙 엔진에 붙일 때 검증해야 할 지점은 다음과 같다.

PagedAttention/RadixAttention과의 호환

vLLM의 PagedAttention과 SGLang의 RadixAttention은 KV 캐시를 페이지 단위로 관리한다. XQuant는 저장하는 텐서가 K/V가 아니라 X이므로 페이지 레이아웃 자체를 재정의해야 한다. 구체적으로는:

• 페이지 크기: X는 K/V보다 작으므로 같은 페이지 크기라도 더 많은 토큰을 담는다. 페이지 크기와 슬롯 수의 재조정 필요.
• 프리픽스 캐시 재사용: X를 저장하면 동일 프리픽스에 대한 캐시 재사용이 여전히 성립한다(다만 재계산 시점에 K/V를 매번 다시 만들어야 함).
• KV 오프로딩 계층과의 조합: CPU DRAM으로 오프로딩하는 계층 스토리지가 이미 있다면 X 저장 형식으로 바꾸기만 하면 대역폭이 절반이 된다.

정확도 검증

프로덕션 도입 전에는 자신의 워크로드에 대해 XQuant 정확도 저하를 재측정해야 한다. 논문의 PPL 수치는 WikiText, C4 등 표준 벤치마크 기준이다. 실무 환경에서는:

• 긴 문맥 QA·요약: 상대적으로 안전.
• 정확한 정보 회수(needle in a haystack): 5비트 이상에서 안전, 3비트 이하는 검증 필요.
• 에이전트/도구 사용: 도구 스키마의 정확한 매칭이 필요한 경우 저비트 저하가 실패율로 이어질 수 있음.

권장 절차는 (1) FP16 KV 기준 정답률·PPL을 먼저 측정하고, (2) XQuant를 6→4→3비트 순으로 조여 정답률 감소가 허용치를 넘는 첫 지점을 찾은 뒤, (3) 한 단계 위로 여유를 두고 배포하는 것.

서빙 지표에서 무엇을 볼 것인가

XQuant를 켰을 때 관측해야 할 서빙 메트릭:

• gpu_kv_cache_usage_perc (또는 동등 지표): 즉시 낮아진다. 대신 배치를 더 키우거나 컨텍스트를 더 길게 받을 수 있다.
• TPOT(time per output token): 대부분 개선(재사영 GEMM 오버헤드 < HBM 로드 시간 감소).
• TTFT(time to first token): 프리필 단계에는 XQuant가 저장 시점 양자화 오버헤드를 추가하므로 소폭 증가할 수 있음.
• 정확도 지표: reference-based 평가(정답률, ROUGE, exact-match)와 사용자 리텐션 모두 트래킹.

관련 연구와의 관계

XQuant는 기존 KV 양자화 계열과 대체 관계가 아니라 더 아래 계층을 건드리는 접근이다.

• KIVI, KVQuant, KVLinC: K와 V를 저장 시점에 양자화. XQuant는 저장 대상 자체를 X로 바꾼다는 점이 다르다.
• RateQuant, SmallKV: 토큰별 중요도에 따라 정밀도를 다르게 두거나(RateQuant), 잘라낸 KV를 작은 모델로 보상(SmallKV). XQuant는 이런 정책과 직교하게 조합 가능하다.
• MLA (DeepSeek-V3의 Multi-Head Latent Attention): 학습 시점에 latent-space K/V 압축을 내장. XQuant의 GQA 확장은 이 아이디어를 학습 없이 사후에 흉내낸다.
• KV 캐시 오프로딩 (Mooncake, NIXL, ObjectCache): CPU/SSD/오브젝트 스토리지로 KV를 계층화. XQuant는 GPU HBM 안에서 KV 크기 자체를 줄이는 방향이고, 오프로딩 계층 위에 그대로 얹을 수 있다.

즉 실제 서빙 스택에서는 XQuant + 프리픽스 캐시 재사용 + 계층 오프로딩을 조합해 GPU HBM 예산과 SLO를 함께 관리하는 방향이 자연스럽다.

남은 문제

논문 자체가 지적하는 한계와, 실무 관점에서 남은 미해결 이슈들.

• 커널 성숙도. 지금까지 공개된 XQuant 구현은 대부분 연구 프로토타입이다. FlashAttention·PagedAttention 수준의 최적화된 커널은 아직 없다. 특히 XQuant-CL의 델타 합산 경로가 GEMM 뒤에 붙는 elementwise 스텝이 되어 커널 융합 여부에 따라 성능이 크게 갈린다.
• 비디디시 배치 안정성. 서로 다른 컨텍스트 길이·다른 시퀀스가 섞인 배치에서 재사영 GEMM은 padding으로 인해 유효 활용도가 낮아진다. continuous batching 스케줄러와의 상호작용 검증 필요.
• 긴 컨텍스트 검증의 결여. 논문 실험은 대체로 8K–32K 컨텍스트에서 수행됐다. 128K–1M 컨텍스트에서 CL 델타 근사가 얼마나 유지되는지, needle-in-a-haystack 스타일 검색이 얼마나 안전한지는 별도 검증이 필요하다.
• 모델 종속성. Llama-2/3, Mistral, Qwen 계열에서는 잘 동작하는 것이 확인됐다. Gemma·Phi·DeepSeek-V4 등 최근 hybrid attention 모델(선형 어텐션·Mamba·MLA 혼합)에서의 거동은 재현 실험이 부족하다. Open question.

정리: 무엇이 바뀌었나

XQuant가 던지는 메시지는 명확하다. "KV 캐시를 압축하는 것이 아니라, KV를 만들지 않을 수도 있다." 이 관점 전환이 저비트 양자화의 정확도 절벽을 우회하는 실마리를 만든다.

운영자 관점에서 XQuant를 이해하는 세 가지 요약:

1. 하드웨어 트렌드가 이 접근을 유리하게 만든다. 텐서 코어 성능 대비 HBM 대역폭이 더 느리게 성장한다. 재계산으로 로드를 줄이는 알고리즘은 앞으로 더 유리해진다.
2. MHA에서는 즉시 2배 이득, XQuant-CL로는 최대 12.5배. GQA/MLA에서는 SVD latent 재구성으로 여전히 3–5× 절감이 가능하다.
3. KV 양자화·프리픽스 캐시·계층 오프로딩과 직교. 이미 있는 서빙 최적화 위에 얹을 수 있다.

프로덕션 도입까지는 커널 성숙과 자기 워크로드에서의 정확도 재검증이라는 두 과제가 남아 있다. 하지만 방향성 자체는 디코딩 스텝의 기본 저장 단위를 재정의한다는 점에서 향후 서빙 엔진 로드맵에 영향을 줄 것으로 보인다.

References

• Aditya Tomar 외, "XQuant: Breaking the Memory Wall for LLM Inference with KV Cache Rematerialization", arXiv:2508.10395. https://arxiv.org/abs/2508.10395
• XQuant paper HTML, arXiv:2508.10395v1. https://arxiv.org/html/2508.10395v1
• HuggingFace Papers: XQuant paper page. https://huggingface.co/papers/2508.10395
• ggml-org/llama.cpp Discussion #15400: "XQUANT - cache post-norm X, rematerialize K/V on decode". https://github.com/ggml-org/llama.cpp/discussions/15400
• Zirui Liu 외, "KIVI: A Tuning-Free Asymmetric 2bit Quantization for KV Cache", arXiv:2402.02750. https://arxiv.org/abs/2402.02750
• Coleman Hooper 외, "KVQuant: Towards 10 Million Context Length LLM Inference with KV Cache Quantization", arXiv:2401.18079. https://arxiv.org/abs/2401.18079
• Amir Gholami 외, "AI and Memory Wall", IEEE Micro. https://arxiv.org/abs/2403.14123
• DeepSeek-AI, "DeepSeek-V3 Technical Report" (MLA 상세). https://arxiv.org/abs/2412.19437
• NVIDIA Blackwell architecture whitepaper (B200 tensor/HBM 스펙). https://resources.nvidia.com/en-us-blackwell-architecture