GPU 메모리가 가득 차면 로컬 AI 서비스가 CPU로 장애 조치할 수 있나요?

에바 왕

IceWhale author

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

Can a Local AI Service Fail Over to CPU When GPU Memory Is Full? - Zima Store Online

가능합니다. 하지만 안정적인 CPU 장애 조치는 GPU 메모리가 가득 차기 전에 설계해야 합니다. 대부분의 추론 프로세스는 예기치 않은 OOM에서 투명하게 복구되지 않습니다.

홈 AI 서버는 GPU에서 빠르게 응답하다가 더 긴 프롬프트, 더 큰 배치, 이미지 요청 또는 두 번째 모델이 남은 VRAM을 소모하면 문제가 발생할 수 있습니다. 시스템 RAM과 CPU가 유휴 상태여도 다음 메모리 할당이 실패할 수 있습니다. 요청이 계속 처리되는지는 런타임에 따라 달라집니다. 일부 런타임은 처음부터 가중치를 CPU에 배치할 수 있지만, 다른 런타임은 별도의 CPU 워커와 안전하게 재시도하는 라우터가 필요합니다.

CPU 오프로딩과 CPU 장애 조치는 서로 다른 문제를 해결합니다

CPU 오프로딩은 모델 배치 전략입니다. 선택한 레이어, 텐서 또는 파이프라인 구성 요소를 시스템 RAM에 두고 필요할 때 가속기로 이동하여 일반적인 요청에 필요한 VRAM을 줄입니다. CPU 장애 조치는 서비스 동작입니다. GPU 경로를 사용할 수 없거나 요청을 거부하면 다른 워커가 요청을 받아 작업을 잃지 않고 CPU 호환 모델로 실행합니다.

Hugging Face Accelerate는 CPU 오프로딩 방식을 제공하며, 이를 통해 모델 상태를 CPU 메모리와 실행 장치 사이에서 의도적으로 이동할 수 있습니다. 이는 임의의 CUDA 상태가 실패한 후의 긴급 대응이 아니라 계획된 이기종 실행입니다. 모델, 디바이스 맵, 훅 및 메모리 예산은 추론이 시작되기 전에 준비됩니다.

부분적으로 오프로딩된 모델은 이미 CPU를 사용하고 있어도 모든 토큰을 처리할 때 GPU에 의존할 수 있습니다. GPU가 실패하면 해당 프로세스가 중단된 토큰부터 CPU에서 계속 실행된다고 보장할 수 없습니다. 진정한 장애 조치는 일반적으로 CPU를 사용할 준비가 된 워커에서 요청을 다시 시작합니다. 이 차이 때문에 애플리케이션이 CPU를 지원한다고 명시하면서도 현재 요청을 완료하지 못하고 OOM 오류를 반환할 수 있습니다.

모델이 성공적으로 로드된 후에도 VRAM이 가득 찰 수 있습니다

모델 가중치는 메모리 예산의 일부일 뿐입니다. 키-값 캐시는 활성 시퀀스 길이와 동시성에 따라 증가하고, 임시 커널에는 작업 공간이 필요하며, 이미지 또는 오디오 인코더는 텐서를 추가합니다. 또한 메모리 할당자는 재사용을 위해 블록을 예약할 수 있습니다. 따라서 시작 시 모델이 들어맞더라도 긴 컨텍스트나 여러 동시 사용자로 인해 실패할 수 있습니다.

PyTorch는 캐싱 메모리 할당자를 사용하므로 예약된 메모리로 보고되는 양이 현재 사용 중인 텐서 메모리와 일치하지 않습니다. 단편화와 프레임워크 외부에서 발생한 할당은 사용 가능한 여유 공간을 더욱 줄일 수 있습니다. 장애 조치 트리거는 하나의 대시보드 수치나 모델 로드 성공 여부만으로 안전성을 판단하지 말고, 거부된 메모리 할당과 워커 상태를 감시해야 합니다.

이 때문에 고정된 “모델 크기가 VRAM보다 작다”는 규칙만으로는 충분하지 않습니다. 서비스는 컨텍스트 한도를 낮추거나, 동시 시퀀스 수를 제한하거나, 런타임 할당을 보호하기 위해 VRAM의 일정 비율을 사용하지 않을 수 있습니다. 이러한 제어는 GPU 프로세스를 알려진 상태로 유지하고 허용된 요청의 지연 시간을 예측 가능하게 만들기 때문에, 사후 대응 방식의 CPU 전환보다 더 많은 장애를 예방합니다.

