Ray Serve LLM을 활용한 vLLM WideEP 배포의 DP 그룹 결함 허용(Fault Tolerance) 발표

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

핵심 요약

대규모 MoE 모델 서빙 시 사용되는 WideEP 구조는 데이터 병렬(DP) 어텐션과 전문가 병렬(EP) 레이어를 결합하지만, 단일 랭크 장애가 전체 DP 그룹의 통신을 마비시키는 취약점이 존재한다. Ray Serve LLM은 '갱 스케줄링(Gang Scheduling)' 프리미티브를 활용하여 DP 그룹을 하나의 논리적 단위로 관리하는 결함 허용 메커니즘을 도입했다. 이 방식은 특정 랭크 장애 시 해당 그룹 전체를 즉시 격리하고 원자적으로 재구축함으로써 다른 건강한 그룹의 서비스 연속성을 보장한다. 결과적으로 32~128개에 달하는 GPU 그룹의 장애 반경을 최소화하고, 그룹 단위의 오토스케일링을 통해 대규모 추론 인프라의 가용성을 극대화한다.

배경

Ray Serve 및 vLLM 기본 지식, MoE(Mixture of Experts) 아키텍처 이해, 분산 시스템의 데이터 병렬(DP) 및 전문가 병렬(EP) 개념

대상 독자

프로덕션 환경에서 대규모 MoE 모델을 서빙하는 MLOps 엔지니어 및 인프라 개발자

의미 / 영향

이 기술은 대규모 MoE 모델 서빙의 가장 큰 약점인 분산 시스템의 취약성을 해결합니다. 단일 GPU 장애가 수백 개의 GPU 클러스터를 멈추게 하던 문제를 그룹 단위 격리로 해결함으로써, 기업들이 DeepSeek와 같은 거대 모델을 더 안정적이고 비용 효율적으로 운영할 수 있게 합니다.

섹션별 상세

WideEP 구조에서 단일 GPU 장애는 전체 DP 그룹의 추론 프로세스를 중단시키는 치명적인 병목이 된다. MoE는 전문가 레이어를 여러 랭크에 분산하여 배치하므로, 한 곳만 장애가 발생해도 토큰의 Dispatch/Combine 통신이 불가능해져 전체 그룹이 작동 불능 상태에 빠진다. 일반적인 설정에서 DP 그룹은 16~128개의 GPU를 포함하며, 단일 장애가 이들 전체의 가용성을 0으로 만든다. 따라서 그룹 단위의 장애 감지와 복구 능력이 프로덕션 환경의 필수 요구사항이다.

MoE 파이프라인의 DP 어텐션과 셰어드 전문가 레이어 구조 다이어그램 — Diagram요청이 DP0-DP3 어텐션 복제본으로 분산된 후 DeepEP를 통해 공유 전문가 레이어 E0-E7로 전달되고 다시 결합되는 과정을 보여줍니다. 이 구조에서 모든 랭크가 건강해야만 통신이 완료될 수 있음을 시각화합니다.

Ray Serve LLM은 '갱 스케줄링'을 통해 DP 그룹을 단일 논리적 모델 인스턴스로 취급하여 관리한다. 각 DP 랭크를 Ray Serve 복제본으로 호스팅하고, 이들을 하나의 '갱(Gang)'으로 묶어 스케줄링, 상태 확인, 확장을 동시에 수행한다. 이 구조는 제어 평면이 부분적으로 살아있는 유효하지 않은 그룹에 트래픽을 보내는 것을 원천 차단한다. 이를 통해 분산된 리소스들이 하나의 유닛처럼 동작하도록 강제한다.

python

from ray.serve.llm import (
    build_dp_deployment,
    LLMConfig,
    ModelLoadingConfig,
)

llm_config = LLMConfig(
    model_loading_config=ModelLoadingConfig(
        model_id="microsoft/Phi-tiny-MoE-instruct",
        model_source="microsoft/Phi-tiny-MoE-instruct",
    ),
    deployment_config=dict(
        num_replicas=2, # <--- Number of DP groups
    ),
    engine_kwargs=dict(
        tensor_parallel_size=1,
        pipeline_parallel_size=1,
        data_parallel_size=2, # <--- DP group size
    ),
)

app = build_dp_deployment(llm_config)
deployment_handle = serve.run(app, blocking=False)

Ray Serve LLM에서 DP 그룹 결함 허용을 활성화하기 위한 기본 배포 설정 예시

전문가 병렬(EP) 크기에 따른 GPU당 디코드 처리량 비교 차트 — ChartEP 크기가 32에서 96으로 증가해도 GPU당 처리량이 크게 떨어지지 않음을 보여줍니다. 이는 무조건 큰 그룹을 만들기보다 장애 반경을 줄이기 위해 적절한 크기의 그룹 여러 개를 운영하는 것이 효율적이라는 주장의 근거가 됩니다.

