GPU 메모리 단편화가 로컬 AI 모델을 차단할 수 있는 이유

에바 왕기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

GPU 메모리 단편화는 사용 가능한 용량이 런타임의 다음 할당 패턴을 충족할 수 없는 영역으로 나뉘어 있을 때 로컬 AI 모델의 실행을 막을 수 있습니다.

이 문제는 모델을 전환하거나, 컨텍스트 길이를 변경하거나, 이미지 및 언어 워크로드를 함께 실행하거나, 임시 텐서의 크기가 커졌다 줄어드는 요청을 처리한 후에 자주 나타납니다. 모니터링에는 사용하지 않은 VRAM이 표시되더라도, 할당자는 기존 블록을 해제하거나 재구성하지 않고는 대형 워크스페이스, 모델 샤드 또는 KV 캐시 확장을 배치하지 못할 수 있습니다. 아래에서는 실제 용량 부족과 할당자 단편화를 구분하고, 런타임을 재시작하면 같은 모델이 일시적으로 다시 적재될 수 있는 이유를 설명합니다.

전체 여유 VRAM이 사용 가능한 할당 공간과 같은 것은 아닙니다

메모리 모니터는 전체 용량을 보여주지만, 할당자는 자신이 관리하는 블록과 가상 매핑을 통해 요청을 충족해야 합니다. 여러 개의 작은 여유 영역을 합치면 요청 크기보다 클 수 있어도, 연속 할당 규칙에서는 사용할 수 없을 수 있습니다.

LLM 운영 분석에서는 KV 캐시와 가변 텐서로 인해 다음 요청보다 작은 빈 공간이 생길 때 나타나는 이러한 여유 메모리 불일치를 설명합니다. 따라서 표시되는 OOM은 전체 바이트 수뿐 아니라 메모리 배치와도 관련이 있습니다.

드라이버와 프레임워크는 디바이스 여유 메모리, 예약 메모리, 할당 메모리, 비활성 메모리를 서로 다르게 보고할 수도 있습니다. 한 가지 대표 수치만 믿기보다 런타임 할당자의 관점과 디바이스 수준 사용량을 비교하세요.

변하는 텐서 크기는 시간이 지나면서 빈 공간을 만듭니다

AI 워크로드는 프롬프트, 배치, 이미지 크기, 어텐션 워크스페이스, 임시 변환을 위해 서로 다른 크기의 텐서를 반복해서 할당하고 해제합니다. 캐싱 할당자는 블록을 재사용하기 위해 보관하는데, 이를 매번 드라이버에 반환하는 비용이 크기 때문입니다.

GMLake 연구에 따르면 불규칙한 할당은 분할 기반 메모리 풀의 성능을 저하시키고 대형 모델에서 상당한 단편화를 만들 수 있습니다. 동일한 크기를 재사용하는 것은 효율적이지만, 크기가 맞지 않는 블록을 반복해서 분할하고 병합하는 작업은 더 어렵습니다.

모델을 전환하는 홈 서버는 특히 취약합니다. 언어, 확산, 비전, 음성 런타임이 동일한 GPU에서 서로 매우 다른 형태의 블록을 요청하기 때문입니다.

메모리 누수가 없어도 단편화는 누적될 수 있습니다. 모든 할당이 결국 풀로 반환되더라도 풀의 구조가 다음 워크로드와 잘 맞지 않는 상태로 남을 수 있습니다.

증가하는 KV 캐시는 추론 단편화를 동적으로 만듭니다

LLM 가중치는 로드된 후 비교적 안정적이지만, KV 캐시는 활성 사용자 수, 프롬프트 길이, 생성된 토큰 수에 따라 증가합니다. 또한 요청마다 종료 시점이 달라 고르지 않은 영역이 해제됩니다.

PagedAttention은 최종 시퀀스 길이를 알 수 없는 상태에서 하나의 큰 연속 영역을 예약하는 대신, 요청 상태를 더 작은 블록에 저장하여 KV 캐시 단편화를 줄이도록 설계되었습니다.

이 문제는 프레임워크의 일반 텐서 할당자에서 발생하는 단편화와는 다르지만, 두 문제가 동시에 발생할 수 있습니다. 페이징된 KV 관리자는 모델 워크스페이스나 다른 프로세스가 소유한 할당을 자동으로 압축할 수 없습니다.

ZimaSpace의 동시 컨텍스트 관련 설명은 여러 대화가 동시에 확장될 때 한 명의 사용자에게는 맞던 모델이 어떻게 메모리 한계를 넘을 수 있는지 보여줍니다.

-15% OFF

예약된 메모리는 문제를 누수처럼 보이게 만들 수 있습니다

프레임워크 할당자는 이후 요청을 빠르게 처리하기 위해 해제된 블록을 보관하는 경우가 많습니다. 디바이스 도구는 현재 모델이 해당 블록 모두에 활성 텐서를 보유하고 있지 않더라도, 이를 프로세스가 사용 중인 메모리로 집계합니다.

실용적인 OOM 가이드는 예약 메모리와 활성 모델 및 캐시 요구량을 구분합니다. 둘 사이의 큰 차이는 재사용 가능한 할당자 블록, 단편화 또는 현재 상태보다 피크 사용량이 더 높았던 워크로드를 의미할 수 있습니다.

캐시를 비우면 일부 블록이 드라이버로 반환될 수 있지만, 활성 가중치, 현재 사용 중인 KV 상태, 다른 프로세스의 컨텍스트 또는 다음 연산에 필요한 워크스페이스까지 해제할 수는 없습니다.

안정적인 할당 형태와 페이징은 반복되는 실패를 줄입니다

모델 하나, 고정된 컨텍스트 제한, 고정된 배치 크기, 경쟁하는 AI 서비스가 없는 환경에서 실패를 재현하세요. 프로세스 수준의 할당 및 예약 메모리, 디바이스 수준의 여유 메모리, 가장 큰 요청 크기, OOM 직전에 실행된 워크로드 순서를 기록하세요.

vAttention은 가상 메모리 매핑을 사용하여 연속적인 가상 KV 공간과 물리적 할당을 분리합니다. 이와 유사한 페이징 및 분할 할당 방식은 하나의 물리적으로 연속된 영역에 대한 의존성을 줄입니다.

홈 서버에서 사용할 수 있는 실용적인 제어 방법으로는 VRAM 여유 공간 확보, 모델 전환 제한, 안정적인 컨텍스트 및 배치 상한 설정, 하나의 런타임을 통한 서비스 조정, 사용자 요청이 실패한 후가 아니라 유지보수 중에 단편화된 프로세스 재시작 등이 있습니다.

깨끗하게 재시작한 후에도 모델이 적재되지 않는다면, 주요 문제는 누적된 단편화보다 실제 용량 부족일 가능성이 높습니다. 모델 크기, 양자화 용량, 컨텍스트, 배치 또는 경쟁하는 할당을 줄이세요.

기술 및 AI 허브

더 읽어보기

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.