여러 로컬 모델이 하나의 가속기를 공유할 수 있도록 하는 구성 요소는 무엇인가요?

에바 왕

IceWhale author

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

What Components Enable Multiple Local Models to Share One Accelerator?

서빙 계층이 워크로드 전반에서 가중치 상주, 동적 메모리, 실행 시간, 요청 격리를 조율하면 여러 로컬 모델이 하나의 가속기를 공유할 수 있습니다.

가정용 GPU는 채팅 모델, 임베딩 모델, 비전 인코더, 음성 인식 모델 사이를 번갈아 사용할 수 있습니다. 모든 가중치 세트를 영구적으로 로드하면 VRAM을 초과할 수 있고, 요청마다 언로드하면 첫 토큰 지연 시간이 불안정해집니다. 멀티 모델 컨트롤러에는 별도 프로세스가 무작정 경쟁하도록 맡기는 대신 상주 정책, 모델 간 메모리 회계, 스케줄링, 캐시 격리, 선점, 공정성이 필요합니다.

상주 정책이 어떤 가중치를 계속 준비된 상태로 둘지 결정합니다

컨트롤러는 모델 크기, 요청 도착률, 로드 시간, 지연 시간 목표, 최근 사용량을 추적합니다. 인기 모델은 상주 상태로 유지하고, 사용 빈도가 낮은 모델은 CPU나 스토리지를 사용하도록 하며, 예측된 수요에 따라 다음 요청이 가속기에 도달하기 전에 프리워밍을 시작할 수 있습니다.

멀티 모델 프리워밍은 여러 모델을 위한 범용 GPU 워커를 준비하고, 축출을 고려한 배치와 프리워밍을 조율합니다. 이 결과는 예측 가능한 수요에서 콜드 로드를 피하는 것이 첫 토큰까지의 시간을 크게 개선할 수 있는 이유를 보여줍니다. 이러한 차이는 이후 가정 환경 테스트에서도 확인할 수 있습니다.

상주 여부를 결정할 때는 양자화 및 어댑터 변형도 포함해야 합니다. 겉보기에는 유사한 두 엔드포인트라도 서로 다른 기본 가중치를 보유할 수 있기 때문입니다. 엄격한 메모리 예산은 사전 로딩으로 인해 활성 요청의 KV 캐시가 축출되는 것을 방지합니다. 자동화가 후속 작업을 수행하기 전에 중간 결과를 계속 확인할 수 있어야 합니다.

모델 간 메모리 조율이 분할된 용량을 방지합니다

가중치는 대부분 안정적으로 유지되지만 활성값과 KV 캐시는 배치 및 시퀀스 길이에 따라 증가합니다. 공유 할당자는 필요할 때 메모리 페이지를 매핑하고, 유휴 영역을 회수하며, 예약량을 공개해 한 모델이 다른 모델에 약속된 공간을 모두 차지하지 못하도록 할 수 있습니다.

모델 간 메모리 조율은 동적 가상-물리 페이지 매핑과 런타임 공유 정책을 통해 모델 간 메모리 조율을 구현합니다. 이 설계는 일반적인 프로세스 수준 GPU 공유가 빠르게 변하는 모델 수요에 효과적으로 대응하지 못하는 이유를 설명합니다. 이러한 한계는 현실적인 운영 조건에서 별도로 측정해야 합니다.

메모리 공유는 데이터 공유가 아닙니다. KV 캐시 블록, 프리픽스 캐시, 임시 버퍼, 어댑터 상태에는 테넌트 및 모델 식별자가 필요합니다. 그렇지 않으면 재사용된 페이지나 캐시 키로 인해 엔드포인트 간 컨텍스트가 유출되거나 결과가 손상될 수 있습니다.

스케줄링과 어댑터 다중화가 실행 시간을 제어합니다

스케줄러는 모델이 메모리를 함께 사용하는 공간적 공유와 커널이 번갈아 실행되는 시간적 공유 중 하나를 선택합니다. 연속 배칭은 처리량을 높이고, 선점과 가중 큐는 대화형 요청을 긴 백그라운드 작업으로부터 보호합니다.

어댑터 다중화는 어댑터 가중치를 페이징하고 서로 다른 배치를 조율해 공유 기본 모델 위에서 수천 개의 저랭크 어댑터를 제공합니다. 이는 완전히 분리된 모델 복제본보다 더 많은 상태를 공유하면서도 특화를 구현할 수 있음을 보여줍니다. 여러 소스가 제한된 컨텍스트를 두고 경쟁할 때 이러한 실질적인 효과가 나타납니다.

실패가 발생하는 경계는 커널 및 메모리 간섭입니다. 동시에 적재되는 두 모델이 메모리에 들어가더라도 컴퓨팅 자원, 대역폭, 복사 엔진을 두고 경쟁하면 지연 시간 목표를 달성하지 못할 수 있습니다. 공유는 총 사용률이 높아 보일 때가 아니라 모델별 p95 지연 시간과 공정성이 정책 범위 안에 유지될 때만 유용합니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

모델 공유 간섭 매트릭스를 구축하세요

각 모델을 단독으로 측정한 다음, 중요한 모든 모델 쌍과 예상되는 4개 모델 조합을 짧은 요청, 긴 요청, 버스트 요청, 백그라운드 요청으로 실행합니다. 콜드 로드 시간, 상주 메모리, KV 증가량, 커널 사용률, 처리량, p50 및 p95 지연 시간, 축출 횟수를 기록하세요.

라우팅된 모델 상주에 설명된 라우팅 스택 원칙을 사용해 각 엔드포인트에 우선순위와 상주 등급을 지정하세요. 어댑터, 양자화된 변형, 연속 배칭, 선점을 적용해 반복하면서 캐시와 요청 식별자가 계속 격리되는지 확인하세요.

중요한 대화형 모델이 최악의 예상 조합에서도 지연 시간 목표를 충족할 때만 공유 정책을 유지하세요. 특정 모델 쌍이 반복적인 스래싱을 일으킨다면 더 나은 사용률 그래프를 위해 동시성을 높이는 대신 해당 쌍을 직렬화하거나 시간 창을 예약하세요.