はじめに
コンピューティング研究所の高品・粟本です。 この記事では、富士通研究所で開発している ACB (AI computing broker) という、 AI アプリケーションに対して GPU を効率的に割り当てる技術について説明します。
さらに、昨今急激に重要度を増している LLM 推論サービスの運用に ACB を活用する最新デモをご紹介し、より少ないハードウェア投資で多数の LLM をデプロイできることを示します。
以前 の Tech blog でも何度か ACB についてご紹介させていただいております。以下のエントリも追加でご覧いただくとより深く理解していただけるのではないかと思います。
ACB の概要
AI の効率的な実行のために GPU による計算は欠かせないものです。 一方、 GPU はその性能の高さと急激な需要増加から高価な資源となっており、多くの企業にとってインフラコストのボトルネックとなっています。 ACB は GPU の利用効率を最大限高め、限りある GPU 資源の上でできるだけ多くのワークロードを実行できるようにすることを目指した技術です。
ACB は従来のGPU資源の割当方法によって生じるGPU利用率低下に注目し、 GPU の割り当て戦略を見直すことで GPU 利用率の向上を図ります。 このことを、以下の図 1 で説明します。
従来の AI ジョブ実行における GPU 割り当てにおいては、GPU リソースをジョブの開始から終了まで占有する方式が一般的でした (図 1 上)。 複数ジョブで GPU の利用が干渉するとコンテキストスイッチ等による性能低下を引き起こしやすくなるほか、複数ジョブによるメモリ確保の衝突から GPU メモリ不足等を引き起こしてジョブの実行が失敗してしまうこともあります。 このような問題を避けるため、ジョブ全体にわたって GPU を占有させるように保守的に割り当てを行うのです。
一方で、AI ワークロードでは多くの場合 CPU 処理 (データロード等の I/O, 前処理, etc) と GPU 処理 (学習, 推論) が混在しています。従来のような保守的な割り当ての場合、 GPU を実際には利用していない CPU 処理の時間も GPU を占有し続けることになり、 GPU が利用されないアイドル時間が長くなってしまいます。
ACB は GPU が実際に必要な時間だけジョブに割り当てることで、余計な GPU の確保を減らし利用効率を向上させます (図 1 下)。 ここで「ACB を利用した場合にはアプリケーション間の GPU 利用が干渉してしまうことは無いのか」という疑問が浮かんでくるかもしれません。 ACB は以下のような点を管理することによって GPU 利用の干渉を防ぎ、安全にアプリケーションを実行することを可能にしています。
- GPU の計算が重複しないように割り当て期間を管理する
- GPU メモリ不足を起こさないように GPU 上のデータを必要に応じて退避させる
このように、 ACB は GPU 利用の干渉を防ぎつつ、最大限 GPU の割り当て機会を増やすことで利用効率を向上させる技術になっています。
参考: 他のリソース管理システムとの比較
GPU 等計算クラスタのリソース管理でよく使われるシステムとしては Slurm があります。 こちらはジョブごとに資源を占有させる方式のもので、上であげた従来の割り当て方法にあげた課題が当てはまります。
また、近年では Kubernetes が GPU クラスタ管理に用いられるケースも多くあり、 Run:ai のような Kubernetes との統合にフォーカスした AI 向けのリソース管理ソフトウェアも登場しています。 Kubernetes を用いた場合でもジョブ (Pod) ごとに既定された量のリソースを占有させるという仕組みは基本的に変わりません。 資源利用効率を高めたい場合には、 MIG 等を用いて GPU を物理的に小さな単位に分割するという方針を考えることになります。 しかし MIG によって GPU リソースを分割した場合には、分割後のサイズによってジョブの規模が制約されることになるため、大きなサイズのジョブを実行することはできなくなってしまいます。 また、ジョブの種類によって計算コア, メモリ使用量に差があるような不均一なワークロードに対しての対応も難しくなります。
ACB の構成
前節では、 ACB がどのような GPU 割り当て戦略によって利用効率を向上させるかを説明しました。 今度は実際にどのような仕組みで GPU の割り当てを実現しているのか技術的な側面に焦点を当てて見ていきます。
全体アーキテクチャ
ACB は複数アプリに対する柔軟な GPU 割り当てを実現するために、クライアント・サーバーアーキテクチャを採用しています。全体アーキテクチャを図 2 に示します。
ACBの主要なコンポーネントとその役割は以下の通りです。
- GPU Assigner (server): マシンに搭載されている GPU を管理するコンポーネントです。 利用可能なGPUの検出、各アプリへの GPU 割り当ておよび割り当て状態の管理を行います。
- ACB クライアント:
アプリケーション側に組み込まれ、アプリケーションと GPU Assigner 間の橋渡しを行います。
ユーザーが
agarunというスクリプトを用いてアプリケーションを立ち上げると、アプリケーションは GPU assigner と通信し、 GPU を適切に割り当てられたタイミングで使用することができます。
クライアント・サーバー間の通信インターフェースは、 gRPC で定義されています。 gRPC は protocol buffer というバイナリフォーマットを用いた高性能な RPC フレームワークです。 宣言的に通信インターフェースを定義することが可能で、通信メッセージの拡張等にも対応しやすくなっています。 クライアント・サーバー間は gRPC によるメッセージのやりとりだけ行うことができれば良いので、各アプリケーションや GPU assigner はそれぞれコンテナ, VM 等隔離された環境で実行することも可能です。
GPU の割り当てはアプリ内のひとかたまりの GPU 処理に対応するリクエスト単位で行われます。 このリクエストベースの割り当てモデルにより、従来よりも細かい単位で柔軟に GPU 割り当てを行うことが可能となり、 GPU 利用率の向上につなげることができます。
既存アプリケーションとの統合
ACB のようなリソース管理を導入するとき、既存のアプリケーションを実行対象としたいことが多くなるでしょう。 しかし、ACB を前提としない既存アプリケーションが勝手に GPU assigner と適切なタイミングで通信してくれるわけではありませんから、アプリケーションコードを変更せずに ACB と統合することは容易なことではありません。 工数や安定性の面で既存アプリケーションへの変更はできるだけ避けたいことであり、アプリケーションはそのままで ACB と統合できるような仕組みが望まれます。
ACB ではこの課題を PyTorch のフック機構を活用することで解決しています。 PyTorch は非常に多くの AI アプリケーションで採用されるフレームワークであり、デファクトスタンダードとなっています。 図 3 に示したように、ACB クライアントはフック機構を用いて PyTorch の特定 API 呼び出しを検知します。これにより、アプリケーションが GPU を必要とするタイミングを自動的に捉え、その裏で GPU Assigner へのリソース割り当て要求を行う通信を透過的に挿入することが可能になります。
このアプローチにより、既存のアプリケーションに全く変更を加えることなく ACB と統合することができます。 一例として、 OpenFold というタンパク質の構造予測を行うアプリケーションにおいて、アプリケーション側に全く変更を行わずに ACB と統合できることを実証しました (SC '24 デモ 参照)。 このように既存のアプリケーションをそのまま使えることは、導入の障壁を下げる大きなメリットといえます。
多くのユースケースにおいては、上述のような透過的な統合機能によって効果が期待できます。 さらに細かい制御やより高い性能を求める場合には、アプリケーションコードに数行から数十行程度の変更を加え、ACB の通信 API 呼び出しを手動で追加することも可能です。 これにより、アプリケーションの特定の処理フェーズに合わせてGPUリソースの要求と解放を明示的に制御し、より精密な最適化を実現することができます。
vLLMを用いたLLM推論サービスにおけるGPU利用率の最適化
大規模言語モデル（LLM）の活用が広がるにつれて、その推論サービスの運用におけるGPU利用率の最適化が重要な課題となっています。特に、セキュリティ、レイテンシ、コスト、カスタマイズ性といった要因から、クラウドベースのLLMではなく、オンプレミスやプライベートクラウドにローカルLLMを導入したいという需要は根強くあります。しかし、ローカルLLMの運用する上で、GPUリソースを効率的に活用する事は容易ではありません。
LLM推論サービスの運用における課題
ローカルLLM環境では、複数のドメイン特化型LLMモデルをデプロイするケースが多く見られます。このような状況では、特定のモデルへのリクエストが集中する一方で、他のモデルへの需要が低いといった、モデル間の需要の不均衡が頻繁に発生します。また、RAG（Retrieval Augmented Generation）のような、I/O待ちが発生する処理を含むLLMを用いる場合、リクエストが途切れるとモデルがアイドル状態になってしまいます。
これらの状況（モデル間の需要の不均衡やI/O待ちによるアイドル状態）は、結果としてGPUリソースが十分に活用されず、GPU利用率の低下を招きます。推論エンジン（例：vLLM）をリクエストごとに再起動し、必要なモデルをその都度ロードすることも考えられますが、モデルのロードや初期化にかかる起動コストが大きく、現実的な選択肢ではありません。そのため、需要がないモデルであっても、常にGPU上にロードしておく必要が生じます。しかし、これには大量のGPUメモリと、それに伴う大量のGPUが必要になります。例えば、それぞれ4GPUを使用するモデルAとモデルB、そして8GPUを使用するモデルCを同時にサービス提供する場合、各モデルの需要に関わらず、合計16台のGPUが必要となります。利用率の低いGPUを大量に抱えることは、インフラコストの増大に直結します。
ACBを用いたLLM推論サービスの課題解決
上記のような、GPUがアイドル状態になることによる利用率低下と、それに伴うインフラコストの増大という課題に対し、富士通研究所では、広く使われているLLM推論エンジンであるvLLMと、ACB を連携させる技術を開発しました。
ACBとvLLMを組み合わせることで、以下のようなメリットが得られます。
- インフラコストの削減と柔軟なモデル運用: モデルの需要変動に合わせてGPUリソースを柔軟に割り当て・解放できるため、GPUの利用率が向上し、必要なGPUリソースを削減できます。これにより、インフラコストの最適化が可能になります。
- コールドスタートの不要化: モデルがGPU上に常駐せずとも、必要な時に動的にロード・アンロードされるため、モデルの切り替えや新規リクエストに対するコールドスタートが不要になり、レスポンスタイムの改善に貢献します。
ACBとvLLMを組み合わせたデモ
実際にACBとvLLMを組み合わせて、必要となるGPU数を削減できる事をデモンストレーションした動画が以下の通りです。（この動画はACB全体の紹介動画であり、デモンストレーション部分は2分47秒～4分4秒となります。）
デモ環境として、4GPUを搭載したサーバーを2台用意しました。ワークロードとして、それぞれ4GPUを使用するモデルAとモデルB、そして8GPUを使用するモデルCを同時に稼働させました。これらのモデルはRAGを併用しているため、I/O待ちの間はGPUがアイドル状態になるという特徴があります。
ACBを使用しない従来の運用では、4GPUのモデルAとB、8GPUのモデルCを同時に動かすには、それぞれ専用のGPUリソースが必要となるため、合計16GPUが必要となります。しかし、ACBとvLLMを組み合わせることで、動的にGPUリソースを共有・切り替えることが可能となり、同等のワークロードを8GPUしかないデモ環境で動作させられることを示しました。
β 版公開中！
この記事では ACB の構成やデモについて紹介させていただきました。 現在 Fujitsu Research Portal にて ACB の β 版を公開中です。 技術的により詳しい内容を記述した Technical White Paper もご覧いただけます。
ご興味いただけた場合は、以下のリンクよりお試しください。 5 つの technology から "Computing" を選択いただくと、 AI computing broker のページが見つかるはずです。
