Benchmark on IBM UFCG

Inferência de LLMs com Ollama na IBM Power9 Utilizando CPU

Wed, 01 Apr 2026 00:00:00 +0000

Contexto

Este post apresenta um guia prático para realizar inferência de grandes Modelos de Linguagem (LLMs) utilizando o Ollama, em um ambiente IBM POWER9. O Ollama é um framework baseado no llama.cpp, projetado para simplificar a implementação e execução de tais modelos, oferecendo uma interface amigável e suporte para diversas tarefas.

Fluxo de uma requisição

Apesar do crescimento no uso de LLMs, a disponibilidade de materiais voltados para a arquitetura ppc64le (IBM POWER9) ainda é bastante limitada. Em geral, os tutoriais disponíveis são antigos, pouco detalhados ou focados em arquiteturas mais comuns, como x86_64, o que dificulta a reprodução do ambiente no contexto apresentado. Este é o primeiro de dois posts dessa série, que tem como objetivo realizar a inferência inteiramente via CPU, explorando a arquitetura ppc64le, de maneira atualizada, prática e reproduzível. No próximo post, abordaremos a utilização de GPU para acelerar o processo.

TL;DR

Este post apresenta detalhes sobre como configurar o ambiente para realizar inferências com a infraestrutura da IBM POWER9.
A execução é realizada via CPU utilizando o Ollama;
O principal desafio envolve a configuração correta do ambiente, especialmente dependências como Go, GCC e CMake, além da compatibilidade com RHEL

Ambiente utilizado

Hardware:

Arquitetura ppc64le;
RAM: ~64GB;
Execução: Máquina Virtual (VM);

Sistema Operacional: Alma Linux 8.10 (ppc64le), binário compatível com Red Hat Enterprise Linux (RHEL) 8.9/8.10.

Setup inicial

Para executar o Ollama na arquitetura POWER9, é necessário preparar o ambiente com as dependências adequadas.O primeiro passo é atualizar o sistema e instalar os utilitários básicos:

sudo dnf update -ysudo dnf install -y wget git tar make gcc gcc-c++ cmake gcc-toolset-11

Embora esse comando instale parte das dependências, é necessário garantir que as versões corretas estejam sendo utilizadas.

Configuração do Go

O Ollama é desenvolvido em Go, portanto é necessário garantir a versão adequada.

Versão esperada: 1.25.7 linux/ppc64le

Caso não esteja instalado:

wget https://go.dev/dl/go1.25.7.linux-ppc64le.tar.gzsudo tar -C /usr/local -xzf go1.25.7.linux-ppc64le.tar.gzexport PATH=/usr/local/go/bin:$PATH

Para adicionar ao PATH permanentemente:

echo 'export PATH=/usr/local/go/bin:$PATH' >> ~/.bashrcsource ~/.bashrc

Verifique se a versão está correta: go version

Configuração do Cmake

Verifique se a versão está correta: cmake --version

Versão esperada: cmake 3.26.5

Caso não esteja instalado:

wget https://github.com/Kitware/CMake/releases/download/v3.26.5/cmake-3.26.5.tar.gztar -xzf cmake-3.26.5.tar.gzcd cmake-3.26.5./bootstrapmake -j$(nproc)sudo make install

Configuração do GCC

Versão esperada: gcc 11.2.1

Importante: No AlmaLinux 8, o gcc-toolset não é ativado automaticamente. É necessário habilitar a sessão manualmente:

scl enable gcc-toolset-11 bash

Esse comando ativa o GCC apenas na sessão atual. Se abrir outro terminal, será necessário executar o comando novamente.

Verifique a versão: gcc --version

Caso não esteja instalado:

sudo dnf install -y gcc-toolset-11scl enable gcc-toolset-11 bash

Clonando o Ollama

Com o ambiente configurado, podemos realizar o build do Ollama. Aqui vamos clonar o repositório oficial do ollama e mudar a versão utilizada (importante para a compatibilidade com a POWER e para obter uma versão estável).

cd /rootgit clone https://github.com/ollama/ollama.gitcd ollama#Alterar a versão: git checkout v0.9.4

Para verificar, use: git status

Build do Ollama

Após ativar GCC na versão certa:

export CGO_ENABLED=1go clean -cache -modcache -i -rgo build -o ollama .

O CGO precisa estar habilitado porque o Ollama depende do llama.cpp, que utiliza código em C/C++ para otimizações de performance. Sem isso, o build falha ou perde compatibilidade com a arquitetura.

Isso deve ocorrer sem nenhum erro e gerar o binário ollama criado no diretório atual.

Para verificar: ./ollama --version

Realizando a Inferência

Com o Ollama compilado, podemos iniciar o servidor:

./ollama serve

Uma observação importante é que, como o ambiente está sendo executado em uma máquina virtual, não é possível manter o comando em execução no terminal principal e, simultaneamente, utilizar outro terminal na mesma sessão para realizar a inferência, sem alguma ferramenta auxiliar para gerenciar múltiplos terminais.O que faremos então é executar o servidor em segundo plano (background), mas você pode optar por usar Tmux ou Screen, permitindo que o mesmo terminal continue disponível para a execução dos demais comandos (que veremos a seguir). Para isso, você pode rodar:

./ollama serve &

Para verificar se deu certo: ps aux | grep ollama. Vai aparecer algo assim:

Ollama executando

Baixar o modelo de teste e executar a inferência

Para validação, utilizamos o modelo TinyLlama, por ser leve e adequado para execução em CPU. Para isso, em outro terminal, rode:

./ollama pull tinyllama

Para executar a inferência:

./ollama run tinyllama "O céu é azul?"

Se tudo tiver sido feito de maneira correta, você terá algo como:

Inferencia sendo executada

É importante destacar que o Ollama trabalha, por padrão, com modelos disponibilizados em seu próprio repositório, que já estão convertidos e otimizados para execução, geralmente no formato compatível com o llama.cpp. Esses modelos podem ser facilmente utilizados por meio do comando ollama pull, como no caso do TinyLlama utilizado neste exemplo. Embora seja possível utilizar modelos externos, isso exige etapas adicionais, como a conversão para formatos compatíveis (por exemplo, GGUF) e a criação de um Modelfile.

Considerações Finais

Com os passos apresentados, foi possível configurar o ambiente para executar inferências de LLMs em uma máquina IBM POWER9 utilizando a CPU. Apesar de ser funcional, essa abordagem apresenta limitações no desempenho, especialmente para modelos maiores, devido a ausência de aceleração via GPU. Como próximo passo, pretendemos explorar a execução utilizando GPU, avaliando ganhos de desempenho e escalabilidade.

Próximos Passos

Testar versões mais recentes e a compatibilidade entre elas;
Realizar uma experimentação de benchmarks para comparar o desempenho da Inferência em CPU em relação a inferência em GPU;
Segundo post dessa série, realizando inferência em GPU.

Virtualização em Power9: como estruturamos um ambiente isolado com KVM e Libvirt

Fri, 27 Mar 2026 00:00:00 +0000

Contexto

Diante da necessidade de estabelecer ambientes isolados e seguros para a instalação de bibliotecas, frameworks e ferramentas de uso geral, o encapsulamento de um ambiente surgiu como alternativa para resolução desse problema, fazendo-se presente através do KVM gerenciado por meio do virt-manager e do virsh.

A virtualização é amplamente utilizada em ambientes x86, com ferramentas e fluxos bem consolidados. No entanto, quando migramos para arquiteturas como o IBM Power9 (ppc64le), muitos desses processos deixam de ser diretos e exigem adaptações específicas. Abaixo, temos um diagrama que demonstra essa comunicação dividida em 4 camadas.

Fluxo de comunicação entre Hardware (Power9) e Máquinas Virtuais

O fluxo é organizado nas seguintes camadas:

Figura 1: Diagrama que representa a arquitetura de virtualização em 4 camadas.

Neste trabalho, exploramos a construção de um ambiente virtualizado utilizando KVM e Libvirt em um servidor Power9, com foco em isolamento, reprodutibilidade e uso compartilhado entre membros de uma equipe.

TL;DR

Implementamos um ambiente virtualizado no Power9 usando KVM + Libvirt.
Adaptamos fluxos comuns de virtualização para arquitetura ppc64le, resolvendo problemas de permissão, lock de escrita e provisionamento.
O ambiente permite isolamento seguro entre usuários e fácil gerenciamento de VMs.
Disponibilizamos imagens prontas com drivers NVIDIA/CUDA para uso imediato.

Ambiente utilizado

Arquitetura: Servidor IBM Power9 (Arquitetura ppc64le).
Sistema Operacional (SO): AlmaLinux 8.10 binário compatível com Red Hat Enterprise Linux (RHEL) 8.9/8.10.
RAM: 512GB.
Execução: Virtual Manager para gerenciamento de Máquinas Virtuais (VMs).
Hypervisor: KVM (Kernel-based Virtual Machine) / QEMU.
Gerenciamento: Libvirt (virsh, virt-install, virt-customize).
Armazenamento: Discos virtuais no formato .qcow2.
GPUs: 4x NVIDIA Tesla V100 SXM2 16GB (NVLink2).

Instalando o ambiente de virtualização (KVM + Libvirt)

Antes de criar qualquer VM, é necessário instalar e configurar o KVM e o Libvirt no servidor Power9.

Instalação dos pacotes:

sudo dnf install -y qemu-kvm libvirt libvirt-client libvirt-daemon libvirt-daemon-kvm virt-install virt-viewer guestfs-tools \libguestfs-tools python3-libvirt

Iniciando serviço:

sudo systemctl enable --now libvirtdsudo systemctl status libvirtd

Adicionando o usuário ao grupo libvirt:Para que usuários não-root possam gerenciar VMs sem precisar de sudo em todo comando:

Execute o comando abaixo:

sudo usermod -aG libvirt $(whoami)

Faça logout e login novamente para aplicar a mudança.

Verificando instalação:

Verifique a versão do virsh:

sudo virsh version

Valide o suporte à virtualização no processador:

sudo virt-host-validate

Setup

Preparação de ambiente:No KVM, a forma mais rápida de provisionar VMs é clonar uma imagem “semente” (.qcow2) e expandi-la, em vez de fazer uma instalação limpa via ISO. Portanto, para manter a organização, todos os discos virtuais ficarão em um diretório separado:

Baixe a imagem base do Alma Linux 8:

cd /home/user/wget https://repo.almalinux.org/almalinux/8/cloud/ppc64le/images/AlmaLinux-8-GenericCloud-latest.ppc64le.qcow2 -O alma8_base.qcow2

Gerenciamento do Hipervisor:A administração do hipervisor e das instâncias segue protocolos específicos para garantir a estabilidade do sistema. Comandos para o Administrador controlar o serviço no Power9:

Desative o sistema KVM:

sudo systemctl stop libvirtd

Reative o sistema KVM:

sudo systemctl start libvirtd

Habilite no boot:

sudo systemctl enable libvirtd

Resolução de permissões:O usuário do sistema que executa o KVM (chamado qemu) precisa ter permissão para acessar os discos da VM. Se o diretório estiver dentro de uma home pessoal, o Linux bloqueará o acesso por padrão. Para permitir que o hipervisor acesse a pasta de discos sem expor seus arquivos pessoais, conceda permissão de execução (o+x) nos diretórios:

Permita que o qemu “atravesse” a home (apenas travessia, não leitura):

chmod o+x /home/user

Permita que o qemu acesse a pasta de discos:

chmod o+x /home/user/discos

Configuração de rede virtual (Libvirt):O Libvirt cria uma rede NAT padrão (default) que coloca as VMs na faixa 192.168.122.0/24. As VMs têm acesso à internet via NAT, mas não são acessíveis diretamente da rede externa sem configuração adicional.

Verifique o status da rede:

sudo virsh net-list --all

Se estiver inativa, inicie e habilite no boot:

sudo virsh net-start defaultsudo virsh net-autostart default

Se a rede não existir, defina e inicialize:

sudo virsh net-define /usr/share/libvirt/networks/default.xmlsudo virsh net-start defaultsudo virsh net-autostart default

Se o XML não for encontrado, instale o pacote de configuração de rede:

sudo dnf install -y libvirt-daemon-config-network

Criando novas VMs:

Clone a imagem base:

cp /home/user/alma8_base.qcow2 /home/user/discos/nome_vm.qcow2

Expanda o disco (a expansão deve ser feita ANTES de criar a VM):

qemu-img resize /home/user/discos/nome_vm.qcow2 +100G

