vLLM x TileRT: 지연시간 중심 서빙을 위한 특화 디코드 엔진

목차

1. 개요
2. 배경
   • 분산 서빙과 디코드 플러그인화
   • TileRT의 목표
3. 핵심 내용
   • 제로 변경 코존재 설계
   • 아키텍처 구성
   • 핸드오프 메커니즘
   • 성능 평가
   • 설치와 실행 절차
4. 의미와 시사점
   • 디코드 풀 선택 기준
   • 현재 한계점
5. 결론
6. Reference

개요

vLLM 프로젝트가 2026년 7월 14일 vLLM x TileRT: Specialized Decode for Latency-Critical Serving 를 공개했다. TileRT는 사용자별 디코드 속도 최적화에 특화된 추론 런타임이며, 이번 통합은 vLLM의 프리필 경로와 서빙 표면을 그대로 둔 채 디코드 단계만 교체하는 구조를 제시한다. 가장 두드러진 설계 결정은 vLLM 코드베이스에 단 한 줄의 변경도 요구하지 않는다는 점이다. 포크도 패치도 내부 워커 래핑도 없이, 전적으로 공개 확장 인터페이스인 KVConnectorBase_V1 위에서 구현된다.

이 글에서는 분산 서빙 아키텍처가 디코드를 교체 가능한 부품으로 만든 배경, TileRT와 vLLM의 코존재 설계, KV 캐시 핸드오프 메커니즘, 성능 평가 조건, 실제 설치 절차, 그리고 현재 남아 있는 제약을 정리한다.

배경

분산 서빙과 디코드 플러그인화

LLM 서빙에서 분산 처리, 즉 Disaggregated Serving 패턴이 사실상의 표준으로 자리잡고 있다. 이 패턴은 계산 집약적인 프리필 단계와 메모리 대역폭 집약적인 디코드 단계를 물리적으로 분리한다. 두 단계는 요구하는 하드웨어 특성이 근본적으로 다르기 때문에 하나의 엔진에서 함께 처리하면 어느 쪽도 최적점에 도달하지 못한다.

이 아키텍처가 만들어낸 가장 중요한 부수 효과는 디코드 부분이 플러그인 가능해진다는 점이다. 프리필과 디코드 사이의 경계가 KV 캐시 전송이라는 명확한 인터페이스로 정의되면서, 디코드 엔진을 독립적으로 교체할 수 있는 여지가 생겼다. TileRT 통합은 바로 이 여지를 활용한 사례다.

TileRT의 목표

TileRT는 하드웨어 한계에 도달할 때까지 사용자당 디코드 속도를 밀어붙이는 것을 목표로 구축된 런타임이다. 설계 축이 전체 처리량이 아니라 개별 사용자의 응답 속도에 맞춰져 있다.

이런 최적화 방향이 의미를 갖는 워크로드는 명확하다.

워크로드	지연시간이 중요한 이유
에이전트 루프	여러 단계의 추론이 순차적으로 이어져 단계별 지연이 누적된다
실시간 음성	사람의 대화 속도에 맞춰 토큰이 생성되어야 자연스럽다
대화형 코딩 어시스턴트	개발자가 결과를 기다리는 시간이 곧 작업 흐름의 단절이다

집계 처리량을 극대화하는 일반 목적 서빙과는 최적화 목표 자체가 다르다.

핵심 내용

제로 변경 코존재 설계

이번 통합의 핵심 설계 원칙은 vLLM에 제로 변경이다. TileRT는 vLLM을 포크하지 않고, 패치를 적용하지 않으며, 내부 워커를 래핑하지도 않는다. 모든 연동은 vLLM이 이미 공개하고 있는 KVConnectorBase_V1 확장 인터페이스를 통해 이루어진다.

역할 분담은 다음과 같이 정리된다.

구성 요소	담당	설명
프리필	vLLM	스케줄링, 청크 프리필, 프리픽스 캐싱을 그대로 유지한다
서빙 표면	vLLM	동일한 OpenAI 호환 API와 요청 형식을 노출한다
디코드	TileRT	페어드 스택이 기존 vLLM 배포와 나란히 실행된다

즉 변경되는 것은 오직 디코드뿐이다. TileRT 스택은 기존 vLLM 배포를 대체하는 것이 아니라 그 옆에서 함께 동작한다. 운영 관점에서 보면 기존 배포를 그대로 둔 채 특화 경로를 추가하는 형태이므로 도입 위험이 낮다.

아키텍처 구성

통합 아키텍처는 라우팅, 클레임 필터링, 순수 생산자 역할이라는 세 개의 축으로 구성된다.

첫 번째는 라우팅이다. 가벼운 라우터가 TileRT 풀을 담당한다. 라우터는 vLLM으로 보내는 요청에 max_tokens=1 을 설정하는데, 이는 vLLM이 프리필을 수행한 뒤 첫 토큰만 발행하도록 하기 위함이다. 그리고 표준 통과 필드를 사용해 대상 디코드 노드를 지정한다.

