首頁 >科技週邊 >人工智慧 >開發者狂喜! Meta最新發布的LLM Compiler,實現77%自動調校效率

開發者狂喜! Meta最新發布的LLM Compiler,實現77%自動調校效率

王林
王林原創
2024-07-01 18:16:391282瀏覽
Meta搞了一個很牛的LLM Compiler,幫助程式設計師更有效率地寫程式碼。

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

Cri
OpenAI 推出基於GPT-4 訓練的新門?開源9B、27B 版Gemma2,而Meta 則拿出了最新的人工智慧突破——LLM Compiler。

這是一套強大的開源模型,旨在優化程式碼並徹底改變編譯器設計。這項創新有可能改變開發者處理程式碼最佳化的方式,使其更快、更有效率、更經濟。
开发者狂喜!Meta最新发布的LLM Compiler,实现77%自动调优效率
據悉,該LLM Compiler 的最佳化潛力達到了自動調優搜尋的77%,這一結果可以顯著減少編譯時間,並提高各種應用的程式碼效率,並且在反彙編方面,其往返反彙編的成功率為45%。

有網友表示,這像是程式碼最佳化和反彙編的遊戲規則改變者。
开发者狂喜!Meta最新发布的LLM Compiler,实现77%自动调优效率
這對開發者來說是個令人難以置信的好消息。
开发者狂喜!Meta最新发布的LLM Compiler,实现77%自动调优效率
概述

大語言模型在眾多軟體工程和程式設計任務中表現出了卓越的能力,然而它們在程式碼最佳化及編譯器領域的應用尚未充分挖掘。訓練這些 LLMs 需要消耗大量的運算資源,包括昂貴的 GPU 時間和龐大的資料集,這往往使得許多研究和專案難以為繼。

為了彌補這一空白,Meta 研究團隊引入了一種 LLM Compiler,以專門優化程式碼並徹底改變編譯器設計。透過在包含 5,460 億個標記的 LLVM-IR 和彙編程式碼的龐大語料庫上訓練模型,他們使模型能夠理解編譯器中間表示、彙編語言和最佳化技術。
开发者狂喜!Meta最新发布的LLM Compiler,实现77%自动调优效率
論文連結:https://ai.meta.com/research/publications/meta-large-language-model-compiler-foundation-models-of-compiler-optimization/

他們的論文中解釋說:「LLM Compiler 增強了對編譯器中間表示(IR)、彙編語言和優化技術的理解。」這種增強的理解使模型能夠執行以前僅限於人類專家或專業工具的任務。

LLM Compiler 的訓練流程如圖 1 所示。
开发者狂喜!Meta最新发布的LLM Compiler,实现77%自动调优效率LLM Compiler 在程式碼大小最佳化方面取得了顯著成果。在測試中,模型的最佳化潛力達到了自動調優搜尋的 77%,這一結果可以顯著減少編譯時間,並提高各種應用的程式碼效率。

模型在反組譯方面的能力更為優異。 LLM Compiler 在將 x86_64 和 ARM 組譯程式碼轉換回 LLVM-IR 時,往返反組譯的成功率為 45%(其中 14% 完全符合)。這種能力對於逆向工程任務和舊程式碼維護可能具有無法估量的價值。

計畫的核心貢獻者之一Chris Cummins 強調了這項技術的潛在影響:「透過提供兩種大小的預訓練模型(7 億和13 億參數)並透過微調版本展示其有效性, 」他說,「LLM Compiler 為探索LLM 在代碼和編譯器優化領域未被開發的潛力鋪平了道路。」

用於編譯器優化的Code Llama

在在彙編程式碼和編譯器IR 上進行預訓練

用於訓練程式設計LLMs 的資料通常主要由像Python 這樣的高階原始語言組成,彙編程式碼在這些資料集中的比例微乎其微,編譯器IR 的比例更小。

為了建構一個對這些語言有良好理解的LLM,研究團隊用Code Llama 的權重初始化LLM Compiler 模型,然後在一個以編譯器為中心的資料集上訓練4,010 億個token,這個資料集主要由組譯程式碼和編譯器IR 組成,如表1 所示。
开发者狂喜!Meta最新发布的LLM Compiler,实现77%自动调优效率
資料集LLM Compiler 主要在由LLVM(版本17.0.6)產生的編譯器中間表示和彙編程式碼上進行訓練,這些資料來源於用於訓練Code Llama 的相同資料集,已在表2中概述了該資料集。與 Code Llama 一樣,我們也從自然語言資料集中取得少量訓練批次。 开发者狂喜!Meta最新发布的LLM Compiler,实现77%自动调优效率
編譯器模擬的指令微調
 
