LLMs no GitLab CI: testes com GPU sem infraestrutura

Em 2025, muita equipa de engenharia já aceitou uma verdade desconfortável: o “hello world” de IA não chega à fábrica. O protótipo funciona no portátil, mas falha quando entra na realidade dos pipelines, da segurança, dos tempos de resposta e — sobretudo — da necessidade de reprodutibilidade. E é aí que a conversa deixa de ser “prompts” e passa a ser engenharia.

A boa notícia é que dá para trazer LLMs (modelos de linguagem) para um fluxo DevOps previsível usando uma peça que já existe no dia a dia de quem entrega software industrial: GitLab CI. A abordagem de “servir um LLM dentro do próprio pipeline”, através de GitLab CI services (com GPU quando necessário), reduz fricção, aumenta confiança nos testes e evita a dependência de endpoints externos.

Neste artigo — parte da série “IA na Energia e Sustentabilidade” — vou ligar os pontos entre esta prática de engenharia de software e o que realmente interessa em energia, utilities e indústria: eficiência energética, automação fiável e ciclos de melhoria contínua. Porque, no terreno, uma IA “quase certa” é um custo; uma IA testada e observável é um ativo.

Por que testar LLMs no CI virou requisito (não luxo)

Resposta direta: porque LLMs introduzem variabilidade e dependências externas que quebram a confiança num pipeline de entrega — e isso é fatal em sistemas industriais e energéticos.

Quando uma aplicação usa um LLM, o comportamento final depende de:

• versão do modelo (e até do quantization)
• parâmetros de geração (seed, temperatura, top-p)
• prompt e mensagens de sistema
• bibliotecas cliente, formato de saída e validação
• infraestrutura de inferência (CPU/GPU, memória, throttling)

Em energia e sustentabilidade, isto ganha peso. Exemplos típicos:

• Centros de despacho e operação a gerar relatórios de ocorrências e recomendações (com linguagem natural) precisam de consistência e auditoria.
• Gestão de manutenção (turbinas, subestações, linhas) usa LLMs para resumir históricos e sugerir ações — e erros aqui viram horas de indisponibilidade.
• Otimização de consumo em fábricas usa interfaces conversacionais para orientar ajustes em HVAC, compressores e linhas — e respostas erradas custam kWh e produção.

A minha posição é simples: LLM em produção sem testes de integração no CI é dívida técnica com juros altos.

A ideia central: usar GitLab CI Services para “subir” um LLM no pipeline

Resposta direta: em vez de chamar um endpoint externo (cloud) durante os testes, o pipeline inicia um “servidor de inferência” como service container e testa contra ele.

O GitLab CI tem um conceito muito útil: services. São contentores auxiliares que sobem ao lado do contentor principal do job. Muita gente já usa isso para PostgreSQL, Redis, Selenium/Playwright ou Docker-in-Docker.

A mesma lógica funciona para LLMs:

• o job de testes roda num contentor “normal” (Python, por exemplo)
• um serviço sobe um servidor de inferência (por exemplo, Ollama)
• os testes chamam a API HTTP do serviço dentro da rede do job

O ganho prático é grande:

• reprodutibilidade: o pipeline controla versão do servidor e do modelo
• isolamento: sem dependência de serviços externos para testes
• segurança: menos chaves/API tokens a circular
• velocidade de feedback: falhas são detectadas antes de chegar a ambientes industriais

Por que Ollama faz sentido aqui

Resposta direta: porque é um stack open-source para executar LLMs localmente e expor uma API HTTP simples.

O Ollama consegue:

• puxar modelos (por exemplo, phi3:mini)
• servir inferência local (CPU ou GPU)
• oferecer API para geração e gestão do modelo

Em termos de engenharia, é o tipo de ferramenta que encaixa bem em ambientes industriais e energéticos que valorizam controle, soberania de dados e previsibilidade.

GPU no CI: quando passa de “nice to have” a obrigatório

Resposta direta: quando o tempo de inferência em CPU torna os testes lentos, caros e pouco úteis — ou quando o modelo escolhido exige GPU para ser viável.

Alguns modelos pequenos rodam em CPU com tempos aceitáveis. Mas, em casos mais realistas (modelos maiores, prompts longos, validação estruturada), CPU vira gargalo e destrói a disciplina do CI:

• pipelines passam a demorar dezenas de minutos
• equipas “pulam” testes para entregar mais rápido
• o risco sobe exatamente onde deveria cair

Uma evolução importante descrita na fonte original é o suporte a GPU em GitLab CI services via GitLab Runner (introduzido a partir da versão v17.10 do Runner). Na prática, o administrador do Runner consegue configurar GPUs não só para o job principal, mas também para os services.

Isso é especialmente relevante para energia e sustentabilidade porque abre caminho para:

• testes de integração de agentes que consultam dados de energia (picos, demanda, eventos) e precisam de respostas rápidas
• pipelines de modelos “on-prem” em ambientes regulados
• cenários onde se quer evitar depender de cloud por custo, latência ou compliance

Boas práticas de GPU (especialmente em hosts multi-GPU)

Resposta direta: pinar GPU por job e evitar “luta” por recursos.

Na vida real, hosts com várias GPUs são compartilhados. Para manter previsibilidade:

