アイドル状態の Inference GPU Pool を活用した GPU ジョブスケジューリング

アイドル状態の Inference GPU Pool を活用した GPU job スケジューリング: LG AI研究院のインフラ効率化事例

LG AI研究院 Platform&Infra Team が公開した今回の記事では、大規模言語モデル（LLM）サービスの運用過程で発生するアイドル GPU リソースを、研究・実験作業にどのように再活用したかを扱っています。AI サービス運営企業は通常、トラフィックのピークを基準に GPU をあらかじめ確保しておくため、トラフィックが減る時間帯には高価な GPU がメモリだけを占有したまま遊休状態になります。研究院は、この空き時間帯の GPU を学習・評価用ジョブに自動割り当てするパイプラインを構築し、追加設備の購入なしに計算資源を確保する成果を上げました。

中核となる問題定義

• LLM サービスのオートスケーリングの限界: 一般的な Web サービスと異なり、LLM は入力・出力トークン長やモデル構造によって、1 リクエストあたりの GPU 消費量が大きく変動します。そのため、CPU 使用率やメモリ占有率といった従来指標では実際の負荷を測定しにくいという課題があります。
• アイドル資源の規模: レプリカ（サービスインスタンスの複製）1 つが GPU 4 基を使う環境で、夜間の非混雑時間帯（20 時〜翌 8 時）には、1 日平均 52 基の GPU が約 12 時間アイドル状態でした。

解決方法

• vLLM の内部指標を活用: 一般的なシステム指標の代わりに、LLM 推論エンジン vLLM が提供するリアルタイムのスループットやキュー待機状況などの指標をオートスケーリング基準とし、LLM の特性に合った精密なリソース調整を実装しました。
• Best-effort 方式のジョブ実行: 夜間のアイドル GPU で研究ジョブを動かしつつ、トラフィックが再び増えればいつでも研究ジョブを中断してサービス側へ GPU を戻せる構造に設計し、サービスの安定性を損なわないようにしました。
• Argo Workflows ベースのパイプライン: Docker イメージ単位でジョブを定義し、データ前処理・事前学習・教師あり微調整・強化学習・評価などをステップ（段階）に分け、逐次または並列で実行できるようにしました。

設計原則の特長

• 汎用性: 学習でも推論でも、どのフレームワークであっても Docker イメージで包めばそのまま実行できます。
• 拡張性と柔軟性: 新しいジョブ種別が追加されても、パイプラインコードを修正せずに受け入れられます。
• 再現性: すべての設定をコードではなく外部パラメータとして注入し、入出力はクラウドストレージで管理することで、同一条件なら同一結果が保証されます。パイプラインが状態を保持しない Stateless 構造である点も、運用安定性に寄与します。

運用結果

• 累積使用量: 2025 年 11 月から 2026 年 1 月までの約 3 か月間で 85 件のジョブが実行され、累積 GPU 使用量は 95,000 GPU 時間に達しました。
• 増加傾向: 1 月の GPU 使用量は 11 月比で約 70% 増加し、24 時間換算では新たに約 55 基の GPU を確保したのと同等の効果を生みました。
• コスト削減: 同じ計算量をパブリッククラウドの 3 年契約基準で換算すると、1 月単月で約 7,500 万ウォン、3 か月累計で約 1 億 8,500 万ウォン規模の削減効果がありました。

今後の計画

• スケーリング指標の高度化: サービスごとの利用パターンをさらに細分化し、リソース割り当てロジックを精緻化する予定です。
• 常時スケジューリングの拡大: Kubernetes と独自モデル EXAONE を活用し、夜間だけでなく、リソースが空き次第すぐにジョブを起動する常時実行体制へ拡張したい考えです。
• UX 改善: 研究者がジョブ申請からモニタリングまでを直感的に行えるインターフェースを用意する計画です。

今回の事例は、GPU 不足という業界共通の課題を、ハードウェア増設ではなく運用構造の改善で解決した試みという点で示唆に富みます。特に、LLM サービス特有の負荷測定の難しさを vLLM の内部指標で回避し、研究ジョブを Best-effort とすることで、サービス安定性とリソース活用率という相反する 2 つの目標を同時に追求したアプローチが目を引きます。追加投資なしで約 1 億 8,000 万ウォン台のコストを削減したという定量的成果は、GPU インフラを運用する他組織にとっても十分参考になる運用モデルを提示しています。