라이프스타일

AWS, 멀티 노드 Ray LLM 컨테이너 출시: 대규모 언어 모델의 '프롬프트 읽기'와 '답변 생성'을 GPU 노드 두 대로 분리

AWS가 멀티 노드 배포용 Ray LLM Deep Learning Container를 내놓고, Amazon EKS에서 GPU 노드 두 개가 각각 프롬프트 읽기(prefill)와 답변 생성(decode)을 맡는 예시를 공개했습니다. AWS는 대형 모델 서비스를 직접 구축하는 팀이 소프트웨어 스택을 직접 조합하지 않고 AWS가 유지·테스트하는 컨테이너를 쓸 수 있다고 밝혔습니다.

읽는 데 약 7분

AWS, 멀티 노드 Ray LLM 컨테이너 출시: 대규모 언어 모델의 '프롬프트 읽기'와 '답변 생성'을 GPU 노드 두 대로 분리
사진: Mokaair (Original editorial artwork)

무슨 일이 있었나

AWS는 블로그 글에서 멀티 노드 배포용 Ray LLM Deep Learning Container(DLC)가 출시되면서 DLC의 사전 빌드 방식이 멀티 노드 추론으로 확장되었다고 밝혔습니다. AWS 설명에 따르면 DLC는 프레임워크, 의존성 패키지, GPU 소프트웨어 스택을 테스트와 패치를 거친 조합으로 묶어 둔 사전 빌드 Docker 이미지로, 내려받아 바로 쓸 수 있습니다. AWS 글은 Amazon EKS(Amazon Elastic Kubernetes Service)에서 단일 대규모 언어 모델을 GPU 노드 두 개에 배포하는 방법을 보여 줍니다. prefill 노드와 decode 노드를 따로 두되 하나의 OpenAI 호환 엔드포인트 뒤에 놓으므로, 사용자는 표준 채팅 요청 형식으로 이 서비스 진입점을 호출할 수 있습니다.

AWS에 따르면 Ray LLM DLC에는 추론 엔진인 vLLM, 서비스 계층인 Ray Serve의 HTTP, 노드 간 KV 캐시 전송을 위한 NIXL(NVIDIA Inference Transfer Library), 그리고 고대역폭 노드 간 통신을 맡는 EFA(Elastic Fabric Adapter) 스택(libfabric 및 aws-ofi-nccl)이 들어 있습니다. AWS는 DLC의 모든 구성 요소를 릴리스 전에 함께 검증하므로 CUDA 런타임, 프레임워크, 서비스 계층 사이에 버전 드리프트(구성 요소 버전이 서로 어긋나는 문제)가 없고, 보안 패치는 빌드 시점에 적용된다고 밝혔습니다.

AWS는 서비스 애플리케이션 전체가 YAML 설정 한 덩어리일 뿐이며 핸들러 클래스, 모델 아카이브 도구, 커스텀 이미지가 필요 없다고 설명합니다. 보조 함수 build_pd_openai_app이 prefill 및 decode 설정을 받아 하나의 OpenAI 호환 엔드포인트 뒤에서 KV 캐시 전송을 연결합니다.

prefill과 decode를 분리하는 이유

AWS에 따르면 대규모 언어 모델 추론은 두 단계로 나뉩니다. Prefill은 입력 프롬프트 전체를 병렬로 처리해 key-value(KV) 캐시를 만들고, Decode는 토큰(모델이 출력하는 텍스트 단위)을 한 번에 하나씩 생성하면서 그 캐시를 읽고 확장합니다. AWS는 두 단계를 분리하면 연산량이 큰 긴 프롬프트가 진행 중인 요청의 토큰 생성을 늦추는 일을 막고, 두 단계를 독립적으로 확장할 수 있다고 지적합니다.

AWS 글이 설명한 두 추론 단계
항목PrefillDecode
작업 내용입력 프롬프트 전체를 병렬 처리하고 KV 캐시 생성토큰을 한 번에 하나씩 생성하며 해당 캐시를 읽고 확장
AWS가 설명한 병목연산 능력에 제한됨메모리 대역폭에 제한됨
예시 속 노드g6.8xlarge GPU 노드 1개다른 g6.8xlarge GPU 노드 1개

