PD 분리는 처리량을 늘리지 않는다 — 프리필/디코드 분리가 실제로 사는 것

들어가며 — 한 GPU에 사는, 성격이 다른 두 개의 일
왜 한 GPU에 두면 문제인가 — 간섭
그래서 분리한다 — PD 분리의 구조
숫자를 읽는 법 — 처리량이 아니라 goodput
그 배수들을 실제로 뜯어보면
KV를 옮기는 배관 — 진짜 엔지니어링은 여기 있다
2026년 4월, MORI-IO — 구체적인 측정 하나
공짜가 아니다 — 정직한 비용
그래서, 당신은 써야 하나
마치며
참고 자료

들어가며 — 한 GPU에 사는, 성격이 다른 두 개의 일

LLM 추론이 두 단계로 나뉜다는 건 이제 상식입니다. 프롬프트 전체를 한 번의 포워드 패스로 밀어 넣어 KV 캐시를 만드는 프리필(prefill), 그리고 토큰을 하나씩 뽑는 디코드(decode). KV 캐시 이야기를 할 때마다 나오는 그 두 단계입니다.

중요한 건 이 둘의 성격이 정반대라는 점입니다. SGLang 문서의 표현을 그대로 옮기면, 프리필은 입력 시퀀스 전체를 처리하는 연산 집약적(computation-intensive) 작업이고, 디코드는 KV 캐시를 관리하는 메모리 집약적(memory-intensive) 작업입니다. 프리필은 GPU의 연산 유닛을 태우고, 디코드는 매 토큰마다 모델 가중치와 KV 캐시 전체를 다시 읽느라 메모리 대역폭에 묶입니다.

성격이 다른 두 작업을 같은 GPU에 올려놓고 같은 스케줄러로 돌리면 무슨 일이 생길까요. 그리고 쪼개면 정말 나아질까요. 이 글은 그 "쪼개기" — PD 분리(prefill/decode disaggregation) — 가 2026년에 어디까지 왔는지, 그리고 왜 인터넷에 돌아다니는 배수 숫자들을 곧이곧대로 읽으면 안 되는지에 대한 이야기입니다.

왜 한 GPU에 두면 문제인가 — 간섭

SGLang 문서는 통합 엔진에서 생기는 문제를 두 가지로 못 박습니다.

첫째, 프리필 인터럽션(Prefill Interruption). 문서의 문장 그대로는 "들어오는 프리필 배치가 진행 중인 디코드 배치를 자주 중단시켜 토큰 생성에 상당한 지연을 유발한다"입니다. 그림을 그려 보면 명확합니다. 어떤 사용자가 토큰을 한 개씩 받으며 스트리밍 중인데, 옆에서 8000토큰짜리 프롬프트가 하나 도착합니다. 그 프리필은 GPU를 한동안 통째로 점유하고, 스트리밍 중이던 사용자의 다음 토큰은 그만큼 늦게 나옵니다. 사용자 입장에서는 글자가 흐르다가 뚝 멈추는 순간입니다.

둘째, DP 어텐션 불균형(DP Attention Imbalance). 데이터 병렬 어텐션에서 한 DP 워커는 프리필 배치를, 다른 워커는 디코드 배치를 동시에 처리하게 되면 디코드 지연이 늘어납니다.

TensorRT-LLM의 기술 블로그도 같은 진단을 내립니다 — 통합 서빙에서는 "컨텍스트 처리가 토큰 생성을 지연시키는 간섭"이 생기고, 그래서 상호작용성이 떨어진다는 것입니다. 그리고 이 블로그는 문제의 본질을 한 문장으로 정리합니다. "TTFT 같은 한 지표를 최적화하면 TPOT 같은 다른 지표를 희생하게 되는 일이 잦다."

이게 핵심입니다. 한 GPU 위에서 프리필과 디코드는 같은 자원을 두고 경쟁하는 두 개의 상충하는 목표입니다. 배치를 키우면 처리량은 오르지만 꼬리 지연이 무너지고, 프리필을 잘게 쪼개면(청크드 프리필) 간섭은 줄지만 프리필 효율이 떨어집니다. 하나의 스케줄러로 두 목표를 동시에 만족시키려는 시도 자체가 구조적으로 타협입니다.

그래서 분리한다 — PD 분리의 구조

발상은 단순합니다. 성격이 다르니 하드웨어를 따로 주자.

