KI-Code-Review selbst gehostet: PR-Agent oder Kodus mit lokalem LLM für Merge Requests

Was ein Review-Bot bei jedem Merge Request tut

Ein selbst gehosteter KI-Code-Review-Bot kommentiert jeden Merge oder Pull Request automatisch mit einem lokalen LLM auf Ihrer eigenen GPU, sodass Code und Diff in Ihrem Netz bleiben. Das quelloffene Werkzeug PR-Agent (MIT) leistet das für GitHub, GitLab, Bitbucket und Gitea über einen Webhook-Server oder einen CI-Job; Kodus (AGPLv3) ist eine zweite Option. Nach unserer Schätzung aus NVIDIAs veröffentlichtem Durchsatz kann eine einzige NVIDIA RTX PRO 6000 Blackwell Server Edition die Review-Last einer ganzen Entwicklungsabteilung tragen, denn Reviews warten in einer Warteschlange, und niemand sitzt vor dem Bildschirm und wartet auf die Antwort.

PR-Agent arbeitet mit Befehlen, die es beim Öffnen eines Merge Requests selbst ausführt oder die ein Entwickler als Kommentar eingibt. /describe schreibt Titel und Beschreibung, /review schreibt ein Review mit optionalen Abschnitten zu Prüfaufwand, Sicherheitsbedenken und Tests und setzt jedes wichtige Problem als Inline-Kommentar, wo die Plattform das erlaubt, /improve schlägt Codeänderungen vor, und /ask beantwortet eine Frage zur Änderung. In den Konfigurationsbeispielen von PR-Agent führen GitLab und Gitea bei jedem neuen Merge Request /describe, /review und /improve aus; das GitLab-Beispiel führt bei neuen Commits zusätzlich /describe und /review erneut aus und überspringt Draft-Merge-Requests standardmäßig.

Der Bot gibt nichts frei. Er ist ein zweiter Leser für jeden Diff, auch einen sehr großen, während die menschliche Freigabe, die Linter, die statische Sicherheitsanalyse und die Testsuite in der Pipeline bleiben. Unser Artikel zu GPU-Runnern für CI behandelt Builds und Tests auf GPUs; diese Seite handelt vom Sprachmodell, das den Code liest.

PR-Agent im Oktober 2026

Laut README hat Qodo das Projekt an die Open-Source-Community übergeben; es liegt heute in einer eigenen GitHub-Organisation, gehört der Community und wird an eine Open-Source-Stiftung übergeben. Es beschreibt sich als „distinct from Qodo's primary AI code review offering“, und Qodos frühere gehostete Enterprise-Version Qodo Merge heißt heute Qodo (2.0). Das Repository zeigt 13.600 Sterne, und PyPI führt 0.49.0 vom 25. Oktober 2026 als aktuelles Release, nach 0.48.0 vom 16. Oktober und 0.47.0 vom 2. Oktober; es setzt Python 3.12 oder neuer voraus.

Die jüngsten Releases dienen vor allem der Härtung. Seit 0.47.0 brauchen Gitea-Webhooks ein Secret, sonst werden sie mit HTTP 403 abgewiesen; 0.48.0 lässt die Docker-Images als Benutzer ohne Root-Rechte laufen und entfernt Anbieter-Tokens aus den Logs; 0.49.0 bringt eine Sperre gegen DNS-Rebinding und weitere Schwärzung von Zugangsdaten. /help_docs ist seit 0.36.1 wegen eines Problems mit offengelegten Zugangsdaten deaktiviert. Images ab 0.34.2 erscheinen als pragent/pr-agent, und die Dokumentation rät, im Produktivbetrieb ein Versions-Tag oder einen Digest festzulegen statt latest, das mit jedem Release wandert.

