開発者は大喜びです! Meta の LLM コンパイラの最新リリースは 77% の自動チューニング効率を達成-AI-php.cn

Meta は、プログラマーがより効率的にコードを作成できるようにする素晴らしい LLM コンパイラーを開発しました。

昨日、3大AI大手OpenAI、Google、Metaが提携し、自社の大規模モデルの最新の研究結果を発表しました -

OpenAIはGPT-4に基づく新しいモデルCriticGPTを発表しましたバグ発見に特化したトレーニング、Google オープンソースの Gemma2 9B および 27B バージョン、そして Meta は最新の人工知能の画期的な LLM コンパイラーを考案しました。

これは、コードを最適化し、コンパイラー設計に革命を起こすように設計されたオープンソースモデルの強力なセットです。このイノベーションは、開発者がコードの最適化に取り組む方法を変え、コードの最適化をより高速に、効率的に、そしてコスト効率よく行う可能性があります。

LLM コンパイラーの最適化の可能性は、自動チューニング検索の 77% に達すると報告されており、この結果により、コンパイル時間が大幅に短縮され、さまざまなアプリケーションのコード効率が向上し、逆アセンブリに関してはその効果が向上します。トリップ分解成功率は45%。

一部のネチズンは、これはコードの最適化と逆アセンブリのゲームチェンジャーのようなものだと言いました。

これは開発者にとって非常に良いニュースです。

概要

大規模な言語モデルは、多くのソフトウェアエンジニアリングやプログラミングタスクで優れた機能を示していますが、コードの最適化やコンパイラーの分野でのアプリケーションは十分に活用されていません。これらの LLM のトレーニングには、高価な GPU 時間や大規模なデータセットを含む広範なコンピューティングリソースが必要であり、多くの研究やプロジェクトが持続不可能になることがよくあります。

このギャップを埋めるために、メタ研究チームは、特にコードを最適化し、コンパイラー設計に革命を起こす LLM コンパイラーを導入しました。 LLVM-IR およびアセンブリコードの 5,460 億トークンの膨大なコーパスでモデルをトレーニングすることにより、モデルがコンパイラの中間表現、アセンブリ言語、および最適化手法を理解できるようになりました。

論文リンク: https://ai.meta.com/research/publications/meta-large- language-model-compiler-foundation-models-of-compiler-optimization/

「」の研究者LLM コンパイラーは、コンパイラーの中間表現 (IR)、アセンブリ言語、および最適化手法についての理解を強化します」と論文では説明しています。

LLM Compilerのトレーニングプロセスを図1に示します。

LLM コンパイラーは、コードサイズの最適化において重要な結果を達成します。テストでは、モデルの最適化可能性は自動チューニング検索の 77% に達し、その結果、コンパイル時間を大幅に短縮し、さまざまなアプリケーションのコード効率を向上させることができました。

このモデルは分解が得意です。 LLM コンパイラは、x86_64 および ARM アセンブリコードを LLVM-IR に変換する際に、45% の往復逆アセンブリ成功率 (うち 14% は完全一致) を達成します。この機能は、リバースエンジニアリングタスクやレガシーコードのメンテナンスに非常に役立ちます。

このプロジェクトの中心的な貢献者の 1 人、Chris Cummins は、このテクノロジーの潜在的な影響を次のように強調しました。「LLM コンパイラーは、コードとコンパイラーの最適化の分野で LLM の未開発の可能性を探求する道を開きます」と彼は述べました。通常、LLM は主に Python などの高レベルのソース言語で構成され、これらのデータセットではアセンブリコードが占める割合はごくわずかで、コンパイラ IR が占める割合はさらに小さくなります。

これらの言語をよく理解して LLM を構築するために、研究チームは、Code Llama の重みを使用して LLM コンパイラーモデルを初期化し、主にコンパイラー中心のデータセットで 4,010 億個のトークンをトレーニングしました。表 1 に示すように、アセンブリコードとコンパイラ IR で構成されます。

データセット LLM コンパイラーは主に、LLVM (バージョン 17.0.6) によって生成されたコンパイラーの中間表現とアセンブリコードでトレーニングされます。これらのデータは、表 2 で報告されているコード Llama のトレーニングに使用されたのと同じデータセットから派生します。データセットの概要をに示します。 Code Llama と同様に、自然言語データセットから小さなトレーニングバッチも取得します。开发者狂喜！Meta最新发布的LLM Compiler，实现77%自动调优效率