vLLM 문서의 정의로는, 분리 프리필은 프리필과 디코드 단계를 서로 다른 vLLM 인스턴스에서 돌리고, 그 사이에서 KV 캐시를 커넥터로 옮기는 것입니다. 실제 배치는 대략 이렇게 생겼습니다.

                     [ 프록시 / 라우터 ]
                        |          |
              요청 ---->|          |
                        v          v
              [ 프리필 인스턴스 ]  [ 디코드 인스턴스 ]
               GPU 0-3              GPU 4-7
               프롬프트 -> KV       KV -> 토큰 스트림
                        |          ^
                        |  KV 캐시  |
                        +--- RDMA --+
                          (커넥터)

세 조각이 필요합니다.

프리필 인스턴스 — 프롬프트를 받아 KV 캐시를 만든다.
디코드 인스턴스 — 그 KV 캐시를 받아 토큰을 뽑는다.
커넥터와 프록시 — KV 캐시를 실어 나르고, 요청을 어느 쪽으로 보낼지 조율한다.

이제 각 단계에 병렬화 전략을 따로 걸 수 있습니다. 프리필에는 TP를 낮게, 디코드에는 높게 — 혹은 그 반대로. vLLM 문서가 이 기능의 이점으로 첫 번째로 꼽는 게 정확히 이것입니다. "TTFT와 ITL을 따로 튜닝하기." 그리고 두 번째는 "꼬리 ITL 통제하기"입니다. 프리필 잡이 디코드를 방해할 수 없으니, 디코드 GPU 위에서 토큰은 일정한 리듬으로 나옵니다.

vLLM에서 이 기능은 아직 experimental로 표시돼 있습니다. 문서의 문장 그대로 "이 기능은 실험적이며 변경될 수 있습니다."

숫자를 읽는 법 — 처리량이 아니라 goodput

여기가 이 글의 핵심입니다.

PD 분리를 검색하면 "2배", "7배" 같은 숫자가 쏟아집니다. 그런데 정작 vLLM 공식 문서에는 이런 문장이 대문자로 박혀 있습니다.

"Disaggregated prefill DOES NOT improve throughput." (분리 프리필은 처리량을 개선하지 않습니다.)

모순처럼 보입니다. 하지만 둘 다 맞습니다. 이유를 알면 PD 분리를 보는 눈이 완전히 바뀝니다.

생각해 보면 당연합니다. PD 분리는 GPU를 더 만들어 주지 않습니다. 8장의 GPU를 4장은 프리필, 4장은 디코드로 나눴다고 해서 총 연산량이 늘어날 리 없습니다. 오히려 KV 캐시를 네트워크로 옮기는 일이 새로 생겼으니, 순수한 총 작업량으로 따지면 늘어납니다. TensorRT-LLM 블로그도 이걸 인정합니다 — "분리는 KV 캐시 블록을 전송하는 오버헤드를 수반한다."

그러면 그 배수들은 뭘 잰 걸까요. 답은 goodput입니다.

이 개념의 출처는 PD 분리의 원조 논문인 DistServe(Zhong 등, OSDI 2024)입니다. 제목부터가 "Goodput-optimized"입니다. goodput은 대략 이렇게 정의됩니다 — TTFT와 TPOT 제약을 둘 다 만족시키면서 감당할 수 있는 최대 요청률. 그냥 처리량이 "초당 몇 개를 뱉었나"라면, goodput은 "초당 몇 개를 약속한 품질로 뱉었나"입니다.

이 차이가 얼마나 큰지는 vLLM에 들어온 MORI-IO 커넥터 블로그가 명확히 보여 줍니다. 그 블로그의 goodput 정의는 이렇습니다.

"Goodput = maximum request rate (req/s) such that requests satisfy both TTFT < T_ttft and ITL < T_itl."

즉 SLO를 못 지킨 요청은 세지 않습니다. 처리량 계산에서는 3초 걸린 TTFT도 한 건이지만, goodput 계산에서는 0건입니다. 사용자가 이미 탭을 닫았을 테니까요.

그래서 정리하면 이렇습니다.

처리량(순수 tokens/s, 지연 무시): PD 분리는 개선하지 않는다. 오히려 전송 오버헤드로 약간 손해다. — vLLM 문서가 말하는 게 이것.
goodput(SLO를 지킨 처리량): PD 분리가 크게 개선한다. — 벤더 블로그들이 재는 게 이것.

같은 시스템, 다른 자. 인터넷의 배수를 볼 때 어느 자로 쟀는지를 먼저 확인해야 하는 이유입니다.

