긴 컨텍스트 요청이 많아지면서 KV 캐시 Eviction을 도입하는 팀이 늘었다. 메모리를 줄이고 throughput을 올리는 목적으로 보면 맞는 판단이다. 그런데 어떤 Eviction 정책을 쓰느냐에 따라 동일한 KV 예산에서 perplexity가 수십에서 수천까지 벌어진다는 사실을 실측 전에 아는 팀은 많지 않다. 그 격차를 만드는 변수는 하나다 — Attention Sink 토큰을 제거했느냐 살렸느냐.
Attention 분포의 비대칭성
트랜스포머의 Attention 스코어를 레이어별로 시각화하면 이상한 패턴이 눈에 띈다. 첫 1~4개 토큰 — BOS 토큰이나 첫 번째 줄바꿈 문자 — 이 전 레이어에 걸쳐 압도적 비중을 차지한다. Xiao et al. (2023)의 분석에 따르면 4096 토큰 시퀀스에서 첫 번째 토큰이 받는 Attention 스코어는 대부분의 레이어에서 전체 합산의 절반을 넘는다.
모델은 학습 과정에서 처리 흐름의 기준점(Sink) 역할을 이 위치에 고정했다. 텍스트 내용과 무관하게, 항상 이 슬롯이 그 역할을 맡는다.
Softmax의 구조가 이 현상을 만든다. 레이어 $l$, 헤드 $h$에서 토큰 $i$가 $j$에 두는 Attention 스코어는:
$$\alpha_{ij}^{(l,h)} = \frac{\exp(q_i^T k_j / \sqrt{d_k})}{\sum_{j'} \exp(q_i^T k_{j'} / \sqrt{d_k})}$$
분모는 항상 1.0으로 정규화된다. 모델이 특정 슬롯으로 주의를 집중하는 경향이 자리를 잡으면, 그 슬롯의 존재 자체가 나머지 분포를 안정화하는 기준점이 된다. Sink 토큰이 사라지면 이 기준이 무너지고, 남은 토큰들 사이에서 Attention 분포가 불안정해진다.
Sink를 제거했을 때 perplexity는 얼마나 달라지는가
StreamingLLM 논문이 이를 수치로 확인한다. Llama-2-13B에서 최근 1024개 토큰만 유지하는 슬라이딩 윈도우 — Sink 없이 오래된 KV를 잘라내는 가장 단순한 방식 — 를 적용하면, 20K 토큰 시퀀스에서 perplexity가 5158까지 치솟는다. 같은 예산에서 앞 4개 토큰의 KV를 고정 보존하면 perplexity는 5.40으로 떨어진다. 슬라이딩 윈도우를 매 스텝 전체 재계산하는 oracle baseline도 5.40이다.
Sink 4개를 추가하는 것만으로 perplexity가 1000배 이상 차이가 난다.
이 정도 격차는 모델 양자화 한 단계(W8 → W4)가 주는 품질 손실과 맞먹거나 그 이상이다. 양자화는 팀이 명시적으로 결정하는 반면, Eviction 정책은 기본값 그대로 두다가 나중에야 문제를 인식하는 경우가 많다.
Sink 탈락의 실패 양상도 특징적이다. 같은 구절을 반복하거나, Prompt 초반에 언급된 이름이나 조건을 참조하지 못하는 문맥 단절이 나타난다. Sink 슬롯 수에 대한 민감도를 보면, 논문 Table 2 기준으로 1~2개는 불완전한 회복이고 4개에서 수렴한다. 8개 이상은 4개 대비 유의미한 차이가 없다.
세 전략이 Sink를 다루는 방식
StreamingLLM, H2O, SnapKV는 Sink를 다루는 접근이 근본적으로 다르다.
StreamingLLM은 명시적이다. 앞 N개 토큰(기본값 4)의 KV를 하드코딩으로 고정 보존하고, 나머지는 슬라이딩 윈도우로 채운다. 구현이 단순하고 Sink 탈락 리스크가 없다. 약점은 Sink + 최근 N 토큰 외에는 기억하지 못한다는 것이다. 긴 문서 중간에 등장하는 중요한 내용은 증발한다. 실시간 스트리밍이나 연속 대화처럼 지금 이 순간의 흐름이 중요한 워크로드에 어울린다.
H2O는 간접적으로 Sink를 살린다. 각 헤드별로 누적 Attention 스코어(Heavy Hitter score)가 높은 토큰을 동적으로 선택한다. 첫 번째 토큰은 모든 Attention 계산에 참여하므로 누적 스코어가 자연스럽게 상위권에 쌓인다. Sink가 "알아서 살아남는" 구조다. 강점은 Sink뿐 아니라 쿼리와 관련된 중간 토큰도 함께 보존한다는 것이다. H2O 논문 결과 기준으로, OPT-30B에서 20% KV 예산을 유지하면 COPA 84.0 (풀 캐시 85.0), PiQA 78.45 (풀 78.51), Winogrande 69.06 (풀 70.24)로 손실이 거의 없다. 반면 최근 토큰만 유지하는 Local 전략은 동일 예산에서 최대 37% 하락하는 시나리오가 보고된다.
H2O의 취약 지점은 KV 예산이 극단적으로 낮아지는 상황이다. 누적 스코어 경쟁이 치열해지면 특정 헤드에서 Sink가 Heavy Hitter 순위에서 밀릴 수 있다. 이 구간에서는 동적 선택의 장점보다 Sink 탈락 위험이 더 크게 작용한다.
SnapKV는 생성 이전에 KV 선택을 확정한다. Prompt 끝부분(observation window)에서 각 헤드가 어떤 토큰에 주의를 기울이는지 파악하고, 그 패턴으로 보존할 위치를 결정한다. Sink 토큰은 observation 단계에서 이미 high-score 위치로 식별된다. 장점은 Query 내용에 맞는 선택이다. SnapKV 논문은 16K 토큰 입력 기준으로 생성 속도 3.6배, 메모리 효율 8.2배를 보고하며, A100-80GB 단일 GPU에서 380K 컨텍스트를 처리한다. 단, Prompt를 한 번 보고 선택을 확정하므로 생성이 길어지면서 새로운 토큰이 중요해지는 상황은 따라가지 못한다. RAG 패턴이나 긴 문서 QA에 잘 맞는다.
전략별 비교
| 전략 | Sink 보존 | 중간 토큰 보존 | 동적 업데이트 | 적합 워크로드 |
|---|---|---|---|---|
| StreamingLLM | 명시적 고정 (4개) | 없음 (최근 N개만) | 불필요 | 실시간 스트리밍, 긴 대화 |
| H2O | 암묵적 (누적 스코어 상위) | Heavy Hitter 기반 | 매 토큰 | 중간 길이, 정보 추출 |
| SnapKV | Prompt 관찰로 사전 결정 | Query 기반 선택 | 없음 | 긴 문서 QA, RAG |
| Random / FIFO | 없음 | 무작위 | — | 사용 비권장 |
KV 예산 50%에서는 H2O와 SnapKV 모두 안정적이다. 예산이 25% 이하로 줄어들수록 H2O에서 Sink가 밀릴 위험이 커지고, 이 구간에서는 StreamingLLM의 명시적 고정이 더 안전하다.
Sink 고정은 어느 정책에나 얹힌다
Sink 고정 비용은 슬롯 4개다. 어떤 전략을 쓰든 전체 KV 예산에서 4개 슬롯을 먼저 확보하고, 나머지 예산으로 Heavy Hitter 선택이나 Prompt 관찰 기반 선택을 돌리면 된다. StreamingLLM의 Sink 고정 아이디어는 독립 전략이 아니라 다른 정책에 얹는 플러그인으로 쓸 때 가장 가치가 있다.
H2O의 vLLM 통합 논의(vllm-project/vllm#3532)가 진행된 바 있고, 현재 프로덕션에서는 커스텀 구현이 많다. Sink 보존이 포함되지 않은 구현은 반드시 검토해야 한다. KV 예산 50%에서는 안정적으로 보이다가 컨텍스트가 길어지거나 예산을 더 줄이는 시점에 품질이 갑자기 무너지는데, A/B 테스트 없이는 잡아내기 어렵다.