Crie a VM:

sudo virt-install \ --connect qemu:///system \ --name vm_nome \ --memory 131072 \ --vcpus 16 \ --cpu host \ --disk path=/home/user/discos/nome_vm.qcow2,format=qcow2 \ --import \ --os-variant almalinux8 \ --network network=default \ --graphics none \ --noautoconsole

Customização após criar as VMs:Após criar a VM, é necessário definir a senha root, pois a imagem cloud vem sem senha por padrão. Utilizamos o virt-customize para isso. Importante: A VM deve estar desligada para que o disco possa ser editado em segurança.

Desligue a VM:

sudo virsh shutdown vm_nome

Aguarde o desligamento completo:

sudo virsh list --all

Injete a senha no disco:

sudo virt-customize -a /home/user/discos/nome_vm.qcow2 \ --root-password password:senha_desejada

Ligue a VM novamente:

sudo virsh start vm_nome

Acessando VMs:

Via console serial

Conecte ao console da VM:

sudo virsh console vm_nome

Para sair do console, use Ctrl + ].

Via SSH

Descubra o IP da VM:

sudo virsh domifaddr vm_nome

Acesse via SSH:

ssh root@<ip_da_vm>

Gerenciar e apagar VMs:Se você precisar destruir um ambiente para recriá-lo do zero, siga os 3 passos obrigatórios para limpar tudo:

Force o desligamento da VM:

sudo virsh destroy nome_da_vm

Remova a definição da VM do Libvirt:

sudo virsh undefine nome_da_vm

Apague o disco virtual para liberar espaço no Power9:

rm -f /home/user/discos/nome_da_vm.qcow2

Criar VM a partir de imagem existente (clonagem):Para criar uma nova VM a partir de uma imagem já configurada, como as imagens prontas com drivers NVIDIA:

Opção A: clonar via qemu-img (mantém a imagem original intacta):

qemu-img create -f qcow2 -b imagem-base.qcow2 -F qcow2 nova-vm.qcow2

Opção B: clonar via virt-clone:

virt-clone \ --original vm-base \ --name vm-nova \ --file /home/user/discos/nova-vm.qcow2

Caso seja necessário, pode-se executar o passo de excluir a VM e recriá-la conforme a etapa 5.

Imagens prontas com drivers NVIDIA

Para facilitar o uso das GPUs Tesla V100 presentes no servidor, disponibilizamos imagens .qcow2 pré-configuradas com os drivers NVIDIA, CUDA e cuDNN instalados. Isso elimina a necessidade de configurar o ambiente base a cada novo uso.

Imagens disponíveis:
Imagem Conteúdo
AlmaLinux-8-Power9-NVIDIA-drivers.qcow2.xz AlmaLinux 8.10 + drivers NVIDIA 535 + CUDA 12.2 + cuDNN 9.0
Como usar imagens pré-configuradas:

Imagem	Conteúdo
AlmaLinux-8-Power9-NVIDIA-drivers.qcow2.xz	AlmaLinux 8.10 + drivers NVIDIA 535 + CUDA 12.2 + cuDNN 9.0

Baixe e descompacte a imagem:

pip install --user gdowngdown --folder "https://drive.google.com/file/d/1coGmFTwLWdUP6AlOfwd-_VmN0eoNwFOT/view?usp=drive_link"xz -d AlmaLinux-8-Power9-NVIDIA-drivers.qcow2.xz

Mova para o diretório de discos e crie a VM a partir dela:

cp AlmaLinux-8-Power9-NVIDIA-drivers.qcow2 /home/user/discos/minha-vm-gpu.qcow2

Crie a VM normalmente:

sudo virt-install \ --connect qemu:///system \ --name vm_gpu \ --memory 131072 \ --vcpus 16 \ --cpu host \ --disk path=/home/user/discos/minha-vm-gpu.qcow2,format=qcow2 \ --import \ --os-variant almalinux8 \ --network network=default \ --graphics none \ --noautoconsole

Para que a VM tenha acesso às GPUs físicas, é necessário configurar o passthrough PCIe conforme descrito no próximo post desta série.

Como gerar nova imagem a partir de VM configurada:Após instalar drivers ou qualquer software dentro de uma VM, você pode exportar o estado atual como nova imagem para reuso:

Desligue a VM:

sudo virsh shutdown vm_nome

Converta e compacte a imagem (remove espaço não utilizado):

qemu-img convert -O qcow2 -c \ /home/user/discos/vm_nome.qcow2 \ /home/user/discos/AlmaLinux-8-Power9-minha-imagem.qcow2

Comprima para distribuição:

xz -T0 -v /home/user/discos/AlmaLinux-8-Power9-minha-imagem.qcow2

Saída esperada: AlmaLinux-8-Power9-minha-imagem.qcow2.xz.

Verifique a integridade:

qemu-img check AlmaLinux-8-Power9-minha-imagem.qcow2qemu-img info AlmaLinux-8-Power9-minha-imagem.qcow2

Avaliação de Modelos IBM Granite para Tarefas de Geração de Código no HumanEvalX

Fri, 28 Nov 2025 00:00:00 +0000

Contexto

O uso de modelos de linguagem para geração e compreensão de código tem se tornado essencial em fluxos de desenvolvimento modernos.
Como parte do esforço conjunto entre o LSD/UFCG e a IBM Brasil, investigamos a performance da família IBM Granite 4 no benchmark HumanEvalX, que avalia capacidades de programação em cinco linguagens: Python, Java, Go, C++, e JavaScript.

O objetivo foi responder perguntas centrais da equipe:

Quão versáteis são os modelos Granite entre linguagens diferentes?
Modelos menores entregam performance útil?
Como os Granite se posicionam frente a modelos open-source como DeepSeek Coder e CodeLlama?

Metodologia / Processo

A avaliação foi conduzida utilizando o OpenCompass, um framework moderno e extensível para benchmarking de LLMs em escala. Ele permitiu executar todos os experimentos de forma padronizada, reprodutível e com protocolos consistentes de inferência.

Como o OpenCompass não possui suporte nativo aos modelos hospedados na IBM Cloud, foi necessário desenvolver um client personalizado para integrar o framework à IBM Cloud Inference API. Esse client permitiu que o processo de avaliação executasse requisições de forma transparente, tratasse autenticação, controlasse parâmetros de geração e retornasse as respostas no formato esperado pelo benchmark. Os experimentos também foram executados no Google Colab, que serviu como ambiente prático de prototipação e execução dos modelos.

Utilizamos o benchmark HumanEvalX, uma extensão do HumanEval tradicional, cobrindo cinco linguagens com métricas consistentes de avaliação como, por exemplo ,Pass@1.

Os modelos avaliados incluíram:

Granite 4.0 Micro (3B)
Granite 4.0 (1B)
Granite 4.0 h-tiny (7B)
Granite 4.0 h-small (30B) — via IBM Cloud
granite 4.0 (350M)
granite code instruct 8B — via IBM Cloud
DeepSeek Coder (6.7B)
CodeLlama (7B)

A métrica utilizada foi Pass@1, seguindo o protocolo do benchmark.

Resultados e Conclusões

Heatmap do desempenho dos modelos no HumanEvalX.

A avaliação revelou comportamentos importantes:

1. O granite-4.0-h-small se destacou pela versatilidade

Ele superou 60% de Pass@1 em Java, C++ e JavaScript, além de manter mais de 50% em Python e Go. Esse desempenho consistente entre linguagens sugere que o modelo tem boa capacidade de generalização, mostrando-se promissor em cenários que envolvem diferentes ecossistemas de programação, embora análises adicionais em outros benchmarks sejam importantes para uma conclusão mais ampla.

2. O Granite Micro (3B) apresentou performance acima do esperado

Apesar de ser um modelo pequeno, o Granite Micro (3B) surpreendeu ao alcançar 65.85% em JavaScript e 68.90% em Java, superando inclusive modelos maiores avaliados.Esse comportamento mostra que, mesmo com uma arquitetura compacta, ele consegue entregar resultados sólidos, tornando-se uma opção altamente eficiente para aplicações que exigem baixo custo computacional sem abrir mão de desempenho.

3. A progressão de tamanhos (350M → 1B → 3B → 7B → 30B) mostra evolução gradual e coerente

Os resultados mostram que, à medida que avançamos pelos diferentes tamanhos da linha Granite, há uma evolução coerente no desempenho. Os modelos menores entregam resultados estáveis dentro da sua categoria, enquanto os maiores ampliam progressivamente a capacidade de resolver tarefas mais complexas. Essa distribuição ajuda a entender melhor onde cada modelo se encaixa no espectro de uso.

4. A comparação entre provedores ajuda a contextualizar os resultados

Ao lado dos modelos da IBM, também avaliamos modelos de outros provedores, como DeepSeek e Meta. Em algumas linguagens, as diferenças foram pequenas, mas em todas elas houve ao menos um modelo da família Granite que alcançou a melhor pontuação. Os modelos Granite 4 Micro (3B) e Granite 4 h-small (30B) foram os destaques com resultados que ficaram próximos, e em alguns casos acima, de modelos reconhecidos por serem especialistas em código.

Próximos Passos

Executar os mesmos modelos da família Granite no LiveCodeBench, um benchmark mais amplo que vai além de code-generation, avaliando também code execution e test-output.
Realizar um fine-tuning de um modelo Granite 4.0 Micro (3B) utilizando o InstructLab e observar o impacto dessa adaptação no desempenho do modelo no HumanEvalX, comparando antes e depois do ajuste.

Contaminação por dados de Benchmark em LLMs: Fundamentos, Causas e Estratégias de Detecção

Mon, 21 Jul 2025 00:00:00 +0000

Contexto

Benchmarks são estruturas organizadas e padronizadas que podem ser utilizadas para avaliar o desempenho de grandes modelos de linguagem (LLMs). Compostos, em geral, por uma base de dados, um conjunto de tarefas e métricas de avaliação, esses recursos fornecem um ponto de referência comum para mensurar avanços, comparar arquiteturas e orientar decisões de desenvolvimento e implantação.

Apesar de seu uso recorrente, os resultados obtidos em benchmarks podem ser influenciados por diversos fatores. Um dos fatores ocorre quando, de alguma forma, os dados de teste são previamente expostos ao modelo durante seu treinamento. Esse cenário caracteriza o fenômeno conhecido como contaminação por dados de benchmark, que pode ocorrer de forma acidental ou deliberada. A presença desse tipo de contaminação tende a comprometer a avaliação, pois o modelo pode memorizar parcial ou integralmente os exemplos avaliados em uma determinada tarefa, distorcendo seu desempenho real.

Contaminação por dados de benchmark

Com o objetivo de introduzir e difundir esse tema, esta postagem apresenta os fundamentos conceituais da contaminação por dados de benchmark, suas causas recorrentes e as metodologias atualmente utilizadas para sua detecção.

TL;DR

Modelos são vulneráveis à contaminação quando os dados utilizados para testá-lo são previamente expostos durante o treinamento.
A contaminação pode ocorrer de forma acidental ou intencional e compromete a validade das avaliações.
Existem diferentes formas de contaminação, que variam pelo conteúdo exposto, momento da exposição e nível de abstração.
Métodos de detecção podem ser diretos (quando os dados de treinamento são acessíveis) ou indiretos (baseados em comportamento ou inferência).
Ferramentas como LLMSanitize, BenBench, ConStat e CDD-TED auxiliam na identificação sistemática de contaminações.

Impactos da contaminação

A contaminação por dados de benchmarks provoca distorções que afetam tanto o rigor científico das avaliações quanto a confiabilidade de aplicações baseadas em LLMs. Os principais impactos descritos abaixo, também são discutidos em estudos como [1] [5] [7].

Riscos da contaminação por dados de benchmark

Inflacionamento de métricas: A exposição prévia aos dados de avaliação pode elevar artificialmente o desempenho dos modelos, resultando em métricas superestimadas, como acurácia e calibragem. Isso dificulta a interpretação precisa de suas capacidades reais.
Avaliação comprometida: Quando um benchmark é aplicado a modelos que já tiveram acesso a seus dados, ele deixa de refletir a dificuldade real das tarefas, comprometendo sua função como instrumento de avaliação imparcial.
Redução da generalização: A contaminação favorece a memorização de exemplos específicos em vez da aprendizagem de padrões gerais, o que reduz a capacidade do modelo de lidar com dados não vistos, especialmente em casos de contaminação por rótulo ou semântica.
Riscos em aplicações sensíveis: Avaliações contaminadas podem levar à adoção de modelos em domínios críticos, como saúde, direito e finanças, com base em métricas distorcidas. Isso aumenta o risco de falhas operacionais e decisões inadequadas.
Comparações enviesadas e desperdício de recursos: A contaminação prejudica a equidade entre modelos, especialmente quando apenas alguns foram expostos previamente aos dados de benchmark. Isso compromete comparações, favorece modelos não auditáveis e pode levar à alocação ineficiente de recursos.
Comprometimento da integridade científica: Avaliações baseadas em benchmarks contaminados afetam a reprodutibilidade e podem resultar em conclusões inválidas, enfraquecendo a confiabilidade de estudos que utilizam esses resultados como base empírica.

