‹ Back to Blog

Technical Report

크로스 벤더 Disaggregated Inference: NVIDIA H100과 AMD MI300X를 활용한 GPT-OSS 120B

March 18, 2026

이 문서는 AI를 통해 자동 번역되었습니다. 어색하거나 부정확한 내용이 있을 수 있으니, 필요한 경우 영어 원문을 참고해 주세요. 영어 원문 보기

Full technical report in PDF

단일 GPU 만능 시대의 종말

AI 데이터센터는 전통적으로 단일 GPU 모델을 중심으로 구축되어 왔습니다 — 예산이 허용하는 한 최신 NVIDIA GPU를 최대한 많이 구매하고, 동일하게 배포한 뒤, 로드 밸런서가 요청을 균등하게 분배하는 방식입니다. 이 접근 방식은 단순하지만, 대규모 AI 추론의 경제적 현실과 점점 더 괴리가 커지고 있습니다. 단일 accelerator 아키텍처가 모든 워크로드에 최적일 수는 없으며, 한 가지 유형만 배포하면 일부 하드웨어는 항상 과잉 프로비저닝되거나 활용도가 떨어지게 됩니다.

업계는 서로 다른 accelerator 유형을 결합하여 각각의 하드웨어를 가장 적합한 워크로드에 할당하는 이기종 시스템 방향으로 이동하고 있습니다. NVIDIA는 GTC 2026에서 이러한 방향을 명확히 제시하며, Vera Rubin GPU와 NVIDIA Groq 3 LPX — 256개의 LPU accelerator로 구성된 랙(칩당 500 MB SRAM, accelerator당 150 TB/s 대역폭) — 를 조합하여 공동으로 추론을 수행하는 시스템을 발표했습니다. NVIDIA는 기존의 추론 아키텍처가 상호작용성과 처리량 사이에서 선택을 강요했으며 — “세 가지를 모두 가질 수는 없었다”(상호작용성, 지능, 처리량)고 밝혔습니다. LPX는 GPU의 연산 밀도와 LPU의 초고속 SRAM 접근을 단일 시스템에 결합하여 이 문제를 해결하며, 조(trillion) 단위 파라미터 모델에 대해 메가와트당 최대 35× 높은 처리량을 달성한다고 주장합니다.

Figure 1. NVIDIA Groq 3 LPX rack containing 256 LPU accelerators, designed to work alongside Rubin GPU racks for heterogeneous inference.
Figure 1. NVIDIA Groq 3 LPX rack (256 LPU accelerators). In a Vera Rubin system, this rack works alongside a Rubin GPU rack — GPUs and LPUs jointly perform inference, each contributing its architectural strength. (Source: NVIDIA)

동일한 논리는 단일 벤더의 제품 라인을 넘어서도 적용됩니다. 실제 데이터센터에서는 이미 GPU 세대(B300과 H200 혼용), GPU 벤더(NVIDIA와 AMD), 그리고 완전히 다른 accelerator 클래스(GPU와 Tenstorrent 프로세서 같은 AI accelerator)를 혼합하여 사용하고 있습니다. 각 조합은 워크로드에 따라 서로 다른 효율 최적점을 열어줍니다.

Prefill-Decode 분리

이기종 accelerator를 활용하는 다양한 기법 중 가장 대표적인 것이 prefill-decode 분리(PD disaggregation)입니다. LLM 추론은 연산 특성이 근본적으로 다른 두 단계로 구성됩니다. Prefill 단계는 전체 입력 프롬프트를 밀집 행렬 곱셈을 통해 병렬로 처리하며 compute-bound입니다. Decode 단계는 자기회귀 방식으로 출력 토큰을 하나씩 생성하며, 각 단계에서 모델 파라미터와 KV cache를 GPU 메모리에서 읽어오므로 memory-bandwidth-bound입니다. 이 두 단계는 근본적으로 다른 하드웨어 요구사항을 가지고 있습니다.

Figure 2. Traditional serving vs. disaggregated serving: in traditional serving, prefill and decode share the same GPUs; in disaggregated serving, they run on dedicated GPU groups.
Figure 2. Traditional serving (left) vs. disaggregated serving (right). Separating compute-bound prefill from memory-bound decode onto dedicated GPUs eliminates interference between the two phases. (Source: NVIDIA)

