vLLM에서 양방향 KV 전송으로 멀티턴 에이전틱 워크로드의 TTFT 개선

멀티턴 에이전틱 워크로드는 에이전트가 추론하고, 도구를 호출하고, 이전 결과를 반영하면서 축적된 컨텍스트를 기반으로 발전합니다. 새로운 턴이 올 때마다 클라이언트는 시스템 지침, 이전 프롬프트, 도구 결과, 모델 응답을 포함한 대화 이력을 다시 전송하므로, 커징하는 컨텍스트가 반복적으로 처리됩니다. In Prefill-decode (P-D) disaggregation에서는 각 요청이 전문화된 노드들로 분할됩니다. 프리필 노드가 프롬프트를 처리하고 KV 캐시를 구축한 다음, 디코드 노드가 해당 KV 블록을 가져와 응답을 생성합니다.

그러나 기존의 분산 서빙은 KV 캐시를 한 방향으로만, 즉 프리필 노드에서 디코드 노드로만 전송합니다. 이 일방향 흐름은 멀티턴 워크로드에서 두 가지 비효율을 만듭니다. 첫째, 응답 생성 후 디코드 노드는 프롬프트와 새로 생성된 토큰 모두에 대한 KV 캐시 항목을 보유합니다. 다음 턴을 처리할 때 프리필 노드는 이 항목들을 가져올 수 없으므로, 이전 응답 토큰에 대한 KV 프로젝션을 재계산해야 합니다. 둘째, 디코드 노드는 세션 상태를 유지하는 반면 프리필 노드는 그렇지 않아, 프리필 노드에서 활성 세션의 캐시가 축출(eviction)될 확률이 높아집니다. 완전한 캐시 미스가 발생하면 프리필 노드는 시스템 지침, 이전 사용자 요청, 도구 결과, 모델 생성 응답을 포함한 전체 대화 이력에 대한 KV 프로젝션을 재계산해야 합니다. 대화가 길어질수록 이러한 중복 작업은 가속기 용량을 더 많이 소모하고 첫 토큰 생성 시간(TTFT)을 증가시킵니다.

대화형 어시스턴트와 에이전틱 애플리케이션을 구축하는 고객의 경우, 길어지는 상호작용 이력은 반복적인 프리필 계산을 통해 지연 시간을 증가시키고 가속기 용량을 소모할 수 있습니다. 이번 게시물에서는 양방향 KV 캐시 전송 이 프리필 및 디코드 노드가 턴 간에 이전에 계산된 컨텍스트를 재사용할 수 있게 하여 가속기 활용도를 높이고, 대화가 길어져도 애플리케이션이 빠른 TTFT를 유지하도록 돕는 방법을 보여줍니다.

AWS Elastic Fabric Adapter로 연결된 Amazon EC2 P5en 인스턴스를 사용한 1P1D 배포에서 수행한 우리의 멀티턴 벤치마크에서(AWS EFA, AWS에서 서버 간에 사용되는 저지연 RDMA 네트워크)로 연결된 Amazon EC2 P5en 인스턴스를 사용한 1P1D 배포의 멀티턴 벤치마크에서, 양방향 KV 전송은 Qwen3-32B의 TTFT를 최대 1.6배, zai-org/GLM-5-FP8의 TTFT를 최대 3.3배 개선했습니다(자세한 내용은 성능 데이터 섹션 참조). 결과는 워크로드와 구성에 따라 달라집니다.

당사는 처음에 EFA로 연결된 AWS Trainium 인스턴스 클러스터에서 이 기능을 구축하고 검증했으며, 가속기에 구애받지 않는(accelerator-agnostic) 기능으로 vLLM에 기여했습니다. 여기에 제시된 결과는 EFA가 적용된 Amazon EC2 P5en GPU 클러스터에서 얻은 것으로, 이점이 GPU에도 동일하게 적용됨을 보여줍니다. 이 게시물에서는 양방향 전송 아키텍처, 라우터 메타데이터 흐름, KV 블록 보존 및 재계산 제어, 성능 결과, 벤치마크 재현 방법을 설명합니다.

양방향 KV 전송

양방향 KV 전송은 대화의 후속 턴에서 디코드 노드가 이전에 계산한 KV를 프리필 노드에 반환하여, 프리필 노드에서 공유 컨텍스트의 재계산을 피할 수 있게 하는 메커니즘으로, 구성 가능한 KV 재계산 임계값으로 제어됩니다. 이는 앞서 설명한 두 가지 계산 중복 시나리오를 모두 완화하며, 이를 실현하려면 KV가 이를 생성한 턴 이후에도 유지되고 KV 캐시 인식 라우터에 의해 조정되어 역방향으로 전송되어야 합니다.

