同じクラスタで稼働率33ポイント向上、変えたのは割り当て順序だけ

何が起きたか

Hugging Faceのブログで、GPU割り当ての順序を変えるだけでクラスタの効率が大きく変わるという実験結果が報告されました。記事を書いたのはDharma-AIで、制約対応GPUアロケータをFIFOスケジューラと比較しています。同一ハードウェア上で同じワークロードを実行し、割り当ての判断順序だけを変えたところ、GPU稼働率は最大で33ポイント向上しました。

優先度で重み付けしたアウトプットは、7つのベンチマークシナリオすべてで向上し、最大で105%増えたと報告されています。ハードウェアは一切変更しておらず、変わったのは割り当て判断の順序だけです。この記事は前回の続編として書かれており、今回は割り当ての仕組みそのものの設計が解説されています。

問題は「順序」にある

記事は「GPUを遊ばせない」という方針だけではシステムは実行できないと指摘します。どのGPUで、どのジョブを、どの時点で、どの優先度で実行するかという、1つ1つの2値判断の集まりが割り当て問題です。ここで登場するワークロードは、訓練・リアルタイム推論・バッチ推論・量子化の4種類に分けられます。

このうち訓練・バッチ推論・量子化は、開始すると終了まで連続したGPUブロックを占有する「バッチ型」です。一方のリアルタイム推論は、トラフィックに応じて毎時点で需要が増減する伸縮型です。互いに両立しにくい2つの形状が同じGPUを取り合うことが、問題の核心だと説明されています。

FIFOが稼働率を下げる仕組み

比較対象のFIFOスケジューラには、2つの非効率があると記事は分析します。1つはリアルタイム推論の予約を固定することです。リアルタイム推論は待機を許されないため、FIFOではその日の最大需要分のGPUを1日中確保します。たとえば昼に6基、午前4時に2基必要なアプリケーションは1日6基を保持し、使われない4基が終日ほかのジョブに使えません。

2つ目は到着順の割り当てです。優先度が高いジョブでも、先に来たジョブの後ろに並びます。収容できるかどうかは容量だけでなく順序で決まるため、先約が後から来るジョブの形に合わない配置を占めてしまうと、GPU時間が未使用のまま残ります。予約による固定は混雑していなくても発生し、競合が起きると顕在化すると指摘されています。記事の計測では、予約が支配的な2つのシナリオで稼働率は51.6%と53.6%にとどまりました。

制約モデルとヒューリスティック

記事は割り当て問題を5つの制約で定式化しています。1つのGPUは同時に1ジョブのみ、各ジョブは需要範囲を守る、バッチ型は2のべき乗サイズの連続ブロックを使う、リアルタイム型は隣接時点間のGPU交換数に上限がある、開始済みジョブは中断できない、という内容です。目的関数は、バッチ型への割り当てを優先度と時間減衰の積で報酬化し、リアルタイム需要の未達には割り当て報酬の5〜10倍のペナルティを設定します。この重みの比率がサービスレベルのポリシー全体を1つの数値で表しており、レイテンシ義務が割り当てと同じ最適化の中で担保される仕組みです。

この問題はNP困難で、ジョブが到着するたびに再計算する必要があります。そこで実装は、ヒューリスティックを高速経路に置き、正式モデルを仕様として背後に置く2層構成になっています。ヒューリスティックのルールは正式モデルの制約をそのまま実装したもので、生成される割り当ては常に制約を満たす設計です。システムには高速モードとフルモードの2つがあり、フルモードは高速モードの配置を起点に正式モデルが改善を試みる形式で、定期レビュー向けとされています。処理時間は競合シナリオで1〜2ミリ秒、64GPU・30ジョブでは15ミリ秒です。

稼働率と価値は別物

結果は7シナリオ中6つで稼働率が向上し、残る1つは同率でした。優先度加重出力は全7シナリオで向上しています。特筆すべきは、稼働率が同じでも価値が変わった点です。64GPU・30ジョブのスケールテストでは、稼働率はFIFOと同じ44.9%、完了ジョブ数も同じ27件でしたが、優先度加重出力は15.9%増えました。

一様優先度テストでは、全ジョブの優先度を同じにしても、稼働率は76.8%から87.5%に向上し、価値も23.1%増えています。優先度による並べ替えだけでなく、割り当て全体を見通して計画することが効果を持つことを示しています。一方で、記事は各ジョブの所要GPU時間とリアルタイム需要の予測が正確でなければこの仕組みは機能しないとも注意しており、需要予測の専門化の議論は後編で扱われる見込みです。