Push-based KV transfer to improve TTFT and TPOT for disaggregated inference in vLLM

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

vLLM의 push 기반 KV 전송은 prefill과 전송 준비를 겹치고 decode의 설정 부담을 줄여, Qwen3-32B·1P1D·Amazon EC2 P5en·EFA 벤치마크에서 pull 대비 TTFT를 최대 약 3배 개선하고 TPOT를 최대 30% 개선했다.

📌 핵심 요약

• vLLM의 prefill-decode 분리는 두 단계를 독립적으로 확장·최적화하지만, decode 시작 전에 KV 캐시 전송이 필요하다. 기본 NIXL pull 방식은 prefill 완료 후 라우터의 메타데이터 전달, decode 블록 할당과 전송 준비, NIXL READ가 순차적으로 진행되어 TTFT를 늘린다.
• push 방식은 decode가 목적지 블록을 미리 할당·등록하고, prefill 측이 KV 계산 완료와 등록 도착을 모두 확인하면 NIXL WRITE를 시작한다. prefill 작업자별 백그라운드 스레드가 전송 준비와 제출을 담당하며, decode는 필요한 완료 알림을 모두 받은 뒤 토큰 생성을 시작한다.
• Qwen3-32B를 사용한 Amazon EC2 P5en·EFA의 1P1D 평가에서는 prefix caching을 비활성화하고 입력 길이 1k~16k, 요청률 1~8 QPS, 출력 128토큰을 비교했다. 8 QPS·16k에서 TTFT는 pull 약 1,744ms, push 약 540ms였으며, 성능은 워크로드와 구성에 따라 달라진다.
• 낮은 부하에서 TPOT는 두 방식 모두 약 5.6~5.8ms로 비슷했지만, 4~8 QPS·16k에서 pull은 약 10.4ms, push는 약 7ms였다. 원문은 decode의 전송 준비 부담을 덜어 TPOT가 최대 30% 개선됐다고 보고한다.
• pull은 prefill 완료 후 decode 인스턴스를 선택할 수 있어 부하와 서비스 품질을 고려한 라우팅에 더 유연하다. push는 decode를 더 일찍 선택하는 대신 전송 준비를 prefill과 겹치며, 비슷한 부하에서 prefill의 KV 블록을 더 빨리 해제할 수 있다.

🧩 주요 포인트

1. 임계 경로 단축: 목적지 등록과 prefill의 병행으로 완료 후 조정 대기를 줄이고, 백그라운드 전송 준비로 decode의 토큰 생성 지연을 완화한다.
2. 효과가 커지는 조건: 짧은 입력·낮은 부하에서는 차이가 작지만 긴 입력·높은 QPS에서는 격차가 커지므로, 최대 개선치는 해당 워크로드와 평가 구성에 연결해 해석해야 한다.
3. 라우팅과 자원 회수의 절충: decode 조기 선택은 pull의 사후 라우팅 유연성을 줄이는 대신, 전송 시작과 prefill KV 블록 해제를 앞당길 수 있다.

🧠 상세 정리

1. P-D 분리와 기본 pull 방식의 병목

vLLM은 대규모 언어 모델을 위한 오픈소스 추론·서빙 엔진이며, 추론은 입력 프롬프트를 처리하고 KV 캐시를 만드는 prefill과 이 캐시로 출력 토큰을 하나씩 생성하는 decode로 나뉜다. 두 단계는 연산·메모리·확장 특성이 달라, 별도 엔진 인스턴스로 분리하면 각각 독립적으로 최적화하고 부하 상황의 자원 활용·처리량·지연을 개선할 수 있다. 다만 decode를 시작하려면 prefill에서 만든 KV 캐시를 먼저 전달해야 하므로, 전송 효율이 첫 토큰까지의 시간인 TTFT에 직접 영향을 준다. 기본 NIXL pull 방식에서는 prefill 완료 후 라우터가 원본 블록 ID 등의 메타데이터를 decode에 전달한다. 이어 decode가 목적지 블록을 할당하고 전송을 준비한 뒤 NIXL READ를 실행하므로, 이 순차 작업들이 첫 토큰 생성까지의 임계 경로를 늘린다.

2. push 설계와 직접 메모리 전송 기반