양방향 전송을 위한 NIXL KV 커넥터 개선 사항

당사는 프리필 노드가 원격 KV 블록을 소비할 수 있도록 NVIDIA Inference Xfer Library(NIXL) KV 커넥터 를 확장했습니다. 이는 디코드 노드가 프리필 노드가 제공하는 KV 블록을 소비하는 방식과 유사합니다. 이는 사소한 변경이 아닙니다. 두 노드 유형은 아키텍처적으로 다르기 때문입니다. 프리필 노드는 새 프롬프트 토큰에 대한 KV 표현을 계산하며 완전한 프롬프트 KV 블록을 제공할 수 있습니다. 디코드 노드는 완전한 KV 표현을 생성할 능력(또는 효율성)이 없으며, 이전에 캐시된 KV 블록만 제공할 수 있습니다. 결과적으로 프리필 노드와 디코드 노드는 원격 및 로컬 KV 블록의 메타데이터를 계산하기 위한 각자의 역할과 로직을 여전히 유지합니다. 그러나 실제 KV 전송 메커니즘(NIXL READ)은 P->D 및 D->P 양방향 모두에 공통입니다.

다음 다이어그램은 먼저 파란색으로 기존 흐름을 보여줍니다. 라우터가 요청을 프리필 노드로 보내고, 프리필 노드가 프롬프트 KV를 계산하여 블록 메타데이터를 반환하며, 라우터가 요청과 메타데이터를 디코드 노드로 전달하여 표준 P→D NIXL READ를 수행합니다. 번호가 매겨진 빨간색 경로는 양방향 KV 전송 추가 사항을 보여줍니다. (1) 디코드 노드가 생성 후 적격 KV 블록을 보존하고, (2) 스트리밍 응답에 해당 메타데이터를 반환하며, (3) 라우터가 다음 프리필 요청을 위해 해당 메타데이터를 캐시합니다. 그런 다음 프리필 노드는 (4) 로컬 캐시 매치를 적용한 후 원격으로 재사용 가능한 KV를 확인하고, (5) 재사용 가능한 토큰 수가 임계값을 충족하면 비동기 수신을 큐에 넣으며, (6) 나머지 접미사(suffix)를 계산하기 전에 D→P NIXL READ를 수행합니다.

KV 캐시 인식 라우터

vLLM은 커넥터 측의 양방향 KV 전송 지원을 포함하며, 대화 턴 간 KV 재사용을 조정하려면 KV 캐시 인식 라우터가 필요합니다. vLLM GitHub은 다음을 제공합니다. 예시 프록시 이 게시물에서 사용된 흐름을 구현한 것으로, 사용자 환경에 맞게 조정할 수 있습니다.

KV-cache 인식 라우터는 클라이언트, 프리필(prefill), 디코드(decode) 노드 사이에 위치한 경량의 상태 저장(stateful) 컨트롤 플레인 구성 요소입니다. 이 라우터는 클라이언트가 제공한 정보로부터의 인메모리 매핑을 유지합니다. conversation_id decode의 kv_transfer_params. 라우터는 KV 텐서가 아닌 블록 위치 메타데이터만 저장하며, 해당 메타데이터를 디코드 노드에 별도로 쿼리하는 것이 아니라 응답 스트림에서 가져옵니다.

다음 다이어그램은 라우터가 대화 턴 전반에서 KV 메타데이터를 어떻게 관리하는지 보여줍니다. 첫 번째 턴에서는 캐시 조회가 실패하고 요청이 표준 P→D 흐름을 따릅니다. 이후 라우터는 응답 스트림에서 디코드의 메타데이터를 저장합니다. 이후 턴에서는 라우터가 그 메타데이터를 다음을 사용하여 검색합니다. conversation_id, 프리필(prefill)이 디코드(decode)의 KV를 재사용할 수 있도록 하고, 생성이 끝난 후 다음 턴을 위해 메타데이터를 갱신합니다.

블록 보존 TTL

