개발자들은 신이 납니다! Meta의 최신 LLM 컴파일러 릴리스는 77%의 자동 튜닝 효율성을 달성했습니다.-일체 포함-php.cn

Meta는 프로그래머가 코드를 보다 효율적으로 작성할 수 있도록 돕는 멋진 LLM 컴파일러를 개발했습니다.

어제 AI 3대 기업인 OpenAI, Google, Meta가 협력하여 자체 대형 모델의 최신 연구 결과를 발표했습니다. -

OpenAI가 GPT-4 기반의 새로운 모델 CriticGPT를 출시했습니다. 버그 발견을 전문으로 하는 교육, Google 오픈소스 9B 및 27B 버전의 Gemma2, 그리고 Meta가 최신 인공지능 획기적인 LLM 컴파일러를 내놓았습니다.

이것은 코드를 최적화하고 컴파일러 디자인에 혁명을 일으키도록 설계된 강력한 오픈 소스 모델 세트입니다. 이러한 혁신은 개발자가 코드 최적화에 접근하는 방식을 변화시켜 더 빠르고 효율적이며 비용 효율적으로 만들 수 있는 잠재력을 가지고 있습니다.

LLM 컴파일러의 최적화 잠재력은 자동 튜닝 검색의 77%에 도달한다고 보고되었습니다. 이 결과는 컴파일 시간을 크게 줄이고 다양한 응용 프로그램의 코드 효율성을 향상시킬 수 있으며 분해 측면에서도 라운드가 가능합니다. 여행 분해 성공률은 45%입니다.

일부 네티즌들은 이것이 코드 최적화 및 분해의 게임 체인저와 같다고 말했습니다.

이것은 개발자에게 매우 좋은 소식입니다.

개요

대형 언어 모델은 많은 소프트웨어 엔지니어링 및 프로그래밍 작업에서 탁월한 기능을 보여줬지만 코드 최적화 및 컴파일러 분야에서의 적용은 완전히 활용되지 않았습니다. 이러한 LLM을 교육하려면 값비싼 GPU 시간과 대규모 데이터 세트를 비롯한 광범위한 컴퓨팅 리소스가 필요하므로 많은 연구와 프로젝트를 지속 불가능하게 만드는 경우가 많습니다.

이러한 격차를 메우기 위해 Meta 연구팀은 특히 코드를 최적화하고 컴파일러 설계에 혁신을 가져오는 LLM 컴파일러를 도입했습니다. 5,460억 개의 LLVM-IR 토큰과 어셈블리 코드로 구성된 대규모 자료에서 모델을 훈련함으로써 모델이 컴파일러 중간 표현, 어셈블리 언어 및 최적화 기술을 이해할 수 있게 되었습니다.

논문 링크: https://ai.meta.com/research/publications/meta-large-언어-model-compiler-foundation-models-of-compiler-optimization/

"의 연구원 LLM 컴파일러는 컴파일러 중간 표현(IR), 어셈블리 언어 및 최적화 기술에 대한 향상된 이해를 제공합니다.” 이러한 향상된 이해를 통해 모델은 이전에는 인간 전문가 또는 전문 도구로 제한되었던 작업을 수행할 수 있습니다.

LLM 컴파일러의 교육 과정은 그림 1에 나와 있습니다.

LLM 컴파일러는 코드 크기 최적화에서 상당한 결과를 달성합니다. 테스트에서 모델의 최적화 잠재력은 자동 튜닝 검색의 77%에 도달했으며, 그 결과 컴파일 시간을 크게 줄이고 다양한 애플리케이션의 코드 효율성을 향상시킬 수 있습니다.

해체성이 더 좋은 모델입니다. LLM 컴파일러는 x86_64 및 ARM 어셈블리 코드를 다시 LLVM-IR로 변환할 때 45%의 왕복 디스어셈블리 성공률(정확히 일치하는 비율은 14%)을 달성합니다. 이 기능은 리버스 엔지니어링 작업 및 레거시 코드 유지 관리에 매우 중요할 수 있습니다.

이 프로젝트의 핵심 기여자 중 한 명인 Chris Cummins는 이 기술의 잠재적인 영향을 다음과 같이 강조했습니다. “두 가지 크기(7억 및 13억 매개변수)로 사전 훈련된 모델을 제공하고 미세한 조정된 버전에서는 "LLM 컴파일러는 코드 및 컴파일러 최적화 분야에서 LLM의 미개척 잠재력을 탐색할 수 있는 길을 열어줍니다."라고 그는 말했습니다. 어셈블리 코드 및 컴파일러 IR에 대한 사전 교육