PD 분리는 이러한 단계를 전용 서버 노드에 분리하여, 각 GPU를 하드웨어 특성에 가장 적합한 역할에 할당합니다. Prefill 노드는 입력 프롬프트를 높은 처리량으로 처리하고, 생성된 KV cache를 고속 저지연 네트워크를 통해 decode 노드로 전송합니다. Decode 노드는 토큰 생성만을 담당하며, 낮고 예측 가능한 토큰 간 지연 시간을 유지합니다. 이러한 분리 없이 클러스터에서 서로 다른 GPU를 혼합하면 이점이 제한적입니다 — 각 노드가 여전히 두 단계를 모두 실행하므로, 약한 단계가 병목이 됩니다.

크로스 벤더 분리의 도전 과제

단일 벤더 생태계 내에서의 PD 분리는 이미 vLLM, SGLang, NVIDIA Dynamo와 같은 프레임워크에서 지원됩니다. 그러나 이를 벤더 경계를 넘어 확장하는 것 — 예를 들어 NVIDIA GPU에서 prefill을 실행하고 AMD GPU에서 decode를 실행하는 것 — 은 기존의 어떤 오픈소스 프레임워크도 해결하지 못한 고유한 엔지니어링 과제를 야기합니다.

가장 근본적인 장벽은 통합된 크로스 벤더 통신 계층의 부재입니다. NVIDIA GPU는 NCCL을, AMD GPU는 RCCL을 사용하며, 이 라이브러리들은 상호 운용되지 않습니다. 서로 다른 벤더의 prefill 노드와 decode 노드 간 KV cache 전송은 GPU 간 직접 메모리 접근을 위한 GPUDirect RDMA를 사용할 수 없으며, 대신 데이터를 호스트 CPU 메모리를 경유하여 전달해야 하므로 임계 경로에 지연이 추가됩니다. 또한 두 벤더 생태계는 완전히 다른 소프트웨어 스택(CUDA vs. ROCm)을 사용하므로, 별도의 커널 구현, 별도의 모델 컴파일, 그리고 아키텍처 간 호환성을 보장하기 위한 KV cache 메모리 포맷의 세심한 관리가 필요합니다. 마지막으로, 서로 다른 GPU 아키텍처는 연산 대 대역폭 비율이 다르기 때문에, 프레임워크가 각 아키텍처의 성능 특성을 이해하여 클러스터 전체에서 prefill과 decode 워크로드를 최적으로 분배해야 합니다.

MoAI 추론 프레임워크: 크로스 벤더 분리

MoAI 추론 프레임워크는 크로스 벤더 PD 분리를 지원하는 유일한 프로덕션급 추론 프레임워크로 — 단일 서빙 클러스터 내에서 서로 다른 벤더의 GPU로 prefill과 decode를 라우팅합니다. NVIDIA Dynamo, vLLM, SGLang은 각각의 플랫폼에서 PD 분리를 지원하지만, 이 기능을 벤더 경계를 넘어 확장하지는 못합니다.

MoAI는 소프트웨어 스택과 아키텍처별 성능 특성의 차이를 처리하는 벤더 중립 추상화 계층과, 서로 다른 벤더의 GPU 간 RDMA 기반 KV cache 전송을 가능하게 하는 통신 라이브러리를 통해 크로스 벤더 과제를 해결합니다. 데이터센터 운영자는 단일 벤더 종속에서 벗어나, 하드웨어 예산을 여러 공급업체에 분배하고, 각 벤더의 GPU를 최상의 성능을 발휘하는 워크로드 단계에 할당할 수 있습니다.

본 보고서에서는 하나의 특정 크로스 벤더 조합을 벤치마크합니다: prefill에 NVIDIA H100, decode에 AMD Instinct MI300X를 사용하여 GPT-OSS-120B 모델을 서빙합니다. 네 가지 ISL/OSL 시나리오에서 크로스 벤더 구성은 단일 벤더 MI300X 클러스터 대비 기하평균 기준 8–9% 더 나은 종단간 지연 시간 및 처리량을 달성하며, 가장 부하가 높은 워크로드에서는 지연 시간 최대 43%, 처리량 최대 67%의 개선을 보여줍니다.

