콘텐츠로 이동

헬스, 캐싱 & 로깅

헬스 체크 섹션

백엔드 헬스 모니터링을 설정합니다:

health_checks:
  enabled: true                    # 헬스 모니터링 활성화/비활성화
  interval: "30s"                  # 확인 주기
  timeout: "10s"                   # 요청 타임아웃
  unhealthy_threshold: 3           # 비정상 표시까지의 실패 횟수
  healthy_threshold: 2             # 정상 표시까지의 성공 횟수
  endpoint: "/v1/models"           # 확인할 엔드포인트
  warmup_check_interval: "1s"      # 워밍업 중 가속화된 확인 주기
  max_warmup_duration: "300s"      # 최대 워밍업 감지 시간

헬스 체크 프로세스:

  1. 라우터가 각 백엔드의 헬스 엔드포인트를 쿼리
  2. 성공적인 응답은 성공 카운터 증가
  3. 실패한 응답은 실패 카운터 증가
  4. 실패 임계값에 도달하면 백엔드를 비정상으로 표시
  5. 성공 임계값에 도달하면 백엔드를 정상으로 표시
  6. 정상 백엔드만 트래픽 수신

가속화된 워밍업 헬스 체크

라우터는 백엔드 워밍업 중 가속화된 헬스 체크를 지원합니다. 이는 모델 로딩 중 HTTP 503을 반환하는 llama.cpp와 같은 백엔드에 특히 유용합니다.

백엔드 상태:

상태 HTTP 응답 동작
ready 200 OK 일반 간격으로 체크
warming_up 503 Service Unavailable 가속화된 간격으로 체크
down 연결 실패 일반 간격으로 체크
unknown 초기 상태 첫 번째 체크로 상태 결정

워밍업 설정:

옵션 기본값 설명
warmup_check_interval 1s 워밍업 중 가속화된 체크 간격
max_warmup_duration 300s 가속화 모드 유지 최대 시간

동작 방식:

  1. 백엔드가 HTTP 503을 반환하면 warming_up 상태로 진입
  2. 헬스 체크가 가속화된 간격(기본값: 1초)으로 전환
  3. 백엔드가 HTTP 200을 반환하면 ready 상태가 되어 일반 간격으로 복귀
  4. 워밍업이 max_warmup_duration을 초과하면 백엔드를 비정상으로 표시

이 기능으로 모델 가용성 감지 지연 시간이 최대 30초(최악의 경우)에서 약 1초로 단축됩니다.

백엔드별 헬스 체크 설정

각 백엔드 타입에는 합리적인 기본 헬스 체크 엔드포인트가 있습니다. 백엔드별로 커스텀 health_check 설정으로 이러한 기본값을 재정의할 수 있습니다.

백엔드 타입별 기본 헬스 체크 엔드포인트:

백엔드 타입 기본 엔드포인트 폴백 엔드포인트 메서드 참고
openai /v1/models - GET 표준 OpenAI 엔드포인트
vllm /health /v1/models GET /health는 모델 로드 후 사용 가능
ollama /api/tags / GET Ollama 전용 엔드포인트
llamacpp /health /v1/models GET llama-server 엔드포인트
mlxcel /health /v1/models GET MLxcel 서버 (llama-server 호환)
lmstudio /v1/models /api/v1/models GET OpenAI 호환 + 네이티브 API
continuum-router /health /v1/models GET 원격 CR / Backend.AI GO
anthropic /v1/messages - POST 200, 400, 401, 429를 정상으로 허용
gemini /models /v1beta/models GET 네이티브 Gemini 엔드포인트
azure /health /v1/models GET Azure OpenAI 엔드포인트
generic /health /v1/models GET 범용 폴백

폴백 동작:

기본 헬스 체크 엔드포인트가 HTTP 404를 반환하면 라우터는 자동으로 폴백 엔드포인트를 순서대로 시도합니다. 이를 통해 모든 표준 엔드포인트를 구현하지 않는 백엔드와의 호환성을 보장합니다.

커스텀 헬스 체크 설정:

backends:
    - name: vllm-custom
    type: vllm
    url: http://localhost:8000
    models:
        - my-model
    health_check:
        endpoint: /custom-health          # 기본 엔드포인트
        fallback_endpoints:               # 기본 엔드포인트가 404 반환 시 시도
            - /health
            - /v1/models
        method: GET                       # HTTP 메서드: GET, POST 또는 HEAD
        timeout: 10s                      # 전역 헬스 체크 타임아웃 재정의
        accept_status:                    # 정상을 나타내는 상태 코드
            - 200
            - 204
        warmup_status:                    # 모델 로딩 중을 나타내는 상태 코드
            - 503

헬스 체크 설정 옵션:

옵션 타입 기본값 설명
endpoint string 백엔드 타입별 상이 기본 헬스 체크 엔드포인트 경로
fallback_endpoints array 백엔드 타입별 상이 기본 엔드포인트가 404 반환 시 시도할 엔드포인트
method string GET HTTP 메서드: GET, POST 또는 HEAD
body object null POST 요청용 JSON 본문
accept_status array [200] 백엔드가 정상임을 나타내는 상태 코드
warmup_status array [503] 백엔드가 워밍업 중임을 나타내는 상태 코드
timeout string 전역 타임아웃 전역 헬스 체크 타임아웃 재정의

예시: Anthropic 스타일 헬스 체크:

POST 요청을 사용하거나 오류 코드를 정상 지표로 허용하는 백엔드의 경우:

backends:
    - name: custom-api
    type: generic
    url: http://localhost:9000
    models:
        - custom-model
    health_check:
        endpoint: /api/v1/health
        method: POST
        body:
            check: true
        accept_status:
            - 200
            - 400    # Bad request는 서버가 동작 중임을 의미
            - 401    # Unauthorized는 서버가 동작 중임을 의미
            - 429    # Rate limited는 서버가 동작 중임을 의미

요청 섹션

요청 처리 동작을 제어합니다:

request:
  timeout: "300s"                  # 최대 요청 지속 시간
  max_retries: 3                   # 실패한 요청의 재시도 횟수
  retry_delay: "1s"                # 재시도 간 초기 지연

타임아웃 고려 사항:

  • 긴 타임아웃 (300s)은 느린 모델 추론 수용
  • 스트리밍 요청은 비스트리밍보다 오래 걸릴 수 있음
  • 사용자 경험과 리소스 사용 간 균형

재시도 섹션

복원력을 위한 전역 재시도 설정:

retry:
  max_attempts: 3                  # 최대 재시도 횟수
  base_delay: "100ms"              # 재시도 간 기본 지연
  max_delay: "30s"                 # 재시도 지연 상한
  exponential_backoff: true        # 지수 백오프 사용
  jitter: true                     # 무작위 지터 추가

재시도 전략:

  • 지수 백오프: 지연이 지수적으로 증가 (100ms, 200ms, 400ms...)
  • 지터: 썬더링 허드 방지를 위한 무작위성 추가
  • 최대 지연: 극도로 긴 대기 방지

캐시 섹션

캐싱 및 최적화를 제어합니다:

cache:
  model_cache_ttl: "300s"         # 모델 목록 캐시 기간
  deduplication_ttl: "60s"        # 동일 요청 캐시 기간
  enable_deduplication: true      # 요청 중복 제거 활성화

캐시 스탬피드 방지

라우터는 캐시 스탬피드(썬더링 허드 문제)를 방지하기 위해 세 가지 전략을 구현합니다:

  1. 싱글플라이트 패턴: 한 번에 하나의 집계 요청만 실행
  2. Stale-While-Revalidate: 백그라운드에서 갱신하면서 오래된 데이터 반환
  3. 백그라운드 갱신: 만료 전 사전 캐시 업데이트

고급 캐시 설정:

model_aggregation:
  cache_ttl: 60                     # 캐시 TTL (초, 기본값: 60)
  soft_ttl_ratio: 0.8               # 백그라운드 갱신 트리거 시점 (기본값: 0.8 = 80%)
  empty_response_base_ttl_seconds: 5   # 빈 응답의 기본 TTL
  empty_response_max_ttl_seconds: 60   # 지수 백오프 최대 TTL
  max_cache_entries: 100            # 최대 캐시 항목 수
  background_refresh:
    enabled: true                   # 백그라운드 갱신 활성화
    check_interval: 10s             # 검사 간격