프로그래밍 교육에 사용되는 데이터입니다. LLM은 일반적으로 Python과 같은 고급 소스 언어로 주로 구성되며 어셈블리 코드는 이러한 데이터 세트에서 무시할 수 있는 비율을 차지하고 컴파일러 IR은 더 작은 비율을 차지합니다.

이러한 언어에 대한 이해가 풍부한 LLM을 구축하기 위해 연구팀은 Code Llama의 가중치로 LLM 컴파일러 모델을 초기화한 다음 컴파일러 중심 데이터 세트에서 4,010억 개의 토큰을 훈련했습니다. 표 1과 같이 어셈블리 코드와 컴파일러 IR로 구성됩니다.

데이터 세트 LLM 컴파일러는 주로 LLVM(버전 17.0.6)에서 생성된 컴파일러 중간 표현 및 어셈블리 코드에 대해 교육됩니다. 이러한 데이터는 표 2에 보고된 Code Llama 교육에 사용된 것과 동일한 데이터 세트에서 파생됩니다. 데이터 세트는 에 설명되어 있습니다. Code Llama와 마찬가지로 자연어 데이터 세트에서 소규모 교육 배치도 얻습니다. 开发者狂喜！Meta最新发布的LLM Compiler，实现77%自动调优效率

컴파일러 시뮬레이션을 위한 명령어 미세 조정

코드 최적화 메커니즘을 이해하기 위해 연구팀은 그림 2와 같이 LLM 컴파일러 모델에서 명령어 미세 조정을 수행하여 컴파일러 최적화를 시뮬레이션했습니다.

이 아이디어는 무작위로 생성된 컴파일러 최적화 시퀀스를 이러한 프로그램에 적용하여 최적화되지 않은 제한된 시드 프로그램 모음에서 많은 수의 예제를 생성하는 것입니다. 그런 다음 최적화로 생성된 코드를 예측하도록 모델을 훈련시켰고, 최적화를 적용한 후 코드 크기를 예측하도록 모델도 훈련했습니다.

작업 사양. 최적화되지 않은 LLVM-IR(clang 프런트엔드의 출력), 최적화 패스 목록 및 시작 코드 크기가 주어지면 이러한 최적화를 적용한 후 결과 코드와 코드 크기를 생성합니다.

이 작업에는 두 가지 유형이 있습니다. 첫 번째에서는 모델이 컴파일러 IR을 출력할 것으로 예상하고, 두 번째에서는 모델이 어셈블리 코드를 출력할 것으로 예상합니다. 입력 IR, 최적화 프로세스 및 코드 크기는 두 유형 모두 동일하며 힌트에 따라 필요한 출력 형식이 결정됩니다.

코드 크기. 코드 크기를 측정하기 위해 IR 명령어 수와 바이너리 크기라는 두 가지 측정항목을 사용합니다. 바이너리 크기는 IR 또는 어셈블리를 개체 파일로 다운그레이드한 후 .TEXT 및 .DATA 세그먼트 크기의 합으로 계산됩니다. .BSS 세그먼트는 디스크 크기에 영향을 주지 않으므로 제외합니다.

패스 최적화. 본 연구에서 연구팀은 LLVM 17.0.6을 목표로 하며 새로운 프로세스 관리자(PM, 2021)를 사용하여 패스를 모듈, 함수, 루프 등 다양한 수준으로 분류하고 패스를 변환하고 분석합니다. . 변환 단계는 지정된 입력 IR을 변경하는 반면, 분석 단계는 후속 변환에 영향을 미치는 정보를 생성합니다.

opt에 가능한 346개의 통과 매개변수 중 167개를 선택하여 사용했습니다. 여기에는 모든 기본 최적화 파이프라인(예: 모듈(default)), 개별 최적화 변환 패스(예: 모듈(constmerge))가 포함되지만 최적화되지 않은 유틸리티 패스(예: 모듈(dot-callgraph))는 제외되고 의미 변환 패스는 유지되지 않습니다. (예: 모듈(내부화)).

부작용이 없기 때문에 분석 패스를 제외하고 필요에 따라 종속 분석 패스를 주입하기 위해 패스 관리자에 의존합니다. 매개변수를 허용하는 패스의 경우 기본값(예: 모듈(licm))을 사용합니다. 표 9에는 사용된 모든 패스 목록이 포함되어 있습니다. LLVM의 opt 도구를 사용하여 통과 목록을 적용하고 clang을 사용하여 결과 IR을 개체 파일로 다운그레이드합니다. 목록 1은 사용된 명령을 보여줍니다.

