【ITニュース解説】Restoring a grant is not restoring capacity

システムエンジニアを目指す皆さんにとって、AI推論エンジンの効率的な運用は興味深いテーマでしょう。今回の記事は、「MoFlux」という仕組みがAIモデルを動かすシステムのキャパシティ（処理能力）をどのように管理し、特にインタラクティブな処理が戻ってきたときのシステム復旧にどのような課題があるのかを深掘りしています。

MoFluxは、AI推論エンジンの手前に位置する「アドミッションコントロール層」と呼ばれるものです。例えるなら、コンサート会場の入場ゲートの役割を果たします。推論エンジンは、皆さんが普段使うChatGPTのようなAIモデルの計算を実行する心臓部分であり、限られた処理能力を持っています。MoFluxの主な目的は二つです。一つは、ユーザーからの直接的な問い合わせなど、応答速度が求められる重要な処理（インタラクティブトラフィック）のために一定のキャパシティを「保護」すること。もう一つは、その保護されたキャパシティが一時的に使われていないアイドル状態のときに、報告書作成のような応答速度が緩やかな「バッチ処理」にそのキャパシティを一時的に「貸し出す（lending）」ことです。これにより、貴重な計算資源を無駄なく活用しようとします。

しかし、インタラクティブトラフィックが戻ってきたとき、貸し出したキャパシティがすぐに使えるようになるかは重要な問題です。記事では、「キャパシティが復元される」という言葉が、実際には三つの異なる、そしてそれぞれ時間のかかるイベントを指していることを明らかにしました。

まず一つ目は、「グラント（許可）が回復する」イベントです。これは、MoFluxの入場ゲートが、保護すべきインタラクティブなリクエストを再び「通していいよ」と許可を出す状態に戻ることです。実験では、インタラクティブな需要が検知されてから、この許可が戻るまでにかかる時間は約1秒以内でした。これは比較的素早く行われる部分です。

二つ目は、「借りた占有（borrowed occupancy）が解消される」イベントです。これは、貸し出されたキャパシティで実行されていたバッチ処理が、すべて終了して本来の割り当てに戻ることを意味します。コンサート会場の例で言えば、休憩中に貸し出していたスペースから、貸していた人たちが全員出ていくのを待つようなものです。このイベントにかかる時間は、バッチリクエストの性質によって大きく異なりました。短いバッチリクエストの場合で最大4秒、長いバッチリクエストの場合では最大20秒もかかりました。これは、MoFluxが実行中のバッチ処理を強制的に中断させる（プリエンプション）ことはせず、あくまで自然に終了するのを待つためです。特に、大量のメモリを使うような長いバッチ処理が残っている場合、その解放に時間がかかるため、インタラクティブな処理が使えるようになるまでにかなりの時間を要する可能性が示されました。

三つ目は、「エンジンが戻ってきたリクエストをスケジュールする」イベントです。これは、MoFluxの許可を得て、かつ借用占有も解消された後に、実際に推論エンジンがインタラクティブなリクエストの処理に取り掛かるまでの時間です。記事の実験では、グラントが回復してから実際にエンジンがスケジューリングを開始するまで、さらに3.6〜4.0秒の待ち時間が発生するケースがありました。これは、推論エンジン自体が、リクエスト全体を処理するために必要なメモリや計算資源が確保できるまで、リクエストをキューに入れて待たせる仕組みになっているためです。MoFluxのようなアドミッションコントロール層は、エンジンの内部的なスケジューリングには直接介入できないため、この待ち時間は避けられない課題となります。

これらの実験は、Apple M1チップを搭載した一台のコンピューター上で、vLLMという推論エンジンとQwen2.5-1.5Bという小規模なAIモデルを使って行われました。MoFluxだけでなく、先着順（FCFS）、優先度順（Priority）、固定パーティション（Static）といった他のキャパシティ管理方法も同時にテストされました。特に「ワークロード」の違いが結果に大きく影響しました。短いバッチリクエストを使う「Balanced」ワークロードと、大量のメモリを消費する長いバッチプロンプトを使う「Long-context」ワークロードの二種類で比較されました。

結果として、MoFluxはアイドル時にバッチ処理の完了数を増やすというメリットをもたらしました。これは、キャパシティを効率的に利用するという当初の目的を達成したと言えます。しかし、その代償として、インタラクティブなリクエストが時間通りに処理される割合は、固定パーティションやネイティブの優先度スケジューリングと比較して劣るケースが多く見られました。特に、借りた占有の解消に時間がかかる場合（長いバッチリクエストのとき）は、インタラクティブな処理の遅延や失敗が顕著になりました。これは、システムが一時的にバッチ処理に多くのリソースを貸し出しすぎると、いざ重要なインタラクティブ処理が戻ってきたときに、すぐに「本業」に戻れないというジレンマを示唆しています。

記事では、まだ解決されていないいくつかの疑問も提起しています。一つは「いつ貸し出しを再開すべきか？」という問いです。インタラクティブトラフィックがアイドルになった瞬間にすぐに貸し出しを始めると、以前の貸し出しによるバッチ処理がまだ終わっていない状態で、次の貸し出しが始まる可能性があります。これにより、システムが完全に回復する前に再び貸し出しが行われ、復旧がさらに遅れる悪循環に陥る可能性が指摘されています。もう一つは、「アドミッション境界（MoFluxの制御）がエンジンのスケジューラにどう影響するか？」という疑問です。MoFluxが厳しくリクエストを制限していると、推論エンジン自体のキューがほとんど空になり、エンジン内の優先度スケジューラがあまり活躍しない可能性があります。境界を緩めてエンジンに少し余裕を持たせることが、全体のパフォーマンスにどう影響するかは、まだ今後の研究課題です。

この研究にはいくつかの限界があります。実験は単一のホスト、小規模なモデル、そして特定のハードウェア環境（Apple M1とMetal）で行われたため、この結果が一般的な大規模AIシステム全体にそのまま当てはまるわけではありません。また、データのサンプリング頻度や、「キャパシティが解放された」という状態の定義にも限界があり、推論エンジンが実際にリソースを解放したかまでは厳密には示されていません。MoFluxがGPUメモリやKVキャッシュを能動的に「取り戻す」あるいは実行中の推論を「プリエンプト（強制終了）」する機能は、この記事で検証された範囲には含まれていません。

これらの結果は、AI推論システムの設計がいかに複雑で、様々な要素がパフォーマンスに影響を与えるかを示しています。限られたリソースの中で、応答速度を求めるインタラクティブな処理と、効率性を求めるバッチ処理のバランスをいかに取るかは、今後のシステムエンジニアにとって重要な課題となるでしょう。単に「貸し借り」をするだけでなく、その復旧のタイミングや方法をより賢く制御する仕組みが求められています。