vLLM 양방향 KV 전송, 멀티턴 에이전트의 반복 작업 감소

AWS는 재사용 가능한 모델 연산을 서버 간 양방향으로 이동시키는 vLLM 양방향 KV 전송을 사용해 첫 토큰 생성 속도가 최대 3.3배 향상됐다고 보고했다. 첫 토큰까지의 시간(Time to First Token, TTFT)은 요청이 응답 시작 전까지 대기하는 시간을 측정한다. 이 변화는 에이전트가 서빙 인프라가 이미 계산한 대화 이력을 반복 처리하는 특정 비효율을 겨냥한다.

AWS는 10월 19일 게시물에서 Qwen3-32B의 경우 최대 1.6배, GLM-5-FP8의 경우 최대 3.3배의 개선을 보고했다. AWS의 멀티턴 추론 벤치마크는 까다로운 분산 워크로드를 위해 설계된 AWS 네트워킹인 Elastic Fabric Adapter로 연결된 Amazon EC2 P5en 인스턴스를 사용했다. 이는 독립적으로 확립된 성능 보장이 아니라 회사가 보고한 결과다.

핵심 경쟁은 기존 컨텍스트를 다시 계산하는 방식과 다른 서버에서 재사용 가능한 연산을 가져오는 방식 사이에 있다. NVIDIA Dynamo는 이러한 인프라 선택을 이해하는 데 유용한 업계 기준점이다. 에이전트를 구축하는 개발자에게 당면한 질문은 자체 워크로드가 추가 조정을 정당화할 만큼 기존 작업을 반복하는 데 충분한 시간을 쓰는지다.

vLLM 양방향 KV 전송이 바꾸는 점

이 기능은 이전 응답에서 완료된 작업을 다음 요청을 처리하는 서버에서 사용할 수 있게 한다.

키-값 캐시(KV cache)는 언어 모델이 시퀀스를 처리할 때 재사용하는 중간 어텐션 데이터를 저장한다. Prefill은 모델이 소비하는 텍스트 단위인 입력 토큰을 처리한다. Decode는 응답을 생성한다. 분리형 서빙에서는 별도의 워커가 이 단계를 처리한다.

새 경로가 중요한 이유는 응답을 생성하는 서버가 해당 응답에서 얻은 유용한 연산 결과를 보유하기 때문이다. 이후 요청에는 앞선 대화와 함께 생성된 단어가 포함될 수 있다. 다른 서버가 해당 요청을 처리하면, 유용한 캐시 작업은 그렇지 않으면 생성 측에 고립된 채 남을 수 있다.

NIXL 커넥터 가이드는 턴 전반에 걸쳐 캐시 위치를 추적하는 상태 저장 프록시를 설명한다. NVIDIA Inference Xfer Library인 NIXL은 전송 메커니즘을 제공한다. 이후 턴에서 prefill 워커는 새 입력을 처리하기 전에 decode 워커에서 적격 블록을 가져올 수 있다.

이는 재사용 가능한 작업의 출처를 확장한다. 그러나 실제로 새로 들어온 자료를 처리할 필요를 없애지는 않는다.

실패한 빌드를 조사하는 예시 코딩 에이전트를 생각해 보자. 에러를 읽고, 설명을 제안하고, 도구를 호출한 뒤 테스트 결과를 받는다. 다음 모델 요청에는 익숙한 대화 이력과 새로운 증거가 모두 포함된다. 익숙한 부분을 다시 계산해도 조사에 새로 기여하는 것은 없다.

기존 연산을 이동하는 시간이 다시 구축하는 시간보다 짧을 때 가져오기는 매력적이다. 이 조건이 기능의 경제적·기술적 핵심이다. 연산을 절약하더라도 더 긴 대기 시간을 추가하는 전송은 목적에 어긋난다.

이 때문에 이 소식은 더 빠른 모델 벤치마크를 넘어선다. 모델은 그대로일 수 있지만, 서빙 시스템은 호출 사이에서 이전 작업이 얼마나 유지되는지를 바꿀 수 있다. 인프라 동작은 에이전트 응답성의 일부가 된다.

제품 팀에는 이 구분이 책임 소재를 파악하는 데 도움이 된다. 느린 후속 응답이 선택한 모델을 교체해야 한다는 뜻은 아니다. 애플리케이션이 이미 처리한 컨텍스트에 대해 다시 비용을 지불하고 있을 수 있다.