데이터세트. 연구팀은 표 2에 요약된 최적화되지 않은 프로그램에 1~50개의 무작위 최적화 패스 목록을 적용하여 컴파일러 시뮬레이션 데이터 세트를 생성했습니다. 각 합격 목록의 길이는 균일하고 무작위로 선택됩니다. 패스 목록은 위의 167개 패스 세트에서 균일하게 샘플링하여 생성됩니다. 120초 후에 컴파일러가 충돌하거나 시간 초과되는 원인이 되는 통과 목록은 제외됩니다.

LLM 컴파일러 FTD: 다운스트림 컴파일 작업 확장

최적화 플래그 튜닝을 위한 명령 미세 조정

컴파일러 플래그 조작은 런타임 성능과 코드 크기에 상당한 영향을 미칩니다. 연구팀은 가장 작은 코드 크기를 생성하도록 선택하는 LLVM의 IR 최적화 도구에 대한 플래그를 선택하는 다운스트림 작업을 수행하도록 LLM 컴파일러 FTD 모델을 교육했습니다.

플래그 조정 기계 학습 방법은 이전에 좋은 결과를 보여주었지만 다양한 프로그램 전반에 걸쳐 일반화하는 데 어려움을 겪었습니다.이전 작업에서는 다양한 구성을 시도하고 가장 성능이 좋은 옵션을 찾기 위해 새로운 프로그램을 수십, 수백 번 컴파일해야 하는 경우가 많았습니다. 연구팀은 보이지 않는 프로그램의 코드 크기를 최소화하기 위해 플래그를 예측함으로써 이 작업의 제로샷 버전에서 LLM 컴파일러 FTD 모델을 훈련하고 평가했습니다.

그들의 접근 방식은 선택한 컴파일러 및 최적화 지표에 의존하지 않으며 향후 런타임 성능을 목표로 삼고 있습니다. 현재 코드 크기를 최적화하면 훈련 데이터 수집이 단순화됩니다.

작업 사양. 연구팀은 최적화되지 않은 LLVM-IR(clang 프런트엔드에서 생성됨)을 LLM 컴파일러 FTD 모델에 제시하고 적용해야 하는 opt 플래그 목록, 이러한 최적화 적용 전후의 바이너리 크기 및 입력 코드에서 사용할 수 없는 경우 출력 코드 최적화되지 않은 바이너리 크기만 포함하는 짧은 출력 메시지를 생성하도록 개선되었습니다.

그들은 컴파일러 시뮬레이션 작업과 동일한 제한된 최적화 패스 세트를 사용하고 동일한 방식으로 바이너리 크기를 계산했습니다.

그림 3은 훈련 데이터를 생성하는 데 사용되는 프로세스와 추론 시 모델이 사용되는 방식을 보여줍니다.

평가 중에는 생성된 합격 목록만 필요합니다. 모델 출력에서 합격 목록을 추출하고 주어진 매개변수를 사용하여 opt를 실행합니다. 그런 다음 연구원은 모델의 예측 바이너리 크기의 정확성을 평가하고 출력 코드를 최적화할 수 있지만 이는 보조 학습 작업이므로 사용에 필요하지 않습니다.

정확함. LLVM 최적화 프로그램은 오류가 없는 것이 아니며 예상치 못한 순서 또는 테스트되지 않은 순서로 최적화 과정을 실행하면 모델의 유용성을 감소시키는 미묘한 정확성 오류가 노출될 수 있습니다. 이러한 위험을 완화하기 위해 연구팀은 프로그램 의미 체계를 깨뜨리거나 컴파일러 충돌을 일으키는 통과 목록을 자동으로 식별하는 데 도움이 되는 도구인 PassListEval을 개발했습니다. 그림 4는 도구 개요를 보여줍니다.

PassListEval은 후보 합격 목록을 입력으로 받아들이고 HumanEval-X에서 가져온 164개의 자체 테스트 C++ 프로그램 제품군에서 이를 평가합니다. 각 프로그램에는 "주어진 숫자 벡터에서 두 숫자 사이의 거리가 주어진 임계값보다 작은지 확인"과 같은 프로그래밍 문제에 대한 참조 솔루션과 정확성을 확인하기 위한 일련의 단위 테스트가 포함되어 있습니다. 후보 패스 목록을 참조 솔루션에 적용한 다음 이를 테스트 스위트와 연결하여 바이너리를 생성합니다. 실행하는 동안 테스트가 실패하면 바이너리가 충돌합니다. 바이너리가 충돌하거나 컴파일러 호출이 실패하면 후보 통과 목록을 거부합니다.

