VAST Data 통합 가이드¶
Continuum Router는 VAST Data 스토리지와 세 가지 지점에서 통합됩니다: 응답 캐시 L2 티어, 스토리지 오프로드 텐서 추적을 위한 KV 캐시 인덱스, 그리고 분리형 prefill/decode 서빙의 KV 텐서 전송 레이어입니다. 이 가이드에서는 각 통합 지점을 실용적인 배포 예시와 전체 프로덕션 설정과 함께 설명합니다.
목차¶
- VAST Data 연결 방법
- 사전 요구사항
- 예시: VAST 응답 캐시 (S3 API)
- 예시: KV 텐서 오프로딩 (vLLM + VAST)
- 예시: VAST를 활용한 분리형 Prefill/Decode
- 예시: 전체 프로덕션 설정
- 성능 벤치마크
VAST Data 연결 방법¶
VAST Data는 여러 액세스 프로토콜을 제공합니다. Continuum Router는 응답 캐시 스토리지에는 S3 호환 API를, 분리형 서빙의 KV 텐서 전송에는 HTTP 엔드포인트를 사용합니다.
| 프로토콜 | Continuum Router 사용 용도 | VAST Data 기능 | 일반적인 대역폭 | 비고 |
|---|---|---|---|---|
| S3 API (HTTP/HTTPS) | 응답 캐시 L2 티어 | VAST S3 게이트웨이 | 10–100 Gbps | 표준 AWS S3 SDK 호환; 캐시된 응답 블롭에 사용 |
| HTTP 엔드포인트 | KV 텐서 전송 (분리형 서빙) | VAST Element Store | 10–100 Gbps | disaggregated_serving.default_external_storage.endpoint에 사용 |
| NFS | 라우터에서 직접 미사용 | VAST Universal Storage | 10–40 Gbps | vLLM이 모델 가중치에 직접 사용 가능 |
| NVMe-oF / RDMA | 라우터에서 직접 미사용 | VAST NVMe-over-Fabric | 100–400 Gbps | 초저지연 텐서 액세스를 위해 vLLM 백엔드에서 사용 가능 |
라우터 레벨 통합을 위해 VAST Data에서 두 가지가 필요합니다:
- 버킷과 자격 증명이 있는 S3 호환 엔드포인트 (응답 캐시용)
- KV 텐서 전송을 위한 HTTP 엔드포인트 (분리형 서빙용)
이 두 가지는 다른 포트나 경로를 사용하여 동일한 VAST 클러스터를 가리킬 수 있습니다.
사전 요구사항¶
VAST Data 클러스터 요구사항¶
- VAST Data 소프트웨어 버전 4.0 이상
- 응답 캐시 통합을 위한 S3 게이트웨이 활성화
- 워크로드에 맞는 충분한 용량:
- 응답 캐시: 고유 요청당 2–20 KB 추정; 수백만 항목 계획
- KV 텐서: 캐시된 prefix당
2 × num_layers × num_heads × head_dim × seq_len × 2 바이트추정
자격 증명 및 액세스¶
- 대상 버킷에 대한 읽기/쓰기 권한이 있는 S3 액세스 키와 시크릿 키
- 사전에 생성된 버킷 (라우터는 버킷을 자동으로 생성하지 않음)
- 각 라우터 인스턴스에서 VAST 클러스터로의 네트워크 경로
네트워크 요구사항¶
- 라우터 호스트와 VAST 클러스터 간 L3 연결 (대용량 텐서 전송에는 점보 프레임 권장)
- 다음 트래픽을 허용하는 방화벽 규칙:
- VAST S3 게이트웨이로의 TCP 포트 443 또는 80 (응답 캐시)
- VAST HTTP 엔드포인트로의 TCP 포트 8080 또는 설정된 포트 (분리형 서빙)
- NVMe-oF/RDMA의 경우: 전용 RDMA NIC 및 패브릭 (라우터 레벨 통합에는 불필요)
환경 변수¶
민감한 자격 증명은 설정 파일 대신 환경 변수에 저장하세요:
라우터는 시작 시 설정 값의 ${ENV_VAR} 참조를 확장합니다.
예시: VAST 응답 캐시 (S3 API)¶
이 설정은 Redis를 핫 L1 캐시로, VAST Data S3를 내구성 있는 L2 캐시로 사용합니다. L1을 놓친 응답은 백엔드에 도달하기 전에 VAST에서 확인됩니다. L2 적중은 이후 빠른 액세스를 위해 L1으로 승격됩니다.
동작 방식¶
- 클라이언트가 결정론적 요청(temperature = 0)을 전송
- 라우터가 요청 매개변수로부터 캐시 키 계산
- L1(Redis) 확인 — 적중 시 즉시 응답 반환
- L1 미스 시 L2(VAST S3) 확인 — 적중 시 응답을 반환하고 L1으로 승격
- 두 곳 모두 미스 시 백엔드 호출 후 L1과 L2 모두에 응답 저장
설정¶
response_cache:
enabled: true
# "tiered"로 L1 + L2 아키텍처 활성화
backend: tiered
# 모든 캐시 항목의 전역 TTL
ttl: "24h"
# 캐시 대상 최대 응답 본문 크기
max_response_size: 1048576 # 1 MiB
max_stream_buffer_size: 10485760 # 10 MiB
# L1: Redis (핫 캐시 — 빠른 조회, 제한된 용량)
l1:
type: memory # 분산 L1에는 "redis" 사용
max_value_size: 1048576 # 1 MiB 초과 값은 L2로 직접 저장
# l1.type이 "redis"일 때 L1에 사용되는 Redis 설정
redis:
url: "redis://redis-service:6379"
pool_size: 16
key_prefix: "cr:resp:"
fallback_to_memory: true
# L2: VAST Data S3 (웜 캐시 — 고용량, 내구성)
l2:
type: s3
endpoint: "https://vast-s3.example.com"
bucket: "llm-response-cache"
key_prefix: "response-cache/"
region: "us-east-1"
access_key: "${S3_ACCESS_KEY}"
secret_key: "${S3_SECRET_KEY}"
# 선택 사항: L2 항목에 대한 TTL 재정의 (기본값: 전역 ttl 상속)
ttl_override: "7d"
# 계층형 캐시 승격 동작
tiered:
promote_on_hit: true # L2 적중을 L1으로 승격
l1_promotion_ttl: "30m" # 승격된 L1 항목의 TTL
필드 참조¶
| 필드 | 설명 |
|---|---|
l2.type |
VAST Data S3 백엔드의 경우 "s3" 필수 |
l2.endpoint |
VAST S3 게이트웨이 URL (HTTP 또는 HTTPS) |
l2.bucket |
사전에 생성된 S3 버킷 이름 |
l2.key_prefix |
버킷 내 키 prefix (기본값: "response-cache/") |
l2.region |
AWS 호환 리전 문자열 (기본값: "us-east-1") |
l2.access_key |
S3 액세스 키; ${ENV_VAR} 확장 지원 |
l2.secret_key |
S3 시크릿 키; ${ENV_VAR} 확장 지원; 로그에서 마스킹 |
l2.ttl_override |
L2 항목의 선택적 TTL 재정의 (예: "7d", "24h") |
tiered.promote_on_hit |
L2 적중을 L1에 복사할지 여부 (기본값: true) |
tiered.l1_promotion_ttl |
승격으로 생성된 L1 항목에 적용되는 TTL (기본값: "5m") |
예시: KV 텐서 오프로딩 (vLLM + VAST)¶
이 설정은 스토리지 오프로딩 인식이 있는 KV 캐시 인덱스를 활성화합니다. vLLM이 GPU KV 텐서를 VAST로 오프로드하면, 라우터는 해당 텐서를 StorageWarm 티어로 추적하고 GPU 상주(GpuHot) 데이터보다 낮은 점수 가중치를 적용합니다.
동작 방식¶
- vLLM이 프롬프트에 대한 KV 텐서를 계산하고
cache_created이벤트 보고 (티어:GpuHot) - GPU 메모리 압박 하에 vLLM이 텐서를 VAST로 오프로드하고
cache_offloaded보고 - KV 인덱스가 해당 항목을
StorageWarm으로 다운그레이드 - 라우터가 매칭 prefix를 가진 새 요청을
StorageWarm데이터를 보유한 백엔드로 라우팅 (overlap 점수 감소) - vLLM이 VAST에서 텐서를 다시 로드하고
cache_reloaded보고. 인덱스가GpuHot으로 업그레이드
Continuum Router 설정¶
kv_cache_index:
enabled: true
backend: memory # 멀티 인스턴스 배포에는 "redis" 사용
# 고유 프롬프트 수 × 백엔드 수에 맞게 max_entries 조정
max_entries: 500000
# 항목은 15분 후 만료; vLLM 축출 속도에 따라 조정
entry_ttl_seconds: 900
scoring:
overlap_weight: 0.6
load_weight: 0.3
health_weight: 0.1
# 백엔드가 ≥30% 커버리지를 보유할 때만 KV 인식 라우팅 활성화
min_overlap_threshold: 0.30
# GPU 상주 데이터는 전체 overlap 점수 부여
gpu_tier_weight: 1.0
# 스토리지 오프로드 데이터는 가치 있지만 재로드 지연 발생 — 할인 적용
storage_tier_weight: 0.6
# GPU 핫 vs. VAST 웜 티어 추적
storage_offloading:
enabled: true
# vLLM이 cache_created/cache_evicted만 내보낼 때 (cache_offloaded 없음),
# 축출을 영구 제거가 아닌 VAST 오프로드로 처리
treat_eviction_as_offload: true
# 각 vLLM 백엔드에서 KV 이벤트 구독
event_sources:
- backend_name: vllm-1
endpoint: "http://vllm-1:8000/v1/kv_events"
reconnect_interval_ms: 5000
- backend_name: vllm-2
endpoint: "http://vllm-2:8000/v1/kv_events"
reconnect_interval_ms: 5000
vLLM 실행 명령어¶
vLLM은 KV 이벤트를 내보내고 텐서 오프로딩에 VAST Data를 사용하도록 구성해야 합니다:
vllm serve meta-llama/Llama-3.1-70B-Instruct \
--host 0.0.0.0 \
--port 8000 \
--enable-prefix-caching \
--kv-cache-dtype auto \
--max-model-len 32768 \
--kv-transfer-config '{"kv_connector":"VastKVConnector","kv_buffer_device":"cpu","kv_buffer_size":4e9,"kv_role":"kv_both","kv_connector_extra_config":{"vast_endpoint":"http://vast-cluster:8080","kv_namespace":"inference/kv-cache"}}'
주요 플래그:
--enable-prefix-caching: 백엔드에서 KV prefix 캐싱 활성화--kv-cache-dtype auto: 캐시 스토리지에 모델의 기본 dtype 사용--kv-transfer-config: 오프로딩을 위한 VAST KV 커넥터 설정
--enable-prefix-caching이 활성화되면 KV 이벤트 SSE 스트림이 http://<vllm-host>:<port>/v1/kv_events에서 제공됩니다.
VAST 오프로딩 시 스코어링 동작¶
| 시나리오 | 티어 | 점수 배율 | 효과 |
|---|---|---|---|
| GPU VRAM에 텐서 존재 | GpuHot |
1.0 (전체 점수) | 최고 라우팅 우선순위 |
| VAST로 텐서 오프로드됨 | StorageWarm |
0.6 (할인됨) | 중간 라우팅 우선순위; 적중 시 vLLM이 재로드 |
| 텐서 캐시 없음 | — | 0.0 | 설정된 선택 전략으로 폴백 |
예시: VAST를 활용한 분리형 Prefill/Decode¶
이 설정은 prefill(프롬프트 처리)과 decode(토큰 생성)를 분리합니다. VAST Data는 KV 텐서 전송 레이어입니다: prefill 워커가 VAST에 텐서를 쓰고, decode 워커가 읽습니다. 라우터가 2단계 흐름을 조율합니다.
동작 방식¶
- 라우터가 요청의 prefix hash에 대해 KV 인덱스 확인
- decode 워커가 GPU 상주 텐서(
GpuHot)를 보유한 경우: 해당 워커로 직접 라우팅 (빠른 decode) - VAST에 텐서가 있는 경우(
StorageWarm): 최소 부하 decode 워커로 라우팅 (VAST에서 로드) - 캐시 없는 경우: prefill 워커 선택, prefill 단계 실행, VAST에 텐서 저장, 토큰 생성을 위해 decode 워커로 라우팅
설정¶
disaggregated_serving:
enabled: true
# prefill 연산 단계 타임아웃
prefill_timeout: "60s"
# VAST와 워커 간 KV 텐서 전송 타임아웃
kv_transfer_timeout: "15s"
# 분리형 백엔드 사용 불가 시 통합형 백엔드로 폴백
fallback_to_unified: true
# 자체 external_storage를 지정하지 않은 백엔드의 기본 외부 스토리지
default_external_storage:
endpoint: "http://vast-cluster:8080"
kv_namespace: "inference/kv-cache"
# VAST가 익명 접근으로 설정된 경우 자격 증명 선택 사항
# credentials: "${VAST_CREDENTIALS}"
backends:
# Prefill 워커 — 입력 프롬프트의 KV 텐서 계산
- name: prefill-worker-1
url: "http://vllm-prefill-1:8000"
role: prefill
external_storage:
endpoint: "http://vast-cluster:8080"
kv_namespace: "inference/kv-cache"
- name: prefill-worker-2
url: "http://vllm-prefill-2:8000"
role: prefill
# external_storage 생략 시 default_external_storage 상속
# Decode 워커 — 캐시된 KV 데이터로 토큰 생성
- name: decode-worker-1
url: "http://vllm-decode-1:8000"
role: decode
weight: 2
- name: decode-worker-2
url: "http://vllm-decode-2:8000"
role: decode
weight: 2
- name: decode-worker-3
url: "http://vllm-decode-3:8000"
role: decode
weight: 2
# 통합형 폴백 — 분리형 풀 사용 불가 시 두 단계 모두 처리
- name: unified-fallback
url: "http://vllm-unified:8000"
role: unified
vLLM 워커 실행 명령어¶
Prefill 워커:
vllm serve meta-llama/Llama-3.1-70B-Instruct \
--host 0.0.0.0 \
--port 8000 \
--enable-prefix-caching \
--kv-cache-dtype auto \
--kv-transfer-config '{"kv_connector":"VastKVConnector","kv_role":"kv_producer","kv_connector_extra_config":{"vast_endpoint":"http://vast-cluster:8080","kv_namespace":"inference/kv-cache"}}'
Decode 워커:
vllm serve meta-llama/Llama-3.1-70B-Instruct \
--host 0.0.0.0 \
--port 8000 \
--enable-prefix-caching \
--kv-cache-dtype auto \
--kv-transfer-config '{"kv_connector":"VastKVConnector","kv_role":"kv_consumer","kv_connector_extra_config":{"vast_endpoint":"http://vast-cluster:8080","kv_namespace":"inference/kv-cache"}}'
kv_role 필드가 producer(prefill)와 consumer(decode) 워커를 구분합니다.
라우팅 경로 헤더¶
| 헤더 | 값 | 의미 |
|---|---|---|
X-Continuum-Routing-Path |
prefill_then_decode, fast_decode, unified, fallback |
선택된 라우팅 경로 |
X-Continuum-Prefill-Backend |
백엔드 이름 | prefill 단계를 실행한 prefill 워커 |
X-Continuum-Decode-Backend |
백엔드 이름 | 토큰을 생성한 decode 워커 |
풀 크기 권장사항¶
- decode 대 prefill 비율 3:1로 시작. decode 워커가 prefill 워커보다 토큰 처리에 더 오랜 시간이 걸리기 때문이다.
- 프롬프트 다양성이 높은 워크로드(다양한 system prompt)의 경우 prefill 풀 증가
- 출력 시퀀스가 길거나 동시성이 높은 워크로드의 경우 decode 풀 증가
예시: 전체 프로덕션 설정¶
이 설정은 세 가지 VAST 통합 지점을 모두 결합합니다: 계층형 응답 캐시(Redis L1 + VAST S3 L2), 스토리지 오프로딩 인식 KV 캐시 인덱스, 분리형 prefill/decode 서빙.
server:
host: "0.0.0.0"
port: 8080
selection_strategy: LeastLatency
# ─── Prefix 인식 라우팅 (티어 1) ─────────────────────────────────────────────
prefix_routing:
enabled: true
max_prefix_length: 2048
load_factor_epsilon: 0.20
virtual_nodes: 200
# ─── 계층형 응답 캐시 (티어 2 + VAST S3 L2) ──────────────────────────────────
response_cache:
enabled: true
backend: tiered
ttl: "24h"
max_response_size: 2097152 # 2 MiB
max_stream_buffer_size: 20971520 # 20 MiB
# L1: Redis (핫, 빠름, 제한된 용량)
l1:
type: redis
max_value_size: 524288 # 512 KiB 초과 값은 L2로 직접 저장
redis:
url: "redis://redis-cluster:6379"
pool_size: 32
key_prefix: "cr:resp:"
connect_timeout_ms: 3000
command_timeout_ms: 1000
fallback_to_memory: true
# L2: VAST Data S3 (웜, 내구성, 고용량)
l2:
type: s3
endpoint: "https://vast-s3.prod.example.com"
bucket: "prod-llm-response-cache"
key_prefix: "response-cache/"
region: "us-east-1"
access_key: "${S3_ACCESS_KEY}"
secret_key: "${S3_SECRET_KEY}"
ttl_override: "7d"
tiered:
promote_on_hit: true
l1_promotion_ttl: "30m"
# ─── VAST 오프로딩 인식 KV 캐시 인덱스 (티어 4) ─────────────────────────────
kv_cache_index:
enabled: true
backend: redis # response_cache.redis의 redis 풀 재사용
max_entries: 1000000
entry_ttl_seconds: 1800
scoring:
overlap_weight: 0.6
load_weight: 0.3
health_weight: 0.1
min_overlap_threshold: 0.25
gpu_tier_weight: 1.0
storage_tier_weight: 0.6
storage_offloading:
enabled: true
treat_eviction_as_offload: true
event_sources:
- backend_name: prefill-worker-1
endpoint: "http://vllm-prefill-1:8000/v1/kv_events"
reconnect_interval_ms: 5000
- backend_name: prefill-worker-2
endpoint: "http://vllm-prefill-2:8000/v1/kv_events"
reconnect_interval_ms: 5000
- backend_name: decode-worker-1
endpoint: "http://vllm-decode-1:8000/v1/kv_events"
reconnect_interval_ms: 5000
- backend_name: decode-worker-2
endpoint: "http://vllm-decode-2:8000/v1/kv_events"
reconnect_interval_ms: 5000
- backend_name: decode-worker-3
endpoint: "http://vllm-decode-3:8000/v1/kv_events"
reconnect_interval_ms: 5000
# ─── 분리형 Prefill/Decode 서빙 ──────────────────────────────────────────────
disaggregated_serving:
enabled: true
prefill_timeout: "60s"
kv_transfer_timeout: "15s"
fallback_to_unified: true
default_external_storage:
endpoint: "http://vast-cluster.prod.example.com:8080"
kv_namespace: "prod/inference/kv-cache"
# ─── 백엔드 ───────────────────────────────────────────────────────────────────
backends:
- name: prefill-worker-1
url: "http://vllm-prefill-1:8000"
role: prefill
models: ["meta-llama/Llama-3.1-70B-Instruct"]
- name: prefill-worker-2
url: "http://vllm-prefill-2:8000"
role: prefill
models: ["meta-llama/Llama-3.1-70B-Instruct"]
- name: decode-worker-1
url: "http://vllm-decode-1:8000"
role: decode
weight: 2
models: ["meta-llama/Llama-3.1-70B-Instruct"]
- name: decode-worker-2
url: "http://vllm-decode-2:8000"
role: decode
weight: 2
models: ["meta-llama/Llama-3.1-70B-Instruct"]
- name: decode-worker-3
url: "http://vllm-decode-3:8000"
role: decode
weight: 2
models: ["meta-llama/Llama-3.1-70B-Instruct"]
- name: unified-fallback
url: "http://vllm-unified:8000"
role: unified
models: ["meta-llama/Llama-3.1-70B-Instruct"]
# ─── 헬스 체크 ────────────────────────────────────────────────────────────────
health_checks:
interval: "15s"
timeout: "5s"
unhealthy_threshold: 3
healthy_threshold: 2
# ─── 서킷 브레이커 ────────────────────────────────────────────────────────────
circuit_breaker:
enabled: true
failure_threshold: 5
recovery_timeout: "30s"
전체 프로덕션 설정을 위한 vLLM 실행 명령어¶
Prefill 워커 (2개 인스턴스):
vllm serve meta-llama/Llama-3.1-70B-Instruct \
--host 0.0.0.0 \
--port 8000 \
--tensor-parallel-size 4 \
--enable-prefix-caching \
--kv-cache-dtype auto \
--max-model-len 32768 \
--gpu-memory-utilization 0.85 \
--kv-transfer-config '{
"kv_connector": "VastKVConnector",
"kv_role": "kv_producer",
"kv_buffer_device": "cpu",
"kv_buffer_size": 8e9,
"kv_connector_extra_config": {
"vast_endpoint": "http://vast-cluster.prod.example.com:8080",
"kv_namespace": "prod/inference/kv-cache"
}
}'
Decode 워커 (3개 인스턴스):
vllm serve meta-llama/Llama-3.1-70B-Instruct \
--host 0.0.0.0 \
--port 8000 \
--tensor-parallel-size 4 \
--enable-prefix-caching \
--kv-cache-dtype auto \
--max-model-len 32768 \
--gpu-memory-utilization 0.90 \
--kv-transfer-config '{
"kv_connector": "VastKVConnector",
"kv_role": "kv_consumer",
"kv_buffer_device": "cpu",
"kv_buffer_size": 8e9,
"kv_connector_extra_config": {
"vast_endpoint": "http://vast-cluster.prod.example.com:8080",
"kv_namespace": "prod/inference/kv-cache"
}
}'
통합형 폴백 (1개 인스턴스):
vllm serve meta-llama/Llama-3.1-70B-Instruct \
--host 0.0.0.0 \
--port 8000 \
--tensor-parallel-size 4 \
--enable-prefix-caching \
--kv-cache-dtype auto \
--max-model-len 32768
통합형 폴백은 두 단계를 독립적으로 처리하므로 VAST 설정이 필요하지 않습니다.
성능 벤치마크¶
다음 수치는 일반적인 LLM 서빙 워크로드에서 측정한 예시 추정값입니다. 실제 결과는 프롬프트 다양성, GPU 메모리 용량, VAST로의 네트워크 대역폭, 동시 요청 볼륨에 따라 달라집니다.
응답 캐시 적중률 (VAST L2 포함)¶
| 워크로드 패턴 | L1 (Redis) 적중률 | L2 (VAST S3) 적중률 | 총 적중률 |
|---|---|---|---|
| 문서 QA (고정 문서 + 다양한 질문) | 30–50% | 20–35% | 50–75% |
| RAG 파이프라인 (고정 system prompt + 검색) | 15–30% | 10–20% | 25–45% |
| 동일 요청 반복 API | 70–95% | 3–10% | 75–98% |
| 완전히 고유한 요청 | < 5% | < 2% | < 7% |
L2는 L1 TTL을 초과하여 수 시간 또는 수 일에 걸쳐 동일한 요청이 반복되는 워크로드에 이점을 제공합니다.
분리형 서빙 지연 시간¶
70B 파라미터 모델에서 통합형(단일 워커) 추론 대비 지연 시간 개선:
| 라우팅 경로 | TTFT (첫 번째 토큰까지의 시간) | 통합형 대비 |
|---|---|---|
fast_decode (GPU 상주 KV) |
50–100 ms | 40–60% 감소 |
fast_decode (VAST 로드 KV) |
100–200 ms | 15–35% 감소 |
prefill_then_decode |
200–500 ms | 0–10% 오버헤드 (일회성 prefill 비용) |
unified (폴백) |
300–600 ms | 기준값 |
prefill_then_decode 경로는 prefix의 첫 번째 요청에 오버헤드를 추가하지만, 동일 prefix를 사용하는 이후 요청은 fast_decode 경로의 혜택을 받습니다.
KV 캐시 인덱스 라우팅 효과¶
| 시나리오 | KV 인식 라우팅 비율 | TTFT 감소 |
|---|---|---|
| 높은 prefix 중복 (동일 system prompt, 다수 사용자) | 70–85% | 20–40% |
| 중간 prefix 중복 (다양한 system prompt) | 40–60% | 10–25% |
| 낮은 prefix 중복 (완전히 고유한 프롬프트) | < 10% | < 5% |
VAST Data 액세스 지연 시간¶
| 작업 | 지연 시간 범위 | 대역폭 |
|---|---|---|
| S3 GET (응답 캐시 읽기) | 1–10 ms | 연결당 최대 10 Gbps |
| S3 PUT (응답 캐시 쓰기) | 2–15 ms | 연결당 최대 10 Gbps |
| KV 텐서 쓰기 (prefill → VAST) | 5–50 ms | 네트워크 제한; RDMA 사용 시 < 5 ms |
| KV 텐서 읽기 (VAST → decode) | 5–50 ms | 네트워크 제한; RDMA 사용 시 < 5 ms |
KV 전송 경로의 엄격한 지연 시간 요구사항이 있는 프로덕션 배포의 경우, VAST 클러스터를 동일 랙에 배치하거나 vLLM에서 직접 NVMe-oF 프로토콜로 액세스하는 RDMA 지원 네트워크 어댑터 사용을 고려하세요.