kv_transfer_params = {
    "tilert_host": "...",
    "tilert_ctrl_port": "...",
}

두 번째는 클레임 필터링이다. TileRT 커넥터는 위와 같이 표시된 요청만 처리하고, 그 외 모든 요청에 대해서는 완전한 무동작으로 동작한다. 이 덕분에 두 개의 디코드 풀이 하나의 프리필 인스턴스를 공유할 수 있다. 동일한 프리필 자원 위에서 지연시간 특화 경로와 처리량 중심 경로를 동시에 운영할 수 있다는 뜻이다.

세 번째는 순수 생산자 역할이다. 커넥터는 kv_producer 로만 작동하며 스케줄링이나 샘플링에는 전혀 개입하지 않는다. 프리필이 끝난 뒤 상태를 추출하고 전송하는 것이 커넥터가 하는 일의 전부다. 개입 범위를 최소화한 이 설계가 vLLM 제로 변경을 가능하게 하는 전제 조건이다.

핸드오프 메커니즘

프리필 노드에서 디코드 노드로 상태를 넘기는 과정은 세 가지 특성으로 요약된다.

데이터 플레인 측면에서는 프리필 이후 압축된 KV 캐시, 스파스 어텐션 인덱스 캐시, 메타데이터가 RDMA 단측 쓰기로 전송된다. 전송 엔진으로는 Mooncake 또는 NIXL을 사용하며 중간 직렬화 단계가 없다. 직렬화와 역직렬화를 거치지 않기 때문에 전송 경로에서 발생하는 오버헤드가 최소화된다.

프리필과의 중첩 측면에서는 상태 추출이 포워드 윈도우 내에서 발생하고, 실제 네트워크 전송은 백그라운드 센더가 수행한다. 따라서 TileRT 바운드 요청이 다음 프리필 반복을 차단하지 않는다. 전송이 프리필 파이프라인을 정체시키지 않으므로 프리필 인스턴스의 처리량이 유지된다.

라이브 엔진 주입 측면에서는 상태가 도착하는 시점에 TileRT 네이티브 레이아웃으로 변환되어 실행 중인 엔진에 직접 주입된다. 그리고 첫 단계부터 다중 토큰 추측 디코딩이 활성화된다. 워밍업 구간 없이 곧바로 최적 디코드 모드로 진입한다는 점이 지연시간 관점에서 중요하다.

단계	처리 내용
상태 추출	프리필 포워드 윈도우 내에서 KV 캐시와 인덱스 캐시를 추출한다
전송	백그라운드 센더가 RDMA 단측 쓰기로 Mooncake 또는 NIXL을 통해 전달한다
주입	도착 즉시 TileRT 네이티브 레이아웃으로 변환해 실행 중인 엔진에 넣는다
디코드 시작	첫 단계부터 다중 토큰 추측 디코딩이 동작한다

성능 평가

성능 평가는 다음 환경에서 진행되었다.

항목	값
모델	GLM-5.1-FP8
하드웨어	NVIDIA B200 8장
입력 길이	1K에서 192K
출력 길이	1K

측정은 추측 디코딩 적용 여부와 수용 길이에 따라 세 가지 구성으로 나뉜다.

구성	설명
MTP 없음	추측 디코딩을 적용하지 않은 기본 성능
MTP 평균 수용 길이 3.2	평균적으로 추측 디코딩이 3.2 토큰의 추측을 수용하는 조건
최적 케이스 수용 길이 4.0	추측 토큰이 최대로 수용되는 피크 성능

입력 길이를 1K에서 192K까지 넓게 잡은 것은 긴 컨텍스트 상황에서도 사용자별 디코드 속도가 유지되는지를 확인하기 위한 구성이다. TileRT는 프리필이 끝난 직후 곧바로 멀티 토큰 추측 디코딩으로 디코딩을 시작하므로, 수용 길이가 높을수록 사용자당 토큰 생성 속도의 이득이 커진다.

설치와 실행 절차

설치 요구사항은 TileRT 0.1.5 버전, Python 3.12, CUDA 13 휠이다. TileRT는 PyPI에서 제공되며 프리필 노드와 디코드 노드 양쪽 모두에 설치해야 한다.

일회성 사전 준비로 모델 가중치를 TileRT 형식으로 변환한다.

python -m tilert.models.preprocess.weight_converter \
    --model_type glm-5 \
    --model_dir /path/to/GLM-5.1 \
    --save_dir /path/to/tilert-glm5.1-weights

1단계는 TileRT 디코드 노드 기동이다. 변환된 가중치를 지정하고 MTP를 활성화하며 제어 포트와 HTTP 포트를 열어둔다.

python -m tilert.pd_vllm.decode_server \
    --engine tilert --model glm5 \
    --model-weights-dir /path/to/tilert-glm5.1-weights \
    --with-mtp --max-seq-len 202752 \
    --kv-cache-dtype fp8 \
    --ctrl-port 5556 --http-port 5557

