Docker on IBM UFCG

Executando VMs com KubeVirt na IBM Power9 (ppc64le)

Fri, 22 May 2026 00:00:00 +0000

Contexto

Este post tem como objetivo apresentar o processo de adaptação do KubeVirt para a arquitetura IBM POWER9 (ppc64le). Serão abordados os principais desafios encontrados, as modificações realizadas no código-fonte, o papel de cada componente e os resultados obtidos ao final do processo.

O KubeVirt é um operador que estende o Kubernetes para gerenciar máquinas virtuais (VMs) como recursos nativos. Em ambientes tradicionais, VMs são gerenciadas por ferramentas como libvirt/virsh, separadas do ecossistema de containers. O KubeVirt elimina essa separação: com ele, é possível criar, iniciar, parar e monitorar VMs usando os mesmos comandos e workflows do Kubernetes — kubectl, YAML, namespaces e RBAC. As VMs rodam como processos QEMU/KVM reais dentro de pods gerenciados pelo Kubernetes.

A motivação para este trabalho surgiu no contexto do projeto Multiarq, que mantém uma infraestrutura compartilhada de HPC na IBM POWER9. A possibilidade de gerenciar VMs e containers no mesmo cluster Kubernetes simplifica a administração do ambiente e abre caminho para cenários como GPU passthrough para workloads de AI/ML dentro de VMs, isolamento de ambientes de pesquisa e testes de compatibilidade multi-arquitetura.

O principal desafio é que o KubeVirt não oferece suporte oficial para ppc64le. Apenas x86_64 (amd64), arm64 e s390x são suportados. Isso significa que o sistema de build, as validações da API, os defaults de configuração e o pipeline de geração de domínios libvirt não reconhecem ppc64le, tratando tudo como amd64 por padrão.

TL;DR

O KubeVirt não suporta ppc64le oficialmente; todo o pipeline assume amd64 como fallback.
Compilamos os binários Go diretamente, contornando o sistema de build Bazel que não reconhece a arquitetura.
Foram necessários patches em ~14 arquivos Go e a criação de 4 arquivos novos para adicionar suporte a ppc64le.
As imagens Docker foram criadas com Dockerfiles customizados e servidas via registry local.
Com as adaptações, foi possível executar uma VM CirrOS ppc64le via KubeVirt no POWER9, gerenciada inteiramente pelo Kubernetes.

Ambiente de Execução

Arquitetura: Servidor IBM Power9 (ppc64le).
Sistema Operacional: AlmaLinux 8.10, binário compatível com RHEL 8.9/8.10.
GPUs: 4x NVIDIA Tesla V100-SXM2-16GB.
Docker: Docker CE 26.1.3.
Kubernetes: v1.35.0 via minikube v1.38.0 (driver docker, runtime containerd).
KubeVirt: v1.8.2.
Go: 1.24.9.

O que é o KubeVirt e como ele funciona

O KubeVirt é composto por vários componentes que trabalham juntos para traduzir um recurso Kubernetes (a VirtualMachineInstance, ou VMI) em uma VM QEMU/KVM real rodando no host.

O virt-operator é o ponto de entrada: quando o administrador cria o Custom Resource KubeVirt no cluster, o operator provisiona todos os outros componentes — deployments, daemonsets, services, RBAC. Ele funciona como um instalador permanente que reconcilia o estado desejado.

O virt-api recebe as chamadas da API do Kubernetes para os recursos do KubeVirt. Quando o usuário faz kubectl apply de uma VMI, o virt-api valida o YAML (ex: a arquitetura é suportada? o machine type existe?) e injeta defaults (ex: firmware UUID, CPU topology).

O virt-controller observa as VMIs e decide onde elas devem rodar. Ele cria um pod especial — o virt-launcher — no node adequado, com todas as configurações necessárias (volumes, devices, node selectors).

O virt-handler roda como DaemonSet (um por node) e é o agente local que faz a ponte entre Kubernetes e libvirt/QEMU. Quando o pod do virt-launcher aparece no node, o virt-handler lê a spec da VMI, gera o XML do domínio libvirt e instrui o libvirt a criar a VM. Também registra device plugins no kubelet (/dev/kvm, /dev/net/tun, /dev/vhost-net) para que os pods possam acessar os dispositivos necessários.

O virt-launcher é o pod que encapsula a VM. Cada VMI gera um pod dedicado com três containers: o compute (QEMU + libvirt), o guest-console-log e o container disk. Dentro do container compute, o processo QEMU roda a VM real — com seu próprio kernel, memória e CPU virtual.

O fluxo completo é:

kubectl apply → API Server → virt-api (valida, injeta defaults)
virt-controller detecta a VMI → cria o pod virt-launcher no node adequado
kubelet inicia o pod virt-launcher no node
virt-handler detecta o pod → lê a spec da VMI → gera XML libvirt → chama o libvirt
libvirt inicia o QEMU → VM roda dentro do pod

É importante ressaltar que a VM não vira um container — ela roda como um processo QEMU real dentro de um pod. O Kubernetes gerencia o ciclo de vida do pod, e o KubeVirt traduz entre os dois mundos.