Causas da contaminação por dados de benchmark

A contaminação por dados de benchmarks em LLMs pode ocorrer de forma acidental [1] [4] ou intencional [1] [3], com diferentes origens e consequências, dependendo principalmente da forma como os dados de treinamento são coletados, utilizados e reaproveitados nos ciclos de desenvolvimento dos modelos.

A contaminação acidental é a mais comum e ocorre, na maioria dos casos, devido ao uso de dados extraídos automaticamente da internet para pré-treinamento em larga escala [1] [4]. Esses corpora, por sua diversidade e volume, frequentemente incluem conteúdos associados a benchmarks, como exemplos idênticos, trechos brutos ou textos semanticamente relacionados. Isso se deve ao fato de benchmarks e dados de treinamento frequentemente compartilharem fontes públicas comuns, como Wikipedia, repositórios educacionais, artigos técnicos e redes sociais.

Exemplo de fluxo de contaminação não intencional

Embora mecanismos de filtragem possam ser implementados para evitar a inclusão de benchmarks conhecidos, essa estratégia apresenta limitações [4]. É difícil garantir a exclusão de todos os benchmarks existentes, especialmente os lançados recentemente ou ainda não amplamente documentados. Além disso, a identificação de sobreposição semântica é complexa, o que torna a detecção de vazamentos indiretos ainda mais desafiadora.

Outro vetor de contaminação acidental está relacionado à reutilização de interações com usuários para re-treinamento ou ajuste fino de modelos implantados em produção [7]. Sistemas comerciais podem reaproveitar entradas fornecidas por usuários durante testes, avaliações públicas ou uso real. Quando essas interações reproduzem exemplos derivados de benchmarks, há risco de contaminação retroativa, mesmo que não intencional, nos ciclos seguintes de treinamento.

Além disso, a contaminação pode se propagar por meio da geração de conteúdo por LLMs [1]. Modelos contaminados podem gerar textos que replicam padrões ou trechos presentes em benchmarks, mesmo que de forma parafraseada ou reestruturada. Esses textos, quando reutilizados em novos benchmarks ou conjuntos de treinamento, perpetuam e amplificam a contaminação original. Apesar de, nesses casos, os desenvolvedores poderem estar cientes da contaminação prévia, a natureza recursiva do processo faz com que a propagação ocorra de forma indireta e, muitas vezes, incontrolável. Por esse motivo, esse tipo de exposição também pode ser considerado um caso de contaminação acidental.

Por outro lado, a contaminação intencional ocorre quando dados de benchmark são deliberadamente incluídos no treinamento, com o objetivo de melhorar o desempenho do modelo em tarefas específicas [1] [3]. Essa prática pode ocorrer, por exemplo, ao incorporar conjuntos como MATH ou GSM8K com o propósito de otimizar a performance em raciocínio matemático [6]. Embora esse uso possa ser justificável como dado supervisionado, sua posterior reutilização como benchmark invalida a avaliação.

Exemplo de fluxo de contaminação intencional

É fundamental que, em casos como esse, haja transparência na documentação dos modelos. benchmarks utilizados como parte do treinamento não devem ser reaplicados como instrumentos de avaliação. Ainda assim, essa distinção nem sempre é respeitada, especialmente em modelos comerciais cuja documentação é limitada ou inexistente [5].

Categorias e níveis de contaminação

A contaminação por dados de benchmark pode assumir diferentes formas, variando conforme o tipo de conteúdo exposto, o grau de abstração da informação vazada e o estágio do treinamento em que a contaminação ocorre. Essas categorias não são mutuamente exclusivas e frequentemente se combinam, o que torna o fenômeno difícil de rastrear e mitigar.

Em muitos casos, a exposição ocorre devido a um vazamento de entrada, que é quando apenas as entradas dos benchmarks são expostas ao modelo [4], como perguntas, comandos ou prompts. No entanto, há situações em que tanto as entradas quanto os rótulos ou respostas anotadas estão presentes no treinamento, e essa situação é conhecida como vazamento de entrada-saída [4].

Outra forma comum de categorizar a contaminação é quando os modelos são expostos ao texto bruto utilizado na construção de benchmarks [5], como artigos da Wikipedia, decisões judiciais ou descrições técnicas. Complementarmente, há o caso que envolve a contaminação por diretrizes de anotação [5], quando o modelo acessa instruções empregadas no processo de rotulagem dos dados. Esse tipo de vazamento pode induzir comportamentos compatíveis com os critérios esperados pelo benchmark, mesmo sem exposição direta aos exemplos.

Além disso, a contaminação pode ocorrer em diferentes níveis de abstração. No nível semântico, o modelo é exposto a conteúdos conceitualmente semelhantes ou derivados dos benchmarks, como reformulações, tópicos correlatos ou textos provenientes da mesma fonte [1]. Essa forma de vazamento pode introduzir vieses temáticos e comprometer a capacidade de generalização do modelo, sendo difícil de detectar por não envolver cópia literal. No nível informacional, o vazamento ocorre por meio de estruturas secundárias associadas ao benchmark, como distribuições temporais, frequências de rótulos, metadados ou até análises externas sobre o conjunto de dados [1]. Essas informações, mesmo sem conter o conteúdo principal, podem influenciar sutilmente o comportamento do modelo. No nível de dados, ocorre a exposição literal de exemplos do conjunto de avaliação, mas sem os rótulos correspondentes, o que ainda assim permite que o modelo aprenda padrões específicos do benchmark [1]. Já no nível de rótulos, o caso mais crítico, tanto os exemplos quanto os rótulos estão presentes no treinamento, o que favorece memorização direta, reduz a capacidade de generalização e compromete seriamente a validade da avaliação [1].

Por fim, a contaminação pode ocorrer em diferentes fases do ciclo de treinamento [5]. Durante o pré-treinamento, é comum que corpora amplos e não curados incluam trechos relacionados a benchmarks, por compartilharem fontes comuns. No ajuste fino supervisionado, conjuntos rotulados podem conter instâncias próximas ou idênticas às utilizadas posteriormente nos dados de teste do modelo. Já na fase pós-implantação, dados derivados de interações com usuários ou gerados por outras LLMs também podem introduzir contaminação, especialmente quando reaproveitados para re-treinamento.

Essas diferentes manifestações evidenciam que a contaminação por dados de benchmarks é um fenômeno multifacetado, que pode ser sutil ou direta, intencional ou não, com impactos relevantes para a validade das avaliações, a comparação entre modelos e a confiabilidade dos sistemas desenvolvidos.

Metodologias de detecção

A identificação de contaminação em benchmarks exige metodologias específicas, que variam conforme o nível de acesso ao modelo avaliado. Esse acesso costuma ser classificado em três categorias. Modelos caixa branca permitem acesso completo aos pesos e aos dados de treinamento. Modelos caixa cinza têm documentação limitada e expõem distribuições de probabilidade ou valores de log‑probabilidade, mas não os dados originais. Já modelos caixa preta oferecem apenas as respostas finais, sem qualquer visibilidade sobre arquitetura ou treinamento.

Níveis de acesso a modelos

Cada configuração impõe limitações próprias e condiciona as técnicas de detecção disponíveis. Metodologias de detecção direta, como busca por duplicação literal ou análise de similaridade semântica, requerem transparência total sobre os dados de treinamento e, portanto, aplicam‑se principalmente a modelos caixa branca [1] [3] [4]. Já metodologias de detecção indireta, focadas em vazamentos comportamentais, manipulação de entrada, perturbações ou evidências temporais, podem ser empregadas inclusive em modelos caixa cinza ou caixa preta, pois não dependem de acesso direto aos dados utilizados no treinamento [3] [4]. A seguir, apresentam‑se as principais abordagens descritas na literatura, organizadas de acordo com a origem da evidência e o grau de inferência envolvido.

Metodologias de detecção direta

Algumas metodologias de detecção partem da premissa de que o conjunto de dados utilizado no treinamento do modelo é conhecido ou publicamente acessível. Nesses casos, é possível realizar comparações diretas entre os dados de teste (benchmarks) e os dados efetivamente utilizados no treinamento, o que permite evidenciar contaminações com alto grau de precisão.

Modelos classificados como caixa branca, como o Tucano, disponibilizam não apenas a arquitetura e os pesos, mas também todo o processo de pré-processamento e os dados utilizados no treinamento, possibilitando esse tipo de verificação. Já para modelos caixa cinza, mesmo entre os de código aberto como o LLaMA ou o Mistral, a ausência dos dados de treinamento impossibilita a aplicação dessas estratégias.

Entre os métodos mais utilizados nesse cenário estão:

String matching: busca por duplicações exatas entre exemplos do benchmark e entradas do conjunto de treinamento. Essa técnica utiliza substrings, n‑gramas ou trechos completos, sendo eficiente e de fácil implementação. Embora direta e objetiva, há limitação quanto à identificação de repetições literais, sem capturar variantes semânticas ou paráfrases [4].
Similaridade via embeddings: utiliza representações vetoriais de sentenças para medir a proximidade semântica entre exemplos do conjunto de treinamento e do benchmark. Essa técnica permite identificar contaminações menos explícitas, como reformulações e variações estruturais, sendo especialmente útil em casos em que não há duplicações literais. No entanto, além de mais custosa, sua eficácia depende da escolha apropriada do modelo de embeddings e da métrica de distância utilizada [4].
Detecção de paráfrases: utiliza LLMs ou classificadores especializados para avaliar se exemplos do benchmark são paráfrases de conteúdos previamente vistos. Essa abordagem é útil quando há suspeita de reformulações, mas exige supervisão humana ou limiares bem definidos para reduzir falsos positivos [4].

Essas técnicas são consideradas concretas e verificáveis, pois operam diretamente sobre os dados de treinamento e permitem mensurar de forma clara a sobreposição com os benchmarks. No entanto, apresentam alto custo metodológico, já que requerem acesso completo aos dados de treinamento e demandam recursos computacionais significativos para análise em larga escala.

Metodologias de detecção indireta

Em contextos em que os dados de treinamento não são públicos, como no caso de modelos proprietários (GPT-4, Claude ou Gemini), não é possível realizar comparações diretas com os benchmarks. Nessas situações, a detecção de contaminação depende de evidências indiretas, geralmente obtidas por meio de inferência estatística, análise cronológica ou observação de comportamentos em tarefas específicas.

Essas abordagens são especialmente relevantes em modelos classificados como caixa preta e caixa cinza, nos quais não há acesso aos dados de treinamento. Ainda assim, também podem ser aplicadas a modelos caixa branca, especialmente em análises comparativas, complementares ou em cenários de validação cruzada.

As principais estratégias empregadas nesse cenário incluem:

Análise cronológica: busca comparar o desempenho do modelo em benchmarks publicados em momentos distintos. Uma melhora abrupta em benchmarks liberados após a data de corte do treinamento pode sugerir exposição posterior ao conteúdo de teste [4].
Análise comportamental: avalia se o modelo responde corretamente a variações nos exemplos do benchmark, como prompts truncados, reordenados ou parafraseados. Técnicas como o TS-Guessing exploram esse princípio para detectar memorização implícita [2] [4].
Inferência por confiança: abrange métodos que estimam a presença de exemplos de treinamento com base no padrão de respostas do modelo. Técnicas como os Membership Inference Attacks (MIA) e o BenBench comparam o grau de confiança ou perplexidade do modelo em exemplos suspeitos em relação a exemplos sabidamente fora do treinamento. Uma concentração anormal de confiança ou variação de perplexidade em itens específicos pode indicar memorização [4] [6].

Essas metodologias são úteis para detectar contaminação em modelos sem transparência sobre seus dados de origem, mas envolvem maior grau de incerteza. Por dependerem de inferências comportamentais ou contextuais, os resultados exigem interpretação cuidadosa, especialmente quando utilizados de forma isolada. Ainda assim, úteis para a avaliação de modelos comerciais ou sem documentação disponível.