為了瞭解程式碼最佳化的機制,研究團隊對 LLM Compiler 模型進行指令微調,以模擬編譯器最佳化,如圖 2 所示。
开发者狂喜!Meta最新发布的LLM Compiler,实现77%自动调优效率
其思路是從有限的未最佳化種子程式集合中,透過對這些程式應用隨機產生的編譯器最佳化序列,產生大量範例。然後他們訓練模型預測優化產生的程式碼,也訓練模型預測應用最佳化後的程式碼大小。

任務規範。 給定未經最佳化的 LLVM-IR(由 clang 前端輸出),一個最佳化過程列表,以及一個起始程式碼大小,產生應用這些最佳化後的結果程式碼以及程式碼大小。

這個任務有兩種類型:在第一種中,模型預期輸出編譯器 IR;在第二種中,模型預期輸出彙編程式碼。兩種類型的輸入 IR、最佳化過程和程式碼大小是相同的,提示決定了所需的輸出格式。

程式碼大小。 他們使用兩個指標來衡量程式碼大小:IR 指令數和二進位大小。二進位大小透過將 IR 或彙編降級為目標檔案後,.TEXT 和 .DATA 段大小的總和計算得出。我們排除 .BSS 段,因為它不影響磁碟上的大小。

最佳化 pass。 在這項工作中,研究團隊針對LLVM 17.0.6,並使用新的過程管理器(PM, 2021),它將pass 分類為不同的級別,如模組、函數、循環等,以及轉換和分析pass 。轉換 pass 改變給定的輸入 IR,而分析 pass 產生影響後續轉換的資訊。
 
在 opt 的 346 個可能的 pass 參數中,他們選擇了 167 個使用。這包括每個預設最佳化管線(例如module (default)),單獨的最佳化轉換pass (例如module (constmerge)),但排除了非最佳化實用程式pass (例如module (dot-callgraph)) 和不保留語義的轉換pass (例如module (internalize))。

他們排除了分析 pass,因為它們沒有副作用,我們依賴 pass 管理器根據需要注入依賴的分析 pass。對於接受參數的 pass,我們使用預設值 (例如 module (licm))。表 9 包含了所有使用的 pass 清單。我們使用 LLVM 的 opt 工具應用 pass 列表,並使用 clang 將結果 IR 降級為目標檔案。清單 1 顯示了使用的命令。
开发者狂喜!Meta最新发布的LLM Compiler,实现77%自动调优效率
資料集。 研究團隊透過對表 2 中總結的未最佳化程序應用 1 到 50 個隨機最佳化 pass 清單產生編譯器模擬資料集。每個 pass 清單的長度是均勻隨機選擇的。 pass 清單是透過從上述 167 個 pass 集合中均勻取樣產生的。導致編譯器崩潰或在 120 秒後逾時的 pass 清單被排除。

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

最佳化標誌調音

最佳化標誌調時研究團隊訓練 LLM Compiler FTD 模型執行下游任務,即為 LLVM 的 IR 最佳化工具 opt 選擇標誌,以產生最小的程式碼大小。

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

他們的方法不依賴所選的編譯器和最佳化指標,他們打算在未來針對運行時效能。目前,優化程式碼大小簡化​​了訓練資料的收集。

任務規範。研究團隊向LLM Compiler FTD 模型呈現一個未優化的LLVM-IR (由clang 前端生成),並要求它生成應該應用的opt 標誌列表,這些優化應用前後的二進制大小,以及輸出代碼,如果無法對輸入代碼進行改進,則產生一個只包含未最佳化二進位大小的簡短輸出訊息。

他們使用了與編譯器模擬任務相同的受限最佳化 pass 集,並以相同的方式計算二進位大小。

圖 3 說明了用於產生訓練資料的過程以及如何在推理時使用模型。
开发者狂喜!Meta最新发布的LLM Compiler,实现77%自动调优效率
在評估時只需要產生的 pass 清單。他們從模型輸出中提取 pass 列表,並使用給定的參數來執行 opt。然後,研究人員可以評估模型預測的二進位大小和最佳化輸出程式碼的準確性,但這些是輔助學習任務,不是使用所必需的。

