相信很多大家對開發(fā)者狂喜！Meta最新發(fā)布的LLM Compiler，實現(xiàn)77%自動調優(yōu)效率還不知道吧，今天菲菲就帶你們一起去了解一下~.~！

Meta搞了個很牛的LLM Compiler，幫助程序員更高效地寫代碼。

昨天，三大 AI 巨頭 OpenAI、Google、Meta 組團發(fā)布自家大模型最新研究成果 ——

OpenAI 推出基于 GPT-4訓練的專門找 bug 的新模型 CriticGPT，谷歌開源9B、27B 版 Gemma2，而 Meta 則拿出了一項最新的人工智能突破 ——LLM Compiler。

這是一套強大的開源模型，旨在優(yōu)化代碼并徹底改變編譯器設計。這項創(chuàng)新有可能改變開發(fā)者處理代碼優(yōu)化的方式，使其更快、更高效、更經濟。

據(jù)悉，該 LLM Compiler 的優(yōu)化潛力達到了自動調優(yōu)搜索的77%，這一結果可以顯著減少編譯時間，并提高各種應用的代碼效率，并且在反匯編方面，其往返反匯編的成功率為45%。

有網(wǎng)友表示，這像是代碼優(yōu)化和反匯編的游戲規(guī)則改變者。

這對于開發(fā)者來說是個讓人難以置信的好消息。

概述

大語言模型在眾多軟件工程和編程任務中表現(xiàn)出了卓越的能力，然而它們在代碼優(yōu)化及編譯器領域的應用尚未得到充分挖掘。訓練這些 LLMs 需要消耗大量的計算資源，包括昂貴的 GPU 時間和龐大的數(shù)據(jù)集，這往往使得許多研究和項目難以為繼。

為了彌補這一空白，Meta 研究團隊引入了一種 LLM Compiler，以專門優(yōu)化代碼并徹底改變編譯器設計。通過在包含5460億個標記的 LLVM-IR 和匯編代碼的龐大語料庫上訓練模型，他們使模型能夠理解編譯器中間表示、匯編語言和優(yōu)化技術。

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

研究人員在他們的論文中解釋說:「LLM Compiler 增強了對編譯器中間表示（IR）、匯編語言和優(yōu)化技術的理解?！惯@種增強的理解使模型能夠執(zhí)行以前僅限于人類專家或專業(yè)工具的任務。

LLM Compiler 的訓練流程如圖1所示。

LLM Compiler 在代碼大小優(yōu)化方面取得了顯著成果。在測試中，模型的優(yōu)化潛力達到了自動調優(yōu)搜索的77%，這一結果可以顯著減少編譯時間，并提高各種應用的代碼效率。

模型在反匯編方面的能力更為出色。LLM Compiler 在將 x86_64和 ARM 匯編代碼轉換回 LLVM-IR 時，往返反匯編的成功率為45%（其中14% 完全匹配）。這種能力對于逆向工程任務和舊代碼維護可能具有無法估量的價值。

項目的核心貢獻者之一 Chris Cummins 強調了這項技術的潛在影響:「通過提供兩種大小的預訓練模型（7億和13億參數(shù)）并通過微調版本展示其有效性，」他說，「LLM Compiler 為探索 LLM 在代碼和編譯器優(yōu)化領域未被開發(fā)的潛力鋪平了道路?！?/p>

用于編譯器優(yōu)化的 Code Llama

在匯編代碼和編譯器 IR 上進行預訓練

用于訓練編程 LLMs 的數(shù)據(jù)通常主要由像 Python 這樣的高級源語言組成，匯編代碼在這些數(shù)據(jù)集中的比例微乎其微，編譯器 IR 的比例更小。

為了構建一個對這些語言有良好理解的 LLM，研究團隊用 Code Llama 的權重初始化 LLM Compiler 模型，然后在一個以編譯器為中心的數(shù)據(jù)集上訓練4010億個 token，這個數(shù)據(jù)集主要由匯編代碼和編譯器 IR 組成，如表1所示。