데이터세트. 팀은 사전 훈련에 사용된 450만 개의 최적화되지 않은 IR에서 파생된 플래그 조정 예제 데이터 세트에서 LLM 컴파일러 FTD 모델을 훈련했습니다. 각 프로그램에 대한 최상의 합격 목록 예를 생성하기 위해 그림 3과 같이 광범위한 반복 컴파일 프로세스를 수행했습니다.

1. 연구팀은 대규모 무작위 검색을 사용하여 프로그램에 대한 초기 후보 베스트 합격 목록을 생성합니다. 각 프로그램에 대해 그들은 이전에 설명한 검색 가능한 167개 패스 세트에서 균일하게 샘플링된 최대 50개 패스의 무작위 목록을 독립적으로 생성했습니다. 프로그램의 통과 목록을 평가할 때마다 결과 바이너리 크기를 기록한 다음 가장 작은 바이너리 크기를 생성하는 각 프로그램의 통과 목록을 선택했습니다. 그들은 220억 개의 독립 편집물을 실행했는데, 이는 프로그램당 평균 4,877개였습니다.

2. 무작위 검색으로 생성된 합격 목록에는 최종 결과에 영향을 미치지 않는 중복된 합격이 포함될 수 있습니다. 또한 일부 패스 순서는 서로 바꿔서 사용할 수 있으며 순서를 변경해도 최종 결과에는 영향을 미치지 않습니다. 이는 훈련 데이터에 노이즈를 도입하기 때문에 최소화 프로세스를 개발하여 이를 각 합격 목록에 적용했습니다.

최소화에는 중복 패스 제거, 버블 정렬, 삽입 검색의 세 단계가 포함됩니다. 중복 패스 제거에서는 개별 패스를 반복적으로 제거하여 바이너리 크기에 기여하는지 확인하고 그렇지 않은 경우 폐기하여 최적의 패스 목록을 최소화합니다. 더 이상 패스를 삭제할 수 없을 때까지 이 과정을 반복합니다. 그런 다음 버블 정렬은 패스 하위 시퀀스에 대한 통합된 순서를 제공하고 키워드를 기반으로 패스를 정렬하려고 시도합니다. 마지막으로 삽입 정렬은 패스 목록의 각 패스를 반복하고 그 앞에 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와 동일한 토크나이저를 사용하여 바이트 쌍 인코딩을 통해 토큰화됩니다. 네 가지 훈련 단계 모두에 동일한 훈련 매개변수를 사용합니다. 그들은 β1과 β2에 대해 0.9와 0.95 값을 갖는 AdamW 최적화 프로그램을 사용하여 Code Llama 기본 모델과 동일한 훈련 매개변수를 대부분 사용했습니다. 그들은 워밍업 단계가 1000단계인 코사인 스케줄링을 사용하고 최종 학습 속도를 최고 학습 속도의 1/30으로 설정했습니다.

Code Llama 기본 모델과 비교하여 팀은 단일 시퀀스의 컨텍스트 길이를 4096에서 16384로 늘렸지만 배치 크기는 400만 토큰으로 일정하게 유지했습니다. 더 긴 컨텍스트를 수용하기 위해 학습률을 2e-5로 설정하고 RoPE 위치 임베딩의 매개변수를 수정하여 빈도를 기본 값 θ=10^6으로 재설정했습니다. 이러한 설정은 Code Llama 기본 모델의 장기 컨텍스트 교육과 일치합니다.

평가

연구팀은 플래그 튜닝 및 분해 작업, 컴파일러 시뮬레이션, 다음 토큰 예측 및 소프트웨어 엔지니어링 작업에 대한 LLM 컴파일러 모델의 성능을 평가합니다.

플래그 튜닝 작업

방법. 그들은 보이지 않는 프로그램에 대한 최적화 플래그 조정 작업에서 LLM 컴파일러 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 모듈을 함수당 하나씩 더 작은 모듈로 분할합니다. 결과적으로 15,000개 토큰 컨텍스트 창에 맞는 1,985개의 힌트가 생성되고 443개의 번역 단위가 남습니다. 적합하지 않음 . 성능 점수를 계산할 때 제외된 443개의 번역 단위에 대해 -Oz를 사용했습니다. 표 10에는 벤치마크가 요약되어 있습니다.

