LLMエージェントがHPCジョブを異種クラスターへ投入、記述的なハードウェアデータで成功率が48%から87%に向上

Lawrence Livermore National Laboratoryの研究者らは8月12日、「ジョブ要件の理解」と決定論的なスケジューリングおよび投入メカニズムを分離した、エージェント型HPCジョブディスパッチ実験を公開した。オープンソースの[Resource Secretary](https://github.com/converged-computing/resource-secretary)は、CPU、GPU、メモリ、ネットワーク、コンテナ、および10種類のworkload managerを検出し、利用可能な操作をMCPツールに似た関数として公開する。エージェントは自然言語の意図をジョブ仕様に変換し、ジョブを投入してステータスとログを読み取り、最後にFlux APIで検証可能なjob receiptを返す。

最初のテストでは、チームは5ノードのEKS／Flux環境でLAMMPSを実行し、workload manager、リソース、アプリケーション設定、追加フラグ、4種類のプロンプトスタイルを組み合わせ、合計432件のジョブを投入した。そのうち423件が正常に完了し、成功率は97.9%だった。9件の失敗には、フラグとファイル名の誤った連結、`False`の挿入、再試行時に320-taskのジョブを単一ノードへ縮小したことによるタイムアウトが含まれていた。これは、ログ監視とパラメーター検証によって、エージェントが「完了した」と口頭で主張するだけの挙動を抑制できる一方、コマンドライン構文やリソース数のチェックを代替するものではないことを示している。

第2の実験では、219個のコンテナを11個のアプリケーションに集約し、AWSとGoogle Cloud上の計6つの3ノードクラスターにデプロイした。ハードウェアはamd64、arm64、EFA、異なるメモリ構成にまたがり、1時間当たりのコストは0.29～3.78米ドルだった。Fluxqはまずリソースグラフを照合し、その後クラスターを選択して、決定論的なテンプレートでコマンドを変換した。アーキテクチャ、ネットワーク、メモリの記述を追加すると、220件のジョブの成功率は48%から87%へ上昇し、アーキテクチャ非互換による問題も解消された。測定可能な10個のアプリケーションのうち5個が高速化し、MiniFEでは最大3.3倍に達した。

ただし、[論文](https://arxiv.org/abs/2608.11524)は、metadataの主な役割はまったく実行できないノードを回避することであり、最速のマシンを確実に選び出せたわけではないと強調している。テストしたクラスターは小規模でGPUを搭載しておらず、エージェントモデルについてもモデル間比較は行われていない。さらに、5回のAPI停止時に実行されたfallbackジョブはすべて失敗した。エンジニアリング上、今後注目すべき点は、各コマンドをschemaで検証すること、queue depth、コスト、過去の性能をスコアリングに組み込むこと、そしてエージェントに単純な自己再試行をさせるだけでなく、最初のジョブ投入が失敗した後に安全に再マッチングできるかどうかである。