옵션 기본값 설명
cache_ttl 60초 하드 TTL - 이 시간 후 캐시 만료
soft_ttl_ratio 0.8 소프트 TTL = cachettl * softttl_ratio. 소프트와 하드 TTL 사이에서 캐시가 오래되었지만 사용 가능
empty_response_base_ttl_seconds 5 빈 응답의 기본 TTL (DoS 방지)
empty_response_max_ttl_seconds 60 지수 백오프 최대 TTL (base * 2^n)
max_cache_entries 100 최대 캐시 항목 수
background_refresh.enabled true 사전 캐시 갱신 활성화
background_refresh.check_interval 10초 캐시 신선도 검사 주기

캐시 이점:

  • 모델 캐싱은 백엔드 쿼리 감소
  • 중복 제거는 중복 처리 방지
  • TTL은 오래된 데이터 문제 방지
  • 스탬피드 방지로 썬더링 허드 회피
  • 백그라운드 갱신으로 캐시가 항상 신선하게 유지

응답 캐시 섹션

결정적(temperature == 0) 요청에 대해 완전한 LLM 응답을 캐싱합니다 — 비스트리밍과 스트리밍 모두 지원합니다. 반복되는 동일한 요청은 백엔드를 호출하지 않고 메모리에서 제공됩니다.

response_cache:
  enabled: true                     # 응답 캐싱 활성화 (기본값: false)
  backend: memory                   # 캐시 백엔드: "memory" (기본값), "redis", 또는 "tiered"
  capacity: 1000                    # 최대 캐시 응답 수 (LRU 퇴거)
  ttl: "5m"                         # 캐시 항목 유효 기간 (예: "5m", "1h")
  max_response_size: 1048576        # 최대 응답 본문 크기 (바이트, 기본값: 1 MiB)
  max_stream_buffer_size: 10485760  # 최대 스트리밍 버퍼 크기 (바이트, 기본값: 10 MiB)

캐시 적격성

다음 조건이 모두 충족될 때만 응답이 캐싱됩니다:

  • response_cache.enabledtrue
  • 요청의 temperature 필드가 0이거나 없음 (결정적 출력)
  • 응답 본문이 max_response_size를 초과하지 않음
  • 비스트리밍 요청의 경우: 응답에 finish_reason: "error"가 포함되지 않음
  • 스트리밍 요청의 경우: 스트림이 성공적으로 완료됨 (최종 [DONE] 이벤트 수신); 중단되거나 오류가 발생한 스트림은 폐기되며 캐싱되지 않음

적격하지 않은 요청은 정상적으로 백엔드에 전달됩니다.

스트리밍 캐시 동작

캐싱이 활성화되고 temperature0일 때, 스트리밍(stream: true) chat completions도 캐싱 대상이 됩니다:

  1. SSE 이벤트가 클라이언트로의 정상 스트림 전달과 함께 메모리에 버퍼링됩니다 — 관측 가능한 지연 증가는 없습니다.
  2. 스트림이 성공적으로 완료되면(최종 [DONE] 이벤트), 라우터가 버퍼링된 청크에서 완전한 chat.completion JSON 객체를 재구성하여 캐시에 저장합니다.
  3. 스트림이 중단되면(클라이언트 연결 해제, 타임아웃, 백엔드 오류), 버퍼가 폐기되고 아무것도 저장되지 않습니다.
  4. 캐시 히트 시, 캐시된 응답이 X-Cache: HIT 헤더와 함께 합성 SSE 스트림(text/event-stream)으로 클라이언트에 재생됩니다.
  5. max_stream_buffer_size 설정은 스트리밍 버퍼를 제한합니다. 총 버퍼 내용이 이 임계값을 초과하는 스트림은 캐싱되지 않습니다.

X-Cache 응답 헤더

모든 chat completion 응답에 X-Cache 헤더가 포함됩니다:

의미
HIT 캐시에서 응답이 제공됨; 백엔드 호출 없음
MISS 캐시를 확인했지만 항목이 없음; 백엔드에서 응답을 받아 저장함
BYPASS 요청이 캐싱 불가 (예: temperature > 0); 백엔드가 호출되었으나 저장하지 않음

캐시 설정 옵션