Desafios e Adaptações

Sistema de Build

O sistema de build do KubeVirt utiliza Bazel, que não reconhece ppc64le. A função format_archname no script de build só aceita x86_64, aarch64 e s390x. A solução foi compilar os binários Go diretamente com go build, contornando o Bazel.

Uma dependência adicional é o libnbd: o virt-launcher requer a versão 1.18+, mas o AlmaLinux 8 só disponibiliza a 1.6. Foi necessário compilar o libnbd 1.20 do fonte. O componente container-disk é um programa C (não Go) que precisa de compilação estática para rodar em containers FROM scratch.

Validação da API

O webhook de validação do virt-api rejeita VMIs com arquitetura desconhecida. Sem o patch, uma VMI com architecture: ppc64le seria recusada antes mesmo de chegar ao scheduler. Foi necessário adicionar cases no admitter e criar uma função de validação específica para ppc64le.

Defaults de Configuração

O KubeVirt precisa saber qual machine type usar para cada arquitetura (ex: pc-q35 para amd64, virt para arm64). Para ppc64le, configuramos pseries como machine type padrão — o tipo de máquina virtual do POWER.

Geração do Domínio Libvirt

Este foi o desafio central. O KubeVirt converte a spec da VMI em um XML de domínio libvirt que o QEMU interpreta. Esse pipeline tem duas partes:

O arch-defaulter define valores padrão do OS type (arch e machine) no XML. Sem o patch, ele retornava x86_64 para ppc64le, fazendo o libvirt tentar criar uma VM x86 numa máquina POWER — resultando no erro No emulator found for arch 'x86_64'.

O converter é uma interface com ~12 métodos que definem comportamentos específicos de cada arquitetura: se precisa de USB, SMBIOS, PCIe placement, ROM tuning, etc. Existiam implementações para amd64, arm64 e s390x, mas não para ppc64le. O código caía no fallback converterAMD64, gerando configurações incompatíveis. Criamos o converterPPC64LE com valores adequados para POWER: sem USB, sem SMBIOS, sem PCIe placement, com VirtIO como modelo de disco.

Resolvido o converter, surgiu o erro de dispositivos USB: o pipeline de graphics/video não tinha case para ppc64le, fazendo o libvirt adicionar um video device VGA default que dependia de USB — mas o controller USB estava desabilitado (IsUSBNeeded: false). A solução foi adicionar um case ppc64le no configurador de video com virtio como dispositivo de vídeo, seguindo o mesmo padrão do s390x e arm64.

Por fim, o CPU model: o KubeVirt usa host-model como default, que não funciona em virtualização aninhada no POWER9. A solução foi especificar POWER9 como CPU model na VMI.

Imagens Docker

Sem Dockerfiles no projeto (tudo é gerado pelo Bazel), criamos Dockerfiles customizados para cada componente. Os componentes mais simples (virt-operator, virt-api, virt-controller, virt-exportproxy) usam ubi8/ubi-minimal como base. O virt-handler requer ferramentas de sistema adicionais. O virt-launcher é o mais complexo, com almalinux:8 como base e dependências de qemu-kvm, libvirt e o libnbd compilado. Um registry local (registry:2 na porta 5000) serve as imagens para o minikube.

Passo a Passo Técnico

Devido à grande quantidade de etapas envolvidas, o passo a passo com os procedimentos detalhados, incluindo todos os patches no código Go, Dockerfiles, comandos de compilação e configuração, está disponível neste link: guia-instalacao-kubevirt-ppc64le.

Resultados

Com todas as adaptações aplicadas, foi possível executar uma VM CirrOS ppc64le via KubeVirt no POWER9, gerenciada inteiramente pelo Kubernetes:

$ kubectl get vmi test-vmi -o wideNAME AGE PHASE IP NODENAME READYtest-vmi 2m43s Running 10.244.120.124 minikube True

Dados coletados de dentro da VM confirmam a execução correta:

	Valor
Arquitetura	ppc64le
CPU	POWER9 (architected), altivec supported
Hypervisor	KVM
Plataforma	pSeries
Modelo	IBM pSeries (emulated by qemu)
Kernel	5.15.0-71-generic ppc64le

Esses dados confirmam que o KubeVirt está gerando o domínio libvirt correto para ppc64le, com machine type pseries, CPU POWER9 e virtualização KVM/QEMU com paravirtualização VirtIO.

Considerações Finais

Com as adaptações realizadas, tornou-se possível utilizar o KubeVirt para criar e gerenciar máquinas virtuais em uma IBM POWER9 via Kubernetes. A VM executada é uma VM KVM/QEMU real — com kernel próprio, memória isolada e CPU virtual — gerenciada como qualquer outro recurso Kubernetes.

No contexto do projeto Multiarq, essa solução permite unificar a gestão de containers e VMs no mesmo cluster, simplificando a administração da infraestrutura compartilhada. Workloads que exigem isolamento de kernel ou acesso direto a hardware (como GPU passthrough) podem ser executados em VMs sem abandonar o ecossistema Kubernetes.

