GitLab Duo Self-Hosted mit vLLM: Modelle, AI Gateway und GPUs für 50 bis 500 Entwickler

GitLab Duo lokal betreiben: was Self-Hosted voraussetzt

Mit GitLab Duo Self-Hosted betreibt eine GitLab-Self-Managed-Instanz Duo-Funktionen wie Code Suggestions, Chat und die Agent Platform mit Modellen von Ihrem eigenen GPU-Server, mit vLLM als der Serving-Plattform, die GitLab dokumentiert. Nötig sind der Tarif Premium oder Ultimate mit dem Add-on GitLab Duo Enterprise, ein selbst betriebenes AI Gateway auf gewöhnlichen CPU-Servern und ein OpenAI-kompatibler vLLM-Endpunkt je Modell. Für 50 bis 500 Entwickler deckt ein Server mit zwei, vier oder acht NVIDIA RTX PRO 6000 Blackwell Server Edition nach unserer Auslegung den Bereich ab, mit Qwen3.8-27B für Agenten-Sitzungen und einem kleineren Modell für Code-Vorschläge und Chat.

Alle Angaben zu GitLab stammen aus der Dokumentation von GitLab für Version 19.6, gelesen am 25. Oktober 2026. GitLab ändert diesen Bereich mit fast jedem Release, prüfen Sie die Seiten vor der Bestellung also erneut. Für die allgemeine Wahl von Coding-Modellen, IDE-Erweiterungen und Lizenzen lesen Sie unseren Leitfaden zum privaten Coding-Assistenten; diese Seite behandelt, was für GitLab gilt.

Tarif, Add-ons und Versionen

GitLabs Seite nennt „Tier: Premium, Ultimate“ und „Offering: GitLab Self-Managed, GitLab Dedicated for Government“. Zum Add-on ist sie eindeutig: „To use GitLab Duo features with GitLab Duo Self-Hosted, you must have the GitLab Duo Enterprise add-on“, auch für Funktionen, die Duo Core oder Duo Pro über GitLabs Cloud-Gateway bieten.

Die Versionsgeschichte ist wichtig, wenn Sie ein Upgrade planen:

GitLab-Dokumentation „GitLab Duo Self-Hosted“, „Configure GitLab Duo Self-Hosted“ und „Offline deployment“ (Dokumentationsversion 19.6), gelesen am 25. Oktober 2026.

GitLab beschreibt drei Betriebsarten. In der vollständig selbst betriebenen Konfiguration betreiben Sie Ihr eigenes AI Gateway und nutzen nur unterstützte LLMs in Ihrer Infrastruktur; diese Variante „can operate in fully isolated networks“. Die Hybrid-Konfiguration schickt ausgewählte Funktionen an von GitLab verwaltete Modelle und braucht Internetzugang. Mit einer Online-Lizenz kontaktiert die Instanz GitLabs Lizenz- und Abrechnungsendpunkte über Port 443; GitLab erklärt, dass Inferenzdaten, also Code-Eingaben, Prompts und Antworten der Modelle, das Kundennetzwerk nicht verlassen. Die Abrechnung unterscheidet sich zwischen Online- und Offline-Lizenzen, die Bedingungen bestätigt der Vertrieb von GitLab; wir machen dazu keine Aussage.

Das AI Gateway: CPU-Server, keine GPU

Das AI Gateway ist GitLabs Dienst zwischen der Instanz und Ihren Modellen. GitLabs Installationsseite sagt klar: „A GPU is not needed for the AI Gateway.“ Es läuft als Docker-Image oder Helm-Chart, hört auf Port 5052 für HTTP und 50052 für den gRPC-Dienst der Agent Platform, und sein Image-Tag muss zur GitLab-Version passen: Für GitLab vX.Y.*-ee nehmen Sie das neueste Tag self-hosted-vX.Y.*-ee.

GitLabs eigene Skalierungsangaben sind die beste Orientierung:

• 2 vCPUs und 8 GB RAM bewältigen etwa 40 gleichzeitige Anfragen;
• 8 vCPUs und 32 GB bewältigen bis zu 160 gleichzeitige Anfragen, für etwa 50 bis 200 Nutzer;
• über 200 Nutzern mehrere solcher Instanzen mit Autoscaling;
• als Planungsgröße „7 RPS (requests per second) per 1000 active users“.

Code-Vervollständigung mit einem selbst betriebenen Modell läuft über die GitLab-Instanz, die IDEs der Entwickler brauchen also keinen direkten Zugang zum Gateway. Flows der Agent Platform laufen als Jobs auf Ihren GitLab-Runnern mit GitLabs Executor-Image, das Sie laut Offline-Leitfaden auf die Version festlegen, die Ihre Instanz anfordert.

