TorchServe 지원 종료 이후 AWS Ray Serve Deep Learning Containers가 역할을 이어받다
TorchServe가 무기한 유지보수 동결에 들어감에 따라 AWS는 AWS Ray Serve Deep Learning Containers를 활용하는 단일 GPU 마이그레이션 경로를 공개했다. 이는 TorchServe 사용자가 더 이상 프로덕션 PyTorch 모델을 뒷받침하는 적극적으로 유지 관리되는 서빙 프레임워크를 보유하지 않게 됐다는 점에서 중요하다. AWS는 그 대신 검증된 컨테이너 스택을 제공하지만, 팀은 여전히 서빙 애플리케이션을 다시 작성하고 주변 인프라를 운영해야 한다.
새로운 마이그레이션 가이드는 Amazon Elastic Kubernetes Service, 즉 Amazon EKS에서 Qwen3-VL-2B 비전 언어 모델을 배포한다. 이 모델은 NVIDIA A10G GPU 1개와 GPU 메모리 24GB를 갖춘 g5.xlarge 인스턴스 1대의 단일 pod 내부에서 실행된다. 예제는 포트 8000의 HTTP 엔드포인트를 통해 모델을 제공한다.
이처럼 소규모인 배포 사례는 더 큰 충돌 지점을 드러낸다. TorchServe는 한때 PyTorch 중심 워크플로우 뒤에서 모델 아카이빙, 핸들러, 구성, 서빙을 하나로 묶었다. AWS Ray Serve Deep Learning Containers는 이 프레임워크를 유지 관리되는 이미지, Ray Serve 애플리케이션 코드, 표준 Kubernetes 리소스로 대체한다. 운영 책임이 사라지는 것이 아니라 그 형태가 바뀌는 셈이다.
AWS, TorchServe 지원 공백을 컨테이너 마이그레이션 경로로 전환
AWS는 TorchServe의 유지보수 동결에 대응해 즉시 대체 가능한 제품이 아니라 검증된 추론 스택을 제시하고 있다.
공식 TorchServe 문서는 이제 제한적 유지보수 공지를 표시한다. 이 공지에 따르면 프로젝트는 더 이상 적극적으로 유지 관리되지 않는다. 기존 릴리스는 계속 사용할 수 있지만, 업데이트, 버그 수정, 기능 추가 또는 보안 패치는 계획되어 있지 않다.
이 경고는 프로덕션 사용자들의 위험 계산을 바꾼다. 안정적인 애플리케이션은 기존 TorchServe 릴리스에서 계속 실행될 수 있다. 그러나 새로운 프레임워크, 운영체제, CUDA 또는 보안 요구 사항이 생길 때마다 애플리케이션 소유자는 또 다른 호환성 결정을 내려야 한다.
보안은 미루기 가장 어려운 문제다. TorchServe 공지는 취약점이 해결되지 않을 수 있다고 명시적으로 경고한다. 조직은 배포를 격리하고 주변 계층을 패치할 수 있지만, 서빙 프레임워크에 대한 향후 업스트림 수정에 의존할 수는 없다.
AWS는 이러한 워크로드를 위한 지원 기반으로 일반적으로 DLC라고 불리는 Ray Serve Deep Learning Container를 제시한다. DLC는 선택된 프레임워크와 관련 종속성이 함께 설치되고 검증된 컨테이너 이미지다. AWS는 Amazon EC2 및 EKS용, 그리고 Amazon SageMaker용 Ray Serve 이미지를 별도로 제공한다.
GPU 이미지는 NVIDIA Amazon Linux 2023 기반에서 시작한다. 이 기반에는 운영체제와 CUDA 런타임 라이브러리가 포함된다. 이후 AWS는 PyTorch, Ray Serve, FastAPI, Uvicorn, Hugging Face Transformers와 비전, 오디오, 멀티모달 처리를 위한 유틸리티를 추가한다.
이 이미지는 비디오 전처리를 위한 NVIDIA 하드웨어 가속 기능의 FFmpeg 빌드도 포함한다. 이 세부 사항은 비디오 프레임, 이미지, 오디오, 텍스트를 결합하는 모델을 제공하는 팀에 중요하다. 이러한 워크로드에는 모델 프레임워크와 HTTP 서버만으로는 충분하지 않은 경우가 많다.
AWS는 각 이미지 릴리스 전에 포함된 구성 요소들을 함께 검증한다고 밝혔다. 보안 패치는 이미지가 빌드될 때 적용된다. 이 접근 방식은 CUDA 런타임, PyTorch, Ray Serve, 웹 서빙 계층 사이의 버전 드리프트를 줄인다.
이 약속에는 명확한 경계가 있다. AWS는 컨테이너 조합을 지원하고 테스트하지만, 사용자는 모델 코드, 클러스터 구성, 네트워크 제어, 확장 정책, 업그레이드 프로세스에 대한 책임을 계속 진다. 유지 관리되는 이미지는 팀이 직접 구성해야 하는 표면을 좁혀 준다.
이 예제는 Ray Serve를 투명한 TorchServe 호환 모드로 제시하는 것도 피한다. 엔지니어는 새로운 Python 서빙 클래스를 작성하고 Ray Serve를 통해 이를 배포한다. TorchServe 아카이브를 가져오거나 전체 관리 인터페이스를 재사용하지 않는다.
이 구분은 발표 내용을 현실에 맞게 유지한다. AWS Ray Serve Deep Learning Containers는 영향을 받는 워크로드를 위한 지원 대상지를 제공한다. 하지만 프로덕션 마이그레이션을 자동화하거나 배포 테스트의 필요성을 없애지는 않는다.
TorchServe 팀이 이제 GPU 스택의 더 많은 부분을 책임져야 하는 이유
TorchServe의 적극적인 유지보수 종료는 업스트림 불확실성을 플랫폼 및 머신러닝 엔지니어링 팀에 직접 이전한다.
GPU 추론 서비스는 독립적으로 변화하는 여러 계층에 의존한다. 여기에는 운영체제, NVIDIA 런타임, CUDA 라이브러리, PyTorch, 모델 종속성, 요청 서버, 오케스트레이션 환경이 포함된다. 모델 코드가 바뀌지 않아도 호환성 실패가 발생할 수 있다.
TorchServe는 이전까지 PyTorch 팀에 익숙한 패키징 및 서빙 경로를 제공했다. 개발자는 torch-model-archiver로 모델 아카이브를 만들고, 맞춤 핸들러를 제공하며, config.properties를 통해 동작을 제어할 수 있었다. 이 워크플로우에도 자체적인 복잡성은 있었지만, 공통의 운영 관례를 제공했다.
유지보수 동결은 이 관례가 인접 소프트웨어의 변화 속도를 계속 따라갈 것이라는 신뢰를 없앤다. 팀은 모든 종속성을 고정할 수 있지만, 고정은 다음 결정을 늦출 뿐이다. 운영체제 패치, GPU 변경 또는 프레임워크 업그레이드는 결국 스택 전반의 검증을 요구한다.
TorchServe를 계속 실행하는 것은 여전히 가능하다. 프로젝트가 사라진 것은 아니며, 기존 릴리스는 많은 배포 환경에서 여전히 작동한다. 문제는 이를 계속 사용하는 일이 지원되는 기본 선택이 아니라 의도적인 내부 소유권 선택이 된다는 점이다.
이 경로를 택하는 조직에는 명확한 보안 프로세스가 필요하다. 관련 종속성을 모니터링하고, 노출된 인터페이스를 평가하며, 새 TorchServe 릴리스를 기대하지 않고 이미지를 재빌드하고 수정 사항을 테스트해야 한다. TorchServe 자체의 취약점에 대한 계획도 필요하다.
대안인 마이그레이션은 즉각적인 엔지니어링 작업을 만든다. TorchServe 핸들러와 모델 아카이브가 자동으로 Ray Serve 배포로 전환되지는 않는다. 요청 파싱, 헬스 동작, 메트릭, 모델 로딩, 배치 처리, 오류 처리를 모두 비교해야 한다.
Ray Serve는 기본 프로그래밍 모델을 바꾼다. 개발자는 Python 클래스에 @serve.deployment를 지정하고, 그 클래스 안에서 모델을 초기화하며, __call__을 통해 들어오는 HTTP 요청을 처리한다. .bind()를 호출하면 Ray Serve에 애플리케이션이 등록된다.
이 모델은 TorchServe의 아카이브 및 핸들러 구조보다 단순하게 느껴질 수 있다. 또한 개발자에게 일반적인 Python 조합 방식과 Ray의 리소스 선언에 대한 직접적인 접근을 제공한다. 예를 들어 AWS 배포는 ray_actor_options={"num_gpus": 1}를 통해 GPU 1개를 요청한다.
그러나 애플리케이션 코드가 더 단순하다고 해서 프로덕션 운영까지 더 단순해지는 것은 아니다. 팀은 여전히 준비 상태 검사, 인증, 트래픽 관리, 텔레메트리, 배포 제어, 롤백 절차를 마련해야 한다. 모델 가중치가 환경에 유입되는 방식과 업데이트 중 복제본이 동작하는 방식도 결정해야 한다.
AWS 컨테이너는 여러 호환성 선택을 업스트림으로 옮긴다. AWS는 기본 운영체제, CUDA 런타임, 프레임워크, 서빙 종속성을 선택하고 검증한다. 이는 내부에서 조립한 이미지에 필요한 반복적 통합 작업을 줄일 수 있다.
동시에 AWS 이미지 릴리스에 대한 새로운 종속성도 만든다. 플랫폼 팀은 이미지 태그를 추적하고, 변경 사항을 검토하며, 추가한 계층을 스캔하고, 자체 환경에서 새 버전을 검증해야 한다. 검증된 기반은 유용한 근거이지만 애플리케이션 수준의 인증은 아니다.
규정 준수 요건이 있는 팀에는 더 많은 검증이 필요하다. 이미지 내용이 내부 정책을 충족하는지, 업데이트가 요구된 일정 내에 도착하는지 확인해야 한다. 또한 전체 이미지에 대한 소프트웨어 자재 명세서와 취약점 관리 기록도 필요하다.
따라서 부담은 성숙한 TorchServe 환경을 보유한 팀에 가장 크게 돌아간다. 이들은 하나의 프레임워크를 중심으로 핸들러, 패키징 단계, 대시보드, 운영 지식을 축적해 왔다. Ray Serve로 옮긴다는 것은 기존 시스템이 여전히 안정적으로 보일 수 있는 상황에서 그 전문성을 새로 투자해야 한다는 뜻이다.
소규모 배포 환경은 다른 계산이 필요하다. 서비스에 모델이 하나뿐이고 트래픽이 예측 가능하다면, 완전한 Ray 및 Kubernetes 스택은 불필요한 복잡성을 도입할 수 있다. 가치는 조직이 이미 EKS를 운영하고 있으며 더 광범위한 확장 요구를 예상하는지에 달려 있다.
AWS Ray Serve Deep Learning Containers가 서빙 모델을 바꾸는 방식
핵심 메커니즘은 사전 통합이다. AWS가 기본 스택을 고정하고, Ray Serve가 TorchServe의 패키징과 요청 수명 주기를 대체한다.
AWS 예제는 이미지와 텍스트를 처리하는 비전 언어 모델 Qwen/Qwen3-VL-2B-Instruct를 제공한다. 이미지 URL과 프롬프트를 받아 생성된 설명이나 답변을 반환한다. 이 모델은 GPU 추론과 멀티모달 전처리를 모두 수행하기 때문에 예제에 적합하다.
AWS는 Hugging Face Transformers를 통해 모델을 로드한다. AutoProcessor는 멀티모달 입력을 준비하고, AutoModelForImageTextToText는 반정밀도 가중치로 모델을 로드한다. 이후 애플리케이션은 이 가중치를 CUDA 장치로 옮긴다.
서빙 클래스는 HTTP 요청을 직접 받는다. JSON에서 이미지 URL과 프롬프트를 추출하고, 모델 입력을 준비하며, 생성을 실행한 뒤 결과를 반환한다. FastAPI와 Uvicorn은 DLC에 포함된 웹 서빙 기반을 제공한다.
이 설계는 익숙한 TorchServe 아티팩트 세 가지를 제거한다. TorchServe 모델 아카이브도, TorchServe 핸들러 계층도, config.properties 파일도 없다. 서빙 계약은 Ray Serve 애플리케이션과 배포 구성에 존재한다.
AWS는 Kubernetes ConfigMap을 통해 이 Python 애플리케이션을 주입한다. ConfigMap은 pod가 런타임에 마운트할 수 있는 비밀이 아닌 구성 또는 파일을 저장한다. 이를 통해 엔지니어는 컨테이너 이미지를 다시 빌드하지 않고도 데모 코드를 변경할 수 있다.
이러한 유연성은 평가 과정에서 유용하다. 서빙 로직을 검증된 기본 이미지에서 분리하고 수정-배포-테스트 주기를 단축한다. 하지만 프로덕션 팀은 변경 가능한 구성이 자체 릴리스 및 감사 요건에 적합한지 판단해야 한다.
일부 조직은 대신 파생 이미지에 애플리케이션을 빌드할 것이다. 이 접근 방식은 AWS 기반과 승인된 서빙 코드를 모두 포함하는 불변 아티팩트를 만든다. 모든 애플리케이션 변경에 새 빌드가 필요하지만 재현성을 높일 수 있다.
배포는 Kubernetes nvidia.com/gpu 리소스를 사용해 GPU 1개를 예약한다. 또한 role=gpu-worker 레이블을 사용해 GPU 노드를 선택한다. 이러한 설정은 Kubernetes가 추론 pod를 의도한 인스턴스에 배치하도록 돕는다.
Ray는 컨테이너 환경과 애플리케이션 선언을 통해 GPU 할당을 받는다. 모델 클래스는 pod에 노출된 단일 GPU와 일치하게 GPU 1개를 요청한다. 더 큰 구성에서는 Ray가 선언된 리소스 풀 전체에 걸쳐 배포를 스케줄링할 수 있다.
AWS는 예제 주변에 세 개의 스크립트를 제공한다. 첫 번째 스크립트는 eksctl, 네트워크 구성, OpenID Connect 공급자, 핵심 애드온을 사용해 EKS 클러스터를 생성한다. 두 번째 스크립트는 관리형 GPU 노드 그룹을 추가한다.
세 번째 스크립트는 ConfigMap과 Kubernetes 배포를 적용한다. GPU 노드에서 Ray Serve pod를 스케줄링하고 포트 8000에서 서비스를 시작한다. 함께 제공되는 샘플 리포지토리에서는 이러한 배포 아티팩트를 검토할 수 있다.
배포 후 사용자는 pod를 점검해 GPU 할당을 확인할 수 있습니다. 이어서 로컬 포트 8000을 실행 중인 배포에 포워딩하고, 이미지 URL과 프롬프트가 포함된 HTTP 요청을 전송할 수 있습니다. pod 내부에서 nvidia-smi를 실행하면 GPU 사용을 확인할 수 있습니다.
시작 시퀀스는 프로덕션 설계에서 처리해야 할 운영상의 세부 사항을 보여줍니다. AWS는 Ray Serve가 요청에 응답하기 전에 Kubernetes가 pod를 준비 상태로 보고할 수 있다고 설명합니다. pod가 해당 상태에 도달한 뒤에도 모델은 여전히 로딩 중일 수 있습니다.
데모에서 첫 요청이 거부되는 것은 허용될 수 있지만, 프로덕션 트래픽 환경에서는 위험합니다. 팀은 컨테이너 상태뿐 아니라 애플리케이션 가용성에 readiness를 연결해야 합니다. 모델과 엔드포인트가 실제 요청을 처리할 수 있을 때까지 probe는 성공하지 않아야 합니다.
모델 다운로드도 또 다른 변수입니다. 이 데모는 애플리케이션 초기화 시 모델을 내려받으며, 이는 외부 가용성과 네트워크 처리량에 좌우됩니다. 프로덕션 팀은 시작 동작을 제어하기 위해 로컬 스토리지, 객체 스토리지 또는 이미지 레이어를 사용할 수 있습니다.
시크릿도 별도로 처리해야 합니다. ConfigMap에는 액세스 토큰이나 비공개 자격 증명을 저장해서는 안 됩니다. 필요한 인증 정보는 Kubernetes Secrets, EKS Pod Identity 또는 승인된 다른 시크릿 시스템을 통해 제공해야 합니다.
이러한 결정은 DLC가 실제로 무엇을 단순화하는지 보여줍니다. DLC는 소프트웨어 기반을 표준화하고 검증된 실행 환경을 제공합니다. 그러나 조직이 모델, 시크릿, 릴리스 아티팩트 또는 서비스 노출을 처리하는 방식을 결정해주지는 않습니다.
단일 GPU 데모는 출발점일 뿐, 프로덕션의 결론은 아닙니다
GPU 하나에서 pod 하나를 실행하는 것은 배포 경로를 입증하지만, 프로덕션 신뢰성·효율성·확장성을 보장하지는 않습니다.
AWS는 의도적으로 레퍼런스 아키텍처를 작게 유지합니다. EKS 클러스터에는 g5.xlarge 인스턴스를 기반으로 한 관리형 GPU 노드 하나가 있습니다. pod 하나가 노드의 NVIDIA A10G GPU를 사용하고, Ray Serve 프로세스 하나가 모델 엔드포인트를 노출합니다.
이 구성은 마이그레이션 테스트에 유용합니다. 팀은 분산 클러스터를 먼저 설계하지 않고도 핸들러를 변환하고, 응답 동작을 점검하며, 출력을 비교하고, GPU 접근을 확인할 수 있습니다. 또한 장애를 더 쉽게 분리할 수 있습니다.
그러나 이러한 단순성은 독자가 도출할 수 있는 결론도 제한합니다. 이 예시는 중복 레플리카, 멀티 노드 모델 병렬화, 트래픽 기반 오토스케일링 또는 가용 영역 전반의 장애 복구를 보여주지 않습니다. 비교 가능한 지연 시간이나 처리량 결과도 공개하지 않습니다.
이러한 측정이 없다면, 이 글은 Ray Serve가 특정 TorchServe 배포보다 뛰어난 성능을 낸다고 입증할 수 없습니다. 성능은 모델, 입력 형태, 동시성, 배치 처리, GPU, 전처리 경로 및 생성 설정에 따라 달라집니다. 마이그레이션 팀에는 자체적인 대표 테스트가 필요합니다.
아키텍처에는 서비스 장애의 단일 지점도 존재합니다. pod가 재시작되거나 GPU 노드를 사용할 수 없게 되면 Kubernetes가 이를 복구할 때까지 엔드포인트는 응답하지 않습니다. 프로덕션 서비스에는 일반적으로 추가 레플리카 또는 명확한 복구 목표가 필요합니다.
설계를 확장하면 Ray 클러스터 관리를 위해 권장되는 Kubernetes 오퍼레이터인 KubeRay가 도입됩니다. Ray의 Kubernetes 배포 가이드는 Ray 클러스터 구성과 Serve 애플리케이션을 결합하는 RayService 커스텀 리소스를 설명합니다.
KubeRay는 head 및 worker pod, 애플리케이션 업데이트, 클러스터 수명 주기를 관리할 수 있습니다. 또한 이기종 컴퓨팅 리소스와 오토스케일링도 지원합니다. 이러한 기능은 멀티 모델 파이프라인이나 노드 전반으로 확장해야 하는 서비스에서 Ray Serve의 활용도를 높입니다.
동시에 운영 개념도 추가됩니다. 팀은 Ray head, worker, Serve controller, 리소스 선언, Kubernetes 커스텀 리소스 및 여러 계층의 로그를 이해해야 합니다. 문제 해결은 Kubernetes와 Ray 두 제어 플레인에 걸쳐 이루어질 수 있습니다.
이러한 트레이드오프는 대안을 비교할 때 중요합니다. 단일 트랜스포머 모델을 제공하는 팀은 독립형 vLLM 엔드포인트를 평가할 수 있습니다. 여러 모델 형식을 사용하는 조직은 NVIDIA Triton Inference Server를 고려할 수 있습니다. Kubernetes 중심 팀은 표준화된 추론 리소스를 위해 KServe를 평가할 수 있습니다.
이 옵션들은 서로 겹치는 문제를 해결하지만, 우선순위는 다릅니다. Ray Serve는 Python 애플리케이션 구성, 분산 실행, 레플리카, 라우팅 및 확장에 중점을 둡니다. TorchServe는 PyTorch 모델의 패키징과 서빙을 중심으로 경험을 구축했습니다.
AWS도 다른 서빙 경로를 문서화하고 있습니다. 현재 EKS 추론 가이드는 LLM 배포에 vLLM Deep Learning Container를 사용합니다. 이는 Ray Serve DLC가 범용적인 대체재가 아니라 지원되는 하나의 패턴임을 확인해 줍니다.
올바른 선택은 워크로드에 달려 있습니다. 맞춤형 전처리를 포함한 비전-언어 서비스는 Ray Serve의 Python 네이티브 구성 방식에서 이점을 얻을 수 있습니다. 표준화된 텍스트 생성 엔드포인트는 대규모 언어 모델에 특화해 최적화된 엔진을 선호할 수 있습니다.
마이그레이션 평가는 인터페이스 동등성에서 시작해야 합니다. 팀은 요청 스키마, 오류 응답, 상태 확인 엔드포인트, 인증 및 클라이언트 타임아웃을 비교해야 합니다. 이후 통제된 테스트 세트를 기준으로 모델 출력을 검증해야 합니다.
그다음에는 부하 테스트가 필요합니다. 엔지니어는 콜드 스타트 시간, 최초 응답까지의 시간, 정상 상태 지연 시간, 처리량, GPU 메모리 및 급격한 트래픽 증가 상황에서의 동작을 측정해야 합니다. 테스트에는 프로덕션에서 사용하는 것과 동일한 전처리 및 생성 구성이 포함되어야 합니다.
장애 테스트도 똑같이 중요합니다. 팀은 pod를 종료하고, 노드를 드레이닝하며, 모델 접근을 중단하고, 잘못된 애플리케이션 리비전을 배포해야 합니다. 이러한 테스트는 대체 솔루션이 복구 및 롤백 기대치를 충족하는지 보여줍니다.
관측성에는 직접적인 매핑이 필요합니다. 기존 TorchServe 메트릭과 대시보드는 변경 없이 이전되지 않습니다. 운영자는 어떤 Ray, 애플리케이션, Kubernetes 및 GPU 메트릭이 상태, 포화도 및 사용자 대면 성능 저하를 정의하는지 결정해야 합니다.
마지막으로 팀에는 업그레이드 실험이 필요합니다. 스테이징 환경에서 두 DLC 버전 사이를 이동하고, 필요한 코드·구성·모델 변경 사항을 기록해야 합니다. 일상적인 업그레이드의 배포 위험이 여전히 너무 크다면 지원의 가치는 제한적입니다.
TorchServe 사용자가 다음으로 주목해야 할 점
다음 검증 과제는 AWS가 명확한 마이그레이션 예시를 신뢰할 수 있는 릴리스 및 확장 경로로 발전시킬 수 있는지 여부입니다.
첫 번째 신호는 Ray Serve DLC의 릴리스 주기입니다. 팀은 문서화된 이미지 태그, 프레임워크 버전, CUDA 조합, 보안 업데이트 및 지원 종료 정책을 지켜봐야 합니다. 예측 가능한 릴리스는 이 이미지가 장기 유지보수 작업을 줄인다는 AWS의 주장을 강화할 것입니다.
릴리스 노트는 릴리스 빈도만큼 중요합니다. 운영자는 어떤 종속성이 바뀌었는지, 업데이트에 호환성을 깨는 동작이 포함되는지 알아야 합니다. 또한 새 이미지를 도입하기 전에 테스트할 수 있도록 지원되는 태그 간에 충분한 중복 기간이 필요합니다.
두 번째 신호는 readiness, 모델 로딩 및 장애 복구를 위한 프로덕션 가이드입니다. 현재 예시는 Ray Serve가 응답하기 전에 pod가 준비된 것처럼 보일 수 있음을 인정합니다. 더 강력한 레퍼런스는 Kubernetes readiness를 로드된 모델 및 응답 가능한 엔드포인트에 맞춰야 합니다.
이 가이드는 모델 스토리지와 시작 동작도 다뤄야 합니다. 초기화 중 가중치를 다운로드하는 방식은 작은 데모에는 적합합니다. 대규모 배포에는 재현 가능한 로딩, 통제된 자격 증명, 적절한 스토리지 및 실제 모델 워밍업에 맞춘 startup probe가 필요합니다.
세 번째 신호는 GPU 하나에서 여러 레플리카 또는 노드로 이어지는 지원 경로입니다. AWS는 분산 서빙 및 수평 확장을 위해 독자를 KubeRay로 안내합니다. 향후 예시는 DLC가 RayService 배포 내에서 어떻게 동작하는지 보여줘야 합니다.
멀티 레플리카 레퍼런스는 트래픽 라우팅, 롤링 업데이트, 오토스케일링 신호 및 GPU worker가 사라졌을 때의 복구를 문서화해야 합니다. 또한 비용이 높은 가속기 용량을 모델에 유지할 수 있도록 Ray head 워크로드와 GPU 추론 worker를 분리해야 합니다.
팀은 모든 레퍼런스가 나오기를 기다렸다가 평가를 시작할 필요가 없습니다. 지금 TorchServe 서비스를 목록화하고 노출도, 비즈니스 중요도 및 마이그레이션 난이도에 따라 우선순위를 매길 수 있습니다. 인터넷에 노출된 엔드포인트는 격리된 배치 시스템보다 더 이른 주의가 필요합니다.
각 서비스에 대해 엔지니어는 현재 사용 중인 TorchServe 기능을 나열할 수 있습니다. 여기에는 모델 아카이브, 커스텀 핸들러, 워크플로, 배치 처리, 메트릭, 관리 API 및 구성 파일이 포함됩니다. 이 목록은 구체적인 Ray Serve 마이그레이션 체크리스트가 됩니다.
작은 개념 검증은 기존 요청 및 응답 계약을 유지해야 합니다. 클라이언트를 변경하지 않으면 더 광범위한 애플리케이션 재작성과 서빙 계층 마이그레이션을 분리할 수 있습니다. 또한 이전 및 신규 엔드포인트 간의 통제된 트래픽 비교가 가능해집니다.
평가에는 동일한 모델 가중치와 대표 입력을 사용해야 합니다. 팀은 출력 일관성, 지연 시간, 처리량, GPU 활용률 및 오류 동작을 비교할 수 있습니다. 또한 각 서비스가 재시작 후 복구하는 데 걸리는 시간도 기록해야 합니다.
보안 팀은 결과 이미지를 완전한 아티팩트로 검토해야 합니다. AWS 기반 이미지는 검증된 종속성과 빌드 시점 패치를 받을 수 있지만, 로컬에서 추가한 패키지는 취약점을 다시 유입시킬 수 있습니다. 맞춤화 이후에도 스캔은 계속되어야 합니다.
플랫폼 소유자는 마이그레이션 전에 소유권도 정의해야 합니다. AWS는 DLC를 유지보수하고, Ray는 Ray Serve를 유지보수하며, 조직은 자체 애플리케이션과 EKS 배포를 책임집니다. 명확한 경계는 지원되는 구성 요소가 종단 간 지원되는 서비스로 오인되는 일을 방지합니다.
더 넓은 교훈은 모든 TorchServe 사용자가 Ray Serve를 채택해야 한다는 것이 아닙니다. 유지보수되지 않는 서빙 계층은 이제 명시적인 결정을 요구한다는 점입니다. 현 상태를 유지하든, Ray Serve로 마이그레이션하든, 다른 서버를 선택하든 각각 다른 지원 모델이 만들어집니다.
AWS Ray Serve Deep Learning Containers는 이러한 선택지 중 하나를 더 구체적으로 만듭니다. 새로운 예시는 검증된 기반, 직접적인 프로그래밍 모델 및 동작하는 단일 GPU EKS 배포를 제공합니다. 동시에 남은 책임도 분명하게 보여줍니다.
대표적인 TorchServe 서비스 하나에서 시작해 실제 트래픽 패턴으로 마이그레이션을 테스트하십시오. DLC가 가용성을 약화하지 않으면서 종속성 작업을 줄인다면 더 폭넓게 도입할 가치가 있습니다. Ray의 운영 계층이 그 이점을 상쇄한다면, 테스트가 이를 조기에 드러낼 것입니다.
