ChipNeMo: 칩 설계를 위한 도메인 적응 LLM: LLM 애플리케이션

링크 표

• 초록 및 소개
• 데이터세트
• ChipNemo 도메인 적응 방법
• LLM 지원서
• 평가
• 논의
• 관련 작품
• 결론
• 감사의 말, 기여 및 참고자료
• 부록

IV. LLM 지원서

우리는 디자인 팀 내에서 잠재적인 LLM 애플리케이션에 대한 설문조사를 실시하고 이를 코드 생성, 질문 및 답변, 분석 및 보고 , 분류의 4가지 버킷으로 분류했습니다. 코드 생성은 LLM 생성 설계 코드, 테스트벤치, 어설션, 내부 도구 스크립트 등을 의미합니다. Q & A는 LLM이 디자인, 도구, 인프라 등에 대한 질문에 답변하는 것을 말합니다. 분석 및 보고는 LLM이 데이터를 분석하고 보고서를 제공하는 것을 의미합니다. 분류는 로그 및 보고서가 제공되는 설계 또는 도구 문제를 디버깅하는 데 도움이 되는 LLM을 나타냅니다. 우리는 추가 연구를 위해 남겨둔 분류 범주를 제외하고 이 작업에서 연구하기 위해 각 범주에서 하나의 주요 응용 프로그램을 선택했습니다. 각 응용 프로그램의 동기와 기술적 세부 사항은 다음과 같습니다.

A. 엔지니어링 보조 챗봇

이 애플리케이션은 설계 엔지니어가 아키텍처, 설계, 검증 및 구축 질문에 대한 답변을 제공하여 다른 사람의 생산성에 영향을 주지 않고 전반적인 생산성을 크게 향상시킬 수 있도록 돕는 것을 목표로 합니다. 설계 엔지니어는 브레인스토밍, 하드웨어 설계, 코드 작성을 즐기지만 부족한 설계 지식에 대한 답변을 기다리는 데 시간이 많이 소요되는 것으로 나타났습니다. 엔지니어가 잘못된 가정을 기반으로 코드를 작성하거나 익숙하지 않은 코드를 디버깅하는 것을 방지함으로써 설계 생산성도 향상될 수 있습니다. 내부 연구에 따르면 일반적인 칩 설계자 시간의 최대 60%가 설계 사양, 테스트벤치 구성, 아키텍처 정의, 도구 또는 인프라를 포함한 다양한 주제에 걸쳐 디버그 또는 체크리스트 관련 작업에 소요되는 것으로 나타났습니다. 다국적 기업에서는 이러한 문제에 대한 전문가가 전 세계에 분산되어 있는 경우가 많기 때문에 즉각적인 도움을 받기가 항상 편리한 것은 아닙니다. 따라서 내부 설계 문서, 코드, 설계에 관한 기록 데이터, 이메일, 기업 인스턴트 커뮤니케이션 등 기술 커뮤니케이션에서 추출된 지식을 기반으로 하는 엔지니어링 보조 챗봇은 설계 생산성을 크게 향상시키는 데 도움이 될 수 있습니다. 우리는 섹션 III-D에서 언급한 도메인 적응 RAG 방법을 사용하여 이 애플리케이션을 구현했습니다.

B. EDA 스크립트 생성

산업용 칩 설계 흐름의 또 다른 일반적인 작업은 다음과 같은 다양한 작업을 수행하기 위해 EDA 스크립트를 작성하는 것입니다.

디자인 구현, 성찰 및 변형으로. 이러한 스크립트는 도구별 스크립트 라이브러리와 사용자 정의 내부 스크립트 라이브러리를 모두 활용하는 경우가 많습니다. 이러한 라이브러리를 배우고, 도구 문서를 탐색하고, 이러한 스크립트를 작성 및 디버깅하는 데 상당한 엔지니어링 시간이 소요될 수 있습니다.

LLM은 광범위한 작업에서 소규모 코드 생성에 능숙한 것으로 입증되었으므로[32] 이러한 모델을 사용자 정의하여 이 도메인 특정 작업에서 엔지니어 생산성을 가속화하는 것이 자연스럽게 적합합니다. 이 작업에서 우리는 자연어 작업 설명에서 두 가지 유형의 스크립트를 생성하는 데 중점을 둡니다. 첫 번째는 설계 편집 및 분석을 위한 내부 Python 라이브러리인 Tool1을 활용하는 스크립트입니다. 두 번째는 선도적인 산업용 정적 타이밍 분석 도구인 Tool2에서 제공하는 명령 인터페이스를 사용하는 Tcl 스크립트입니다.

