
拓海先生、最近部下から「GPUを効率的に使える仕組みを導入したい」と言われまして、サーバーレスで深層学習の推論を安く回せるという論文があると聞きました。要点をかみ砕いて教えていただけますか。

素晴らしい着眼点ですね!端的に言えば、この論文はサーバーレス環境でGPUをもっと細かく分け合い、コストを下げつつ性能の約束(SLO: Service Level Objectives)を守る仕組みを提示しています。大丈夫、一緒に整理していきますよ。

サーバーレスというのは確か支払いが使った分だけでいい仕組みでしたね。で、GPUを分けるって具体的にどういうことですか。社内の工場で言えば機械を共同利用するようなイメージですか。

その通りです。Function-as-a-Service (FaaS)(FaaS, サーバーレス実行基盤)で複数の関数が同じGPUを時間や領域で細かく分け合う、いわば工作機械を時間帯とスペースでシェアするイメージです。これにより遊んでいるGPU資源を減らせますよ。

ただ、現場では性能の約束(SLO)が重要です。安く回すために他の仕事と共有して遅延が出たら困ります。どうやって遅延を防ぐのですか。

良い質問です。論文は三つの柱で対応します。1つ目はFaST-Managerと呼ぶ制御層で、GPUの領域と時間を区切って分離(isolation)すること、2つ目はFaST-Profilerで実際に関数の性能を計測してどの割当てでSLOが守れるかを学ぶこと、3つ目はFaST-Schedulerでプロファイルに基づいて自動配分とノード選定を行うことです。

これって要するに、最初にどれだけ資源を割り当てるかを決めて、実績に応じて増減する自動運転みたいなものですか。それとメモリ競合の問題も出るんじゃないですか。

まさにそのイメージです。FaST-GShareは静的な大きな割当てではなく、細かく区切った初期割当てから実績で動的に再配分します。メモリ競合(GPU memory contention)にはモデル共有(model sharing)という工夫で、同じモデルを共有して二重に読み込まない仕組みを入れて軽減していますよ。

なるほど。で、実際の効果はどのくらい出るのか、数字で示せますか。うちの投資判断で重要なのは改善率です。

良い着眼点ですね。論文のプロトタイプ実験では、従来の単純な時間分割(time sharing)と比べ、スループットが平均で3.15倍、GPU利用率が平均で1.34倍、SM(Streaming Multiprocessor、GPU内演算ユニット)占有率が平均で3.13倍改善したと報告しています。投資対効果の判断材料には十分使える数字です。

導入のハードルはどこにありますか。クラウドの仕組みに依存する部分が大きければ外部に委託するしかないと思うのですが。

確かに実装は簡単ではありません。論文はOpenFaaS上でのプロトタイプを示しており、既存クラウドのFaaSが提供するインスタンス単位のスケーリングと完全に整合しない点を指摘しています。そのため既製のマネージドサービスだけで完結するケースは限られ、社内環境や専用レイヤーの検討が必要です。

最後に私の理解を確認させてください。要するにFaST-GShareは、GPUを細かく時間と領域で分割して複数関数で共有させ、性能を測る仕組みで配分を決めて、メモリはモデル共有で抑えつつSLOを守るようにスケジューリングする仕組みということでよろしいでしょうか。自分の言葉で言うとこうなります。

素晴らしい要約です!その理解で正しいですよ。では、会議で使える短い要点を3つでまとめますね。1) GPUを時空間で細かく共有して無駄を減らす、2) 実測に基づくプロファイリングでSLOを保証する、3) メモリ競合はモデル共有で緩和する、です。大丈夫、一緒に取り組めば必ず導入できますよ。


