AI・機械学習
システム最適化はCI/CDの一部であるべきだ
Systems optimization should be part of CI/CD (ucbskyadrs.github.io)
要約
AI駆動型システム研究(ADRS)はアルゴリズム発見に有望ですが、現在のフレームワークはコストが高すぎます。LEVIは、費用対効果の高い小さなモデルを主に活用し、多様性を維持することで、ADRSのコストを大幅に削減するフレームワークです。これにより、ADRSの成果をCI/CDプロセスに組み込み、各デプロイメントの特定のワークロードやハードウェアに合わせてアルゴリズムを継続的に最適化できるようになります。
全文翻訳
すべての投稿 この投稿は、AI駆動型システム研究(ADRS)のケーススタディシリーズの一部です。私たちはAIを使用して、実世界のシステム問題に対するより優れたアルゴリズムを自動的に発見しています。OpenEvolveやGEPAのようなアルゴリズム発見フレームワークは、AI駆動型システム研究(ADRS)が強力なアルゴリズムを生み出すことができることを示しました。しかし、今日のフレームワークは、ADRSが次に進むべき方向にとってあまりにも高価です。未来は、一度限りのベンチマーク結果ではなく、継続的かつオーダーメイドの最適化にあります。システムは、デプロイメントの正確なワークロード、ハードウェア、およびSLOに合わせたソリューションを生成し、これらが変化するにつれて適応する必要があります。すべての最適化に莫大な費用がかかる場合、これは不可能です。
LEVIは、アルゴリズム発見のコストを下げることを目的として構築されたフレームワークです。すべてのステップで最強かつ最も高価なモデルを使用する代わりに、検索ハーネスに投資します。つまり、より小さく安価なモデル(例:QWEN 30B)がほとんどのミューテーションを行い、より大きなモデルはまれなパラダイムシフトのために予約されます。これは、LEVIがコード構造(例:ループの数)と実際の動作(例:サブセットxでのパフォーマンス)の両方で多様性を維持し、検索アーカイブが単一のソリューションファミリーに崩壊しないようにするため可能になります。その結果、より強力なADRSの結果を、わずかなコストで実現するフレームワークが誕生しました。主要なベンチマーク比較では、ベースラインよりも約3〜7倍安価です。
✍️ 以前のADRSブログ: https://ucbskyadrs.github.io/
👩💻 コード: github.com/ttanv/levi
💬 ご参加ください: join.slack.com/t/adrs-global および Discord
🌎 フォローしてください: x.com/ai4research_ucb
LLMアルゴリズム発見フレームワークは、ADRSに強力な結果をもたらす可能性を示しています。しかし、主要なボトルネックは依然としてコストです。このブログでは、コストがADRSで重要な役割を果たす理由を論じ、その後、わずかなコストで他のフレームワークを凌駕するアルゴリズム発見フレームワークであるLEVIを紹介します。既存のフレームワークでは、高価で大規模なクローズドソースLLMを使用する必要があります。これは明白な理由から問題です。例えば、ほとんどの研究者がそのような実験を行う余裕がないため、参入障壁が高まります。しかし、より重要な問題はより広範です。ADRSは、単一の強力な結果を生み出すために一度実行するものとして見なすべきではありません。
バーバリアンを広げようか?コストを桁違いに削減することが、ADRSの次の自然なステップであるべきです。これは、ADRSの結果を、通常のシステム論文のように一度限りの研究成果として扱うべきではないからです。そこでは、与えられた問題に対して、研究者がアルゴリズムとヒューリスティックを改善してより良い結果を生み出します。そして、業界はこれらのアルゴリズムを移植し、自社のセットアップに適応させることで追従します。代わりに、私たちは完全にオーダーメイドのソリューションへと移行すべきです。各ソリューションは、各デプロイメントが持つ正確なセットアップと環境に合わせて調整され、最大限の成果を絞り出します。
図1:すべての人に1回の高価なADRS実行(上)と、デプロイメントごとの安価でオーダーメイドの最適化(下)。
図1:すべての人に1回の高価なADRS実行(上)と、デプロイメントごとの安価でオーダーメイドの最適化(下)。
論理的な結論として、ADRSはより洗練されたCI/CDの一形態と見なされるべきです。ユーザーがスコアリング関数とデプロイメント設定を定義し、リンターやフォーマッターがスタイルやフォーマットを自動的に修正するだけでなく、アルゴリズム自体が自動的に最適化されます。リソース(例:新しいGPU)や優先順位(異なるSLO)が変化するにつれて、対応するアルゴリズムが自動的に最適化されます。今日、マルチリージョンクラウドスケジューラーを実行している企業は、他のすべての人と同じアルゴリズムを使用しています。より安価なADRSがあれば、実際のトラフィックパターン、実際のSLO、実際のハードウェアミックスに対して夜間に再最適化できるでしょう。
LEVIの紹介:わずかなコストでのLLMベースの最適化
上記の状況を踏まえ、このブログではLEVIを紹介します。LEVIは、ADRS問題でSOTA(State-Of-The-Art)のパフォーマンスをわずかなコストで生み出すLLMベースの進化的フレームワークです。これは、あまりにも多くのフレームワークが最大のSOTAモデルへのアクセスを前提とし、それらの周りにハーネスを構築しているという重要な洞察に基づいています。
重要な洞察:モデルではなくハーネスに投資する
最大のモデルへのアクセスを前提とすべきではありません。実際、オリジナルのFunSearch論文は、より大きなモデルから利益を得ることができず、AlphaEvolveでのみ成功したと報告しています。オープンソースコミュニティはしばしばこれを見逃し、あらゆるステップで最強のモデルを投入します。
LEVIは代わりに、層別モデル割り当てと改善された多様性維持という2つの主要なコンポーネントを通じて、ハーネスファーストのアプローチを取ります。
図2:LEVIのアーキテクチャ:多様なシードがCVT-MAP-Elitesアーカイブを初期化します。より小さなモデルがほとんどのミューテーションを処理します。フロンティアモデルはK回の評価ごとにパラダイムシフトを注入します。
図2:LEVIのアーキテクチャ:多様なシードがCVT-MAP-Elitesアーカイブを初期化します。より小さなモデルがほとんどのミューテーションを処理します。フロンティアモデルはK回の評価ごとにパラダイムシフトを注入します。
層別モデル割り当て
フロンティアモデルは役立ちますが、すべてのミューテーションで使用すると無駄になります。予算が厳しい場合、より小さなLLMの方が実際に好ましい場合があります。なぜなら、それらが生成するソリューションの純粋な量が、より大きなモデルの品質上の利点を上回る可能性があるからです。しかし、より小さなモデルは事前学習の分布が狭く、アイデアの範囲や根本的に異なるアプローチを提案する能力が制限されます。どちらのモデルクラスも厳密には優れているわけではありません。それぞれ異なる強みを持っているだけです。
既存のいくつかのフレームワークはすでに複数のモデルをサポートしていますが、それらを交換可能に扱い、アンサンブルから均一にサンプリングしたり、ミューテーションが実際に何を要求するかに関係なく呼び出しをルーティングしたりします。これは自然な非対称性を無視しています。まったく新しいアルゴリズムの方向性を提案するには幅広い知識と創造的な推論が必要ですが、既存のアプローチを洗練する(定数の調整、操作の順序変更、エッジケースのチューニング)にははるかに少ない知識で済みます。ハーネスはこの区別を認識し、それに応じて割り当てるべきです。
LEVIは層別モデル割り当てを導入し、モデル容量とタスク要求を一致させます。より小さく、安価なモデルが検索の大部分を処理します。確立されたアルゴリズムファミリー内の局所的な洗練と漸進的な改善です。より大きなモデルは、まれなパラダイムシフトのために予約されます。これらは、既存のアプローチを磨くのではなく、構造的に異なるアプローチを提案することを目的としたミューテーションです。
原則は簡単です。各モデルをその強みに応じて割り当てます。幅広さとスループットには小さなモデルを、創造的な飛躍には大きなモデルを。しかし、これには2つの疑問が生じます。第一に、パラダイムシフトのために、より大きなモデルに意味のあるコンテキストを与えるために、各アルゴリズムファミリーから代表的なソリューションをどのように選択するか?第二に、より小さなモデルとその出力量に頼る度合いが高まるため、アーカイブが収束するのを防ぐためのより堅牢なメカニズムが必要になります。
LEVIはモデル容量をタスク要求に合わせます。洗練には安価なモデル(例:ローカルQWEN 30B)を、パラダイムシフトには高価なモデルを使用します。
改善された多様性維持
構造的および行動的多様性の統合。既存のフレームワークがフロンティアモデルを必要とするあまり明白でない理由は、これらのモデルが二重の役割を担っていることです。それらのより大きな出力空間が暗黙のうちに多様性を維持しています。GPT-5やClaude Opusは、アーカイブ自体に収束を防ぐ強力なメカニズムがないという事実を無視して、30Bモデルよりも自然に広範なソリューションを生み出します。多様性が崩壊した場合、その対応策は、さらに多くのLLM呼び出しを使用する拒否サンプリングから、埋め込みモデルの使用に至るまで、複雑さを追加することでした。これらは弱い基盤に対する補償であり、根本的な問題の解決策ではありません。根本的な問題は、既存のフレームワークが単一の軸に沿ってのみ多様性を維持しており、それも狭い軸であるということです。OpenEvolveはコード長のような構造的特徴を考慮します。GEPAはパレートフロンティアを通じてインスタンスごとのパフォーマンスのトレードオフを考慮します(実際には前者よりも強力なメカニズムであることが多いです)。どちらも現実の何かを捉えていますが、どちらも