Infrathon、AIエージェントの長時間インフラ最適化能力を検証

導入

AIエージェントが短いコード課題を解けるかどうかと、実際のAIインフラを継続的に改善できるかどうかは別の問題です。推論サービスやキャッシュ圧縮、システム性能の調整では、変更を提案するだけでは不十分です。エージェントは実験を実行し、結果を検証し、失敗から方針を修正しながら、長い時間をかけてより良い構成を探す必要があります。Infrathonは、この継続的な最適化能力を測るために設計されました。

主な発見

• 現実的なインフラ課題を対象にする。 Infrathonには、複数のレベルにまたがる多様なAIインフラ最適化課題が含まれます。単発の正解ではなく、繰り返しの実験から測定可能な改善を見つけることが目的です。
• 評価時間で順位が変わる。 6モデルを150回実行し、各実行に最大24時間、合計で1万GPU時間以上を使用しました。評価をどの時点で打ち切るかによって、モデルの相対的な順位は変化します。
• 後半にも改善が続く。 150回のうち135回では、予算の後半にさらに改善が確認されました。初期の結果だけを見れば、探索や準備に続いて現れる成果を取りこぼす可能性があります。
• 人手設計の基準を上回る場合がある。 KVキャッシュ圧縮では、Claude Opus 5.5が人手設計のQuant-VideoGenコーデックの平均圧縮率6.82%を19.86%まで高めました。長時間の探索が、既存設計に含まれていない構成を見つける可能性を示しています。

意義と限界

Infrathonが示す最も重要な点は、エージェント評価の設計そのものです。多くのベンチマークは素早い完了を評価しますが、インフラ最適化ではハードウェアの挙動、実装の細部、測定の品質、複数の性能指標のバランスが結果を左右します。短時間の試験では、エージェントが最終的にどこまで改善できるかではなく、作業を開始する速さだけを測ってしまうかもしれません。

一方、長時間動かせば自動的に性能が伸びるわけではありません。軌跡の分析では、課題の制約に反する行動、信頼できないテスト、早すぎる完了判断が継続的な改善を妨げました。今後のエージェントには、コード生成力だけでなく、制約を守り、再現性のある実験を設計し、ノイズを含む指標を解釈し、探索を続けるべきか判断する能力が求められます。

実務では、十分に長い予算、再現可能な測定、完全な実行履歴を組み合わせて評価することが重要です。Infrathonは、エージェントを「課題を終えられるか」ではなく、「制約の下でシステムを責任を持って改善し続けられるか」という観点から捉える方向を示しています。

出典：Hugging Face Daily Papers