[초록 & 서론] 3줄 요약 + 문제 제기
3줄 요약
- 긴 문맥을 다루는 LLM은 과거 토큰의 Key, Value 벡터를 계속 쌓아 두어야 하므로, 결국 KV 캐시가 VRAM을 먹어 치우는 진짜 병목이 됩니다.
- 예전 방식: 숫자를 아주 짧게만 적어 둬도, 묶음마다 “원래 값으로 되돌리는 데 필요한 부가 숫자”를 또 적어야 합니다. 그 부가 정보는 보통 정밀한 형식(예: FP16)으로 따로 저장되기 때문에, 겉으로는 줄인 것 같은데 VRAM은 생각만큼 안 줄어드는 경우가 많습니다.
- PolarQuant는 벡터를 먼저 무작위로 섞은 뒤 극좌표로 옮겨 각도만 짧게 저장합니다. 그 무거운 부가 설명에 덜 묶이면서도 4.2배 이상 압축과 강한 장문맥 품질을 동시에 보여 줍니다.
맞춤 비유: 무게표를 박스마다 붙이는 택배창고 vs 방향만 기록하는 나침반 창고
기존 양자화는 박스마다 "이 박스의 최소값, 최대값, 스케일" 같은 딱지를 붙인 뒤 창고에 넣는 방식에 가깝습니다. 박스를 줄이려고 했는데, 정작 딱지 보관 비용이 계속 따라옵니다. PolarQuant는 박스를 통째로 한 번 잘 섞어 둔 뒤, 각 물건이 "어느 방향으로 향하느냐"만 저장하는 방식입니다. 절대적인 크기 정보는 반지름 하나로 남기고, 나머지는 방향 정보로 압축하니 창고가 훨씬 가벼워집니다.
쉬운 말로 짚어보면
- 딜레마: 숫자만 줄이면 끝이 아니라, 블록마다 붙는 설명서(메타데이터)가 FP16으로 무거워 배보다 배꼽이 큰 상황이 생기기 쉽습니다.
- PolarQuant의 방향: 좌표 숫자 대신 거리(반지름 ) 하나와 방향(각도들)으로 나누어 담습니다. 나머지는 어느 쪽으로 기울었나만 기록하는 셈입니다.
- 믹서기()와 : 극좌표로 넘어가기 전에 좌표를 무작위로 섞으면, 큰 덩어리를 반으로 나눴을 때 앞·뒤 무게(에너지)가 비슷해지는 경우가 많고, 그 비율을 각도로 쓰면 () 근처에 값이 몰리기 쉽습니다. 좁은 각도 구간에 자주 등장한다는 걸 알면 적은 비트로도 각도만 양자화할 여지가 생깁니다.
- 실험에서 보고된 것: KV 캐시 4.2배 이상 압축, 104K 근처 극한 문맥에서도 바늘 찾기 등에서 강한 결과, 오프라인 코드북으로 Prefill 시간을 크게 줄이는 구간(논문에서 온라인 대비 약 11.6초 vs 약 3.4초 등)이 있습니다.
한 줄: 잘 섞으면 각도가 예측 가능하게 몰리는 통계 구조를 이용해, 복구용 부가 정보 부담을 크게 걷어 낸 접근입니다.