vLLM als Serving-Plattform

GitLabs Seite zu den Serving-Plattformen verlangt vLLM „v0.18.1 or later“ und sagt, dass bei OpenAI-kompatiblen Plattformen wie vLLM die Endpunkt-URL auf /v1 enden muss. Im Admin-Bereich legen Sie jedes Deployment mit Namen, Modellfamilie, Endpunkt, optionalem API-Schlüssel und einer Modellkennung der Form custom_openai/<model> an.

Drei Einstellungen entscheiden, ob es in der Praxis funktioniert:

1. Tool Calling. GitLabs Modellseite verlangt --enable-auto-tool-choice und einen passenden --tool-call-parser; ohne beide scheitern Anfragen mit Tools mit der Meldung, dass „auto“ tool choice beide Flags voraussetzt. Unser Artikel zu den Tool-Calling-Parsern von vLLM nennt den Parser je Modellfamilie.
2. Kontextlänge. Die Agent Platform kürzt den Verlauf auf ein Kontextfenster von 200.000 Token, und der Code-Review-Flow sendet bis zu 1 MiB Merge-Request-Kontext. Setzen Sie --max-model-len auf den Kontext, den Sie unterstützen wollen, und legen Sie den KV-Cache dafür aus.
3. Timeouts. Das AI Gateway beendet eine einzelne Chat-Anfrage an das Modell standardmäßig nach 30 Sekunden (AIGW_DUO_CHAT__MODEL_REQUEST_TIMEOUT erhöht den Wert), das allgemeine Anfrage-Timeout liegt bei 120 Sekunden, einstellbar von 60 bis 600. Ein zu kleiner GPU-Server zeigt sich zuerst als Timeout im Chat.

Setzen Sie --api-key in vLLM und tragen Sie denselben Schlüssel in GitLab ein. Er schützt nur die Pfade unter /v1, /v2, /inference und /cohere (Sicherheitsleitfaden von vLLM 0.32.0); halten Sie die Engine also in einem internen Netz oder hinter einem LLM-Gateway mit Schlüsseln und Protokoll. Jede Duo-Funktion erhält ihr Modell aus einer Auswahlliste, Code-Vorschläge, Chat und Agent Platform können also auf verschiedenen Modellen und Karten laufen.

Welche Modelle GitLab unterstützt

GitLab bewertet jedes Modell je Funktion: F für volle, P für teilweise und L für eingeschränkte Funktionalität; ein mit L bewertetes Modell hält GitLab für die Funktion ungeeignet. Der größte Teil der Liste sind Cloud-Modelle. Die offenen Modelle, die auf einen Server mit RTX PRO 6000 Server Edition passen, sind diese:

Bewertungen F / P / L aus GitLab „Supported models and hardware requirements“ (Dokumentation 19.6; Mistral Small 24B 2506 = Mistral Small 24B Instruct 2506; CODE = Code-Vervollständigung und Code-Generierung, bei diesen vier gleich bewertet), gelesen am 25. Oktober 2026. Gewichte: Summe der Safetensors-Dateien auf Hugging Face (Mistral-Small-3.2-24B-Instruct-2506, gpt-oss-120b, Mistral-Medium-3.5-128B) und Repository-Größe von Qwen3.8-27B-FP8 (30,9 GB), gelesen am 25. Oktober 2026.

GitLab führt außerdem Llama 3.1 und 3.3 70B, Codestral 22B und sehr große Modelle wie GLM-5.3, Kimi-K2.6 und MiniMax-M2.7 sowie eine Beta-Liste „kompatibler“ Modelle wie Gemma-4-31B-IT und Qwen3.6-35B-A3B, für die GitLab keinen modellspezifischen Support gibt.

Die Lizenzen unterscheiden sich. gpt-oss-120b und Qwen3.8-27B stehen laut ihren LICENSE-Dateien unter Apache 2.0; Mistral Small 3.2 ist auf seiner Modellkarte als Apache 2.0 gekennzeichnet, sein Repository enthält keine LICENSE-Datei. Mistral Medium 3.5 steht unter einer „Modified MIT License“, deren Abschnitt 2 alle Rechte entzieht, wenn der weltweite konsolidierte Monatsumsatz Ihres Unternehmens (oder Ihres Arbeitgebers) im Vormonat 20 Millionen US-Dollar übersteigt; ein Unternehmen oberhalb dieser Grenze muss also eine kommerzielle Lizenz anfragen, die Mistral AI laut derselben Datei nach eigenem Ermessen erteilen kann. Die Lizenz von Codestral 22B schränkt den Produktiveinsatz ein, wie unser Leitfaden zum Coding-Assistenten erklärt.

