호스트에서 사용 가능한 메모리가 있다고 표시되는데도 컨테이너화된 AI 모델이 재시작하는 이유

에바 왕

IceWhale author

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

Why Do Containerized AI Models Restart Even When the Host Reports Free Memory? - Zima Store Online

컨테이너화된 AI 모델은 호스트에 사용 가능한 메모리가 남아 있어도 재시작될 수 있습니다. 컨테이너의 cgroup, 가속기 또는 감독자 제한이 시스템 전체 RAM 보기보다 더 좁기 때문입니다.

홈 서버 대시보드에는 사용 가능한 기가바이트 단위의 메모리가 표시되는데도 추론 컨테이너가 사라졌다가 새 프로세스 ID로 다시 나타날 수 있습니다. 컨테이너가 자체 메모리 한도에 도달하거나, 메모리 회수 중 상태 확인에 실패하거나, GPU 메모리를 모두 사용하거나, 메모리 할당 오류 후 종료될 수 있습니다. 그러면 재시작 정책이 이 로컬 장애를 겉보기에는 자발적인 모델 재시작으로 바꿉니다.

컨테이너의 메모리 경계는 호스트와 다릅니다

Linux 제어 그룹은 선택한 프로세스 그룹의 메모리를 추적하고 제한합니다. 관련 없는 호스트 RAM이 커널에 남아 있어도 컨테이너는 memory.max 또는 런타임 제한에 도달할 수 있습니다. 따라서 시스템 전체의 사용 가능 메모리 수치는 해당 서비스에 적용되는 할당 경계를 나타내지 않습니다.

cgroup 메모리 회계에 대한 자세한 설명은 제어 그룹에 부과되는 익명 메모리, 매핑된 파일, 캐시를 구분합니다. 이러한 회계 방식은 디스크에서 매핑된 가중치, 임시 모델 버퍼, 페이지 캐시가 단순한 프로세스 RSS 보기에서는 더 작아 보여도 컨테이너 예산을 소모할 수 있는 이유를 보여줍니다.

제한은 중첩될 수도 있습니다. 모델 컨테이너가 compose 서비스, systemd 슬라이스, 가상 머신 또는 오케스트레이션 그룹 안에 있을 수 있습니다. 가장 좁은 활성 경계가 물리적 호스트가 전역적으로 메모리를 모두 소진하기 전에 메모리 회수 또는 메모리 부족 종료를 일으킬 수 있습니다.

메모리 압박은 OOM 종료 전에 상태 확인을 멈추게 할 수 있습니다

제한에 가까워지면 커널은 캐시를 회수하고 메모리를 검색하며 할당을 제한할 수 있습니다. 모델은 계속 실행 중이어도 상태 확인에 응답하기에는 너무 느려질 수 있으며, 이로 인해 감독자가 모델을 종료하고 컨테이너 수준의 OOM 종료를 기록하지 않은 채 대체 인스턴스를 시작할 수 있습니다.

압력 정체 정보 프레임워크는 사용률만 확인하는 대신 작업이 메모리, CPU 또는 I/O 압력으로 대기하면서 손실한 시간을 측정합니다. 압력 정체 정보는 적극적인 메모리 회수 중에 사용 가능한 바이트 수와 서비스 응답성이 서로 다를 수 있는 이유를 설명합니다.

AI 로딩은 급격한 피크를 만듭니다. 역직렬화 과정에서 압축된 가중치와 압축 해제된 가중치가 일시적으로 함께 메모리에 유지될 수 있고, 양자화는 작업 공간을 할당할 수 있으며, 병렬 작업자는 버퍼를 복제할 수 있습니다. 따라서 로드 완료 후의 안정적인 메모리 사용량만으로는 실패한 상태 확인과 겹치는 짧은 피크를 과소평가하게 됩니다.

GPU 장애와 재시작 정책은 호스트 OOM처럼 보일 수 있습니다

호스트 RAM 지표에는 일반적으로 전용 VRAM이 포함되지 않습니다. 가중치, KV 캐시, 커널 및 다른 작업이 가속기를 점유하고 있어 모델의 GPU 할당이 실패할 수 있으며, 이때 호스트는 시스템 메모리가 충분하다고 계속 보고하는 동안 애플리케이션 오류로 종료될 수 있습니다.

리소스 관리 지침은 컨테이너 메모리 제한과 노드 전체의 메모리 부족을 구분하며, 제한은 대시보드의 사용 가능 메모리 레이블이 아니라 런타임과 커널이 적용한다고 설명합니다. 따라서 재시작은 메모리 측정 자체가 아니라 워크로드의 재시작 정책에 따라 결정됩니다.

새 컨테이너 ID가 생성될 때마다 OOM 이벤트가 발생했다고 가정하는 것이 오류의 경계입니다. 이미지 업데이트, 감시자 시간 초과, 수동 재배포, 장치 재설정, 애플리케이션 충돌도 동일한 표면 증상을 만듭니다. 메모리를 원인으로 판단하기 전에 종료 이유, 커널 로그, cgroup 이벤트, GPU 오류가 서로 일치하는지 확인해야 합니다.

-15% OFF

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

Single board computer zimaboard2

모든 메모리 경계에서 종료 이유를 상호 연관시키세요

컨테이너 메모리.current, memory.max, memory.events, 프로세스 RSS 및 매핑된 파일, 호스트 MemAvailable, 압력 정체 누적값, GPU 메모리, 상태 확인 지연 시간, 프로세스 종료 코드, 감독자 재시작 횟수를 하나의 시간 기준으로 기록하면서 모델 로드를 한 번 재현하세요.

컨테이너 간 경합을 맥락으로 활용한 다음, 더 높은 컨테이너 제한, 비활성화된 재시작 정책, 경쟁하는 가속기 작업이 없는 조건에서 동일한 모델로 반복하세요. 실행마다 경계를 하나만 변경해야 성공적인 재시작이 원래 장애를 가리지 않습니다.

제한을 변경하기 전에 이벤트를 cgroup OOM, 전역 OOM, GPU 할당 실패, 상태 확인에 의한 종료 또는 애플리케이션 종료로 분류하세요. 피크가 정상적인 것이라면 여유 공간을 확보하고, 상태 확인이 메모리를 회수 중인 정상 모델을 종료한다면 실제 멈춤을 가리지 않는 범위에서 상태 확인 타이밍을 조정하세요.