본문으로 건너뛰기

Ray Serve DLC로 TorchServe 추론 환경을 EKS에 배포하기

Ray Serve DLC가 CUDA와 PyTorch 의존성을 묶어 Qwen3-VL-2B를 Amazon EKS에서 GPU 추론 서비스로 실행합니다.

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

TorchServe는 더 이상 업데이트, 버그 수정, 새 기능, 보안 패치를 받지 않으므로 운영팀이 CUDA와 PyTorch를 포함한 전체 의존성 호환성을 직접 관리해야 합니다. AWS의 Ray Serve DLC는 Amazon Linux 2023, CUDA 런타임, PyTorch, Ray Serve, FastAPI, Uvicorn과 멀티모달 처리 도구를 검증된 하나의 컨테이너 이미지로 묶고 빌드 시점에 보안 패치를 반영합니다. 글에서는 이 GPU 이미지를 Amazon EKS의 단일 g5.xlarge 노드에 배포하고, ConfigMap으로 주입한 Python 코드가 24GB VRAM의 NVIDIA A10G에서 Qwen3-VL-2B를 HTTP 포트 8000으로 제공합니다. Ray Serve는 모델 클래스를 @serve.deployment로 등록하고 num_gpus=1 설정에 따라 GPU worker에 배치하며, 더 큰 규모에서는 KubeRay를 이용해 여러 노드로 확장할 수 있습니다.

섹션별 상세

01
TorchServe는 공식 프로젝트 차원에서 업데이트, 버그 수정, 새 기능과 보안 패치가 예정되지 않아 최신 PyTorch와 CUDA에 맞춘 호환성 관리가 사용자 몫으로 남습니다. 운영팀은 GPU 스택의 버전을 맞추고 각 계층의 취약점을 패치하며 구성요소 간 불일치로 생기는 오류까지 직접 추적해야 합니다. Ray Serve DLC는 AWS가 테스트하고 유지하는 사전 구성 이미지로 이 의존성 조립 작업을 줄여 모델 제공에 집중할 기반을 마련합니다.
02
Ray Serve DLC의 CPU 이미지는 Amazon Linux 2023을 기반으로 하고 GPU 이미지는 CUDA 런타임 라이브러리를 포함한 NVIDIA Amazon Linux 2023 이미지 위에 구성됩니다. 여기에 PyTorch, Ray Serve, FastAPI, Uvicorn, Transformers와 NVIDIA 하드웨어 가속이 적용된 FFmpeg가 함께 들어가며, 릴리스 전에 CUDA 런타임과 프레임워크, serving 계층의 조합을 검증합니다. EKS와 EC2, SageMaker용 이미지는 실행 환경에 맞는 entrypoint를 사용하면서 공통 스택과 의존성을 공유합니다.
python
from ray import serve
from transformers import AutoModelForImageTextToText, AutoProcessor
import torch

@serve.deployment(ray_actor_options={"num_gpus": 1})
class QwenVLService:
    def __init__(self):
        model_name = "Qwen/Qwen3-VL-2B-Instruct"
        self.processor = AutoProcessor.from_pretrained(model_name)
        self.model = AutoModelForImageTextToText.from_pretrained(
            model_name, torch_dtype=torch.float16
        ).to("cuda")

    async def __call__(self, request):
        try:
            body = await request.json()
            image_url = body.get("image_url")
            prompt = body.get("prompt")

            messages = [{"role": "user", "content": [
                {"type": "image", "image": image_url},
                {"type": "text", "text": prompt},
            ]}]

            inputs = self.processor.apply_chat_template(
                messages,
                tokenize=True,
                add_generation_prompt=True,
                return_dict=True,
                return_tensors="pt"
            ).to("cuda")

            generated_ids = self.model.generate(**inputs, max_new_tokens=200)
            trimmed = [o[len(i):] for i, o in zip(inputs.input_ids, generated_ids)]
            output = self.processor.batch_decode(trimmed, skip_special_tokens=True)[0]
            return {"response": output}
        Except Exception:
            logger.exception("Qwen inference request failed")
            return {"error": "Unable to generate a response. Please try again later."}

app = QwenVLService.bind()

Qwen3-VL-2B를 CUDA GPU에 올리고 이미지 URL과 text prompt를 받아 HTTP 응답을 생성하는 Ray Serve deployment 코드입니다.