시스템 아키텍처

NVIDIA H100과 AMD Instinct MI300X는 근본적으로 다른 하드웨어 프로파일을 가지고 있어, 추론의 서로 다른 단계에 적합합니다.

NVIDIA H100 SXMAMD Instinct MI300XMI300X / H100
HBM Capacity80 GB (HBM3)192 GB (HBM3)2.4×
Memory Bandwidth3.35 TB/s5.3 TB/s1.58×
FP8 TFLOPS1,9792,6151.32×
L1 + Scratchpad256 KB per SM32 KB L1D + 64 KB LDS per CU0.38×

MI300X는 H100 대비 2.4×의 HBM 용량과 1.58×의 메모리 대역폭을 제공하여, memory-bandwidth-bound인 decode 단계에서 구조적 이점을 가집니다. 반대로, prefill 단계는 대규모 GEMM이 지배적이며, H100의 더 큰 L1 및 scratchpad 메모리(SM당 256 KB vs. CU당 96 KB)가 낮은 피크 TFLOPS에도 불구하고 더 높은 연산 활용률을 유지할 수 있게 합니다. 이러한 특성을 바탕으로 H100을 prefill에, MI300X를 decode에 할당합니다.

두 가지 구성을 테스트했으며, 각각 하나의 전용 prefill 노드와 하나의 전용 decode 노드로 구성됩니다:

  • 크로스 벤더(이기종): prefill에 H100 노드, decode에 MI300X 노드. Moreh는 RDMA를 통해 KV cache를 전송하는 커스텀 크로스 벤더 통신 계층을 구현했습니다. 현재 구현은 호스트 메모리를 경유하여 데이터를 전달하며, 향후 릴리스에서 벤더 경계를 넘어 GPU 간 직접 전송을 가능하게 하는 GPUDirect RDMA 지원이 추가될 예정입니다.
  • 단일 벤더(동종): prefill에 MI300X 노드, decode에 MI300X 노드. KV cache 전송은 GPUDirect RDMA가 활성화된 NIXL 커넥터를 사용하여, CPU 스테이징 없이 NIC를 통한 GPU 간 직접 메모리 전송이 가능합니다.

백엔드 추론 엔진은 AMD MI300X 노드에서 Moreh vLLM, NVIDIA H100 노드에서 vLLM입니다. 크로스 벤더 구성이 하드웨어 가속 GPUDirect RDMA가 아닌 호스트 스테이징 전송 경로를 사용함에도 불구하고, 연산-통신 오버래핑 기법이 특히 고부하 워크로드에서 전송 지연을 효과적으로 숨깁니다.

실험 설정

세 개의 독립 서버 노드를 사용했습니다: 8× H100 80 GB SXM GPU를 탑재한 NVIDIA H100 노드 1대(prefill용), 그리고 각각 8× MI300X 192 GB OAM GPU를 탑재한 AMD MI300X 노드 2대(하나는 decode용, 하나는 단일 벤더 테스트의 prefill용). 모든 노드는 200 Gbps ConnectX-6 NIC로 연결되었습니다.

CategoryH100 NodeMI300X Node
CPU2× AMD EPYC 9654 (96-core, 2.4 GHz)2× AMD EPYC 9474F (48-core, 3.6 GHz)
Memory1,536 GB2,304 GB
GPU8× NVIDIA H100 80 GB SXM8× AMD Instinct MI300X 192 GB OAM
NICConnectX-6 (200 Gbps)ConnectX-6 (200 Gbps)
OSUbuntu 22.04.3 LTSUbuntu 22.04.4 LTS
ModelGPT-OSS-120BGPT-OSS-120B
PrecisionMXFP4MXFP4
ParallelismTensor Parallelism (TP=8)Tensor Parallelism (TP=8)
Backend EnginevLLM 0.15.0Moreh vLLM

