로컬 AI 서비스가 가속기 메모리를 두고 경쟁하면 어떻게 될까요?

로컬 AI 서비스가 가속기 메모리를 두고 경쟁하면 각 런타임이 다른 모델, 요청, 캐시 및 임시 텐서에 사용할 수 있는 용량을 줄입니다.

홈 서버에서는 별도의 컨테이너나 프로세스를 통해 채팅, 임베딩, 이미지 생성, 음성 인식, 음성 합성, 비전 감지 및 카메라 분석을 실행할 수 있습니다. 대시보드에는 유휴 상태로 표시되더라도 모델 가중치와 할당자 풀이 동일한 GPU, NPU 또는 공유 메모리 가속기에 계속 상주할 수 있습니다. 그러면 새 요청에는 정적 모델 용량만으로는 드러나지 않았던 프롬프트 상태, 활성화 값 및 출력 버퍼를 위한 공간이 필요해집니다. 아래 섹션에서는 별도의 서비스가 명목상의 가속기 용량을 어떻게 요청 수락 실패와 불안정한 지연 시간으로 바꾸는지 설명합니다.

각 서비스는 모델 가중치 이상의 것을 사용합니다

로드된 모델은 파라미터 메모리를 차지하지만, 실제 추론에는 런타임 라이브러리, 실행 컨텍스트, 임시 작업 공간, 입력 버퍼, 활성화 값 및 요청별 상태도 필요합니다.

대규모 언어 모델 서빙 연구에서는 KV 캐시 메모리를 주요 동시성 제한 요소로 지목합니다. 활성 시퀀스 수와 컨텍스트 길이에 따라 KV 캐시가 증가하기 때문입니다. 유휴 상태에서는 실행 가능한 모델도 여러 개의 긴 요청이 동시에 활성화되면 실패할 수 있습니다.

비전, 확산, 음성 및 임베딩 서비스는 서로 다른 임시 메모리 사용 패턴을 보입니다. 평균 사용률이 낮더라도 최대 할당 시점이 겹칠 수 있습니다.

별도의 프로세스는 컨텍스트와 런타임 오버헤드를 중복 생성합니다

각 AI 기능을 자체 컨테이너에서 실행하면 운영상 분리가 향상되지만, 별도의 프로세스는 각각 별도의 가속기 컨텍스트, 라이브러리, 할당자 풀 및 공유 모델 구성 요소의 복사본을 만들 수 있습니다.

멀티 모델 시스템에서는 단순히 모델마다 하나의 서비스를 배치하는 방식이 메모리와 연산을 모두 낭비하기 때문에 멀티 모델 서빙을 연구합니다. 조정된 공동 배치는 각 런타임이 디바이스를 독점한다고 가정하는 독립적인 런타임보다 용량을 더 효과적으로 공유할 수 있습니다.

동일한 토크나이저, 비전 인코더 또는 언어 모델을 사용하는 두 서비스가 물리적으로 하나의 복사본을 자동으로 공유하는 것은 아닙니다. 공유하려면 런타임 지원과 호환되는 프로세스 경계가 필요합니다.

이러한 중복 비용은 소형 가속기에서 특히 크게 나타납니다. 수백 MB에 불과한 컨텍스트와 라이브러리 오버헤드가 다른 모델의 실행 가능 여부를 결정할 수 있기 때문입니다.

예약된 풀은 다른 런타임에서 메모리를 숨길 수 있습니다

프레임워크는 이후 요청에서 값비싼 디바이스 할당과 동기화를 피하기 위해 해제된 블록을 유지하는 경우가 많습니다. 서비스에는 실제로 할당된 메모리가 줄어든 것으로 표시되지만, 다른 프로세스는 예약된 물리 공간을 여전히 사용할 수 없습니다.

통계적 다중화와 같은 시스템은 각 모델 서버가 최악의 상황을 기준으로 자체 예약을 수행하도록 두지 않고, 배치와 버스트 패턴을 전역 문제로 다룹니다. 독립적인 로컬 서비스에는 오케스트레이터가 이를 강제하지 않는 한 이러한 전역 관점이 없습니다.

이 때문에 가속기가 낮은 연산 사용률을 보이면서도 새 모델을 거부할 수 있습니다. 활성 커널이 아니라 가중치, 예약된 블록 또는 조각화된 여유 영역이 용량을 차지하고 있기 때문입니다.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

경합은 OOM 오류가 발생하기 전에 지연 시간을 바꿉니다