數(shù)據(jù)集 LLM Compiler 主要在由 LLVM（版本17.0.6）生成的編譯器中間表示和匯編代碼上進行訓練，這些數(shù)據(jù)來源于用于訓練 Code Llama 的同一數(shù)據(jù)集，已在表2中概述了該數(shù)據(jù)集。與 Code Llama 一樣，我們也從自然語言數(shù)據(jù)集中獲取少量訓練批次。

編譯器模擬的指令微調

為了理解代碼優(yōu)化的機制，研究團隊對 LLM Compiler 模型進行指令微調，以模擬編譯器優(yōu)化，如圖2所示。

其思路是從有限的未優(yōu)化種子程序集合中，通過對這些程序應用隨機生成的編譯器優(yōu)化序列，生成大量示例。然后他們訓練模型預測優(yōu)化生成的代碼，還訓練模型預測應用優(yōu)化后的代碼大小。

任務規(guī)范。給定未經優(yōu)化的 LLVM-IR（由 clang 前端輸出），一個優(yōu)化過程列表，以及一個起始代碼大小，生成應用這些優(yōu)化后的結果代碼以及代碼大小。

這個任務有兩種類型:在第一種中，模型預期輸出編譯器 IR;在第二種中，模型預期輸出匯編代碼。兩種類型的輸入 IR、優(yōu)化過程和代碼大小是相同的，提示決定了所需的輸出格式。

代碼大小。他們使用兩個指標來衡量代碼大小:IR 指令數(shù)和二進制大小。二進制大小通過將 IR 或匯編降級為目標文件后，.TEXT 和 .DATA 段大小的總和計算得出。我們排除 .BSS 段，因為它不影響磁盤上的大小。

優(yōu)化 pass。在這項工作中，研究團隊針對 LLVM17.0.6，并使用新的過程管理器 （PM，2021），它將 pass 分類為不同的級別，如模塊、函數(shù)、循環(huán)等，以及轉換和分析 pass 。轉換 pass 改變給定的輸入 IR，而分析 pass 生成影響后續(xù)轉換的信息。

在 opt 的346個可能的 pass 參數(shù)中，他們選擇了167個使用。這包括每個默認優(yōu)化流水線 （例如 module (default<Oz>）)，單獨的優(yōu)化轉換 pass (例如 module (constmerge))，但排除了非優(yōu)化實用程序 pass (例如 module (dot-callgraph)) 和不保留語義的轉換 pass (例如 module (internalize))。

他們排除了分析 pass，因為它們沒有副作用，我們依賴 pass 管理器根據(jù)需要注入依賴的分析 pass。對于接受參數(shù)的 pass，我們使用默認值 （例如 module (licm<allowspeculation>）)。表9包含了所有使用的 pass 列表。我們使用 LLVM 的 opt 工具應用 pass 列表，并使用 clang 將結果 IR 降級為目標文件。清單1顯示了使用的命令。

數(shù)據(jù)集。研究團隊通過對表2中總結的未優(yōu)化程序應用1到50個隨機優(yōu)化 pass 列表生成編譯器模擬數(shù)據(jù)集。每個 pass 列表的長度是均勻隨機選擇的。pass 列表是通過從上述167個 pass 集合中均勻采樣生成的。導致編譯器崩潰或在120秒后超時的 pass 列表被排除。

LLM Compiler FTD :擴展下游編譯任務

優(yōu)化標志調優(yōu)的指令微調

操作編譯器標志對運行時性能和代碼大小都有顯著影響。研究團隊訓練 LLM Compiler FTD 模型執(zhí)行下游任務，即為 LLVM 的 IR 優(yōu)化工具 opt 選擇標志，以生成最小的代碼大小。

標志調優(yōu)的機器學習方法以前已經顯示出良好的結果，但在不同程序之間的泛化方面存在困難。以前的工作通常需要編譯新程序數(shù)十或數(shù)百次，以嘗試不同的配置并找出性能最佳的選項。該研究團隊通過預測標志來最小化未見程序的代碼大小，在這個任務的零樣本版本上訓練和評估 LLM Compiler FTD 模型。