コンパイラシミュレーションのための命令の微調整

コード最適化のメカニズムを理解するために、研究チームは、図 2 に示すように、LLM コンパイラモデルで命令の微調整を実行し、コンパイラの最適化をシミュレートしました。

そのアイデアは、ランダムに生成されたコンパイラ最適化シーケンスをこれらのプログラムに適用することにより、最適化されていないシードプログラムの限られたコレクションから多数の例を生成することです。次に、最適化によって生成されるコードを予測するようにモデルをトレーニングし、最適化を適用した後のコードサイズを予測するようにモデルをトレーニングしました。

タスクの仕様。 最適化されていない LLVM-IR (clang フロントエンドによる出力)、最適化パスのリスト、および開始コードサイズを指定して、これらの最適化を適用した後の結果のコードとコードサイズを生成します。

このタスクには 2 つのタイプがあります。1 つ目では、モデルはコンパイラ IR を出力することを期待し、2 つ目では、モデルはアセンブリコードを出力することを期待します。入力 IR、最適化プロセス、コードサイズはどちらのタイプでも同じで、ヒントによって必要な出力形式が決まります。

コードサイズ。 コードサイズを測定するために、IR 命令の数とバイナリサイズという 2 つの指標が使用されます。バイナリサイズは、IR またはアセンブリをオブジェクトファイルにダウングレードした後、.TEXT セグメントサイズと .DATA セグメントサイズの合計として計算されます。 .BSS セグメントはディスク上のサイズに影響を与えないため、除外します。

パスを最適化します。 この作業では、研究チームは LLVM 17.0.6 をターゲットにしており、パスをモジュール、関数、ループなどのさまざまなレベルに分類し、パスの変換と分析を行う新しいプロセスマネージャー (PM、2021) を使用しています。。変換パスは特定の入力 IR を変更しますが、分析パスは後続の変換に影響を与える情報を生成します。

opt に使用できる 346 個のパスパラメーターのうち、使用する 167 個を選択しました。これには、すべてのデフォルトの最適化パイプライン (例: module (default))、個々の最適化変換パス (例: module (constmerge)) が含まれますが、非最適化ユーティリティパス (例: module (dot-callgraph)) は除外され、セマンティクス変換パスは保持されません。 (モジュール(内部化)など)。

分析パスには副作用がなく、必要に応じて依存する分析パスを挿入するためにパスマネージャーに依存しているため、分析パスは除外されます。パラメーターを受け入れるパスの場合は、デフォルト値を使用します (例: module (licm))。表 9 には、使用されたすべてのパスのリストが含まれています。 LLVM の opt ツールを使用してパスリストを適用し、clang を使用して結果の IR をオブジェクトファイルにダウングレードします。リスト 1 に、使用されるコマンドを示します。

データセット。研究チームは、表 2 にまとめた最適化されていないプログラムに 1 ～ 50 のランダムな最適化パスのリストを適用することで、コンパイラーシミュレーションデータセットを生成しました。各パスリストの長さは均一かつランダムに選択されます。パスリストは、上記の 167 パスセットから均一にサンプリングして生成されます。コンパイラーのクラッシュまたは 120 秒後のタイムアウトの原因となるパスリストは除外されます。

llmコンパイラFTD：ダウンストリームコンパイルタスクを拡張するintruction最適化フラグのためのインストラクション微調整

操作コンパイラフラグは、ランタイムパフォーマンスとコードサイズに大きな影響を与えます。研究チームは、LLVM の IR 最適化ツールのフラグを選択する下流タスクを実行して、最小のコードサイズを生成するように LLM コンパイラー FTD モデルをトレーニングしました。

フラグ調整された機械学習手法はこれまでに良好な結果を示してきましたが、異なるプログラム間での一般化には困難がありました。以前の作業では、さまざまな構成を試して最もパフォーマンスの高いオプションを見つけるために、新しいプログラムを何十回も何百回もコンパイルする必要があることがよくありました。研究チームは、フラグを予測して未確認プログラムのコードサイズを最小限に抑えることにより、このタスクのゼロショットバージョンで LLM コンパイラ FTD モデルをトレーニングおよび評価しました。

