vLLM 푸시 기반 KV 전송, Prefill과 Decode 사이의 대기 시간 겨냥
vLLM 푸시 기반 KV 전송은 캐시 핸드오프 작업을 더 이른 시점으로 옮긴다. AWS는 풀 기반 벤치마크와 비교해 첫 토큰 지연 시간에서 최대 3배의 개선을 보고했다. TTFT(time to first token)는 요청이 출력 생성을 시작하기 전까지 기다리는 시간을 측정한다. 이 변경은 프롬프트 처리와 답변 생성 사이의 조율을 겨냥한다.
AWS는 10월 19일 게시물에서 이후 각 토큰의 생성 시간을 측정하는 TPOT(time per output token)도 최대 30% 개선됐다고 밝혔다. 이 결과는 AWS의 저지연 서버 인터커넥트인 AWS Elastic Fabric Adapter를 사용하는 Amazon EC2 P5en 인스턴스에서 Qwen3-32B를 대상으로 측정한 것이다. 이는 모든 vLLM 배포 환경에 적용되는 일반적인 가속 약속이 아니라, 특정 비교의 결과를 설명한다.
핵심 경쟁은 푸시와 풀 방식의 조율에 있다. 푸시는 수신 엔진을 더 일찍 준비하고, 풀은 생성이 실행될 위치를 더 늦게 결정할 수 있도록 한다. 프롬프트 처리와 생성을 분리하는 운영자에게 이 소식은 구체적인 질문을 제기한다. 더 짧은 핸드오프를 위해 어느 정도의 라우팅 유연성을 교환할 것인가?
vLLM 푸시 기반 KV 전송은 핸드오프가 시작되는 시점을 바꾼다
이 변경은 핸드오프 이후가 아니라 그 이전에 준비 작업을 옮겨, 프롬프트 처리가 끝난 뒤 수행해야 하는 작업을 줄인다.
입력 토큰을 처리하는 추론 단계인 Prefill은 이후 생성에 필요한 중간 어텐션 상태를 담은 키-값 캐시를 만든다. 출력 토큰을 생성하는 단계인 Decode는 이 상태를 사용한다. 분산 추론은 이 단계를 별도의 엔진 인스턴스에 배치하며, 그 사이에 전송 경계를 만든다.
AWS의 KV 전송 벤치마크는 하나의 Prefill 인스턴스와 하나의 Decode 인스턴스를 사용해 푸시와 풀을 비교한다. 이 테스트는 요청이 이전에 계산된 상태를 재사용할 수 있게 하는 프리픽스 캐싱을 비활성화한다. 출력 토큰은 128개로 설정했으며, 입력 길이는 1,000~16,000토큰, 요청률은 초당 1~8개 쿼리로 구성했다.
가장 까다로운 조건에서 AWS는 풀의 TTFT가 약 1,744밀리초인 데 비해 푸시는 약 540밀리초라고 보고했다. 보고된 TPOT 비교에서는 풀 약 10.4밀리초, 푸시 약 7밀리초에 이른다. 낮은 부하와 짧은 입력에서는 두 방식의 성능이 비슷하다.
이러한 경계 조건은 헤드라인의 배수보다 더 중요하다. 이 결과는 핸드오프 조율이 중요한 영향을 미치는 워크로드를 보여 준다. 사용량이 적은 서비스나 다른 모델, 더 큰 배포 환경에서도 같은 이점을 얻는다는 점을 입증하지는 않는다.
실무적으로는 응답성이 악화될 때 운영자가 무엇을 조사해야 하는지가 바뀐다. 첫 응답이 느리다고 해서 프롬프트 계산에 더 많은 가속기 용량이 필요한 것은 아니다. 다음 단계를 정리하는 데 소요되는 시간도 별도로 면밀히 살펴야 한다.
이 구분은 제품 팀이 성능 장애를 해석하는 방식도 바꾼다. 사용자가 답변 지연을 보고한다면, 팀은 계산을 기다리는 시간과 조율을 기다리는 시간을 구별해야 한다. 리소스 추가는 이 원인들을 서로 다르게 해결하며, 종합 지연 시간 차트는 그 차이를 가릴 수 있다.
따라서 이 벤치마크는 한 가지 분명한 결론을 뒷받침한다. 캐시 전송을 둘러싼 순서는 측정되는 사용자 경험에 실질적인 영향을 줄 수 있다. 다음 단계는 그 순서가 특정 서비스의 지연 시간에서 의미 있는 비중을 차지하는지 파악하는 것이다.
이를 풀이 보편적인 대체재라고 부르는 것은 증거를 과장하는 일이다. 더 유용한 해석은 vLLM이 이제 또 하나의 스케줄링 선택지를 제공한다는 것이다. 운영자는 실제로 필요한 워크로드와 라우팅 동작을 기준으로 그 선택지를 평가할 수 있다.
이 시점이 중요한 이유는 이것이 모델 발표가 아니라 구현 수준의 서빙 개선이기 때문이다. 팀은 모델 품질의 변화를 가정하지 않고도 이를 검토할 수 있다. 잠재적 이점은 기존 요청이 인프라를 통과하는 방식에 있다.
서빙 팀은 컴퓨팅 문제와 함께 조율 문제에도 직면한다
프롬프트 처리와 토큰 생성을 분리해 지연 시간 목표를 달성하는 운영자에게 부담이 집중된다.
vLLM의 분산 Prefill 문서는 첫 토큰 지연 시간과 토큰 간 지연 시간을 각각 독립적으로 조정하는 관점에서 분리를 설명한다. 또한 이미 답변을 생성 중인 엔진에 프롬프트 처리가 유입될 때 발생하는 간섭도 지적한다. 이 문서는 이 기능을 실험적이라고 표시하며, 분산화 자체를 처리량 개선으로 간주하지 말라고 명시적으로 주의한다.
이는 광범위한 아키텍처 주장에 중요한 균형추가 된다. 작업을 분리하면 독립적 조정의 기회가 생기지만, 동시에 책임도 추가된다. 시스템은 상태를 조율하고, 목적지를 선택하며, 추가 경계를 넘어 요청이 계속 진행되도록 해야 한다.
가상의 문서 지원 도우미를 예로 들면, 이러한 책임은 익숙한 사용자 행동과 연결된다. 사용자는 긴 문서를 제출하고 답변이 시작되기를 기다린다. 동시에 다른 사용자는 이미 시작된 응답이 안정적으로 계속 도착하기를 기대한다.
이 기대들은 서로 관련돼 있지만, 서로 대체할 수는 없다. 서비스는 답변을 빠르게 시작하면서도 이후 불규칙하게 전달할 수 있다. 반대로 시작 후에는 매끄럽게 생성하지만, 아무것도 표시되기 전까지 사용자를 지나치게 오래 기다리게 할 수도 있다.
푸시 제안이 중요한 이유는 운영자가 두 경험을 모두 평가해야 하기 때문이다. 커넥터 결정은 하나의 유리한 평균이 아니라 응답 시작과 지속적인 생성 모두를 기준으로 판단해야 한다. 그렇지 않으면 팀은 관찰하는 지표는 개선하면서 사용자가 체감하는 경험을 놓칠 위험이 있다.
이는 인프라 담당자에게 측정 모델을 개선해야 한다는 압박을 만든다. 총 소요 시간과 함께 요청의 각 단계에 대한 가시성이 필요하다. 이러한 분리가 없으면 조율 오버헤드가 모델 실행 시간으로 오인될 수 있다.
호스팅 추론을 평가하는 구매자에게도 압박이 생긴다. 보고된 가속 비율에는 기준선, 워크로드, 운영 경계가 필요하다. 구매자는 서비스 비교에 사용하기 전에 결과의 기반에서 무엇이 바뀌었는지 물어야 한다.
이 구분은 특히 애플리케이션이 긴 요청과 짧은 요청을 함께 처리할 때 중요하다. 평균 프롬프트 길이는 가장 큰 스케줄링 부담을 만드는 요청을 가린다. 설득력 있는 평가는 이러한 변동을 균일한 입력으로 대체하지 않고 유지해야 한다.
이 모든 것이 모든 애플리케이션에 분산화가 필요하다는 뜻은 아니다. 결정은 여전히 서비스에서 관찰된 제약에서 시작한다. 현재 아키텍처가 응답 목표를 충족한다면, 전송 경계를 추가하려면 별도의 근거가 필요하다.
하지만 이미 단계를 분리해 운영하는 팀에게 커넥터는 성능 계획의 일부가 된다. 그 동작은 라우터가 무엇을 알아야 하는지, 리소스가 언제 할당되는지에 영향을 준다. 따라서 이 변경은 전송 코드를 유지보수하는 엔지니어를 넘어 관련성을 갖는다.
이에 따라 제품 팀과 플랫폼 팀은 성공에 대한 공통의 설명이 필요하다. 유용한 설명은 사용자에게 보이는 대기 시간과 인프라 측정치, 배포 조건을 연결한다. 커넥터의 벤치마크를 애플리케이션의 완전한 예측으로 취급하지 않는다.
이러한 평가를 관리하는 팀은 검색 가능한 지식 베이스에 조사 결과를 정리할 수 있다. 구성 정보를 결론과 함께 보관하면, 이후 검토자가 이전 결과가 적용됐거나 적용되지 않은 이유를 이해하는 데 도움이 된다.
이른 목적지 설정이 푸시의 장점을 만든다
푸시는 캐시 상태를 이동할 필요를 없애는 것이 아니라, 전송을 둘러싼 의존성의 순서를 바꾼다.
푸시 커넥터 설계는 NVIDIA Inference Xfer Library, 즉 NIXL을 사용해 전송을 조율하는 대안인 NixlPushConnector를 문서화한다. 수신 Decode 엔진은 목적지 메모리를 할당하고 그 위치를 알린다. 그러면 Prefill 엔진은 완료된 상태를 준비된 목적지에 기록한다.
등록 정보와 완료된 프롬프트 상태는 어느 순서로든 도착할 수 있다. 커넥터는 쓰기 작업을 시작하기 전에 이들을 매칭한다. 백그라운드 작성자 스레드가 푸시 전용 작업을 처리하고, 완료 상태 계산은 수신된 상태가 준비됐는지 엔진에 알린다.
이것이 vLLM 푸시 전송의 핵심 설명이다. 유용한 계산이 계속되는 동안 목적지를 준비하고, 전제 조건이 갖춰졌을 때 핸드오프를 완료한다. 이러한 순서는 Prefill이 끝난 뒤 모든 조율을 시작할 필요를 줄인다.
이 차이는 의존성 문제로 보면 더 쉽게 평가할 수 있다. 계산이 끝날 때까지 준비를 시작할 수 없다면, 요청은 두 작업을 순차적으로 모두 기다려야 한다. 준비가 계산과 겹치면 생성 시작 시점을 결정하는 경로에서 일부 대기가 사라진다.
이 중첩에도 조건은 있다. 수신자가 존재해야 하고, 목적지가 적합해야 하며, 전송이 올바르게 완료돼야 한다. 일찍 준비한다고 해서 이러한 책임이 선택 사항이 되는 것은 아니며, 단지 발생 시점이 바뀔 뿐이다.
그래서 단순히 푸시를 더 빠른 네트워크 작업이라고 설명하면 메커니즘을 놓치게 된다. 아키텍처의 질문은 어떤 작업이 진행을 막는지에 관한 것이다. 전송이 뛰어난 하드웨어를 사용하더라도 주변 소프트웨어가 요청을 불필요하게 기다리게 할 수 있다.
백그라운드 실행은 또 다른 유용한 구분을 만든다. 더 이상 엔진 루프를 차단하지 않는 작업도 어딘가에서는 리소스를 소비한다. 따라서 운영자는 작업이 어디로 이동했는지, 그 위치가 지속적인 수요 아래에서도 건전한지 물어야 한다.
같은 논리는 TPOT 해석에도 적용된다. 조율이 기존 요청을 처리하는 실행 경로와 경쟁한다면, 전송 관련 변경은 지속적인 생성에 영향을 줄 수 있다. 새로 유입되는 요청만 평가하면 이 상호작용을 놓치게 된다.
따라서 vLLM 푸시와 풀을 비교할 때 결정적인 비교는 쓰기와 읽기보다 더 넓다. 여기에는 목적지 선택, 준비 시점, 실행 주체, 준비 완료 신호가 포함된다. 이러한 세부 사항은 커넥터 변경이 모델을 바꾸지 않고도 애플리케이션 동작을 바꿀 수 있는 이유를 설명한다.
이 구현은 또한 모든 배포 결정에서 정확성이 성능과 함께 고려돼야 하는 이유를 보여 준다. 생성에 완전하게 예상된 상태가 필요하다면 일부 상태를 받는 것만으로는 충분하지 않다. 특히 작업이 여러 참여자에 걸쳐 있을 때 성공적인 핸드오프에는 모호하지 않은 준비 완료 조건이 필요하다.
NVIDIA는 Dynamo의 분산 서빙 아키텍처를 통해 유용한 업계 참고 사례를 제공한다. 해당 문서는 분리된 Prefill 및 Decode 풀, 라우터 오케스트레이션, 토폴로지를 고려한 전송 요소를 설명한다. 이는 vLLM 커넥터 대비 성능 순위의 증거가 아니라, 비교 가능한 조율 문제를 보여 준다.
Dynamo 역시 서빙 엔진을 위한 통합 환경이므로, 이를 단순한 회사 대 회사 경쟁으로 규정하면 오해의 소지가 있다. 관련된 경쟁은 요청을 구성하는 방식들 사이에 있다. 각 접근 방식은 배치, 상태 이동, 생성 준비 상태를 조율해야 한다.
AWS 결과를 그런 맥락에서 바라볼 필요가 있다. 이 기여는 더 큰 서빙 워크플로 안의 특정 지점에 관한 것이다. 그 가치는 해당 지점을 개선하는 일이 서비스의 실제 응답 목표를 진전시키는지에 달려 있다.
더 이른 디코더 선택은 유연성과 중첩을 맞바꾼다
pull을 유지해야 하는 가장 강력한 이유는 목적지를 더 나중에 선택할 수 있다는 가치다.
push 순서는 핸드오프 전에 준비된 수신자를 요구한다. 이러한 확정은 중첩을 가능하게 하지만, 동시에 이 글의 핵심적인 상충 관계를 만든다. 운영자는 목적지 선택 시점과 분리해 조정 지연 감소를 평가할 수 없다.
요청이 디코더 풀 전체에 고르지 않게 도착하는 가상의 서비스를 생각해 보자. 목적지를 일찍 선택하면 프롬프트 처리가 완료되기 전에 경로를 예약하게 된다. 나중에 선택하면 라우팅 결정 시점에 시스템의 더 최신 정보를 활용할 수 있다.
어느 선택도 자동으로 더 우월한 것은 아니다. prefill 동안 조건이 예측 가능하게 유지된다면, 조기 선택은 합리적인 교환일 수 있다. 조건이 크게 바뀐다면, 나중 선택에는 전송 중심 벤치마크가 포착하지 못하는 운영상 가치가 있을 수 있다.
관련 질문은 그 유연성이 결과를 얼마나 자주 바꾸는가다. 운영자는 지연된 선택이 큐를 의미 있게 줄이는지, 과부하된 워커를 피하는지, 또는 서비스 일관성을 높이는지 살펴봐야 한다. 그러한 관찰이 없다면 유연성은 측정된 요구 사항이 아니라 추상적인 이점으로 남는다.
이것이 페어링된 배포만으로 모든 라우팅 문제를 결론낼 수 없는 이유이기도 하다. 이는 핸드오프를 검토하기 위한 통제된 환경을 제공한다. 특히 여러 목적지의 워크로드가 서로 다를 때, 많은 목적지 가운데 선택하는 문제에 대해서는 근거가 제한적이다.
캐시 재사용 사례는 또 다른 경계를 더한다. vLLM은 10월 12일 게시물에서 이후 대화 턴에 decode의 재사용 가능한 상태를 prefill로 되돌리는 양방향 KV 전송을 설명했다. 이 작업은 NIXL 읽기를 양방향으로 사용해 대화 기록이 늘어날 때 반복 연산을 다룬다.
이는 다른 최적화 목표를 나타낸다. 더 짧은 순방향 핸드오프와 더 적은 반복 프롬프트 연산은 모두 응답성을 높일 수 있다. 하지만 이점이 자동으로 결합된다고 가정해서는 안 되며, 동일한 작업을 측정하는 것처럼 비교해서도 안 된다.
대화형 어시스턴트는 이 차이를 잘 보여 준다. 첫 요청과 누적된 기록을 포함하는 이후 요청은 인프라에 서로 다른 요구를 가할 수 있다. 한 전환을 개선했다고 해서 전체 대화에 가장 적합한 정책이 확립되는 것은 아니다.
vLLM push와 pull의 비교에서는, 제품이 이에 의존한다면 평가에 세션 동작을 포함해야 한다는 의미다. 서로 관련 없는 프롬프트의 균일한 스트림은 더 좁은 질문에만 답한다. 이는 애플리케이션의 반복 상호작용을 시험하는 일을 대체할 수 없다.
캐시 비활성화 벤치마크도 같은 신중한 처리가 필요하다. 재사용을 제거하면 전송 동작을 분리하는 데 도움이 되지만, 프로덕션 환경의 재사용은 그 동작이 얼마나 자주 중요해지는지를 바꾼다. 전체 전송을 자주 피하는 애플리케이션은 다른 기회 프로필을 갖는다.
그렇다고 통제된 비교가 무효가 되는 것은 아니다. 그 목적을 규정할 뿐이다. 운영자는 분리된 결과를 유지하면서 애플리케이션의 실제 캐싱 및 라우팅 결정을 복원한 워크로드 평가를 추가해야 한다.
보고된 향상 폭에도 근거상의 경계가 있다. 수치는 여기서 검토한 독립 재현 결과가 아니라 참여한 기술 소스에서 나온 것이다. 조사할 가치는 있지만, 보편적 우위나 보장된 플릿 비용 절감을 주장하는 근거는 되지 못한다.
따라서 회의적인 결론은 구체적이다. 조기 준비에는 이해 가능한 메커니즘이 있지만, 그 전체 가치는 배포 환경에 따라 달라진다. 건전한 도입 결정은 조정 이점과 그 대가로 교환하는 유연성을 함께 측정해야 한다.
pull 기준선도 변하고 있다
보고된 이점의 일부는 전송 준비가 실행되는 위치와 관련되며, 이는 pull도 다시 검토할 수 있는 설계 선택이다.
공개된 reader-thread 제안은 NIXL pull 제출을 대상으로 한다. 명시된 목적은 읽기 제출을 전용 백그라운드 스레드로 옮겨 엔진의 forward 실행 스레드에서 수행되는 작업을 줄이는 것이다. 이 제안은 완료 폴링을 forward 스레드에 유지한다.
이 글에서 검토한 페이지는 해당 제안을 open 상태로 표시한다. 이는 진행 중인 개발을 보여 줄 뿐, 제공된 성능 결과를 의미하지는 않는다. 미래의 pull 구현이 push와 일치하거나 격차의 특정 비율을 해소한다고 주장할 근거는 제공하지 않는다.
그 중요성은 개념적이다. 전송 방향과 실행 위치는 별개의 선택이다. push는 더 이른 목적지 준비의 이점을 얻을 수 있고, 백그라운드 실행은 다른 간섭 원인을 해결한다.
이 구분은 벤치마크 우위의 해석을 바꾼다. 비교는 그 시점에 시험된 구현을 포착한다. 승자에게 붙은 아키텍처 레이블에 관측된 모든 이점을 영구적으로 귀속하지는 않는다.
구매자와 운영자에게 실질적인 결과는 버전 인식이다. “Push”와 “pull”만으로는 평가 환경을 설명하기에 충분하지 않다. 관련 구현과 구성에 따라 어느 준비 단계가 어디에서 실행되는지가 결정된다.
따라서 유지보수 이력도 성능 근거의 일부가 된다. 이후 커넥터 업데이트는 모델이나 하드웨어를 바꾸지 않고도 기준선을 바꿀 수 있다. 팀은 실행 동작이 실질적으로 바뀔 때 이전 결론을 다시 검토해야 한다.
reader-thread 작업은 근본 설명을 검증하는 유용한 시험도 제공한다. 백그라운드 제출이 비교 가능한 조건에서 pull을 개선한다면, 이는 실행 위치의 중요성을 뒷받침할 것이다. 그렇다고 그 자체로 목적지 설정을 중첩하는 별도의 이점을 없애지는 않는다.
반대로 제한적인 개선도 해석이 필요하다. 남은 지연은 다른 종속성과 관련될 수 있고, 워크로드가 다른 제약을 드러낼 수도 있다. 기대에 못 미치는 결과가 이 제안의 설계가 다른 곳에서 가치가 없음을 자동으로 증명하는 것은 아니다.
성능 보고에는 이 지점에서 절제가 필요하다. 유용한 보고서는 측정된 내용, 이를 설명하는 메커니즘, 그리고 여전히 가설인 내용을 구분한다. 이 범주를 합치면 자신감 있는 헤드라인은 만들 수 있지만 운영 지침은 약해진다.
vLLM의 push 기반 KV 전송에서 오래 지속될 교훈은 핸드오프 주변의 작업을 살펴보는 것이다. 커넥터 이름은 동작을 요약하지만 모든 지연을 설명하지는 않는다. 실제 실행 경로의 프로파일링은 여전히 필요하다.
변화하는 기준선은 성급한 표준화 결정도 막는다. 팀은 현재 요구를 충족하는 구성을 채택하면서도 재검토할 근거를 보존할 수 있다. 목표는 전송 방향에 대한 영구적 충성이 아니라 신뢰할 수 있는 서비스다.
재현, pull-thread 진행 상황, 라우팅 동작을 지켜봐야 한다
다음으로 유용한 근거는 분리된 조정 이점이 현실적인 배포 선택에서도 유지되는지를 보여 줄 것이다.
향후 1~3개월 동안 가장 먼저 주시할 신호는 애플리케이션 형태의 워크로드 전반에서 이뤄지는 독립 재현이다. 가장 유익한 결과는 동일한 비교를 유지하되 프롬프트 분포, 캐싱 동작, 배포 규모를 달리하는 것이다. 일관된 개선은 더 폭넓은 도입의 근거를 강화할 것이다.
재현은 응답 시작과 지속적인 생성도 구분해야 한다. 서비스는 상호작용 전반에서 더 민첩해지는지 알아야 한다. 유난히 부담이 큰 벤치마크 지점에만 국한된 긍정적 결과는 더 제한적인 배포 결정을 뒷받침할 것이다.
두 번째 신호는 pull을 위한 백그라운드 제출의 진행 상황이다. 검토와 릴리스를 거친 구현에 이어 비교 가능한 벤치마크가 나오면 실행 위치가 얼마나 기여하는지 분명해질 것이다. 격차가 작아진다면 메커니즘 설명은 강화되는 한편, push를 범주적으로 우월하다고 취급할 근거는 약해질 것이다.
이 신호에는 실제 측정 결과가 필요하다. 병합된 변경만으로는 성능 동등성이 아니라 제공 가능 여부만 입증한다. 운영자는 관련 워크로드가 시험되기 전에 개발 활동을 수치적 주장으로 바꾸는 일을 피해야 한다.
세 번째 신호는 고정된 prefill-decode 쌍을 넘어서는 라우팅 동작이다. 결과는 조기 목적지 선택이 변화하는 디코더 수요와 만날 때 어떤 일이 일어나는지 보여줘야 한다. 안정적인 사용자 대면 지연 시간은 현실적인 배치 압력에서도 중첩의 가치가 유지된다는 근거를 강화할 것이다.
반대로 조기 확정이 다른 곳에서 더 긴 큐를 만든다면, 선호되는 배포 경계는 좁아질 것이다. push는 여전히 예측 가능한 워크로드에 적합할 수 있지만, 나중 선택은 다른 경우에 계속 가치가 있을 수 있다. 이는 결과를 부정하는 것이 아니라 정교화하는 일이다.
이러한 신호는 논의를 원래 사건과 연결해 둔다. 질문은 준비를 더 앞당기는 일이 해당 서비스의 자체 운영 조건에서 완전한 서비스를 개선하는가다. 추론 경제성에 대한 더 광범위한 주장은 이 커넥터 비교가 제공하는 것보다 더 폭넓은 근거를 필요로 한다.
지금 무엇을 할지 결정하는 팀이라면, 대표적인 요청 추적과 명확히 정의된 응답 목표에서 시작해야 한다. 커넥터 결과를 비교할 때 모델, 캐싱 정책, 라우팅 동작, 구현 버전을 보존하라. 대기가 어디에서 발생하는지 기록한 뒤, 더 이른 준비가 다른 곳에 더 큰 큐를 만들지 않으면서 그 지연을 줄이는지 살펴보라. 통제된 벤치마크와 프로덕션 형태의 평가를 분리해 각각이 명확한 질문에 답하도록 하라. 보고된 비율을 용량 결정으로 옮기기 전에 설계와 벤치마크 조건을 읽어야 한다. vLLM의 push 기반 KV 전송에서 유용한 조치는 애플리케이션이 실제로 수행하는 핸드오프에 대한 범위가 정해진 평가다. 더 이른 목적지 준비가 서비스가 감당해야 하는 부하에서 사용자가 실제로 받는 경험을 개선하는가?