他們的方法不依賴于所選擇的編譯器和優(yōu)化指標，他們打算在未來針對運行時性能。目前，優(yōu)化代碼大小簡化了訓練數(shù)據(jù)的收集。

任務規(guī)范。研究團隊向 LLM Compiler FTD 模型呈現(xiàn)一個未優(yōu)化的 LLVM-IR （由 clang 前端生成），并要求它生成應該應用的 opt 標志列表，這些優(yōu)化應用前后的二進制大小，以及輸出代碼，如果無法對輸入代碼進行改進，則生成一個只包含未優(yōu)化二進制大小的簡短輸出消息。

他們使用了與編譯器模擬任務相同的受限優(yōu)化 pass 集，并以相同的方式計算二進制大小。

圖3說明了用于生成訓練數(shù)據(jù)的過程以及如何在推理時使用模型。

在評估時只需要生成的 pass 列表。他們從模型輸出中提取 pass 列表，并使用給定的參數(shù)運行 opt。然后，研究人員可以評估模型預測的二進制大小和優(yōu)化輸出代碼的準確性，但這些是輔助學習任務，不是使用所必需的。

正確性。LLVM 優(yōu)化器并非無懈可擊，以意外或未經測試的順序運行優(yōu)化 pass 可能會暴露出微妙的正確性錯誤，從而降低模型的實用性。為了緩解這種風險，研究團隊開發(fā)了 PassListEval，這是一個工具，用于幫助自動識別破壞程序語義或導致編譯器崩潰的 pass 列表。圖4顯示了該工具的概覽。

PassListEval 接受候選 pass 列表作為輸入，并在一個包含164個自測試 C++ 程序的套件上對其進行評估，這些程序取自 HumanEval-X。每個程序都包含一個編程挑戰(zhàn)的參考解決方案，例如「檢查給定數(shù)字向量中是否有兩個數(shù)字之間的距離小于給定閾值」，以及驗證正確性的單元測試套件。他們將候選 pass 列表應用于參考解決方案，然后將它們與測試套件鏈接以生成二進制文件。執(zhí)行時，如果任何測試失敗，二進制文件將崩潰。如果任何二進制崩潰，或者任何編譯器調用失敗，我們就拒絕該候選 pass 列表。

數(shù)據(jù)集。該團隊在一個源自450萬個未優(yōu)化 IR 的標志調優(yōu)示例數(shù)據(jù)集上訓練了 LLM Compiler FTD 模型，這些 IR 用于預訓練。為生成每個程序的最佳 pass 列表示例，他們進行了廣泛的迭代編譯過程，如圖3所示。

1. 研究團隊使用大規(guī)模隨機搜索為程序生成初始候選最佳 pass 列表。對每個程序，他們獨立生成最多50個 pass 的隨機列表，從之前描述的167個可搜索 pass 集合中均勻采樣。每次他們評估一個程序的 pass 列表時，都記錄生成的二進制大小，然后選擇產生最小二進制大小的每個程序 pass 列表。他們運行了220億次獨立編譯，平均每個程序4，877次。

2. 隨機搜索生成的 pass 列表可能包含冗余 pass，這些 pass 對最終結果沒有影響。此外，一些 pass 順序是可交換的，重新排序不會影響最終結果。由于這些會在訓練數(shù)據(jù)中引入噪聲，他們開發(fā)了一個最小化過程，并將其應用于每個 pass 列表。

