가정용 AI 서버는 메모리 사용량에 따라 모델을 어떻게 라우팅하나요?

홈 AI 서버는 각 요청을 전체 작업 세트가 사용 가능한 디바이스 여유 메모리에 맞는 모델과 연결하여 메모리 사용량에 따라 모델을 라우팅합니다.

로컬 라우터는 소형 및 대형 언어 모델, 임베딩 모델, 비전 인코더, 음성 시스템, CPU 또는 GPU 실행 경로 중에서 선택할 수 있습니다. 체크포인트 파일 크기는 시작점에 불과합니다. 실제 실행 허용 여부는 양자화 메타데이터, 런타임 컨텍스트, KV 캐시, 프롬프트 길이, 동시성, 비전 토큰, 임시 작업 공간, 다른 서비스가 이미 예약한 메모리에도 좌우됩니다. 유용한 라우터는 실행 전에 이러한 비용을 프로파일링하고, 전체 요청 동안 안정적으로 유지될 수 있는 모델, 정밀도, 컨텍스트 제한, 하드웨어 경로를 선택합니다.

체크포인트 크기는 전체 메모리 사용량 중 고정된 부분일 뿐입니다

가중치와 양자화 메타데이터는 예측 가능한 상주 메모리 기준량을 만듭니다. 런타임은 여기에 라이브러리, 할당자 풀, 실행 그래프, 입력 버퍼, 활성값, 요청 상태를 추가합니다.

ZimaSpace의 하드웨어 가이드는 전체 AI 메모리를 모델 파일 크기 이상의 개념으로 설명합니다.

파일 크기만 사용하는 라우터는 모델을 성공적으로 로드하더라도 긴 프리필, 멀티모달 요청 또는 동시 채팅 중에 실패하는 모델을 허용할 수 있습니다.

각 모델에는 실측 메모리 프로필이 필요합니다

모든 모델과 양자화 조합에 대해 유휴 상태 상주 메모리, 프리필 피크 메모리, 컨텍스트 토큰당 바이트 수, KV 정밀도, 배치 제한, 시각 토큰 비용, 런타임 예약 메모리를 기록합니다.

2026년 다중 모델 스케줄링 연구는 모든 모델에 동일한 배치 공식을 적용한다고 가정하지 않고, 아키텍처와 이기종 하드웨어 전반의 모델 메모리 동작을 분석합니다.

컴파일 캐시와 할당자의 최고 수위 메모리 사용량이 이전 요청 이후 사용 가능한 메모리를 바꿀 수 있으므로, 프로필에는 콜드 상태와 웜 상태를 모두 포함해야 합니다.

런타임, 드라이버, 컨텍스트 설정, 양자화 또는 모델 형식을 변경한 후에는 프로필을 다시 작성합니다.

라우터는 허용 전에 동적 여유 메모리를 예약해야 합니다

요청에는 프롬프트 길이, 예상 출력 길이, 이미지 수와 해상도, 요청 배치, 현재 사용자 동시성 등 추가 정보가 포함됩니다.

Prism의 글로벌 메모리 스케줄러는 고정 예약 대신 워크로드와 큐 정보를 활용해 모델 활성화와 축출을 조정합니다.

홈 라우터는 더 간단한 허용 공식을 사용할 수 있습니다. 디바이스의 가용 메모리에서 안전 여유 공간을 뺀 값이 모델 기준량에 예상 요청 상태와 작업 공간을 더한 값보다 커야 합니다.

예상 메모리가 부족하면 라우터는 컨텍스트를 줄이거나, 배치를 축소하거나, 더 작은 모델을 선택하거나, 캐시 정밀도를 낮추거나, 요청을 대기열에 넣거나, 다른 디바이스로 라우팅할 수 있습니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

GPU 전체 적재, 부분 오프로딩, CPU 실행은 서로 다른 경로입니다

VRAM에 완전히 들어가는 모델은 일반적으로 호스트와 디바이스 간 가중치 반복 전송을 피할 수 있습니다. 더 큰 모델은 CPU 부분 오프로딩이나 통합 메모리를 통해 실행할 수 있지만, 지연 시간과 대역폭 제한은 달라집니다.