Os patches realizados são potencialmente contribuíveis ao projeto KubeVirt upstream. A arquitetura do KubeVirt já prevê extensibilidade por arquitetura — o padrão de interfaces (Converter, ArchDefaulter) e switches por arch facilita a adição de novas plataformas. O ppc64le segue o mesmo padrão do s390x, que também foi adicionado posteriormente ao projeto.

Próximos Passos

Resolver o conflito USB/Graphics para permitir VNC sem o workaround autoattachGraphicsDevice: false, habilitando acesso gráfico às VMs;
Ajustar o CPU model default no código para que ppc64le use POWER9 automaticamente, sem exigir especificação manual na VMI;
Explorar GPU passthrough das V100 via KubeVirt para executar workloads de AI/ML dentro de VMs gerenciadas pelo Kubernetes;
Testar outras distribuições como containerDisk (Fedora, Ubuntu Server, AlmaLinux ppc64le) para validar a compatibilidade além do CirrOS;
Configurar masquerade networking para habilitar live migration entre nodes;
Documentar as mudanças em formato de PR para contribuição ao KubeVirt upstream;
Validar o KubeVirt no Single Node OpenShift (OCP 4.21) já instalado na máquina, usando o OpenShift Virtualization como operador.

TensorFlow 2.21 CPU na IBM Power9 (ppc64le)

Mon, 04 May 2026 00:00:00 +0000

Contexto

O TensorFlow (TF) é o framework de machine learning mais adotado globalmente. No entanto, desde 2021, o Google encerrou o suporte oficial de binários pré-compilados para a arquitetura ppc64le, e o repositório comunitário tensorflow/community foi arquivado em 2025.

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 (Instalação do TF 2.14)

Como ponto de partida, validamos a instalação do TensorFlow 2.14.1 (via RocketCE) em uma VM IBM Power9 (arquitetura ppc64le) com AlmaLinux, usando Miniforge (conda). Seguem os comandos para a instalação:

conda create -n tf214 python=3.11 -yconda activate tf214conda install -c rocketce tensorflow-cpu=2.14.1 -y# saída esperada: 2.14.1python -c "import tensorflow as tf; print(tf.__version__)"

Como resultado, espera-se o TensorFlow 2.14.1 funcional. Essa mesma versão também está disponível nos canais Open-CE da Oregon State University e do MIT. Com o TF 2.14 funcionando, temos acesso ao: Keras, TensorBoard, TensorFlow Hub, tensorflow-text, Hugging Face Transformers, Jupyter, e todo o stack de ML clássico.

TF 2.14 vs TF 2.21 (o mais recente)

A versão 2.14 é funcional, mas está a algumas versões de distância da mais recente, a 2.21. As diferenças mais significativas se concentram na incompatibilidade com duas ferramentas muito importantes:

Keras 3: uma reescrita completa que transforma o Keras em um framework multi-backend, que permite rodar o mesmo modelo e o mesmo código em TensorFlow, PyTorch ou JAX sem qualquer alteração. O TF 2.14 dá suporte apenas ao Keras 2.
NumPy 2: Além de corrigir dezenas de inconsistências históricas da API, o NumPy 2.0 traz ganhos significativos de eficiência. O TF 2.14 não suporta o NumPy 2.

Compilando o TensorFlow 2.21 Nativamente no Power9 (CPU-Only)

Inicialmente, compilamos com sucesso o TensorFlow 2.21 (CPU-Only) diretamente a partir do código-fonte. Essa compilação foi realizada em uma VM IBM Power9 e gerou um pacote .whl nativo para linux_ppc64le. Em seguida, o TF 2.21 teve seu funcionamento validado através de uma suíte completa de testes. Este é um marco fundamental sobre o qual o suporte a GPU será construído na próxima etapa.

Desafios: Hermetismo e Dependência de x86

A arquitetura moderna do TensorFlow (e seu sistema de build, o Bazel 7) abraçou o modelo “Hermético”: forçando o uso de binários pré-compilados e lógicas atreladas às arquiteturas x86_64, aarch64 e aceleradores NVIDIA. Para ppc64le, isso significa que a compilação naive simplesmente falha ao tentar baixar ferramentas para arquiteturas incompatíveis.

Identificamos quatro categorias de bloqueio:

Bazel 7: O Google não distribui o Bazel 7 para PowerPC. Seria necessário compilá-lo do zero.
Toolchains herméticas: O TF 2.21 tenta baixar LLVM/Clang pré-compilado para x86 ou aarch64, que não executa no Power9.
Dependências CUDA/GPU: Mesmo em modo CPU-only, o sistema de build tenta baixar e vincular bibliotecas NVIDIA gigantes. Nossa estratégia foi isolar completamente o suporte a GPU com stubs vazios, garantindo uma fundação CPU-only estável antes de adicionar qualquer acelerador.
Bugs de C++ latentes: O código do XLA e do MLIR contém construções que funcionam no Clang do Google, mas quebram no GCC 8.5 padrão do sistema, de flags AVX-512 até ambiguidades de template em absl::NoDestructor.

Processo de Compilação

