로컬 AI 런타임에서 모델 사본이 중복으로 로드되는 원인은 무엇인가?

서로 분리된 프로세스, 복제본, 세션 또는 디바이스 컨텍스트가 하나의 로드된 가중치 할당을 공유하지 못하면 모델의 중복 복사본이 나타납니다.

홈 AI 서버에 웹 UI, 백그라운드 워커, 음성 서비스, 문서 인덱서 또는 두 번째 API 엔드포인트를 추가한 후 예상 RAM 또는 VRAM의 거의 두 배가 사용될 수 있습니다. 디스크의 모델 파일은 하나뿐이어도 여러 런타임 객체가 독립적인 가중치, 변환된 텐서, 사전 패킹된 커널, 캐시 및 디바이스 컨텍스트를 보유할 수 있습니다. 일부 중복은 우발적으로 발생하지만, 동시성, 격리 또는 병렬 실행을 위해 의도적으로 생성되는 복제본도 있습니다.

하나의 모델 파일이 여러 개의 독립적인 런타임 객체를 만들 수 있습니다

동일한 경로에서 로드한다고 해서 두 애플리케이션이 메모리에 있는 하나의 모델을 참조한다는 의미는 아닙니다. 각 런타임 인스턴스가 체크포인트를 파싱하고 자체 텐서를 할당할 수 있습니다.

Google Cloud의 추론 가이드는 프로세스마다 또는 가상 머신마다 모델 복사본 하나를 로드하는 구성을 구분합니다.

워커 수가 증가할 때 메모리가 모델 크기만큼씩 증가한다면 주요 원인은 인스턴스 복제입니다. 증가 폭이 더 작다면 워커별 캐시, 메모리 할당자 또는 실행 컨텍스트일 가능성이 높습니다.

웹 서버와 작업 워커는 별도의 프로세스를 시작하는 경우가 많습니다

프론트엔드 서버, 큐 소비자, 스케줄러, 전사 서비스 및 RAG 워커가 하나의 Compose 스택에 속해 있어도 각각 모델 로더를 임포트할 수 있습니다.

프로세스 격리를 사용하면 각 서비스가 자체 주소 공간을 갖습니다. CPU 페이지는 운영 체제 메커니즘을 통해 공유되는 경우가 있지만, 일반적인 프레임워크 객체와 GPU 할당은 자동으로 하나의 공유 모델 서비스가 되지 않습니다.

중복은 프로세스 ID와 서비스 경계를 따라 발생합니다. 컨테이너 하나를 중지했을 때 모델 복사본 하나에 해당하는 메모리가 해제된다면, 해당 컨테이너는 중앙 런타임으로 요청을 전달하기만 한 것이 아닙니다.

서빙 복제본은 설계상 개별 복사본입니다

오토스케일링 시스템은 더 많은 복제본을 시작해 처리량을 높입니다. 복제본은 다른 워커가 바쁠 때 요청을 처리할 수 있는 독립적인 워커입니다.

Ray Serve는 복제본을 별도의 액터 프로세스에서 실행되는 개별 복사본으로 정의합니다.

트래픽 급증이나 오토스케일러 이벤트에 맞춰 메모리가 증가한다면 이는 누수가 아니라 의도적인 복제입니다. 추가 복제본이 축소되는 데 시간이 걸리더라도 원인은 선택한 동시성 모델입니다.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

여러 추론 세션이 초기화 객체와 사전 패킹된 가중치를 중복할 수 있습니다

애플리케이션은 서로 다른 스레드, 엔드포인트, 프로필 또는 실행 제공자를 위해 하나의 프로세스 안에서 여러 세션을 생성할 수 있습니다.

ONNX Runtime은 별도의 세션이 메모리 오버헤드를 추가하기 때문에 세션 간에 할당자, 초기화 객체 및 사전 패킹된 가중치를 공유하는 방법을 문서화하고 있습니다.

하나의 프로세스가 여러 세션 객체를 보유하고 각 세션이 초기화될 때 메모리가 증가한다면 중복 상태는 컨테이너 간이 아니라 애플리케이션 내부에 존재합니다.

포킹이 가속기 가중치 공유를 보장하지는 않습니다

