LLM Local en CI/CD: Revisión de Código Automatizada Sin Cloud

Datos rápidos

• Modelo recomendado: Qwen3-Coder 30B en Q4_K_M (~17 GB VRAM, Apache 2.0).
• Runtime recomendado: Ollama por simplicidad de configuración; vLLM si necesitas mayor concurrencia en la misma GPU.
• GPU mínima para equipos serios: RTX 4090 (24 GB). Las tarjetas más pequeñas obligan a usar el modelo 7B con una calidad de revisión notablemente peor.
• Concurrencia en una sola GPU de 24 GB: cómodamente 1–3 revisiones simultáneas en Qwen3-Coder 30B; cola de espera a partir de ahí.
• Objetivo de latencia: menos de 30 segundos para un diff de 200 líneas. Pasado ese punto, el comportamiento del autor de la PR cambia y las revisiones se omiten.
• Postura de auditoría: el cero egreso saliente en el servidor GPU es demostrable; toda la superficie es ollama serve + un único archivo de log.
• Cruce frente a GitHub Advanced Security ($19/dev/mes): 15–25 asientos pagados cubren una build con RTX 4090 en 5–10 meses.
• Paridad con GitLab CI: arquitectura idéntica, reemplaza la GitHub Action con un job de CI que llama al mismo endpoint HTTP.

Comparación de Arquitecturas: Tres Opciones Reales para Revisión de Código en CI

El Stack Recomendado: Ollama + Qwen3-Coder + una GitHub Action Liviana

• Servidor GPU con Ollama (o vLLM para mayor concurrencia). Ollama expone una API HTTP compatible con OpenAI en localhost:11434 por defecto; vincúlala a una interfaz privada o un proxy inverso con autenticación antes de exponerla a los runners.
• Modelo ajustado para codificación: Qwen3-Coder 30B en Q4_K_M es el estándar de mayo de 2026 — la dirección open-weight más potente para codificación, contexto de 256K, licencia Apache 2.0, cabe en una GPU de 24 GB. Para GPUs de 8–16 GB, usa Qwen3-Coder 7B teniendo en cuenta que la calidad de revisión cae notablemente.
• Integración CI: un runner de GitHub Actions autoalojado en la misma red que el servidor GPU, o tus runners hospedados por GitHub existentes alcanzando el servidor GPU por una red privada (Tailscale, WireGuard o peering de VPC).
• GitHub Action personalizada (JavaScript o composite) que obtiene el diff de la PR por la API de GitHub, lo envía al endpoint de Ollama con un prompt de revisión, analiza la respuesta estructurada y publica comentarios en línea de vuelta en la PR.
• Opcional: un pequeño caché de Redis o SQLite con clave en hash de archivo + hash de diff para evitar re-revisiones de archivos sin cambios en ejecuciones de CI posteriores.
• Paridad con GitLab: la misma arquitectura, con un job de GitLab CI que reemplaza la GitHub Action. La llamada al LLM es idéntica.

Un Flujo de Trabajo de GitHub Actions Funcional

• El runner debe poder alcanzar OLLAMA_HOST por red — autoalojado en el mismo VPC, o vía Tailscale / WireGuard si el servidor GPU está en otro lugar.
• El prompt de sistema impone una respuesta JSON estructurada para que la action pueda ramificar limpiamente según el veredicto. Sin format: "json" y un esquema estricto en el prompt, gastarás tiempo operativo analizando salida de formato libre.
• El checkout con fetch-depth: 0 es necesario para calcular un diff real contra la rama base — los checkouts superficiales producen diffs malformados.
• Para repositorios con más de ~50K líneas de código modificado por PR, trunca o divide el diff antes de enviarlo. El contexto de 256K en Qwen3-Coder 30B es generoso, pero el contexto de trabajo práctico es más cercano a 64K–128K (ver Mejores modelos de codificación locales en 2026).
• Para profundidad en diseño de prompt — prompts de sistema vs usuario, ejemplos, salidas estructuradas — ver Prompt de Sistema vs Prompt de Usuario: ¿Cuál es la Diferencia?.

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

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  review:
    runs-on: self-hosted   # o cualquier runner que pueda alcanzar 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 }}   # ej. 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

Dimensionamiento de Hardware por Tamaño de Equipo

Compartir GPU entre Builds y Otras Cargas de Trabajo