正確性。 LLVM 優化器並非無懈可擊,以意外或未經測試的順序運行優化 pass 可能會暴露出微妙的正確性錯誤,從而降低模型的實用性。為了緩解這種風險,研究團隊開發了 PassListEval,這是一個工具,用於幫助自動識別破壞程式語義或導致編譯器崩潰的 pass 清單。圖 4 顯示了該工具的概覽。
开发者狂喜!Meta最新发布的LLM Compiler,实现77%自动调优效率
PassListEval 接受候選 pass 清單作為輸入,並在一個包含 164 個自測 C++ 程式的套件上進行評估,這些程式取自 HumanEval-X。每個程式都包含一個程式設計挑戰的參考解決方案,例如“檢查給定數字向量中是否有兩個數字之間的距離小於給定閾值”,以及驗證正確性的單元測試套件。他們將候選 pass 清單應用於參考解決方案,然後將它們與測試套件連結以產生二進位檔案。執行時,如果任何測試失敗,二進位檔案將崩潰。如果任何二進位崩潰,或任何編譯器呼叫失敗,我們就拒絕該候選 pass 清單。

資料集。該團隊在一個源自 450 萬個未優化 IR 的標誌調優範例資料集上訓練了 LLM Compiler FTD 模型,這些 IR 用於預訓練。為產生每個程式的最佳 pass 列表範例,他們進行了廣泛的迭代編譯過程,如圖 3 所示。

1. 研究團隊使用大規模隨機搜尋為程式產生初始候選最佳 pass 清單。對每個程序,他們獨立產生最多 50 個 pass 的隨機列表,從先前描述的 167 個可搜尋 pass 集合中均勻取樣。每次他們評估一個程式的 pass 清單時,都會記錄產生的二進位大小,然後選擇產生最小二進位大小的每個程式 pass 清單。他們運行了 220 億次獨立編譯,平均每個程式 4,877 次。

2. 隨機搜尋產生的 pass 清單可能包含冗餘 pass,這些 pass 對最終結果沒有影響。此外,有些 pass 順序是可交換的,重新排序不會影響最終結果。由於這些會在訓練資料中引入噪聲,他們開發了一個最小化過程,並將其應用於每個 pass 清單。

最小化包括三個步驟:冗餘 pass 消除、冒泡排序和插入搜尋。在冗餘 pass 消除中,他們透過迭代刪除單個 pass 來最小化最佳 pass 列表,看它們是否對二進位大小有貢獻,如果沒有,就丟棄它們。重複此過程,直到不能再丟棄 pass。然後冒泡排序嘗試為 pass 子序列提供統一排序,根據關鍵字對 pass 進行排序。最後,插入排序透過遍歷 pass 清單中的每個 pass 並嘗試在其之前插入 167 個搜尋 pass 中的每一個來執行局部搜尋。如果這樣做改善了二進位大小,就保留這個新的 pass 清單。整個最小化管道循環直到達到固定點。最小化後的 pass 列表長度分佈如圖 9 所示。平均 pass 列表長度為 3.84。

3. 他們將先前描述 PassListEval 應用於候選最佳 pass 清單。透過這種方式,他們確定了1,704,443 個獨立pass 列表中的167,971 個(9.85%) 會導致編譯時或運行時錯

4. 他們將100 個最常見的最優pass 列表廣播到所有程序,如果發現改進就更新每個程序的最佳pass 清單。之後,唯一最佳 pass 清單的總數從 1,536,472 減少到 581,076。

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

 反彙編的指令微調

將程式碼從彙編語言提升到更高層次的結構,或將執行額外的最佳化,例如直接整合到應用程式中的程式碼遺留程式碼移植到新架構。反編譯領域在將機器學習技術應用於從二進位執行檔生成可讀和準確的程式碼方面取得了進展。在本研究中,研究團隊展示了 LLM Compiler FTD 如何透過微調進行反彙編,學習彙編程式碼和編譯器 IR 之間的關係。任務是學習 clang -xir - -o - -S 的逆向翻譯,如圖 5 所示。
开发者狂喜!Meta最新发布的LLM Compiler,实现77%自动调优效率
往返測驗。使用 LLM 進行反彙編會導致正確性問題。提升的程式碼必須透過等價性檢查器進行驗證,這並不總是可行的,或需要手動驗證正確性,或經過充分的測試案例以獲得信心。然而,可以透過往返測試找到正確性的下限。也就是說,透過將提升的 IR 重新編譯成彙編程式碼,如果彙編程式碼是相同的,則 IR 是正確的。這為使用 LLM 的結果提供了一條簡單途徑,並且是衡量反組譯模型效用的簡單方法。