부모 프로세스가 워커를 만들기 전에 모델을 로드하면 copy-on-write를 통해 CPU 페이지를 공유하는 것처럼 보일 수 있습니다. 그러나 가속기 초기화와 변경 가능한 런타임 상태는 이러한 가정을 복잡하게 만듭니다.

PyTorch의 멀티프로세싱 가이드는 텐서가 프로세스 간 공유 메모리 메커니즘을 사용할 수 있다고 설명하지만, 공유하려면 명시적이고 호환되는 설계가 필요합니다.

CPU 체크포인트 페이지가 공유되고 있더라도, 워커가 모델을 GPU로 옮기거나 가중치를 변경하거나 캐시를 구축하거나 spawn 이후 초기화하면 새 복사본을 할당할 수 있습니다.

별도의 CUDA 컨텍스트는 프로세스별 디바이스 상태를 추가합니다

하나의 GPU를 사용하는 두 프로세스는 일반적으로 특수한 공유 아키텍처를 사용하지 않는 한 서로 별도의 CUDA 컨텍스트를 통해 작동합니다.

NVIDIA는 여러 CUDA 애플리케이션 프로세스가 일반적으로 메모리 오버헤드를 동반하는 여러 컨텍스트를 생성한다고 설명합니다.

컨텍스트 오버헤드 자체가 모델 전체의 두 번째 복사본은 아니지만, 중복된 가중치, 커널, 워크스페이스 및 캐시와 함께 발생할 수 있습니다. 따라서 체크포인트 크기보다 작은 메모리 증가도 프로세스 중복에서 비롯될 수 있습니다.

하나의 GPU에서 두 런타임 인스턴스가 메모리를 독립적으로 예약합니다

대시보드가 모델 서버 하나를 시작하는 동시에 자동화 서비스가 동일한 체크포인트와 디바이스를 가리키는 또 다른 서버를 시작할 수 있습니다.

vLLM은 GPU 메모리 사용률이 인스턴스별 제한이라고 문서화하고 있으며, 하나의 GPU 용량을 두 인스턴스가 나누어 사용하는 예를 제시합니다.

각 엔드포인트에 자체 리스너, 로그, 스케줄러 및 KV 캐시가 있다면 두 프로세스는 독립적인 추론 엔진입니다. 공유 모델 디렉터리는 중복 다운로드를 방지할 뿐, 중복 런타임 할당을 방지하지는 않습니다.

리로드로 인해 기존 프로세스가 새 프로세스와 함께 남아 있을 수 있습니다

핫 리로더, 슈퍼바이저, 롤링 업데이트, 비정상적인 종료 및 상태 확인에 따른 재시작은 기존 워커가 모델을 해제하기 전에 대체 워커를 시작할 수 있습니다.

이 원인은 시작 시간이 서로 다른 거의 동일한 프로세스 두 개가 일시적 또는 지속적으로 나타나는 형태로 확인됩니다. 요청은 새 프로세스에만 전달되더라도 기존 프로세스가 RAM 또는 VRAM을 계속 점유할 수 있습니다.

ZimaSpace의 AI 런타임 상태를 모델 파일과 분리해야 하는 이유에 관한 글은 그 경계를 설명합니다. 하나의 체크포인트 캐시가 여러 배포에서 사용될 수 있지만, 로드된 복사본의 수는 여전히 서비스 토폴로지에 의해 결정됩니다.

FAQ

디스크에 모델 파일이 하나뿐이면 RAM에도 복사본이 하나뿐인가요?

아니요. 여러 프로세스나 세션이 동일한 파일을 독립적으로 읽고 자체 텐서, 캐시 및 실행 상태를 할당할 수 있습니다.

추가된 모든 복사본이 메모리 누수인가요?

아니요. 복제본, 텐서 병렬 워커, 폴백 런타임 및 격리된 서비스는 의도적으로 추가 상태를 할당할 수 있습니다. 누수는 해당 상태를 사용하는 활성 런타임 객체가 없는데도 계속 증가합니다.

컨테이너가 하나의 GPU 모델을 자동으로 공유할 수 있나요?

아니요. 컨테이너는 동일한 디바이스와 파일에 액세스할 수 있지만, 로드된 모델 할당 하나를 재사용하려면 공유 서빙 프로세스 또는 명시적인 프로세스 간 설계가 필요합니다.