동시 로컬 AI 요청에서 페이지드 어텐션은 KV 캐시를 어떻게 관리하나요?

Paged Attention은 각 요청에서 증가하는 토큰 상태를 독립적으로 할당하고 재활용할 수 있는 고정 크기 블록에 매핑하여 동시 KV 캐시를 관리합니다.

이는 홈 AI 서버에서 중요합니다. 활성 채팅, 문서 작업, 에이전트는 컨텍스트 길이가 같지 않고 동시에 끝나는 경우도 드물기 때문입니다. 연속 예약 전략은 이러한 가변 시퀀스 주변의 제한된 가속기 메모리를 낭비합니다. 페이징은 메모리 배치를 변경하여 스케줄러가 사용 가능한 용량을 더 밀도 높게 활용할 수 있도록 합니다.

동시 요청은 서로 다른 속도로 증가하는 KV 캐시를 만듭니다

활성 오토리그레시브 요청은 처리한 토큰에 대한 키 및 값 상태를 필요로 합니다. 한 채팅은 100토큰 후 끝날 수 있지만 다른 채팅은 수천 토큰까지 계속될 수 있으므로, 배치가 시작될 때 필요한 메모리 양을 정확히 알 수 없습니다.

PagedAttention 논문은 동적으로 증가하는 KV 캐시 메모리를 서빙 병목으로 지목하며, 비효율적인 할당이 배칭을 제한한다고 설명합니다.

여러 사용자나 백그라운드 에이전트가 있는 홈 서버에서는 이러한 변동성 때문에 큰 여유 메모리가 있어도 서로 다른 크기의 활성 할당이 많이 생깁니다.

고정된 연속 예약은 가변 시퀀스 주변의 메모리를 낭비합니다

단순한 런타임은 최대 길이를 기준으로 요청마다 하나의 큰 연속 영역을 예약할 수 있습니다. 짧은 요청은 예약 영역 내부에 사용하지 않는 공간을 남기고, 긴 요청은 재할당이나 과도한 사전 할당이 필요할 수 있습니다.

vAttention은 페이징의 최초 동기를 다음과 같이 요약합니다. KV를 미리 예약하면 내부 단편화가 발생합니다. 낭비되는 메모리는 동시에 활성 상태로 유지할 수 있는 요청 수를 줄입니다.

실제로는 사용 중인 토큰 상태의 총량이 사용 가능한 VRAM보다 적어 보이는데도 메모리 부족 한도에 도달하거나 최대 배치 크기가 작아지는 현상으로 나타납니다.

PagedAttention은 KV 상태를 고정 크기 블록으로 나눕니다

PagedAttention은 물리적으로 연속된 하나의 요청 버퍼를 논리적 블록 시퀀스로 대체합니다. 더 많은 토큰이 들어오면 런타임은 공유 풀에서 물리 블록을 추가로 할당합니다.

vLLM은 KV 블록이 비연속적인 물리 메모리에 위치할 수 있다고 설명합니다. 블록 테이블은 요청의 논리적 토큰 순서를 해당 물리 위치에 매핑합니다.

모델은 여전히 올바른 시퀀스에 어텐션을 수행합니다. 간접 참조는 메모리 배치를 변경할 뿐 대화의 의미적 순서를 바꾸지 않습니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

요청이 끝나면 해제된 블록은 공유 풀로 돌아갑니다

한 요청이 완료되면 공유되지 않는 블록을 즉시 해제하여 다른 활성 요청이나 새로 수락된 요청이 재사용할 수 있습니다. 서버는 거대한 전체 메모리 영역이 비워질 때까지 기다릴 필요가 없습니다.

NVIDIA의 추론 스택은 서빙 리소스로서의 KV 캐시 용량을 제공하며, 이 용량은 가중치 및 런타임 작업 공간과 균형을 맞춰야 합니다.

이러한 블록 단위 재활용은 요청 길이가 불규칙한 홈 환경에서 유용합니다. 한 사람은 짧은 스마트홈 질문을 하고, 다른 사람은 긴 문서 도우미를 실행하며, 백그라운드 에이전트는 파일을 요약할 수 있기 때문입니다.

페이징은 각 토큰을 줄이는 것이 아니라 단편화를 줄여 동시성을 높입니다

PagedAttention은 한 토큰의 키 및 값 텐서 자체를 근본적으로 더 작게 만들지 않습니다. 주요 메모리 이점은 실제 시퀀스 증가량에 가깝게 할당하고, 유효한 경우 공유를 가능하게 하는 데서 나옵니다.

PyTorch의 분산 처리 지침은 모델 병렬 처리와 서빙 메모리 관리를 구분합니다. 페이징은 텐서 병렬 처리가 아니며 모델 가중치를 여러 GPU에 자동으로 분할하지도 않습니다.

모델 가중치가 이미 디바이스 메모리 대부분을 차지하고 있다면 페이징만으로 대규모 동시 처리를 위한 충분한 용량을 만들어낼 수는 없습니다. 페이징은 남아 있는 KV 영역의 활용도를 높입니다.

블록 관리에는 자체적인 오버헤드와 스케줄링 한계가 있습니다

이제 런타임은 블록 테이블, 참조 카운트, 할당 결정, 페이징된 레이아웃을 이해하는 어텐션 커널을 관리해야 합니다. 배치가 매우 작거나 지원되지 않는 하드웨어에서는 이점이 줄어들 수 있습니다.

ZimaSpace의 가족 단위 동시 사용과 KV 압박 관련 글은 사용자 관점의 한계를 보여줍니다. 메모리 효율이 중요한 이유는 대기열이 길어지기 전에 얼마나 많은 활성 컨텍스트가 공존할 수 있는지를 결정하기 때문입니다.

하나의 합성 배치만 사용하는 대신 여러 요청 길이와 도착 패턴을 테스트하세요. ZimaSpace의 슬라이딩 컨텍스트 윈도우와 KV 메모리 가이드는 유용한 비교 자료입니다. 윈도잉은 각 시퀀스가 유지하는 상태의 양을 바꾸는 반면, 페이징은 해당 상태가 할당되는 방식을 바꾸기 때문입니다. 활성 시퀀스 수, 사용 중인 KV 블록, 대기 시간, 선점 횟수를 기록하세요.

Hugging Face의 TGI 스케줄러 역시 동시 서빙에서 프리필과 디코드 스케줄링을 구분합니다. 페이징된 메모리는 스케줄러가 작업을 수락하는 데 도움을 주지만, 공정성과 지연 시간은 여전히 작업이 대기열에 배치되는 방식에 따라 달라집니다.