상태: 초안 (2026-10-05). 공식 문서로 확인한 서술을 바탕으로 쓴 글이고, 필자의 실험 환경에서 직접 잰 실측은 아직 반영되지 않았습니다. 글 끝의 「확인한 버전과 날짜」와 「확인하지 못한 것」을 먼저 읽으십시오. 실측이 들어오면 「실측」 절이 더해지고 이 배너가 바뀝니다. 작성 규칙: 실측 데이터가 기본이고, 못 잰 것은 「미실측」으로 표시합니다.

분산 추론과 NVIDIA Dynamo

요약

큰 모델은 GPU 한 장에 들어가지 않으므로 가중치를 여러 장에 나누어야 합니다. 나누는 방식(텐서·파이프라인·전문가·데이터 병렬)마다 통신량과 지연이 크게 다르기 때문에, 노드 안에서는 대역폭이 큰 방식을, 노드 사이에서는 통신이 적은 방식을 쓰는 경향이 있습니다. 또한 prefill(프롬프트 처리)과 decode(토큰 생성)는 자원 특성이 달라서 풀을 나누면 서로 방해하지 않지만, 대신 KV 캐시를 옮겨야 합니다. NVIDIA Dynamo 는 이 분리, KV 인지 라우팅, 자동 스케일링을 엔진 위에서 조율하는 계층입니다.

이 글을 읽고 나면 면접에서 설명할 수 있는 것

1. 텐서·파이프라인·전문가·데이터 병렬이 각각 무엇을 나누고 어떤 통신을 일으키는지, 노드 안과 노드 사이에서 선택이 갈리는 이유.
2. prefill/decode 분리의 동기와 대가를 KV 캐시 크기 계산으로 설명하고, 이득인 워크로드와 손해인 워크로드를 가르는 기준.
3. Dynamo v1.5.0 의 구성요소가 요청 한 건을 어떻게 처리하는지, llm-d·vLLM·SGLang 과 무엇이 다른지.

글쓴이의 위치. 저는 일반 이더넷(1~2.5GbE 급) 환경에서 실험하고 있으며 RDMA, InfiniBand, NVLink 경험이 없습니다. 이 글은 공식 문서와 논문을 읽고 정리한 것이고, 직접 측정한 값은 LMCache 실험 하나뿐입니다.

1. 모델을 쪼개는 네 가지 방법

통신량은 Narayanan 외(2021) 논문의 식으로 가늠합니다. PP 는 인접 구간 사이에서 마이크로배치당 b·s·h 개 원소(배치, 시퀀스 길이, 은닉 차원의 곱)를 보냅니다. TP 는 학습 기준으로 층마다 장치당 8·b·s·h·(t−1)/t 개를 주고받는데, 순전파와 역전파에서 all-reduce 가 두 번씩이기 때문입니다. 추론에는 역전파가 없으므로 순전파 몫만 남기면 4·b·s·h·(t−1)/t 입니다(글쓴이의 유도).

설명용 예시(실측 아님). Qwen3-32B(은닉 5120, 64층)에 8,000 토큰 프롬프트 하나를 TP=8 로 prefill 하고 bf16 으로 계산하면, 층마다 장치당 약 287MB, 64층 전체로 약 18GB 가 all-reduce 로 오갑니다. 같은 요청에서 PP 경계 하나를 넘는 데이터는 약 82MB 입니다.

