추론 서빙 아키텍처 — P/D 분리와 오케스트레이션

서빙 엔진 — 무엇을 고를 것인가

추론 서빙 엔진의 핵심 과제는 하나다. 길이도 도착 시각도 제각각인 요청들을 GPU에 잘 채워 넣는 것.

P/D 분리 — 성격이 다른 일을 다른 기계에

멀티모달이 더하는 단계

이미지·오디오가 섞이면 프리필 앞에 인코드(encode) 단계가 하나 더 붙는다. 이 단계는 또 성격이 다르므로(비전 인코더는 연산 집약이지만 프리필과 자원 요구가 다르다) 같은 논리로 다시 분리하는 설계가 나온다. 워크로드를 쪼갤수록 랙 종류가 늘어난다는 4장의 관찰이 여기서도 반복된다.

오케스트레이션 — 요청을 어디로 보낼 것인가

풀을 나누면 새로운 문제가 생긴다. 어느 요청을 어느 GPU로 보낼 것인가? 무작위로 보내면 분리의 이득이 사라진다.

• llm-d — CNCF로 이관된 Kubernetes 네이티브 분산 추론 스택.
• Grove · KAI Scheduler — 추론 워크로드를 위한 스케줄링 계층. 12장의 토폴로지 인식이 추론에서도 필요하다 — P/D 분리에서는 프리필 풀과 디코드 풀이 KV 전송에 유리한 거리에 있어야 한다.

처리량을 끌어올리는 기법들

각 기법이 어느 병목을 노리는지 대응시켜 보면 정리가 된다.

병렬화 조합 — 추론에서는 학습과 다른 답이 나온다

12장에서 병렬화를 배웠지만, 그것은 학습 기준이었다. 추론에서는 목적이 다르다. 학습은 「전체 처리량 최대」가 목표지만, 추론은 「SLO를 지키면서 처리량 최대」가 목표다. 제약이 하나 더 붙으면 최적해가 달라진다.

각 병렬화를 늘리면 무슨 일이 일어나는가

추론에서 병렬화 차수를 하나씩 올려 보면 효과가 명확히 갈린다. 아래 세 그림을 같은 축으로 놓고 비교하는 것이 이 절의 핵심이다.

이 탐색을 손으로 하면 며칠이 걸린다. Dynamo의 AIConfigurator 같은 도구가 SLO를 입력하면 구성 후보를 추려 주는 것도 그 때문이다. 다만 도구가 추천한 구성도 자기 요청 분포로 반드시 재검증해야 한다 — 도구는 대개 균일한 합성 부하를 가정한다.

실습 — 서빙하고, 재고, 나눠 보기

vllm serve <model> --max-model-len 8192

# 동시 요청 수를 바꿔 가며 부하를 건다
python -m vllm.entrypoints.openai.api_server ...   # 또는 벤치마크 스크립트
#   동시성: 1, 2, 4, 8, 16, 32, 64
#   기록: TTFT(p50/p99), TPOT(p50/p99), 처리량(tok/s), GPU 사용률

참고 자료

• Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention (SOSP 2023) — vLLM 원논문
• vLLM 블로그 — PagedAttention · SGLang 문서
• NVIDIA Technical Blog — 대규모 추론 배포 : 이 페이지 도해 출처
• NVIDIA Dynamo 문서 — Disaggregated Serving · llm-d (CNCF)