슬라이딩 컨텍스트 창은 로컬 AI의 메모리 사용량을 어떻게 변화시키나요?

슬라이딩 컨텍스트 윈도우는 유지된 윈도우가 설정된 한도에 도달하면 오래된 토큰 상태를 제외하여 활성 어텐션 메모리를 제한합니다.

전체 인과 어텐션은 활성 시퀀스 전체의 키와 값을 유지하므로, 대화, 문서 또는 생성된 답변이 길어질수록 KV 메모리도 증가합니다. 슬라이딩 윈도우 어텐션은 이 관계를 바꿉니다. 각 토큰이 제한된 최근 영역에만 직접 어텐션하도록 하여, 롤링 저장을 지원하는 구현에서는 오래된 캐시 항목을 덮어쓰거나 생략할 수 있습니다. 따라서 모델은 더 예측 가능한 작업 집합으로 긴 스트림을 처리할 수 있지만, 폐기된 기록은 더 이상 동일한 직접 어텐션 경로를 통해 사용할 수 없습니다.

전체 어텐션은 활성 KV 기록을 계속 확장합니다

일반적인 전체 컨텍스트 추론에서는 유지되는 각 토큰이 모델 어텐션 계층 전반에 걸쳐 키 및 값 텐서에 기여합니다. 따라서 대화가 길어질수록 주소를 지정할 수 있는 상태로 유지해야 하는 캐시도 커집니다.

Mistral 7B는 긴 시퀀스를 처리하면서 추론 비용을 줄이는 방법으로 슬라이딩 윈도우 어텐션을 도입했습니다.

가중치 메모리는 대화 길이에 따라 변하지 않지만, KV 캐시와 사용자 및 임시 작업에 사용할 수 있는 런타임 메모리는 변합니다.

고정된 윈도우는 워밍업 후 캐시 증가를 제한할 수 있습니다

각 계층이 가장 최근의 토큰 윈도우만 유지한다면 새 토큰이 들어올 때 오래된 KV 항목이 활성 작업 집합에서 빠질 수 있습니다. 그러면 메모리는 전체 스트림 길이가 아니라 윈도우 크기에 따라 정해지는 상한에 가까워집니다.

Longformer는 모든 토큰 쌍이 아니라 선택한 주변 영역에 따라 계산량이 증가하는 로컬 윈도우 어텐션을 정식화했습니다.

롤링 KV 버퍼는 윈도우가 가득 찬 후 물리적 슬롯을 재사용할 수 있으므로, 장시간 이어지는 로컬 채팅이나 전사 스트림에서 메모리 사용량을 더욱 안정적으로 유지할 수 있습니다.

이러한 이점은 런타임이 실제로 윈도우 밖의 상태를 삭제하거나 덮어쓰는지에 따라 달라집니다. 로컬 어텐션을 사용하는 모델 아키텍처라고 해서 모든 서빙 엔진이 캐시를 동일한 방식으로 할당하는 것은 아닙니다.

여러 계층을 쌓으면 하나의 로컬 윈도우를 넘어 정보를 전달할 수 있습니다

한 계층의 토큰은 이전 계층의 최근 주변 영역을 읽습니다. 더 깊은 계층은 이미 이전 주변 영역의 정보가 혼합된 표현을 입력으로 받습니다.

Mistral 아키텍처는 이를 계층화된 수용 영역으로 설명합니다. 여러 트랜스포머 계층을 거치면 정보가 하나의 윈도우보다 더 멀리 전달될 수 있습니다.

간접적인 정보 전달은 오래된 모든 토큰에 대한 정확한 직접 접근을 유지하는 것과는 다릅니다. 모델은 제한 없는 전체 기록 조회 테이블이 아니라 변환된 표현을 받습니다.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

오래된 KV 상태를 삭제하면 모델이 직접 검색할 수 있는 정보가 달라집니다

초기의 토큰이 관련된 모든 어텐션 윈도우에서 벗어나면 이후 토큰은 일반적인 로컬 어텐션 경로를 통해 해당 토큰의 원래 키와 값에 어텐션할 수 없습니다.

StreamingLLM은 시퀀스가 캐시 크기를 초과한 후 단순한 최근 토큰 제거가 모델 동작을 저하시킬 수 있음을 보여줍니다.

어텐션 싱크, 전역 토큰, 요약, 검색 증강 또는 아키텍처별 하이브리드 계층을 사용하면 대부분의 캐시 메모리를 제한된 상태로 유지하면서 선택한 장거리 정보를 보존할 수 있습니다.

따라서 메모리 절약에는 의미론적 한계가 있습니다. 오래된 세부 정보는 요약하거나 다시 검색하거나, 일반적인 슬라이딩 영역 외부에 의도적으로 보존해야 할 수 있습니다.

윈도우 크기는 실제 런타임과 워크플로에서 테스트해야 합니다

윈도우 크기, KV 헤드 수, 헤드 차원, 계층 수, 정밀도, 배치 크기 및 활성 사용자 수를 기준으로 캐시 상한을 추정하세요. 그런 다음 이론적인 상한이 완전히 구현된다고 가정하지 말고 실제 할당자의 동작을 확인하세요.

ZimaSpace의 Kimi K3 분석은 긴 컨텍스트 메모리를 설명하면서 고정 상태와 토큰에 따라 증가하는 상태를 구분합니다. 어텐션 설계가 다르면 최대 컨텍스트를 비슷하게 표시하더라도 서로 다른 제한이 발생할 수 있습니다.

짧은 채팅, 윈도우보다 긴 스트림, 초반에 배치한 정보, 여러 동시 사용자 및 초기화 후 상태를 테스트하세요. 최대 메모리, 첫 토큰 지연 시간, 출력 속도, 초기 정보가 계속 사용 가능한지를 기록하세요.

더 작은 윈도우는 로컬 워크플로에서 보존해야 하는 정보를 제거하지 않으면서 안정성이나 동시성을 확보할 만큼의 메모리를 확보해 줄 때 유용합니다.

FAQ

슬라이딩 윈도우는 대화를 삭제하는 것과 같은가요?

아니요. 애플리케이션은 전체 대화 기록을 계속 저장할 수 있지만, 오래된 내용이 요약되거나 다시 검색되지 않는 한 모델은 최근 윈도우에만 직접 어텐션할 수 있습니다.

슬라이딩 윈도우 어텐션은 항상 일정한 메모리만 사용하나요?

하나의 시퀀스에 대한 어텐션 캐시 크기를 제한할 수는 있지만, 전체 메모리에는 여전히 가중치, 다른 계층, 활성 사용자, 임시 버퍼 및 런타임 예약 공간이 포함됩니다.

모델이 윈도우보다 오래된 사실을 기억할 수 있나요?

전달된 표현, 전역 어텐션, 요약, 검색 또는 애플리케이션 메모리를 통해 가능한 경우도 있지만, 원래 토큰 상태에 대한 직접 접근은 아키텍처에 의해 제한됩니다.