PagedAttention 원리 정리: vLLM이 KV 캐시 낭비를 60~80%에서 4% 미만으로 줄인 방법

핵심 메시지

• 기존 LLM 서빙은 요청마다 최대 길이를 가정해 연속된 메모리를 통째로 예약하기 때문에, 전체 메모리는 남아 있어도 조각나 있어서 새 요청을 거절하는 일이 벌어진다.
• PagedAttention은 운영체제의 가상 메모리 아이디어를 KV 캐시에 적용해, 캐시를 보통 16개 토큰 단위의 고정 크기 블록으로 쪼개고 블록 테이블로 논리 위치와 물리 위치를 연결한다.
• 블록 단위로 나누면 여러 요청이 같은 접두어를 공유할 수 있다. 같은 프롬프트로 시작해 뒤에서 갈라지는 세 개의 대화라면, 공유 구간을 한 번만 저장해 약 67%를 절약한다.
• 연속 배칭은 나머지 절반의 속도 향상을 담당한다. 정적 배칭에서는 먼저 끝난 요청이 다른 요청을 기다리며 GPU를 놀리지만, 연속 배칭은 요청이 끝나는 즉시 다음 반복에서 새 요청을 채워 넣는다.
• 논문 기준 수치로 Llama 13B에서 FasterTransformer 대비 약 4배, Orca 대비 약 1.8배의 처리량을 냈고, OPT 175B급에서는 메모리 낭비가 4% 미만으로 떨어져 A100 80GB 16장이 필요하던 작업을 3~4장으로 처리할 수 있다고 소개된다.

쉽게 이해하기

영상은 아주 구체적인 장면에서 출발한다. 40GB 메모리를 가진 A100 한 장에서 여러 대화를 서빙하는데, 하나가 3GB, 다른 하나가 4GB, 또 하나가 5GB를 쓴다. 이 중 둘이 끝나면서 앞쪽에 3GB, 뒤쪽에 5GB의 빈자리가 생긴다. 이때 6GB가 필요한 새 대화가 들어오면 전체로는 8GB가 비어 있는데도 연속된 6GB를 확보할 수 없어 요청이 거절된다. 메모리 단편화다.

낭비는 여기서 그치지 않는다. 전통적인 서빙 방식은 요청마다 최대 시퀀스 길이를 가정해 연속된 메모리를 미리 예약한다. 40GB GPU에서 한 요청에 30GB를 잡아두었는데 실제로는 12GB만 쓴다면 18GB가 할당 안에서 그대로 놀게 된다. 영상은 일반적인 LLM 추론이 이런 식으로 메모리의 60~80%를 낭비한다고 설명한다. 길이 분포의 긴 꼬리에 대비해야 하는데 평균 사용량은 훨씬 낮고, 그 사이에 생긴 틈은 할당기가 제대로 재사용하지 못하기 때문이다.

해법은 운영체제에서 그대로 빌려 왔다. 프로그램이 얼마나 많은 메모리를 쓸지 미리 알 수 없다는 문제를 운영체제는 RAM을 4킬로바이트짜리 고정 페이지로 쪼개고, 필요할 때마다 할당하며, 페이지 테이블로 논리 주소와 물리 주소를 연결하는 방식으로 풀었다. 프로그램은 연속된 주소 공간을 보지만 실제 페이지는 어디에 흩어져 있어도 된다. 물리적으로 연속일 필요가 없다는 통찰이 외부 단편화를 없앤다. vLLM은 같은 전략을 KV 캐시에 적용해, 캐시를 보통 16개 토큰짜리 고정 블록으로 나누고 블록 테이블이 논리 블록 순서를 물리 블록 위치로 옮겨준다.

실제 흐름은 단순하다. 64개 토큰을 생성해야 하면 64를 16으로 나눠 올림한 네 개의 블록이 필요하다. 토큰이 나오는 대로 첫 블록부터 차례로 채우고, 요청이 끝나면 네 블록을 즉시 자유 풀로 돌려준다. 거대한 영역을 미리 잡아두지 않으니 다음 요청이 곧바로 그 자리를 쓸 수 있다. 여기에 진짜 장점인 접두어 공유가 더해진다. 세 사용자가 같은 프롬프트로 시작해 각각 '쉽게', '기술적으로', '한 문장으로'라고 갈라진다면, 공유 구간을 세 번 저장하는 대신 한 번만 저장하고 세 요청이 같은 물리 블록을 가리키게 한다. 영상은 이 예에서 약 67%가 절약되며 동시 요청 수에 비례해 효과가 커진다고 설명한다.

속도의 나머지 절반은 연속 배칭이다. 정적 배칭에서는 네 요청을 함께 시작해 모두 끝날 때까지 기다리므로, 먼저 끝난 요청의 자리는 놀게 되고 GPU 사이클이 낭비된다. 연속 배칭에서는 요청이 끝나는 즉시 바로 다음 반복에서 새 요청이 그 자리를 차지한다. 영상은 이것만으로 처리량이 2~3배 올라가고 요청당 지연도 줄어든다고 정리한다. 마지막으로 vLLM이 연구용 트릭이 아니라 완결된 시스템이라는 점을 강조한다. 비연속 블록 위에서 어텐션을 효율적으로 계산하는 커널, 블록을 할당하고 반환하는 블록 매니저, 연속 배칭을 구현하는 스케줄러, 소유권과 공유를 추적하는 KV 캐시 매니저로 구성되며 설치는 pip 한 줄, 운영에서는 비동기 엔진이나 OpenAI 호환 서버를 쓰면 된다.

주요 인사이트

• 이 영상의 핵심 통찰은 성능 문제가 연산이 아니라 메모리 관리에 있었다는 점이다. 같은 GPU로 최대 네 배 많은 사용자를 받을 수 있게 된 것은 더 빠른 커널 때문이 아니라, 쓰지도 않을 자리를 미리 잡아두던 관행을 없앴기 때문이다.
• 고정 크기 블록이라는 선택이 두 가지를 동시에 해결한다는 점도 눈여겨볼 만하다. 블록이 작고 균일하기 때문에 큰 내부 공백이 생기지 않고, 동시에 여러 요청이 같은 블록을 가리킬 수 있어 공유가 가능해진다. 가변 크기 할당이었다면 둘 다 어려웠을 것이다.
• 블록 단위 관리가 연속 배칭을 가능하게 만든다는 인과 관계도 중요하다. 메모리가 작고 예측 가능한 단위로 움직이기 때문에 요청을 아무 때나 넣고 뺄 수 있고, 그래서 GPU를 계속 바쁘게 유지할 수 있다.
• 접두어 공유는 시스템 프롬프트가 긴 실제 서비스에서 특히 크게 작동한다. 영상의 예시는 세 사용자뿐이지만, 절약 효과가 동시 요청 수에 비례해 커진다는 설명은 같은 프롬프트를 공유하는 워크로드일수록 이득이 커진다는 뜻이다.
• 자동 자막 특성상 영상 음성에서는 PagedAttention이 'paged detention'으로, vLLM이 'VLM'으로 들리는 구간이 있다. 정확한 명칭은 영상 설명란과 원 논문 기준으로 PagedAttention과 vLLM이다.

자주 묻는 질문

관련 AI 소식