그 배수들을 실제로 뜯어보면

이 렌즈로 공개된 숫자들을 다시 읽어 봅시다. 아래는 전부 벤더/저자 자체 측정이며, 각 측정의 조건을 함께 적습니다. 조건이 곧 숫자의 의미입니다.

DistServe (Zhong 등, OSDI 2024, 저자 자체 측정). 논문의 헤드라인은 "7.4배 더 많은 요청" 또는 "12.6배 더 빡빡한 SLO"입니다. 그런데 바로 뒤에 조건이 붙습니다 — "요청의 90퍼센트 초과에 대해 지연 제약 안에 머물면서". 이건 처리량 배수가 아니라 SLO 달성률을 고정한 상태의 요청률 배수입니다. 그리고 배수는 모델·애플리케이션·지연 요구사항에 따라 달라진다고 논문 스스로 말합니다.

TensorRT-LLM (NVIDIA 자체 측정, GB200). 여기 숫자가 특히 교훈적입니다. DeepSeek R1에서 입력 4400 / 출력 1200 조건일 때 MTP 없이 1.4~~1.8배, MTP를 켜면 1.6~~2.5배. 입력 8192 / 출력 256에서는 4-GPU 최대 1.73배, 8-GPU 2배. 그리고 결정적인 항목 — 입력 4096 / 출력 1024에서 "사용자당 초당 50토큰 지점에서 1.7배 개선". 마지막 문장을 다시 읽어 보십시오. 사용자당 초당 50토큰이라는 지연 목표를 고정한 상태에서의 처리량 배수입니다. 지연 제약을 풀면 이 배수는 그대로 있지 않습니다. Qwen 3에서는 입력 8192 / 출력 1024 조건에 1.7~6.11배라는 넓은 범위가 보고됐는데, 범위가 이렇게 넓다는 것 자체가 "조건이 전부"라는 증거입니다.

그리고 NVIDIA는 정직한 각주를 하나 답니다. 이론적 "rate-matched" 분석과 실제 종단 벤치마크 사이에 0~25퍼센트의 격차가 있고, 그 원인은 "이상화된 가정"과 "KV 캐시 전송 오버헤드"라는 것입니다. 이론 배수를 그대로 믿지 말라는 이야기를 벤더가 직접 하고 있는 셈입니다.

llm-d on AWS (AWS 자체 측정, 2026년 3월 16일). GPT-OSS 모델, ml.p6-b200.48xlarge 인스턴스, 프리필 파드 4개(TP1)와 디코드 파드 1개(TP4), 입출력 각 1024토큰, 동시성 최대 128. 결과는 "동시성이 올라갈수록 표준 vLLM 배포 대비 초당 토큰 수가 최대 70퍼센트까지 증가". 여기서도 "동시성이 올라갈수록"이라는 조건이 붙어 있습니다 — 부하가 낮으면 이득이 없다는 뜻입니다. 그리고 AWS 저자들은 이렇게 덧붙입니다. "하지만 모든 워크로드를 위한 것은 아닙니다. 더 큰 모델, 더 긴 입력 시퀀스, 희소 MoE 아키텍처에서 시도해 보십시오."

패턴이 보이시나요. 모든 숫자에 지연 목표 또는 부하 조건이 고정돼 있습니다. 이건 우연이 아닙니다. 그게 PD 분리가 파는 상품이기 때문입니다.

KV를 옮기는 배관 — 진짜 엔지니어링은 여기 있다

PD 분리의 아이디어는 한 문단이면 설명됩니다. 어려운 건 배관입니다. 프리필 GPU가 만든 KV 캐시를 디코드 GPU로 옮겨야 하는데, 이게 작지 않습니다. 그리고 이 전송이 TTFT에 그대로 얹힙니다.

그래서 2026년의 실제 경쟁은 전송 계층에서 벌어집니다.

NIXL(NVIDIA Inference Xfer Library)이 현재 가장 널리 쓰이는 축입니다. 저장소의 설명 그대로는 "NVIDIA Dynamo 같은 AI 추론 프레임워크의 점대점 통신을 가속하기 위한 것이며, 모듈식 플러그인 아키텍처를 통해 다양한 메모리(CPU·GPU)와 스토리지(파일·블록·오브젝트 스토어)에 대한 추상화를 제공"합니다. Apache 2.0이고, 백엔드 플러그인이 UCX, POSIX, OBJ, AZURE_BLOB, HF3FS, MOONCAKE, GUSLI, UCCL, GDS, GPUNETIO, LIBFABRIC 등으로 붙습니다. 요컨대 KV 캐시를 InfiniBand로도, NVMe로도, S3로도 옮길 수 있게 한 추상화 계층입니다.

