서빙 설정¶

공통 인자¶

상태 열은 Target Configuration 검증에서 각 값을 사용했는지 나타냅니다.

도구 호출 및 reasoning 관련 인자 3개는 검증 및 제한 사항의 에이전트 워크로드에서 사용했습니다. 이 워크로드에서는 mini-swe-agent가 여러 턴에 걸쳐 도구를 호출합니다.

P/D role별 인자¶

LMCache 환경 변수(prefill 전용)¶

Default configuration: 기능 및 정확도 검증에서 동작을 확인했지만 효과는 측정하지 않았습니다. 설정 파일 없이 환경 변수만으로 구성하며 차트 기본값에서는 modelserver.extraServeEnv.prefill에 지정합니다.

RDS 용량은 디스크 크기가 아닌 rank당 청크 수로 지정합니다. 각 rank(엔진 프로세스)는 RDS에 바인딩한 디바이스에 최대 rds_max_chunks개의 청크를 보관합니다(기본값 1000, LMCACHE_EXTRA_CONFIG에 rds_max_chunks를 추가해 설정). 새 청크를 저장하기 전에 가장 오래 사용하지 않은 청크를 제거합니다. 기본값과 LMCACHE_CHUNK_SIZE 4096을 사용하면 rank당 RDS에 최대 4,096,000 토큰(rds_max_chunks × LMCACHE_CHUNK_SIZE)을 보관합니다. 저장한 청크 하나는 NVMe 드라이브마다 칩렛 0 메모리 2 MiB를 사용합니다. 따라서 rds_max_chunks × 2 MiB × 드라이브 수에 staging 버퍼를 더한 값이 --gpu-memory-utilization이 남긴 칩렛 0 메모리 안에 들어가야 합니다. 두 값은 함께 변경하세요. lmcache-rbln 0.12.0 미만은 rds_max_chunks를 읽지 않습니다. 디바이스 요구 사항은 노드 준비 › RDS 설정을 참고하세요.

Speculative decoding(prefill과 decode 모두)¶

1
2
3
4
5

{
  "method": "eagle3",
  "model": "asherszhang/MiniMax-M2.7-EAGLE3-draft-vocab200k",
  "num_speculative_tokens": 3
}

prefill과 decode에 같은 값을 설정합니다. EAGLE-3의 draft head는 prefill 순전파 중 자체 KV 캐시를 채우므로 prefill에도 --speculative-config가 필요합니다.

라우터(llm-d EPP/GAIE)¶

표준 설정에서는 다음 플러그인으로 prefix 캐시를 고려한 라우팅을 사용합니다. scorer 가중치는 서빙 차트가 배포하는 업스트림 pd-epp-config를 따릅니다. 이 설정 전체는 Unverified입니다. 라우팅은 여러 Pod 가운데 대상을 고르는 일이므로 prefill과 decode가 하나씩인 기능 및 정확도 검증으로는 확인할 수 없습니다. Target Configuration 검증은 이 설정을 사용하지 않았습니다.

기능 및 정확도 검증의 P/D 배포도 이 표와 같은 플러그인과 가중치를 사용했습니다.

라우터는 요청을 보낸 Pod를 기록할 뿐 엔진이 실제로 캐시했는지는 확인하지 않습니다. 따라서 같은 프롬프트를 다시 보내면 decider가 prefill을 건너뜁니다. 모든 요청이 prefill을 거쳐야 하는 측정에서는 prefix-based-pd-decider 대신 always-disagg-pd-decider를 사용하세요.

AGG 레시피는 prefill Pod가 없으므로 다른 플러그인을 사용합니다. approx-prefix-cache-producer, inflight-load-producer, prefix-cache-affinity-filter, token-load-scorer를 단일 scheduling profile에 둡니다. prefix-cache-affinity-filter의 peakPrefillThroughput은 이 모델의 AGG 구성에서 측정한 2256(토큰/초)입니다.