장애 발생 시 해당 그룹을 즉시 격리하고 원자적으로 재구축하여 장애 반경을 효과적으로 제한한다. 장애가 감지되면 Ray Serve 컨트롤러가 해당 그룹으로의 트래픽 라우팅을 즉시 중단하고 그룹 전체를 삭제한 후 새로 생성한다. 이 과정에서 다른 건강한 DP 그룹들은 중단 없이 정상적인 서빙을 유지하여 시스템 전체의 가용성 저하를 막는다. Grafana 대시보드 테스트 결과, 특정 워커 프로세스 종료 시에도 전체 서비스 가용성 드롭 없이 복구가 완료됨이 확인됐다.

DP 그룹 결함 허용의 장애 감지 및 복구 흐름도 — Diagram랭크 장애 발생 시 전체 DP 그룹(갱)이 비정상으로 표시되고, 컨트롤러가 트래픽을 차단한 후 그룹을 재구축하여 정상 상태로 복구하는 4단계 사이클을 설명합니다.

장애 발생 시 복제본 수와 QPS 변화를 보여주는 메트릭 차트 — Chart특정 시점에 워커 장애가 발생했을 때 Ray Serve가 영향을 받은 DP 그룹을 제거하고(복제본 감소) 다시 건강한 그룹을 생성하여 QPS를 회복하는 실시간 운영 데이터를 보여줍니다.

오토스케일링 역시 개별 복제본이 아닌 DP 그룹 단위로 수행되어 서빙 토폴로지의 일관성을 유지한다. 트래픽 변화에 따라 복제본 수를 조절할 때 반드시 `data_parallel_size`의 배수 단위로 증감시켜 유효하지 않은 부분 그룹(partial group) 생성을 방지한다. 사용자는 `min_replicas`와 `max_replicas`를 그룹 수 단위로 설정하기만 하면 된다. 이는 대규모 클러스터에서 자원 효율성과 구조적 안정성을 동시에 확보하게 해준다.

python

llm_config = LLMConfig(
    model_loading_config=ModelLoadingConfig(
        model_id="microsoft/Phi-tiny-MoE-instruct",
        model_source="microsoft/Phi-tiny-MoE-instruct",
    ),
    deployment_config=dict(
        num_replicas="auto",
        autoscaling_config=dict(
            min_replicas=1, # <-- Min. number of DP groups
            max_replicas=4, # <-- Max. number of DP groups
        )
    ),
    engine_kwargs=dict(
        tensor_parallel_size=1,
        pipeline_parallel_size=1,
        data_parallel_size=2, # <--- DP group size
    ),
)

DP 그룹 경계를 준수하며 자동으로 확장/축소되도록 설정하는 오토스케일링 예시

갱 인식 오토스케일링 메트릭 분석 — Chart트래픽 증가 및 감소에 따라 복제본 수가 항상 DP 그룹 크기(예: 2)의 배수로 정렬되어 확장 및 축소되는 과정을 보여줍니다. 확장 시 CUDA 그래프 캡처 등으로 인한 일시적 지연 시간 변화도 확인할 수 있습니다.

vLLM의 'Elastic EP'와 상호보완적으로 작동하여 엔진과 오케스트레이션 계층의 복원력을 모두 확보한다. Ray Serve는 그룹 간의 장애 도메인과 트래픽 라우팅을 관리하는 오케스트레이션 계층의 복원력을 담당한다. 반면 vLLM Elastic EP는 엔진 내부에서 동적으로 토폴로지를 변경하고 복구하는 계층을 담당하여 시너지를 낸다. 두 계층의 결합은 대규모 MoE 모델 서빙의 안정성을 완성하는 핵심 로드맵이다.

실무 Takeaway

대규모 MoE 모델 배포 시 GPU 장애로 인한 전체 서비스 중단을 막으려면 Ray Serve의 DP 그룹 결함 허용 기능을 활성화하여 장애 반경을 그룹 단위로 격리해야 한다.
처리량 효율을 위해 EP 그룹 너비를 무조건 키우기보다, GPU당 처리량이 최적화되는 최소 수준(예: 32~96)으로 설정하여 장애 발생 시의 리스크를 분산해야 한다.
오토스케일링 설정 시 `data_parallel_size`를 고려하여 그룹 단위로 복제본이 생성되도록 구성함으로써 서빙 토폴로지의 일관성을 보장해야 한다.

언급된 리소스

DemoEfficient Multi-Node Orchestration of Sparse MoE Model Serving

문서vLLM Elastic Expert Parallelism RFC