LLM의 메모리 낭비를 잡는 해법, 페이지드어텐션과 vLLM
컨텐츠 정보
- 조회 471
본문
GPT와 PaLM 같은 대형 언어 모델(Large Language Model, LLM)은 프로그래밍 도우미에서 범용 챗봇에 이르기까지 모든 것을 뒷받침하며 사람이 일하고 소통하는 방식을 바꿔놓고 있다. 그러나 문제가 있다. 이렇게 강력한 모델을 실행하는 것은 특히 클라우드에서 서비스 형태로 운영할 경우, 비용이 매우 높다는 점이다. 전통적인 키워드 검색보다 최대 10배 이상 비쌀 수 있다. 이 비용의 상당 부분은 LLM 제공 과정에서 발생하는 비효율적인 메모리 관리 때문이다.
숨은 메모리 괴물 ‘KV 캐시’
LLM의 핵심에는 트랜스포머(Transformer) 모델이 있다. 이 모델은 텍스트를 한 번에 한 토큰(단어)씩 생성한다. 이를 효율적으로 처리하려면 이전에 생성된 토큰들의 맥락을 기억해야 한다. 이 기억이 바로 키밸류(Key-Value, KV) 캐시에 저장된다. 쉽게 말해 KV 캐시는 대화에서 LLM이 활용하는 단기 기억 공간이라고 볼 수 있다.
문제는 이 KV 캐시의 크기가 매우 크다는 점이다. 요청마다 그 크기가 동적으로 늘었다 줄었다 하는데, 기존 시스템은 이를 보통 연속된 단일 메모리 블록에 저장한다. 이 방식은 2가지 큰 문제를 일으킨다.
메모리 단편화
- 내부 단편화 : 기존 시스템은 각 요청이 생성할 수 있는 대 출력 길이(예 : 2048토큰)를 가정하고, 그만큼의 큰 메모리 블록을 미리 할당한다. 그러나 실제로는 요청이 짧은 출력을 생성하는 경우가 많아, 예약된 메모리의 상당 부분이 사용되지 않고 낭비된다. 이로 인해 심각한 메모리 낭비가 발생한다.
- 외부 단편화 : 요청마다 필요한 메모리 블록 크기가 다르다 보니, GPU 메모리가 여기저기 잘게 쪼개져 쓸 수 없는 빈 공간이 흩어지게 된다. 이 때문에 전체적으로는 여유 메모리가 남아 있어도 새로운 요청을 수용하기가 어려워진다. 실제 조사에 따르면, 기존 시스템에서 KV 캐시 메모리의 실제 활용률은 20.4%~38.2%에 불과하며, 나머지는 사실상 낭비되고 있다.
메모리 공유 불가
병렬 샘플링(parallel sampling)이나 빔 서치(beam search) 같은 고급 디코딩 기법은 하나의 프롬프트에서 여러 출력을 동시에 생성한다. 따라서 이 경우에는 KV 캐시의 일부를 공유할 수 있는 여지가 있다. 그러나 기존 시스템에서는 각 시퀀스의 KV 캐시가 각각 독립된 연속 메모리 블록에 저장되기 때문에 이런 공유가 사실상 불가능하다.
이런 비효율성은 동시에 처리할 수 있는 요청 수, 즉 배치 크기를 크게 제한하고 결국 시스템의 처리량(초당 처리할 수 있는 토큰/요청 수)을 직접적으로 떨어뜨린다.
OS에서 영감을 얻은 ‘페이지드어텐션’
이 메모리 문제를 해결하기 위해 개발된 것이 페이지드어텐션(PagedAttention)이다. 페이지드어텐션의 핵심 아이디어는 사실 OS의 고전적인 기법인 가상 메모리(Virtual Memory)와 페이징(Paging)에서 영감을 얻었다. OS에 비유하자면 다음과 같다.
- KV 블록은 페이지와 같다. 연속된 메모리에 저장하는 대신, 페이지드어텐션은 각 시퀀스의 KV 캐시를 작고 고정된 크기의 KV 블록으로 나눈다. 각 블록은 일정 개수의 토큰에 대한 키와 값을 저장한다.
- 토큰은 바이트와 같다. KV 캐시 안의 개별 토큰들은 마치 한 페이지 안에 들어 있는 바이트처럼 동작한다.
- 요청은 프로세스와 같다. 각 LLM 요청은 하나의 프로세스처럼 관리되며, ‘논리적’ KV 블록이 GPU 메모리의 ‘물리적’ KV 블록에 매핑된다.
페이지드어텐션이 문제를 해결하는 방식
거의 ‘제로’에 가까운 단편화
KV 블록은 물리적 메모리에서 연속적으로 배치될 필요가 없기 때문에 페이지드어텐션은 요청에 따라 블록을 동적으로 할당할 수 있다. 이 방식 덕분에 메모리는 필요할 때만 할당되므로 내부 단편화가 사실상 사라지고, 모든 블록이 동일한 크기를 가지므로 외부 단편화 문제 역시 해결된다.
유연한 메모리 공유
페이지드어텐션은 서로 다른 시퀀스 간, 심지어는 다른 요청 간에도 KV 블록을 공유할 수 있게 한다. 예를 들어 병렬 샘플링이나 빔 서치 과정에서는 여러 출력이 동일한 초기 프롬프트의 KV 캐시를 공유할 수 있어 상당한 메모리를 절약할 수 있다. 또한 수정이 필요한 블록에 대해서는 카피 온 라이트(copy-on-write) 메커니즘(역시 OS에서 차용한 개념)을 적용해 불필요한 중복 없이 효율적으로 공유할 수 있다.
페이지드어텐션 기반의 고처리량 엔진 ‘vLLM’
페이지드어텐션을 기반으로 구축된 vLLM은 고처리량(High-throughput)을 목표로 설계된 LLM 서빙 시스템이다. vLLM은 블록 단위 메모리 관리(block-level memory management)와 페이지드어텐션과 긴밀히 연동되는 정교한 스케줄러를 활용한다.
vLLM의 주요 이점은 ▲KV 캐시 메모리 낭비가 사실상 제로에 가깝다는 점 ▲요청 내·요청 간 KV 캐시 공유가 유연하다는 점이다. 이 결과, vLLM은 패스터트랜스포머(FasterTransformer)나 오르카(Orca) 같은 최신 시스템 대비 2~4배 높은 처리량을 보여주면서도 지연 시간은 늘어나지 않는다. 이 개선 효과는 시퀀스가 길어지거나, 모델 규모가 커지거나, 디코딩 알고리즘이 복잡해질수록 더욱 두드러진다.
예를 들어 매개변수 130억(13B) 규모 LLM을 서빙할 때, vLLM은 출력 길이를 완벽히 안다고 가정한 오르카 오라클 버전보다 2.2배, 오르카 맥스(Max)보다 4.3배 더 많은 요청을 동시에 처리할 수 있다. 메모리 절감 효과도 크다. 병렬 샘플링에서는 6.1%~9.8%, 빔 서치에서는 37.6%~55.2%의 메모리를 절약한다.
LLM 서빙의 미래
OS 아이디어를 영리하게 차용한 페이지드어텐션과 vLLM은 LLM 서빙 효율성을 획기적으로 끌어올리고 있다. 이는 곧 클라우드 서비스 비용을 쉽게 절감할 수 있고, 사용자에게는 더 빠르고 즉각 반응하는 LLM 애플리케이션을 제공할 수 있음을 의미한다. 이는 중요한 병목 현상을 해소하는 게임 체인저이자, 차세대 LLM 기반 서비스를 가능하게 하는 핵심 동력이라 할 수 있다.
*Raul Leite는 레드햇의 수석 솔루션 아키텍트다.
dl-itworldkorea@foundryco.com
관련자료
-
링크
-
이전
-
다음