最小化包括三個步驟:冗余 pass 消除、冒泡排序和插入搜索。在冗余 pass 消除中，他們通過迭代刪除單個 pass 來最小化最佳 pass 列表，看它們是否對二進制大小有貢獻，如果沒有，就丟棄它們。重復此過程，直到不能再丟棄 pass。然后冒泡排序嘗試為 pass 子序列提供統(tǒng)一排序，根據(jù)關鍵字對 pass 進行排序。最后，插入排序通過遍歷 pass 列表中的每個 pass 并嘗試在其之前插入167個搜索 pass 中的每一個來執(zhí)行局部搜索。如果這樣做改善了二進制大小，就保留這個新的 pass 列表。整個最小化管道循環(huán)直到達到固定點。最小化后的 pass 列表長度分布如圖9所示。平均 pass 列表長度為3.84。

3. 他們將之前描述過 PassListEval 應用于候選最佳 pass 列表。通過這種方式，他們確定了1，704，443個獨立 pass 列表中的167，971個 （9.85%） 會導致編譯時或運行時錯

4. 他們將100個最常見的最優(yōu) pass 列表廣播到所有程序，如果發(fā)現(xiàn)改進就更新每個程序的最佳 pass 列表。之后，唯一最佳 pass 列表的總數(shù)從1，536，472減少到581，076。

上述自動調優(yōu)管道相比 -Oz 產生了7.1% 的幾何平均二進制大小減少。圖10顯示了單個 pass 的頻率。對他們來說，這種自動調優(yōu)作為每個程序優(yōu)化的黃金標準。雖然發(fā)現(xiàn)的二進制大小節(jié)省很顯著，但這需要280億次額外編譯，計算成本超過21，000個 CPU 天。對 LLM Compiler FTD 進行指令微調以執(zhí)行標志調優(yōu)任務的目標是在不需要運行編譯器數(shù)千次的情況下達到自動調優(yōu)器性能的一部分。

反匯編的指令微調

將代碼從匯編語言提升到更高層次的結構，可以運行額外的優(yōu)化，例如直接集成到應用程序代碼中的庫代碼，或者將遺留代碼移植到新架構。反編譯領域在將機器學習技術應用于從二進制可執(zhí)行文件生成可讀和準確的代碼方面取得了進展。在本研究中，研究團隊展示了 LLM Compiler FTD 如何通過微調進行反匯編，學習匯編代碼和編譯器 IR 之間的關系。任務是學習 clang -xir - -o - -S 的逆向翻譯，如圖5所示。

往返測試。使用 LLM 進行反匯編會導致正確性問題。提升的代碼必須通過等價性檢查器進行驗證，這并不總是可行的，或者需要手動驗證正確性，或經過充分的測試用例以獲得信心。然而，可以通過往返測試找到正確性的下限。也就是說，通過將提升的 IR 重新編譯成匯編代碼，如果匯編代碼是相同的，則 IR 是正確的。這為使用 LLM 的結果提供了一條簡單途徑，并且是衡量反匯編模型效用的一種簡單方法。

任務規(guī)范。研究團隊向模型提供匯編代碼，并訓練它發(fā)出相應的反匯編 IR。這項任務的上下文長度設置為輸入?yún)R編代碼8k 個 token 和輸出 IR8k 個 token。

數(shù)據(jù)集。他們從之前任務中使用的數(shù)據(jù)集中派生出匯編代碼和 IR 對。他們的微調數(shù)據(jù)集包含470萬個樣本，輸入 IR 在降低到 x86匯編之前已經使用 - Oz 進行了優(yōu)化。

訓練參數(shù)

數(shù)據(jù)通過字節(jié)對編碼進行標記化，使用與 Code Llama、Llama 和 Llama2相同的標記器。他們對所有四個訓練階段使用相同的訓練參數(shù)。他們使用的大部分訓練參數(shù)與 Code Llama 基礎模型相同，使用 AdamW 優(yōu)化器，β1和 β2的值為0.9和0.95。他們使用余弦調度，預熱步驟為1000步，并將最終學習率設置為峰值學習率的1/30。

與 Code Llama 基礎模型相比，該團隊將單個序列的上下文長度從4096增加到16384，但保持批量大小恒定為400萬個 token。為了適應更長的上下文，他們將學習率設置為2e-5，并修改了 RoPE 位置嵌入的參數(shù)，其中他們將頻率重置為基本值 θ=10^6。這些設置與 Code Llama 基礎模型進行的長上下文訓練一致。