결과. 표 3은 플래그 튜닝 작업에 대한 모든 모델의 제로샷 성능을 보여줍니다. LLM Compiler FTD 모델만이 -Oz보다 개선되었으며, 13B 매개변수 모델은 더 작은 모델보다 성능이 약간 뛰어나 61%의 경우 -Oz보다 작은 개체 파일을 생성했습니다.

어떤 경우에는 모델에서 생성된 합격 목록이 -Oz보다 대상 파일 크기가 더 커졌습니다. 예를 들어, LLM 컴파일러 FTD 13B의 경우 12%에서 성능 저하가 발생했습니다. 프로그램을 두 번 컴파일하면 이러한 성능 저하를 피할 수 있습니다. 한 번은 모델에 의해 생성된 합격 목록으로 한 번은 -Oz로 한 번, 그런 다음 최상의 결과를 산출하는 합격 목록을 선택합니다. -Oz와 관련된 저하를 제거함으로써 이러한 -Oz 백업 점수는 -Oz와 관련된 LLM 컴파일러 FTD 13B의 전반적인 개선을 5.26%로 높이고 Code Llama - Instruct 및 GPT-4 Turbo를 활성화하여 -Oz와 관련된 약간의 개선을 달성할 수 있습니다. 그림 6은 다양한 벤치마크에서 각 모델의 성능 분석을 보여줍니다.

바이너리 크기 정확도. 모델에 의해 생성된 바이너리 크기 예측은 실제 컴파일에 영향을 미치지 않지만, 연구팀은 최적화 전후의 바이너리 크기 예측에서 모델의 성능을 평가하여 각 모델이 최적화를 얼마나 잘 이해하는지 이해할 수 있습니다. 그림 7은 결과를 보여줍니다.

LLM 컴파일러 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 컴파일러 FTD를 평가하고 이를 Code Llama - Instruct 및 GPT-4 Turbo와 비교하고 이러한 모델에서 최상의 성능을 추출하려면 추가 힌트 접미사가 필요하다는 것을 발견했습니다.

접미사는 작업 및 예상 출력 형식에 대한 추가 컨텍스트를 제공합니다. 모델의 성능을 평가하기 위해 모델에서 생성된 분해 IR을 다시 조립으로 왕복 다운그레이드했습니다. 이를 통해 원래 어셈블리의 BLEU 점수를 왕복 결과와 비교하여 분해의 정확성을 평가할 수 있습니다.조립부터 IR까지 무손실 완벽한 분해의 왕복 BLEU 점수는 1.0(정확 일치)입니다.

데이터세트. 그들은 위의 플래그 튜닝 평가에 사용된 2,398개의 번역 단위를 사용하여 MiBench 벤치마크 제품군에서 추출한 2,015개의 테스트 힌트를 사용하여 평가하여 디스어셈블리 힌트를 생성했습니다. 그런 다음 최대 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는 각 단계에서 거의 변하지 않습니다.

기본 모델 작업

방법. 연구팀은 다음 토큰 예측과 컴파일러 시뮬레이션이라는 두 가지 기본 모델 작업에 대해 LLM 컴파일러 모델에 대한 절제 연구를 수행했습니다. 그들은 각 연속 작업에 대한 훈련이 성과에 어떤 영향을 미치는지 이해하기 위해 훈련 파이프라인의 각 단계에서 이 평가를 수행합니다. 다음 토큰 예측을 위해 모든 최적화 수준에서 작은 LLVM-IR 샘플과 어셈블리 코드에 대한 복잡성을 계산합니다. 생성된 IR 또는 어셈블리 코드가 컴파일되는지 여부와 생성된 IR 또는 어셈블리 코드가 컴파일러가 생성하는 것과 정확히 일치하는지 여부라는 두 가지 측정항목을 사용하여 컴파일러 시뮬레이션을 평가합니다.

데이터세트. 다음 토큰 예측을 위해 훈련 데이터와 동일한 분포의 작은 홀드아웃 검증 데이터 세트를 사용하지만 훈련에는 사용되지 않습니다. 최적화되지 않은 코드, -Oz로 최적화된 코드, 무작위로 생성된 통과 목록을 포함한 최적화 수준을 혼합하여 사용합니다. 컴파일러 시뮬레이션의 경우 섹션 2.2에 설명된 방식으로 무작위로 생성된 합격 목록을 사용하여 MiBench에서 생성된 500개의 팁을 사용하여 평가되었습니다.

