Simplify and support your TorchServe workloads using Ray Serve Deep Learning Containers

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

AWS는 유지보수가 중단된 TorchServe의 대안으로, 추론 스택을 사전 통합·검증하고 보안 패치를 관리하는 Ray Serve DLC와 Amazon EKS에서의 Qwen3-VL-2B 단일 GPU 배포 방법을 소개한다.

📌 핵심 요약

• TorchServe는 더 이상 적극적으로 유지보수되지 않으며, 공식 공지상 업데이트·버그 수정·신기능·보안 패치 계획이 없어 취약점이 해결되지 않을 수 있다.
• Ray Serve DLC는 PyTorch, CUDA 런타임, Ray Serve 등의 조합을 AWS가 릴리스 전에 검증하고 빌드 시 보안 패치를 적용하는 추론용 컨테이너로, CPU·GPU 및 실행 환경별 이미지가 제공된다.
• 예제는 Qwen3-VL-2B를 float16으로 로드하고 이미지 URL과 텍스트 프롬프트에 응답하는 HTTP 엔드포인트를 구현하며, ConfigMap으로 서빙 코드를 주입해 이미지 재빌드 없이 코드를 변경할 수 있게 한다.
• Amazon EKS 배포는 NVIDIA A10G GPU 1개와 24 GB VRAM을 갖춘 g5.xlarge 1대에서 파드 1개를 실행하고 포트 8000으로 제공하며, 다중 노드 분산 서빙에는 KubeRay를 활용하는 확장이 필요하다.
• 배포 후 파드 상태·GPU 할당·실제 추론을 확인해야 하며, 파드 Ready 표시가 실제 응답 가능 시점보다 1~2분 빠를 수 있다. 지속적인 과금을 피하려면 Ray Serve 배포, GPU 노드 그룹, EKS 클러스터 순으로 삭제한다.

🧩 주요 포인트

1. TorchServe의 유지보수 중단 → 운영팀이 떠안는 의존성 호환성·취약점 관리 부담을 AWS가 관리하는 Ray Serve DLC로 줄이는 이전 경로를 제시한다.
2. 검증된 추론 이미지와 ConfigMap 기반 코드 주입 → 공통 실행 환경을 활용하면서 모델 서빙 로직을 별도로 변경할 수 있고, 추가 라이브러리가 필요한 모델은 기본 이미지 위에 확장할 수 있다.
3. 단일 GPU 예제와 응답 준비 지연 → Amazon EKS 배포 성공은 실제 추론까지 확인해야 하며, 다중 노드 모델 병렬화나 여러 복제본의 수평 자동 확장은 KubeRay를 이용한 추가 구성이 필요하다.

🧠 상세 정리

1. TorchServe 유지보수 중단이 만드는 운영 부담

글은 TorchServe가 더 이상 적극적으로 유지보수되지 않는다는 공식 프로젝트 공지를 출발점으로 삼으며, 이를 기존 추론 서비스 운영팀이 대응해야 할 문제로 설명한다. 공지에는 업데이트, 버그 수정, 신기능, 보안 패치 계획이 없고 취약점이 해결되지 않을 수 있다는 내용이 포함된다. 이에 따라 새로운 PyTorch와 CUDA 버전에 맞춘 호환성 업데이트도 중단되어, 엔지니어가 GPU 스택 전반의 호환 가능한 버전을 직접 선택해야 한다. 각 계층의 취약점을 패치하고 구성 요소의 버전이 어긋날 때 발생하는 미묘한 장애를 디버깅하는 일도 운영팀의 책임으로 남는다. 저자들은 이러한 작업이 최종 제품의 가치를 높이지 않으면서 모델 제공 속도를 늦추는 부담이라고 보고, 관리되는 추론 컨테이너로 전환할 필요성을 제시한다.

2. 학습용 DLC의 관리 방식을 추론으로 확장

AWS Deep Learning Containers는 프레임워크와 의존성, GPU 스택을 검증되고 패치된 조합으로 묶은 사전 제작·성능 최적화 Docker 이미지이며, 기존에는 학습 워크로드에서 이러한 환경 관리 문제를 다뤄 왔다. Ray Serve DLC는 같은 접근을 추론으로 확장해 HTTP 엔드포인트 뒤에서 모델을 제공하는 데 필요한 스택을 AWS가 유지보수하고 시험한 형태로 제공한다. CPU 이미지는 Amazon Linux 2023을 기반으로 하고, GPU 이미지는 운영체제 계층과 CUDA 런타임 라이브러리를 포함한 공식 NVIDIA Amazon Linux 2023 이미지를 기반으로 한다. 그 위에는 PyTorch, FastAPI와 Uvicorn을 포함한 Ray Serve 서빙 계층, 비전·오디오·멀티모달 작업용 공통 유틸리티가 추가된다. 영상 전처리용 FFmpeg도 NVIDIA 하드웨어 가속을 지원하도록 컴파일되어 있으며, 구성 요소는 릴리스마다 함께 검증되고 보안 패치는 빌드 시 적용된다.

