긴 대화가 늘어날 때 AI 서버에 남겨야 할 메모리

모델을 GPU에 올리는 데 성공해도 긴 요청을 동시에 처리할 여유는 따로 필요하다. KV 캐시의 용량을 계산하고 문맥 길이, 동시 요청, 저장 정밀도를 업무 응답 기준과 연결하는 방법을 살펴본다.

GPT Image 2로 만든 개념 일러스트레이션. 실제 장비나 메모리 측정 결과를 나타내지 않는다.

팀이 자체 AI 서버에 모델을 올리고 짧은 질문으로 동작을 확인했다고 가정해 보자. 혼자 사용할 때는 잘 돌아간다. 그런데 여러 사람이 회의록과 참고 문서를 붙여 질문하기 시작하자 응답이 늦어지거나 메모리가 부족해진다. 모델 파일은 바뀌지 않았다. 달라진 것은 서버가 동시에 붙잡아 두어야 할 요청의 상태다.

이때 살펴볼 대상 가운데 하나가 KV 캐시다. 모델을 적재할 수 있는지 확인하는 일과, 긴 요청을 몇 개까지 원하는 응답 시간 안에 처리할 수 있는지 확인하는 일은 서로 다른 시험이다. 업무용 AI의 준비 상태를 판단하려면 가중치가 차지하는 공간 옆에 요청을 위한 공간도 남겨야 한다.

모델 옆에서 자라는 요청의 상태

일반적인 자기회귀 Transformer는 앞에서 처리한 토큰을 바탕으로 다음 토큰을 생성한다. 매번 이전 토큰의 key와 value를 다시 계산하지 않도록, 어텐션 층별로 그 상태를 저장해 재사용하는 것이 KV 캐시다. 전체 이력을 유지하는 어텐션에서는 처리한 토큰이 늘어날수록 저장할 상태도 늘어난다. Hugging Face 캐시 설명

2026년 10월 26일 확인한 Transformers 기본 브랜치의 DynamicLayer는 key와 value를 배치, 헤드, 시퀀스, 헤드 차원의 텐서로 보관한다. 새 상태는 시퀀스 차원을 따라 이어 붙인다. 이 구현을 보면 모델의 매개변수 개수가 그대로여도 요청의 길이와 묶음 크기에 따라 추가 메모리가 필요해지는 이유를 알 수 있다. 확인한 리비전의 캐시 구현

그렇다고 모든 모델의 캐시가 끝없이 같은 방식으로 늘어나는 것은 아니다. 슬라이딩 윈도나 청크 단위 어텐션을 쓰는 층은 보존 범위가 제한될 수 있다. 다른 종류의 상태를 사용하는 모델도 있다. 따라서 ‘토큰 수가 두 배면 캐시도 두 배’라는 계산은 어떤 구조의 캐시를 전제했는지와 함께 써야 한다. Transformers 캐시 전략

가중치를 낮은 정밀도로 저장했다는 사실만으로 KV 캐시의 저장 형식까지 판단할 수도 없다. 현재 vLLM 설정은 캐시 저장 형식을 cache_dtype로 별도 다루며, 선택 가능한 형식과 동작에는 모델·실행 환경의 조건이 붙는다. ‘작은 모델 파일’이라는 한 항목 대신 가중치 형식과 실제 캐시 형식을 각각 확인하는 편이 정확하다. 확인한 vLLM 캐시 설정

용량 계산에 동시 요청을 넣는다

모든 층에서 같은 크기의 key와 value를 저장하는 전체 어텐션을 가정하자. 공유나 압축 없이, 실제로 보관한 텐서 값만 세면 다음과 같이 용량을 계산할 수 있다. 저장 형상에서 유도한 단순 계산이며 특정 서버의 실측 공식은 아니다.

KV 값의 바이트 수
= 2 × 층 수 × KV 헤드 수 × 헤드 차원
  × 요청별 저장 토큰 수의 합 × 요소당 바이트 수

앞의 2는 key와 value 두 묶음을 뜻한다. KV 헤드 수는 실제 캐시 텐서에 저장되는 헤드 수다. 여기서 토큰 수는 서비스가 광고하는 최대 문맥 길이가 아니라, 해당 시점에 캐시에 남긴 토큰 수다. 요청에 포함한 입력과 생성하면서 추가된 상태를 함께 고려해야 한다.

가상의 모델이 32개 층, KV 헤드 8개, 헤드 차원 128을 사용하고 각 값을 2바이트로 저장한다고 해 보자. 한 요청에서 8,192토큰의 상태를 보관하면 2 × 32 × 8 × 128 × 8,192 × 2는 1,073,741,824바이트, 즉 1GiB다. 같은 길이의 요청 8개를 공유 없이 동시에 보관하면 KV 값만 8GiB다. 이 수치는 산술 예시이며 실제 모델의 성능 측정 결과가 아니다.