인프라 팀에는 분석 단위가 달라진다. 모든 요청을 무관한 것으로 취급하면, 요청이 지속 중인 작업에 속할 때만 드러나는 기회를 놓칠 수 있다. 대화는 스케줄링과 캐시 관리에서 관련성이 생긴다.

따라서 실질적인 변화는 영구적인 에이전트 메모리보다 범위가 좁지만 더 구체적이다. 이는 지속되는 입력 시퀀스에 연결된 재사용 가능한 연산에 관한 것이다. 에이전트가 올바른 사실을 기억하는지는 별개의 애플리케이션 문제로 남는다.

이 경계는 발표의 유용성을 유지한다. 추론 품질, 도구 신뢰성 또는 에이전트 주변의 모든 지연을 해결한다고 주장하지 않으면서 측정 가능한 지연 원인을 짚는다.

길어지는 대화는 서빙 팀에 부담을 준다

가장 큰 영향을 받는 팀은 동일한 작업 안에서 컨텍스트가 많은 모델 호출을 반복적으로 제공하는 팀이다.

이 부담은 애플리케이션 동작과 요청 중심 인프라 간의 불일치에서 비롯된다. 에이전트의 작업은 호출을 넘어 계속되지만, 서빙 시스템은 여전히 각 요청마다 어떤 연산이 유지될지 결정해야 한다.

예시 리서치 어시스턴트를 보면 이 불일치를 쉽게 이해할 수 있다. 문서를 수집하고, 결과를 비교하고, 수정 요청을 받은 뒤 답변을 고친다. 각 단계에서 새 정보가 추가되지만, 작업 컨텍스트의 상당 부분은 계속 관련성을 유지한다.

사용자 관점에서 이 단계들은 같은 작업에 속한다. 서빙 계층 관점에서는 각 단계가 처리할 입력을 포함한 또 하나의 요청을 만든다. 모든 입력 부분이 재사용된다고 가정하지 않으면서 연속성을 인식하는 데 기회가 있다.

에이전트 시연을 평가하는 엔터프라이즈 구매자에게도 이 구분은 중요하다. 반응이 빠른 첫 대화가 긴 조사가 계속해서 빠르게 반응한다는 것을 입증하지는 않는다. 평가는 수정과 도구 반환을 포함한 이후 턴까지 작업을 따라가야 한다.

투자처를 선택하는 엔지니어링 관리자에게도 중요하다. 모델 선택, 애플리케이션 설계, 서빙 구성은 서로 다른 지연 원인을 다룬다. 이러한 원인이 분리되기 전까지 에이전트가 느리다는 포괄적 불만은 실질적인 지침을 거의 제공하지 못한다.

vLLM 문서는 분리형 prefill 가이드에서 관련 구분을 제시한다. Prefill과 decode를 분리하면 각 단계의 지연 특성을 독립적으로 조정할 수 있다. 또한 문서는 분리 자체가 시스템이 시간에 따라 완료하는 작업량인 처리량을 개선하지는 않는다고 주의한다.

이 경고는 더 빠른 응답 시작이 더 큰 총처리 용량으로 이어진다는 성급한 결론을 막는다. 애플리케이션은 한 지연 측정값을 개선할 수 있지만, 다른 병목은 그대로일 수 있다. 구매자는 제안된 인프라 변경이 실제로 어떤 결과를 겨냥하는지 물어야 한다.

고객 지원 에이전트는 이 차이를 보여준다. 설명을 더 빨리 시작하면 대화가 반응성 있게 느껴지는 데 도움이 된다. 그렇다고 느린 계정 조회나 외부 작업을 완료하는 데 필요한 시간이 반드시 줄어드는 것은 아니다.

마찬가지로 코딩 어시스턴트는 테스트 스위트를 더 빨리 끝내지 못하더라도 수정 설명을 더 빨리 시작할 수 있다. 성능 개선은 여전히 가치가 있지만, 그 기여는 더 큰 작업 타임라인 안에 위치한다.

지식 근로자에게 개인 지식 베이스와의 연결은 실용적이다. 유용한 정보를 찾는 일과 반복되는 컨텍스트를 처리하는 일은 서로 다른 대기 시간을 만든다. 한쪽을 개선했다고 다른 쪽도 개선됐다고 볼 수는 없다.