• GPU dedicada solo para revisión: el modelo más simple. La latencia es predecible; la planificación de capacidad es directa; los modos de fallo están aislados. La recomendación para cualquier equipo que no opera ya infraestructura GPU.
• GPU compartida con inferencia ML: viable si la carga de trabajo de inferencia tiene una envolvente estable (por ejemplo, un pequeño servicio de embeddings que cabe en 4–6 GB). El modelo de revisión ocupa el resto del VRAM. Las colisiones de programación son raras con este patrón.
• GPU compartida con entrenamiento ML: fuertemente desaconsejado. Los jobs de entrenamiento disparan el uso de VRAM al límite y privan al modelo de revisión, causando latencias de revisión de 30–120 segundos que erosionan la confianza de los desarrolladores en el sistema.
• vLLM con atención paginada: diseñado específicamente para servir LLM con alta concurrencia. La misma RTX 4090 que maneja 1–3 revisiones simultáneas bajo Ollama puede manejar 4–8 bajo vLLM, a costa de una configuración más compleja. Vale la pena a partir de 25 desarrolladores.
• Multi-tenant en H100: a escala de 100+ desarrolladores, particiona un H100 en rebanadas MIG o ejecuta vLLM con cuotas por tenant. Esto es territorio de ingeniería de plataforma; no lo improvises.

Comparación de Costos frente a GitHub Advanced Security

• GitHub Advanced Security (Code Security): $19/desarrollador/mes al precio de lista (verifica en la página de precios de GitHub; hay descuentos por volumen disponibles para clientes enterprise).
• API de LLM en la nube (ej. OpenAI, Anthropic): aproximadamente $50–200/mes por desarrollador activo con el volumen típico de PR; varía enormemente según el tamaño de la base de código y el diseño del prompt de revisión.
• LLM local autoalojado, build con RTX 4090: aproximadamente $2.500 en hardware único (GPU + un chasis de servidor básico). Energía: ~50W en reposo, ~350W bajo carga — calcula unos $20–30/mes en electricidad con uso típico. Sin tarifas por asiento.
• Cruce con 10 devs: GHAS $190/mes vs autoalojado $25/mes de operación + $2.500 capex. El capex se amortiza en ~14 meses.
• Cruce con 25 devs: GHAS $475/mes vs autoalojado $25/mes de operación + $2.500 capex. El capex se amortiza en ~5–6 meses.
• Cruce con 50 devs: GHAS $950/mes vs autoalojado $40/mes de operación + $7.500 capex (GPU de 48 GB). El capex se amortiza en ~8 meses.
• El número de capex es lo que domina el cálculo. Si compras una GPU específicamente para esto, la amortización es real. Si tienes capacidad GPU existente, el costo marginal está más cerca de cero y el autoalojamiento gana de inmediato.

Modelo de Seguridad y Postura de Auditoría

• El modelo solo ve el diff que tu action le envía. Sin telemetría, sin llamadas de red ocultas. Confirmable con tcpdump o nft monitor en la interfaz saliente del servidor GPU — bajo operación en estado estable, deberías ver cero paquetes salientes hacia hosts no internos.
• La superficie de auditoría completa es un proceso y un archivo de log. ollama serve es todo el stack del LLM. Sus logs (cuerpos de solicitudes, latencia, eventos de carga del modelo) son el registro de auditoría. Sin panel de SaaS que consultar, sin política de retención de terceros que leer.
• El aislamiento de red es directo. Vincula ollama serve a una interfaz privada; coloca un proxy inverso con mTLS o autenticación de secreto compartido delante; niega el tráfico saliente en el namespace de red del servidor GPU excepto hacia la subred de tu runner de CI. Patrón estándar de zero-trust, sin magia específica de LLM.
• Los pesos del modelo son artefactos estáticos firmados por el proveedor. Descárgalos una vez con Ollama, fija el digest y el modelo no puede cambiar sin una acción del operador. Esto es una historia de cadena de suministro más sólida que una API de SaaS donde el modelo upstream puede intercambiarse silenciosamente.
• Postura de cumplimiento: el cero egreso de datos es sencillo de documentar para SOC 2, ISO 27001, GDPR y la clasificación de riesgo limitado del EU AI Act. La parte más difícil del cumplimiento del autoalojamiento es generalmente documentar el propio servidor de inferencia; Ollama y vLLM están ambos bien documentados.
• El modelo sigue viendo tu código. Autoalojado no significa privado del modelo — significa privado de terceros. Los escenarios de amenaza interna (un ingeniero con acceso al servidor GPU lee logs que contienen diffs de PR anteriores) siguen en alcance; rota los logs y limita el acceso en consecuencia.