Ferramentas auxiliares na detecção de contaminação

Com o aumento da preocupação em torno da contaminação por dados de benchmarks, diversas ferramentas têm sido desenvolvidas para automatizar e padronizar estratégias de detecção. Essas ferramentas integram métodos complementares baseados em correspondência literal, similaridade semântica, comportamento do modelo e análises estatísticas, permitindo investigações mais robustas mesmo em contextos com acesso restrito aos dados ou aos parâmetros dos modelos.

O LLMSanitize implementa diversas técnicas descritas em diferentes estudos, oferecendo métodos voltados a modelos caixa branca, como string matching, truncamento de entrada e avaliação semântica com LLMs, bem como estratégias para modelos caixa cinza e caixa preta, como o TS-Guessing e o Sharded Likelihood, metodologias baseadas em análise comportamental.

Algumas ferramentas são voltadas a metodologias específicas. O BenBench, por exemplo, busca sinais de memorização implícita por meio da análise de perplexidade, similaridade e acurácia em versões originais e parafraseadas de benchmarks, sendo especialmente útil na avaliação de modelos caixa preta ou caixa cinza. O ConStat é voltado à comparação estatística entre o desempenho do modelo em dados suspeitos e em outros benchmarks similares, visando detectar padrões de desempenho atípicos. Já o CDD-TED propõe o uso de benchmarks diagnósticos controlados para examinar discrepâncias na distribuição de confiança e entropia das respostas, oferecendo evidências indiretas de contaminação.

Essas ferramentas representam meios práticos e sistemáticos para detectar exposições em diferentes níveis.

Conclusão

A contaminação por dados de benchmark constitui um desafio relevante para a avaliação justa de modelos de linguagem. Como discutido ao longo do texto, esse fenômeno compromete a validade das métricas, dificulta comparações entre LLMs e pode levar à adoção de modelos com desempenho superestimado em aplicações reais.

Para mitigar a contaminação, diversas estratégias têm sido indicadas na literatura. Entre elas, destacam-se a reformulação de benchmarks por meio de técnicas como paraphrasing e back-translation, a criação de conjuntos de teste dinâmicos, o uso de avaliações mediadas por modelos de linguagem mais robustos e a implementação de benchmarks privados com acesso controlado. No entanto, essas soluções ainda enfrentam limitações práticas, especialmente em idiomas sub-representados, nos quais a variedade e a qualidade dos dados disponíveis são restritas.

Este artigo apresentou uma caracterização geral da contaminação por dados de benchmark, abordando suas causas, impactos e principais metodologias de detecção. Como continuidade, serão conduzidos estudos empíricos com foco em idiomas sub-representados. Embora a maioria dos trabalhos existentes se concentre em idiomas amplamente representados nos dados globais, como o inglês e o chinês, há indícios de que o problema seja ainda mais crítico em línguas com menor presença nos repositórios de treinamento. A escassez de benchmarks exclusivos e a ampla reutilização de fontes públicas aumentam a probabilidade de sobreposição entre dados de treinamento e teste nesse contexto.

Tomando o português brasileiro como exemplo de idioma sub-representado, os estudos futuros utilizarão modelos multilíngues e especializados no idioma, com o objetivo de estimar o grau de exposição a dados de avaliação e contribuir para práticas mais consistentes de validação e comparação entre modelos.

Referências

[1] Cheng Xu, Shuhao Guan, Derek Greene, and M-Tahar Kechadi. 2024. Benchmark Data Contamination of Large Language Models: A Survey. arXiv preprint arXiv:2406.04244.

[2] Chunyuan Deng, Yilun Zhao, Xiangru Tang, Mark Gerstein, and Arman Cohan. 2024. Investigating Data Contamination in Modern Benchmarks for Large Language Models. In Proceedings of the 2024 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies (Volume 1: Long Papers), pages 8706–8719, Mexico City, Mexico. Association for Computational Linguistics.

[3] Chunyuan Deng, Yilun Zhao, Yuzhao Heng, Yitong Li, Jiannan Cao, Xiangru Tang, and Arman Cohan. 2024. Unveiling the Spectrum of Data Contamination in Language Model: A Survey from Detection to Remediation. In Findings of the Association for Computational Linguistics: ACL 2024, pages 16078–16092, Bangkok, Thailand. Association for Computational Linguistics.

[4] Mathieu Ravaut, Bosheng Ding, Fangkai Jiao, Hailin Chen, Xingxuan Li, Ruochen Zhao, Chengwei Qin, Caiming Xiong, and Shafiq Joty. 2024. How much are LLMs contaminated? A Comprehensive Survey and the LLMSanitize Library. arXiv preprint arXiv:2404.00699.

[5] Oscar Sainz, Jon Campos, Iker García-Ferrero, Julen Etxaniz, Oier Lopez de Lacalle, and Eneko Agirre. 2023. NLP Evaluation in Trouble: On the Need to Measure LLM Data Contamination for Each Benchmark. In Findings of the Association for Computational Linguistics: EMNLP 2023, pages 10776–10787, Singapore. Association for Computational Linguistics.

[6] Ruijie Xu, Zengzhi Wang, Run-Ze Fan, and Pengfei Liu. 2024. Benchmarking Benchmark Leakage in Large Language Models. arXiv preprint arXiv:2404.18824.

[7] Simone Balloccu, Patrícia Schmidtová, Mateusz Lango, and Ondrej Dusek. 2024. Leak, Cheat, Repeat: Data Contamination and Evaluation Malpractices in Closed-Source LLMs. In Proceedings of the 18th Conference of the European Chapter of the Association for Computational Linguistics (Volume 1: Long Papers), pages 67–93, St. Julian’s, Malta. Association for Computational Linguistics.

Computação@UFCG lidera contribuições do Brasil ao framework HELM-Stanford em parceria com a IBM

Wed, 09 Jul 2025 00:00:00 +0000

Colaboração entre Ciência da Computação da UFCG e a IBM faz da universidade a maior contribuinte brasileira para o framework de avaliação HELM-Stanford em 2025.

O HELM-Stanford é um dos principais frameworks globais para avaliar modelos de linguagem, medindo precisão, robustez e responsabilidade. Ser a maior contribuinte brasileira — por meio da parceria entre Computação@UFCG e a IBM — destaca o protagonismo nacional na construção de métricas mais justas, seguras e representativas para LLMs, especialmente em contextos multilíngues e culturais diversos.

A parceria entre Computação@UFCG e a IBM resultou em 15 contribuições significativas ao HELM-Stanford em 2025. Essas contribuições incluem a adição de benchmarks voltados à língua portuguesa, correções de bugs, melhorias no código-fonte e a inclusão de novos conjuntos de avaliação, ampliando a diversidade linguística e a robustez do framework.

O projeto coordenado pelo professor João Brunet, com participação dos professores Fábio Morais e Leandro Balby, conta com uma equipe multidisciplinar dedicada à avaliação de LLMs. Participam também um professor do IFPB, três alunos de pós-graduação, três de graduação e um profissional com experiência em desenvolvimento de software. A IBM, parceira no projeto, também destaca profissionais para atuarem diretamente na colaboração. Juntos, o grupo tem contribuído de forma expressiva para o avanço do HELM-Stanford, com foco na inclusão da língua portuguesa e na melhoria contínua do framework.

Equipe multidisciplinar do projeto

API de inferência de Modelos de Linguagem no servidor Power9 IBM

Thu, 03 Jul 2025 00:00:00 +0000

Contexto

Este é o quarto e último post de uma série de tutoriais cujo objetivo é mostrar passo a passo como construir uma API de Modelos de Linguagem em um servidor Power9, desde a configuração do sistema operacional até a execução remota de inferências. Já configuramos o sistema operacional, os drivers NVIDIA, CUDA e cuDNN no primeiro post, no segundo post instalamos Conda e PyTorch e no terceiro post construímos a API. Nesta etapa, vamos apresentar a API construída e mostrar como realizar requisições.

TL;DR

Este post apresenta a API de inferência de LLMs construída e como utilizar.
Vamos mostrar como realizar requisições via python e curl.

Apresentando a API

Esta API foi desenvolvida para expor modelos de linguagem de grande porte para inferência remota. Permite ao usuário carregar modelos específicos, mantê-los na memória da GPU para chamadas sucessivas e gerar texto a partir de prompts enviados via requisição HTTP. Foi implementada em FastAPI e inclui controle de acesso via API Key, gerenciamento de memória (carregar e descarregar modelos), suporte a múltiplas GPUs com sharding automático e endpoints para consulta de status. O objetivo é oferecer um serviço robusto, otimizado para uso intensivo, garantindo rapidez nas inferências e facilidade de integração com aplicações externas.

Visão Geral da Arquitetura

A API expõe modelos de linguagem via FastAPI com endpoints REST. O ModelManager gerencia o carregamento, descarregamento e a inferência dos modelos, mantendo-os em GPU para chamadas rápidas. A autenticação é feita por API Key. A arquitetura suporta múltiplas GPUs com sharding automático para otimizar o uso de memória e desempenho. Os modelos são importados do HuggingFace e utiliza a biblioteca Transformers para execução de inferências.

Diagrama da arquitetura

Principais Funcionalidades

Carregar Modelos
- /load_model
- Carrega modelo do HuggingFace Hub
- Faz sharding para as GPUs
- Suporte ao HuggingFace Token
Gerar Texto
- /generate
- Recebe prompt, max_tokens, nome do modelo, temperatura e top_p
- Usa modelo já carregado ou carrega um novo
- Retorna resultado em JSON
Gerenciamento
- /status: Verifica modelo carregado em device (CPU/GPU)
- /unload_model: libera GPU e memória
- /generate_apikey: cria chaves a partir de usuário LDAP

Fluxo de Uso

Diagrama do fluxo de uso

Entradas e Endpoints

Na tabela abaixo estão descritos o endpoints da API, entradas necessárias e retornos.

Tabela de endpoints e entradas
Endpoints	Método	Api Key	Entrada (Body/Query)	Retorno
`/generate_apikey`	POST	❌	{username}	API Key
`/load_model`	POST	✅	{model_name hf_token(opcional) device(opcional)}	Nenhum, apenas carrega o modelo
`/generate`	POST	✅	{model_name prompt hf_token(opcional) max_tokens(opcional) temperature(opcional) top_p(opcional)}	Texto gerado pelo modelo
`/status`	GET	✅	Nenhuma	Status do modelo e dispositivo que ele está carregado
`/unload_model`	POST	✅	Nenhuma	Nenhum, apenas descarrega o modelo

Como usar a API com Python

Gerar API Key

 1import requests 2import json 3import os 4 5url = "http://<ip_servidor_power9>:8000/" 6username = <usuario_ldap> 7hf_token = os.getenv("HUGGINGFACE_TOKEN") 8 9response = requests.post(f"{url}/generate_apikey", json={"username": username}).content.decode()1011api_key = json.loads(response).get("api_key")

É importante que o HuggingFace Token esteja definido como variável de ambiente no local em que esteja executando a inferência.
api_key será o retorno da função chamada.

Carregar Modelo

Primeiramente precisamos criar um header que irá conter a API Key retornada com o código acima e o payload que irá conter o model_name o token do huggingface hf_token. Após isso, podemos enviar a requisições com essas duas informações.

1headers = {"Content-Type": "application/json",2"x-api-key": api_key}34payload = {"model_name": "ibm-granite/granite-3.3-8b-instruct",5 "hf_token": hf_token}67resp = requests.post(f"{url}/load_model", headers=headers, json=payload)

Gerar Texto

Agora precisamos criar um novo payload com as informações necessárias para gerar um texto com uma llm, são elas: prompt, model_name e hf_token.

1payload = {"prompt": "Olá, me fale um pouco sobre a Universidade Federal de Campina Grande (UFCG)",2 "model_name": "ibm-granite/granite-3.3-8b-instruct",3 "hf_token": hf_token}45resp = requests.post(f"{url}/generate", headers=headers, json=payload)67resp = json.loads(resp.content.decode())

Consultar status e descarregar o modelo

Para consultar o status e descarregar o modelo não precisamos passar conteúdo pelo payload, apenas o header com a API key:

1requests.get(f"{url}/status", headers=headers).content

1resp = requests.post(f"{url}/unload_model", headers=headers)

Como usar a API com curl em CLI

Gerar API Key

curl -X POST "http://<ip_servidor_power9>:8000/generate_apikey" \ -H "Content-Type: application/json" \ -d '{"username": <usuario_ldap>}'