Etapa 1: Compilando o Bazel 7.1.0 do Zero

Como o Google não distribui o Bazel 7 para ppc64le, o primeiro passo para permitir seu uso em arquitetura ppc64le foi compilar o próprio Bazel a partir do seu código-fonte, usando o arquivo -dist.zip, que já inclui os artefatos de bootstrap necessários para que o Bazel se autoconstrua sem depender de uma versão anterior de si mesmo. O processo exige Java 21 e leva entre 1 e 2 horas dependendo dos núcleos disponíveis na VM. O ponto crítico aqui é passar as variáveis corretas para o script compile.sh. Sem esse passo, nenhuma das etapas seguintes é possível. O comando bazel build simplesmente não existe para ppc64le de outra forma. Criamos um tutorial com o processo de instalação do Bazel 7.1 que pode ser acessado no repositório.

Etapa 2: Estratégia de Bypass — Repositórios Stub

Com o Bazel 7 funcional em arquitetura ppc64le, atacamos o problema das dependências herméticas. Nossa solução foi criar repositórios “stub”, diretórios locais vazios que satisfazem as declarações de dependência do Bazel sem baixar nada:

LLVM stubs: Filesgroups vazios que satisfazem as regras de toolchain sem tentar instalar o LLVM.
CUDA/ROCm/TensorRT stubs: Bibliotecas C++ e regras Starlark vazias que permitem que o build prossiga sem erros de dependência faltante.
PyPI stubs: Módulos Python stub que simulam as dependências do pip hermético do Google, forçando o uso das bibliotecas do ambiente conda.
Python stub: Redireciona para o Python do nosso ambiente conda, contornando o download do Python hermético que não existe para ppc64le.

Todos os stubs são injetados via --override_repository na chamada do bazel build, sem alterar o código-fonte do TensorFlow.

Estratégia de Bypass - Repositórios Stub

Etapa 3: Patches Cirúrgicos no Código-Fonte

Com a infraestrutura de build resolvida, encontramos 21 incompatibilidades no código C++ e Python do TensorFlow que se manifestam exclusivamente na combinação GCC 13 + ppc64le. Os problemas se concentraram em três categorias:

Flags de compilação exclusivas do Clang que o GCC rejeita.
Ambiguidades de templates C++ em componentes do XLA e MLIR que o compilador do Google mascara mas o GCC 13 expõe.
Referências a headers de CUDA e TensorRT que deixam de existir quando substituídos pelos stubs.

Cada incompatibilidade foi resolvida com um patch Python preciso, sem alterar a lógica funcional do TensorFlow. A tabela completa com todos os 21 patches está disponível no repositório.

Etapa 4: A Compilação

Com todos os patches aplicados, a compilação final é disparada com um único comando bazel build. Além das flags de otimização padrão, o comando injeta todos os repositórios stub via --override_repository, totalizando cerca de 80 flags. O cache incremental do Bazel é fundamental aqui: cada vez que um patch é necessário e a compilação é retomada, apenas os alvos afetados são recompilados. Isso transformou o ciclo “patch → compilar → erro → patch” de inviável em gerenciável (cerca de 4 horas).

A Solução Definitiva: Pacote Conda e Binários (Pronto para Uso)

Para que a comunidade não precise refazer todo esse complexo processo de build, nós empacotamos o resultado dessa engenharia em uma solução “plug and play”.

Disponibilizamos uma Release oficial no repositório contendo o código-fonte já com todos os patches aplicados e o binário .whl gerado nativamente. Mais importante ainda: criamos e publicamos uma receita Conda completa que resolve de forma automática os clássicos problemas de compatibilidade de bibliotecas C++ (GLIBCXX e GCC mismatch) comuns no Power9.

Agora, o TensorFlow 2.21 nativo pode ser instalado diretamente através do nosso canal Conda, proporcionando a mesma experiência de instalação oficial de distribuições corporativas.

Como Instalar (Tutorial Rápido)

Para utilizar o TensorFlow 2.21 em seu ambiente Power9 imediatamente, basta executar:

conda create -n tf221 python=3.11 -yconda activate tf221conda install -c ufcg-ibm -c conda-forge tensorflow-cpu=2.21.0 -y

Um tutorial detalhado de instalação via Conda também está disponível no nosso repositório.

Resultado Funcional no servidor IBM Power9

Instalamos o pacote final e executamos uma suíte completa de 35 testes, cobrindo oito categorias funcionais: desde operações básicas com tensores até save/load de modelos e testes de stress. Todos os 35 testes passaram. O teste de stress (multiplicação de matrizes 5000×5000) executou com sucesso na CPU do IBM Power9, e o treinamento de um MLP por 20 épocas confirmou convergência de loss, indicando que diferenciação automática, otimizadores e operações numéricas estão todos funcionando corretamente de ponta a ponta.

Ferramentas IBM que usam TensorFlow