이 계산에는 가중치, 임시 연산 공간, 메모리 할당기의 여유분, 패딩이나 블록 끝의 빈 공간이 들어 있지 않다. 정적 캐시처럼 최대 크기를 미리 확보하는 구현에서는 실제 저장 토큰 수로 센 값보다 예약 공간이 클 수 있다. 여러 GPU에 나누는 방식과 일부 상태를 공유하는 방식도 장치별 사용량을 바꾼다. 계산표의 값은 필요한 항목 하나를 드러내는 출발점으로 써야 한다.

업무 관점에서 중요한 변화는 요청 수를 단순한 접속자 수로 보지 않게 된다는 것이다. 짧은 질문 8개와 긴 문서 질문 8개는 같은 메모리 부담을 만들지 않는다. 짧게 시작한 대화도 여러 차례 이어지면 상태가 길어질 수 있다. 따라서 동시 처리 규모를 말할 때에는 어떤 길이의 입력과 출력을 전제로 했는지 함께 밝혀야 한다.

공간을 줄이는 선택에는 다른 비용이 붙는다

캐시를 다루는 방법은 하나가 아니다. Transformers의 동적 캐시는 필요에 따라 커지고, 정적 캐시는 정해 둔 최대 크기를 확보해 컴파일에 유리한 고정 형상을 만든다. CPU로 캐시를 옮기는 offloading은 GPU 공간을 줄일 수 있지만 전송 작업이 생긴다. 캐시 양자화도 저장량을 줄이지만, 짧은 문맥에서 메모리가 충분한 경우에는 지연에 불리할 수 있다고 공식 문서는 설명한다. Transformers 캐시 전략과 제약

이 선택들을 ‘메모리 절약’이라는 한 점수로 줄이면 업무에 맞는 결정을 하기 어렵다. 즉시 답해야 하는 짧은 질의와 오래 걸려도 되는 문서 일괄 처리는 허용할 수 있는 지연이 다르다. 저장 정밀도를 바꿀 때는 공간 감소뿐 아니라 해당 업무의 답변 품질도 다시 확인하는 것이 좋다. 특정 캐시 방식을 모든 업무의 기본값으로 정하기 전에 입력 길이와 응답 요구를 나눠 보는 이유다.

현재 vLLM의 kv_cache_memory_bytes는 GPU별 KV 캐시 용량을 지정하는 설정이다. 값을 명시하면 gpu_memory_utilization을 통한 추정보다 우선한다. 설정에는 최대 문맥 길이를 기준으로 한 동시 수용량을 나타내는 항목도 있다. 이는 용량을 해석할 단서를 주지만, 사용자가 원하는 응답 속도를 보장하는 수치는 아니다. 메모리에 여러 요청을 담을 수 있어도 계산과 데이터 이동, 대기 시간은 따로 남는다. vLLM 캐시 설정 문서

기존 글에서 다룬 prefix caching은 공통 입력 앞부분의 계산 재사용에 초점이 있다. 오늘의 질문은 동시에 살아 있는 요청의 상태에 얼마만큼의 공간이 필요한가다. FlashAttention의 어텐션 중간값·메모리 이동 최적화도 이 용량 검토와 연결되지만, 요청 상태의 예산을 대신 정해 주지는 않는다. 서로 다른 최적화의 효과를 같은 것으로 계산하지 않아야 한다.

업무의 응답 기준에서 수용량을 정한다

팀이 자체 서버를 도입한다면, 실제 업무에 가까운 요청을 길이와 동시성별로 나눠 시험하는 방식을 제안한다. 다음 표는 시험 설계 예시다. 제품의 보장 수치나 이미 수행한 벤치마크가 아니다.

처음에는 모델 리비전과 캐시 형식, 장비를 고정하고 한 조건씩 바꾼다. 그다음 캐시 전략을 바꿔 같은 요청 묶음으로 다시 비교한다. 메모리 부족이 사라졌는지와 함께, 기다림이 어느 단계에서 늘었는지 확인해야 한다. 평균 응답 시간만 보면 일부 긴 요청이 겪는 대기를 놓칠 수 있으므로, 느린 요청의 분포도 살펴볼 필요가 있다.

결과에 따라 긴 문서 처리를 별도 대기열로 보내거나, 동시에 받는 요청 수와 입력·출력 한도를 조정할 수 있다. 한도를 줄이는 일이 업무에 필요한 근거를 잘라 내지 않는지도 같이 검토해야 한다. 이는 필자의 운영 제안이며 특정 엔진이 자동으로 정해 주는 정책이 아니다. 메모리 사용량이 낮아졌다는 이유만으로 서비스 품질이 좋아졌다고 판단하지 않는 것이 핵심이다.

AI 서버의 용량 계획에는 ‘어떤 모델을 올렸는가’와 ‘어떤 요청을 함께 처리하는가’가 나란히 들어가야 한다. KV 캐시를 계산하는 목적도 최대 숫자를 광고하는 데 있지 않다. 팀이 실제로 맡길 긴 대화와 문서 작업에, 검증된 답을 끝까지 돌려줄 공간과 시간을 확보하는 데 있다.