03
이 글의 serving 코드는 TorchServe의 model archiver, custom handler, properties 파일 대신 Ray Serve의 Python 클래스와 @serve.deployment를 사용합니다. 요청에서 image_url과 prompt를 읽어 chat template로 입력을 만들고, Qwen3-VL-2B가 CUDA에서 최대 200개의 새 토큰을 생성한 뒤 기존 입력 토큰을 잘라 자연어 응답으로 반환합니다. ray_actor_options={"num_gpus": 1} 설정은 해당 deployment를 GPU 한 개를 사용할 수 있는 Ray worker에 배치하며, float16 로딩은 24GB VRAM의 NVIDIA A10G에 맞춘 구성입니다.
04
배포 구조는 NVIDIA A10G 한 개를 탑재한 g5.xlarge 단일 노드와 모델 serving pod 한 개로 구성되며, pod는 HTTP 포트 8000에서 요청을 받습니다. deploy_cluster.sh가 EKS와 VPC, OIDC 기반 pod 인증을 만들고 deploy_node_group.sh가 GPU 노드를 추가한 뒤 deploy_ray_cluster.sh가 ConfigMap과 Kubernetes Deployment를 적용해 Ray Serve를 시작합니다. kubectl port-forward로 로컬 요청을 전달하고 curl로 이미지 설명을 요청하며 nvidia-smi로 GPU 할당을 확인할 수 있지만, pod가 Ready가 된 뒤에도 모델 로딩 때문에 응답까지 1~2분이 더 걸릴 수 있습니다.
AWS VPC의 private subnet 안에 있는 Amazon EKS 클러스터와 Ray Serve Head pod, 외부의 Amazon ECR Public 이미지 저장소를 연결한 배포 구조도입니다.
Diagram다이어그램은 사용자가 kubectl port-forward로 EKS 내부의 Ray Serve Head에 접근하고, Ray Serve DLC가 Amazon ECR Public에서 이미지를 가져오는 흐름을 나타냅니다. 본문에서 설명한 단일 GPU 노드 기반 serving 구조와 ConfigMap을 포함한 Ray Serve 배포 경로를 시각적으로 보완합니다.
05
단일 노드 구성을 여러 노드의 model parallelism이나 수평 autoscaling으로 확장하려면 KubeRay 위에 Ray worker를 추가하는 구조가 필요합니다. 현재 예제는 ConfigMap으로 qwen_serve.py를 컨테이너에 주입하므로 serving 코드를 바꿀 때 이미지를 다시 빌드하지 않아도 되며, 추가 라이브러리가 필요한 모델은 테스트된 DLC 기반에 계층을 더할 수 있습니다. 결과적으로 버전 변경은 새 이미지 tag를 선택하는 작업으로 단순화되고, AWS가 관리하는 보안 패치와 검증된 추론 스택을 활용할 수 있습니다.

용어 해설

Deep Learning Containers
프레임워크, 라이브러리, CUDA 런타임, 운영체제 구성요소를 함께 묶은 사전 제작 Docker 이미지입니다. 각 구성요소의 호환성을 테스트하고 보안 패치를 반영해, 사용자가 GPU 추론 환경을 직접 조립하는 부담을 줄입니다.
Ray Serve
Python 코드로 모델 추론 API를 구성하고 HTTP 엔드포인트로 제공하는 serving 프레임워크입니다. @serve.deployment로 모델 클래스를 배포 단위로 만들고, Ray가 GPU 같은 자원에 작업을 배치합니다.
ConfigMap
Kubernetes에서 애플리케이션 코드나 설정을 컨테이너 이미지와 분리해 저장하는 리소스입니다. 이 글에서는 qwen_serve.py를 ConfigMap으로 주입해 이미지를 다시 빌드하지 않고 serving 코드를 바꿉니다.
KubeRay
Kubernetes 환경에서 Ray 클러스터와 작업을 운영하기 위한 구성요소입니다. 단일 노드 배포를 여러 GPU 노드와 복수 replica 구조로 확장할 때 Ray worker의 배치와 실행을 조정합니다.

기술

  • Ray Serve DLC
  • TorchServe
  • Ray Serve
  • PyTorch
  • FastAPI
  • Uvicorn
  • FFmpeg
  • Transformers
  • Amazon EKS
  • Amazon EC2
  • Amazon SageMaker
  • KubeRay
  • AWS CLI
  • eksctl
  • kubectl
  • Qwen3-VL-2B
  • NVIDIA A10G
  • CUDA

활용 사례

  • Amazon EKS에서 vision-language model 추론 API 운영
  • 단일 GPU 노드 기반 HTTP 모델 serving
  • TorchServe에서 Ray Serve DLC로 마이그레이션
  • KubeRay를 활용한 다중 노드 분산 serving
AI 분석 전체 내용 보기

AI 요약 · 북마크 · 개인 피드 설정 — 무료

출처 · 인용 안내

원문 발행 2026. 09. 10.수집 2026. 09. 10.출처 타입 RSS

인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.