É importante que o HuggingFace Token esteja definido como variável de ambiente no local em que esteja executando a inferência.
O usuário no campo de username deve estar entre aspas (" “)
Após executar a requisição acima, a API key retornada deverá ser salva como variável de ambiente para facilitar as próximas execuções. Para salvar você deve copiar a API key retornada e executar o comando:

export API_KEY_P9=<api_key_retornada>

Carregar Modelo

curl -X POST "http://<ip_servidor_power9>:8000/load_model" \ -H "Content-Type: application/json" \ -H "x-api-key: $API_KEY" \ -d '{ "model_name":"ibm-granite/granite-3.3-8b-instruct", "hf_token":"'"$HUGGINGFACE_TOKEN"'" }'

Gerar Texto

curl -X POST "http://<ip_servidor_power9>:8000/generate" \ -H "Content-Type: application/json" \ -H "x-api-key: $API_KEY" \ -d '{ "model_name": "ibm-granite/granite-3.3-8b-instruct" "prompt":"Olá, me fale um pouco sobre a Universidade Federal de Campina Grande (UFCG)", "hf_token": "'"$HUGGINGFACE_TOKEN"'", "max_tokens":50 }'

Consultar status e descarregar o modelo

Para consultar o status e descarregar o modelo não precisamos passar conteúdo pelo payload, apenas o header com a API key:

curl -X GET "http://<ip_servidor_power9>:8000/status" \ -H "Content-Type: application/json" \ -H "x-api-key: $API_KEY"

curl -X POST "http://<ip_servidor_power9>:8000/unload_model" \ -H "Content-Type: applicatzion/json" \ -H "x-api-key: $API_KEY"

Esperamos que estes posts tenham ajudado a esclarecer todo o processo de desenvolvimento e implantação. O time LLM-IBM-UFCG está à disposição para dúvidas ou sugestões sobre aprimoramentos futuros.

Construindo API para inferências de LLMs em um servidor IBM Power9

Wed, 02 Jul 2025 00:00:00 +0000

Contexto

Este é o terceiro post de uma série de tutoriais cujo objetivo é mostrar passo a passo como construir uma API de Modelos de Linguagem em um servidor Power9, desde a configuração do sistema operacional até a execução remota de inferências. Já configuramos o sistema operacional, os drivers NVIDIA, CUDA e cuDNN no primeiro post, e no segundo post instalamos Conda e PyTorch. Nesta etapa, vamos construir a API usando FastAPI e a biblioteca Transformers, baixando modelos do Hugging Face e executando o servidor web com uvicorn.

A API implementada terá as funcionalidades de gerar API Key, carregar modelos, realizar inferências, obter status e desccaregar modelos.

FastAPI: Framework web moderno para construção de APIs com Python 3.8+, baseado em tipagem estática e assíncrona. Foi projetado para ser rápido, fácil de usar e robusto, tornando o desenvolvimento de APIs mais eficiente.

Transformers: Biblioteca de código aberto desenvolvida pela Hugging Face. Fornece acesso prático e eficiente a uma ampla coleção de modelos pré-treinados de última geração para Processamento de Linguagem Natural (PLN), visão computacional e áudio.

Hugging Face: Hugging Face é uma plataforma focada em inteligência artificial, conhecida por hospedar modelos de NLP e outras tarefas. O Hugging Face Hub é um repositório colaborativo onde desenvolvedores e pesquisadores podem compartilhar, versionar e baixar modelos prontos para uso, facilitando o acesso e integração de modelos.

Uvicorn: Servidor web ASGI (Asynchronous Server Gateway Interface). O Uvicorn é um servidor de alta performance para aplicações Python assíncronas.

TL;DR

Este post apresenta o passo a passo para implementar uma API que realiza inferências de Grandes Modelos de Linguagem.
Usaremos FastAPI e Transformers para desenvolver essa API e Hugging Face para baixar os modelos.

Configuração do Ambiente

Estrutura de Diretórios

Primeiro, vamos criar a estrutura básica do projeto:

model_api/├── requirements.txt├── app/│ ├── __init__.py│ ├── main.py│ ├── schemas.py│ ├── auth.py│ ├── model_manager.py│ ├── utils.py│ └── apikey_store.json└── README.md (opcional)

Arquivo `requirements.txt`

Vamos usar FastAPI e Transformers para implementar a API. Além disso, usaremos uvicorn para executar o servidor, pydantic para validação de dados de entrada e torch, que já instalamos no tutorial anterior.

Primeiro, vamos instalar as bibliotecas necessárias e depois preencher o arquivo requirements.txt. Lembre-se de ativar o ambiente conda se você o criou, para garantir o uso correto do pytorch.

conda activate llm_apipip install fastapi uvicorn transformers

O arquivo requirements.txt ficará assim:

requirements.txt

1fastapi>=0.104.02uvicorn>=0.24.03torch>=2.0.04transformers>=4.35.05pydantic>=2.0.0

Arquivo de Armazenamento de API Keys

O arquivo apikey_store.json será usado para armazenar as chaves de API geradas. Vamos iniciá-lo vazio, contendo apenas {}.

apikey_store.json

1{}

Schemas e validação de dados

Os schemas são essenciais para validar os dados de entrada e saída da API. Eles garantem que os dados estejam no formato correto e permitem a geração automática de documentação.

Vamos criar o arquivo app/schemas.py com todos os modelos de dados. Teremos quatro modelos: GenerateRequest, LoadModelRequest, ApiKeyResponse e LDAPUserRequest.

schemas.py

 1from pydantic import BaseModel, Field 2from typing import Optional 3 4class GenerateRequest(BaseModel): 5 model_name: str = Field(..., description="The name of the model to use for generation.") 6 prompt: str = Field(..., description="The input text to generate a response for.") 7 max_tokens: Optional[int] = Field(300, description="The maximum length of the generated response.") 8 temperature: Optional[float] = Field(1.0, description="The sampling temperature for generation.") 9 top_p: Optional[float] = Field(1.0, description="The cumulative probability for nucleus sampling.")10 hf_token: Optional[str] = Field(None, description="The Hugging Face tokenizer to use, if applicable.")111213class LoadModelRequest(BaseModel):14 model_name: str = Field(..., description="The name of the model to load.")15 device: Optional[str] = Field("cuda", description="The device to load the model on (e.g., 'cpu', 'cuda').")16 hf_token: Optional[str] = Field(None, description="The Hugging Face tokenizer to use, if applicable.")1718class ApiKeyResponse(BaseModel):19 api_key: str = Field(..., description="The API key for accessing the model API.")2021class LDAPUserRequest(BaseModel):22 username: str = Field(..., description="The username for LDAP authentication.")

Todas as classes herdam da classe BaseModel da biblioteca pydantic, obtendo funcionalidades de validação, serialização e documentação automática.
O campo Field(...) define um campo obrigatório sem valor padrão.
O campo Field(value) define um campo obrigatório com value como valor padrão.
O tipo Optional[type] indica que o campo é opcional, mas deve ser do tipo type se fornecido.

Com os schemas definidos, vamos criar o arquivo responsável pela autenticação via API Key.

Autenticação e API Keys

O sistema de autenticação protege a API, garantindo que apenas usuários autorizados possam acessar os endpoints. Vamos implementar um mecanismo baseado em API Keys.

Vamos criar o arquivo app/auth.py com todas as funcionalidades de autenticação.

auth.py

 1import secrets  2import json 3from fastapi import HTTPException, Request 4 5APIKEY_STORE_FILE = "app/apikey_store.json" 6 7def load_apikeys(): 8 try: 9 with open(APIKEY_STORE_FILE, "r") as f:10 return json.load(f)11 except FileNotFoundError:12 raise HTTPException(13 status_code=404,14 detail=f"Arquivo de API keys não encontrado: {APIKEY_STORE_FILE}")15 16def save_apikeys(keys: dict):17 with open(APIKEY_STORE_FILE, "w") as f:18 json.dump(keys, f, indent=4)1920def generate_apikey(user:str) -> str:21 key = secrets.token_hex(32)22 keys = load_apikeys()23 keys[user] = key24 save_apikeys(keys)25 return key2627async def verify_apikey(request: Request) -> bool:28 apikey = request.headers.get("x-API-Key")29 if not apikey:30 raise HTTPException(31 status_code=401,32 detail="API key não fornecida.")33 try:34 keys = load_apikeys()35 if apikey in keys.values():36 return True37 38 except json.JSONDecodeError:39 raise HTTPException(40 status_code=403,41 detail="API key inválida.")

A função load_apikeys carrega as informações armazenadas no arquivo app/apikey_store.json.
save_apikeys é responsável por salvar o conteúdo no formato JSON.
A função generate_apikey cria uma chave para um usuário e a adiciona ao dicionário, usando o username como chave.
verify_apikey será chamada sempre que uma requisição chegar, para realizar a validação.

Gerenciador de Modelos e GPU

O app/model_manager.py é o coração da API, responsável por carregar, gerenciar e executar os modelos de linguagem. Ele otimiza o uso de GPU/CPU e garante eficiência na geração do texto.

model_manager.py

 1import torch  2from transformers import AutoTokenizer, AutoModelForCausalLM 3from fastapi import HTTPException 4import gc 5from .utils import is_model_on_gpu 6 7DEVICE = "cuda" if torch.cuda.is_available() else "cpu" 8 9class ModelManager:10 def __init__(self):11 self.model = None12 self.tokenizer = None13 self.model_name = None1415 def load_model(self, model_name: str, hf_token:str = None, device: str = DEVICE):16 if self.model_name != None and self.model_name != model_name:17 print("Removendo modelo carregado anteriormente...")1819 self.unload_model() 20 print(f"Carregando modelo {model_name} no dispositivo {device}...")21 22 if self.model_name != model_name:23 try: 24 if hf_token: 25 self.tokenizer = AutoTokenizer.from_pretrained(model_name, token=hf_token)26 self.model = AutoModelForCausalLM.from_pretrained(model_name, device_map="balanced", token=hf_token)27 else:28 self.tokenizer = AutoTokenizer.from_pretrained(model_name)29 self.model = AutoModelForCausalLM.from_pretrained(model_name, device_map="balanced")30 self.model.eval()31 self.model_name = model_name32 print(is_model_on_gpu(self.model.hf_device_map, self.model_name))33 34 except Exception as e:35 raise HTTPException(status_code=500, detail=f"Erro ao carregar modelo: {str(e)}")36 else:37 print(f"O modelo {model_name} já está carregado.")3839 def generate(self, model_name:str, hf_token: str, prompt:str, max_tokens:int = 300, temperature:float = 1.0, top_p:float = 1.0) -> str:40 41 if self.model_name != model_name:42 self.load_model(model_name, hf_token, device=DEVICE)4344 if self.model is None or self.tokenizer is None:45 raise HTTPException(status_code=400, detail="Nenhum modelo carregado.")4647 try:48 inputs = self.tokenizer(prompt, return_tensors="pt").to(self.model.device)49 with torch.no_grad(): 50 outputs = self.model.generate(**inputs, max_new_tokens=max_tokens,temperature=temperature, top_p=top_p, eos_token_id=self.tokenizer.eos_token_id)51 return self.tokenizer.decode(outputs[0], skip_special_tokens=True)52 except Exception as e:53 raise HTTPException(status_code=500, detail=f"Erro ao gerar texto: {str(e)}")54 55 def get_status(self) -> str: 56 if self.model is None:57 self.unload_model()58 return "Nenhum modelo carregado." 59 return is_model_on_gpu(self.model.hf_device_map, self.model_name)6061 def unload_model(self):62 self.model = None63 self.tokenizer = None64 old_model = self.model_name if self.model_name else False65 self.model_name = None6667 gc.collect()68 torch.cuda.empty_cache()69 return f"Modelo {old_model} descarregado com sucesso." if old_model else "Nenhum modelo carregado para descarregar."7071manager = ModelManager()

A função load_model carrega o novo modelo na memória, removendo algum modelo que foi carregado anteriormente.
generate é a principal função da API, ela é responsável por realizar a inferência do modelo. Permite alterar os parâmetros: temperature, top_p e max_tokens.
get_status é responsável por informar se existe modelo carregado e se está em GPU ou CPU.
A função unload_model remove o modelo da memória, limpando o cache do CUDA e utilizando o garbage collector do python para não restar resquícios que possam atrapalhar futuros carregamentos.

Endpoints da API FastAPI

O arquivo app/main.py é onde todos os componentes se conectam. Nele definimos todos os endpoints e a lógica de roteamento da API.

main.py

 1from fastapi import FastAPI, Request, HTTPException, Depends 2from fastapi.responses import JSONResponse 3from app import schemas, model_manager, auth 4 5app = FastAPI() 6 7async def require_api_key(request: Request) -> schemas.LDAPUserRequest: 8 user = await auth.verify_apikey(request) 9 if not user:10 raise HTTPException(status_code=401, detail="API key invalida.")11 return user1213@app.post("/generate_apikey")14async def generate_apikey(payload: schemas.LDAPUserRequest) -> JSONResponse:15 key = auth.generate_apikey(payload.username)16 return JSONResponse(status_code=200, content={"api_key": key})1718@app.post("/load_model", dependencies=[Depends(require_api_key)])19async def load_model(payload: schemas.LoadModelRequest) -> JSONResponse:20 try:21 model_manager.manager.load_model(payload.model_name, payload.hf_token, payload.device)22 return JSONResponse(content={"message": f"Modelo {payload.model_name} carregado com sucesso."})23 except Exception as e:24 raise HTTPException(status_code=500, content={"error": str(e)})25 26@app.post("/generate", dependencies=[Depends(require_api_key)])27async def generate(payload: schemas.GenerateRequest)-> JSONResponse:28 try:29 result = model_manager.manager.generate(payload.model_name, payload.hf_token,payload.prompt, payload.max_tokens, payload.temperature, payload.top_p)30 return {"result": result}31 except Exception as e:32 return JSONResponse(status_code=500, content={"error": str(e)})33 34@app.get("/status", dependencies=[Depends(require_api_key)])35async def status()-> JSONResponse:36 str_status = model_manager.manager.get_status()37 return JSONResponse(content={"status": str_status})3839@app.post("/unload_model", dependencies=[Depends(require_api_key)])40async def unload_model() -> JSONResponse:41 try:42 str_unload = model_manager.manager.unload_model()43 return JSONResponse(content={"message":str_unload})44 except Exception as e:45 raise HTTPException(status_code=500, content={"error": str(e)})

A função require_api_key verifica a API Key sempre que chega uma requisição e retorna o usuário autenticado ou gera erro 401.
generate_apikey gera e retorna uma nova chave de API para o usuário informado.
load_model carrega o modelo especificado. Caso o modelo necessite de um token Hugging Face, a função também recebe esse parâmetro.
A função generate é responsável por fazer o modelo realizar a inferência a partir do prompt e os parâmetros passados.
Ao chamar o endpoint status o usuário recebe o status atual do gerenciador de modelos.
unload_model descarrega o modelo atualmente carregado e retorna uma mensagem de sucesso caso tenha concluído corretamente.

Arquivo `utils.py`

O arquivo app/utils.py contém a função que verifica se o modelo carregado está totalmente/parcialmente em GPU ou foi carregado em CPU.

utils.py

1def is_model_on_gpu(hf_device_map: dict, model_name: str) -> str:2 if '' in hf_device_map.keys() and hf_device_map[''] == 'cpu':3 return f"Modelo {model_name} carregado totalmente na CPU."4 elif 'cpu' in hf_device_map.values():5 return f"Algumas camadas do modelo {model_name} estão carregadas na CPU."6 else:7 return f"Modelo {model_name} carregado totalmente na GPU."

Executando a API

Para executar a API com o uvicorn é muito simples, basta executar um comando com as informações de host e porta para o serviço rodar.

uvicorn app.main:app --host 0.0.0.0 --port 8000 --reload

app:main se refere ao arquivo app/main.py responsável por conectar todos os componentes e receber as requisições realizadas pelo usuário.
--host 0.0.0.0 define o endereço IP no qual o servidor Uvicorn irá escutar as requisições. O valor 0.0.0.0 define que este servidor estará acessível de qualquer interface de rede disponível na máquina Power9.
--port 8000 especifica a porta na qual o servidor irá escutar as requisições.
--reload flag para ser utilizada em desenvolvimento. Recarrega a aplicação sempre que uma mudança é realizada.

Seguindo estas implementações, você terá uma API capaz de realizar inferências com Modelos de Linguagem baixados do Hugging Face. No próximo tutorial será demonstrado como enviar requisições para a API via curl e python.

Configurando Conda e PyTorch em um servidor IBM Power9

Mon, 30 Jun 2025 00:00:00 +0000

Contexto

Este é o segundo post de uma série de tutoriais que vamos mostrar o passo-a-passo de como construir uma API de Modelos de Linguagem em um servidor Power9, desde da configuração do Sistema Operacional, até a API executando inferências de forma remota. O primeiro post mostra como instalar o S.O e configurar drivers NVIDIA, CUDA e CUDNN. Nesta etapa do tutorial vamos mostrar a configuração do gerenciador de pacotes Conda e da biblioteca PyTorch

Conda: Conda é um sistema de gerenciamento de pacotes e ambientes de código aberto e multiplataforma. Ele funciona como uma “caixa de ferramentas” para cientistas de dados e desenvolvedores, ajudando a organizar seus projetos.

PyTorch: PyTorch é uma biblioteca de código aberto para aprendizado de máquina, desenvolvida principalmente pelo Facebook AI Research (FAIR). Ela é especialmente popular para o desenvolvimento de aplicações de deep learning (aprendizado profundo), um subcampo do aprendizado de máquina que se inspira no funcionamento do cérebro humano.

TL;DR

Este post apresenta o passo-a-passo para a instalação do Conda e PyTorch.
O desafio maior é encontrar versões compatíveis com a arquitetura das máquinas Power.

Configurando Conda

Vamos começar com a instalação do Conda. Em sistemas Power, a arquitetura usada é a ppc64le (PowerPC 64 bits little-endian), por isso é essencial que a versão baixada seja para esta arquitetura. Para isso, vamos utilizar o miniconda, uma versão mais leve e direta para setups customizados como o servidor Power9.

Para baixar e instalar a versão mais atualizada do miniconda:

sudo wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-ppc64le.shbash ~/Miniconda3-latest-Linux-ppc64le.sh

Verifique se a instalação ativou o conda automático:

conda -–version

Caso não tenha iniciado automaticamente, o Conda precisa ser ativado.

Para não precisar ativar sempre que realizar uma nova conexão, vamos escrever o comando no bashrc (ou zshrc):

echo 'source ~/miniconda3/etc/profile.d/conda.sh' >> ~/.bashrcsource ~/.bashrc

Verifique novamente com o comando:

conda --version

A saída esperada é algo semelhante a: conda 23.10.0

Instalando e configurando a biblioteca PyTorch

Não existem builds oficiais ou wheels Conda/PyPi com suporte completo para a arquitetura ppc64le, sendo assim, para instalar o PyTorch precisamos buildar manualmente.

(Opcional) Criação de ambiente virtual Conda

Para iniciarmos a instalação é aconselhável criar um ambiente virtual para instalar o pytorch apenas nele.

Para criar e ativar o ambiente virtual executamos os comandos:

conda create -y -n api_llm python=3.10conda activate api_llm

Instalando pré-requisitos

Precisamos instalar alguns pacotes necessários para realizar o build do PyTorch da forma correta.

Inicialmente, vamos instalar os pacotes com os seguintes comandos:

conda install -y -c conda-forge openblas libblas cmake ninja python3-devel gcc-c++ rust cargo

O CMake (sistema de build utilizado pelo PyTorch) removeu o suporte a scripts que declaram compatibilidade com versões antigas (<3.5). Para resolver isso, precisamos instalar via pip uma versão do cmake <3.5.

Executamos o comando:

pip install cmake==3.27.7

Para garantir que a versão correta foi instalada, executamos o comando:

cmake --version

A saída esperada é: cmake version 3.27.7

Build do Pytorch

Agora vamos iniciar o processo de build do PyTorch.

O primeiro passo é clonar o repositório e configurar para instalar a versão 2.6.0:

git clone --recursive https://github.com/pytorch/pytorchcd pytorchgit checkout v2.6.0 git submodule sync git submodule update --init --recursive

Para instalar os pacotes necessários via pip executamos o seguinte comando:

pip install -r requirements.txt

E, finalmente, para realizar o build do PyTorch, executamos o setup.py do python:

sudo USE_CUDA=1 USE_DISTRIBUTED=1 USE_NCCL=1 USE_GLOO=1 USE_CUDNN=1 python setup.py install

O processo de build geralmente demora um tempo considerável, cerca de 15 minutos.

Para testar se tudo ocorreu certo, vamos criar um arquivo chamado test_torch.py

nano test_torch.py

Esse arquivo deve conter as seguintes linhas:

 1import torch 2print(torch.__version__) 3print("CUDA disponível:", torch.cuda.is_available()) 4print("Número de GPUs:", torch.cuda.device_count()) 5print("Nome da GPU:", torch.cuda.get_device_name(0)) 6x = torch.rand(3, 3).cuda() 7y = torch.rand(3, 3).cuda() 8print("Soma na GPU:", (x + y)) 9print("cuDNN disponível:", torch.backends.cudnn.is_available())10print("Extensões C carregadas:", torch._C._cuda_getDeviceCount() > 0)

Ao executar esse arquivo, saberemos:

Versão instalada do pytorch
Disponibilidade do CUDA
Quantidade de GPUs disponíveis
Nome da GPU no servidor Power9
Se a utilização da GPU está acontecendo de forma correta
Disponibilidade do CUDNN
Se os arquivos .so foram compilados corretamentes

Esse arquivo apenas checa algumas informações do CUDA e PyTorch e executa uma operação de soma utilizando tensores em GPU.

Vamos executar o arquivo com o comando:

python test_gpu.py

A saída deve ser algo semelhante a:

2.6.0a0+git1eba9b3CUDA disponível: TrueNúmero de GPUs: 4Nome da GPU: Tesla V100-SXM2-16GBSoma na GPU: tensor([[1.9163, 1.2208, 0.5998], [1.7962, 0.6040, 1.3943], [0.9536, 0.8010, 0.0668]], device='cuda:0')cuDNN disponível: TrueExtensões C carregadas: True

É importante lembrar que as saídas podem ser diferentes em relação ao número e modelo das GPUs e a soma de tensores (devido a aleatoriedade). É importante que as saídas booleanas do código que executamos tenham resultados igual a True.

Com isso, a biblioteca PyTorch está instalada e configurada para ser utilizada. No próximo tutorial vamos realizar a primeira inferência de um Modelo de Linguagem no servidor Power9.

Configurando S.O, NVIDIA Drivers, CUDA e CUDNN em um servidor IBM Power9

Sun, 29 Jun 2025 00:00:00 +0000

Contexto

Este é o primeiro post de uma série de tutoriais sobre como construir uma API de Modelos de Linguagem em um servidor Power9, desde da configuração do Sistema Operacional, até a API executando inferências de forma remota.Esta etapa do tutorial mostra como configurar o Sistema Operacional, instalar os drivers da NVIDIA, CUDA e CUDNN em máquinas com processador IBM Power9 AC922. O foco é garantir que tudo funcione corretamente em arquiteturas ppc64le, comuns em ambientes de alto desempenho.

IBM Power9: A IBM Power9 AC922 é uma máquina de alto desempenho usada em tarefas pesadas como inteligência artificial e processamento científico. Ela usa processadores Power9 e trabalha bem com GPUs NVIDIA, oferecendo alta velocidade de comunicação entre CPU e GPU.

NVIDIA Drivers: Programas que permitem que o sistema operacional se comunique corretamente com as placas de vídeo da marca. São essenciais para ativar o uso de GPUs.

CUDA: Plataforma NVIDIA que permite usar GPUs para acelerar cálculos paralelos. Com essa plataforma é possível rodar algoritmos complexos de forma rápida, como a execução de Grandes Modelos de Linguagem, por exemplo.

CUDNN: Uma biblioteca de primitivas otimizadas para redes neurais profundas (DNNs), desenvolvida pela NVIDIA. Ele oferece implementações de alto desempenho para operações essenciais em DNNs, como convoluções, pooling e normalização, acelerando significativamente o treinamento e a inferência em GPUs.

TL;DR

Este post apresenta o passo-a-passo de configurar um servidor Power9 incluindo setup do SO e configurações NVIDIA.
O desafio maior é encontrar versões compatíveis com a arquitetura das máquinas Power.

Configurando Sistema Operacional

Vamos começar com a instalação do Red Hat Enterprise Linux 8.10 (Ootpa). Em sistemas Power, a arquitetura usada é a ppc64le (PowerPC 64 bits little-endian), por isso é essencial que a imagem .iso seja compatível com essa arquitetura. Caso contrário, o petitboot da Power9 não reconhecerá a mídia e a instalação não poderá continuar.

Você pode baixar a imagem correta pelo link indicado.
Neste tutorial, usaremos a opção Boot ISO e seguiremos as instruções da documentação oficial da Red Hat para criar uma mídia USB inicializável.
Após inserir a mídia de instalação no servidor Power 9 e reiniciar a máquina, o sistema deve iniciar automaticamente no petitboot.
A partir desta etapa, basta seguir o guia de instalação oficial para concluir a configuração do sistema.

Configurando Driver NVIDIA e CUDA

Checagem de GPUs e Sistema Operacional

Para o sistema operacional realizar comunicação correta com as GPUs do servidor, precisamos instalar e configurar o driver da NVIDIA.

Inicialmente, vamos checar a presença da(s) GPU(s):

lspci | grep -i nvidia

A saída esperada é algo como:

0004:04:00.0 3D controller: NVIDIA Corporation GV100GL [Tesla V100 SXM2 16GB] (rev a1)

Após isso, vamos verificar arquitetura e nome do sistema operacional:

uname -m && cat /etc/redhat-release

A saída esperada é:

ppc64le Red Hat Enterprise Linux release 8.10 (Ootpa)

Evitando interferências

Para evitar algumas interferências, é recomendável desativar o driver nouveau e SELinux.

O noveau é um driver de código aberto para GPUs NVIDIA que subsitui o driver proprietário quando o usuário quer apenas usar o software livre, sem necessidade de de alto desempenho.

O SELinux=enable restringe alguns processos de aplicarem mudanças no sistema, podendo conflitar com as instalações que vamos fazer neste tutorial.

Desative o driver nouveau:

echo -e "blacklist nouveau\noptions nouveau modeset=0" | sudo tee /etc/modprobe.d/disable-nouveau.conf

Para desativar o SELinux, primeiro vamos checar o status executando:

sestatus

Caso esteja ativo, será preciso setar o parâmetro SELINUX=disabled no arquivo /etc/selinux/config para prosseguir. É importante lembrar que a edição só será salva com permissão sudo.

Após isso, vamos atualizar o initrafms e reiniciar a máquina com os seguintes comandos:

sudo dracut --forcesudo reboot

Para checar se tudo deu certo até agora, vamos checar se o nouveau foi desabilitado:

lsmod | grep nouveau

Caso tenha sido desabilitado, não terá saída.

Para checar o SELinux:

sestatus

Caso tenha sido desabilitado, a saída será: SELinux status: disabled

Instalando pré-requisitos

Vamos instalar alguns pré-requisitos antes de iniciar a instalação de fato:

sudo dnf install pciutils environment-modulessudo dnf install kernel-devel-$(uname -r) kernel-headerssudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpmsudo dnf clean all sudo dnf install dkms

Também precisamos habilitar alguns repositórios:

sudo subscription-manager repos --enable=rhel-8-for-ppc64le-appstream-rpmssudo subscription-manager repos --enable=rhel-8-for-ppc64le-baseos-rpmssudo subscription-manager repos --enable=codeready-builder-for-rhel-8-ppc64le-rpms

Baixando e instalando repositórios dos pacotes CUDA

Vamos baixar a versão 12.2 do CUDA e o Driver NVIDIA 535.54.03-1 com o comando seguinte:

wget https://developer.download.nvidia.com/compute/cuda/12.2.0/local_installers/cuda-repo-rhel8-12-2-local-12.2.0_535.54.03-1.ppc64le.rpm

Para instalar o pacote baixado:

sudo rpm -i cuda-repo-rhel8-12-2-local-12.2.0_535.54.03-1.ppc64le.rpm

Para instalar o driver NVIDIA e o CUDA, os seguintes comandos serão executados:

sudo dnf install nvidia-driver-cuda sudo dnf clean all sudo dnf module reset nvidia-driver sudo dnf module enable nvidia-driver:latest-dkmssudo dnf -y module install nvidia-driver:latest-dkmssudo dnf -y install cuda

Com esses comandos a instalação do driver e do CUDA estão finalizadas.

Processos pós-instalação

Vamos declarar as variáveis de ambiente PATH e LD_LIBRARY_PATH. Para isso, deve-se editar o arquivo .bashrc e adicionar essas duas linhas:

export PATH=/usr/local/cuda/bin:$PATH export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH

Para atualizar as variáveis de ambiente, vamos executar o comando:

source ~/.bashrc

Precisamos realizar duas mudanças de forma manual, pois não são tratadas de forma automática pela instalação dos pacotes CUDA. Caso não sejam realizadas, a instalação do driver CUDA ficará inoperante.

A primeira mudança será configurar o deamon de persistência da NVIDIA. Primeiro vamos verificar o status e caso não esteja ativo, vamos ativar:

systemctl status nvidia-persistencedsystemctl enable nvidia-persistenced

Algumas distros Linux possuem uma regra do udev que coloca a memória hot-plug em estado online assim que é detectada fisicamente, impedindo que o software da NVIDIA configure a memória da GPU com os parâmetros corretos no Power9.

Para desativar esta regra, vamos executar os comandos:

sudo cp /lib/udev/rules.d/40-redhat.rules /etc/udev/rules.d/sudo sed -i 's/SUBSYSTEM!="memory",.*GOTO="memory_hotplug_end"/SUBSYSTEM=="*", GOTO="memory_hotplug_end"/' /etc/udev/rules.d/40-redhat.rules

Checagem de instalação

Após realizar todos esses procedimentos, vamos reiniciar a máquina e checar as instalações:

Reiniciando a máquina:

sudo reboot

Checagem de driver NVIDIA:

nvidia-smi

A saída do comando acima deve mostrar informações do compilador CUDA: versão e data de instalação. Além de mostrar os dispositivos (GPUs) disponíveis com nome, memória, temperatura entre outras informações.

Para realizar a última checagem, vamos baixar o repositório cuda-samples e executar o teste de dispositivos.

Baixando o repositório e acessando a versão do cuda-samples referente ao CUDA instalado:

git clone https://github.com/NVIDIA/cuda-samples.git cd cuda-samples/Samples/1_Utilities/deviceQuerygit checkout v12.2

Para buildar e executar os testes:

make./deviceQuery

Após executar este teste, espera-se que na última linha contenha: Result = PASS. Com isso, a Power9 está configurada, com driver NVIDIA e CUDA funcionando corretamente.

Configurando CUDNN

Inicialmente, precisamos baixar e instalar o .rpm específico para ppc64le.

wget https://developer.download.nvidia.com/compute/cudnn/9.0.0/local_installers/cudnn-local-repo-rhel8-9.0.0-1.0-1.ppc64le.rpmsudo rpm -i cudnn-local-repo-rhel8-9.0.0-1.0-1.ppc64le.rpmsudo dnf clean allsudo dnf -y install cudnn

Após a instalação, precisamos configurar as variáveis de ambiente CUDNN_LIBRARY e CUDNN_INCLUDE_DIR: (De uma forma mais direta do que fizemos anteriormente)

echo 'export CUDNN_LIBRARY=/usr/lib64' >> ~/.bashrc echo 'export CUDNN_LIBRARY=/usr/lib64' >> ~/.bashrc

Após isso, o processo de instalação do CUDNN está finalizado.

Esta é a primeira parte do nosso tutorial. Uma vez que todas as etapas mostradas neste post foram finalizadas, o servidor está pronto para ter o gerenciador de pacotes conda e a biblioteca pytorch instaladas, você pode acessar a segunda parte deste tutorial neste link.

Avaliando LLMs de Pequeno Porte (até 8B) em Benchmarks PT-BR

Mon, 02 Jun 2025 00:00:00 +0000

Contexto

Este é o primeiro de dois posts desta série, que tem como objetivo apresentar um resumo da investigação que conduzimos utilizando o framework de avaliação HELM (Holistic Evaluation of Language Models) para avaliar os modelos da família Granite, o modelo Llama-3.1-8B e o modelo DeepSeek-R1-Distill-Llama-3.1-8B. As avaliações contemplam tanto benchmarks em português quanto tarefas voltadas à geração de código. Nesta primeira parte, o foco é avaliar o desempenho dos modelos no contexto do português brasileiro (PT-BR) para as tarefas de análise de sentimentos e MQA (Multiple-Choice Question Answering). Depois, na segunda parte, que será publicada em breve, abordará os resultados das avaliações em tarefas de geração de código.

O uso de conjuntos de dados em inglês para a avaliação de modelos de linguagem é uma prática comum. No entanto, para verificar a eficácia desses modelos em diferentes idiomas e contextos culturais, é relevante testá-los em benchmarks de outras línguas. No caso do PT-BR, que costuma representar uma parcela menor dos dados utilizados no treinamento de modelos multilíngues, compreender o comportamento desses modelos é um passo importante para avaliar sua adequação a tarefas e contextos específicos dessa língua. Neste sentido, este post busca contribuir para esse entendimento, destacando avanços e desafios ainda presentes no desempenho dessas LLMs em tarefas no contexto do PT-BR.

TL;DR

Avaliamos os modelos: Granite, Llama-3.1-8B e DeepSeek-R1-Distill-Llama-3.1-8B nos benchmarks ENEM Challenge, TweetSent-Br e IMDB.
Nosso método envolveu uma experimentação apoiada pelo framework HELM, que apresentamos em detalhes neste documento.
Os resultados revelam que os modelos classificam com precisão os sentimentos em críticas de filmes em PT-BR.

Método

Ambiente de Execução e Ferramenta Utilizada

O HELM foi a ferramenta utilizada para conduzir as avaliações. Trata-se de um framework de avaliação de LLMs, desenvolvido por pesquisadores da Universidade de Stanford, que contempla uma variedade de benchmarks, como análise de sentimentos, geração de código, questões de múltipla escolha, entre outros. Com base nesses benchmarks, utilizamos os modelos Granite (até 8B), Llama-3.1-8B e DeepSeek-R1-Distill-Llama-3.1-8B para medir e comparar seus desempenhos.

Para a execução dos experimentos, utilizamos o Google Colab como ambiente, que conta com uma GPU A100. Neste ambiente, foi possível clonar o repositório do HELM e executar modelos com até 8 bilhões de parâmetros. Todo o processo de configuração e testes foi realizado nessa plataforma, garantindo praticidade e acesso aos recursos computacionais necessários.

Em uma postagem futura, iremos detalhar as estratégias e ferramentas de avaliação de LLMs, com um foco mais aprofundado no funcionamento e nas capacidades do HELM.

Benchmarks e Modelos

Para realizar os testes em cenários voltados ao português brasileiro, foi necessário estender o HELM com a inserção de novos benchmarks, uma vez que, até então, a ferramenta não apresentava suporte para esse idioma. Essa iniciativa representou uma contribuição direta ao HELM, com a adição de três benchmarks:

ENEM Challenge: construído a partir de questões do Exame Nacional do Ensino Médio (ENEM), com o objetivo de avaliar a capacidade dos LLMs em resolver tarefas de MQA em diversas áreas do conhecimento, incluindo Ciências Humanas, Ciências da Natureza, Linguagens e Códigos e Matemática.
TweetSent-Br: composto por tweets, voltado especificamente para tarefas de análise de sentimentos. O dataset é organizado em três classes principais de avaliação: positivo (tweets que expressam uma reação ou avaliação positiva em relação ao tópico principal da postagem), negativo (tweets que expressam uma reação ou avaliação negativa sobre o tema central) e neutro (tweets que não se enquadram nas categorias anteriores).
IMDB: composto por críticas de filmes escritas em português brasileiro, esse benchmark também se concentra em tarefas de classificação de sentimentos, mas utiliza textos originados de resenhas mais completas, ao contrário do TweetSent-Br, que usa publicações breves.

Em relação aos modelos, a seleção foi guiada pela compatibilidade com a infraestrutura de execução disponível e com base na relevância de citações e performance. Estes incluem os modelos da família Granite, desenvolvidos pela IBM; os modelos Llama, da Meta; e o DeepSeek-R1-Distill-Llama-8B, uma versão compacta e otimizada derivada do Llama 3.1. Essa escolha permitiu uma comparação justa e viável entre os modelos.

Resultados

A seguir, apresentamos os resultados obtidos, acompanhados de gráficos desenvolvidos pela equipe, com o objetivo de facilitar a visualização e compreensão do desempenho dos modelos nas tarefas avaliadas.

ENEM Challenge:

Gráfico dos resultados no ENEM Challenge

Os resultados indicam que os modelos apresentaram desempenhos semelhantes, com uma leve vantagem para o Llama. Os modelos alcançaram uma média de acerto de 62,53%, esse percentual sugere que, embora os modelos demonstrem algum nível de compreensão das questões, ainda não possuem aptidão suficiente para responder de forma satisfatória às provas do ENEM, ou seja, para selecionar a alternativa correta. Há, portanto, um espaço para melhorias, especialmente no que diz respeito à capacidade de raciocínio e interpretação em língua portuguesa.

TweetSent-Br:

Gráfico dos resultados no TweetSent-Br

Nesse benchmark, assim como observado no ENEM Challenge, os resultados também foram semelhantes entre os modelos. Isso reforça a percepção de que ainda existem lacunas no desempenho dos modelos em tarefas relacionadas à classificação de sentimentos em português. Classificar uma mensagem como positiva, negativa ou neutra ainda representa um desafio para esses modelos, especialmente diante das nuances e ambiguidades da linguagem.

IMDB:

Gráfico dos resultados no IMDB

No IMDB os resultados foram bastante positivos, os modelos apresentaram taxas de acerto superiores a 90%, demonstrando boa performance na tarefa de classificação de sentimentos. O destaque foi o modelo Granite com 8B de parâmetros, que teve uma leve superioridade em relação aos demais. Esses resultados indicam que os modelos conseguem categorizar com facilidade as críticas de filmes em português, mostrando maior domínio nesse tipo de tarefa.

Conclusão

Com este estudo, foi possível obter uma visão mais clara sobre o desempenho dos modelos de linguagem em PT-BR, por meio da avaliação em três benchmarks distintos. Os resultados indicam que os modelos analisados possuem desempenho razoável ao selecionar uma alternativa para áreas do conhecimento do ENEM, e evidenciam que ainda há espaço para melhorias. Por outro lado, em tarefas de análise de sentimentos no benchmark IMDB, os modelos de pequeno porte demonstraram boa capacidade de classificação.

A equipe planeja, em estudos futuros, conduzir experimentos com modelos de grande porte, a fim de possibilitar comparações mais amplas de desempenho e eficiência. Isso permitirá uma análise detalhada dos erros cometidos por cada modelo, contribuindo para uma compreensão mais aprofundada de seus pontos fortes e limitações.

Realizando Inferências em CPU na Power10

Sun, 06 Apr 2025 00:00:00 +0000

Contexto

Neste post iremos apresentar a nossa experiência em executar o modelo Granite-20b-Code-Instruct em uma máquina Power10, apresentando os desafios e demais configurações necessárias para realizar inferências utilizando o Llama.cpp, uma das bibliotecas opensource mais populares neste domínio.

TL;DR

Este post apresenta detalhes sobre como configurar e realizar inferências utilizando a infraestrutura da IBM Power 10;
Nosso maior desafio foi a configuração do Llama cpp, que demandou ajustes como a instalação do Ninja-builder, realização da compilação do OpenBLAS e atualização do compilador C.

Infraestrutura

As inferências foram realizadas em uma máquina com arquitetura IBM POWER10, equipada com 750 GB de memória RAM e executando o sistema operacional Red Hat Enterprise Linux 8.10. O acesso ao ambiente é realizado por meio de uma VM, sendo necessário o uso de uma VPN para estabelecer uma comunicação segura e controlada com o sistema, possibilitando a execução das atividades de forma remota e eficiente.

Setup Inicial

A biblioteca que nos permite executar LLMs utilizando os recursos computacionais da CPU é o Llama.cpp. Para a sua configuração, foi necessário resolver duas dependências externas: o Ninja-builder e o OpenBLAS. O NinjaBuilder é responsável por otimizar o processo de compilação, enquanto o OpenBLAS é uma biblioteca responsável pelos cálculos matriciais de alto desempenho.

Durante o processo de build do OpenBLAS, identificamos discrepâncias nos testes internos de validação dos cálculos matriciais, indicando um problema de compatibilidade com o compilador C disponível, que estava em uma versão mais antiga, a 8.5.0. A solução, portanto, foi a atualização do compilador para uma versão mais recente, a 13.2, garantindo melhor compatibilidade com a arquitetura Power10 e validando a precisão das operações numéricas necessárias para o funcionamento do Llama.cpp. A seguir, apresentamos o passo a passo realizado para viabilizar a compilação das bibliotecas necessárias, bem como a atualização do compilador C.

Criando o ambiente de compilação para o builder

sudo dnf update -y && dnf -y groupinstall 'Development Tools' && dnf install -y \ cmake git ninja-build-debugsource.ppc64le \ && dnf clean all

Atualizando compilador C e definindo variáveis de ambiente

scl enable gcc-toolset-13 bashexport CC=/usr/bin/gcc-13export CXX=/usr/bin/g++-13

Baixando e compilando o OpenBLAS

git clone --recursive https://github.com/DanielCasali/OpenBLAS.git && cd OpenBLAS && \ make -j$(nproc --all) TARGET=POWER10 DYNAMIC_ARCH=1 && \ make PREFIX=/opt/OpenBLAS install && \ cd /

Baixando e compilando o Llama.cpp usando a biblioteca OpenBLAS que acabamos de baixar

 git clone https://github.com/DanielCasali/llama.cpp.git && cd llama.cpp && sed -i "s/powerpc64le/native -mvsx -mtune=native -D__POWER10_VECTOR__/g" ggml/src/CMakeLists.txt && \ mkdir build; \ cd build; \ cmake -DGGML_BLAS=ON -DGGML_BLAS_VENDOR=OpenBLAS -DBLAS_INCLUDE_DIRS=/opt/OpenBLAS/include -G Ninja ..; \ cmake --build . --config Release

Com todos esses passos realizados com sucesso, o ambiente foi devidamente configurado e otimizado para a execução local do Llama.cpp. Agora, somos capazes de iniciar um servidor para realizar inferências com LLM’s de forma eficiente, utilizando exclusivamente os recursos da CPU.

Realizando Inferência

Nós escolhemos o modelo Granite-20b-code-instruct no formato .GGUF, que é desenvolvido especificamente para otimizar o desempenho de modelos de linguagem em ambientes que utilizam apenas CPU. Esses modelos são quantizados, ou seja, a precisão dos cálculos feitos por eles são reduzidas, e, por conseguinte, o tamanho e consumo de memória também são menores, tornando-os ideais para a execução eficiente com Llama.cpp. Essa abordagem viabiliza inferências locais com alto desempenho, mesmo em arquiteturas baseadas exclusivamente em processadores, como é o caso da POWER10.O download do modelo foi feito diretamente do Hugging Face. A seguir, mostraremos o passo a passo para realizar o download:

Criar um diretório para o modelo no Llama.cpp:

mkdir -p /root/llama.cpp/models/granite-20b-code-instruct-8k-GGUF

Acessar o diretório no Llama.cpp:

cd /root/llama.cpp/models/granite-20b-code-instruct-8k-GGUF

Baixar o modelo via Hugging Face:

wget https://huggingface.co/ibm-granite/granite-20b-code-instruct-8k-GGUF/resolve/main/granite-20b-code-instruct.Q4_K_M.gguf

O último passo pode ser mais demorado a depender da quantidade de parâmetros do modelo. Todavia, após concluir os passos acima, podemos subir um servidor Llama.cpp para que seja possível realizarmos inferências, por padrão, o servidor é exposto na porta 8080 da Power10, mas isso é completamente customizável. O código a seguir ilustra como configurar e executar o servidor Llama:

/root/llama.cpp/build/bin/llama-server --host 0.0.0.0 --model /root/llama.cpp/models/granite-20b-code-instruct-8k-GGUF/granite-20b-code-instruct.Q4_K_M.gguf

Com o servidor do Llama.cpp executando na porta 8080, agora somos capazes de realizar inferências via requisições HTTP. Neste exemplo, para fins de simplicidade, utilizamos o curl para requisições:

curl -X POST http://localhost:8080/completion \ -H "Content-Type: application/json" \ -d '{ "prompt": "Make a hello world program in Java. Your answer should be in Java code only.", "max_tokens": 100 }'

A seguir, um exemplo de como a resposta é retornada:

{ "content": "public class HelloWorld { public static void main(String[] args) { System.out.println("Hello, World!"); }}

Com isso, agora somos capazes de realizar inferências em CPU. Nossos próximos passos visa realizar essas inferências utilizando o Framework de avaliação HELM (Holistic Evaluation of Language Models) como mediador.

Introdução

Wed, 12 Mar 2025 00:00:00 +0000

Bem-vindo ao blog da parceria entre a Universidade Federal de Campina Grande (UFCG) e a IBM!

Este espaço reúne artigos, tutoriais e resultados de pesquisa produzidos pela nossa equipe ao longo de diferentes projetos. Cada projeto aborda uma área de investigação distinta:

LLM Evaluation — avaliação de modelos de linguagem de grande porte, com foco em benchmarks para o português brasileiro.
AgentOps — criação de agentes de inteligência artificial capazes de executar múltiplas tarefas de forma autônoma.
Judo-AI — uso de modelos de IA para análise de partidas e sessões de treinamento de judô, usando técnicas de visão computacional e deep learning para detecção de movimentos e reconhecimento de ações.
5G — interação de técnicas de IA em ambientes de rede 5G, com controle inteligente, otimização e mecanismos de gestão de rede.
MultiArq — provisão de ferramentas comuns para novas arquiteturas (ppc64le), buscando e adaptando ferramentas específicas e criando documentações técnicas acerca da arquitetura.

Explore os posts e acompanhe as novidades!

Benchmark on IBM UFCG

Inferência de LLMs com Ollama na IBM Power9 Utilizando CPU

Contexto

TL;DR

Ambiente utilizado

Setup inicial

Configuração do Go

Caso não esteja instalado:

Configuração do Cmake

Caso não esteja instalado:

Configuração do GCC

Caso não esteja instalado:

Clonando o Ollama

Build do Ollama

Realizando a Inferência

Baixar o modelo de teste e executar a inferência

Considerações Finais

Próximos Passos

Virtualização em Power9: como estruturamos um ambiente isolado com KVM e Libvirt

Contexto

Fluxo de comunicação entre Hardware (Power9) e Máquinas Virtuais

TL;DR

Ambiente utilizado

Instalando o ambiente de virtualização (KVM + Libvirt)

Setup

Imagens prontas com drivers NVIDIA

Avaliação de Modelos IBM Granite para Tarefas de Geração de Código no HumanEvalX

Contexto

Metodologia / Processo

Resultados e Conclusões

1. O granite-4.0-h-small se destacou pela versatilidade

2. O Granite Micro (3B) apresentou performance acima do esperado

3. A progressão de tamanhos (350M → 1B → 3B → 7B → 30B) mostra evolução gradual e coerente

4. A comparação entre provedores ajuda a contextualizar os resultados

Próximos Passos

Contaminação por dados de Benchmark em LLMs: Fundamentos, Causas e Estratégias de Detecção

Contexto

TL;DR

Impactos da contaminação

Causas da contaminação por dados de benchmark

Categorias e níveis de contaminação

Metodologias de detecção

Metodologias de detecção direta

Metodologias de detecção indireta

Ferramentas auxiliares na detecção de contaminação

Conclusão

Referências

Computação@UFCG lidera contribuições do Brasil ao framework HELM-Stanford em parceria com a IBM

API de inferência de Modelos de Linguagem no servidor Power9 IBM

Contexto

TL;DR

Apresentando a API

Visão Geral da Arquitetura

Principais Funcionalidades

Fluxo de Uso

Entradas e Endpoints

Como usar a API com Python

Gerar API Key

Carregar Modelo

Gerar Texto

Consultar status e descarregar o modelo

Como usar a API com curl em CLI

Gerar API Key

Carregar Modelo

Gerar Texto

Consultar status e descarregar o modelo

Construindo API para inferências de LLMs em um servidor IBM Power9

Contexto

TL;DR

Configuração do Ambiente

Estrutura de Diretórios

Arquivo requirements.txt

Arquivo de Armazenamento de API Keys

Schemas e validação de dados

Autenticação e API Keys

Gerenciador de Modelos e GPU

Endpoints da API FastAPI

Arquivo utils.py

Executando a API

Configurando Conda e PyTorch em um servidor IBM Power9

Arquivo `requirements.txt`

Arquivo `utils.py`