Mooncake는 SGLang의 기본 전송 엔진이고, SGLang은 Mooncake·NIXL·ASCEND 세 백엔드를 지원합니다. Mooncake 경로는 --disaggregation-ib-device로 InfiniBand 장치를 지정해야 합니다.

vLLM 쪽 커넥터 목록은 지금 이렇습니다 — NixlConnector, LMCacheConnectorV1, MooncakeConnector, MoRIIOConnector(ROCm 전용), MultiConnector, OffloadingConnector, FlexKVConnectorV1, 그리고 예제용 ExampleConnector. 내부 추상화는 세 조각입니다 — 커넥터(생산자·소비자 간 KV 검색), LookupBuffer(insert는 논블로킹, drop_select는 블로킹), Pipe(단방향 FIFO).

여기서 배관이 요구사항으로 되돌아온다는 점을 놓치면 안 됩니다. RDMA 패브릭이 사실상 전제입니다. AWS가 llm-d를 굴리며 EFA와 libfabric 플러그인을 함께 이야기하는 이유가 이것이고, SGLang이 InfiniBand 장치 지정을 요구하는 이유도 같습니다. 평범한 이더넷 위에서 이 설계를 얹으면, 아껴 놓은 ITL을 전송 지연으로 도로 토해 냅니다.

2026년 4월, MORI-IO — 구체적인 측정 하나

추상적인 이야기를 구체적인 측정 하나로 내려 봅시다. 2026년 4월 7일 vLLM 블로그에 MORI-IO 커넥터 글이 올라왔습니다. AMD와 Embedded LLM 팀이 쓴 글이고, 측정은 2026년 3월 12일에 수행됐습니다. AMD 자체 측정이라는 점을 먼저 밝혀 둡니다.

MORI-IO는 MORI(Modular RDMA Interface) 프레임워크 위에 올린 RDMA 기반 KV 캐시 커넥터로, vLLM에 기여됐습니다. AMD GPU(ROCm) 진영에서 NIXL에 해당하는 자리를 채우는 물건이라고 보면 됩니다.

측정 조건은 이렇습니다.

하드웨어: AMD Instinct MI300X 8장(각 192GB), AMD EPYC 9654 96코어 2소켓
소프트웨어: Ubuntu 22.04 LTS, ROCm 7.0.51831, vLLM 0.16.0rc1.dev1
모델: Qwen/Qwen3-235B-A22B-FP8
워크로드: 입력 2000토큰, 출력 1000토큰, 총 100개 요청, 요청률 0.5~10 req/s
SLO: TTFT 1초 미만, ITL 토큰당 50ms 미만
구성: 프리필 GPU 0-3, 디코드 GPU 4-7, 그리고 프록시 서버

요청률 8 req/s 지점에서 보고된 결과입니다.

구성	SLO 만족 요청	상대 goodput
표준 (1× TP8)	26/100	0.9배
표준 (2× TP4)	30/100	1배 (기준)
MORI-IO Read (1P+1D)	70/100	2.4배
MORI-IO Write (1P+1D)	73/100	2.5배

이 표에서 제일 중요한 건 배수가 아니라 왜 실패했는지입니다. 블로그의 문장을 그대로 옮깁니다.

"두 분리 모드 모두 ITL 위반을 완전히 제거한다. 남은 실패는 요청률이 오르면서 발생하는 TTFT 초과다."

이게 PD 분리의 정체를 한 문장으로 요약합니다. ITL 위반이 0이 됐습니다. 디코드 GPU 위에는 프리필이 끼어들 수 없으니 당연합니다. 그런데 실패가 사라진 게 아니라 TTFT 쪽으로 옮겨 갔습니다. 병목을 없앤 게 아니라 이동시킨 것이고, 그 거래가 남는 장사였을 뿐입니다.

Read 모드와 Write 모드의 차이도 같은 이야기의 연장입니다.

Read 모드: 디코드가 프리필에서 KV를 RDMA로 당겨 온다. 블로그의 설명으로는 "TTFT가 최소 한 번의 완전한 프리필 포워드 패스(프록시 직렬화)에 RDMA 전송 시간을 더한 만큼 증가"한다.
Write 모드: 프리필이 연산 중에 KV를 디코드로 밀어 넣는다. "TTFT는 RDMA 전송 시간만큼만 증가하는데, 이 전송이 프리필 연산과 겹치므로 순 페널티가 더 작다."