彼らのアプローチは、選択したコンパイラーや最適化メトリクスに依存せず、将来的には実行時のパフォーマンスをターゲットにする予定です。現在、コードサイズを最適化することでトレーニングデータの収集が簡素化されています。

タスクの仕様。研究チームは、最適化されていない LLVM-IR (clang フロントエンドによって生成された) を LLM コンパイラー FTD モデルに提示し、適用する必要がある opt フラグのリスト、これらの最適化が適用される前後のバイナリサイズ、および入力コードで使用できない場合の出力コード最適化されていないバイナリサイズのみを含む短い出力メッセージを生成するように改良が加えられました。

彼らは、コンパイラシミュレーションタスクと同じ制限付き最適化パスのセットを使用し、同じ方法でバイナリサイズを計算しました。

図 3 は、トレーニングデータの生成に使用されるプロセスと、推論時にモデルがどのように使用されるかを示しています。

評価中に必要なのは、生成されたパスリストのみです。モデル出力からパスリストを抽出し、指定されたパラメーターを使用して opt を実行します。その後、研究者はモデルの予測バイナリサイズの精度を評価し、出力コードを最適化できますが、これらは補助的な学習タスクであり、使用には必須ではありません。

正しさ。 LLVM オプティマイザーは確実ではなく、最適化パスを予期しない順序またはテストされていない順序で実行すると、モデルの有用性を低下させる微妙な正確性エラーが露呈する可能性があります。このリスクを軽減するために、研究チームは PassListEval を開発しました。これは、プログラムのセマンティクスを壊す、またはコンパイラのクラッシュを引き起こすパスリストを自動的に特定するのに役立つツールです。図 4 にツールの概要を示します。

PassListEval は、候補パスのリストを入力として受け取り、HumanEval-X から取得した 164 個の自己テスト C++ プログラムのスイートでそれを評価します。各プログラムには、「指定された数値ベクトル内の 2 つの数値間の距離が指定されたしきい値より小さいかどうかを確認する」などのプログラミングの課題に対する参照ソリューションと、正確さを検証するための一連の単体テストが含まれています。候補パスのリストを参照ソリューションに適用し、それらをテストスイートにリンクしてバイナリを生成します。実行時にテストが失敗すると、バイナリはクラッシュします。バイナリがクラッシュするか、コンパイラ呼び出しが失敗した場合、合格候補リストは拒否されます。

データセット。チームは、事前トレーニングに使用された 450 万の最適化されていない IR から派生したフラグ調整されたサンプルデータセットで LLM コンパイラー FTD モデルをトレーニングしました。各プログラムのベストパスリストの例を生成するために、図 3 に示すように、広範な反復コンパイルプロセスが実行されました。

1. 研究チームは大規模なランダム検索を使用して、プログラムの最初の候補ベストパスリストを生成します。各プログラムについて、前述の 167 個の検索可能なパスのセットから均一にサンプリングされた、最大 50 個のパスのランダムリストを独自に生成しました。プログラムのパスリストを評価するたびに、結果のバイナリサイズを記録し、最小のバイナリサイズを生成する各プログラムのパスリストを選択しました。彼らは 220 億の独立したコンピレーションを実行し、プログラムごとに平均 4,877 を実行しました。

2. ランダム検索によって生成されたパスリストには冗長なパスが含まれる場合がありますが、最終結果には影響しません。さらに、一部のパス順序は交換可能であり、順序を変更しても最終結果には影響しません。これらはトレーニングデータにノイズを導入するため、最小化プロセスを開発し、それを各パスリストに適用しました。

最小化には、冗長パスの削除、バブルソート、挿入検索の 3 つのステップが含まれます。冗長パスの削除では、個々のパスを繰り返し削除してバイナリサイズに影響を与えているかどうかを確認し、そうでない場合は破棄することで、最適なパスリストを最小化します。パスがドロップされなくなるまで、このプロセスを繰り返します。次に、バブルソートは、キーワードに基づいてパスを並べ替え、パスのサブシーケンスに統一された順序付けを提供しようとします。最後に、挿入ソートは、パスリスト内の各パスをループし、その前に 167 個の検索パスのそれぞれを挿入しようとすることにより、ローカル検索を実行します。そうすることでバイナリサイズが改善される場合は、この新しいパスリストを保持してください。最小化パイプライン全体は、固定点に到達するまでループされます。最小化されたパスリストの長さの分布を図 9 に示します。パスリストの平均長は 3.84 です。