任務規範。研究團隊向模型提供彙編程式碼,並訓練它發出相應的反彙編 IR。這項任務的上下文長度設定為輸入彙編代碼 8k 個 token 和輸出 IR8k 個 token。

資料集。他們從先前任務中使用的資料集中派生出彙編程式碼和 IR 對。他們的微調資料集包含 470 萬個樣本,輸入 IR 在降低到 x86 彙編之前已經使用 - Oz 進行了最佳化。

訓練參數 

資料透過位元組標記編碼化,使用與 Code Llama、Llama 和 Llama 2 相同的標記器。他們對所有四個訓練階段都使用相同的訓練參數。他們使用的訓練參數大多與 Code Llama 基礎模型相同,使用 AdamW 優化器,β1 和 β2 的值為 0.9 和 0.95。他們使用餘弦調度,預熱步驟為 1000 步,並將最終學習率設定為峰值學習率的 1/30。

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

 評估
 
該研究團隊評估 LLM Compiler 模型在標誌調優和反彙編任務、編譯器模擬、下一個 token 預測以及軟體工程任務上的表現。
 
標誌調優任務
 
方法。他們評估 LLM Compiler FTD 在未見程序的最佳化標誌調優任務上的表現,並與 GPT-4 Turbo 和 Code Llama - Instruct 進行比較。他們對每個模型運行推理,從模型輸出中提取優化 pass 列表,然後他們使用這個 pass 列表來優化特定程式並記錄二進位大小,基線是使用 -Oz 優化時程式的二進位大小。
 
對於 GPT-4 Turbo 和 Code Llama - Instruct,他們在提示後附加一個後綴,提供額外上下文以進一步描述問題和預期輸出格式。
 
所有模型產生的 pass 清單都使用 PassListEval 進行驗證,如果驗證失敗則使用 -Oz 作為替代。為進一步驗證模型產生的 pass 清單的正確性,他們連結最終的程式二進位文件,並將其輸出與使用保守的 -O2 最佳化管道最佳化的基準輸出進行差分測試。
 
資料集。研究團隊使用從 MiBench 基準套件提取的 2,398 個測試提示進行評估。為產生這些提示,他們取構成 24 個 MiBench 基準的所有 713 個翻譯單元,並從每個單元產生未最佳化的 IR,然後將它們格式化為提示。如果產生的提示超過15k tokens,他們使用llvm-extract 將代表該翻譯單元的LLVM 模組分割成更小的模組,每個函數一個,這導致1,985 個提示適合15k token 上下文窗口,剩下443 個翻譯單元不適合。在計算效能分數時,他們對 443 個被排除的翻譯單元使用 -Oz。表 10 總結了基準。
开发者狂喜!Meta最新发布的LLM Compiler,实现77%自动调优效率
結果。表 3 顯示了所有模型在標誌調優任務上的零樣本表現。只有 LLM Compiler FTD 模型比 -Oz 有所改進,13B 參數模型略優於較小的模型,在 61% 的情況下產生比 -Oz 更小的目標檔。
开发者狂喜!Meta最新发布的LLM Compiler,实现77%自动调优效率
在某些情況下,模型產生的 pass 清單會導致比 -Oz 更大的目標檔案大小。例如,LLM Compiler FTD 13B 在 12% 的情況下有退化。這些退化可以透過簡單地編譯程式兩次來避免:一次使用模型產生的 pass 列表,一次使用 -Oz,然後選擇產生最佳結果的 pass 列表。透過消除相對於-Oz 的退化,這些-Oz 備份分數將LLM Compiler FTD 13B 相對於-Oz 的整體改進提高到5.26%,並使Code Llama - Instruct 和GPT-4 Turbo 相對於-Oz 有適度的改進。圖 6 顯示了每個模型在各個基準上的效能細分。
开发者狂喜!Meta最新发布的LLM Compiler,实现77%自动调优效率
 二進位大小準確度。雖然模型產生的二進位大小預測對實際編譯沒有影響,但研究團隊可以評估模型在預測最佳化前後的二進位大小的效能,以了解每個模型對最佳化的理解程度。圖 7 顯示了結果。
