Privater Coding-Assistent auf eigener Hardware: welches LLM, welche GPU fürs Team

Code­vervollständigung, Chat und Agenten: drei Bemessungsregeln

Einen privaten Coding-Assistenten dimensioniert man nach der Zahl gleichzeitig laufender Agentensitzungen. Nach unserer Regel für Nutzer je Karte fasst eine RTX PRO 6000 Qwen3-Coder-30B-A3B in FP8 mit 8 Sitzungen von 64K Token (17 mit einem FP8-Cache) und eine H200 NVL 15, während ein DGX Spark für ein Pilotprojekt oder ein kleines Team passt. Wir liefern alle drei und bauen damit GPU-Server auf Bestellung. Schreiben Sie uns, wie Ihre Entwickler Agenten einsetzen, unser Team hilft Ihnen weiter.

Code­vervollständigung ergänzt Code, während Sie tippen. Die IDE-Erweiterung sendet den Code vor und nach dem Cursor, das Modell schreibt die Mitte (Fill-in-the-Middle, FIM), und der Vorschlag hilft nur, wenn er vor dem nächsten Tastendruck ankommt. Das verlangt ein kleines Modell, das für diese Aufgabe trainiert ist. Die Erweiterung Continue (seit ihrem letzten Release schreibgeschützt, siehe unten) schreibt, dass die von ihr vorgeschlagenen Modelle „mit einem sehr spezifischen Prompt-Format trainiert werden“ und dass „die meisten der modernsten Autocomplete-Modelle nicht mehr als 10 Milliarden Parameter haben“; für den lokalen Einsatz verweist sie auf ollama run qwen2.5-coder:1.5b, einen Download von 986 MB für ein Modell mit 1,54 Milliarden Parametern unter Apache 2.0 und einem Kontext von 32K. Qwen gibt an, dass FIM ebenfalls „in jeder Version von Qwen3-Coder unterstützt wird“.

Chat ist ein Entwickler, der Fragen zu Code stellt, den er einfügt: Prompts mit einigen tausend Token und Antworten, die in menschlichem Tempo gelesen werden. Auf einem DGX Spark ergeben die Zahlen der Maintainer von llama.cpp für Qwen3-Coder-30B-A3B in 8 Bit mit Prompts von 4.096 Token umgerechnet 15 Token pro Sekunde je Anfrage bei 8 gleichzeitigen Anfragen und 10 bei 16.

Agenten bearbeiten Dateien und führen Befehle in Schritten aus. Jeder Schritt ist ein Modellaufruf, der die bisherige Aufgabe mitführt: Anweisungen, die gelesenen Dateien, Befehlsausgaben und die früheren Schritte. Prompts wachsen auf Zehntausende Token, und die Dokumentation von Ollama verlangt für Agenten und Coding-Werkzeuge mindestens 64.000 Token Kontext.

Warum Agenten die Dimensionierung verändern

Das Einlesen eines Prompts ist Rechenarbeit; die Token-Generierung ist durch die Speicherbandbreite begrenzt, und jeder Schritt liest außerdem den Cache der Sitzung. NVIDIAs eigener Agententest auf dem DGX Spark, veröffentlicht im März 2026, ließ Qwen3 Coder Next in FP8 auf vLLM laufen: Ein Prompt mit 128K Token brauchte 54 Sekunden zum Einlesen, und die vollständige Antwort lag nach 89 Sekunden vor. Mit Prompts von 32K Token und Antworten von 1K Token dauerte eine Aufgabe 35 Sekunden, zwei gleichzeitig 54 Sekunden und vier gleichzeitig 91 Sekunden. Das erste Token kam im Median nach 9, 12 und 15 Sekunden, und laut NVIDIA stieg der Durchsatz bei der Prompt-Verarbeitung von einer auf vier Aufgaben auf etwa das Dreifache; die Generierung der Antworten dauerte länger als das Einlesen der Prompts. Bei llama.cpp zeigen die Zahlen der Maintainer dagegen, dass sich die Prompts stauen. Qwen3-Coder-30B-A3B liest auf einem Spark etwa 2.700 bis 2.900 Prompt-Token pro Sekunde, ob eine Anfrage wartet oder zweiunddreißig, sodass acht Prompts mit 8.192 Token 24 Sekunden brauchen, bevor die Antwort auf den letzten beginnt.