런타임은 메모리가 부족해지면 배치 크기를 줄이거나, 동시에 처리할 수 있는 시퀀스 수를 제한하거나, 제거된 상태를 다시 계산하거나, 레이어를 CPU RAM으로 이동하거나, 다른 모델을 언로드할 수 있습니다.

Aegaeon은 변화하는 수요에 따라 여러 모델을 조정하기 위해 토큰 단위 스케줄링을 사용합니다. 이에 상응하는 조정 기능이 없는 홈 서버에서는 이러한 부족 현상이 첫 토큰 생성 지연, 일시 정지, 모델 교체 또는 예측하기 어려운 대기열로 나타나는 경우가 많습니다.

ZimaSpace의 가족 동시 사용 관련 글은 동일한 경계를 요청 수준에서 보여줍니다. 한 명만 사용할 때는 빠르게 느껴지더라도 활성 대화가 메모리와 스케줄러의 처리 우선순위를 두고 경쟁합니다.

메모리 부족 예외는 최종적인 실패 형태일 뿐입니다. 지연 시간의 불안정성과 처리량 감소는 대개 그보다 먼저 나타납니다.

모델 축출은 즉각적인 응답과 용량을 맞바꿉니다

비활성 모델을 언로드하면 다른 서비스가 사용할 수 있는 큰 연속 영역이 확보됩니다. 하지만 축출된 서비스에 다음 요청이 들어오면 가중치를 다시 로드하고 런타임 상태를 재구성해야 하므로 메모리 압박이 콜드 스타트 지연으로 이어집니다.

WarmServe는 잦은 모델 전환이 첫 토큰 생성 시간에 악영향을 미치기 때문에 축출 인식 배치를 연구합니다. 모든 모델을 웜 상태로 유지하는 방식은 가속기에 모델의 상주 상태와 활성 상태를 합친 용량을 충분히 확보할 수 있을 때만 더 빠릅니다.

홈 서버에 적합한 정책은 워크로드에 따라 달라집니다. 음성 제어는 영구 상주가 적합할 수 있지만, 가끔 사용하는 이미지 생성은 다시 로드하는 지연을 감수할 수 있습니다.

하나의 리소스 관리자가 실제 용량 경계를 적용할 수 있습니다

가능하다면 하나의 추론 서버를 통해 서비스를 조정하고, 서비스별 메모리 제한, 디바이스 가시성, 모델 상주 규칙, 동시성 제한 및 우선순위를 명시적으로 지정하세요.

메모리 벌루닝에 관한 최근 연구는 모델 인기도와 요청 부하가 변할 때 정적 할당이 용량을 낭비하는 이유를 보여줍니다. 동적 공유는 활용률을 높일 수 있지만, 이를 위해서는 경쟁하는 모든 워크로드를 관찰하는 하나의 시스템이 필요합니다.

서비스별로 가중치, 예약된 메모리, 활성 할당량, KV 캐시, 요청 동시성, 컨텍스트 길이, 배치 크기 및 모델 전환 빈도를 측정하세요. 서비스별 분석이 없는 전역 디바이스 총량만으로는 충돌 원인을 설명할 수 없습니다.

지연 시간에 민감한 서비스를 우선 보호하고, 임베딩과 인덱싱은 유지 관리 시간대에 예약하며, 일시적인 피크를 위해 할당하지 않은 여유 용량을 남겨 두세요. 목표는 유휴 상태에서 모든 바이트를 채우는 것이 아니라, 동시 요청이 발생해도 의도한 서비스 구성을 안정적으로 유지하는 것입니다.

FAQ

GPU 사용률이 낮은데 가속기 메모리는 왜 가득 차 있나요?

연산 사용률은 현재 실행 중인 작업을 측정하는 반면, 모델 가중치, 컨텍스트, 캐시 및 예약된 할당자 블록은 요청이 없는 동안에도 메모리를 차지할 수 있습니다.

컨테이너가 GPU 메모리 제한을 자동으로 적용할 수 있나요?

모든 런타임에서 안정적으로 적용되는 것은 아닙니다. 디바이스 할당과 프로세스 격리가 여러 프레임워크의 내부 예약을 조정해 준다는 보장은 없습니다.

공유 추론 서버가 항상 더 나은가요?

그렇지는 않습니다. 중복을 줄이고 스케줄링을 개선할 수 있지만, 서비스 격리, 프레임워크 호환성, 보안, 장애 복구 및 모델 지원 여부에 따라 별도의 런타임이 더 적합할 수 있습니다.