評估

該研究團隊評估 LLM Compiler 模型在標志調優(yōu)和反匯編任務、編譯器模擬、下一個 token 預測以及軟件工程任務上的表現(xiàn)。

標志調優(yōu)任務

方法。他們評估 LLM Compiler FTD 在未見程序的優(yōu)化標志調優(yōu)任務上的表現(xiàn)，并與 GPT-4Turbo 和 Code Llama - Instruct 進行比較。他們對每個模型運行推理，從模型輸出中提取優(yōu)化 pass 列表，然后他們使用這個 pass 列表來優(yōu)化特定程序并記錄二進制大小，基線是使用 -Oz 優(yōu)化時程序的二進制大小。

對于 GPT-4Turbo 和 Code Llama - Instruct，他們在提示后附加一個后綴，提供額外上下文以進一步描述問題和預期輸出格式。

所有模型生成的 pass 列表都使用 PassListEval 進行驗證，如果驗證失敗則使用 -Oz 作為替代。為進一步驗證模型生成的 pass 列表的正確性，他們鏈接最終的程序二進制文件，并將其輸出與使用保守的 -O2優(yōu)化管道優(yōu)化的基準輸出進行差分測試。

數(shù)據(jù)集。研究團隊使用從 MiBench 基準套件提取的2，398個測試提示進行評估。為生成這些提示，他們取構成24個 MiBench 基準的所有713個翻譯單元，并從每個單元生成未優(yōu)化的 IR，然后將它們格式化為提示。如果生成的提示超過15k tokens，他們使用 llvm-extract 將代表該翻譯單元的 LLVM 模塊分割成更小的模塊，每個函數(shù)一個，這導致1，985個提示適合15k token 上下文窗口，剩下443個翻譯單元不適合。在計算性能分數(shù)時，他們對443個被排除的翻譯單元使用 -Oz。表10總結了基準。

結果。表3顯示了所有模型在標志調優(yōu)任務上的零樣本性能。只有 LLM Compiler FTD 模型比 -Oz 有所改進，13B 參數(shù)模型略優(yōu)于較小的模型，在61% 的情況下生成比 -Oz 更小的目標文件。

在某些情況下，模型生成的 pass 列表導致比 -Oz 更大的目標文件大小。例如，LLM Compiler FTD13B 在12% 的情況下有退化。這些退化可以通過簡單地編譯程序兩次來避免:一次使用模型生成的 pass 列表，一次使用 -Oz，然后選擇產生最佳結果的 pass 列表。通過消除相對于 -Oz 的退化，這些 -Oz 備份分數(shù)將 LLM Compiler FTD13B 相對于 -Oz 的總體改進提高到5.26%，并使 Code Llama - Instruct 和 GPT-4Turbo 相對于 -Oz 有適度的改進。圖6顯示了每個模型在各個基準上的性能細分。

二進制大小準確性。雖然模型生成的二進制大小預測對實際編譯沒有影響，但研究團隊可以評估模型在預測優(yōu)化前后的二進制大小方面的性能，以了解每個模型對優(yōu)化的理解程度。圖7顯示了結果。

LLM Compiler FTD 的二進制大小預測與實際情況相關性良好，7B 參數(shù)模型對未優(yōu)化和優(yōu)化的二進制大小分別達到了0.083和0.225的 MAPE 值。13B 參數(shù)模型的 MAPE 值相似，分別為0.082和0.225。Code Llama - Instruct 和 GPT-4Turbo 的二進制大小預測與實際情況幾乎沒有相關性。研究人員注意到，LLM Compiler FTD 對優(yōu)化代碼的錯誤略高于未優(yōu)化代碼。特別是 LLM Compiler FTD 偶爾有高估優(yōu)化效果的趨勢，導致預測的二進制大小低于實際情況。

