3장: PagedAttention과 vLLM

이 장에서 배우는 것

• OS 가상 메모리와 PagedAttention의 대응 관계
• 논리적 블록에서 물리적 블록으로의 매핑 원리
• 메모리 낭비를 4% 미만으로 줄이는 메커니즘
• vLLM의 아키텍처와 핵심 설계 결정
• Automatic Prefix Caching(APC)의 동작 방식
• 계층적 KV 캐시: GPU에서 CPU, 네트워크까지

문제 재정의: 메모리 관리의 실패

2장에서 확인한 핵심 문제를 다시 정리합니다. 기존 추론 시스템은 요청이 들어오면 최대 시퀀스 길이에 해당하는 KV 캐시 메모리를 연속된 공간에 미리 할당합니다. 이 방식에는 세 가지 구조적 비효율이 있습니다.

1. 예약 낭비: 실제 생성 길이를 예측할 수 없어 최대치를 예약
2. 내부 단편화: 할당 단위와 실제 사용량의 불일치
3. 외부 단편화: 요청의 생성과 소멸이 반복되며 빈 공간이 조각남

이 문제는 컴퓨터 과학에서 이미 오래전에 해결된 문제입니다. 바로 운영체제의 메모리 관리에서요.

OS 가상 메모리에서의 영감

현대 운영체제는 프로세스에 연속된 물리 메모리를 할당하지 않습니다. 대신 가상 메모리(Virtual Memory) 시스템을 통해 논리적으로는 연속된 주소 공간을 제공하면서, 물리적으로는 비연속적인 페이지(Page) 단위로 메모리를 관리합니다.

PagedAttention은 이 아이디어를 KV 캐시 관리에 그대로 적용합니다. UC Berkeley의 연구팀이 2023년에 발표한 이 기법은, KV 캐시를 고정 크기의 블록으로 나누어 비연속적으로 저장하고 블록 테이블로 매핑하는 방식입니다.

PagedAttention의 동작 원리

블록 기반 저장

KV 캐시를 연속된 하나의 텐서가 아닌, 고정 크기(보통 16토큰)의 블록(Block) 단위로 분할합니다. 각 블록은 GPU 메모리의 어디에든 위치할 수 있으며, 반드시 연속적일 필요가 없습니다.

기존 방식 (연속 할당):
  요청 A: [████████████████________________]  (16토큰 사용, 32토큰 할당)
  
PagedAttention (블록 할당, 블록 크기 = 4토큰):
  요청 A: 블록0[████] → 블록3[████] → 블록7[████] → 블록2[████]
                                                        (16토큰 사용, 16토큰 할당)

블록 테이블

각 요청은 **블록 테이블(Block Table)**을 가집니다. 이 테이블은 논리적 블록 번호를 물리적 블록 번호로 매핑합니다.

요청 A의 블록 테이블:
  논리 블록 0 → 물리 블록 7
  논리 블록 1 → 물리 블록 2
  논리 블록 2 → 물리 블록 15
  논리 블록 3 → 물리 블록 9  (마지막 블록: 2/4 슬롯 사용)

Attention 연산 시, 커스텀 CUDA 커널이 블록 테이블을 참조해 물리 블록에서 KV 텐서를 수집(Gather)하고 연산을 수행합니다. 이 과정이 기존의 연속 텐서 연산보다 약간의 오버헤드를 추가하지만, 메모리 효율의 이득이 압도적으로 큽니다.

동적 블록 할당

새 토큰이 생성되어 현재 블록이 가득 차면, 비어 있는 물리 블록 하나를 새로 할당합니다. OS의 페이지 폴트(Page Fault)와 유사한 메커니즘입니다.

메모리 낭비 분석

PagedAttention에서 메모리 낭비는 오직 마지막 블록의 내부 단편화에서만 발생합니다. 블록 크기가 16토큰일 때, 한 요청의 마지막 블록에서 평균 8토큰(블록의 절반)이 낭비됩니다.

평균 시퀀스 길이가 2,000토큰이라면 낭비율은 약 0.4%에 불과합니다. vLLM 논문에서 보고한 4% 미만이라는 수치는 다양한 워크로드를 종합한 결과입니다.

결과적으로, 동일한 GPU 메모리에서 2-4배 더 많은 요청을 동시에 처리할 수 있습니다.

vLLM 아키텍처

vLLM은 PagedAttention을 구현한 오픈소스 추론 엔진으로, 현재 LLM 서빙의 사실상 표준으로 자리 잡았습니다.

핵심 구성 요소

