LLM Local no seu CI/CD: Revisão de Código Automatizada Sem Cloud

Fatos rápidos

• Modelo recomendado: Qwen3-Coder 30B em Q4_K_M (~17 GB VRAM, Apache 2.0).
• Runtime recomendado: Ollama pela simplicidade de configuração; vLLM se você precisar de maior concorrência na mesma GPU.
• GPU mínima para equipes sérias: RTX 4090 (24 GB). Placas menores forçam o modelo 7B e uma qualidade de revisão notavelmente pior.
• Concorrência em uma única GPU de 24 GB: confortavelmente 1–3 revisões simultâneas no Qwen3-Coder 30B; fila de espera a partir daí.
• Meta de latência: menos de 30 segundos para um diff de 200 linhas. Passado esse ponto, o comportamento do autor da PR muda e as revisões são ignoradas.
• Postura de auditoria: o zero egresso de saída no servidor GPU é demonstrável; toda a superfície é ollama serve + um único arquivo de log.
• Cruzamento frente ao GitHub Advanced Security ($19/dev/mês): 15–25 assentos pagos cobrem um build com RTX 4090 em 5–10 meses.
• Paridade com GitLab CI: arquitetura idêntica, substitua a GitHub Action por um job de CI chamando o mesmo endpoint HTTP.

Comparação de Arquiteturas: Três Opções Reais para Revisão de Código no CI

O Stack Recomendado: Ollama + Qwen3-Coder + uma GitHub Action Enxuta

• Servidor GPU com Ollama (ou vLLM para maior concorrência). O Ollama expõe uma API HTTP compatível com OpenAI em localhost:11434 por padrão; vincule-a a uma interface privada ou a um proxy reverso com autenticação antes de expô-la aos runners.
• Modelo ajustado para codificação: Qwen3-Coder 30B em Q4_K_M é o padrão de maio de 2026 — a direção open-weight mais potente para codificação, contexto de 256K, licença Apache 2.0, cabe em uma GPU de 24 GB. Para GPUs de 8–16 GB, use o Qwen3-Coder 7B tendo em conta que a qualidade de revisão cai notavelmente.
• Integração de CI: um runner do GitHub Actions autohospedado na mesma rede que o servidor GPU, ou seus runners hospedados pelo GitHub existentes alcançando o servidor GPU por uma rede privada (Tailscale, WireGuard ou peering de VPC).
• GitHub Action personalizada (JavaScript ou composite) que obtém o diff da PR pela API do GitHub, envia-o ao endpoint do Ollama com um prompt de revisão, analisa a resposta estruturada e publica comentários em linha de volta na PR.
• Opcional: um pequeno cache de Redis ou SQLite com chave em hash de arquivo + hash de diff para evitar revisar novamente arquivos sem alterações em execuções de CI subsequentes.
• Paridade com GitLab: a mesma arquitetura, com um job do GitLab CI substituindo a GitHub Action. A chamada ao LLM é idêntica.

Um Fluxo de Trabalho Funcional do GitHub Actions

• O runner precisa conseguir alcançar o OLLAMA_HOST pela rede — autohospedado no mesmo VPC, ou via Tailscale / WireGuard se o servidor GPU estiver em outro lugar.
• O prompt de sistema impõe uma resposta JSON estruturada para que a action possa ramificar de forma limpa conforme o veredito. Sem format: "json" e um esquema estrito no prompt, você gastará tempo operacional analisando saída de formato livre.
• O checkout com fetch-depth: 0 é necessário para calcular um diff real contra a branch base — checkouts rasos produzem diffs malformados.
• Para repositórios com mais de ~50K linhas de código alterado por PR, trunque ou divida o diff antes de enviá-lo. O contexto de 256K no Qwen3-Coder 30B é generoso, mas o contexto de trabalho prático fica mais próximo de 64K–128K (ver Melhores modelos de codificação locais em 2026).
• Para profundidade em design de prompt — prompts de sistema vs usuário, exemplos, saídas estruturadas — ver Prompt de Sistema vs Prompt de Usuário: Qual é a Diferença?.