Ferramentas de IA da IBM como AIF360, AIX360 e ART, já eram compatíveis com o TensorFlow 2.14, pois são bibliotecas Python que utilizam o TF do ambiente sem acoplamento binário. O valor real do TensorFlow 2.21 compilado nativamente para Power9 está na continuidade: essas bibliotecas já começavam a declarar dependências em versões de TF superiores ao 2.14, o que significava que, sem esse build, o ambiente no Power9 ficaria preso em versões antigas e sem suporte. Além disso, as melhorias acumuladas no TF entre as versões 2.14 e 2.21 trazem ganhos incrementais de desempenho para os pipelines de análise de fairness, explicabilidade e robustez adversarial.

Reprodutibilidade e Materiais

Todo o processo e os artefatos gerados estão documentados e disponíveis em nosso repositório:

Release oficial: Código-fonte alterado e o binário .whl pronto.
tutorial_instalacao_conda.md: Guia prático para instalar a versão 2.21 diretamente pelo nosso canal Conda.
tutorial_bazel7_power9.md: Compilação do Bazel 7.1.0 a partir do código-fonte.
tutorial_tf221_power9.md: Compilação do TensorFlow 2.21 com todos os patches.

Impacto

Esta compilação representa a versão mais recente do TensorFlow disponível nativamente para ppc64le e com ela:

Keras 3 fica disponível para ppc64le pela primeira vez.
NumPy 2.0 deixa de ser um gargalo para o ecossistema científico Python no IBM Power9.
Stack Hugging Face Transformers com mais modelos compatíveis com a Power9.

Próximos Passos

O TF 2.21 que compilamos roda exclusivamente em CPU. O próximo desafio é repetir o processo com CUDA habilitado em servidores IBM Power9 equipados com GPUs NVIDIA. Os stubs que criamos para isolar a GPU nesta compilação foram projetados justamente para facilitar essa transição: ao substituí-los pelas bibliotecas CUDA reais, teremos um ponto de partida sólido para a compilação GPU. Se bem-sucedido, o Power9 passaria a ter o framework de deep learning mais recente com aceleração de hardware, algo inexistente hoje em qualquer distribuição para ppc64le.

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

Thu, 16 Apr 2026 00:00:00 +0000

Contexto

Este é o segundo post da série sobre inferência de modelos de linguagem na POWER9 com o Ollama. Neste post, abordaremos como enviar requisições utilizando GPU, obtendo um ganho significativo de desempenho em relação à abordagem via CPU apresentada no post anterior.

O principal desafio é que o Ollama não oferece suporte oficial para a arquitetura ppc64le com CUDA. A solução encontrada foi através de um blog da comunidade oficial IBM, onde um contribuidor disponibilizou um fork do Ollama adaptado para suportar GPUs NVIDIA na POWER9 via CUDA. No entanto, esse fork está desatualizado e não suporta modelos mais recentes como Gemma 3 e DeepSeek.

Por isso, desenvolvemos um fork atualizado, baseado no Ollama oficial (v0.23.2), com os patches necessários para ppc64le e suporte a GPU via CUDA. Este tutorial explica como compilar o Ollama para a arquitetura ppc64le, e para quem não quiser compilar, também disponibilizamos um binário pré-compilado nas releases no GitHub.

TL;DR

Este post apresenta detalhes sobre a configuração do ambiente para realizar inferências utilizando a infraestrutura da IBM POWER9;
O Ollama não oferece suporte oficial para ppc64le com CUDA;
O fork foi compilado do zero utilizando CMake e Go, apontando para CUDA 12.2 e especificando a arquitetura do V100 (sm_70);
Um binário pré-compilado também está disponível no github do projeto;
Com isso, foi possível executar inferência de LLMs na IBM POWER9 com aceleração GPU e suporte para modelos recentes.

Ambiente utilizado

Hardware:

Arquitetura ppc64le;
RAM: mínimo recomendado de ~64GB;
GPU: NVIDIA Tesla V100;
Driver NVIDIA: 535.54.03;
CUDA: versão 12.2.

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

Verificações iniciais

Verificar se o driver e a GPU estão visíveis

nvidia-smi

Verificar se o CUDA está instalado

nvcc --version

OBS: Se não aparecer nada, tente:

export PATH=/usr/local/cuda-12.2/bin:$PATHexport CUDACXX=/usr/local/cuda-12.2/bin/nvcc

Verifique também se o CUDA 12 existe:

ls -la /usr/local/cuda-12

Execução em Ambiente Virtual

Neste tutorial, estamos fazendo as configurações necessárias em um ambiente virtual para isolar o ambiente de execução e as configurações utilizadas. Essa execução é opcional, mas recomendada.

conda create -n ollamaGPU python=3.11 -yconda activate ollamaGPU

Para desativar o ambiente:

conda deactivate

Setup inicial

Para compilar o Ollama na POWER9, são necessárias as seguintes dependências com as versões adequadas:

Go: 1.26.0
GCC: 11.2.1 (via gcc-toolset-11)
CMake: >= 3.24

Clonando e compilando o Ollama