일반적으로 디코드 인스턴스는 생성이 끝나는 즉시 요청의 블록을 해제합니다. 양방향 모드에서는 구성 가능한 수명(decoder_kv_blocks_ttl, 기본값 480초) 동안 블록을 보유하고 그 위치와 만료 시점을 게시하여, 프롬프트 접두사와 생성된 응답 모두를 포함하는 대화의 KV가 다음 턴에 사용 가능한 상태로 유지됩니다. TTL이 만료되기 전에 도착한 턴은 프리필 노드가 KV를 재사용하고, 그보다 늦게 도착한 턴은 일반 프리필로 폴백합니다. 이 TTL은 갱신되지 않는 고정값이므로, KV 재사용과 가속기 메모리 사용량 간의 균형을 맞추기 위해 턴 사이의 예상 시간에 맞춰 조정하십시오. 자연스러운 다음 개선 방향은 하트비트로 갱신되는 임대(lease)를 디코드 측에도 확장하여, 고정 타이머 종료 시점이 아니라 대화가 유휴 상태가 되는 즉시 디코드 인스턴스가 블록을 회수하도록 하는 것입니다.

KV 재계산 임계값

KV 재사용이 항상 로컬 재계산보다 빠른 것은 아닙니다. 짧은 재사용 가능 접두사의 경우 상호연결 및 조정 오버헤드가 토큰을 재계산하는 데 필요한 시간을 초과할 수 있습니다. kv_recompute_threshold 설정(기본값 64 토큰)이 이 결정을 제어합니다. 프리필 노드는 계산할 토큰 수가 임계값 미만일 때 재계산하고, 임계값 이상일 때 디코드 노드에서 KV를 가져옵니다. 배포 환경은 모델 계산 시간, KV 크기, 상호연결 성능에 따라 이 값을 조정할 수 있습니다.

성능 데이터

평가를 위해 EFA로 연결된 Amazon EC2 P5en 인스턴스를 사용한 1P1D 배포에서 Qwen3-32B 및 GLM-5-FP8 모델을 사용했습니다. 프리필 노드가 로컬 캐시를 제거했거나 라우터가 해당 대화의 KV 블록이 없는 다른 프리필 노드를 선택하는 시나리오를 에뮬레이션하기 위해, 다음과 같이 프리필 노드에서 접두사 캐싱을 비활성화했습니다: --no-enable-prefix-caching.

두 모델 모두에서 양방향 KV 전송을 켜면 멀티 턴 대화에서 프리필 계산이 줄어들며, 그 이점은 일반적으로 프롬프트 길이가 길어질수록 커집니다. 이 기능이 OFF일 때 프리필 인스턴스는 매 턴마다 증가한 전체 컨텍스트를 재계산하므로 TTFT가 가파르게 상승합니다: Qwen3-32B는 2k에서 158 ms에서 24k에서 778 ms로, GLM-5-FP8은 2k에서 500 ms에서 20k에서 2,334 ms로 상승합니다. 기능이 ON이면 디코드 인스턴스가 보유한 KV가 재계산 대신 재사용되어 TTFT가 훨씬 완만하게 유지됩니다: Qwen3-32B는 동일한 범위에서 122 ms에서 460 ms로만 상승하고(가장 긴 프롬프트에서 약 1.6배 감소), GLM-5-FP8은 358 ms에서 702 ms로 상승하며 긴 프롬프트에서 재계산 경로보다 최대 3.3배 낮게 실행됩니다. 프리필 소요 시간 분석이 그 이유를 설명해 줍니다.

양방향 전송은 약간의 KV 전송 시간을 추가하지만(Qwen3-32B의 경우 약 30ms에서 130ms, GLM-5-FP8의 경우 약 29ms에서 110ms), 이를 통해 제거되는 프리필 연산량이 그 KV 전송 시간을 훨씬 상회합니다. 그 결과, 전송을 켠 상태의 총 프리필 시간(Qwen3-32B: 128ms에서 414ms, GLM-5-FP8: 316ms에서 541ms)은 재계산만 사용하는 경로(Qwen3-32B: 153ms에서 744ms, GLM-5-FP8: 500ms에서 2,331ms)보다 훨씬 낮게 유지됩니다. 더 큰 GLM-5-FP8 모델은 절대적 및 상대적 격차가 더 크게 나타나는데, 토큰당 재계산 시간이 더 높기 때문에 모델과 컨텍스트가 커질수록 KV 재사용의 이점이 더욱 커집니다.

Qwen3-32B

아래 차트는 Qwen3-32B에 대해 TTFT를 프롬프트 길이에 따라 나타낸 것으로, 양방향 KV 전송 ON과 OFF를 비교합니다.

다음 차트는 동일한 실행에 대한 프리필(prefill) 소요 시간을 재계산(recompute)과 KV 전달 구성 요소로 나누어 보여줍니다.

