홈 AI의 컨텍스트 길이가 늘어나면 KV 캐시가 커지는 이유는 무엇인가요?

KV 캐시는 런타임이 여러 모델 레이어에서 유지되는 모든 토큰의 어텐션 키와 값을 저장하기 때문에 컨텍스트 길이에 따라 증가합니다.

짧은 홈 AI 프롬프트는 여러 사용자를 위한 메모리를 충분히 남길 수 있지만, 긴 문서나 긴 채팅 기록 또는 에이전트 추적 정보는 모델 파일 자체를 변경하지 않고도 훨씬 더 많은 작업 메모리를 사용할 수 있습니다. 캐시는 프롬프트 처리 중에 생성되기 시작하며 모델이 새 토큰을 생성하는 동안 계속 증가합니다. 캐시 크기는 레이어 수, 어텐션 아키텍처, 수치 정밀도, 동시 요청 수에도 영향을 받습니다. 아래 섹션에서는 토큰 하나에서 서버 전체의 메모리 한도에 이르기까지 캐시가 증가하는 과정을 살펴봅니다.

유지되는 토큰 하나마다 어텐션 상태가 추가됩니다

트랜스포머 추론 중에는 각 레이어가 이미 처리된 토큰에서 키 텐서와 값 텐서를 생성합니다. 런타임은 다음 토큰이 전체 시퀀스를 다시 계산하지 않고 이전 컨텍스트에 어텐션할 수 있도록 이러한 텐서를 유지합니다.

vLLM 연구는 효율적인 LLM 서빙을 위한 토큰별 KV 상태를 서빙 메모리의 주요 요구 사항으로 설명합니다. 새 토큰이 추가되면 새로운 캐시 항목이 생성되고, 이전에 유지된 항목은 이후 어텐션 단계에서 계속 사용할 수 있습니다.

따라서 캐시는 정적인 모델 가중치의 일부가 아니라 변경 가능한 요청 상태입니다. 동일한 모델을 더 긴 활성 대화와 함께 로드하면 메모리 사용량이 더 커집니다.

캐시 증가는 유지되는 시퀀스 길이에 대체로 비례합니다

고정된 모델 아키텍처와 캐시 정밀도에서는 유지되는 토큰 수를 두 배로 늘리면 해당 요청에 저장되는 KV 항목도 대략 두 배가 됩니다. 프롬프트와 생성된 답변은 모두 활성 시퀀스에 포함됩니다.

H2O는 KV 캐시가 시퀀스 길이와 배치 크기에 따라 확장되는 방식을 설명합니다. 추가되는 각 토큰이 캐시를 생성하는 모든 레이어에 키와 값을 추가하므로 관계는 대체로 선형으로 유지됩니다.

따라서 런타임 설정을 작은 컨텍스트에서 훨씬 큰 최대 컨텍스트로 변경하면 모델이 동일한 가중치를 사용하더라도 실제 메모리 한도가 달라질 수 있습니다.

최대 설정과 실제 사용량은 다릅니다. 일부 런타임은 필요할 때 캐시 블록을 할당하는 반면, 다른 런타임은 향후 증가를 보장하기 위해 더 큰 영역을 초기에 예약합니다.

모델 아키텍처에 따라 토큰당 바이트 수가 달라집니다

동일한 파라미터 수를 가진 두 모델이라도 레이어 수, 헤드 차원, 어텐션 헤드 수, 그룹 쿼리 어텐션 또는 멀티 쿼리 어텐션이 다를 수 있으므로 필요한 KV 메모리는 달라질 수 있습니다.

KIVI는 KV 캐시 정밀도를 연구하며, 키와 값을 더 적은 비트로 저장하면 피크 메모리를 크게 줄일 수 있음을 보여줍니다. 이 효과는 기본 모델 가중치를 축소하는 것이 아니라 요청 상태에 적용됩니다.

그룹 쿼리 및 멀티 쿼리 설계는 여러 쿼리 헤드에서 키-값 헤드를 공유하므로 전체 멀티 헤드 어텐션에 비해 토큰당 캐시 바이트 수를 줄일 수 있습니다. 그래도 레이어 수와 헤드 폭은 유지되는 상태의 크기를 계속 늘립니다.

따라서 유용한 추정치를 얻으려면 다른 모델에서 가져온 일반적인 토큰당 바이트 규칙이 아니라 정확한 모델 아키텍처와 런타임 캐시 형식을 사용해야 합니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