Com o ambiente configurado, podemos realizar o build do Ollama. A compilação utiliza CMake para gerar os kernels CUDA com nvcc, e Go para compilar o binário. Um detalhe importante é o parâmetro CUDA_ARCHITECTURES=70: cada GPU NVIDIA possui uma arquitetura específica identificada por um código sm_XX, e o V100 é da arquitetura Volta (sm_70). Especificando esse valor, instruímos o build a compilar apenas para o V100, reduzindo o tempo de compilação.

O passo a passo completo de compilação, incluindo os fixes necessários para ppc64le, além da instalação e configuração das dependências mencionadas anteriormente, está documentado no README do repositório.

Para quem não quiser compilar, um binário pré-compilado está disponível diretamente na página de releases:

# Baixe o bináriowget https://github.com/llm-pt-ibm/ollama-ppc64le/releases/download/v0.23.2-ppc64le-power9/ollama-ppc64le# Dê permissão de execuçãochmod +x ollama-ppc64le

Nota: O repositório contém as branches do Ollama oficial. Os patches para ppc64le estão exclusivamente na branch ollama-ppc64le.

Realizando a inferência

Com o Ollama compilado, podemos iniciar o servidor:

./ollama serve

Para verificar se deu certo, digite o comando: ps aux | grep ollama.

Aguarde alguns segundos e verifique os logs para confirmar que o servidor detectou as GPUs corretamente. Procure por estas linhas:

inference compute ... library=CUDA compute=7.0 ... description="Tesla V100-SXM2-16GB" total="16.0 GiB"

Baixar o modelo de teste e executar a inferência

Para validação, utilizamos o modelo llama3.1:8b. Para isso, em outro terminal, rode:

./ollama pull llama3.1:8b

Para executar a inferência:

./ollama run llama3.1:8b "me fale todos os números ímpares até 100"

Confirmar o uso da GPU

Em outro terminal, com a inferência em execução, rode:

nvidia-smi

Na seção de processos, você deve ver o ollama com memória alocada em uma das GPUs:

Ollama usando a GPU

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 as GPUs NVIDIA Tesla V100. Com essa abordagem, a inferência de modelos possui um ganho de desempenho significativo em relação à execução via CPU. Utilizando o modelo Meta Llama 3.1 8B Instruct como referência, a execução via GPU atingiu uma maior geração de tokens por segundo em relação à execução via CPU.

Vejamos os dados coletados para uma mesma requisição (Me fale todos os números ímpares até 100) com os dois tipos de execução:

	CPU	GPU
Taxa de geração de tokens	0.71 tokens/s	79.82 tokens/s
Duração total	3m49s	4.52s
Taxa de avaliação do prompt	10.67 tokens/s	295.77 tokens/s

Com os dados apresentados na tabela, percebemos que a execução com GPU foi aproximadamente 112 vezes mais rápida na geração de tokens, com o tempo total de resposta reduzido de 3 minutos e 49 segundos para 4.52 segundos.

Próximos Passos

Avaliar a execução com GPU e CPU em um post comparativo e com outras arquiteturas;
Testar a inferência em GPU com modelos maiores, com mais de 8 bilhões de parâmetros, por exemplo;
Testar novos modelos disponíveis no fork atualizado, como Gemma 3 e DeepSeek;

Inferência de LLMs com vLLM Utilizando GPU em Power9

Fri, 10 Apr 2026 00:00:00 +0000

Contexto

Este post tem como objetivo apresentar os passos necessários para instalar o vLLM em um ambiente IBM POWER9 (arquitetura ppc64le). Serão detalhados os principais recursos necessários, modificações, dependências, versões utilizadas e etapas de instalação necessárias para executar inferências com um determinado modelo.

O vLLM é uma ferramenta voltada para serving e inferência eficiente de modelos de linguagem de grande porte (LLMs), permitindo disponibilizar modelos por meio de uma API e executar inferências de forma otimizada, especialmente em ambientes com GPU.

A necessidade de instalar o vLLM surgiu durante o processo de geração de dados com a ferramenta InstructLab. Nesse fluxo, é necessário utilizar um modelo professor para gerar dados sintéticos que serão posteriormente utilizados no treinamento ou refinamento de outros modelos. Para isso, é possível utilizar ferramentas como llama-cpp, já compatível com o ambiente IBM POWER9, ou o vLLM, que ainda não estava disponível devido a dificuldades relacionadas à instalação nesta arquitetura. Diferentemente do llama-cpp, que é mais voltado para execução local e cenários de menor escala, o vLLM se destaca pelo melhor aproveitamento de GPU e pela capacidade de atender múltiplas requisições simultaneamente de forma eficiente, sendo mais adequado para cenários de inferência em larga escala e ambientes de produção.

Dessa forma, apresentaremos os passos técnicos necessários para viabilizar a instalação do vLLM no ambiente IBM POWER9 (ppc64le), descrevendo as adaptações realizadas para que a ferramenta funcione corretamente nesse contexto.

TL;DR

Compilação e instalação do LLVM, necessário como infraestrutura de compilação para dependências subsequentes.
Compilação e adaptação do Triton, incluindo ajustes para compatibilidade com a arquitetura Power9.
Instalação e configuração do vLLM, considerando suas dependências e requisitos específicos de execução.
Desenvolvimento de containers contendo todo o ambiente configurado para execução da ferramenta.
Demonstração prática do uso das imagens, incluindo a inicialização do servidor e a realização de inferências utilizando GPU.