두 차트를 함께 보면 기능을 켠 경우 TTFT는 거의 평평하게 유지되는 반면, 기능을 끈 경로는 컨텍스트가 커짐에 따라 가파르게 상승하는데, 이는 작은 KV 전송 시간이 해당 방식으로 제거되는 재계산(recompute) 비용에 비해 크게 무의미하기 때문입니다.

zai-org/GLM-5-FP8

동일한 두 가지 관점이 GLM-5-FP8에도 적용됩니다. 첫 번째 그래프는 기능을 ON으로 했을 때와 OFF로 했을 때의 TTFT를 프롬프트 길이에 따라 보여줍니다.

두 번째는 프리필(prefill) 시간을 재계산(recompute) 구성 요소와 KV-전송 구성 요소로 분해합니다.

GLM-5-FP8은 Qwen3-32B보다 훨씬 큰 격차를 보이며, 긴 프롬프트에서 TTFT가 최대 약 3.3배 낮아집니다. 이는 토큰당 재계산 시간이 더 높기 때문에 컨텍스트 길이가 길어질수록 KV 재사용의 이점이 더욱 커지기 때문입니다.

벤치마크 실행 방법

1개의 프리필(prefill) 노드와 1개의 디코드(decode) 노드로 구성된 저희의 1P1D 벤치마크 구성을 재현하려면, EFA가 지원되는 Amazon EC2 P5en 인스턴스를 사용하여 다음 문서의 단계별 지침을 따르십시오. 우리의 결과 재현하기 아래 가이드를 참조하세요. 이 가이드는 환경 설정, vLLM prefill 및 decode 서버 실행, 벤치마크 실행, 결과 수집 방법을 다룹니다. 이 기능은 다른 지원되는 구성에서도 실행할 수 있지만, 성능 결과는 하드웨어, 모델, 워크로드 및 네트워크 구성에 따라 달라집니다.

결론

이 게시물에서는 에이전트의 대화 기록이 길어질 때 양방향 KV 캐시 전송이 TTFT를 어떻게 줄일 수 있는지 보여드렸습니다. P-D 분리 배포 환경에서는 이 기능을 통해 prefill 노드가 여러 턴에 걸쳐 decode 노드가 보유한 KV 블록을 재사용할 수 있어 반복 계산이 줄어듭니다. 구성 가능한 블록 보존 및 재계산 임계값이 재사용이 발생하는 시점을 결정합니다. EFA로 연결된 Amazon EC2 P5en 인스턴스를 사용하는 1P1D 배포에서 테스트한 가장 긴 프롬프트 길이에서 Qwen3-32B의 경우 1.6배, zai-org/GLM-5-FP8의 경우 3.3배의 TTFT 감소를 확인했으며, 결과는 워크로드와 배포 구성에 따라 달라집니다. 사용자 환경에서 이를 구현하려면 vLLM v0.21.0 이상을 다음과 함께 사용하십시오. NixlConnector, 활성화 bidirectional_kv_xfer 프리필(prefill) 서버와 디코드(decode) 서버 모두에 대해 KV 캐시 인식 라우터를 사용하고, 다음을 따르십시오: 재현 가이드.

관련 자료

• AWS EFA
• Prefill-Decode (P-D) 분리 서빙
• 멀티턴 대화를 활용한 벤치마크 KV 캐시 오프로딩

감사의 말

이 기능 유지에 도움을 주신 Nicolò Lucchesi(Mistral), Mark McLoughlin(Red Hat), 그리고 vLLM 커뮤니티께 감사드립니다.

부록: 결과 재현하기

토폴로지는 두 대의 AWS p5en 인스턴스로 구성되며(prefill은 첫 번째 인스턴스에서 :8100, 디코드는 :8200EFA가 활성화된 )과, 프록시와 벤치마크 클라이언트를 실행하는 세 번째 소형 노드로 구성됩니다. :8000.

이 글에는 세 개의 스크립트가 포함되어 있습니다: serve_pd_multiturn.sh 기능을 켜거나 끈 상태로 각 레그를 실행하고, run_multiturn_sweep.sh 프롬프트 길이 스윕을 수행하며, cleanup.sh 배포를 정리합니다.

테스트 환경

두 GPU 노드는 동일하게 구성되었습니다:

