AI 생성 이미지
LLM 배포에서 더 이상 “모델이 몇 B인가”만으로는 충분하지 않습니다. 긴 컨텍스트와 높은 동시성을 요구하는 서비스에서는 모델 가중치보다 KV 캐시가 먼저 GPU 메모리 병목이 될 수 있습니다.
KVCache.ai가 공개한 웹 기반 오픈소스 KV Cache Size Calculator는 이 병목을 배포 전에 빠르게 가늠하게 해주는 도구입니다. DeepSeek V4 Flash, Qwen3, GLM, Kimi, MiniMax 같은 모델을 포함하며, 예를 들어 DeepSeek V4 Flash는 100만 토큰 기준 총 KV 캐시가 2.893 GiB로 제시됩니다.1
핵심은 단순합니다. “이 모델을 GPU에 올릴 수 있는가”가 아니라 “원하는 컨텍스트 길이와 동시 요청 수를 KV 캐시까지 포함해 감당할 수 있는가”를 먼저 확인해야 합니다.
KV 캐시는 왜 커지는가
KV 캐시는 생성 과정에서 이미 계산한 key-value 쌍을 저장해 다음 토큰 생성 때 재사용하는 메모리입니다. 같은 프리픽스나 이전 토큰에 대한 계산을 반복하지 않도록 해 추론 속도를 높입니다.2
하지만 이 편의에는 비용이 있습니다. KV 캐시 크기는 대체로 토큰 수, 배치 크기, 레이어 수, KV 헤드 수, head dimension, 데이터 타입의 바이트 수에 따라 증가합니다. 흔히 다음과 같은 형태로 설명됩니다.3
2 × KV heads × head dim × layers × sequence length × batch size × bytes여기서 중요한 점은 컨텍스트 길이와 동시성이 거의 직접적으로 메모리 요구량을 키운다는 것입니다. 컨텍스트를 2배로 늘리거나 동시에 처리하는 요청 수를 2배로 늘리면 KV 캐시도 그에 가깝게 커질 수 있습니다. 장문 컨텍스트 서비스에서 메모리 계획이 어려운 이유가 여기에 있습니다.
계산기의 역할은 “초기 판단”이다
KV Cache Size Calculator의 가치는 정밀 벤치마크를 대체하는 데 있지 않습니다. 배포 전에 특정 모델과 컨텍스트 설정이 GPU 메모리 예산 안에 들어갈 가능성이 있는지 빠르게 판단하게 해주는 데 있습니다.
특히 모델별 차이를 직접 비교할 수 있다는 점이 유용합니다. 파라미터 수가 비슷해 보여도 KV 캐시 구조가 다르면 긴 컨텍스트 비용은 크게 달라질 수 있습니다. GQA나 MQA 같은 구조는 저장해야 할 KV 헤드 수를 줄여 캐시 메모리를 낮출 수 있습니다.2
따라서 모델 선택에서는 다음 질문이 중요해집니다.
최대 컨텍스트를 얼마나 길게 제공할 것인가
동시에 몇 개의 요청을 처리해야 하는가
해당 모델의 KV 캐시 구조가 메모리 예산에 맞는가
캐시 재사용이 실제 트래픽 패턴에서 효과를 낼 수 있는가
계산기는 이 질문들에 대한 첫 번째 숫자를 제공합니다.
KV 캐시는 단순한 메모리 덩어리가 아니다
실제 추론 엔진은 KV 캐시를 더 정교하게 관리합니다. TensorRT-LLM은 KV 캐시를 고정된 수의 토큰에 대한 KV 상태를 담는 블록 풀 구조로 관리합니다.2 이때 단일 KV 캐시 블록의 토큰 수는 2보다 큰 2의 거듭제곱이어야 합니다.2
또한 새 요청이 기존 요청과 같은 프리픽스를 공유하면 저장된 KV 블록을 재사용할 수 있습니다.2 TensorRT-LLM은 채워진 KV 블록을 radix 검색 트리에 저장해 이후 요청에서 재사용할 수 있도록 합니다.2 이런 재사용은 계산량뿐 아니라 메모리 사용량도 줄일 수 있습니다.2
즉 KV 캐시 최적화는 단순히 “얼마나 큰가”의 문제가 아닙니다. 요청들이 프리픽스를 공유하는지, 긴 시스템 프롬프트가 반복되는지, 캐시 블록이 얼마나 오래 유지되는지 같은 트래픽 특성도 함께 봐야 합니다.
배포 전에 확인할 세 가지
1. 최대 컨텍스트 길이
긴 컨텍스트를 지원할수록 KV 캐시 예산은 커집니다. 사용자가 항상 최대 길이를 쓰지 않더라도, 서비스가 보장하려는 최대 길이는 용량 계획의 기준이 됩니다.
따라서 “모델이 100만 토큰을 지원한다”는 사실만 보고 배포를 결정하기보다, 실제 제품에서 필요한 최대 컨텍스트가 얼마인지 먼저 정해야 합니다.
2. 배치 크기와 동시성
단일 요청 기준으로는 문제가 없어 보여도 여러 요청이 겹치면 KV 캐시는 빠르게 병목이 됩니다. 특히 긴 입력을 여러 사용자가 동시에 처리하는 서비스라면 모델 가중치보다 KV 캐시가 남은 GPU 메모리를 먼저 소진할 수 있습니다.
계산기는 이 지점을 조기에 드러내는 데 유용합니다. 모델별 KV 캐시 크기를 비교하면서 목표 동시성에 맞는 현실적인 컨텍스트 길이를 정할 수 있습니다.
3. 캐시 축출 정책
캐시가 가득 차면 어떤 블록을 유지하고 어떤 블록을 버릴지도 중요합니다. TensorRT-LLM은 우선순위 기반 LRU 방식으로 KV 블록을 축출합니다.2 KV 블록 우선순위는 0부터 100까지 지정할 수 있으며, 100이 가장 중요합니다.2 기본 우선순위는 35입니다.2
이 정책은 반복적으로 쓰이는 프롬프트나 중요한 세션의 캐시를 더 오래 유지하는 데 영향을 줄 수 있습니다. 결국 KV 캐시는 메모리 계산뿐 아니라 운영 정책의 문제이기도 합니다.
결론: KV 캐시는 배포 가능성을 가르는 핵심 변수다
KVCache.ai의 KV Cache Size Calculator가 유용한 이유는 복잡한 추론 시스템의 한 가지 핵심 질문을 숫자로 바꿔주기 때문입니다.
원하는 모델, 컨텍스트 길이, 동시성을 GPU 메모리 안에서 감당할 수 있는가?
LLM 배포 계획에서는 모델 파라미터 수와 가중치 크기만 볼 것이 아니라 KV 캐시까지 함께 계산해야 합니다. 긴 컨텍스트를 제공하거나 동시 요청을 많이 처리해야 한다면 KV 캐시는 선택적 최적화 항목이 아니라 초기 설계 단계에서 확인해야 할 필수 변수입니다.
KVCache.ai 계산기는 그 판단을 시작하기 위한 실용적인 출발점입니다.
1kv-cache-calculator/index.html at main · paralleliq/kv-cache-calculator · GitHub
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.