GitLabs eigene Hardware-Tabelle beruht auf der A100 und älteren Modellen, von einer A100 mit 40 GB für ein 7B-Modell bis zu zwei A100 mit 80 GB für Codestral 22B, und sagt, H100 und H200 sollten funktionieren, seien aber nicht getestet. Blackwell-Karten führt sie nicht; die Kartenzahlen unten sind deshalb unsere Auslegung, nicht die von GitLab.

Wir liefern Server mit RTX PRO 6000 Server Edition und H200 NVL auf Bestellung, auf Wunsch mit eingerichtetem vLLM; nennen Sie uns die Zahl Ihrer Entwickler und die geplanten Duo-Funktionen, und unser Team antwortet mit einer Kartenaufteilung und den Modellen je Funktion.

Wie viele Sitzungen eine Karte hält

Unsere Nutzer-pro-Karte-Regel nimmt 90 Prozent des vom Treiber gemeldeten Speichers und zieht 3 GiB je Karte ab: 83,0 GiB auf einer RTX PRO 6000 Server Edition. Was die Gewichte übrig lassen, steht als KV-Cache für die laufenden Anfragen bereit. Der Cache je Token stammt aus der config.json des jeweiligen Modells.

Unsere Schätzungen nach der Nutzer-pro-Karte-Regel. Cache je 32K Token in 16 Bit: Qwen3.8-27B 2,0 GiB auf seinen 16 Full-Attention-Schichten plus höchstens 0,14 GiB Linear-Attention-Zustand; Mistral Small 3.2 5,0 GiB (40 Schichten, 8 KV-Heads zu 128); Mistral Medium 3.5 11,0 GiB (88 Schichten, 8 KV-Heads zu 128); gpt-oss-120b 1,125 GiB. Speicherrechnung, kein gemessener Durchsatz.

Qwen3.8-27B ist hier das effiziente Agenten-Modell: Nur 16 seiner 64 Schichten halten einen vollen KV-Cache, eine 32K-Sitzung kostet also etwa 2,1 GiB. Mistral Medium 3.5 ist das einzige offene Modell mit F für jede Funktion, braucht als dichtes 128B-Modell mit 88 vollen Schichten aber 11 GiB je 32K-Sitzung in 16 Bit, und zwei Karten halten drei solche Sitzungen. Auf zwei H200 NVL mit NVLink, nach unserer Regel 246,8 GiB nutzbar, hält es 11 Sitzungen zu 32K, mit FP8-Cache 22.

Für Code-Vorschläge ist die Last gering. GitLabs Planungsgröße von 7 Anfragen pro Sekunde je 1.000 aktive Nutzer ergibt für 500 Entwickler 3,5 Anfragen pro Sekunde, und jede Sekunde, die eine Anfrage in Bearbeitung bleibt, erhöht die Zahl gleichzeitiger Anfragen auf der GPU um 3,5. Mistral Small 3.2 auf einer Karte hält nach unserer Regel 30 Anfragen zu 8K Token mit 16-Bit-Cache und trägt damit die Vervollständigungen von 500 Entwicklern, solange eine Anfrage im Mittel in etwa 8 Sekunden fertig ist. Die echte Dauer misst ein Pilotbetrieb.

Konfigurationen für 50 bis 500 Entwickler

Die Agenten-Sitzungen bestimmen den Server. Unsere Regel aus dem Leitfaden zum Server für Coding-Agenten zählt eine generierende Sitzung je Entwickler zur Spitzenstunde als Obergrenze; die Duo-Nutzungsanalyse von GitLab oder das Gateway-Protokoll eines Pilotbetriebs liefern den echten Anteil, und bei einem niedrigeren Anteil bedient derselbe Server mehr Personen.

Unsere Schätzungen nach der Nutzer-pro-Karte-Regel mit einer Qwen3.8-27B-Kopie je Agenten-Karte (je 47 Sitzungen zu 32K mit FP8-KV-Cache, 25 mit 16-Bit-Cache); Leistung an der Steckdose nach unserer Schätzung mit Karten bei 600 W, zwei AMD-EPYC-Prozessoren und 15 Prozent für den Rest, wie auf unseren Server-Seiten. Planen Sie die Zuleitungen nach der Angabe des Herstellers.