• use device pinning por índice/UUID
• se o job e o service precisarem da mesma GPU, alocar explicitamente a mesma
• monitorize filas de pipeline e uso de GPU para evitar saturação

Em operações industriais, isso se traduz num princípio simples: capacidade computacional é parte do processo produtivo, então precisa de governança (SLA, quotas, observabilidade).

Um exemplo útil: transformar um LLM em “calculadora” testável

Resposta direta: o exemplo mostra como tornar o output do LLM validável com um esquema (JSON Schema/Pydantic), reduzindo ambiguidades.

No artigo-base, o exemplo é um mini-projeto Python que cria uma classe LLMCalculator. A parte mais inteligente não é “fazer contas”; é forçar o LLM a devolver uma resposta estruturada e validar isso com Pydantic.

Há duas lições aqui que eu aplicaria diretamente a energia e sustentabilidade:

1. Respostas estruturadas > texto livre para processos operacionais.
2. Erros explícitos (strings/enum) são melhores do que “respostas vagas” quando o sistema precisa reagir.

O padrão que vale ouro: “contrato de saída” + validação

Em vez de pedir “diz o resultado”, o sistema define:

• quais formatos são aceitos (ex.: número ou códigos de erro)
• como o LLM deve sinalizar falhas (divisão por zero, domínio inválido, expressão inválida)
• validação automatizada no código

Isto é muito parecido com automação industrial: um PLC não aceita ‘quase certo’. Ou a leitura está no intervalo, ou gera alarme. LLMs precisam da mesma disciplina.

Adaptando o exemplo para casos de energia

A mesma arquitetura funciona para coisas mais úteis, como:

• classificar um evento de consumo: normal, standby, anomalia
• extrair campos de um relatório de intervenção: causa, ação, duração, risco
• gerar uma recomendação de eficiência com limites: faça X se Y, senão retorne erro

A chave é sempre a mesma: contrato de output + testes de integração no CI.

Como fica um pipeline GitLab CI “pronto para LLM”

Resposta direta: um job de testes com um service ollama, que puxa o modelo antes e executa pytest apontando para o host do serviço.

O desenho típico é:

1. O job sobe um service container do Ollama (alias ollama).
2. O pipeline faz pull do modelo escolhido (isso pode ser cacheado por volume/runner, dependendo da configuração).
3. Os testes rodam e chamam --ollama-host ollama.

Na prática, o que muda para a equipa é mínimo. E isso é bom: mudanças pequenas têm mais adesão.

Três recomendações para não transformar o CI num caos

Resposta direta: controlo de versão, determinismo e limites de custo.

1. Fixe versões

   • fixe a imagem do service (ex.: ollama/ollama:0.6.x)
   • fixe a versão do modelo (quando possível) e do cliente

2. Busque determinismo

   • use seed sempre que o caso permitir
   • reduza temperatura e variação quando o objetivo é teste, não criatividade

3. Controle custos e tempo

   • crie uma suíte “smoke” rápida para cada MR e uma suíte completa em schedule nocturno
   • defina timeouts e limites de tokens

Se a sua organização opera ativos energéticos, esta disciplina vira um diferencial: menos incidentes, menos retrabalho, mais confiança para automatizar.

Perguntas comuns (e respostas sem rodeios)

“Não é mais fácil usar um endpoint cloud e pronto?”

Para protótipos, sim. Para operação em energia/indústria, geralmente não.

Quando o teste depende de cloud:

• a latência varia
• custos variam
• permissões e chaves viram um problema
• compliance e residência de dados podem bloquear o caminho

Ter a opção de rodar localmente (inclusive no CI) dá autonomia.

“Mas puxar modelo no pipeline não vai deixar tudo lento?”

Se você puxar o modelo a cada job, vai. A solução é tratar modelo como artefacto pesado:

• usar runners com cache/volumes persistentes quando fizer sentido
• escolher modelos compatíveis com o seu tempo de feedback
• separar suites: rápidas por MR, completas por schedule

“Isto serve para produção?”

A abordagem é principalmente para engenharia e testes. Mas ela empurra a equipa para um lugar saudável: infra e runtime previsíveis, que é pré-requisito para produção.

Onde isso encaixa na agenda de Energia e Sustentabilidade

A ligação é direta: eficiência energética e sustentabilidade dependem de operações estáveis. E operações estáveis, hoje, incluem software e modelos.

Quando você coloca LLMs no pipeline com GitLab CI services (e GPU quando necessário), você cria uma base para:

• acelerar ciclos de melhoria (menos tempo entre ideia e validação)
• reduzir desperdício computacional (testes mais curtos, infraestrutura controlada)
• avançar com IA local/on-prem em ambientes regulados
• levar automação para o “chão de fábrica” e para o “chão da subestação” com mais segurança

O próximo passo lógico é aplicar o mesmo rigor a observabilidade (logs, métricas de tokens, latência, custo por chamada) e a governança (versões, aprovação de prompts, trilhas de auditoria). Em energia, isso não é burocracia; é continuidade de serviço.

Se você está a avaliar IA para eficiência energética, monitorização ambiental ou otimização de processos industriais, a pergunta que deixo é bem prática: o seu pipeline já trata o LLM como um componente testável — ou ainda como uma caixa-preta que “a gente vê depois”?