AI가 대화를 기억할수록 메모리는 더 많이 필요하다
AI와 오래 대화할수록 앞에서 무슨 말을 했는지 기억해야 합니다. 그런데 매번 대화 처음부터 다시 계산하면 너무 비효율적입니다. 그래서 이전 계산 결과를 임시로 적어두는 ‘대화 메모장’을 만드는데, 이것이 KV Cache라고 생각하면 됩니다.
LLM은 사용자가 입력한 문장을 처리하면서 attention 계산에 필요한 Key와 Value 값을 만든다. 이전 token의 Key·Value를 매번 다시 계산하면 매우 비효율적이기 때문에 GPU 메모리에 저장해 재사용한다.
이 저장공간이 KV Cache다.
문제는 대화가 길어지고 사용자가 많아질수록 KV Cache가 빠르게 커진다는 것이다. 모델 weight가 고정돼 있어도 긴 context와 수천 개 동시 세션 때문에 GPU HBM이 가득 찰 수 있다.
그래서 최신 AI inference 시스템에서는 GPU 연산 성능 못지않게 KV Cache를 어디에 저장하고 어떻게 이동시킬지가 중요하다.
KV Cache는 왜 필요한가?
KV Cache는 ‘AI가 이미 계산한 내용을 다음 답변에서도 다시 쓰기 위한 메모’입니다. 계산을 줄여 답변을 빠르게 만들지만, 대화가 길수록 이 메모장이 커져 GPU 메모리를 많이 차지합니다.
LLM은 새 단어 하나를 만들 때 앞에서 나온 단어들과 어떤 관계가 있는지 계속 살펴본다. Transformer에서는 이 과정을 attention 계산이라고 부른다.
대화가 10,000 token까지 길어졌다면 새로운 token을 생성할 때 과거 모든 token의 Key와 Value를 매번 새로 계산하는 것은 낭비다.
그래서 한 번 계산한 K와 V를 메모리에 저장해두고 다음 token 생성 때 재사용한다.
이 방식은 계산량을 크게 줄여주지만 메모리 사용량을 늘린다.
추론 비용은 단순 GPU FLOPS가 아니라 ‘compute + memory capacity + memory bandwidth’ 문제다.
Context Window가 길어지면 왜 문제가 커질까?
한 장짜리 메모를 기억하는 것과 300쪽 회의록 전체를 펼쳐놓고 기억하는 것은 필요한 책상 크기가 다릅니다. Context Window가 길어질수록 AI가 유지해야 할 KV Cache도 커집니다.
초기 LLM은 수천 token의 context를 사용했지만 최신 모델은 수십만 token 이상을 지원하기도 한다.
긴 문서, 코드베이스, 멀티턴 대화를 한 번에 처리하려면 context가 커져야 한다.
KV Cache 크기는 context length와 batch size, 모델 layer 수, hidden dimension에 따라 증가한다.
특히 여러 사용자의 요청을 동시에 처리하는 serving 환경에서는 사용자마다 별도의 KV Cache가 필요하다.
GPU HBM이 아무리 커져도 모든 세션을 계속 유지하기 어려운 이유다.
Prefix Cache는 무엇인가?
매일 같은 회사소개와 업무규칙을 처음부터 읽게 하지 않고, 한 번 읽어둔 내용을 메모해두고 재사용하는 방식입니다. 여러 사용자가 같은 앞부분을 쓸 때 특히 효과가 큽니다.
많은 요청은 공통된 앞부분을 공유한다.
예를 들어 회사의 시스템 프롬프트, 동일한 문서, 같은 코드베이스를 여러 사용자가 반복해서 입력할 수 있다.
이미 계산한 prefix의 KV Cache를 재사용하면 같은 prefill 계산을 다시 하지 않아도 된다.
이것이 prefix caching이다.
AI 서비스 규모가 커질수록 cache hit rate를 높이는 것만으로도 GPU 계산량과 비용을 크게 줄일 수 있다.
KV Cache Offloading은 무엇인가?
책상 위가 꽉 찼다고 메모를 모두 버리는 대신, 지금 당장 안 보는 메모는 서랍이나 창고로 옮겨두는 방식입니다. GPU HBM이 책상이라면 CPU RAM은 서랍, SSD는 더 큰 창고 역할을 합니다.
GPU HBM이 부족할 때 모든 KV Cache를 삭제하면 나중에 다시 계산해야 한다.
대신 당장 사용하지 않는 KV block을 더 저렴한 메모리 계층으로 내릴 수 있다.
NVIDIA Dynamo는 KV Cache를 GPU에서 CPU RAM, local SSD, remote storage로 offload할 수 있는 구조를 제공한다.
사용자가 다시 요청하면 해당 KV block을 GPU로 가져와 재사용한다.
즉 KV Cache는 단순 GPU 메모리가 아니라 HBM → CPU Memory → SSD → Remote Storage로 이어지는 계층형 storage problem이 된다.
NVIDIA Dynamo가 보여주는 추론 인프라의 변화
Dynamo는 여러 AI 서버 가운데 ‘이 사용자의 메모장을 이미 가지고 있는 서버’를 찾아 요청을 보내고, 오래된 메모는 더 싼 저장계층으로 옮기는 교통정리 시스템에 가깝습니다.
NVIDIA Dynamo는 대규모 AI 추론 서비스를 여러 서버에 나눠 운영하면서, 어느 서버에 필요한 KV Cache가 있는지 찾아 요청을 보내고 필요 없는 캐시는 다른 메모리 계층으로 옮기는 기능을 제공한다. 전문적으로 disaggregated serving, KV-aware routing, KV Cache offloading이라고 부른다.
KV-aware router는 어떤 worker가 필요한 cache를 이미 갖고 있는지 확인하고 그 서버로 요청을 보낼 수 있다.
KVBM은 GPU memory, pinned host memory, remote RDMA memory, local/distributed SSD, remote file/object storage까지 하나의 memory layer처럼 관리한다.
이 구조가 중요한 이유는 GPU HBM보다 훨씬 큰 cache 공간을 확보하면서도 이미 계산한 KV를 최대한 재사용할 수 있기 때문이다.
AI 추론 효율 경쟁이 GPU kernel 최적화에서 cache placement와 routing까지 확대되고 있다.
KV Cache가 SSD까지 내려가면 너무 느리지 않을까?
자주 쓰는 캐시는 GPU에, 가끔 쓰는 캐시는 CPU 메모리에, 오래 쉬는 캐시는 SSD에 둡니다. 옷장에서도 매일 입는 옷과 계절 옷을 같은 위치에 두지 않는 것과 같습니다.
SSD는 HBM보다 압도적으로 느리다. 그래서 모든 KV Cache를 SSD에 두는 것은 의미가 없다.
핵심은 access frequency에 따라 tier를 나누는 것이다.
지금 응답 중인 active session은 HBM에 두고, 잠시 쉬고 있는 대화는 CPU RAM으로, 더 오래된 session이나 반복사용 가능성이 낮은 cache는 SSD로 내린다.
Cache를 다시 불러오는 비용보다 재계산 비용이 더 큰 경우에 offloading이 유리하다.
따라서 KV Cache tiering은 단순 저장기술이 아니라 workload prediction과 economics의 문제다.
KV Cache는 AI 서비스의 비용구조도 바꾼다
LLM 서비스의 비용은 GPU 시간을 얼마나 효율적으로 사용하는지에 따라 크게 달라진다.
같은 prompt를 반복해서 prefill하면 GPU가 같은 계산을 계속 수행한다.
KV Cache 재사용률을 높이면 first-token latency를 줄이고 GPU당 처리량을 높일 수 있다.
NVIDIA Dynamo는 cache-aware routing과 offloading을 통해 TTFT와 throughput을 개선하는 사례를 제시하고 있다.
앞으로 AI inference 경쟁에서 ‘tokens per second’뿐 아니라 ‘cache hit rate’와 ‘cost per token’이 더 중요한 운영지표가 될 가능성이 높다.
KV Cache가 스토리지 산업에 주는 의미
과거 SSD는 모델파일과 데이터셋을 저장하는 장치였다.
추론이 커지면서 SSD는 실행 중인 AI 서비스의 상태를 저장하는 active tier로 들어오기 시작했다.
대용량·저지연 NVMe SSD, RDMA, GPUDirect Storage, CXL memory가 KV Cache 계층에서 함께 사용될 수 있다.
이것은 스토리지가 ‘cold data’ 중심 산업에서 AI memory extension 역할까지 확장되는 변화다.
다음 편에서는 SSD와 GPU 사이의 데이터 복사를 어떻게 줄이는지 GPUDirect Storage를 중심으로 살펴본다.
이 글에서 기억할 핵심
KV Cache는 생성형 AI가 이미 계산한 문맥 정보를 재사용하기 위한 저장공간입니다. 모델 크기와 대화 길이, 동시 사용자 수가 늘 때 메모리와 저장장치 사이의 이동 비용이 어떻게 변하는지가 핵심입니다.
- AI 스토리지와 메모리 인프라는 GPU가 데이터를 기다리지 않게 만드는 핵심 시스템이다.
- KV Cache는 LLM 추론에서 계산을 줄여주는 메모리이면서 동시에 HBM·DRAM·SSD를 하나의 계층으로 묶게 만드는 새로운 AI 스토리지 워크로드다.
- 최신 규격과 기술은 상용화 수준과 연구·로드맵 단계를 구분해 설명해야 한다.
한 줄 핵심
KV Cache는 LLM 추론에서 계산을 줄여주는 메모리이면서 동시에 HBM·DRAM·SSD를 하나의 계층으로 묶게 만드는 새로운 AI 스토리지 워크로드다.
같이 읽기
- AI 스토리지③ — CXL 메모리: 서버의 메모리를 풀처럼 공유할 수 있을까?
- AI 스토리지⑤ — GPUDirect Storage: 저장장치에서 GPU로 바로 데이터를 보내는 기술
- 불마켓 산업·기술 전체 글 보기
KV 캐시는 저장장치가 아니라 추론 중간상태다
KV 캐시는 대규모 언어모델이 이전 토큰의 어텐션 계산 결과를 다시 계산하지 않도록 보관하는 중간상태입니다. 대화가 길어지고 동시 요청이 늘수록 요청별 캐시가 커지기 때문에, 모델 가중치가 GPU 메모리에 들어가더라도 KV 캐시 부족으로 동시 처리량이 제한될 수 있습니다. 따라서 ‘모델이 올라간다’와 ‘원하는 동시 사용자 수를 처리한다’는 별도의 질문입니다.
공통 시스템 프롬프트나 긴 문서 앞부분이 반복되면 prefix caching으로 기존 캐시를 재사용해 첫 토큰 지연과 연산량을 줄일 수 있습니다. 반대로 GPU 메모리가 부족해 KV 캐시를 호스트 메모리나 저장장치로 내리면 용량은 늘지만 전송 지연이 생깁니다. 어떤 데이터를 유지하고 퇴출할지, 요청을 캐시가 있는 워커로 보낼지까지 포함해 시스템 전체를 설계해야 합니다.
운영자가 볼 지표
- KV 캐시 사용률과 블록 퇴출률
- prefix cache 적중률
- 첫 토큰 지연과 토큰 생성 속도
- 요청 길이별 동시처리 수
- 오프로딩 시 전송 대역폭과 꼬리 지연
추가 원자료: NVIDIA TensorRT — KV Cache, vLLM — Hybrid KV Cache Manager
공식·주요 참고자료
※ 본 글은 산업과 기술 구조를 이해하기 위한 정보형 콘텐츠이며 특정 종목의 매수·매도 추천이나 수익 보장을 목적으로 하지 않습니다.