자동 재시도는 요청을 재실행할 수 있을 때만 안전합니다

OOM 발생 후 라우터는 GPU 워커를 비정상 상태로 표시하고, 해당 워커를 해제하거나 다시 시작한 뒤 원래 요청을 CPU 워커에서 재실행할 수 있습니다. 외부 부작용이 발생하지 않은 일반적인 텍스트 생성에서는 이 방식이 작동합니다. 그러나 스트리밍 응답, 무작위 시드를 사용하는 이미지 파이프라인 또는 이미 도구를 호출했을 수 있는 에이전트에서는 더 어렵습니다.

프레임워크는 처음부터 대규모 모델을 여러 장치에 분산할 수도 있습니다. Accelerate의 대규모 모델 추론은 모델이 하나의 장치를 초과할 때 디바이스 맵과 CPU 또는 디스크 배치를 지원합니다. 이 방식은 하나의 계획된 실행 그래프 안에서 요청을 계속 처리할 수 있지만, 용량을 확보하는 대신 속도가 느려지며 실패한 요청을 별도의 서비스로 라우팅하는 것과 혼동해서는 안 됩니다.

CPU에 충분한 RAM이 없거나, 런타임에 호환되는 CPU 커널이 없거나, 요청이 이미 되돌릴 수 없는 작업을 수행했거나, 예상되는 CPU 지연 시간이 클라이언트 타임아웃을 초과하면 장애 조치가 적용되지 않습니다. 이러한 경우에는 제어된 용량 초과 오류를 반환하거나 요청을 대기열에 넣어야 합니다. 무조건 조용히 재시도하면 부작용이 중복되거나 사용자가 인터페이스가 약속한 시간보다 훨씬 오래 기다리게 될 수 있습니다.

-15% OFF

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

Single board computer zimaboard2

의도적인 메모리 테스트로 장애 조치를 검증하세요

라우터 뒤에 GPU 워커 하나와 CPU 워커 하나를 실행한 다음, 시스템 RAM을 초과하지 않으면서 GPU 프로필을 초과하는 요청을 전송하세요. 최초 실패 시점, 재시도 결정, CPU 시작 시간, 최종 출력 및 클라이언트 연결 유지 여부를 기록하세요. 먼저 스트리밍을 비활성화한 상태에서 반복한 다음, 취소, 동시 트래픽 및 모의 도구를 사용하는 에이전트 요청을 테스트하세요.

부분적인 GPU 실행은 유용한 기준이 됩니다. llama.cpp 추론과 같은 런타임은 모델 작업의 구성 가능한 일부를 가속기에 배치하면서 CPU 실행을 유지할 수 있습니다. GPU 상주, 계획된 CPU/GPU 분할 및 독립적인 CPU 폴백 프로필을 비교하세요. 하이브리드 AI 워크로드 모델을 사용하면 용량 부족에 따른 폴백과 일반적인 클라우드 라우팅을 구분할 수 있습니다.

재시도가 한 번만 완료되고, 요청 식별자를 유지하며, 도구 작업의 중복을 방지하고, 관련 없는 작업을 중단하지 않은 채 GPU 워커를 복구할 때만 설계를 신뢰할 수 있는 것으로 간주하세요. CPU 처리가 너무 느리다면 대화형 처리와 동등한 경로가 아니라 대기열을 유지하는 안전 경로로 사용하세요. 운영상의 목표는 CPU와 GPU 서비스 수준이 서로 같다고 가장하는 것이 아니라, 성능을 우아하게 저하시키는 것입니다.

동작	OOM 전에 준비되었나요?	현재 요청을 저장할 수 있나요?
CPU/GPU 오프로딩	예	일반적으로 계획된 그래프 내에서 가능
GPU 동시성 낮추기	예	안전하지 않은 작업의 수락을 방지
라우터의 CPU 재시도	예	재실행할 수 있다면 가능
계획되지 않은 프로세스 내 전환	아니요	일반적으로 불가능