开发者狂喜!Meta最新发布的LLM Compiler,实现77%自动调优效率
LLM Compiler FTD 的二進位大小預測與實際情況相關性良好,7B 參數模型對未最佳化和最佳化的二進位大小分別達到了 0.083 和 0.225 的 MAPE 值。 13B 參數模型的 MAPE 值相似,分別為 0.082 和 0.225。 Code Llama - Instruct 和 GPT-4 Turbo 的二進位大小預測與實際情況幾乎沒有相關性。研究人員注意到,LLM Compiler FTD 對最佳化程式碼的錯誤略高於未最佳化程式碼。特別是 LLM Compiler FTD 偶爾有高估優化效果的趨勢,導致預測的二進位大小低於實際情況。

消融研究。表 4 對模型在 500 個提示的小型保留驗證集上的表現進行了消融研究,這些提示來自與他們訓練資料相同的分佈 (但未在訓練中使用)。他們在圖 1 所示訓練管道的每個階段進行標誌調優訓練,以比較表現。如圖所示,反組譯訓練導致表現從平均 5.15% 略微下降到 5.12%(相對於 -Oz 的改進)。他們還展示了用於產生第 2 節所述訓練資料的自動調優器的性能。 LLM Compiler FTD 達到了自動調優器 77% 的效能。
开发者狂喜!Meta最新发布的LLM Compiler,实现77%自动调优效率
 反組譯任務
 
方法。研究團隊評估 LLM 產生的程式碼在將彙編程式碼反彙編到 LLVM-IR 時的功能正確性。他們評估 LLM Compiler FTD 並與 Code Llama - Instruct 和 GPT-4 Turbo 進行比較,發現需要額外的提示後綴才能從這些模型中提取最佳性能。
 
後綴提供了任務和預期輸出格式的額外上下文。為評估模型的效能,他們將模型產生的反彙編 IR 往返降級回彙編。這使我們能夠透過比較原始彙編與往返結果的 BLEU 分數來評估反彙編的準確性。從彙編到 IR 的無損完美反組譯將有 1.0 的往返 BLEU 分數 (精確匹配)。
 
資料集。他們使用從 MiBench 基準套件提取的 2,015 個測試提示進行評估,取用於上述標誌調優評估的 2,398 個翻譯單元,產生反彙編提示。然後他們根據最大 8k token 長度過濾提示,允許 8k tokens 用於模型輸出,剩下 2,015 個。表 11 總結了基準。
开发者狂喜!Meta最新发布的LLM Compiler,实现77%自动调优效率
結果。表 5 顯示了模型在反組譯任務上的表現。
开发者狂喜!Meta最新发布的LLM Compiler,实现77%自动调优效率
LLM Compiler FTD 7B 的往返成功率略高於 LLM Compiler FTD 13B,但 LLM Compiler FTD 13B 具有最高的往返彙編準確性 (往返 BLEU) 和最頻繁產生完美反彙編 (精確往返彙編)。 Code Llama - Instruct 和 GPT-4 Turbo 在產生語法正確的 LLVM-IR 方面有困難。圖 8 顯示了所有模型的往返 BLEU 分數分佈。
开发者狂喜!Meta最新发布的LLM Compiler,实现77%自动调优效率
消融研究。表 6 對模型在 500 個提示的小型保留驗證集上的表現進行了消融研究,這些提示取自先前使用的 MiBench 資料集。
开发者狂喜!Meta最新发布的LLM Compiler,实现77%自动调优效率
他們在圖 1 所示訓練管道的每個階段進行反組譯訓練,以比較表現。往返率在通過整個訓練資料堆疊時最高,並隨每個訓練階段持續下降,儘管往返 BLEU 在每個階段變化不大。
 
 基礎模型任務
 
方法。研究團隊在下一個 token 預測和編譯器模擬兩個基礎模型任務上對 LLM Compiler 模型進行消融研究。他們在訓練管道的每個階段進行這種評估,以了解為每個連續任務訓練如何影響表現。對於下一個 token 預測,他們在所有最佳化等級的 LLVM-IR 和彙編程式碼的小樣本上計算困惑度。他們使用兩個指標來評估編譯器模擬:產生的 IR 或彙編程式碼是否編譯,以及產生的 IR 或彙編程式碼是否與編譯器產生的完全匹配。
 
