멀티 노드 Disaggregated Inference: AMD Instinct MI300X GPU에서의 DeepSeek R1 671B

서론

자기회귀(autoregressive) LLM 추론은 두 가지 별개의 단계로 구성됩니다: 전체 입력 프롬프트를 병렬로 처리하여 KV cache를 구축하는 prefill 단계와, 캐시된 key와 value를 사용하여 출력 토큰을 하나씩 생성하는 decode 단계입니다. 이 두 단계는 매우 다른 실행 특성을 가집니다 — prefill은 한 번의 길고 연속적인 단계에서 많은 토큰을 동시에 처리하는 반면, decode는 높은 빈도로 짧은 반복을 여러 번 수행합니다 — 그러나 기존의 서빙 시스템에서는 동일한 GPU 자원을 공유하기 때문에, 상호 간섭이 발생하여 처리량과 지연 시간 모두가 저하됩니다.

Prefill-decode 분리(disaggregated serving)는 각 단계를 전용 GPU 노드 풀에 할당하여 prefill과 decode가 동일한 GPU에서 동일한 자원을 놓고 경쟁하지 않도록 합니다.DistServe(Zhong et al., OSDI 2024)에서 처음 공식화된 이 개념은 이후 광범위하게 채택되었지만, 프로덕션에서 그 잠재력을 완전히 실현하려면 커널 수준의 연산 효율성부터 클러스터 전체의 스케줄링 및 KV cache 전송에 이르기까지 고도로 최적화된 풀 스택 소프트웨어 솔루션이 필요합니다.

본 보고서에서는 MoAI Inference Framework — AMD GPU에서 고성능 disaggregated serving에 최적화된 Moreh의 프로덕션 수준 추론 프레임워크 — 를 사용하여, DeepSeek R1 671B를 실행하는 5노드 AMD Instinct MI300X 클러스터에서 prefill-decode 분리의 효과를 측정합니다. 먼저 colocated baseline 대비 disaggregated serving의 이점을 보여준 후, 두 가지 구성을 비교하여 요청 패턴에 따라 최적의 prefill 대 decode 노드 비율이 어떻게 달라지는지 살펴봅니다: 2P3D(Prefill 2대 + Decode 3대)와 1P4D(Prefill 1대 + Decode 4대).

배경: Prefill과 Decode를 왜 분리하는가?

간섭 문제

Prefill과 decode가 동일한 GPU에서 colocated되면, 여러 가지 방식으로 서로 간섭합니다:

• 지연 시간 급증. Prefill은 한 번의 단계에서 많은 토큰을 동시에 처리하며, 잠재적으로 오래 실행될 수 있습니다. 긴 컨텍스트의 prefill 요청이 도착하면 GPU를 장시간 점유하여, 동일한 디바이스를 공유하는 모든 진행 중인 decode 반복을 지연시킵니다. 이로 인해 P99 inter-token latency(ITL)가 급증하며 — 때로는 수 자릿수까지 — 사용자가 기대하는 원활한 스트리밍 경험이 깨집니다.
• 스케줄링 충돌. Prefill과 decode는 상반된 스케줄링 선호도를 가집니다: prefill은 time-to-first-token(TTFT)을 최소화하기 위해 새 요청을 빠르게 처리하려 하고, decode는 낮은 inter-token latency를 유지하기 위해 빈번하고 중단 없는 반복이 필요합니다. 단일 서빙 인스턴스는 두 가지 사이에서 지속적으로 중재해야 하며, 어떤 타협이든 최소 하나의 지표를 저하시킵니다.
• 결합된 스케일링. 운영자는 prefill 또는 decode 용량을 독립적으로 추가할 수 없습니다. 모든 새 노드가 두 단계를 모두 처리해야 하므로, 병목이 덜한 단계의 자원이 과잉 프로비저닝됩니다.

Disaggregated Serving의 작동 방식

