LLM 서빙: 연속 배칭·PagedAttention·프리필-디코드 분리

왜 필요했나: 모델보다 '줄 서는 방식'이 병목

모델 서빙(학습이 끝난 모델을 실제 요청에 응답하도록 운영하는 일)에서 대규모 언어 모델(LLM)은 일반 웹 서버와 사정이 다르다. 요청마다 답의 길이가 다르고, 답은 자기회귀 모델 방식으로 토큰을 하나씩 이어 붙여 만들어진다. 같은 GPU에 들어온 요청이라도 어떤 것은 10토큰 만에, 어떤 것은 2,000토큰이 지나서야 끝난다.

추론은 두 단계로 나뉜다. 먼저 프리필(prefill)에서 프롬프트 전체를 한 번에 읽고, 그 과정에서 나온 중간 계산 결과인 KV 캐시(어텐션이 다시 쓰는 Key·Value 값)를 저장한다. 이어지는 디코드(decode)에서는 이 KV 캐시를 읽으며 토큰을 하나씩 만든다. 프리필은 큰 행렬 곱이 많아 연산이 병목이고, 디코드는 한 토큰을 만들 때마다 가중치와 KV 캐시 전체를 메모리에서 읽어야 해서 메모리 대역폭이 병목이다.

옛 방식인 정적 배치 처리는 요청 여러 개를 묶어 한꺼번에 돌리고, 묶음 안에서 가장 긴 요청이 끝나야 다음 묶음을 받았다. 짧은 요청은 일찍 끝나고도 자리를 비우지 못하고, KV 캐시는 '최대 길이'만큼 미리 잡아 두느라 GPU 메모리(VRAM)가 낭비됐다. 지연 시간도 길고 처리량(토큰/초)도 낮았던 이유가 여기에 있다.

그래서 서빙 기술은 세 가지 질문에 답하는 방향으로 발전했다. 요청을 언제 넣고 뺄 것인가(연속 배칭), KV 캐시를 메모리에 어떻게 담을 것인가(PagedAttention), 성격이 다른 두 단계를 같은 GPU에서 돌려야 하는가(프리필-디코드 분리).

핵심 아이디어: 엘리베이터, 주차 칸, 분업 주방

세 기법을 비유 하나씩으로 잡아 두면 이해가 빠르다. 연속 배칭(Continuous Batching)은 엘리베이터와 같다. 정적 배치는 모든 승객이 내릴 때까지 1층으로 돌아오지 않는 엘리베이터이고, 연속 배칭은 층마다 서서 내릴 사람은 내리고 탈 사람은 태운다. 여기서 '층'은 토큰 하나를 만드는 한 걸음이다.

PagedAttention(페이지드 어텐션)은 주차장을 칸으로 나누는 일에 가깝다. 요청마다 최대 길이만큼 긴 빈터를 통째로 잡아 두는 대신, 작은 칸(블록)을 필요할 때 하나씩 내준다. 운영체제가 가상 메모리를 페이지 단위로 관리하는 방식에서 따온 생각이다. 요청의 KV 캐시가 물리적으로 흩어져 있어도 블록 표만 있으면 이어 읽을 수 있다.

프리필-디코드 분리는 식당 주방의 분업이다. 재료 손질(프리필)은 한꺼번에 많은 양을 빠르게 처리하는 일이고, 조리(디코드)는 접시마다 조금씩 꾸준히 하는 일이다. 한 요리사가 둘을 번갈아 하면 손질 작업이 들어올 때마다 조리가 멈춘다. 둘을 다른 팀에 맡기면 서로 방해하지 않지만, 손질한 재료(KV 캐시)를 조리대로 옮기는 운반 비용이 새로 생긴다.

세 기법이 맞바꾼 것을 정리하면 이렇다. 연속 배칭은 단순함을 내주고 매 걸음 스케줄링 비용을 받아들였다. PagedAttention은 연속된 메모리 배치를 포기하고 블록 표를 따라가는 간접 참조를 감수한다. 분리 구조는 단계 간 간섭을 없앤 대가로 네트워크 전송을 떠안는다.

어떻게 작동하나

