13. vLLM 아키텍처

핵심 질문
지금까지 개념으로 본 것들(스케줄러·KV 관리·워커)이 실제 한 시스템에서 어떤 책임 경계로 나뉘는가?
그 경계를 읽을 때, 무엇이 안정적이고 무엇이 버전 의존적인가?

목표
vLLM V1의 컴포넌트 책임 경계를 하나의 요청 여정으로 정리한다.
버전 고정(V1, 확인일 2026-07-20)을 지키며 원 설계와 현재 명칭을 구분한다.

여정에서의 위치 — 지도의 완성

01장에서 그린 요청 여정 지도를, 이제 하나의 실제 엔진(vLLM V1)을 사례로 구체화합니다. 지금까지의 개념들 — tokenization(02), prefill/decode(02·03), KV 캐시(05), continuous batching(08), PagedAttention(09), prefix caching(10) — 이 이 컴포넌트들에 어떻게 배치되는지 봅니다.

⚠️ 흔한 실수

버전 고정 안내
아래는 vLLM V1 아키텍처(2025-01 재설계 이후, 확인일 2026-07-20) 기준입니다. 컴포넌트 명칭·경계·기본값은 버전마다 바뀝니다. 이것은 "개념을 실제에 앉혀 보는" 사례일 뿐, vLLM 사용 권고가 아니며, 다른 엔진(SGLang·TensorRT-LLM 등)은 구조가 다릅니다.

컴포넌트 책임 경계

vLLM V1은 요청 처리와 모델 실행을 여러 프로세스로 분리한 구조로 문서화돼 있습니다.

컴포넌트	책임 (V1 문서 기준)	이 안내서의 어느 개념
API 서버 / AsyncLLM	HTTP 수신, tokenization·detokenization, 응답 스트리밍	02(tokenize·streaming)
EngineCore	스케줄러·실행자를 관리하는 내부 실행 루프; CPU 작업과 GPU 루프를 겹쳐 throughput↑	01(제어/데이터 분리)
Scheduler	요청 배칭·토큰 단위 스케줄링; RUNNING 전환 시 KV 블록 할당	07·08(배칭·admission/allocation)
KV Cache Manager	PagedAttention식 블록 할당	05·09(KV·블록)
Executor	워커들에 분산 실행 조율(TP·PP·DP)	01(실행자)
Worker	GPU 1개당 1 프로세스; 가중치 로드·forward pass·GPU 메모리 관리	01·04
ModelRunner	입력 텐서 준비·모델 호출·(cudagraph 등) 실행 로직	01
OutputProcessor	생성 토큰 id를 detokenize해 사용자에게 방출	02

sequenceDiagram
    participant U as 사용자
    participant API as API서버/AsyncLLM
    participant EC as EngineCore
    participant SC as Scheduler
    participant KV as KV Cache Mgr
    participant EX as Executor/Worker/ModelRunner
    U->>API: 프롬프트
    API->>API: tokenize
    API->>EC: EngineCoreRequest
    EC->>SC: 스케줄 요청
    SC->>KV: KV 블록 할당
    SC->>EX: 배치 실행 지시
    EX->>EX: forward pass (prefill→decode)
    EX-->>API: 생성 토큰
    API-->>U: detokenize·streaming

🔎 약어 풀이: TP/PP/DP = tensor/pipeline/data parallelism(텐서·파이프라인·데이터 병렬). 큰 모델을 여러 GPU에 나눠 싣거나(TP·PP), 같은 모델 복제로 처리량을 늘리는(DP) 방식. 깊은 설명은 선수 과정 참조.

무엇이 안정적이고 무엇이 버전 의존적인가

이 장에서 반드시 갖고 갈 태도입니다.

안정적(개념 수준)

제어 경로와 데이터 경로의 분리(01), 스케줄러가 배칭·KV 할당을 조율한다는 큰 그림, 워커가 forward pass를 담당한다는 역할 구분. 이 구조적 아이디어는 버전이 바뀌어도 대체로 유지됩니다.

버전 의존적(구현 수준 — 확인 필요, 못 하면 unknown)

정확한 클래스·프로세스 명칭, 기본 블록 크기, 스케줄러의 세부 정책(선점 규칙 등), V0↔V1 차이, 특정 기능 지원 시점.

🔬 증거 읽기
위 표는 vLLM 공식 문서·블로그·저장소·DeepWiki(PRIMARY, vendor-reported 설계 서술, 확인일 2026-07-20)에 근거합니다. 이는 명칭과 책임 경계의 근거로는 적절하지만, "vLLM이 다른 엔진보다 빠르다"는 성능 비교의 근거로는 부족합니다 — 그건 조건이 명시된 measured 비교가 따로 필요하며, owner 자료는 그 단독 근거가 될 수 없습니다.

⚠️ 흔한 실수

흔한 오해: "V1이 prefill/decode를 없앴다"(01장에서도 언급) — 스케줄링 관점의 균일 처리이지, 계산 phase 자체의 소멸이 아닙니다.

📌 핵심

vLLM V1은 API/EngineCore/Scheduler/KV Cache Manager/Executor/Worker/ModelRunner로 책임을 분리한 다중 프로세스 구조.
각 컴포넌트는 앞 장들의 개념(tokenize·배칭·KV 블록·forward)에 대응된다.
구조적 아이디어는 안정적, 명칭·기본값·정책은 버전 의존적 — 후자는 확인하거나 unknown.
owner 설계 서술은 성능 비교의 단독 근거가 아니다.

🔎 이 장의 '지지하지 않는 결론'

이 장은 책임 경계만 보였을 뿐, "vLLM이 더 빠르다/낫다"를 말할 수 없습니다.
특정 버전의 정확한 명칭·기본값을 이 안내서만으로 확정할 수 없습니다 — 문서·버전 확인이 필요합니다.

✍️ 확인 문제

vLLM V1의 컴포넌트 중 세 개를 골라, 이 안내서의 어느 개념(장)에 대응하는지 연결하세요.
"안정적인 것"과 "버전 의존적인 것"을 각각 두 가지씩 드세요.
(조건 유형) "공식 문서에 이렇게 나오니 vLLM이 가장 효율적이다"라는 추론의 결함을, 출처 등급으로 설명하세요.

다음 장: 14 · 추론 지표 — 이벤트·집계·분모를 못 박기.

← 이전12. speculative decoding과 MTP다음 →14. 추론 지표