이 작업을 위한 도메인별 미세 조정 데이터세트를 구축하기 위해 두 도구 모두에 대한 생산 스크립트를 설계 전문가로부터 수집했습니다. 우리는 DAPT 모델이 코드에 대한 합리적인 인라인 주석을 생성할 수 있음을 관찰했습니다. 이를 통해 우리는 이러한 모델을 사용하여 추가 인라인 주석을 생성함으로써 수집된 스크립트의 품질을 향상시킬 수 있었습니다. 인간 전문가는 나중에 이러한 의견을 확인하고 수정하고 관련 프롬프트를 만들었습니다. 이러한 프롬프트와 코드 쌍은 섹션 III-C에 설명된 형식으로 DSFT에 사용되는 데이터를 구성합니다.

가장 의미 있는 방식으로 피드백을 제공하고 수집하기 위해 엔지니어가 동일한 인터페이스를 통해 모델을 쿼리하고 생성된 코드를 실행할 수 있는 그림 4에 표시된 흐름을 구축하는 데 상당한 노력을 기울였습니다. 이를 통해 우리는 생성된 코드의 정확성을 확신할 수 있을 뿐만 아니라 엔지니어가 작동하는 스크립트를 얻기 위해 얼마나 많은 수정이 필요한지 확인할 수 있어 정확한 피드백을 제공할 수 있습니다. 도구 서버에 대한 대화형 연결을 설정하여 Tool1 및 Tool2 통합을 지원합니다.

또한 다양한 모델을 비교하고 사용자 피드백에서 귀중한 통찰력을 얻을 수 있는 사용자 피드백 양식을 제공합니다. 이 귀중한 정보는 모델을 더욱 개선하는 데 도움이 될 수 있습니다.

C. 버그 요약 및 분석

생산 흐름의 여러 단계에서 다양한 기능과 버그의 보고, 분류, 디버그 및 해결을 추적하는 것은 시간이 많이 걸리는 프로세스입니다. 엔지니어링 관리자는 프로젝트 상태를 이해하고 실행 속도를 높이기 위해 내부 문제 추적 데이터베이스를 검토하는 데 많은 시간을 소비합니다. 따라서 모든 지원 정보를 살펴보고 기술 및 관리 데이터를 신속하게 요약하고 다음 단계를 제안할 수 있는 도구는 팀 생산성을 높일 것입니다. 우리는 LLM을 사용하여 세 가지 다른 결과를 생성하는 데 중점을 둡니다. 하나는 기술적 세부 사항에 초점을 맞추고, 하나는 관리 세부 사항에 초점을 맞추고 다른 하나는 작업 할당을 권장합니다.

이러한 작업을 연구하기 위해 NVIDIA의 내부 버그 데이터베이스인 NVBugs를 사용했습니다. 이 데이터베이스는 버그 보고, 추적, 해결은 물론 회사 전체의 일반 작업 및 기능 추적에도 사용됩니다. DAPT 데이터 세트에 많은 양의 버그 데이터가 포함되어 있으므로 ChipNeMo 모델이 이 작업을 잘 수행할 것으로 기대합니다. 또한 이 작업을 위해 버그 요약 및 작업 할당 작업의 예가 포함된 도메인별 SFT 데이터세트를 구축했습니다.

버그 설명에는 긴 댓글 기록과 함께 로그 파일이나 코드 덤프의 큰 조각이 포함되는 경우가 많습니다. 이러한 경우 버그 텍스트가 LLM 컨텍스트 창에 비해 너무 큽니다. 이 문제를 해결하기 위해 우리는 두 가지 솔루션을 구현했습니다. 먼저, 모델이 전체 문자열을 처리할 필요 없이 버그의 여러 위치에서 발생하는 경로를 연결할 수 있도록 긴 경로 이름을 찾아 더 짧은 별칭으로 바꿨습니다. 둘째, 요약 작업을 모델이 여러 요약 및 버그 데이터 청크에 걸쳐 데이터를 축적하는 작업을 수행하는 증분 작업으로 분할했습니다. 우리는 버그가 먼저 컨텍스트 창에 맞는 덩어리로 분리되는 계층적 접근 방식을 사용합니다. 그런 다음 해당 청크가 요약되고 요약이 누적된 다음 청크로 분리됩니다. 이 프로세스는 전체 요약 세트가 단일 컨텍스트 창에 들어가고 단일 요약이 생성될 때까지 반복됩니다. 요약에 사용되는 LLM과 별개로 이와 동일한 접근 방식을 사용합니다.