첫째, 요청이 들어오면 스케줄러가 대기열을 본다. 연속 배칭에서는 토큰 단위로 요청을 끼워 넣고 빼므로, 한 걸음이 끝날 때마다 '끝난 요청 제거, 새 요청 추가'가 일어난다. 연속 배칭 스케줄링 연구논문는 이것을 시퀀스가 도착하고 끝나는 대로 요청을 토큰 단위로 엇갈려 처리하는 방식이라고 설명한다. 긴 프롬프트가 한꺼번에 들어와 디코드 중인 요청을 멈추게 하는 일을 막으려고 프리필을 조각으로 나눠 넣는 청크 프리필(chunked prefill)도 흔히 함께 쓰인다. QBA 연구논문의 시뮬레이터는 디코드 우선 배칭, 청크 프리필, 토큰 예산, KV 캐시 여유를 확인한 뒤의 입장 허가까지 서빙 엔진의 동작으로 모델링한다.

둘째, 새 요청의 프리필이 KV 캐시를 만들면 PagedAttention 방식의 메모리 관리자가 고정 크기 블록을 내준다. 블록 단위로 관리하기 때문에 여러 요청이 같은 접두부(예: 같은 시스템 프롬프트)를 쓰면 그 블록을 공유할 수 있고, 메모리가 모자라면 블록 단위로 내쫓거나 아래 계층으로 내릴 수 있다. 뒤에서 볼 KV 캐시 연구 대부분이 이 '블록'을 기본 단위로 삼는다.

셋째, 분리 구조에서는 프리필 GPU가 만든 KV 캐시를 디코드 GPU로 보낸다. 광 KV 캐시 네트워크 연구논문는 응답이 시작되기 전에 요청마다 KV 캐시가 프리필 GPU에서 디코드 GPU로 옮겨 가야 하고, 코딩 에이전트의 한 턴은 긴 컨텍스트 전체의 KV 캐시를 옮기는 일이 많다고 짚는다. 대역폭이 모자라는 네트워크에서는 이 전송이 TTFT(첫 토큰까지 걸리는 시간)에 그대로 더해진다.

넷째, 디코드 GPU는 블록 표를 따라 KV 캐시를 읽으며 토큰을 하나씩 만들고, 걸음마다 스케줄러가 배치를 다시 짠다. 답이 끝난 요청의 블록은 풀어 주거나, 다음 턴에 재사용하도록 캐시에 남긴다.

발전 흐름: KV 캐시를 줄이고, 다시 쓰고, 옮기기

블록 단위 관리가 자리 잡자 연구의 초점은 'KV 캐시를 얼마나 아껴 쓰느냐'로 옮겨 갔다. 한 갈래는 다시 쓰기다. CacheTune논문은 긴 컨텍스트에서 프리필이 만드는 TTFT가 가장 큰 병목이라고 보고, 기존 접두부 캐싱이 앞부분이 정확히 같을 때만 통한다는 한계를 겨냥한다. 접두부가 아닌 위치의 KV를 그대로 재사용하면 조각 사이의 어텐션 관계가 깨져 품질이 떨어지므로, 어텐션 회복에 중요한 토큰만 골라 다시 계산하고 나머지는 재사용한다.

다른 갈래는 줄이기와 내쫓기다. EVICPRESS논문는 사용자가 늘면 KV 캐시가 GPU 메모리를 쉽게 넘는데, 기존 연구는 아래 계층으로 내쫓거나 압축하는 것 중 하나만 했다고 지적한다. 그래서 모든 컨텍스트의 압축·교체 결정을 하나의 효용 함수로 함께 최적화한다. KV 블록 공동 인코딩논문은 요청과 입력 조각을 가로질러 비슷한 블록을 하나의 공유 표현으로 합치면서 표준 캐시 구조는 그대로 둔다. 최대 4.38배 압축에 정확도 손실은 거의 없었고, 단일 머신 vLLM 벤치마크에서 토큰 처리량이 약 40% 늘었다고 보고한다.

무엇을 내쫓을지도 다시 따져졌다. 최근성·빈도 적응형 KV 캐싱논문은 흔히 쓰는 LRU(가장 오래 안 쓴 것부터 내쫓기) 정책 아래서 서로 관계없는 작업들이 서로의 캐시를 밀어낸다고 지적한다. 최근에 쓴 블록과 자주 쓰는 블록에 공간을 동적으로 나눠 주자, 합성 문서 질의응답 작업에서 vLLM 대비 캐시 적중률이 최대 10.8% 오르고 TTFT가 최대 12.6% 줄었다. 다만 실제 대화 작업에서는 각각 2.1%, 2.0%에 그쳤다.

