LLM은 학습보다 ‘서빙’이 어렵다 — KV Cache와 Prefill·Decode 자원 관리

LLM은 학습보다 ‘서빙’이 어렵다 — KV Cache와 Prefill·Decode 자원 관리

LLM을 서비스에 올리면 모델 정확도만큼 중요한 것이 응답 속도와 동시 처리량입니다. 같은 GPU에서도 메모리를 어떻게 관리하고 요청을 어떻게 스케줄링하느냐에 따라 서비스 품질이 크게 달라집니다.

LLM 추론은 두 단계로 나뉜다

사용자 입력을 한꺼번에 처리하는 Prefill 단계는 계산량이 크고 병렬성이 높습니다. 이후 토큰을 하나씩 생성하는 Decode 단계는 반복적으로 KV Cache를 읽으며 진행됩니다. 두 단계의 자원 사용 특성이 다르기 때문에 같은 방식으로 스케줄링하면 비효율이 발생합니다.

KV Cache가 메모리를 먹는다

LLM은 이전 토큰의 Attention 계산 결과를 KV Cache로 저장해 같은 계산을 반복하지 않습니다. 대화가 길어지고 동시 사용자가 늘어나면 KV Cache가 GPU 메모리를 빠르게 차지합니다. 따라서 캐시를 어떤 단위로 할당하고 재사용하거나 다른 계층으로 이동할지가 핵심 운영 문제입니다.

연속 배치와 메모리 관리

요청이 들어올 때마다 고정 배치를 만드는 대신 실행 중인 배치에 새 요청을 계속 합류시키는 방식은 GPU 활용도를 높일 수 있습니다. 또한 메모리를 페이지 단위로 관리하면 요청 길이가 제각각일 때 발생하는 낭비를 줄일 수 있습니다. 이런 아이디어가 대규모 LLM 서빙 시스템의 중요한 기반이 되고 있습니다.

Prefill과 Decode를 분리할 것인가

최근 연구는 Prefill과 Decode를 서로 다른 GPU나 노드로 분리해 각 단계에 최적화된 자원을 배치하는 구조를 제안합니다. 반대로 두 단계를 적절히 혼합해 GPU 유휴 시간을 줄이는 접근도 있습니다. 핵심은 특정 구조 하나가 항상 정답이 아니라 워크로드에 따라 처리량과 지연시간의 균형점을 찾는 것입니다.

Goodput이 중요하다

단순 초당 토큰 수보다 사용자가 요구하는 지연시간 목표를 만족하면서 처리한 요청량, 즉 Goodput 관점이 중요해지고 있습니다. 긴 요청 하나가 전체를 막지 않도록 스케줄링하고, 캐시와 연산 자원을 동적으로 배치해야 실제 서비스 품질이 높아집니다.

기업 도입 시 체크할 것

사내 LLM을 구축한다면 GPU 모델과 VRAM만 비교해서는 부족합니다. 동시 사용자 수, 평균 입력 길이, 출력 길이, 긴 컨텍스트 비율, 첫 토큰 응답시간, 토큰 생성 지연, KV Cache 사용량을 실제 업무 트래픽으로 측정해야 합니다. 서빙 소프트웨어의 선택이 하드웨어 구매만큼 중요합니다.

참고 자료
한국정보과학회, 정보과학회지 2026년 9월호 「AI 시대의 HPC 인프라와 시스템 기술」 특집을 바탕으로 블로그용으로 재구성했습니다.

태그
#LLM서빙 #KVCache #Prefill #Decode #GPU메모리 #vLLM #AI인프라 #생성형AI