Diseño de Prompt para Revisión de Código

• La salida estructurada no es negociable. Fuerza JSON con un esquema estricto (verdict, summary, comments[]). Sin él, la action gasta el 30% de su código analizando salida de formato libre y los modos de fallo son sutiles.
• Para la guía completa sobre el cumplimiento de salida estructurada en modelos, ver salida estructurada y modo JSON.
• Los umbrales de severidad pertenecen al prompt, no a la action. Dile al modelo qué cuenta como crítico, alto, medio, bajo; dile que filtre los hallazgos de baja severidad salvo que se pidan explícitamente. Esto es mucho más confiable que el filtrado post-hoc en un campo de severidad de formato libre.
• Ancla el prompt con ejemplos. Un prompt de 1–2 disparos con un diff real y un JSON de revisión ideal supera masivamente al zero-shot para el mismo modelo y el mismo tamaño de diff.
• Distingue la intención de "revisar" de "comentar". Un comentario de revisor ("considera extraer esto a un helper") y un bloqueador ("esto introduce una inyección SQL") necesitan acciones diferentes en CI. Etiquétalos en la salida estructurada y haz que la action solo bloquee en los bloqueadores.
• Las variantes de prompt por lenguaje ayudan a partir de cierto tamaño. Una base de código polígota se beneficia de un prompt que referencia los modismos del lenguaje relevante (Pythonic vs Rust idiomático). Esto es opcional por debajo de ~25 desarrolladores; valioso por encima.
• Para fundamentos más profundos de ingeniería de prompt — prompts de sistema vs usuario, salidas estructuradas, few-shot prompting — ver Prompt de Sistema vs Prompt de Usuario: ¿Cuál es la Diferencia?.

Gestión de Falsos Positivos sin Erosionar la Confianza de los Desarrolladores

• Establece un umbral de "bloqueo" alto. Un veredicto de bloquear que se dispara ante cualquier problema menor de lint entrena a los desarrolladores a saltarse la verificación. Reserva bloquear para problemas de seguridad, pruebas fallidas y fallos de corrección evidentes.
• Haz que los comentarios no bloqueantes sean baratos. Los comentarios en línea sobre los que el modelo no está seguro deben etiquetarse ("tentativo" / "considera") para que los autores puedan descartarlos rápidamente sin ceremonia.
• Construye un ciclo de retroalimentación en el primer mes. Agrega una reacción (👍 / 👎) a cada comentario de revisión. Periódicamente (semanalmente funciona) revisa los 👎 y actualiza el prompt de sistema con instrucciones explícitas de "no marcar X" para las categorías de falsos positivos más comunes.
• Limita el volumen de comentarios por PR. Una sola PR no debería recibir más de 5–10 comentarios del LLM; pasado eso, la relación señal-ruido colapsa. Limita la action a nivel del prompt ("devuelve como máximo N comentarios").
• Rastrea la correlación veredicto-a-merge semanalmente. Si el 80% de los veredictos de bloquear se fusionan de todas formas, tu umbral es demasiado agresivo. Si el 0% de los veredictos de comentar reciben alguna acción humana, tu prompt está generando ruido.

Trampas Operativas que Aparecen en el Segundo Mes

• Las actualizaciones del modelo rompen los prompts. Una nueva versión de Qwen3-Coder cambia sutilmente el formato de salida; el análisis de JSON estructurado falla en CI; las revisiones dejan de publicarse. Fija el digest del modelo con ollama show <model> --modelfile; actualiza en una rama de staging antes de promocionar.
• Fragmentación de memoria de GPU bajo tiempo de actividad prolongado. Un servidor GPU que corre 24/7 puede fragmentar el VRAM y rechazar nuevas asignaciones tras semanas de operación. Reinicia ollama serve semanalmente mediante un cron job; es barato y evita completamente este modo de fallo.
• Contención del runner de CI. Un runner autoalojado que aloja tanto el servidor LLM como otros jobs de CI verá dispararse la latencia de revisión bajo carga de build. Separa el runner y el servidor GPU cuando el tamaño del equipo supere ~25 desarrolladores.
• Crecimiento del tamaño del diff. Los tamaños de PR van creciendo; eventualmente una PR supera el contexto de trabajo práctico del modelo y las revisiones se degradan silenciosamente. Agrega una guarda en la action que divide o trunca los diffs por encima de ~30K tokens y advierte al autor.
• Energía y refrigeración. Una RTX 4090 con carga continua consume ~350W bajo inferencia y genera una cantidad significativa de calor. Una sala de servidores del tamaño de un armario sin refrigeración activa limitará la GPU; la limitación cuesta latencia y los desarrolladores lo notan.
• Rotación de logs olvidada. Ollama registra cada cuerpo de solicitud por defecto. Después de tres meses de revisiones de PR, el archivo de log es grande y contiene diffs de PR históricas en texto plano. Rota los logs semanalmente; archiva o elimina según tu política de retención de datos.