3. 前述の PassListEval を最適パス候補のリストに適用します。このようにして、彼らは、コンパイル時エラーまたは実行時エラーを引き起こす可能性のある 1,704,443 個の一意のパスリストのうち 167,971 個 (9.85%) を特定しました

4。最も一般的な 100 個の最適なパスリストをすべてのプログラムにブロードキャストし、更新します。改善が見つかった場合は、各プログラムのベストパスリスト。その後、単一ベストパスリストの総数は 1,536,472 から 581,076 に減少しました。

上記の自動チューニングパイプラインにより、-Oz と比較して幾何平均 7.1% のバイナリサイズの削減が行われました。図 10 は、シングルパスの周波数を示しています。彼らにとって、この自動チューニングはあらゆるプログラム最適化のゴールドスタンダードとして機能します。バイナリサイズの削減は大幅ですが、これには 21,000 CPU 日を超える計算コストで 280 億の追加コンパイルが必要でした。フラグチューニングタスクを実行するための LLM コンパイラ FTD の命令微調整の目標は、コンパイラを何千回も実行することなく、自動チューナーのパフォーマンスの一部を達成することです。

逆アセンブリのための命令の微調整

コードをアセンブリ言語から、アプリケーションコードに直接統合されたライブラリコードや、レガシーコードを新しいアーキテクチャ。逆コンパイルの分野では、バイナリ実行可能ファイルから可読で正確なコードを生成する機械学習技術の適用が進歩しました。この研究で研究チームは、LLM コンパイラー FTD が微調整を通じてどのように逆アセンブリを実行できるかを示し、アセンブリコードとコンパイラー IR の関係を学習します。課題は、図 5 に示すように、clang -xir - -o - -S の逆変換を学習することです。

往復テスト。逆アセンブリに LLM を使用すると、正確性の問題が発生する可能性があります。ブーストされたコードは等価性チェッカーを使用して検証する必要がありますが、常に可能であるとは限らず、手動による正確性の検証または信頼性を得るために十分なテストケースが必要です。ただし、正確さの下限はラウンドトリップテストを通じて見つけることができます。つまり、リフトされた IR をアセンブリコードに再コンパイルすることにより、アセンブリコードが同じであれば、IR は正しいことになります。これは、LLM の結果を使用するための簡単なパスを提供し、逆アセンブルされたモデルの有用性を測定する簡単な方法です。

タスクの仕様。研究チームはモデルのアセンブリコードを入力し、対応する逆アセンブリ IR を出力するようにトレーニングしました。このタスクのコンテキスト長は、入力アセンブリコードの場合は 8k トークン、出力 IR の場合は 8k トークンに設定されました。

データセット。彼らは、前のタスクで使用されたデータセットからアセンブリコードと IR のペアを導き出しました。彼らの微調整データセットには 470 万のサンプルが含まれており、入力 IR は x86 アセンブリに削減される前に -Oz を使用して最適化されています。

トレーニングパラメータ

データは、Code Llama、Llama、および Llama 2 と同じトークナイザーを使用して、バイトペアエンコードによってトークン化されます。 4 つのトレーニングフェーズすべてに同じトレーニングパラメーターを使用します。彼らは、Code Llama ベースモデルと同じトレーニングパラメーターのほとんどを使用し、β1 と β2 の値が 0.9 と 0.95 の AdamW オプティマイザーを使用しました。彼らは、1000 ステップのウォームアップステップでコサインスケジューリングを使用し、最終学習率をピーク学習率の 1/30 に設定しました。

Code Llama 基本モデルと比較して、チームは単一シーケンスのコンテキスト長を 4096 から 16384 に増加しましたが、バッチサイズは 400 万トークンで一定に保ちました。より長いコンテキストに対応するために、学習率を 2e-5 に設定し、RoPE 位置埋め込みのパラメーターを変更し、周波数を基本値 θ=10^6 にリセットしました。これらの設定は、Code Llama 基本モデルの長いコンテキストトレーニングと一致しています。

評価

研究チームは、フラグの調整と逆アセンブリのタスク、コンパイラーのシミュレーション、次のトークンの予測、およびソフトウェアエンジニアリングのタスクに関する LLM コンパイラーモデルのパフォーマンスを評価します。

フラグチューニングタスク