제품 팀에 대한 함의는 응답 시작과 완료된 작업을 모두 측정해야 한다는 것이다. 그렇지 않으면 인프라 개선이 마케팅에서 과장되거나 개발 과정에서 간과될 수 있다.

이것이 vLLM 멀티턴 추론을 하나의 시퀀스로 평가해야 하는 이유다. 중요한 질문은 단순히 서버가 빠르게 답하는지가 아니다. 작업이 커질수록 반복 상호작용이 유용한 작업을 보존하는지다.

재사용은 경쟁 모델이 아니라 재계산과 경쟁한다

가장 강력한 비교는 동일한 지속 워크로드를 제공하는 대안적 방식들 사이에서 이루어진다.

이 발표를 모델 리더보드로 바꾸는 것은 오해를 불러일으킨다. AWS는 서빙 최적화를 테스트했다. 이 결과는 한 모델이 다른 모델보다 더 뛰어난 능력을 갖추게 됐다는 것을 입증하지 않는다.

기존 기준선도 신중하게 다뤄야 한다. vLLM은 이미 요청이 초기 시퀀스를 공유할 때 캐시된 연산을 재사용하는 자동 프리픽스 캐싱을 지원한다. 문서는 반복적인 문서 질의와 다회차 대화를 관련 워크로드로 제시한다.

따라서 양방향 전송은 워커 간 재사용 가능한 연산에 접근하는 문제를 다룬다. 반복적인 프롬프트 처리를 피한다는 일반적 개념을 새로 도입하는 것은 아니다.

이 구분은 팀이 비교를 해석해야 하는 방식을 바꾼다. 이미 유용한 로컬 캐시를 보존하는 배포 환경은 그 접근 권한을 반복적으로 잃는 환경과 출발점이 다르다. 점진적 이점은 기존 시스템이 실제로 무엇을 하는지에 달려 있다.

vLLM의 prefill-decode 분할은 연산 문제뿐 아니라 배치 문제도 만든다. 유용한 작업은 배포 환경 어딘가에 존재할 수 있지만, 다음 요청이 필요로 하는 곳에서는 사용할 수 없을 수 있다.

유용한 비유는 완료된 결과가 다른 팀에 있어 엔지니어링 팀이 분석을 반복하는 상황이다. 부족한 요소는 접근성과 조정이다. 원래 계산을 더 빠르게 만드는 것은 문제의 다른 부분을 해결한다.

NVIDIA의 분리형 서빙 문서는 중립적인 비교 기준을 제공한다. Dynamo는 prefill 워커와 decode 워커를 분리하고, 그 분리와 캐시 위치 기반 라우팅을 구별한다. 또한 분리가 모든 워크로드에 자동으로 더 나은 선택은 아니라고 경고한다.

이 때문에 Dynamo는 직접적인 경쟁 우위의 증거가 아니라 업계 기준점이 된다. 문서는 워커 배치, 전송, 재사용이 더 광범위한 서빙 문제임을 보여준다. 이 AWS 구성에 대한 동등 조건 비교를 제공하지는 않는다.

구매자에게 유용한 경쟁 질문은 대체 시스템이 비교 가능한 조건에서 자체 대화 패턴을 더 효율적으로 처리하는지다. 제품명만으로는 답할 수 없다.

동일한 논리는 기존 배포 환경 내 vLLM 멀티턴 추론에도 적용된다. 팀은 제안된 경로를 실제 현재 구성과 비교해야 한다. 인위적으로 더 약한 구성과 비교하면 더 좁은 질문에만 답하게 된다.

복잡성을 어디에 둘지에 대한 선택도 있다. 작업을 로컬에 유지하면 접근을 단순화할 수 있지만 배치를 제한할 수 있다. 원격에서 가져오면 조정과 전송 작업을 추가하는 대신 재사용 기회를 확대할 수 있다.

어느 접근 방식도 정의상 이기는 것은 아니다. 결정적 증거는 애플리케이션의 운영 조건에서 절약된 연산이 추가 작업을 초과하는지다.

이러한 틀은 분석을 검증된 사건에 집중시킨다. 구현 자체가 NVIDIA 전송 기술을 사용함에도 AWS와 NVIDIA 간 경쟁을 만들어내는 일을 피한다.

이 발표는 분산 추론의 정교화로 이해하는 편이 낫다. 추가 재사용 경로를 제공한 뒤, 그 경로가 언제 효과를 내는지는 운영자가 판단하도록 남긴다.

