vLLM 추론 서빙에서 PagedAttention과 연속 배치가 GPU 활용률을 바꾸는 방식

정적 배치가 남기는 GPU 유휴

Netflix는 사내 LLM 서빙 추론 엔진으로 vLLM을 선택했다고 밝히며, 페이지 단위 KV 캐시 관리와 연속 배치가 대규모 운영에서 중요한 선택 기준임을 보여줬다. 같은 GPU라도 어떤 엔진을 쓰는지에 따라 처리 가능한 QPS가 크게 달라지고, 그 차이는 인프라 비용으로 이어진다.

Netflix는 처음 TensorRT-LLM 기반에서 출발했지만, 오픈소스 엔진과 전용 스택의 성능 차이가 좁혀진 시점에 선택을 다시 검토했다. 복잡한 컴파일 없이 커스텀 모델 아키텍처를 적재할 수 있는 유연성, 커스텀 디코딩 로직을 위한 확장 훅, 그리고 디버깅 편의성이 선택 근거였다.

실제 워크로드는 임베딩 생성, 랭킹·검색을 위한 프리필 전용 추론, 자기회귀 디코딩, 단계별 제약 로직을 가진 커스텀 모델이 섞여 있다. 하나의 최적화 스택만으로 이 구성을 모두 흡수하기는 어렵다.

LLM 서빙에서 GPU가 놀게 되는 대표적 이유는 가변 길이 요청을 정적 배치에 묶는 방식이다. 짧은 요청이 먼저 끝나도 가장 긴 요청이 끝날 때까지 해당 슬롯은 비어 있게 된다. 연속 배치는 완료된 요청의 자리에 대기 요청을 즉시 넣고, 매 디코딩 스텝마다 실행 집합을 다시 구성한다.

페이지 단위 KV 캐시와 스케줄러의 역할

PagedAttention은 KV 캐시를 고정 크기 블록, 즉 페이지 단위로 다룬다. 연속 메모리를 최대 길이에 맞춰 미리 확보하는 방식은 실제 사용 길이와 예약 길이의 차이만큼 메모리를 낭비한다. 반면 블록 단위 할당은 필요한 시점에 필요한 만큼만 확보하므로 낭비를 블록 크기 이내로 제한한다.

블록 테이블은 논리적인 토큰 위치와 물리 블록을 연결한다. 블록 크기는 단순한 상수가 아니다. 작게 잡으면 메모리 낭비는 줄지만 테이블 오버헤드가 늘고, 크게 잡으면 그 반대가 된다.

연속 배치의 이점은 요청 길이 분산이 클수록 커진다. 길이가 비슷한 요청만 처리한다면 정적 배치와의 차이가 작지만, 편차가 큰 실서비스에서는 그 차이가 배 이상 벌어진다.

프리필과 디코드도 동일한 성격의 작업이 아니다. 프리필은 연산 집약적이고, 디코드는 메모리 대역 집약적이다. 이 둘을 같은 배치에서 다루면 프리필이 디코드 지연을 밀어낼 수 있다. 별도로 실행하거나 프리필을 청크 단위로 나누어 디코드 사이에 배치하면 지연 튐을 억제할 수 있다.

동일한 시스템 프롬프트나 문서 프리픽스를 사용하는 요청은 블록을 함께 쓸 수 있다. 공유 블록은 참조 카운트로 관리하며, 마지막 참조가 사라질 때 회수한다. 페이지 단위 관리 구조는 이 프리픽스 캐시 공유를 자연스럽게 지원한다.

텐서 병렬은 하나의 모델을 여러 GPU에 나누어 대형 모델을 적재할 수 있게 하지만 통신 오버헤드를 추가한다. 투기적 디코딩은 소형 초안 모델이 여러 토큰을 제안하고 본 모델이 이를 일괄 검증하는 방식이며, 수용률이 높은 워크로드에서 디코딩 지연을 낮춘다.

GPU 메모리가 부족해지면 새 요청은 큐에서 기다리거나, 실행 중인 요청이 선점(preempt)된다. 선점된 요청은 재계산 또는 스왑으로 복구한다. 대기 시간이 SLO를 위협하는 시점을 오토스케일 트리거로 삼는 접근이 실무적이다.

⤢✕

실제 요청 분포를 기준으로 운영점 찾기

엔진 벤치마크는 조직의 실제 요청 분포를 반영해야 한다. 길이가 균일한 합성 부하만으로는 연속 배치의 효과를 과소평가할 수 있다. 처리량(토큰/초), TTFT, 토큰 간 지연, GPU 메모리 사용률, 선점 발생률을 함께 측정해야 하며, 처리량 하나로 엔진을 선택하면 지연이 무너질 수 있다.

배치 크기는 처리량과 지연을 맞바꾸는 조절점이다. 배치를 키우면 처리량은 오르지만 개별 지연도 늘어난다. 따라서 목표는 “P95 TTFT 이내에서 최대 처리량”처럼 제약 최적화 형태로 잡아야 한다.