NVIDIAs Performance-Tabellen für TensorRT-LLM, gemessen bei maximalem Durchsatz, enthalten Qwen3-30B-A3B, das dieselbe Zahl an Schichten, Köpfen und Experten hat wie das Coder-Modell. In FP4 auf einer RTX PRO 6000 Server Edition erzeugt es 9.938 Ausgabe-Token pro Sekunde bei Prompts und Antworten von 1.000 Token, 1.914 bei Prompts von 8.192 Token und 374 bei Prompts von 32.768 Token, die letzten beiden mit Antworten von 1.024 Token. Nach unserer Rechnung sind 374 Token pro Sekunde bei 1.024 Token je Antwort etwa 22 abgeschlossene Aufrufe mit 32K Token pro Minute für die ganze Karte, die sich alle Agenten darauf teilen.

Prefix Caching senkt diesen Aufwand. Der nächste Aufruf eines Agenten beginnt meist mit denselben Token wie sein vorheriger, und vLLM (Prefix Caching standardmäßig aktiv), SGLang (RadixAttention) und TensorRT-LLM (Wiederverwendung von KV-Blöcken) können den zwischengespeicherten Teil wiederverwenden, solange er noch im Speicher liegt. Keiner der Tests oben weist eine solche Wiederverwendung aus, und den Cache resident zu halten kostet Speicher. Unser Artikel zu einem DGX Spark für ein Team enthält die vollständigen Zahlen zu gleichzeitigen Anfragen für einen Spark.

Offene Coding-Modelle und ihre Lizenzen

Parameter und Lizenzen aus den Model Cards und der API von Hugging Face, September 2026; die Gewichte sind bei gpt-oss Dateigrößen und bei den übrigen Tensor-Bytes. Cache je Sitzung mit 64K Token in BF16, nach unserer Rechnung aus der jeweiligen config.json; ein FP8-Cache halbiert ihn.

Alle sechs erlauben die kommerzielle Nutzung unter Apache 2.0. Drei Modelle, die bei denselben Suchen auftauchen, sind an Bedingungen geknüpft: Devstral 2 (123B), dessen modifizierte MIT-Lizenz Unternehmen oberhalb einer monatlichen Umsatzschwelle ausschließt; Codestral 22B, dessen Lizenz „Mistral AI Non-Production License“ die Nutzung auf „testing, research, Personal, or evaluation purposes in Non-Production Environments“ beschränkt; und Qwen2.5-Coder-3B, dessen Qwen-Research-Lizenz „FOR NON-COMMERCIAL PURPOSES ONLY“ gilt, obwohl seine Geschwistermodelle mit 1,5B und 7B unter Apache 2.0 stehen. Die Model Cards von Qwen3-Coder geben an, dass die Modelle nur den Non-Thinking-Modus unterstützen. Stand 16. Oktober 2026 führt Mistrals Dokumentation Devstral 2 und Devstral Small 2 unter „Deprecated & retired models“; diese Liste betrifft Mistrals API, die Gewichte beider Modelle sind weiterhin auf Hugging Face veröffentlicht. Neuere offene Modelle brauchen je Sitzung weit weniger Cache: Nach derselben Regel hält eine RTX PRO 6000 Qwen3.6-35B-A3B (Apache 2.0) in FP8 mit 18 Sitzungen zu 128K Token, wie unser Leitfaden Claude Code mit lokalem Modell zeigt.

Speicher: die Gewichte plus ein Cache je Sitzung

Jede offene Sitzung hält ihren eigenen Key/Value-Cache. Je Token sind das 2 × Schichten × Key/Value-Köpfe × Kopfdimension × Byte je Wert, mit den Zahlen aus der config.json des jeweiligen Modells. Qwen3-Coder-30B-A3B hat 48 Schichten, 4 Key/Value-Köpfe und eine Kopfdimension von 128: 96 KiB je Token in BF16, 6 GiB für eine Sitzung mit 64K Token und 24 GiB bei seinen nativen 256K. Devstral Small 2 hat 40 Schichten mit 8 Key/Value-Köpfen der Dimension 128: 160 KiB je Token und 10 GiB je 64K-Sitzung.