에이전트와 분리 구조는 새로운 압력을 더했다. TokenCake논문는 외부 함수 호출을 기다리는 에이전트의 KV 캐시가 GPU 메모리에 놀고 있는 문제를 다룬다. 함수 호출 동안 캐시를 미리 내려 두고 돌아올 때를 예측해 올리는 방식으로, 메모리가 빠듯한 환경에서 vLLM보다 전체 지연을 최대 47.06% 줄이고 실효 GPU 활용률을 16.9%p 높였다. 분리 구조 쪽에서 SpectrumKV논문는 KV 전송을 '보낸다/안 보낸다'의 이분법이 아니라 토큰마다 정밀도를 달리 주는 문제로 바꿨고, 광 KV 캐시 네트워크논문는 전송 경로 자체를 광 회로 스위치로 바꿨다.

요즘 어디로 가고 있나

첫 번째 흐름은 KV 캐시를 GPU 밖으로 더 멀리 내리는 일이다. KVStream논문은 에이전트·코딩·문서 작업에서 재사용할 접두부의 KV 캐시가 GPU와 호스트 메모리를 넘어서면서 저장장치 입출력이 추론 단계의 핵심 경로에 올라왔다고 본다. 노드 로컬 NVMe 하나가 모든 읽기를 떠안는 동안 이미 마운트된 병렬 파일 시스템은 거의 놀고 있다는 관찰에서 출발해, 청크를 모든 계층에 복제하고 비어 있는 계층이 다음 청크를 가져가게 했다. LMCache에 붙여 최대 128개 GPU에서 평가한 결과, 이론상 대역폭 한계의 5% 안에서 읽어 왔고 오프라인 처리량은 LMCache보다 최대 1.49배, 요청이 몰릴 때의 평균 TTFT는 최대 6.1배 낮았다.

두 번째 흐름은 스케줄링 정책을 다시 보는 일이다. 연속 배칭 스케줄링 연구논문는 모델 구조나 커널을 바꾸지 않고 가벼운 정책만 바꿔도 지연과 처리량의 균형이 달라지는지 확인했다. 여섯 개 모델과 L40S·A100·H100 GPU에서 여덟 가지 정책을 1,152회 실행한 결과, 모델·GPU·작업·배치 크기·프리필 예산이 같아도 스케줄러 선택에 따라 처리량, TTFT, 꼬리 지연이 달라졌다. 많은 설정에서 에이징을 더한 '짧은 프롬프트 먼저'가 가장 강한 실용 기준선이었다. 남은 길이를 미리 아는 이상적인 스케줄러조차 충분하지 않았는데, 배칭과 하드웨어 효과가 성능을 함께 좌우하기 때문이다.

QBA논문는 같은 문제를 공정성 쪽에서 본다. 답이 짧을 것으로 예측된 요청을 먼저 처리하면 평균 지연은 줄지만 긴 요청이 심하게 밀린다. 그렇다고 오래 기다린 요청을 무제한으로 앞으로 올리면 혼잡할 때 긴 요청이 과하게 우대된다. QBA는 오래 기다린 긴 요청을 올려 주되 할당량과 '빚' 규칙으로 그 폭을 제한해, 긴 요청의 꼬리 지연을 크게 줄이면서도 평균 지연 이득의 상당 부분을 지켰다.

한계와 쟁점

프리필-디코드 분리는 공짜가 아니다. SpectrumKV논문가 말하듯 분리는 KV 캐시를 네트워크로 보내야 하는 짐으로 바꾼다. 전송량을 줄이려 KV를 양자화하면 모델마다 견디는 정도가 다르다. 이 연구에서 Qwen2.5-7B는 INT4 KV 양자화에서 심하게 무너졌고 Mistral-7B와 Gemma-2-9B는 안정적이었다. 그래서 배포할 때 짧은 탐침 실험을 돌려 INT4를 쓸지 정한다. 정규화 KV 예산 50%의 WikiText-2에서 SpectrumKV의 퍼플렉서티 변화는 세 모델에서 +1.97%, -0.06%, -0.44%였고, 비교 방법인 PDTrim은 +25.85%, +22.07%, +35.63%였다.