최대 시퀀스 길이를 실제 요청 분포보다 과도하게 잡으면 메모리 예약이 늘어 동시성이 감소한다. 최대 배치 크기는 메모리 한계와 지연 목표 중 먼저 제약이 되는 쪽에서 정해진다. 두 값을 함께 스윕해 운영점을 찾아야 한다.

캐시 사용률을 100%에 가깝게 운용하면 선점과 재계산이 빈발해 처리량이 오히려 낮아질 수 있다. 여유율 목표를 정하고(예: 10~15%) 이를 넘으면 스케일아웃하는 정책이 안정적이다.

부하 시험에는 긴 요청과 짧은 요청의 혼합, 프리픽스 공유 비율 변화, 급증 트래픽을 포함한다. 용량 계획에서는 “GPU 1대당 처리 가능 QPS”를 산출해야 하며, 이 값이 원가 산정과 오토스케일 정책의 기준이 된다.

엔진 버전, 배치 파라미터, 양자화 설정은 형상관리 대상이다. 성능 회귀 원인의 다수가 설정 변경이기 때문이다. 엔진 업그레이드는 벤치마크 통과를 배포 게이트로 삼아 관리할 필요가 있다.

정적 배치, 페이지 캐시, 런타임 선택의 차이

구분	연속 배치	정적 배치
GPU 활용률	높음	최장 요청에 종속
길이 편차 대응	강함	취약
구현 복잡도	스케줄러 필요	단순
지연 예측성	변동 있음	상대적 일정
처리량	우세	열세
적합 상황	가변 길이 실서비스	균일 길이 배치 작업

정적 배치에서는 배치 안의 모든 요청이 끝날 때까지 슬롯이 유지된다. 요청 길이 차이가 큰 서비스일수록 GPU 유휴가 커지는 이유다. 연속 배치는 요청 완료 직후 슬롯을 채우므로 동일 GPU에서 처리 가능한 QPS를 크게 높인다. 다만 길이가 균일한 오프라인 배치 작업에서는 두 방식의 차이가 크지 않다.

연속 메모리 KV 캐시는 최대 길이를 기준으로 예약해야 하므로 실제 사용량과의 차이만큼 메모리를 소비하고, 그만큼 동시 세션 수가 줄어든다. PagedAttention은 이 낭비를 블록 크기 이내로 제한하고 프리픽스 공유를 가능하게 한다. 대신 블록 테이블 조회 오버헤드가 추가되지만, 동시성이 중요한 서빙에서는 페이지 방식의 이득이 이를 크게 상회한다.

벤더 최적화 런타임은 특정 하드웨어와 모델 조합에서 최고 성능을 낼 수 있지만, 커스텀 아키텍처 적재나 디코딩 개입은 어렵고 컴파일 절차도 무겁다. 오픈소스 엔진은 유연성과 디버깅 편의성에서 앞선다. 성능 격차가 좁혀진 시점부터는 성능 외의 운영 조건이 선택 기준으로 올라선다. 대신 자체 운영 조직은 엔진 버전 관리와 성능 회귀 대응을 맡아야 한다.

성능 관리와 용량 계획에 남는 기준

LLM 서빙의 성능은 하드웨어 사양만으로 결정되지 않는다. 스케줄링 방식에 따라 같은 GPU의 처리량이 배 단위로 달라질 수 있다. 처리량과 지연은 별도의 지표로 관리해야 하며, 하나를 개선하면서 다른 하나를 무너뜨리지 않도록 해야 한다.

용량 산정의 단위도 GPU 대수가 아니라 GPU 1대당 QPS가 되어야 한다. 이 값은 요청 길이 분포와 프리픽스 공유율에 의존하므로, 워크로드 특성과 함께 기록해야 다시 활용할 수 있다. 메모리 여유율을 용량 계획에 명시적으로 포함해야 선점 폭주에 따른 성능 붕괴를 막을 수 있다.

배치 크기와 최대 시퀀스 길이는 성능과 안정성을 직접 바꾸는 통제 항목이다. 운영자가 임의로 조정할 수 있게 두면 장애 원인을 추적하기 어렵다. 엔진 업그레이드는 정기 변경 항목으로 편입하고, 벤치마크 결과를 승인 증적으로 남긴다.

연속 배치와 페이지 단위 캐시 관리는 추론 엔진의 기본 요건으로 굳어지며, 비교 기준은 지원 여부보다 스케줄러 정책의 세부로 옮겨갈 전망이다. 프리필·디코드 분리 실행은 별도 노드 풀로 확장되는 분리형 서빙으로 대규모 서비스에서 확산될 수 있다. 투기적 디코딩에서는 수용률 관리와 초안 모델 선택이 튜닝 항목으로 정착하고, 오픈소스 엔진과 벤더 런타임의 성능 격차 축소는 선택 기준을 성능에서 확장성과 운영 편의로 이동시킬 전망이다.