‹ Back to Blog

Customer Case

통신사 LLM 추론 최적화: AMD MI300X에서 1.38배 높은 서빙 용량 달성

November 25, 2025

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

배경

국내 주요 통신사 중 하나가 그룹 계열사에서 개발한 7.8B 파라미터 규모의 dense LLM을 활용하여 LLM 기반 서비스를 배포할 계획이었습니다. 인프라 평가의 일환으로, 이 모델의 프로덕션 서빙에 있어 AMD Instinct MI300X와 기존 NVIDIA H100 GPU를 비교하고자 했습니다.

고객사는 Moreh에 이 계열사 모델의 MI300X 추론 최적화 및 H100과의 직접 벤치마크 비교를 요청했습니다. 목표는 단순한 속도 측정이 아니라, 구체적인 비즈니스 질문에 답하는 것이었습니다: 허용 가능한 응답 품질을 유지하면서 단일 GPU가 몇 명의 동시 사용자를 처리할 수 있는가?

이는 고객 대면 AI 서비스를 배포하는 통신사에서 흔히 제기되는 질문으로, 동시 세션 수가 필요한 GPU 수를 직접 결정하며 — 이는 곧 총 인프라 비용을 의미합니다.

지표가 중요한 이유

결과를 살펴보기 전에, 각 지표가 선정된 이유를 설명할 필요가 있습니다. 고객사는 가입자 대면 LLM 서비스를 설계하고 있었으므로, 모든 지표는 사용자 경험과 운영 비용의 특정 측면에 대응합니다:

  • TTFT (Time To First Token): 서비스가 응답을 시작하기까지 사용자가 기다리는 시간입니다. 대화형 인터페이스에서 높은 TTFT는 느리게 느껴져 사용자 이탈을 유발합니다. 이는 "체감 응답성" 지표입니다.
  • TPOT (Time Per Output Token): 생성 중 연속적인 토큰 사이의 간격으로, 응답의 스트리밍 속도를 결정합니다. 낮은 TPOT는 자연스러운 실시간 타이핑처럼 느껴지고, 높은 값은 눈에 띄는 끊김이나 지연을 유발합니다.
  • End-to-End Latency (E2EL): 요청 제출부터 마지막 토큰까지의 총 시간입니다. 전체 응답에 대한 사용자의 완전한 대기 시간을 포착합니다.
  • Output TPS (Tokens Per Second): 집계 처리량 — 시스템이 초당 생성하는 토큰 수입니다. 높은 TPS는 단위 시간당 GPU당 더 많은 작업을 처리함을 의미합니다.
  • Max Concurrency: TTFT와 TPOT를 고객이 지정한 임계값(Service Level Objectives, SLO) 내로 유지하면서 단일 GPU가 처리할 수 있는 최대 동시 요청 수입니다. 이는 운영적으로 가장 중요한 지표입니다: 주어진 사용자 규모에 대해 고객이 구매해야 하는 GPU 수를 직접 결정합니다.

테스트 구성

모든 테스트는 단일 GPU 대 단일 GPU로 비교했습니다:

  • MI300X 측: 1× AMD Instinct MI300X (192 GB HBM3e), Moreh vLLM 실행
  • H100 측: 1× NVIDIA H100 SXM (80 GB HBM3), vLLM 실행

워크로드는 ShareGPT 트레이스 — ChatGPT 유사 서비스의 실제 대화 로그 — 를 사용하여 현실적인 대화 상호작용을 시뮬레이션했습니다. 고정된 입출력 길이를 사용하는 합성 벤치마크와 달리, ShareGPT 트레이스는 실제 사용자의 매우 가변적인 요청 패턴을 반영합니다: 짧은 후속 질문, 긴 초기 프롬프트, 다양한 응답 길이 등. 이를 통해 결과가 고객이 프로덕션에서 경험할 상황을 더 잘 대표합니다.

최적화 기법