3. 실행 환경별 이미지와 애플리케이션 코드 분리

Ray Serve DLC는 Amazon EKS·Amazon EC2용 이미지와 Amazon SageMaker용 이미지로 나뉘며, 각 환경의 서빙 규약에 맞는 전용 진입점을 제공한다. 이 이미지들은 기반 스택과 의존성을 공유하므로, 배포 환경에 따라 진입점이 달라도 공통 추론 환경을 활용하는 구조다. Qwen3-VL을 포함한 여러 모델은 기본 이미지에 들어 있는 공통 추론 스택만으로 실행할 수 있고, 추가 라이브러리가 필요한 모델은 동일한 검증 기반 위에 필요한 요소를 덧붙일 수 있다. 예제는 GPU용 이미지로 Qwen3-VL-2B를 제공하며, DLC에 이미 GPU 스택, PyTorch, Ray Serve, Transformers가 포함되어 있다는 점을 활용한다. 서빙 애플리케이션은 qwen-serve-code ConfigMap으로 컨테이너에 주입하므로 이미지를 다시 빌드하지 않고 코드를 변경할 수 있으며, 실행 전에는 과금이 활성화된 AWS 계정, 대상 리전의 충분한 g5.xlarge 할당량, 설치·설정된 AWS CLI·eksctl·kubectl이 필요하다.

4. Python 클래스로 구현하는 모델 엔드포인트

Ray Serve에서는 @serve.deployment로 장식한 Python 클래스가 모델 엔드포인트가 되고, __call__에서 HTTP 요청을 처리한 뒤 .bind()로 애플리케이션을 등록한다. 글은 이 구조가 TorchServe의 사용자 정의 핸들러, torch-model-archiver 단계, config.properties 파일을 대체해 서빙 구현을 단순화한다고 설명한다. 예제의 QwenVLService는 Qwen/Qwen3-VL-2B-Instruct와 해당 프로세서를 불러오고, 모델을 float16으로 GPU에 배치한다. 요청에 포함된 이미지 URL과 텍스트 프롬프트를 메시지로 구성한 뒤 프로세서로 입력을 만들고, 최대 200개의 새 토큰을 생성하도록 호출한다. 생성 결과에서는 입력 토큰 부분을 제외하고 나머지를 디코딩해 JSON 응답으로 반환하며, GPU 1개를 요구하는 배포 설정과 float16 로딩은 다음 단계에서 사용하는 A10G의 24 GB VRAM에 모델을 배치하도록 구성되어 있다.

5. Amazon EKS의 단일 GPU 배포와 확장 경계

대상 아키텍처는 Amazon EKS 클러스터 안의 단일 GPU 노드에서 파드 1개가 모델을 실행하고 HTTP 포트 8000으로 요청을 받는 구성이다. 사용 인스턴스는 NVIDIA A10G GPU 1개와 24 GB VRAM을 제공하는 g5.xlarge이며, 예제의 범위는 한 머신·한 GPU·한 파드로 제한된다. 저장소의 deploy_cluster.sh는 eksctl을 사용해 VPC 네트워킹, IAM 기반 파드 인증을 위한 OIDC 공급자, 핵심 클러스터 애드온을 포함한 EKS 클러스터를 생성한다. 이어 deploy_node_group.sh가 role=gpu-worker 레이블을 가진 단일 g5.xlarge 관리형 GPU 노드 그룹을 추가하고, deploy_ray_cluster.sh가 코드 ConfigMap과 Kubernetes Deployment를 적용해 GPU 노드에서 Ray Serve를 시작한다. 여러 머신에 걸친 모델 병렬화나 복수 복제본의 수평 자동 확장이 필요한 경우에는 이 기반 위에 KubeRay를 도입해 노드 간 Ray 워커를 조율해야 한다.

6. 파드 준비 상태와 실제 GPU 추론 확인

세 배포 스크립트를 실행한 뒤에는 inference 네임스페이스의 파드 목록과 상세 정보를 조회해 파드가 실행 중인지, nvidia.com/gpu 리소스가 할당되었는지 확인한다. 파드가 준비 상태를 보고하면 ray-cluster Deployment의 포트 8000을 로컬 포트 8000으로 전달하고, 새 터미널에서 HTTP POST 요청을 보낸다. 예제 요청은 kitten.jpg 이미지 URL과 이미지를 간단히 설명해 달라는 프롬프트를 전달하며, 정상적으로 처리되면 모델의 이미지 설명이 담긴 JSON 응답을 받는다. GPU에서 추론이 실행되는지 확인하기 위한 방법으로는 해당 파드 안에서 nvidia-smi를 실행하는 명령이 제시된다. 다만 모델 로딩이 계속되는 동안 파드가 실제 응답 가능 시점보다 1~2분 먼저 Ready를 표시할 수 있으므로, 첫 요청이 거부되면 1분 정도 기다린 뒤 다시 시도해야 한다.