# .github/workflows/local-llm-review.yml
name: Local LLM Code Review

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  review:
    runs-on: self-hosted   # or any runner that can reach OLLAMA_HOST
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Generate diff
        id: diff
        run: |
          git diff origin/${{ github.base_ref }}...HEAD > /tmp/pr.diff
          echo "size=$(wc -c < /tmp/pr.diff)" >> "$GITHUB_OUTPUT"

      - name: Call local LLM for review
        id: review
        env:
          OLLAMA_HOST: ${{ secrets.OLLAMA_HOST }}   # e.g. http://gpu-server.internal:11434
        run: |
          DIFF=$(jq -Rs . < /tmp/pr.diff)
          curl -sS "$OLLAMA_HOST/api/chat" \
            -H 'Content-Type: application/json' \
            -d "{
              \"model\": \"qwen3-coder:30b\",
              \"stream\": false,
              \"format\": \"json\",
              \"messages\": [
                {\"role\": \"system\", \"content\": \"You are a senior code reviewer. Return JSON: {verdict: 'approve'|'comment'|'block', summary: string, comments: [{path, line, severity, message}]}\"},
                {\"role\": \"user\", \"content\": $DIFF}
              ]
            }" > /tmp/review.json
          echo "verdict=$(jq -r '.message.content | fromjson | .verdict' < /tmp/review.json)" >> "$GITHUB_OUTPUT"

      - name: Post review comment
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs');
            const review = JSON.parse(JSON.parse(fs.readFileSync('/tmp/review.json')).message.content);
            const body = `### Local LLM Review: \`${review.verdict}\`\n\n${review.summary}`;
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
              body
            });

      - name: Block on critical verdict
        if: steps.review.outputs.verdict == 'block'
        run: exit 1

Dimensionamento de Hardware por Tamanho de Equipe

Compartilhar GPU entre Builds e Outras Cargas de Trabalho

• GPU dedicada apenas para revisão: o modelo mais simples. A latência é previsível; o planejamento de capacidade é direto; os modos de falha ficam isolados. A recomendação para qualquer equipe que ainda não opere infraestrutura GPU.
• GPU compartilhada com inferência de ML: viável se a carga de trabalho de inferência tiver um envelope estável (por exemplo, um pequeno serviço de embeddings que cabe em 4–6 GB). O modelo de revisão ocupa o restante da VRAM. As colisões de agendamento são raras com esse padrão.
• GPU compartilhada com treinamento de ML: fortemente desaconselhado. Os jobs de treinamento disparam o uso de VRAM ao limite e privam o modelo de revisão, causando latências de revisão de 30–120 segundos que corroem a confiança dos desenvolvedores no sistema.
• vLLM com atenção paginada: projetado especificamente para servir LLM com alta concorrência. A mesma RTX 4090 que lida com 1–3 revisões simultâneas sob o Ollama pode lidar com 4–8 sob o vLLM, ao custo de uma configuração mais complexa. Vale a pena a partir de 25 desenvolvedores.
• Multi-tenant em H100: na escala de 100+ desenvolvedores, particione um H100 em fatias MIG ou execute o vLLM com cotas por tenant. Isso é território de engenharia de plataforma; não improvise.

Comparação de Custos frente ao GitHub Advanced Security

• GitHub Advanced Security (Code Security): $19/desenvolvedor/mês ao preço de tabela (verifique na página de preços do GitHub; há descontos por volume disponíveis para clientes enterprise).
• API de LLM na nuvem (ex. OpenAI, Anthropic): cerca de $50–200/mês por desenvolvedor ativo com o volume típico de PR; varia enormemente conforme o tamanho da base de código e o design do prompt de revisão.
• LLM local autohospedado, build com RTX 4090: cerca de $2.500 em hardware único (GPU + um chassi de servidor básico). Energia: ~50W em repouso, ~350W sob carga — calcule cerca de $20–30/mês em eletricidade com uso típico. Sem tarifas por assento.
• Cruzamento com 10 devs: GHAS $190/mês vs autohospedado $25/mês de operação + $2.500 capex. O capex se paga em ~14 meses.
• Cruzamento com 25 devs: GHAS $475/mês vs autohospedado $25/mês de operação + $2.500 capex. O capex se paga em ~5–6 meses.
• Cruzamento com 50 devs: GHAS $950/mês vs autohospedado $40/mês de operação + $7.500 capex (GPU de 48 GB). O capex se paga em ~8 meses.
• O número do capex é o que domina o cálculo. Se você compra uma GPU especificamente para isso, o payback é real. Se você tem capacidade GPU existente, o custo marginal está mais perto de zero e a autohospedagem vence de imediato.

Modelo de Segurança e Postura de Auditoria