대상 모델은 OpenAI의 GPT-OSS-120B로, 총 약 1,168억 개의 파라미터와 토큰당 약 51억 개의 활성 파라미터를 가진 희소 Mixture-of-Experts (MoE) 모델입니다. MXFP4 양자화와 tensor parallelism TP=8로 추론을 실행했으므로, 각 노드의 8개 GPU가 하나의 모델 파이프라인을 형성합니다. 각 하드웨어 구성의 순수 연산 효율을 분리하기 위해 prefix caching은 비활성화했습니다.

네 가지 ISL/OSL(입력 시퀀스 길이 / 출력 시퀀스 길이) 시나리오를 테스트했습니다: 1K/1K, 1K/8K, 8K/1K, 8K/8K. 동시 처리 수준은 대부분의 시나리오에서 1에서 32까지, 8K/1K 시나리오는 고부하 동작을 관찰하기 위해 256까지 확장했습니다. 요청 속도는 모든 실험에서 REQ_RATE=8로 고정했습니다. 메모리 할당, GPU 커널 초기화, KV cache 커넥터 핸드셰이크로 인한 콜드 스타트 영향을 제거하기 위해 각 측정 전에 두 번의 워밍업 반복을 수행했습니다.

결과

아래 표는 크로스 벤더(H100 prefill + MI300X decode)와 단일 벤더(MI300X prefill + MI300X decode) 성능을 비교합니다. E2EL은 중앙값 종단간 지연 시간(초 단위)이며, TPS는 초당 총 처리 토큰 수입니다. E2EL Ratio와 TPS Ratio는 크로스 벤더 / 단일 벤더로 — E2EL 비율이 1.0 미만이고 TPS 비율이 1.0 초과이면 크로스 벤더가 유리함을 나타냅니다.

핵심 결과: 고부하 워크로드에서의 크로스 벤더 우위

긴 시퀀스와 높은 동시 처리 수준의 부하가 높은 워크로드에서, 크로스 벤더 분리는 단일 벤더 기준 대비 상당한 개선을 제공합니다.

ISL/OSLCONCross E2EL (s)Single E2EL (s)E2EL RatioCross TPSSingle TPSTPS Ratio
8K/1K256190.52256.620.74×12,1079,0301.34×
8K/8K16119.24207.670.57×2,1901,3121.67×
8K/8K32214.75324.800.66×2,4171,5401.57×
Geomean0.65×1.52×

ISL 8K / OSL 8K에서 크로스 벤더 구성은 동시 처리 수준 16–32에서 E2EL을 34–43% 줄이고 처리량을 57–67% 높입니다. 이러한 성능 향상은 각 GPU를 하드웨어 특성에 가장 적합한 추론 단계에 할당하고, 벤더 경계를 넘어 KV cache 전송을 관리하는 통신 계층을 결합한 결과입니다. 다음 섹션에서는 네 가지 ISL/OSL 시나리오와 다양한 동시 처리 수준에 걸친 전체 결과를 제시하며, 크로스 벤더 분리가 언제, 왜 이점을 제공하는지 보여줍니다.

ISL 1024 / OSL 1024

입력과 출력 모두 1,024 토큰인 가장 가벼운 워크로드에서, 두 구성은 모든 동시 처리 수준에서 사실상 동일한 성능을 보여줍니다.

CONCross E2EL (s)Single E2EL (s)E2EL RatioCross TPSSingle TPSTPS Ratio
15.325.321.00×3813781.01×
46.426.391.00×1,1651,2340.94×
87.287.301.00×2,1392,1750.98×
169.099.240.98×3,4023,3331.02×
3211.6611.391.02×5,1985,0861.02×
Geomean1.00×1.00×

입력 토큰이 1,024개에 불과하면 어느 GPU에서든 prefill이 빠르게 완료되며, 요청당 KV cache는 수십 메가바이트에 불과합니다. Prefill 연산이나 KV cache 전송 모두 병목이 되지 않으므로, 성능은 거의 전적으로 decode 속도에 의해 결정되며 — 이는 두 구성에서 동일합니다. 이는 크로스 벤더 운영이 본질적인 성능 저하를 야기하지 않음을 확인해 줍니다.

ISL 1024 / OSL 8192