Modelle, deren Attention nur in einigen Schichten den vollen Kontext abdeckt, brauchen weit weniger. In gpt-oss-120b nutzen 18 von 36 Schichten ein Sliding Window von 128 Token, das der Cache-Manager von vLLM nur für „die jüngsten sliding_window_size Token“ vorhält, sodass 36 KiB je Token bleiben. Qwen3-Coder-Next hält in 12 seiner 48 Schichten einen Cache je Token, 24 KiB je Token; die übrigen 36 nutzen Linear Attention mit einem festen Zustand je Anfrage, den wir auf unter 80 MiB schätzen. Ein FP8-Cache (--kv-cache-dtype fp8 in vLLM) halbiert jeden Wert je Token, nicht aber den Zustand der Linear Attention, und kann ohne kalibrierte Skalierungsfaktoren Genauigkeit kosten.

Gewichte und Cache müssen in den Speicher passen, den die Engine nutzen darf. Nach unserer Regel für Nutzer je Karte, wie in unserem Artikel zu Nutzern pro RTX PRO 6000, sind das 90 Prozent des Speichers, den der Treiber meldet, abzüglich etwa 3 GiB je Karte für Aktivierungen und CUDA Graphs; die Zahlen unten sind also Obergrenzen. Damit bleiben 61,5 GiB auf der RTX PRO 5000 mit 72 GB (wir haben keinen Treiberwert dafür gefunden und rechnen die 95,6 GiB der 96-GB-Karte auf 71,7 GiB herunter, wie unsere anderen Artikel zur RTX PRO 5000), 83,0 GiB von den 95,6 GiB, die eine 96-GB-Karte anzeigt, und 123,4 GiB auf einer H200 NVL. vLLM gibt beim Start den tatsächlichen Wert als „Maximum concurrency“ für den eingestellten Kontext aus, wie der genannte Artikel erklärt.

Hardwarestufen und was die Zahlen hergeben

Dimensionieren Sie die Hardware nach der Zahl gleichzeitiger Sitzungen statt nach der Zahl der Entwickler. Ein Entwickler, dessen Agent gerade arbeitet, belegt einen langen Kontext, während Anfragen zur Code­vervollständigung und im Chat kurz sind. Die Tabelle zählt Sitzungen mit 64K Token, die neben den Gewichten Platz finden, mit der nächstliegenden veröffentlichten Messung je Stufe.

Sitzungen mit 64K Token neben Qwen3-Coder-30B-A3B oder Qwen3-Coder-Next in FP8, Cache in BF16 (FP8-Cache in Klammern), nach unserer Rechnung; die Werte für Coder-Next enthalten je Sitzung bis zu 80 MiB Zustand der Linear Attention. Arbeitsbudget des DGX Spark aus unserem Artikel zu den 128 GB (0,8 und 0,9 des Pools); bei 0,7 aus NVIDIAs vLLM-Startskript für einen Spark, rund 90 GB, fasst Coder 30B-A3B etwa 9 (18) Sitzungen. NVIDIA-Daten: DGX-Spark-Blog, März 2026; Performance-Tabellen von TensorRT-LLM (Dokumentation 1.3.0rc29, abgerufen am 5. Oktober 2026), Ausgabe-Token pro Sekunde je GPU bei maximalem Durchsatz, Antworten von 1.024 Token nach 32K-Prompts und von 1.000 nach 1K.

DGX Spark eignet sich für ein Pilotprojekt oder ein kleines Team: Die Geschwindigkeit begrenzt ihn früher als der Speicher, und NVIDIAs Agententabelle endet bei vier parallelen Aufgaben, 91 Sekunden für alle vier. Auf der RTX PRO 5000 72 GB lässt gpt-oss-120b nach dieser Regel etwa 0,7 GiB übrig, zu wenig für eine 64K-Sitzung. Zwei RTX PRO 6000 liefern als zwei Kopien eines Modells, das auf eine Karte passt, den höchsten Durchsatz: In NVIDIAs Tabelle erzeugte eine per Expertenparallelität auf zwei Karten verteilte Kopie bei 1K-Prompts 8.409 Ausgabe-Token pro Sekunde je Karte, gegenüber 9.938 auf einer. Eine Kopie über beide fasst mehr 64K-Sitzungen, 22 gegenüber 16 mit einem BF16-Cache nach unserer Rechnung, und ein größeres Modell lässt sich weiterhin über PCIe auf beide verteilen. Vier Karten fassen Qwen3-Coder-Next am besten als zwei Paare: Mit 2 Key/Value-Köpfen würde eine Aufteilung auf vier Karten seinen Cache duplizieren, und vLLM schaltet seinen Custom All-Reduce bei mehr als zwei GPUs ohne NVLink ab. Jedes Paar tauscht seine Daten über PCIe aus, und keine veröffentlichte Messung deckt diese Anordnung ab; planen Sie deshalb einen Lasttest im Pilotbetrieb ein. Unser Leitfaden zum Server für Coding-Agenten dimensioniert zwei, vier und acht Karten der Server Edition für 20 bis 100 Entwickler.

