섹션별 상세
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을 결합한 동기식 분산 배치 추론 구현 방식
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 라이브러리를 사용한 비동기식 프로덕션 규모 배치 추론 설정
토큰화(Tokenization)와 디토큰화(Detokenization) 과정을 엔진에서 분리하여 CPU, GPU, 메모리 자원을 각 단계별로 세밀하게 제어할 수 있는 모듈형 아키텍처를 채택했다.
요청 수준의 에러가 발생해도 전체 데이터 파이프라인이 중단되지 않고 결과 데이터셋에 에러를 기록하며, 요청별 지연 시간 등 상세한 관측성(Observability) 데이터를 제공하여 디버깅을 용이하게 한다.
Qwen-4B 모델을 사용한 벤치마크 결과, 생성 길이가 길고 가변적인 추론 환경일수록 비동기 방식의 우위가 두드러지며 동기식 대비 최대 2배 이상의 처리량 향상을 보였다.
용어 해설
- 연속 배칭(Continuous Batching)
- — 대형 언어 모델 추론 시 요청 단위가 아닌 토큰 단위로 배치를 동적으로 구성하는 기술이다. 각 요청의 생성 길이가 다르더라도 완료된 요청 자리에 즉시 새로운 요청을 채워 넣어 GPU 활용도를 극대화하고 유휴 시간을 최소화한다.
- 파이프라인 버블(Pipeline Bubble)
- — 병렬 처리 시스템에서 작업 간의 처리 속도 차이나 동기화 대기 시간으로 인해 발생하는 리소스 유휴 상태를 의미한다. LLM 추론에서는 생성 길이가 짧은 요청이 긴 요청의 종료를 기다릴 때 발생하며, 이는 전체 시스템의 처리량 저하로 이어진다.
- 결함 허용(Fault Tolerance)
- — 시스템의 일부 구성 요소에 장애가 발생하더라도 전체 서비스가 중단되지 않고 정상적으로 작동을 유지하는 능력이다. Ray Data LLM에서는 실패한 노드를 자동으로 교체하거나 에러가 발생한 배치를 재시도하여 대규모 작업의 완결성을 보장한다.
- 스트리밍 실행(Streaming Execution)
- — 전체 데이터셋을 메모리에 한꺼번에 로드하지 않고 필요한 만큼씩 나누어 처리하는 방식이다. 사용 가능한 CPU RAM 용량을 초과하는 대규모 데이터셋을 처리할 때 필수적이며, 데이터 로드와 연산을 병렬로 수행하여 효율성을 높인다.
기술
- Ray
- vLLM
- Python
- Qwen-4B
활용 사례
- 합성 데이터 생성 (Synthetic Data Generation)
- 대규모 데이터 큐레이션 및 분류
- 대규모 모델 평가 (Large-scale Evaluation)
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
수집 2026. 02. 23.출처 타입 RSS
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