7. 지속적인 과금을 막기 위한 리소스 정리

글은 추론 응답을 확인한 다음에도 배포 리소스를 정리하는 단계가 필요하다고 설명하며, 그 목적을 지속적인 과금 방지로 명시한다. 정리 순서는 생성 단계의 역순으로, 먼저 모델을 제공하는 Ray Serve 배포를 제거하고 이어 GPU 노드 그룹을 삭제한 뒤 EKS 클러스터를 삭제하는 방식이다. 제공된 명령은 각각 delete_ray_cluster.sh, delete_node_group.sh, delete_cluster.sh이며, 독자가 앞서 만든 구성 요소와 삭제 대상을 연결해 실행할 수 있도록 제시된다. 따라서 예제의 전체 흐름은 클러스터 생성과 모델 배포에 그치지 않고, 요청 전송을 통한 동작 확인과 사용한 리소스 제거까지 이어진다. 원문은 별도의 비용 수치나 절감률을 제시하지 않으며, 실습 이후에도 과금이 계속되지 않도록 이 순서로 자원을 철거하라는 운영상 조치에 초점을 둔다.

8. TorchServe 이전 경로와 이후 확장 방향

결론에서 저자들은 CUDA 호환성을 직접 관리하거나 TorchServe 핸들러의 반복 코드를 작성하고 GPU 스택을 연결하는 다단계 Dockerfile을 구성하지 않아도 추론 엔드포인트를 만들 수 있다는 점을 강조한다. Ray Serve DLC의 목적은 지원되고 사전 검증된 컨테이너를 제공해 엔지니어가 인프라 유지보수보다 모델 코드에 집중하도록 하는 데 있다. 글은 이를 기존 TorchServe 팀에 유력한 이전 경로로 제시하면서, 구성 요소 간 버전 불일치를 없애고 이미지 태그 교체로 업그레이드를 단순화하며 AWS가 정기적인 보안 패치를 관리한다고 설명한다. 단일 노드를 넘어서는 워크로드에는 KubeRay로 같은 기반을 다중 노드 분산 서빙으로 확장하는 방향을 제시하지만, 본문에서 실제로 따라 하는 배포는 단일 GPU 구성이다. 후속 자료로는 전체 배포 과정을 담은 코드 예제와 CPU 변형 및 다른 프레임워크를 포함한 AWS Deep Learning Containers 이미지 참조 문서를 안내한다.

🧾 핵심 주장 / 시사점

• 이전의 핵심 가치는 서빙 코드 단순화와 함께 GPU 스택의 호환성 검증·보안 패치 부담을 줄이는 데 있으며, 글은 두 효과를 연결해 Ray Serve DLC를 제안한다.
• 검증된 기본 이미지와 ConfigMap의 조합은 공통 실행 환경 관리와 애플리케이션 코드 변경을 분리하면서, 추가 의존성이 필요한 모델에도 확장 여지를 제공한다.
• 단일 GPU 엔드포인트의 동작 확인, 실제 요청 처리 준비, 다중 노드 확장은 서로 다른 단계이며, Ready 표시만으로 추론 서비스 준비가 완료되었다고 판단할 수 없다.

✅ 액션 아이템

• TorchServe의 유지보수 중단에 따른 의존성·취약점 관리 부담을 바탕으로 Ray Serve DLC 이전 적합성을 검토한다.
• Amazon EKS에서 Qwen3-VL-2B의 파드 상태·GPU 할당·실제 추론을 확인하고, Ready 이후 1~2분의 응답 지연 가능성을 반영한다.
• 실습 종료 후 Ray Serve 배포, GPU 노드 그룹, EKS 클러스터 순으로 삭제해 지속적인 과금을 방지한다.

❓ 열린 질문

• 현재 TorchServe 운영에서 의존성 호환성과 취약점 관리 중 Ray Serve DLC 이전으로 줄이려는 부담은 무엇인가?
• 대상 모델은 Ray Serve DLC의 공통 추론 스택으로 실행 가능한가, 추가 라이브러리가 필요한가?
• 대상 워크로드는 g5.xlarge 1대의 단일 GPU 구성으로 충분한가, KubeRay를 이용한 다중 노드 모델 병렬화나 여러 복제본의 수평 자동 확장이 필요한가?