ChipNeMo: LLMs adaptados ao domínio para design de chips: Apêndice

Tabela de Links

• Resumo e introdução
• Conjunto de dados
• Métodos de adaptação de domínio ChipNemo
• Aplicações LLM
• Avaliações
• Discussão
• Trabalhos relacionados
• Conclusões
• Agradecimentos, Contribuições e Referências
• Apêndice

APÊNDICE

A. Processo de coleta de dados

A coleção foi implementada com um conjunto de scripts shell e Python, projetados para identificar dados e documentação de projeto relevantes, convertê-los em texto simples, se aplicável, filtrá-los usando métricas básicas de qualidade, calcular uma soma de verificação para desduplicação precisa de arquivos e compactá-los para armazenamento. O fluxo de coleta não usou scripts de coleta e raspagem específicos do LLM prontos para uso, pois nosso objetivo era minimizar os requisitos de espaço por meio da coleta de dados in-situ de fontes de dados internas (sistemas de arquivos em rede e aplicativos da Web internos). Para a coleta baseada em sistema de arquivos, os dados foram mantidos no local enquanto eram filtrados quanto à qualidade, em vez de armazenar conjuntos adicionais de dados brutos localmente.

A coleta de dados de design e verificação abrangeu uma variedade de arquivos de origem, incluindo Verilog e VHDL (RTL e netlists), C++, Spice, Tcl, várias linguagens de script e arquivos de configuração relacionados à construção. Os dados de serviços web internos foram coletados por meio de chamadas de API REST e rastreamento convencional, com a formatação HTML sendo removida usando a biblioteca de código aberto BeautifulSoup [52] Python em ambos os casos para minimizar a remoção inadvertida de exemplos de codificação, ao custo da introdução de mais caldeiras. barras de navegação de placas e outros elementos da página HTML. Nosso fluxo de coleta de dados suportava formatos de documentação convencionais, incluindo .docx, .pptx e .pdf, usando bibliotecas de conversão Python prontamente disponíveis e ferramentas de código aberto.

Como se acredita que a maioria dos dados internos são de alta qualidade, foi aplicada uma filtragem mínima: a filtragem de contagem de linhas foi usada para garantir que arquivos excessivamente grandes ou pequenos fossem excluídos, e os arquivos foram classificados em amplas categorias de escritos manualmente versus gerados por ferramentas.

B. Pré-treinamento adaptativo de domínio (DAPT)

Nesta seção apresentamos resultados detalhados em nossos modelos pré-treinados adaptativos de domínio. Também detalhamos nossos experimentos de ablação no pré-treinamento adaptativo de domínio.

Hiperparâmetros DAPT: Detalhes apresentados na Tabela VI.

Resultados da avaliação automática: apresentamos resultados detalhados sobre benchmarks de avaliação automática na Tabela VII e na Tabela VIII. Para simplificar, no restante da seção apresentamos resultados de referência agregados para estudos de ablação:

• Chip : Relatamos resultados médios em benchmarks de Design, Scripting, Bugs e Circuitos no domínio da Tabela III (5 tentativas).

• MMLU: Relatamos os resultados gerais do MMLU (5-shot) [22], um benchmark agregado popular em uma ampla variedade de assuntos.

• Raciocínio : Relatamos resultados médios em benchmarks públicos populares sobre raciocínio de bom senso (0-shot), incluindo Winogrande [53], hellaswag [54], ARC-easy [55] e RACE-High [56].

• Código : relatamos a taxa média de aprovação de benchmarks de codificação com decodificação gananciosa, incluindo HumanEval [23], VerilogEval-Machine [12] e VerilogEval-Human [12].

Aumento do tokenizador: Experimentamos o DAPT usando o tokenizer LLaMA2 original e o tokenizer aumentado conforme descrito na Seção III-A. A Figura 11 mostra a perda de treinamento suavizada para ChipNeMo com o tokenizer original não modificado. Quando comparado com a Figura 2, observamos que um tokenizer aumentado tem maior perda de treinamento na inicialização, devido ao fato de tokens adicionados nunca serem observados durante o pré-treinamento do modelo básico. Perda de treinamento semelhante é alcançada para DAPT com 1 época.

A Tabela IX apresenta resultados agregados de benchmark de avaliação automática. Observamos que o aumento cuidadoso do tokenizer e a inicialização do peso impactam apenas ligeiramente o desempenho do modelo em benchmarks acadêmicos gerais. O DAPT melhorou significativamente os benchmarks de domínio com qualquer tokenizador, incluindo codificação Verilog (sem grande diferença no HumanEval). Concluímos que aumentar o tokenizer traz o benefício de um tokenizer aprimorado e da eficiência do treinamento, sem degradação da linguagem geral dos modelos e dos recursos de domínio.

Combinação de conjuntos de dados públicos: conforme apresentado na Seção II-A, incluímos dados públicos no DAPT, amostrados de conjuntos de dados públicos comumente usados para pré-treinamento do modelo básico. Esperávamos principalmente que a mistura de dados públicos, como a Wikipedia no DAPT, pudesse ajudar a “corrigir” os distúrbios causados pelo aumento do tokenizador e melhorar as capacidades gerais de linguagem natural

de modelos. Conduzimos outra rodada de DAPT com aumento de tokenizador usando apenas os dados do domínio, treinando para o mesmo número de etapas, o que equivale a aproximadamente 1,1 época dos dados. Descobrimos que a combinação de dados públicos melhora ligeiramente os resultados. Apresentamos resultados detalhados na Tabela X.