Errores Comunes al Configurar la Revisión de Código con LLM Local

• Error 1: empezar con un modelo 7B en una GPU de 16 GB. Las revisiones con Qwen3-Coder 7B son notablemente peores que con el 30B; los desarrolladores pierden confianza rápidamente y el proyecto se abandona. Si no puedes alojar el 30B, mejora la GPU o usa una API en la nube los primeros seis meses mientras aseguras presupuesto.
• **Error 2: bloquear PRs por veredictos de bloquear desde el primer día.** El primer mes es calibración; trata toda la salida como consultiva hasta que hayas medido la tasa de falsos positivos. Promueve a bloqueante solo cuando la tasa esté por debajo del ~5%.
• **Error 3: exponer ollama serve en 0.0.0.0:11434 sin autenticación.** Esto es el equivalente en la era de los LLM a dejar Redis vinculado a una interfaz pública. Vincula a una interfaz privada y coloca autenticación delante antes de cualquier exposición entre hosts.
• Error 4: omitir el caché. Revisar de nuevo archivos sin cambios en cada ejecución de CI desperdicia ~80% del presupuesto de inferencia en una PR típica. Un pequeño caché de hash de archivo + hash de diff (Redis o SQLite) reduce drásticamente la latencia de revisión y la carga en la GPU.
• Error 5: ejecutar jobs de entrenamiento en la misma GPU. El entrenamiento dispara el uso de VRAM al límite y priva al modelo de revisión de recursos. Usa GPUs separadas o, si debes compartir, ejecuta el entrenamiento en un horario estricto que no se superponga con las horas pico de PR.
• Error 6: construir la GitHub Action sin un ciclo de retroalimentación. Un sistema de revisión sin reacciones 👍/👎 no puede mejorar. Construye el ciclo en la primera semana; recopila datos; itera el prompt mensualmente.

Fuentes

• Documentación de Ollama — Referencia oficial de la API HTTP para /api/chat, /api/generate, salida estructurada y gestión de modelos.
• Documentación de vLLM — Documentación del servidor de inferencia de alto rendimiento; la ruta de actualización más allá de Ollama para equipos con alta concurrencia.
• Documentación de GitHub Actions — Referencia oficial para runners autoalojados, secretos y el SDK de JavaScript de Actions usado en el flujo de trabajo anterior.
• Precios de GitHub Advanced Security — Referencia de precios de lista para la comparación de costos; verifica frente a tus términos negociados reales.
• Ficha del modelo Qwen3-Coder — Arquitectura, ventana de contexto y términos de licencia para el modelo de revisión recomendado.
• Referencia de GitLab CI/CD — Referencia equivalente para equipos de GitLab; la porción de llamada al LLM del flujo de trabajo es idéntica.

FAQ

Lecturas Relacionadas

• Reemplazar GitHub Copilot con un LLM Local — contexto más amplio de reemplazo de costos para equipos que consideran herramientas de IA autoalojadas.
• Continue.dev vs Cline vs Aider: Mejor Agente de Codificación Local en 2026 — qué funciona en pipelines vs trabajo interactivo en el editor; la capa de harness bajo el modelo.
• Mejores Modelos de Codificación Local en 2026 — el lado del modelo en la ecuación: Qwen3-Coder, DeepSeek, Codestral y el panorama de licencias.
• Prompt de Sistema vs Prompt de Usuario: ¿Cuál es la Diferencia? — fundamentos de ingeniería de prompt para el prompt de sistema de revisión.
• llama.cpp vs Ollama vs vLLM — comparación de motores de inferencia; vLLM es la ruta de actualización más allá de Ollama para equipos con alta concurrencia.
• Power Local LLM Hub — biblioteca completa de guías.