‹ 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 との直接比較ベンチマークの実施を依頼しました。目標は単なる生のスピード測定ではなく、具体的なビジネス上の問いに答えることでした:許容可能な応答品質を維持しながら、1 つの 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):合計スループット — システムが 1 秒あたりに生成するトークン数。TPS が高いほど、GPU あたり・単位時間あたりの処理量が多くなります。
  • Max Concurrency:TTFT と TPOT を顧客指定の閾値(Service Level Objectives、SLO)内に維持しながら、1 つの GPU が処理できる最大同時リクエスト数。これは運用上最も重要な指標です:所定のユーザーベースに対して顧客が購入する必要のある GPU 数を直接決定します。

テスト構成

すべてのテストは GPU 1 基対 1 基で比較しました:

  • 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 の潜在能力を最大限に引き出すため、2 つの重要な最適化を適用しました:

  • カスタム attention backend:AMD ROCm 向けに複数の attention kernel 実装が存在しますが、このモデルアーキテクチャに対してすべてのシナリオで一貫して他を上回るものはありませんでした。Moreh は prefill フェーズと decode フェーズで各候補を個別にプロファイリングし、各フェーズで最も性能の高いカーネルを統合したカスタム attention backend を構築しました。これだけで、ベースラインの ROCm vLLM と比較して出力スループットとトークン間レイテンシが 17% 改善しました。
  • 形状認識ディスパッチによる GEMM チューニング:モデルの BF16 行列乗算は汎用的な GEMM パスで処理されていました。Moreh は複数の GEMM backend(decode 時の小バッチサイズに最適化された aiter.tgemm や特殊な skinny-GEMM kernel を含む)上にカスタムディスパッチレイヤーを構築し、モデル内で発生するすべての GEMM 形状に対して形状固有のディスパッチテーブルをチューニングしました。これにより、出力スループットがさらに 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 準拠の最大サービング容量

単一リクエストの生の速度は有用ですが、本番環境のデプロイ判断は別の問いによって左右されます:許容可能なサービス品質を維持しながら、1 つの 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 は、SLO 準拠のサービング容量で 1.38× を達成しました:GPU あたり 880 同時リクエスト vs. H100 の 636。単一の MI300X は、TTFT と TPOT の両方を顧客指定の範囲内に維持しながら、38% 多くの同時セッションを処理できます。

数百万の加入者にサービスを提供する通信事業者にとって、この差はスケールで増幅されます。サービスが 10,000 の同時セッションを処理する必要がある場合、必要な GPU は MI300X で約 12 基 vs. H100 で 16 基 — ハードウェアコストの差を考慮する前に、サービング容量の優位性だけで GPU 数が 25% 削減されます。

モデル精度の検証

GPU プラットフォームと推論エンジンの変更は、モデル出力品質に影響を与える微妙な数値差のリスクを伴います。MI300X + Moreh vLLM への移行がモデルの能力を損なわないことを検証するため、両プラットフォームで 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 より低い調達コストです。

両方の要因を組み合わせると、Moreh の内部分析では、この推論ワークロードにおいて MI300X + Moreh vLLM プラットフォームで最大 70% のコスト効率改善が見込まれました。全国規模で AI サービスを展開する通信事業者にとって、これは大幅な設備投資の削減につながります。

まとめ

韓国の大手通信事業者との本プロジェクトは、AMD Instinct MI300X が Moreh vLLM と組み合わせることで、本番 LLM サービングにおいて NVIDIA H100 の有力な代替となることを示しています。関連企業が開発した 7.8B パラメータモデルにおいて:

  • 単一リクエストスループット 1.30× 向上、end-to-end レイテンシ 1.31× 低減
  • SLO 準拠サービング容量 1.38×(GPU あたり 880 vs. 636 同時セッション)
  • 同等のモデル精度(MMLU 65.25 vs. 65.80)
  • 最大 70% のコスト効率改善(性能とハードウェアコストの両方の優位性を考慮)

関連企業が開発した LLM を AMD ハードウェア上で効率的に動作させるためには、Moreh によるカスタム最適化作業 — モデル固有の attention backend と形状認識 GEMM チューニングを含む — が必要でした。これは、Moreh が AMD GPU 向けにモデルを最適化し、顧客が GPU サプライチェーンを多様化して単一ベンダーへの依存を軽減できるようにする能力を示しています。

Moreh は AMD GPU 上のモデルに対するカスタム vLLM 最適化を提供しています。AMD Instinct GPU での推論ワークロードの評価をご検討中の場合は、お問い合わせください