A Figura 12 mostra a perda de treinamento para ChipNeMo-7B com tokenizadores aumentados, incluindo combinação de conjunto de dados público. Observamos grandes picos na perda de treinamento nas etapas iniciais de treinamento, com a perda final de treinamento para os modelos 7B sendo ainda melhores do que os hiperparâmetros DAPT originais de 13B. No entanto, notamos uma degradação substancial nos benchmarks de linguagem natural, conforme mostrado na Tabela XII, incluindo o design de chips no domínio. As capacidades de codificação melhoraram de acordo com as descobertas de [32].

Destacamos que nosso caso difere daquele em [32]. Embora também conduzamos a inicialização de “pré-treinamento contínuo” a partir de pontos de verificação pré-treinados, queremos preferencialmente que o modelo mantenha altos graus de desempenho nas capacidades gerais, enquanto

destilar informações e conhecimento do conjunto de dados de domínio (não vistos no pré-treinamento do modelo) em pesos de modelo. Em contraste, [32] utilizam dados de código disponíveis publicamente que predominantemente carecem de elementos de linguagem natural, enfatizando seu foco principal em tarefas relacionadas à codificação. Nossa hipótese é que uma taxa de aprendizagem menor desempenhou um papel duplo para a adaptação do domínio, facilitando a destilação do conhecimento do domínio através do DAPT, mantendo um equilíbrio que não se desviou muito do modelo básico, preservando assim as capacidades gerais da linguagem natural e melhorando significativamente o desempenho em -tarefas de domínio

Ajuste fino com eficiência de parâmetros (PEFT): O ajuste fino com eficiência de parâmetros congela os pesos do modelo pré-treinado e injeta parâmetros treináveis em modelos de adaptadores menores para um ajuste fino eficiente de tarefas posteriores. Exploramos o uso de PEFT em DAPT usando Low-Rank Adaptation (LoRA) [16]. Como nossa implementação de camada transformadora funde KQV em uma única projeção, adicionamos adaptadores LoRA para uma única projeção de baixo nível para cada camada de autoatenção de forma combinada. Experimentamos modelos LLaMA2-13B com o tokenizer LLaMA2 original, usando as mesmas configurações de treinamento DAPT na Tabela VI. Realizamos dois experimentos, introduzindo parâmetros treináveis adicionais de 26,4 milhões (pequeno) e 211,2 milhões (grande), respectivamente.

A Figura 13 mostra as curvas de perda de treinamento dos modelos LoRA e compara com o treinamento de parâmetros completos. Para ambos os modelos LoRA, a perda converge rapidamente e para de diminuir além de um certo ponto. A Tabela XIII relata os resultados da avaliação nos modelos LoRA. Ambos os modelos LoRA apresentam desempenho significativamente inferior ao treinamento completo de parâmetros em tarefas de design de chips no domínio. Os modelos LoRA melhoram nas tarefas de design de chips em comparação com seus equivalentes não-DAPT, com o modelo maior exibindo resultados ligeiramente melhores (mas não significativos).

C. Treinamento do modelo de recuperação

A geração manual de amostras de treinamento exige muito esforço, por isso optamos por implementar um processo para gerá-las automaticamente. Como estamos usando o aprendizado contrastivo para ajustar nosso modelo, cada amostra requer um conjunto de passagens positivas e negativas, particularmente negativas duras para maximizar a precisão.

1) Procedimento de amostragem do conjunto de dados: A Figura 14 descreve as etapas executadas para gerar uma amostra:

• Etapa 1: selecione aleatoriamente uma passagem do corpus do documento

• Etapa 2: Use um modelo de linguagem (Vicuna) para gerar uma consulta válida a partir da passagem

• Etapa 3: use um modelo de recuperação pré-existente (transformador de frase) para buscar as N passagens principais do corpus do documento para a consulta, onde cada passagem é um potencial negativo forte

• Etapa 4: é possível que algumas das passagens buscadas sejam realmente positivas, então use o mesmo modelo de linguagem para filtrar as passagens positivas

• Etapa 5: Se não houver passagens negativas suficientes após esse processo de filtragem, complemente com passagens aleatórias do corpus

Para nossa pesquisa inicial utilizamos Vicuna [4] e Sentence Transformer [33]; no entanto, eles podem ser facilmente substituídos por LLaMA2 [5] e BM25 [42], respectivamente, para produzir um modelo de recuperação que seja comercialmente viável.

2) Comparação da qualidade dos acertos: Nem todos os acertos são criados iguais. A passagem no exemplo de especificação abaixo responde de forma clara e completa à sua consulta. A passagem no exemplo Build contém a resposta; no entanto, é necessário mais contexto para responder à consulta.

Exemplo de especificação: a passagem de sucesso responde claramente à consulta.

Exemplo de construção: informações adicionais são necessárias para responder totalmente à consulta. Tais como: O que é um DL? Como sabemos que Arch-Build-Hotseat-XXX é um DL?

D. Dados Adicionais de Avaliação

A Tabela XIV mostra os dados de avaliação de todos os modelos da aplicação chatbot do assistente de engenharia.

A Tabela XV mostra nossos resultados de avaliação para todos os modelos na tarefa de geração de script EDA.

A Tabela XVI mostra nossos resultados de avaliação para todos os modelos na tarefa de resumo e análise de bugs.

E. Exemplos

1) Chatbot Assistente de Engenharia:

2) Geração de script EDA: alguns nomes de funções e comandos são ofuscados.

3) Resumo e análise de bugs: Nomes de usuários, nomes de chips e caminhos são ofuscados.