• Scheduler: 요청의 우선순위를 정하고 배치를 구성합니다. Continuous Batching(4장에서 상세히 다룸)을 기반으로 iteration-level 스케줄링을 수행합니다.
• Block Manager: 물리 블록의 할당, 해제, 매핑을 관리하는 핵심 컴포넌트입니다. OS의 메모리 관리자에 해당합니다.
• PagedAttention Kernel: 블록 테이블을 참조해 비연속 KV 블록에서 Attention 연산을 수행하는 커스텀 CUDA 커널입니다.

Copy-on-Write 메커니즘

Beam Search나 Parallel Sampling처럼 하나의 프롬프트에서 여러 출력을 생성하는 경우, 입력 부분의 KV 캐시를 복사하지 않고 블록을 공유합니다. 공유 중인 블록에 쓰기가 필요할 때만 복사본을 만드는 Copy-on-Write(CoW) 전략을 사용합니다.

Beam 1: [블록A] → [블록B] → [블록C] → [블록D_beam1]
                              ↑ 공유
Beam 2: [블록A] → [블록B] → [블록C] → [블록E_beam2]
 
블록 A, B, C는 공유 (참조 카운트 = 2)
블록 D, E는 각 Beam의 고유 블록

이를 통해 Beam Search에서 KV 캐시 메모리를 최대 55%까지 절감할 수 있습니다.

Automatic Prefix Caching (APC)

vLLM의 **Automatic Prefix Caching(APC)**은 서로 다른 요청들 사이에서 공통된 프롬프트 접두사의 KV 캐시를 공유하는 기능입니다.

실제 서비스에서 많은 요청이 동일한 시스템 프롬프트를 공유합니다. 예를 들어 "당신은 친절한 AI 어시스턴트입니다..." 같은 시스템 프롬프트가 모든 요청에 붙는 경우, 이 부분의 KV 캐시를 매번 다시 계산하는 것은 낭비입니다.

요청 1: [시스템 프롬프트(500토큰)] + [사용자 질문 A]
요청 2: [시스템 프롬프트(500토큰)] + [사용자 질문 B]
요청 3: [시스템 프롬프트(500토큰)] + [사용자 질문 C]
 
APC 적용 시:
  공유 블록: 시스템 프롬프트 500토큰의 KV 캐시 (한 번만 계산)
  개별 블록: 각 사용자 질문의 KV 캐시만 새로 계산

APC는 블록 단위로 해시를 계산해 동일한 내용의 블록을 자동으로 감지하고 공유합니다. 이 기능은 6장의 Prefix Caching에서 더 깊이 다루겠습니다.

계층적 KV 캐시

GPU 메모리만으로 모든 KV 캐시를 감당할 수 없는 경우, 계층적 캐시(Hierarchical Cache) 전략이 필요합니다.

GPU to CPU 오프로딩

활성 요청의 KV 캐시는 GPU에, 일시 중단된 요청이나 자주 사용되지 않는 캐시는 CPU RAM으로 내립니다. PCIe 또는 NVLink를 통해 전송하며, 다시 필요할 때 GPU로 프리페치합니다.

LMCache와 분산 캐시

LMCache 같은 프로젝트는 여러 GPU 서버 간에 KV 캐시를 네트워크를 통해 공유합니다. Ceph 같은 분산 스토리지에 KV 캐시를 저장하고, 동일한 접두사를 가진 요청이 다른 서버에 도착해도 캐시를 재활용할 수 있습니다.

실제 성능 영향

vLLM의 PagedAttention이 가져온 성능 개선을 요약합니다.

이 수치는 모델 정확도의 손실 없이 달성되는 순수한 시스템 최적화입니다. PagedAttention의 블록 기반 Attention 커널이 기존 연속 텐서 대비 약간의 연산 오버헤드를 추가하지만, 메모리 효율 개선으로 인한 배칭 증가 효과가 이를 압도합니다.

정리

이 장에서는 PagedAttention의 원리와 vLLM의 아키텍처를 분석했습니다.

• PagedAttention은 OS 가상 메모리의 페이징 기법을 KV 캐시에 적용해, 비연속적 블록 저장과 동적 할당을 가능하게 합니다
• 메모리 낭비를 4% 미만으로 줄여 동일 GPU에서 2-4배 더 많은 요청을 동시 처리합니다
• Copy-on-Write로 Beam Search 시 블록을 공유하고, APC로 공통 접두사의 KV 캐시를 재활용합니다
• 계층적 캐시 전략으로 GPU 메모리의 한계를 넘어 대규모 서빙이 가능합니다

다음 장에서는 이 메모리 효율의 개선을 처리량으로 연결하는 핵심 기법인 Continuous Batching을 다룹니다. 정적 배칭의 한계와 iteration-level 스케줄링이 어떻게 GPU 활용률을 극대화하는지 알아보겠습니다.