그래서 Write가 73, Read가 70입니다. 블로그의 설명대로 "동시 프록시 디스패치가 TTFT를 낮추기" 때문입니다. 3점 차이의 정체가 결국 TTFT 페널티의 크기라는 뜻입니다.

그리고 각주 하나가 조용히 붙어 있습니다. "MORI-IO 커넥터가 요구하는 대로 프리픽스 캐싱 비활성화." 두 분리 구성 모두에서 그렇습니다. 이건 작은 각주가 아닙니다 — 다음 절에서 다루겠습니다.

공짜가 아니다 — 정직한 비용

이제 청구서입니다.

TTFT가 나빠진다. 앞에서 본 그대로입니다. KV 캐시가 네트워크를 건너는 시간이 TTFT에 얹히고, Read 모드에서는 프록시 직렬화까지 더해집니다. MORI-IO 측정에서 SLO를 못 지킨 27~30개 요청이 전부 TTFT 초과였다는 사실을 기억하십시오. PD 분리는 ITL 문제를 TTFT 문제로 바꾸는 거래입니다. 당신의 병목이 TTFT라면 이 거래는 손해입니다.

프리픽스 캐싱과 충돌할 수 있다. MORI-IO 측정에서 프리픽스 캐싱은 커넥터 요구사항으로 꺼져 있었습니다. 이게 왜 아픈가 하면 — 프리픽스 캐싱은 긴 시스템 프롬프트나 멀티턴 대화에서 프리필 비용을 통째로 날려 주는, 대부분의 실무 워크로드에서 가장 큰 단일 최적화이기 때문입니다. 긴 공통 프리픽스를 공유하는 챗봇 트래픽이라면, 프리픽스 캐싱을 끄고 얻은 2.5배 goodput이 프리픽스 캐싱을 켠 통합 서빙보다 나은지는 전혀 자명하지 않습니다. 이건 반드시 당신의 트래픽으로 직접 재야 하는 항목입니다. (커넥터와 버전에 따라 상황이 다르므로, 쓰려는 조합의 현재 제약을 확인하십시오.)

RDMA 패브릭이 필요하다. InfiniBand나 RoCE, AWS라면 EFA. 이건 하드웨어 조달과 네트워크 설계의 문제이지 플래그 하나 켜는 문제가 아닙니다.

GPU가 여러 장 필요하다. 최소 프리필 1 + 디코드 1이고, 실전 구성은 그보다 큽니다 — MORI-IO 측정은 8장을 4:4로 갈랐고, AWS 사례는 프리필 파드 4개와 디코드 파드 1개였습니다. GPU 두어 장으로 굴리는 서비스에서 논의할 주제가 아닙니다.

운영 복잡도가 늘어난다. 인스턴스 하나가 인스턴스 두 종류 + 프록시/라우터 + 전송 계층이 됩니다. 프리필과 디코드의 비율을 워크로드에 맞춰 튜닝해야 하고(AWS 글이 지적하는 그 항목입니다), 장애 모드도 그만큼 늘어납니다. 프로파일링조차 번거로워집니다 — SGLang 문서는 프리필 워커와 디코드 워커를 따로 프로파일해야 한다고 적어 두었습니다.

모델 아키텍처를 탄다. SGLang의 스테이징 버퍼 최적화는 비-MLA 모델(GQA·MHA)용이고, 문서는 "MLA 모델(DeepSeek-V2/V3 등)은 이 플래그를 켜면 안 된다"고 명시합니다. TensorRT-LLM은 이 접근이 "긴 입력 시퀀스와 중간 길이 출력" 워크로드에 가장 유리하다고 말합니다. 짧은 프롬프트에 긴 출력이라면 프리필이 애초에 병목이 아니니 나눌 이유도 적습니다.

아직 experimental이다. 적어도 vLLM에서는 그렇습니다.

그래서, 당신은 써야 하나

판단 기준은 의외로 선명합니다. MORI-IO 블로그가 직접 답을 줍니다.

"프로덕션 부하에서 ITL p99이 SLO를 초과한다면: 분리하십시오 — 이것이 주된 사용 사례입니다."

"낮은 요청률에 짧은 프롬프트: 표준 서빙으로 충분합니다."

여기에 지금까지의 재료를 얹어 정리하면 이렇습니다.

써서 값을 하는 경우