NIXL에 의한 EFA 디바이스 선택. LIBFABRIC 백엔드는 16개의 모든 EFA 장치를 다음과 같은 레일로 엽니다. efa 프로바이더와 함께 16개의 EFA 디바이스를 모두 레일로 엽니다. 그런 다음 각 GPU의 KV 캐시를 해당 GPU의 PCIe 스위치를 공유하는 2개의 레일에만 등록하여 모든 전송이 PCIe 로컬로 유지되도록 합니다. NIXL 또는 libfabric 디바이스 오버라이드는 설정되지 않았으며, 이것이 기본 선택입니다. 자신의 노드에서 이를 확인하려면 NIXL_LOG_LEVEL=DEBUG 옵션으로 서버를 시작하고 등록 라인을 확인하십시오:

grep -E "Created rail [0-9]+ \(device=|mapped to rail" server.log

1. 노드 프로비저닝

두 GPU 노드에 EFA 사용자 영역 스택을 설치하고 프로바이더가 있는지 확인합니다. 우리는 인스톨러 1.50.0:

curl -O https://efa-installer.amazonaws.com/aws-efa-installer-1.50.0.tar.gz
tar -xf aws-efa-installer-1.50.0.tar.gz && cd aws-efa-installer
sudo ./efa_installer.sh -y
fi_info --version         # libfabric 2.6.0amzn1.0
fi_info -p efa -t FI_EP_RDM            # verify the EFA provider is present on both GPU nodes

2. 두 GPU 노드에 vLLM 및 NIXL 설치

python3 -m venv ~/venv-pd && source ~/venv-pd/bin/activate
pip install --upgrade pip && pip install vllm==0.29.0 nixl==1.4.1

vLLM PR #40186 을 두 노드 모두에 한 번 적용합니다. 이 PR은 kv_transfer_params 에 스트리밍 응답을 연결하며, 이것이 멀티턴 프록시가 턴을 연결하는 데 필요한 기능입니다: 프록시는 항상 디코드 노드에 stream=True, 그래서 이 패치가 없으면 디코드 노드가 블록 메타데이터를 절대 반환하지 않으며 모든 턴이 캐시 미스로 기록됩니다.

SITE=$(python -c 'import site; print(site.getsitepackages()[0])')
curl -sL https://github.com/vllm-project/vllm/pull/40186.diff -o /tmp/40186.diff
patch -p1 -d "$SITE" --fuzz=3 < /tmp/40186.diff

3. 모델 다운로드

export HF_HOME=/fsx/huggingface        # a large shared volume
hf download Qwen/Qwen3-32B

4. P/D 쌍 실행

실행 serve_pd_multiturn.sh GPU 노드당 한 번. BIDIR A/B의 두 다리 사이에서 변경되는 유일한 부분이며, 양쪽 노드에서 일치해야 합니다:

# on the prefill node
P_IP=<P_IP> D_IP=<D_IP> ROLE=prefill BIDIR=false ./serve_pd_multiturn.sh
# on the decode node
P_IP=<P_IP> D_IP=<D_IP> ROLE=decode  BIDIR=false ./serve_pd_multiturn.sh

이는 프리필(prefill) 측에서는 다음과 같이 확장됩니다:

export FI_PROVIDER=efa
export VLLM_NIXL_SIDE_CHANNEL_HOST=<P_IP> VLLM_NIXL_SIDE_CHANNEL_PORT=5600
vllm serve Qwen/Qwen3-32B --served-model-name Qwen --dtype bfloat16 \
  --tensor-parallel-size 8 --max-model-len 32768 --max-num-seqs 8 \
  --no-enable-prefix-caching --port 8100 \
  --kv-transfer-config '{"kv_connector":"NixlConnector","kv_buffer_device":"cuda",
    "kv_role":"kv_producer","engine_id":"prefill-engine-001","kv_rank":0,
    "kv_parallel_size":2,"kv_connector_extra_config":{"backends":["LIBFABRIC"],
    "kv_recompute_threshold":64,"decoder_kv_blocks_ttl":480,
    "bidirectional_kv_xfer":false}}'

--no-enable-prefix-caching prefill 노드에만 설정됩니다. 이것이 바로 벤치마크가 에뮬레이션하는 캐시 축(eviction) 시나리오입니다. decode 노드에서는 prefix caching을 활성화된 상태로 두십시오. 양쪽 모두가 될 때까지 기다리십시오 /health 엔드포인트가 200을 반환하도록 합니다.

5. 멀티턴 프록시 시작

python3 -m venv ~/venv-proxy && source ~/venv-proxy/bin/activate
pip install fastapi uvicorn httpx pandas numpy aiohttp transformers tqdm
sudo dnf install -y jq || sudo apt-get install -y jq
git clone --depth 1 --branch v0.29.0 https://github.com/vllm-project/vllm.git ~/vllm_src
export VLLM_SRC=~/vllm_src
 