결과. 표 7은 모든 교육 단계에서 두 가지 기본 모델 교육 작업(다음 토큰 예측 및 컴파일러 시뮬레이션)에 대한 LLM 컴파일러 FTD의 성능을 보여줍니다. 다음 토큰 예측 성능은 IR 및 어셈블리를 거의 볼 수 없는 Code Llama 이후 급격하게 상승하며, 이후의 미세 조정 단계마다 약간씩 감소합니다.

컴파일러 시뮬레이션의 경우 Code Llama 기본 모델과 사전 훈련된 모델은 이 작업에 대해 훈련되지 않았기 때문에 제대로 수행되지 않습니다. LLM 컴파일러 FTD 13B 컴파일에서 생성된 IR 및 어셈블리의 95.6%가 컴파일러와 정확히 일치하고 20%가 컴파일러 시뮬레이션 교육 직후에 최대 성능에 도달합니다. 플래그 튜닝 및 분해 미세 튜닝을 한 후 성능이 저하되었습니다.

소프트웨어 엔지니어링 작업

방법. LLM 컴파일러 FTD의 목적은 코드 최적화를 위한 기본 모델을 제공하는 것이지만 소프트웨어 엔지니어링 작업용으로 교육된 기본 Code Llama 모델을 기반으로 구축되었습니다. LLM 컴파일러 FTD의 추가 교육이 코드 생성 성능에 어떤 영향을 미치는지 평가하기 위해 Code Llama와 동일한 벤치마크 제품군을 사용하여 "가장 긴 체인을 찾는 함수 작성"과 같은 자연어 프롬프트에서 Python 코드를 생성하는 LLM의 기능을 평가했습니다. 세트의 쌍으로 구성됩니다. 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보다 성능이 뛰어납니다.

제한 사항

Meta 연구팀은 LLM 컴파일러가 컴파일러 최적화 작업에서 우수한 성능을 발휘하고 이전 작업에 비해 컴파일러 표현 및 어셈블리 코드에 대한 이해도가 향상되었음을 입증했지만 여전히 몇 가지 제한 사항이 있습니다. 주요 제한 사항은 입력(컨텍스트 창)의 시퀀스 길이가 제한되어 있다는 것입니다.

LLM 컴파일러는 16k 토큰의 컨텍스트 창을 지원하지만 프로그램 코드는 이보다 훨씬 길 수 있습니다. 예를 들어, 표 10에 표시된 것처럼 플래그 튜닝 팁으로 형식을 지정한 경우 MiBench 번역 단위의 67%가 이 컨텍스트 창을 초과했습니다.

이 문제를 완화하기 위해 더 큰 번역 단위를 별도의 기능으로 분할합니다. 하지만 이로 인해 수행할 수 있는 최적화 범위가 제한되고 여전히 분할 번역 단위의 18%가 모델에 비해 너무 큽니다. 입력으로 받아들여집니다. 연구자들은 점점 더 많은 상황 창을 사용하고 있지만 제한된 상황 창은 LLM에서 여전히 일반적인 문제로 남아 있습니다.

두 번째 제한 사항이자 모든 LLM에 공통적으로 나타나는 문제는 모델 출력의 정확성입니다. LLM 컴파일러 사용자는 컴파일러별 평가 벤치마크를 사용하여 모델을 평가하는 것이 좋습니다. 컴파일러에는 버그가 없기 때문에 제안된 컴파일러 최적화는 엄격하게 테스트되어야 합니다. 모델이 어셈블리 코드로 디컴파일되면 라운드트립, 수동 검사 또는 단위 테스트를 통해 정확성을 확인해야 합니다. 일부 응용 프로그램의 경우 LLM 생성을 정규식으로 제한하거나 정확성을 보장하기 위해 자동 유효성 검사와 결합할 수 있습니다.

^{참조 링크:}

^{https://x.com/AIatMeta/status/1806361623831171318}^{https://ai.meta.com / 연구/출판/메타 -대형 언어 모델-컴파일러-기초-모델-컴파일러-최적화/?utm_source=twitter&utm_medium=organic_social&utm_content=link&utm_campaign=fair}

위 내용은 개발자들은 신이 납니다! Meta의 최신 LLM 컴파일러 릴리스는 77%의 자동 튜닝 효율성을 달성했습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!