PP와 DP의 동시 사용 제한¶

엔트리포인트는 pipeline-parallel-size > 1과 data-parallel-size > 1을 동시에 설정하면 실행을 거부합니다. 이 제약에 따라 P/D role별 구성은 사실상 prefill PP4/DP1, decode DP4/PP1로 결정됩니다.

Prefill: PP4¶

PP4는 62개 레이어를 4부분으로 나누어 가중치를 카드 4개에 분산합니다. 각 스테이지는 레이어 경계에서 활성값만 교환합니다.

Decode: DP4, expert parallel 활성화¶

decode는 요청마다 한 번에 토큰 1개를 생성하므로 소수의 expert만 활성화됩니다. DP4와 expert parallel을 결합하여 expert 256개를 카드 4개에 분산합니다. decode에서는 PP를 사용할 수 없으므로 expert parallel을 끄면 모든 카드에 전체 가중치가 필요합니다.

값 변경의 영향¶

--block-size 4096¶

Validated.

KV 캐시는 4,096 토큰 단위 블록으로 할당합니다. sub-block prefix caching을 활성화했으므로 prefix 재사용 단위는 이 블록보다 작습니다. 자세한 내용은 512 토큰의 prefix 재사용 단위에서 확인할 수 있습니다.

512 토큰의 prefix 재사용 단위¶

Default configuration: 기능 및 정확도 검증에서 동작을 확인했지만 sub-block 크기가 성능에 주는 효과는 측정하지 않았습니다.

sub-block prefix caching(VLLM_RBLN_SUB_BLOCK_CACHE=1)을 사용하면 sub-block 크기가 --max-num-batched-tokens 값이 됩니다(차트 기본값처럼 VLLM_RBLN_SUB_BLOCK_SIZE를 지정하지 않은 경우). 따라서 prefix 재사용 단위는 --block-size(4096)가 아닌 512입니다.

라우터가 prefix를 해시하는 단위는 autoTune 값에 따라 달라집니다. 차트와 레시피가 유지하는 기본값 autoTune: true에서는 라우터가 vllm:cache_config_info의 블록 크기와 블록 수로 approx-prefix-cache-producer.blockSizeTokens와 lruCapacityPerServer를 덮어씁니다. vllm-rbln은 sub-block prefix caching을 사용해도 이 메트릭에 --block-size(4096)를 보고합니다. 따라서 라우터는 prefix를 4,096 토큰 단위로 해시합니다. 한 블록보다 짧은 prefix는 엔진이 재사용할 수 있지만 라우터는 추적하지 않습니다. 차트 values의 blockSizeTokens: 512와 lruCapacityPerServer: 1024는 라우터가 Pod의 메트릭을 처음 읽기 전에만 적용하는 기본값입니다. 이후 메트릭을 읽지 못하면 라우터는 마지막으로 읽은 값을 유지합니다. autoTune: false이면 라우터는 지정한 blockSizeTokens를 사용하며 512가 sub-block 단위와 일치합니다. 이때 lruCapacityPerServer는 그 단위의 Pod당 블록 수로 지정해야 합니다. 이 구성은 Unverified입니다.

KV 블록 수¶

엔진이 시작 시 --gpu-memory-utilization에 맞춰 KV 블록 수를 산출합니다. 시작 시 노드에서 Not enough memory for N blocks of KV cache 또는 SYS_EBUSY: Lack of device memory를 보고할 때만 --gpu-memory-utilization을 낮추세요.

라우터가 참조하는 KV 용량¶

Default configuration: 동작은 확인했지만 효과는 측정하지 않았습니다.

