태그: #vLLM 에서 Dynamo 로

← 전체 글

• prefill 과 decode 를 나누면, 작은 모델과 느린 망에서 잰 분리 서빙

  Dynamo 의 분리 서빙을 쿠버네티스에서 Grove 없이 띄우고, 3편과 같은 요청을 보냈습니다. 같은 서버 안에서 prefill 워커 둘과 decode 워커 둘로 나누자 첫 토큰 시간의 중앙값이 34~106ms 에서 286~896ms 로 늘었고 처리량은 37~48% 줄었습니다. 캐시에 맞은 요청도 KV 272MB 를 decode 워커로 옮겨야 하기 때문입니다. 서버 사이(1GbE)에서는

  2026-11-13 · 12 분 읽기 #NVIDIA Dynamo#vLLM#분리 서빙#prefill decode#NIXL

• 같은 요청을 Dynamo 로 보내면, 라운드로빈과 KV 인지 라우팅 실측

  1편에서 잰 요청을 같은 순서로 Dynamo 에 다시 보냈습니다. 프런트엔드를 라운드로빈으로 두면 적중률은 Service 뒤 vLLM 과 같았습니다. Dynamo 를 거치는 것만으로는 캐시가 살아나지 않습니다. KV 인지 라우팅을 켜면 워커 6대에서 요청 단위 적중이 접두 7종 56%→83%, 12종 32%→68%, 24종 18%→43% 로 올랐고, 동시 16 의 TTFT p99 는 1.3~

  2026-11-13 · 16 분 읽기 #NVIDIA Dynamo#vLLM#KV 인지 라우팅#접두 캐시#KV 캐시

• Dynamo 오퍼레이터를 깔기 전에 볼 것: 웹훅 범위, 설치 방식 둘, 반입 목록

  Dynamo 1.6.2 를 쿠버네티스에 올리려면 오퍼레이터를 먼저 깔아야 합니다. 차트를 그려 보니 기본(전역) 방식은 ClusterRole 12개와 웹훅 8개를 만들고, 그 가운데 하나는 클러스터의 모든 파드 생성에 걸립니다. 웹훅을 좁히는 값은 차트가 거부했고, 남은 길인 네임스페이스 제한 방식은 단독으로 쓰면 CRD·변환 웹훅 주소·인증서가 빠집니다. 오퍼레이터와 워크로드의 네임스페이스

  2026-11-13 · 15 분 읽기 #NVIDIA Dynamo#쿠버네티스 오퍼레이터#승인 웹훅#Helm#폐쇄망

• Service 뒤에 vLLM 을 여러 대 두면 접두 캐시는 얼마나 맞는가

  vLLM 파드 여러 대를 쿠버네티스 Service 하나로 묶으면 요청은 아무 파드로나 갑니다. 접두 캐시는 파드마다 따로이므로, 같은 앞부분을 가진 요청이 다른 파드로 가면 처음부터 다시 계산합니다. 0.6B 모델과 워커 6대·3대로 재 보니 접두가 2종일 때는 요청의 95~98% 가 캐시에 맞았지만 7종에서 52~60%, 12종에서 29~34%, 24종에서 16~18% 로 떨어졌습니다. 이

  2026-11-13 · 11 분 읽기 #NVIDIA Dynamo#vLLM#접두 캐시#KV 캐시#쿠버네티스