python3 $VLLM_SRC/examples/disaggregated/disaggregated_serving/disagg_proxy_multiturn.py \
  --port 8000 --prefiller-host <P_IP> --prefiller-ports 8100 \
  --decoder-hosts <D_IP> --decoder-ports 8200 \
  2>&1 | tee ~/proxy_$(date +%Y%m%d_%H%M%S).log

프록시는 URL이 아니라 호스트와 포트를 받습니다. 재사용은 클라이언트가 전송하는 것에 따라 결정됩니다 conversation_id, 따라서 여기에서 이를 활성화할 플래그는 없습니다.

6. OFF 구간을 달린 후 ON 구간을 달립니다

VLLM_SRC=~/vllm_src LEG=off ./run_multiturn_sweep.sh

ON 다리(leg)의 경우, 두 서버와 프록시를 모두 중지하고 다음과 같이 4단계를 다시 시작하십시오. BIDIR=true 각 노드에서 프록시를 재시작하고(대화 캐시는 프로세스 내에 있음), 그다음 다음을 수행합니다:

VLLM_SRC=~/vllm_src LEG=on ./run_multiturn_sweep.sh

GLM-5-FP8에 대해 두 다리를 모두 반복합니다, 이어서 MODEL=zai-org/GLM-5-FP8 SERVED_NAME=GLM.

7. 숫자 모으기

소스당 하나씩, 세 개의 수량:

• TTFT, 벤치마크가 작성한 요청별 통계 JSON에서 --stats-json-output. 각 레코드에는 다음이 포함됩니다 ttft_ms 함께 input_num_tokens 그리고 conversation_id. 이것은 TTFT 차트의 y축입니다.
• 프리필 소요 시간, 프록시 로그에서, 각 요청의 프리필 구간을 다음과 같이 보고하는 로그로부터 확인할 수 있다 Prefill done in <N>ms. 이는 prefill-duration 분해에서 각 막대의 총 높이입니다.
• KV 전송 시간 및 용량, 프리필(prefill) 노드의 로그에서 가져온 것으로, 이 로그에는 KV Transfer metrics: 평균 및 P90 전송 시간, 전송당 바이트 수, 처리량이 보고됩니다. 이것이 각 ON 막대의 KV-xfer 구성 요소입니다.

NIXL 텔레메트리는 전송을 시작하는 측에서 기록되므로, D->P 읽기백은 프리필 노드의 로그에 나타나고 일반적인 P->D 풀은 디코드 노드의 로그에 나타납니다.

프롬프트 길이별로 각 수치를 평균 낸 뒤 시각화하세요: TTFT를 프롬프트 길이에 대한 두 개의 선(ON과 OFF)으로 표시하고, 프리필(prefill) 소요 시간은 프롬프트 길이별로 짝지어진 누적 막대로 표시하되 ON 막대를 프리필 연산과 KV 전송으로 나눕니다. 두 관점의 차이가 핵심입니다 — 막대가 드러내는 전송 비용이야말로 TTFT 선이 절감 효과로 변환해 보여주는 것입니다.

문제 해결

• 프록시는 항상 로그를 기록합니다 cache MISS ON 러닝 세션 중에 — 누락됨 --send-conversation-id, 양쪽 노드 모두에 PR #40186이 적용되지 않았거나 BIDIR=false 디코드 노드에 남는 경우, 이때는 아무것도 반환하지 않습니다 kv_transfer_params 전혀 그렇지 않습니다.
• Declining expired remote read 프리필 노드에서 — 다음 턴이 도착하기 전에 디코드 노드의 블록들이 만료되었다. Raise decoder_kv_blocks_ttl (기본값 480초)를 설정하고 프록시의 캐시 TTL을 그보다 낮게 유지하십시오.
• fi_info -p efa 비어 있거나 소켓으로 대체됩니다 — EFA 공급자가 없습니다. 다시 설치하십시오 aws-efa-installer 그리고 인스턴스가 EFA 활성화된 인터페이스로 시작되었는지 확인하세요. 그렇지 않으면 NIXL이 초기화에 실패하거나 조용히 TCP로 동작하여 전송 수치가 무의미해집니다.

정리

./cleanup.sh proxy      # on the proxy / benchmark driver node
./cleanup.sh server     # on each GPU node

그런 다음 인스턴스를 종료하고 실행 중인 인스턴스가 더 이상 없는지 확인하십시오.