push 방식은 decode가 목적지 블록을 미리 등록하고, prefill이 KV를 계산하는 동안 전송에 필요한 준비를 병행하도록 설계됐다. 따라서 생산자 블록이 준비되면 전송을 시작할 수 있어, pull에서 prefill 이후 필요했던 블록 ID 확인과 조정 왕복을 첫 토큰까지의 경로에서 제거한다. 전송 설정은 prefill 측 백그라운드 스레드가 맡아 decode의 지연 민감한 토큰 생성 단계에서 해당 작업이 연산 시간을 차지하지 않도록 한다. 두 방식 모두 NIXL과 EFA/RDMA 데이터 경로를 사용하며, 지원 인스턴스의 EFA는 GPUDirect RDMA와 Neuron Direct RDMA를 통해 호스트 메모리를 거치지 않는 GPU 또는 AWS Trainium 장치 메모리 간 KV 전송을 지원한다. 이 기능은 EFA로 연결된 AWS Trainium 클러스터에서 개발·검증된 뒤 가속기 종류에 종속되지 않는 기능으로 vLLM에 기여됐으며, 글의 성능 결과는 GPU 기반 P5en에서 측정됐다.

3. 목적지 등록과 요청 매칭

프로토콜의 첫 단계에서 decode는 원격 prefill이 필요한 요청에 로컬 KV 블록을 할당하고, 자신의 식별 정보와 예약한 블록 위치를 담은 등록 정보를 만든다. 작업자는 같은 엔진 스텝 안에서 이를 NIXL 알림으로 prefill에 보내므로, prefill 계산이 끝나기 전에 목적지 위치를 전달할 수 있다. 다음 매칭 단계에서는 목적지 등록과 prefill 완료가 어느 순서로 발생하더라도 처리하도록 두 사건을 연결한다. 등록이 먼저 오면 prefill 측이 계산 완료까지 등록 정보를 보관하고, 계산이 먼저 끝나면 등록이 도착할 때까지 해당 요청의 KV 블록을 유지한다. 나중에 발생한 사건이 전송을 촉발하며, 요청 ID를 이용한 매칭은 재발행된 요청도 고려해 선점되거나 재시도된 요청을 올바르게 연결한다.

4. NIXL WRITE와 수신 완료 판정

요청 매칭이 끝나면 prefill 측은 필요할 경우 decode와 연결을 맺고, NIXL WRITE로 KV 블록을 decode가 등록한 메모리에 직접 기록한다. 이 과정은 목적지의 각 텐서 병렬 rank를 대상으로 수행되며, 생산자와 소비자가 서로 다른 내부 블록 배치를 사용하는 경우도 처리한다. 각 측이 전송 시점에 블록 위치를 자신의 물리적 배치에 맞게 변환하므로, 양쪽의 블록 크기가 달라도 전송할 수 있다. 각 WRITE에는 데이터 도착 후 NIXL이 decode에 전달하는 완료 알림이 연결되며, decode는 자신에게 기록하는 생산자 rank마다 하나씩 예상되는 알림을 센다. 일부 알림만 도착한 상태에서는 KV 수신이 끝난 것으로 보지 않고, 예상한 알림을 모두 받은 뒤 해당 요청을 decode 단계로 진행시킨다.

5. 백그라운드 처리와 라우팅의 절충

각 prefill 작업자는 전용 백그라운드 전송 스레드를 사용하며, 목적지 등록과 프롬프트 KV가 모두 준비되면 메인 루프가 블록을 넘기고 모델 실행으로 빠르게 복귀한다. 백그라운드 스레드는 NIXL 연결을 생성하거나 재사용하고, KV 블록 ID를 메모리 디스크립터로 변환하며, 연속 블록을 더 큰 전송 영역으로 병합한 뒤 WRITE를 제출한다. 이 분리는 요청마다 발생하는 디스크립터 준비와 전송 제출이 지연에 민감한 메인 루프의 모델 실행을 늦추는 일을 줄인다. 한편 pull은 prefill 완료 후 decode를 선택할 수 있어 부하와 서비스 품질을 반영한 라우팅에 더 유연하지만, push는 준비를 병행하기 위해 decode를 더 일찍 선택해야 한다. 그 대가로 push는 프롬프트 KV와 목적지 등록이 모두 준비되는 즉시 전송을 시작할 수 있어, 비슷한 부하에서 prefill이 KV 블록을 더 빨리 해제할 수 있다.

6. 평가 조건과 TTFT 결과