그래서 논문은 TP 를 서버 안의 GPU 수까지 쓰고 그 이상은 PP 로 늘리라고 정리합니다(Takeaway #1, 학습 맥락). vLLM 문서도 TP 를 노드당 GPU 수로, PP 를 노드 수로 두라고 하며 NVLink 가 없는 GPU(L40S 등)에서는 PP 가 낫다고 적습니다. 대역폭 차이는 사양으로도 보입니다. NVIDIA 는 NVLink 4세대를 GPU 당 900GB/s, 5세대를 1,800GB/s(양방향 합계)로 표기하고, ConnectX-7 한 장은 400Gb/s(방향당 약 50GB/s)입니다. DeepSeek-V3 보고서의 H800 클러스터는 NVLink 160GB/s 대 InfiniBand 50GB/s 였습니다.

EP 는 토큰을 전문가가 있는 GPU 로 보냈다가 결과를 되돌려 받으므로 all-to-all 이 층마다 일어납니다. DeepSeek-V3 는 토큰이 최대 4개 노드까지만 가도록 라우팅을 제한해 InfiniBand 트래픽을 줄였고, 배포 단위를 prefill 32 GPU(EP32), decode 320 GPU(EP320)로 잡았습니다. vLLM 에서는 --enable-expert-parallel 을 켜면 EP 크기가 TP × DP 가 되고, 통신 백엔드로 prefill 에 deepep_high_throughput, decode 에 deepep_low_latency 를 안내합니다.

 [노드 A: TP=4]                          [노드 B: TP=4]
 GPU0 GPU1 GPU2 GPU3 -- PP 경계 --> GPU4 GPU5 GPU6 GPU7
  └ NVLink all-reduce ┘  (활성화 텐서,    └ NVLink all-reduce ┘
    층마다, 지연 민감       점대점, RDMA)      층마다, 지연 민감

2. prefill/decode 분리: 왜 하고, 무엇을 치르는가

동기. Dynamo 문서는 prefill 을 연산 중심, decode 를 메모리 중심으로 설명하며, 그래서 decode 에 더 큰 TP, prefill 에 더 작은 TP 를 줄 수 있다고 합니다. SGLang 문서는 한 엔진에서 섞으면 새 prefill 이 진행 중인 decode 를 끊어 토큰 생성이 지연된다고 설명합니다. vLLM 문서는 TTFT(첫 토큰까지의 시간)와 ITL(토큰 사이 지연)을 따로 조정하고 꼬리 ITL 을 통제할 수 있다는 점을 이유로 들면서, 분리가 처리량을 높이지는 않는다고 분명히 적습니다. 논문 쪽에서 DistServe 는 챗봇에서 vLLM 대비 요청률 2.0~4.6배(DeepSpeed-MII 대비 1.6~7.4배), 요약에서 SLO 를 최대 12.6배 엄격하게 만족한다고 보고하며(서로 다른 응용과 비교 대상의 최댓값이라 한 구성에서 동시에 얻은 값이 아닙니다), Splitwise 는 기존 클러스터 대비 처리량 1.4배에 비용 20% 감소 또는 같은 전력에서 2.35배를 주장합니다(클러스터 규모의 이득은 실측이 아니라 시뮬레이터 결과). 둘 다 70B 에서 175B 급 모델과 빠른 연결(NVLink 안 배치, InfiniBand 200/400Gbps)이라는 논문 조건에서 나온 값입니다. 본문 수치는 아래 「외부 근거」에서 직접 확인했습니다.

대가: KV 캐시를 옮겨야 합니다. 토큰당 KV 크기는 2(K와 V) × 층 수 × KV 헤드 수 × 헤드 차원 × 바이트 수 입니다. Qwen3-32B 의 config.json(64층, KV 헤드 8, 헤드 차원 128, bf16)으로 계산하면 토큰당 256KiB, 8,000 토큰이면 약 2.1GB 입니다.

필자의 실측. Qwen2.5-1.5B 를 8GB급 노트북 GPU 에서 vLLM+LMCache 로 돌린 실험입니다. 문서당 4,864 토큰(0.13GB)의 KV 를 CPU 메모리에서 GPU 로 불러오는 데 약 8~9ms, 같은 5천 토큰을 새로 계산하는 데 약 560ms 가 걸렸습니다. 이 모델의 토큰당 KV 는 28KiB 이므로 4,864 토큰이 0.13GiB 가 되어 로그의 0.1299 와 맞습니다. 다만 한 노드 안의 CPU 에서 GPU 로의 이동이지 네트워크 전송이 아니고, 동시성 1, 모델 1.5B, 합성 문서, 단일 측정입니다. 읽을 수 있는 결론은 "옮기는 편이 다시 계산하는 편보다 쌀 수 있다"는 방향까지이며, 네트워크 구간에서 성립하려면 위 표처럼 대역폭이 받쳐 주어야 합니다.

Dynamo 문서 세트는 TCP 로 KV 를 옮기면 TTFT 가 약 98초, RDMA 면 200~500ms 라고 적습니다. 두 수치의 성격이 다릅니다. 98초는 Llama-3.1-8B, 입력 8,000토큰, AWS p5.48xlarge 에서 EFA 파드의 NIXL 이 UCX 의 느린 경로로 조용히 떨어졌을 때 잰 값이고(문서가 해결책으로 NIXL 백엔드를 LIBFABRIC 으로 지정하라고 안내), 200~500ms 는 문서가 「사양 기반 기대치」라고 적은 값입니다. 같은 조건의 EFA 에서 실제로 잰 KV 전송 추가분은 37ms 였습니다. 그러므로 「TCP 는 98초, RDMA 는 0.5초」를 일반적인 대비로 읽으면 안 됩니다(아래 「외부 근거」).

3. KV 캐시는 어떤 경로로 이동하는가

전송 라이브러리는 NIXL(NVIDIA Inference Xfer Library)입니다. 메모리 종류(HBM, DRAM, 파일, 객체 저장소)를 추상화하고 플러그인으로 백엔드를 고릅니다. 문서가 드는 백엔드는 UCX 와 GPUDirect Storage 이고, Dynamo 문서는 UCX 나 libfabric 을 거친다고 적으며, SGLang 은 Mooncake 와 NIXL 을 지원합니다. 노드 안에서는 CUDA IPC 로 NVLink 를, 노드 사이에서는 RDMA 를 씁니다.

방향은 "decode 가 prefill 에서 끌어오는(pull)" 형태입니다. llm-d 문서가 그렇게 적고, vLLM NixlConnector 는 prefill 쪽 KV 블록을 기본 30초 임대(lease)로 붙잡아 둡니다. 운영에서 알아 둘 점이 네 가지 있습니다. 첫째, NCCL_IB_HCA 같은 NCCL 변수는 NixlConnector 에 적용되지 않고 UCX_TLS, UCX_NET_DEVICES 를 써야 합니다. 둘째, Dynamo 문서에 따르면 같은 노드의 서로 다른 파드끼리도 NVLink 가 막혀 NIC 로 전송해야 합니다. 셋째, 쿠버네티스에서 /dev/shm 기본값(64MB)은 NIXL 초기화에 모자라 sharedMemory 를 16Gi 로 올리라고 안내합니다. 넷째, vLLM 문서는 kv_role="kv_both" 를 폐기 예정으로 두고 kv_producer/kv_consumer 를 쓰라고 하는데 Dynamo 1.5.0 문서 예시는 아직 kv_both 를 씁니다.

4. Dynamo v1.5.0 의 구조

Dynamo 는 엔진을 대체하지 않고 vLLM, SGLang, TensorRT-LLM 위에서 여러 노드를 조율합니다. 런타임은 Rust, 확장은 Python 입니다.

flowchart LR
  C[클라이언트] -->|HTTP 8000| F[Frontend<br/>토큰화·검증]
  F --> R[Router / PrefillRouter]
  R -->|1 prefill 요청| P[Prefill Worker]
  P -->|2 disaggregated_params| R
  R -->|3 decode 요청+메타데이터| D[Decode Worker]
  P -.->|4 KV 전송 NIXL| D
  D -->|5 토큰 스트림| F
  PL[Planner] -.->|복제본 수 조정| P
  PL -.-> D
  DS[(Discovery: K8s 또는 etcd)] -.-> F

• Frontend: OpenAI 호환 HTTP 서버(포트 8000)로, 채팅 템플릿 적용, 토큰화, 검증, 역토큰화를 맡습니다.
• Router: 접두사가 이미 캐시된 워커와 현재 부하를 함께 보고 가장 싼 워커를 고릅니다. 비용은 prefill_load_scale × max(0, 활성 prefill 블록 + 신규 프롬프트 블록 − 겹침 크레딧) + 잠재 decode 블록 + 활성 요청 비용 입니다. 워커가 KV 생성·삭제 이벤트를 발행해 인덱스를 갱신하며, 이벤트를 못 받으면 --no-router-kv-events 로 예측 모드를 씁니다. 문서는 이것을 "배치 결정"이라 부르며, 캐시가 뜨거운 워커도 부하가 높으면 집니다.
• Worker: 엔진 프로세스입니다. 분리 배포에서는 --disaggregation-mode prefill|decode 로 역할을 가릅니다.
• Planner: TTFT, ITL SLA 를 목표로 복제본 수를 조정합니다. 목표는 throughput(기본), latency, load, sla 이고, 처리량 기반(기본 180초 주기)과 부하 기반(기본 5초 주기)을 함께 쓸 수 있습니다. 스케일 다운 때 진행 중 요청을 기다리지 않고 워커를 종료하므로 min_endpoint 하한을 두라고 권고합니다.
• 통신 평면: 디스커버리(쿠버네티스는 DynamoWorkerMetadata 와 EndpointSlice, 베어메탈은 etcd), 요청(TCP 기본, NATS 선택), 이벤트(ZMQ 기본, NATS 선택).
• 바뀌거나 폐기된 것: KV Block Manager(KVBM)는 v1.5.0 에서 폐기 예정이고 v1.6.0 제거가 목표입니다(엔진의 KV 오프로딩으로 이전 권고). AIConfigurator 는 AISimulate 로 개명되었고 Go Endpoint Picker 는 Rust 판으로 대체되었습니다.

쿠버네티스. Dynamo Operator 가 CRD 를 조정합니다. 핵심은 DynamoGraphDeployment(DGD, 프런트엔드와 워커로 된 추론 그래프 한 벌)이고, DynamoComponentDeployment, DynamoGraphDeploymentRequest(DGDR, 모델·하드웨어·SLA 를 적으면 프로파일링해 DGD 를 생성), DynamoGraphDeploymentScalingAdapter(HPA/KEDA 연동), DynamoModel 이 더 있습니다. v1.5.0 에서 nvidia.com/v1beta1 이 저장 버전이 되어 spec.components 목록에 type: frontend|worker|prefill|decode 를 씁니다. 여러 노드에 걸친 워커는 Grove(기본) 또는 LeaderWorkerSet 이 없으면 Operator 가 오류를 냅니다. 다음은 문서 예시(Qwen3-32B)를 줄인 것이며 실제로 적용해 본 것이 아닙니다.

apiVersion: nvidia.com/v1beta1
kind: DynamoGraphDeployment
spec:
  components:
  - {name: Frontend, type: frontend}
  - name: VllmPrefillWorker
    type: prefill
    sharedMemorySize: 16Gi
    # args: --model Qwen/Qwen3-32B --disaggregation-mode prefill
    #       --kv-transfer-config '{"kv_connector":"NixlConnector",...}'
  - name: VllmDecodeWorker
    type: decode        # args 는 같고 --disaggregation-mode decode

5. llm-d, vLLM, SGLang 과의 위치 차이

세 프로젝트는 배타적이지 않습니다. Dynamo 1.5.0 릴리스 노트에 llm-d 배치 게이트웨이 예시가 있고, 둘 다 vLLM·SGLang 을 모델 서버로 씁니다. 어느 쪽이 더 빠른지는 확인하지 못했습니다. llm-d 의 "최대 70% 처리량"(B200, AWS)과 Dynamo 의 "TTFT 2배"(Baseten)는 조건이 다를 뿐 아니라 측정 대상이 다릅니다. 70% 는 prefill/decode 분리의 처리량(GPT-OSS, 입력과 출력 1,024토큰), 2배는 분리가 아니라 KV 인지 라우팅의 TTFT(Qwen3-Coder 480B, 입력 약 5만 토큰, 무작위 라우팅 대비)이므로 둘을 나란히 놓고 우열을 읽을 수 없습니다.

6. 분리가 이득인 곳과 손해인 곳

Dynamo 문서 기준으로 이득은 긴 프롬프트로 prefill 이 비싼 경우, 높은 동시성으로 decode 가 병목인 경우, 두 풀을 따로 확장하려는 경우, 두 단계에 다른 병렬화가 필요한 큰 모델입니다. llm-d 는 입력 대 출력이 10:1 인 긴 문맥을 권장 사례로 듭니다. 손해는 작은 모델, 짧은 프롬프트, 낮은 동시성, 빠른 KV 전송망이 없는 경우로, 통합(aggregated) 배포가 더 단순하고 흔히 더 빠릅니다. 문서는 decode KV 용량이 병목일 때 prefill 복제본을 늘리면 전체 용량이 줄 수 있다고도 경고합니다.

Dynamo 의 대응은 조건부 분리(conditional disaggregation, 실험적) 입니다. 라우터가 decode 워커의 KV 겹침을 빼고 남은 유효 입력 길이가 기본 2048 토큰 미만이고 원래 길이 대비 비율이 0.7 미만이면, prefill 워커를 거치지 않고 decode 워커가 prefill 까지 처리합니다. 다중 턴 대화처럼 접두사 재사용이 많은 경우를 겨냥하며, vLLM 의 양방향 KV 전송(prefill 이 decode 가 가진 이전 턴 KV 를 끌어옴)도 같은 문제의식입니다.

7. 직접 해 보기

RDMA 와 다중 GPU 노드가 없으면 분리 서빙을 재현할 수는 없고, 가능한 범위는 아래와 같습니다.

1. KV 크기 계산(환경 변경 없음). 모델 config.json 에서 토큰당 KV 를 계산합니다.

   python3 -c "import json,sys;c=json.load(open(sys.argv[1]));h=c.get('head_dim',c['hidden_size']//c['num_attention_heads']);print(2*c['num_hidden_layers']*c['num_key_value_heads']*h*2,'bytes/token(2바이트 가정)')" config.json
   

2. KV 불러오기 비용 측정. 2절의 실험처럼 임시 파드 하나에서 vLLM 과 LMCache 를 돌려, KV 를 CPU 메모리에서 불러오는 시간과 새로 계산하는 시간을 비교합니다. 끝나면 파드를 지웁니다. 노드 메모리를 다른 워크로드와 나눠 쓴다면 한도를 키우기 전에 여유를 확인해야 합니다.
3. TCP 로 NIXL 돌려 보기(미검증). GPU 가 한 장씩인 두 서버에서 prefill/decode 인스턴스를 띄우고 UCX_TLS 를 TCP 계열로 제한해 TTFT 가 위 표의 1GbE 줄처럼 늘어나는지 보는 실험입니다. 이 글을 쓰며 실행하지 않았고 동작도 보장하지 못합니다. GPU 가 다른 워크로드에 점유되어 있을 수 있어 실행 전 확인이 필요합니다. 외부 측정에 따르면 100Gb/s TCP 에서도 GPU 간 전송이 구현에 따라 0.55GB/s(UCX)에서 약 4.8GB/s(UCCL)까지 갈리므로, 1GbE 줄의 이론 선속도가 실제로는 더 느릴 수 있습니다(아래 「외부 근거」).
4. 노드 사이 TCP 처리량을 직접 잰 값(계산에 필요한 최소 실측). 서로 다른 세 쌍의 노드(파드 네트워크, iperf3 10초)에서 단일 스트림 894~902Mbit/s, 4개 스트림 901~912Mbit/s 로 모두 1GbE 급(약 112MB/s)이었습니다. 이 망에서 토큰당 114,688바이트인 1.7B 모델의 8,000토큰 KV(약 917MB)를 옮기면 약 8초이고, 같은 입력을 8GB급 GPU 가 다시 계산하는 데는 약 1초(21편)입니다. 즉 작은 모델과 1GbE 에서는 분리 서빙이 손해(전송이 재계산보다 8배 느림)라는 6절의 서술이 계산으로 확인됩니다. 직접 두 인스턴스를 연결한 종단 TTFT 는 재지 않았습니다(미실측).

외부 근거: 논문과 공식 자료로 확인한 것

분리 서빙은 데이터센터급 장비 없이는 재현할 수 없어서, 이 글의 수치 주장은 모두 1차 자료를 열어 조건과 함께 확인했습니다. 외부 수치는 우리 환경(작은 모델, GPU 한 장, 1GbE)과 조건이 달라 직접 비교하지 않고 방향만 판정했습니다.

벤더(NVIDIA, AWS, Baseten, llm-d) 수치는 조건이 본문에 적힌 것만 옮겼습니다. 두 llm-d README 항목의 원 블로그와 Megatron-LM 의 통신량 공식은 열지 못해 수치를 쓰지 않았습니다.

8. 면접에서 나올 만한 질문

1. 70B 모델을 GPU 8장짜리 노드 두 대에 올린다면 병렬화를 어떻게 잡습니까? 노드 안은 NVLink 가 있으므로 TP=8, 노드 사이는 통신이 적은 PP=2 로 잡습니다. 다만 PP 는 bubble 이 생기므로 모델이 한 노드에 들어간다면 노드마다 TP 복제본을 두고 DP 로 늘리는 편이 낫다고 덧붙입니다.
2. prefill/decode 분리는 왜 하고 언제 하지 않습니까? 연산 중심과 메모리 중심이라는 자원 특성 차이와 서로의 방해를 풀어 TTFT, ITL 을 따로 통제하려는 것이 동기입니다. KV 전송과 GPU 분할이 대가이므로 짧은 프롬프트, 낮은 동시성, 느린 네트워크에서는 통합이 낫습니다.
3. 8K 토큰 프롬프트의 KV 를 100GbE 로 보내면 얼마나 걸립니까? 토큰당 KV(Qwen3-32B 는 256KiB)로 약 2.1GB 이고 선속도 12.5GB/s 이면 이론상 0.17초입니다. 실제는 더 걸리므로 TTFT 목표와 비교해 RDMA 필요 여부를 정한다고 답합니다.
4. KV 인지 라우팅의 장점과 위험은 무엇입니까? 접두사를 가진 워커로 보내면 prefill 계산을 건너뛰어 TTFT 가 줄지만, 캐시가 있는 워커에 몰리면 핫스팟이 됩니다. Dynamo 는 캐시 크레딧과 활성 부하를 한 비용 식에 넣고, 효과는 random|round-robin 과 kv 를 같은 부하로 비교해 확인하라고 안내합니다.
5. Planner 는 HPA 와 무엇이 다릅니까? CPU 나 요청 수가 아니라 TTFT, ITL SLA 와 prefill/decode 별 신호(큐 깊이, KV 사용률)를 쓰고 트래픽을 예측합니다. 스케일 다운 때 진행 중 요청이 실패할 수 있어 최소 복제본 하한을 둡니다.

9. 흔한 오해

• "분리하면 항상 더 빠르다." vLLM 문서는 처리량을 높이지 않는다고 적습니다. 목적은 지연 분리와 꼬리 지연 통제입니다.
• "KV 전송에도 NCCL_IB_HCA 가 적용된다." NixlConnector 는 UCX 를 쓰므로 UCX_NET_DEVICES 를 설정합니다.
• "KVBM 이 Dynamo 의 핵심이다." v1.5.0 에서 폐기 예정입니다. README 기능 표에는 남아 있으니 릴리스 노트를 기준으로 보십시오.
• "TP 를 키울수록 빨라진다." 층마다 all-reduce 가 일어나므로 노드를 넘기면 통신이 지배합니다. Dynamo 도 새 엔진이 아니라 엔진 위의 조율 계층입니다.

참고 자료(실제로 열어 본 것)

• Dynamo v1.5.0 릴리스 노트: https://github.com/ai-dynamo/dynamo/releases/tag/v1.5.0
• Dynamo 저장소 README 와 문서(release/1.5.0 docs/fern/pages: 아키텍처, 분리 서빙, KV 인지 라우팅, 라우터 개념, 조건부 분리, 플래너, 쿠버네티스 분리 서빙·DGD·RDMA·설치, API 레퍼런스, 용어집): https://github.com/ai-dynamo/dynamo , https://docs.nvidia.com/dynamo/
• NIXL: https://github.com/ai-dynamo/nixl
• vLLM: https://docs.vllm.ai/en/latest/features/disagg_prefill/ , https://docs.vllm.ai/en/latest/features/nixl_connector_usage/ , https://docs.vllm.ai/en/latest/serving/parallelism_scaling/ , https://docs.vllm.ai/en/latest/serving/expert_parallel_deployment/
• SGLang: https://docs.sglang.ai/advanced_features/pd_disaggregation.html
• llm-d: https://github.com/llm-d/llm-d , https://llm-d.ai/docs/architecture , https://llm-d.ai/docs/well-lit-paths/foundations/pd-disaggregation
• 논문: https://arxiv.org/abs/2104.04473 , https://arxiv.org/abs/2412.19437 , https://arxiv.org/abs/2401.09670 , https://arxiv.org/abs/2311.18677
• NVLink 사양: https://www.nvidia.com/en-us/data-center/nvlink/ , Qwen3-32B config: https://huggingface.co/Qwen/Qwen3-32B/raw/main/config.json

확인한 버전과 날짜, 확인하지 못한 것

확인일은 2026-10-05 입니다. GitHub 릴리스 API 로 Dynamo v1.5.0(2026-09-21, 번들 엔진 SGLang v0.5.18, TensorRT-LLM v1.3.0rc25, vLLM v0.28.0), NIXL v1.5.0(2026-09-30), llm-d v0.10.0(2026-09-29), vLLM 최신 v0.30.0, SGLang 최신 v0.5.21 을 확인했고, 문서 사이트의 latest 도 v1.5.0 입니다.

확인하지 못한 것: (1) Dynamo 문서 일부가 아직 v1alpha1 과 kv_both 예시를 쓰는 이유. (2) llm-d·Dynamo·SGLang 사이의 성능 우열(측정 대상이 달라 비교 자체가 어렵습니다). (3) 7절 3번 실험(두 서버에서 TCP 로 NIXL 을 돌려 TTFT 를 보는 시험)은 실행하지 않았습니다. 대신 노드 사이 TCP 처리량을 재서 계산했습니다(7절). (4) 두 llm-d README 항목의 원 블로그 일부와 Megatron-LM 논문의 통신량 공식은 열지 못해 쓰지 않았습니다. 98초와 200~500ms 의 조건(이제 확인), DistServe·Splitwise 본문 수치(이제 확인)는 「외부 근거」에 있습니다.