네트워크 비용도 쟁점이다. 광 KV 캐시 네트워크논문는 대역폭이 모자란 패킷 네트워크 뒤에서는 전송이 TTFT를 늘린다고 보고, 프리필이 계산되는 동안 광 회로를 미리 예약해 기계식 스위치의 재구성 지연을 숨겼다. 실제 서빙 트레이스로 한 시뮬레이션에서 400G 패킷 네트워크와 비슷한 성능을 2:1 네트워크 비용의 0.55~0.78배로 냈고, 384포트 기계식 스위치의 50ms 재구성 지연도 견뎠다. 다만 시뮬레이션 결과라는 점은 함께 봐야 한다.

KV 캐시를 아래 계층으로 내리는 일도 조건을 탄다. KVStream논문의 성능 모델은 부하가 클수록 TTFT 이득이 커지지만, 호스트 메모리나 요청 도착 순서 덕분에 재사용분이 이미 캐시에 남아 있으면 이득이 사라진다고 예측한다. 압축 계열은 손실 압축이라 품질 영향을 작업별로 확인해야 한다. EVICPRESS논문가 품질과 지연을 하나의 효용 함수로 묶은 것도 이 둘이 서로 맞바뀌기 때문이다.

스케줄링에는 공정성 문제가 따른다. '짧은 것 먼저'는 평균을 좋게 만들지만 긴 요청을 굶길 수 있고논문, 실험실의 이상적 정책이 실제 하드웨어에서 그대로 통하지 않는다논문. 평균 지연 한 숫자만 보고 정책을 고르면 꼬리 지연에서 사고가 난다.

실무 판단 기준: 언제 무엇을 쓰나

연속 배칭과 PagedAttention 방식의 블록 관리는 오늘날 추론 엔진(vLLM·SGLang·TensorRT-LLM 등)의 기본값에 가깝다. 따로 고를 문제라기보다 켜져 있다고 보고, 블록 크기·최대 배치·프리필 예산 같은 손잡이를 작업에 맞게 조정하는 쪽에 시간을 쓰는 편이 낫다. 지켜볼 지표는 평균 지연이 아니라 TTFT와 꼬리 지연(P90·P99), 그리고 KV 캐시 적중률이다.

프리필-디코드 분리는 긴 프롬프트와 긴 출력이 섞여 서로 간섭이 심할 때, 그리고 GPU 사이 대역폭이 충분할 때 검토할 만하다. 프롬프트가 짧고 트래픽이 작으면 전송 비용과 운영 복잡도가 이득을 넘기 쉽다. 분리 구조에서 KV를 양자화해 보낸다면 모델별로 먼저 시험해야 한다. 같은 INT4라도 어떤 모델은 무너진다논문.

에이전트 작업은 따로 따져야 한다. 도구 호출을 기다리는 동안 KV 캐시가 GPU 메모리를 붙잡고 있고논문, 재사용할 접두부가 커서 저장장치 입출력이 병목이 된다논문. 이런 작업이라면 KV 캐시 내리기·미리 올리기와 다계층 저장을 우선 살펴본다. 서로 다른 작업이 한 캐시를 함께 쓴다면 LRU가 서로의 캐시를 밀어내는지 적중률로 확인한다논문.

흔한 실수는 세 가지다. 같은 GPU·같은 모델이니 스케줄러는 상관없다고 가정하는 것, 합성 작업의 개선 수치를 실제 대화 작업에 그대로 기대하는 것(논문에서 10.8%가 2.1%로 줄었다), 압축률만 보고 품질 확인을 건너뛰는 것이다.

더 공부하려면

서빙의 전체 그림을 먼저 잡고 싶다면 연속 배칭 스케줄링 연구논문부터 읽기를 권한다. 연속 배칭이 무엇이고 스케줄러가 처리량·TTFT·꼬리 지연을 어떻게 바꾸는지 실험으로 보여 준다. 이어서 QBA논문를 읽으면 짧은 요청 우선과 공정성 사이의 줄다리기를 이해할 수 있다.

KV 캐시 관리는 최근성·빈도 적응형 캐싱논문으로 교체 정책의 기본을 익히고, EVICPRESS논문와 KV 블록 공동 인코딩논문으로 압축과 교체를 함께 다루는 법을 본 뒤, CacheTune논문으로 접두부가 아닌 위치의 재사용까지 넓히는 순서가 자연스럽다.

프리필-디코드 분리는 SpectrumKV논문와 광 KV 캐시 네트워크논문를 함께 읽으면 '무엇을 보낼까'와 '어떻게 보낼까'를 양쪽에서 볼 수 있다. 에이전트 서빙에 관심이 있다면 TokenCake논문와 KVStream논문을 이어 읽는다.