GPUStack v2.2: 모델 서빙에서 토큰 연산으로, 컴퓨팅 풀링에서 GPU-as-a-Service로

모델을 배포하고 온라인 상태로 만드는 것은 AI 서비스 제공의 시작점에 불과합니다.

대규모 언어 모델 (LLM) 애플리케이션이 확장된 프로덕션 단계로 이동함에 따라, AI 인프라는 단순히 실행할 수 있는 단계를 넘어 운영 준비가 된 (operations-ready) 단계로 진입하는 필연적인 성숙기에 접어들고 있습니다.

이러한 변화는 단순히 더 많은 기능을 추가하는 것만을 의미하지 않습니다. 이는 플랫폼 포지셔닝의 진화를 반영합니다. 즉, 추론 워크로드 (inference workloads)를 안정적으로 서빙하는 것에서 벗어나, 기업의 AI 서비스 제공을 진정으로 지원할 수 있는 **인프라 기반 (infrastructure foundation)**이 되는 과정입니다.

이 단계에서 핵심 과제는 두 가지 영역을 병행하여 발전시키는 데 있습니다. 모델 서빙은 운영 등급의 **신뢰성 (reliability)**과 **가시성 (visibility)**을 제공해야 하며, 컴퓨팅 관리 (compute management)는 "추론 워크로드 서빙"에서 "AI에 필요한 다양한 리소스의 통합 할당"으로 확장되어야 합니다.

GPUStack v2.2는 이 두 방향 모두에서 더욱 깊이 나아가고 있습니다. 모델 서빙은 사용 가능한 (available) 상태에서 운영 준비가 된 (operations-ready) 상태로 진화하고 있으며, 컴퓨팅 관리는 **통합 스케줄링 (unified scheduling)**에서 **온디맨드 서비스 (on-demand services)**로 확장되고 있습니다.

모델 추론 시나리오 및 라이프사이클 관리 지원 심화

모델 서빙의 안정성은 단순히 배포 단계만의 문제가 아닙니다. 인스턴스가 실행을 시작한 후에는 OOM 에러 (OOM errors), 추론 요청 중단 (hanging inference requests), 그리고 **프로세스 무단 종료 (silent process crashes)**와 같은 문제들이 프로덕션 환경에서 더 흔하게 발생하는 문제입니다.

이전에는 GPUStack의 상태 확인 (health checks)이 주로 **시작 단계 (startup phase)**를 다루었습니다. 인스턴스가 성공적으로 시작되고 나면, 플랫폼은 이후에 발생하는 문제를 감지할 방법이 없었습니다. 결함이 있는 인스턴스가 서비스 풀에 남아 계속해서 트래픽을 받을 수 있었고, 이는 누군가 이를 인지하고 수동으로 처리할 때까지 **침묵하는 실패 (silent failures)**로 이어졌습니다.

v2.2에서는 헬스 프로빙 (health probing) 기능이 **전체 런타임 생명주기 (entire runtime lifecycle)**로 확장되었습니다. 플랫폼은 각 인스턴스의 실제 추론 능력을 지속적으로 점검합니다. 비정상적인 인스턴스가 감지되면 즉시 서비스 풀 (service pool)에서 제거되고 자동으로 재시작됩니다. 복구되면 자동으로 다시 추가됩니다. 이제 서비스 가용성은 수동 점검이나 사용자 보고에 의존하는 대신, 플랫폼에 의해 선제적으로 유지됩니다.

문제 해결 (troubleshooting) 기능 또한 체계적으로 강화되었습니다. 프로덕션 환경에서 팀들이 가장 필요로 하는 것은 장애 발생 당시 어떤 일이 일어났는지에 대한 완전한 기록입니다. 이전에는 터미널에 로그인하여 수동으로 로그를 확인해야 했습니다. v2.2는 세 가지 유형의 로그 액세스를 도입합니다:

재시작 전 과거 로그 (Historical logs before restart): 인스턴스가 충돌한 후 과거의 장애 로그에 대한 접근 권한을 잃는 대신, 충돌 전의 전체 출력을 확인할 수 있습니다.

분산 서브 인스턴스 로그 (Distributed sub-instance logs): 멀티 노드 배포 (multi-node deployments) 환경에서 각 노드의 출력을 개별적으로 검사하여 문제가 발생한 위치를 빠르게 식별할 수 있습니다.