2단계는 vLLM 프리필 노드 기동이다. 여기서 사용하는 vLLM은 어떠한 수정도 가하지 않은 스톡 버전이다. --kv-transfer-config 에 TileRT 커넥터를 등록하고 kv_role 을 kv_producer 로 지정하는 것이 핵심이다.

vllm serve /path/to/GLM-5.1 \
    --served-model-name glm5.1 \
    --port 8000 \
    --tensor-parallel-size 8 \
    --enforce-eager \
    --kv-cache-dtype fp8_ds_mla \
    --speculative-config '{"method": "mtp", "num_speculative_tokens": 1}' \
    --kv-transfer-config '{"kv_connector": "TileRTConnector", "kv_connector_module_path": "tilert.pd_vllm.prefill_connector", "kv_role": "kv_producer", "kv_connector_extra_config": {"tilert_host": "[IP]", "tilert_ctrl_port": 5556, "tilert_model": "glm5"}}'

3단계는 라우터 기동이다. 라우터가 OpenAI 호환 입구 역할을 하며 프리필 노드 주소와 디코드 노드 주소를 함께 받는다.

python -m tilert.pd_vllm.pd_router \
    --vllm-url http://prefill-node:8000 \
    --decode decode-node:5556:5557 \
    --model-path /path/to/GLM-5.1 \
    --port 23333

클라이언트는 23333 포트의 라우터로 요청을 보내면 되고, 요청 형식은 기존 OpenAI 호환 API와 동일하다.

의미와 시사점

디코드 풀 선택 기준

두 디코드 스택은 대체 관계가 아니라 선택 관계다. 워크로드 특성에 따라 어느 쪽을 쓸지 판단하면 된다.

선택	적합한 조건
TileRT 디코드	사용자별 토큰 속도가 제약 조건인 경우
TileRT 디코드	대화형 에이전트, 실시간 어시스턴트, 지연시간 SLO 추론
TileRT 디코드	모델이 TileRT 지원 범위 안에 있는 경우
vLLM 네이티브 디코드	최대 집계 처리량이 필요한 경우
vLLM 네이티브 디코드	고 동시성 배치 처리
vLLM 네이티브 디코드	더 많은 모델과 기능 지원이 필요한 경우

두 스택 모두 동일한 OpenAI 호환 표면을 노출한다는 점이 실무적으로 중요하다. 워크로드를 일반화된 디코드 엔진과 전문화된 디코드 엔진 사이에서 이동시키는 작업이 라우팅 변경으로 끝난다. 클라이언트 코드나 요청 형식을 바꿀 필요가 없으므로 전환 비용이 낮다.

현재 한계점

도입을 검토할 때 반드시 고려해야 할 제약이 세 가지 있다.

한계	내용
동시성	TileRT 디코드 노드는 한 번에 비행 중인 요청을 1개만 처리한다
백프레셔	라우터가 게이트 디스패치와 백프레셔를 제공한다
모델 지원	현재 GLM-5, GLM-5.1, DeepSeek-V3.2만 지원하며 확대 예정이다

디코드 노드당 인플라이트 요청이 1개라는 제약은 사용자별 속도를 극한까지 끌어올리기 위한 설계의 직접적인 귀결이다. 배치를 만들지 않는 대신 단일 요청에 하드웨어 자원을 온전히 할당하는 방식이다. 따라서 동시 사용자 수를 늘리려면 디코드 노드를 수평으로 늘려야 하며, 라우터의 게이트 디스패치와 백프레셔가 이 흐름을 조율한다. 모델 지원 범위 역시 아직 좁기 때문에 지원 목록을 먼저 확인하는 것이 우선이다.

결론

vLLM x TileRT 통합은 분산 서빙 아키텍처가 열어놓은 확장점을 실제로 활용한 사례다. KVConnectorBase_V1 이라는 공개 인터페이스만으로 디코드 엔진을 통째로 교체하면서도 vLLM 본체에는 아무런 변경을 요구하지 않는다. 프리필의 스케줄링과 프리픽스 캐싱, OpenAI 호환 서빙 표면은 그대로 유지되고 디코드 단계만 특화된 런타임으로 넘어간다.

vLLM 측은 이 변화를 다음과 같이 설명한다. “분산 처리는 조용히 추론 스택이 무엇인지를 변화시키고 있다: 단일 엔진에서 공유 서빙 계층 뒤의 전문화된 엔진 구성으로.” 개별 엔진이 한 차원에서 깊이 있게 특화될 수 있고, 그러기 위해 다른 모든 것을 다시 구축할 필요가 없다는 의미다.

현재는 디코드 노드당 요청 1개, 지원 모델 3종이라는 제약이 있어 범용 배포에 바로 적용하기는 이르다. 다만 사용자별 응답 속도가 곧 제품 품질인 대화형 에이전트나 실시간 음성 워크로드라면, 기존 vLLM 배포를 유지한 채 라우팅만 나누어 특화 경로를 추가로 운영해볼 만한 구조다.

Reference

• vLLM x TileRT: Specialized Decode for Latency-Critical Serving