짧은 입력에 긴 출력(8,192 토큰)인 경우, decode 단계가 전체 실행 시간의 대부분을 차지합니다. 크로스 벤더 우위는 동시 처리 수준 4부터 나타나 꾸준히 확대되며, 동시 처리 수준 32에서 E2EL 29% 감소와 처리량 46% 향상에 도달합니다. 긴 8K 출력 시퀀스가 decode 측 혼잡 효과를 증폭시킵니다: 단일 벤더 구성에서는 NIXL 커넥터를 통한 비제어 KV cache 버스트가 전체 출력 생성에 걸쳐 토큰 간 지연 시간을 증가시킵니다.

CONCross E2EL (s)Single E2EL (s)E2EL RatioCross TPSSingle TPSTPS Ratio
145.0544.131.02×2042080.98×
453.6758.510.92×6866261.10×
867.0674.490.90×1,0939861.11×
1693.8292.411.02×1,6391,4891.10×
32108.74152.610.71×2,5081,7221.46×
Geomean0.91×1.14×

ISL 8192 / OSL 1024

긴 입력(8,192 토큰)과 짧은 출력에서는 prefill이 전체 지연 시간의 더 큰 비중을 차지합니다. 낮은 동시 처리 수준(1–16)에서는 prefill이 더 memory-bandwidth-bound이며, MI300X의 5.3 TB/s 대역폭이 단일 벤더 구성에 유리합니다. 동시 처리 수준 32에서 명확한 전환점이 나타납니다: prefill이 compute-bound가 되면서 H100의 이점이 발휘되고, 크로스 벤더 구성은 동시 처리 수준 256까지 우위를 유지합니다(E2EL 26% 개선, 처리량 12,000 tok/s 이상 유지 vs. 단일 벤더 10,000 tok/s 미만).

CONCross E2EL (s)Single E2EL (s)E2EL RatioCross TPSSingle TPSTPS Ratio
16.526.021.08×1,4091,5090.93×
49.007.601.18×3,8544,7270.82×
811.729.651.21×6,0777,0950.86×
1617.3314.621.19×8,7949,5970.92×
3224.9336.540.68×11,4868,1051.42×
6447.7657.000.84×11,8709,9781.19×
128101.58119.450.85×11,2249,5981.17×
256190.52256.620.74×12,1079,0301.34×
Geomean0.95×1.06×

ISL 8192 / OSL 8192

가장 무거운 워크로드는 앞선 두 시나리오의 효과를 결합합니다. 동시 처리 수준 1에서는 낮은 동시 처리 수준에서의 MI300X 대역폭 이점으로 인해 단일 벤더 구성이 약간 더 빠릅니다. 동시 처리 수준 8부터 크로스 벤더 구성이 결정적으로 앞서기 시작하며 — 동시 처리 수준 16–32에서 E2EL이 34–43% 빨라지고 처리량이 57–67% 높아집니다. 긴 입력과 긴 출력의 이중 압력이 H100의 compute-bound prefill 이점과 decode 측 혼잡 효과를 모두 증폭시킵니다.

CONCross E2EL (s)Single E2EL (s)E2EL RatioCross TPSSingle TPSTPS Ratio
152.6747.881.10×3113420.91×
473.4774.770.98×8909270.96×
887.13110.400.79×1,5951,1831.35×
16119.24207.670.57×2,1901,3121.67×
32214.75324.800.66×2,4171,5401.57×
Geomean0.80×1.25×

핵심 발견

