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 지원 네트워크 어댑터 사용을 고려하세요.