メソッド。彼らは、目に見えないプログラムの最適化フラグを調整するタスクにおける LLM Compiler FTD のパフォーマンスを評価し、それを GPT-4 Turbo および Code Llama - Instruct と比較します。各モデルで推論を実行し、モデル出力から最適化パスのリストを抽出します。次に、このパスリストを使用して特定のプログラムを最適化し、バイナリサイズを記録します。ベースラインは、-Oz で最適化されたときのプログラムのバイナリサイズです。

GPT-4 Turbo および Code Llama - Instruct の場合、ヒントの後にサフィックスを追加して、問題と予想される出力形式を詳しく説明するための追加のコンテキストを提供します。

モデルによって生成されたすべてのパスリストは PassListEval を使用して検証され、検証が失敗した場合は代替として -Oz が使用されます。モデルによって生成されたパスリストの正確性をさらに検証するために、最終的なプログラムバイナリをリンクし、保守的な -O2 最適化パイプラインを使用して最適化されたベンチマーク出力に対してその出力を差分テストしました。

データセット。研究チームは、MiBench ベンチマークスイートから抽出した 2,398 個のテストキューを使用して評価を実施しました。これらのヒントを生成するために、24 の MiBench ベンチマークを構成する 713 個の翻訳ユニットをすべて取得し、各ユニットから最適化されていない IR を生成し、それらをヒントにフォーマットします。生成されたヒントが 15,000 トークンを超える場合、llvm-extract を使用して、その翻訳単位を表す LLVM モジュールを関数ごとに 1 つずつ小さなモジュールに分割します。その結果、1,985 個のヒントが 15,000 トークンのコンテキストウィンドウに収まり、443 個の翻訳単位が残ります。不適切。パフォーマンススコアを計算する際、除外された 443 個の翻訳単位に -Oz を使用しました。表 10 はベンチマークをまとめたものです。

結果。表 3 は、フラグ調整タスクにおけるすべてのモデルのゼロショットパフォーマンスを示しています。 LLM コンパイラ FTD モデルのみが -Oz よりも改善されており、13B パラメータモデルはより小さいモデルよりわずかに優れており、61% の確率で -Oz よりも小さなオブジェクトファイルを生成します。

場合によっては、モデルによって生成されたパスリストにより、ターゲットファイルサイズが -Oz よりも大きくなることがありました。たとえば、LLM Compiler FTD 13B では 12% のケースで機能低下が発生します。これらの機能低下は、プログラムを 2 回コンパイルするだけで回避できます。1 回目はモデルによって生成されたパスリストを使用し、もう 1 回目は -Oz を使用して、最良の結果が得られるパスリストを選択します。 -Oz と比較した低下を排除することで、これらの -Oz バックアップスコアは、-Oz と比較した LLM Compiler FTD 13B の全体的な改善を 5.26% に増加させ、Code Llama - Instruct および GPT-4 Turbo が -Oz と比較してわずかな改善を達成できるようにします。図 6 は、さまざまなベンチマークにおける各モデルのパフォーマンスの内訳を示しています。

バイナリサイズの精度。モデルによって生成されたバイナリサイズの予測は実際のコンパイルには影響しませんが、研究チームは最適化の前後でバイナリサイズを予測するモデルのパフォーマンスを評価し、各モデルが最適化をどの程度理解しているかを理解できます。図 7 に結果を示します。

LLM Compiler FTD のバイナリサイズ予測は実際の状況とよく相関しており、7B パラメータモデルは、最適化されていないバイナリサイズと最適化されたバイナリサイズに対してそれぞれ 0.083 と 0.225 の MAPE 値を達成しています。 13B パラメータモデルの MAPE 値は同様で、それぞれ 0.082 と 0.225 でした。 Code Llama - Instruct および GPT-4 Turbo のバイナリサイズ予測は現実とほとんど相関がありません。研究者らは、LLM コンパイラ FTD では、最適化されたコードの方が、最適化されていないコードよりもエラーがわずかに高いことに気づきました。特に、LLM コンパイラ FTD は、最適化の有効性を過大評価する傾向があり、その結果、バイナリサイズが実際よりも小さくなることが予測されます。