네 가지 ISL/OSL 시나리오 전체에서 크로스 벤더 구성(H100 prefill + MI300X decode)은 단일 벤더 MI300X 클러스터 대비 기하평균 E2EL 비율 0.92×, 기하평균 TPS 비율 1.10×를 달성했습니다(E2EL 비율 1.0 미만, TPS 비율 1.0 초과가 크로스 벤더 유리). 주요 시사점은 다음과 같습니다:

  • 실현 가능성 확인: NVIDIA와 AMD GPU 간 크로스 벤더 PD 분리는 테스트된 모든 워크로드에서 안정적으로 작동합니다. MoAI 추론 프레임워크가 하드웨어 차이를 추상화하여, 운영자가 호환성 제약 없이 단일 서빙 클러스터에서 GPU 벤더를 혼합할 수 있게 합니다.
  • 저부하에서의 성능 동등성: 가벼운 워크로드(1K/1K)와 낮은 동시 처리 수준에서 두 구성은 사실상 동일한 성능을 보여, 크로스 벤더 운영이 본질적인 성능 저하를 야기하지 않음을 확인합니다.
  • 높은 동시 처리 수준에서의 크로스 벤더 우위: 긴 출력 시퀀스(1K/8K, 8K/8K) 또는 높은 동시 처리 수준(8K/1K에서 CON ≥ 32)의 워크로드에서, 크로스 벤더 구성은 단일 벤더 대비 지연 시간 최대 43%, 처리량 최대 67% 개선됩니다. 두 가지 요인이 기여합니다: (1) 동시 처리 수준이 높아지면 prefill이 compute-bound가 되며, H100의 더 큰 온칩 메모리(L1 + shared memory)가 밀집 GEMM을 더 효율적으로 처리합니다; (2) 크로스 벤더 통신 계층의 소프트웨어 기반 전송 버퍼링이 NIXL 커넥터의 직접 GPU 메모리 경로에서 발생하는 decode 노드 큐 포화를 방지합니다.
  • 상호 보완적 하드웨어 강점: 낮은 동시 처리 수준에서는 prefill이 더 memory-bandwidth-bound이며, MI300X의 5.3 TB/s 대역폭이 유리합니다. 높은 동시 처리 수준에서는 prefill이 compute-bound로 전환되어 H100의 연산 밀도가 이점을 제공합니다. MI300X의 192 GB HBM3과 높은 대역폭은 memory-bandwidth-bound인 decode 단계에 일관되게 적합합니다.
  • 워크로드 의존적 최적화의 중요성: 성능 특성은 시퀀스 길이와 동시 처리 수준에 따라 극적으로 달라집니다 — 낮은 동시 처리 수준에서 뒤처지는 구성이 높은 동시 처리 수준에서는 최대 43–67% 앞설 수 있습니다. 이기종 하드웨어의 전체 이점을 활용하려면 실시간 워크로드 패턴에 기반한 prefill/decode 할당, KV cache 전송 전략, 요청 라우팅의 동적 조정이 필요합니다. MoAI 추론 프레임워크는 이러한 최적화를 자동화하여, 각 GPU 아키텍처와 워크로드 상호작용에 대한 깊은 지식이 필요한 수동 튜닝에서 운영자를 해방시키는 것을 목표로 합니다.

결론

본 연구는 이기종 GPU 클러스터가 단일 벤더 구성만큼 — 그리고 많은 시나리오에서 더 효과적으로 — LLM을 서빙할 수 있음을 입증합니다. NVIDIA H100 GPU를 compute 집약적인 prefill 단계에, AMD MI300X GPU를 memory-bandwidth 집약적인 decode 단계에 할당함으로써, MoAI 추론 프레임워크는 데이터센터 운영자가 단일 벤더 종속을 넘어 벤더 제약이 아닌 워크로드 특성에 기반하여 GPU 인프라를 설계할 수 있게 합니다.

가장 부하가 높은 워크로드에서 크로스 벤더 구성은 단일 벤더 MI300X 클러스터 대비 종단간 지연 시간을 최대 43% 줄이고 처리량을 최대 67% 높입니다. 동시에, 결과는 성능 특성이 시퀀스 길이와 동시 처리 수준에 따라 상당히 달라짐을 보여줍니다 — 저부하에서 최적인 것이 고부하에서는 최적이 아닐 수 있으며, 그 반대도 마찬가지입니다. 이러한 복잡성을 수동으로 관리하는 것은 대규모에서 비현실적입니다. MoAI 추론 프레임워크는 이기종 클러스터 전반에 걸쳐 워크로드 인식 GPU 자원 할당, KV cache 전송 전략, 요청 라우팅을 자동화하여, 운영자가 지속적인 수동 튜닝의 운영 부담 없이 크로스 벤더 분리의 성능 이점을 확보할 수 있도록 합니다.