Ambiente de Execução

O ambiente utilizado para a instalação do vLLM inclui:

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.
GPUs: 4x NVIDIA Tesla V100 SXM2 16GB (NVLink2).

Dependências e Instalação

Durante o processo de build do vLLM, destacam-se três dependências principais: LLVM, Triton e PyTorch. Essas dependências são problemáticas para o funcionamento correto da ferramenta.

O LLVM constitui a base da infraestrutura de compilação utilizada ao longo de todo o processo, sendo responsável pela geração, otimização e transformação de código intermediário em código de baixo nível executável. No contexto do vLLM, sua função é essencial para viabilizar a execução eficiente de kernels em GPU, especialmente aqueles definidos pelo Triton, que dependem diretamente de seus backends de compilação (componentes responsáveis por gerar código otimizado para diferentes arquiteturas de hardware). O Triton, por sua vez, atua como o componente responsável pela definição e execução de kernels otimizados para GPU, desempenhando um papel central na eficiência da inferência de modelos de linguagem. Sua integração com o LLVM permite a geração de código altamente otimizado para diferentes arquiteturas. Já o PyTorch fornece a base para a manipulação de tensores e execução dos modelos de linguagem, oferecendo as operações fundamentais para inferência em GPU, além de servir como interface com os mecanismos de aceleração e bibliotecas de baixo nível.

Fluxo de Dependências para compilar vLLM na Power9.

Devido à ausência de suporte nativo desses pacotes para a arquitetura ppc64le, sua utilização na IBM POWER9 exigiu a realização de diversas adaptações a partir dos repositórios oficiais dessas ferramentas. Essas modificações envolveram desde a correção de incompatibilidades em métodos específicos até ajustes em subdependências que não possuíam suporte para a arquitetura ppc64le, além do uso do Conda para auxiliar na gestão de ambientes e dependências. Em alguns casos, também foi necessária a compilação manual de componentes adicionais. Após a superação desses desafios, tornou-se possível instalar e executar o vLLM no ambiente IBM POWER9.

Devido à grande quantidade de etapas envolvidas, o passo a passo com os procedimentos detalhados são apresentados neste link: guia-instalacao-vllm. Ressalta-se que cada um dos passos descritos é essencial para garantir a correta compilação e execução do vLLM no ambiente proposto.

Conteinerização

Durante o processo de instalação, observou-se que a grande quantidade de etapas envolvidas poderia dificultar a reprodução do ambiente e levar à cenários inconsistentes. Diante disso, optamos pela conteinerização da solução como forma de tornar o experimento reprodutível, portátil e mais simples de ser utilizado por outros usuários.Para isso, disponibilizamos (neste repositório) scripts responsáveis tanto pela construção das imagens quanto pela automação da execução, organizando todas as etapas necessárias. Esses scripts realizam tarefas como a identificação dos recursos disponíveis, cópia dos binários CUDA necessários e a inicialização do vLLM de forma adequada.

A execução foi simplificada de forma que é necessário que o usuário apenas informe o caminho local do modelo a ser utilizado. Parâmetros como porta, quantidade de GPUs e imagem a ser executada são opcionais, possuindo valores padrões previamente definidos.

Repositório desenvolvido para execução do vLLM via containers.

Além disso, disponibilizamos um vídeo (demonstração do vLLM no Power9) que demonstra o uso do vLLM a partir do repositório disponibilizado.

Considerações Finais

Com os recursos disponibilizados neste repositório, tornou-se possível automatizar o processo de instalação e utilização do vLLM em arquiteturas ppc64le com GPUs V100.

No contexto do projeto IBM-MultiArq, essa solução se mostra especialmente relevante para a utilização do InstructLab, permitindo a execução local de modelos professores por meio do vLLM, ampliando as possibilidades de experimentação e desenvolvimento dentro do ambiente proposto.

Próximos Passos

Como continuidade deste trabalho, propõe-se a realização de um estudo comparativo de desempenho entre o llama-cpp e o vLLM. Além disso, o repositório foi estruturado para oferecer suporte contínuo ao vLLM, incluindo sua adaptação a versões futuras, a identificação de limitações ainda existentes e a evolução das soluções à medida que novos desafios surgirem.

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.

Instalação do Docker em ambiente Arquitetura ppc64le (Power9)

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

Contexto

Diante da necessidade de padronizar a execução de softwares no nosso servidor IBM Power9 (ppc64le), o uso de contêineres apresenta-se como uma solução robusta para evitar conflitos de ambiente. Este post dá continuidade à estruturação da nossa infraestrutura, detalhando a instalação do Docker Engine no AlmaLinux. A adoção desta tecnologia é estratégica para garantir o isolamento rigoroso de dependências e a portabilidade das diversas aplicações. Com isso, conseguimos encapsular desde bibliotecas de uso geral até serviços mais complexos, assegurando um ambiente de execução limpo, seguro e altamente reprodutível.