Für GitLab beschreibt die Dokumentation zwei Betriebsarten. Als CI-Job auf merge_request_event prüft es jeden neuen Merge Request, erhält aber keine Kommentar-Events, sodass Entwickler /review oder /improve nicht per Kommentar aufrufen können. Als Webhook-Server reagiert es auf Push-, Kommentar- und Merge-Request-Events; dafür braucht es einen eigenen GitLab-Benutzer, ein Personal Access Token mit Scope api, die Rolle Developer, wenn /describe Beschreibungen ändern darf (für Review-Kommentare genügt Reporter), und GitLab 15.7 oder neuer für den Abruf der Diffs. GITLAB__URL verweist auf eine Self-Managed-Instanz. Gitea und Bitbucket Server haben eigene Webhook-Server. Der Webhook-Server bemisst sich nach den CPUs seines Containers, standardmäßig mit 2 bis 4 Workern, und die Dokumentation schlägt als Start etwa 1 GiB Speicher für 4 Worker vor.

PR-Agent mit einem lokalen Modell verbinden

PR-Agent spricht jedes Modell über einen LiteLLM-Modellnamen an. Das Ollama-Beispiel der Dokumentation setzt model = "ollama/qwen2.5-coder:32b", custom_model_max_tokens=128000 und duplicate_examples=true, das die Formatbeispiele im Prompt wiederholt, „to help the model to generate structured output“, dazu api_base in einem Abschnitt [ollama]. Ein vLLM-Server wird als OpenAI-kompatibler Endpunkt angesprochen: model = "openai/<Modell-ID>" und api_base im Abschnitt [openai] der Datei .secrets.toml oder die Variablen OPENAI__API_BASE und OPENAI__KEY.

Das Kontextfenster muss auf beiden Seiten passen. PR-Agent warnt, dass der Standardkontext von Ollama „is not enough to cover pr-agent prompt and pull-request diff“ und dass custom_model_max_tokens zu OLLAMA_CONTEXT_LENGTH passen muss, sonst kann die Ausgabe des Modells unerwartet ausfallen. Bei vLLM setzen Sie --max-model-len und custom_model_max_tokens gemeinsam. Ist ein Diff größer als das Budget, komprimiert PR-Agent ihn: Es lässt Binär- und Nicht-Code-Dateien weg, sortiert die Dateien nach den Hauptsprachen des Repositorys und nach Größe, stellt Ergänzungen vor Löschungen, listet den Rest als „other modified files“ und überspringt, was dann noch nicht passt. Das Aufteilen eines großen Reviews in Teilstücke ist standardmäßig aus; eingeschaltet ist jedes Teilstück ein eigener Modellaufruf, bis zu max_number_of_calls, standardmäßig 3.

Bei lokalen Modellen ist die Dokumentation vorsichtig. Sie schreibt, dass „local open-source models are suitable for experimentation and learning purposes“ und „not suitable for production-level code analysis tasks“ seien, in einem Abschnitt, der sich auf die Modelle „as of January 2025“ bezieht. Qwen3-Coder und gpt-oss erschienen danach, doch keine Seite von PR-Agent bewertet sie neu. Behandeln Sie die ersten Wochen daher als Pilotbetrieb: Lassen Sie den Bot über jüngere Merge Requests laufen, die Ihre Reviewer bereits beurteilt haben, und vergleichen Sie seine Befunde mit ihren.

Sie können die Workstation oder den Server allein bestellen, die Einrichtung von vLLM, dem Review-Modell und PR-Agent für Ihren Git-Server allein oder beides zusammen: das System mit allem fertig installiert und eingerichtet; schreiben Sie uns, wir schlagen Ihnen die beste Lösung für Ihre Aufgaben und Ihr Budget vor.

Kodus, GitLab Duo und ein eigener Webhook

Kodus beschreibt sich als „Open source (AGPLv3) AI code review you self-host on-prem or in your cloud“. Seine Seite nennt GitHub Enterprise Server, GitLab Self-Managed und Bitbucket Data Center als selbst betriebene Plattformen und daneben Gitea und Forgejo, und die README ergänzt in Alltagssprache formulierte Regeln je Repository oder Pfad sowie die Nachverfolgung von Vorschlägen, die nie umgesetzt wurden. Als Modell dient jede OpenAI-kompatible API, gesetzt über drei Variablen: API_OPENAI_FORCE_BASE_URL, API_OPEN_AI_API_KEY und API_LLM_PROVIDER_MODEL. Laut Kodus werden diese Aufrufe nicht über Kodus geleitet. Es läuft mit Docker Compose und braucht mindestens 8 GB RAM, 16 GB für Repositories mit mehr als 100.000 Codezeilen, dazu PostgreSQL mit pgvector, MongoDB und RabbitMQ. SSO, rollenbasierter Zugriff, Audit-Logs und Analysen sind Enterprise-Funktionen unter kommerzieller Lizenz, und selbst gehostete Instanzen senden täglich einen anonymen Heartbeat, sofern nicht KODUS_TELEMETRY_DISABLED=true gesetzt ist.

Innerhalb von GitLab steht das ältere, nicht agentische GitLab Duo Code Review nur mit dem Add-on Duo Enterprise zur Verfügung; den Code Review Flow der GitLab Duo Agent Platform führt GitLabs Dokumentation dagegen für die Tarife Free, Premium und Ultimate, auch mit selbst gehosteten Modellen. Er läuft als CI/CD-Job auf eigenen Runnern und hat eigene Voraussetzungen (GitLab-Dokumentation 19.6, gelesen am 31. Oktober 2026). Unser Artikel zu GitLab Duo Self-Hosted hält fest, dass der Flow bis zu etwa 1 MiB Kontext aus dem Merge Request sammelt. Ein Team kann auch einen eigenen Bot auf den Webhooks des Git-Servers aufbauen. GitHubs Dokumentation verlangt eine 2XX-Antwort „within 10 seconds“ und empfiehlt eine Warteschlange für die Payloads, weil ein Review weit länger dauert; dasselbe Muster gilt für jeden Git-Server.

Welches Modell für Code-Review

Ein Review-Modell muss einen langen Diff mit den umliegenden Dateien lesen und in der Struktur antworten, die der Bot erwartet; deshalb wiederholt das Ollama-Beispiel von PR-Agent die Formatbeispiele im Prompt. Vier offene Modelle passen zur Hardware in diesem Artikel, alle unter Apache 2.0.

Modellkarten, Konfigurations- und Dateiseiten auf Hugging Face (gpt-oss-20b, Qwen3-Coder-30B-A3B, Qwen3-Coder-Next gelesen am 30. Oktober 2026; gpt-oss-120b aus unseren Coding-Artikeln, gelesen am 24. Oktober 2026). Cache in BF16 nach unserer Rechnung aus der jeweiligen config.json; ein FP8-Cache halbiert ihn.

Qwen3-Coder-30B-A3B ist der übliche Einstieg: Seine Modellkarte beschreibt Tool Calling und einen nativen Kontext von 262.144 Token, und es arbeitet nur im Non-Thinking-Modus, was die Antworten kurz hält. gpt-oss-20b unterstützt strukturierte Ausgaben und drei Reasoning-Stufen, die im Systemprompt gesetzt werden, und passt auf eine Karte mit 32 GB. Qwen3-Coder-Next passt auf eine RTX PRO 6000 mit 96 GB, mit Platz für nach unserer Regel nur etwa 5 Sitzungen zu 64K; es läuft daher am besten als Tensor-Parallel-Paar auf zwei Karten, was zu einem Review passt, das sich den Server mit den Coding-Agenten teilt. Unser Leitfaden zum privaten Coding-Assistenten nennt die Lizenzen dieser Modelle und solcher, die die kommerzielle Nutzung einschränken.

Wie viele Merge Requests eine GPU pro Stunde prüft

Code-Review ist Batch-Arbeit. Ein Merge Request kann eine Minute auf seine Kommentare warten; entscheidend ist daher, wie viele Aufrufe eine Karte pro Stunde erledigt. Der nächstliegende veröffentlichte Wert ist NVIDIAs TensorRT-LLM-Leistungstabelle für Qwen3-30B-A3B, das dieselben Schichten, Heads und Experten hat wie das Coder-Modell: In FP4 auf einer RTX PRO 6000 Server Edition erzeugt es 374 Ausgabe-Token pro Sekunde bei Prompts von 32.768 Token und Antworten von 1.024 Token und 1.914 bei Prompts von 8.192 Token, gemessen bei maximalem Durchsatz mit allen Anfragen in der Warteschlange. Nach unserer Rechnung sind das etwa 22 Aufrufe pro Minute mit 32K-Prompts und 112 mit 8K-Prompts. Macht jeder der drei Befehle einen Aufruf je Merge Request, wie wir für ein Review ohne Aufteilung annehmen, erledigt die Karte mit 32K-Prompts etwa 440 Merge Requests pro Stunde. Das ist eine Obergrenze für FP4 auf der Server Edition; FP8-Gewichte und eine nicht voll ausgelastete Warteschlange erreichen weniger, und ein Pilot misst Ihren Wert.

Der Speicher legt fest, wie viele Reviews gleichzeitig laufen. Nach unserer Regel für Nutzer je Karte (90 Prozent des Speichers, den der Treiber meldet, abzüglich 3 GiB je Karte und abzüglich der Gewichte) bleiben auf einer Karte mit 32 GB 25,7 GiB, auf der RTX PRO 5000 72 GB 61,5 GiB und auf einer RTX PRO 6000 mit 96 GB 83,0 GiB.

Nach unserer Regel für Nutzer je Karte, BF16-Cache (FP8-Cache in Klammern; gpt-oss-20b nur mit BF16-Cache). Durchsatz: NVIDIA TensorRT-LLM Performance Overview, gelesen am 30. Oktober 2026, Ausgabe-Token pro Sekunde je GPU bei maximalem Durchsatz, gemessen auf der RTX PRO 6000 Blackwell Server Edition.

Auf einer RTX PRO 6000 Blackwell mit 96 GB passt auch gpt-oss-120b, mit 9 Reviews zu 64K oder 4 zu 128K. In einer Workstation ist die Karte die RTX PRO 6000 Workstation Edition oder Max-Q; im Rack-Server für den Dauerbetrieb empfehlen wir die Server Edition, die passive Karte, auf der NVIDIAs Tabelle gemessen wurde.

Auf einem gemeinsam genutzten Coding-Server bekommt das Review eine eigene Engine-Instanz, damit eine Welle von Merge Requests die Agenten der Entwickler nicht bremst, entweder auf einer eigenen Karte oder in einer MIG-Instanz einer RTX PRO 6000, wie unser Artikel zu den MIG-Profilen der RTX PRO 6000 beschreibt. Große Reviews können auch auf den Abend warten. Diese Aufteilung, eine Review-Instanz neben der Instanz der Agenten, richten wir auf Ihrem Server ein; beschreiben Sie uns Ihre heutige Git- und CI-Umgebung, und wir schlagen vor, wie die Karten aufgeteilt werden. Unser Artikel zum Server für Coding-Agenten dimensioniert die Agentenseite eines solchen Servers.

Tokens, Logs und Geheimnisse

Das Wertvollste, was der Bot besitzt, ist sein Token. Geben Sie dem Bot einen eigenen Git-Benutzer mit der niedrigsten Rolle, die funktioniert, in GitLab Reporter für Kommentare und Developer nur, wenn /describe Beschreibungen umschreiben darf, und erneuern Sie das Token wie alle Zugangsdaten eines Dienstes. Setzen Sie auf jeder Plattform ein Webhook-Secret; PR-Agent weist Gitea-Webhooks ohne Secret seit 0.47.0 ab.

Diffs enthalten, was Entwickler committen, manchmal auch einen Schlüssel oder ein Passwort. Protokollieren Sie die Aufrufe an einem LLM-Gateway mit Nutzer, Modell und Token-Zahl, und entscheiden Sie bewusst, ob Prompts überhaupt gespeichert werden; welcher Code zu welchem Werkzeug darf, behandelt unser Leitfaden zur Richtlinie für KI-Coding-Assistenten. Halten Sie vLLM im internen Netz, wie unser Artikel zum Absichern eines GPU-Servers erklärt: Laut dem Sicherheitsleitfaden von vLLM für Version 0.32.0 schützt --api-key nur die Pfade unter /v1, /v2, /inference und /cohere. Legen Sie das PR-Agent-Image auf eine Version fest, damit ein Update des Bots eine Änderung ist, die Sie wie jede andere prüfen.

Wir binden den Review-Bot an Ihren GitLab-, Gitea- oder Bitbucket-Server an und richten das Modell dahinter ein; nennen Sie uns Ihre Git-Plattform und die Zahl der Merge Requests, die Ihre Teams pro Tag öffnen, und wir dimensionieren das System für Ihre Aufgaben und Ihr Budget.

FAQ