Disaggregated serving은 클러스터를 별도의 prefill 노드와 decode 노드로 분리합니다. 각 풀은 전체 모델 가중치를 보유하지만(풀 간 모델 샤딩은 없음), 지정된 단계만 처리합니다. Prefill 노드가 입력 처리를 완료하면, 생성된 KV cache를 고대역폭 인터커넥트(예: RDMA)를 통해 decode 노드로 전송하고, decode 노드는 간섭 없이 토큰 생성을 계속합니다.

이 분리는 여러 핵심 이점을 제공합니다. 모든 노드가 동일한 GPU를 가진 동종 클러스터에서도 disaggregation은 다음을 제공합니다:

• Prefill-decode 간섭 제거. Decode 노드는 들어오는 prefill 작업에 방해받지 않고 안정적인 속도로 토큰을 생성하여, inter-token latency가 극적으로 낮아지고 더 예측 가능해집니다.
• 독립적 스케일링. 운영자는 워크로드의 입력/출력 길이 분포에 맞춰 prefill 대 decode 노드 비율을 조정할 수 있어, 과잉 프로비저닝을 방지합니다.
• 단계별 최적화. 각 풀은 상대 단계에 타협하지 않고, 해당 단계에 독립적으로 튜닝된 병렬화 전략, 스케줄링 정책, 배칭 구성을 적용할 수 있습니다.

이종(heterogeneous) 클러스터에서는 disaggregation이 추가적인 최적화 차원을 열어줍니다: prefill은 연산 바운드이고 decode는 메모리 대역폭 바운드이므로, 운영자는 연산 밀도가 높은 GPU를 prefill 풀에, 대역폭에 최적화된 GPU를 decode 풀에 할당하여 각 단계의 병목에 맞는 하드웨어 특성을 매칭할 수 있습니다. 본 보고서는 동종 AMD MI300X 클러스터에 초점을 맞추어, 하드웨어 조합 효과와 분리하여 간섭 제거, 스케일링, 단계별 최적화의 이점을 분석합니다.

실험 환경

테스트 환경

모든 실험은 5노드 GPU 클러스터에서 수행되었습니다. 각 노드는 듀얼 AMD EPYC 9474F CPU (48코어, 3.6 GHz), 2,304 GB 메인 메모리, 8대의 AMD Instinct MI300X GPU(각 192 GB HBM3e)를 탑재한 Gigabyte G593-ZX1-AAX1 서버입니다. 노드 간 연결은 InfiniBand HDR로 구성되어 있습니다.

구성

동일한 5노드 클러스터를 사용하여 세 가지 구성을 평가했습니다:

• Colocated (Baseline): 5개 노드 모두가 prefill과 decode를 모두 처리합니다. 로드 밸런싱이 요청을 노드 간에 분산합니다.
• Disaggregated 2P3D: 2개 노드는 prefill 전용, 3개 노드는 decode 전용입니다. 1P4D 대비 prefill에 더 많은 용량을 할당합니다.
• Disaggregated 1P4D: 1개 노드는 prefill 전용, 4개 노드는 decode 전용입니다. 2P3D 대비 decode에 더 많은 용량을 할당합니다.

벤치마크 시나리오

모든 벤치마크는 vllm bench serve를 사용하여 실행되었습니다. 다양한 동시성 수준에서 네 가지 ISL/OSL(Input Sequence Length / Output Sequence Length) 조합을 테스트했습니다. 이 조합들은 특정 애플리케이션을 모델링하기보다는 서빙 파이프라인의 각기 다른 부분에 부하를 주도록 설계되었습니다:

• 1K/1K: 균형 잡힌 입력 및 출력 길이
• 1K/8K: 짧은 입력, 긴 출력 (decode 중심)
• 8K/1K: 긴 입력, 짧은 출력 (prefill 중심)
• 8K/8K: 긴 입력 및 출력