Die H200 NVL führt FP8 aus, als Hopper-Karte aber keine FP4-Arithmetik. NVIDIAs nächstliegender Wert gilt für die H200 SXM mit denselben 141 GB und 4,8 TB/s; die NVL hat laut NVIDIAs Spezifikationen etwa 16 Prozent weniger FP8-Rechenleistung. Qwen3-Coder-480B-A35B braucht einen Server mit mehreren GPUs: Vier H200 NVL lassen nach seinen 482,1 GB FP8-Gewichten etwa 44 GiB für den Cache übrig, also fünf 64K-Sitzungen mit einem FP8-Cache.

Sie können den Server allein bestellen, die Einrichtung von vLLM und Qwen3-Coder-30B-A3B für Cline oder Kilo Code allein oder beides zusammen: den Server mit allem fertig installiert und eingerichtet; nennen Sie uns, wie viele Agentensitzungen gleichzeitig laufen, wir schlagen Ihnen die beste Lösung für Ihre Aufgaben und Ihr Budget vor.

Bereitstellung und Anbindung der IDE

Stellen Sie das Hauptmodell für ein Team mit vLLM oder SGLang bereit, die kontinuierlich Batches bilden und Präfixe wiederverwenden; unser Vergleich der Engines enthält die Details. Agenten brauchen Tool Calling, das vLLM mit --enable-auto-tool-choice und dem Parser des Modells aktiviert, SGLang allein mit dem Parser. Die Model Card von Qwen3-Coder-Next verwendet für beide --tool-call-parser qwen3_coder, die von Devstral Small 2 --tool-call-parser mistral für vLLM. Stellen Sie den Kontext ein, den Sie planen, nicht das Maximum des Modells: --max-model-len in vLLM, --context-length in SGLang.

Betreiben Sie das Modell für die Code­vervollständigung als eigene kleine Instanz, auf einer eigenen GPU, wenn Agenten die Haupt-GPU auslasten: vLLM stellt je Server ein Modell bereit, und sein Speicheranteil wird je Instanz festgelegt. llama-server hat einen Endpunkt /infill für FIM, und Ollama akzeptiert ein Suffix an seinem OpenAI-kompatiblen Completions-Endpunkt. NVIDIAs eigenes DGX-Spark-Playbook kombiniert Continue mit Ollama und gpt-oss:120b; das passt für ein Pilotprojekt, sobald der unten beschriebene Proxy davorgeschaltet ist, denn das Playbook öffnet Ollama für das Netzwerk (OLLAMA_HOST=0.0.0.0:11434, OLLAMA_ORIGINS=*). Continue erhält keine Updates mehr; ein Pilotprojekt, das wachsen soll, läuft deshalb besser mit Cline oder Kilo Code gegen denselben Endpunkt. Verwenden Sie Ollama ab 0.35.0: Frühere Versionen sind von der am 8. Oktober 2026 veröffentlichten CVE-2026-103663 betroffen, über die eine nicht authentifizierte Anfrage an /api/pull Dateien außerhalb des Modellspeichers schreiben und, wo der Ollama-Dienst in /usr/lib/ollama schreiben kann, nach einem Neustart zur Ausführung von Code als root führen kann. Für vLLM verwenden Sie 0.31.0 oder neuer, das die Sicherheitslücke GHSA-h3rc-6mm3-gc2m behebt, besser das aktuelle Release 0.33.0 vom 2. November 2026, dessen Builds für CUDA 13.0 einen Treiber ab R580 brauchen (Stand November 2026). Für mehr als einen Nutzer erhöhen Sie OLLAMA_NUM_PARALLEL und setzen den Kontext, zum Beispiel OLLAMA_CONTEXT_LENGTH=64000 ollama serve.

IDE-Erweiterungen: Cline, Kilo Code und Continue