• O modelo só vê o diff que sua action envia. Sem telemetria, sem chamadas de rede ocultas. Confirmável com tcpdump ou nft monitor na interface de saída do servidor GPU — sob operação em estado estável, você deveria ver zero pacotes de saída para hosts não internos.
• A superfície de auditoria completa é um processo e um arquivo de log. O ollama serve é todo o stack do LLM. Seus logs (corpos de requisições, latência, eventos de carregamento do modelo) são o registro de auditoria. Sem painel de SaaS para consultar, sem política de retenção de terceiros para ler.
• O isolamento de rede é direto. Vincule o ollama serve a uma interface privada; coloque um proxy reverso com mTLS ou autenticação de segredo compartilhado na frente; negue o tráfego de saída no namespace de rede do servidor GPU exceto para a sub-rede do seu runner de CI. Padrão zero-trust convencional, sem mágica específica de LLM.
• Os pesos do modelo são artefatos estáticos assinados pelo fornecedor. Baixe-os uma vez com o Ollama, fixe o digest e o modelo não pode mudar sem uma ação do operador. Isso é uma história de cadeia de suprimentos mais sólida que uma API de SaaS onde o modelo upstream pode ser trocado silenciosamente.
• Postura de conformidade: o zero egresso de dados é simples de documentar para SOC 2, ISO 27001, GDPR e a classificação de risco limitado do EU AI Act. A parte mais difícil da conformidade da autohospedagem é geralmente documentar o próprio servidor de inferência; o Ollama e o vLLM estão ambos bem documentados.
• O modelo continua vendo seu código. Autohospedado não significa privado do modelo — significa privado de terceiros. Os cenários de ameaça interna (um engenheiro com acesso ao servidor GPU lê logs que contêm diffs de PR anteriores) continuam no escopo; rotacione os logs e limite o acesso conforme necessário.

Design de Prompt para Revisão de Código

• A saída estruturada não é negociável. Force JSON com um esquema estrito (verdict, summary, comments[]). Sem ele, a action gasta 30% do seu código analisando saída de formato livre e os modos de falha são sutis.
• Para o guia completo sobre a imposição de saída estruturada nos modelos, ver saída estruturada e modo JSON.
• Os limiares de severidade pertencem ao prompt, não à action. Diga ao modelo o que conta como crítico, alto, médio, baixo; diga-lhe para filtrar os achados de baixa severidade a menos que sejam pedidos explicitamente. Isso é muito mais confiável que a filtragem post-hoc em um campo de severidade de formato livre.
• Ancore o prompt com exemplos. Um prompt de 1–2 disparos com um diff real e um JSON de revisão ideal supera massivamente o zero-shot para o mesmo modelo e o mesmo tamanho de diff.
• Distinga a intenção de "revisar" da de "comentar". Um comentário de revisor ("considere extrair isto para um helper") e um bloqueador ("isto introduz uma injeção SQL") precisam de ações diferentes no CI. Marque-os na saída estruturada e faça a action bloquear apenas nos bloqueadores.
• As variantes de prompt por linguagem ajudam a partir de certo tamanho. Uma base de código poliglota se beneficia de um prompt que referencia os idiomatismos da linguagem relevante (Pythonic vs Rust idiomático). Isso é opcional abaixo de ~25 desenvolvedores; valioso acima.
• Para fundamentos mais profundos de engenharia de prompt — prompts de sistema vs usuário, saídas estruturadas, few-shot prompting — ver Prompt de Sistema vs Prompt de Usuário: Qual é a Diferença?.

Gestão de Falsos Positivos sem Corroer a Confiança dos Desenvolvedores

• Estabeleça um limiar de "bloqueio" alto. Um veredito de bloquear que dispara diante de qualquer problema menor de lint treina os desenvolvedores a pular a verificação. Reserve bloquear para problemas de segurança, testes falhos e falhas de correção evidentes.
• Faça com que os comentários não bloqueantes sejam baratos. Os comentários em linha sobre os quais o modelo não está seguro devem ser marcados ("tentativo" / "considere") para que os autores possam descartá-los rapidamente sem cerimônia.
• Construa um ciclo de feedback no primeiro mês. Adicione uma reação (👍 / 👎) a cada comentário de revisão. Periodicamente (semanalmente funciona) revise os 👎 e atualize o prompt de sistema com instruções explícitas de "não sinalizar X" para as categorias de falsos positivos mais comuns.
• Limite o volume de comentários por PR. Uma única PR não deveria receber mais de 5–10 comentários do LLM; passado isso, a relação sinal-ruído entra em colapso. Limite a action no nível do prompt ("retorne no máximo N comentários").
• Acompanhe a correlação veredito-para-merge semanalmente. Se 80% dos veredictos de bloquear forem mesclados de qualquer forma, seu limiar está agressivo demais. Se 0% dos veredictos de comentar receberem alguma ação humana, seu prompt está gerando ruído.

Armadilhas Operacionais que Aparecem no Segundo Mês