다만 AWS는 대가도 있다고 말합니다. prefill이 만든 KV 캐시를 decode 노드로 넘겨야 하는데, 이 전송이 충분히 빨라야 분리의 이점이 상쇄되지 않으므로 노드 간 인터커넥트(노드끼리 잇는 네트워크 연결)가 중요하다는 것입니다. AWS는 이 아키텍처가 검색 증강 생성(RAG), 문서 요약, 에이전트형 애플리케이션 같은 워크로드에 적합하다고 설명합니다.

예시 아키텍처와 유의할 점

AWS의 예시 아키텍처는 시스템 워크로드, KubeRay operator, Ray head pod를 호스팅하는 CPU 시스템 노드(m7i.xlarge) 하나와, prefill용과 decode용으로 나뉜 GPU 워커 노드(g6.8xlarge) 두 개를 사용합니다. AWS는 EFA가 가용 영역(Availability Zone, AZ)을 넘나들 수 없기 때문에 GPU 노드 그룹이 단일 AZ에 고정된다고 밝혔습니다.

AWS의 예시는 Qwen3.5-9B 모델을 사용하고 max_model_len을 4096으로 설정했습니다. AWS는 g6.8xlarge에서 글에 나온 캐시 설정을 쓰면 재시작 시 모델 가중치 로딩 시간이 약 145초에서 약 2초로 줄어든다고 밝혔습니다.

AWS는 또한 연산을 담당하는 워커 pod가 privileged: true 설정으로 실행된다고 설명합니다. NIXL이 CUDA VRAM(GPU 메모리)을 EFA 네트워크 카드에 등록하는데, IPC_LOCK 권한만으로는 충분하지 않기 때문입니다.

일반 독자에게 갖는 의미

일반 독자에게 이는 대형 모델 서비스를 직접 구축해야 하는 팀이 GPU와 네트워크 관련 소프트웨어 스택을 직접 조합하지 않고도 AWS가 유지·테스트하는 컨테이너를 쓸 수 있다는 뜻입니다. AWS는 흔한 멀티 노드 추론 패턴으로 텐서 및 파이프라인 병렬(단일 인스턴스에 들어가지 않는 모델을 쪼개는 방식), 데이터 병렬(처리량을 높이기 위해 모델을 복제하는 방식), prefill/decode 분리(추론의 두 단계를 서로 다른 노드에 두는 방식)를 꼽습니다.

AWS가 제시한 사전 요건은 결제가 활성화된 AWS 계정, g6.8xlarge 인스턴스 두 개를 실행할 수 있는 할당량(최소 64 vCPU), 그리고 AWS CLI, kubectl, eksctl, helm, envsubst 등의 도구입니다. AWS의 배포 절차는 네 단계로, EKS 클러스터 생성(처음부터 만들면 약 15~20분), GPU 워커 노드 추가, KubeRay operator 설치, RayService 배포입니다. 지속적인 비용 발생을 피하려면 AWS는 리소스를 역순으로 삭제하라고 권고합니다.

이상은 모두 AWS 자체의 설명이며, 성능과 비용 결과는 각자의 환경에서 확인해야 합니다.

자주 묻는 질문

prefill/decode 분리란 무엇인가요?

AWS에 따르면 입력 프롬프트를 처리하는 prefill 단계와 토큰을 하나씩 생성하는 decode 단계를 서로 다른 노드에 두어, 서로 간섭하지 않고 독립적으로 확장할 수 있게 하는 방식입니다.

이 컨테이너는 무엇에 쓰나요?

AWS는 Ray LLM DLC에 vLLM, Ray Serve의 HTTP 서비스 계층, NIXL, EFA 스택이 들어 있으며, OpenAI 호환 엔드포인트로 멀티 노드 모델 추론을 제공하는 데 쓴다고 설명합니다.

배포하려면 코드를 작성해야 하나요?

AWS는 서비스 애플리케이션 전체가 YAML 한 덩어리일 뿐이며 핸들러 클래스, 모델 아카이브 도구, 커스텀 이미지가 필요 없다고 밝혔습니다. 다만 EKS 클러스터와 관련 도구는 설정해야 합니다.

이 성능 수치를 뒷받침하는 다른 출처가 있나요?

이 글의 내용은 모두 AWS 자체 블로그 글에서 나온 단일 출처이므로 AWS의 주장으로 보아야 합니다.

이 주제의 최신 뉴스 보기

같은 주제의 글

출처

라이프스타일