# eGPU: Production-Scale Elastic Sharing over 10,000 GPUs > [!abstract] 概要 > GPU のコストが上昇し続ける中、効率性を高めリソース利用率を最大化するための GPU 共有ソリューションの重要性がますます高まっている。一方で、ワークロードの変動性やオーケストレーションの複雑さが新たな実運用の配慮事項をもたらす異種混合の本番環境において、そうしたソリューションの大規模な実運用展開は比較的未開拓のままである。本稿では、本番規模における機械学習（ML）の学習および推論の同時実行に特化して設計された、弾力的で高効率かつスケーラブルな GPU 共有フレームワークである eGPU を提案する。eGPU は、高いリソース利用率と障害隔離を維持しながら、複数ジョブ間での細粒度かつ実行時に調整可能な GPU 共有を実現する。通信ボトルネックに対処するため、既存設計の多くでは制限されているか利用不可能であった、共有 GPU インスタンス間でのネイティブな NVLink/NCCL ベース通信をサポートする。本番展開を念頭に構築された eGPU は、大規模オーケストレーションを支援するために Kubernetes（K8s）と統合されている。eGPU は 1 万台以上の GPU を備える本番クラスタに展開され、5 年間にわたり安定稼働を続けている。評価結果により、eGPU がインスタンスサイズに対する弾力的で精密な制御を達成し、最先端（SOTA）の共有ソリューションと比較してジョブ効率を 21% から 31% 向上させ、必要な GPU 数を最大 8 倍節約し、クラスタの GPU 利用率を 3 倍以上向上させることが示された。 ## 問題設定と背景 ### GPU共有の機会と本番環境の実態 GPU は機械学習（ML）、科学シミュレーション、データ分析などの計算を加速する不可欠なアクセラレータとなっている。しかし GPU は極めて高価であり、すべてのワークロードが単一 GPU の全計算能力を常時必要とするわけではない。特に分散学習やオンライン推論では、GPU の占有割り当てが極めて低い平均利用率をもたらす。 著者らが所属する [[Alibaba Group]] の本番クラスタにおいて、約 100 万件のユーザジョブ（2 ヶ月間の実トレース）の GPU 利用率（過去の監視期間中に少なくとも 1 つのカーネルが実行されていた時間の割合）を調査したところ、驚くべき実態が判明した（図 1（Figure 1））。 ![[_attachments/eGPU---Production-Scale-Elastic-Sharing-over-10000-GPUs/fig01-gpu-utilization.png]] *図 1（Figure 1）: 本番クラスタにおける機械学習ジョブの GPU 利用率分布。約 93% のジョブが GPU の 50% 未満しか使用しておらず、全体の平均利用率はわずか 24.70% に留まる。* 調査対象となったワークロードの約 93% は GPU 利用率が 50% 未満であり、全ジョブの平均 GPU 利用率はわずか 24.70% であった。この巨大なリソースの遊休は、データセンターの運用コストと電力持続可能性の観点から深刻な課題である。 ### 既存の共有方式とその限界: 空間共有対時間共有、優先度対パーティション 既存の GPU 共有方式は大きく「空間共有（Spatial Sharing）」と「時間共有（Temporal Sharing）」に分類される。 - **空間共有**（MPS、MIG、REEF、Orion、GPUlet 等）: GPU のメモリや SM などの計算コアを分割し、複数アプリケーションを同時並行に実行する。高い利用率を達成しやすい反面、カーネルレベルの介入による障害波及（MPS 等）や、ハードウェアの静的分割による柔軟性の欠如・通信制約（MIG 等）というトレードオフを抱える。 - **時間共有**（Gandiva、Antman、Clockwork、TGS、Salus 等）: タイムスロットごとに異なるジョブへ GPU を排他的に時分割割り当てする。コンテキスト切り替えやメモリ退避が必要になることが多い。 さらに運用方針として、既存研究の多くは**優先度ベース共有（Priority-based Sharing）**（高優先度ジョブの余剰資源に低優先度ジョブを日和見的に割り当てる方式）を採用してきた。しかし、本番環境において優先度ベース共有には重大な問題が存在する: 1. **ユーザによる優先度ゲーミング**: ユーザは自身のジョブを「高優先度」と申告する傾向があり、余剰枠を埋める「低優先度ジョブ」自体がクラスタ内で払底する。 2. **低優先度ジョブの飢餓（Starvation）**: 低優先度ジョブの実行が何日も遅延・停止し、1 週間以上スケジュールされない事例が多発して公平性と予測可能性が損なわれる。 ![[_attachments/eGPU---Production-Scale-Elastic-Sharing-over-10000-GPUs/fig02-percentage-sharing.png]] *図 2（Figure 2）: 本番クラスタにおいて優先度ベース共有を選択したジョブの割合（2024年4月〜10月の6ヶ月間）。利用率は 14.3%〜35.5% に留まり、ユーザの大半は公平かつ独立したパーティションベース共有を選好する。* 図 2（Figure 2）に示すように、社内本番クラスタでユーザが優先度ベース共有を選択した割合は 14.3%〜35.5% に過ぎず、大半のユーザは明示的なリソース枠を保証する**パーティションベース共有（Partition-based Sharing）**を求めている。 ### 本番展開における6大課題（Table I） 著者らは、最先端の学術・商用ソリューションを大規模本番環境に適用する過程で、以下の 6 つの主要課題（P1〜P6）を抽出した。 1. **P1: 割り当ての弾力性の達成（Achieve Allocation Elasticity）**: ワークロードの需要変動に応じて、インスタンスの GPU 計算・メモリ比率を実行時に細粒度かつ動的に増減できなければならない。MIG のような静的分割では対応できない。 2. **P2: 障害隔離の保証（Provide Fault Isolation）**: 1 つのジョブのエラーが同一 GPU を共有する他ジョブを道連れにしてはならない。MPS では GPU コンテキスト統合により 1 ジョブのクラッシュが全ジョブを巻き込む。 3. **P3: ジョブ完全性の維持（Keep Job Integrity）**: ユーザジョブのバッチサイズ変更やコード改変、事前のプロファイリングやジョブ分類を強制してはならない。 4. **P4: SLA遵守の保証（Guarantee SLA Compliance）**: 日和見実行による低優先度ジョブの無期限遅延を排除し、設定されたリソース枠内で安定した応答時間・スループットを提供しなければならない。 5. **P5: ユーザ透過性の維持（Maintain User Transparency）**: ユーザプログラムやコンテナイメージへの修正なしに、OCI 標準コンテナ環境で透過的に動作しなければならない。 6. **P6: 異種GPU環境のサポート（Support GPU Heterogeneity）**: 長年にわたり調達された多世代の異種混合 GPU（ハードウェア分割機能を持たないものや、独自インターフェースを含む）を統一的にサポートしなければならない。 | 課題 | Salus [59] | Clockwork [21] | Antman [58] | TGS [56] | REEF [22] | GPUlet [17] | Orion [48] | MPS [8] | MIG [7] | eGPU（提案） | | :--- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | | **P1: 割り当ての弾力性** | ✕ | ✕ | ✕ | ✕ | ✕ | ✕ | ✕ | ◯ | ✕ | ◯（FAA） | | **P2: 障害隔離** | ◯ | ◯ | ◯ | ◯ | ✕ | ✕ | ✕ | ✕ | ◯ | ◯（K8s 隔離） | | **P3: ジョブ完全性** | ✕ | ✕ | ✕ | ◯ | ◯ | ✕ | ✕ | ◯ | ◯ | ◯（設定変更不要） | | **P4: SLA遵守保証** | ✕ | ✕ | ✕ | ✕ | ✕ | ✕ | ✕ | ◯ | ◯ | ◯（パーティション共有） | | **P5: ユーザ透過性** | ✕ | ✕ | ✕ | ◯ | ✕ | ✕ | ✕ | ◯ | ◯ | ◯（API 傍受） | | **P6: 異種GPUサポート** | ✕ | ✕ | ✕ | ✕ | ✕ | ✕ | ✕ | ✕ | ✕ | ◯（CPU側処理） | *表 I（Table I）: eGPU と既存の代表的 GPU 共有ソリューションの課題対応比較。既存手法のいずれも 6 つの課題を同時に解決できていないのに対し、eGPU はすべてを同時に達成する。* ## 提案手法: eGPU の設計と実装 ### システム概要 eGPU は、クラスタスケジューラ（Kubernetes や Slurm 等）と直交してノードレベルで動作する弾力的 GPU 共有フレームワークである（図 3（Figure 3））。 ![[_attachments/eGPU---Production-Scale-Elastic-Sharing-over-10000-GPUs/fig03-egpu-overview.png]] *図 3（Figure 3）: eGPU のシステム概要。ノードレベルのパーティショナーとして CPU 側で動作し、FAA による弾力性（Elasticity）、NVLink/NCCL による通信効率性（Efficiency）、Kubernetes 最適化によるスケーラビリティ（Scalability）を提供する。* eGPU の主要な設計方針は以下の通りである: 1. **CPU 側での非侵入的動作**: GPU カーネルの書き換えやドライバの侵入的改変を行わず、CPU 側の CUDA/HIP API インターセプトによって純粋に動作する。 2. **コンテナ完全透過**: OCI（Open Container Initiative）標準に準拠したコンテナランタイムツールキットを提供し、ユーザコードの変更や事前プロファイリングを不要とする。 3. **高効率なノード内・プロセス間通信**: 共有インスタンス間での NVLink および NCCL ネイティブ通信をサポートする。 ### 細粒度飢餓防止アルゴリズム（FAA: Fine-grained Anti-starving Algorithm） 伝統的な時間共有方式では、長い監視周期（例: 1 秒）に対して静的割合（例: 70% なら 0.7 秒、30% なら 0.3 秒）を連続して割り当てるため、インスタンスの一時的な停滞や飢餓が発生する。 著者らは本番クラスタにおけるカーネル実行時間を実測し、**ML ワークロードの GPU カーネルが極めて短時間である**という重要な洞察を得た（図 4（Figure 4））。 ![[_attachments/eGPU---Production-Scale-Elastic-Sharing-over-10000-GPUs/fig04-kernel-length.png]] *図 4（Figure 4）: 本番クラスタ（V100）における約 20 件のユーザジョブの GPU カーネル実行時間分布。85% 超のカーネルが 0.1ms 未満で完了し、98% 超が 1ms 未満である。* このようなマイクロ秒〜ミリ秒単位の短時間カーネルが反復実行される環境下では、粗粒度の時間窓（0.7 秒など）によるスケジューリングは重大な一時的飢餓を引き起こす。そこで eGPU は、割り当てウィンドウを細粒度のタイムスライスに分割して動的にスケジュールする **Fine-grained Anti-starving Algorithm（FAA）** を導入した（図 5（Figure 5））。 ![[_attachments/eGPU---Production-Scale-Elastic-Sharing-over-10000-GPUs/fig05-anti-starving.png]] *図 5（Figure 5）: eGPU の細粒度飢餓防止アルゴリズム（FAA）。1 秒の期間を複数の短いスライスに分割し、過去の履歴から最も割り当てが不足しているインスタンスへ次のスライスを割り当てることで、目標比率（例: 70%:30% = 2.33:1）へ滑らかに収束させる。* FAA の動作機構（Algorithm 1）: - 監視期間（Monitoring Period）を実機サンプリングに合わせた $1/6$ 秒〜 $1$ 秒とし、個々のタイムスライス長をハードウェア制約とのトレードオフから $0.01$ 秒〜 $0.02$ 秒に設定する。 - 監視期間ごとに、各インスタンス $I_i$ の目標割り当て比率 $R_{target,i}$ と過去の履歴に基づく現在比率 $R_{current,i}$ の偏差 $D_i = R_{current,i} - R_{target,i}$ を算出する。 - 偏差が最小（最も不足している）のインスタンス $I_{min\_dev}$ に次のタイムスライスを割り当て、履歴を更新する。これにより、各インスタンスの実行比率が常に目標比率へと滑らかに収束し、飢餓が完全に防止される。 ### 実行時における動的リソース調整（Elastic Adjustment） eGPU は、コンテナを再起動することなく、実行中に各インスタンスの GPU 計算力およびメモリ割り当てを動的に変更できる（図 6（Figure 6））。 ![[_attachments/eGPU---Production-Scale-Elastic-Sharing-over-10000-GPUs/fig06-instance-adjustment.png]] *図 6（Figure 6）: eGPU におけるインスタンス資源の動的調整機構。実行中のインスタンスを停止させることなく、通知機構を介して割り当て比率を即座に再配分する。* 例えば、インスタンスの要求割合を 70% から 60% へ引き下げる場合、FAA の目標収束比率を再設定するだけで、インスタンスの稼働を一切中断することなく即座にリソースが解放され、他タスクや余剰プールへと配分される。 ### 高効率な通信サポート: NVLink と NCCL のネイティブ統合 分散 ML 学習において、勾配同期などの集団通信は学習時間の大部分を占める。しかし既存の GPU 共有機構では、コンテナやハードウェアの隔離境界によって NVLink が無効化されるという深刻な制約が存在した。さらに、集団通信ライブラリ [[NCCL]] は同一物理 GPU を同一コミュニケータの複数ランクとして共有することを仕様上サポートしておらず、最新の NCCL v2.28 では共有デバイスを検知するとエラーを返して異常終了する。 eGPU は、トポロジ認識型の NVLink 通信方式によりこの壁を突破した（図 7（Figure 7））。 ![[_attachments/eGPU---Production-Scale-Elastic-Sharing-over-10000-GPUs/fig07-nvlink-support.png]] *図 7（Figure 7）: 効率的な分散学習に向けた eGPU の NVLink サポート。コンテナ内の各ランクに物理 GPU デバイスを可視化し、ノード環境変数（`eGPU_NODE`）と NCCL コール傍受を組み合わせることで、リソース境界を維持したまま NVLink P2P 通信を確立する。* 1. **トポロジ認識 NVLink 通信**: - インスタンス初期化時、各コンテナにノード上のすべての物理 GPU デバイスを可視化し、環境変数 `eGPU_NODE=nodename` を注入する。これにより各 NCCL ランクは通信相手が同一ノード内に存在するかを判定できる。 - NCCL ライブラリ呼び出しをインターセプトし、通信が許可されたインスタンス間でのみ NVLink 認識の Peer-to-Peer（P2P）通信を有効化する。これにより、リソース境界を侵すことなく NVLink の最大帯域（第 5 世代で双方向 1800 GB/s）をフル活用できる。 2. **GPU内（Intra-GPU）通信**: - 同一物理 GPU に複数インスタンスが同居する場合、(1) ホスト共有メモリ（PCIe 経由で共有メモリ領域を読み書き）、(2) CUDA IPC（デバイスメモリの送受信バッファアドレスを通知し、ダイレクトな Device-to-Device コピーを実行）という 2 つの相補的メカニズムにより超高速なデータ交換を実現する。 ### Kubernetes を用いたスケーラブルなインスタンス制御 大規模本番クラスタでの運用を支えるため、eGPU は Kubernetes（K8s）の標準フレームワークを拡張する 3 つのコンポーネントと 2 つの通信リンクで構成される（図 8（Figure 8））。 ![[_attachments/eGPU---Production-Scale-Elastic-Sharing-over-10000-GPUs/fig08-scalable-instance-control.png]] *図 8（Figure 8）: Kubernetes（K8s）によるスケーラブルなインスタンス制御アーキテクチャ。eGPU Device Plugin、eGPU Container Toolkit、eGPU Runtime Daemon が連携し、gRPC リンクを通じて静的環境変数の排除と動的リソース制御を実現する。* 1. **eGPU Device Plugin**: クラスタスケジューラに対し、分割可能な GPU 計算力およびメモリを広報し、スケジューリング判断を可能にする。 2. **eGPU Container Toolkit**: OCI 標準に準拠したインスタンス制御インターフェースを提供し、Docker、Containerd、Podman、Singularity、Pouch などの主要コンテナ技術へ非侵入的に eGPU 機能を注入する。コンテナイメージの直接改変は不要である。 3. **eGPU Runtime Daemon**: 各インスタンス内部に常駐し、Device Plugin との第 2 の gRPC リンクを通じて、実行中の動的リソース調整要求を受信・適用する。 従来の `CUDA_VISIBLE_DEVICES` 環境変数の書き込みによる脆弱なデバイス割り当てを完全に廃止し、Device Plugin と Container Toolkit 間の第 1 のリンク（gRPC）によってデバイスのマウントと情報取得を行うことで、ユーザによる他デバイスへの誤アクセスを構造的に防止している。 ### CUDA API インターセプトの実装ワークフロー eGPU は C および Golang を中心とする約 10 万行のコードで実装されている。インスタンス起動時に、コンテナ内の CUDA ランタイム/ドライバライブラリが自動的に `eGPU Wrapper` に置き換えられる（図 9（Figure 9））。 ![[_attachments/eGPU---Production-Scale-Elastic-Sharing-over-10000-GPUs/fig09-cuda-interception.png]] *図 9（Figure 9）: CUDA API インターセプトのワークフロー。API の種別に応じて、事前検査（Pre-check）、事後検査（Post-check）、カーネル実行時のペーシング（Utilization Check & Delay）を行い、クォータ超過を防止する。* - **メモリ割り当て API（`cudaMalloc` 等）**: 事前検査（Pre-check）を実行。要求サイズがインスタンスの残りメモリクォータを超える場合は、実際の割り当てを行わずに即座にエラー（`cudaErrorMemoryAllocation`）を返す。 - **その他のメモリ消費 API**: API 実行後に事後検査（Post-check）を実施。クォータを超過していれば失敗を返す。 - **カーネル起動 API（`cudaLaunchKernel` 等）**: 現在のインスタンスの計算利用率が設定クォータを超えているか検査する。超過している場合は一定時間ウェイト（ペーシング）を入れてから再検査し、許可されたタイムスライス内でのみ実 API を呼び出す。 - **その他の API**: 検査をスキップし、そのまま本物の CUDA API を呼び出すことでオーバーヘッドを極小化する。 ## 実験と評価 ### 評価環境 - **プラットフォーム 1**: NVIDIA A100 40GB PCIe × 8、Intel Xeon Platinum 8269CY、ホストメモリ 768GB（MIG および LLM 評価用）。 - **プラットフォーム 2**: NVIDIA Tesla V100-SXM2-32GB × 8、Intel Xeon Platinum 8260、ホストメモリ 1.5TB（実行時リソース調整評価用）。 - **プラットフォーム 3**: NVIDIA T4 15GB × 8、Intel Xeon Platinum 8260、ホストメモリ 512GB（その他一般ワークロード用）。 - **本番クラスタ**: 1 万台以上の異種混合 GPU を擁するアリババの本番クラスタ。 - **ワークロード**: CV 系（ResNet-50、ResNet-101、社内非公開モデル 2 種）、NLP/LLM 系（BERT-Large、Qwen、LLaMA）。 ### 分割精度と実行時動的調整（Figure 10, Figure 11） 1 つの物理 GPU を 2 つのインスタンスで 50%/50% に分割した際の学習スループット比率を比較した（図 10（Figure 10））。 ![[_attachments/eGPU---Production-Scale-Elastic-Sharing-over-10000-GPUs/fig10-precise-partitioning.png]] *図 10（Figure 10）: インスタンスの精密なリソース分割（50%/50% 分割時）。eGPU はハードウェアレベルの MIG と同等に正確な 50%/50% のスループット分割を達成する。MPS は干渉によりわずかに偏りが生じ、優先度ベース手法は高優先度インスタンスが独占する。* MIG はハードウェア分離によりほぼ完全な 50%/50% 分割を達成するが、eGPU も FAA により MIG と同等の極めて精密な 50%/50% スループット比率を実現した。これに対し MPS は干渉による偏りが見られ、優先度ベース手法では高優先度側が圧倒的な支配を示した。 さらに、実行中に割り当てリソースを 10% 刻みで増減させた際の学習スループットの変化を評価した（図 11（Figure 11））。 ![[_attachments/eGPU---Production-Scale-Elastic-Sharing-over-10000-GPUs/fig11-adjustment-runtime.png]] *図 11（Figure 11）: 実行時におけるインスタンスサイズの動的調整。(a) 単一タスクのリソース変更（Figure 11a）、(b) 2つの同時実行タスクの個別リソース変更（Figure 11b）。スループットが設定変更に即座かつ滑らかに追従する。* 単一タスクの割り当て変更（Figure 11a）でも、2 つの並行タスクを独立に動的調整した場合（Figure 11b）でも、学習スループットはリソース変更に即座かつリニアに追従し、eGPU が実行時調整を完全に達成できることが実証された。 ### FAA の有効性（Figure 12） 粗粒度のラウンドロビン時間分割（Coarse Slicing）と FAA の比較を行った（図 12（Figure 12））。 ![[_attachments/eGPU---Production-Scale-Elastic-Sharing-over-10000-GPUs/fig12-coarse-vs-faa.png]] *図 12（Figure 12）: 粗粒度タイムスライシングと FAA の性能比較。(a) ResNet-50 学習スループット（Figure 12a）、(b) 推論応答時間（RT）オーバーヘッド（Figure 12b）。FAA はスループットを向上させ、推論遅延オーバーヘッドを平均 10.1%（最大 24.1%）削減する。* 粗粒度スライシングでは学習スループットが 56〜192 ips であるのに対し、FAA では 63〜192 ips に向上した（Figure 12a）。また推論応答時間（RT）のオーバーヘッドは、FAA の導入により平均 10.1%、最大 24.1% 削減された（Figure 12b）。 ### 低オーバーヘッド性の検証（Table II） eGPU の 100% 割り当て時とネイティブ GPU の推論スループットを多様なモデルおよびバッチサイズ（bs=4〜64）で比較した（表 II（Table II））。 | ワークロード | bs=4 (Native / eGPU) | bs=16 (Native / eGPU) | bs=64 (Native / eGPU) | | :--- | :---: | :---: | :---: | | **ResNet-50** | 424.607 / 420.032 | 608.036 / 608.159 | 664.216 / 642.188 | | **BERT** | 41.608 / 41.266 | 44.880 / 44.762 | 45.917 / 45.868 | | **LLaMA** | 0.852 / 0.834 | 2.610 / 2.592 | 5.910 / 5.893 | | **Private User Model 1** | 756.659 / 793.304 | 1203.132 / 1210.332 | 1339.478 / 1346.200 | | **Private User Model 2** | 1048.248 / 1102.955 | 2818.940 / 2900.120 | 4792.150 / 4800.020 | *表 II（Table II）: 各種機械学習ワークロードにおけるネイティブ GPU 対 eGPU の推論スループット（queries/sec）。eGPU のオーバーヘッドは全条件で 4% 未満に収まり、最悪ケースでもネイティブ比 96.7% の性能を維持する。* すべてのモデルおよびバッチサイズにおいて、eGPU のオーバーヘッドは極めて軽微（4% 未満）であり、ネイティブ GPU と同等のスループットを維持した。 ### 推論タスクのSLA保証（Figure 13） インスタンスの GPU 制限レベル（45%〜70%）を設定し、実際の GPU 使用率に対する推論応答時間（RT）を測定した（図 13（Figure 13））。 ![[_attachments/eGPU---Production-Scale-Elastic-Sharing-over-10000-GPUs/fig13-response-time-inference.png]] *図 13（Figure 13）: 推論タスクにおける応答時間（RT）SLA の保証。(a) ResNet-50、(b) BERT-Large。実際の GPU 使用量が要求制限に達するまで RT は一定に保たれ、制限に達した瞬間にのみ急増してリソース境界が厳格に施行される。* 実際の GPU 使用量が要求制限値に達するまで推論 RT は完全にフラットに保たれ、SLA が厳格に遵守される。そして制限値に達した時点で急峻にレイテンシが増加することから、他のインスタンスへ悪影響を及ぼさずに正確なリソース抑制が機能していることが確認された。 ### NVLink による学習高速化（Figure 14） Kubernetes 上で BERT-Large の分散学習（400 ステップ、バッチサイズ 128）を実施し、エンドツーエンド学習時間を比較した（図 14（Figure 14））。 ![[_attachments/eGPU---Production-Scale-Elastic-Sharing-over-10000-GPUs/fig14-nvlink-training-time.png]] *図 14（Figure 14）: NVLink 活用による学習時間の短縮。(a) BERT-Large 分散学習時間の比較（Figure 14a）、(b) 測定された NVLink 通信トラフィック推移（Figure 14b）。通信ボトルネックの解消により、1.21x〜1.31x の学習高速化を達成する。* コンテナ環境で NVLink 通信が阻害される既存手法に対し、eGPU はトポロジ認識 NVLink サポートにより、学習効率を 1.21 倍〜 1.31 倍（21%〜31%）向上させた。 ### ケーススタディと障害隔離（Figure 15, Figure 16, Figure 17） ![[_attachments/eGPU---Production-Scale-Elastic-Sharing-over-10000-GPUs/fig15-17-sharing-priority-fairness.png]] *図 15〜17: LLM 混在推論・優先度ベース共有・障害隔離の評価。図 15（Figure 15）: LLaMA-7B 推論と ResNet-50 学習の共存、図 16（Figure 16）: 推論＋学習の優先度ベース共有実トレース、図 17（Figure 17）: 致命的エラー発生時の障害隔離と GPU 利用率推移。* 1. **LLM ワークロードとの混在（図 15（Figure 15））**: LLaMA-7B 推論と ResNet-50 学習を共存させ、LLaMA への配分を 70% から 30% へ減らすと推論 RT が 8.2 秒から 20.0 秒へ増加する一方、ResNet-50 の学習スループットが向上した。LLM のような巨大モデルでも弾力的なトレードオフ制御が可能である。 2. **優先度ベース運用の実トレース（図 16（Figure 16））**: 画像分類推論（高優先度）が GPU 利用率約 11% で動作中、タイムスタンプ 48 秒で DNN 学習（低優先度）が到着。パーティションを推論 31% / 学習 69% に動的変更した結果、推論の応答時間（20〜24ms）を維持したまま、クラスタ全体の GPU 利用率を約 80% まで跳ね上げることに成功した。 3. **障害隔離の比較（図 17（Figure 17））**: 同時実行中の 1 タスクに致命的エラー（Fatal Error）を注入した。 - **MPS**: 単一コンテキスト共有のため、エラー発生時に GPU 全体がクラッシュし、無関係な正常タスクも道連れに停止した。 - **MIG**: 正常タスクは生存したが、停止タスクのハードウェアスライスが固定されたまま遊休化し、GPU 利用率は 91% から 39% へと急落した。 - **eGPU**: 正常タスクは中断なく継続し、解放された計算リソースを残余タスクが動的に再利用したことで、85% という極めて高い GPU 利用率を維持した。 ### 10 インスタンスの高密度共有（Table III） 単一の NVIDIA H20 GPU 上で、Llama-3.2-1B-Instruct（メモリ 13% 割当）× 5 と Qwen2.5-0.5B-Instruct（メモリ 7% 割当）× 5 の計 10 インスタンスを同時起動し、スループット安定性を検証した（表 III（Table III））。 | タイムスタンプ (s) | 10 | 20 | 30 | 40 | 50 | 60 | 70 | 80 | 90 | 100 | | :--- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | | **1-st Llama** | 23.29 | 23.29 | 23.28 | 23.29 | 23.28 | 23.28 | 23.28 | 23.28 | 23.27 | 23.27 | | **2-nd Llama** | 23.28 | 23.29 | 23.27 | 23.28 | 23.28 | 23.29 | 23.28 | 23.28 | 23.28 | 23.27 | | **3-rd Llama** | 23.29 | 23.29 | 23.28 | 23.28 | 23.28 | 23.28 | 23.28 | 23.28 | 23.28 | 23.27 | | **4-th Llama** | 23.28 | 23.29 | 23.28 | 23.27 | 23.29 | 23.28 | 23.28 | 23.29 | 23.28 | 23.27 | | **5-th Llama** | 23.29 | 23.28 | 23.28 | 23.28 | 23.29 | 23.29 | 23.28 | 23.28 | 23.28 | 23.27 | | **1-st Qwen** | 25.56 | 25.54 | 25.52 | 25.54 | 25.54 | 25.52 | 25.54 | 25.53 | 25.53 | 25.53 | | **2-nd Qwen** | 25.57 | 25.53 | 25.53 | 25.53 | 25.53 | 25.53 | 25.54 | 25.54 | 25.53 | 25.53 | | **3-rd Qwen** | 25.54 | 25.54 | 25.53 | 25.54 | 25.53 | 25.53 | 25.53 | 25.53 | 25.55 | 25.52 | | **4-th Qwen** | 25.54 | 25.53 | 25.53 | 25.54 | 25.55 | 25.53 | 25.53 | 25.54 | 25.52 | 25.52 | | **5-th Qwen** | 25.56 | 25.53 | 25.55 | 25.54 | 25.53 | 25.55 | 25.54 | 25.52 | 25.52 | 25.53 | *表 III（Table III）: 単一 H20 GPU 上で 10 個の同時実行推論インスタンスを稼働させた際の推論スループット（tokens/sec）。Llama の変動幅は 0.1% 未満、Qwen の変動幅は 0.2% 未満に収まり、極めて安定した高密度共有が実証された。* ### 社内本番業務におけるGPUリソース削減実績（Table IV） 社内本番業務において eGPU を適用した際の必要 GPU 台数削減効果を測定した（表 IV（Table IV））。 | ワークロード | ネイティブ必要台数 | eGPU 導入後台数 | 削減倍率（Ratio） | | :--- | :---: | :---: | :---: | | **視覚特徴量処理（Visual Feature Processing）** | 2,000 台 | 250 台 | **8.0x** | | **テキスト生成（Text Generation）** | 1,500 台 | 190 台 | **7.9x** | | **動画タグ生成（Video Tag Generation）** | 100 台 | 50 台 | **2.0x** | | **コンテンツ分析（Content Analyzing）** | 90 台 | 30 台 | **3.0x** | *表 IV（Table IV）: eGPU 導入による GPU 資源の節約効果。視覚特徴処理で最大 8 倍、テキスト生成で 7.9 倍の GPU 台数削減を達成した。* ### 1万台規模の本番クラスタ展開実績（Figure 18, Figure 19） eGPU は 2020 年 4 月に初配備されて以来、4 年以上にわたり本番運用規模を拡大し続けている（図 18（Figure 18））。 ![[_attachments/eGPU---Production-Scale-Elastic-Sharing-over-10000-GPUs/fig18-active-instances.png]] *図 18（Figure 18）: 稼働 eGPU インスタンス数および正規化クラスタ GPU 利用率の推移（2020年4月〜2023年4月）。インスタンス数は 10 から 10,000 超へ成長し、クラスタの平均・ピーク GPU 利用率ともに 3 倍以上の向上を達成した。* 稼働インスタンス数は 2020 年 4 月の 10 インスタンスから 2023 年 4 月には 10,000 インスタンスを突破した。これに伴い、クラスタ全体の GPU 利用率は平均・ピークともに配備前比で **3 倍以上** 向上した。 ![[_attachments/eGPU---Production-Scale-Elastic-Sharing-over-10000-GPUs/fig19-heterogeneous-gpus.png]] *図 19（Figure 19）: クラスタ内の異種 GPU 展開比率。H20（30%超）、A10（約22%）、T4（16%）、A100（7%）、V100（5%）、その他（18%）と多世代にわたるハードウェアを統一サポートする。* 図 19（Figure 19）に示すように、展開先 GPU は H20（30%超）、A10（約22%）、その他（18%）、T4（16%）、A100（7%）、V100（5%）など多岐にわたり、合計で 1 万台を大幅に超える異種混合 GPU クラスタで安定稼働を続けている。 ## 考察と運用上の教訓（Lessons Learned） 著者らは 5 年間の本番運用を通じて、以下の 3 つの決定的な教訓を報告している。 ### 教訓1: 動的需要変動への適応と短時間カーネルの現実（Lesson 1） - **潮汐型（tide-style）の需要変動**: 本番クラスタの GPU 需要は昼夜で周期的に激しく変動する。当初検討した MIG は、構成変更に GPU リセット（再起動）を要し、NVLink も使えないため本番の動的環境に耐えられなかった。 - **短時間カーネルの支配**: 85% 以上のカーネルが 0.1ms 未満で完了するため、個々のカーネルの実行時間を制御しようとする従来のアプローチは破綻した。大量に反復される短時間カーネル群を細粒度タイムスライス（FAA）で確率的・偏差最小化により制御することが、実運用で唯一有効な解法であった。 ### 教訓2: 効率性と応答性の両立 — 高速GPUにおけるCPUボトルネックの逆転（Lesson 2） - **高速アクセラレータによる CPU ボトルネック化**: A100 などの先進 GPU を導入した際、GPU 側のカーネル実行が極めて高速化したため、CPU 側で動作する eGPU の API インターセプト処理が追いつかず、CPU が全体のボトルネックになるという逆転現象（パラドックス）が発生した。 - **マルチスレッド並列化による解決**: eGPU プロセス内にスレッド並列処理を導入し、CPU 側処理能力をスケールさせることでボトルネックを解消した。 - **パーティション精度と SLA の優先順位**: パーティション分割精度を極限まで高めても、ユーザ SLA を損なえば実運用では無意味である。SLA 遵守を第一の制約とした上でリソース配分を最適化する重要性が実証された。 ### 教訓3: 異種環境への適応とOCI標準コンテナ統合（Lesson 3） - **コンテナイメージ無改造の鉄則**: 初期の eGPU はプラットフォーム提供コンテナに依存し、起動スクリプトの修正を必要としていたため、起動遅延とプラットフォーム結合度の問題が生じた。 - **eGPU Container Toolkit による注入**: OCI 標準に準拠したツールキットを開発し、コンテナ起動時にランタイムライブラリを動的注入する方式へ移行したことで、イメージ変更なしの完全なユーザ透過性と高いスケーラビリティが確立された。 ### 障害隔離と今後の展望（Future Directions） - **CUDA コンテキストによるプロセス分離**: eGPU は各コンテナに対して独立した CUDA コンテキストを割り当てるため、CPU プロセスと同等の高いメモリ・データ隔離が保たれており、5 年間の運用で十分なセキュリティと耐障害性が実証されている。 - **空間・時間ハイブリッド共有への拡張**: eGPU の時間分割（FAA）は既存の空間分割機構（MPS や MIG）と直交しており、高信頼環境での eGPU + MPS や、強隔離環境での eGPU + MIG という空間・時間統合共有システムの構築が、データセンター GPU 共有の有望な次世代の道筋として提起されている。 ## 出典 - [[.raw/papers/eGPU---Production-Scale-Elastic-Sharing-over-10000-GPUs.pdf]] - [[.raw/papers/eGPU---Production-Scale-Elastic-Sharing-over-10000-GPUs.txt]] - [[@2022__NSDI__MLaaS in the Wild - Workload Analysis and Scheduling in Large-Scale Heterogeneous GPU Clusters]]（Alibaba PAI トレース） - [[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]]（Philly トレース） - W. Xiao et al., "AntMan: Dynamic Scaling on GPU Clusters for Deep Learning," OSDI 2020. - A. Gujarati et al., "Serving DNNs like Clockwork: Performance Predictability from the Bottom Up," OSDI 2020. - M. Han et al., "Microsecond-scale Preemption for Concurrent GPU-accelerated DNN Inferences," OSDI 2022 (REEF). - B. Wu et al., "Transparent GPU Sharing in Container Clouds for Deep Learning Workloads," NSDI 2023 (TGS). - S. Choi et al., "Serving Heterogeneous Machine Learning Models on Multi-GPU Servers with Spatio-Temporal Sharing," USENIX ATC 2022 (GPUlet). - F. Strati et al., "Orion: Interference-aware, Fine-grained GPU Sharing for ML Applications," EuroSys 2024. - NVIDIA Multi-Instance GPU (MIG) User Guide & Multi-Process Service (MPS) Overview