캐시 유지가 성능 방정식의 일부가 된다

재사용 기능은 다음 요청이 도착했을 때 유용한 연산이 계속 사용 가능할 때만 가치를 제공한다.

커넥터 문서에는 기본 디코드 측 보존 기간이 480초로 명시되어 있습니다. 또한 역방향 전송이 트리거되기 전 필요한 재사용 가능 토큰의 기본 임계값을 64개로 설명합니다. 이 임계값 아래에서는 시스템이 로컬에서 다시 계산합니다.

이러한 제어 항목은 헤드라인 뒤에 있는 상충 관계를 보여 줍니다. 캐시된 데이터를 유지하면 메모리를 점유합니다. 데이터를 가져오면 작업이 추가됩니다. 너무 일찍 해제하면 향후 재사용 기회를 잃게 됩니다.

올바른 선택은 캐싱을 더 많이 해야 한다는 보편적 선호가 아니라 작업의 특성에 따라 달라집니다. 곧바로 재개되는 대화는 사람이 결과를 검토하는 동안 멈춘 대화와는 다른 기회를 제공합니다.

계속 진행하기 전에 승인을 기다리는 내부 분석 에이전트를 생각해 봅시다. 다음 요청은 짧은 확인 후 도착할 수도 있고 회의 후 도착할 수도 있습니다. 모델이 적극적으로 응답하지 않는 동안에도, 두 간격 전체에 걸쳐 계산 결과를 유지하면 리소스 측면의 영향이 발생합니다.

자동화된 에이전트는 다른 패턴을 만듭니다. 도구 완료, 재시도, 애플리케이션 스케줄링이 다음 요청의 도착 시점을 결정할 수 있습니다. 따라서 운영자는 정제된 데모에서 추론하기보다 실제 턴 간 간격을 살펴봐야 합니다.

검색 임계값은 이와 유사한 문제를 제기합니다. 원격 재사용에는 오버헤드가 있으므로 계산을 피했다는 사실만으로 요청이 더 빨라졌다는 충분한 근거가 되지는 않습니다. 재사용 가능한 작업량이 검색을 정당화해야 합니다.

vLLM 양방향 KV 전송의 경우, 이는 구성 결정이 지연 시간과 메모리 압박 모두에 영향을 미칠 수 있음을 뜻합니다. 이러한 결과는 각각 따로 최적화하기보다 함께 검토해야 합니다.

응답 시작이 개선된 것을 축하하는 팀은 그 응답들 사이에 어떤 리소스가 계속 점유됐는지도 물어봐야 합니다. 유지 메모리를 줄이는 또 다른 팀은 그 결과로 얼마나 많은 반복 작업이 다시 발생했는지 물어봐야 합니다.

이는 평가를 위한 질문이지, 해당 기능이 반드시 용량에 해롭다는 증거는 아닙니다. 공개된 주장은 명시된 조건에서 지연 시간 개선 기회가 있음을 보여 줍니다. 더 폭넓은 배포 경제성은 추가 측정이 필요합니다.

세션 처리도 비슷한 주의가 필요합니다. 시스템은 계속되는 요청을 올바른 이전 계산과 연결해야 합니다. 그 연결을 끊는 애플리케이션 변경은 원래 적합했던 워크로드의 효과를 약화시킬 수 있습니다.

예를 들어 제품 팀이 대화 생성 또는 재개 방식을 재설계할 수 있습니다. 겉보기에 별개인 이 애플리케이션 변경도 새로운 성능 검증을 촉발해야 합니다. 재사용 경로는 연속성이 서빙 계층까지 전달되는 데 의존합니다.

따라서 vLLM의 프리필과 디코드 경계는 모델 서빙 전문가만의 운영 문제가 아닙니다. 애플리케이션 엔지니어와 인프라 엔지니어는 작업이 요청 전반에서 어떻게 이어지는지에 대한 공통의 이해가 필요합니다.

더 큰 교훈은 유용한 작업을 의도적으로 보존하는 데 있습니다. 캐시 보존, 요청 식별자, 전송 결정은 동일한 성능 논의에 포함되어야 합니다. 이를 서로 무관한 설정으로 다루면 그 결과로 나타나는 동작을 설명하기가 더 어려워집니다.

벤치마크는 특정 캐시 미스 시나리오를 측정한다