Ray 컨테이너 로그 (Ray container logs): 터미널 명령어를 통한 문제 해결 없이 UI에서 직접 Ray 컨테이너 로그를 확인할 수 있습니다.

이제 대부분의 프로덕션 문제 해결 워크플로우를 GPUStack UI 내에서 엔드 투 엔드 (end to end)로 완료할 수 있습니다.

분산 추론 (distributed inference)을 위해, v2.2는 **vLLM MP 자동 분산 모드 (vLLM MP auto-distributed mode)**를 도입했습니다.

이전에는 GPUStack이 Ray 기반의 자동 분산 vLLM 배포만 지원했습니다. MP 기반의 분산 배포는 수동으로 구성해야 했으며, GPUStack이 모든 분산 인스턴스를 자동으로 실행할 수 없었습니다.

vLLM의 급격한 발전과 함께, 새로운 MP (Model Parallelism) 기반의 분산 모드는 운영 오버헤드(operational overhead)와 추론 성능(inference performance) 측면에서 Ray 기반의 자동 분산 배포(auto-distributed deployments)보다 명확한 이점을 제공합니다.

이제 사용자들은 자신의 요구 사항에 가장 적합한 vLLM 자동 분산 배포 전략을 선택할 수 있습니다.

또 다른 주목할 만한 업데이트는 Multi-LoRA 지원입니다.

엔터프라이즈 환경에서는 다양한 비즈니스 시나리오에 맞춰 모델을 미세 조정(fine-tuning)하는 것이 일반적인 요구 사항입니다. 이전에는 각 **LoRA 어댑터 (LoRA Adapter)**가 별도의 모델 인스턴스로 실행되어야 했으므로, 작업 수가 늘어남에 따라 **GPU 메모리 오버헤드 (GPU memory overhead)**가 선형적으로 증가하고 상당한 리소스 낭비가 발생했습니다.

v2.2에서는 여러 LoRA 어댑터를 **동일한 베이스 모델 인스턴스 (same base model instance)**에 마운트하고 동적으로 전환할 수 있습니다. 이를 통해 동일한 하드웨어에서 더 많은 미세 조정된 작업을 지원할 수 있으며, **GPU 메모리 활용도 (GPU memory utilization)**를 크게 향상시킬 수 있습니다.

모델 서비스를 위한 토큰 사용 거버넌스 (Token Usage Governance)

모델이 실행 중일 수는 있지만, 토큰이 정확히 어디에서 소비되고 있을까요? 사용량이 제한적인 초기 단계에서는 이 질문이 명확하지 않을 수 있습니다. 하지만 여러 팀과 애플리케이션이 동일한 플랫폼을 공유하기 시작하면, 이는 빠르게 운영상의 고충(pain point)이 됩니다.

GPUStack은 이전에 모델 (model) 및 **사용자 (user)**별 사용 통계를 지원하여 팀이 전반적인 소비 트렌드를 이해할 수 있도록 도왔습니다.

하지만 이 두 가지 차원만으로는 정확한 귀속(attribution)을 수행하기에 충분하지 않았습니다.

서로 다른 애플리케이션과 사업부가 동일한 사용자 계정 아래에서 여러 키를 공유할 때, 사용량을 명확하게 분리할 수 없어 비용 회계(cost accounting)를 수행하기 어렵습니다.

v2.2는 API 키(API Key) 수준의 사용 통계를 도입합니다. 각 키에 대한 토큰 소비량이 **독립적으로 측정(metered independently)**되므로, 관리자는 어떤 호출자가 무엇을 얼마나 소비하고 있는지 명확하게 확인할 수 있습니다. 이는 팀 간 비용 귀속(cost attribution) 및 **할당량 관리(quota management)**를 위한 직접적인 근거를 제공합니다.

또 다른 중요한 변화는 사용자에게 가시성을 다시 돌려주는 것입니다. 이전에는 자신의 소비량을 이해하려는 사용자가 관리자에게 데이터를 추출해 달라고 요청해야 했습니다.