llm-d 라우터의 Endpoint Picker(EPP)는 각 Pod가 보유한 prefix의 인덱스를 유지합니다. approx-prefix-cache-producer의 lruCapacityPerServer는 Pod별 인덱스 항목 수를 blockSizeTokens 단위로 지정합니다. 표준 설정은 두 값을 메트릭을 읽기 전에 쓰는 기본값으로만 지정합니다(blockSizeTokens: 512, lruCapacityPerServer: 1024). 기본적으로 활성화된 autoTune이 각 Pod의 vllm:cache_config_info 메트릭(CacheBlockSize, CacheNumBlocks)를 읽어 두 값을 Pod별로 덮어씁니다. 지정한 값은 라우터가 해당 Pod의 메트릭을 처음 읽기 전에만 적용합니다. 동적 KV를 사용하면 블록 수가 런타임에 결정되므로 메트릭이 기준이 됩니다. 이렇게 산출하므로 prefill과 decode Pod의 HBM 용량이 서로 달라도 각자에 맞는 용량을 적용합니다.

참고로 다음 표는 엔진이 보고한 HBM 용량입니다. Target Configuration의 4P4D에서 decode --max-num-seqs 1을 사용했을 때의 값입니다. 시작 시 동적 KV 크기 조정 후 vllm:cache_config_info의 num_gpu_blocks × --block-size로 구한 값입니다. 엔진이 워밍업 전에 기록하는 KV 캐시 크기는 조정 전 추정치이므로 더 큰 값이 표시됩니다.

EAGLE-3의 draft head와 자체 KV 캐시가 HBM 일부를 사용하므로 draft 모델을 로드하지 않는 방식보다 용량이 작습니다. decode의 --max-num-seqs를 높이면 decode 그래프가 추가될 때마다 메모리를 예약하여 용량이 더 줄어듭니다. EAGLE-3에서 --max-num-seqs 8을 사용하면 decode 엔진당 282,624 토큰을 보관합니다.

이 메트릭에는 HBM만 포함됩니다. prefill Pod의 RDS 용량(rank당 rds_max_chunks × LMCACHE_CHUNK_SIZE 토큰)은 산출 값에 반영되지 않습니다. LMCache/RDS를 활성화하면 인덱스가 실제 prefill 보유량보다 작아집니다. 라우터가 RDS에 남아 있는 일부 prefix를 놓쳐 hit 비율은 낮아지지만 오류는 발생하지 않습니다. Target Configuration 검증은 LMCache 없이 실행했으므로 이 동작은 Unverified입니다.

--kv-cache-dtype fp8¶

차트에 포함된 MiniMax-M2.7과 DeepSeek-V3.2 레시피는 KV 캐시에 fp8을 사용하며 이 설계에서도 사용합니다. KV 캐시를 8비트로 저장하고 모델 가중치와 활성값은 W8A16으로 실행하므로 전체 구성은 W8A16KV8입니다. 토큰당 약 124 KiB의 KV 캐시 크기는 이 구성을 기준으로 합니다. 이 인자를 변경하면 Rebel100™ 기반 Coding Assistant › KV 캐시 크기와 라우터가 참조하는 KV 용량을 다시 계산해야 합니다.

CPU 계층¶

Optional: RDS를 사용할 수 없는 노드에서는 호스트 메모리를 KV 오프로딩 계층으로 사용할 수 있습니다. Default configuration: 기능 및 정확도 검증의 lmcache cpu 모드로 정확도와 캐시 재사용을 확인했지만 효과는 측정하지 않았습니다. KV connector 구성(MultiConnector)은 RDS와 같고, modelserver.extraServeEnv.prefill의 다음 값만 바꿉니다.

LMCACHE_ENABLE_KV_EVENTS와 LMCACHE_PRE_CACHING_HASH_ALGORITHM은 RDS 구성과 같은 값을 유지합니다. prefill의 --gpu-memory-utilization 0.8은 RDS가 사용할 칩렛 0 메모리를 남기기 위한 값이므로 CPU 계층만 사용할 때는 지정하지 않아도 됩니다. CPU 계층은 prefill Pod의 호스트 메모리를 사용하므로 Pod 메모리 한도 안에 들어가야 합니다.