資料集。對於下一個 token 預測,他們使用從與我們訓練資料相同分佈但未用於訓練的小型保留驗證資料集。他們使用混合的優化級別,包括未優化程式碼、用 -Oz 優化的程式碼和隨機生成的 pass 列表。對於編譯器模擬,他們使用從 MiBench 產生的 500 個提示進行評估,這些提示使用第 2.2 節描述的方式隨機產生的 pass 清單。
 
結果。表 7 顯示了 LLM Compiler FTD 在所有訓練階段在兩個基礎模型訓練任務 (下一個 token 預測和編譯器模擬) 上的表現。下一個 token 預測性能在 Code Llama 之後急劇上升,後者幾乎沒有見過 IR 和彙編,並在隨後的每個微調階段略有下降。
开发者狂喜!Meta最新发布的LLM Compiler,实现77%自动调优效率
對於編譯器模擬,Code Llama 基礎模型和預訓練模型表現不佳,因為它們沒有在這個任務上訓練過。在編譯器模擬訓練之後直接達到最高效能,其中 LLM Compiler FTD 13B 產生的 95.6% 的 IR 和彙編可以編譯,20% 與編譯器完全匹配。在進行標誌調優和反彙編微調後,效能下降。
 
軟體工程任務
 
方法。雖然 LLM Compiler FTD 的目的是為程式碼最佳化提供基礎模型,但它建立在為軟體工程任務訓練的基礎 Code Llama 模型之上。為評估LLM Compiler FTD 的額外訓練如何影響程式碼產生的效能,他們使用與Code Llama 相同的基準套件,評估LLM 從自然語言提示產生Python 程式碼的能力,例如「編寫一個函數,找出可以從給定的對集合形成的最長鏈。他們使用 HumanEval 和 MBPP 基準,與 Code Llama 相同。
 
結果。表 8 顯示了從 Code Llama 基礎模型開始的所有模型訓練階段和模型大小的貪婪解碼效能 (pass@1)。它也顯示了模型在 pass@10 和 pass@100 上的分數,這些分數是用 p=0.95 和 temperature=0.6 產生的。每個以編譯器為中心的訓練階段都導致 Python 程式設計能力略有退化。在 HumanEval 和 MBPP 上,LLM Compiler 的 pass@1 性能最多下降 18% 和 5%,LLM Compiler FTD 在額外的標誌調優和反彙編微調後最多下降 29% 和 22%。所有模型在這兩個任務上仍然優於 Llama 2。
开发者狂喜!Meta最新发布的LLM Compiler,实现77%自动调优效率
局限性
 
Meta 研究團隊已經展示了LLM Compiler 在編譯器優化任務上表現良好,並且相比先前的工作,對編譯器表示改進和彙編程式碼的理解但仍存在一些限制。主要限制是輸入的有限序列長度 (上下文視窗)。

LLM Compiler 支援 16k tokens 的上下文窗口,但程式碼可能遠遠超過這個長度。例如,當格式化為標誌調優提示時,67% 的 MiBench 翻譯單元超過了這個上下文窗口,如表 10 所示。
开发者狂喜!Meta最新发布的LLM Compiler,实现77%自动调优效率
為了緩解這一問題,他們將較大的翻譯單元拆分為單獨的函數,儘管這限制了可以執行的優化範圍,而且仍有18% 的拆分翻譯單元對模型來說太大,無法作為輸入接受。研究人員正在採用不斷增加的上下文窗口,但有限的上下文窗口仍然是 LLM 的一個普遍問題。
 
第二個限制,也是所有 LLM 的共同問題,是模型輸出的準確度。建議 LLM Compiler 的使用者使用特定於編譯器的評估基準來評估他們的模型。鑑於編譯器並非無 bug,任何建議的編譯器最佳化都必須經過嚴格測試。當模型反編譯彙編程式碼時,其準確性應透過往返、人工檢查或單元測試來確認。對於某些應用,LLM 產生可以被限制在正規表示式內,或與自動驗證結合以確保正確性。

參考連結:
https://x.com/AIatMeta/status/1806361623831713238317132383. 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

以上是開發者狂喜! Meta最新發布的LLM Compiler,實現77%自動調校效率的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn