Lokale LLM im CI/CD: Automatisierte Code Review ohne Cloud

Schnellübersicht

• Empfohlenes Modell: Qwen3-Coder 30B bei Q4_K_M (~17 GB VRAM, Apache 2.0).
• Empfohlene Laufzeit: Ollama für Setup Vereinfachung; vLLM wenn Sie höhere Concurrency auf derselben GPU benötigen.
• Minimale GPU für ernst zu nehmende Teams: RTX 4090 (24 GB). Kleinere Karten erzwingen das 7B Modell und merklich schlechtere Review Qualität.
• Concurrency auf einer einzelnen 24 GB GPU: komfortabel 1–3 gleichzeitige Reviews auf Qwen3-Coder 30B; Queue darüber hinaus.
• Latenz Ziel: unter 30 Sekunden für eine 200-zeilige Diff. Danach ändert sich PR-Author Verhalten und Reviews werden umgangen.
• Audit Posture: Null ausgehender Egress auf dem GPU Server ist beweisbar; gesamte Oberfläche ist ollama serve + eine einzelne Log Datei.
• Kostenparität vs GitHub Advanced Security ($19/dev/Monat): 15–25 bezahlte Seats decken einen RTX 4090 Build in 5–10 Monaten ab.
• GitLab CI Parität: identische Architektur, ersetzen Sie die GitHub Action mit einem CI Job, der die gleiche HTTP Endpoint aufruft.

Architekturvergleich: Drei echte Optionen für Code Review in CI

Der empfohlene Stack: Ollama + Qwen3-Coder + eine dünne GitHub Action

• GPU Server mit Ollama (oder vLLM für höhere Concurrency). Ollama exponiert eine OpenAI-kompatible HTTP API auf localhost:11434 standardmäßig; binden Sie sie an eine private Schnittstelle oder einen Reverse Proxy mit Auth, bevor Sie zu Runnern exponieren.
• Coding-optimiertes Modell: Qwen3-Coder 30B bei Q4_K_M ist der Mai 2026 Standard — stärkste Open-Weight Coding Richtung, 256K Kontext, Apache 2.0 Lizenz, passt auf eine 24 GB GPU. Für 8–16 GB GPUs verwenden Sie Qwen3-Coder 7B mit dem Verständnis, dass Review Qualität merklich sinkt.
• CI Integration: ein Self-Hosted GitHub Actions Runner im selben Netzwerk wie der GPU Server, oder Ihre bestehenden GitHub-gehosteten Runner, die den GPU Server über ein privates Netzwerk erreichen (Tailscale, WireGuard oder VPC Peering).
• Benutzerdefinierte GitHub Action (JavaScript oder Composite), die die PR Diff über die GitHub API abruft, sie mit einem Review Prompt zur Ollama Endpoint sendet, die strukturierte Antwort parst und Inline Kommentare zurück zur PR sendet.
• Optional: ein kleiner Redis oder SQLite Cache, der nach Datei Hash + Diff Hash schlüsselt, um Re-Reviews von unveränderten Dateien in nachfolgenden CI Läufen zu vermeiden.
• GitLab Parität: die gleiche Architektur, mit einem GitLab CI Job, der die GitHub Action ersetzt. Der LLM Aufruf ist identisch.

Ein funktionierender GitHub Actions Workflow

• Der Runner muss OLLAMA_HOST über das Netzwerk erreichen können — Self-Hosted im gleichen VPC, oder über Tailscale / WireGuard, wenn der GPU Server woanders lebt.
• Der System Prompt erzwingt eine strukturierte JSON Antwort, damit die Action sauber auf Verdikt verzweigen kann. Ohne format: "json" und ein striktes Schema im Prompt werden Sie operative Zeit bei Freiform Output Parsing verbringen.
• Der fetch-depth: 0 Checkout ist notwendig, um eine echte Diff gegen den Base Branch zu berechnen — flache Checkouts produzieren malformed Diffs.
• Für Repositories über ~50K Zeilen geänderter Code pro PR truncate oder chunk die Diff vorher. Der 256K Kontext auf Qwen3-Coder 30B ist großzügig, aber praktischer Arbeits Kontext ist näher an 64K–128K (siehe Best Local Coding Models in 2026).
• Für Prompt-Design Tiefe — System vs User Prompts, Beispiele, strukturierte Outputs — siehe System Prompt vs User Prompt: What's the Difference.

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

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  review:
    runs-on: self-hosted   # oder jeder Runner, der OLLAMA_HOST erreichen kann
    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 }}   # z.B. 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

Hardware Dimensionierung nach Teamgröße

GPU Sharing über Builds und anderen Workloads hinweg

• Dedizierte GPU nur für Review: einfachstes Modell. Latenz ist vorhersehbar; Kapazitäts Planung ist unkompliziert; Fehlermodi sind isoliert. Die Empfehlung für jedes Team, das nicht bereits GPU Infrastruktur betreibt.
• Gemeinsame GPU mit ML Inference: funktioniert, wenn der Inference Workload eine stabile Hülle hat (z.B. ein kleiner Embedding Service, der in 4–6 GB passt). Das Review Modell besetzt den Rest von VRAM. Scheduling Kollisionen sind auf diesem Muster selten.
• Gemeinsame GPU mit ML Training: stark abgeraten. Training Jobs sprengen VRAM Nutzung zum Limit und verhungern das Review Modell, was 30–120-sekündige Review Latenzen verursacht, die Entwicklervertrauen erode.
• vLLM mit Paged Attention: Purpose-Built für High-Concurrency LLM Serving. Die gleiche RTX 4090, die unter Ollama 1–3 gleichzeitige Reviews bedient, kann unter vLLM 4–8 bedienen, zum Preis eines komplexeren Setups. Wert es ab 25 Entwickler.
• Multi-Tenant auf H100: bei der 100+ Entwickler Skala, partitionieren Sie einen H100 in MIG Slices oder betreiben Sie vLLM mit Per-Tenant Quoten. Dies ist Platform Engineering Territorium; improvisieren Sie es nicht.

Kostenvergleich vs GitHub Advanced Security

• GitHub Advanced Security (Code Security): $19/Entwickler/Monat bei Listenpreis (verifizieren Sie auf der GitHub Pricing-Seite; Volumen Rabatte verfügbar für Enterprise Kunden).
• Cloud LLM API (z.B. OpenAI, Anthropic): grob $50–200/Monat pro aktiver Entwickler bei typischem PR Volumen; variiert wild nach Codebase Größe und Review Prompt Design.
• Self-Hosted Lokale LLM, RTX 4090 Build: grob ca. 2.300 € einmalige Hardware (GPU + ein einfaches Server Gehäuse). Stromverbrauch: ~50W untätig, ~350W unter Last — nennen wir es ca. 18–28€/Monat in Elektrizität bei typischer Nutzung. Keine Pro-Seat Gebühren.
• Kostenparität bei 10 Entwickler: GHAS $190/Monat vs Self-Hosted ca. 25€/Monat betrieben + ca. 2.300 € Capex. Capex wird in ~14 Monaten rentabel.
• Kostenparität bei 25 Entwickler: GHAS $475/Monat vs Self-Hosted ca. 25€/Monat betrieben + ca. 2.300 € Capex. Capex wird in ~5–6 Monaten rentabel.
• Kostenparität bei 50 Entwickler: GHAS $950/Monat vs Self-Hosted ca. 40€/Monat betrieben + ca. 7.500 € Capex (48 GB GPU). Capex wird in ~8 Monaten rentabel.
• Die Capex Zahl ist das, was die Mathematik dominiert. Wenn Sie eine GPU speziell dafür kaufen, ist die Payback real. Wenn Sie bestehende GPU Kapazität haben, sind die Marginalkosten näher an null und Self-Hosting gewinnt sofort.

Sicherheitsmodell und Audit Posture

• Das Modell sieht nur die Diff, die Ihre Action sendet. Keine Telemetrie, keine versteckten Netzwerk Aufrufe. Bestätigbar mit tcpdump oder nft monitor auf der GPU Server Ausgangs Schnittstelle — unter Steady-State Operation sollten Sie null ausgehende Pakete zu Nicht-Internen Hosts sehen.
• Die vollständige Audit Oberfläche ist ein Prozess und eine Log Datei. ollama serve ist der gesamte LLM Stack. Seine Logs (Request Bodies, Latenz, Model Loading Events) sind der Audit Record. Kein SaaS Dashboard zum Abfragen, keine Drittanbieter Aufbewahrungs Richtlinie zum Lesen.
• Netzwerk Isolierung ist unkompliziert. Binden Sie ollama serve an eine private Schnittstelle; legen Sie einen Reverse Proxy mit mTLS oder Shared-Secret Auth davor; lehnen Sie ausgehende auf dem GPU Server Netzwerk Namespace ab, außer zu Ihrem CI Runner Subnet. Standard Zero-Trust Muster, keine LLM-spezifisch Magie.
• Die Modell Gewichte sind statische, von Vendor signierte Artefakte. Ziehen Sie sie einmal über Ollama, pinnen Sie den Digest und das Modell kann nicht ohne Operator Action ändern. Dies ist eine stärkere Supply-Chain Story als eine SaaS API, wo das Upstream Modell stillschweigend getauscht werden kann.
• Compliance Postur: Null Daten Egress ist einfach zu dokumentieren für SOC 2, ISO 27001, GDPR und die EU AI Act Limited-Risk Klassifizierung. Der schwierigste Teil von Self-Hosting Compliance ist gewöhnlich die Dokumentation des Inference Server selbst; Ollama und vLLM sind beide gut dokumentiert.
• Das Modell sieht immer noch Ihren Code. Self-Hosted bedeutet nicht privat vor dem Modell — es bedeutet privat vor Dritten. Insider-Threat Szenarien (Engineer mit GPU Server Zugang liest Logs, die vergangene PR Diffs enthalten) sind immer noch im Scope; rotieren Sie Logs und limitieren Sie Zugang entsprechend.

Prompt Design für Code Review

• Strukturierter Output ist nicht verhandelbar. Erzwingen Sie JSON mit einem strikten Schema (verdict, summary, comments[]). Ohne es werden 30% des Action Code mit Freiform Output Parsing verbracht und die Fehlermodi sind subtil.
• Für den vollständigen Leitfaden zum Strukturierten Output Enforcement über Modelle, siehe structured output and JSON mode.
• Severity Thresholds gehören zum Prompt, nicht zur Action. Erzählen Sie dem Modell, was als kritisch, hoch, mittel, niedrig zählt; erzählen Sie ihm, Befunde mit niedriger Severity zu filtern, es sei denn, es wird ausdrücklich gefragt. Dies ist viel zuverlässiger als Post-Hoc Filterung auf einem Freiform Severity Feld.
• Veranker den Prompt mit Beispielen. Ein 1–2-Shot Prompt mit einer echten Diff und einem echten Ideal-Review JSON übertrifft Zero-Shot massiv für das gleiche Modell und die gleiche Diff Größe.
• Unterscheide "überprüfe" von "Kommentar" Absicht. Ein Reviewer Kommentar ("erwägen Sie, dies zu einem Helper zu extrahieren") und ein Blocker ("dies führt eine SQL Injection ein") benötigen unterschiedliche Aktionen in CI. Taggen Sie sie im strukturierten Output und lassen Sie die Action nur auf Blocker blockieren.
• Pro-Sprache Prompt Varianten helfen ab einer gewissen Größe. Ein Polyglot Codebase profitiert von einem Prompt, der relevante Sprach Idiome referenziert (Pythonic vs Idiomatisch Rust). Dies ist optional unter ~25 Entwickler; wertvoll darüber.
• Für tiefere Prompt-Engineering Fundament — System vs User Prompts, Strukturierte Outputs, Few-Shot Prompting — siehe System Prompt vs User Prompt: What's the Difference.

Umgang mit falsch positiven Ergebnissen ohne Entwicklervertrauen zu zerode

• Setzen Sie einen "block" Threshold hoch. Ein block Verdikt, das bei jedem kleineren Lint Problem feuert, trainiert Entwickler, die Prüfung zu umgehen. Reservieren Sie block für Sicherheits Probleme, fehlgeschlagene Tests und klare Correctness Fehler.
• Lassen Sie Nicht-Blocking Kommentare billig fühlen. Inline Kommentare, bei denen das Modell unsicher ist, sollten getaggt werden ("tentativ" / "erwägen"), damit Autoren sie schnell ohne Zeremonien verwerfen können.
• Baue eine Feedback Schleife im ersten Monat auf. Füge eine Reaktion (👍 / 👎) zu jedem Review Kommentar hinzu. Gelegentlich (wöchentlich funktioniert) überprüfe die 👎s und aktualisiere den System Prompt mit expliziten "markiere X nicht" Anweisungen für die häufigsten Falsch-Positiv Kategorien.
• Ratenlimit Comment Volumen pro PR. Eine einzelne PR sollte nicht mehr als 5–10 Kommentare vom LLM erhalten; danach bricht Signal-Noise zusammen. Begrenze die Action auf Prompt Level ("geben zurück höchstens N Kommentare").
• Verfolge die Verdikt-zu-Merge Korrelation wöchentlich. Wenn 80% der block Verdikt trotzdem Merge, Ihr Threshold ist zu aggressiv. Wenn 0% der comment Verdikt irgendeine Human Action bekommen, produziert Ihr Prompt Rauschen.

Operational Pitfalls im zweiten Monat

• Modell Updates brechen Prompts. Ein neues Qwen3-Coder Release ändert Output Formatierung subtil; strukturiertes JSON Parsing fällt in CI; Reviews geben auf zu posten. Pinne den Model Digest mit ollama show <model> --modelfile; upgrade in einem Staging Branch bevor Sie promoten.
• GPU Memory Fragmentierung unter langer Uptime. Ein GPU Server, der 24/7 läuft, kann VRAM fragmentieren und sich weigern, neue Zuweisungen nach Wochen der Operation zu machen. Starten Sie ollama serve wöchentlich über einen Cron Job erneut; dies ist billig und vermeidet die Fehlermodus ganz.
• CI Runner Contention. Ein Self-Hosted Runner, der sowohl den LLM Server als auch andere CI Jobs hostet, wird Review Latenz unter Build Load sprengen. Trennen Sie den Runner und den GPU Server, wenn die Teamgröße ~25 Entwickler überschreitet.
• Diff Größen Wachstum. PR Größen driften nach oben; schließlich überschreitet eine PR den praktischen Arbeits Kontext des Modells und Reviews degrade stillschweigend. Füge einen Guard in der Action hinzu, der Diffs über ~30K Tokens splittet oder truncated und dem Autor warnt.
• Strom und Kühlung. Ein kontinuierlich geladener RTX 4090 zieht ~350W unter Inference und produziert eine bedeutsame Menge Hitze. Ein Closet-großer Server Room ohne aktive Kühlung wird die GPU drosseln; Drosseln kostet Latenz und Entwickler bemerken.
• Vergessene Log Rotation. Ollama loggt jeden Request Body standardmäßig. Nach drei Monaten PR Reviews ist die Log Datei groß und enthält historische PR Diffs in Klartexte. Rotate Logs wöchentlich; archivieren oder löschen pro Ihrer Daten Aufbewahrung Richtlinie.

Häufige Fehler beim Setup von lokaler LLM Code Review

• Fehler 1: Start mit einem 7B Modell auf einer 16 GB GPU. Qwen3-Coder 7B Reviews sind merklich schlechter als 30B Reviews; Entwickler verlieren schnell Vertrauen und das Projekt wird abgestellt. Wenn Sie das 30B nicht passen können, upgraden Sie entweder die GPU oder verwenden Sie eine Cloud API für die ersten sechs Monate während Sie Budget sichern.
• **Fehler 2: Blockieren PRs auf block Verdikt von Tag Eins.** Der erste Monat ist Kalibrierung; behandeln Sie alle Outputs als beratend, bis Sie die Falsch-Positiv Rate gemessen haben. Promoten Sie zu blockieren, nur nachdem die Rate unter ~5% liegt.
• **Fehler 3: Exponieren Sie ollama serve auf 0.0.0.0:11434 ohne Auth.** Dies ist das LLM-Ära Äquivalent zum Verlassen von Redis auf einer öffentlichen Schnittstelle gebunden. Binden Sie an eine private Schnittstelle und legen Sie Auth davor, bevor Sie Cross-Host exponieren.
• Fehler 4: Cache überspringen. Re-Reviewing unveränderte Dateien bei jedem CI Run verschwendet ~80% des Inference Budget auf einem typischen PR. Ein kleiner Datei-Hash + Diff-Hash Cache (Redis oder SQLite) reduziert Review Latenz und GPU Load dramatisch.
• Fehler 5: Laufen Training Jobs auf der gleichen GPU. Training sprengt VRAM Nutzung zum Limit und verhungert das Review Modell. Verwenden Sie separate GPUs oder, wenn Sie müssen Share, führen Sie Training auf einem strikten Schedule durch, das nicht mit Peak PR Hours überlappt.
• Fehler 6: Bau die GitHub Action ohne Feedback Schleife. Ein Review System ohne 👍/👎 Reaktionen kann nicht verbessert. Baue die Schleife in Woche Eins; sammele Daten; iteriere auf dem Prompt monatlich.

Quellen

• Ollama Dokumentation — Offizielle HTTP API Referenz für /api/chat, /api/generate, strukturiertem Output und Modell Management.
• vLLM Dokumentation — High-Throughput Inference Server Dokumentation; der Upgrade Path jenseits von Ollama für High-Concurrency Teams.
• GitHub Actions Dokumentation — Offizielle Referenz für Self-Hosted Runner, Secrets und die Actions JavaScript SDK, die im oben Workflow verwendet wird.
• GitHub Advanced Security Preise — Listenpreis Referenz für den Kostenvergleich; überprüfen Sie gegen Ihre echten verhandelten Bedingungen.
• Qwen3-Coder Model Card — Architektur, Kontext Fenster und Lizenz Bedingungen für das empfohlene Review Modell.
• GitLab CI/CD Referenz — Äquivalente Referenz für GitLab Teams; die LLM-Call Portion des Workflow ist identisch.

FAQ

Weiterführende Ressourcen

• Replace GitHub Copilot With a Local LLM — breiterer Kosten Ersatzkontext für Teams, die Self-Hosted AI Tooling erwägen.
• Continue.dev vs Cline vs Aider: Best Local Coding Agent in 2026 — was läuft in Pipelines vs interaktive Editor Arbeit; die Harness Schicht unter dem Modell.
• Best Local Coding Models in 2026 — Modell Seite der Gleichung: Qwen3-Coder, DeepSeek, Codestral und die Lizenzierungs Landschaft.
• System Prompt vs User Prompt: What's the Difference — Prompt-Design Fundament für den Review System Prompt.
• llama.cpp vs Ollama vs vLLM — Inference Engine Vergleich; vLLM ist der Upgrade Path jenseits von Ollama für High-Concurrency Teams.
• Power Local LLM Hub — vollständige Leitfaden Bibliothek.