O Docker Engine tem suporte oficial para AlmaLinux nas arquiteturas x86_64, arm64, s390x e ppc64le, o que nos permite utilizá-lo diretamente no Power9 sem adaptações especiais. No entanto, alguns cuidados são necessários antes e durante a instalação, como desinstalar ferramentas que conflitam com o Docker e garantir que as imagens utilizadas sejam compatíveis com a arquitetura ppc64le.

TL;DR

Este post apresenta o passo a passo para instalar o Docker Engine no AlmaLinux na arquitetura ppc64le.
É necessário remover o Podman e o Buildah antes de instalar, pois conflitam com o Docker.
Imagens do Docker Hub precisam ter suporte explícito a ppc64le para funcionar no Power9.

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

Pré-requisitos

Antes de instalar o Docker, é importante estar ciente de uma limitação relacionada ao firewall: ao expor portas de contêineres usando o Docker, essas portas ignoram as regras padrão do firewalld. Certifique-se de que isso não representa um problema para o seu ambiente antes de prosseguir. Além disso, é importante destacar que o Docker Engine é compatível com Rocky Linux 8 e 9 e o AlmaLinux 8 na arquitetura ppc64le.

Removendo pacotes conflitantes

O AlmaLinux, por padrão, possui o Podman e o Buildah instalados. Esses pacotes conflitam com o Docker Engine e precisam ser removidos antes da instalação. Também é recomendável remover quaisquer versões antigas do Docker que possam estar presentes:

sudo dnf remove -y podman \ buildah \ docker \ docker-client \ docker-client-latest \ docker-common \ docker-latest \ docker-latest-logrotate \ docker-logrotate \ docker-engine

Adicionando repositório do Docker e instalando pacotes necessários

Configuração do repositório

O método recomendado de instalação é utilizar o repositório oficial do Docker. Vale mencionar que o Docker utiliza o repositório do CentOS para distribuições baseadas em RHEL — como o AlmaLinux — e isso é oficialmente suportado. Primeiro, instale o pacote dnf-plugins-core e adicione o repositório:

sudo dnf install -y dnf-plugins-coresudo dnf config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

Instalando o Docker Engine

Com o repositório configurado, instale a versão mais recente do Docker Engine junto com os plugins de build e compose:

sudo dnf install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Iniciando o serviço

Diferentemente de distribuições baseadas em Debian, como o Ubuntu, o Docker não inicia automaticamente no AlmaLinux após a instalação. É necessário iniciar o serviço manualmente e habilitá-lo para que suba junto com o sistema:

sudo systemctl start dockersudo systemctl enable docker

Verificando a instalação

Para confirmar que tudo foi instalado corretamente, execute a imagem hello-world. O Docker detectará automaticamente a arquitetura ppc64le e baixará a imagem correta:

sudo docker run hello-world

A saída esperada é uma mensagem que confirme que o Docker está funcionando corretamente.

Configurações pós-instalação

Por padrão, apenas o usuário root ou usuários com privilégios de sudo podem executar comandos do Docker. Para evitar o uso de sudo em todo comando, adicione seu usuário ao grupo docker. Primeiro, crie o grupo caso ele não exista:

sudo groupadd docker

Em seguida, adicione seu usuário ao grupo:

sudo usermod -aG docker $USER

É necessário deslogar e logar novamente para que as permissões sejam aplicadas.

Dicas para arquitetura Power9

Como estamos utilizando o IBM Power9, alguns cuidados adicionais são importantes ao trabalhar com o Docker Hub. O primeiro ponto é a compatibilidade de imagens: nem todas as imagens disponíveis no Docker Hub possuem suporte a ppc64le. Imagens exclusivas para x86_64 resultarão em erro de execução no Power9, por isso sempre verifique se a imagem desejada possui a tag ppc64le antes de utilizá-la.

Para validar se o Docker está rodando corretamente e reconhecendo a arquitetura da máquina, use:

docker version --format '{{.Server.Arch}}'

A saída esperada é ppc64le.

Considerações finais

A instalação do Docker Engine no AlmaLinux (ppc64le) segue um fluxo direto, desde que os conflitos com o Podman e o Buildah sejam resolvidos previamente. O suporte oficial ao ppc64le pelo Docker garante uma experiência estável no Power9, com a ressalva de que a compatibilidade das imagens utilizadas deve ser sempre verificada antes do uso.

Com o Docker instalado e configurado, o ambiente está pronto para executar contêineres e avançar para as próximas etapas da nossa infraestrutura de modelos de linguagem.

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
InstructLab-Power9-0.25.0.qcow2.xz	AlmaLinux 8.10 + InstructLab 0.25.0 + dependências necessárias para execução no Power9 (ppc64le).

Como usar imagens pré-configuradas:

Baixe a imagem da pasta compartilhada e descompacte:

pip install --user gdowngdown --folder "https://drive.google.com/drive/u/1/folders/1WM8fHKWaMu-NJOzwqh6cdcET7mNE50du"xz -d InstructLab-Power9-0.25.0.qcow2.xz

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

cp InstructLab-Power9-0.25.0.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!