각 시나리오에서 트래픽 부하는 두 가지 파라미터로 제어되었습니다: N_REQs(총 요청 수)와 REQ_RATE(요청 도착률, req/s 단위). N_REQs는 모든 시나리오에서 동시성 수준의 2배로 설정되었습니다. REQ_RATE는 짧은 출력 시나리오에서 더 높게(1K/1K의 경우 3–6 req/s, 8K/1K의 경우 2–4 req/s), 긴 출력 시나리오에서는 더 낮게(1K/8K와 8K/8K의 경우 2 req/s) 설정되었으며, 이는 긴 생성 요청이 GPU 자원을 더 오래 점유한다는 점을 반영합니다. REQ_RATE가 지정되면, N_REQs와 함께 — 명목상의 동시성 수준만으로보다 실제 트래픽 패턴을 더 정밀하게 결정합니다.

결과: Disaggregated vs. Colocated Serving

먼저 disaggregated 2P3D 구성(prefill 2대 + decode 3대)을 5개 노드 모두가 두 단계를 모두 처리하는 colocated baseline과 비교합니다. 클러스터 연산 자원의 40%를 prefill에 할당하는 2P3D는 네 가지 ISL/OSL 시나리오 전체에 걸친 주요 disaggregation 구성으로 사용됩니다.

End-to-End Latency

Disaggregated 2P3D는 모든 테스트 구성에서 중앙값 end-to-end latency의 기하 평균 1.35배 개선을 달성했습니다.

가장 큰 개선은 8K/1K(prefill 중심) 시나리오에서 나타나며, CON=160에서 최대 1.84배에 달합니다. 이는 예상된 결과입니다: 전용 prefill 노드를 사용하면 긴 입력 시퀀스가 더 이상 decode 작업을 차단하지 않으며, prefill 노드가 이를 더 효율적으로 배칭하고 처리할 수 있습니다.

총 처리량

Disaggregated 2P3D는 총 처리량(초당 토큰 수)에서 기하 평균 1.20배 개선을 달성했습니다.

Latency vs. Throughput

다음 산점도는 각 ISL/OSL 시나리오별 latency-throughput 트레이드오프를 시각화합니다. 왼쪽 위(낮은 latency, 높은 throughput)에 위치한 점이 더 좋습니다. 각 점은 서로 다른 동시성 수준을 나타냅니다.

비용 효율성 (Token/Dollar)

Disaggregated serving은 colocated baseline과 동일한 총 GPU 수를 사용하므로, 처리량 향상은 토큰당 비용 절감으로 직접 이어집니다. 2P3D 구성은 colocated baseline 대비 기하 평균 107.57%의 token/dollar 효율성을 달성하여, 운영자가 동일한 인프라 비용으로 7.57% 더 많은 토큰을 서빙할 수 있음을 의미합니다.

결과: Prefill 대 Decode 비율의 영향

Disaggregated serving이 colocated serving보다 우수하다는 것을 확인한 후, 후속 질문을 던집니다: 클러스터의 노드를 prefill과 decode 사이에 어떻게 나누어야 하는가? 이에 답하기 위해, decode 중심의 1K/8K 시나리오에서 2P3D 구성(prefill 2대 + decode 3대)과 1P4D(prefill 1대 + decode 4대)를 비교합니다. 이 시나리오에서는 prefill에서 decode로 노드를 하나 이동시키는 것의 영향이 가장 뚜렷하게 나타납니다.

End-to-End Latency: 2P3D vs. 1P4D (1K/8K)

총 처리량: 2P3D vs. 1P4D (1K/8K)

이 decode 중심 워크로드에서 1P4D는 일관되게 2P3D를 능가합니다. 추가 decode 노드가 더 많은 총 decode 용량을 제공하여, 더 낮은 end-to-end latency와 더 높은 처리량을 달성합니다 — 특히 decode가 병목이 되는 높은 동시성에서 그렇습니다. CON=480에서 1P4D는 6,082.84 TPS를, 2P3D는 5,668.40 TPS를 달성했습니다.

비용 효율성 비교

Token/dollar 효율성(기하 평균) 기준으로, 1P4D는 111.07%를, 2P3D는 107.57%를 colocated baseline 대비 달성했습니다. Decode 중심 워크로드에서는 추가 decode 노드가 더 나은 비용 효율성으로 직접 이어집니다.