消融研究。表4對模型在500個提示的小型保留驗證集上的性能進行了消融研究，這些提示來自與他們訓練數(shù)據(jù)相同的分布 （但未在訓練中使用）。他們在圖1所示訓練管道的每個階段進行標志調優(yōu)訓練，以比較性能。如圖所示，反匯編訓練導致性能從平均5.15% 略微下降到5.12%(相對于 -Oz 的改進)。他們還展示了用于生成第2節(jié)所述訓練數(shù)據(jù)的自動調優(yōu)器的性能。LLM Compiler FTD 達到了自動調優(yōu)器77% 的性能。

反匯編任務

方法。研究團隊評估 LLM 生成的代碼在將匯編代碼反匯編到 LLVM-IR 時的功能正確性。他們評估 LLM Compiler FTD 并與 Code Llama - Instruct 和 GPT-4Turbo 進行比較，發(fā)現(xiàn)需要額外的提示后綴才能從這些模型中提取最佳性能。

后綴提供了關于任務和預期輸出格式的額外上下文。為評估模型的性能，他們將模型生成的反匯編 IR 往返降級回匯編。這使我們能夠通過比較原始匯編與往返結果的 BLEU 分數(shù)來評估反匯編的準確性。從匯編到 IR 的無損完美反匯編將有1.0的往返 BLEU 分數(shù) （精確匹配）。

數(shù)據(jù)集。他們使用從 MiBench 基準套件提取的2，015個測試提示進行評估，取用于上述標志調優(yōu)評估的2，398個翻譯單元，生成反匯編提示。然后他們根據(jù)最大8k token 長度過濾提示，允許8k tokens 用于模型輸出，剩下2，015個。表11總結了基準。

結果。表5顯示了模型在反匯編任務上的性能。

LLM Compiler FTD7B 的往返成功率略高于 LLM Compiler FTD13B，但 LLM Compiler FTD13B 具有最高的往返匯編準確性 （往返 BLEU） 和最頻繁產生完美反匯編 (往返精確匹配)。Code Llama - Instruct 和 GPT-4Turbo 在生成語法正確的 LLVM-IR 方面存在困難。圖8顯示了所有模型的往返 BLEU 分數(shù)分布。

消融研究。表6對模型在500個提示的小型保留驗證集上的性能進行了消融研究，這些提示取自之前使用的 MiBench 數(shù)據(jù)集。

他們在圖1所示訓練管道的每個階段進行反匯編訓練，以比較性能。往返率在通過整個訓練數(shù)據(jù)堆棧時最高，并隨每個訓練階段持續(xù)下降，盡管往返 BLEU 在每個階段變化不大。

基礎模型任務

方法。該研究團隊在下一個 token 預測和編譯器模擬兩個基礎模型任務上對 LLM Compiler 模型進行消融研究。他們在訓練管道的每個階段進行這種評估，以了解為每個連續(xù)任務訓練如何影響性能。對于下一個 token 預測，他們在所有優(yōu)化級別的 LLVM-IR 和匯編代碼的小樣本上計算困惑度。他們使用兩個指標評估編譯器模擬:生成的 IR 或匯編代碼是否編譯，以及生成的 IR 或匯編代碼是否與編譯器產生的完全匹配。

數(shù)據(jù)集。對于下一個 token 預測，他們使用從與我們訓練數(shù)據(jù)相同分布但未用于訓練的小型保留驗證數(shù)據(jù)集。他們使用混合的優(yōu)化級別，包括未優(yōu)化代碼、用 -Oz 優(yōu)化的代碼和隨機生成的 pass 列表。對于編譯器模擬，他們使用從 MiBench 生成的500個提示進行評估，這些提示使用第2.2節(jié)描述的方式隨機生成的 pass 列表。

結果。表7顯示了 LLM Compiler FTD 在所有訓練階段在兩個基礎模型訓練任務 （下一個 token 預測和編譯器模擬） 上的性能。下一個 token 預測性能在 Code Llama 之后急劇上升，后者幾乎沒有見過 IR 和匯編，并在隨后的每個微調階段略有下降。

