0. GPUStack의 자리

문제는 GPU가 여러 개 있다는 사실이 아니라 여러 곳의 실행 상태를 사람이 기억해야 한다는 것이다

이 장에서 처음 나오는 말4개

관리 평면Control plane

원하는 상태를 받아 실제 상태를 맞추는 중앙 부분. GPUStack Server와 scheduler가 여기에 속한다.

workerWorker node

모델 컨테이너가 실제로 실행되는 노드. 이 덱에서는 DGX Spark 한 대가 worker 하나다.

deploymentModel deployment

어떤 모델을 어떤 backend·설정·replica 수로 계속 실행할지 적은 원하는 상태다.

replicaReplica

같은 모델을 독립적으로 실행하는 복제본. 다른 replica가 살아 있으면 한 노드 장애에도 요청을 계속 받을 수 있다.

먼저 생기는 운영 문제

Spark가 한두 대일 때는 SSH와 docker run으로 충분하다. 대수가 늘면 같은 방식이 다음 질문에 답하지 못한다.

질문	수동 Docker만 쓸 때	GPUStack이 맡을 자리
모델 A는 지금 어디에 떠 있나	사람의 메모·문서	deployment와 instance 목록
노드가 죽었다 살아나면	운영자가 재실행	원하는 replica 수에 맞춰 재생성
같은 모델 두 개로 트래픽을 어떻게 나누나	별도 proxy 설정	model route와 gateway
새 모델이 어느 GPU에 들어가나	접속해서 메모리 확인	scheduler·selector·수동 GPU 선택
로그와 GPU 상태는 어디서 보나	노드마다 접속	중앙 로그 진입점과 metrics exporter
FastAPI 자체 모델은 어떻게 올리나	별도 배포 스크립트	custom backend + Generic Proxy

GPUStack의 가치는 vLLM을 실행하는 명령 자체보다 배포 상태를 데이터로 만들고 계속 맞추는 것에 있다.

GPUStack이 잘 맞는 범위

잘 맞는다

여러 Linux GPU 노드에 모델 서버를 배치한다.

vLLM·SGLang 같은 표준 backend를 주로 쓴다.

FastAPI 모델이 컨테이너 하나와 health endpoint로 닫힌다.

모델 단위 replica·route·재시작·관측이 필요하다.

Kubernetes 운영팀 없이 빠르게 시작해야 한다.

경계가 온다

학습 job의 queue·fair-share가 핵심이다.

서비스 하나가 DB·queue·sidecar·CronJob을 함께 요구한다.

복잡한 secret·network policy·GitOps·canary가 플랫폼 공통 요구다.

FastAPI 자체 backend가 여러 노드를 함께 써야 한다.

이 경우 Slurm 또는 Kubernetes/KServe의 문제에 가까워진다.

이 환경에서의 판단

이 덱이 가정하는 워크로드는 세 갈래다.

워크로드	기본 실행 단위	권장 backend	이용자 입구
LLM	Spark 1대, 예외적으로 2대 pair	GPUStack 내장 vLLM	LiteLLM
embedding	Spark 1대	우선 vLLM, 필요 시 FastAPI custom	OpenAI 호환이면 LiteLLM
classification	Spark 1대	FastAPI custom	GPUStack Generic Proxy 또는 사내 API Gateway

이 조합은 GPUStack의 중심 범위와 정확히 겹친다. Kubernetes가 더 많은 것을 할 수 있다는 사실은 선택 이유가 아니다. 이 구성에서 필요한 배포 단위가 모델 서버 컨테이너 하나이므로 그 단위를 직접 아는 GPUStack이 더 작은 운영 비용으로 문제를 푼다.

함정

GPUStack의 인증·API key 기능과 LiteLLM의 사용자 정책을 동시에 주인으로 만들지 않는다. 외부 사용자는 LiteLLM만 보고, GPUStack API는 내부망에 둔다. GPUStack key는 LiteLLM과 운영자만 가진다.

성공 조건을 먼저 적는다

도입 성공을 “UI에서 모델이 떴다”로 잡으면 안 된다. PoC는 다음 질문에 답해야 한다.

• worker 한 대를 재부팅했을 때 서비스가 언제 복구되는가
• 같은 모델 replica 둘 중 하나를 죽여도 기존 endpoint가 계속 응답하는가
• vLLM streaming과 LiteLLM timeout·retry가 함께 정상인가
• FastAPI /health 실패를 GPUStack이 감지하고 재시작하는가
• ARM64·GB10용 image를 digest로 고정해 다른 Spark에서도 같은 결과가 나는가
• 한 대와 두 대 pair의 처리량·첫 토큰 시간·장애 복구 차이가 측정됐는가

참고 자료

• GPUStack 공식 개요 — GPU cluster manager의 범위와 내장 backend.
• GPUStack 아키텍처 — server, worker, AI Gateway, scheduler의 역할.
• GPUStack 요구사항 — ARM64·Docker·NVIDIA worker 지원과 통신 포트.

1. 요청이 지나가는 길LiteLLM, GPUStack gateway, deployment와 worker가 각각 무엇을 알고 있는지 경계를 긋는다.