계열사에서 개발한 모델을 새로운 GPU 플랫폼에서 실행하는 것은 단순히 하드웨어를 교체하는 문제가 아닙니다. 이 모델은 NVIDIA GPU에서 개발 및 테스트되었으며, AMD ROCm 스택의 기본 오픈소스 vLLM은 상당한 성능을 활용하지 못하고 있었습니다. Moreh는 이 격차를 해소하고 MI300X의 잠재력을 최대한 끌어내기 위해 두 가지 핵심 최적화를 적용했습니다:

  • 커스텀 attention 백엔드: AMD ROCm용 여러 attention 커널 구현이 존재하지만, 이 모델 아키텍처의 모든 시나리오에서 일관되게 최고 성능을 보이는 것은 없었습니다. Moreh는 prefill과 decode 단계에서 각 후보를 개별적으로 프로파일링한 후, 각 단계에서 최고 성능을 보이는 커널을 통합 커스텀 attention 백엔드로 결합했습니다. 이것만으로도 기본 ROCm vLLM 대비 출력 처리량과 토큰 간 지연이 17% 개선되었습니다.
  • Shape-aware dispatch를 활용한 GEMM 튜닝: 모델의 BF16 행렬 곱셈은 범용 GEMM 경로를 통해 처리되고 있었습니다. Moreh는 여러 GEMM 백엔드(aiter.tgemm 및 decode에서 일반적인 작은 배치 크기에 최적화된 특수 skinny-GEMM 커널 포함) 위에 커스텀 dispatch 레이어를 구축한 후, 모델에서 발생하는 모든 GEMM shape에 대해 shape별 dispatch 테이블을 튜닝했습니다. 이를 통해 출력 처리량이 추가로 10%, TTFT가 3% 개선되었습니다.

이러한 최적화를 결합하여 Moreh vLLM은 동일한 MI300X 하드웨어에서 기본 ROCm vLLM보다 최대 27% 빠른 성능을 달성했습니다 — H100과의 비교 이전입니다. 아래 결과는 이 완전히 최적화된 구성을 반영합니다.

단일 요청 지연

첫 번째 테스트는 단일 요청(동시 부하 없음)에서의 기본 성능을 측정했습니다. 이는 배칭 효과 없이 각 플랫폼의 순수 추론 속도를 분리합니다:

MetricMoreh vLLM (MI300X)vLLM (H100)Comparison
Output TPS (tok/s)186.75143.391.30× higher
TPOT (ms)5.336.961.31× faster
End-to-End Latency (ms)2,9133,8081.31× faster

Single request, ShareGPT workload, single GPU. TPOT = Time Per Output Token, E2EL = End-to-End Latency.

단일 요청에서 MI300X의 Moreh vLLM은 1.30× 높은 출력 처리량과 모든 지표에서 1.31× 낮은 지연을 달성했습니다. 실질적으로, 사용자는 전체 응답이 약 900 ms 더 빨리 도착하는 것을 경험하게 됩니다(2.9초 vs. 3.8초) — 대화형 인터페이스에서 체감 가능한 개선입니다.

이러한 이점은 MI300X의 높은 HBM3e 메모리 대역폭(5.3 TB/s vs. H100의 3.35 TB/s)과 위에서 설명한 Moreh vLLM의 커널 수준 최적화의 결합에서 비롯됩니다.

SLO 준수 최대 서빙 용량

단일 요청의 순수 속도는 유용하지만, 프로덕션 배포 결정은 다른 질문에 의해 좌우됩니다: 허용 가능한 서비스 품질을 유지하면서 하나의 GPU가 동시에 몇 명의 사용자를 서빙할 수 있는가?

이에 답하기 위해, 시스템이 고객이 지정한 Service Level Objectives (SLO)를 더 이상 충족하지 못할 때까지 동시 요청 수를 점진적으로 증가시켰습니다:

  • TTFT < 1,000 ms
  • TPOT < 100 ms

이러한 임계값은 고객이 자체 서비스 요구사항에 기반하여 정의했습니다. 두 SLO를 모두 충족하는 최대 동시성이 단일 GPU의 유효 서빙 용량을 나타냅니다.

MetricMoreh vLLM (MI300X)vLLM (H100)Comparison
Max Concurrency (SLO-compliant)8806361.38×

Customer-specified SLO thresholds: TTFT < 1,000 ms, TPOT < 100 ms. ShareGPT workload on a single GPU.