Etwa 50 Entwickler: zwei Karten. Eine Karte bedient Code Suggestions und Chat mit Mistral Small 3.2, die andere betreibt Qwen3.8-27B für die Agent Platform mit 47 Sitzungen zu 32K Token bei FP8-Cache, fast eine je Entwickler. Mit 128K-Kontexten hält die Agenten-Karte 13 Sitzungen, ein Team mit langen Review-Flows braucht also früh eine zweite Agenten-Karte. Das ist unsere Einstiegskonfiguration, beschrieben auf unserer Seite zum Kauf eines Servers mit zwei Server-Edition-Karten, und sie läuft an einer Zuleitung mit 230 V und 16 A.

Etwa 150 Entwickler: vier Karten. Drei Kopien von Qwen3.8-27B halten 141 Agenten-Sitzungen zu 32K mit FP8-Cache, und die erste Karte kann Chat stattdessen mit gpt-oss-120b bedienen, das GitLab für Chat ebenfalls mit F bewertet. Der Server mit vier Server-Edition-Karten nennt Bauteile und Leistungswerte.

300 bis 500 Entwickler: acht Karten oder zwei Server. Sieben Agenten-Karten halten 329 Sitzungen zu 32K mit FP8-Cache, genug für 500 Entwickler, wenn zur Spitzenstunde etwa zwei Drittel mit einem Agenten arbeiten. Ab dieser Größe lohnen sich zwei Server mit je vier Karten statt eines Servers mit acht, damit Duo weiterläuft, wenn ein Server ausfällt; mit je einer Karte für Code und Chat halten ihre sechs Agenten-Karten 282 Sitzungen zu 32K mit FP8-Cache, und ein LLM-Gateway vor beiden verteilt die Last. Ein Server mit acht Karten braucht Drehstrom, wie unsere Seite zu acht RTX PRO 6000 Server Edition für LLMs erklärt.

Ein Modell für alles. Mistral Medium 3.5 auf allen acht Karten gibt jeder Funktion GitLabs volle Bewertung, hält in 16 Bit aber nur 49 Sitzungen zu 32K (mit FP8-Cache 98), einen Bruchteil der Qwen-Aufteilung, und seine Lizenz schließt Unternehmen oberhalb der Umsatzgrenze aus. Wir würden es nur wählen, wenn ein Pilotbetrieb zeigt, dass die kleineren Modelle für Ihren Code nicht ausreichen.

Offline- und Air-Gap-Installation

GitLabs Offline-Leitfaden behandelt Premium und Ultimate auf GitLab 18.9 oder neuer mit einer Offline-Cloud-Lizenz, für die Sie vor dem Kauf eine Ausnahme vom Cloud Licensing brauchen. In das isolierte Netz übertragen Sie das Image des AI Gateway (etwa 0,6 GiB), der Flows-Executor der Agent Platform (etwa 0,5 GiB), das Image vllm/vllm-openai ab v0.18.1 (etwa 9 GiB) und die Modellgewichte, die vLLM aus dem Dateisystem liest; GitLabs Beispiel ist Mistral Small 24B mit etwa 48 GB. Der Inferenz-Host braucht NVIDIA-Treiber, CUDA und das NVIDIA Container Toolkit. GitLab weist darauf hin, dass sein Health Check Gateway und Lizenz prüft, nicht aber die Inferenz; testen Sie Chat und Code Suggestions nach jedem Upgrade also direkt.

Das allgemeine Vorgehen für einen isolierten GPU-Server, von gespiegelten Paketen bis zu Prüfsummen, steht in unserem Leitfaden zum LLM-Server ohne Internetzugang. Bei jedem GitLab-Upgrade übertragen Sie die passenden Gateway- und Executor-Images; die Modellgewichte bleiben, solange Sie die Modelle behalten.

Was wir liefern

Wir bauen GPU-Server mit zwei, vier oder acht RTX PRO 6000 Server Edition oder H200 NVL auf Bestellung, vor der Lieferung montiert und getestet, mit Linux, NVIDIA-Treiber, CUDA und Container-Runtime auf Wunsch vorinstalliert, und unser Engineering-Partner Vixen.UNO richtet vLLM und die Modelle im Rahmen unseres Angebots Private AI/ML ein. Mengen und Lieferzeit werden mit dem Angebot schriftlich bestätigt, mit einem EU-Vertrag und einer Rechnung. GitLab-Lizenzen und Add-ons kommen von GitLab; wir liefern die Hardware und das Model Serving dahinter.

FAQ