대규모 언어 모델 (LLM)의 진화하는 환경에서 "머신당 하나의 모델" 배포 패턴은 기업의 LLM 서빙 비용 효율성에 상당한 병목 현상이 되고 있습니다. LLM은 최대 부하를 관리하기 위해 전체 8x H100 GPU 노드와 같은 상당한 하드웨어 예약을 요구하는 경우가 많습니다. 하지만 표준 작업 중에는 이러한 고가의 리소스가 활용되지 않는 경우가 많아 총 소유 비용 (TCO)이 높아집니다.
모델 공동 호스팅 은 여러 모델 인스턴스가 동일한 가상 머신 및 GPU 리소스를 공유할 수 있도록 하여 이러한 효율성 격차를 해결합니다. 여기에는 Llama 3.3 및 Gemma 3과 같은 완전히 다른 모델이 포함됩니다. Vertex AI Model Garden은 하위 GPU 메모리 슬라이싱 및 지능형 리소스 파티셔닝을 활용하여 정적 하드웨어 예약을 유연한 고밀도 컴퓨팅 풀로 변환합니다.
이 기술 블로그에서는 모델 공동 호스팅을 프로덕션에 즉시 사용 가능한 클라우드 서비스로 가져오는 Vertex AI 엔지니어링의 프로세스를 자세히 설명합니다. 컨테이너 수준 구현 전략, 최적의 서빙 구성 식별, 광범위한 다중 모델 벤치마크 연구의 주요 결과를 위한 Google의 방법론을 공유하여 LLM 서빙 비용 효율성을 극대화할 수 있도록 지원합니다.
모델 공동 호스팅 이해: 개념 및 아키텍처
모델 공동 호스팅은 여러 대규모 언어 모델 (LLM) 인스턴스 또는 서로 다른 모델 아키텍처가 단일 가상 머신 (VM) 내에서 동일한 물리적 하드웨어 리소스를 공유할 수 있도록 하는 고밀도 서빙 전략입니다. 단일 모델에 전체 VM 또는 GPU를 할당하는 기존 배포 모델과 달리 공동 호스팅은 세분화된 리소스 파티셔닝을 활용하여 하드웨어 ROI를 극대화하고 메모리 및 컴퓨팅 리소스의 활용도를 개선합니다.
Google의 구현은 독립적인 구성을 사용하여 여러 모델을 동시에 서빙할 수 있는 컨테이너 수준 솔루션에 중점을 둡니다. 이 아키텍처는 단일 컨테이너 내에 여러 독립적인 모델 서버 인스턴스를 배포하는 것으로 시작하여 여러 통합 기술 메커니즘을 통해 작동합니다. 이러한 각 인스턴스는 모델 서버의 완전하고 독립적인 사본 역할을 하며, 이를 통해 가상 머신 전체에서 동시 요청 처리가 가능합니다. 이 트래픽을 관리하기 위해 Google은 컨테이너 내에 인스턴스 라우팅 레이어를 구현하여 수신 요청을 활성 인스턴스 간에 효율적으로 분산합니다.
이 설계는 공동 호스팅 모델 이 텐서 병렬 처리 (TP), 파이프라인 병렬 처리 (PP) 및 특정 모델 인스턴스 수 에 대한 고유한 설정을 포함하는 전용 서빙 구성을 활용할 수 있도록 하여 세분화된 병렬 처리를 제공합니다. 이는 리소스 슬라이싱으로 보완됩니다. 여기서 특정 GPU 메모리 파티션이 각 모델에 할당됩니다(예: 모델당 0.4 GPU 메모리 파티션). 이를 통해 중요한 메모리 리소스를 서로 부족하게 하지 않고 동일한 액셀러레이터에서 다양한 워크로드가 공존할 수 있습니다. 이 아키텍처 접근 방식은 전체 8x H100 GPU 노드와 같은 정적 하드웨어 예약을 대규모 추론 모델에서 소규모의 짧은 지연 시간 채팅 모델에 이르기까지 다양한 포트폴리오를 서빙할 수 있는 유연한 컴퓨팅 풀로 변환합니다.
프로토타입 제작 및 벤치마크 연구
프로덕션에 즉시 사용 가능한 오케스트레이터를 개발하기 전에 모델 공동 호스팅의 이론적 효율성을 검증하기 위해 포괄적인 벤치마크 연구를 진행했습니다. 이 단계에서는 vLLM의 기본 병렬 처리를 철저히 테스트하고 모델이 동일한 실리콘 칩을 공유할 때 '간섭' 정도를 정확히 정량화하는 것을 목표로 했습니다.
병렬 처리 조사: '교차점' 찾기
Google의 초기 분석은 vLLM의 기본 텐서 병렬 처리 (TP) 와 모델 인스턴스의 Vertex 구현을 여러 vLLM 서버 인스턴스로 집중하여 이러한 전략이 다양한 사용자 부하와 어떻게 상호작용하는지 파악했습니다. 최적의 구성은 동시 실행에 크게 의존하는 것으로 확인되었습니다. 동시 실행이 낮을 때는 높은 텐서 병렬 처리 (예: TP=8)가 사용 가능한 모든 액셀러레이터에 레이어를 분산하여 개별 요청에 대한 지연 시간을 가장 짧게 제공합니다. 하지만 동시 트래픽이 증가하면 병목 현상이 발생합니다. 부하가 높은 조건에서 처리량을 극대화하기 위해 최적의 구성은 TP=8에서 TP=4, TP=2, 최종적으로 TP=1로 전환되는 동시에 독립적인 모델 인스턴스 수를 늘립니다. 이 전환은 TP가 낮은 설정에서 GPU 간 통신 지연 시간 감소의 이점이 TP가 높은 실행의 원시 속도보다 큰 '교차점'을 정의합니다. 다음은 Gemma 2 9B IT 모델의 교차점 차트입니다.
최적의 확장: 단일 모델, 다중 복제본
확장성을 위한 엄격한 기준을 설정하기 위해 단일 노드에서 동일한 모델의 여러 인스턴스를 벤치마크했습니다. 포화 트래픽 조건 (GPU당 2048개의 동시 요청)에서 8xH100 노드에서 8개의 독립적인 vLLM 서버 인스턴스를 실행하면 단일 GPU 기준선에 비해 지연 시간 회귀가 거의 없이 처리량이 약 7.8배 향상 되었습니다.
인프라 비교: 컨테이너와 포드 공동 예약
또한 Google은 기본 인프라 수준 솔루션, 특히 포드 공동 예약에 대해 컨테이너 수준 오케스트레이션을 평가했습니다. 두 솔루션 모두 다중 복제본 서빙에 비슷한 성능을 제공했지만 최종적으로 최소 기능 제품(MVP)에 컨테이너 수준 접근 방식을 선택했습니다. 이 결정은 컨테이너 수준 솔루션이 제공하는 이종 공동 호스팅의 우수한 유연성으로 인해 개발자가 기본 Kubernetes 예약 제약조건에 의해 제한되지 않는 세분화된 소프트웨어 정의 메모리 파티션과 함께 서로 다른 모델 아키텍처를 나란히 서빙할 수 있기 때문입니다. 또한 컨테이너 수준 오케스트레이션을 사용하면 훨씬 빠르게 반복할 수 있으며 맞춤설정하고 혁신하기가 더 쉽습니다.
간섭 테스트: 서로 다른 모델 공동 호스팅
최종 프로토타입 제작 마일스톤은 동일한 VM에서 Gemma-3n-E2B-it 및 Llama-3.1-8B-Instruct를 공동 호스팅한 '간섭 테스트'였습니다. 각 모델에 0.4 GPU 메모리 파티션이 할당된 상태에서 서빙 성능은 단일 모델 벤치마크와 거의 동일하게 유지되었습니다. 예를 들어 Gemma-3n은 공동 호스팅 환경에서 30.21 req에 도달한 반면 격리된 환경에서는 30.96 req에 도달했습니다. 이러한 결과는 메모리 리소스가 KV 캐시 부족을 방지하기 위해 적절하게 파티셔닝되는 경우 정체가 심한 경우에도 공동 호스팅 모델 간에 컴퓨팅 간섭이 거의 또는 전혀 없음을 확인합니다.
MVP 컨테이너 구현
검증된 벤치마크에서 프로덕션에 즉시 사용 가능한 시스템으로 전환하려면 강력한 컨테이너화된 오케스트레이터를 엔지니어링해야 했습니다. 이 개발 단계는 결정론적 리소스 격리를 보장하면서 여러 모델 수명 주기의 복잡성을 관리할 수 있는 고급 소프트웨어 레이어를 빌드하는 데 중점을 두었습니다.
모델 공동 호스팅 서버 설계
Google 구현의 핵심은 컨테이너 내에서 마스터 오케스트레이터 역할을 하도록 설계된 커스텀 진입점인 model_cohost_server입니다. 표준 단일 프로세스 모델에서 벗어나 이 서버는 하위 프로세스 관리를 구현하여 vLLM과 같은 여러 독립적인 모델 서버 인스턴스를 격리된 하위 프로세스로 동시에 실행할 수 있도록 합니다. 수신 트래픽을 관리하기 위해 오케스트레이터는 고급 요청 라우팅을 사용하여 --served-model-name과 같은 인수를 통해 고유한 모델 식별자로 요청을 식별하고 해당 내부 서버 인스턴스로 요청을 전달합니다. 라우팅 외에도 서버는 모든 공동 호스팅 인스턴스의 초기화, 상태 모니터링, 종료를 관리하는 포괄적인 수명 주기
오케스트레이션을 제공합니다. 이 중앙 집중식 관리는 각 하위 프로세스의 고유한 운영 경계를 유지하면서 외부 트래픽을 위한 단일 통합 엔드포인트를 제공합니다.
GPU 리소스 파티셔닝: 결정론적 슬라이싱
단일 모델의 워크로드가 공동 호스팅 환경 전체에서 메모리 부족(OOM) 오류를 트리거할 위험을 없애기 위해 엄격한 리소스 슬라이싱 메커니즘을 구현했습니다. 이는 개발자가 명시적 메모리 비율 (예: 0.4, 0.4)을 정의하여 각 개별 모델 인스턴스에 대해 노드의 총 GPU 메모리의 고정된 비율을 예약할 수 있는 gpu-memory-partition 인수를 통해 운영됩니다.
이 할당을 안내하기 위해 Google은 정적 리소스 요구사항과 동적 리소스 요구사항을 구분하는 "사전 할당된 메모리"
모델을 채택합니다.
'사전 할당된' 메모리는 모델 가중치 및 KV 캐시에 사용되는 메모리로 구성됩니다. 모델 가중치에 사용되는 메모리 양은 모델의 매개변수 수와 정밀도에 따라 다릅니다. 예를 들어 BF16의 8B 매개변수 모델에는 약 16GB의 정적 스토리지가 필요합니다. KV 캐시에 사용되는 메모리 양은 모델 크기, 정밀도, 컨텍스트 길이, 시퀀스 수에 따라 다릅니다. "임시" 메모리는 중간 계산 및
추론 작업 메모리로 구성됩니다. gpu-memory-partition 인수는 '사전 할당된' 메모리를 고려합니다. gpu-memory-partition의 합이 1.0보다 작도록 설정하여 '임시' 메모리를 위한 버퍼 공간을 남겨두는 것이 좋습니다.
제품화
Vertex AI를 사용한 모델 공동 호스팅의 제품화 단계는 단일 모델 다중 복제본 및 다중 모델 서빙 구성 모두를 위한 원활하고 프로덕션에 즉시 사용 가능한 환경을 구축하는 데 전념했습니다. 이 전환은 경험적 벤치마크 결과를 간소화된 배포 워크플로와 심층적으로 통합된 인프라 지원 구조로 효과적으로 변환했습니다.
간소화된 배포 워크플로
고밀도 서빙의 진입 장벽을 낮추기 위해 기존 Vertex AI API와 기본적으로 통합되는 커스텀 컨테이너 인수를 사용하여 공동 호스팅 구성을 표준화했습니다. 8x H100 노드와 같은 전체 모양 가상 머신의 경우 특정 사용 사례에 가장 적합한 레시피를 맞춤설정하는 벤치마크 유틸리티 를 개발했습니다. 이 벤치마크 유틸리티를 사용하면 모델의 특정 매개변수 수와 정밀도에 따라 텐서 병렬 처리 (TP), 파이프라인 병렬 처리 (PP), 모델 인스턴스 수를 자동으로 균형 조정하는 구성을 찾을 수 있습니다. 이는 강력한 배포 API 지원으로 보완되어 개발자가 표준 deployModel 요청 내에서 직접 정확한 GPU 메모리 파티션을 포함한 이러한 세분화된 매개변수를 지정하고 모델을 배포할 수 있습니다.
동적 다중 모델 서빙
Google의 기술 여정에서 중요한 발전은 정적 구성에서 동적 서빙 아키텍처로의 전환이었습니다. 이 기능은 트래픽 패턴이 빠르게 변화하는 프로덕션 환경에 매우 중요합니다. 전체 컨테이너를 다시 시작하지 않고 모델을 로드하거나 언로드할 수 있는 기능은 인프라 민첩성과 고가용성을 유지하는 데 필수적이기 때문입니다.
동적 업데이트 API (update_models)
변경 불가능한 배포의 고유한 제한사항을 해결하기 위해 Vertex Model Garden vLLM 모델 공동 호스팅 컨테이너 내에 특수 모델 업데이트 API를 구현했습니다. 이 API는 핫 다시 로드를 지원하여 서버가 Cloud Storage 버킷에 저장된 Cloud Storage 버킷에 저장된 중앙 집중식 구성 파일을 기반으로 호스팅된 모델의 포트폴리오를 즉시 조정할 수 있도록 합니다.
업데이트 프로세스는 Cloud Storage YAML 파일을 가리키는 model_config_path가 포함된 update_models 엔드포인트에 대한 POST 요청을 통해 시작됩니다.
이 요청을 수신하면 서버는 최소 다운타임에 최적화된 다단계 오케스트레이션 시퀀스를 실행합니다.
- 정상적인 언로드: 시스템은 새 구성에서 누락된 모델을 식별하고 먼저 하위 프로세스를 종료하여 GPU 메모리 및 컴퓨팅 리소스를 즉시 회수합니다.
- 지능형 로드 및 재사용: 그런 다음 서버는 새 모델 인스턴스를 초기화합니다. 중요한 점은 텐서 병렬 처리 (TP) 또는 파이프라인 병렬 처리 (PP)와 같은 모델의 병렬 처리 설정과 할당된 메모리 파티션이 변경되지 않은 경우 오케스트레이터가 기존 실행 중인 인스턴스를 재사용한다는 것입니다. 이 최적화는 비용이 많이 드는 재초기화 단계를 우회하여 구성 전환 중에 활성 서비스가 중단되지 않도록 합니다.
지연 시간 및 성능 분석
이러한 업데이트 전략에 대한 경험적 분석에 따르면 동적 핫 다시 로드는 대규모 LLM 서빙과 일반적으로 관련된 '콜드 스타트' 페널티를 크게 완화합니다.
결론
Vertex AI를 사용한 모델 공동 호스팅은 엄격하고 하드웨어 중심의 모놀리식 배포에서 유연하고 효율적인 서빙 아키텍처로 전환하는 근본적인 패러다임 전환을 나타냅니다. 조직은 'VM당 하나의 모델' 표준을 넘어 고밀도 컴퓨팅 풀 모델로 발전함으로써 성능 벤치마크를 유지하고 종종 개선하면서 총 소유 비용 (TCO)을 크게 줄일 수 있습니다.
Google의 엔지니어링 여정과 광범위한 다중 모델 벤치마크 연구를 통해 이 아키텍처에 대한 명확한 프로덕션 가이드라인을 수립했습니다.
- 모든 상황에 적합한 단일 구성은 없습니다. Google은 특정 사용 사례 (모델, 하드웨어, 트래픽)에 가장 적합한 서빙 레시피를 찾고 이를 위한 도구를 빌드하는 것을 옹호합니다.
- 복제본으로 처리량 확장.
- 하드웨어 경계를 허물고 메모리를 더 세분화된 수준으로 분할하여 리소스 활용도를 개선합니다.
공동 호스팅 아키텍처를 성공적으로 구현하려면 다음 기술 워크플로를 사용하는 것이 좋습니다.
- 명시적 파티셔닝:
--gpu-memory-partitions인수를 사용하여 개별 모델에 메모리 리소스를 할당합니다. - 반복적 벤치마크: 제공된 벤치마크 유틸리티를 활용하여 워크로드의 특정 '동시 실행 교차점'(인스턴스 수, TP, PP의 '스위트 스폿' 구성)을 식별합니다.
Google Cloud Model Garden에서 공동 호스팅을 구현하면 고밀도 AI 애플리케이션을 빌드하기 위한 확장 가능한 청사진이 제공됩니다. 개발자는 이러한 기능을 살펴보고 제공된 튜토리얼 노트북 을 사용하여 벤치마크를 재현하여 특정 엔터프라이즈 요구사항에 맞게 서빙 구성을 최적화하는 것이 좋습니다.
읽어 주셔서 감사합니다.
Vertex AI에 대한 의견이나 질문이 있으면 언제든지 알려주시기 바랍니다.
감사의 말씀
Google Cloud Vertex AI팀에 진심으로 감사드립니다. 특히 Bo Wu와 Ting Yu의 리더십과 안내, 그리고 Deborah He, Shawn Ma, Desmond Liu, Yang Pan, Surya K G Tangatur, Luis Rizo의 귀중한 기여에 감사드립니다.