ATSInfer는 텐서 수준 배치를 사용해 소비자용 CPU와 GPU 메모리 전반에서 저장, 전송, 연산을 조율합니다.

라우터는 “실행할 수 있는가”와 “워크플로의 마감 시간을 충족하는가”를 구분해야 합니다. 부분 오프로딩 모델은 밤새 진행하는 분석에는 적합할 수 있지만 음성 상호작용에는 부적합할 수 있습니다.

인기도와 재로드 비용은 어떤 모델을 상주 상태로 유지할지에 영향을 줍니다

자주 요청되는 모델은 웜 상태로 유지하고, 드물게 사용되는 대형 모델은 작업에서 로드 비용을 감수할 가치가 있을 때까지 스토리지에 둘 수 있습니다.

Weaver는 인기도가 고르지 않은 여러 엔드포인트를 제공하는 시스템에서 핫 모델과 콜드 모델을 분석합니다.

요청 품질 요구 사항을 충족하면서 긴 축출 및 재로드 과정을 피할 수 있다면, 요청은 조금 더 작은 웜 모델로 라우팅할 수 있습니다. 어려운 작업은 예상되는 품질 향상이 지연 시간보다 클 때 대형 모델을 로드할 이유가 됩니다.

메모리만으로 결정하지 말고 작업 요구 사항을 반영해야 합니다

메모리 사용량이 가장 작은 경로가 항상 올바른 선택은 아닙니다. 코딩, 다국어 텍스트, 복잡한 추론, OCR, 도구 계획에는 더 작은 모델에 없는 기능이 필요할 수 있습니다.

MuxServe는 효율적인 서비스 제공이 모델 수요와 리소스 동작 모두에 달려 있기 때문에 배치와 스케줄링을 결합합니다.

먼저 필요한 기능 수준을 정의한 다음, 워크플로의 품질, 안전성, 지연 시간, 형식 테스트를 통과하는 모델 중 메모리 사용량이 가장 적은 모델을 선택합니다.

결정적인 추출 작업은 작은 상주 모델로 라우팅할 수 있지만, 어려운 계획 수립 요청은 더 큰 모델로 라우팅하거나 용량이 확보될 때까지 대기시킬 수 있습니다.

라우팅은 실시간 메모리와 최근 실행 이력에 맞춰 조정되어야 합니다

정적 프로필만으로는 모든 할당자 예약, 메모리 단편화 영역, 경쟁 컨테이너 또는 열로 인한 성능 저하를 포착할 수 없습니다. 라우터에는 현재 가용 메모리, 큐 깊이, 상주 모델, 최근 실패 기록도 필요합니다.

에이전트형 CPU-GPU 스케줄링 연구는 이기종 AI 작업을 할당할 때 메모리 사용량, 콜드 스타트 비용, 실행 이력, 하드웨어 정보를 결합합니다.

선택한 경로, 예측 메모리, 실제 피크 메모리, 로드 시간, 첫 토큰 지연 시간, 출력 속도, 폴백 여부를 기록합니다. 예측 오차가 정의된 허용 범위를 초과하면 모델 프로필을 업데이트합니다.

메모리 인지형 라우팅은 요청을 안정적인 용량 범위 안에 유지하면서도 현재 작업의 서비스 목표를 충족할 수 있는 가장 강력한 모델을 서버가 계속 선택할 때 성공적입니다.

FAQ

라우터가 모델 파일 크기를 빠른 추정치로 사용할 수 있나요?

유용한 기준값이기는 하지만, 요청을 허용하기 전에 런타임 오버헤드, KV 캐시, 프롬프트, 배치, 안전 여유 공간도 고려해야 합니다.

VRAM이 가득 차면 모델을 항상 CPU로 라우팅해야 하나요?

CPU 또는 하이브리드 실행이 작업의 지연 시간과 메모리 요구 사항을 충족할 때만 그렇습니다. 요청을 대기시키거나 더 작은 모델을 선택하는 편이 나을 수 있습니다.

메모리 인지형 라우팅을 사용하려면 GPU가 여러 개 필요한가요?

아닙니다. 단일 홈 서버에서도 GPU 한 개, CPU 실행, 부분 오프로딩, 다양한 양자화 방식, 여러 모델 크기 중에서 선택할 수 있습니다.