アブレーションの研究。表 4 は、トレーニングデータと同じ分布からの 500 キューの小さなホールドアウト検証セット (ただしトレーニングには使用されません) でのモデルのパフォーマンスのアブレーションスタディを示しています。彼らは、図 1 に示すトレーニングパイプラインの各段階でフラグ調整トレーニングを実行し、パフォーマンスを比較しました。示されているように、分解トレーニングでは、パフォーマンスが平均 5.15% から 5.12% にわずかに低下しました (-Oz よりも改善)。また、セクション 2 で説明したトレーニングデータの生成に使用されるオートチューナーのパフォーマンスも示します。 LLM コンパイラ FTD は、オートチューナーのパフォーマンスの 77% を達成します。

逆アセンブルタスク

メソッド。研究チームは、アセンブリコードを LLVM-IR に逆アセンブルする際に、LLM で生成されたコードの機能の正確さを評価します。彼らは LLM Compiler FTD を評価し、Code Llama - Instruct および GPT-4 Turbo と比較し、これらのモデルから最高のパフォーマンスを引き出すには追加のヒントサフィックスが必要であることを発見しました。

サフィックスは、タスクに関する追加のコンテキストと予想される出力形式を提供します。モデルのパフォーマンスを評価するために、モデルによって生成された逆アセンブリ IR をアセンブリに戻すラウンドトリップダウングレードを行いました。これにより、元のアセンブリの BLEU スコアとラウンドトリップ結果を比較することで、逆アセンブリの精度を評価できます。アセンブリから IR までのロスのない完全な逆アセンブリでは、往復の BLEU スコアは 1.0 (完全一致) になります。

データセット。彼らは、MiBench ベンチマークスイートから抽出された 2,015 のテストヒントを使用して評価し、上記のフラグ調整評価に使用された 2,398 の翻訳単位を取得して、逆アセンブリヒントを生成しました。次に、最大 8,000 トークンの長さに基づいてチップをフィルタリングし、モデル出力に 8,000 トークンを許可し、2,015 個が残りました。表 11 にベンチマークをまとめます。

結果。表 5 は、分解タスクにおけるモデルのパフォーマンスを示しています。