AWS가 보고한 가장 큰 개선 폭은 그 결과를 만들어 낸 기준선과 함께 해석해야 합니다.

AWS는 축출되었거나 대화의 캐시 블록이 없는 워커로 라우팅되는 상황을 모사하기 위해 프리필 워커의 로컬 프리픽스 캐싱을 비활성화했습니다. 비교에는 프리필 노드 하나와 디코드 노드 하나를 사용했습니다.

이는 관련성 있는 시나리오이지만, 모든 프로덕션 배포를 대표하지는 않습니다. 프리필 측에 재사용 가능한 로컬 컨텍스트가 없을 때 어떤 일이 일어나는지를 묻는 방식입니다. 해당 컨텍스트를 일관되게 유지하는 구성에 대해서도 같은 이점이 있음을 입증하지는 않습니다.

벤치마크 재현 가이드에는 중요한 구현 세부 사항이 추가되어 있습니다. 안내문은 특정 소프트웨어 버전을 고정하고, 스트리밍 응답에서 전송 메타데이터를 반환하기 위한 패치를 포함합니다. 따라서 결과를 재현하려면 테스트된 소프트웨어 경로에 주의를 기울여야 합니다.

이 세부 사항이 유용한 이유는 바로 운영과 관련되기 때문입니다. 기능 플래그만으로는 배포 환경이 실제로 원격 계산을 재사용하고 있다는 충분한 증거가 되지 않습니다. 요청 흐름은 이를 찾는 데 필요한 정보를 전달해야 합니다.

독립적인 검증은 별개의 문제로 남습니다. 재현 자료는 실험을 더 면밀히 살펴볼 수 있게 하지만, 안내문을 공개하는 것 자체가 외부 재현 결과를 제공하지는 않습니다.

결과가 벤더에서 나왔다는 이유로 이를 일축할 필요는 없습니다. 적절한 대응은 그 적용 범위를 유지하는 것입니다. AWS는 문서화된 구성에서의 이점을 보고했으며, 운영자는 여전히 자신의 트래픽에 대한 증거가 필요합니다.

“최대”라는 표현도 실제로 큰 의미를 가집니다. 이는 모든 요청에서 기대되는 결과가 아니라 관측된 유리한 결과를 가리킵니다. 더 짧은 입력, 다른 재사용 패턴, 또는 다른 배포 조건은 각각의 측정이 필요합니다.

응답 시작 지연 시간은 전체 작업 시간과 구분되어야 합니다. 첫 토큰은 더 일찍 도착할 수 있지만, 나머지 응답에는 비슷한 시간이 걸릴 수 있습니다. 도구 작업과 애플리케이션 처리는 이 개선 범위 밖에 남을 수 있습니다.

마찬가지로 기능 설정 간 유리한 비교가 인프라 지출의 비례적 감소를 입증하지는 않습니다. 그러한 결론을 내려면 지연 시간과 함께 리소스 및 용량 측정이 필요합니다.

유용한 평가는 기존 최적화를 제거하지 않고 프로덕션 기준선을 유지해야 합니다. 그다음 원격 재사용이 이러한 최적화를 넘어 어느 지점에서 가치를 더하는지 확인해야 합니다.

테스트에는 불리한 사례도 의도적으로 포함해야 합니다. 재사용 가능한 컨텍스트가 없는 요청, 재개된 대화, 일반적인 애플리케이션 중단은 개선 효과의 경계를 파악하는 데 도움이 됩니다.

이러한 사례는 벤치마크의 방해 요소가 아닙니다. 고객이 실제로 사용하는 서비스에서 벤치마크에 유리한 조건이 얼마나 자주 나타나는지를 결정합니다.

이것이 이 발표를 바라보는 올바른 회의적 관점입니다. 메커니즘은 문서화되어 있고, 보고된 결과는 구체적입니다. 아직 해결되지 않은 질문은 테스트된 구성 밖에서 그러한 기회의 빈도와 가치가 얼마나 되는가입니다.

운영자가 향후 3개월 동안 지켜봐야 할 사항

다음으로 유용한 증거는 재현 가능한 지연 시간 개선을 일반적인 애플리케이션 트래픽 및 운영 조건과 연결할 것입니다.

첫 번째 신호는 프로덕션과 유사한 기준선을 대상으로 한 독립 재현입니다. 강력한 후속 검증은 기존 로컬 캐싱 동작을 그대로 유지하면서 원격 검색이 언제 추가적인 이점을 제공하는지 보여 줄 것입니다.