對于編譯器模擬，Code Llama 基礎模型和預訓練模型表現(xiàn)不佳，因為它們沒有在這個任務上訓練過。在編譯器模擬訓練之后直接達到最高性能，其中 LLM Compiler FTD13B 生成的95.6% 的 IR 和匯編可以編譯，20% 與編譯器完全匹配。在進行標志調優(yōu)和反匯編微調后，性能下降。

軟件工程任務

方法。雖然 LLM Compiler FTD 的目的是為代碼優(yōu)化提供基礎模型，但它建立在為軟件工程任務訓練的基礎 Code Llama 模型之上。為評估 LLM Compiler FTD 的額外訓練如何影響代碼生成的性能，他們使用與 Code Llama 相同的基準套件，評估 LLM 從自然語言提示生成 Python 代碼的能力，如「編寫一個函數(shù)，找出可以從給定的對集合形成的最長鏈?！?/p>

數(shù)據(jù)集。他們使用 HumanEval 和 MBPP 基準，與 Code Llama 相同。

結果。表8顯示了從 Code Llama 基礎模型開始的所有模型訓練階段和模型大小的貪婪解碼性能 （pass@1）。它還顯示了模型在 pass@10和 pass@100上的分數(shù)，這些分數(shù)是用 p=0.95和 temperature=0.6生成的。每個以編譯器為中心的訓練階段都導致 Python 編程能力略有退化。在 HumanEval 和 MBPP 上，LLM Compiler 的 pass@1性能最多下降18% 和5%，LLM Compiler FTD 在額外的標志調優(yōu)和反匯編微調后最多下降29% 和22%。所有模型在這兩個任務上仍然優(yōu)于 Llama2。

局限性

Meta 研究團隊已經展示了 LLM Compiler 在編譯器優(yōu)化任務上表現(xiàn)良好，并且相比先前的工作，對編譯器表示和匯編代碼的理解有所改進，但仍存在一些局限性。主要限制是輸入的有限序列長度 （上下文窗口）。

LLM Compiler 支持16k tokens 的上下文窗口，但程序代碼可能遠遠超過這個長度。例如，當格式化為標志調優(yōu)提示時，67% 的 MiBench 翻譯單元超過了這個上下文窗口，如表10所示。

為了緩解這一問題，他們將較大的翻譯單元拆分為單獨的函數(shù)，盡管這限制了可以執(zhí)行的優(yōu)化范圍，而且仍有18% 的拆分翻譯單元對模型來說太大，無法作為輸入接受。研究人員正在采用不斷增加的上下文窗口，但有限的上下文窗口仍然是 LLM 的一個普遍問題。

第二個限制，也是所有 LLM 的共同問題，是模型輸出的準確性。建議 LLM Compiler 的用戶使用特定于編譯器的評估基準來評估他們的模型。鑒于編譯器并非無 bug，任何建議的編譯器優(yōu)化都必須經過嚴格測試。當模型反編譯匯編代碼時，其準確性應通過往返、人工檢查或單元測試來確認。對于某些應用，LLM 生成可以被限制在正則表達式內，或與自動驗證相結合以確保正確性。

參考鏈接:

https://x.com/AIatMeta/status/1806361623831171318

https://ai.meta.com/research/publications/meta-large-language-model-compiler-foundation-models-of-compiler-optimization/?utm_source=twitter&utm_medium=organic_social&utm_content=link&utm_campaign=fair

以上就是關于【開發(fā)者狂喜！Meta最新發(fā)布的LLM Compiler，實現(xiàn)77%自動調優(yōu)效率】的相關內容，希望對大家有幫助！

　　免責聲明：本文由用戶上傳，與本網(wǎng)站立場無關。財經信息僅供讀者參考，并不構成投資建議。投資者據(jù)此操作，風險自擔。 如有侵權請聯(lián)系刪除！