Stand Oktober 2026 verbinden zwei gepflegte Open-Source-Erweiterungen die IDE mit Ihrem eigenen Modell, Cline und Kilo Code, während Continue, das auch die Code­vervollständigung abdeckte, schreibgeschützt ist. Continue, verfügbar als IDE-Erweiterungen und als CLI, verbindet sich mit provider: openai und einer apiBase mit jedem OpenAI-kompatiblen Server, führt vLLM und TensorRT-LLM unter den kompatiblen Servern und gibt einem Modell für die Code­vervollständigung die Rolle autocomplete. Stand Oktober 2026 hält sein GitHub-Repository fest, dass es nicht mehr aktiv gepflegt wird und für alle Nutzer schreibgeschützt ist („is no longer actively maintained and is read-only for all users“), nach einem letzten Release 2.0.0 seiner IDE-Erweiterungen und der CLI. Cline, ein Agent für IDE und Terminal, der mit Zustimmung des Nutzers Dateien bearbeitet und Befehle ausführt, nimmt unter seinem Provider „OpenAI Compatible“ eine Basis-URL, einen Schlüssel, eine Modell-ID und ein Kontextfenster entgegen und empfiehlt für lokale Modelle seine Einstellung „Use Compact Prompt“; es steht unter Apache 2.0. Kilo Code, unter der MIT-Lizenz, nimmt als Provider „OpenAI Compatible“ eine Basis-URL, einen optionalen Schlüssel und Modell-IDs entgegen und dokumentiert Ollama und LM Studio für lokale Modelle; laut Dokumentation laufen seine Autocomplete-Anfragen über das Kilo Gateway (gelesen am 31. Oktober 2026), für die Inline-Vervollständigung mit Ihrem eigenen Modell siehe daher unseren Leitfaden zum Code-Completion-Server. Roo Code, eine dritte Agenten-Erweiterung, wurde am 15. Mai 2026 eingestellt und sein Repository archiviert. Welche Werkzeuge ein Team heute noch einführen kann, mit ihren Teamfunktionen und der GPU für jedes, vergleicht unser Leitfaden zu GitHub-Copilot-Alternativen selbst gehostet.

Governance: Quellcode im eigenen Netz halten

Halten Sie jeden Endpunkt im internen Netz hinter einem authentifizierenden Proxy. Ollama lauscht standardmäßig auf 127.0.0.1 und ignoriert API-Schlüssel („required but ignored“ in seinen Beispielen). Das eigene Container-Image von Ollama setzt jedoch OLLAMA_HOST=0.0.0.0:11434, und der dokumentierte Aufruf docker run mit -p 11434:11434 gibt den Port auf allen Adressen des Hosts frei; ein so eingerichteter Server macht also eine API ohne Authentifizierung von außen erreichbar. vLLM lauscht auf allen Schnittstellen, sofern --host nicht gesetzt ist. vLLM und llama-server prüfen einen --api-key, verwalten aber keine Benutzerkonten; der Schlüssel von vLLM schützt nur Pfade unter /v1, /v2, /inference und /cohere, und seine Sicherheitsseite nennt Routen, die er offen lässt, etwa /invocations, /pause und /update_weights. Protokollieren Sie am Proxy, wer welches Modell wann und mit wie vielen Token aufgerufen hat; Prompts enthalten Quellcode, entscheiden Sie also, ob Sie sie überhaupt speichern. Protokolle je Entwickler sind personenbezogene Daten im Sinne der DSGVO; Zweck und Aufbewahrungsdauer bestätigt Ihr Datenschutz­beauftragter vor der Einführung. Richten Sie die Erweiterungen nur auf Ihren Endpunkt und prüfen Sie deren Telemetrie: Cline dokumentiert einen Schalter für die Telemetrie und gibt an, dass seine Telemetrie Code, Dateiinhalte und Gesprächsinhalte ausschließt.

Was wir liefern

Wir liefern die Hardware für jede Stufe EU-weit, unter einem Vertrag und auf einer Rechnung, mit Herstellergarantie: die DGX Spark Founders Edition (128 GB), die RTX PRO 5000 72 GB, die RTX PRO 6000 als Workstation Edition, Max-Q und Server Edition sowie die H200 NVL. Die GPUs gibt es als Karten oder in nach Auftrag gebauten KI-Servern, mit NVIDIA AI Enterprise im selben Angebot, wo es nötig ist. Wenn Sie das Modell zusätzlich on-premise bereitstellen lassen möchten, mit Zugriffskontrolle und Protokollierung von Anfragen und Antworten, ist das unser Service Private AI/ML.

FAQ