요약: 어떤 비율을 선택할 것인가?

2P3D는 prefill 중심의 8K/1K 워크로드에서 기하 평균 1.80배의 latency 개선을 제공하지만, decode 중심의 1K/8K 워크로드에서는 그 이점이 1.08배로 줄어듭니다. 해당 영역에서는 1P4D가 추가 decode 노드 덕분에 1.13배 E2EL 개선과 111% token/dollar 효율성으로 앞서갑니다. 프로덕션에서 실제 워크로드는 거의 균일하지 않습니다 — 짧은 쿼리, 긴 컨텍스트 RAG, 추론 요청이 동시에 도착하며, 최적 비율은 트래픽 패턴이 변화함에 따라 하루 종일 달라질 수 있습니다.

이는 prefill/decode 비율의 수동 구성을 본질적으로 취약하게 만듭니다: 피크 시간 트래픽에 맞춰 튜닝된 비율은 비피크 시간에는 비최적일 수 있으며, 그 반대도 마찬가지입니다. 과제는 올바른 비율을 한 번 선택하는 것이 아니라, 지속적으로 적응하는 것입니다.

Latency 안정성: P99 Inter-Token Latency

Disaggregated serving의 가장 영향력 있는 이점 중 하나는 tail latency의 극적인 개선입니다. Colocated 환경에서는 긴 prefill 요청이 간헐적으로 decode 단계를 차단하여, P99 inter-token latency(ITL)가 수 초까지 급증합니다. 이는 스트리밍 애플리케이션에서 사용자 경험을 직접적으로 저하시킵니다.

Disaggregated serving에서는 prefill과 decode가 동일한 GPU 자원을 놓고 경쟁하지 않습니다. 그 결과, P99 ITL이 극적으로 감소합니다:

이는 disaggregated serving을 사용하면, 혼합 워크로드 조건에서도 사용자가 일관되고 원활한 토큰 스트리밍을 경험한다는 것을 의미합니다 — 프로덕션 채팅 및 추론 애플리케이션에서 필수적인 요구 사항입니다.

결론

Prefill-decode 분리는 대규모 MoE 모델 추론에서 colocated serving 대비 명확하고 측정 가능한 성능 향상을 제공합니다. DeepSeek R1 671B를 실행하는 5노드 AMD MI300X 클러스터에서:

• 두 disaggregated 구성 모두 모든 테스트 시나리오에서 colocated baseline을 능가하며, end-to-end latency 최대 1.84배 개선과 P99 inter-token latency 12–51배 감소를 달성했습니다.
• 2P3D(더 많은 prefill 노드)는 prefill 중심 워크로드에서 탁월하며, 8K/1K에서 기하 평균 1.80배 E2EL 개선을 달성했습니다.
• 1P4D(더 많은 decode 노드)는 decode 중심 워크로드에서 더 나은 비용 효율성을 제공하며, 1K/8K에서 111% token/dollar를 달성했습니다.

그러나 최적의 prefill 대 decode 비율은 고정적이지 않습니다 — 워크로드의 입력/출력 길이 분포와 동시성에 따라 달라지며, 이 두 요소는 프로덕션에서 시간에 따라 변합니다. 잘못된 비율을 선택하면 prefill 또는 decode 용량이 활용되지 못하여, disaggregation이 제공하는 바로 그 성능 향상이 훼손될 수 있습니다.

MoAI Inference Framework는 disaggregated serving의 구성을 자동화하여 이 문제를 해결합니다. 운영자가 고정된 prefill/decode 비율을 수동으로 선택하고 유지할 필요 없이, MoAI는 관찰된 워크로드 특성에 기반하여 할당을 동적으로 조정합니다 — expert parallelism, 라우팅 및 기타 분산 추론 최적화와 함께 — 운영자가 수동 튜닝 없이 AMD Instinct GPU 클러스터에서 disaggregation의 모든 이점을 실현할 수 있도록 합니다.