LLM Compiler FTD 7B は、LLM Compiler FTD 13B よりもラウンドトリップの成功率がわずかに高くなりますが、LLM Compiler FTD 13B のラウンドトリップアセンブリ精度 (ラウンドトリップ BLEU) が最も高く、最も頻繁に完全な逆アセンブリが生成されます (往復完全一致）。 Code Llama - Instruct および GPT-4 Turbo では、構文的に正しい LLVM-IR を生成することが困難です。図 8 は、すべてのモデルの往復 BLEU スコア分布を示しています。

アブレーションの研究。表 6 は、以前に使用した MiBench データセットから取得した、500 個のキューからなる小規模なホールドアウト検証セットでのモデルのパフォーマンスのアブレーションスタディを示しています。

彼らは、図 1 に示すトレーニングパイプラインの各段階で逆アセンブリトレーニングを実行し、パフォーマンスを比較しました。ラウンドトリップレートは、トレーニングデータスタック全体を通過するときに最も高く、トレーニングステージごとに減少し続けますが、ラウンドトリップ BLEU は各ステージでほとんど変化しません。

基本モデルタスク

メソッド。研究チームは、次のトークン予測とコンパイラシミュレーションという 2 つの基本的なモデルタスクについて、LLM コンパイラモデルのアブレーション研究を実施しました。彼らはトレーニングパイプラインの各段階でこの評価を実行し、連続する各タスクのトレーニングがパフォーマンスにどのような影響を与えるかを理解します。次のトークンを予測するために、LLVM-IR の小さなサンプルとアセンブリコードのパープレキシティをすべての最適化レベルで計算します。彼らは、生成された IR またはアセンブリコードがコンパイルされるかどうか、および生成された IR またはアセンブリコードがコンパイラが生成するものと正確に一致するかどうかという 2 つの指標を使用してコンパイラシミュレーションを評価します。

データセット。次のトークンの予測には、トレーニングデータと同じ分布からの小さなホールドアウト検証データセットが使用されますが、トレーニングには使用されません。これらは、最適化されていないコード、-Oz で最適化されたコード、ランダムに生成されたパスリストなど、最適化レベルを組み合わせて使用します。コンパイラシミュレーションの場合、セクション 2.2 で説明した方法でランダムに生成されたパスリストを使用して MiBench から生成された 500 個のヒントを使用して評価されました。

結果。表 7 は、すべてのトレーニングステージにわたる 2 つの基本モデルトレーニングタスク (次のトークン予測とコンパイラシミュレーション) における LLM コンパイラ FTD のパフォーマンスを示しています。次のトークンの予測パフォーマンスは、IR とアセンブリがほとんど見られない Code Llama の後で急激に上昇し、その後の微調整段階ごとにわずかに低下します。

コンパイラシミュレーションの場合、Code Llama ベースモデルと事前トレーニングされたモデルは、このタスクでトレーニングされていないため、パフォーマンスが良くありません。コンパイラシミュレーショントレーニングの直後に最大のパフォーマンスが達成され、LLM コンパイラ FTD 13B によって生成された IR とアセンブリの 95.6% がコンパイルされ、20% がコンパイラと正確に一致します。フラグチューニングと逆アセンブリの微調整を行った後、パフォーマンスが低下しました。

ソフトウェアエンジニアリングタスク

メソッド。 LLM コンパイラ FTD の目的はコード最適化のための基本モデルを提供することですが、ソフトウェアエンジニアリングタスク用にトレーニングされた基本コード Llama モデルに基づいて構築されています。 LLM コンパイラ FTD の追加トレーニングがコード生成のパフォーマンスにどのような影響を与えるかを評価するために、Code Llama と同じベンチマークスイートを使用して、自然言語プロンプトから Python コードを生成する LLM の機能を評価しました。指定された Python コードセットのペアによって形成される最長のチェーン。 Code Llama と同じ、HumanEval および MBPP ベンチマークを使用します。

結果。表 8 は、Code Llama ベースモデルから始まるすべてのモデルトレーニングステージとモデルサイズに対する貪欲なデコードパフォーマンス (pass@1) を示しています。また、p=0.95 および温度=0.6 で生成された pass@10 および pass@100 でのモデルのスコアも表示されます。コンパイラ中心の各トレーニングフェーズでは、Python プログラミング能力がわずかに低下します。 HumanEval と MBPP では、追加のフラグ調整と逆アセンブリ微調整の後、LLM コンパイラーの pass@1 パフォーマンスが最大 18% と 5% 低下し、LLM コンパイラー FTD は最大 29% と 22% 低下しました。すべてのモデルは、両方のタスクにおいて依然として Llama 2 を上回っています。

制限事項

メタ研究チームは、LLM Compilerがコンパイラ最適化タスクで良好に実行し、以前の研究と比較してコンパイラ表現とアセンブリコードの理解を向上させることを実証しました。しかし、まだいくつかの制限があります。主な制限は、入力 (コンテキストウィンドウ) のシーケンス長が制限されていることです。

LLM コンパイラーは 16,000 トークンのコンテキストウィンドウをサポートしますが、プログラムコードはこれよりもはるかに長くなる可能性があります。たとえば、表 10 に示すように、フラグチューニングヒントとしてフォーマットされた場合、MiBench 翻訳単位の 67% がこのコンテキストウィンドウを超えました。

この問題を軽減するために、より大きな翻訳単位を個別の関数に分割しますが、これにより実行できる最適化の範囲が制限されますが、それでも分割された翻訳単位の 18% はモデルが大きすぎるため大きすぎます。入力として受け入れられます。研究者は増え続けるコンテキストウィンドウを採用していますが、限られたコンテキストウィンドウが LLM の一般的な問題として残っています。

2 番目の制限は、すべての LLM に共通する問題であり、モデル出力の精度です。 LLM コンパイラのユーザーは、コンパイラ固有の評価ベンチマークを使用してモデルを評価することをお勧めします。コンパイラにバグがないわけではないため、提案されたコンパイラの最適化は厳密にテストする必要があります。モデルをアセンブリコードに逆コンパイルするときは、ラウンドトリップ、手動検査、または単体テストを通じてその精度を確認する必要があります。一部のアプリケーションでは、LLM の生成を正規表現に制限したり、正確性を確保するために自動検証と組み合わせたりすることができます。

^{参考リンク：}

^{https://x.com/AIatMeta/status/1806361623831171318}^{https://ai.meta.com/研究/出版物/メタ-large- language-model-compiler-foundation-models-of-compiler-optimization/?utm_source=twitter&utm_medium=organic_social&utm_content=link&utm_campaign=fair}

以上が開発者は大喜びです! Meta の LLM コンパイラの最新リリースは 77% の自動チューニング効率を達成の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。