v2.2는 사용자 측면에서 셀프 서비스 방식의 개인 사용량 조회를 도입합니다. 이제 모델별, 시간 범위별 소비 이력을 요청 프로세스를 거치지 않고 UI에서 직접 확인할 수 있습니다.

측정(metering) 기능이 갖춰지면, 토큰 소비는 더 이상 **블랙박스(black box)**가 아닙니다. 이는 할당량 배분(quota allocation), 내부 비용 청구(internal chargeback), 그리고 **비용 분석(cost analysis)**을 지원할 수 있는 운영 데이터가 됩니다.

강화된 프로덕션 배포 역량

플랫폼의 역량은 견고한 배포 경험이 뒷받침될 때에만 온전히 실현될 수 있습니다. v2.2에서 GPUStack은 세 가지 영역에 걸쳐 엔터프라이즈 프로덕션 배포의 주요 격차를 해소합니다.

Kubernetes는 엔터프라이즈 인프라의 주류 선택지가 되었습니다. 하지만 이전에는 K8s 환경에 GPUStack을 배포하기 위한 표준화된 클라우드 네이티브 (cloud-native) 경로가 부족했습니다.

v2.2는 공식 Helm Chart를 제공하여, Helm을 통해 단일화된 간소화된 프로세스로 설치 및 구성을 가능하게 합니다. 이를 통해 GPUStack은 기존의 GitOps 워크플로 (workflows) 및 CI/CD 시스템에 직접 통합될 수 있으며, 배포 및 업그레이드의 운영 비용을 크게 절감합니다.

v2.2는 또한 OceanBase 및 openGauss에 대한 지원을 통해 데이터베이스 호환성을 확장하여, 팀들에게 엔터프라이즈 배포 환경에서 더 많은 유연성을 제공합니다.

네트워크 토폴로지 (network topology) 측면에서, v2.2는 Worker-to-Server 단방향 액세스 모드를 지원합니다.

리전 간(cross-region) 또는 네트워크 경계 간(cross-network-boundary) 배포 시나리오에서는 많은 환경에서 Server와 Worker 사이의 양방향 연결을 설정하는 것이 어렵습니다.

단방향 네트워킹을 사용하면 Worker 노드는 Server에 액세스하기만 하면 되며, Server는 역방향 연결을 시작할 필요가 없습니다. 이는 멀티 리전 클러스터의 통합 관리를 위한 핵심적인 네트워킹 장벽을 제거합니다.

컴퓨팅 풀링에서 GPU 서비스로

이기종 컴퓨팅 리소스의 통합 스케줄링 (unified scheduling)은 항상 GPUStack의 핵심 역량 중 하나였습니다. 즉, 서로 다른 벤더와 서로 다른 사양을 가진 GPU들을 단일 컴퓨팅 풀 (compute pool)로 가져와 통합 스케줄링 및 모니터링을 수행하는 것입니다. 그러나 이전에는 이 컴퓨팅 풀이 주로 하나의 시나리오, 즉 **추론 (inference)**만을 위해 사용되었습니다.

데이터 과학자들은 종종 **대화형 개발 환경 (interactive development environment)**이 필요하며, 알고리즘 엔지니어들은 실험 및 디버깅을 위해 **전용 GPU (dedicated GPUs)**가 필요할 수 있습니다. 많은 팀에서 이러한 요구사항은 GPUStack 외부의 별도 시스템을 통해 처리되었으며, 이는 파편화된 리소스 할당 및 과금 (resource allocation and metering) 결과로 이어졌습니다.

v2.2는 **GPU 인스턴스 서비스 (GPU Instance Service)**를 도입하여, "격리된 GPU 환경을 할당하는" 프로세스를 통합된 플랫폼 관리 하에 가져왔습니다.

사용자는 온디맨드(on demand)로 격리된 GPU 인스턴스를 요청할 수 있으며, GPU 제조사, 모델 및 수량을 지정하고 스토리지 마운트(storage mounts)와 포트 설정(port configurations)을 포함하는 런타임 템플릿(runtime templates)을 선택할 수 있습니다. 인스턴스가 준비되면 SSH 또는 웹을 통해 접속할 수 있습니다.

사용량은 플랫폼에 의해 중앙에서 측정(metered)되며, 추론 서비스 (inference services)와 동일한 스케줄링 및 사용 시스템을 공유합니다.