그러한 증거는 vLLM 양방향 KV 전송이 기존 서빙 시스템에 실용적으로 추가될 수 있다는 근거를 강화할 것입니다. 개선 폭이 훨씬 작다면 원래의 캐시 미스 결과를 무효화하지 않으면서도 최적의 사용 사례는 더 좁혀질 것입니다.

재현은 비교가 이해 가능하도록 해야 합니다. 독자는 무엇이 동일하게 유지됐고, 무엇이 바뀌었으며, 어떤 요청이 이점을 얻었는지 알아야 합니다. 고립된 헤드라인 배수만으로는 이러한 차이를 설명할 수 없습니다.

두 번째 신호는 다양한 대화 타이밍과 부하에서의 성능입니다. 유용한 보고서에는 이어지는 세션과 재개 전 멈추는 대화가 모두 포함될 것입니다. 또한 지연 시간 동작을 유지 메모리 및 사용 가능한 서빙 용량과 연결할 것입니다.

그러한 조건에서도 응답성을 유지하는 결과는 더 광범위한 배포에 대한 신뢰를 뒷받침할 것입니다. 비정상적으로 유리한 타이밍이 필요하다는 결과는 더 선별적인 사용을 시사할 것입니다.

이는 에이전트의 작업 일정이 종종 모델 서버 외부에서 결정되기 때문에 중요합니다. 서빙 최적화는 애플리케이션이 항상 협조할 것이라고 가정하기보다 그 일정에 맞아야 합니다.

세 번째 신호는 라우팅 및 메타데이터 주변의 더 명확한 통합 증거입니다. 운영자는 원격 재사용이 실제로 발생함을 보여 주고, 발생할 수 없을 때의 동작도 이해할 수 있게 하는 재현 가능한 구성을 주시해야 합니다.

이는 기능을 활성화하는 것과 그 이점을 얻는 것 사이의 불확실성을 줄일 것입니다. 반대로 반복되는 통합 실패는 도입을 정당화하는 데 필요한 운영 노력을 늘릴 것입니다.

이러한 신호는 대안을 비교하는 더 나은 방법도 제공합니다. NVIDIA Dynamo와 기타 서빙 구성은 동일한 애플리케이션 워크로드 및 결과 지표로 평가받아야 합니다. 별도의 벤치마크 주장만으로는 어느 쪽이 우위인지 입증할 수 없습니다.

개발자에게 당장의 기회는 기본적으로 아키텍처를 바꾸는 것이 아니라 조사에 있습니다. 더 복잡한 배포를 결정하기 전에 후속 요청이 어디에서 시간을 소비하는지 파악하세요.

엔터프라이즈 구매자는 시연된 개선이 자신의 작업과 같은 형태에서도 유지되는지 물어봐야 합니다. 이후 턴, 수정, 도구 대기, 재개된 작업을 포함하세요. 짧은 초기 대화만으로는 핵심 재사용 질문에 답할 수 없습니다.

제품 팀은 응답성과 유용성의 구분을 유지해야 합니다. 응답이 여전히 정확하고 작업도 안정적으로 완료된다면 더 이른 응답 시작은 가치가 있습니다. 서빙 지표는 이러한 결과와 함께 평가되어야 합니다.

대표적인 에이전트 세션부터 시작해 시간이 어디에 쓰이는지 측정하세요. 최적화를 선택하기 전에 입력 처리, 응답 생성, 도구 대기, 애플리케이션 작업을 구분하세요. 그런 다음 원격 재사용을 현재 배포에 이미 존재하는 캐싱 동작과 비교하세요. 유용한 계산 결과가 턴 사이에 유지되고 이를 필요로 하는 워커까지 도달한다는 증거를 요구하세요. 완료된 작업의 지연 시간을 첫 토큰 지연 시간과 함께 추적하고, 동일한 워크로드에서 메모리 사용량도 살펴보세요. vLLM 양방향 KV 전송은 반복 작업을 회수할 수 있는 구체적인 방법을 제공하지만, 그 가치는 해당 작업을 얼마나 자주 회수할 수 있는지에 달려 있습니다. 공개된 벤치마크를 검증 가능한 단서로 활용한 뒤, 해당 기능을 애플리케이션이 실제로 처리하는 대화를 기준으로 판단하세요.