Ein privater Coding-Assistent auf eigener Hardware: welche Modelle, wie Sie sie bereitstellen, welche GPU für welches Team

Drei Arbeitslasten, drei Regeln für die Dimensionierung

Codevervollstä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 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, da vLLM vier Prompts zusammen nach unserer Rechnung etwa 2,4-mal so schnell einlas wie einen; die Generierung der Antworten nahm den Rest der Zeit ein und dauerte länger als das Einlesen der Prompts. In den Zahlen der Maintainer von llama.cpp stauen sich Prompts sehr wohl: 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, nennen für 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: 9.938 Ausgabe-Token pro Sekunde bei Prompts und Antworten von 1.000 Token, dann 1.914 und 374 bei Prompts von 8.192 und 32.768 Token und 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 mildert das. 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 ein Gerät.

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.

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. Wir halten ein Zehntel in Reserve: 64,8 GiB auf der RTX PRO 5000 mit 72 GB, wobei wir 72 GB als 72 GiB ansetzen, da wir keinen Treiberwert dafür gefunden haben, 86,0 GiB von den 95,6 GiB, die eine 96-GB-Karte anzeigt, und 126,4 GiB auf einer H200 NVL. vLLM gibt beim Start den tatsächlichen Wert als „Maximum concurrency“ für den eingestellten Kontext aus, wie unser Artikel zu Nutzern pro RTX PRO 6000 erklärt.

Hardwarestufen und was die Zahlen hergeben

Dimensionieren Sie nach gleichzeitigen Sitzungen, nicht nach Kopfzahl: Ein Entwickler, dessen Agent gerade arbeitet, belegt einen langen Kontext, während Anfragen zur Codevervollstä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. NVIDIA-Daten: DGX-Spark-Blog, März 2026; Performance-Tabellen von TensorRT-LLM (Dokumentation 1.3.0rc28), 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 sich gpt-oss-120b mit etwa 4 GiB Reserve laden, was einer Sitzung entspricht. Zwei RTX PRO 6000 liefern als zwei Kopien eines Modells, das auf eine Karte passt, den höchsten Durchsatz: In NVIDIAs Tabelle erzeugte eine Kopie über zwei Karten 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, 23 gegenüber 18 mit einem BF16-Cache nach unserer Rechnung, und ein größeres Modell lässt sich weiterhin über PCIe auf beide verteilen.

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 56 GiB für den Cache übrig, also sieben 64K-Sitzungen mit einem FP8-Cache.

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: vLLM erwartet --enable-auto-tool-choice plus den Parser des Modells, SGLang nur den 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 Codevervollstä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, was für ein Pilotprojekt passt; für mehr als einen Nutzer erhöhen Sie OLLAMA_NUM_PARALLEL und setzen den Kontext, zum Beispiel OLLAMA_CONTEXT_LENGTH=64000 ollama serve.

Zwei Erweiterungen unter Apache 2.0 decken die drei Arbeitslasten ab. 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 Codevervollständigung die Rolle autocomplete. 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“.

Governance: Der Code bleibt im Haus

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, und die Dokumentation von vLLM warnt, dass sein Schlüssel Routen wie /invocations offen lässt. 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. 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

Eurokommerz liefert DGX Spark, die RTX PRO 5000 72 GB, die RTX PRO 6000 Workstation und Max-Q sowie die H200 NVL EU-weit mit Herstellergarantie, einzeln oder in nach Auftrag gebauten KI-Servern. Wir konfigurieren die Maschine für das Modell, den Kontext und die Engine, die Sie planen, mit NVIDIA AI Enterprise, wo es nötig ist; die Seite zur RTX PRO 6000 behandelt die Karte mit 96 GB.

FAQ