화웨이가 공개한 KVarN — LLM 추론의 '메모리 먹는 하마' KV 캐시를 양자화로 길들이기

무슨 일이 있었냐면요

화웨이가 KVarN이라는 프로젝트를 공개했어요. 한 줄로 요약하면 "vLLM에 곧바로 붙여 쓸 수 있는, KV 캐시 양자화 전용 백엔드"예요. 이름만 보면 무슨 외계어 같은데, 천천히 풀어볼게요. 이건 거대 언어 모델(LLM)을 실제로 서비스할 때 가장 골치 아픈 문제 중 하나인 GPU 메모리 부족을 정면으로 다루는 도구거든요.

KV 캐시가 뭐냐면요

먼저 KV 캐시부터 이해해야 해요. LLM이 글을 한 글자(토큰)씩 생성하는 과정을 떠올려보세요. 다음 단어를 예측하려면 앞에 나온 모든 단어를 '참고'해야 하거든요. 이때 어텐션(attention)이라는 연산이 각 토큰마다 Key(K)와 Value(V)라는 벡터를 만들어내요.

그런데 토큰을 새로 만들 때마다 앞 토큰들의 K, V를 매번 다시 계산하면 너무 낭비예요. 이미 계산한 건데 또 하는 거니까요. 그래서 한 번 계산한 K, V를 메모리에 저장해두고 재사용하는데, 이게 바로 KV 캐시예요. 일종의 '대화 기억 노트'라고 보면 돼요.

문제는 이 노트가 어마어마하게 무겁다는 거예요. 문맥(context)이 길어질수록, 그리고 동시에 처리하는 요청(batch)이 많아질수록 KV 캐시는 선형으로 불어나요. 긴 문서 요약이나 코드 전체를 넣는 작업처럼 컨텍스트가 수만 토큰에 달하면, 모델 가중치보다 KV 캐시가 GPU 메모리를 더 많이 잡아먹는 상황도 흔하거든요. GPU 메모리는 비싸고 한정돼 있는데 말이죠.

양자화로 캐시를 다이어트시킨다

여기서 양자화(quantization)가 등장해요. 양자화가 뭐냐면, 숫자를 표현하는 정밀도를 낮춰서 용량을 줄이는 기법이에요. 보통 KV 캐시는 FP16(16비트 부동소수점)으로 저장되는데, 이걸 INT8(8비트)이나 INT4(4비트) 정수로 바꾸면 단순 계산으로도 메모리가 절반, 1/4로 줄어들어요.

비유하자면 고화질 사진을 적당히 압축하는 거랑 비슷해요. 용량은 확 줄지만 눈으로 보기엔 거의 차이가 안 나죠. KV 캐시 양자화도 마찬가지로, 정밀도를 낮춰도 모델 출력 품질은 거의 유지하면서 메모리만 절약하는 게 목표예요. 메모리가 절약되면 같은 GPU로 더 긴 컨텍스트를 다루거나, 더 많은 사용자 요청을 동시에 처리할 수 있어요. 곧 비용 절감으로 이어지는 거죠.

KVarN이 강조하는 건 이걸 vLLM에 네이티브로 통합했다는 점이에요. vLLM은 요즘 LLM 추론 서빙의 사실상 표준처럼 쓰이는 엔진인데, PagedAttention이라는 기법으로 KV 캐시를 OS 가상메모리처럼 페이지 단위로 효율적으로 관리하는 걸로 유명해요. KVarN은 그 vLLM 안에 양자화 백엔드를 직접 끼워 넣어서, 별도의 어색한 변환 단계 없이 추론 파이프라인 안에서 자연스럽게 K, V를 압축·복원하도록 만든 거예요.

업계 흐름에서 보면

KV 캐시 양자화 자체는 화웨이만 하는 게 아니에요. 이미 KIVI(2비트 비대칭 양자화로 유명한 연구), KVQuant, 그리고 vLLM에 내장된 FP8 KV 캐시 옵션 등 비슷한 시도가 여럿 있었거든요. 학계에서도 "K와 V는 분포가 달라서 양자화 전략을 다르게 가져가야 한다"는 식의 디테일한 연구가 활발했어요.

KVarN이 차별화되는 지점은 '연구용 코드'가 아니라 실서비스 엔진에 곧바로 꽂아 쓰는 백엔드 형태로 나왔다는 거예요. 거기에 화웨이가 만들었다는 점도 의미가 있어요. 자사 Ascend NPU 같은 자체 가속기 생태계와의 연계를 염두에 둔 행보일 가능성이 크거든요. 엔비디아 GPU 의존도를 낮추려는 큰 그림의 한 조각으로 볼 수도 있어요.

한국 개발자에게 주는 시사점

LLM을 직접 서빙해본 분이라면 "OOM(메모리 부족) 에러"에 한 번쯤 데여봤을 거예요. 특히 사내 GPU 자원이 빠듯한 환경에서 긴 컨텍스트 RAG나 문서 처리를 돌릴 때요. KV 캐시 양자화는 이럴 때 모델을 더 작은 걸로 바꾸지 않고도 동시 처리량을 끌어올릴 수 있는 현실적인 카드예요.

당장 프로덕션에 넣기 전엔 반드시 품질 검증을 거치세요. 양자화는 공짜가 아니라서, 특히 INT4처럼 공격적으로 줄이면 긴 문맥에서 미묘하게 답변 품질이 떨어질 수 있거든요. 자신의 실제 데이터로 정확도를 측정해보고, FP8 → INT8 → INT4 순으로 조심스럽게 내려가며 메모리 절감과 품질의 균형점을 찾는 걸 추천해요.