• As atualizações do modelo quebram os prompts. Uma nova versão do Qwen3-Coder muda sutilmente o formato de saída; a análise de JSON estruturado falha no CI; as revisões param de ser publicadas. Fixe o digest do modelo com ollama show <model> --modelfile; atualize em uma branch de staging antes de promover.
• Fragmentação de memória da GPU sob tempo de atividade prolongado. Um servidor GPU rodando 24/7 pode fragmentar a VRAM e recusar novas alocações após semanas de operação. Reinicie o ollama serve semanalmente por meio de um cron job; é barato e evita completamente esse modo de falha.
• Contenção do runner de CI. Um runner autohospedado que hospeda tanto o servidor LLM quanto outros jobs de CI verá a latência de revisão disparar sob carga de build. Separe o runner e o servidor GPU quando o tamanho da equipe ultrapassar ~25 desenvolvedores.
• Crescimento do tamanho do diff. Os tamanhos de PR vão crescendo; eventualmente uma PR ultrapassa o contexto de trabalho prático do modelo e as revisões se degradam silenciosamente. Adicione uma guarda na action que divide ou trunca os diffs acima de ~30K tokens e avisa o autor.
• Energia e refrigeração. Uma RTX 4090 com carga contínua consome ~350W sob inferência e gera uma quantidade significativa de calor. Uma sala de servidores do tamanho de um armário sem refrigeração ativa vai limitar a GPU; a limitação custa latência e os desenvolvedores notam.
• Rotação de logs esquecida. O Ollama registra cada corpo de requisição por padrão. Após três meses de revisões de PR, o arquivo de log é grande e contém diffs de PRs históricas em texto puro. Rotacione os logs semanalmente; arquive ou apague conforme sua política de retenção de dados.

Erros Comuns ao Configurar a Revisão de Código com LLM Local

• Erro 1: começar com um modelo 7B em uma GPU de 16 GB. As revisões com o Qwen3-Coder 7B são notavelmente piores que com o 30B; os desenvolvedores perdem a confiança rapidamente e o projeto é abandonado. Se você não consegue alojar o 30B, melhore a GPU ou use uma API na nuvem nos primeiros seis meses enquanto garante orçamento.
• **Erro 2: bloquear PRs por veredictos de bloquear desde o primeiro dia.** O primeiro mês é calibração; trate toda a saída como consultiva até ter medido a taxa de falsos positivos. Promova para bloqueante apenas quando a taxa estiver abaixo de ~5%.
• **Erro 3: expor o ollama serve em 0.0.0.0:11434 sem autenticação.** Isso é o equivalente na era dos LLMs a deixar o Redis vinculado a uma interface pública. Vincule a uma interface privada e coloque autenticação na frente antes de qualquer exposição entre hosts.
• Erro 4: pular o cache. Revisar novamente arquivos sem alterações a cada execução de CI desperdiça ~80% do orçamento de inferência em uma PR típica. Um pequeno cache de hash de arquivo + hash de diff (Redis ou SQLite) reduz drasticamente a latência de revisão e a carga na GPU.
• Erro 5: executar jobs de treinamento na mesma GPU. O treinamento dispara o uso de VRAM ao limite e priva o modelo de revisão de recursos. Use GPUs separadas ou, se precisar compartilhar, execute o treinamento em um horário estrito que não se sobreponha às horas de pico de PR.
• Erro 6: construir a GitHub Action sem um ciclo de feedback. Um sistema de revisão sem reações 👍/👎 não pode melhorar. Construa o ciclo na primeira semana; colete dados; itere o prompt mensalmente.

Fontes

• Documentação do Ollama — Referência oficial da API HTTP para /api/chat, /api/generate, saída estruturada e gestão de modelos.
• Documentação do vLLM — Documentação do servidor de inferência de alto throughput; o caminho de atualização além do Ollama para equipes com alta concorrência.
• Documentação do GitHub Actions — Referência oficial para runners autohospedados, segredos e o SDK JavaScript do Actions usado no fluxo de trabalho acima.
• Preços do GitHub Advanced Security — Referência de preços de tabela para a comparação de custos; verifique frente aos seus termos negociados reais.
• Ficha do modelo Qwen3-Coder — Arquitetura, janela de contexto e termos de licença para o modelo de revisão recomendado.
• Referência do GitLab CI/CD — Referência equivalente para equipes do GitLab; a porção de chamada ao LLM do fluxo de trabalho é idêntica.

FAQ

Leituras Relacionadas

• Substituir o GitHub Copilot por um LLM Local — contexto mais amplo de substituição de custos para equipes que consideram ferramentas de IA autohospedadas.
• Continue.dev vs Cline vs Aider: Melhor Agente de Codificação Local em 2026 — o que funciona em pipelines vs trabalho interativo no editor; a camada de harness sob o modelo.
• Melhores Modelos de Codificação Locais em 2026 — o lado do modelo na equação: Qwen3-Coder, DeepSeek, Codestral e o panorama de licenças.
• Prompt de Sistema vs Prompt de Usuário: Qual é a Diferença? — fundamentos de engenharia de prompt para o prompt de sistema de revisão.
• llama.cpp vs Ollama vs vLLM — comparação de motores de inferência; o vLLM é o caminho de atualização além do Ollama para equipes com alta concorrência.
• Power Local LLM Hub — biblioteca completa de guias.