옵션 기본값 설명
enabled false 응답 캐싱 활성화 여부
backend "memory" 캐시 백엔드 타입: "memory", "redis", 또는 "tiered". 변경 시 재시작 필요.
capacity 1000 최대 항목 수; 제한에 도달하면 가장 오래된 항목이 퇴거됨 (LRU). Redis 또는 tiered 백엔드 사용 시 무시됨.
ttl "5m" 캐시 항목의 유효 기간. 기간 문자열 지원: "30s", "5m", "1h"
max_response_size 1048576 이 값(바이트)보다 큰 비스트리밍 응답은 캐싱되지 않음
max_stream_buffer_size 10485760 누적 버퍼가 이 값(바이트)을 초과하는 스트리밍 응답은 캐싱되지 않음 (기본값: 10 MiB)
redis.url -- Redis/Valkey 연결 URL (redis-cache 빌드 기능 및 backend: redis 필요).
redis.pool_size 8 Redis 연결 풀의 연결 수
redis.key_prefix "cr:resp:" 모든 캐시 키의 네임스페이스 접두사. 동일한 Redis 인스턴스의 다른 애플리케이션과의 충돌 방지.
redis.connect_timeout_ms 3000 새 Redis 연결 설정 타임아웃 (밀리초)
redis.command_timeout_ms 1000 개별 Redis 명령 타임아웃 (밀리초)
redis.tls false Redis 연결에 TLS 사용 여부 (또는 URL에 rediss:// 스킴 사용)
redis.fallback_to_memory true Redis에 연결할 수 없을 때 인메모리 캐시로 폴백
l1.type "memory" tiered 백엔드의 L1 티어 타입: "memory" 또는 "redis" (redis-cache 기능 필요)
l1.max_value_size 1048576 L1 저장 대상 최대 값 크기 (바이트). 이를 초과하는 값은 L2에만 저장됨.
l2.type "s3" L2 티어 타입 (현재 "s3"만 지원; s3-cache 기능 필요)
l2.endpoint -- S3 호환 엔드포인트 URL (예: https://vast-cluster:8080)
l2.bucket -- 캐시 객체 저장을 위한 S3 버킷 이름
l2.key_prefix "response-cache/" 버킷 내 객체 키 접두사
l2.region "us-east-1" AWS 호환 리전 문자열
l2.access_key -- S3 액세스 키. ${ENV_VAR} 확장 지원.
l2.secret_key -- S3 시크릿 키. ${ENV_VAR} 확장 지원.
l2.ttl_override -- L2 항목의 선택적 TTL 오버라이드 (예: "24h"). L2 저장 시에만 전역 ttl을 대체함.
tiered.promote_on_hit true L2 히트 시 L1으로 프로모션할지 여부
tiered.l1_promotion_ttl "5m" L2에서 L1으로 프로모션된 값에 적용되는 TTL

Redis/Valkey 백엔드

기본적으로 응답 캐시는 프로세스 메모리에 항목을 저장합니다. 여러 라우터 인스턴스 간에 캐시를 공유하거나 재시작 후에도 유지하려면 Redis 또는 Valkey 백엔드를 설정하세요.

빌드 요구 사항: 바이너리가 redis-cache Cargo 기능으로 컴파일되어야 합니다:

cargo build --release --features redis-cache

설정:

response_cache:
  enabled: true
  backend: redis                     # Redis 백엔드 선택
  ttl: "5m"
  redis:
    url: "redis://localhost:6379"    # 일반 TCP
    # url: "rediss://redis.example.com:6380"   # TLS
    # url: "redis://:password@localhost:6379"  # 인증 포함
    pool_size: 8                     # 연결 풀 크기 (기본값: 8)
    key_prefix: "cr:resp:"           # 키 네임스페이스 접두사 (기본값: "cr:resp:")
    connect_timeout_ms: 3000         # 연결 타임아웃 (기본값: 3000)
    command_timeout_ms: 1000         # 명령별 타임아웃 (기본값: 1000)
    tls: false                       # TLS 사용 (기본값: false)
    fallback_to_memory: true         # 실패 시 인메모리로 폴백 (기본값: true)

자동 장애 조치: fallback_to_memorytrue(기본값)이고 Redis에 연결할 수 없으면, 라우터는 투명하게 인메모리 캐시로 폴백하고 경고를 로깅합니다. 백그라운드 헬스 모니터가 주기적으로 PING 명령을 보내고 연결이 복원되면 다시 Redis로 전환합니다. 이 동작을 비활성화하려면 fallback_to_memory: false를 설정하세요 — 폴백 대신 작업이 실패합니다.

키 안전성: clear()FLUSHDB 대신 설정된 접두사 패턴으로 SCAN + DEL을 사용합니다. 접두사와 일치하는 키만 제거되므로 다른 애플리케이션과 Redis 인스턴스를 안전하게 공유할 수 있습니다.

S3 호환 계층형 백엔드

계층형 백엔드는 빠른 L1 캐시와 S3 호환 API로 지원되는 거의 무제한의 L2 캐시를 결합합니다. 대형 응답은 L1의 퇴거 압력을 방지하기 위해 L2에만 저장됩니다. L2 히트 시 값은 선택적으로 L1으로 프로모션되어 이후 접근 속도를 높입니다.

빌드 요구 사항: 바이너리가 s3-cache Cargo 기능으로 컴파일되어야 합니다:

cargo build --release --features s3-cache

계층형 캐시 쓰기 경로:

  1. 모든 set()은 L2 (S3)에 무조건 씁니다.
  2. 값이 l1.max_value_size보다 작으면 L1에도 씁니다.
  3. 임계값을 초과하는 값은 L2 전용으로 강등되며, 강등 카운터가 증가합니다.

계층형 캐시 읽기 경로:

  1. L1을 먼저 확인합니다. 히트 시 즉시 값을 반환합니다.
  2. L1 미스 시 L2 (S3)를 조회합니다.
  3. L2 히트 시, tiered.promote_on_hittrue이고 값이 L1에 맞으면 tiered.l1_promotion_ttl을 TTL로 L1에 프로모션합니다.

TTL 적용: 각 S3 객체는 expires-at 메타데이터 필드(Unix 타임스탬프)를 가집니다. GET 시 타임스탬프가 지나면 객체가 지연 삭제되고 캐시 미스가 반환됩니다. l2.ttl_override를 사용하여 L2 항목을 전역 ttl보다 오래 유지할 수 있습니다.

설정:

response_cache:
  enabled: true
  backend: tiered                    # 계층형 L1/L2 백엔드 선택
  ttl: "5m"                          # 두 티어 모두의 기본 TTL

  l1:                                # L1 (핫) 티어 — 빠르고 제한됨
    type: memory                     # "memory" 또는 "redis" (redis는 redis-cache 기능 필요)
    max_value_size: 1048576          # 이보다 큰 값은 L2 전용 (기본값: 1 MiB)

  l2:                                # L2 (웜) 티어 — S3
    type: s3
    endpoint: "https://s3.example.com:8080"
    bucket: "llm-response-cache"
    key_prefix: "response-cache/"    # 객체 키 접두사 (기본값: "response-cache/")
    region: "us-east-1"              # 리전 문자열 (기본값: "us-east-1")
    access_key: "${S3_ACCESS_KEY}" # 환경 변수 확장 지원
    secret_key: "${S3_SECRET_KEY}"
    ttl_override: "24h"              # 선택적: L2 항목을 전역 TTL보다 오래 유지

  tiered:                            # 프로모션/강등 동작
    promote_on_hit: true             # L2 히트를 L1으로 프로모션 (기본값: true)
    l1_promotion_ttl: "5m"          # 프로모션된 항목의 TTL (기본값: "5m")

메트릭: s3-cache 빌드는 L1/L2 히트율, 프로모션/강등 카운트, S3 작업 지연 히스토그램(continuum_cache_s3_latency_seconds)에 대한 Prometheus 카운터를 추가합니다.

Redis를 L1으로 사용: redis-caches3-cache 기능을 결합하여 Redis를 L1 티어로 사용할 수 있습니다:

cargo build --release --features redis-cache,s3-cache
response_cache:
  backend: tiered
  l1:
    type: redis                      # 인스턴스 간 공유를 위해 Redis를 L1으로 사용
    max_value_size: 1048576
  redis:                             # l1에서 재사용되는 공유 Redis 설정
    url: "redis://localhost:6379"
    pool_size: 8
  l2:
    type: s3
    endpoint: "https://s3.example.com:8080"
    bucket: "llm-response-cache"
    access_key: "${S3_ACCESS_KEY}"
    secret_key: "${S3_SECRET_KEY}"

제한 사항

  • 스트리밍 캐시는 OpenAI 호환 백엔드에서만 지원됩니다. Anthropic 및 Gemini 네이티브 스트리밍 형식은 캐싱되지 않습니다.
  • Anthropic(/anthropic/v1/messages) 및 OpenAI(/v1/chat/completions) 엔드포인트는 response_cache.enabled: true일 때 동일한 공유 캐시 인스턴스를 유지합니다.
  • Redis 백엔드를 설정하지 않으면 캐시는 인메모리에 저장되며 서버 재시작 후 유지되지 않습니다.

KV 캐시 인덱스 섹션

정밀한 오버랩 점수 기반 라우팅을 위한 실시간 KV 캐시 상태 추적을 활성화합니다. vLLM 백엔드가 요청을 처리하면 캐싱된 토큰 접두사를 설명하는 SSE 이벤트를 발생시킵니다. 라우터는 이러한 이벤트를 구독하고, 모든 백엔드의 캐시 상태 인덱스를 유지하며, 이 데이터를 사용하여 관련 KV 캐시 데이터를 가지고 있을 가능성이 가장 높은 백엔드로 요청을 라우팅합니다.

kv_cache_index:
  enabled: true                      # KV 캐시 인덱스 활성화 (기본값: false)
  backend: memory                    # 인덱스 백엔드: "memory" (기본값) 또는 "redis"
  max_entries: 100000                # 추적할 최대 접두사 해시 항목 수
  entry_ttl_seconds: 600             # 인덱스 항목 TTL (초)
  scoring:                           # 백엔드 선택을 위한 스코어링 가중치
    overlap_weight: 0.6              # 캐시 오버랩 신호 가중치 (0.0-1.0)
    load_weight: 0.3                 # 백엔드 부하 신호 가중치 (0.0-1.0)
    health_weight: 0.1               # 백엔드 헬스 신호 가중치 (0.0-1.0)
    min_overlap_threshold: 0.3       # KV 인식 라우팅 활성화 최소 오버랩
    gpu_tier_weight: 1.0             # GPU 상주(핫) 캐시 데이터에 대한 계층 배수
    storage_tier_weight: 0.6         # 스토리지 오프로드(웜) 캐시 데이터에 대한 계층 배수
  storage_offloading:                # 계층형 스토리지 인식 (GPU 핫 / 스토리지 웜)
    enabled: false                   # 스토리지 계층 추적 활성화 (기본값: false)
    treat_eviction_as_offload: true  # 퇴거를 웜 스토리지로의 오프로드로 처리 (기본값: true)
  event_sources:                     # vLLM 백엔드 KV 이벤트 스트림 엔드포인트
    - 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

동작 방식

  1. 이벤트 소비: 라우터가 설정된 vLLM 백엔드의 SSE 이벤트 스트림을 구독합니다. 각 이벤트는 접두사 해시와 토큰 수를 포함한 CacheCreated, CacheEvicted, CacheOffloaded, CacheReloaded, 또는 CachePurged 액션을 보고합니다.
  2. 인덱스 업데이트: 이벤트가 접두사 해시를 캐시된 토큰 수와 스토리지 계층(GpuHot 또는 StorageWarm)과 함께 백엔드에 매핑하는 인메모리(또는 Redis 기반) 인덱스를 업데이트합니다.
  3. 스코어링: 각 요청 시 오버랩 스코어러가 요청의 접두사 키에 대한 인덱스를 쿼리하고 캐시 오버랩(계층 배수로 조정됨), 백엔드 부하, 백엔드 헬스를 결합한 가중 점수를 계산합니다.
  4. 라우팅 결정: 최고 점수가 min_overlap_threshold를 초과하면 해당 백엔드를 선택합니다. 그렇지 않으면 설정된 선택 전략(예: PrefixAwareHash)이 폴백으로 사용됩니다.

스코어링 공식

final_score = overlap_weight * (raw_overlap * tier_multiplier)
            + load_weight * (1 - load_ratio)
            + health_weight * health_score

여기서:

  • raw_overlap = backendtokencount / maxtokencountacrossbackends (0.0 ~ 1.0)
  • tier_multiplier = GPU 상주 데이터는 gpu_tier_weight, 오프로드 데이터는 storage_tier_weight
  • load_ratio = inflightrequests / maxinflight (0.0 ~ 1.0)
  • health_score = 백엔드 success_rate (0.0 ~ 1.0)

storage_offloading.enabledfalse이면 모든 데이터가 GpuHot으로 처리되며 tier_multiplier는 항상 gpu_tier_weight(기본값: 1.0)입니다.

설정 옵션

옵션 기본값 설명
enabled false KV 캐시 인덱스 활성화 여부
backend "memory" 인덱스 저장 백엔드: "memory" 또는 "redis". Redis는 redis-cache 빌드 기능과 response_cache.redis의 공유 Redis 설정이 필요.
max_entries 100000 최대 접두사 해시 항목 수. 용량 도달 시 LRU 퇴거 적용.
entry_ttl_seconds 600 인덱스 항목의 TTL. 오래된 항목은 주기적으로 정리됨.
scoring.overlap_weight 0.6 캐시 오버랩 신호의 가중치. 높은 값은 캐시 친화성을 선호.
scoring.load_weight 0.3 백엔드 부하 신호의 가중치. 높은 값은 부하가 적은 백엔드를 선호.
scoring.health_weight 0.1 백엔드 헬스 신호의 가중치. 높은 값은 더 건강한 백엔드를 선호.
scoring.min_overlap_threshold 0.3 KV 인식 라우팅 활성화를 위한 최소 오버랩 점수. 이를 초과하는 백엔드가 없으면 폴백 전략 사용.
scoring.gpu_tier_weight 1.0 데이터가 GPU 상주(GpuHot)일 때 오버랩 점수에 적용되는 배수. storage_offloading.enabledtrue일 때만 유효.
scoring.storage_tier_weight 0.6 데이터가 스토리지 오프로드(StorageWarm)일 때 오버랩 점수에 적용되는 배수. storage_offloading.enabledtrue일 때만 유효.
storage_offloading.enabled false 스토리지 계층 추적 활성화. false이면 퇴거 이벤트가 항목을 완전히 제거.
storage_offloading.treat_eviction_as_offload true true이면 cache_evicted 이벤트가 항목을 제거하는 대신 GpuHot에서 StorageWarm으로 다운그레이드. storage_offloading.enabledtrue일 때만 유효.
event_sources[].backend_name -- 백엔드 이름 (설정된 백엔드 이름과 일치해야 함)
event_sources[].endpoint -- vLLM KV 이벤트 SSE 엔드포인트 URL (http, https, ws 또는 wss)
event_sources[].reconnect_interval_ms 5000 연결 끊김 후 재연결 지연

Redis 백엔드

backend: redis일 때, KV 인덱스는 response_cache.redis의 공유 Redis 연결을 사용합니다. 여러 라우터 인스턴스가 동일한 인덱스를 공유하여 전체 플릿에서 일관된 라우팅 결정을 내릴 수 있습니다.

response_cache:
  redis:
    url: "redis://localhost:6379"
    pool_size: 8

kv_cache_index:
  enabled: true
  backend: redis    # response_cache.redis의 Redis 설정 사용

Admin 엔드포인트

  • GET /admin/kv-index/stats — 인덱스 크기, 이벤트 비율, 연결 상태, 스코어링 분포
  • GET /admin/kv-index/backends — 백엔드별 캐시 상태 요약
  • POST /admin/kv-index/clear — 인덱스 초기화 (디버깅용)

전체 응답 스키마는 Admin API를 참조하세요.

제한 사항

  • 이벤트 소스는 현재 vLLM 호환 SSE 엔드포인트만 지원합니다.
  • backendmemoryredis 간에 변경하려면 재시작이 필요합니다.
  • KV 인덱스는 선택적 개선 기능입니다 — 사용 불가 시에도 라우팅은 정상 작동합니다.

로깅 섹션

로깅 출력을 설정합니다:

logging:
  level: "info"                   # trace, debug, info, warn, error
  format: "json"                  # json, pretty
  enable_colors: false            # 컬러 출력 (pretty 형식만)

로그 레벨:

  • trace: 매우 상세, 모든 세부 정보 포함
  • debug: 상세한 디버깅 정보
  • info: 일반적인 운영 정보
  • warn: 경고 메시지 및 잠재적 문제
  • error: 오류 조건만

로그 형식:

  • json: 구조화된 JSON 로깅 (프로덕션 권장)
  • pretty: 사람이 읽기 쉬운 형식 (개발에 적합)