GPUWorks가 40MB 하나로 이기종 GPU 클러스터를 서빙 플랫폼으로 묶는다

GPUWorks는 여러 대의 GPU 서버를 하나의 클러스터로 묶어 vLLM·SGLang 같은 추론 엔진을 OpenAI 호환 API 뒤에 세워주는 관리·서빙 플랫폼이다. 눈에 띄는 건 덩치다. 웹 UI까지 포함한 컨트롤 플레인이 40MB 안팎의 배포본 하나로 끝나고, 쿠버네티스는 필요하지 않다.

설치 절차도 짧다. 리눅스 호스트(x86_64 또는 arm64)나 애플 실리콘 맥에서 스크립트 한 줄을 실행하면 8800번 포트에 서비스가 등록되고 접속 주소와 초기 관리자 비밀번호가 출력된다. GPU 노드는 웹 UI가 만들어주는 명령을 해당 장비에서 실행하면 합류한다. 서버와 에이전트는 각각 CGO_ENABLED=0으로 빌드된 정적 바이너리 하나이고, 서버는 웹 UI(영어·중국어)와 플랫폼별 에이전트를 품은 채 상태를 SQLite 파일 하나에 담는다. 에이전트가 WebSocket으로 밖으로 접속하는 구조라 노드에 인바운드 포트를 열 필요가 없고, 반대로 외부로 나갈 수 없는 망에서는 서버가 직접 접속하는 방식도 지원한다.

가장 차별적인 지점은 가속기 혼합이다. NVIDIA, AMD Instinct와 라이젠 AI Max, 화웨이 Ascend, T-Head PPU, 하이곤 DCU, 애플 실리콘(M1~M5, macOS 15 이상)이 같은 클러스터에 나란히 들어간다. GPU 탐지는 nvidia-smi, npu-smi, ppu-smi, hy-smi 같은 벤더 CLI와 AMD의 경우 amdgpu sysfs·KFD를 활용해 NVML이나 cgo 의존을 없앴다. 컨테이너 런타임은 도커, containerd, 또는 자체 루트리스 런타임인 runveil을 쓴다. 엔진은 vLLM(vLLM-Ascend, vLLM-Omni 포함)과 SGLang, 맥에서는 vllm-metal·MLX-VLM·MLX-Audio·llama.cpp까지 포괄한다.

모델 배포는 카탈로그에서 고르는 데서 시작한다. 392개 모델에 대해 1,235개의 런치 스펙을 내장하고 있고, 각 스펙에는 이미지, 엔진, 플래그, 고정된 가중치 리비전이 GPU 종류별로 지정돼 있다. 실제 NVIDIA·AMD·Ascend·PPU·애플 하드웨어에서 돌려본 조합에는 동작이 확인된 설정이 붙는다. 배포 전에는 가중치와 KV 캐시, 엔진 오버헤드가 GPU 메모리를 얼마나 요구하는지 추정치를 보여주고, 스케줄러가 어떤 GPU를 골랐는지 그리고 나머지 후보가 왜 탈락했는지도 함께 설명한다. 한 장의 GPU를 여러 모델이 나눠 쓰는 dGPU 모드도 있는데, 인스턴스마다 MiB 단위로 메모리 쿼터를 강제하며 NVIDIA는 HAMi-core, Ascend는 vCANN, PPU는 HGGC, 하이곤은 hy-smi 가상 디바이스를 쓴다. sleep/wake로 vLLM 모델들이 같은 GPU를 번갈아 쓰는 기능은 NVIDIA·Ascend 910C·PPU ZW810E·하이곤 K100·AMD MI300X에서 검증됐다.

규모에 대한 주장도 구체적이다. 알리바바 클라우드에서 진행한 드릴 테스트에서 서버 한 대가 7개 리전에 흩어진 임대 GPU 머신 1,003대를 관리했고, 500개 넘는 레플리카를 4분 안에 배치·기동했으며, 게이트웨이로 2,000건의 동시 요청을 처리하는 동안 서버 CPU 사용량은 최대 9코어 수준이었다.

운영 기능도 두텁다. 노드를 넘나드는 레플리카 확장, 멀티노드 텐서·파이프라인 병렬, 프리필/디코드 분리(NVIDIA의 vLLM+NIXL, Ascend의 vLLM-Ascend+문케이크, PPU의 SGLang 또는 vLLM+문케이크, 하이곤의 실험적 vLLM+문케이크)를 지원한다. 게이트웨이는 /v1 아래 채팅, 임베딩, 리랭크, 오디오, 이미지, 비디오, 리얼타임을 OpenAI 호환으로 노출하고 /v1/messages와 /v1/responses는 그대로 통과시키며, 최소 요청 수·프리픽스 친화·페일오버 라우팅을 제공한다. GPU와 엔진 메트릭, 검색 가능한 로그, 요청별 타임라인 트레이스(OTLP 내보내기), 호스트·컨테이너로 들어가는 웹 터미널, 동시성을 훑어 SLA 한계를 찾는 내장 벤치마크도 포함된다. UI에서 클러스터에 대해 질문하거나 Claude Code 같은 MCP 클라이언트를 붙일 수 있고, 폐쇄망을 위해 아카이브나 HTTP 파일 서버에서 이미지·모델을 가져와 노드 간에 동기화하는 경로도 마련돼 있다.

이런 도구가 등장한 배경에는 GPU 인프라 운영의 현실이 있다. 추론 서버 한 대를 띄우는 일 자체는 어렵지 않지만, 클라우드마다 다른 인스턴스를 끌어오고 남는 온프레미스 장비를 붙이고 세대가 다른 가속기를 섞는 순간 쿠버네티스와 GPU 오퍼레이터, 드라이버 조합을 관리하는 일이 금세 본업이 된다. GPUWorks는 그 계층을 40MB짜리 바이너리와 SQLite 파일 하나로 대체하겠다고 나선다. 용량 풀은 베어메탈 서버, 퍼블릭 클라우드 인스턴스, 프라이빗 클라우드 VM을 아우르며 RunPod, CompShare, AutoDL, Vast.ai, 알리바바 클라우드 인스턴스와 ZStack VM을 에이전트 설치 한 번으로 같은 풀에 넣을 수 있다.

실무적으로는 소규모 팀이 유휴 GPU를 굴리는 시나리오가 가장 현실적이다. 모델을 고르고 배포 버튼을 누르면 곧바로 OpenAI 호환 엔드포인트가 나오므로, 엔진 플래그와 이미지 태그를 조합하던 시간이 줄어든다. 여러 클라우드를 오가며 GPU를 조달하는 팀이라면 벤더별 콘솔을 하나의 스케줄러 아래로 모을 수 있다는 점이 크다.

다만 원문이 명시한 전제는 확인해야 한다. 쿠버네티스 클러스터와 Slurm 파티션을 용량 풀에 합류시키는 것은 아직 다음 단계이고, 파인튜닝·학습 작업도 예정된 기능이다. 지원 매트릭스에는 검증 완료, 실험적, 미검증 조합이 구분돼 있으니 도입 전에 자신의 가속기 조합이 어디에 속하는지 봐야 한다. 웹 UI가 영어와 중국어만 제공된다는 점도 국내 팀에는 변수다.