프리필 이후에도 생성된 토큰이 캐시를 계속 확장합니다

프롬프트 처리는 입력 컨텍스트에 대한 초기 캐시를 생성합니다. 이후 자기회귀 디코딩은 승인된 출력 토큰마다 상태를 추가하므로, 뒤에 생성되는 토큰이 전체 대화에 어텐션할 수 있습니다.

vAttention은 요청이 시작될 때 최종 출력 길이를 알 수 없기 때문에 동적 캐시 증가를 할당 문제로 다룹니다. 너무 많이 예약하면 메모리가 낭비되고, 너무 적게 예약하면 선점이나 확장 작업이 발생할 수 있습니다.

여유 있게 처리되는 프롬프트라도 긴 답변을 생성하는 동안 메모리 한도를 초과할 수 있습니다. 따라서 출력 제한은 응답 길이와 생성 시간을 관리할 뿐 아니라 메모리도 보호합니다.

동시 사용자는 각각의 컨텍스트 상태를 늘립니다

모델 가중치는 여러 요청에서 공유할 수 있지만, 각 활성 대화는 일반적으로 자체 토큰 기록과 KV 캐시를 가집니다. 같은 모델을 사용한다고 해서 긴 컨텍스트를 가진 사용자 5명이 하나의 범용 캐시를 공유하는 것은 아닙니다.

최근 KV 관리 연구는 요청별 예약을 메모리 효율성과 선점 위험 사이의 핵심 절충점으로 설명합니다. 출력 길이를 알 수 없기 때문에 결합된 피크 사용량은 단순한 사용자 수보다 예측하기 어렵습니다.

런타임이 정확한 프리픽스 매칭을 지원하면 공유 프롬프트 프리픽스의 캐시 상태를 재사용할 수 있는 경우도 있지만, 개인 채팅 기록과 서로 다른 출력은 여전히 별도의 분기를 만듭니다.

ZimaSpace의 하드웨어 가이드는 컨텍스트와 동시성을 모델 파일 외에 고려해야 하는 메모리 요구 사항으로 다룹니다. 따라서 한 명의 사용자만 테스트하면 가정용 어시스턴트에 필요한 RAM 또는 VRAM을 과소평가할 수 있습니다.

페이징, 양자화, 제거는 한도를 바꾸지만 원인은 바꾸지 않습니다

페이징 할당은 캐시 상태를 더 작은 블록으로 나누어 단편화를 줄이므로, 런타임이 가능한 모든 시퀀스에 대해 하나의 지나치게 큰 연속 영역을 예약할 필요가 없습니다.

PagedAttention은 블록 기반 할당을 제공하며, 캐시 양자화는 저장된 값 하나당 바이트 수를 줄이고 제거 정책은 선택한 이전 항목을 버립니다. 각 방법은 수용할 수 있는 컨텍스트의 양을 바꾸지만, 유지되는 어텐션 상태는 토큰이 누적될수록 계속 증가합니다.

제거나 슬라이딩 윈도우는 이전 토큰을 제거해 메모리를 제한할 수 있지만, 모델은 더 이상 일반적인 전체 컨텍스트 경로를 통해 제거된 상태에 어텐션할 수 없습니다. 압축과 선택적 유지는 품질 또는 워크로드에 따른 절충을 초래할 수도 있습니다.

실제 모델, 컨텍스트, 캐시 정밀도, 배치 크기, 사용자 수를 사용해 캐시 사용량을 측정하세요. 제거, 오프로딩, 재계산 또는 오류 없이 다른 토큰이나 요청을 수용할 수 없을 때 실제 한도에 도달합니다.

FAQ

컨텍스트 길이를 늘리면 모델 파일도 커지나요?

아니요. 모델 가중치는 그대로 유지됩니다. 추가 메모리는 활성 프롬프트와 생성된 토큰을 위해 생성되는 런타임 상태입니다.

최대 컨텍스트를 크게 설정하면 모든 KV 메모리가 즉시 할당되나요?

아니요. 할당 방식은 런타임에 따라 다릅니다. 일부 런타임은 용량을 초기에 예약하고, 페이징 시스템은 토큰이 수용될 때 블록을 할당합니다.

VRAM이 가득 차면 시스템 RAM에 KV 캐시를 저장할 수 있나요?

일부 런타임은 캐시 상태를 오프로딩하거나 이동할 수 있지만, 전송으로 인해 지연 시간이 늘어나며 소프트웨어 지원, 대역폭, 활성 어텐션 경로에 따라 달라집니다.