평가는 EFA로 연결된 Amazon EC2 P5en에서 prefill 한 대와 decode 한 대로 구성한 1P1D 배포와 Qwen3-32B 모델을 사용했다. 전송 자체의 성능을 분리해 보기 위해 --no-enable-prefix-caching으로 prefix caching을 비활성화했으며, 이 조건에서는 모든 요청이 prefill에서 전체 KV 캐시를 가져온다. 캐싱을 허용하면 겹치는 프롬프트가 decode의 로컬 캐시를 재사용해 전송을 우회할 수 있으므로, 전송 방식 비교를 왜곡할 수 있다는 설명이다. 출력 128토큰 조건에서 입력 길이 1k~16k와 요청률 1~8 QPS를 비교한 결과, 낮은 부하와 짧은 프롬프트에서는 두 방식의 TTFT가 거의 같았다. 그러나 8 QPS·16k에서는 pull이 약 1,744ms까지 증가한 반면 push는 약 540ms로 유지돼 약 3배의 개선을 보였으며, 원문은 pull의 decode 엔진 루프 안에서 동기적으로 수행되는 디스크립터 설정을 주요 원인으로 설명한다.

7. TPOT 결과와 토큰 생성 간섭

같은 평가 조건에서 출력 토큰당 시간인 TPOT도 TTFT와 유사하게 부하와 입력 길이가 커질수록 두 방식의 차이가 벌어졌다. 낮은 부하에서는 push와 pull이 모두 약 5.6~5.8ms로 가까워, 이 조건에서 얻는 지연 개선은 제한적이었다. 반면 입력 16k와 4~8 QPS에서는 pull이 약 10.4ms까지 증가했지만, push는 약 7ms를 유지했다. 원문은 push가 디스크립터 준비와 전송 제출을 decode 작업자에서 분리함으로써 토큰 생성에 필요한 실행 시간이 잠식되는 현상을 줄인다고 설명한다. 이에 따라 높은 동시성과 긴 문맥에서도 토큰당 지연이 상대적으로 안정적이었으며, 글은 해당 벤치마크의 최대 TPOT 개선 폭을 30%로 제시한다.

8. 재현 방법과 결과의 적용 범위

글은 같은 P5en·EFA 기반 1P1D 구성을 재현하려는 경우 별도의 Reproducing our results 가이드를 참고하도록 안내한다. 이 가이드는 환경 설정, vLLM prefill·decode 서버 실행, 벤치마크 수행과 결과 수집을 다루며, 본문은 재현 절차의 모든 세부 명령을 직접 제시하지 않는다. 기능 자체는 다른 지원 구성에서도 실행할 수 있지만, 성능은 하드웨어·모델·워크로드·네트워크 구성에 따라 달라진다고 명시한다. 따라서 Trainium에서 개발·검증하고 P5en GPU에서 개선을 확인했다는 사실은 가속기를 넘어 적용할 수 있음을 보여주지만, 다른 환경에서도 동일한 개선 폭을 보장하는 근거는 아니다. 결론은 prefill 계산과 목적지 준비를 겹치고 decode의 설정 부담을 줄이는 방식이 특히 높은 요청률에서 유효하다는 것이며, 최대 약 3배의 TTFT 개선과 30%의 TPOT 개선은 제시된 평가 조건에 연결해 해석해야 한다.

🧾 핵심 주장 / 시사점

• 같은 NIXL·EFA/RDMA 데이터 경로에서도 준비 작업의 시점과 실행 위치를 바꾸면 TTFT와 TPOT를 함께 개선할 수 있다는 결과다.
• 긴 입력과 높은 QPS에서 격차가 커진 점은 전송 준비가 decode의 토큰 생성과 실행 시간을 두고 경쟁하는 문제가 부하에 따라 커질 수 있음을 보여준다.
• push 도입의 판단에는 지연 개선뿐 아니라 decode 조기 선택으로 달라지는 라우팅 유연성도 포함된다. 최대 성능 수치는 prefix caching을 끈 특정 구성의 결과라는 조건과 함께 해석해야 한다.

✅ 액션 아이템

• Qwen3-32B·Amazon EC2 P5en·EFA의 1P1D 비교 시 prefix caching 비활성화, 입력 1k~16k, 요청률 1~8 QPS, 출력 128토큰 조건을 반영한 TTFT·TPOT 비교.
• 긴 입력·높은 QPS에서 push의 TTFT·TPOT 개선과 짧은 입력·낮은 부하에서의 작은 차이를 구분해 적용 효과 평가.
• decode 조기 선택에 따른 라우팅 유연성 변화와 prefill KV 블록의 조기 해제 효과를 함께 고려해 push 적용 판단.

❓ 열린 질문

• Qwen3-32B·1P1D·Amazon EC2 P5en·EFA와 다른 구성에서는 TTFT와 TPOT 개선 폭이 어떻게 달라지는가?
• prefix caching을 활성화하면 push와 pull의 TTFT·TPOT 격차는 어떻게 달라지는가?
• decode 조기 선택에 따른 라우팅 유연성 감소와 prefill KV 블록의 빠른 해제는 실제 부하에서 어떤 절충을 만드는가?