꼬리 ITL이 실제 SLO 위반의 원인이다. 스트리밍이 끊긴다는 불만이 있고, p99 ITL을 재 보니 프리필 간섭이 범인이다.
긴 입력 + 중간 길이 출력 워크로드다. (TensorRT-LLM이 명시한 조건)
부하가 실제로 높다. AWS 측정의 이득이 "동시성이 올라갈수록" 나타났다는 걸 기억하십시오.
RDMA 패브릭과 GPU 여유가 이미 있다.
큰 모델, 특히 희소 MoE. (AWS가 권한 조건)

과잉이거나 손해인 경우

병목이 TTFT다. 분리는 TTFT를 더 나쁘게 만듭니다.
프리픽스 캐싱이 당신의 주력 최적화다. 긴 공통 시스템 프롬프트를 공유하는 챗봇이라면 특히.
부하가 낮거나 프롬프트가 짧다.
GPU가 몇 장 없거나 RDMA가 없다.
그냥 처리량이 아쉬운 것뿐이다. — 이 경우엔 분리가 답이 아닙니다. vLLM 문서가 대문자로 말해 준 그대로입니다.

마지막 항목이 제일 흔한 오해입니다. "GPU 비용을 줄이고 싶다"는 동기로 PD 분리를 검토하러 왔다면, 방향이 틀렸습니다. 그건 양자화나 배치 튜닝이 푸는 문제입니다. PD 분리가 파는 건 예측 가능성이지 용량이 아닙니다.

마치며

정리하면 이렇습니다. 프리필은 연산 집약적이고 디코드는 메모리 집약적인데, 한 GPU에 같이 두면 프리필이 디코드를 끊어 먹습니다. PD 분리는 둘을 다른 GPU로 갈라 그 간섭을 원천 제거하고, 각 단계의 병렬화를 따로 튜닝하게 해 줍니다. MORI-IO 측정에서 ITL 위반이 완전히 사라진 게 그 증거입니다.

대신 KV 캐시를 네트워크로 옮겨야 하고, 그 시간이 TTFT에 얹히고, RDMA 패브릭과 여러 장의 GPU와 늘어난 운영 복잡도를 요구하고, 프리픽스 캐싱 같은 기존 최적화와 부딪힐 수 있습니다. 그리고 순수 처리량은 — vLLM 문서의 표현대로 — 늘어나지 않습니다.

그래서 PD 분리는 "더 빠른 서빙"이 아니라 "약속을 지키는 서빙"입니다. 같은 GPU로 더 많이 뱉는 기술이 아니라, 뱉는 것들이 SLO 안에 들어오게 만드는 기술입니다. 이 구분을 흐리는 순간 인터넷의 배수 숫자에 속게 됩니다 — 그 숫자들은 전부 지연 목표를 고정한 채 잰 goodput이니까요.

그러니 순서는 이렇습니다. 먼저 p99 ITL을 재십시오. 그게 SLO를 넘고 있고 범인이 프리필 간섭이라면, 그때 분리를 꺼내십시오. 재 보지도 않고 분리부터 하는 건, 있지도 않은 병을 아주 비싼 약으로 치료하는 일입니다.

참고 자료

Disaggregated Prefilling (experimental) — vLLM 공식 문서 — 커넥터 목록과 "처리량을 개선하지 않는다"는 문장의 출처
Next-Level Inference: Why Your Single-Node vLLM Setup Needs Prefill-Decode Disaggregation — vLLM 블로그, 2026-04-07 — AMD·Embedded LLM의 MORI-IO 커넥터와 MI300X 측정(벤더 자체 측정)
DistServe: Disaggregating Prefill and Decoding for Goodput-optimized LLM Serving (Zhong 등, OSDI 2024, arXiv 2401.09670) — goodput 개념의 출처
Disaggregated Serving in TensorRT-LLM — NVIDIA 기술 블로그 — GB200 측정과 rate-matching 격차(벤더 자체 측정)
Introducing Disaggregated Inference on AWS powered by llm-d — AWS, 2026-03-16 — EFA·NIXL 기반 llm-d 측정(벤더 자체 측정)
PD Disaggregation — SGLang 공식 문서 — 프리필 인터럽션·DP 어텐션 불균형, 전송 엔진과 MLA 제약
ai-dynamo/nixl — NVIDIA Inference Xfer Library — 전송 계층 추상화와 백엔드 플러그인
KV 캐시를 4비트로 — SAW-INT4와 시스템을 아는 INT4 양자화(관련 글)