Ray Data LLM: vLLM 동기식 엔진 대비 2배 높은 처리량 구현

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

핵심 요약

대규모 데이터 큐레이션이나 평가와 같은 LLM 배치 워크로드는 개별 요청의 지연 시간보다 전체 시스템의 처리량 최적화가 핵심이다. 기존 vLLM의 동기식 API나 단순한 Ray 통합 방식은 메모리 부족(OOM)이나 리소스 유휴 상태인 파이프라인 버블 문제를 겪는다. Ray Data LLM은 vLLM의 비동기 엔진과 Ray의 스트리밍 실행 모델을 결합하여 리소스 활용도를 극대화한다. 이를 통해 오류 발생 시에도 파이프라인이 중단되지 않는 프로덕션 수준의 안정성과 2배 이상의 처리량 향상을 달성했다.

배경

Ray 프레임워크 기본 지식, vLLM 추론 엔진에 대한 이해, Python 및 분산 데이터 처리 개념

대상 독자

프로덕션 환경에서 대규모 LLM 배치 추론 및 데이터 처리를 수행하는 AI 엔지니어

의미 / 영향

이 기술은 대규모 데이터 합성이나 모델 평가 비용을 획기적으로 낮출 수 있게 합니다. 특히 추론 길이가 길고 가변적인 최신 추론 모델(Reasoning Models) 환경에서 리소스 활용도를 극대화하여 인프라 효율성을 크게 개선할 것으로 기대됩니다.

섹션별 상세

vLLM의 Offline Inference API를 사용하는 나이브한 방식은 전체 데이터셋을 CPU 메모리에 로드해야 하므로 대규모 작업 시 메모리 부족(OOM) 오류가 발생하며 결함 허용 기능이 부족하다.

python

from vllm import LLM 
llm = LLM(model="facebook/opt-125m") 

prompts = [
 "What is machine learning?",
 "Explain neural networks.",
 "How does backpropagation work?",
]

sampling_params = SamplingParams(
 temperature=0.7,
 max_tokens=100,
)

outputs = llm.generate(prompts, sampling_params)

vLLM의 Offline Inference API를 사용하는 나이브한 배치 추론 예시

Ray Data의 map_batches API를 사용해 동기식 LLM 엔진을 분산 실행하더라도, 요청마다 생성 길이가 다른 LLM의 특성상 짧은 요청이 긴 요청을 기다리는 파이프라인 버블 현상이 발생하여 리소스가 낭비된다.

python

class vLLMCallable:
 def __init__(self, *args, **kwargs):
  self.llm = LLM(*args, **kwargs)
 
 def __call__(self, batch: pd.DataFrame) -> dict:
  prompts = batch['prompt'].tolist()
  sampling_params = SamplingParams(temperature=0.7, max_tokens=100)
  outputs = self.llm.generate(prompts, sampling_params)
  generated_texts = [out.outputs[0].text for out in outputs]
  return {"generated_text": generated_texts}

ds = ds.map_batches(
 vLLMCallable,
 batch_size=32,
 num_gpus=1,
 fn_constructor_kwargs={"model": "facebook/opt-125m"},
)

Ray Data와 vLLM을 결합한 동기식 분산 배치 추론 구현 방식

동기식 실행에서 발생하는 리소스 유휴 상태(빈 박스)를 시각화한 이미지이다. — Diagram배치 내에서 생성 길이가 짧은 요청들이 가장 긴 요청이 끝날 때까지 기다려야 하는 '파이프라인 버블' 문제를 명확히 보여준다.

Ray Data LLM은 vLLM의 비동기 엔진을 활용하여 토큰 수준의 연속 배칭(Continuous Batching)을 수행하고, map_batches를 비동기적으로 호출하여 여러 배치를 동시에 처리함으로써 GPU 포화 상태를 유지한다.

python

from ray.data.llm import vLLMEngineProcessorConfig, build_processor

config = vLLMEngineProcessorConfig(
 model_source="facebook/opt-125m",
 concurrency=16,
 batch_size=32,
 tokenize_stage=True,
 detokenize_stage=True,
)

processor = build_processor(
 config,
 preprocess=lambda row: {
  "messages": [{"role": "user", "content": row["prompt"]}],
  "sampling_params": {"temperature": 0.7, "max_tokens": 100},
 },
 postprocess=lambda row: {"response": row["generated_text"]},
)

ds = processor(ds)

Ray Data LLM 라이브러리를 사용한 비동기식 프로덕션 규모 배치 추론 설정

나이브한 배치 처리와 Ray/vLLM을 이용한 비동기 스트리밍 실행 구조 비교 다이어그램이다. — Diagram기존 방식은 모든 데이터를 한꺼번에 처리하려다 OOM이 발생하지만, Ray Data LLM은 클라우드 저장소에서 데이터를 스트리밍하여 비동기 및 분산 방식으로 처리함을 보여준다.

동기식과 비동기식 Ray 실행의 리소스 활용도 차이를 비교한 다이어그램이다. — Diagram비동기 실행 시 여러 배치가 겹쳐서 처리되어 GPU가 항상 포화 상태를 유지하며 유휴 슬롯이 최소화되는 과정을 설명한다.

토큰화(Tokenization)와 디토큰화(Detokenization) 과정을 엔진에서 분리하여 CPU, GPU, 메모리 자원을 각 단계별로 세밀하게 제어할 수 있는 모듈형 아키텍처를 채택했다.

요청 수준의 에러가 발생해도 전체 데이터 파이프라인이 중단되지 않고 결과 데이터셋에 에러를 기록하며, 요청별 지연 시간 등 상세한 관측성(Observability) 데이터를 제공하여 디버깅을 용이하게 한다.

Qwen-4B 모델을 사용한 벤치마크 결과, 생성 길이가 길고 가변적인 추론 환경일수록 비동기 방식의 우위가 두드러지며 동기식 대비 최대 2배 이상의 처리량 향상을 보였다.

Qwen4B 모델의 생성 길이에 따른 동기 vs 비동기 처리량 비교 그래프이다. — Chart생성 토큰 수가 늘어날수록 비동기 실행(파란색)이 동기식(초록색)보다 일관되게 높은 처리량(rows/s)을 기록함을 증명한다.

동기식 대비 비동기 실행의 처리량 개선율을 보여주는 차트이다. — Chart평균 생성 길이가 2000토큰에 도달할수록 비동기 방식의 성능 개선 폭이 120% 이상으로 급격히 증가함을 나타낸다.

실무 Takeaway

대규모 배치 추론 시 Ray Data LLM을 사용하면 비동기 실행을 통해 GPU 유휴 시간을 최소화하고 처리량을 2배까지 높일 수 있다.
연속 배칭 기능이 없는 동기식 API 대신 비동기 엔진 기반의 라이브러리를 선택해야 가변적인 응답 길이 환경에서 리소스 효율을 극대화할 수 있다.
프로덕션 환경에서는 개별 요청 실패가 전체 배치 작업을 중단시키지 않도록 Ray Data LLM의 에러 기록 및 결함 허용 기능을 활용하는 것이 필수적이다.

언급된 리소스

문서Ray Slack #llm channel

DemoRay LLM Office Hours Recordings

Ray Data LLM: vLLM 동기식 엔진 대비 2배 높은 처리량 구현

핵심 요약

배경

대상 독자

의미 / 영향

섹션별 상세

실무 Takeaway

언급된 리소스

관련 토론

댓글

관련 피드

관련 토론

댓글

관련 피드