MI300X의 Moreh vLLM은 1.38× 높은 SLO 준수 서빙 용량을 달성했습니다: GPU당 880개의 동시 요청 vs. H100의 636개. 단일 MI300X가 TTFT와 TPOT 모두를 고객이 지정한 범위 내로 유지하면서 38% 더 많은 동시 세션을 처리할 수 있습니다.

수백만 가입자를 서빙하려는 통신사에게 이 차이는 규모에서 복합적으로 작용합니다. 서비스가 10,000개의 동시 세션을 처리해야 한다면, 약 12개의 MI300X GPU vs. 16개의 H100 GPU가 필요합니다 — 하드웨어 비용 차이를 고려하기 전에 서빙 용량 이점만으로 GPU 수가 25% 감소합니다.

모델 정확도 검증

GPU 플랫폼과 추론 엔진을 전환하면 모델 출력 품질에 영향을 줄 수 있는 미묘한 수치적 차이의 위험이 발생합니다. Moreh vLLM을 사용한 MI300X로의 마이그레이션이 모델의 능력을 저하시키지 않는지 확인하기 위해, 두 플랫폼에서 MMLU (Massive Multitask Language Understanding, 5-shot) 정확도를 측정했습니다:

BenchmarkMoreh vLLM (MI300X)vLLM (H100)
MMLU (5-shot)65.2565.80

MMLU = Massive Multitask Language Understanding. The 0.55-point difference is within normal variance and does not indicate quality regression.

0.55점 차이는 MMLU 평가의 정상 분산 범위 내에 있으며, Moreh vLLM의 MI300X 최적화가 의미 있는 품질 저하를 초래하지 않음을 확인합니다. 고객은 응답 품질이 H100 기준과 동일할 것이라는 확신을 가지고 MI300X에 배포할 수 있습니다.

TCO 분석

성능 결과와 하드웨어 경제성을 결합하면 총 소유 비용(TCO)에 대한 명확한 그림이 나타납니다:

  • 서빙 용량 이점: 각 MI300X는 H100보다 1.38× 더 많은 동시 사용자를 서빙하여, 주어진 워크로드에 필요한 GPU 수를 줄입니다.
  • 하드웨어 비용 이점: AMD Instinct MI300X는 NVIDIA H100 SXM보다 낮은 구매 비용을 가지고 있습니다.

두 요소를 결합하면, 내부 분석에서 MI300X + Moreh vLLM 플랫폼이 이 추론 워크로드에 대해 최대 70% 더 나은 비용 효율성을 보일 것으로 예측했습니다. 전국 규모로 AI 서비스를 배포하는 통신사에게 이는 상당한 자본 지출 절감으로 이어집니다.

요약

국내 주요 통신사와의 이번 프로젝트는 AMD Instinct MI300X가 Moreh vLLM과 결합하여 프로덕션 LLM 서빙에서 NVIDIA H100의 강력한 대안이 될 수 있음을 보여줍니다. 계열사에서 개발한 7.8B 파라미터 모델에 대해:

  • 1.30× 높은 단일 요청 처리량과 1.31× 낮은 end-to-end 지연
  • 1.38× 높은 SLO 준수 서빙 용량 (GPU당 880 vs. 636 동시 세션)
  • 동등한 모델 정확도 (MMLU 65.25 vs. 65.80)
  • 최대 70% 더 나은 비용 효율성 (성능과 하드웨어 비용 이점을 모두 고려 시)

이 계열사 개발 LLM은 AMD 하드웨어에서 효율적으로 실행되기 위해 Moreh의 커스텀 최적화 작업 — 모델별 attention 백엔드와 shape-aware GEMM 튜닝 포함 — 이 필요했습니다. 이는 AMD GPU에 대한 모델 최적화 역량을 보여주며, 고객이 GPU 공급망을 다변화하고 단일 벤더 의존도를 줄일 수 있게 합니다.

Moreh는 AMD GPU에서 모델을 위한 커스텀 vLLM 최적화를 제공합니다. 추론 워크로드에 AMD Instinct GPU를 평가하고 계신다면, 문의하기를 통해 저희가 어떻게 도움을 드릴 수 있는지 상담해 보세요.