콘텐츠로 이동

VAST Data 통합 가이드

Continuum Router는 VAST Data 스토리지와 세 가지 지점에서 통합됩니다: 응답 캐시 L2 티어, 스토리지 오프로드 텐서 추적을 위한 KV 캐시 인덱스, 그리고 분리형 prefill/decode 서빙의 KV 텐서 전송 레이어입니다. 이 가이드에서는 각 통합 지점을 실용적인 배포 예시와 전체 프로덕션 설정과 함께 설명합니다.

목차


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에서 두 가지가 필요합니다:

  1. 버킷과 자격 증명이 있는 S3 호환 엔드포인트 (응답 캐시용)
  2. 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 및 패브릭 (라우터 레벨 통합에는 불필요)

환경 변수

민감한 자격 증명은 설정 파일 대신 환경 변수에 저장하세요:

export VAST_ACCESS_KEY="your-access-key"
export VAST_SECRET_KEY="your-secret-key"

라우터는 시작 시 설정 값의 ${ENV_VAR} 참조를 확장합니다.


예시: VAST 응답 캐시 (S3 API)

이 설정은 Redis를 핫 L1 캐시로, VAST Data S3를 내구성 있는 L2 캐시로 사용합니다. L1을 놓친 응답은 백엔드에 도달하기 전에 VAST에서 확인됩니다. L2 적중은 이후 빠른 액세스를 위해 L1으로 승격됩니다.

동작 방식

  1. 클라이언트가 결정론적 요청(temperature = 0)을 전송
  2. 라우터가 요청 매개변수로부터 캐시 키 계산
  3. L1(Redis) 확인 — 적중 시 즉시 응답 반환
  4. L1 미스 시 L2(VAST S3) 확인 — 적중 시 응답을 반환하고 L1으로 승격
  5. 두 곳 모두 미스 시 백엔드 호출 후 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) 데이터보다 낮은 점수 가중치를 적용합니다.

동작 방식

  1. vLLM이 프롬프트에 대한 KV 텐서를 계산하고 cache_created 이벤트 보고 (티어: GpuHot)
  2. GPU 메모리 압박 하에 vLLM이 텐서를 VAST로 오프로드하고 cache_offloaded 보고
  3. KV 인덱스가 해당 항목을 StorageWarm으로 다운그레이드
  4. 라우터가 매칭 prefix를 가진 새 요청을 StorageWarm 데이터를 보유한 백엔드로 라우팅 (overlap 점수 감소)
  5. 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단계 흐름을 조율합니다.

동작 방식

  1. 라우터가 요청의 prefix hash에 대해 KV 인덱스 확인
  2. decode 워커가 GPU 상주 텐서(GpuHot)를 보유한 경우: 해당 워커로 직접 라우팅 (빠른 decode)
  3. VAST에 텐서가 있는 경우(StorageWarm): 최소 부하 decode 워커로 라우팅 (VAST에서 로드)
  4. 캐시 없는 경우: 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 지원 네트워크 어댑터 사용을 고려하세요.