[Paper] HPC 인프라스트럭처에서 자동 동적 AI 추론 스케일링: Kubernetes, Slurm 및 vLLM 통합

Source: arXiv - 2511.21413v1

Overview

이 논문은 vLLM(고속 LLM 서빙 엔진), Slurm(슈퍼컴퓨터의 사실상 배치 스케줄러), 그리고 Kubernetes(개발자가 이미 익숙한 컨테이너 오케스트레이션 플랫폼)라는 세 가지 인기 오케스트레이션 도구를 결합해 전통적인 고성능 컴퓨팅(HPC) 클러스터에서 대규모 언어 모델(LLM) 추론을 실행할 수 있는 프로토타입을 제시합니다. 저자들은 이 하이브리드 스택이 수백에서 천 개에 이르는 동시 사용자 요청을 처리하면서도 추가 지연이 약 500 ms에 불과함을 보여주어, 기존 HPC 자원을 저지연 사용자‑대면 AI 서비스에 재활용할 수 있음을 입증합니다.

Key Contributions

• Hybrid orchestration layer – Slurm과 Kubernetes를 새롭게 통합해 HPC 노드를 클라우드‑네이티브 풀처럼 관리하면서도 배치 스케줄러의 할당 정책을 그대로 유지합니다.
• vLLM‑centric serving – 고처리량 vLLM 추론 엔진을 HPC 컨테이너 내부에 삽입해 텐서‑패러렐리즘 및 모델‑셔딩을 여러 노드에 걸쳐 구현합니다.
• Dynamic scaling logic – 실시간 요청량에 따라 vLLM 파드를 자동으로 증감시키는 컨트롤러를 제공, 100, 500, 1 000개의 동시 쿼리에 대해 거의 선형적인 확장을 달성합니다.
• End‑to‑end benchmark – RAMSES 슈퍼컴퓨터에서 지연시간, 처리량, 오버헤드를 정량적으로 평가해 순수 클라우드 배포 대비 약 0.5 s의 추가 지연만 발생함을 보여줍니다.
• Open‑source reference implementation – 저자들은 다른 기관이 자체 Slurm 기반 클러스터에서 동일한 설정을 재현할 수 있도록 스크립트와 Helm 차트를 공개합니다.

Methodology

1. Environment Setup – GPU가 장착된 RAMSES HPC 클러스터는 자원 할당을 위해 Slurm을 사용합니다. 가벼운 Kubernetes 컨트롤 플레인은 헤드 노드에 배포되고, 각 컴퓨트 노드는 Kubernetes 워커로 등록되는 Kubelet을 실행합니다.
2. Containerization – vLLM 서버, 종속성 및 LLM 모델 파일을 Docker 이미지에 패키징하고, 클러스터에서 접근 가능한 사설 레지스트리에 저장합니다.
3. Scheduling Bridge – 사용자 요청이 REST 엔드포인트를 통해 들어오면 Slurm‑to‑Kubernetes 브릿지가 Slurm 작업을 생성해 GPU를 예약하고, 해당 작업에 맞는 Kubernetes 파드(vLLM)를 실행합니다.
4. Dynamic Autoscaling – 컨트롤러가 요청 지연시간과 큐 깊이를 모니터링합니다. 큐가 임계값을 초과하면 추가 Slurm 할당을 요청해 더 많은 vLLM 파드를 띄우고, 수요가 감소하면 파드를 정상적으로 종료해 GPU를 Slurm에 반환합니다.
5. Benchmarking – 저자들은 7B 파라미터 LLM에 대해 100, 500, 1 000개의 동시 HTTP 요청을 합성 워크로드로 생성하고, 최종 지연시간(클라이언트 → API 게이트웨이 → vLLM → GPU)을 기록합니다. 이를 Slurm 없이 전용 Kubernetes 클러스터에서 실행한 vLLM 기준선과 비교합니다.

Results & Findings

• Scalability – 지연시간이 서브라인 형태로 증가하여, 네트워크나 GPU 메모리를 포화시키지 않고도 천 개의 동시 쿼리를 지속할 수 있습니다.
• Overhead – 약 500 ms의 추가 지연은 주로 Slurm‑Kubernetes 전환 및 컨테이너 시작에 기인하며, 파드가 워밍업된 이후에는 요청당 비용이 네이티브 클라우드 배포와 비슷합니다.
• Resource Utilization – 피크 부하 시 GPU 활용도가 85 % 이상에 달해, HPC 클러스터에서 흔히 사용되는 정적 할당 전략보다 훨씬 효율적입니다.

Practical Implications

• Leverage Existing HPC Investments – 대학·연구소는 별도의 추론 클러스터를 구매하지 않고도 GPU‑집약형 슈퍼컴퓨터를 AI 웹 서비스에 노출시킬 수 있습니다.
• Cost‑Effective AI SaaS – 배치‑스케줄링 자원을 재사용함으로써 조직은 학생·연구원·내부 도구에 저지연 LLM API를 제공하면서 실제 사용량에만 비용을 지불하면 됩니다.
• Developer‑Friendly Ops – Kubernetes 외피 덕분에 개발자는 익숙한 kubectl, Helm 차트, CI/CD 파이프라인을 사용할 수 있고, HPC 관리자는 Slurm 정책(공정‑공유, 할당량, 회계)을 통해 제어권을 유지합니다.
• Hybrid Cloud Edge Cases – 온프레미스 HPC 큐가 포화될 경우 클라우드로 AI 워크로드를 버스트할 수 있어, 온프레미스·오프프레미스 추론 연속성을 매끄럽게 구현할 수 있습니다.
• Standardization Path – 브릿지 코드와 Helm 차트는 다른 HPC 센터가 AI 서비스를 외부에 제공하기 위한 레퍼런스 구현이 될 수 있어, “HPC‑as‑a‑service” 형태의 AI 채택을 가속화합니다.

Limitations & Future Work

• Model Size Boundaries – 평가에 사용된 7B 파라미터 모델을 넘어 70B 이상 모델로 확장하면 현재 GPU 노드의 메모리 한계에 부딪히고, 보다 정교한 텐서‑패러렐리즘이 필요합니다.
• Cold‑Start Penalty – ~500 ms 오버헤드의 대부분은 파드 시작 및 모델 로딩에 소요되므로, 워밍된 파드를 캐시하거나 “웜 풀”을 활용하면 이를 감소시킬 수 있습니다.
• Security & Multi‑Tenant Isolation – 현재 프로토타입은 신뢰된 내부 네트워크를 전제로 하므로, 다중 테넌트 공개 API로 확장하려면 파드 보안 정책, 네트워크 샌드박싱 등 강력한 격리가 필요합니다.
• Scheduler Complexity – Slurm과 Kubernetes 두 스케줄러를 동시에 운영하면 운영 부담이 늘어나므로, 향후에는 더 긴밀한 통합 또는 통합 API 레이어를 탐색할 수 있습니다.
• Broader Benchmarks – 실제 워크로드(예: 검색‑증강 생성, 멀티모달 추론)와 이종 하드웨어(TPU, 최신 GPU)에서의 성능 검증이 남아 있습니다.